Re: Open source firewalls

[Helge Hafting <helge.hafting@aitel.hist.no>]

RVK wrote:

> Proxies can be a good way of filtering but it can't avoid buffer 
> overflows. 

Yes they can - did you read and udnerstand my previous post at all?
A proxy _can_ avoid a buffer overflow by noticing the
anomalously large data item and simply refuse to pass
it on to the real server!  The proxy can terminate the tcp
connection and throw away the data.

> It can only increase it. More code more bugs. 

Of course the proxy can be buggy too, but it is easier to
avoid problems there:
1. The server was written to perform a service, perhaps with
    security thrown in later.  (Yes, that's bad design.)
    A firewall proxy is written for security, so buffer overflows
    are usually avoided in the firewall proxy itself.  Because this
    is exactly what the firewall writer is thinking about.
2. The proxy may be much smaller and simpler than the server
    it protects, it is therefore much easier to audit for security
    problems.
3. Fixing the server is indeed best, but not necessarily an option.
    It could be proprietary, or written in a unknown language.

> If it is running on a hardware firewall as a service then its more

"Hardware firewall" ???

> dangerous as once it is compramised then IDS signatures also can be 
> deleated :-). No use of IDS the right ?

A compromised firewall is of no use - sure.  So what? That applies
to any firewall, any IDS, or any server for that matter.

> So the best way is either make your code free of buffer overflows or

Yes, but the server may not be "my code" at all.  Can't you see that
problem?  It may very well be someone elses code.  I may not have the
source, or the source may be useless for a number of reasons,
such as:
1. being written in a language I don't understand
2. Have a licence that forbids change
3. Need compilers/tools I don't have
4. Being such a nasty mess that writing a proxy is much easier
    than fixing the bloated ill-designed server code one
    unfortunately depends on for the time being.

In these cases, I can still protect my server with a proxy firewall,
although I can't fix the server itself.

> use some library which controls the attack during any buffer overflow 
> or use Stack Randomisation and Canary based approaches.

A library that controls any buffer overflow doesn't exist at all.

Stack randomization helps but don't solve all cases, the attacker
simply need code to search for randomly moved parts he need, pad with
a few megabytes of NOPs and things like that.  Of course, a proxy
can easily detect megabytes of NOPs and kill that connection . . .

Helge Hafting