mailing list archives
Re: Firewall-1 Security Advisory
From: larryp () secure-it net (Larry Pingree)
Date: Tue, 27 Oct 1998 15:13:29 -0800
This is a multi-part message in MIME format.
Once you place the
Source "Any" Dest "Firewall" and service "Any" Action "Drop" rule into
place, ping should no longer work even if the "Accept ICMP" is checked under
the Policy Property settings, what this leads me to believe is that not all
ICMP is allowed by the default rule, which leads me to the
question.......What is the definition of "ICMP" in that default setting?
From: Paul Sears <Paul_Sears () NACM COM>
To: BUGTRAQ () NETSPACE ORG <BUGTRAQ () NETSPACE ORG>
Date: Monday, October 26, 1998 1:59 PM
Subject: Re: Firewall-1 Security Advisory
Diligence Risks wrote:
Diligence Security Advisory
Issue: Checkpoint's Firewall-1 has a "feature" that can allow an external
intruder to pass through the firewall and attack machines, unihibited, on
the protected side.
Details: When Firewall-1 is installed there is an implicit rule: ANY
(Source), ANY (Destination), ANY (Service) and ACTION (drop). This means,
theory, that all IP based packets, whether incoming or outgoing should be
dropped. However, Firewall-1, out of the box, allows certain "core"
protocols through - these being RIP (UDP port 520), DNS (UDP and TCP port
53) and all ICMP except Redirects. These are allowed through, from ANY
(source) to ANY (Destination), without being logged, before the rule base
These are because the Firewall Properties are set to allow this protocols
through. These settings are what as known as the Firewall-1 "Implicit
These properties have four settings, unchecked, which means disabled;
and "First" which means the this is handled before it hits the ruleset;
and "Before Last" which means that this property is passed through the
but accepted just before the last rule, which is usually any-any-any-drop;
checked and "Last" which means that this rule is automatically the last
your ruleset. This is documented in the administration guide and CCSE
classes also cover these.
In FW-1 version 4.0 you can toggle the display of these implicit rules,
makes them much easier to identify and understand how they affect your
ruleset.. In previous versions, you had to keep track of them manually,
they were much easier to forget about.
The problem is not how these properties are controlled, IMHO, but instead
they default to enabled and "First". In my opinion, it should follow the
standard Checkpoint mantra of "Which is not explicitly allowed is denied."
violate their own standards there. Still, this is documented, though you
to wade through the manuals.
Just a point, however, is that setting up firewall is not a trivial thing
every FW-1 admin that I have dealt with is familiar with how these
work, if you are not familiar with the product, inside and out, how can you
sure you are properly implementing the product when it has such a critical
Consequently, DNS cache poisoning aside, if an attacker has managed to
a trojan or another "backdoor" on a host on the protected side, through
whatever method, and set it listening on TCP or UDP port 53, they will be
able to access this host transparently, through the firewall. No logging
will take place. The firewall host itself is reachable by this method,
if a 'stealth' rule has been placed in the rule-base to protect it.
During our lab tests we set an NT Server listening on TCP port 53 using
netcat and on connection spawned a command prompt (cmd.exe). On
to this server, through the firewall, we were able to attack all other
machines on the "protected" side. We also installed the cDc's Back
on a Windows 95 client listening on UDP port 53 and could access this
machine through the firewall. When listening on UDP 520 (RIP) the we
not access the 95 client, indicating that firewall-1 checks the validity
traffic sent over the RIP port.
Versions tested: Firewall-1 v3.0b on NT server 4.0 with Service Pack 3
Fix: From the Firewall-1 Security Policy Window choose Properties from
Policy Menu. Uncheck the "Accept Domain Name Queries (UDP)" and "Accept
Domain Name Download (TCP)". This will disable DNS which, of course, will
cause problems. In order to avoid this you will need to create a specific
rule in the rule base to allow these core protocols to function. The
nature of this rule will vary depending on the configuration of DNS
your own network and the above steps should only be taken after
with in-house DNS administrators. Diligence accepts no responsibility for
any problems caused by the disabling of these default settings.
Instead of completely disabling these rules, I recommend the "enabled" but
process it "Last" and have appropriate rules to authorize and log these
For further information see: http://www.diligence.co.uk
Senior UNIX Systems Admin
Nicholas | Applegate
600 West Broadway, 33rd Floor
San Diego, CA 92101
(619) 652-5493 voice
(619) 687-8136 fax
- Re: Firewall-1 Security Advisory, (continued)