Eicar Testvirus will not be recognized

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Eicar Testvirus will not be recognized

L3 Networker

On the website EICAT TESTVIRUS resides a lot of different kinds of eicar. Most of them will not be recognized by the Palo Alto Networks AV-Engine. The behaviour of the firewall is thereby a bit confusing. It seems: if you click on the links more then one time, you can download the virus on the second or third instance. Especially the PDF-Eicar often downloads on the second click.

We are driving PAN OS 4.0.7

greets

Manfred

1 accepted solution

Accepted Solutions

Hi sec sec,

our working firewall is a bit more used

Device is up          : 0 day 13 hours 47 mins 18 sec

Packet rate           : 4144/s

Throughput            : 20701 Kbps

Total active sessions : 7915

Active TCP sessions   : 7104

Active UDP sessions   : 781

Active ICMP sessions  : 16

Our block page is customized, but in a very simple way.

I suspect that there is a performance problem by blocking "dangerous" content. If the firewall dont has the time to block the first bytes, it will block in the course of the http session (which could be build by more than one tcp sessions). And so, a small part of the pdf file will reach the client, leading to an error message of the browser plugin. Assuming that the firewall cannot buffer a lot of bytes, it seems to be possible that the firewall recognize dangerous content after starting to deliver the content. But then it would be imho more correct to sending the block page instead of simply blocking the further content.

Anyway, since we upgraded to 4.1.7, the problem seems to be mitigated or dead. I will continue with testing during the next days.

regards

Manfred

View solution in original post

5 REPLIES 5

L3 Networker

Hi Manfred,

I'd like to understand the test setup a little more.  Anything the firewall blocks should be blocked consistently.  If you are using a browser, it is possible that the browser is caching data and reserving it to you.  Are you using a block action or a continue action in your AV profile?  Which ones specifically are you seeing this behavior with, and can you describe the sequence of actions in detail?

Hi tettema,

... Anything the firewall blocks should be blocked consistently. ..

Hope so. But apparently this happens not in all cases.

If you are using a browser, it is possible that the browser is caching data and reserving it to you. 

I used a browser, but the "pdf"-file was surely not in the browsercache.

Are you using a block action or a continue action in your AV profile?  Which ones specifically are you seeing this behavior with, and can you describe the sequence of actions in detail?

Please take a look at our AV-profile. There is no "continue".

av1.jpg

Sorry, there is no more detail. I simply clicking on the pdf link  http://www.faerber.fidelitas.de/virtst/eicar.pdf and see sometimes my firewall warning "blocking a dangerous site", and some other times "Fehler beim Laden des PDF-Dokumentes" (english translation: "Error while loading the PDF file"), because it is not really a pdf file.

regards

Manfred

Manfred,

I tried that link on one of our PAN 500 running version: 4.0.3

Application version319-1453 (2012/07/17)
Threat version319-1453 (2012/07/17)
Antivirus version812-1116 (2012/08/09)
URL Filtering version3922

And it's working fine every time, have you setup any custom warning pages or are they out of the box default? Looks like a bug to me if the config is 100%.

The tested config is running a very simple rulebase (small) and it's only using below throughput and CPU/Mem at the time of testing. The segment if going through a VWire.

MGM CPU: 7%

Data Plane CPU: 5%
Device is up          : 139 days 11 hours 20 mins 52 sec

Packet rate           : 295/s

Throughput            : 1434 Kbps

Total active sessions : 358

Active TCP sessions   : 323

Active UDP sessions   : 35

Active ICMP sessions  : 0

Out of interest is this blocked on the way back from the download point or when the client tries to access the pdf?

Hi sec sec,

our working firewall is a bit more used

Device is up          : 0 day 13 hours 47 mins 18 sec

Packet rate           : 4144/s

Throughput            : 20701 Kbps

Total active sessions : 7915

Active TCP sessions   : 7104

Active UDP sessions   : 781

Active ICMP sessions  : 16

Our block page is customized, but in a very simple way.

I suspect that there is a performance problem by blocking "dangerous" content. If the firewall dont has the time to block the first bytes, it will block in the course of the http session (which could be build by more than one tcp sessions). And so, a small part of the pdf file will reach the client, leading to an error message of the browser plugin. Assuming that the firewall cannot buffer a lot of bytes, it seems to be possible that the firewall recognize dangerous content after starting to deliver the content. But then it would be imho more correct to sending the block page instead of simply blocking the further content.

Anyway, since we upgraded to 4.1.7, the problem seems to be mitigated or dead. I will continue with testing during the next days.

regards

Manfred

I have noticed the same behaviour on 2050 and older PANOS (pre 4.1).

Sometimes the bad packet was let through with a following rst which depending on browser could mean that the browser would render whatever it got so far (internet explorer did this of course 😃

Also you should verify so you have ssl termination activated otherwise the https downloads will bypass your PA's AV/IPS functions.

  • 1 accepted solution
  • 8367 Views
  • 5 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!