pfを使用して特定のIPからのICMPフラッドをブロックする

system.logで多くのICMPスロットルメッセージを取得しています。

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リクエスターであると想定します（1000のログ行に表示される唯一の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関連する場合は、OS X 10.8.5でIceFloorを使用して構成しています。

問題は、サーバーがポート27960に送信されたUDPパケットのフラッドを受信し、ICMP Destination Port Unreachableエラーメッセージを送信して応答していたことです。ICMPスロットルは、UDPパケットのインバウンドフラッドに対するサーバーのアウトバウンドICMPエラー応答を忠実にスロットリングするカーネルです。

このポートは以前に使用されたと思われ、許可ルールはまだpf.confにある可能性があります。すべてのインバウンドUDP接続がファイアウォールでブロックされている場合、サーバーはUDPパケットに対するICMPエラー応答を生成しません。

pfフィルタールールは、UDPフラッドをブロックするようにルールを構成する必要がある場合に、icmpをブロックするように構成されています。例：

block drop in quick on re0 inet proto udp from 185.......98 to 64.......125 port 27960

UDPポートが実際に1つ以上のサービスに対して開かれている場合、アウトバウンド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で再度監視した後、トラフィックははるかに正常に見えます（1時間にわたってさまざまなポートを見る少数の異なるIP）。

pfが最初にこのアクティビティをブロックしなかった理由について考えられる説明を聞いて喜んでいますが、今は問題ありません。