- CheckMates
- :
- Products
- :
- General Topics
- :
- Criteria in the security rules
- 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
Criteria in the security rules
Hello, world.
This question, maybe it is very "silly", but I want to understand more about the operation of the Checkpoint Firewall.
My doubt is based on the security rules that are created in the SmartConsole.
For example, an administrator defines a security rule:
Source: 192.168.50.64
Destination: 172.17.20.30
HTTP Service
Action: Allow(Accept)
In other manufacturers such as Fortinet, Palo Alto (to name a few brands), in their rules, they usually "call" either the interface or zone, where the traffic arrives and leaves, but in Checkpoint this is not usually common (at least in my experience, I mean, when working security policies based on zones).
So, when an administrator defines a rule, as I put it above, like Checkpoint, he "identifies" the origin where the packet will enter and where it will be taken out????
Is there a flow to understand this?
I hope you can understand my doubt, and help to clarify it.
Thank you.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes we have different approaches to many things not least of which is our fundamental ethos.
Zones can be defined as part of the interface topology in all current software releases of GAiA and subsequently referenced in the security policy rules src/dst but this wasn't always the case. They are often used in parent rules for layers.
Refer also:
https://support.checkpoint.com/results/sk/sk128572
https://community.checkpoint.com/t5/General-Topics/White-Paper-Security-Zones/td-p/53415#M10641
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes we have different approaches to many things not least of which is our fundamental ethos.
Zones can be defined as part of the interface topology in all current software releases of GAiA and subsequently referenced in the security policy rules src/dst but this wasn't always the case. They are often used in parent rules for layers.
Refer also:
https://support.checkpoint.com/results/sk/sk128572
https://community.checkpoint.com/t5/General-Topics/White-Paper-Security-Zones/td-p/53415#M10641
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey bro,
I think what you defined specifically applies to PAN and Fortinet, for sure. They have an easy way to define zones, unlike CP. But, regardless of that, layers in CP starting R80 give you an amazing option for policy hardening, compared to R77 and before.
Links @Chris_Atkinson sent are good reference.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To add to my last response, I guess you could technically compare say if you have inline layer on CP with internal zone (tied to internal interface) to something like internal to WAN section on Fortigate firewall. Maybe not the best comparison, but somewhat similar. On FGT firewalls, once you create a rule from, just as an example, ssl vpn interface to say internal, that would represent what vpn clients can access when they connect in. That could, I guess, compare to say inline layer on CP firewall.
Makes sense?
Andy