Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Prime
Contributor
Jump to solution

Traffic to port 500 is accepted by implied rule on 0

We have observed a traffic permit from Source IP 106.75.64.59 (Blacklisted 6/114) to destination IP 202.56.229.167 on destination ports 500.
 
Observation:
 
* High no. of events to same destination IP
* Anomaly: Excessive Firewall Permit from Multiple Source
* As per the log analysis, we found there is a Firewall Permit on bharti firewall.

We have analysed the external to external traffic from source 106.75.64.59 (Blacklisted 6/114) to a single destination port.


Do we need to block the source if the communication is not legitimate?
If the source IP is legitimate, please confirm whether we can whitelist the same in our rule.

 

 

0 Kudos
1 Solution

Accepted Solutions
HeikoAnkenbrand
Champion Champion
Champion

Hi @Prime

There are some implied rules that open certain ports on a gateway.
Depending on the settings in "Global Properties > Firewall" the ports can be different.

You can find an overview of used ports here:
R80.x - Ports Used for Communication by Various Check Point Modules

 

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips

View solution in original post

7 Replies
Chris_Atkinson
Employee Employee
Employee

To confirm is the destination currently used to terminate VPNs?

(This may alter the suggestions provided)

CCSM R77/R80/ELITE
0 Kudos
Prime
Contributor
(202.56.229.167)this is our secondary firewall outside interface IP, we are not using for VPN
0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

Hi @Prime

There are some implied rules that open certain ports on a gateway.
Depending on the settings in "Global Properties > Firewall" the ports can be different.

You can find an overview of used ports here:
R80.x - Ports Used for Communication by Various Check Point Modules

 

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
Timothy_Hall
Legend Legend
Legend

All IKE UDP 500 traffic to and from the gateway interfaces themselves (this does not include IKE traffic trying to transit the gateway) will always be allowed by these implied rules:

ike_implied.png

Once allowed the source IP address will be checked against a list of known VPN peers by vpnd, and if it doesn't match the IKE traffic is discarded.  While in most cases the two endpoints for a site-to-site VPN have fixed IP addresses, all IKE traffic to the gateway's interfaces must be initially accepted from any source IP address to cover the case of a Dynamically Assigned IP (DAIP) VPN peer.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Prime
Contributor
 
0 Kudos
Prime
Contributor

is it the legitimate traffic and can we whitelist the same in our rule?

Should we block the source if the communication is not legitimate?

Attached the log

 

 

 

0 Kudos
Timothy_Hall
Legend Legend
Legend

You can't directly block UDP/TCP port 500 in the main Network/Firewall policy because it is allowed in the implied rules which are always "first"; it has to be initially allowed then later denied by vpnd as an invalid peer.  The only way to change this is to modify the implied rules settings in the Global Properties, but this is a great way to cause all kinds of nasty problems with basic firewall functionality and is NOT recommended.

I would suggest putting this attacking IP address in the SecureXL blacklist or in a SAM rule (sk112454: How to configure Rate Limiting rules for DoS Mitigation (R80.20 and newer)), which would kill the traffic before it is even able to reach the first implied rules.  Or you could simply block that entire country with Geo Policy since it is applied prior to the first implied rules.  Geo Updatable Objects are referenced after the first implied rules, so you'll need to use Geo Policy instead of Geo Updatable Objects for blocking the attacker in this specific case.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
(1)

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events