Solved

NTP DDos attack caused by old NTP server running FreeBSD

Posted on 2014-02-19
4
576 Views
Last Modified: 2016-02-11
We recently fell victim to an NTP DDoS attack as a result of failing to patch our old FreeBSD 6.0 time server.

When the attack occurred it maxed out both our incoming and outgoing bandwidth.  We soon identified the NTP server as the problem and disconnected it, as well as blocking all traffic to it in the firewall.  This solved the outgoing problem, as the NTP server was no longer sending replies to the NTP requests - but our incoming bandwidth continues to be hammered.

Graphs show that all the attack packets (UDP 123 destined for the NTP server) stop at the firewall as you would expect.

Do we now just need to wait for the attacker to instruct his botnet to look elswhere - or is there something else we can do to mitigate this?

Thanks in advance for any advice!
0
Comment
Question by:David Haycox
  • 2
4 Comments
 
LVL 28

Accepted Solution

by:
Jan Springer earned 400 total points
ID: 39871431
Ask your upstream if it/they will block destination UDP 123 for your subnets.
0
 
LVL 1

Author Comment

by:David Haycox
ID: 39872591
We're still waiting for them to call us back!  They escalated it through different levels of support and have identified it as a "security issue".  Our account manager is apparently chasing their 2nd line security support in order to identify the next step.

Is this something that has happened to you, and if so were you able to get UDP 123 blocked?
0
 
LVL 25

Assisted Solution

by:masnrock
masnrock earned 100 total points
ID: 39902484
Is your firewall dropping the packets or specifically refusing them? Dropping would be the better approach, because then the attacker doesn't know the difference between the server being offline and your firewall not allowing the packets. But yes, unless you have good reason, you shouldn't have your NTP server be accessible from outside of the firewall. Might want to review your firewall rules as a whole while you're at it.
0
 
LVL 1

Author Comment

by:David Haycox
ID: 39902534
Problem was resolved by the leased line provider blocking UDP 123 destined for the problem server's IP at their router, thereby not clogging up our bandwidth.

Firewall was dropping the packets, so as far as the attacker's concerned nothing changed when this started happening  one hop further back.

Firewall rules already reviewed!

Thanks
0

Featured Post

Create the perfect environment for any meeting

You might have a modern environment with all sorts of high-tech equipment, but what makes it worthwhile is how you seamlessly bring together the presentation with audio, video and lighting. The ATEN Control System provides integrated control and system automation.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

If you thought ransomware was bad, think again! Doxware has the potential to be even more damaging.
Provide an easy one stop to quickly get the relevant information on common asked question on Ransomware in Expert Exchange.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

829 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question