Andrew Plato wrote:
>The problem with your comments, Crispin, is that you consider basic packet
>inspection to be security analysis. I disagree. Most firewalls (Checkpoint,
>pix, netscreen, etc.) are packet filters. They look at communication
>information and apply access control lists based on some rules.
>
No I don't. The proposition that a packet filter could substitute for a
real application proxy firewall like Gauntlet was Checkpoint's idea, not
mine :-)
I think a firewall is a widget that sits between the Internet and your
protected machines, deciding which packets get in & out. The depth of
analysis is a property of the firewall in question. Simple stateless
packet inspection is really lightweight "analysis." Deep semantics like
SNORT's ability to detect novel buffer overflows by identifying absurdly
long strings in fields where they shouldn't be is deeper analysis.
That's a quality comparison, but they are fundamentally doing the same
thing: deciding which packets are admitted, and which are not.
>This is no where near synonymous with an IPS which looks beyond the packet
>and analyzes the entire communication stream. Proxy-based firewalls
>(Sidewinder/Gauntlet and some variants) go part of the way there. They do
>application-layer rules. But the classic packet filter firewalls do not have
>that kind of ability.
>
Right. See? You're comparing these various firewalls on their merits,
and claiming that one is better than another. This is a good thing.
>I see firewalls as essentially an access control point. To use an airport
>security analogy: firewalls control who gets on the plane and that's all.
>They don't look to see if the person is carrying a bomb. And IPS does both
>access control and looks in the person's luggage to see if there is any
>bombs in there.
>
Your distinction is just how deep the inspection goes. Both cases are
still access control.
>Consider the extremely basic problem of things like Code Red. Firewalls
>couldn't stop code red at all, unless port 80 was blocked. But since that
>would have killed the web sites of many companies - that wasn't really an
>option. Therefore, the firewall did nothing to prevent code red. But a
>host-IPS or network-IPS could have seen code red in the stream and dropped
>the offending packets and kept web access open.
>
Again, both cases are just access control, with depth of inspection
being the only difference.
>>How about we stop trying to classify them and just call them *all*
>>firewalls? Then we can just compare firewalls head to head on
>>features, performance, operational costs, security, etc.
>>
>>
>Then we're comparing CheckPoints to IntruVerts, Netscreens to RealSecure
>Guards - and that is a crummy comparison because they really are not the
>same types of products. An IntruVert is not anywhere near the same as a
>CheckPoint.
>
How are they different?
> A comparison between the two would be misleading. It would make
>CheckPoint look lame and Intruvert look outlandishly priced.
>
Unless it really *is* the case that CheckPoint is lame and Intruvert is
outlandishly priced :-) Especially when compared against IPTables (free
stateful packet inspection in Linux) and inline-SNORT (free signature-
and rule-based intrusion prevention), both of which are available in
commercial products that cost much less than CheckPoint and Intruvert.
>As for your quadrants. You define anything that does merely access control
>as prevention.
>
Damn straight :) There is a subset relation here:
* all access control is prevention
* there are other forms of prevention besides access control
Therefore, all firewalls are intrusion prevention systems, period. But
some firewalls prevent more stuff than others.
> I disagree. Access control does not mean bad stuff can't get
>in.
>
Of course not. It only means you applied controls, not that the controls
are correct or complete.
>* Network
> o Access control:
> + classic firewalls: Checkpoint, Netscreen,
> PIX, etc.
> + Router/VLAN ACLs
> o Prevention:
> + NIPS: inline SNORT, IntruVert, ISS Guard,
> TopLayer Attack Mitigator, etc.
> + Application firewalls: Sidewinder, WatchGuard (sort of)
>
I see no reason to separate "access control" from "prevention" in this
way. Oh wait, I *do* see a reason: *marketing*. People selling
"prevention" can charge more for it if they create a synthetic
distinction that separates their products from firewall, which are,
after all, commoditized & boring, and therefore cheap.
> o Detection:
> + IDS: RealSecure, Snort/Sourcefire, ManHunt, etc.
>* Host
> o Access control:
> + ACLs, token authentication, locks, passwords, etc.
> o Prevention:
> + Behavior HIPS: Okena, Entercept
> + Signature HIPS: RS Desktop/Server, Sygate
> + Secure OS: Immunix, a Windows box with no power ;-), etc.
>
Small context: the distinction between behavior and signature is
correct. However, Immunix belongs in the behavior space.
Larger comment: ACLs are a behavior-based mechanism. "Access controls"
in the OS context means specifying who can do what. The details are in
how you specify the "who" and the "what":
* ALC's (Access Control Lists): specify which subjects (users) can
access a given file.
* Okena, Entercept, and Systrace (OpenBSD): specify which system
calls a given program may invoke. At least in the case of
Systrace, you can also specify the arguments to the syscalls that
are permitted.
* Immunix SubDomain: specify which files a program may access. Less
expressive but easier to manage than syscall profiling.
There are also non-access control behavior techniques:
* Immunix
o StackGuard: programs may not overwrite function call
activation records while the function is running.
o FormatGuard: programs may not pass a printf format string
that specifies more arguments than are provided at the call site
o RaceGuard: one program may not interrupt another program
creating a temp file, to resist temp file race attacks
* Libsafe: programs may not call the "big 7" string functions with
parameters that point at their own stack activation records
* Openwall Linux:
o non-executable stack segment
o various restrictions on following symbolic and hard links to
resist temp file race attacks
> o Detection:
> + Integrity monitors: Tripwire, etc.
>
Yeah. Plus assorted logging and log analysis stuff, which I left out of
my quad.
>And I would say best practices would be to try to have something at every
>level.
>
Sure, it is always best to have everything :)
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/
This archive was generated by hypermail 2b30 : Tue Jun 24 2003 - 17:23:58 PDT