Coordinated global attack against Checkpoint VPN?

[Juergen_Blumens]

Hello colleagues,

We have been experiencing a massive distributed attack against our Endpoint VPN access over the last few weeks. Login attempts are being made from various source IP addresses. Even known usernames are being used. caseyb describes this attack here https://community.checkpoint.com/t5/General-Topics/R81-20-Jumbo-Hotfix-Accumulator-take-96-has-been-..., which I also see here.

Unfortunately, the technical defense measures are limited, as the attacker tries different user accounts from one IP. We need a solution that blocks failed login attempts with different user accounts from the same IP.

Question to the community: Do you also see failed login attempts in your logs, for example from the IP 138.124.184.205?

Greetings
Juergen

[G_W_Albrecht]

What about using certificate authentication ? Username/PW is rather very old-fashioned...

[Juergen_Blumens]

No, we had that in the past. The administrative effort is too high. Security also depends on how passwords are composed.

[G_W_Albrecht]

I see.

[CaseyB]

We have not really explored certificate authentication for the Endpoint VPN, I would like to imagine administrative overhead issues with that as well, but I could be mistaken.

We do have MFA on the VPN, so I'm not as concerned.

[Wolfgang]

@Juergen_Blumens how about using SmartEvent ? You can define as an example an action to block the source IP for the next hour.

[Chillyjim]

This is absolutely the right way, though I would lower the number of events and time period in your case. In the automatic reactions section you can block the connections for a time period. The SmartEvent server will then issue a SAM (suspicious activity monitor) block for that time period to all of your gateways. SAM blocks happen before any other inspection (packet sanity checks might occur before, I don't remember.)

[the_rock]

If you know the IP does not change, I would use SAM rule to block it, its instant and you dont even need to install policy.

Andy

[Juergen_Blumens]

The problem is that it is a distributed attack from around 60 different IP addresses that are distributed worldwide. It's not easy to detect the attacker in the logs at first, then I have to configure the drop afterwards. Until then, the attacker comes from other IPs. That's why I want to request the new feature from sk182087 not only on a user-specific basis, but also to block the Source IP in the event of several unsuccessful login attempts within a short period of time.

At first I thought this was just an attack against us, but after CaseyB's screenshot I can see that the same attacker is trying it on other Checkpoint firewalls at the same time. Can you take a look on your logs, do you also see failed login attempts from the IP 138.124.184.205?

[the_rock]

I understand what you mean. Just checked, dont see anything for that IP for the last year.

Andy

[PhoneBoy]

Based on https://support.checkpoint.com/results/sk/sk182087 this behavior is by design.
Specifically: "The main motivation behind not to remember only a public IP address is to avoid collective DoS attacks that might block multiple Remote Access VPN users, who may connect from behind the same NAT device."

[Juergen_Blumens]

You're right about that. However, it should still be possible to select for incorrect login attempts within a narrowly defined period. Real users do not have so many failed attempts.

[the_rock]

Hey @Juergen_Blumens 

Just curious, does this involve IPs from different countries? Because if so, maybe you can try do geo blocking by using updatable objects.

Andy

[Juergen_Blumens]

Our users are spread all over the world. Even if we exclude countries without our own branch, we could still have travelers there.
The attack against us used dozens of source IP addresses. And they came from several countries. Even large countries were involved.

[the_rock]

That really makes it tough then 😞

[PhoneBoy]

Seems a reasonable ask...I'll ask R&D about it.
It might also be worth a TAC case.

[CaseyB]

While I understand the concern, it would be ideal to have the flexibility to just block the IP with multiple failed logins. I would be curious to know the statistics behind that concern, for our end-users, they would have a better chance at winning the lottery than connecting from a network that is also performing a DoS attack against our firewall. I feel like other organizations are in the same boat.

[Lesley]

Use this filter to quickly see failed login attempts in the logs:

login NOT blade:"Identity Awareness"  AND action:"Failed Log In"

+ uploaded template that you can import in Smartview, it will give an overview of failed logins. 

You can change it and also add for example source IP colum, etc. 

Unpack the zip and import the file!