Firewall Wizards mailing list archives
Re: Firewall Primitives
From: "Alex Goldney" <agoldney () qantas com au>
Date: Thu, 7 Nov 2002 12:11:16 +1000
"Marcus J. Ranum" <mjr () ranum com> To: George Capehart <capegeo () opengroup org>, Crispin Cowan <crispin () wirex com> Sent by: cc: firewall-wizards () honor icsalabs com firewall-wizards-admin@honor.i Subject: Re: [fw-wiz] Firewall Primitives csalabs.com 06/11/2002 11:48 PM ** Stuff deleted **
A firewall gets a SYN packet aimed at port 23 on a machine behind the firewall. The firewall looks in its policy table and drops the packet (or sends a reset) to the client, and logs a refused connection. What does an IDS see? Nothing (if it's inside the firewall) or nothing (if it's outside the firewall) except a rejected connection. Was it a probe or attack? We'll never know because it never got far enough to even matter. Maybe we don't care but maybe we'd have wanted the firewall to do something like hand-off the connection to an internal routine that tarpitted the connect, or gave a login: prompt, or whatever. Just for information collection. It'd be an interesting option, anyhow.
But in case 1, the firewall sees something and logs it. You could post process that information, or even feed it into the IDS as another data stream (theoretically), so it's not like the information is really lost. You could always have one IDS outside the firewall, and another inside, but because they probably don't communicate information between themselves, it may still be difficult to figure out if an event seen by one IDS is part of a larger problem, or just someone typing the wrong IP address. The problem really boils down to how you centralise and process all the information available to you from multiple different sources, preferably in real time.
The next case is more complex and really points out (to me) a lot of the flaws in firewalls today. Consider a firewall gets a connection on port 80 inbound to a webserver. It checks policy and sees it should be allowed. It logs the connect and begins shuttling packets. That's as far as most firewalls go. BUT the firewall _should_ be doing app-level processing and signature checking against the incoming (or optionally outgoing) stream to check for misuse or intrusions. Suppose it finds an incoming URL that looks like a buffer overrun. At that point, it might make sense to hand the traffic off (simulating a session start-up internally or setting one up with an external machine and switching into proxy/NAT on that session) to something that might perform more detailed analysis, packet capture, IDS, or honeypotting.
Well, the firewall doesn't necessarily HAVE to do that type of processing. As long as it makes sure the connection can only get from/to where you told it to go, the firewall has added value. It could be seen as the job of the application at the other end of the connection to make sure it doesn't do anything outside what that application is allowed to do. (Naturally, this doesn't work in practice :-)) Since we assume the application may have a hole one day, we might put in a NID or a HID. If I have an IDS behind the firewall, it can check for intrusions, and optionally trash the connection if it sees something it doesn't like. Ultimately, you are limited by the performance of the box as to how much you can achieve on one piece of hardware. We operate in a distributed environment, so it seems reasonable to have distributed security mechanisms.
About a month ago(?) I posted a flowchart for the whole IDS/firewall/antivirus/content inspection/honeypot/VPN/NAT gamut, which are all really aspects of the same thing: security oriented boundary traffic management. Traffic management can't be just packet-level because there are non-packet-level attacks that we should be worried about. Most firewalls are packet-oriented but that's only because the customers and equity markets have rewarded speed over security in such products.
Well, speed is important too. Customers just go somewhere else if they can't get what they want from you in a timely manner. Cost is also important, if it costs me more to secure my environment than the cost of an intrusion, it's very difficult to get a business case that will be approved. Which again comes back to the validity of having distributed products to allow the use of more economical hardware.
mjr. --- Marcus J. Ranum http://www.ranum.com Computer and Communications Security mjr () ranum com
_______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
*******************Confidentiality and Privilege Notice******************* This email is intended only to be read or used by the addressee. It is confidential and may contain legally privileged information. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone, and you should destroy this message and kindly notify the sender by reply email. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you. Qantas Airways Limited ABN 16 009 661 901 Visit Qantas online at http://www.qantas.com.au _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: Firewall Primitives, (continued)
- Re: Firewall Primitives Devdas Bhagat (Nov 07)
- Re: Firewall Primitives Adam Shostack (Nov 09)
- BS claims (was Re: Firewall Primitives) Marcus J. Ranum (Nov 09)
- Re: Firewall Primitives Mikael Olsson (Nov 09)
- Re: Firewall Primitives Marcus J. Ranum (Nov 09)
- Re: Firewall Primitives Christopher Hicks (Nov 10)
- Re: Firewall Primitives Predrag Zivic (Nov 10)
- Re: Firewall Primitives Stephen P. Berry (Nov 11)
- Re: Firewall Primitives Cat Okita (Nov 11)
- Re: Firewall Primitives Paul Robertson (Nov 11)
- Re: Firewall Primitives Stephen P. Berry (Nov 11)