LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Advisory Watch: December 12th, 2014
Linux Security Week: December 9th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
HowTo: Secure your Ubuntu Apache Web Server Print E-mail
User Rating:      How can I rate this item?
Source: www.linuxsecurity.com - Posted by Administrator   
Features Setting up a web server with Apache on a Linux distribution is a very quick process, however to make it a secure setup takes some work. This article will show you how to make your Apache web server more secure from an attack by effectively using Access control and authentication strategies.



Bill Keys
All the examples below assumes that you are using Ubuntu 7.10 with a basic Apache configuration setup. However, these examples will help any user running an Apache server to make it more secure since the concepts will still apply. This HOWTO should be used on a test server then once that is secure migrated to a production web server.



File Permissions and Access Control

Users and groups:

One of the first things to ensure is that Apache does not run as root because if Apache is cracked then an attacker could get control of the root account. Lets take a look at what user and group Apache is running as.

Run the following command:

# ps auwwfx | grep apache www-data 25675 0.0 0.0 10348 508 ? S Jan21 0:00 \_ /usr/sbin/apache2 -k start
www-data 25686 0.0 0.2 231816 2208 ? Sl Jan21 0:00 \_ /usr/sbin/apache2 -k start
www-data 25688 0.0 0.2 231816 2200 ? Sl Jan21 0:00 \_ /usr/sbin/apache2 -k start
As you can see www-data is the user running Apache. However if it's not then you need to edit your Apache configurations and create a new user and group by:

# groupadd www-data
# useradd -g www-data www-data
# vi /etc/apache2/apache2.conf
Change:
User root
Group root
To:
User www-data
Group www-data
Do a reload to make sure the changes take effect:
# /etc/init.d/apache2 reload
Permissions to serve files:

One of the most overlooked security practices is correctly using the chmod command. For example, we just created a index.cgi in our Apache html root directory but when we go to open the file in our browser we get the error message permission denied. To get our index.cgi file working we do a chmod 777 index.cgi. Before you try this, every Apache administrator should think to themselves' is this secure? The answer should be NO! But how do we make the permissions secure enough and allow the index.cgi script to work?
chmod:
Apache needs to have permission to execute the index.cgi file. However, we don't want everyone to read and write to index.cgi. The owner of the file should have permission to read and write to the file. We do this by:
# chmod 755 index.cgi
Files outside the web root should not be served:

It's very important to have the following lines in your apache.conf:

Options FollowSymLinks
AllowOverride None

Notes
1.The above lines prevent Apache from having access to files outside of its web root.
2.Some distributions have better default security configuration then others. EnGarde Secure Linux is one example where they include the above lines in their Apache configuration file by default.

We don't want users running CGI scripts anywhere on the filesystem but we do need them to run in the web root. The solution to this problem is the "Options ExecCGI" directive.

Example:
Add the following lines to /etc/apache2/apache2.conf:

AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
Reload apache:
# /etc/init.d/apache2 reload
What if your have resources that should only be accessed by a certain network or IP address?
A solution to this problem is using our Apache configuration to enforce it for you.

Example only allow access to network 192.168.0.0.

Change the following lines in your /etc/apache2/apache2.conf:

AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
To:

AllowOverride None
Options ExecCGI
Order Deny,Allow
Deny from all
Allow from 192.168.0.0/16
Do a reload to make sure the changes take effect:
# /etc/init.d/apache2 reload
Now only users on you internal network can run CGI script in "/home/username/public_html/cgi-bin"

Authentication

How can we allow only users with the correct password and username to have access to a part of our web root? The following steps will show you how to do this securely.

Basic authentication:

Enable .htaccess
# vi /etc/apache2/apache2.conf
Change:
AllowOverride None
To:
AllowOverride AuthConfig
Do a reload to make sure the changes take effect:
# sudo /etc/init.d/apache2 reload
Create a password file:
# mkdir /var/www/misc
# chmod a+rx /var/www/misc
# cd /var/www/misc
# htpasswd -bc private.passwords username password
Adding password for user username

Create .htaccess
# cd /home/username/public_html/cgi-bin
# vi .htaccess
Add the below in .htaccess
AuthName My Private Area"
AuthType Basic
AuthUserFile /var/www/misc/private.passwords
AuthGroupFile /dev/null require valid-user
Change:

AllowOverride None
Options ExecCGI
Order Deny,Allow
Deny from all
Allow from 192.168.0.0/16

To:

