[asterisk][iptables] Соединение в обход фаерволла? WTF?

А что в цепочке DROP1?
Что видно по tcpdump?
А если по-раньше завести правило, которое будет персонаьно дропать таргетинговый трафик?

Ну и офтоп. ACCEPT all  — * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED правильно ставить после loop или даже самым первым. Так как по нему трафику больше и Вы зачем-то этот трафик гоняете через всю цепочк ваших правил. Что не есть гуд.

policy DROP 0 packets, 0 bytes

Зачем нужен DROP1, у вас по дефолт-полиси ни одного байта (!) не прошло, о чем это говорит?

Уберите все правила из input и оставьте ТОЛЬКО (!) разрешающие - зачем дублировать default policy еще какими-то drop'ами?

В цепочке DROP1 ведётся лог отброшенных пакетов:

# iptables -L DROP1 -nv
Chain DROP1 (21 references)
 pkts bytes target     prot opt in     out     source               destination         
   52  3996 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 1/sec burst 10 LOG flags 0 level 4 prefix `DROP ' 
   52  3996 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

REJECT1 ведёт себя также. Смысл моих правил в том, что все пакеты дропаются и об этом создаётся запись в логе, особо указанные пакеты, т.е. те, которые ACCEPT, проходят без логирования.

Так вот, несмотря на то, что в INPUT на udp 5060 приём не разрешён, tcpdump показывает, с каких ай-пи идёт флуд на порт 5060

19:38:25.582301 IP 203.183.227.168.5533 > re.al.ipa.dr2.5060: SIP, length: 344
19:38:25.585014 IP 203.183.227.170.5278 > re.al.ipa.dr2.5060: SIP, length: 341
^C
445 packets captured
446 packets received by filter
0 packets dropped by kernel

Данные господа, похоже брутфорсят меня на скорости ≈1.5 Мбит/с и провайдер уже оповещён об этом, так что, скоро их заблокируют. Тут другое интересно: почему пакеты не дропнуты и в логах вообще не светятся. Я в первый раз сталкиваюсь с таким поведением за всё время использования (примерно 20 машинолет) такого фильтра.

что все пакеты дропаются и об этом создаётся запись в логе

policy - drop
1.accept
2. accept
n. accept
last. -j LOG -limit

Вот и все, этим вы упростите себе и жинь и дебаг (все равно в drop1 нифига ценного), а у вас уета наверчена.

Спасибо за эти подсказки и мелкие оптимизации, но они не отвечают на вопрос: почему трафик на 5060 udp не проходит через DROP, а сразу бежит в ACCEPT.

Проглядел всё ещё раз, всё правильно, а поди ж ты… Ради теста попробовал убрать в разрешённых входящие на 25 порт и сразу получил результат в логе.

Фантастика, в общем.

Решил все модули ядра, отвечающие за сетевую подсистему перекомпилировать статически, в ядро. Заодно, перезагрузился.

И, знаете, весь этот поток флуда стал дропаться. Но после перезапуска iptables опять полез.

Как я понимаю, ты сначала ставишь разрешающее правило, а когда начинается брутфорс, удаляешь его?
Тогда сразу после удаления правила выполняй conntrack -F (бинарник из пакета conntrack или conntrack-tools), и твои волосы станут мягкими и шелковистыми.

Не совсем так. Без разрешительных правил даём iptables'у -HUP и он нормально перезапускается. Если же остановить через -SIGTERM и запустить заново, то этот флуд лезет.

Испробую conntrack, о результатах отпишусь.

Мне ведь надо как-то решить проблему с автобаном таких вот брутфорсеров на будущее.

Для tcp-соединений, к примеру, сделано так:

$IPT -A INPUT -i $EXTIF -d $EXTIP -p tcp -m multiport --dports $INP_TCPSERV_E -m recent --update --seconds 180 --hitcount 2 --rttl --name SEC --syn -m state --state NEW -j LOG --log-prefix "BRUTE FORCE "
$IPT -A INPUT -i $EXTIF -d $EXTIP -p tcp -m multiport --dports $INP_TCPSERV_E -m recent --update --seconds 180 --hitcount 2 --rttl --name SEC --syn -m state --state NEW -j DROP
$IPT -A INPUT -i $EXTIF -d $EXTIP -p tcp -m multiport --dports $INP_TCPSERV_E -m recent --set --name SEC --syn -m state --state NEW -j ACCEPT

Для udp-соединений я хотел использовать аналогичное, только без проверки на --syn. К сожалению, оно не работает как надо, но, возможно, после использования conntrack -F ситуация исправится.

>Без разрешительных правил даём iptables'у -HUP и он нормально перезапускается. Если же остановить через -SIGTERM

WTF??? Какой HUP, какой TERM? iptables работает доли секунды, и в нормальной ситуации управление через сигналы не требуется.

Все наборы правил хранятся в ядре (точнее, в его компоненте — netfilter). iptables лишь модифицирует один из блоков этих правил (отвечающий за фильтрацию IPv4). Никаких юзерспейсовских сигналов нетфильтру послать нельзя, потому что это не юзерспейсовский процесс.

service iptables restart — просто очищает список правил в ядре, а потом загружает новый набор правил из файла. А за список активных соединений iptables не отвечает, поэтому перезагрузка правил никак не сказывается на пропускании пакетов уже существующих соединений.
Сброс таблицы соединений выполняется программой conntrack, как я писал выше.

Сегодня испробовал очистку таблицы текущих соединений.

Да, действительно, помогает при рестарте и при добавлениях-удалениях правил.

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

Всем спасибо за ответы.