Security - Recommended update to httpd.conf files via custombuild

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,005
Update:

A patch can now be used instead of the httpd.conf files changes, and is the recommended method.
Use the harden-symlinks-patch option instead of secure_htaccess.
Code:
cd /usr/local/directadmin/custombuild
./build update
./build set harden-symlinks-patch yes
./build set secure_htaccess no
./build apache
./build rewrite_confs
Related knowledgebase entry:
http://help.directadmin.com/item.php?id=421


--------------------------------

Hello,

It's been discovered that it's more secure not to allow the FollowSymLinks option in apache. The only way to truly disable that item is to change the AllowOverride settings in the main httpd.conf. Without the change of the AllowOverride, anyone could simply re-enable in an .htaccess file.

The catch with this change, is that any sites that currently have:
Code:
Options FollowSymLinks
will throw an 500 Internal Server Error. The apache error log entry would look like:
Code:
[Thu Dec 08 03:25:56 2011] [alert] [client 1.2.3.4] /home/[b]username[/b]/domains/[b]domain.com[/b]/public_html/.htaccess: Option FollowSymLinks not allowed here
which would signify that the .htaccess has the FollowSymLinks option, which is no longer allowed to be used.

Since this change as the potential to break existing sites, we will not enable it for existing installs. However, new installs will have this option enabled.
The option is in the custombuild options.conf and is
Code:
secure_htaccess=yes
which, when set and you run
Code:
./build update
./build set secure_htaccess yes
./build rewrite_confs
you'll end up with a httpd-directories.conf symbolic link in /etc/httpd/conf/extra/httpd-directories-new.conf. When set to "no", it will link to httpd-directories-old.conf, which contain the old method of setting up the AllowOverride for the <Directory ..>

Versions entry:
http://www.directadmin.com/features.php?id=1119

John
 

Acceleratic

Verified User
Joined
May 25, 2009
Messages
59
running the custombuild changes will break mod_ruid(2), resulting in:

"Invalid command 'RMode', perhaps misspelled or defined by a module not included in the server configuration"

Apache won't start. Reinstall mod_ruid(2) will do the trick:

/usr/sbin/apxs -a -i -l cap -c mod_ruid2.c

grep mod_ruid2 /etc/httpd/conf/httpd.conf
Result: LoadModule ruid2_module /usr/lib/apache/mod_ruid2.so

Edit:
Better, use the custom configs (thanks SeLLeRoNE)
 
Last edited:

SeLLeRoNe

Super Moderator
Joined
Oct 9, 2004
Messages
6,793
Location
A Coruña, Spain
Actually you should use a custom httpd.conf and remember to fix that before rewrite_confs :)

I had edited my custom one, grepped out the ruid and extension i had added manually and merged in new httpd.conf

Result, no downtime and no errors :)

Pay so much attention when you go to rewrite_confs, be sure to have your backup copy and specially with custombuild your custom versions of file for skip every risk.

Regards
 

Acceleratic

Verified User
Joined
May 25, 2009
Messages
59
That's why we have test servers, so no downtime :) nice message-add with the configs, reply is more complete now.
 

Crusader

Verified User
Joined
Nov 29, 2006
Messages
81
Tried to set secure_htaccess on but had to switch it back off. Anyone know how to use mod_rewrite without symlinks?
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
14,243
Location
GMT +7.00
If you've got /home as a symlink to /usr/home (and all docroots /home/<username>/domains/<domain>/public_html) you'll probably run into troubles with enabling the feature.
 

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,005
I can't recall off the top of my head, but it depends on how SymLinksIfOwnerMatch works.
I *believe*, as long as the owner of the link itself, matches the owner of the file it points to, then apache is happy to follow it.
For /home -> /usr/home, I beleive, they'll both be root.. thus it should in theory work.

John
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
14,243
Location
GMT +7.00
John, I've ran into the issue, so it gave an error:

[Wed Dec 14 14:54:01 2011] [error] [client 195.bbb.ccc.91] Symbolic link not allowed or link target not accessible: /home
and

Code:
# cd /
# ls -la
...
lrwxrwxrwx   1 root root     9 May 16  2011 home -> /usr/home
...
Code:
# cd /usr
# ls -la /
...
drwxr-xr-x 44 root root  4096 Oct 28 15:44 home
...
So I've moved /usr/home to /home
 

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,005
It might not be turned on that high up... although you've already moved it, this may be a possible solution:

1) edit:
/etc/httpd/conf/extra/httpd-directories-new.conf

2) Find the section for <Directory /> and make it look like this:
Code:
<Directory />
        Options [b]SymLinksIfOwnerMatch[/b]
        AllowOverride None

        Order Deny,Allow
        Deny from All
</Directory>
As the /home link is above /home in /.

If it's not a security issue, we can consider making that the new default for httpd-directories-new.conf.

John
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
14,243
Location
GMT +7.00
Then an issue with private_html might occur:



Code:
lrwxrwxrwx 1 root     root        13 May 16  2011 private_html -> ./public_html
drwx--x--x 3 user  user   4096 Dec  2  2010 public_ftp
drwxr-xr-x 5 user  user   4096 Dec 29 15:45 public_html
So you should run

