headers
Rocky Olsen | 1 Apr 12:07

Re: SecChrootDir in vhost?

Herm, Bugger.

Well i guess the question to be asked is, does anyone know of a way to
chroot apache inside <VirutalHost>'s. Say when a connection comes in for a
vhost and the parent process spawns the child to handle it, that child
chroot's itself in the vhost's directory?

realize it's a bit off topic for this list, but might as well ask.

-Rocky

--

-- 
______________________________________________________________________

what's with today, today?

Email:	rocky <at> mindphone.org
PGP:	http://rocky.mindphone.org/rocky_mindphone.org.gpg
Permalink | Reply | 1 comment |
headers
Ivan Ristic | 4 Apr 10:52
Gravatar

Re: Re: SecChrootDir in vhost?

Rocky Olsen wrote:
> Herm, Bugger.
> 
> Well i guess the question to be asked is, does anyone know of a way to
> chroot apache inside <VirutalHost>'s. Say when a connection comes in for a
> vhost and the parent process spawns the child to handle it, that child
> chroot's itself in the vhost's directory?

   For that to happen you would need to run Apache as root, perform
   chroot and suid on every request, and configure children to die
   after serving only one request. It's perfectly possible, but would
   probably suffer a performance penalty. There are suid modules
   around, but I haven't heard of one that allows chroot too.

   But you can do the following:

   Run a separate Apache instance for each <VirtualHost>, chrooted
   and running as the user. Install one Apache instance in front
   and use it as a reverse proxy. This is a very secure and flexible
   solution but it requires a lot of memory. It is thus only suitable
   when there is a small number of virtual hosts.

--

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roman Medina-Heigl Hernandez | 4 Apr 13:34
Gravatar

Rules database

Hi,

I'm interested in protecting webapps in a "generic way" (more or less
:-)), which means that if I choose to install a PHP-Nuke portal and a
new SQL injection bug in that portal is disclosed, it will not be
exploitable (the code would still be buggy until patching, but that's
unavoidable). Of course, the idea is to catch the more kind of bugs
being possible (not only SQL injection, but directory traversal, remote
PHP script injection, shell injection, etc).

I visited:
http://www.modsecurity.org/db/rules/
But I got a bit disappointed when I saw only 4 rules :-(. The db seems
to be discontinued... ?

I'm wondering whether:
1) There are other "repositories" for mod-security rules, or
2) Some of you, security-specialists, would be kind enough to share the
rules you have, ideas, etc.

Other repositories (not direcly related to Mod-security but perhaps
easily "convertible" to; for instance, rules from other IPS devices) may
also be interesting.

Hope hearing from you, guys :-)

Kind regards,
-Román

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 13 comments |
headers
Gerwin Krist -|- Digitalus Webhosting | 4 Apr 15:43
Picon
Favicon
Gravatar

Re: Rules database


Hello Román,

You could try http://www.gotroot.com/downloads/ftp/mod_security/rules.conf
It has a LOT of rules.
Hope it's helpfull.

Gerwin

Roman Medina-Heigl Hernandez wrote:
| Hi,
|
| I'm interested in protecting webapps in a "generic way" (more or less
| :-)), which means that if I choose to install a PHP-Nuke portal and a
| new SQL injection bug in that portal is disclosed, it will not be
| exploitable (the code would still be buggy until patching, but that's
| unavoidable). Of course, the idea is to catch the more kind of bugs
| being possible (not only SQL injection, but directory traversal, remote
| PHP script injection, shell injection, etc).
|
| I visited:
| http://www.modsecurity.org/db/rules/
| But I got a bit disappointed when I saw only 4 rules :-(. The db seems
| to be discontinued... ?
|
| I'm wondering whether:
| 1) There are other "repositories" for mod-security rules, or
| 2) Some of you, security-specialists, would be kind enough to share the
| rules you have, ideas, etc.
|
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alberto Gonzalez Iniesta | 4 Apr 14:35
Favicon

Re: Rules database

On Mon, Apr 04, 2005 at 01:34:30PM +0200, Roman Medina-Heigl Hernandez wrote:
> I'm wondering whether:
> 1) There are other "repositories" for mod-security rules, or

You can try at:
http://modsecrules.monkeydev.org/index.php
It's quite new, but growing fast.

Regards,

Alberto

--

-- 
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
Permalink | Reply | 0 comments |
headers
Roman Medina-Heigl Hernandez | 4 Apr 16:14
Gravatar

Re: Rules database

