27 Апр
2012
Рубрика: Asterisk, Linux
Автор:    Комментариев нет

Iptables и Fail2ban для защиты Asterisk. Часть 2

Подобное ограничение является особенно комфортным. Однако это лишь с одной стороны так, ведь подавляющая часть всех клиентов, даже наиболее крупных, занимаются рассылкой пакетов с одного и того же адреса при скорости ниже, чем тридцать пакетов в одну секунду.

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

Некоторые системы имеют небольшое встроенное ограничение recent модуля на hitcount параметр. Всего лишь двадцать пакетов данное ограничение стоит и внутри ОС CentOS. Выполнив данную команду вы увидите следующую ошибку:

iptables -A INPUT -p udp —dport 5060 -m recent —update —seconds 2 —hitcount 60 —name SIP \
-j LOG —log-prefix “SIP flood detected: „
iptables: Unknown error 4294967295

Или вот так, для 64 битных систем:

iptables -A INPUT -p udp —dport 5060 -m recent —update —seconds 2 —hitcount 60 —name SIP \
-j LOG —log-prefix “SIP flood detected: „
iptables: Unknown error 18446744073709551615

Чтобы максимальное ограничение изменить нужно передать модулю recent спец. параметр при загрузке. Чтобы сделать это необходимо создать файл /etc/modprobe.d/ipt.conf и прописать в нем следующий параметр:

options ipt_recent ip_pkt_list_tot=60

Нужно быть осторожными увеличивая это ограничение, потому что с ним увеличивается память, которая требуется для хранения последних пакетов, а еще и количество циклов для их обработки.

Отныне любой малейший флуд, поступающий на порт 5060, будет моментально обнаружен благодаря модулю recent и пакету iptables. Уведомление в виде сообщения об обнаруженном флуде направится в лог системы, где система обнаружения различных атак (к примеру fail2ban) сможет его заметить. Не станет ограничивать нас и iptables одним системным логом, действию под названием LOG смело можно указывать level (уровень) и сообщения Facility. С помощью настроек Syslog можно будет направлять данные сообщения в другой отдельный файл.

Сами же сообщения о SIP флуде будут выглядеть вот так:

Jun 20 22:53:42 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:22:5e:d6:16:b8:10:0f:34:f8:28:7f:08:00 SRC=184.172.52.3 DST=192.168.2024.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350
Jun 20 22:53:42 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:22:5e:d6:16:b8:10:0f:34:f8:28:7f:08:00 SRC=184.172.52.3 DST=192.168.204.217 LEN=369 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=349
Jun 20 22:53:42 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:22:5e:d6:16:b8:10:0f:34:f8:28:7f:08:0

Что вы думаете об этом?