01-08-2014 11:11 AM
Short question - can it be done?
Now, I know what "incomplete" entries are in the log - they are failed 3-way handshakes, or ones that completed with no additional data. The problem is that "incomplete" is not an application or vulnerability that I can select and apply to rules in order to drop it.
Now, I realize I could get rid of it by crafting a more specific rule that does not simply pass "any" service, but uses Application defaults. The reason I don't do that is that I work at a university, and it is university mandate (as with many public institutions) to block and/or censor as little of the Internet as possible. Basically unless it's a known bad thing, I'm not allowed to block it. That said, being able to define "incomplete" as a vulnerability and set it up like some of the Brute Force attacks (SSH, for example) would be greatly beneficial. I could then set a threshold for how many of these I would permit before putting the offending external IP into quarantine. Is there a way to do this?
01-08-2014 11:19 AM
The reason that "incomplete" is not selectable is because the firewall doesn't know ahead of time what the app is. All applications technically start as incomplete and are changed into some valid application once enough packets come in. Only when that session has failed to establish does the log get written and the app is listed as incomplete.
Thus, there is no way to trigger on that. The cart is before the horse, so to speak. If you were to be able to trigger on 'incomplete', everything would trigger.
You can enable brute force attempt blocking via vulnerability profiles. There is a DOS protection policy you can put in place, and a zone protection policy to cover a whole zone.
Hope this helps,
Greg
01-08-2014 11:54 AM
I am aware that everything essentially starts as incomplete. I was hoping there was a way that it could track how many incomplete transactions were coming from an IP and act based on passing a certain threshold after a time.
The problem with the DoS protection is that when we last turned it on (during testing of the firewall), it was triggering on passing the established thresholds within minutes, and dropping a great deal of traffic to the campus. It seems to not apply the DoS to individual external offending IPs, but to the traffic as a whole. Zone-based may be a way to better control that, but zone-based DoS is not (or was not at the time) logged, and we must log any packet that is dropped/blocked.
01-09-2014 12:46 PM
Hi Aarom,
take a look at the DoS-protection differences for classified and aggregated traffic.
This should be helpful:
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
