Gabriele Buratti wrote:
>let's say our knowledgebase is the definition of http protocol as it should be. So, if you find malformed http (=non compliant) you drop it. What if you find some instant messaging traffic (you don't want in your network) that is http compliant ?
This is exactly what I meant about whether a device is internally designed
around 'default permit' or 'default deny'. A device that is aimed toward
default deny would know what totally vanilla HTTP looked like and would
discard anything that was not exactly plain HTTP.
Protocol-over-protocol tunnelling is nothing new. But step back and ask
yourself "why tunnel protocol over protocol"?? There is actually no real
reason for tunnelling except to make it easier to bypass controls, right?
After all, if we use SSL on port 443 for "https" and SSL on port 993
for "imap" etc, it's clear that we can use protocol layering without
trying to violate policy... So I, frankly, I feel that if I see instant messenger
traffic on my HTTP service that I've caught someone with their hand in
the cookie jar, so to speak. Time to cut it off...
Remember, a lot of these tunnelled protocols are billed as being
"firewall friendly." In the same sense that a .50 BMG SLAP
round is "skull friendly" - it's designed to zip right through whether you
want it to or not, with virtually no performance degradation on the
bullet's trajectory. Implicit in the very design of a tunnelled protocol
is the idea that it is trying to violate policy. That, of course, makes
it commercially attractive! For some reason, people _like_ firewalls
that are more permeable to '"firewall friendly" protocols, but they
shy away from "skull friendly" bullets. I just can't figure it out.
mjr.
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Received on Feb 07 2006
Intro
