I've setup a Zone Protection network profile and applied it to our DMZ zone. I changed the default for port scan on the Reconaissance Protection tab to 30 events in 3 seconds. TCP port scan is enabled, and the action is set to block-IP.
I run a test by scanning a host in the DMZ, 10,000 ports in 166 sec. That's a rate of ~ 60 port / sec, and it should have triggered the ZP profile, but didn't.
Do security policies take precedence over ZP, or vice versa?
zone protection has precedence over security policies
where are you scanning from? the internet or your lan network?
Zone protection is applied to the ingress interface, so you need to apply the protection profile to the zone where your scans are 'entering' your network (as opposed to the final destination)
This to protect the network and the firewall at the very first instance where the attack can be detected
I actually scanned both from the "tunnel" zone (a remote site) and the WAN. I've been using this to test:
C:\Program Files\Nmap>nmap -PS -pT:1-9999 -r <destIP> Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-04 07:49 Pacific Daylight Tim e Nmap scan report for <fqdn> (<destIP>) Host is up (0.00092s latency). Not shown: 5050 filtered ports, 4946 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 11.51 seconds
I can see all these packets in the logs, but ZP does not kick in. Is there anything else you need to do, besides creating a ZP profile and assigning it to a certain zone?
zone protection has precedence over security policies
Apparently this is not entirely accurate. Turns out that if a security policy blocks the offending scans, ZP does not kick in:
I run a test by allowing the source_ip in my security policies, run a new port scan, and the "scan" threat got triggered. This seems inconsistent with the whole ZP has precedence over security policies idea.
I do hope this changes at one point
What the article states is correct in the fact that you will not see threat logs generated by your Zone Protection profile because it's dropping the traffic right from the get go. So even though your traffic to your eyes should have registered the traffic is dropped before the limits are able to build up to trigger the Zone Protection profile.
If you are trying to test a Zone Protection profile it needs to be legit traffic or you really need to throw traffic at the zone to actually get it to trigger. The Deny rule is being hit and the traffic is being dropped before your Zone Protection has a chance to trigger because it's thresholds are not being hit; which is what the article is trying to get across.
You can still trigger your Zone Protection profile prior to the traffic being dropped but you need to throw enough traffic at the zone to the point where it doesn't have enough time to analyze the security policies before your limits are reached. That is a very hard task to accomplish and I don't think you'll hit it testing with one box.
But he is right with his point, at least for the port scans. The port scan protection in the zone protection is pretty much useless unless you have quite a few or all ports allowed or when you have an app in your poilicy with tcp/udp/dynamic as default ports and you did not manually restrict it to a few ports.
Or am I missing something?
If I'm not mistaken, DoS profiles do not have reconaissance protection, (at least in 7.1.11); how do I stop port scan / host sweep with DoS?
To my previous post, I was just wondering what is the use-case of ZP protection recoinnassance as it is now? 99% of the time most ports from the outside are going to be already blocked, so ZP for port scan is... redundant? If ZP kicked in no matter the security policies, I think that that would be useful.
One use for ZP could be to protect the LAN zone, but then I need a way to white-list some IPs. :)
I would say ZP Protection recoinnassance is primarly used in ISP enviroments where you actually would have all ports open to your customers, and therefore the ZP can actually work as intended without having the Deny rule processing the traffic before the thresholds can be hit. I would guess that hosting enviorments would likely see the same benefits; but yes most customers won't have any real protection as the Deny rule will simply drop the traffic before the set threshold is reached which doesn't allow the ZP to actually ever hit the threshold within the interval setting.
DoS protection doesn't offer a reconaissance protection but it does offer the ability to set a Session Limit specific to one IP address. In a way this will prevent a port scan as you can set the maximum session count a sole source should ever generate to that IP. Initiating a port scan would cause a sources session count to climb relatively quickly causeing the limit to trigger. In almost all cases the actual session limit value that I'm able to keep on my DMZ gear is very low on a classified DoS profile and in testing stops port scans relatively quickly. Of course the attacker will know a few of the most common ports status as that session limit is reached, but that's true with port-scan detection as well.
Thanks for explaining. Is this the right command to count the current sessions for a specific IP:
> show session all filter count yes destination <dest_ip>
If, for instance, I get a typical value is 60-80 concurrent sessions for a specific server (our mail server), what max session count would you use to build a classified DoS object? I understand that every situation is different, just looking for a starting point.
Maybe I'm looking at this wrong, does the total session count even matter in setting this up, since the classified DoS policy counts sessions for every source IP?
I'm trying to think in which scenario a single source IP would (legitimately) open multiple sessions...
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!