Я получаю много сообщений 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 ответа2

1

Проблема заключалась в том, что ваш сервер получал поток пакетов 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
0

Возможно, все сообщения "udp port 27960 unreachable" были из-за ранее открытого соединения, которое не было закрыто должным образом?

Я заметил, что к данному порту было открыто соединение с данного IP.

После перезагрузки и повторного просмотра с помощью tcpdump трафик выглядит намного более нормальным (несколько разных IP-адресов, смотрящих на разные порты в течение часа).

Рад слышать возможные объяснения того, почему pf изначально не блокировал эту деятельность, но сейчас все выглядит хорошо.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .