These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Mod_Security install? on the new forum.
Web Hosting and Cloud Computing Control Panels
No, a tarball is not a package. ;-)
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).
--
Check out the forum guidelines!
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.....
<b>"Nothing is secure unless the admin is."</b>
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 <b>ALL</b> temp files under /home/user/tmp directory not as apache.
Then you have a pretty darn good secured server.
<div class='quote'>I don't know what you mean by "world facing code" but the config files are stuffed in /etc...</div>
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.
--
Check out the forum guidelines!
<div class='quote'>Never think that just from one module its going to protect your server</div>
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.
<div class='quote'>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.</div>
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. ;-)
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.)
--
Check out the forum guidelines!
Just to prove that you can't rename a directory if a file under is +i
<div class='quote'>
[sgrayban@borgnet ~]
$ mkdir test
[sgrayban@borgnet ~]
$ touch test/test.txt
[sgrayban@borgnet ~]
$ sudo chattr +i test/test.txt
[sgrayban@borgnet ~]
$ lsattr test/
----i--------- test/test.txt
[sgrayban@borgnet ~]
$ rm-fr test/
bash: rm-fr: command not found
[sgrayban@borgnet ~]
$ rm -fr test/
rm: cannot remove `test/test.txt': Operation not permitted
</div>
<div class='quote'>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?</div>
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 <i>nothing</i> 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.
--
Check out the forum guidelines!
All these need to be edited in the default php.ini file..
upload_tmp_dir = /home/${USER}/tmp
session.save_path = /home/${USER}/tmp
soap.wsdl_cache_dir="/home/${USER}/tmp"
<div class='quote'>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. ;-)</div>
I disagree.
<div class='quote'>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.)</div>
Giving everyone a ]b]private<b> ~/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</b> there php.ini and create a new template one for VM to use then your statement is wrong and misleading.
<div class='quote'>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.</div>
Every script that runs under our default mod_fcgid+mod_suexec configuration uses a private tmp in ~/tmp.
--
Check out the forum guidelines!
<div class='quote'>I disagree.</div>
And that's the wonderful thing about America. ;-)
--
Check out the forum guidelines!
<div class='quote'>Every script that runs under our default mod_fcgid+mod_suexec configuration uses a private tmp in ~/tmp.</div>
You are assuming <b>a lot</b> 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
<div class='quote'>Can a script running under mod_fcgid+mod_suexec see higher than home? </div>
Of course.
--
Check out the forum guidelines!
actually yes.
I didn't know until I had a test script running and it was because the open_base_dir hadn't been set.
this can be set in the server template- "Apache website" in system settings-module config-
open_basedir
${HOME}:/tmp:/usr/lib/php:/usr/local/lib/php on a default centos with fcgi-suexec
or with running apache as mod_php and mod_suid after recompiling Apache2 to its default location in /usr/local/apache
php_admin_value open_basedir ${HOME}:/var/lib/php/session:/usr/share/pear
this worked for me, but for anyone else might have different paths/settings
attached is the test file i used, but be sure to delete it after the useage as my test domain got indexed :(
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....
You think this is secure to test on a rootserver? ;)
I tested it on a vmware box. Why wants my browser connect www.r57shell.in when clicking around in that application?
actually yes.
I didn't know until I had a test script running and it was because the open_base_dir hadn't been set.
this can be set in the server template- "Apache website" in system settings-module config-
open_basedir
${HOME}:/tmp:/usr/lib/php:/usr/local/lib/php on a default centos with fcgi-suexec
or with running apache as mod_php and mod_suid after recompiling Apache2 to its default location in /usr/local/apache
php_admin_value open_basedir ${HOME}:/var/lib/php/session:/usr/share/pear
this worked for me, but for anyone else might have different paths/settings
attached is the test file i used, but be sure to delete it after the useage as my test domain got indexed :(
ah in reference of not setting the open_basedir, a user with such script as above could dwell through the system with no restriction at all, go to a .usermin folder-mailbox, look inside inbox.imap and see the password....so he would be able to log in to any account. This is with suexec/fcgi enabled
I dont know but i am not experienced sys admin and had about everything set to default and was shocked when i discovered this.
Also this is not the first time i found out accidentally about major security risks, as in exposing master admins passwords in some situations. (these have been resolved with webmin 1.42 and VM 3.58)
hmm you actually tested this?
yes i have.
i browsed to the test domain, and i could go through the whole server and do 'anything' with the files from 2 different locations/computers/browser.
I could open any inbox.imap file and get the password of that user.
hmm so it seems you can -- not a good thing. I have set all my domains to a restricted open_basedir
yes indeed. And not being experienced (i guess there are many others out there) and not knowing about open_basedir, the default install let's that of course wide open.
Im wondering if this could be set somehow during an installation (at least have ${HOME} in it) or give a warning when the field in the template is left blank.
This setting can also be done afterwards through the server template "PHP configuration variables for scripts" in the Pro version.
Also enable_dl must be set to Off else a user can upload and execute any module and without open_basedir set I don't want to think of the consequences :).
I'm just saying, if talking about security then lets presume system admins are not experienced at all. I'm guessing there must be many current resellers who upgrade themselfs to "webhosts" and as you say: a system is as safe as the admin running it.
yes indeed. And not being experienced (i guess there are many others out there) and not knowing about open_basedir, the default install let's that of course wide open.
Im wondering if this could be set somehow during an installation (at least have ${HOME} in it) or give a warning when the field in the template is left blank.
This setting can also be done afterwards through the server template "PHP configuration variables for scripts" in the Pro version.
Also enable_dl must be set to Off else a user can upload and execute any module and without open_basedir set I don't want to think of the consequences :).
I'm just saying, if talking about security then lets presume system admins are not experienced at all. I'm guessing there must be many current resellers who upgrade themselfs to "webhosts" and as you say: a system is as safe as the admin running it.
on the other hand running mod_fcgi lets a user edit its own php.ini file and could remove the open_basedir throwing the server wide open again.
so i have now switched to mod_php with only a master php.ini and made it immutable.
apparently you have not read http://www.virtualmin.com/documentation/id,securing_your_server_howto/
hehe actually i did a few days ago and scratched my ear after reading : "and understand how perl works"
anyway the "chattr +i" is an important one if you have 'untrusted users' defined by malicious people and users unknowingly experimenting with available options.
A regular user who will simply publish his site about his upcoming wedding will likely not have any intention to abuse your system :)
Normally a usrs php.ini has root root 733 which can then be rewritten/recreated. with the offered solution "chattr +i" this will be prevented.
but you know how people do not read :)
I modified my code to fit my servers. So this solution is just great because you can't go wrong.
I modified functions.les and opt.dat to fit the exact path I used in setting up my server. A person only has to think outside the box because you can adapt LES for nearly anything you want to secure.
<div class='quote'>Normally a usrs php.ini has root root 733 which can then be rewritten/recreated. with the offered solution "chattr +i" this will be prevented.
but you know how people do not read :) </div>
People don't have to read. This is automatic in 3.58+ (coming out today).
--
Check out the forum guidelines!
What prompted you to add that to VM Joe ?
BTW velvetpixel -- sorry we took over your thread. It just got really good about security overall, although we should have made a new thread for it.
Oops. Actually I misspoke. We are not setting +i on php.ini. We're setting it on the fcgi-bin directory. Setting it on the users php.ini would be kind of stupid, as the whole point is to allow users to control their own PHP destiny. ;-)
--
Check out the forum guidelines!
And I'm not actually even all that confident about that one. I'm just having vague recollections of a couple of bug reports, and how Jamie resolved them.
--
Check out the forum guidelines!
confident about the +i on fcgi-bin ?
If you edit function.les find <i>secure_prof</i>
Then just look how its setting the +i and you can add your own paths to set in there.
Like mine I added... for the +i
[code:1]eout "{sec.profile} chattr $ECHA $HOME/$pusr/etc/php*/php.ini"
chattr $ECHA $HOME/$pusr/etc/php*/php.ini >> /dev/null 2>&1
eout "{sec.profile} chattr $ECHA $HOME/$pusr/domains/*/etc/php*/php.ini"
chattr $ECHA $HOME/$pusr/domains/*/etc/php*/php.ini >> /dev/null 2>&1
[/code:1]
Then for the -i....
[code:1]
eout "{sec.profile} chattr $ECHA $HOME/$pusr/etc/php*/php.ini"
chattr $DCHA $HOME/$pusr/etc/php*/php.ini >> /dev/null 2>&1
eout "{sec.profile} chattr $ECHA $HOME/$pusr/domains/*/etc/php*/php.ini"
chattr $DCHA $HOME/$pusr/domains/*/etc/php*/php.ini >> /dev/null 2>&1
[/code:1]
Then when you run <i>les --secure-prof 1</i> you get something like....
[code:1]
Jun 13 15:04:40 spock les(28439): {sec.profile} chmod 644 /home/totalcompsystem/.bash_profile
Jun 13 15:04:40 spock les(28439): {sec.profile} chattr +i /home/totalcompsystem/.bash_profile
Jun 13 15:04:40 spock les(28439): {sec.profile} chattr +i /home/totalcompsystem/etc/php*/php.ini
Jun 13 15:04:40 spock les(28439): {sec.profile} chattr +i /home/totalcompsystem/domains/*/etc/php*/php.ini
Jun 13 15:04:40 spock les(28439): {sec.profile} chmod 644 /home/totalcompsystem/.bashrc
Jun 13 15:04:40 spock les(28439): {sec.profile} chattr +i /home/totalcompsystem/.bashrc
Jun 13 15:04:40 spock les(28439): {sec.profile} chattr +i /home/totalcompsystem/etc/php*/php.ini
Jun 13 15:04:40 spock les(28439): {sec.profile} chattr +i /home/totalcompsystem/domains/*/etc/php*/php.ini
Jun 13 15:04:40 spock les(28439): {sec.profile} chmod 644 /home/totalcompsystem/.bash_logout
Jun 13 15:04:40 spock les(28439): {sec.profile} chattr +i /home/totalcompsystem/.bash_logout
Jun 13 15:04:40 spock les(28439): {sec.profile} chattr +i /home/totalcompsystem/etc/php*/php.ini
Jun 13 15:04:40 spock les(28439): {sec.profile} chattr +i /home/totalcompsystem/domains/*/etc/php*/php.ini
[/code:1]
Then to check to make sure +i was set you do <i>lsattr /home/totalcompsystem/*/</i>
And you get something like.....
[code:1]
----i------------- /home/totalcompsystem/cgi-bin/php5.cgi
----i------------- /home/totalcompsystem/cgi-bin/php4.cgi
----i------------- /home/totalcompsystem/etc/php.ini
----i------------- /home/totalcompsystem/fcgi-bin/php5.fcgi
[/code:1]
Aint that neat ?
that looks good.
what if you have a trusted user and set the php configuration module (or set it in the template) to On.
Would the user then get the privilege or need you to run the -i cmd on his account afterwards?
use sudo for them and add there access to /etc/sudoers
i think not only the file but also the folders need +i as they can still be renamed and recreated.
always could happen -- whats nice about setting a directory +i all the files/directories under it are also protected.
<div class='quote'>i think not only the file but also the folders need +i as they can still be renamed and recreated.</div>
Actually no -- since php.ini is set +i you can't do anything including deleting the folder or renaming it because php.ini is under that path which stops what you just said.
i started a support ticket with this as I have in the template: "do not allow php configuration" (which is not foolproof as said in the help)
then the php.ini is set to root. but a user can still rename the folder and recreate the ini file making the option in the template fancy but not effective imo.
same for fcgi-bin folder.
<div class='quote'>
Just to prove that you can't rename a directory if a file under is +i
[sgrayban@borgnet ~]
$ mkdir test
[sgrayban@borgnet ~]
$ touch test/test.txt
[sgrayban@borgnet ~]
$ sudo chattr +i test/test.txt
[sgrayban@borgnet ~]
$ lsattr test/
----i--------- test/test.txt
[sgrayban@borgnet ~]
$ rm-fr test/
bash: rm-fr: command not found
[sgrayban@borgnet ~]
$ rm -fr test/
rm: cannot remove `test/test.txt': Operation not permitted</div>
can you do this with rename instead of rm ? as i think you can still rename and then recreate...unless you prove me wrong :)
<div class='quote'>BTW velvetpixel -- sorry we took over your thread. It just got really good about security overall, although we should have made a new thread for it.</div>
That's ok! It's a good discussion and I am learning more about security which is always a good thing :)
so as root i navigated to a user.
i created a folder test with a file test.txt
then I chattr +i that file
#####
[root@ns3 byethost.be]# mkdir test
[root@ns3 byethost.be]# touch test/test.txt
[root@ns3 byethost.be]# chattr +i test/test.txt
[root@ns3 byethost.be]# lsattr test/
----i-------- test/test.txt
#####
i logged in as that user into webmin and went to filemanager (a user has no shell so this is what he has)
I changed the test folder to untest which I have permission to as a user.
Below you see the folder has a changed name and the +i test.txt is still in it.
#####
[root@ns3 byethost.be]# ls
cgi-bin homes Maildir public_html untest
awstats fcgi-bin logs tmp
#####
I create a new folder (in filemanager) called test (this is now my folder) and made a new test.txt (this is now my file)
The renamed untest with +i test.txt is still there, but doesn't do anything.
So I really think only do a +i on the file is not enough, you need to +i the folder too
Anyone can test this on his own system.
damn.. you can move the directory still......
So I guess the only way to secure php.ini is set both directory and php.ini +i
That's fine -- I'll just edit functions.les and make the change.
Pages