Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
BlueGrass
Contributor

Will CheckPoint Firewall AV Blade Block Eicar?

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?

0 Kudos
11 Replies
PhoneBoy
Admin
Admin

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.
0 Kudos
HristoGrigorov

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

0 Kudos
jbfixurpc
Participant

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!

0 Kudos
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
jbfixurpc
Participant

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!

 

0 Kudos
Wolfgang
Authority
Authority

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

eicar.png

Wolfgang

jbfixurpc
Participant

Thanks! Perhaps this will do the trick!

0 Kudos
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
Participant

Agreed. Totally makes sense, thanks for the explanation appreciate it!
0 Kudos
Timothy_Hall
Champion
Champion

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.

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events