Когда вы открываете свой сервер в интернет, вы по сути бросаете вызов всему миру: от случайных сканеров до целенаправленных атак. Одним из простых и мощных способов защититься — это mod_security. Расскажу, как я настраивала его на Apache на своём VPS и что из этого получилось.
Что такое mod_security и зачем он нужен?
mod_security — это веб-аппликационный firewall (WAF), который работает в связке с веб-сервером Apache (или Nginx, но там немного сложнее). Он перехватывает HTTP-запросы до того, как они попадают к вашему приложению. Например, кто-то решил проверить, есть ли у вас уязвимости SQL-инъекций — mod_security может «поймать» такой запрос и заблокировать его.
Это не серебряная пуля, но для старта — очень достойный уровень защиты. Особенно если вы хостите WordPress, Laravel, Bitrix или любое другое приложение, которое часто становится целью ботов и сканеров.
Установка mod_security на VPS с Apache
Я использую Ubuntu 22.04 LTS. Установка — дело двух команд:
sudo apt update sudo apt install libapache2-mod-security2 -y
После установки модуль автоматически активируется, но работает в режиме обнаружения (Detection Only) — то есть он пишет в лог, но не блокирует. Это хорошо на старте, чтобы не забанить случайно половину легитимных пользователей.
Перевод в режим блокировки (On)
Открываем основной конфиг:
sudo nano /etc/modsecurity/modsecurity.conf-recommended
Находим строку:
SecRuleEngine DetectionOnly
И меняем на:
SecRuleEngine On
Затем сохраняем файл как
modsecurity.conf
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
Подключаем базовые правила OWASP CRS
OWASP ModSecurity Core Rule Set (CRS) — это набор уже готовых правил, заточенных под реальные угрозы. Подключить их — это must-have:
cd /usr/share sudo git clone https://github.com/coreruleset/coreruleset.git cd coreruleset sudo cp crs-setup.conf.example crs-setup.conf sudo cp -r rules /etc/modsecurity/ sudo cp crs-setup.conf /etc/modsecurity/
Теперь подключаем эти правила в Apache:
sudo nano /etc/apache2/mods-enabled/security2.conf
Добавляем в конец:
IncludeOptional /etc/modsecurity/crs-setup.conf IncludeOptional /etc/modsecurity/rules/*.conf
Сохраняем и перезапускаем Apache:
sudo systemctl restart apache2
Проверка работы
Самый простой способ — попробовать с curl:
curl http://yourdomain.com/?param=%3Cscript%3Ealert(1)%3C/script%3E
Если mod_security работает, вы получите ошибку 403, а в логе
/var/log/apache2/modsec_audit.log
Где хранятся логи?
По умолчанию:
- — полные логи по событиям.
/var/log/apache2/modsec_audit.log
- — общие ошибки Apache, иногда срабатывает сюда.
/var/log/apache2/error.log
Очень полезно поставить tail в реальном времени:
sudo tail -f /var/log/apache2/modsec_audit.log
Фильтрация по IP и whitelist
Если вы заметили, что mod_security слишком агрессивен (например, блокирует ваш API), можно добавить исключения. Пример исключения по URI:
SecRule REQUEST_URI "@beginsWith /api" "id:1234,phase:1,nolog,allow,ctl:ruleEngine=Off"
Можно добавить whitelist по IP:
SecRule REMOTE_ADDR "^123\.123\.123\.123$" "id:1000,phase:1,nolog,allow"
Советы по производительности
- Не включайте слишком много правил, особенно если трафик большой.
- Используйтедля отключения конкретных правил.
ctl:ruleRemoveById
- Храните копии конфигов — особеннои
modsecurity.conf
.crs-setup.conf
Итого…
mod_security — это бесплатный и мощный инструмент для фильтрации веб-трафика. Я на своём VPS теперь чувствую себя гораздо спокойнее: каждый входящий запрос фильтруется, попытки атак логируются, а лишний шум блокируется ещё до того, как дойдёт до PHP.
Если вы ещё не ставили его на свой сервер — очень советую. Это одна из тех вещей, которую ты один раз настраиваешь, а потом она спасает тебе часы и нервы.
Делаем год чуть длиннее
365 дней VPS? А как насчёт 395?