mod-security-users — General discussion about mod_security

[mod-security-users] Re: HTTPD Dos

[David F. <Da...@me...>]

On Fri, 12 Nov 2004 20:23:12 -0800
mod...@li... wrote:

> Subject: [mod-security-users] HTTPD Dos
> 
> Hello there,
> 
> One of our servers is being ddossed (httpd based), 100ths of clients are
> trying to download 1 certain file. My question, is it possible
> to filter on the download and put the the ip in an iptables rule?
> 
> Regards,
> Gerwin

Hi,

I have been getting attacks with over 1000 per second requests like this:

default.domain 141.150.49.213 - - [04/Nov/2004:09:30:52 +0000] "OPTIONS /
HTTP/1.1" 403 266 "-" "Microsoft-WebDAV-MiniRedir/5.1.2600" (-)

They seem to have stopped before I did anything about them, but I was
looking at mod_dosevasive available here:

http://www.nuclearelephant.com/projects/dosevasive/

It doesn't look like its been developed in over a year (perhaps it doesn't
need it?) but it might be useful. I wonder if there is any case for
integrating it with mod_security?

Another approach in this case will be just to block OPTIONS requests, but
other DOS attacks might not use this request method.

David.

-- 
-------------------------------------------------
Email: Da...@me...
-------------------------------------------------

Re: [mod-security-users] help with rule

[Ivan R. <iv...@we...>]

modsecurity wrote:

> I'm trying to block clients from using web based scripts to send mail from *@paypal.com or with the realname of paypal. This is what the post looks like:
> 
> -----------------------------7d43991d691196
> Content-Disposition: form-data; name="from"
> 
> bi...@pa...
> -----------------------------7d43991d691196
> Content-Disposition: form-data; name="realname"
> 
> paypal
> 
> Since the name="from" and the bi...@pa... are not on the same line I'm having a little trouble with this. Can anyone give me a clue as to how this can be done?

  You don't need to concern yourself with how the data is laid out in a
  request, mod_security takes care of that for you (I am assuming you
  are running 1.8.x). Just tell it which parameters to look for:

  SecFilterSelective ARG_from @paypal\.com$
  SecFilterSelective ARG_realname paypal

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] help with rule

[modsecurity <mod...@ez...>]

I'm trying to block clients from using web based scripts to send mail =
from *@paypal.com or with the realname of paypal. This is what the post =
looks like:

-----------------------------7d43991d691196
Content-Disposition: form-data; name=3D"from"

bi...@pa...
-----------------------------7d43991d691196
Content-Disposition: form-data; name=3D"realname"

paypal

Since the name=3D"from" and the bi...@pa... are not on the same =
line I'm having a little trouble with this. Can anyone give me a clue as =
to how this can be done?

[mod-security-users] Help with rule

[<da...@ez...>]

I'm trying to block clients from using web based scripts to send mail =
from *@paypal.com or with the realname of paypal. This is what the post =
looks like:

-----------------------------7d43991d691196
Content-Disposition: form-data; name=3D"from"

bi...@pa...
-----------------------------7d43991d691196
Content-Disposition: form-data; name=3D"realname"

paypal

Since the name=3D"from" and the bi...@pa... are not on the same =
line I'm having a little trouble with this. Can anyone give me a clue as =
to how this can be done?
=20

Re: [mod-security-users] HTTPD Dos

[Ivan R. <iv...@we...>]

Gerwin Krist -|- Digitalus Webhosting wrote:
> Hello there,
> 
> One of our servers is being ddossed (httpd based), 100ths of clients are
> trying to download 1 certain file. My question, is it possible
> to filter on the download and put the the ip in an iptables rule?

  Are the IP addresses constantly changing? I wrote some scripts for the
  book, available here http://www.apachesecurity.net/, that might be
  able to protect you automatically from that sort of attack.

  The blacklist script is a dynamic iptables firewall. You can tell it
  which IP address to block and for how long.

  The apache-protect script will watch mod_status output and count the
  number of identical requests coming from one IP address and invoke
  the blacklist script to ban the addresses that reach the threshold.

  Finally, blacklist-webclient can be invoked from mod_security via the
  exec action, if you so wish.

  Just be careful not to block legitimate users :)

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] HTTPD Dos

[Gerwin K. -|- D. W. <ge...@di...>]

Hello there,

One of our servers is being ddossed (httpd based), 100ths of clients are 
trying to download 1 certain file. My question, is it possible
to filter on the download and put the the ip in an iptables rule?

Regards,
Gerwin

