FreeBSD: Limiting icmp unreach response from 222 to 200 packets/sec

/var/log/messages が以上に肥大化していることを発見しました。

中身を見てみると次のようなメッセージが大量に記録され続けていました。

Jan  5 00:59:54 freebsd kernel: Limiting icmp unreach response from 222 to 200 packets/sec
Jan  5 00:59:56 freebsd kernel: Limiting icmp unreach response from 226 to 200 packets/sec
Jan  5 01:00:04 freebsd last message repeated 4 times
Jan  5 01:00:05 freebsd kernel: Limiting icmp unreach response from 228 to 200 packets/sec
Jan  5 01:00:08 freebsd kernel: Limiting icmp unreach response from 229 to 200 packets/sec
Jan  5 01:00:10 freebsd kernel: Limiting icmp unreach response from 228 to 200 packets/sec

icmpパケットの不達が大量に戻っているような感じ。
1/1の午後に突然始まり、いまだに継続していてログが膨れ続けています。放置しようかとも思いましたが過去ログがログローテートによって消えてしまうのもまずいので原因を調査して対策することにしました。

まず、このパケットはどこから来ているのか?

ファイヤーウォールのログを見ても、icmpパケットがどこから到着しているか記録されていません。

突然ログが膨れ始めたので外部からの攻撃だと考えて、ルーターのアクセスランプを見たものの、エラーメッセージが記録されるタイミングに外部からパケットが届いているようには見えません。外じゃなくて、LAN内部からのパケット?

となると、ホストを特定するためにファイヤーウォールの設定に、ICMPを記録するように一時的な設定を付加してみることにしました。LANから到着するICMPパケットを全部記録してみたところ、簡単に見つかりました。なぜかMacがサーバーに対してICMPパケットを出しているようです。LANをリセットすれば片付きそうです。

ということは、Macをリブートすればいいのでは?
確かに、安易ではありますが効果を見込めます。しかし再起動は時間が掛かることと、常時起動しているアプリケーションを起動するのが面倒なので、MacのLANだけリセットしてみることにしました。LANのリセットといってもリセットボタンがある訳じゃなく、ネットワークを一度無線LANに切り替えて、再度有線LANに戻してみることにします。

やっていたところ、一部アプリケーションを再起動する必要がありましたけどリブートすることなく問題解決。

ファイヤーウォール設定を元に戻して対策終了。こんなこともあるんですね〜。

コメントを残す