Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Firewall Wizards: Re: on-the-fly-analysis vs. proxy rewrites

Re: on-the-fly-analysis vs. proxy rewrites

From: ArkanoiD <ark_at_eltex.net>
Date: Fri, 10 Feb 2006 14:37:15 +0300

nuqneH,

Well, a sad example comes to mind: IMAP. It is incredibly complex and
you CANNOT strip it down efficiently because various implementation use
different subsets. Mostly to achive simple goal "something like pop3 but
with server folders". A real nightmare for firewall implementation.

On Thu, Feb 09, 2006 at 12:06:47PM -0500, Marcus J. Ranum wrote:
>
> >You keep using SMTP as an example but that is such a small bunch of
> >RFC's.
>
> Well, it -was- small, but now it's not. The standards pukes keep bolting
> new curb-feelers and shag carpet and mirror disco balls onto it, too...
> Last year I recall I was poking fun at Wietse Venema about the fact
> that postfix now has more lines of code in it than sendmail (!!)
> 17362 lines: sendmail 4.6 (1991) from net2 tape
> 299545 lines: postfix-2.2.2 (current release)
> 220263 lines: sendmail-8.13.4 (current release)
> (See: http://www.ranum.com/security/computer_security/archives/issa-minneapolis-2005.pdf )
> and Wietse pointed out that he tracks the wads of code bloat against
> the RFCs that trigger them, and the cost of complying with standards
> is measurable and large.
>
> I'll also note that in 1991 Steve Bellovin used to call sendmail
> "sendwhale" because he felt that at 17,000+ lines of code it was
> too bloated to have its security properties understood. ;) I know
> Wietse feels postfix is OK in spite of the bloat because he designed
> the system so that the volume of trusted code has not grown
> in comparison the the volume of un-trusted code. My hat's off to
> Wieste - but the standards pukes get a big raspberry from Marcus:
> if SMTP worked in 1991 they should have left it the hell alone
> and gone back to making IPV6 too bloated to use instead.
>
> Of course my response to that is "why comply with standards?" A boundary
> device SHOULD NOT BE 100% STANDARDS COMPLIANT because the
> protocols SUCK.
>
> Ahem, excuse me for shouting, there. But this particular topic makes me
> want to scream every time I think about it. Consider the FTP RFC. The
> FTP RFC *requires* that an FTP server be capable of carrying out FTP
> bounce attacks and scans. Well, OK, I just looked at the FTP RFC and
> the standards pukes have apparently hammered TLS into it "to secure
> it" and my brain shut off when I saw the magic phrase "firewall-friendly"
> and I could read no further. Perhaps FTP has gotten better. Who wants
> to bet?
>
> So, the fact that SMTP is a "small bunch of RFCs" is not the issue; the
> issue is that SMTP is already off the chart of suckage and rocketing
> toward the stratosphere of suck. Don't get me started on HTTP...
>
> >What about trying to deal with http which has almost no bounds?
>
> Ah, I thought I told you not to get me started on HTTP... ;)
>
> >There are two many possible uri's.
>
> That's putting it far more mildly than I would. So let's leave it at that.
>
> >All of the proxies I've looked (and that's
> >not many) do very little in the way of breaking down the uri and
> >handling those various subcomponents (such as java script, activex,
> >dll's even). It's usually block all java script (useless) or let it all
> >through (worse than useless).
>
> Yes, the current state of the art can best be summarized as
> "horrible and getting worse"
>
>
> >And what do you do when there are hundreds of nasty DLL's in paths and
> >hundreds of good ones. I mean, where do you start?
>
> Only a really stupid stupid operating system would use DLLs. I mean,
> think about it - the whole notion of a stable "release level" completely
> goes down the toilet when you imagine a runtime environment where
> major subcomponents of a program can be altered between invocations
> without the program's having any idea that it happened. Surely nobody
> would actually implement such a bad idea? Oh, um, wait...
>
> >And with all the other demands placed upon my valuable time and
> >resource, how on earth could someone possibly be expected to parse and
> >control every nuance within the realm of http? What about parsing the
> >query? What's safe? What's not?
>
> You can't. It's achieved "critical mass of suck" - and thanks to
> backwards, forwards, and sideways compatibility, it will get
> worse and worse until finally the suck gets so severe that
> it bends light and gravity and consumes everything. Oh, wait,
> that happened when content chunk encoding was invented.
> Does anyone know what the hell motivated that particular
> piece of braindamage? Was some twit trying to do TCP over
> an existing TCP stream?
>
> >I feel that the horse has already bolted on that one.
>
> The horse didn't bolt, he walked out rather leisurely, then caught
> a cruise ship to Brazil, changed his name, and cashed in his
> stock options for a bunch of flashy mares and a lot of carrots.
>
> All I can say is "hey, I didn't break it, stop asking me to fix it."
> In the immortal words of Lord John Worfin: "S'notta my problem, monkey-boy."
>
> mjr.
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards_at_honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Received on Feb 19 2006

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos