​​На одном из чужих серверов, на котором пришлось выполнять некоторые работы, заметил новый для себя инструмент fail2web. Заинтересовался и решил посмотреть, что это такое. Это оказался web интерфейс для управления fail2ban. Так как последний я постоянно использую, решил посмотреть, как всё это выглядит.

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

Сначала ставим fail2rest. Это служба, которая взаимодействует с fail2ban. Написана на GO.
# dnf install golang git gcc nginx
# go get -v github.com/Sean-Der/fail2rest
# go install -v github.com/Sean-Der/fail2rest
В директории ~/go/bin будет бинарник fail2rest. Для его запуска нужно создать конфиг config.json с двумя параметрами:
{
 "Addr": "127.0.0.1:5000",
 "Fail2banSocket": "/var/run/fail2ban/fail2ban.sock"
}

После этого можно запустить fail2rest:
# fail2rest --config=config.json
Проверить работу можно отправив запрос на указанный адрес и порт:
# curl http://127.0.0.1:5000/global/ping
"pong"
Можно настроить запуск через systemd (поменяйте пути на свои):
[Unit]
Description=fail2ban REST server
Documentation=man:fail2rest(1)
ConditionPathExists=/etc/fail2rest.json
After=fail2ban.service

[Service]
ExecStart=/usr/bin/fail2rest -config=/etc/fail2rest.json

[Install]
WantedBy=multi-user.target

Теперь качаем веб интерфейс:
# git clone --depth=1 https://github.com/Sean-Der/fail2web.git /var/www/fail2web
# rm -rf /var/www/fail2web/.git
И настраиваем виртуальный хост apache или nginx. Я для простоты nginx взял:
server {
  listen    80;
  server_name YOUR_SERVER_NAME;
  auth_basic "Restricted";
  auth_basic_user_file /var/www/htpasswd;
  location / {
    root /var/www/fail2web;
  }
  location /api/ {
    proxy_pass     http://127.0.0.1:5000/;
    proxy_redirect   off;
  }
}

Не забудьте создать файл /var/www/htpasswd и добавить туда юзера. Ну и конечно желательно на HTTPS перейти, если реально будете использовать.

На этом собственно всё, можно заходить на настроенный виртуальный хост и управлять fail2ban. Сделано простенько, но функционально. Если реально постоянно какая-то движуха идёт с fail2ban, может быть полезно. Я нашёл всё то же самое, только на Docker, но уже не стал проверять.

Сразу подскажу тем, кто будет реально разбираться. Если видите в веб интерфейсе ошибку:
502 Bad Gateway - Couldn't contact fail2rest
Смотрите лог или настройки fail2ban. Например, если нет ни одного jail, будет эта ошибка. Если неправильно настроены action тоже будут ошибки. В общем, если есть какие-то проблемы с fail2ban, вы будете видеть ошибку соединения с fail2rest, что несколько сбивает с толку.

По сути эта заметка готовая инструкция. Других в интернете вообще нет, так что можно сохранить на память.

Исходники: https://github.com/Sean-Der/fail2rest
https://github.com/Sean-Der/fail2web
Обсуждение: https://www.reddit.com/r/linux/comments/294fn3/fail2web_a_fail2ban_web_gui/

#security #fail2ban

Покажу на простом и наглядном примере методику защиты от типичных брутфорс атак (перебор учётных записей). Для этого возьму всем привычный инструмент nmap и популярный движок сайта Wordpress. Все настройки возьму с реально работающего сервера, где блокировка переборов паролей успешно работает.

Сайты на Wordpress брутят повсеместно. Из-за того, что этот движок очень легко установить, много установок, сделанных дилетантами (сеошники, блогеры и т.д.). О безопасности там никто особо не заботится, поэтому и вероятность взлома значительная, чтобы заинтересованные люди решили потратить на это своё время.

Для примера покажу, как легко и просто начать подбор паролей. Возьмём всем известный сетевой сканер nmap. Нам понадобится любой список паролей, по которому мы будем делать перебор. Можно взять для тестов простые списки в репозитории BruteX или огромный список в wordlist.

В составе nmap есть готовый скрипт для брута админки Wordpress. Достаточно указать адрес сайта, учётную запись, например, admin и список паролей для перебора. Запускаем перебор:

# nmap example.com --script http-wordpress-brute --script-args \
'user=admin, passdb=password.lst, http-wordpress-brute.thread=3, brute.firstonly=true'

В логах веб сервера увидите POST запросы к /wp-login.php от user_agent="Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)". Этот скрипт удобно использовать для тестирования своей защиты.

Теперь расскажу, как работает защита от такого перебора с помощью fail2ban. Устанавливаете его в систему и делаете очень простой фильтр wp-login.conf, положив его в директорию /etc/fail2ban/filter.d:

[Definition]
failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).*

Он ищет все POST запросы к указанным url. Это защита от подборка учёток через wp-login и xmlrpc (последний лучше вообще отключить или закрыть доступ через nginx). Далее создаём настройку jail wp-login.conf и кладём её в директорию /etc/fail2ban/jail.d:

[wp-login]
enabled = true
port = http,https
action = iptables-multiport[name=WP, port="http,https", protocol=tcp]
filter = wp-login
logpath = /var/log/nginx/example.com/access.log
maxretry = 5

Это пример настроек, когда используется iptables. Теперь, как только в логе access.log появится более 5 попыток POST запросов к wp-login.php или xmlrpc.php, IP адрес обратившегося будет забанен. Это удобно проверить с помощью скрипта для nmap.

