xinetd завис? (было "iptables/recent помогите с диагностикой?")

[AnrDaemon]

(Нажмите, чтобы показать/скрыть)

Есть такая вот ловушечка для любителей по(а)бузить.

Код: [Выделить]

-A INPUT -p tcp -m multiport --dports 9,22,25,110 -m conntrack --ctstate NEW -j SSH_CHECK

-A SSH_CHECK -m conntrack --ctstate NEW -m recent --set --name SSH --rsource
-A SSH_CHECK -m conntrack --ctstate NEW -m recent --update --seconds 90 --hitcount 4 --name SSH --rsource -j NOWAY

-A NOWAY -p tcp -j REJECT --reject-with tcp-reset
-A NOWAY -j REJECT --reject-with icmp-port-unreachable
Работает замечательно, пока её не трогают. Но когда я запускаю пинговалку раз в минуту в порт 9(discard/tcp), почему-то немедленно сваливается в блок.
Причём началось это не так давно, может, с месяц назад. До того работало нормально, пинг показывал доступность серверов, гадкие абузеры шли лесом.
Как вообще читать /proc/net/ipt_recent/SSH ? Там явно сохраняется больше пакетов, чем за последние 90 секунд. И вообще намного больше.
Пользователь решил продолжить мысль 21 Ноября 2011, 20:59:53:Вот сейчас, один сервер нормально отдаёт пинги, второй сидит в блоке даже при том, что в таблице ipt_recent/SSH всего три пакета с указанного адреса.

См. https://forum.ubuntu.ru/index.php?topic=175419.0#msg1296326

[alexxnight]

я немного по другому делаю и все работает. если адаптировать под Ваш код, то

-A INPUT -p tcp -m multiport --dports 9,22,25,110 -m conntrack --ctstate NEW -j SSH_CHECK
.....

# 1. проверка, 2. бан, 3. занесение нового в список
iptables -A SSH_CHECK -j SSH_CHECK_remove
iptables -A SSH_CHECK -m conntrack --ctstate NEW -m recent --name bruteforce --rsource --update --seconds 90 --hitcount 4 -j REJECT --[.....]
iptables -A SSH_CHECK -m recent --name bruteforce --rsource --set

# удаление из бана через 12 часов (43200 сек)
iptables -A SSH_CHECK_remove -m recent --name bruteforce --rsource --rcheck --seconds 43200 -j RETURN
iptables -A SSH_CHECK_remove -m recent --name bruteforce --rsource --remove

у Вас же ведь проверяется tpc пакеты, почему icmp влияет на это?
в цепочке SSH_CHECK явно не указывается tpc, может из какой-то еще цепочки туда заход есть?

а список большой, потому что нет отчистки: туда заносятся все входящие пакеты, которые пришли на порт 9,22,25,110 (судя по коду)

вообще нужно все смотреть... iptables-save

[AnrDaemon]

Server A (Ubuntu 2.6.24-29.95-server), сидит за NAT'ом. Единственная сетевая, разделение трафика по IP. Пинг вот прямо сейчас работает нормально.

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# Generated by iptables-save v1.3.8 on Mon Nov 21 22:46:45 2011
*mangle
:PREROUTING ACCEPT [2734807:1344412082]
:INPUT ACCEPT [1819548:609289760]
:FORWARD ACCEPT [915069:735114274]
:OUTPUT ACCEPT [2550921:2415151910]
:POSTROUTING ACCEPT [3428800:3145780546]
-A FORWARD -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1357:1500 -j TCPMSS --set-mss 1356
COMMIT
# Completed on Mon Nov 21 22:46:45 2011
# Generated by iptables-save v1.3.8 on Mon Nov 21 22:46:45 2011
*nat
:PREROUTING ACCEPT [26686:1605687]
:POSTROUTING ACCEPT [10535:795075]
:OUTPUT ACCEPT [9902:769755]
-A PREROUTING -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A POSTROUTING -s 192.168.35.0/255.255.255.0 -d ! 192.168.35.0/255.255.255.0 -m conntrack --ctstate NEW -j SNAT --to-source 192.168.10.2
COMMIT
# Completed on Mon Nov 21 22:46:45 2011
# Generated by iptables-save v1.3.8 on Mon Nov 21 22:46:45 2011
*filter
:INPUT DROP [528:130205]
:FORWARD DROP [1994:79760]
:OUTPUT ACCEPT [2514501:2410629453]
:NOWAY - [0:0]
:SSH_CHECK - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -s 192.168.35.0/255.255.255.0 -i ! eth1 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 9,22,25,110 -m conntrack --ctstate NEW -j SSH_CHECK
-A INPUT -p tcp -m tcp --dport 9 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -m conntrack --ctstate NEW -j NOWAY
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -j NOWAY
-A INPUT -p tcp -m tcp --dport 110 -m conntrack --ctstate NEW -j NOWAY
-A INPUT -p tcp -m tcp --dport 1723 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -i ! eth1 -j LOG
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -s 192.168.35.0/255.255.255.0 -i ! eth1 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i ! eth1 -j LOG
-A OUTPUT -o lo -p tcp -m tcp --dport 25 -m conntrack --ctstate NEW -j ACCEPT
-A NOWAY -p tcp -j REJECT --reject-with tcp-reset
-A NOWAY -j REJECT --reject-with icmp-port-unreachable
-A SSH_CHECK -m conntrack --ctstate NEW -m recent --set --name SSH --rsource
-A SSH_CHECK -m conntrack --ctstate NEW -m recent --update --seconds 90 --hitcount 4 --name SSH --rsource -j NOWAY
COMMIT
# Completed on Mon Nov 21 22:46:45 2011

