Blockieren Sie ICMP-Flood von einer bestimmten IP-Adresse mit pf
781
owenfi
Ich bekomme eine Menge ICMP-Drosselnachrichten in meinem 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
Ich habe festgestellt, dass der Datenverkehr von einem einzelnen Host kommt, indem er ausgeführt wird 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
Wo 64.......125ist die IP meines Servers und ich nehme an, 185.......98ist der Anforderer (das ist die einzige IP, die in Tausenden von Protokollzeilen zu sehen ist)
Ich habe versucht, pfdiese IP-Adresse auf eine schwarze Liste zu setzen, den ICMP-Zugriff auf diesen Port zu blockieren (oder im Allgemeinen, da ICMP scheinbar nicht portbasiert ist?), Und habe eine benutzerdefinierte Regel zum Blockieren versucht:
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
Unabhängig von all meinen pf Versuchen sehe ich immer noch die Aktivität system.log und tcpdump.
Habe ich die tcpdumpZeilen richtig interpretiert ? (Die Karatrichtung lässt es so aussehen, als wären es nur ausgehende Pakete?)
Mein Verständnis war, dass pf die Pakete vom Kernel ferngehalten hat. Wenn sie also richtig konfiguriert wurden, würden diese Nachrichten verschwinden. Ist das korrekt?
Wenn es nicht korrekt ist, muss ich basierend auf den Anforderungen Maßnahmen ergreifen oder sollte ich einfach den Anweisungen zum Annullieren der Protokollzeilen folgen?
Ich verwende IceFloor zur Konfiguration pfunter OS X 10.8.5, sofern dies relevant ist.
1 Antwort auf die Frage
0
owenfi
Möglicherweise waren alle "UDP-Port 27960 nicht erreichbar" -Meldungen auf eine zuvor geöffnete Verbindung zurückzuführen, die nicht ordnungsgemäß geschlossen wurde.
Ich habe festgestellt, dass von dieser IP-Adresse aus eine Verbindung zu diesem Port besteht.
Nach dem Neustart und dem erneuten Anschauen mit tcpdump erscheint der Datenverkehr viel normaler (eine Handvoll verschiedener IPs betrachtet verschiedene Ports im Verlauf einer Stunde).
Es freut mich, mögliche Erklärungen zu hören, warum pf diese Aktivität anfangs nicht blockiert hat, aber jetzt scheint es gut zu sein.