Wildfire submission

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

Wildfire submission

L2 Linker

Hi Guys,


how does Wildfire logs work?




Cyber Elite
Cyber Elite


It was likely a post identification. So the traffic was allowed and the sample submitted for evaluation, and only then did it come back as phishing. It'll be logged as phishing with the action of allow because the firewall didn't have the verdict prior to the sample submission, so it allowed the download. 

Thank you!

Since it’s valid/normal process of Wildfire, what would happen if the NGFW sees the same file (phishing) again? I meant what actions would FW take? is it under Logs-Threat if I need to check its log? 


Under Objects- security profile - antivirus profile, there is a profile which I created for antivirus, under Action of the profile there is  'Wildfire Signature Action' tab where i can allow, alert, block…etc for protocols http, pop3, http2…etc, as of now all of them set ‘allow’, what do they mean 'allow' to Wildfire? do I need to set all of them block or drop instead? 







Cyber Elite
Cyber Elite


Okay in that case, forget what I said above. You can have a verdict of malicious as an example on allowed traffic due to delayed authentication of a submission, in a standard deployment that is the only time you'd expect to see an action of allow with a non-benign verdict. In this scenario, subsequent identifications of the file would be blocked because the firewall can identify the file as malicious in flight without having to submit it for analysis.


Now in your scenario you've modified the default actions on http/http2/ftp/smb decoders to be set to 'alert'. By default, only smtp/imap/pop3 would ever have an alert action. These decoders are set to alert because it's presumed that you have a spam gateway that can better deal with these identifications (because it can quarantine them instead of just dropping the traffic). 

You'd absolutely want to have your profile on at least untrust traffic to be set as the default 'reset-both' actions on all non-email (smtp, pop3, imap) decoders. So SMB, http, http2, ftp should all absolutely be setup as the default action (reset-both) unless you've identified a good reason to have these set to allow. Otherwise you aren't taking advantage of WildFire's ability to identify these files at all. 


Whether or not you reset email traffic (those smtp, pop3, imap decoders) is debatable. Again, the default action is set to alert with the assumption that you have a spam gateway already filtering your traffic. If that isn't the case, I'd argue that you should also be resetting this traffic so that you have at least some defense. 

I'd argue that even in an environment with a spam gateway the only profile that shouldn't have all wildfire actions set to reset the traffic should be the profiles controlling traffic from/to the spam gateway. This ensures that all untrust traffic from clients is dropped if something malicious is identified. 

  • 3 replies
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!