I wanted to test detection of vulnerability 36815 on inbound traffic to the GlobalProtect portal. I'd received an email from PAN on 10/20 which suggested signature 36815 could be used to block attempted SSL 3.0 sessions including "GlobalProtect SSL VPN". I'll settle for detecting it, which should happen with the default or strict vulnerability protection policy.
So I tried creating a security policy that explicitly allows SSL to the ip address of the GP portal, with a profile that applies strict vulnerability protection.
Now if I run the tool at https://www.ssllabs.com/ssltest I can see the traffic in the monitor and I can verify that the rule matches the policy I created. But the test for SSLv3 by Qualys doesn't show up in the threat monitor.
SSLv3 vulnerability is covered in latest content. It should detect if rule has anti-vuln profile configured.
Refer following thread for more detail.
Yes, if I enable, say, the strict vulnerability protection policy on outbound connections, the SSLv3 alert will fire when I access https://www.poodletest.com/ from my workstation inside the LAN.
If I point the tool mentioned above at my GlobalProtect portal, I agree that it should detect SSLv3. But it doesn't, even though the traffic is logged due to the security policy for ssl traffic to the GlobalProtect portal.
I think firewall is not on latest content, please provide me output for
1. Show system info
> show system info
time: Mon Oct 27 16:25:33 2014
uptime: 32 days, 0:14:15
app-release-date: 2014/10/23 09:15:45
av-release-date: 2014/10/24 04:00:01
threat-release-date: 2014/10/23 09:15:45
wildfire-release-date: 2014/10/26 06:29:02
global-protect-datafile-release-date: 2014/10/27 07:51:58
The Vulnerability signature which is provided will not be applied to traffic destined to firewall
For example: people from DMZ are tried to manage firewall on firewall's DMZ interface, the signature will not be enough to identify ssl3, because content inspection is not applied when traffic is destined to firewall and not passing through the firewall. The same will apply to GP. we would not be able to identify this when SSL connection terminates on untrust interface of firewall
The work around while we wait for engineering is to host the GP on loopback. Because when the service is hosted on loopback (different zone). This will make packet pass though the CTD engine of firewall to detect vulnerability.
I have tested this before in the lab that vulnerability profile applied to traffic destined to firewall does work for management but not GP (even if is on a loopback in a different zone).
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!