I would like to see HTTP removed from vendor's list of places to "punch
holes through firewalls". Mark Ryland (mailto:markry @
microsoft .
com), a
Technical Evangelist in Microsoft's DRG group, commented that
(paraphrased) HTTP be used as a transport for DCOM so people can (if
they want to) take advantage of punching through port-based firewalls.
This represents, IMO, a call to all Firewall vendors to do one thing,
build a unified HTTP filter.
If, for example, every standard HTTP proxy recognized images, which
typically have some sort of header text, and ASCII text, then the proxy
could prevent any code blocks that contain anything else. This would
eliminate the need to constantly modify the proxy for new innovations.
New innovations should use distinct port numbers as they clearly are not
simply enhancements to HTTP as the innovation vendors would like to
espouse. Why is NNTP and SMTP handled on separate ports...they could be
seen as so similar as to warrant the use on the same port. Why was POP
put on its own port, its a function of SMTP. Why is it that innovation
vendors who make tools for HTML Browsers believe that it is only capable
of using a single port? Maybe more importantly to the security
community, why should we allow innovation vendors to use HTTP for
anything they desire?
Where is the IETF on this issue, how can you possibly write a protocol
specification that says something like "after the handshake messages,
you can stuff anything you want down this pipe, enjoy..."??? If they
don't do something to address these issues then that's what we'll
continue to have.
If Firewall vendors were to step up and put their foot down with respect
to the use of HTTP, if for no other reason than to allow themselves the
ability to continue to offer a product which affords some protection, I
think innovation vendors would have no choice but to face up to the
realities of security. How much longer will Firewall vendors be able to
say that using this innovation or that is not recommended through their
Firewall (i.e. Java, ActiveX) as its security cannot be assured? If
everyone believes everything can be done over HTTP, then what's the
point of a proxy server, why not just have a packet filtering router? Or
do Firewall vendors see this as a new opportunity to create yet another
server, an HTTP Protocol Server, to go into my Firewall solution?
Don't misunderstand me, I think Java, ActiveX, DCOM, and others are all
necessary progress and valuable tools, but you can't throw security to
the wind. DCOM uses NT authentication for its security, so I'm not
saying that DCOM is insecure, but stuffing it through an existing HTTP
proxy means it can't be prevented or properly monitored in larger
environments. This is the same issue as Java and ActiveX, if they can do
anything they want, and I don't want them to, how do I stop them without
stopping all HTTP traffic? Patching HTTP proxies, as Carl Claunch of
Hitachi Data Systems has done (mailto:carl @
hdshq .
com) for TIS is, in his
words, "an arms race, and each new executable requires me to keep up by
creating corresponding parsing logic. IMHO, any executable type allowed
through conceptually permits an intelligent hacker to pass any other
type". With DCOM, we're not trying to screen executables, but instead,
instructions, which could yield far more than an executable could ever
gain.
The "build it and they will secure it" idea is not a Bad Thing(tm), but
when you don't give us anyway to secure it what are we supposed to do?
When its on its own port, at least it can be explicitly denied if
desired. When you throw it into HTTP you intentionally destroy the
ability to properly secure HTTP, since its next to impossible to
properly isolate it from other data.
I consistently uphold Microsoft's ability to bring new technologies to
the mainstream (please, no flames), but this particular statement has
suggested, nay, recommended a way to put Firewalls at huge potential
risk. While I don't believe its Microsoft's intention to develop
products to usurp Firewalls, clearly most vendors of Internet
innovations today do not understand the impact their tools can have on a
network...buyer beware seems to be all they'll admit to. I think its
necessary to speak out against foolish and potentially malicious
recommendations from major vendors with regards to "punching through
port-based firewalls", and make them think about security first and
functionality second.
Cheers,
Russ
Because of the nature of this message, it has been cross-posted to
Firewalls @
GreatCircle .
com, a Firewalls mailing list (to subscribe go to
http://www.greatcircle.com/firewalls/ for more information), and
DCOM @
Listserv .
MSN .
com, a mailing list dedicated to Distributed Common
Object Model (to subscribe go to
http://www.lsoft.com/SCRIPTS/WL.EXE?SL1=DCOM&H=LISTSERV.MSN.COM for more
informtion).
|
|
