Настройка безопасности Drupal веб-сервера

Итак, наш веб-сервер управляется ОС Debian, и нам необходимо обезопасить его, настроить всё так, чтобы свести все риски к минимуму. Для начала, выполняем базовую настройку Firewall. Наш выбор - IPTables.

Изначально фаервол открыт, весь трафик проходит через него беспрепятственно. Список правил iptables мы проверяем следующей командой:

Всё ясно. Удаление всех правил из IPTables осуществляется следующей командой:

Правила по умолчанию -- удобная и полезная вещь. В IPTables они задаются с помощью политик (-P). Обычная практика -- отбрасывание всех пакетов и ряд разрешающих правил конкретных случаев.

Отбрасывать (блокировать) все пакеты позволяет следующее правило:

Дополнительное усиление защиты -- запрет пересылаемых пакетов, то есть пакетов, маршрутизируемых брандмауэром к точке назначения. Этот уровень защиты включается следующим правилом:

Для loopback мы разрешаем локальный трафик:

В следующем правиле используется модуль (-m) state. Он позволяет проверить состояние устанавливаемого соединения, которое может быть RELATED или ESTABLISHED. Соединение устанавливается только тогда, когда оно удовлетворяет настройкам правила. Состояние ESTABLISHED указывает на то, что в рамках соединения уже пересылались пакеты, состояние RELATED -- на то, что пересылкой пакета устанавливается новое соединение, но оно связано с уже существующим соединением.

Следующее правило разрешает работу всех уже инициированных соединений (ESTABLISHED) и дочерних по отношению к ним:

А это правило допускает и новые соединения:

Данное правило разрешает форвардинг новых, существующих (инициированных) и их дочерних соединений:

Пара правил ниже говорит, что следует отбрасывать все пакеты, которые невозможно идентифицировать, то есть определенный статус они иметь не могут.

Следующий шаг: определяем разрешающие правила, обеспечивающие корректную работу нашего веб-сервера. Их мы оформляем отдельной цепочкой.

Создаём пользовательские цепочки:

Переход в пользовательскую цепочку осуществляется следующей командой:

Есть ряд ограничений, накладываемых на движение по цепочкам

цепочка должна быть создана до того, как на неё выполняется переход;

цепочка должна находиться в той же таблице, что и цепочка, с которой происходит переход.

Далее мы открываем порт для ssh. Важно: обязательно укажите свой порт, если ранее он был изменён!

Если подключение по ssh позволено только некоторым лицам, имеющим статические ip адреса, есть смысл настроить ограничение по ip адресам. Чтобы сделать это, мы вместо предыдущей команды используем такую:

где х.х.х.х - ip адрес, с которого выполняется подключение.

Так как у нас работает веб-сервер, мы должны открывать порты 80 и 443. Для этого используем следующие команды:

В дополнение ко всем этим правилам, можно настроить ряд правил для следующих случаев:

• Удалённое подключение к серверу MySQL Если такое возможно, лучше ограничивать подключение по ip адресам:
• Сервер настроен на прием почты Для такого случая хорошо иметь следующий набор правил:

Всё. Этих правил достаточно, чтобы наш веб-сервер корректно работал. Для остальных портов и протоколов настраиваем REJECT, то есть не принимаем ничего:

От DROP эта директива отличается тем, что отправитель получает IСМР-сообщение "Port unreachable" («Порт недоступен»). Опция --reject-with позволяет изменить тип ICMP-сообщения и имеет следующие аргументы:

• icmp-net-unreachable — сеть недоступна;
• icmp-host-unreachable — узел недоступен;
• icmp-port-unreachable — порт недоступен;
• icmp-proto-unreachable — неподдерживаемый протокол;
• icmp-net-prohibited — сеть запрещена;
• icmp-host-prohibited — узел запрещен.

По умолчанию передаётся сообщение с аргументом port-unreachable.

TCP-пакеты можно отклонить с помощью аргумента tcp-reset, он подразумевает отправку RST-сообщения. С точки зрения безопасности, это наилучший способ. TCP RST пакеты используются для закрытия TCP соединений.

2. Настройка fail2ban

Fail2ban — простой локальный сервис, отслеживающий log–файлы запущенных программ. Руководствуясь условиями, сервис блокирует по IP обнаруженных нарушителей.

Fail2ban успешно справляется с различными атаками на все популярные *NIX–сервисы (Apache, Nginx, ProFTPD, vsftpd, Exim, Postfix, named и т.д.) Так же Fail2ban защитает SSH–сервер от bruteforce-атак прямо “из коробки”.

