- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-14-2012 08:08 AM
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
08-15-2012 02:41 AM
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
08-14-2012 01:11 PM
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?
08-14-2012 01:31 PM
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".
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
08-15-2012 12:31 AM
Manfred,
I tried that link on one of our PAN 500 running version: 4.0.3
Application version | 319-1453 (2012/07/17) | |
Threat version | 319-1453 (2012/07/17) | |
Antivirus version | 812-1116 (2012/08/09) | |
URL Filtering version | 3922 |
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?
08-15-2012 02:41 AM
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
08-20-2012 03:58 PM
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.
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!