checkpoint firewall default deny?

Dude, the default policy that denies ANY is the same on any firewall man. It's ANY protocol and ANY port on said ANY protocol. Got ANY idea what you are doing?

In NG, each service defined in the GUI has an option labeled "Match for Any" in the advanced properties. If this property is checked, the service will be included in "Any." Services that do not have this checked will not be included in the "Any" definition.

The following is a non-exhaustive list of services in FireWall-1 4.1 and earlier that will require explicit rules with the explicit service to be allowed correctly (i.e. "any" will not allow these services) which was derived from a cursorary look at the INSPECT files inlcuded in $FWDIR/lib:

a.. FTP b.. RPC c.. sunRSH d.. REXEC e.. VDLLive f.. Real Audio g.. RTSP h.. SQL*Net2 i.. FreeTel j.. CoolTalk k.. H.323 l.. NetShow m.. Winframe n.. Backweb o.. IIOP p.. CVP q.. RTSP r.. X11 Does this answer your question?

Its a 'default deny', what do you think it does.

Like Duh.

If you've crafted the policy properly the last rule will do that for you.

greg

I assume you really meant to reply to the OP.

greg

yes it does...thank you so much....

do you know of any documentation that talks about this?

Hey Brian,

It's nice to see someone post a non-sarcastic and actually useful answer to a novice poster. Props to you!

Dani

hello,

In NG, each service defined in the GUI has an option labeled "Match for Any" in the advanced properties. If this property is checked, the service will be included in "Any." Services that do not have this checked will not be included in the "Any" definition.

The following is a non-exhaustive list of services in FireWall-1 4.1 and earlier that will require explicit rules with the explicit service to be allowed correctly (i.e. "any" will not allow these services) which was derived from a cursorary look at the INSPECT files inlcuded in $FWDIR/lib:

a.. FTP b.. RPC c.. sunRSH d.. REXEC e.. VDLLive f.. Real Audio g.. RTSP h.. SQL*Net2 i.. FreeTel j.. CoolTalk k.. H.323 l.. NetShow m.. Winframe n.. Backweb o.. IIOP p.. CVP q.. RTSP r.. X11 Does this answer your question?

True, the "any" service is a group of services which have the option "match for any" checked. The firewall howerver blocks everything by default, even thosenot in the "any" group, as you should (with any firewall) by default deny access to everything and explicitly allow services. Exception in Checkpoint are the implied rules (Policy->Global properties)

If you've crafted the policy properly the last rule will do that for you.

greg

What Greg presumably refers to is the "cleanup" rule, which should be the last rule in the rulebase. Even though Checkpoint denies access to all to begin with, it will do this silently, hence a rule is added as the last rule

any, any, any block, log so you can see what it is exactly what is being dropped for troubleshooting.

There are common guidelines for building a ruleset, i.e drop noisy traffic on external interface(i.e. NBT service group) authentication rules (firewall needs to be accessible) stealth rule (hides firewall gateway object) further rules cleanup rule.

That list is not extensive, nor is it applicable in all cases, but a general guideline.

regards dc

I'd modify that slightly, Personally I wouldnt 'stealth' the firewall on the inside interfaces. Civilised RFC behaviour w.r.t sending back RSTs and unreachables makes debugging connectivity problems a mite easier for all involved.

Good point and well said, and sadly a point most people ignore leading to troubleshooting nightmares. Better to do it properly from the outset ;)

regards dc

Short note on the "drop noisy traffic" reference above (i.e. NBT), don't log that traffic either!

Nothing worse than sorting through a log and having to change the filter criteria all the time because there is so much NBT/etc. noise going on that you can't see the results of what your testing.

However, one should really get used to setting up and using the filters in Checkpoint log viewer tools! Once you do, you will wish you had used the filters before!

Good Luck!

Smooter

Yep.

I'd modify that slightly, Personally I wouldnt 'stealth' the firewall on the inside interfaces. Civilised RFC behaviour w.r.t sending back RSTs and unreachables makes debugging connectivity problems a mite easier for all involved.

greg

A sensible measure regardless of firewall tech used, e.g

~ # cat /etc/pf-nbt.conf Ext="fxp1" RPC_NBT="{ epmap, netbios-ns, netbios-dgm, netbios-ssn, microsoft-ds }"

# Explicitly drop NBT on external interface block quick on $Ext inet proto {tcp,udp} from any to any port $RPC_NBT

is what I use here.

It's pointless logging it in the 1st place, log sizes explode if you do.

It bad enough in some environments having to logswitch hourly to handle volumes without making the problem worse.

Give CKP their due, they are in a class of their own w.r.t interactive log analysis on the fly. The tool is that quick and useful.

greg