public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: RVK <rvk@prodmail.net>
To: Helge Hafting <helge.hafting@aitel.hist.no>
Cc: Vinay Venkataraghavan <raghavanvinay@yahoo.com>,
	linux-crypto@nl.linux.org, linux-kernel@vger.kernel.org
Subject: Re: Open source firewalls
Date: Thu, 14 Jul 2005 17:50:57 +0530	[thread overview]
Message-ID: <42D658A9.7050706@prodmail.net> (raw)
In-Reply-To: <42D658A8.4040009@aitel.hist.no>

Proxies can be a good way of filtering but it can't avoid buffer 
overflows. It can only increase it. More code more bugs. If it is 
running on a hardware firewall as a service then its more dangerous as 
once it is compramised then IDS signatures also can be deleated :-). No 
use of IDS the right ?
So the best way is either make your code free of buffer overflows or use 
some library which controls the attack during any buffer overflow or use 
Stack Randomisation and Canary based approaches.

rvk

Helge Hafting wrote:

> RVK wrote:
>
>> I don't think buffer overflow has anything to do with transparent
>> proxy. Transparent proxying is just doing some protocol filtering.
>
>
> A transparent proxy is a protocol filter, which is why it is an
> ideal way of detecting protocol-dependent buffer overflow attacks.
>
> The detection code have to be built into the proxy, of course.
>
> Examples:
> A web proxy can check for anomalous long "get" request,
> there have been web servers with buffer overflows when the
> URL was too long.  The proxy can terminate such connections,
> protecting the possibly vulnerable webserver.
>
> An ftp proxy can check for (and remove) anomalous long filenames,
> as well as funnies like "ls */*/*/*/*/*"
>
> Similiar for many other services.  The proxy approach is useful
> because knowledge of the protocol is necessary.  After all,
> it is ok to up/download a huge file via ftp, while a 2M filename
> is suspicious.  Size alone is not enough.
>
>> Still the proxy code may have some buffer overflows.
>
>
> A proxy (or any other attempt at a firewall) may have its own
> holes of course, but avoiding making them isn't that hard.
>
>
>> The best way is first to try avoiding any buffer overflows and take
>> programming precautions.
>
>
> Of course, if you have the source and that source isn't an
> unmaintainable mess.  One or both of those conditions may fail,
> and then the IDS becomes useful.
>
>> Other way is to chroot the services, if running it on a firewall.
>
>
> Provided it is an unixish server . . .
>
>> 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.
>
>
> These may or may not be available.  You can always stick a proxy
> firewall in front of the server though, no matter what os and
> server apps it runs.
>
> Helge Hafting
> .
>


  reply	other threads:[~2005-07-14 12:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-13 16:34 Open source firewalls Vinay Venkataraghavan
2005-07-13 16:47 ` Alejandro Bonilla
2005-07-13 17:00   ` Maciej Soltysiak
2005-07-13 17:04 ` Nigel Rantor
2005-07-14 10:13 ` Helge Hafting
2005-07-14 10:24   ` RVK
2005-07-14 12:20     ` Helge Hafting
2005-07-14 12:20       ` RVK [this message]
2005-07-14 13:06         ` Helge Hafting
2005-07-14 14:04           ` RVK
2005-07-14 22:53         ` Buffer Over-runs, was " Brian O'Mahoney
2005-07-15  6:41           ` RVK
2005-07-15  6:51             ` Arjan van de Ven
2005-07-15  8:26               ` RVK
2005-07-15  8:46                 ` Arjan van de Ven
2005-07-15  9:28                   ` RVK
2005-07-15  9:29                   ` RVK
2005-07-15 11:17                   ` RVK
2005-07-15 11:24                     ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42D658A9.7050706@prodmail.net \
    --to=rvk@prodmail.net \
    --cc=helge.hafting@aitel.hist.no \
    --cc=linux-crypto@nl.linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raghavanvinay@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox