Analysis of Ubuntu Apache Web server security maintenance instance

Setting a Web server in a Linux release is a very fast process, but it may take some time to make this configuration a secure process. This article will show you how to effectively use access control and authentication policies to make your Apache Web Server more secure. All the examples below assume that you are using Ubuntu7.10 and have made basic configuration for Apache. However, these examples will help any user running the Apache server to achieve greater security, because they are still applicable to other Linux systems. The methods involved in this article should first be tested on a test server before being migrated to a actually used Web server.

I. File license and Access Control

1. users and groups

The first thing to ensure is that Apache should not run as root, because if Apache is cracked, attackers can control the root account. Let's take a look at the identity of which user and group Apache is running:

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

It can be seen that www-data is the user who runs Apache. However, we need to edit Apache configuration and create a new user and group:

# Groupadd www-data
# Useradd-g www-data
# Vi/etc/apache2/apache2.conf

Change User root Group root:

User www-data Group www-data

Then reload to make the change take effect:

#/Etc/init. d/apache2 reload

2. Service document permission

One of the most easily overlooked security questions is how to correctly use the chmod command. For example, an index. cgi file is created in the Apache html root directory, but the access is denied when the file is opened in the browser. To make our index. cgi File work normally, we execute chomod 777 index. cgi. During this test, is every Apache administrator considering this security? The answer is no. However, how can we make this license safe enough and allow the index. cgi script to run properly?

Apache needs to be authorized to access the index. cgi file. However, we do not want everyone to read and write index. cgi. The owner of the file should have permission to read and write the file. To do this, we need the following command:

# Chmod 755 index. cgi

It is important to add the following line to your Apache. conf file:

Options FollowSymLinks AllowOverride None

Note:

1. The preceding command line prevents Apache from accessing files other than root.

2. Some Linux versions have better security than other versions. EnGarde Secure Linux is a good example, because it contains the above Code lines in its Apache configuration file by default.

We don't want users to run CGI scripts anywhere on the file system, but we do need them to run in root. The solution to this problem is the "Options ExecCGI" command.

For example, add the following rows to the/etc/apache2/apache2.conf file:

AllowOverride None Options ExecCGI Order allow, deny Allow from all

Reload Apache:

#/Etc/init. d/apache2 reload

What if you have resources that should only be accessed by a certain network or IP address? The solution to this problem is to use our Apache configuration to enhance security for you:

In this example, you must change the following line in the/etc/apache2/apache2.conf file:

AllowOverride None Options ExecCGI Order allow, deny Allow from all

Change it:

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

Then reload to make the change take effect:

#/Etc/init. d/apache2 reload

Currently, only users on your internal network can run cgi scripts in/home/username/public_html/CGI-bin.

Ii. Authentication

How can we only allow users with the correct password and user name to access some web root users? The following steps show you how to do this securely:

1. Basic Verification

Allow. htaccess:

# Vi/etc/apache2/apache2.conf

Change AllowOveride None to AllowOveride AuthConfig

Reload to make the change 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 following command to. htaccess:

AuthName My Private Area "AuthType Basic AuthUserFile/var/www/misc/private. passwords AuthGroupFile/dev/null require valid-user

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

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

Then reload to make the change take effect:

#/Etc/init. d/apache2 reload

2. Digest authentication)

Another verification method is digest verification. If digest verification is used, your passwords are not transmitted in plain text over the network, because they are always transmitted as an MD5 Digest of the user's password. If this method is used, the user's password cannot be determined by the network communication method through sniffing.

Create a password file as follows:

# 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. New password:

Create. htaccess:

# Cd/home/username/public_html/cgi-bin # vi. htaccess

Add the following content to. htaccess:

AuthName "My Private Area" AuthType Digest AuthUserFile/var/www/misc/private. passwords AuthGroupFile/dev/null require valid-user

Note:

1. Some old Browsers Do not support Digest authentication)

2. SSL must be used to completely protect your. htaccess

Iii. Summary

The next step to make Apache more secure is to use the Apache module to help achieve better security, such as mod_security and mod_chroot. In addition, to protect our verification, we also need to configure SSL.