Bugtraq 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. ------=_NextPart_000_0058_01BE01BC.5AF15F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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? -----Original Message----- 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,
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
------=_NextPart_000_0058_01BE01BC.5AF15F40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIBjCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggKRMIIB+qADAgECAhEAnARJLhIMCX3uRvua5rzfqjANBgkqhkiG9w0BAQIFADBfMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTcxMDEzMDAwMDAwWhcNMDIxMDEz MjM1OTU5WjBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBDQTCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA3CqZnW4z/LtB dsQ5Ho33dueQD3RVYWFyPPg3SxsfCOkwHXDFFolgM0ZIf8bQmj12mMOhwaxS0Re5FARphlxhT7Nl ZYtjou4hfEGvrXJAw02Rs0m+mPtXx1ousEun7wkk84GdOMWS2kqnmFGp2DB2LWrWry9+2xEqhftl YFpF6BsCAQOjazBpMDYGA1UdIAQvMC0wKwYLYIZIAYb4RQEHAQEwHDAaBggrBgEFBQcCAQQOYWFh YWFhYWFhYWFhYWEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQD AgEGMA0GCSqGSIb3DQEBAgUAA4GBAHCE+skG8m7Qn1cjdlhJAR/3ugeMIpb90+UTT+PoHKHDwSaS TO4fsNFWWggRDeb3bN2TIQVWQ7vtCP3qWdHGAQpQ7HUC3qhiOxGZrSp5YXsf8aUWBKY+3EnFRGCE ThdHlNMhM2g6hNQRsxt1SJBlRXo1jXvAerTGTQi0JXQxCcSAMIIDLDCCApWgAwIBAgIQIQaN5eiV a088P+uEVWu3iDANBgkqhkiG9w0BAQQFADBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMl VmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQTAeFw05ODA4MTEwMDAwMDBaFw05 OTA4MTEyMzU5NTlaMIHTMRcwFQYDVQQKFA5TZWN1cmVJVCwgSW5jLjEMMAoGA1UECxQDUEtJMUYw RAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk2MSAwHgYDVQQMExdTci4gU2VjdXJpdHkgQ29uc3VsdGFudDEbMBkGA1UEAxMS TGF3cmVuY2UgQSBQaW5ncmVlMSMwIQYJKoZIhvcNAQkBFhRsYXJyeXBAc2VjdXJlLWl0Lm5ldDBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDHqtP1QibBu6QOP1SorWm9tAtlO3rOS4UtHsDq5zfwVpow O8b9crn6o8UpTH3U7NdQpQZ0xoXtLVJqwCQTDctpAgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYD VR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24AAAAA AAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBBAUAA4GBACdJG9AAvDNTUeigXllD+bIq B6HuPR1z4DBKT1OBMe2cKkaYW3ijUJulmqQs7COF7Ls7aGAcRpfaQYIsxYnlfogrnSMRm2dvfPxJ p7rVQh7g9i4+smZRFy3WRsB/LEZJV35XdKPZiBdhB2FK8hxt3BRc8WfwoLLKn69uTW23imp6MYIB RTCCAUECAQEwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3Mg MiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQIQaN5eiVa088P+uEVWu3iDAJBgUrDgMCGgUAoIGGMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MTAyNzE1MTMyOVowIwYJ KoZIhvcNAQkEMRYEFHAzrBMsGjEbyZemKAGwgCo3wp2GMCcGCSqGSIb3DQEJDzEaMBgwDQYIKoZI hvcNAwICASgwBwYFKw4DAh0wDQYJKoZIhvcNAQEBBQAEQBmm140ugJt0YhTTcJ8HltPvsKCC43yT mgjKS8eFqCdkL3G2P7oqXg2TkhYC0Wqui973BQMmd594TglKzTvWRT8AAAAAAAA= ------=_NextPart_000_0058_01BE01BC.5AF15F40--
Current thread:
- Re: Firewall-1 Security Advisory, (continued)
- Re: Firewall-1 Security Advisory John Horn (Oct 28)
- rootshell hacked via ssh-1.2.26 Felix von Leitner (Oct 28)
- 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)
- Summary of Printer Sharing and M1CR0S0FT Windows98 Paul Leach (Oct 29)
- Re: Firewall-1 Security Advisory Jason Costomiris (Oct 30)
- Firewall-1 insecurity. Darren Reed (Oct 29)
- Bug in Solaris 2.6 ??? Daniel Ezekiel (Oct 29)
- WatchGuard Firewall internal D.O.S Who Wants To Live Forever ... (Oct 29)
- Re: Firewall-1 Security Advisory Gary Gaskell (Oct 27)
- Re: Firewall-1 Security Advisory Larry Pingree (Oct 27)
- Re: Firewall-1 Security Advisory Simon Finn (Oct 29)
- Re: Firewall-1 Security Advisory Keith Young (Oct 29)