[169328] in North American Network Operators' Group
Re: Filter NTP traffic by packet size?
daemon@ATHENA.MIT.EDU (TGLASSEY)
Thu Feb 20 23:14:57 2014
Date: Thu, 20 Feb 2014 20:14:30 -0800
From: TGLASSEY <tglassey@earthlink.net>
To: nanog@nanog.org
In-Reply-To: <CABSP1OfetOSRO0wrOdCWtAkOhnk0DJ00F=rDYn9bw+kDNrh8sg@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Type Enforcement in the OS Kernel is the place to do that.
Todd
On 2/20/2014 2:12 PM, Damian Menscher wrote:
> On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch <jared@puck.nether.net> wrote:
>> On Feb 20, 2014, at 3:51 PM, John Weekes <jw@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?
>>> 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.
>>
> Also, don't forget to ask those sending the attack traffic to trace where
> the spoofed packets ingressed their networks.
>
> > 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.
>>
> Preferably just source-port 123.
>
> 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.
>>
> Please don't filter UDP/80. It's used by QUIC (
> http://en.wikipedia.org/wiki/QUIC).
>
> Damian
>
>
--
-------------
Personal Email - Disclaimers Apply
