RE: GIDS, Intrusion Prevention: A Firewall by Any Other Name

[Crispin Harris <Harris_C () DeMorgan com au>]

> From: Crispin Cowan [mailto:crispin () wirex com]
> Ryan Russell wrote:
>
> > So, if I may summarize your question: "Don't buzzwords suck, 
> and isn't
> > this a firewall"?  To which I respond: define firewall.
> (according to me) firewall, n.: A network access control device.

Firewall, n.: A network choke (point or region) at which a security policy
can be applied, thus controlling access to and/or from a defined group (or
groups) of systems or resources.

I think that it important to note that:
1) a firewall applies a security policy of some sort.
2) A firewall need not be a single device (indeed a number of "Firewall
Products" in the higher security realm were historically implemented using
multiple devices providing discrete separate functions).

> A firewall decides whether traffic on one side of it may pass to the 
> other side, and in what form.

A better and more general phrasing. A firewall is system performing network
based access control in accordance with a security policy. (i.e. the
firewall should not be the totality of your policy enforcement.)

> > I think a more interesting question is: if GIDS is 
> > the new "firewall", then why did firewalls running 
> > on top end PCs max at 100mbps or so with just a few 
> > dozen rules and terribly simply filtering 
> > capabilities... while a GIDS with much more 
> > interesting filterinag capabilities and a few 
> > thousand rules can also do the same?  Did PCs just 
> > get that much faster?
> I agree with the comment that it's because people 
> tolerate NIDS failing open, where as they would not 
> tolerate that from a classical firewall. 

I doubt that this is the entirety of the answer.
Efficient code will be part of it, hardware accelleration may also help, and
of course, algorithm & process design will make a massive difference.

Marcus or one of the other listmembers who deal with high bandwidth packet
inspection and/or transfer may be able give us a better idea, but I suspect
that if you have unfettered access to networking hardware, and your system
is not being asked to do a whole nightmare of non-inspection tasks, then
throughput can be phenomenal by the standards of the late 90s.

If you can add dedicated ASIC or packet munging hardware, then things
probably get a whole order of magnitude faster. (If the IC could hand me a
TCP payload with appropriate meta information without having to deal with
the initial IP and TCP membuf nonesense or the overhead encounterred in
"bind(), connect(), select()" then things get _MUCH_ quicker.)

> I sure HOPE that signature firewalls don't fail open.

(but suspect that they do...)
I have found more and more "firewalls" are failing open increasing
circumstances. (Because of commercial realities.) An example of this is the
number of otherwise strong products that will continue to allow packets when
they are no-longer capable of logging. [1]

> > (I think part of the answer has to do with the fact 
> > that IDS' are much less concerned with various groups 
> > of IP addresses, like inside, outside, DMZ, web_
> > servers, etc...)
>
> I find it difficult to believe that a device can look up a signature 
> faster than it can look up an IP address.

Particularly, given that properly implemented, a table-lookup is one of the
fastest mass data functions available. I tend to agree with Marcus'
one-liner "Poor code". 

An alternative, which is even less attractive, is that the Signature-Based
firewall is using the same short-cut that most "Stateful" packet filters
use, and only inspect certain portions of any given stream. (in this case,
rather than inspecting the SYN->SYN-ACK packets, they inspect the first
inbound ACK-only data packet.) This sort of short-cut would definitely
improve their performance figures, as they could then cut-through switch the
remainder of the connection.  [2]

Regards,
        Crispin Harris
        Senior Security Consultant (Sydney)
        DeMorgan Information Security Systems


[1] This is particularly relevant to syslog based log systems (i.e. most
appliance based firewalls). While I can see the argument for fail open in
this case, I would prefer to be able to tune this behaviour in response to
executive risk assessment. With a number of products, the only way to chose
"deny if I can't log" is to say "Next product please!" and the vendor can
get quite nasty in the ensuing cat fight :-(

[2] I am still surprised at the number of "Market Leading" firewalls that do
not do sequence number inspection, or deal configurably with the IP Options
or the TCP flags.

----------------------------------------------------

 This correspondence is for the named person's use only.  It may
 contain confidential or legally privileged information or both.
 No confidentiality or privilege is waived or lost by any
 mistransmission.  If you receive this correspondence in error, please
 immediately delete it from your system and notify the sender.  You
 must not disclose, copy or rely on any part of this correspondence
 if you are not the intended recipient.
 
 Any views expressed in this message are those of the individual sender,
 except where the sender expressly, and with authority, states them to
 be the views of DeMorgan Pty Ltd.
 
 This e-mail has been checked for known Viruses. It is the responsibility
 of the receiver to check their system for infected files and any such
 file is deemed not to be the responsibility of DeMorgan.

---------------------------------------------------------