Насколько я понял синтаксис 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 тоже находит все нехорошие вхождения. А вот демон - атакующего не блокирует... Непонятка...

logpath = /var/log/httpd/*error_log

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

Требуется настроить этот махарай таким образом, чтобы нарушитель получал по рукам, если начнет подбирать пароли. В гугле всё это описано не раз, повторять это не хочу. Итак, настроено, и мы после нескольких попыток подбора не получаем ожидаемого выхлопа.
В регистрационном журнале ошибок апача есть строки типа .....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 банится в лучшем виде. А здесь - полный игнор...