RE: [fw-wiz] IPS vs. Firewalls (why vs. ?)

-----Original Message-----
From: firewall-wizards-admin@xxxxxxxxxxxxxxxxxx
[mailto:firewall-wizards-admin@xxxxxxxxxxxxxxxxxx] On Behalf
Of Gabriele Buratti
Sent: Friday, February 03, 2006 8:14 PM
To: firewall-wizards@xxxxxxxxxxxxxxxxxx
Subject: Re: [fw-wiz] IPS vs. Firewalls (why vs. ?)

Parental advisory: explicit vendor opinions may occour in
this message !
Let me invite my competitors in a friendly discussion about
this layer 7 thing :)

Well, OK, you asked for it. :)

Here's the thing:
1) Proxy firewalls: Proxy firewalls are in theory good
because they can
do rfc compliance checks and "strange things won't be forwarded"
approach aka the marketing "day-0 protection". More, they'll
do fragment
reassembly. The problems about proxies are:
- performance decreased due to complete session rewrite

I bet you'll find that the 'session rewrite' (you're talking TCP/IP here, I
guess?) is not a significant performance issue, it's the fact that it's
running an application that actually knows enough about the protocol to
completely parse it. If you don't do that with your 'new technologies' then
you're not providing equivalent security. If you do do it, then you have the
same performance implication, which is I guess where the ASIC craze comes

Note that just because it's proxied doesn't make it secure. Some of the
proxy modules for various protocols are completely useless, cf old rants
about TIS/Gauntlet plug-gw.

- when used as reverse proxies for incoming connections you
always have
that listening ports on the proxy-firewall. Listening ports means
attackable ports.

Absolute FUD! Any time you're parsing network traffic you're prone to
attack, whether or not the port is open. The only attacks you're mitigating
by 'no open ports' are pure attacks against the TCP/IP stack of the network
appliance. The Snort BO preprocessor and the million remote ethereal attacks
should be clear warnings here.

This is a perfect example of false logic, by the way. Listening->Attackable
does not imply !Listening->!Attackable. (a->b =~ !b->!a but not !a->!b)

2) Firewalls with signatures [suck]

Yes, they do.

3) new technologies:

'New'? Consider this a raised eyebrow...

- reassemble the fragments in a separate space, do the checks, then if
ok send the fragments (no session rewriting).
- focus on the "strange things won't be forwarded", rather than
signatures: faster, sharp, you can use the marketing wizard's "0-day
protection" word :)

Well sure, you can use the term, but will it deliver? Let's take the WMF
0day as an example. I will bet $$$ that no IPS stopped it on release day,
unless they stopped all WMF. In fact, I'd be prepared to bet $$$ that no IPS
stops it _now_ if you don't count stopping one or two versions of existing,
published POC. There are about a million ways I can get a malicious WMF to
an unpatched host. How about inside an SSL web page as an IFRAME? Chunked?
MTU-aligned? What about the metasploit randomised Escape() pad version?

Here's HDM (one of the metasploit guys, in case anyone lives under a rock):

"there are so many ways to encode a
valid WMF graphic that any signature-based IDS is going to fail at least
one case. For example, there three different optional headers that can be
placed before the real WMF header. You can insert megabytes of filler
data between the vulnerable record types and even with a by-the-spec WMF
preprocessor, you can abuse bugs in the GDI api to specify invalid record
types that are still accepted."

And if you think _that's_ hard, try stopping an ASN.1 attack without writing
a fully functional parser.

This is not just an attack against network IPS, it works equally well for
proxy-based firewalls that claim 0day protection. You can't stop this kind
of attack at the network layer. Even H-IPS is going to fail, if it only has
a network shim.

Firewalls are not dead - they are great at doing exactly what they always
used to do. The trouble is that what they used to do is becoming less and
less effective against current attacks. People try and react by making
firewalls with bolted-on eggbeaters and waffle-irons, and it doesn't work -
because the new problems are intractable when considered from the point of
view of inline network inspection.

This is why we get the 'firewalls are obsolete' threads. No, they're not -
they just aren't going to solve all your problems. The problem is that,
years ago, people were (sadly) more inclined to believe that they could.


Disclaimer: If I sound a little confrontational, it's mainly due to the
false logic and the marketingspeak. However, you should also know that I
work for a company that sells a Host-IPS, and we do claim it provides 0day
protection (thus reading my rant should make it clear that it doesn't just
do network layer stuff). This can be considered a declaration of potential

firewall-wizards mailing list

Relevant Pages

  • [fw-wiz] IDS/IPS and LOGS
    ... nasty behavior is happening on your network (where your network is ... easily turn your IPS into a big denial of service attack. ... My guess is that most of the Worlds firewalls and IDS/IPS only have half ... I noticed that there is a big emphasis on log parsing while there should ...
  • Tech paper on proposed future generation NIDS
    ... Data is aggregated from the network ... UDP packets, or other incongruity in data and packet types. ... to reduce IDS rule sets and attack proccessing. ... When people in security speak of correlation, ...
  • RE: Intrusion Prevention Systems
    ... Network systems functioning as a bridge can prevent the traffic ... recognize the attack and prevent it from affecting the target is absurd. ... His point is that there are many techniques ... variables affecting the application's receipt of and response to the data. ...
  • Re: Asimov Asks "How People Get New Ideas"
    ... the outside adversary picks up the connection and now has ... a neat hole through the firewall -- the plug acts as your "inside ... connect the plug to the host's "normal" network drop. ... This leaves a few other attack modes: ...
  • [Full-disclosure] Re: RLA ("Remote LanD Attack")
    ... > " That is correct this affects network perimeter devices, ... > I used the -k switch a few, times although, it seemed to work either ... > the data/payload size seems to cause the attack to be more optimized. ... >>> remotely against the central connectivity device. ...