On Feb 20, 2014, at 3:51 PM, John Weekes <j...@nuclearfallout.net> wrote:
> On 2/20/2014 12:41 PM, Edward Roels wrote: >> Curious if anyone else thinks filtering out NTP packets above a certain >> packet size is a good or terrible idea. >> >> From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are >> typical for a client to successfully synchronize to an NTP server. >> >> If I query a server for it's list of peers (ntpq -np <ip>) I've seen >> packets as large as 522 bytes in a single packet in response to a 54 byte >> query. I'll admit I'm not 100% clear of the what is happening >> protocol-wise when I perform this query. I see there are multiple packets >> back forth between me and the server depending on the number of peers it >> has? >> >> >> Would I be breaking something important if I started to filter NTP packets >>> 200 bytes into my network? > > If your equipment supports this, and you're seeing reflected NTP attacks, > then it is an effective stopgap to block nearly all of the inbound attack > traffic to affected hosts. Some still comes through from NTP servers running > on nonstandard ports, but not much. > > Standard IPv4 NTP response packets are 76 bytes (plus any link-level > headers), based on my testing. I have been internally filtering packets of > other sizes against attack targets for some time now with no ill-effect. You can filter packets that are 440 bytes in size and it will do a lot to help the problem, but make sure you conjoin these with protocol udp and port=123 rules to avoid collateral damage. You may also want to look at filtering UDP/80 outright as well, as that is commonly used as an "I'm going to attack port 80" by attackers that don't quite understand the difference between UDP and TCP. Next up, we will see the proto=0 and proto=255 attacks again.. - Jared
