Re: [fw-wiz] Firewall Primitives

From: Marcus J. Ranum (mjr@ranum.com)
Date: 11/09/02 

To: Mikael Olsson <mikael.olsson@clavister.com>
From: "Marcus J. Ranum" <mjr@ranum.com>
Date: Sat Nov  9 22:57:31 2002

Mikael Olsson wrote:
>Any chance I could get you to agree that this also _could_ be related
>to the sheer number of protocols in common use today?

Absolutely!!! I think that it was back in '91 that I posted
to the firewalls mailing list: "if you can't say it with
FTP, telnet, NNTP, or SMTP it probably isn't worth saying" ;)
Ah, well, I've eaten better words than those... ;)

The fact that there are HUGE numbers of new protocols and
many of them are designed by idiots, poorly documented, and
proprietary makes packet-filtering firewalls nearly a
necesssity. It's why (in the early days) CheckPoint did
so well: you could let some braindamaged cruft through a
checkpoint more easily than through a proxy firewall.
Note: I said "let through" not "secure" - though there
were people who felt that going and telling a firewall
"let Oracle back and forth on port XYZ" meant that
the firewall was somehow "securing Oracle." Fortunately
Oracle is now unbreakable...

>Doing thorough app logic on telnet, SMTP, NTTP and FTP is one thing.
>(Well, actually, the FTP assumptions broke completely when Java was
> introduced, but that's another story :))

Early on, we did app logic on HTTP as well. That was when I
was leading Gauntlet development. During the 4 months it took
to get out a solid HTTP proxy, CheckPoint ran away with the
checkered flag. BUT while that was happening, Dave Dalva (who
was on my team) found numerous horrific security holes in
the Mosaic Browser - holes that clients were exposed to if
they were using packet filtration. (e.g.: the way that Mosaic
used to invoke telnet://ip.ip.ip.ip:port URLs was:
sprintf(buf,"telnet %s %d",host,port);
system(buf);
I kid you not...)

>AFAIR, things started going south when HTTP was becoming popular and
>wasn't proxyfied soon enough. (And, yes, I do recall why that was.)

Yup.

>But, really, I can't say I'm surprised that the vast majority of
>firewall installs are just packet filters (or proxies using mainly
>plug-gws). When you move beyond well-defined standardized protocols
>(in which I most certainly do NOT include the fast-moving target HTTP),
>anything approaching thorough application analysis becomes... hard.
>"Whoops! New version of $business-critical-multimedia-app released!
>The proxy broke again!"

Yup. As William Hugh Murray says "Connectivity trumps security
every time." Nobody thinks to ask "HEY!? Why did my business
critical multi-media app suddenly start performing this new
operand 'delete-file' in its command stream that the proxy
doesn't know about???!?"

My conclusion after being a vendor for lo these many years is
that customers *DESERVE* the security they get.

mjr. 

---
Marcus J. Ranum				http://www.ranum.com
Computer and Communications Security	mjr@ranum.com

Relevant Pages

  • [NT] Symantec Enterprise Firewall (SEF) HTTP URL Pattern Evasion Issue
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Firewall product, as supplied by ... For the HTTP ... The HTTP pattern matching functionality works by analysing the HTTP URL ...
    (Securiteam)
  • Re: [fw-wiz] Firewall Primitives
    ... > firewall. ... > the firewall was somehow "securing Oracle." ... spot with protocols and security. ... stuff like "secure filtering" and "Six As of Security" ...
    (Firewall-Wizards)
  • Re: AspNet X J2EE
    ... j2ee and asp.net use different http protocols - thre is only one http ... or iis for example only returns http traffic - the security risk therefore ... with correctly managed firewalls and protocols makes any ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Question about web service
    ... the web service i have developed will be deployed ... > firewall configuration to allow windows to windows native communication. ... > any suhhest the protocols to be used in this application? ... HTTP, which is the "default" protocol for webservices anways. ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • [REVS] Bypassing Client Application Protection Techniques
    ... Get your security news from a reliable source. ... protection programs. ... * Kerio Personal Firewall 4.0 ... And we got actually nothing in the field of client application ...
    (Securiteam)
Loading