There isn't much in the way of on-box reporting.
If I needed to look, I would use the audit viewer option and select either "Virus" or "Virus Severe" from the list of audits provided.
One of the McAfee guys might be able to come up with ACAT command for you, but KB61405 is the knowledgebase article to look at regarding this subject.
If you are running McAfee ePolicy Orchestrator in your organisation you may find that by linking your MFE appliance to ePO you will get better reporting.
I am only aware of Eicar.org myself and any other site providing test samples are only providing you with copies of the same file.
If the system is detecting Eicar and the signatures are up to date then it should detect other viruses.
Remember that virus detection is configured as an application defense and this is then assigned to the rule. So if you feel that the system is not detecting malware I would check to make sure that the traffic isn't passing through a rule which is using an application defense with no AV enabled.
Hi again Phil.
The AV scanning is working fine, eicar test is detected and blocked.
The question is the GTI configuration.
We´ve got the GTI reputation boundaries set on their default values:
- Low risk = -255 to 14
- Unverified = 15 to 29
- Medium = 30 to 49
- High Risk = 50 to 255
It´s clear that with these values most of the requests are going to be "High Risk", and that´s what is happening.
We´ve got three AV scanning rules:
- Low: GTI host reputation is set to "Low"
- Medium: GTI host reputation is set to "Unverified and below"
- High: GTI host reputation is set to "Medium and below"
Most of our requests are matching in the most strict AV scanning rule, as it should be.
We´ve got the feeling that there is a point in which the firewall can´t manage all that huge volume of requests and the web browsing begins to slow down.
So, are these GTI reputation boundary values really fine adjusted?
Thanks in advance for your time and help.
GTI can be an 'interesting' subject and I have encountered some variable results on my travels.
When running your tests it is work looking at the audit viewer (filter it down to a single client IP to make life easier) and take a look at the GTI scores being reported for the sites you are testing. I had one customer who wanted to use GTI in his rules but they didn't seem to be triggering reliably. What we discovered from the audit was that all of his tests were coming back with the same GTI score and this happened to be the default score assigned when GTI is not available. So, for whatever reason, his Firewall was seeming not able to query GTI. The problem seemed to go away of its own accord and all of a sudden he started getting live GTI scores.
Also he started off creating specific allow rules and then configuring GTI to only include Low and Unverified and this also seemed to be very variable when it came to accurately controlling access. He also found it difficult to diagnose as sites not matching his chosed 'allow' GTI categories would simply fall through to the Deny All rule and he didn't always associate the corresponding audit record with GTI.
However, he then changed his tactic, disabled GTI completely in his allow rule and instead created an explicit deny rule (which he placed immediately before the allow) with the GTI categories High & Medium selected. The overall accuracy not only seemed to be better (whether this was psycological or not, I don't know), but more importantly to him, when he looked at the audit he found it easier to read because his deny actions were explicitly logged against that rule, rather than Deny All.
I know this doesn't help and you may need to log a service ticket so that someone from tech support can help you analyse whether your appliance is having difficultly communicating the GTI and find out why.