На хостинге эти проблемы решает сам хостер, а вот на собственном сервере это уже задача администратора. И даже если у Вас хостинг с предустановкой, то вероятность того, что на нем ограничены права для каждого пользователя и сайта маловероятна. Скорее всего Ваш провайдер ограничился установкой стандартных приложений vsftpd, Apache, nginx, php, mysql и тд и тп.
Будем считать, что необходимый комплект на сайте установлен и пришло время позаботиться о безопасности. Если же нет, то находим подходящую инструкцию по «настройке nginx в качестве front-end к apache» и возвращаемся к вопросу безопасности.
Безопасность будем строить из следующих принципов:
Первое это создание пользователей с оболочкой /bin/false на примере vsftpd и proftpd. Это ограничит выполнение скриптов в пределах собственной директории.
Второе разделение пользователей на сайте. Мы сможем запускать наши сайты от имени разных юзеров, и доступ к одному из них, никоим образом не подвергнет опасности другой.
Также я укажу на несколько других известных мне моментов безопасности, если я что-то упустил, то буду рад дополнить статью. А так как единой статьи указывающей на все необходимые моменты безопасности на просторах интернета я не нашел, то думаю статья будет достаточно полезной.
По сути данную памятку я писал для себя исходя из уже существующего и работающего сервера, как завершающий этап установки, так что статья подойдет и для тех, кто только устанавливает сервер, так и для тех, кто хочет его обезопасить и немного ускорить php-интерпретатор, так как этой темы тоже придется коснуться.
Начнем с настройки proftpd. Для этого откроем конфигурационный файл ProFTPd /etc/proftpd/proftpd.conf
#запрем пользователя в своей домашней директории.
DefaultRoot ~
# запрещаем подключать от пользователя root
RootLogin off
#отключим проверку на shell
RequireValidShell off
#ограничим количество одновременных подключений
MaxInstances 10
#ограничим количество попыток для аутентификации
MaxLoginAttempts 5
Перезагружаем proftpd.
Теперь рассмотрим пример на vsftpd. Конфигурационный файл vsftpd /etc/vsftpd.conf
#разрешить авторизацию локальных пользователей
local_enable=YES
#разрешить загрузку файлов
write_enable=YES
#запрем пользователя в своей домашней директории.
chroot_local_user=YES
#права доступа к файлам
local_umask=022
В файле /etc/shells добавим оболочку
/bin/false
В папке /etc/skel пропишем необходимые файлы и папки с соответствующими атрибутами, которые будут создаваться в папке пользователя. Для себя я как минимум устанавливаю папку для сайта (public_html), и папку для хранения временных файлов (tmp). Думаю этого для начала будет достаточно.
Перезагружаем vsftpd.
Добавлять пользователя будем с оболочкой /bin/false, и ключом -m для создания домашней директории одновременно при добавлении пользователя, и сразу запретим запись в корневую директорию, так как все необходимые директории и файлы у нас прописаны выше в /etc/skel
useradd -m -s /bin/false login
passwd login
chmod 555 /home/login
Разделение пользователей и установка fast-cgi
Для разделения пользователей существует как минимум 2 реализации: suexec и apache2-mpm-itk. Для работы через suexec потребуется запускать php приложение для каждого пользователя отдельно, в отличии от аpache2-mpm-itk, который запускается через mod_php один раз для всех процессов. Тем не менее я упущу настройку аpache2-mpm-itk, так как запуск одного процесса не дает достаточной гибкости, и в частности запуска отдельного php.ini, а потерю производительности можно компенсировать использованием Fast-CGI. Конечно, той скорости, дает php_mod получить не удастся, но зато удастся сэкономить ресурсы системы.
Для начала установим необходимые модули. Предполагается, что сервер у Вас уже установлен и настроен.
На примере Ubuntu
aptitude install apache2-suexec libapache2-mod-fcgid php5-cgi
Если Apache2 был установлен с PHP5 в виде модуля Apache, отключаем его:
a2dismod php5
Включим следующие модули, если не включены
a2enmod rewrite
a2enmod suexec
a2enmod include
a2enmod fcgid
Сценарий для выполнения PHP, размещается в коревой директории Suexec, которой по умолчанию является /var/www, тем не менее проверить это поможет следующая команда
/usr/lib/apache2/suexec -V
В ней создадим директорию fcgi, где и будут храниться наши сценарии и настройки php для каждого пользователя и определим вложенную папку непосредственно для владельца
mkdir -p /var/www/fcgi/login
Внутни созданим файл php5, где пропишем сценарий для выполнения php
chown login:login /var/www/fcgi/login/php5
В /var/www/fcgi/login/php5 добавим запись
#!/bin/sh
PHPRC=/var/www/fcgi/login/php.ini
export PHPRC
export PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_CHILDREN=8
exec /usr/lib/cgi-bin/php
Линия PHPRC содержит каталог, где находится файл php.ini (например, /var/www/fcgi/login/ переводится в /var/www/fcgi/login/php.ini). PHP_FCGI_MAX_REQUESTS отвечает за количество запросов, которые обработает один процесс. PHP_FCGI_CHILDREN указывает количество дочерних процессов, запускаемых PHP для обработки входящих запросов. php5 должен быть исполняемым, и он (и его каталоги) должны принадлежать пользователю веб-сайта и группы.
Теперь перенесем дефолтовый файл php.ini из дефолтовой директории /etc/php5/cgi/ в нашу /var/www/fcgi/login/php5, и настроим основные параметры. Для каждого сайта они будут индивидуальные, но на основные следует сразу обратить внимание
;Обеспечивает поддержку правильных PATH_INFO/PATH_TRANSLATED в CGI
cgi.fix_pathinfo=1
;Разрешим использование коротких тегов <? ?>
short_open_tag = on
;Ограничим пользователя его домашним каталогом
open_basedir = /home/login/docs
;Ограничим функции, что в первую очередь относится к функциям exec, которые в нашем случае вреда не принесут. Тем не менее лишнии функции желательно отключить
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_getpriority,pcntl_setpriority,pcntl_exec,exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source,highlight_file,etc
;Отключим глобальные переменные
register_globals = Off
;Отключаем регистрацию устаревших переменных
register_long_arrays = Off
;Устанавливает максимально допустимый размер данных, отправляемых методом POST
post_max_size = 8M
;Временная директория, используемая для хранения файлов во время закачивания
upload_tmp_dir = /home/login/tmp
;Максимальный размер закачиваемого файла
upload_max_filesize = 2M
;Запретим загрузку удаленных файло
allow_url_include = Off
;Агент отправки e-mail
sendmail_path = /usr/sbin/sendmail -t -i
;Уберем лишний заголовок X-PHP-Originating-Script
mail.add_x_header = Off
;Определяем максимально допустимое значение памяти. -1 без ограничений
memory_limit = 128M
;Определяем максимальное время обработки скрипта
max_execution_time = 30
Для корректировки путей в файле /etc/apache2/mods-available/fcgid.conf добавьте
PHP_Fix_Pathinfo_Enable 1
а также установите параметр FcgidMaxRequestLen указав максимальный размер запроса
FcgidMaxRequestLen 10737418
Также скорости прибавит memcached и xcache
aptitude install memcached
aptitude install php5-xcache
Защита от разного рода инъекций
Для дополнительной безопасности установим расширение mod_security
aptitude install libapache2-modsecurity
Переименуем конфигурационный файл
mv /etc/modsecurity/modsecurity.conf{-recommended,}
Теперь откроем его и изменим конфигурации
#Включим режим блокировки
SecRuleEngine on
#Определим максимальный размер данных POST, в данном случае 10м
SecRequestBodyLimit 10485760
#Определим максимальный размер данных POST за вычетом файлов, в данном случае 10м
SecRequestBodyNoFilesLimit 1048576
Подгрузим базовые правила, для чего между IfModule security2_module> в файле /etc/apache2/mods-enabled/mod-security.conf добавим
Include /usr/share/modsecurity-crs/*.conf
Include /usr/share/modsecurity-crs/base_rules/*.conf
Защита от DOS, DDOS и FLUD атак, а также перебора паролей
Установим mod-evasive для Apache
aptitude install libapache2-mod-evasive
подключим
a2enmod
и изменим конфигурации в файле /etc/apache2/mods-available/mod-evasive.conf
<IfModule mod_evasive20.c>
#Размер таблицы адресов
DOSHashTableSize 3097
#Число запросов к одной странице от одного и того же IP в течение указаного интервала времени.
DOSPageCount 2
#Число запросов ко всем страницам домена, т.е если поступило более 50-ти запросов с одного ай-пи на разные страницы домена – тогда такой ай-пи будет заблокирован.
DOSSiteCount 50
#Интервал для директивы DOSPageCount (в секундах)
DOSPageInterval 1
#Интервал для директивы DOSSiteCount (в секундах)
DOSSiteInterval 1
#На сколько заблокировать ай-пи (в секундах)
DOSBlockingPeriod 10
#Email для уведомлений о блокировке
DOSEmailNotify mail@gmail.com
#Файл логов
DOSLogDir "/var/log/mod_evasive"
#Список адресов для которых не будут работать ограничения
DOSWhitelist 127.0.0.1
DOSWhitelist 192.168.1.1
</IfModule>
Для защита от перебора паролей установим Fail2ban
aptitude install fail2ban
Перезапускаем apache, nginx и memcached
Комментарии (14)
mmotor Автор
28.06.2015 00:47+1В целом все то же, что и понуждает хостинги использовать именно Apache. Это как минимум удобство. Как и тот факт, что в одной CMS в разных директориях этот файл может насчитываться десятками. А также возможность предоставления работы с кодом CMS, другим пользователям. Скрипт использующих в своей архитектуре файл htaccess адаптирован для широкого круга пользователей, а возможность залезть в конфиги nginx, есть далеко не у каждого, не говоря о том, что не у каждого и nginx стоит.
rhamdeew
28.06.2015 13:25+3Использовать Apache думаю оправданно использовать только в случае с настройкой сервера под использование большим количеством пользователей которым не разрешается крутить серверные конфиги. В итоге у нас и получается обычный шаред-хостинг со стандартным LAMP.
Виртуальные же сервера люди обычно берут именно из-за того что не желают мириться с ограничениями на шареде. В таком случаем можно потратить лишние 10-15 минут на перенос правил .htaccess в Nginx. Тем более что конфиги Nginx настолько гибкие и приятные что после них нет даже желания разбираться в конфигах Apache.
Раз уж статья про безопасность то перво-наперво стоит упомянуть:
1) Запрет root login
2) SSH-доступ только по ключам
3) Настройка iptables и fail2banvels
30.06.2015 00:41А можно для нубов все три пункта подробнее? Или таки отдельную статью.
Спасибо!rhamdeew
30.06.2015 00:491) В конфиге ssh выставляем PermitRootLogin no, а сами заходим из под другого пользователя который может в su/sudo
2) wiki.archlinux.org/index.php/SSH_keys_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) — посложнее и поподробнее на русском
www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 — коротко и просто на английском
3) можно почитать вот это: xakep.ru/2011/08/23/58089
я у себя вот такие правила выставил — gist.github.com/rhamdeew/252ef62840c8fda2e91f
alfa
28.06.2015 14:13+1Также скорости прибавит memcached и xcache
aptitude install memcached
aptitude install php5-xcache
Чтобы memcached прибавил скорости, мало его установить, нужно установить модуль к php (php5-memcached), ну и чтобы это всё добро начало использоваться, ваш сайт должен уметь работать с memcached, просто поставив ничего не изменится.
Fesor
29.06.2015 09:02+1xcache? серьезно? не думал что его кто-то еще использует. opcache идет из коробки с версии 5.5 и эффективнее реализации в плане кеширования опкодов нету.
J_o_k_e_R
1) Для безопасности proftpd лучше вообще не использовать и уж тем болен не отключать проверку шелла. У vsftpd не упомянуты 90% параметров, влияющих на безопасность. Веб-сервер без апача, а только с nginx+php-fpm при правильной настройке безопаснее и производительнее связки с апачем.
Короче говоря, автор, создавая очередной велосипед, хотя бы «Велосипедостроение для самых маленьких изучили».
Статью категорически не рекомендую к принятию к действию.
mmotor Автор
Nginx не поддерживает htacces, а он используется практически в каждой CMS.
Если Вы знаете возможные уязвимости с оболочкой /bin/false и способы их устранения, буду только рад
J_o_k_e_R
Спорим на 100 евро, что nginx без апача настраивается под полное функционирование любой распространенной opensource CMS?
VolCh
Более того, не просто настраивается, а имеются готовые конфиги, зачастую прямо в руководстве по установки.