Re: Open source firewalls

[RVK <rvk@prodmail.net>]

I don't think buffer overflow has anything to do with transparent proxy. 
Transparent proxying is just doing some protocol filtering. Still the 
proxy code may have some buffer overflows. The best way is first to try 
avoiding any buffer overflows and take programming precautions. Other 
way is to chroot the services, if running it on a firewall. There are 
various mechanisms which can be used like bounding the memory region it 
self. Stack Randomisation and Canary based approaches can also avoid any 
buffer overflow attacks.
IDS runs on L7, best example is snort. Its not possible for IDS to 
detect these attacks accurately.

rvk

Helge Hafting wrote:

> Vinay Venkataraghavan wrote:
>
>> I know how to implement buffer overflow attacks. But
>> how would an intrusion detection system detect a
>> buffer overflow attack.
>>
> Buffer overflow attacks vary, but have one thing in common.  The
> overflow string is much longer than what's usual for the app/protocol in
> question.  It may also contain illegal characters, but be careful -
> non-english users use plenty of valid non-ascii characters in filenames,
> passwords and so on.
>
> The way to do this is to implement a transparent proxy module for every
> protocol you want to do overflow prevention for.  Collect the strings
> transmitted, pass them on after validating them.  Or reset the
> connection when one gets "too long".  For example, you may want to
> limit POP usernames to whatever the maximum username length is
> on your system.  But make such things configurable, others may
> want longer usernames than you.
>
>> My question is at the layer
>> that the intrusion detection system operates, how will
>> it know that a particular string for exmaple is liable
>> to overflow a vulnerable buffer.
>>
>>
>>
> It can't know of course, but it can suspect that 1000-character
> usernames, passwords or filenames is foul play and reset the
> connection.  Or 10k URL's . . .
>
> Helge Hafting
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> .
>