- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Traffic to port 500 is accepted by implied rul...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To confirm is the destination currently used to terminate VPNs?
(This may alter the suggestions provided)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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.
Exclusively at CPX 2025 Las Vegas Tuesday Feb 25th @ 1:00pm
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Exclusively at CPX 2025 Las Vegas Tuesday Feb 25th @ 1:00pm
![](/skins/images/84DAB6BD358ECB13CE1094473F6E2961/responsive_peak/images/icon_anonymous_message.png)