Попался мне тут на глаза (на сервере) замечательный php-шелл WSO 2.5 — прилетел через Joomla, на которой крутился интернет-магазин друга (вот не зря я эту джумлу не люблю). Посему будем разбираться, как ограничить доступ злобных скрипт-киддисов с веб-шеллами к серверу.
Настраиваем php
Понятно, что php — лидер среди скриптовых языков, используемых для создания динамических веб-страниц, поэтому с ограничений его работы мы и начнем.
Для этого открываем конфиг php и вносим в него изменения.
Запрещаем скриптам выполняться в директориях, отличных от директории сайта и /tmp:
open_basedir = /var/www:/tmp
Запрещаем открывать файлы с удаленных серверов по протоколам http и ftp:
allow_url_fopen = Off
И, самое главное, отключаем все опасные модули php, которые нужны для работы web-shell`ов (пишем в одну строку):
disable_functions = popen, get_current_user, apache_get_modules, virtual, getmyinode, fileowner, filegroup, apache_get_version, apache_getenv, disk_free_space, highlight_file, symlink, disk_total_space, ini_get_all, apache_note, apache_setenv, chgrp, closelog, debugger_off, debugger_on, define_sys, define_syslog_variables, diskfreespace, dl, escapeshellarg, escapeshellcmd, exec, getmypid, getmyuid, ini_restore, leak, listen, openlog, passthru, pclose, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, show_source, syslog, system, url_exec, _getppid, 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, posix, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname
Настраиваем Apache
Если используются виртуальные сервера, можно еще больше ужесточить запрет директорий, в которых могут исполняться скрипты:
php_value open_basedir /var/www/saradmin/docs:/tmp
Скроем информацию о сервере, установленных модулях и ОС:
ServerTokens Prod
ServerSignature Off
Ну, и раз уж мы в каталоге Апача, проверим, что время ожидания сервером ответа от клиента составляет не больше 2 минут (можно поставить и меньше — защитит от DoS-атак):
Timeout 120
Кроме всего прочего, к Apache можно подключить модуль ModSecurity (он, кстати, доступен и для Apache, и для Nginx, и даже для IIS) — своего рода файервол для веб-сервера, способный защищать от атак на сервер на основании правил.
Изменяем корневой каталог Apache при помощи mod_chroot
Для решения проблемы веб-шеллов также можно использовать mod_chroot. Мы изменяем корневой каталог для нашего веб-сервера, чтобы он мог иметь доступ только к файлам, находящимся в этом каталоге. В этом случае чтобы обеспечить программе доступ к другим каталогам (например, /tmp), нужно заранее примонтировать в целевом каталоге необходимые каталоги.
Установка классическая:
apt-get install libapache2-mod-chroot
Затем включаем модуль и рестартуем апач
a2enmod mod_chroot
/etc/init.d/apache2 restart
После этого подготовим каталог для pid-файла апача в новом месте
mkdir -p /var/www/var/run
chown -R root:root /var/www/var/run
и сообщим об этом апачу, поправив его конфиг:
PidFile /var/run/apache2.pid
ChrootDir /var/www
Не забудем про виртуальные хосты: в их конфигах нужно указать вместо DocumentRoot /var/www новое место: DocumentRoot /
После этого останавливаем апач, создаем симлинк на его pid и снова запускаем.
/etc/init.d/apache2 stop
ln -s /var/www/var/run/apache2.pid /var/run/apache2.pid
/etc/init.d/apache2 start
Всё остальное
Разумеется, это не все возможные методы решения вопроса безопасной настройки веб-сервера Apache, но в рамках одного небольшого поста я постарался охватить самое нужное. Что касается дополнительных рекомендаций, то они таковы: вне зависимости от установленной CMS лучше всего постараться изменить стандартные пути к конфигурационным папкам и админке. Какую-то конкретику тут привести не получится, всё зависит от типа CMS.
Кроме того, не забывайте про правильные настройки доступа к директориям, постоянное обновление, удаление ненужных шаблонов, установку сложных паролей и периодическое резервное копирование как сайта, так и баз данных.
Ну, а следить за производительностью сервера можно, например, при помощи serverstats. Его установку и настройку при наличии свободного времени опишу чуть позже.
