On 20 Feb 2014, at 20:42, Brian Rak <[email protected]> wrote: > You generally only need rate limits if you have monlist enabled for some > reason. There's no reason to expose monlist to the internet, so you > shouldn't need rate limits.. > > I've lost track of how many times I've said this, but iptables is not the > solution to these attacks. The solution is fixing your config to disable > monlist (add noquery to your 'restrict default' lines).
This is somewhat misleading. Yes of course disabling monlist is a Very Good Thing and everyone should do it. However that simply isn't enough and it's quite wrong of you to imply otherwise. FYI when my server was attacked (50-100Kqps), no monlist queries were involved. This was disabled in the server too. The script kiddies didn't seem to be all that bothered about amplification as an attack vector. So whatever they got from a straight reflection attack was good enough from their perspective. Assuming those cretins applied any thought before mounting the attack. Kernel-level rate limiting can help, albeit at the cost of dropping/blocking some legitimate traffic. It has a role to play as part of a multi-stage defence. Your ISP should be deploying source address filtering/validation at their edge routers. Though they probably don't: good luck getting them to change. Your edge routers or firewalls should be doing traffic shaping and/or rate limiting. Next, rate limiting in the kernel will at least reduce the volume of responses your NTP server sends. That has to be a Good Thing, especially when the query source addresses are bogus. Finally, there's the rate limiting that's built in to ntpd, though that might be little use when there are bazillions of (spoofed) source addresses on the incoming query stream. If I can use an analogy. A modern car doesn't just have safety belts fitted (ie monlist disabled). It has crumple zones. And no sharp edges in the interior. And a collapsable steering wheel. And air bags. And... _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