[mod-security-users] [ANNOUNCE] mod_security 1.8.6 released

[Ivan R. <iv...@we...>]

Mod_security 1.8.6 has been released. It is available for immediate
download from:

   http://www.modsecurity.org/download/

This maintenance release relaxes several minor problems discovered
in 1.8.5. A minor improvement was made to make detection-only
deployment of mod_security easier. Please see the changes below
for more details.

About mod_security
------------------
Mod_security is an Apache module whose purpose is to protect
vulnerable applications and reject human or automated attacks.
It is an open source intrusion detection and prevention system
for Apache. In addition to request filtering, it also creates Web
application audit logs. Requests are filtered using regular
expressions. Some of the things possible are:

 * Apply filters against any part of the request (URI,
   headers, either GET or POST)
 * Apply filters against individual parameters
 * Reject SQL injection attacks
 * Reject Cross site scripting attacks

With few general rules mod_security can protect from both
known and unknown vulnerabilities.


Changes (v1.8.6)
----------------

  * Made changes to accommodate those who only want to operate
    in detection mode. Validation checks (e.g. byte range) are
    now performed only at the beginning of request processing (by
    mod_security, not Apache). At the same time I have expanded
    the validation checks to include request headers as well. Which
    means all request data will be validated. Normalisation (e.g.
    URL decoding, and other anti-evasion actions) is still performed
    for every variable in a rule, as usual.

    There is one constraint to have in mind for detection-only
    deployments, though. Non-fatal default action (e.g. "log,pass"
    is not allowed in the initialization phase. All validation
    problems will result in request rejected. Therefore the only
    way to operate in a fully transparent detection mode is to turn
    off implicit validation options (URL decoding, Unicode, byte
    range, cookie format validation).

  * BUG Fixed the broken "skip" action.

  * BUG Fixed a problem with file interception (when either file
    storage or approval is enabled) that used to occur with IE.

  * BUG I introduced a new bug to 1.8.5 while fixing a bug from
    1.8.4. Uploading a file larger than the memory buffer would
    cause the approval phase to be skipped altogether (Apache 2
    only). Fixed.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Generate Nessus rules for mod_security

[Javier Fernandez-S. <jfe...@ge...>]

> 
>   Thanks Javier, I will test the script and the generated rules
>   next week. I will be happy to include your script into the
>   distribution if you are happy with the GPL licence. Please let
>   me know.
> 

Sorry, I forgot to the add the appropiate license to the file. Of 
course, its GPLd. Feel free to add it to the distribution.

Regards

Javier

Re: [mod-security-users] questions about chrooting

[Ivan R. <iv...@we...>]

posorio7 wrote:
> Thanks for your help, I managed to get apache running in jail. Now my
> problem is with my account files for the websites. It's looking for
> them in /chroot/apache/home/[username]/public_html. I tried doing a
> symlink from /chroot/apache/home to the real /home and when I loaded
> up my sites it game me a 403 forbidden error. It finds the files but
> does not have access to them. What can I do to correct this?

  I don't think it finds the files because it is not possible
  to create symbolic links that would go outside the jail. Perhaps
  the message is because of incorrect permissions of /home, or
  something like that.

  You'll have to put the account files into the jail in order for
  Apache to be able to reach them.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] Generate Nessus rules for mod_security

[Ivan R. <iv...@we...>]

Javier Fernandez-Sanguino wrote:

