Mod_Security install?

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.

confident about the +i on fcgi-bin ?

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.

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

can you do this with rename instead of rm ? as i think you can still rename and then recreate…unless you prove me wrong :slight_smile:

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.

That’s ok! It’s a good discussion and I am learning more about security which is always a good thing :slight_smile:

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.

that is correct. it also is valid for fcgi-bin or any other directory for that matter.
Hence why the button "do not allow php configuration" in the template is not worth much.

as joe said the php.ini is for users to edit, BUT only when you allow them to.
If you don’t want that then it should also not be possible with a trick, it should also not be possible to let them alter the php5.ini if you don’t want to allow it. What is the point of defining 2 subprocesses and let the user alter that to 10000000?

beginning sys admins don’t know about chattr +i and even experienced admins are sometimes a little bit confused, heh scott :)) just kidding here, don’t get mad

there is always a possibility to put some scripts in cgi-bin and do evil but in this case I am talking about making it more difficult to crack what you dont want to have cracked and to protect yourself better against inexperienced experimenters, giving you more time to respond to processes you don’t want to see on your box.

I wasn’t confused. Just didn’t think of that other little step of using mv is all.

i want to add that if users have filemanager with EXT enabled (the little hammer icon) then they will be able to undo the chattr +i with that tool.

hehe webmin is too powerful

Isn’t chattr -i faster ?

yes probably, but what i meant is that as a sys admin is doing his best to secure (let’s say: $DOM/etc/php5/php.ini) with chattr +i and then any user can undo this through the filemanager with the EXT tool.
That doesn’t seem right.

Scott do you know a way to disable that ‘EXT’ for all users at once through webmin?

Actually you can disable the EXT – what I did was create a new user group called ‘hosting’ and went though all the ACL’s for each module and disabled or enforced what they could do in them.

In the “Module Access Control” for “File Manager” I just disabled all the features I didn’t want them to have access to which included “EXT (edit EXT attributes)”.

And of course you assign each user to the ‘hosting’ webmin group.

You think this is secure to test on a rootserver? :wink:
I tested it on a vmware box. Why wants my browser connect www.r57shell.in when clicking around in that application?

Just found that thread when i was searching for mod_security here in this forum.

What i can say is, that mod_security blocked every hacking attempt we tried on our webservers so far. Ok, most of them weren’t very smart, i mean a lot of them were with automated tools. But also manually driven attacks are hard to place because a lot of the stuff u normally try is forbidden with the activated rules.

I use the rules from modsecurity.org and gotroot.com
Sometimes there are false positives, but a little bit of experience and playing with mod_sec and u can alter those rules to fit your needs.
Also we did some performance testing with mod_sec enabled. Fast enough! IF there are performance problems, than its not because of mod_sec in our infrastructure.

Hm, what else do we do to tighten our servers (apache)?
I also use mod_evasive and mod_spamhaus. (but i don’t know how or if mod_spamhaus actually works, there is no way of testing this stuff)

At last, ossec is monitoring the hosts. I altered the config a little bit so that DOS attempts are recognized and blocked. Also mod_security events are recognized correctly. The rest is tweaking the tresholds. No problem with Bruteforce because ossec handles them perfectly so far. The only drawback is, that somebody could use that HIDS to lock out spoofed IP adresses. But it aint over now :wink:

Before such a server starts to work, it is locked down by the RHEL 5.0 benchmark from http://cisecurity.com/benchmarks.html (they are free - most of them are pretty actual - this site if worth a look! no bs)

The only thing i’m missing is selinux and bastille for centos 5.2
First one is too much hassle in combination with virtualmin and the second one won’t run on 5.x so far… anyway, u can set these settings by hand.

Is there a thread regarding security methods and best practices? I love that stuff!

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"

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 :frowning:

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 :frowning:

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.