Security - Recommended update to httpd.conf files via custombuild

DirectAdmin Support · Dec 8, 2011

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 · Dec 12, 2011

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)

SeLLeRoNe · Dec 12, 2011

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 · Dec 12, 2011

That's why we have test servers, so no downtime

nice message-add with the configs, reply is more complete now.

Crusader · Dec 13, 2011

Tried to set secure_htaccess on but had to switch it back off. Anyone know how to use mod_rewrite without symlinks?

zEitEr · Dec 14, 2011

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 · Dec 14, 2011

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 · Dec 14, 2011

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 · Dec 14, 2011

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 · Dec 14, 2011

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 · Dec 14, 2011

DirectAdmin Support said:
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 · Dec 14, 2011

DirectAdmin Support said:
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 · Dec 14, 2011

The same

Code:

chown -h webapps:webapps /var/www/html/*

should be run.

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

Crusader · Dec 14, 2011

Be sure to remove any references to +FollowSymLinks in any .htaccess files you have if you're turning this setting on!

NoBaloney2 · Dec 15, 2011

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 · Dec 15, 2011

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 · Dec 16, 2011

NoBaloney2 said:
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 · Dec 16, 2011

Yes, as soon as all issues are collected, that's a good way to do a one message How-To.

NoBaloney2 · Dec 16, 2011

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 · Dec 16, 2011

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

Security - Recommended update to httpd.conf files via custombuild

Administrator

Verified User

Super Moderator

Verified User

Verified User

Super Moderator

Administrator

Super Moderator

Administrator

Super Moderator

Super Moderator

Super Moderator

Super Moderator

Verified User

NoBaloney Internet Svcs.

Administrator

Verified User

Super Moderator

NoBaloney Internet Svcs.

Administrator