Подобным образом можно настроить защиту от перебора учётных записей любого сервиса, который записывает информацию об аутентификации в текстовый лог файл. Главное не забыть очень важный момент. Лог файл не должен быть очень большим. Обязательно необходима ротация по размеру файла. Если лог становится очень большим, то fail2ban может сам повесить сервер. Он написан, если не ошибаюсь, на Python и работает не очень быстро. Если вас начинают ддосить и access лог разрастается за минуту до гигабайтов, fail2ban вам сам повесит сервер. Его надо оперативно выключать. В отдельной заметке расскажу, как сделать более универсальную защиту без необходимости парсить access.log.

Более подробно с примерами эта настройка описана у меня на сайте в статье: Защита админки wordpress с помощью fail2ban.

Отдельно отмечу, что для fail2ban есть веб интерфейс — fail2web

#security #webserver #wordpress #fail2ban

Ещё один пример защиты веб сервера с помощью fail2ban. На этот раз пример будет более универсальный, который защитит не только от брута, но и от любых множественных подключений к серверу.

Для этого нам понадобятся модули nginx limit_req и limit_conn. С их помощью можно ограничить скорость обработки запросов с одного IP адреса. Для этого в основной конфигурации nginx, в разделе http, нужно добавить одну или несколько зон с максимальной скоростью обработки запросов или количеством числа соединений с одного IP. Я обычно использую несколько зон, чаще всего четыре. Одна для общего ограничения соединений, вторая для статики, третья для легких динамических запросов (обычные php страницы), четвёртая для тяжёлых динамических запросов (аутентификация, поиск, формирование большого каталога и т.д.).

Выглядят настройки примерно так:

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_req_zone $binary_remote_addr zone=lim_50r:10m rate=50r/s;
limit_req_zone $binary_remote_addr zone=lim_10r:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=lim_3r:10m rate=3r/s;

Зону лучше называть по разрешённому лимиту, чтобы проще было использовать в настройках. Далее идём в конфиг виртуального хоста и там расставляем зоны в общей настройке server и разных locations. Примерно так:

server {
...
limit_conn perip 100;
...

# поиск
location /?s= {
limit_req zone=lim_3r burst=5 nodelay;
...
}

# динамика
location ~ \.php$ {
limit_req zone=lim_10r burst=15 nodelay;
...
}

# всё остальное
location / {
limit_req zone=lim_50r burst=65 nodelay;
...
}
}

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

Сработанные ограничения будут отображаться в error.log nginx. Его мы и будем проверять с помощью fail2ban. Для этого добавляем в директорию /etc/fail2ban/filter.d два конфига.

nginx-limit-conn.conf:
[Definition]
failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting connections by zone.*client: <HOST>
ignoreregex =

nginx-limit-req.conf:
[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>,
ignoreregex = 
datepattern = {^LN-BEG}

И в /etc/fail2ban/jail.d два файла конфигурации:

nginx-limit-conn.conf
[nginx-limit-conn]
enabled = true
filter = nginx-limit-conn
port = http
action = iptables-multiport[name=ConnLimit, port="http,https", protocol=tcp]
logpath = /web/sites/*/logs/error.log
bantime = 3600
maxretry = 20

nginx-limit-req.conf
[nginx-limit-req]
enabled = true
filter = nginx-limit-req
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath = /web/sites/*/logs/error.log
bantime = 3600
maxretry = 10

Теперь нарушители лимитов будут отправляться в бан. При этом не так критично разрастание логов, так как error лог редко растёт быстро, даже если вас ддосят. Но всё равно не нужно забывать про его ротацию.

Все лимиты и реакции настраивайте в зависимости от вашей ситуации. Не надо брать мои значения из примера. Они сильно зависят от типа сайта и производительности сервера. Главное, как я уже сказал, без фанатизма. Лимиты должны быть комфортными для легитимных пользователей и систем.

Есть более простой в плане нагрузки способ блокировать тех, кто открывает слишком много соединений. Использовать системную информацию о подключениях, например, с помощью netstat и если превышен лимит, отправлять IP в бан. Я не очень люблю этот способ и редко использую, так как нет гибкой настройки по сайтам, урлам и т.д. Его стоит использовать, если вас ддосят и вам надо максимально быстро и дёшево по ресурсам блокировать атакующих. Иногда это помогает, если ддос не очень сильный и провайдер вас не отключает. Если интересно посмотреть эту реализацию, то напишите в комментах, я расскажу с примером.

#security #fail2ban #webserver #nginx

«Главная проблема цитат в интернете в том, что люди сразу верят в их подлинность», - Владимир Ленин.

Просматривал недавно общение в какой-то заметке с комментариями, а там подняли тему Fail2Ban и SSH, и в голове всплыла выдуманная цитата, приписываемая Салтыкову-Щедрину, хотя он её никогда не произносил: «Если я усну и проснусь через сто лет и меня спросят, что сейчас происходит в России, я отвечу: пьют и воруют». Она на самом деле новодел 90-х годов. Ни один из классиков её никогда не произносил, а в голове у меня она каким-то образом оказалась.

А вспомнил я её, потому что на все эти блокировки SSH у меня родился свой аналог этого выражения:

«Если я усну и проснусь через сто лет и меня спросят, что сейчас настраивают системные администраторы Linux, я отвечу: блокировку SSH с помощью Fail2Ban».

Я не знаю, зачем об этом до сих пор кто-то вспоминает, рекомендует или сам настраивает. Это было неактуально уже тогда, когда я сам начал изучать Linux.

Сервис SSH давно уже не брутится, потому что повсеместно распространены сертификаты, либо можно применить другие существующие настройки sshd: MaxAuthTries, MaxSessions, MaxStartups, которые делают брут фактически невозможным. Наверное стоит посвятить этому отдельную заметку. И никакой Fail2Ban тут не нужен. Я сам его использую, но не для SSH.

#ssh #fail2ban