Anti-bot block page does not show up

[the_rock]

Hey guys,

I hope someone can maybe shed some light into this as to what we might be missing to get this working. I had been working with couple of my colleagues on it and we cant seem to figure it out.

Here is the environment:

R81.20 jumbo 89 mgmt server

R81.20 cluster with anti bot enabled, along with vpn, fw, monitoring, ssl inspection

another R81.20 gw, as well as SE dedicated server, all jumbo 89 (cluster as well)

Now, ssl inspection block page works fine, no issues. We enabled AB blade, made sure shows default block poage as option in TP profile, page we tested does NOT show up, but, block page NEVER comes up. I tested with different dns servers, no joy. Even followed below link, same issue.

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_ThreatPrevention_AdminGuide/Topics...TPG/Configuring-Anti-Bot-Settings.htm

I see in one of the logs below sk comes up, but not sure if thats relevant here.

https://support.checkpoint.com/results/sk/sk74060

For what its worth, same issue happens regardless if IPS blade is enabled or not.

I attached some screenshots of the environment. Any suggestions are always welcome.

Thanks in advance.

Andy

Screenshot_1.png

 

Screenshot_2.png

Screenshot_3.png

 

 

Screenshot_4.png

[the_rock]

Quick update...my colleague and I even enabled AV blade, tested with eicar download test link, but IE blocks the download, NOT av blade, so block page does not work for that either.

I have a feeling we are missing something trivial here, just cant figure out what exactly.

Andy

[_Val_]

Like HTTPS Inspection enabled?

[the_rock]

Nope, thats been enabled for some time actually.

Andy

[the_rock]

Btw, @_Val_ , though we have ssl inspection enabled in the lab, we were told by one of SEs that technically, you do not need that feature turned on to be able to effectively use AB? Is that true?

Andy

[_Val_]

This is a very inaccurate statement. 

For URLF, HTTPSi lite might do, but if you are planning to scan files delivered over HTTPS, inspection is a must. Also, if you want a warning page redirect on any TLS traffic, you cannot do that without the inspection active.

it might be, you misunderstood what he/she said, or took it out of context.  

[the_rock]

Thank you. That was sort of my understanding as well. Well, they said it could technically work, but were not 100% sure about block page being displayed without ssl inspection enabled.

Either way, let me do some more testing in the lab to try make this work, I have a gut feeling I can get it going, just have not had much time to dedicate to further testing.

Andy

[_Val_]

Any popup requires a redirection as part of the communication. You cannot insert a redirection to an encrypted traffic. Hence, HTTPSi

[the_rock]

I will do some more testing in the lab now, since I got couple of hours for it, so lets see if I can make any progress.

Andy

[the_rock]

FWIW, also tested autonomous TP policy, exact same problem.

Andy

[PhoneBoy]

I assume because of how this is being blocked (DNS Trap), we are not generating a block page, which would require an active TCP session.
The default DNS Trap IP does not answer any queries and connections would "time out." 

[the_rock]

Any way to fix that?

Andy

[PhoneBoy · Accepted solution]

Thinking about this, the answer is probably not.

For a block page to be generated, a TCP connection would have to be generated.
This would require HTTPS Inspection, which would have to generate a certificate based on the site being accessed (SNI).
The SNI verification piece would fail since there's no connection to get the site certificate.
Even if you were to change the DNS Trap IP to something that answers with an HTTPS Certificate, it would not be correct based on the site accessed.

I suspect this is RFE territory. 

[the_rock]

Thanks for the feedback, as always. I do have ssl inspection enabled, that part works and we do see logs generated that show pages blocked related to AB blade, but just cant get block page show up.

O well, thats unfortunate, but thank you for confirming!

Andy