Server B (Ubuntu 2.6.24-29.88-server), смотрит напрямую в интернет (eth1). Пинг вотпрямсчаз не работает, хотя IP неоднократно вычищал из таблицы.

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# Generated by iptables-save v1.3.8 on Mon Nov 21 22:51:03 2011
*mangle
:PREROUTING ACCEPT [24807785:7465627540]
:INPUT ACCEPT [17782527:3498619903]
:FORWARD ACCEPT [7024376:3966938305]
:OUTPUT ACCEPT [18248504:5368022841]
:POSTROUTING ACCEPT [25417209:9358956622]
-A FORWARD -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1357:1500 -j TCPMSS --set-mss 1356
COMMIT
# Completed on Mon Nov 21 22:51:03 2011
# Generated by iptables-save v1.3.8 on Mon Nov 21 22:51:03 2011
*nat
:PREROUTING ACCEPT [378514:21271836]
:POSTROUTING ACCEPT [125722:18419128]
:OUTPUT ACCEPT [272032:33419152]
-A PREROUTING -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PREROUTING -i eth1 -p tcp -m tcp --dport 4899 -m conntrack --ctstate NEW -j DNAT --to-destination 192.168.17.2:4899
-A PREROUTING -i eth1 -p tcp -m tcp --dport 23 -m conntrack --ctstate NEW -j DNAT --to-destination 192.168.17.2:23
-A POSTROUTING -o eth1 -j SNAT --to-source XX.YY.ZZ.TT
COMMIT
# Completed on Mon Nov 21 22:51:03 2011
# Generated by iptables-save v1.3.8 on Mon Nov 21 22:51:03 2011
*filter
:INPUT DROP [92699:15103942]
:FORWARD DROP [3138:181302]
:OUTPUT ACCEPT [18248430:5368018273]
:NOWAY - [0:0]
:SSH_CHECK - [0:0]
-A INPUT -i eth1 -j ULOG --ulog-prefix "OWN-INPUT "
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -s 192.168.17.0/255.255.255.0 -i ! eth1 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -i eth1 -p tcp -m multiport --dports 9,22,23,25,110,4899 -m conntrack --ctstate NEW -j SSH_CHECK
-A INPUT -p tcp -m tcp --dport 9 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -m conntrack --ctstate NEW -j NOWAY
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -j NOWAY
-A INPUT -p tcp -m tcp --dport 110 -m conntrack --ctstate NEW -j NOWAY
-A INPUT -p tcp -m tcp --dport 1723 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -i ! eth1 -j LOG --log-prefix "INPUT-TRAP "
-A FORWARD -i eth1 -j ULOG --ulog-prefix "FORWARD-IN "
-A FORWARD -o eth1 -j ULOG --ulog-prefix "FORWARD-OUT "
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -p gre -j ACCEPT
-A FORWARD -i eth1 -p tcp -m multiport --dports 9,22,23,25,110,4899 -m conntrack --ctstate NEW -j SSH_CHECK
-A FORWARD -s 192.168.0.0/255.255.0.0 -i eth1 -j NOWAY
-A FORWARD -d 192.168.0.0/255.255.0.0 -i eth1 -j NOWAY
-A FORWARD -s 192.168.17.0/255.255.255.0 -i ! eth1 -o eth1 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 192.168.17.0/255.255.255.0 -o ! eth1 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i ! eth1 -j LOG --log-prefix "FORWARD-TRAP "
-A OUTPUT -o eth1 -j ULOG --ulog-prefix "OWN-OUTPUT "
-A NOWAY -p tcp -j REJECT --reject-with tcp-reset
-A NOWAY -j REJECT --reject-with icmp-port-unreachable
-A SSH_CHECK -m conntrack --ctstate NEW -m recent --set --name SSH --rsource
-A SSH_CHECK -m conntrack --ctstate NEW -m recent --update --seconds 90 --hitcount 4 --name SSH --rsource -j NOWAY
COMMIT
# Completed on Mon Nov 21 22:51:03 2011

Пользователь решил продолжить мысль 21 Ноября 2011, 23:04:54:Да, авторазбанивание работает нормально. Если прекратить пинговать, то через 3-4 минуты можно подключиться по SSH спокойно.

[victor00000]

Никогда удалить -D ?

[AnrDaemon]

Никогда удалить -D ?

