Solved

NTP DDos attack caused by old NTP server running FreeBSD

Posted on 2014-02-19
4
567 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 20

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

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Today, still in the boom of Apple, PC's and products, nearly 50% of the computer users use Windows as graphical operating systems. If you are among those users who love windows, but are grappling to keep the system's hard drive optimized, then you s…
Meet the world's only “Transparent Cloud™” from Superb Internet Corporation. Now, you can experience firsthand a cloud platform that consistently outperforms Amazon Web Services (AWS), IBM’s Softlayer, and Microsoft’s Azure when it comes to CPU and …
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.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

759 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

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now