Wildfire submission

[tinhnho]

Hi Guys,

how does Wildfire logs work?

Thanks.

[BPry]

@tinhnho,

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. 

[tinhnho]

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? 

Thanks.

[BPry]

@tinhnho,

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.