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
В чем может быть проблема?

← Помогите совладать с sh. Если подставить переменную даёт другие результаты нежели эти же значения в строке.
Разрешить отправку postfix-у только с определенного IP адреса (debian) →

Возьми уже 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 ★★★★★
()

Укажи в первом правиле --hitcount явно.

NightSpamer ★
()
Ответ на: комментарий от 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
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Помогите совладать с sh. Если подставить переменную даёт другие результаты нежели эти же значения в строке.
Admin
Разрешить отправку postfix-у только с определенного IP адреса (debian) →