[Pool] DDoS Type Attack

Nyamul Hassan nyamul at gmail.com
Sun Feb 16 19:58:31 UTC 2014

Good point, Clay Fiske.  Is there a realistic estimate to how many packets
/ sec a legitimate remote is allowed?

Suppose, if we can agree on numbers like:
Less than 100 packets each min
+ Less than 300 packets in 10 mins
+ Less than 500 packets in 1 hour

These tiered rules can be some indicator of "misbehaving" clients, and we
can put checks in place.


On Sat, Feb 15, 2014 at 12:59 AM, Clay Fiske <clay at bloomcounty.org> wrote:

> On Feb 14, 2014, at 8:43 AM, Mouse <mouse at Rodents-Montreal.ORG> wrote:
> >> If you are saying that normal NTP time queries should be forbidden to
> >> those behind NAT routers, you are stopping about 99% of those I know
> >> who are using NTP from doing so.  I hope this was not your intention,
> >> or that I have somehow otherwise mis-understood.
> >
> > No, not that they should be prevented.  Just that if it _doesn't_ work,
> > it's their own fault - that is, when I see "this works without NAT and
> > breaks with NAT", my reaction is much more "don't do that, then" than
> > "the peer should be fixed".
> So all I need to do is write a client that uses a non-123 source port and
> you’ll support fixing it? Great. :)
> I dislike NAT as much as the next person, but it is a reality in a lot of
> places and is often not up to the people who desire NTP synchronization
> whether they are behind a NAT device. And to be clear, NAT is not breaking
> it in this situation. Someone’s deliberate firewall rule is breaking it. So
> more like “this works without your arbitrary rule and breaks with it”.
> Also it only takes a simple tweak and this rule becomes ineffective even
> at its intended purpose. If the attacker is able to spoof the source IP,
> you can bet they’re not prevented from using source port 123 either.
> -c
> _______________________________________________
> pool mailing list
> pool at lists.ntp.org
> http://lists.ntp.org/listinfo/pool

More information about the pool mailing list