So I run a high traffic NTP stratum 2 node. My bandwidth is a Gigabit and that’s what I have set as my speed on my server. Recently the IP fragmentation (Tear drop attacks?) have been THROUGH THE ROOF! I assume this is from the reflection exploits and people attempting to abuse the NTP pool for DDoS attacks.
I actually run snort in IPS mode in front of my NTP server and it’s patched up to the latest and whatnot, but that still doesn’t stop the swamp of fragmented packets flooding my network.
What are some of you doing to protect this? Is there any protection at the network level? Are you bumping your fragmentation tables up on your firewalls and just seeing how much your server can drink from the fire hose? Are there any snort rules that someone has come across that can cut down on this? Are you simply bumping your NTP speeds down to deal with it? I hate to give in to providing an essential public service, since I have the resources available, but it seems like the fragmentation/reflection attacks are hitting the NTP pool pretty hard recently.
I’m on the North America US pool. Hmm, I might be able to craft some type of firewall rule to block it, but I do have some VoIP stuff that does also fragment some UDP, but nothing near the volume that my NTP node sees. Also the VoIP traffic is locked down to only my VoIP provider’s server and it’s only 4 phones.
If that’s the case you could allow all traffic from your provider’s server before creating a rule to drop fragmented udp packets…
For iptables it’s just a simple ‘-p udp -f’ I don’t know if you can filter based on port destination. I forgot what bits are available in the fragments and what parts are only available once it’s reassembled.
From what I gather, the ietf discussion is mostly a theoretical vulnerability. Though it does seem to be quite a heated debate… I still haven’t had a chance to read the paper that was linked, hopefully will get a chance to sit down and do that today.
Zermus - I’m assuming you have done some inspection on these fragmented packets? Are there any more details you can give us?
Another thing besides blocking fragments as mentioned earlier, is blocking traffic at source / destination port 0. Fragments that aren’t the first packet often end up looking like this because of missing header info.
NTP really shouldn’t be sending fragments. Regular unauthenticated requests / responses for IPv4 & IPv6 are typically around only 100 bytes (that includes header info which is about half). NTP actually sends multi-packet responses (instead of fragmenting a single large packet response) only when making mode 6 or 7 responses, which your server should hopefully never answer except to explicitly allowed sources (this was the cause of amplification attacks back in the day).