Will CheckPoint Firewall AV Blade Block Eicar?

[BlueGrass]

Hi all,

Will CheckPoint Firewall AV Blade Block Eicar?

I just enable the AV blade with Web inspection Published and Installed.

Then download the Eicar Virus Test file from only "HTTP" - Not the HTTPS.

And the file is able downloaded.

Am I doing things wrong on the CP Threat Prevention?

[PhoneBoy]

Eicar has always been kind of a special case, as you can see here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
That said, if you're not using Traditional AV and you're on R80.x, I believe it should block this, assuming you're using one of the standard Threat Prevention policies and AV blade is enabled.
Which suggests a TAC case might be in order.

[HristoGrigorov]

IPS is the blade that actually detects Eicar. Enable it and it will catch it 🙂

[jbfixurpc]

Hi

Yes, I am observing that the IPS blade does block this. The only problem I have in this scenario is that the user doesn't seem to be getting notified of this, i.e. end user gets a page simply stating www.eicar.org didn't send any data. Problem is that the users will believe there is a network connection issue or the like and not get information about the block, such as there is a problem with this download and to contact the helpdesk.

Since the IPS blade seems to pick it up, and not the anti-virus I don't seem to have a way to present a block page of any sort (ask is not an option with IPS).

Any thoughts on how to handle this? Or would this be a unique situation only liken to eicar's ?

Thanks!

[Timothy_Hall]

I don't think the IPS blade has the capability to issue a UserCheck like the other Threat Prevention blades can, and I believe IPS takes precedence over the AV blade.  I would suggest modifying the "EICAR AV test file" IPS Protection to Detect or Inactive in the TP profile your gateway is using; that should let EICAR reach the AV blade where a UserCheck can be issued.

[jbfixurpc]

Thanks for the response. This confirms what I believed was happening (IPS blade is preventing before the AV).

My only concern about this is if something outside of a known test venue (eicar.org) were to occur over a 80/443 session, that a user would have no knowledge other than to contact support in the organization about a problem with retrieving a file. I guess what I am interested in achieving is a UserCheck notification under these conditions where TP is enacted. As it stands, if I understand this correctly, there is no way for the end user to understand it is being blocked. Outside of this particular scenario (Eicar.org) potentially some other malicious site could present this and the user's perception is there is a network related issue versus a warning about protecting them from themselves. I don't fancy putting in exceptions for them on a case by case bases.

Thanks again!

[Wolfgang]

Enabling URL-filter / ApplicationControl and blocking "Spyware / malicious websites" also shows the usercheck page if downloading EICAR test file.

 

Wolfgang

[jbfixurpc]

Thanks! Perhaps this will do the trick!

[HristoGrigorov]

I don't think IPS will block any other viruses. In fact, it should not block Eicar either because that way it gives the wrong impression you have A-V protection by just enabling IPS blade which is of course not true.

So, for all other detected viruses you should actually be getting usercheck alert.

[jbfixurpc]

Agreed. Totally makes sense, thanks for the explanation appreciate it!

[Timothy_Hall]

You are right Hristo that IPS really shouldn't block EICAR as that is not really its "job", but it still has a signature for it. Allow me to explain why this is this case.

The IPS blade in its present form was introduced in R70 (it was known as "SmartDefense" in R65 and earlier) and was the original "Threat Prevention" solution.  It predated the four other Threat Prevention blades (and APCL) by many major code releases, so prior to the other four TP blades (AV, ABOT, TEmu, TExt) being introduced, IPS served some of their functions.  So that's why there were IPS signatures for EICAR (should be the job of AV), P2P file sharing protocols (which should be handled by APCL), and Gator (which should be handled by ABOT).  This functional overlap continued through version R77.30, but in version R80.10 IPS was finally integrated alongside the other TP blades in the Threat Prevention policy, and no longer had to be configured separately.  This is why if you still have R77.30 gateways using IPS being managed by an R80+ SMS, there is a separate "IPS" policy layer under Threat Prevention, as IPS must still be configured separately from the rest of TP on an R77.30 or earlier gateway. 

When IPS was "rolled up" alongside the other TP blades in the mainline Threat Prevention policies in R80.10+, Check Point took that opportunity to get rid of most of the overlaps between IPS and the other blades, and this arduous task was documented here:

sk103766: List of IPS Protections removed in R80.x

Not really sure why the EICAR signature specifically is still around in the IPS blade though.

Additionally, in R80.10 Check Point split out the IPS "Geo Protection" signature into "Geo Policy" which became a part of the Access Policy (Firewall blade essentially), other certain IPS signatures became part of the Inspection Settings (once again part of the Access Policy - Firewall Blade).  This left the IPS ThreatCloud Protections (many thousands of them) as still part of IPS Threat Prevention along with the oddball 39 "Core" IPS Protections, which kind of have one foot in Threat Prevention and the other in Inspection Settings, which leads to some unusual procedures being required to properly configure and define exceptions for them.

[HristoGrigorov]

Awesome explanation as usual, thanx.

IPS place in the whole picture is not yet quite clear to me. For example, if I block country via geo object I am expecting that the first thing it will do is to drop connections from this country right away when they arrive. Not really. I still see in the log IPS attacks from this country.  So, unless logging somehow reports wrong country I do not understand why it does that.

Then, as you mention in your book, Geo Policy will likely be dropped in future releases in favor of geo objects. One policy less to configure 😀

Inspection Settings is kind of too general name for what it does but that's just my opinion and not a real issue.

I suspect Eicar was left in IPS sdatabase as an easy way to test if IPS blade signatures work. And indeed it kind of overlaps with the one in AV database but imho the right way to test your blades nowadays is to use CheckMe service.