Защищаемся От Шеллов

[Grind 71]

Несколько основных моментов настройки apache+php, которые сделают ваш веб-сервер существенно устойчивым к шеллам.

 

На примере debian

 

/etc/apache2/conf.d/security

 

# скрываем информацию об установленной ОС, версии веб-сервера, модулях и прочую информацию,

# которая может помочь взломщику в определении уязвимостей веб-сервера

ServerTokens Prod

ServerSignature Off

 

# Запрещаем апачу какие-либо действия с файлами вне разрешенной зоны

# пусть директория с сайтами будет /var/www

 

<Directory />

Order Deny,Allow

Deny from all

</Directory>

<Directory /var/www>

Order Allow,Deny

Allow from all

</Directory>

 

# Отключаем выполнение скриптов CGI и листинг папок

Options -ExecCGI -Indexes

 

/etc/php5/apache2/php.ini

 

# По умолачанию PHP готов рассказать всему миру о том какая у него версия, какие модули и прочую

# информацию, которая может быть полезна вломщику в поиску уявимостей. Поэтому мы это отключим

expose_php = Off

 

# Этот параметр основная причина шеллов. Запретим PHP открывать соединения с внешними серверами.

allow_url_fopen = Off

 

# Запретим PHP доступ в какие-либо места, кроме папки с сайтами, и папки для временных файлов

open_basedir = /var/www/:/tmp/

 

# Если же шелл всетаки как-то попал на наш сайт, делаем невозможным его функционирование, путем отключения

# небезопасных функций php

 

disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,

pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,

exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,escapeshellarg,escapeshellcmd,ini_alter,proc_close,

proc_get_status,proc_nice,proc_terminate,symlink

Изменено 19 ноября, 2013 пользователем Grind

[Grind 71]

Если вы обладаете достаточными знаниями, можно сделать ваш веб-сервер неуязвимым с помощью установки и настройки модуля mod_security

http://www.modsecurity.org/

Изменено 19 ноября, 2013 пользователем Grind

[Akumu 1117]

Если вы обладаете достаточными знаниями, вы не будете использовать Apache.

[Twinker 487]

Использование Apache это уже огромная дыра в безопасности.

Да и методы тут просто отличные. (Сарказм). Лишь несколько из них хороши в деле.

Кстати, curl_exec это очень опасная функция, её обязательно нужно запретить, как это сделали вы!

 

//UPD

Не видел сообщение Akumu (Открыл тему давно)

Изменено 19 ноября, 2013 пользователем Twinker

[Grind 71]

Если вы обладаете достаточными знаниями, вы не будете использовать Apache.

Не будем спорить об этом. Я привел пример наиболее часто используемой связки.

Никаких "дыр" в apache нет. Дыры могут быть в голове у того кто его настраивает.

 

Лично я предпочитаю коммерческий lightspeed webserver.

[Twinker 487]

Не будем спорить об этом. Я привел пример наиболее часто используемой связки.

Никаких "дыр" в apache нет. Дыры могут быть в голове у того кто его настраивает.

 

Лично я предпочитаю коммерческий lightspeed webserver.

Кто говорит, что есть дыры (не без них конечно)? Сравните хотя-бы производительность. Akumu все верно сказал. Сам раньше Apache использовал. Перешел на NGINX + PHP-fpm. Сижу, радуюсь. Не хватает некоторых вещей из Apache, но это не критично.

Изменено 19 ноября, 2013 пользователем Twinker

[r0n1x 126]

Странно читать про производительность Apache от умных людей... Для чего же существует связка Nginx + Apache

Скажите - "зачем апач, можно пользовать один нгинкс!"...? Погуглите яндекс...

[Twinker 487]

Странно читать про производительность Apache от умных людей... Для чего же существует связка Nginx + Apache

Скажите - "зачем апач, можно пользовать один нгинкс!"...? Погуглите яндекс...

Эмм...

NGINX для отдачи статического контента (картинки, html, файлы и т.п), Apache для отдачи не статического контента (php). Все предельно ясно

 

На NGINX + PHP-fpm не хотят переходить из за устоявшихся принципов. Apache более удобен... Apache более простой... и т.п. На самом-же деле все не так. Понимаешь это лишь после установки NGINX и сбора php-fpm

 

P.s "один NGINX" нельзя использовать в целях хостинга проектов

Изменено 19 ноября, 2013 пользователем Twinker

[Akumu 1117]

Не будем спорить об этом. Я привел пример наиболее часто используемой связки.

Никаких "дыр" в apache нет. Дыры могут быть в голове у того кто его настраивает.

 

Лично я предпочитаю коммерческий lightspeed webserver.

 

Никто и не говорил про дыры. Я лишь уточнил что использовать Apache для чего-то выше кулинарного блога домохозяйки, крайне не рекомендуется

Индеец уж слишком прожорлив и не держит особо больших нагрузок aka ddos.

 

Но если вдруг на блог этой домохозяйки ополчились злые хакеры, и каким-то чудом она обладает базовыми навыками системного администрирования то да, ваша статья будет кстате.

 

Все мои посты в этой теме - сугубо моё личное мнение. Я не настаиваю на том что я прав, и не говорю что на apache2 нельзя держать крупных проектов.

[Grind 71]

проблема apa

не держит особо больших нагрузок aka ddos.

До NGINX по производительности ему как до китая. Тут спора нет. Что касается DDoS, то скорее всего имеется введу атака т.н. "медленными запросами", mod_evasive решает эту проблему.

[Grind 71]

Не забываем, что апач это не только prefork модель.