Bugtraq mailing list archives
Re: Firewall-1 Security Advisory
From: Paul_Sears () NACM COM (Paul Sears)
Date: Mon, 26 Oct 1998 12:58:16 -0800
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, in theory, that all IP based packets, whether incoming or outgoing should be dropped. However, Firewall-1, out of the box, allows certain "core" network 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 is referenced.
These are because the Firewall Properties are set to allow this protocols through. These settings are what as known as the Firewall-1 "Implicit Rules". These properties have four settings, unchecked, which means disabled; checked, and "First" which means the this is handled before it hits the ruleset; checked and "Before Last" which means that this property is passed through the ruleset but accepted just before the last rule, which is usually any-any-any-drop; and checked and "Last" which means that this rule is automatically the last rule in your ruleset. This is documented in the administration guide and CCSE training classes also cover these. In FW-1 version 4.0 you can toggle the display of these implicit rules, which makes them much easier to identify and understand how they affect your ruleset.. In previous versions, you had to keep track of them manually, and they were much easier to forget about. The problem is not how these properties are controlled, IMHO, but instead that they default to enabled and "First". In my opinion, it should follow the standard Checkpoint mantra of "Which is not explicitly allowed is denied." They violate their own standards there. Still, this is documented, though you have to wade through the manuals. Just a point, however, is that setting up firewall is not a trivial thing and every FW-1 admin that I have dealt with is familiar with how these properties work, if you are not familiar with the product, inside and out, how can you be sure you are properly implementing the product when it has such a critical role?
Consequently, DNS cache poisoning aside, if an attacker has managed to place 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, even 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 telnetting 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 Orifice 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 could not access the 95 client, indicating that firewall-1 checks the validity of 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 the 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 exact nature of this rule will vary depending on the configuration of DNS within your own network and the above steps should only be taken after consulting 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 services...
For further information see: http://www.diligence.co.uk
-- Paul Sears Senior UNIX Systems Admin Nicholas | Applegate 600 West Broadway, 33rd Floor San Diego, CA 92101 (619) 652-5493 voice (619) 687-8136 fax
Current thread:
- Firewall-1 Security Advisory Diligence Risks (Oct 24)
- <Possible follow-ups>
- Re: Firewall-1 Security Advisory Paul Sears (Oct 26)
- Re: Firewall-1 Security Advisory Mnemonix (Oct 27)
- Sendmail, lynx, Netscape, sshd, Linux kernel (twice) Michal Zalewski (Sep 05)
- Re: Sendmail, lynx, Netscape, sshd, Linux kernel (twice) Nick Andrew (Oct 28)
- Re: Sendmail, lynx, Netscape, sshd, Linux kernel (twice) brian j. pardy (Oct 28)
- [L0pht Advisory] MacOS - FWB passwords easily bypassed Space Rogue (Oct 30)
- Re: Firewall-1 Security Advisory John Horn (Oct 28)
- rootshell hacked via ssh-1.2.26 Felix von Leitner (Oct 28)
- Sendmail, lynx, Netscape, sshd, Linux kernel (twice) Michal Zalewski (Sep 05)
- Re: Firewall-1 Security Advisory David S. Goldberg (Oct 27)
- Re: Firewall-1 Security Advisory Gary Gaskell (Oct 27)
- Re: Firewall-1 Security Advisory Ejovi Nuwere (Oct 29)
- Re: Firewall-1 Security Advisory Gary Gaskell (Oct 27)
(Thread continues...)