0

I'm getting a lot of ICMP throttle messages in my 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

I found the traffic is coming from a single host by running 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

Where 64.......125 is my server's IP and I assume 185.......98 is the requester (that's the only IP seen in 1000's of log lines)

I've tried to use pf to blacklist this IP, block ICMP access to this port (or in general, since it seems like ICMP is not port based?), and tried a custom rule to block:

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

Regardless of all my pf attempts I still see the system.log and tcpdump activity.

Have I properly interpreted the tcpdump lines? (The carat direction makes it look like it's only outbound packets?)

My understanding was pf blocked the packets from reaching the kernel, so if it was configured properly these messages would go away. Is that correct?

If it's not correct, do I need to take action based on the requests, or should I just follow the instructions for nullifying the log lines?

I'm using IceFloor to configure pf on OS X 10.8.5, if it's relevant.

1

The problem was that your server was receiving a flood of UDP packets sent to port 27960, and was responding by sending ICMP Destination Port Unreachable error messages. The ICMP throttling is the kernel dutifully throttling your server's outbound ICMP error responses to the inbound flood of UDP packets.

I suspect this port was used previously and the allow rule may still be in pf.conf. If all inbound UDP connections are blocked at the firewall then your server would not generate any ICMP error responses to UDP packets.

Your pf filter rules were configured to block icmp when the rule should have been configured to block the UDP flood for example:

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

If UDP port(s) are in fact open to one or more services then to block only outbound ICMP 'Destination Port Unreachable' messages and thus help to mitigate this type of DoS attack:

IPv4 (ICMP type 3, code 3)

block out on $ext_if inet proto icmp icmp-type unreach code port-unr

IPv6 (ICMP6 type 1, code 4)

block out on $ext_if inet6 proto icmp6 icmp6-type unreach code port-unr
0

Perhaps all the "udp port 27960 unreachable" messages were due to a previously opened connection that was not closed properly?

I noticed there was connection open to this port from the given IP.

After rebooting and watching with tcpdump again traffic appears much more normal (a handful of different IPs looking at various ports over the course of an hour).

Happy to hear possible explanations of why pf didn't block this activity initially, but it seems fine now.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.