Блокировать флуд 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, если это актуально.

Проблема заключалась в том, что ваш сервер получал поток пакетов 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 изначально не блокировал эту деятельность, но сейчас это выглядит нормально.