Mod_Security install?

69 posts / 0 new
Last post
#1 Thu, 06/12/2008 - 12:45
velvetpixel

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?

Thu, 06/12/2008 - 13:07
Joe
Joe's picture

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!

Thu, 06/12/2008 - 22:30 (Reply to #2)
merlynx

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

Thu, 06/12/2008 - 22:54 (Reply to #3)
velvetpixel

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.

Thu, 06/12/2008 - 23:42 (Reply to #4)
sgrayban

A rule-of-thumb to go by.....

<b>&quot;Nothing is secure unless the admin is.&quot;</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.

Fri, 06/13/2008 - 00:59 (Reply to #5)
Joe
Joe's picture

<div class='quote'>I don't know what you mean by &quot;world facing code&quot; 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!

Thu, 06/12/2008 - 23:59 (Reply to #6)
merlynx

<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 &quot;securing Virtualmin&quot; 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

Fri, 06/13/2008 - 00:08 (Reply to #7)
sgrayban

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.

Fri, 06/13/2008 - 01:02 (Reply to #8)
Joe
Joe's picture

<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 &quot;hardening&quot; 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!

Fri, 06/13/2008 - 08:11 (Reply to #9)
sgrayban

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>

Fri, 06/13/2008 - 01:10 (Reply to #10)
Joe
Joe's picture

<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 &quot;three principles&quot; 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 &quot;password&quot; 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!

Sun, 06/07/2009 - 07:24 (Reply to #11)
sgrayban

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=&quot;/home/${USER}/tmp&quot;

Fri, 06/13/2008 - 01:09 (Reply to #12)
sgrayban

<div class='quote'>If you're &quot;hardening&quot; 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.

Fri, 06/13/2008 - 01:13 (Reply to #13)
Joe
Joe's picture

<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!

Fri, 06/13/2008 - 01:14 (Reply to #14)
Joe
Joe's picture

<div class='quote'>I disagree.</div>

And that's the wonderful thing about America. ;-)

--

Check out the forum guidelines!

Fri, 06/13/2008 - 01:17 (Reply to #15)
sgrayban

<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.

Fri, 06/13/2008 - 01:45 (Reply to #16)
velvetpixel

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

Fri, 06/13/2008 - 01:50 (Reply to #17)
sgrayban

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

Fri, 06/13/2008 - 01:57 (Reply to #18)
sgrayban

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

Fri, 06/13/2008 - 07:03 (Reply to #19)
Joe
Joe's picture

<div class='quote'>Can a script running under mod_fcgid+mod_suexec see higher than home? </div>

Of course.

--

Check out the forum guidelines!

Sun, 06/07/2009 - 07:24 (Reply to #20)
ronald
ronald's picture

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- &quot;Apache website&quot; 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 :(

Fri, 06/13/2008 - 04:10 (Reply to #21)
ronald
ronald's picture

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....

Thu, 10/02/2008 - 00:27 (Reply to #22)
webinger

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?

Sun, 06/07/2009 - 07:24 (Reply to #23)
ronald
ronald's picture

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- &quot;Apache website&quot; 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 :(

Fri, 06/13/2008 - 04:52 (Reply to #24)
ronald
ronald's picture

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)

Fri, 06/13/2008 - 04:54 (Reply to #25)
sgrayban

hmm you actually tested this?

Fri, 06/13/2008 - 04:57 (Reply to #26)
ronald
ronald's picture

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.

Fri, 06/13/2008 - 05:04 (Reply to #27)
sgrayban

hmm so it seems you can -- not a good thing. I have set all my domains to a restricted open_basedir

Sun, 06/07/2009 - 07:24 (Reply to #28)
ronald
ronald's picture

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 &quot;PHP configuration variables for scripts&quot; 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 &quot;webhosts&quot; and as you say: a system is as safe as the admin running it.

Sun, 06/07/2009 - 07:24 (Reply to #29)
ronald
ronald's picture

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 &quot;PHP configuration variables for scripts&quot; 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 &quot;webhosts&quot; and as you say: a system is as safe as the admin running it.

Fri, 06/13/2008 - 05:30 (Reply to #30)
ronald
ronald's picture

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.

Fri, 06/13/2008 - 05:36 (Reply to #31)
Fri, 06/13/2008 - 05:50 (Reply to #32)
ronald
ronald's picture

hehe actually i did a few days ago and scratched my ear after reading : &quot;and understand how perl works&quot;

anyway the &quot;chattr +i&quot; 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 &quot;chattr +i&quot; this will be prevented.

but you know how people do not read :)

Fri, 06/13/2008 - 05:56 (Reply to #33)
sgrayban

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.

Fri, 06/13/2008 - 08:13 (Reply to #34)
Joe
Joe's picture

<div class='quote'>Normally a usrs php.ini has root root 733 which can then be rewritten/recreated. with the offered solution &quot;chattr +i&quot; 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!

Fri, 06/13/2008 - 08:15 (Reply to #35)
sgrayban

What prompted you to add that to VM Joe ?

Fri, 06/13/2008 - 08:16 (Reply to #36)
sgrayban

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.

Fri, 06/13/2008 - 08:17 (Reply to #37)
Joe
Joe's picture

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!

Fri, 06/13/2008 - 08:20 (Reply to #38)
Joe
Joe's picture

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!

Fri, 06/13/2008 - 08:24 (Reply to #39)
sgrayban

confident about the +i on fcgi-bin ?

Sun, 06/07/2009 - 07:24 (Reply to #40)
sgrayban

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 &quot;{sec.profile} chattr $ECHA $HOME/$pusr/etc/php*/php.ini&quot;
chattr $ECHA $HOME/$pusr/etc/php*/php.ini &gt;&gt; /dev/null 2&gt;&amp;1
eout &quot;{sec.profile} chattr $ECHA $HOME/$pusr/domains/*/etc/php*/php.ini&quot;
chattr $ECHA $HOME/$pusr/domains/*/etc/php*/php.ini &gt;&gt; /dev/null 2&gt;&amp;1
[/code:1]

Then for the -i....
[code:1]
eout &quot;{sec.profile} chattr $ECHA $HOME/$pusr/etc/php*/php.ini&quot;
chattr $DCHA $HOME/$pusr/etc/php*/php.ini &gt;&gt; /dev/null 2&gt;&amp;1
eout &quot;{sec.profile} chattr $ECHA $HOME/$pusr/domains/*/etc/php*/php.ini&quot;
chattr $DCHA $HOME/$pusr/domains/*/etc/php*/php.ini &gt;&gt; /dev/null 2&gt;&amp;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 ?

Fri, 06/13/2008 - 06:38 (Reply to #41)
ronald
ronald's picture

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?

Fri, 06/13/2008 - 06:49 (Reply to #42)
sgrayban

use sudo for them and add there access to /etc/sudoers

Fri, 06/13/2008 - 07:08 (Reply to #43)
ronald
ronald's picture

i think not only the file but also the folders need +i as they can still be renamed and recreated.

Fri, 06/13/2008 - 07:15 (Reply to #44)
sgrayban

always could happen -- whats nice about setting a directory +i all the files/directories under it are also protected.

Fri, 06/13/2008 - 08:04 (Reply to #45)
sgrayban

<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.

Fri, 06/13/2008 - 09:06 (Reply to #46)
ronald
ronald's picture

i started a support ticket with this as I have in the template: &quot;do not allow php configuration&quot; (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 :)

Fri, 06/13/2008 - 10:15 (Reply to #47)
velvetpixel

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

Fri, 06/13/2008 - 11:13 (Reply to #48)
ronald
ronald's picture

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.

Fri, 06/13/2008 - 14:38 (Reply to #49)
sgrayban

damn.. you can move the directory still......

Fri, 06/13/2008 - 14:40 (Reply to #50)
sgrayban

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

Topic locked