Squirrelmail problem.

Re: Squirrelmail problem.

toby <at> ketoe.co.uk wrote:
> Hi

   Hi Toby,

> I have recently installed mod_security on my Apache 2.0 server and it 
> works very well.  However, I am having a major problem getting 
> Squirrelmail to work.  I can log in, read emails but any attempt to send 
> results in mod_security blocking the request with the default 500 message.
> 
> I have scoured the Internet and found no-one with the same problem and 
> no solution.
> 
 > ...
 >
> As you can see I am relatively new to this and am looking for someone 
> who can simply point me in the right direction.  I have been through the 
> FAQ, the manual and any other resource I could find.

   From the log samples you provide, it seems like your mod_security
   configuration contains a few rules from the regression tests. So the
   solution is simple - just remove them :)

 > I inserted the rule SecFilter "/squirrelmail/" allow

   What you really want is:

   # disable mod_security for Squirrel mail
   <Location /squirrelmail/≥
       SecFilterEngine Off
   </Location>

Bye,
Ivan

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

RE: Squirrelmail problem.

Ivan

Thanks, that's cured it!

toby

-----Original Message-----
From: mod-security-users-admin <at> lists.sourceforge.net
[mailto:mod-security-users-admin <at> lists.sourceforge.net] On Behalf Of Ivan
Ristic
Sent: 02 May 2005 19:38
To: mod-security-users <at> lists.sourceforge.net
Subject: Re: [mod-security-users] Squirrelmail problem.

toby <at> ketoe.co.uk wrote:
> Hi

   Hi Toby,

> I have recently installed mod_security on my Apache 2.0 server and it
> works very well.  However, I am having a major problem getting 
> Squirrelmail to work.  I can log in, read emails but any attempt to send 
> results in mod_security blocking the request with the default 500 message.
> 
> I have scoured the Internet and found no-one with the same problem and
> no solution.
> 
 > ...
 >
> As you can see I am relatively new to this and am looking for someone
> who can simply point me in the right direction.  I have been through the 
> FAQ, the manual and any other resource I could find.

   From the log samples you provide, it seems like your mod_security
   configuration contains a few rules from the regression tests. So the
   solution is simple - just remove them :)

 > I inserted the rule SecFilter "/squirrelmail/" allow

   What you really want is:

   # disable mod_security for Squirrel mail
   <Location /squirrelmail/≥
       SecFilterEngine Off
   </Location>

Bye,
Ivan

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win
an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
mod-security-users mailing list mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 

Re: Tokens?

Ivan Ristic wrote:

> Christian Martorella wrote:
>
>> Hi, i was looking others Application firewalls and i saw that some of 
>> them use tokens to sign forms or variables with a hash.
>
>
>   Can you be more specific? What are they signing? The hidden fields,
>   the names of the fields?
>
>
What you sign with a hash is the values of the hidden fields, or the 
values of the URL parameters.
For example if you have 

        <input name="year" type="hidden" 
value="1984?MSEC=OurhashOurhashOurHash">
So if someone change 1984 to 1982, when you recalculate the hash for 
year it will be different and you deny the request.

I know this would bring more performance issues, but it will be good for 
Parameter Tampering, Cookie Tampering, and all tampering that could be done.

>> There are plans to implement this on Mod_Security?  or there is 
>> someone already working on it?
>
>
>   No. I am not convinced such feature would have significant value in
>   real life. I can see how it can help in a specific case (e.g. when
>   someone has an app with a hidden field that should never change). But
>   I do not think it can work as a generic protection measure people can
>   turn on and forget about it. In this day and age many applications are
>   creating forms dynamically at runtime, and using JavaScript to change
>   the values in the hidden fields.
>
Maybe you are right, but what about cookies? or session Ids? or url 
parameters that if you change a value you will be take to a private zone 
for example..? My examples are for badly designed applications
that a company couldnt secure.

I just was seeing what other Application Firewalls were doing, and i 
found this functionality.

Cheers!

-- 
_________________________________
Christian Martorella
e-Security Engineer
cmartorella <at> isecauditors.com

Internet Security Auditors, S.L.
c. Santander, 101. Edif. A. 2º 1ª.
08030 Barcelona
Tel: 93 305 13 18
Fax: 93 278 22 48
www.isecauditors.com
          ____________________________________
Este mensaje y los documentos que, en su caso lleve anexos, pueden
contener información confidencial. Por ello, se informa a quien lo
reciba por error que la información contenida en el mismo es reservada
y su uso no autorizado está prohibido legalmente, por lo que en tal
caso le rogamos que nos lo comunique por la misma vía o por teléfono
(93 305 13 18), se abstenga de realizar copias del mensaje o remitirlo
o entregarlo a otra persona y proceda a borrarlo de inmediato.

En cumplimiento de la Ley Orgánica 15/1999 de 13 de diciembre de
protección de datos de carácter personal, Internet Security Auditors
S.L., le informa de que sus datos personales se han incluido en
ficheros informatizados titularidad de Internet Security Auditors
S.L., que será el único destinatario de dichos datos, y cuya finalidad
exclusiva es la gestión de clientes y acciones de comunicación
comercial, y de que tiene la posibilidad de ejercer los derechos de
acceso, rectificación, cancelación y oposición previstos en la ley
mediante carta dirigida a Internet Security Auditors, c. Santander,
101. Edif. A. 2º 1ª, 08030 Barcelona, o vía e-mail a la siguiente
dirección de correo: legal <at> isecauditors.com

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 

mod_ssl: Child could not open SSLMutex lockfile

Re: mod_ssl: Child could not open SSLMutex lockfile

Hi TIA,

I could be on the wrong track, but I think I was getting this error until I
created the directory 

/chroot/apache/usr/local/apache/logs/ssl_scache

where the chroot is to /chroot/apache

If I remember correctly, Apache wants to write there after the chroot has taken
place, by which time it cannot open new files in the log directory in the main
file system. Ensure Apache has write permissions even if the directory
already exists.

It's a while since I had the problem so I could have this wrong, but it might
help.

David

>Subject: [mod-security-users] mod_ssl: Child could not open SSLMutex lockfile
>Reply-To: mod-security-users <at> lists.sourceforge.net
>
>------=_Part_2042_9626190.1115640236279
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>
>Hi guys,
>
>When I chroot my Apache 1.3.x with mod_security, it kept reporting that=20
>error. I have searched through this list and found that this error had been=
>=20
>reported one but still there is no solution rite?=20

--

-- 
---------------------------------------
Email david <at> megapico.co.uk
---------------------------------------

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: Re: mod_ssl: Child could not open SSLMutex lockfile

Re: Re: mod_ssl: Child could not open SSLMutex lockfile

Re: Re: mod_ssl: Child could not open SSLMutex lockfile

Re: mod_security v1.8.4 Chroot problem

I've got mod_security 1.8.4 with just the chroot function, httpd 1.3.31, and
frontpage 2002.  It works fine without chroot.  I haven't tested with suexec
yet.  With chroot enabled, I'm having troubles with the suidkey.

With mod_frontpage being loaded *before* mod_security, and with /bin/ps and
/usr/bin/sum and /proc inside the chroot, frontpage properly creates its
suidkey.$PID inside the chroot.  fpcounter.exe appears to function, but with the
counter reset to 1, never incrementing.  There are no errors in error_log either
of the main server or of the vhost in question.  It's as is mod_frontpage
believes that it's working, and yet it's apparently not with fpcounter.exe.  The
administrative web GUI works.  fpcounter.exe and the administrative web GUI are
the only items I've tested it with.

Please see my strace output at http://smuckola.org/etc/httpd_strace.text

Do you have any clues or suggestions?

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click