Fail2ban есть в репозитории, так что установить его очень просто:

В первую очередь, необходимо настроить защиту сервера по протоколу SSH. Для начала, найдите в файле jail.conf секцию [ssh] и убедитесь в том, что в значении параметра enabled фигурирует true.

Затем следует указать значения параметров fail2ban:

• filter — используемый фильтр. По умолчанию это /etc/fail2ban/filter.d/sshd.conf;
• action — действия, выполняемые fail2ban, когда обнаружен атакующий ip-адрес; описания правил реагирования атаки есть в файле /etc/fail2ban/action.d., то есть значение параметра не может быть таким, которого нет в этом файле;
• logpath — полный путь к файлу, в который записывается записываются данные о попытках получения доступа к VPS;
• findtime — время (в секундах), в течение которого фиксируется подозрительная активность;
• maxretry — максимальное разрешенное количество попыток подключения к серверу;
• bantime — время блокировки попавшего в черный список ip.

Важно: прописывать все параметры необязательно, если вы не сделаете этого, будут действовать настройки, указанные в главном разделе [DEFAULT]. Главное -- указать для переменной enabled значение true.

Рассмотрим применение параметров реагирования в деталях. Ниже -- пример конфигурации fail2ban на порту SSH:

Расшифровка: если выполнено более 3 неудачных попыток подключения к серверу через порт SSH, то ip-адрес, с которого выполнялась авторизация, блокируется на 10 минут. Правило запрета добавляется в IPTables, а владелец сервера получает уведомление на адрес, указанный в переменной dest. В уведомлении -- заблокированный ip, WHOIS-данные об этом ip и причина блокировки.

Дополнительно, для защиты SSH можно активировать следующую секцию:

3. Настройка прав доступа к файлам сайта

Сервер нельзя считать безопасным, если не выполнена настройка прав доступа к файлам Drupal сайта. Приведённый ниже пример -- один из способов изменения владельца и прав на файлы/каталоги Drupal-сайта. Вводные:

• webmaster принадлежит группе webmaster и является владельцем сайта;
• сам сайт находится на сервере, где веб-сервер работает под пользователем www-data.

Пользователь www-data должен иметь права на запись в директорию, поэтому у директории «files» в каталоге sites/default (и у любых других каталогов сайтов, если установка многосайтовая) разрешения различные. Бит s группы владельца используется и для каталога, так как нам надо, чтобы все файлы, созданные в нем веб-сервером, принимали идентификатор группы каталога webmaster, а не группы владельца, создавшего файл в этом каталоге.

Для временного каталога у нас тоже другие права, ведь веб-сервер должен иметь права на запись в этот каталог.

Файл settings.php содержит пароль базы данных и имя пользователя, причём указаны они там простым текстом. Так что после его создания, надо установить такие права, которые позволяют чтение только определённым пользователям. Обычно, необходимо просто лишить прав пользователя «other»:

.htaccess - конфигурационный файл Apache, дающий власть над работой веб-сервера и настройками сайта. Соответственно, права должны допускать чтение только определёнными пользователями:

4. Безопасная настройка ssh

Чтобы сделать систему более защищённой, рекомендую внести некоторые изменения в настройки сервера SSH. Лучше запускать его на нестандартном порту, иначе к нему постоянно будут обращаться боты, в том числе подбирающие пароли. В Debian, как и в других дистрибутивах Linux, SSH по умолчанию работает на порту 22. Можно изменить его на, скажем, 2223. Кроме того, стоит изменить конфигурацию так, чтобы root подключался только с использованием ssh ключа. По умолчанию, в Debian пользователь root по SSH не может пройти авторизацию паролем.

Лучше изменять порт SSH до настройки firewall. Если же вы не сделали это, надо выполнить следующие действия:

Перед сменой порта SSH добавьте в IPTables правило, разрешающие подключение по новому порту

Измените порт сервера SSH в /etc/ssh/sshd_config. Там нужно изменить соответствующие строки, чтобы они выглядели так:

Не забудьте сохранить изменения! Затем перезапустите SSH-сервер:

Тут можно и нужно проверить изменения:

Всё в порядке. SSH-сервер слушает порт 2223, теперь новое подключение будет осуществляться только через этот порт, а после перезапуска SSH старое подключение не будет разорвано.

Внимание! Перед отключением авторизации по паролю для пользователя root проверьте, есть ли в файле /root/.ssh/authorized_keys ваш открытый ключ.

Добавить комментарий

Меня зовут Агабеков Роман я и моя команда специализируемся на поддержке инфраструктуры, администрировании серверов для Drupal проектов.