Эффективность новых фильтров ESBANS для fail2ban

[teleport]

Глядя на страницу статистики системы ESBANS на официальном сайте вашего продукта (esbans_stat.htm), я вижу, что ваши оригинальные фильтры (с префиксом "es-") демонстрируют более высокую эффективность обнаружения и блокирования хакеров на Linux сервере по сравнению с штатными фильтрами системы fail2ban.

За счет чего это достигается? Как именно вы этого добились?

[george]

За счет чего это достигается? Как именно вы этого добились?

История с этими фильтрами довольно простая. Когда мы начали ставить на свои Linux серверы систему fail2ban "из коробки", то количество атак (и нагрузка на них) сразу же уменьшилось. Система fail2ban - отличный продукт, чрезвычайно полезный для администратора Linux сервера.

Однако, изучая логи (nginx, postfix и т.п.), мы своими глазами, на протяжении многих дней, видели очень много реальных фактов продолжения хакерской активности, на которую стандартные фильтры fail2ban никак не реагировали, поскольку эти наблюдаемые нами на практике события не подпадали под те регулярные выражения, которые записаны в стандартных фильтрах fail2ban.

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

[vendor]

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

А какова история создания фильтра es-phpBB? Ведь он, на сколько я понимаю, не имеет аналогов среди штатных средств fail2ban?

[george]

А какова история создания фильтра es-phpBB? Ведь он, на сколько я понимаю, не имеет аналогов среди штатных средств fail2ban?

Да, этот оригинальный фильтр - наша собственная разработка, и мы им очень гордимся. История была такая (кстати, связана она как раз с тем самым phpBB форумом, на котором мы прямо сейчас с вами беседуем). Поначалу я, как администратор всего этого безобразия, жил как в аду. Каждый раз, когда я сюда заходил, меня здесь ждали полчища только что зарегистрировавшихся здесь спамеров и десятки их спам-сообщений. Слава богу, этого хоть не видели мои нормальные посетители - дело в том, что здесь установлен режим предварительной модерации для новых юзеров, так что все их многочисленные сообщения всякий раз ожидали моего одобрения. Но вместо одобрения, естественно, все скопом удалялись. Потом я долго удалял этих бандитов из списка юзеров. На это все всякий раз у меня уходило, наверно, с полчаса, не меньше. Я был очень зол на весь мир, но самоотверженно продолжал делать свою работу.

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

Но роботы продолжали свои безуспешные попытки. Я внимательно посмотрел в логи nginx и заметил там постоянно повторяющуюся сигнатуру (она появляется только при неудачных попытках регистрации на форуме phpBB), которую и внес затем в фильтр es-phpBB. Так что теперь у меня не только форум чистый, но еще и хосты этих бото-ферм постоянно все сидят в бане.

[teleport]

Мы долгое время, продолжая непрерывно наблюдать за логами наших серверов, стали строить свои собственные регулярные выражения, которые описывали именно те события хакерской активности, которые мы там (в наших логах) видели.

А существует ли какой-то способ оценки эффективности каждого отдельно взятого правила? Я имею в виду, можно ли как-то увидеть, насколько оно характерно конкретно для моих логов, на моем сервере?

[george]

А существует ли какой-то способ оценки эффективности каждого отдельно взятого правила? Я имею в виду, можно ли как-то увидеть, насколько оно характерно конкретно для моих логов, на моем сервере?

Да, такой способ существует. Например, для оценки эффективности нашего фильтра es-nginx-access мы используем команду

Код: Выделить всё

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/es-nginx-access.conf

Ее результат выглядит примерно так

Код: Выделить всё

Failregex: 311 total
|-  #) [# of hits] regular expression
|   1) [57] ^<HOST> - - \[.*\] ".*" 400\s
|   2) [50] ^<HOST> - - \[.*\] "GET /.*\.(php|json) HTTP/.*" 404
|   3) [57] ^<HOST> - - \[.*\] "POST /wp-login\.php HTTP/\d\.\d" (200|301)\s
|   4) [60] ^<HOST> - - \[.*\] "(GET|POST) /\.(?!well-known/acme-challenge/).*" 404
|   6) [5] ^<HOST> - - \[.*\] "(GET|POST) /.*(\.\.\/\.\.\/\.\.\/|cgi-bin|eval-stdin).*" 404
|   7) [2] ^<HOST> - - \[.*\] "GET /\?(p|m|author)=\d+ HTTP/\d\.\d" 404\s
|  11) [1] ^<HOST> - - \[.*\] "GET /SDK/.* HTTP/.*" 404
|  12) [22] ^<HOST> - - \[.*\] "GET /ip HTTP/.*" 404
|  13) [57] ^<HOST> - - \[.*\] "GET .*/\.(env|git|aws).* HTTP/.*" 404

Здесь в каждой строке после номера правила в квадратных скобках идет количество обнаруженных совпадений (то есть, количество строк в логе, которые подпадают под данное правило).

Аналогично этот метод можно использовать и для любого другого фильтра, надо только правильно подставить туда путь к соответствующему логу и заменить имя фильтра.

[televendor]

для оценки эффективности нашего фильтра es-nginx-access мы используем команду

Код: Выделить всё

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/es-nginx-access.conf

У меня эта команда для вашего правила

Код: Выделить всё

            ^<HOST> - - \[.*\] "GET / HTTP/1.1" 404

почему-то все время дает ноль попаданий. В чем тут дело?

[george]

У меня эта команда для вашего правила

Код: Выделить всё

            ^<HOST> - - \[.*\] "GET / HTTP/1.1" 404

почему-то все время дает ноль попаданий. В чем тут дело?

Для того, чтобы это правило работало, необходимо удалить ссылку на default в каталоге /etc/nginx/sites-enabled.

Код: Выделить всё

rm /etc/nginx/sites-enabled/default
systemctl reload nginx

То есть, у вас на хосте не должно быть сайта по умолчанию. Именно в этом (и только в этом) случае данное правило создает Honey Pot, куда и попадают разные хулиганы. На наших хостах эта строка фильтра es-nginx-access работает довольно активно.