Mod_Security install?

What’s the best way for me to install mod_security?

I checked in webmin/Software Packages/Package from YUM but it is not listed in the browse YUM search.

I clicked the searchrpmfind button and it only listed Fedora. I’m CentOS 5.1

Can I just download mod_security 2.5.5 from https://bsn.breach.com/downloads/ then upload the .gz to my server and use webmin/Software Packages/Install a new Package from local file feature?

No, a tarball is not a package. :wink:

I’ve long been suspicious of mod_security (I believe it gives a false sense of security, and doesn’t actually provide much other than an additional vector of attack–every service you run on your system, and every module in Apache, is an additional attack vector…I’m not saying mod_security is insecure, just that it’s one more chunk of world-facing code), but I recently talked with the guys at Weebly.com, and they’re making really good use of it on a huge shared free hosting service (with 600,000 of the least trustworthy users possible–they are pretty much wholly anonymous), though in relatively novel ways (their primary goal is to prevent scripts, even their own, from being able to display any information about their systems–like filesystem paths and such).

So, what I’m getting at is that we’ll probably be adding mod_security as an optional package to our software repositories in the near future.

In the meantime, you’ll have to compile it yourself–install the httpd-devel packages, and it’ll hopefully build without trouble using the instructions provided by the mod_security folks (maybe in the tarball, maybe on their website, I dunno).

Thanks Joe,

Yeah the instructions for running the configure script and then compiling with make are in the tarball but I am going to wait until you have a version in your repositories that I know won’t bork my existing install :slight_smile:

I’ve been using mod_security on virtualmin over a year now, and on VHCS before that. It’s a staple IMHO. But as it is, it is not bulletproof.

I don’t know what you mean by “world facing code” but the config files are stuffed in /etc/[where-ever] unless you enable .htaccess usage, and that’s inadvisable - maybe you mean another module apache is running that can be possibly exploited?

The guidelines that I followed for installation were pretty canned. You’ll need a few dependencies (for example like these:
apr-devel-1.2.7-11.x86_64.rpm
apr-util-devel-1.2.7-6.x86_64.rpm
httpd-2.2.3-11.el5.centos.x86_64.rpm
httpd-devel-2.2.3-11.el5.centos.x86_64.rpm
libxml2-2.6.26-2.1.2.x86_64.rpm
libxml2-devel-2.6.26-2.1.2.x86_64.rpm)

You can get many of these at the DAG weers RPM repository.

There are many rule sets out there - and you’ll need to keep a close eye on your server to delineate exceptions which can be a pain, but apparently worth the hassle.

http://www.gotroot.com/ is a good resource for mod_security.

For other vectors - in particular, if you get tired of your log files getting bloated with dictionary attacks try fail2ban or DenyHosts - also from DAG weers for CentOs.

There are some markedly vocal folks against mod_security:
http://www.php-security.org/index.html

To each their own I figure. You may also be interested in mod_evasive (but from my experience this took me more energy to implement.)

HTH,
-merlynx

Thanks for the feedback!

It’s good to hear both sides so I can decide what works best for me.
I probably will install mod_security and test it out but like I said not until it’s available through the vmin SRs so the dependencies all play nice.

A rule-of-thumb to go by…

"Nothing is secure unless the admin is."

Never think that just from one module its going to protect your server. Adding them is just aother config file you have to deal with.

Securing /tmp /var/tmp and /dev/shm is the best thing any server admin can do then make sure that all ruby/cgi/perl/php script runs under the user and stores ALL temp files under /home/user/tmp directory not as apache.

Then you have a pretty darn good secured server.

Never think that just from one module its going to protect your server

Wow - I really hope that’s not what anyone got out of my post!

Good advice about securing those directories, though. I like how VM gives options to ensure that apache runs as domain owner and you can use the FCGId option as well (at least on CentOS). If I recall, that is the default configuration?

About securing these directories and ensuring ALL files are stored to /home/user/tmp - how do you recommend that be set up? Are there particular pitfalls or settings that could lead to issues with these directories?

Is there a "securing Virtualmin" guide out there? Something like:

http://blogsecurity.net/wordpress/wordpress-security-whitepaper/

This is a cool thread here:
http://www.virtualmin.com/forums/webmin/server-hardening-scripts.html

Food for thought

See:
http://www.virtualmin.com/documentation/id,securing_your_server_howto/

I am also writing a script that server owners can run to secure there /tmp directories and I hope Joe will include into the install script to harden the server more.

