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. Regards HASSAN On Sat, Feb 15, 2014 at 12:59 AM, Clay Fiske <[email protected]> wrote: > > On Feb 14, 2014, at 8:43 AM, Mouse <[email protected]> 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 > [email protected] > http://lists.ntp.org/listinfo/pool > _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
