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 <b>only </b>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 <b>undo </b>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.
"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."
I can see one can do this for a group in file manager settings for the group, but, can't figure out what to put in the box that says "ONLY ALLOW ACCESS TO DIRECTORIES". Without this box, the user can get anywhere in file manager.
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 :)
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.
Well you can do what I did --- make a copy of the php.ini file then add all you custom paths to it with the right VM variables then when a new server is created all is good.
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 ;)
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!
2 years later, is this still the best way to install mod_security?
This is a long thread -- what way are you looking at for installing mod_security, and on what distro? :-)
It does typically need to be manually downloaded and installed though, there aren't packages for it in the default repositories for most distros.
CentOS 5.4. Need to protect against automated blanket attacks and integrate with CSF to block those automated attacks.
Yeah, CentOS definitely doesn't have mod_security in it's repository. Installing manually by downloading it from the mod_security site and following their instructions is a common way to do that.
I think there are third party repositories that package mod_security and make it simpler to install, but I'm not familiar with any of them... I'd certainly suggest caution in what repositories you enable, as some can cause problems of various sorts. But if you run into one you trust that provides mod_security, that may save you some time :-)
I trust Atomic Rocket Turtle.