Our campus has been getting a lot of NTP DDoS attacks of late. While the simple solution would be to shut it down except for necessary systems, the problem (as per usual in public-sector) is that everyone seems to want to run something that uses it and complains if we start blocking.
Looking at the attacks, it's very easy to see the difference between a legitimate NTP query (1 or 2 packets) and an attack. My question is: Is there a way to define a threshold-based filter that will drop or block the attack as with brute-force type attacks? That would solve all of the issues.
We can have a threshold based filter with respect to the sessions. In DOS protection profile we can set the Resource Protection to lets say 10 sessions, any traffic coming more than 10 sessions at a time is blocked and we can see the results in global counters.
This is purely used in scenarios where a specific traffic is bombarded. But if anything less than 10 sessions or 10 new packets it allows.
In the DOS rule we can configure the source and destination zone and source and destination IPs accordingly to narrow down right to the attacker.
Hope this helps.
Hmm... that might work if I can create a firewall rule to limit such DoS protection to only the NTP traffic - applying that to the campus traffic as a whole would seriously break things.
In the DOS rule we have an option to specify the service. We can provide port 123 for NTP and that should help by not matching all other campus traffic and only NTP.
Yes - I was looking into it and that was the approach that I was going to try taking. The catch is, we only want this applied on a per IP basis, not to all traffic using UDP 123, or again, with over 40K devices, that threshold would be overrun very quickly.
It would be better if PAN could define a new brute-force vulnerability for NTP so that it could be setup with a configurable threshold, and then an action be picked as a result. Until that happens though (or if it happens at all) the DoS method may be the only thing I have to use against it.
At this stage, it is wise to get packet captures and share the problem scenario and open the case. The logs would be analysed for the threat pattern and frequency and they can come up with a solution.
NTP reflection attacks are occurring frequently these days. The safest approach is lock down who you obtain NTP from (I do this on my border router). Short of that, the other way to approach it is create a threat exception action to block instead of alert:
Hi...You can define a custom threat signature and specify the time attribute as described. The custom signature can be completely new, or based on combination of existing threat signatures.
The problem with this signature is that it's not what's being triggered in this case. In fact, none of the NTP vulnerabilities were getting triggered. It showed up instead as traffic and application "NTP". Blocking anything but legitimate is easier said than done here - being a university with a lot of scientists and research going on, it may take the security teams weeks or months to determine what is officially needed vs. wanted.
For a custom signature, only ever built one that used existing vulnerabilities. Since those are not triggering in this case, how could I define a new one based simply on the fact that it is recognized as a NTP application?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!