> In the line of the snort2modsec script I've written a nessus2modsec
> script. There are some differences between both (there are now so many
> Nessus plugins, for example, that it is necessary to provide the
> directory as an argument instead of plugins/*)
> 
> Attached is both the script (comments and testing welcome!) and rules
> generated based on the latest Nessus plugins.

  Thanks Javier, I will test the script and the generated rules
  next week. I will be happy to include your script into the
  distribution if you are happy with the GPL licence. Please let
  me know.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] questions about chrooting

[Ivan R. <iv...@we...>]

posorio7 wrote:

> Hello, I'm having a hell of a time trying to get apache to run in jail
> using mod_security. Using Fedora Core 1, Apache 1.3.32, mod_security
> 1.8.5, and mod_ssl.
> 
> First of all, what should the chroot path be exactly? Should it be
> under the users (/home) or elsewhere? What directories, if any, do I
> need to create there, and do I need to chmod anything?

  We can't give you a definite answer. You can use anything as the
  chroot path as long as you configure everything else properly.

  Below is a step-by-step guide that worked for me.

-----------------------------------------------
   1. Installed Apache + mod_ssl to /usr/local/apache

   2. Made sure it works

   3. Downloaded mod_security from the web site and
      did: /usr/local/apache/bin/apxs -cia mod_security.c

   4. /usr/local/apache/bin/apachectl stop

   5. Changed the module order, as per the manual. It now
      looks like this:

--
ClearModuleList
AddModule mod_security.c
AddModule mod_env.c
AddModule mod_log_config.c
AddModule mod_mime.c
AddModule mod_negotiation.c
AddModule mod_status.c
AddModule mod_include.c
AddModule mod_autoindex.c
AddModule mod_dir.c
AddModule mod_cgi.c
AddModule mod_asis.c
AddModule mod_imap.c
AddModule mod_actions.c
AddModule mod_userdir.c
AddModule mod_alias.c
AddModule mod_rewrite.c
AddModule mod_access.c
AddModule mod_auth.c
AddModule mod_so.c
AddModule mod_setenvif.c
AddModule mod_ssl.c
--

   6. mkdir -p /chroot/apache/usr/local

   7. mv /usr/local/apache /chroot/apache/usr/local

   8. cd /usr/local; ln -s /chroot/apache/usr/local/apache

   9. Configured mod_security with:
      SecChrootDir /chroot/apache

  10. /usr/local/apache/bin/apachectl startssl

  It works!  :)
-----------------------------------------------


> Next is with mod_ssl. 
> I get this error many times (several times per second actually) when
> restarting with the chroot enabled:
> 
> [error] mod_ssl: Child could not open SSLMutex lockfile
> /usr/local/apache/logs/ssl_mutex.15168 (System error follows)
> [error] System: No such file or directory (errno: 2)

  The path /usr/local/apache/logs/ does not exist in the jail. E.g.
  if your chroot path is /chroot you need to make sure
  /chroot/usr/local/apache/logs exists.

  You also need to take care about the module ordering (if you haven't
  done that already) as documented in the manual.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] How to filter this?

[Ivan R. <iv...@we...>]

sam wun wrote:

> Hi,
> 
> Recently my website received alot of buffer overflow attacks with the
> following content:
> 1.2.3.4 - - [25/Oct/2004:10:05:34 +0800] "SEARCH
> /\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x
> 02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\
> 
> x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1 ....
> ...
> 
> 
> The apache has plugins mod_security and mod_filter compiled with.
> How can I implement rules to filter the above attack?

  You can't, at least not with mod_security, because Apache responds
  to the request before mod_security gets to see it. You can try
  with mod_rewrite (I haven't so I don't know if it would work)
  or you can use custom logging to remove such things from your
  logs. See here for more details:

http://sourceforge.net/mailarchive/forum.php?thread_id=5595944&forum_id=33492

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] How to filter this?

[sam w. <sa...@au...>]

Hi,

Recently my website received alot of buffer overflow attacks with the
following content:
1.2.3.4 - - [25/Oct/2004:10:05:34 +0800] "SEARCH
/\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x
02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\ 

x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1 ....
...


The apache has plugins mod_security and mod_filter compiled with.
How can I implement rules to filter the above attack?

Thanks
Sam

[mod-security-users] questions about chrooting

[posorio7 <pos...@gm...>]

Hello, I'm having a hell of a time trying to get apache to run in jail
using mod_security. Using Fedora Core 1, Apache 1.3.32, mod_security
1.8.5, and mod_ssl.

First of all, what should the chroot path be exactly? Should it be
under the users (/home) or elsewhere? What directories, if any, do I
need to create there, and do I need to chmod anything?

Next is with mod_ssl. 
I get this error many times (several times per second actually) when
restarting with the chroot enabled:

[error] mod_ssl: Child could not open SSLMutex lockfile
/usr/local/apache/logs/ssl_mutex.15168 (System error follows)
[error] System: No such file or directory (errno: 2)

It goes away once I disable the chroot. Looking back in the mailing
list archive found a similiar problem but no confirmed solution. Any
help appreciated, thanks!

RE: [mod-security-users] RE: mod-security-users digest, Vol 1 #127 - 5 msgs

[Tkachenko A. <al...@tk...>]

Thank you.

-----Original Message-----
From: Ivan Ristic [mailto:iv...@we...] 
Sent: Friday, October 29, 2004 00:26
To: Tkachenko Alexei
Cc: mod...@li...
Subject: Re: [mod-security-users] RE: mod-security-users digest, Vol 1
#127 - 5 msgs



>>>I will release 1.8.6 early next week to fix another
>>> small issue that has just popped up.
> 
> My opinion: too hard to be updated so often.

  You don't need to upgrade every time there's a minor update
  available. Minor problems affect a small number of users,
  and they are usually discovered in parts of the code that
  are not used often.

  But if you are affected, the good news is you can.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] RE: mod-security-users digest, Vol 1 #127 - 5 msgs

[Ivan R. <iv...@we...>]

>>>I will release 1.8.6 early next week to fix another
>>> small issue that has just popped up.
> 
> My opinion: too hard to be updated so often.

  You don't need to upgrade every time there's a minor update
  available. Minor problems affect a small number of users,
  and they are usually discovered in parts of the code that
  are not used often.

  But if you are affected, the good news is you can.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[mod-security-users] RE: mod-security-users digest, Vol 1 #127 - 5 msgs

[Tkachenko A. <al...@tk...>]

>> * Reject Cross site scripting attacks

Can anybody give a good example?
Especially for:
	I have many requests like
http://URL?PARAMETER=http://atackersite/atackerpage&ANOTHERPARAMETER
where "http://atackersite/atackerpage" load some bad script from
outside.
	I can not block them by "=http://" filter because much clients
use such form in their work.

>> I will release 1.8.6 early next week to fix another
>>  small issue that has just popped up.

My opinion: too hard to be updated so often.



Alexey.

Re: [mod-security-users] slightly off-topic

[Joachim R. <jr...@we...>]

On Thu, Oct 28, 2004 at 04:42:13 -0400, Daniel Guido wrote:
> So far I'm thinking that once I own the box I do this: immediately 
> delete all the user accounts except root,

this will probably break some daemons running under low priv accounts -
too bad if you need to keep 'em up. I'd recommend to invalidate the
password for all accounts with one.

> rename the adduser binary to 
> something legit-looking yet entirely different 

if I have root, i can edit the files myself. if not, adduser will
usually not work anyways.

> and do the same for all 
> the shells (bash, csh, etc) installed on the system.

this could indeed help against people using standard shellcode - once it
gets known though, it's a trivial change to make it work again.

> Then, load up a 
> kernel module or some other reference monitor type app that watches our 
> 'flag' for modifications and restores it if it's modified.  

tripwire, don't know about kernel mod.

> Then of 
> course, immediately install some auto-update program (yum, apt-get, 
> portage, etc) and update all the services running and change their 
> configurations slightly to make them more secure (can't turn off 
> services).  

easily said, a lot harder to.

> Last, install ettercap on the owned box to capture and 
> report curious traffic going to and from the other servers in-play to 
> catch our opponents.

you might want to monitor for listening ports and/or firewall config too
with something and restore to known good when changed.

> If anyone knows some program that watches files like I described please 
> let me know, I'd rather not have to code that from scratch.
> 
> Can you think of a better strategy once we own a box?

make it really secure. unfortunately this involves major changes like
installing a kernel with pax and rsbac plus a sufficiently paranoid
policy and replacing everything with versions compiled with stackguard.
if something like that is well done, you can give people a rootshell and
still sleep well.

> Has anyone 
> participated in a CTF game before?  Any other tips?

no, i am not really interested in breaking boxes or just quick'n'dirty
hardening.
 
joachim

[mod-security-users] Generate Nessus rules for mod_security

[Javier Fernandez-S. <jfe...@ge...>]

In the line of the snort2modsec script I've written a nessus2modsec 
script. There are some differences between both (there are now so many 
Nessus plugins, for example, that it is necessary to provide the 
directory as an argument instead of plugins/*)

Attached is both the script (comments and testing welcome!) and rules 
generated based on the latest Nessus plugins.

Regards

Javier

BTW: I think I did see some rules for mod_security based on Snort 
plugins but I don't remember where I found them..

[mod-security-users] Patch to properly generate Snort rules

[Javier Fernandez-S. <jfe...@ge...>]

Hi there,

I was meaning to send this for a while, but didn't have time. Attached 
is a patch (I hope Ivan sees it) to fix the snort2modsec script so 
that it only tries to generate filters for the Snort rules which are 
related to HTTP attacks (otherwise, there are a lot of definitions 
which are just not correct). It will also add the SID (Snort ID) to 
the comment so it's easier to track what rule generated which filter.

Attached is also a sample output from the latest Snort ruleset.

Regards

Javier

Re: [mod-security-users] Chroot problem

[Javier Fernandez-S. <jfe...@ge...>]

die...@b-... wrote:
> Hi,
> 
> I have a problem with the Chroot directive.
> 

> In my configuration file, i've writed the two directives that follow :
> 
> Pidfile /opt/web/pids/pid-secure
> .
> .
> SecChrootDir /opt/web
> 
> And my apache  does not start : in de errot log file, i can read :
> 
> No such file or directory:could not create /opt/web/pids/pid-secure
> 
> I'm sure that the rights are correct on the folders and when i delete the
> SecChrootDir directive my apache works without problem.
> 
> I uses an apache 2.0.48 and mod-security 1.8.4. on solaris 9
> 
> Could you help my.
> 

Hmmm... it looks like you need to have

Pidfile /pids/pid-secure

Since the Pidfile is used within the Chroot. With the above definition 
your Apache is trying to find the file under (in your system): 
/opt/web/opt/web/pids/pid-secure (i.e. Chroot+Pidfile location).

Regards

Javier

[mod-security-users] slightly off-topic

[Daniel G. <inf...@sp...>]

Hey list, this is slightly off topic but I thought you might be a great 
crowd to ask this.

I'm participating in a CTF war game pretty soon and I'm trying to come 
up with strategies to make sure that once I own a box, no one else can 
break back in and remove my "flag" from the root home folder.  Every 
team is given a file that they have to place in the /root folder and 
keep there to score points.

So far I'm thinking that once I own the box I do this: immediately 
delete all the user accounts except root, rename the adduser binary to 
something legit-looking yet entirely different and do the same for all 
the shells (bash, csh, etc) installed on the system.  Then, load up a 
kernel module or some other reference monitor type app that watches our 
'flag' for modifications and restores it if it's modified.  Then of 
course, immediately install some auto-update program (yum, apt-get, 
portage, etc) and update all the services running and change their 
configurations slightly to make them more secure (can't turn off 
services).  Last, install ettercap on the owned box to capture and 
report curious traffic going to and from the other servers in-play to 
catch our opponents.

If anyone knows some program that watches files like I described please 
let me know, I'd rather not have to code that from scratch.

Can you think of a better strategy once we own a box?  Has anyone 
participated in a CTF game before?  Any other tips?

Thanks for providing so much good help with mod_security, I've been 
using it for abour 9 months now on both my Windows and Linux server and 
it works great.

Dan

Re: [mod-security-users] [ANNOUNCE] mod_security 1.8.5 released

[Ivan R. <iv...@we...>]

>>Mod_security 1.8.5 has been released. It is available for immediate
>>download from:
>>
>>   http://www.modsecurity.org/download/
>>
>>This maintenance release relaxes several minor problems discovered
>>in 1.8.4. Please see the changes below for more details.
> 
> I am still running 1.7.7. Can I upgrade to 1.8.5 without significant
> changes? (especially to the chroot thingy).

  I don't think you should experience any difficulties. But wait for
  a couple days, I will release 1.8.6 early next week to fix another
  small issue that has just popped up.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [mod-security-users] [ANNOUNCE] mod_security 1.8.5 released

[Mark <ad...@as...>]

Ivan Ristic wrote:

> Mod_security 1.8.5 has been released. It is available for immediate
> download from:
>
>    http://www.modsecurity.org/download/
>
> This maintenance release relaxes several minor problems discovered
> in 1.8.4. Please see the changes below for more details.

I am still running 1.7.7. Can I upgrade to 1.8.5 without significant
changes? (especially to the chroot thingy).

Thanks,

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

Re: [mod-security-users] POST approve script hangs

[Ivan R. <iv...@we...>]

> I have made a SecUploadApproveScript to accept or deny
> files depending upon extension (.exe .cmd etc). And it
> works ok, with small files. But if I try to upload a
> file of abt. 1 MB or so it just hangs there forever.
> 
> I'm using mod_security 1.8.4, and now I see that 1.8.5
> is out, is this something which is fixed in .5? Also
> I'm using Apache 2.0.50 on FedoraCore 2.

  There have been some changes in that area but the problems
  only manifested on Windows, not on Unix platforms. But
  I do suggest you try 1.8.5 to see if it performs better.

  I use a 9 MB file for testing prior to making new releases
  and I haven't noticed anything suspicious. I've tested on
  Windows and Unix.

  The approve script execution should not depend on file
  size. Are you seeing problems only when you enable
  approval or at all times during upload (of large
  files)?

  Please enable debug logging and set log level 9, and then
  send me the output. It will be rather large so I suggest
  you send it to my email only - I'll inform the list later
  if a problem is found.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]