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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|