Code:
for user in `ls -1 /home`; do chown -h $user:$user /home/$user/domains/*/private_html; done;
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
14,243
Location
GMT +7.00
It might not be turned on that high up... although you've already moved it, this may be a possible solution:

1) edit:
/etc/httpd/conf/extra/httpd-directories-new.conf

2) Find the section for <Directory /> and make it look like this:
Code:
<Directory />
        Options [b]SymLinksIfOwnerMatch[/b]
        AllowOverride None

        Order Deny,Allow
        Deny from All
</Directory>
As the /home link is above /home in /.

If it's not a security issue, we can consider making that the new default for httpd-directories-new.conf.

John

Thanks John, that works.
 

SeLLeRoNe

Super Moderator
Joined
Oct 9, 2004
Messages
6,793
Location
A Coruña, Spain
It might not be turned on that high up... although you've already moved it, this may be a possible solution:

1) edit:
/etc/httpd/conf/extra/httpd-directories-new.conf

2) Find the section for <Directory /> and make it look like this:
Code:
<Directory />
        Options [b]SymLinksIfOwnerMatch[/b]
        AllowOverride None

        Order Deny,Allow
        Deny from All
</Directory>
As the /home link is above /home in /.

If it's not a security issue, we can consider making that the new default for httpd-directories-new.conf.

John
Agree with this as default :)

Regards
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
14,243
Location
GMT +7.00
The same

Code:
chown -h webapps:webapps /var/www/html/*
should be run.

P.S. FreeBSD versions of chown does not have -h
 

Crusader

Verified User
Joined
Nov 29, 2006
Messages
81
Be sure to remove any references to +FollowSymLinks in any .htaccess files you have if you're turning this setting on!
 

NoBaloney2

NoBaloney Internet Svcs.
Joined
Jun 17, 2007
Messages
498
Location
California
I've just read 14 messages and I'm confused :(. I can only hope no-one else is.

Will someone please write a one-message How-To. After testing it I can move it to it's own thread.

Thanks.

Jeff
 

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,005
Hi Jeff,

FollowSymLinks is insecure.
SymLinksIfOwnerMatch is much better.

The main difference is that SymLinksIfOwnerMatch requires that the owner of the symbolic link match the path that the link is pointing to.

The way we enforce this, is by changing "AllowOverride All" to instead list all possible values that an .htaccess is allowed to override (I wasn't able to find a way to use "AllowOverride ... Options=All,-FollowSymLinks")

The implications of this, is that any .htaccess that has FollowSymLinks in it will throw an internal server error.
If things are setup correctly, swapping FollowSymLinks with SymLinksIfOwnerMatch in any .htaccess files that have it, should be sufficient.

The other catch, is that if you have any custom modules in Apache that add custom entries into the Options list, the new setup won't recognize them, so would throw an error.
They would need to be added to the AllowOverride line in the httpd-directories-new.conf file. (or just don't use this option).

Regarding /home -> /usr/home, I've updated the default as mentioned, so shouldn't be an issue.

Regarding /home/user/domains/domain.com/private_html -> public_html, just make sure the private_html link is owned by the User, and not root.
I'm going to be adding code to DA to address that for the next release.

Beyond that, see my first post for info on enabling this option.

John
 

jjma

Verified User
Joined
Mar 29, 2004
Messages
329
Location
Edinburgh,Scotland
I've just read 14 messages and I'm confused :(. I can only hope no-one else is.

Will someone please write a one-message How-To. After testing it I can move it to it's own thread.

Thanks.

Jeff
Couldn't agree more. Please let's have a one message How-To instead of this preamble.

thanks

Jon
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
14,243
Location
GMT +7.00
Yes, as soon as all issues are collected, that's a good way to do a one message How-To.
 

NoBaloney2

NoBaloney Internet Svcs.
Joined
Jun 17, 2007
Messages
498
Location
California
Just thinking here... I've always known that FollowSymlinks is insecure and I don't use it personally (but as most of you know I do very little coding). But it appears that if we make the change on our shared hosting servers a lot of user stuff may just not work.

So my main question is, should we make any changes at all, or just switch all instances of FollowSymlinks to the more secure version, and then let people do what they want in their own .htaccess files, but warn them in our monthly mailing? Or is the insecurity serverwide, and therefore must we make sure no one can user it at all?

Jeff
 

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,005
I've always known that FollowSymlinks is insecure and I don't use it personally
It's not a matter of simply "not using it", it's a matter of making sure that User's can't use it for serverwide protection. Previously, they it could be enable it in their .htaccess files.

But it appears that if we make the change on our shared hosting servers a lot of user stuff may just not work
Correct. Any .htaccess that has FollowSymLinks in it with throw an internal sever error with this change. This is why we've made it optional.

I highly recommend making the change though. It may take a few attempts at turning the option on and off until all .htaccess files are cleared out, but for the sake of security, it's recommended.
If you're clients are all 100% trusted, and you know they've got no security issues, then the necessity is less, but this adds an extra layer of protection.

I've written this little script to hunt out all .htaccess files that may contain FollowSymLinks (case insensitive search):
Code:
#!/bin/sh
for i in `find /home/ | grep .htaccess`; do
{
        DATA=`grep -i FollowSymLinks $i`
        if [ "$DATA" != "" ]; then
                echo "$i: $DATA";
        fi
};
done;
exit 0;
or just switch all instances of FollowSymlinks to the more secure version
Yes, swapping FollowSymLinks with SymLinksIfOwnerMatch would be recommended, if they need links.
Note that SymLinksIfOwnerMatch is already enabled by default for /home/*, so you don't need to worry about turning it on.

John
 
Top