«Только запустил Nginx-приложение, а в access.log уже десятки записей с непонятными запросами, переборами паролей и другого» — типичная ситуация для незащищенного сервера. Это следствие работы «ботов» для сканирования белых сетей, поиска открытых портов, сбора информации о версиях запущенных служб и подбора паролей к сервисам.
В статье расскажу, как с помощью open source-инструмента Fail2ban укрепить Nginx и защитить сервисы от взлома. А также продемонстрирую способы блокирования DDoS-атак. Подробности под катом.
Базовая защита в Nginx
Nginx — это не только быстрый и гибкий веб-сервер, но и довольно безопасный, если правильно его настроить. Рассмотрим пару примеров.
Защита от Clickjacking. С помощью встроенного параметра X-Frame-Options в HTTP-ответе веб-сервера можно задать разрешение страницы в фреймы и iframe — и свести вероятность уязвимости Clickjacking к минимуму.
Защита от DDoS. Если правильно «откалибровать» размеры клиентского буфера, можно снизить влияние DDoS-атак. Также с помощью команд deny и allow можно настроить доступ к приложению с определенных IP-адресов и сетей.
Но подобные способы защиты эффективны не во всех случаях. Например, во время интенсивной DDoS-атаки вручную блокировать адреса сложно. Проще настроить автоматическую фильтрацию источников обращений при выполнении определенных условий.
В случае с Bruteforce эффективней настроить временную блокировку пользователя — либо на уровне логики приложения, либо на обратном прокси-сервере. Если используется базовая аутентификация Nginx, сделать это еще проще.
Для автоматизированной отработки атак лучше использовать специальный софт — в нашем случае это Fail2ban. Но для начала давайте посмотрим, что будет, если атаковать беззащитный сервер.
Атака незащищенного веб-сервера
В рамках статьи рассмотрим два вида атак, в которых промежуточным звеном будет Nginx, а целью хакера — некое веб-приложение.
Для демонстрации я развернул такой стенд: Fail2ban пока что отключен и даже не установлен. Зато есть Wazuh, который помогает мониторить события безопасности.
Wazuh — это комплексная open source-платформа для обеспечения мониторинга безопасности. С помощью нее можно:
- закрыть потребность в полноценном SIEM-решении,
- обеспечить реагирование на инциденты,
- собирать логи со множества систем и аналитику корреляции событий.
Благодаря встроенным шаблонам Wazuh позволяет быстро оценивать соответствие системы требованиям различных стандартов в области ИБ. Наиболее подробно установка и базовая настройка описаны в официальной документации.
Посмотрим, что будет, если атаковать Nginx-сервер без защиты Fail2ban.
Имитация DoS-атаки
Суть атаки сводится к тому, чтобы «забить» канал связи бессмысленным трафиком и исчерпать ресурсы сервера. При этом нелегитимные запросы должны отработать до такой степени, чтобы было невозможно обработать легитимные. В качестве такой атаки будем рассматривать флуд HTTP-запросами — для этого используем Siege. Он отлично подходит для стресс-тестов HTTP-приложений.
Нагрузим сервер запросами в 100 конкурентных пользователей.
root@kali:~# siege -t 1m -c 100 http://192.168.100.3/admin
** SIEGE 4.0.4
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...
Transactions: 206090 hits
Availability: 100.00 %
Elapsed time: 59.83 secs
Data transferred: 40.13 MB
Response time: 0.03 secs
Transaction rate: 3444.59 trans/sec
Throughput: 0.67 MB/sec
Concurrency: 99.05
Successful transactions: 206271
Failed transactions: 0
Longest transaction: 0.32
Shortest transaction: 0.00
В мониторинге видим график, содержащий большое количество запросов.
Непроизводительный веб-сервер на таком количестве запросов может ощутимо загрузить процессор. Запустив параллельно несколько источников запроса, можно и вовсе «положить» сервер.
Имитация Bruteforce
Атака предполагает перебор пар логин-пароль по заранее определенному словарю, который содержит часто используемые комбинации. Рассмотрим перебор данных для базового типа аутентификации Nginx, который может быть настроен, например, для административных страниц.
root@kali:~# curl http://192.168.100.3/admin
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.14.0 (Ubuntu)</center>
</body>
</html>
Установка страницы с аутентификацией.
Аутентификация на странице 192.168.100.3/admin настроена. При обращении к ней обычный пользователь получает 401 ошибку.
На хосте для атаки создадим списки с логинами и паролями соответственно. С помощью инструмента patator и модуля http_fuzz «забрутим» страницу с базовой аутентификацией Nginx.
Результат — «всплески» в разделе Security Events мониторинга Wazuh.
Для Bruteforce все пары логин-пароль были обработаны сервером Nginx, блокирования не произошло. Если бы хактевист потратил больше времени на перебор, сервис был бы взломан.
Последствия Bruteforce и DoS-атак могут быть критичными для реального проекта. Поэтому попробуем подключить и настроить Fail2ban — решение, которое может защитить веб-сервер от потенциальных простоев, утечек данных и другого.
Установка и базовая настройка Fail2ban
Fail2ban — это open source-приложение для фильтрации подключений. С помощью него можно создать специальную «клетку» jail, куда будут записываться вредоносные IP-адреса из iptables, и установить, например, сроки блокирования.
Установим и настроим пакет Fail2ban — он есть в стандартных репозиториях Ubuntu, поэтому можно воспользоваться менеджером пакетов.
sudo apt install fail2ban -y
После выполнения команды в каталоге /etc/fail2ban/ появятся файлы конфигурации.
admin@nginx:~# ll /etc/fail2ban/
total 92
drwxr-xr-x 6 root root 4096 Dec 13 17:50 ./
drwxr-xr-x 86 root root 4096 Dec 11 18:10 ../
drwxr-xr-x 2 root root 4096 Nov 25 05:56 action.d/
-rw-r--r-- 1 root root 2334 Jan 18 2018 fail2ban.conf
drwxr-xr-x 2 root root 4096 Apr 4 2018 fail2ban.d/
drwxr-xr-x 3 root root 4096 Dec 13 17:30 filter.d/
-rw-r--r-- 1 root root 22959 Dec 11 19:11 jail.conf
drwxr-xr-x 2 root root 4096 Dec 11 19:03 jail.d/
-rw-r--r-- 1 root root 645 Jan 18 2018 paths-arch.conf
-rw-r--r-- 1 root root 2827 Jan 18 2018 paths-common.conf
-rw-r--r-- 1 root root 573 Jan 18 2018 paths-debian.conf
-rw-r--r-- 1 root root 738 Jan 18 2018 paths-opensuse.conf
Из этого списка нас интересуют следующие файлы:
- /etc/fail2ban/jail.conf — содержит нативные параметры для поиска совпадений в логах.
- /etc/fail2ban/filter.d/nginx-limit-req.conf — нужен для отслеживания количества обращений к странице и скорости ее обработки. Может пригодиться для блокирования DoS- и bruteforce-атак.
- /etc/fail2ban/filter.d/nginx-http-auth.conf — нужен для обнаружения и блокирования bruteforce-атак на базовую аутентификацию Nginx.
По умолчанию в конфиге Fail2ban такие настройки рассматриваемых модулей:
[nginx-http-auth]
port = http,https
logpath = %(nginx_error_log)s
[nginx-limit-req]
port = http,https
logpath = %(nginx_error_log)s
Блокирование атак с помощью Fail2ban
Стенд после включения Fail2ban.
Установка и базовая настройка — лишь первый этап в защите веб-приложения. Самое главное — правильно настроить правила блокировки IP-адресов для конкретных видов атак.
Возможно, эти тексты тоже вас заинтересуют:
→ Open source, собственные серверы и экспертиза: доступный межсетевой экран для инфраструктуры в Selectel
→ Как просканировать сетевой периметр сервиса с помощью open source-инструментов
→ Anonymous покушаются на бургеры. DDoS-2022: ждать ли новые серии атак
Специальная настройка от DoS-атак
Подготовка nginx-limit-req. Попробуем защитить веб-сервер с помощью модуля nginx-limit-req. Он нужен для определения максимального всплеска запросов (burst) и пороговых значений разделяемой памяти (zone). В случае, если эти параметры будут превышены, модуль добавит в лог-файл новые записи. С помощью них Fail2ban определяет и блокирует вредоносные IP-адреса.
Описания ключевых параметров из файлов конфигураций можно найти по ссылке.
Модуль nginx-limit-req входит в nginx-core, и дополнительная его установка не потребуется. В директиве http добавим параметры для включения модуля и определения зоны:
limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
Далее в директиве location достаточно добавить значение для ограничения количества запросов:
limit_req zone=one burst=5;
Теперь при превышении количества запросов, который мы задали в burst, в /var/log/nginx/error.log будут сыпаться ошибки следующего вида:
2022/12/14 18:39:28 [error] 9462#9462: *987284 limiting requests, excess: 1.940 by zone "one", client: 192.168.100.1, server: localhost, request: "GET /admin HTTP/1.1", host: "192.168.100.3"
Теперь мы можем искать в логах шаблонные сообщения. Именно их Fail2ban будет «искать» в логе nginx и при достижении определенного количества выполнять действие — блокирование источника атаки.
Подготовка jail. В файле /etc/fail2ban/jail.local зададим следующие значения:
[nginx-limit-req]
port = http,https
enabled = true
logpath = /var/log/nginx/*error.log
findtime = 10
bantime = 30
maxretry = 5
В фильтрах Fail2ban /etc/fail2ban/filter.d/nginx-limit-req.conf нужно записать следующее регулярное выражение для параметра failregex:
[Definition]
ngx_limit_req_zones = [^"]+
failregex = ^s*[[a-z]+] d+#d+: *d+ limiting requests, excess: [d.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST>,
Регулярное выражение позволяет найти строку определенного формата в логах nginx. Как можем видеть, некоторые слова являются постоянными, а часть значений — переменными. Они заданы специальным синтаксисом регулярного выражения.
Результат. После включения Fail2ban и запуска атаки видим следующие записи:
admin@nginx:~# tail -n 5 /var/log/fail2ban.log
2022-12-14 18:30:39,505 fail2ban.filter [9237]: INFO [nginx-limit-req] Found 192.168.100.1 - 2022-12-14 18:30:39
2022-12-14 18:30:39,506 fail2ban.filter [9237]: INFO [nginx-limit-req] Found 192.168.100.1 - 2022-12-14 18:30:39
2022-12-14 18:30:39,508 fail2ban.filter [9237]: INFO [nginx-limit-req] Found 192.168.100.1 - 2022-12-14 18:30:39
2022-12-14 18:30:39,509 fail2ban.filter [9237]: INFO [nginx-limit-req] Found 192.168.100.1 - 2022-12-14 18:30:39
2022-12-14 18:30:39,960 fail2ban.actions [9237]: NOTICE [nginx-limit-req] Ban 192.168.100.1
Обратите внимание: вредоносный источник превысил параметры nginx-limit-req и попал в клетку jail. Атакующий хост получил сообщение о прекращении сессии.
root@kali:~# siege -t 1m http://192.168.100.3/admin
================================================================
WARNING: The number of users is capped at 255. To increase this
limit, search your .siegerc file for 'limit' and change
its value. Make sure you read the instructions there...
================================================================
** SIEGE 4.0.4
** Preparing 255 concurrent users for battle.
The server is now under siege...ERROR from http_request
ERROR from http_request
ERROR from http_request
ERROR from http_request
[error] socket: unable to connect sock.c:249: Connection refused
ERROR from http_request
ERROR from http_request
ERROR from http_request
siege aborted due to excessive socket failure; you
can change the failure threshold in $HOME/.siegerc
Transactions: 0 hits
Availability: 0.00 %
Elapsed time: 1.20 secs
Data transferred: 0.27 MB
Response time: 0.00 secs
Transaction rate: 0.00 trans/sec
Throughput: 0.23 MB/sec
Concurrency: 6.71
Successful transactions: 7
Failed transactions: 1278
Longest transaction: 0.20
Shortest transaction: 0.00
В Wazuh также виден «всплеск» обращений и их резкое прекращение — Fail2ban заблокировал нелегитимные запросы.
Специальная настройка от Bruteforce
На хосте уже установлен Fail2ban. Создадим файл jail.local и добавим в него настройки для базовой аутентификации.
[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/*error.log
findtime = 10
bantime = 30
maxretry = 3
Переводя на человеческий, можно сказать так:
- после трех неудачных попыток авторизации будут блокироваться порты http (80/TCP) и https (443/TCP),
- Fail2ban мониторит лог-файл /var/log/nginx/error.log,
- поиск совпадений в лог-файле длится 10 секунд,
- вредоносный адрес блокируется на 30 секунд,
- Fail2ban блокирует адрес, если тот совпадает с шаблоном минимум 3 раза.
В файле /etc/fail2ban/filter.d/nginx-http-auth.conf оставили значение регулярного выражения по умолчанию:
admin@nginx:~# cat /etc/fail2ban/filter.d/nginx-http-auth.conf
# fail2ban filter configuration for nginx
[Definition]
failregex = ^ [error] d+#d+: *d+ user "(?:[^"]+|.*?)":? (?:password mismatch|was not found in "[^"]*"), client: <HOST>, server: S*, request: "S+ S+ HTTP/d+.d+", host: "S+"(?:, referrer: "S+")?s*$
При необходимости в этот файл можно добавлять свои регулярные выражения. Их Fail2ban также будет использовать для поиска совпадений.
Результат. Запустим тот же брутфорс, что и в начале статьи.
Первый пик — действие Bruteforce до включения защиты: Nginx обработал весь список пар из логинов паролей. Отсутствие данных на определенных промежутках обусловлено 30-секундной блокировкой вредоносных IP-адресов. По истечении времени часть адресов продолжает «брутфорсить» страницу авторизации. Но все пары из логинов паролей не успевают обрабатываться — отсюда и «затухающие» пики.
В логах Fail2ban записано следующее:
admin@nginx:~# tail -n 5 /var/log/fail2ban.log
2022-12-13 17:34:58,340 fail2ban.filter [21234]: INFO [nginx-http-auth] Found 192.168.100.1 - 2022-12-13 17:34:58
2022-12-13 17:34:58,340 fail2ban.filter [21234]: INFO [nginx-http-auth] Found 192.168.100.1 - 2022-12-13 17:34:58
2022-12-13 17:34:58,340 fail2ban.filter [21234]: INFO [nginx-http-auth] Found 192.168.100.1 - 2022-12-13 17:34:58
2022-12-13 17:34:58,341 fail2ban.filter [21234]: INFO [nginx-http-auth] Found 192.168.100.1 - 2022-12-13 17:34:58
2022-12-13 17:34:58,471 fail2ban.actions [21234]: NOTICE [nginx-http-auth] Ban 192.168.100.1
Обратите внимание: запросы авторизации регистрировались одновременно, и Fail2ban даже не успевал учитывать некоторые из них. Но в результате все равно находил совпадения и блокировал вредоносные адреса. Напомню, действие происходило в рамках одного L2-домена.
Fail2ban блокировал источники путем добавления адресов в цепочку Chain f2b-nginx-http-auth, которая в свою очередь добавлена в INPUT:
admin@nginx:~# sudo iptables -L -v
Chain INPUT (policy ACCEPT 2312 packets, 123K bytes)
pkts bytes target prot opt in out source destination
<b>3517 492K f2b-nginx-http-auth tcp -- any any anywhere anywhere multiport dports http,https</b>
2521 178K f2b-sshd tcp -- any any anywhere anywhere multiport dports ssh
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 2294 packets, 604K bytes)
pkts bytes target prot opt in out source destination
Chain f2b-nginx-http-auth (1 references)
pkts bytes target prot opt in out source destination
<b>172 10320 REJECT all -- any any 192.168.100.1 anywhere reject-with icmp-port-unreachable</b>
2594 437K RETURN all -- any any anywhere anywhere
Обратите внимание: Fail2ban автоматически описал правила iptables для блокирования исходящего трафика от атакующего IP.
А на стороне атакующего получали следующие результаты атаки Bruteforce:
17:54:38 patator INFO - code size:clen time | candidate | num | mesg
17:54:38 patator INFO - -----------------------------------------------------------------------------
17:54:58 patator FAIL - xxx 92:-1 0.000 | admin:123123 | 2 | Unexpected HTTP response
17:55:00 patator FAIL - xxx 92:-1 0.000 | admin:12345 | 4 | Unexpected HTTP response
Это как следствие того, что сервер отклонял обращения на порт 80/TCP с адреса атакующего хоста:
root@kali:~# curl http://192.168.100.3/admin
curl: (7) Failed to connect to 192.168.100.3 port 80: Connection refused
Таким образом можно настраивать защиту от брута как на все ресурсы, так и на отдельные страницы с разными условиями бана.
А какие средства защиты веб-серверов используете вы? Поделитесь своим опытом и мнением в комментариях.
Автор:
is113
