1

Тема: Непонятность с file2ban на CentOS-7

Коллеги, помогите разобраться с сабжевой непоняткой. А именно:
1. Имеем ось CentOS-7+iptables.
2. Имеем apache в котором крутится некий сайт, к которому стандартными средствами http (через .htaccess) реализована простенькая авторизация доступа.
3. имеется, собственно, file2ban.

Требуется настроить этот махарай таким образом, чтобы нарушитель получал по рукам, если начнет подбирать пароли. В гугле всё это описано не раз, повторять это не хочу. Итак, настроено, и мы после нескольких попыток подбора не получаем ожидаемого выхлопа.
В регистрационном журнале ошибок апача есть строки типа .....AH01618: user 1 not found: /
В правилах фильтра apache-auth есть регулярка  ^%(_apache_error_client)s (AH01618: )?user .*? not found(: )?\S*(, referer: \S+)?\s*$

Собственно, правило

[apache]
enabled = true
port = http,https
filter = apache-auth
action   = iptables-multiport[name=apache-auth, port="http,https"]
logpath = /var/log/httpd/*error_log
maxretry = 3

должно срабатывать, но - фиг вам.

Коллеги, подскажите, что я не вижу? Ведь тот же тривиальный ssh банится в лучшем виде. А здесь - полный игнор...

2

Re: Непонятность с file2ban на CentOS-7

Cruiser78 пишет

logpath = /var/log/httpd/*error_log

Это точно путь лога вашего сайта?

Чем больше я работаю админом, тем больше понимаю, насколько волшебна фраза - "Нет технической возможности!"
=====================================================================================================
Mageia 5 x86_64 MATE Mageia Russian Community

3 (06.02.2017 23:25:07 отредактировано Cruiser78)

Re: Непонятность с file2ban на CentOS-7

Именно так. Это, в принципе, дефолтная для CentOS-7  настройка. Там два файла, error_log и ssl_error_log. Полное ощущение, что не срабатывает фильтр. Так как action ставил аналогичным как и для sshd (для него всё срабатывает), то есть убирал _multiport и оставлял только один httpd порт. Не помогло. Собака, похоже, зарылать именно в регулярном выражении от fail2ban. Но вот где именно там ошибка - я не вижу.

Насколько я понял синтаксис fail2ban - там регулярное выражение можно развернуть (_apache_error_client), в конце концов, в следующий код:

<?php
if (preg_match ('/^\[\] \[(:?error|\S+:\S+)\]( \[pid \d+(:\S+ \d+)?\])? \[client <HOST>(:\d{1,5})?\] (AH01618: )?user .*? not found(: )?\S*(, referer: \S+)?\s*$/i', "[Mon Feb 06 20:26:33.352308 2017] [auth_basic:error] [pid 15184] [client 94.188.23.161:57400] AH01618: user 111 not found: /SITE")) {
    print "A match was found.\n";
    } else {
    print "A match was not found.\n";
}

?>

Если запустить таким образом, то получим, что вхождение не найдено. Но, если убрать из выражения содержимое _apache_error_client, то вхождение прекрасно находится. То есть:

<?php
if (preg_match ('/(AH01618: )?user .*? not found(: )?\S*(, referer: \S+)?\s*$/i', "[Mon Feb 06 20:26:33.352308 2017] [auth_basic:error] [pid 15184] [client 94.188.23.161:57400] AH01618: user 111 not found: /SITE")) {
    print "A match was found.\n";
    } else {
    print "A match was not found.\n";
}

?>
искомое вхождение прекрасно находит. Отсюда вывод: собака зарылась в переменной

_apache_error_client = \[\] \[(:?error|\S+:\S+)\]( \[pid \d+(:\S+ \d+)?\])? \[client <HOST>(:\d{1,5})?\]

которая подставляется в конфигурации соответсвующего фильтра в регулярное выражение:

failregex = ^%(_apache_error_client)s (AH01618: )?user .*? not found(: )?\S*(, referer: \S+)?\s*$

В результате строка "[Mon Feb 06 20:26:33.352308 2017] [auth_basic:error] [pid 15184] [client 94.188.23.161:57400] AH01618: user 111 not found: /SITE" не опознается как строка ошибки. И на неё нет реакции.
К сожалению, я совершенно не силён в регулярных выражениях и понять в чем именно ошибка - не могу.
====================
Еще раз внимательно погуглил, пришел к выводу, что проблема из-за изменения формата лога в Apache 2.4. Его "стандартный" file2ban не воспринимает. Ну с с помощью гугля и утилиты file2ban-regexp подобрал следующее выражение

_apache_error_client=\[[^]]*\] \[auth_basic:error\]( \[pid \d+\])? \[client <HOST>(:\d{1,5})?\]( \S+:)?


В общем, если его скормить file2ban-regexp'у, то он находит все "аварийные" строки в регистрационном журнале.  Но, если этот параметр вставить в конфиг file2ban - увы...
Самое непонятное - если тестировать стандартный _apache_error_client, то file2ban-regexp тоже находит все нехорошие вхождения. А вот демон - атакующего не блокирует... Непонятка...