Назад | Перейти на главную страницу

Fail2Ban на CentOS 6.5 Никогда не банит

Среда: * CentOS 6.5 * Fail2Ban 0.8.14-1 * date выводит правильную дату

Поведение: Fail2ban запускается успешно, но не создает блоки iptables после неудачных попыток входа в систему по SSH. На данный момент меня интересует только SSH. Я попытался переустановить, используя это руководство: https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-centos-6

Раньше Fail2Ban работал, но после обновлений системы он, похоже, перестал работать. Если я сбегу

sudo service fail2ban restart

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

Мой файл /etc/fail2ban/jail.local включает запись:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
       sendmail-whois[name=SSH, dest=chalstead@mydomain.edu, sender=fail2ban@campus.mydomain.edu, sendername="Fail2Ban"]
logpath  = /var/log/secure
maxretry = 5

Мой IP-адрес не указан в списке игнорирования. Я использую стандартное время запрета 600, время поиска 600 и максимальное время ожидания 3.

Когда я смотрю на / var / log / secure, я вижу множество неудачных попыток:

Sep 30 00:17:02 nebo unix_chkpwd[3796]: password check failed for user (root)
Sep 30 00:17:02 nebo sshd[3794]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.173.26.189  user=root

iptables -L, похоже, сообщает, что у fail2ban есть цепочка:

Chain fail2ban-SSH (2 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

Мой лучший гость - то, что действие для sshd в actions.d / sshd.conf использует регулярное выражение для просмотра файла журнала, но оно не соответствует текущему синтаксису журнала CentOS для запрещенной попытки.

Время не синхронизировано на: Почему нет сбоев в блокировке fail2ban?

Запустил fail2ban-regex, чтобы проверить мою теорию, и похоже, что я на правильном пути:

[isdept@nebo action.d]$ sudo fail2ban-regex /var/log/secure /etc/fail2ban/filter.d/sshd.conf 

Running tests
=============

Use   failregex file : /etc/fail2ban/filter.d/sshd.conf
Use         log file : /var/log/secure


Results
=======

Failregex: 0 total

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [22655] MONTH Day Hour:Minute:Second
`-

Lines: 22655 lines, 0 ignored, 0 matched, 22655 missed
Missed line(s): too many to print.  Use --print-all-missed to print all 22655 lines

Я не совсем уверен, как изменить шаблоны регулярных выражений, чтобы исправить это (если это проблема), но я удивлен, обнаружив, что не нашел простого исправления, поскольку CentOS является обычным явлением. Буду рад предоставить любую дополнительную информацию. Спасибо за любые советы или указатели, которые вы можете дать!

В целях безопасности - сейчас я отключаю публичный доступ к этому хосту.

Ну, я не мастер регулярных выражений (и даже не новичок), но мне удалось заставить его работать, добавив:

^.*authentication failure;.*rhost=<HOST>

в filter.d / sshd.conf. Это сработало, и я успешно забанил своего первого хозяина. Если какие-либо эксперты по регулярным выражениям захотят вмешаться, я был бы очень признателен. Я уверен, что в этом коротком выражении мне не хватает одного случая, который в определенных случаях не сработает.

Спасибо!

@SteadH В вашем первоначальном посте у вас есть это:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
       sendmail-whois[name=SSH, dest=chalstead@mydomain.edu, sender=fail2ban@campus.mydomain.edu, sendername="Fail2Ban"]
logpath  = /var/log/secure
maxretry = 5

[ssh-iptables] : имя фильтра / ссылка и

фильтр = sshd : файл с фильтром регулярных выражений в /filter.d (sshd.conf)

Тогда в вашем последнем посте вы вносите правки в sshd-iptables.conf? Вы проверили fail2ban-regex на sshd.conf? Какой файл вы используете? и какой из них существует или существуют оба. Я могу помочь вам с шаблоном регулярного выражения, но мне нужно убедиться, что я ищу правильный шаблон для соответствия.

Сегодня я работаю над той же проблемой, также на centos 6.5.

в моем случае файл дистрибутива называется filters.d / sshd.conf, а не Filters.d / sshd-iptables.conf, как вы написали. Не уверен, почему ваши и мои будут разными. но в любом случае я считаю, что проблема идентична.

вот пример записи из моего журнала secure.log:

Oct 11 11:11:11 myhostname sshd[12345]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=1.2.3.4

Ближайший соответствующий файл failregex в фильтрах дистрибутива.d / sshd.conf следующий:

^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error) for .* from <HOST>( via \S+)?\s*$

это явно не будет соответствовать приведенному выше примеру из-за строк «from» и «via» и отсутствия строки «rhost =». мои попытки исправить это перечислены ниже.

  • первый мод, не совпал:

    ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error); .* rhost=<HOST> .*$
    
  • второй мод, не совпал:

    ^%(__prefix_line)[aA]uthentication (?:failure|error); .* rhost=<HOST> .*$
    
  • третий мод, подобранный:

    [aA]uthentication (?:failure|error); .* rhost=<HOST> .*$
    

Подвыражение регулярного выражения __prefix_line происходит из filters.d / common.conf и является отличной попыткой сопоставить все возможные перестановки известных форматов префиксов записей журнала Linux, но, к сожалению, оно требует некоторой настройки для нашей конкретной ситуации с centos 6.5. Я могу взломать это, но от первого взгляда на регулярные выражения в common.conf у меня заболевает голова. менее сложное регулярное выражение без __prefix_line может быть достаточным.

@SteadH на основе вашего решения я обнаружил корень проблемы. Все фильтры sshd заканчиваются на '$' (доллар), который соответствует концу строки в некоторых регулярных выражениях (я заметил, что ваше исправление не было). Ну я удалил доллары и альт! заработало! Я думаю, что где-то в нутри может быть некоторая неправильная конфигурация, из-за которой '$' не работает. В любом случае попробуйте это исправить.