Until that happens I’ll post my script in a few days at the link above I pasted.

I don't know what you mean by "world facing code" but the config files are stuffed in /etc...

I mean it is an Apache module, and since we’re talking about web hosting systems, Apache is a world-facing service: a hole in mod_security is a hole in your server. Pretty much every module in Apache is world-facing code, to one degree or another, and thus another vector of potential attack.

Again, I’m not singling out mod_security or any other Apache module. Most are very good. But it’s worth remembering that adding modules to Apache is like starting another service on your system, as it is code built by another developer.

Anyway, as I mentioned, I’m not a long-time fan of the mod_security concept, but I’ve been converted to its utility by seeing a few examples where it really does provide improved security. But, I suspect that the vast majority of users are not getting any improvement from it, as it requires quite a bit of thought to get good policies in place that match your deployment and your requirements.

I am also writing a script that server owners can run to secure there /tmp directories and I hope Joe will include into the install script to harden the server more.

If you’re “hardening” your /tmp, you and I have a very different idea about the purpose of /tmp. /tmp is 777. That’s its job. :wink:

We resolve the security problems that are intrinsic in having a shared state directory by giving everyone a private ~/tmp directory. So, rather than harden /tmp…use a private tmp for all scripts and all tools. Then, you’ll never have a race-condition that can be exploited by other users on the system to cause you to run other peoples code. (Though any project using good temp file practices won’t have problems…but it’s actually pretty tricky to create secure temp files.)

If you're "hardening" your /tmp, you and I have a very different idea about the purpose of /tmp. /tmp is 777. That's its job. ;-)

I disagree.

We resolve the security problems that are intrinsic in having a shared state directory by giving everyone a private ~/tmp directory. So, rather than harden /tmp...use a private tmp for all scripts and all tools. Then, you'll never have a race-condition that can be exploited by other users on the system to cause you to run other peoples code. (Though any project using good temp file practices won't have problems...but it's actually pretty tricky to create secure temp files.)

Giving everyone a ]b]private ~/tmp is nice in theory but the default php.ini does NOT see or use that. It uses the default location /tmp for everything so unless all the users of VM actually [b]edit there php.ini and create a new template one for VM to use then your statement is wrong and misleading.

About securing these directories and ensuring ALL files are stored to /home/user/tmp - how do you recommend that be set up? Are there particular pitfalls or settings that could lead to issues with these directories?

PHP sessions should already default to ~/tmp. You might also grep your other applications to see if they’re using /tmp for anything, and point them to ~/tmp, instead. There is nothing else you need to do. ~/tmp is owned by the user, and apps running under suexec will always have access to it–just like real /tmp. But nobody else will, unlike real /tmp.

I think the post you linked to sums up my position on Virtualmin security (it’s roughly identical to my position on any server’s security), and I believe my “three principles” for security are the most important three things you can do–if you do them religiously, you’ll be more secure then 95% of servers. As they say, if you and a friend are running from a hungry bear you don’t have to be faster than the bear, just faster than your friend. If your system takes weeks to attack via a brute force password attack, the vast majority of crackers will expend their efforts elsewhere. There are systems out there with a root password of “password” or running services that haven’t been updated in three years, and they’ll serve spam just as well as your box, and won’t take nearly as long to get a hold on.

Giving everyone a ]b]private ~/tmp is nice in theory but the default php.ini does NOT see or use that. It uses the default location /tmp for everything so unless all the users of VM actually [b]edit there php.ini and create a new template one for VM to use then your statement is wrong and misleading.

Every script that runs under our default mod_fcgid+mod_suexec configuration uses a private tmp in ~/tmp.

I disagree.

And that’s the wonderful thing about America. :wink:

Every script that runs under our default mod_fcgid+mod_suexec configuration uses a private tmp in ~/tmp.

You are assuming a lot here… This is assuming that everyone understands this and we all know how ASSumption can suck.

Can a script running under mod_fcgid+mod_suexec see higher than home?

Good question !!

I never thought about that so I am going to google it and see if anyone else has asked this. (not being a smartass either) just curious

Well I didn’t find anything but you could always test this with a php script and have it do something easy like cd /tmp - ls

so i couldnt attach a rar, try again with zip

[file name=test2.zip size=44665]http://www.virtualmin.com/components/com_fireboard/uploaded/files/test2.zip[/file]

but even running the server under fcgi or cgi-wrapper what could they do ? not much I expect because they would be running as the user as if they logged in so unless that user is root or apache they can’t do anything that a normal user can’t.