Atomicorp

Anyone else notice that mod_security as implemented by ASL adds about 100MB of RSS to each httpd process? My load averages have been on the hot side since installing ASL and I think this is the prime culprit. Any thoughts?

Anyone else notice that mod_security as implemented by ASL adds about 100MB of RSS to each httpd process? My load averages have been on the hot side since installing ASL and I think this is the prime culprit. Any thoughts?

Some of the 2006 vintage suggestions don't seem to apply directly to the current modsecurity rulesets.

I was able to get between 10 and 40 mb taken off each httpd process by removing various files from /etc/httpd/modsecurity.d

The 10_asl_antimalware.conf was the biggest one.

http://atomicorp.com/forums/viewtopic.p ... 9&start=15

----------

Does everyone just accept 130mb per httpd process? Or am I having a unique situation?

Yes and no.

I think most people use the full kit and kaboodle.

The three things that take a load of memory are the domain blacklist, the malware blacklist and (unrelated to apache) the Google safe-site list for ClamAV, and disabling one or more of those if definitely an option if you find you have memory usage problems.

But on a system with 2Gb of RAM, running everything should be fine. I seem to remember Mike or Scott mentioning 1.5Gb is plenty too. I guess it depends on how busy the sites are on your system, and how many sites you have. I wouldn't be surprised to hear that some people run all the rules even on systems with much less RAM than that.

Hopefully others will chip in to say what they use and how much RAM they have on their systems.

Faris.

I'm on 2 GB RAM, VPS that I think is on top of the xen hypervisor.

I found a tip to setup a rule to disable mod_security on static files like jpg|gif|png|exe|mp3. It seems to make a difference in page loading, but does it open up a big fat Mack truck sized security hole?

Yes, it can open a hole. We use bypasses when its appropriate, and only in specific cases - so be extra careful with bypasses unless you know exactly what you are bypassing, what attacks those rules protect against, and the effect the bypasses can have. For example, if you bypass the rootkit rules by saying "dont look at this if its a jpeg", modsecurity isnt actually that clever, it would just say bypass if the file ends with .jpg, which a rootkit can certain end with. So keep in mind the limitations of the system too.

So where we know we can bypass things, we do that already - so you might be making a hole (or maybe you found a good improvement for the rules - let us know). So, bottomline, be careful - web attacks are surprisingly clever sometimes, and some really weird apps may name things in strange ways and still take input. If you have suggestions, let us know, we have a staff that will research these things and work out the best compromise. Performance is a big priority for us, so if you have questions or suggestions, please let us know.

Super.

ps axu --sort:rss

apache 5978 0.0 6.1 346804 125728 ? S 13:45 0:00 /usr/sbin/httpd
apache 8487 0.2 6.4 435188 131376 ? S 14:16 0:00 /usr/sbin/httpd
root 5971 0.1 6.7 435188 137880 ? Ss 13:45 0:02 /usr/sbin/httpd
apache 8480 0.5 6.8 497536 139904 ? S 14:16 0:00 /usr/sbin/httpd
apache 8156 0.3 6.9 499612 141280 ? S 14:08 0:01 /usr/sbin/httpd
apache 8157 0.2 7.2 509864 148852 ? S 14:08 0:01 /usr/sbin/httpd
apache 8293 0.3 7.5 515988 154156 ? S 14:10 0:01 /usr/sbin/httpd
apache 8292 0.3 7.5 517004 154692 ? S 14:10 0:01 /usr/sbin/httpd
apache 8294 0.3 7.6 520100 156728 ? S 14:10 0:01 /usr/sbin/httpd
apache 8046 0.3 7.6 519072 156936 ? S 14:05 0:02 /usr/sbin/httpd
apache 6819 0.5 7.7 521124 157920 ? S 14:00 0:05 /usr/sbin/httpd
apache 8042 0.5 7.7 521108 158108 ? S 14:05 0:03 /usr/sbin/httpd


See how big those are?

