Re: [fw-wiz] Firewall Primitives
From: Alex Goldney (agoldney@qantas.com.au)
Date: 11/06/02
- Next message: Devdas Bhagat: "Re: [fw-wiz] Firewall Primitives"
- Previous message: Carson Gaspar: "Re: [fw-wiz] Flat vs Segmented DMZ's"
- Maybe in reply to: Cat Okita: "[fw-wiz] Firewall Primitives"
- Next in thread: Stephen P. Berry: "Re: [fw-wiz] Firewall Primitives"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: "Marcus J. Ranum" <mjr@ranum.com> From: "Alex Goldney" <agoldney@qantas.com.au> Date: Wed Nov 6 20:23:01 2002
"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
- Next message: Devdas Bhagat: "Re: [fw-wiz] Firewall Primitives"
- Previous message: Carson Gaspar: "Re: [fw-wiz] Flat vs Segmented DMZ's"
- Maybe in reply to: Cat Okita: "[fw-wiz] Firewall Primitives"
- Next in thread: Stephen P. Berry: "Re: [fw-wiz] Firewall Primitives"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
