login attacks coming in with geo protection turned on

[Daniel_Kavan]

Does MAB / sslvpn not fall under the umbrella of geo protection?

I'm seeing DoS login failed attacks coming in from countries even though geo protection should be dropping them (NOT accept).  However I see Accept.   Maybe, sometimes the IPs don't fall under the right countries?

Also, I was looking for away to white list networks hitting sslvpn but I'm not seeing that as an option.

[Tal_Paz-Fridman]

It probably used implied rules that are matched before the other rules in the policy.

[Lesley]

Hi,

Traffic is allowed on implied rule. You can disable implied rules, then you can first make a drop rule with geo protection and then allow the rest. 

[Daniel_Kavan]

The only Implied rule I see in global properties that looks relevant is: 

Remote Access Control Connections

Is that https traffic to the MAB portal?

[the_rock]

Im thinking MAB.

[PhoneBoy]

Believe so, yes.
Are you using legacy Geo Protection or doing this in a policy layer?

[Daniel_Kavan · Accepted solution]

Ah, that may be the issue.  Yeah, legacy.   We are switching to a unified policy soon, but right now it's a separate policy in MAB.  Actually, we do have a test gw with unified, does anyone see documentation RE: add a source geo location in the src column?   I don't see anythin the R81.20 admin guide or TP guide for geo location objects.  Ah, I found it sk126172 - Configuring Geo Policy using Updatable Objects  

thank you - the dos mitigation rules are working.

[Daniel_Kavan]

Do you think a geo location rule in the access policy will block attacks to sslvpn when using legacy vpn (not unified policy)?

[PhoneBoy · Accepted solution]

No, but you can do it with Dos Mitigation rules, which can be geo-specific (not in R82 currently) and will apply before implied rules.
https://support.checkpoint.com/results/sk/sk112454 

[Daniel_Kavan]

has anyone done it before to save me time?   For example, if you want to block IP address 94.154.35.24/32 with a dos mitigation rule.

I may try this one:

fwaccel dos rate add source cidr:94.154.35.24/32 https byte-rate 0

smartevent proections aren't stopping it either.  Brute force for example .

Update: the dos mitigation blocks are working.  Thank you.  Even the inline geo-location rule wasn't in my unified policy.

It's like wargames, they are trying other networks now.

[Daniel_Kavan]

Check Point came out with a fix for this in R82 and R81.20 JHF96 and it works.

BTW, I'm implementing a negation rule with US as the update-able geo protection object.  So, it should block everything that's NOT from the USA.