По-хорошему прошу - УЙДИ. Не провоцируй.
Пользователь решил продолжить мысль 21 Ноября 2011, 23:39:36:Я сейчас буду долго и со вкусом ругаться...

Код: [Выделить]

# netstat -tl | grep discard
(упс?)
# invoke-rc.d xinetd restart
 * Stopping internet superserver xinetd
   ...done.
 * Starting internet superserver xinetd
   ...fail!
(эээ.... ???)
# ps ax | grep xinet | grep -v grep
 5942 ?        S      0:00 (xinetd service)  discard -stream типаадрес
 7094 ?        S      0:00 (xinetd service)  discard -stream типаадрес
 8053 ?        S      0:00 (xinetd service)  discard -stream типаадрес
 8399 ?        S      0:00 (xinetd service)  discard -stream типаадрес
 8409 ?        S      0:00 (xinetd service)  discard -stream типаадрес
 8456 ?        S      0:00 (xinetd service)  discard -stream типаадрес
По -KILL'ял зомбей, ещё раз перезапустил xinetd - забегало.
В логах - пусто, пусто и пусто... Вопрос - ЧТОЭТОБЫЛО?

[alexxnight]

Да, авторазбанивание работает нормально. Если прекратить пинговать, то через 3-4 минуты можно подключиться по SSH спокойно.

а как у Вас реализовано авторазбанивание?

[victor00000]

Оффтоп
#truegeek

Предупреждение: 5%, п.2.3 Правил форума.

[AnrDaemon]

а как у Вас реализовано авторазбанивание?

Таки правило читайте

-A SSH_CHECK -m conntrack --ctstate NEW -m recent --set --name SSH --rsource
-A SSH_CHECK -m conntrack --ctstate NEW -m recent --update --seconds 90 --hitcount 4 --name SSH --rsource -j NOWAY


Если за последние 90 секунд было зарегистрировано 4 хита - не пускать.

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

[alexxnight]

а как у Вас реализовано авторазбанивание?

Таки правило читайте

-A SSH_CHECK -m conntrack --ctstate NEW -m recent --set --name SSH --rsource
-A SSH_CHECK -m conntrack --ctstate NEW -m recent --update --seconds 90 --hitcount 4 --name SSH --rsource -j NOWAY


Если за последние 90 секунд было зарегистрировано 4 хита - не пускать.

смотрите... у Вас первое правило заносит любой адрес (который попал в эту цепочку) в список, а второе правило обновляет время последнего обращения, и, если условия по 90 сек. и 4 срабатываниям успешно проверяется, то -j NOWAY.

а удаления нет.
посмотрите, я Вам написал пример с удалением. К сожалению, это организовывается через доп. цепочку...

я думаю, что изменение списка вручную может непредвиденно повлиять на систему... хотя надо тестировать...

[AnrDaemon]

А удаление и не нужно для нормальной работы. Само условие проверки "4 хита в 90 секунд" является разбанивающим.
Другое дело, что таблица может неконтролируемо расти.
А удалять адреса из неё (через нетфильтр) можно только при получении новых пакетов с этого же адреса.
Проще написать скрипт, вычитывающий /proc/net/ipt_recent/SSH и делающий
echo -$address >> /proc/net/ipt_recent/SSH
для всех адресов, с которых не было пакетов за, скажем, последний час.

[alexxnight]

А удаление и не нужно для нормальной работы. Само условие проверки "4 хита в 90 секунд" является разбанивающим.

а не скажите... после 4 хитов за 90 сек. попадает ip в бан и остается там очень надолго (пока не убрать). Не путайте с hashlimit, iplimit...

[AnrDaemon]

А удаление и не нужно для нормальной работы. Само условие проверки "4 хита в 90 секунд" является разбанивающим.

а не скажите... после 4 хитов за 90 сек. попадает ip в бан и остается там очень надолго (пока не убрать). Не путайте с hashlimit, iplimit...

Вы проверяли, прежде чем говорить такое?... Работает именно так, как написано в документации: ограничивает подсчёт числа пакетов указанным временем. Здесь нет никакого специального отдельного бана - само это правило и бан и разбан одновременно.

[alexxnight]

проведем простой тест:
IPTABLES -A -m recent --name test --rsource --update --seconds 20 --hitcount 3 -j REJECT
IPTABLES -A -m recent --name test --rsource --set

теперь сделаем 4 пинга:
первый - прошел
второй - прошел
третий - прошел
четвертый - не прошел - бан

Если теперь подождать 20 и более сек., то тест можно повторить, и результат будет такой же - 4 пинга: 1-ок, 2-ок, 3-ок, 4-бан

Если же пинговать постоянно, то бан будет после 3-ех пакетов и пока пинг не прекратим... или адрес не вычистим из /proc/net/xt_recent/test

[AnrDaemon]

Вы уже определитесь, что вы пытаетесь до меня донести. Что мои правила работают? Они работают. Я и без вас это знал.
И, да, меня устраивает, что бан не снимется, пока долбёжка не прекратится. В этом и есть смысл бана.