LINUX.ORG.RU
решено ФорумAdmin

Загадочное поведение правил iptables

 


0

1

Задача защитить SSH от брутфорса. Перевесил на другой порт 2255. Теперь еще нужно банить на 20 секунд после неправильного ввода пароля. Нашел вот такие правила, вроде должны работать.

 
iptables -A INPUT -p tcp -m state --state NEW --dport 2255 -m recent --update --seconds 20 -j DROP
iptables -A INPUT -p tcp -m state --state NEW --dport 2255 -m recent --set -j ACCEPT 
Начал пробовать сам ломиться в SSH с неправильными паролями. И как-то непонятно эти правила отрабатывают. То он продолжает не пускать меня через 25 секунд после разрыва последнего соединения. То наоборот позволяет устанавливать новые соединения сколько хочешь раз подряд. Захожу с правильным паролем, делаю iptables -L -n - вроде все на месте:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:2255 recent: UPDATE seconds: 20 name: DEFAULT side: source
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:2255 recent: SET name: DEFAULT side: source

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  
В чем может быть проблема?

Возьми уже fail2ban.

Как твои правила iptables определят, корректно ли ты пароль ввел или нет? Тем более у тебя в конфиге сразу написано и запреь, и разрешение, по какой логике (кроме «по порядку») iptables может применять эти правила?

alozovskoy ★★★★★ ()
Последнее исправление: alozovskoy (всего исправлений: 1)
iptables -A INPUT -p tcp -m state --state NEW --dport 2255 -m recent --update --seconds 20 -j DROP
iptables -A INPUT -p tcp -m state --state NEW --dport 2255 -m recent --set -j ACCEPT 

какое поведение ты ожидаешь от этих строк ?

dada ★★★★★ ()
Ответ на: комментарий от dada

Полагаю, после каждого соединения новое соединение можно установить только через 20 секунд с этого ip, иначе DROP и снова запускается 20 секунд.

А какое на самом деле здесь поведение?

iamroman ()

iptables ничего не знает про протокол SSH - он НЕ может сказать ввёл ты пароль правильно или нет.

fail2ban уже посоветовали

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

НЕ может сказать ввёл ты пароль правильно или нет

Да ещё и не даст быстро открыть несколько соединений даже с правильным паролем.

NightSpamer ()
Ответ на: комментарий от af5

Это все правила, я показал вывод iptables -L -n А какие еще нужны?

iamroman ()
Ответ на: комментарий от Pinkbyte

Я рассматривал этот вариант. Но решил попробовать реализовать это с iptables, потому что сервер и так слабенький, а fail2ban парсингом логов будет создавать лишнюю нагрузку. Или это экономия на спичках?

iamroman ()
Ответ на: комментарий от iamroman

Это не экономия на спичках. То, чего хочешь ты НЕВОЗМОЖНО реализовать с использованием одного лишь критерия recent

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Понятно, что iptables не знает, правильно я ввел пароль или нет. Но просто запрет установки нового соединения по SSH чаще, чем через 20 секунд после предыдущего, должен отсекать перебор паролей. Он может чему-то мешать в обычной работе, но в каких случаях?

Да и все равно, эти правила почему-то отрабатывают не так, как ожидается.

iamroman ()

Похоже, загвоздка была в том, что во время тестирования я после еще одного подключения, когда сервер делал DROP и в баше ничего не происходило, я жал Ctrl + Z, что приостанавливало соединение, а надо было Ctrl + C, что закрывало бы его. Поэтому видимо глючил таймер, хотя я не понял до конца почему... Видимо когда я после приостановки снова подключался, то он просто восстанавливал приостановленное подключение.

В общем, косяк был не в правилах, а в моем методе их тестирования.

iamroman ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.