- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
01-05-2012 02:56 AM
Hi all, i'm currently testing some features of our PA-500, i've activated the antivirus policies and going on eicar i can see it blocks the download of the file, when i try to download from https the download proceed. How i can check and block antivirus threat over https session?
The version of os is 4.1 and i've done all features update.
Thanks to all.
01-08-2012 09:03 AM
Check the SSL Decryption technote: https://support.paloaltonetworks.com/index.php?option=com_pan&task=dl_tech_doc&filename=SSL-Decrypti...
What you do is basically:
1) Create a new CA (as a test this can be done with openssl) - set expiration for 10 years or so (if you set for example 1 year you would need to redo this work once a year so its up to any ceritifcation policies at your workplace which expiration times are allowed).
2) Import this CA cert to your PA device.
3) Setup decryption policy in your PA device (for example if you only want to inspect SSL traffic your clients have towards Internet but not towards your own DMZ).
4) Import the public key of the CA into your clients.
The last part is only to make this transparent for the clients - otherwise they will get an warning in their webbrowser that the cert used by the site the client is visiting isnt "trusted". Of course the client could just allow it anyway or for that matter install the cert to avoid get a warning next time - but PA will on the fly generate a new "MITM" cert next time the client visits the particular url.
A good way to test if your SSL-termination is setup correctly is to visit and download the eicar testfile from (both http and https options are available along with .exe and .txt): http://www.eicar.org/85-0-Download.html (for more information: http://www.eicar.org/86-0-Intended-use.html).
Edit: Point 2 above is the private (and public if im not mistaken) key of the CA.
That is because the PA will on the fly generate a new "faked" (MITM - Man In The Middle) cert using this CA cert before sending the traffic to the client (who if point 4 above is done will not notice that its being inspected (unless the client manually inspect the cert received and will notice that the issuer is changed and that the fingerprint (compared to the original cert) doesnt match (if the visited site have published their fingerprints online or if the client some other way knows what the correct fingerprint is)).
01-05-2012 04:56 AM
Hi,
You will have to configure ssl decryption for this.
01-05-2012 05:29 AM
how exacly? Can you be more explicit in your explaination? I have done a Decrypt policy but it seem not working so i suppose i'm doing it wrong.
Thanks
01-08-2012 09:03 AM
Check the SSL Decryption technote: https://support.paloaltonetworks.com/index.php?option=com_pan&task=dl_tech_doc&filename=SSL-Decrypti...
What you do is basically:
1) Create a new CA (as a test this can be done with openssl) - set expiration for 10 years or so (if you set for example 1 year you would need to redo this work once a year so its up to any ceritifcation policies at your workplace which expiration times are allowed).
2) Import this CA cert to your PA device.
3) Setup decryption policy in your PA device (for example if you only want to inspect SSL traffic your clients have towards Internet but not towards your own DMZ).
4) Import the public key of the CA into your clients.
The last part is only to make this transparent for the clients - otherwise they will get an warning in their webbrowser that the cert used by the site the client is visiting isnt "trusted". Of course the client could just allow it anyway or for that matter install the cert to avoid get a warning next time - but PA will on the fly generate a new "MITM" cert next time the client visits the particular url.
A good way to test if your SSL-termination is setup correctly is to visit and download the eicar testfile from (both http and https options are available along with .exe and .txt): http://www.eicar.org/85-0-Download.html (for more information: http://www.eicar.org/86-0-Intended-use.html).
Edit: Point 2 above is the private (and public if im not mistaken) key of the CA.
That is because the PA will on the fly generate a new "faked" (MITM - Man In The Middle) cert using this CA cert before sending the traffic to the client (who if point 4 above is done will not notice that its being inspected (unless the client manually inspect the cert received and will notice that the issuer is changed and that the fingerprint (compared to the original cert) doesnt match (if the visited site have published their fingerprints online or if the client some other way knows what the correct fingerprint is)).
01-10-2012 12:37 PM
Hi i have generated the certificate directly from Paloalto, the problem was that the name of certificate. We have ricreate the certificate with name the ip address of appliance and now it seem's to be working better. Now using the eicar download test, trying to download a file in http i see a blocked response web page, and in https it remain in working and remain in cycling. It doesn't display the response page but don't proceed to download of the file. Have you seen the same behavior ?
01-10-2012 02:15 PM
Visit the url in question and verify that your MITM-cert was being used (check the "issued by" stuff when you click on the cert on clientside - it should read the name you gave the cert (issuer) instead of Verisign or whatever the EICAR-site uses).
Also verify in your decoding policy that you decode for all url-categories (the above will verify if you have set this up correctly).
I have sometimes noticed that occationally the PA unit will let bad code pass, dunno why as I have not yet setup a testcase for this or even did a tcpdump so see what actually happens - the result was anyway that I got open the EICAR.txt over https instead of getting the blocked virus page.
One theory is that the PA unit will send the TCP-RST (or whatever) just after the first packet passes as with EICAR the EICAR teststring will fit in a single packet. Then based on which browser is being used the browser will try to display whatever it got instead of displaying the block (well antivirus) page generated by the PA.
Anyone else who have noticied this behaviour (or now if this have been addressed in 4.x series - I think the box in question is a PA-2050 running either 3.0 or 3.1)?
01-12-2012 03:10 AM
In My cases, the download from https was blocked only i don't see the response page as in http, i've tested with facebook and a lot of other app and the decrypt policies work.
02-06-2012 10:51 AM
Hi - did you get a fix for this?
I have the same issue. SSL decryption def works, but when trying to display anything other than the requested page (App/Virus block, Continue page etc, I just get a timeout in the browser).
Ta
02-07-2012 12:05 AM
Whats your settings of ssl-decrypt along with decryption?
You need to choose "trusted root CA" along with "forward-untrust-certificate" and "forward-trust-certificate" if im not mistaken.
Then in decryption you can set it up as:
Name: SSL-termination
Category: any
Type: ssl-forward-proxy
from: any
to: any
source: any
destination: any
source-user: any
block-if-failed-to-decrypt: yes
negate-source: no
negate-destination: no
action: decrypt
In from/to/source/destination you will limit for which flows it should step in and do the MITM stuff. It can for example be wise to use client-iprange as source in your case.
Then regarding current VSYS you can setup:
allow-forward-decrypted-content: yes
You can upload customized block pages but I think you can in the GUI go back to the factory default.
Also verify that you in the antivirusprofile for this particular rule have setup so "http" is set to "block" (I think this is in the defaultprofile already).
02-07-2012 12:09 AM
For the app, i ve no problem in http or https, example facebook, facebook app or other, but for antivirus features when i try to download the eicar test file in http i see the block page, and in https i see the timeout as you. No news.
02-08-2012 01:39 AM
I have exactly the same problem. I have configured two ssl forwarding certs (a trusted and a unstrusted cert) and imported both certs into my browsers "Trusted Root Cert. Authorities". Configured the ssl decryption policy and tested a few ssl sites with valid and invalid (self signed) certs. All worked as expected except the Eicar tesfiles with ssl. I can see the block in the Threat log, but no response page being displayed in the browser, just sitting there until it times out.
We are running 4.1.2 in Vwire mode
Any ideas ? Bug ? At least the problem seems to be reproducible
rgds Roland
02-08-2012 05:53 AM
Differently from Cisco support Forum, it seem's frequented more from customer who helps each other, and less from Palo Alto Networks tech support. So maybe must be opened a case and after that report on this discusion the solution of the case.
02-08-2012 10:31 AM
Hi - I've found a fix for my issue, hopefully it'll fix yours too.
Basically, my rule matching this traffic was set to 'Application Default' service type and, for whatever reason, the block page traffic was being detected as 'web-browsing' on TCP port 443.
By changing the the rule to web-service ports (80,8080,443) - or whatever is required to match the expected apps on that rule - I now get block pages for both HTTP and HTTPS.
Cheers
02-08-2012 11:04 AM
Ok, that's interesting, I have to try this one tomorrow. Although I doubt this should be like that by design. I remember when I played with the ssl decrypt feature a while ago with a 3.x release when I didn't have to specify any ports in the security policy to get the response pages for ssl working.
Actually my test rulebase is pretty straight forward, (vwire) allow everything inside to outside (internet), any application on any port and applied the security profiles like AV/IPS on top of that.
Anyway it might be time to open up a trouble ticket for this one....
02-09-2012 12:22 AM
Sounds like a good reason to open a supportcase for this 🙂
I have been behind a 3.x device and there both http and https block/continuepages works so it seems like a bug introduced in 4.x or something that (or in combination with updated appid-db).
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!