Solved

NTP DDos attack caused by old NTP server running FreeBSD

Posted on 2014-02-19
4
588 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
4 Comments
 
LVL 29

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 2

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 29

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 2

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

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

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

I had an issue with InstallShield not being able to use Computer Browser service on Windows Server 2012. Here is the solution I found.
This article is a collection of issues that people face from time to time and possible solutions to those issues. I hope you enjoy reading it.
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…

617 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