Gerwin Krist -|- Digitalus Webhosting wrote:

> You could try http://www.gotroot.com/downloads/ftp/mod_security/rules.conf

It looks nice. But it seems to be having problems in Apache 1.x
(according to the comments). Do you know if they've been fixed? I also
read one thread at gotroot.com but it didn't contain specific info about
the issue.

I still have to review the link provided by Alberto (my proxy doesn't
load it, I'll try again l8r).

Thanks to both, Gerwin & Alberto :-)

Regards,
-Román

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
Permalink | Reply | 3 comments |
headers
Ivan Ristic | 4 Apr 16:33
Gravatar

Re: Rules database

Roman Medina-Heigl Hernandez wrote:
> I visited:
> http://www.modsecurity.org/db/rules/
> But I got a bit disappointed when I saw only 4 rules :-(. The db seems
> to be discontinued... ?

   It never took off. At the last minute I decided a repository
   of rules that worked only in mod_security was not the best
   way forward. Instead, I designed the portable web application
   firewall rule format http://www.modsecurity.org/projects/wasprotect/.

   The plan is to implement a portable rule database in Q3 this year,
   with the support of other web application firewall vendors.

   To be honest, there was another reason - I spent eight months last
   year writing the book, so I didn't have time to do anything else.

--

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 4 comments |
headers
Christian Martorella | 4 Apr 16:27

Re: Rules database

Hi Roman:
When i tried the modsecurity, i used a script to convert snort rules to 
modsecurity rules, maybe you could do that to initialize your rules 
database, and then optimize the set of rules.

Here is the link:
http://www.modsecurity.org/documentation/converted-snort-rules.html

Cheers
Christian Martorella

Roman Medina-Heigl Hernandez wrote:

>Hi,
>
>I'm interested in protecting webapps in a "generic way" (more or less
>:-)), which means that if I choose to install a PHP-Nuke portal and a
>new SQL injection bug in that portal is disclosed, it will not be
>exploitable (the code would still be buggy until patching, but that's
>unavoidable). Of course, the idea is to catch the more kind of bugs
>being possible (not only SQL injection, but directory traversal, remote
>PHP script injection, shell injection, etc).
>
>I visited:
>http://www.modsecurity.org/db/rules/
>But I got a bit disappointed when I saw only 4 rules :-(. The db seems
>to be discontinued... ?
>
>I'm wondering whether:
>1) There are other "repositories" for mod-security rules, or
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Anderson | 4 Apr 16:49
Favicon

Re: Rules database

----- Original Message ----- 
From: "Ivan Ristic" <ivanr <at> webkreator.com>
To: <mod-security-users <at> lists.sourceforge.net>
Sent: Monday, April 04, 2005 10:33 AM
Subject: Re: [mod-security-users] Rules database

> Roman Medina-Heigl Hernandez wrote:
>> I visited:
>> http://www.modsecurity.org/db/rules/
>> But I got a bit disappointed when I saw only 4 rules :-(. The db seems
>> to be discontinued... ?
>
>   It never took off. At the last minute I decided a repository
>   of rules that worked only in mod_security was not the best
>   way forward. Instead, I designed the portable web application
>   firewall rule format http://www.modsecurity.org/projects/wasprotect/.

OMG, that looks horrible!  Please don't make that the only accepted format. 
I hate dealing with completely useless markup which can just as easily be 
implied.  It just clutters up the configuration with non-info and bloats 
your file sizes.  The best thing about working in unix environments is that 
everything is kept short and sweet.  Human readability is key.

SecFilterSelective "ARG_open" ^sesame$    (38 chars)

vs

<rule operator="regex" arg="params['open']" value="^sesame$" />    (63 
chars)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ivan Ristic | 4 Apr 17:08
Gravatar

Re: Rules database

Tom Anderson wrote:
 >
>>   It never took off. At the last minute I decided a repository
>>   of rules that worked only in mod_security was not the best
>>   way forward. Instead, I designed the portable web application
>>   firewall rule format http://www.modsecurity.org/projects/wasprotect/.
> 
> OMG, that looks horrible!

   :)

   It will look even worse when a layer of meta-data is added to it.

> Please don't make that the only accepted 
> format.

   ModSecurity will support both formats in version 2, so don't
   worry.

> Human readability is key.

   I agree.

> XML is good for sharing rules between systems, but not for human 
> maintained configs.

   Again, I agree. The new XML-based format was designed just for
   that purpose (sharing between systems), hence the added
   complexity.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane