Re: Firewall best practices

Carson Gaspar <[email protected]> Tue, 27 Apr 2010 16:41:04 -0500
Newsgroups gmane.comp.security.firewalls.wizards
Message-ID <[email protected]>
Marcus J. Ranum wrote:

> I wasn't referring to anything in specific; I think, though,
> that we've moved past the point where we can think of firewalls
> as just source/dest IP source/dest port and we need to start
> characterizing genres and sub-genres of traffic. There was a
> time when Jon Postel said that "Email is the new datagram"
> but now "HTTP is the new IP" - we've lost the battle on trying
> to have HTTP just be a fetch protocol for data; it's now a
> much more complicated thing with genres and sub-genres and
> probably sub-sub-genres of traffic. We can't meaningfully
> "firewall" traffic if "permit source HTTP ANY" includes
> VPNs, bidirectional commands, voice data, and who knows
> what else?

Once upon a time I did some serious thinking about a signature based 
firewall, that cared only a little about port numbers, and a lot about 
packet content. It would necessarily involve an update cycle similar to 
anti-virus signature updates.

I've seen some work on this, mostly from a traffic shaping / IPS / IDS 
slant, but I haven't seen anything serious from the firewall front. But 
then I haven't been doing firewalls for several years, so I may just be 
behind the times.

> You're completely right about the "if the application
> emulates HTTPS traffic" problem. I don't have an answer
> to that one other than "we warned everyone that that
> was going to be a problem." At this point, it's less
> of technical problem than a social one. It seems to me that
> an organization cannot claim to be concerned about
> security while allowing user-oriented encrypted outgoing
> links to any target. That's just foolishness. The fact
> that "everyone does it" doesn't make it any less foolish.
> Back in the proxy days we advocated tying outgoing
> connections to an authenticated user; that's another
> important aspect of the problem that gets short shrift.

See my previous (or possibly next, post moderstion...) post re: SSL MITM 
proxies. Of course that just puts you back at the first problem, except 
you may detect rogue apps by their non-acceptance of your magic CA cert.

-- 
Carson