PA File Detection seems not working right

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.

PA File Detection seems not working right

L3 Networker

PA claims to detect several DOS and Windows executable filetypes. The following filetypes are partially not really executables, but i am wondering that PA ignores (do not show any log) the types totally. (Nevertheless some of the filetypes are potentially really harmfull).

I found the following behaviour of our Palo Alto Firewall (we tested with mail-attachements)

FiletypePalo Alto Detection
tlbno detection
sysno detection
wscno detection
binno detection
vxdno detection
exeok
scfno detection
cmddetection only with file ending ".cmd"
drvok
comok
cplok
vbsno detection
scrok
dllok
ocxok
regno detection
1 accepted solution

Accepted Solutions

Hi Manfred,

Apologies for the delay.  As it turns out, you are correct - our .cmd signature is based on file extension only, as there was no other way for us to create one based on other patterns.  As for your issues with .reg files, these should be detected properly.  Can you comment on what content and PAN-OS version you're using?

--Doris

View solution in original post

9 REPLIES 9

L5 Sessionator

Hello,

I'm assuming you're referring to the file types that we can block via file filtering, correct?  You can find the full list of supported file type signatures here:

https://live.paloaltonetworks.com/docs/DOC-1783

If there is a file type that you'd like to see added, please contact your SE and have them file an enhancement.

Thanks,

Doris

Hi Doris,

PA explicitely declares that they are able to detect the file type "sys" or "reg". But it does not detect this file types, if they are in a mail attachment. Additionally, it should be possible to detect filetypes like "vxd", if PA tries to keep their customer free from potentially harmfull files. Third, it is not a good work, if the PA detects the file type "cmd" only, if the file name ends with ".cmd".

regards

Manfred

Possibly it would be better to log all the unknown files as "unknown files" than to conceal it.

Hi Manfred,

When attempting to detect .sys and .reg files in a mail attachment, did you also have an SSL policy setup to decrypt the traffic?  Or are you testing all file types in the same manner and only .sys and .reg files were not being properly detected?

Generally speaking, our file signatures are based on the unique characteristics of each file, not just on the file extension itself.  If you're experiencing an issue with .cmd files, please open a support case so we can investigate further.

--Doris

Hi Doris,

we tested all the mail attachements with one rule. So in this kind of "file blocking" rule, all executables (so called PE files in PA speek = PE -Microsoft Windows Portable Executable (exe, dll, com, scr, ocx, cpl, sys, drv, tlb)) should be detected. The mails were not encrypted, least of all not with SSL. The communication port was tcp 25 = normal emailexchange between a german freemailer and our mailserver. PA detects correctly the application "smtp" in this data exchange. Exe, dll, com, scr, ocx, cpl, drv were detected correctly, sys and tlb were not detected.

The relating rule simple says: alert all data files - please look at the attached gif. So a reg or a cmd file should be detected too. But the reg files was detected never, and the cmd file was only detected, if the filename ends with "*.cmd".

What makes me very unhappy is, that there is no file logging, although we haved attached some files at an email. In my humble opinion is an attachement very easy to detect, so why did i got no log entry?

The PA art of security seems not to be sufficiently in another point of email communication. If i send an email with javascript in his data body, there is no method in PA to detect and block this code (i tried several data patterns in file blocking or data filtering rules and self designed applications or vulnerabilities). Other security engines like mcafee/webwasher or finjan are able to block such code.  

Manfred

Hi Manfred,

Apologies for the delay.  As it turns out, you are correct - our .cmd signature is based on file extension only, as there was no other way for us to create one based on other patterns.  As for your issues with .reg files, these should be detected properly.  Can you comment on what content and PAN-OS version you're using?

--Doris

Hi Doris,

we are updating our PAN application knowledgecontent allways shortly after it will be delivered. So the phenome occurs on all content, i guess (if i do understand your question correctly). Our OS is 3.1.8 and will be updated to 4.0.3 next week.

ciao

Manni

Thanks for your continued patience, Manni.  I'll see what I can find.  Smiley Happy

Manni,

There shouldn't be a problem with 3.1.8.  Can you open a support ticket and include a PCAP and/or a sample of the file in question so we can take a closer look?

--Doris

  • 1 accepted solution
  • 5039 Views
  • 9 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!