Теперь я точно знаю, что нужна. Рассказываю. Есть один сервер, на котором я развернул защиту от перебора паролей по SSH под названием fail2ban. Писал об этом тут. Впоследствии для повышения защиты перевесил SSH на нестандартный порт. Конечно это не является в полной мере мерой увеличения безопасности, но хоть немного уменьшить поток автоматизированных скриптов по брутфорсу удалось.

Так вот, решил проверить, как работает сервис Fail2ban. Подключаюсь по SSH, ввожу заведомо неверные учётные данные. Запись в логе появляется. Ввожу ещё раз, ещё раз. Думал, что сбился. Ввёл ещё несколько раз – сервер упорно предлагает мне каждый раз новое окно аутентификации. Решил проверить правила на файрволле. Итак, вернёмся к файрволлу:

# iptables -L

Данная команда показала, что мой IP определён успешно, REJECT-ится в цепочке… И в цепочку заворачиваются все входящие соединения на порт ssh из цепочки INPUT. IP определён правильно, как я уже говорил, отдельно проверил. Почему REJECT не работает? Проверил ещё пару раз. Позволяет коннектиться и перебирать пароли/логины.

Здесь, это я уже потом подумал, хорошо бы использовать вывод файрволла с счётчиком пакетов на каждом правиле (будет видно, попадает ли трафик в нужные цепочки или нет, а также видно, какие из них работают, а какие – нет)

# iptables -nvL

Вот тут меня осенило. В правиле используется константа – стандартный порт ssh, а я перевесил на нестандартный, поэтому в цепочку fail2ban-а на REJECT-а ничего не попадает, несмотря на то, что адреса добавляются.

Быстро подправил jail.conf, указав в качестве порта необходимый, мой, нестандартный и перезапустил fail2ban командой:

# service fail2ban restart

Вот теперь всё работало как надо.

Вывод очевиден – при налаживании различных уровней защиты необходимо проверять, как они согласуются между собой. И разумеется тестировать.