If you are running NTP server in public please read URGENTLY

[birdwes]

http://arstechnica.com/security/2014/01 ... ps-floods/

http://web.nvd.nist.gov/view/vuln/detai ... -2013-5211

It's hurting my clients too.

Please make sure you are not a ntp amplifier.

You may have to rebuild ntp.

[birdwes]

The attacks my client are getting are attempting to spoof IP packets to Halo and Steam networks, but they're flooding the net connection. My clients have nothing to do with games. The hackers are just trying to use a non existent ntp server to do an ntp equivalent of a "smurf amplifier" attack.

http://www.theregister.co.uk/2014/02/11 ... s_400gbps/

But the attack continues.....

http://bgr.com/2014/01/20/smart-tvs-fridge-hacked/

[ripat]

The solution for the Debian like os is easy. Remove ntp(d) and install ntpdate instead.

ntpdate is a client and will never answer any ntp request.

[allfox]

Is there any way to configure the full NTP daemon to reply local queries only? Pi has no hardware clock to maintain time accuracy, so I think a constant running daemon is a must for a Pi server.

Edited for additional review on this topic:

I find this page: http://support.ntp.org/bin/view/Main/Se ... tack_using

Mitigation:
Upgrade to 4.2.7p26 or later.
Users of versions before 4.2.7p26 should either:
Use noquery in your default restrictions to block all status queries.
Use disable monitor to disable the ntpdc -c monlist command while still allowing other status queries.

Just checked my Pi, it is running ntp 4.2.6p5...

[ripat]

I always avoid running unnecessary daemon on my *nix boxes. I never used the ntp daemon for that reason. It uses memory and continuously listen on its ports for UDP queries.

If you only need to sync the RPi's clock, ntpdate in more than enough. It is run from the /etc/network/if-up directory waiting for an interface to come up before syncing. You can also copy that script in the /etc/cron.hourly if you really need to update more frequently. The drift rarely exceed 1/10th of a second which is acceptable to me. The average drift on 800 hourly adjustments is -0,07 sec. on one of my RPi's.

[DougieLawson]

I thought it was only a problem if you run an open public NTP server and not a simple slave that only acts as a client and not as a peer.

Port 123 isn't open on my router and my ntp.conf is locked down to my subnets only.

[allfox]

I always avoid running unnecessary daemon on my *nix boxes. I never used the ntp daemon for that reason. It uses memory and continuously listen on its ports for UDP queries.

If you only need to sync the RPi's clock, ntpdate in more than enough. It is run from the /etc/network/if-up directory waiting for an interface to come up before syncing. You can also copy that script in the /etc/cron.hourly if you really need to update more frequently. The drift rarely exceed 1/10th of a second which is acceptable to me. The average drift on 800 hourly adjustments is -0,07 sec. on one of my RPi's.

This solution is cool, I didn't know the cron.hourly magic at all. I just made a link to /etc/network/if-up.d/ntpdate in cron.weekly.

[scruss]

… I just made a link to /etc/network/if-up.d/ntpdate in cron.weekly.

A weekly sync is going to be quite a bit of drift; 10 seconds or so. This matters if you're synching with remote file systems.

Your NTP clients are fine. There's nothing to see here.

[birdwes]

My point is only that I don't know what you've all done with your Pi's. For all I know, some of you could have a GPS stratum 1 hooked up to the Pi running ntpd?

My clients (that is business clients) run another version of Linux on full blown x64 servers. I guess that at least few of you here run full blown servers on business networks?

It is just as important though to make sure that small embedded devices are either firewalled off, or updated if possible as this attack is still causing a lot of problems, this minute as I post.

[birdwes]

You can get attacked, even if you are not running ntpd, or firewalled off. Wireshark will prove this if your big Linux box is a multi-homed router.

The attack will simply consume most of your bandwidth, and deny some of mine if you have an open ntp port on a pre .26 version.

[allfox]

You can get attacked, even if you are not running ntpd, or firewalled off. Wireshark will prove this if your big Linux box is a multi-homed router.

The attack will simply consume most of your bandwidth, and deny some of mine if you have an open ntp port on a pre .26 version.

I guess I can do nothing to eliminate the possibility of being attacked. It's just human nature to hit someone when he has a weapon. I could only prey to the god of education and law. But before the god get noted, I'll try to make my machines not being used to hit other people.

[ripat]

You can get attacked, even if you are not running ntpd, or firewalled off. Wireshark will prove this if your big Linux box is a multi-homed router.
The attack will simply consume most of your bandwidth, and deny some of mine if you have an open ntp port on a pre .26 version.

Yes, all firewalled routers will see the ntp UDP queries coming and drop|reject them as they arrive. Even if you have a ntpd server behind it, these packets will never go through and will remain unanswered, removing the Amplified part of the ADRDOS (Amplified Distributed Reflective Denial of Service). So, I don't see how it can consume so much bandwidth. Our firewalls continuously receive packets of all sorts sent by Script Kiddies and Scanner Monkeys.

Of course, if your client run a public ntp server AND is designated as the target of the ADRDOS attack, the bandwidth will be consumed in no time.

[birdwes]

True,

But if you can get the ISP to block it at their end of the ADSL pipe, it will stop the bandwidth problems. The trouble Eclipse won't do anything about it!

My Client uses 4 ISPs: Demon, Pipex, Zen, Eclipse. The theory being that if one goes down they can continue. That is until pikies got a Land Rover and stole half a mile of the copper.

[plugwash]

My Client uses 4 ISPs: Demon, Pipex, Zen, Eclipse. The theory being that if one goes down they can continue.

Note that pipex were taken over by tiscali (who were later taken over by talktalk) and at least round here they quietly migrated users to tiscali LLU (and broke my parents internet connection in the process), so afaict if you keep using them you are paying pipex prices for tiscali/talktalk service quality.

That is until pikies got a Land Rover and stole half a mile of the copper.

Indeed, I think your client is foolish. IMO to get any significant benefit from having more than two broadband serivces they need to be on different infrastructure (so virgin media cable+BT wholesale ADSL+LLU ADSL+cellular would be a good combination if you can get it)

[birdwes]

Unfortunately that is not available at their location. It is rural. There is no LLU or fibre option.