• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 612
  • Last Modified:

NTP DDos attack caused by old NTP server running FreeBSD

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
David Haycox
Asked:
David Haycox
  • 2
2 Solutions
 
Jan SpringerCommented:
Ask your upstream if it/they will block destination UDP 123 for your subnets.
0
 
David HaycoxAuthor Commented:
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
 
masnrockCommented:
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
 
David HaycoxAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now