Craig Brozefsky wrote:
> On Mon, 9 Jun 1997, Mike Ordun wrote:
> > Have been following this discussion with a lot of interest as a
> > of both SPF and proxy firewalls. I happen to believe that both are
> > appropriate in different circumstances and customer need.
> Nevertheless, I
> > am a little troubled by the claims that SPFs are inherently
> > insecure. Let me present a challenge. Lets compare some specific
> > commercial offerings -- Firewall-1 in one corner representing SPF
> and say
> > Gauntlet, Raptor, or ANS in the other representing the proxy
> > What I would like is some specific vulnerability that I cannot
> > myself from using the SPF as opposed to the proxy approach. Again
> > for emphasis, I am interested in specific vulnerabilities not just
> > restatement that in theory proxies are better because they deal with
> > protocol at the application layer. My somewhat cynical hypothesis,
> > proven wrong with specific example, is that the majority of proxies
> > really not better and in fact may be no more than an disguised SPF
> > address translation.
> I gave an example earlier of smapd, and the capabilities it presents.
Let me continue to be a contrarian and claim that mail, like other
applications, should not necessarily be handled at all at the
firewall. A firewall is first and foremost an access control device,
and running an application (even a simple mail forwarder, like smap)
is not an optimal use of the firewall. I feel much the same way
about http proxying and filtering.
> How about strong authentication at the firewall? Presenting a POP3
> interface that uses APOP?
How about strong authentication? Firewall-1 has offered SecurID
authentication for quite a while now. And I'd rather not have my
firewall present a POP3 interface at all, thank you. APOP or no
APOP, POP3 isn't exactly a model citizen as a protocol.
> Specific vulnerabilities include buffer overflows in your MTA allowing
> /bin/sh to be executed as that UID. How about the IMAP and POP3 holes
> that were recently published. You could not have exploited these on a
> application based IMAP or POP3 proxy.
You could not exploit them on an SPF, either, since it wouldn't be
running the MTA. This (to me) falls into the category of not
neglecting security on internal systems just because you have
a firewall in place.
> Any buffer overlfow or other exploit that would involve the execution
> /bin/sh(or other shell) via a overflow in a network accesable deamon
> (let's say your POP3 or sendmail deamon) would be foiled by an
> application level. This assumes that it is a true application level
> proxy, like smapd for example from TIS. The reson for this is that
> packets are not passed from the attacker to the victim via the
> rather the attacker has to interact with the firewall, and the
> then sends seeprate application level requests to the internal machine
> perform the desired actions(assuming they fit wihtin the acceptable
> of actions).
Actually, I think you have it backward. We find ourselves in the
enviable position of having most of our proxy-based firewalls
written by good people who know what they're doing, thereby having
a lot of good proxies (smap being a fine example) to use as examples.
However, those proxies theoretically are prone to buffer overflow
attacks in the same way as the service daemons they're protecting
are. Since an SPF doesn't reassemble or interpret entire service
requests, it's immune to (for example) a buffer overflow attack
based on the way a particular SMTP command is interpreted.
> One thing to consider when it comes to application level proxies, is
> not all may perform the same level of 'proxying' as I described
> above(generating their own application level requests within a
> range and then packaging the response to send to the original
> requestor). Smapd does this on TIS, I am not sure if http-gw does.
I'd say that a proxy that doesn't do that is hardly worth the name.
Sr. Technology Advisor