Блокировать флуд ICMP от определенного IP с помощью pf
Я получаю много сообщений ICMP о дросселе в моем system.log:
Apr 11 20:45:28 kernel[0]: Limiting icmp unreach response from 1054 to 250 packets per second
Apr 11 20:45:29 kernel[0]: Limiting icmp unreach response from 529 to 250 packets per second
Я обнаружил, что трафик исходит от одного хоста, запустив sudo tcpdump -ni en0 "icmp[0]=3 and icmp[1]=3"
20:48:32.614241 IP 64.........125 > 185.......98: ICMP 64.......125 udp port 27960 unreachable, length 36
20:48:32.616923 IP 64.......125 > 185.......98: ICMP 64.......125 udp port 27960 unreachable, length 36
куда 64.......125 это IP моего сервера и я предполагаю 185.......98 является запросчиком (это единственный IP-адрес, видимый в тысячах строк журнала)
Я пытался использовать pf чтобы занести этот IP в черный список, заблокировать доступ ICMP к этому порту (или вообще, так как кажется, что ICMP не основан на порте?), и попытался создать пользовательское правило для блокировки:
block drop on en0 inet proto icmp from 64.......125 to 185.......98
block drop on en0 inet proto icmp from 185.......98 to 64.......125
Независимо от всех моих попыток pf я все еще вижу активность system.log и tcpdump.
Правильно ли я истолковал tcpdump линии? (Направление в каратах выглядит так, будто это только исходящие пакеты?)
Насколько я понимаю, pf заблокировал пакеты от попадания в ядро, поэтому, если он настроен правильно, эти сообщения исчезнут. Это верно?
Если это не правильно, нужно ли мне предпринимать действия на основе запросов, или я должен просто следовать инструкциям для обнуления строк журнала?
Я использую IceFloor для настройки pf на OS X 10.8.5, если это актуально.
2 ответа
Проблема заключалась в том, что ваш сервер получал поток пакетов UDP, отправленных на порт 27960, и отвечал, отправляя сообщения об ошибках ICMP Destination Port Unreachable. Регуляция ICMP - это ядро, должным образом регулирующее реакцию исходящих ICMP-ошибок вашего сервера на входящий поток пакетов UDP.
Я подозреваю, что этот порт использовался ранее, и правило разрешения все еще может быть в pf.conf. Если все входящие UDP-соединения заблокированы на брандмауэре, ваш сервер не будет генерировать какие-либо ICMP-сообщения об ошибках на UDP-пакеты.
Ваши правила фильтра pf были настроены для блокировки icmp, когда правило должно было быть настроено для блокировки потока UDP, например:
block drop in quick on re0 inet proto udp from 185.......98 to 64.......125 port 27960
Если UDP-порт (-ы) фактически открыт для одной или нескольких служб, то блокировать только исходящие ICMP-сообщения 'Destination Port Unreachable' и, таким образом, можно смягчить этот тип DoS-атаки:
IPv4 (ICMP тип 3, код 3)
block out on $ext_if inet proto icmp icmp-type unreach code port-unr
IPv6 (ICMP6 тип 1, код 4)
block out on $ext_if inet6 proto icmp6 icmp6-type unreach code port-unr
Возможно, все сообщения "udp port 27960 unreachable" были из-за ранее открытого соединения, которое не было закрыто должным образом?
Я заметил, что к данному порту было открыто соединение с данного IP.
После перезагрузки и повторного просмотра с помощью tcpdump трафик выглядит намного более нормальным (несколько разных IP-адресов, смотрящих на разные порты в течение часа).
Рад слышать возможные объяснения того, почему pf изначально не блокировал эту деятельность, но сейчас это выглядит нормально.