Michael, you win the prize. This is exactly what I was speaking about. Most
answers were concerned about the proxy knowing the buffer sizes of the
internal hosts. However, what I have seen from my limited breath of
experience with proxies acrossed platforms is that there are common buffer
sizes for protocol elements. This is either by standard or by convention.
Like much of Unix, network apps such as finger have common roots and so they
will may have the common buffer sizes.
The discussion now can get down to "no they don't" and "yes they do" but I
would rather not. I was just bringing up one example of a possible
natural protection provided by proxies that you may not find in an SPF.
By their nature proxies actually parse and process the protocol data (to some
extent) and this may cause some attacks to be stopped by the proxy.
For those who said they feel this is more an end host problem. I am a stong
advocate for security in depth and I say provide levels of security wherever
you can. Thanks to everyone who participated in this discussion. If there
are examples of other natural protections offered by proxies I would be
interested to hear of them.
>
> On Sun, 30 Jun 1996, Darren Reed wrote:
>
> > > The person who posted the question was under the impression that SPF couldn't
> > > but proxies could. I believe that neither can effectivly protect from that
> > > type of attack,
> > > because it requires very specific knowledge about the platform in question on
> > > the
> > > inside.
>
> > But, in both cases, you must somehow put the knowledge about what is good
> > and bad in the proxy/filter code.
> >
> > It doesn't require any knowledge about the interior platforms which it is
> > attempting to protect.
>
> All of this discussion about buffer overruns seems to be skirting the
> issue.
>
> A. many protocols have defined maximum lengths for various fields
> transferred within those protocols.
>
> B. Often implementors of a protocol inadvertently expose their products to
> misuse by not checking those maximums.
>
> C. Often hackers break into servers by means of exploiting a buffer
> overrun in a flawed server application.
>
> D. There is no technical reason why a firewall proxy could not examine
> the data flowing through it and ensure that all fields are within the
> maximums defined for the protocol by truncating the field and logging
> the event.
>
> E. I don't know enough about stateful packet filters but they may be able
> to do the same as proxies.
>
> F. If we assume that the applications server has been proven to operate
> correctly within the protocol specification by running some sort of
> test suite (a rather common occurence these days) then the proxy would
> provide a greatly reduced level of risk by preventing these buffer
> overrun attacks.
>
> G. Nothing is perfect, the solution I propose is certainly not perfect,
> but I think it moves in the right direction and does not increase
> any security risks or negatively impact the operation of the firewalls
> or the applications.
>
>
> Michael Dillon ISP & Internet Consulting
> Memra Software Inc. Fax: +1-604-546-3049
> http://www.memra.com E-mail: michael @
memra .
com
>
>
>
--
Ron Sharp
Internet address: r .
l .
sharp @
att .
com
|
|