This is the rule that makes it faster, but probably is a bad idea:

SecRule REQUEST_FILENAME ".(?:jpe?g|gif|png|js|mp3)$"
"phase:1,allow"

SecRule REQUEST_FILENAME ".(?:jpe?g|gif|png|js|mp3)$"
"phase:1,allow"

Yes, that rules not a good idea.

So first, thank you for bringing this up. There are already bypasses in the rules for these kinds of files and more, where it is appropriate - if you find other cases where you think the rules could use a bypass or two let us know. For example, we exclude other cases where we can know the file type doesnt need a particular type of inspection, such as javascript files, css files, not looking for SQL attacks against pdf files, and bypassing spam rules for graphics or video files and so on. Those bypasses are already in the rules (as are graphics files, etc. - again where appropriate)

You dont want to skip everything with a rule like you have. For example, there are attacks where a name like "badshell.jpg" may be used and it might contain an actual backdoor shell, if you had a rule like you quoted you would never stop that shell. There are also header based attacks on all file types you never want to ignore, and so on.

One side note, if you write a rule like the one you have, make sure you escape the period "\." if you mean ".", if you dont "." is a wild card and not a period - which means this regular expression:

.jpg

Can actually translate to nastyshelljpg, or anythingjpg, and not just anything .jpg. So make sure you escape your periods.

So, my two cents, I would not use this rule unless you want to miss various attacks like cross site scripting, shells, session hijacking, header injection, session fixation, CSRF, and others.

Thanks for explaining why that's a bad idea!

Are mp3's being appropriately bypassed? I happen to have clients with radio broadcasts by MP3.

They sure are. There are some rules that will inspect requests for mp3s, such as header attacks and XSS scripting, but for the most part they bypass most of the rules.

One place to keep in mind is the rootkit rules. We dont bypass the rootkit rules for any file types (theres just no easy way to know if its really an mp3 or a shell, rootkit, etc. named whatever.mp3), so if by some chance this presents an issues for you, and you want to bypass those rules for mp3s then I would recommend you either use the built in bypass method for those rules:

https://www.atomicorp.com/wiki/index.php/Mod_security

Or just disable the rootkit rules. The downside is that you won't be protected from uploaded rootkits, shells, etc. So, definitely not recommended unless you know users won't upload shells, rootkits, etc. You could compensate by turning on the dazuko features in ASL, but defense in depth is our recommended option (Turn on the rootkit rules, turn on dazuko and upload protection).

Keep in mind dazuko does not work on VPS' because we can't change the kernel on a VPS to support it (no kernel *frown*)

Thanks Mike. Dazuko is one reason I'm looking at moving to a real live actual computer server.

mikeshinn wrote:Keep in mind dazuko does not work on VPS' because we can't change the kernel on a VPS to support it (no kernel *frown*)

Mike:

Is that applicable to all VPS' or only certain types? I thought I recalled reading that KVM had full ASL support, including using the ASL kernel inside a KVM VPS.

Thanks.

You are correct sir! If you're working with a full hypervisor like KVM you can use dazuko just fine. In fact thats one of the systems we use here in development to test it out with.

Scott:

Thank you.

For future reference, when I say "VPS" I am referring to container type virtualization like OpenVZ and Virtuozzo which does not provide the "virtual" server with its own kernel, so you cant modify it (and therefore cant enable dazuko from inside the virtualized environment).

Virtual machine technology, like KVM, vmware and others allow you install your own kernel inside the virtual machine, so you can modify that to your hearts content, and therefore add in modules like dazuko.

Mike:

Thanks, good to know for future reference. From a providers perspective, they tend to lump them all together and use VPS to refer to any/all types.

On a related note, are there any security considerations for a KVM and/or vmware type environment versus a dedicated server? I'd assume that the underlying software for the host box would introduce some potential issues but was curious as to your thoughts about the relative exposure of a guest with ASL (assuming the host itself doesn't run ASL) versus a dedicated box with ASL.

Thanks.