Как отбить DDOS
В общем решили меня не хорошие люди тупо ддосить, не перебирая ни пароли ни ища возможно клиентов на астериске. В целом fail2ban не помог, т.к. не было логов на попытку регистрации (ну так я думал, пока дамп не посмотрел), следовательно ему нечего было в логах искать и банить.
При этом DDOS у меня жрал астер 99,8% от проца и не могли sip юзеры прорегаться, писало има lagged. Забанил их IP в иптайблисе и всё, но в целом хочется на автомате что бы было.
Прочитал что вроде iptables можно заставить наблюдать за активностью на порту 5060, скольок пакетов в секунду можно пропустить. Так вот в эту сторону смотреть или как?
Asterisk 1.6.0.22-samy-r60 currently running on trixbox
Added after 34 minutes:
Вот сдампил это чудо, заодно глянул за 3 дня, не полных 11 гигов налили.
Все пакеты одинаковые, только call-id меняется и branch.
17.23.24.1 - это я
208.87.243.227 - это злодей
Session Initiation Protocol
Request-Line: REGISTER sip:17.23.24.1 SIP/2.0
Method: REGISTER
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 208.87.243.227:5229;branch=z9hG4bK-2282565944;rport
Transport: UDP
Sent-by Address: 208.87.243.227
Sent-by port: 5229
Branch: z9hG4bK-2282565944
RPort: rport
Content-Length: 0
From: "126"
SIP Display info: "126"
SIP from address: sip:126@17.23.24.1
Accept: application/sdp
User-Agent: friendly-scanner
To: "126"
SIP Display info: "126"
SIP to address: sip:126@17.23.24.1
Contact: sip:123@1.1.1.1
Contact Binding: sip:123@1.1.1.1
URI: sip:123@1.1.1.1\r
CSeq: 1 REGISTER
Sequence Number: 1
Method: REGISTER
Call-ID: 1595505752
Max-Forwards: 70
канал вам забьют в любом случае, чтобы вы там у себя не ставили
_________________
Asterisk 1.4.30 @ Ubuntu 9.04 + Cisco MC3810 + NEC NEAX 2000IPS + Polycom IP Phones
Перебить и закрыть, и за пять минут выловить 40 человек и перебить порт, а потом новый геЙний догадается, о смене порта.
Спасибо Samael вот именно этого я ни как найти не мог, видать гугол забанил или не так вопрос ему задавал.
Added after 2 hours 47 minutes:
iptables -A INPUT -p udp --dport 5060 -j SCAMBLOCK
iptables v1.3.5: Couldn't load target `SCAMBLOCK':/lib/iptables/libipt_SCAMBLOCK.so: cannot open shared object file: No such file or directory
В целом не знаю чаго доставить, что бы радость была. В CentOS iptables сейчас до последнего yum обновился.
Added after 28 minutes:
Решил пока на это забить, воткнул два правила
iptables -A INPUT -p udp --dport 5060 -m recent --set --name SIP
iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP -j LOG --log-prefix "SIP flood detected: "
Получаю вот такое
13069 4874K udp -- any any anywhere anywhere udp dpt:sip recent: SET name: SIP side: source
0 0 LOG udp -- any any anywhere anywhere udp dpt:sip recent: UPDATE seconds: 2 hit_count: 60 name: SIP side: s
С виду ни чего в счётчик для логов не попадает, что совсем не так получается......
Added after 1 hours 53 minutes:
вот подсказка - из приведенной Samael ссылки:
| Цитата: | ||
| Ну вот и всё, теперь любой флуд на порт 5060 будет обнаружен с помощью модуля recent пакета iptables. Сообщение об обнаруженном флуде будет направлено в системный лог где его сможет увидеть наша любимая система обнаружения атак (например fail2ban). iptables не ограничивает нас одним лишь системным логом, действию LOG можно указать уровень (level) и facility сообщения, а в настройках Syslog перенаправить данные сообщения в отдельный файл. Сами же сообщения о SIP флуде будут выглядеть вот так: |
| Код: |
| Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350 Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=369 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=349 Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350 |
В той ссылке которую мне дали (я воткнул можно сказать как есть в моём посте от Fri Jun 24, 2011 17:49)
1) Нет либый, да думаю тут другое что-то имелось введу, в инете вообще глухо, что такое слово существует (SCAMBLOCK).
2) Не пишет в лог эти строчки в iptables, в вторую строчку с счётчиком 0 пакетов.
| EXA писал(а): |
| 1) Нет либый, да думаю тут другое что-то имелось введу, в инете вообще глухо, что такое слово существует (SCAMBLOCK). |
Читать нужно внимательней.
| Цитата: |
| Первое правило проверяет наш пакет по цепочке SCAMBLOCK. В данной цепочке хранятся заблокированные IP адреса |
соответственно получается что SCAMBLOCK это всего лишь название блока в правилах iptables и это имя может быть абсолютно любым. автор статьи просто опустил момент создания этого блока в правилах. но по логике этот блок может быть создан например fail2ban, тогда становится понятной логика - сперва проверяем - если ли IP уже в нашем списке и если нет то проводим проверку дальше. если дальнейшая проверка находит вредный IP то fail2ban сует его в этот блок.
ps: это правило можно вообще выкинуть из приведенного примера, пример работать будет всеравно. я так понимаю автор просто этой проверкой пытался снизить нагрузку на сам iptables, в чем есть определенный смысл.
pps: SCAMBLOCK в приведенном примере можно с легкостью заменить например на fail2ban-ASTERISK
| EXA писал(а): |
| 2) Не пишет в лог эти строчки в iptables, в вторую строчку с счётчиком 0 пакетов. |
разберитесь и настройте свой Syslog, не пишет потому что не настроен.
Сегодня по второму заходу буду пробовать.
Added after 1 hours 28 minutes:
Решил пока что забить на цепочку эту (сделать ля начала ну что бы просто так работало).
И сделал вот так
iptables -A INPUT -p udp --dport 5060 -m recent --set --name SIP
iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP -j LOG --log-level INFO --log-prefix "SIP flood detected: "
в /etc/syslog.conf
добавил
kern.=info -/var/log/iptables.log
создал /var/log/iptables.log
/etc/init.d/syslog restart
В файлике логов такое
Jun 27 07:53:53 trixbox kernel: klogd 1.4.1, log source = /proc/kmsg started.
Вот что в iptables -L -v
8724 3352K udp -- any any anywhere anywhere udp dpt:sip recent: SET name: SIP side: source
0 0 LOG udp -- any any anywhere anywhere udp dpt:sip recent: UPDATE seconds: 2 hit_count: 60 name: SIP side: source LOG level info prefix `SIP flood detected: '
Вот все правила в INPUT
Chain INPUT (policy ACCEPT 11M packets, 2309M bytes)
pkts bytes target prot opt in out source destination
53M 18G fail2ban-ASTERISK all -- any any anywhere anywhere
41044 15M udp -- any any anywhere anywhere udp dpt:sip recent: SET name: SIP side: source
0 0 LOG udp -- any any anywhere anywhere udp dpt:sip recent: UPDATE seconds: 2 hit_count: 60 name: SIP side: source LOG level info prefix `SIP flood detected: '
15797 5805K REJECT all -- any any 208.87.243.0/24 anywhere reject-with icmp-port-unreachable
Очень сильно напрягает это "0 0 LOG" почему ну ни чаго.
Гы, оказывается моя CentOS 5 не материться вот так
iptables: Unknown error 18446744073709551615
Поставил вместо 60, 20 стало работать и лог пишется. теперь Fail2Ban надо настроить.
Added after 1 hours 21 minutes:
Кажись забедил
1) Убрал это
в /etc/syslog.conf
kern.=info -/var/log/iptables.log
Т.к. всё равно в message всё дублировалось
Т.к. валиться всё в messages добавил в в настрйки fail2ban в /etc/fail2ban/filter.d/asterisk.conf
такую вот строчку
failregex = ..................................................
SIP flood detected.* SRC=.*
Всё теперь банит.
| EXA писал(а): |
| И сделал вот так iptables -A INPUT -p udp --dport 5060 -m recent --set --name SIP iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP -j LOG --log-level INFO --log-prefix "SIP flood detected: " |
Все то же самое я делаю чуть иначе (просто наглядее получается). Примерно так:
| Код: |
| # даем VoIP доступ # Создаем цепочки SIP attack $IPT -N SIP_CHECK $IPT -N SIP_ATTACKED for i in $VOIP_ALLOWS do # Захватываем SIP-соединение $IPT -A INPUT -p udp -m udp -s $i -m multiport --dports $VOIP_PORTS -j SIP_CHECK # Определяем цепочку SIP_CHECK $IPT -A SIP_CHECK -m recent --name SIP_COUNT --update --seconds 2 --hitcount 60 -j SIP_ATTACKED $IPT -A SIP_CHECK -m recent --name SIP_COUNT --set $IPT -A SIP_CHECK -m recent --name SIP_COUNT ! --rcheck --seconds 15 --hitcount 2 -j REJECT --reject-with icmp-port-unreachable $IPT -A SIP_CHECK -j ACCEPT # Определяем цепочку SIP_ATTACKED $IPT -A SIP_ATTACKED -j LOG --log-prefix "SIP flood detected: " $IPT -A SIP_ATTACKED -j REJECT --reject-with icmp-host-unreachable $IPT -A INPUT -p udp -m udp -s $i --dport 10000:20000 -j ACCEPT done |
Ну и последней записью в цепочке INPUT :
$IPT -A INPUT -j REJECT --reject-with icmp-host-unreachable
То есть банить начинаем сразу (не дожидаясь реакции fail2ban) и немедленно, как только с определенного, явно разрешенного адреса придет лишний пакет за заданный интервал времени. Ну а если придет с неразрешенного адреса - то гуляй, Вася, сразу мимо *. То есть всё, что явно не разрешено отвергается с сообщением о недоступности хоста. А тем хостам, которым заходить можно - порт откроется только со второй попытки в течение 15 секунд. В результате сканирования портов на предмет их открытости - наши порты закрыты. Злобный хакер пойдет дальше (сканировать иные хосты). А если ты знаешь, что он открыт, постучись чуть более понастойчивей, порт и откроется.
fail2ban в этом случае нужен чтобы время бана существенно удлинить, чтобы не через 2 секунды (после обнуления счетчика) интрудер снова возобновил свои попытки, а сильно подольше погулял.
Кстати, а на чем основан выбор 2-60?