antivirus feature on https

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

antivirus feature on https

Not applicable

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.

1 accepted solution

Accepted Solutions

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)).

View solution in original post

15 REPLIES 15

L3 Networker

Hi,

You will have to configure ssl decryption for this.

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

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)).

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 ?

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)?

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.

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

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).

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.

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

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.

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

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....

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).

  • 1 accepted solution
  • 6565 Views
  • 15 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!