Solved

NTP DDos attack caused by old NTP server running FreeBSD

Posted on 2014-02-19
4
575 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 24

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

Netscaler Common Configuration How To guides

If you use NetScaler you will want to see these guides. The NetScaler How To Guides show administrators how to get NetScaler up and configured by providing instructions for common scenarios and some not so common ones.

Question has a verified solution.

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

Suggested Solutions

#Citrix #Citrix Netscaler #HTTP Compression #Load Balance
If you're not part of the solution, you're part of the problem.   Tips on how to secure IoT devices, even the dumbest ones, so they can't be used as part of a DDoS botnet.  Use PRTG Network Monitor as one of the building blocks, to detect unusual…
Internet Business Fax to Email Made Easy - With  eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, f…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

770 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