AllowOverride .htaccess
Options ExecCGI
Order Deny,Allow
Deny from all
Allow from 192.168.0.0/16

Do a reload to make sure the changes take effect:
# /etc/init.d/apache2 reload
Digest authentication:
Another method for authentication is called digest authentication. With digest authentication your password is never sent across the network in the clear because they are always transmitted as an MD5 digest of the user's password. This way passwords cannot be determined by sniffing network traffic:
Create a password file:
# mkdir /var/www/misc
# chmod a+rx /var/www/misc
# cd /var/www/misc
# htdigest -c private.passwords realm username
Adding password for username in realm realm.
New password:
Create .htaccess
# cd /home/username/public_html/cgi-bin
# vi .htaccess
Add the below in .htaccess
AuthName "My Private Area"
AuthType Digest
AuthUserFile /var/www/misc/private.passwords
AuthGroupFile /dev/null require valid-user
Notes
1.For more information on htdigest please check the man pages.
2.Some older versions of Web browsers don't support Digest authentication.
3.To fully protect your .htaccess use SSL.

Where to go from here?
The next step in a more secure Apache is to use some of the Apache modules decided for helping Apache security even more. Some examples are mod_security and mod_chroot. Also, to protect our authentication we will need to configure SSL. In a upcoming HOWTO it will show you how to use SSL to further increase your web server's security and other advance techniques. What ways would you suggest to best secure a Apache web server?

References:

Security Tips for Server Configuration:
Apche.org - Security Tips

Security and Apache: An Essential Primer:
Linuxplanet/- Apache Tutorial

Apache Homepage:
http://www.apache.org

Comments
Written by S.MacLeod on 2008-01-30 13:21:32
What ways would you suggest to best secure a Apache web server? 
 
Install the latest security patches 
 
httpd.conf: 
ServerSignature Off 
ServerTokens Prod 
 
Disable any unnecessary modules 
 
Make sure only root has read access to apache's config and binaries 
 
Lower the Timeout value 
 
Limiting large requests 
 
Limiting Concurrency 
 
Adjusting KeepAlive settings 
 
suEXEC 
http://httpd.apache.org/docs/2.0/suexec.html 
 
CGIWrap 
http://cgiwrap.sourceforge.net/ 
 
Acknowledgments: 
These ideas are sourced from the folloing two pages; 
 
Pete Freitag - 20 ways to Secure your Apache Configuration 
http://www.petefreitag.com/item/505.cfm 
 
Apache > Miscellaneous Documentation > Security Tips 
http://httpd.apache.org/docs/2.0/misc/security_tips.html
Nice how-toWritten by jon on 2008-01-29 20:29:24
I am looking forward to the next Apache HowTo
what am i missingWritten by chris on 2008-03-17 13:22:48
I added "Options FollowSymLinks AllowOverride None" to /etc/apache2/apache2.conf and reloaded. 
it responded with: 
Invalid command 'AllowOveride', perhaps misspelled or defined by a module not included in the server configuration 
...fail! 
THIS IS WHY ADDING STUFF TO APACHE2.confWritten by DJ on 2008-04-07 13:01:17
Fellas I realized you have to add this stuff to the default file 
 
the file for me is located in /etc/apache2/sites-available/default 
 
use your favorite text editor to edit the "default" file. 
 
-DJ
AllowOverrideWritten by jon on 2008-04-07 13:29:41
hi chris  
 
Looks like you missed spelled AllowOveride which should be AllowOverride. 
 
Invalid command 'AllowOveride',
Written by Humbert WrenchWhistle on 2008-06-04 13:54:29
You're how to is terrible, it misses IMPORTANT information such as the tags and FAILS, COMPLETELY FAILS, at showing correct formatting. You also give bad options such Order Deny, Allow WHICH ONLY TAKES ONE ARGUMENT. Thank you for floodng the internet with incomplete information in the form of a knowledgeable "how-to."
Humbert? How about Humbug...Written by Brummbaer on 2009-06-05 00:50:16
Take it easy there turbo... Way to go Bill. Though not exhaustive, it's a great start to setting up a secure apache config. Keep it up, look back to coming back for more.
I have some question(easy for you, hard Written by Pear on 2009-06-14 13:48:09
How to configure the web server, so that each user on our server can have his own web page?

Only registered users can write comments.
Please login or register.

Powered by AkoComment!

 
< Prev   Next >
    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
University of California, Berkeley Hacked, Data Compromised
London teen pleads guilty to Spamhaus DDoS
New England security group shares threat intelligence, strives to bolster region
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.