MarGib – The World Behind the Keyboard: Linux RHCE - Web Server

🌐 🇵🇱 Polski · 🇬🇧 EN

Apache is the most popular and widely used web server on the internet. It is available for many operating systems such as UNIX, LINUX, Microsoft Windows, BSD, OS X and appears as a component of many packages offering additional software like PHP or databases, e.g., XAMPP, LAMP, WAMP, etc. The project's homepage is http://httpd.apache.org/. The main features of the server are multithreading, scalability, security, access control, CGI, proxy, and module support, including mod_ssl. The first version was officially released in April 1995. Currently, the latest server releases already include a graphical configuration interface that parses settings into the httpd.conf file.

APACHE SERVER INSTALLATION

Step 1 - Installing required packages

# yum install -y httpd mod_ssl

Step 2 - Verifying that all necessary packages are in the system

# rpm -qa | grep http
httpd-tools-2.2.15-15.el6.i686
httpd-2.2.15-15.el6.i686

# rpm -qa | grep ssl

openssl-1.0.0-20.el6.i686

mod_ssl-2.2.15-15.el6.i686

Step 3 - Setting services to start with the operating system

# chkconfig httpd on

Step 4 - Verifying the changes made

# chkconfig --list httpd

httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

WEB SERVER CONFIGURATION

After installing the appropriate packages, we can focus on the configuration files and their locations. During installation, the /var/www directory was created, which is where we place website files. There are also several configuration files such as:

/etc/httpd/conf/httpd.conf Main configuration file

/var/log/httpd Web server logs

/usr/lib64/httpd/modules Modules for the Apache server

After installing the server, its configuration located in the main configuration file is ready to use immediately. However, it is worth familiarizing yourself with the available options that can be configured, as there are quite a few, and they are all well-documented. The information in the file is grouped into sections.

Basic global configuration options:

ServerRoot - Location for storing configuration files

Timeout - Time period between requests after which the connection is terminated

Listen - Listening port number

User - User under which the web server service is run

Group - Group under which the web server is run

LoadModule - Definition of modules loaded at web server startup

Basic options for the web server

DocumentRoot - Location of website files

ServerName - Definition of server name, IP address, and port number

Let's start with the configuration related to the location of website files. By default, it is /var/www/html, but if necessary, we can change it.

In the main configuration file, we can also find a section named "Directory":

<Directory "/var/www/html">

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>

The parameters defined here indicate the location where the website files will be found, but if we want to change the location for website files, it must be done in:

DocumentRoot "/var/www/html"

This also applies to the configuration of virtual hosts, which will be discussed later. If the configuration is satisfactory and we agree with the set parameters, we can perform a test to check the configuration file for syntax errors:

# service httpd configtest

httpd: Could not reliably determine the server's fully qualified domain name, using RHEL01.example.com for ServerName

Syntax OK

The above error concerns an unset server name matching the host the server is on; after uncommenting the appropriate option and providing the suggested server name, the error was resolved.

# service httpd configtest

Syntax OK

If we want to restart the server, we use the command:

# service httpd restart

Stopping httpd: [ OK ]

Starting httpd: [ OK ]

We can also reload the server configuration files without restarting the entire service using:

# service httpd reload

There is one more option for restarting the server that allows loading new configuration files without disconnecting a single client currently using the web service.

# service httpd graceful

IPTABLES AND SELINUX CONFIGURATION

Step 1 - Adding appropriate iptables firewall rules

iptables -I INPUT 5 -p tcp -m tcp --dport 80 -j ACCEPT

Step 2 - Saving iptables settings

# service iptables save

iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]

Step 3 - Restarting the system firewall service

# service iptables restart

iptables: Flushing firewall rules: [ OK ]

iptables: Setting chains to policy ACCEPT: filter [ OK ]

iptables: Unloading modules: [ OK ]

iptables: Applying firewall rules: [ OK ]

The above setting opens port 80, on which the service runs, for everyone. However, it is often the case that for some reason we need to block a subnet and leave service access only to selected subnets or hosts.

To make httpd service access possible only for a given subnet, we can introduce a restriction in the form of:

iptables -I INPUT -s 192.168.56.0/24 -p tcp --dport 80 -j ACCEPT

This entry will restrict access for hosts located in the 192.168.56.0/24 subnet.

We can also go further and apply a restriction to a single host

iptables -I INPUT -s 192.168.56.102 -p tcp --dport 80 -j ACCEPT

Now you can only see the websites while being on the local host or 192.168.56.102

Going even further, we have the ability to block access on the local host as well and leave it only from a specific selected machine or subnet. Blocking access from the local machine can be done by blocking the local IP address, e.g., (192.168.56.101)

iptables -I INPUT -s 192.168.56.101 -p tcp --dport 80 -j REJECT

This entry will also block access to websites from the host the server is on.

SELINUX OPTIONS

httpd_can_network_relay - Allows httpd to act as a relay

htttp_can_network_connect_db - Allows httpd scripts and modules to connect to a database.

httpd_use_gpg - Allows httpd to enable gpg in the gpg-web domain

httpd_enable_cgi - Allows support for CGI

httpd_use_cifs - Allows httpd to have access to CIFS

allow_httpd_mon_auth_pam - Allows the use of mod_auth_pam

allow_httpd_anon_write - Allows modification of public files

httpd_enable_homedirs - Enables reading of home directories

allow_httpd_sys_scripts_anon_write - Allows apache scripts to modify the content of a public directory; the directory must have the public_rw_content_t context

httpd_dbus_avahi - Enables communication with the avahi service

httpd_unified - Unification of handles for all file contents

httpd_can_network_connect - Allows httpd scripts and modules to connect to the network via TCP

allow_httpd_mod_auth_ntlm_winbind - Allows the use of mod_auth_pam

httpd_tty_comm - Unified communication with the terminal.

httpd_read_user_content - Allows access to user files

httpd_use_nfs - Access to NFS file systems

httpd_tmp_exec - Access to files in the /tmp directory

httpd_execmem - Allows adding /execmem and /execstak modules

httpd_can_sendmail - Allows the httpd service to send emails

httpd_builtin_scripting - Allows the httpd service to use scripts, usually PHP

httpd_can_check_spam - Spam checking by httpd

httpd_can_network_connect_cobbler - Allows scripts and modules to have a connection to the cobbler network

httpd_ssi_exec - Allows httpd to run SSI in the same domain as CGI scripts

httpd_enable_ftp_server - Allows httpd access to an FTP server and listing files via the FTP port

httpd_setrlimit - Allows the httpd service to change system limits.

To run a basic web service on your own network, there is no need to make any changes to the configuration files. Almost every new option not included in the basic settings requires configuring SELinux settings. When working with web services, one must remember the existence of an additional requirement in the form of SELinux. Apache uses file contexts due to the existence of different content available on the disk.

The context of every newly created directory must be set to the httpd server user so that it can gain proper access to it.

Let's assume, for example, that we need to create two new directories intended for two separate clients:

Step 1 - Creating directories for clients:

# mkdir /var/www/strona1
# mkdir /var/www/strona2

Step 2 - Checking what contexts we currently have for files:

# ls -Z /var/www/
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 error
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 icons
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 strona1
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 strona2

The contexts for client directories need to be changed to match the defaults for websites (html location)

Step 3 - Using the chcon command, we change the context for the domain user

# chcon -Rvu system_u /var/www/strona1
changing security context of `/var/www/strona1'

# chcon -Rvu system_u /var/www/strona2

changing security context of `/var/www/strona2'

Step 4 - We can also refer to the default directory with one command

# chcon --reference /var/www/html/ /var/www/strona2

This is a transfer of the set context on a known file, in this case, the default set context of the html directory, where after installation you can place website files, to another selected or newly created directory that will also have the task of storing website files.

Step 5 - Now we can check the correctness of the contexts for the new locations

# ls -Z /var/www/

drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin

drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 error

drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html

drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 icons

drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 strona1

drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 strona2

TROUBLESHOOTING APACHE

One of the best tools for troubleshooting Apache are log files. Apache server log files have a separate location from system logs to make them easier to find. We have two basic files that we can analyze to resolve problems with the Apache server.

/var/log/httpd/access_log Log of all accesses to the server
/var/log/httpd/error_log Information about server errors

Usually, analyzing the above files provides sufficient information to resolve problems. In the main configuration file, there is a section that allows setting the logging level for the httpd service.

If we use secure sites, there are three additional files for SSL:

/var/log/httpd/ssl_access_log Logging access to a secure site
/var/log/httpd/ssl_error_log Logging information about errors with the ssl site
/var/log/httpd/ssl_request_log Logging requests from the client to the server

As we already know, to check the syntax correctness of the main configuration file, we use the "config-test" command. One of the common errors when starting the service is a message stating that the "ServerName" has not been set, so the server defaults to 127.0.0.1. To get rid of this inconvenience, we set the server name. We can also set the amount of information contained in the logs using the "LogLevel" parameter in the main configuration file.

ELINKS

Another useful tool that can be helpful when troubleshooting Apache is the "elinks" web browser. It is a text-based browser that allows you to quickly check if a website is working. To use this tool, we must install additional packages.

Step 1 - Installing required packages

# yum install -y elinks

Step 2 - After installation, we can test the site's operation by issuing the command:

elinks 192.168.56.101

We should see the content of the file: /var/www/html/index.html

We can also check SSL operation

# elinks https://172.168.1.1

For now, it won't work yet!

APACHE SECURITY

Above, we have already presented how to add rules to the firewall and the principles of SELinux contexts. Here, security methods and configuration settings regulating access to the web server service will be discussed in even more detail.

Securing the service on the host

The first way to secure it is to restrict access to the httpd server from a specific subnet. We do this by entering options in the "Listen" parameter in the main configuration file:

Listen <server_IP_address>:<port>

Listen 192.168.56.101:80

After restarting the server service, the sites will only be available from the specified subnet.

Another way to secure it is the <Directory> directive in the main configuration file:

<Directory "/var/www/html">

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from 192.168.56.102

</Directory>

Such an entry in the configuration file restricts access to the /var/www/html directory and its contents. Access is possible only from the selected host, in this case, it is host 192.168.56.102

Other possible configurations are:

Access restricted to a given domain:

<Directory "/var/www/html">

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from .example.com

</Directory>

Note that the domain name is provided starting with a dot!

Access restricted to a given subnet

<Directory "/var/www/html">

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from 192.168.1

</Directory>

Note that the address should end at the 3rd octet without a dot

After specifying the hosts that should or should not have access to the web server, you need to define the order in which the rules are applied.

Order allow, deny Selected addresses will be allowed first

Order deny, allow Access denial will be performed first.

If we want to allow a given address, we use the option that we first allow the given address and block the rest; alternatively, if we want to block a given address, we block it at the beginning and allow the rest.

In this directive, there are also options:

Option Indexes - If the index.html file does not exist, the listed content of the directory will appear on the page

FollowSymLinks - You can create a symbolic link in the operating system where you point to another directory outside of the one defined in the directive.

AllowOverride - Does not allow regular users to change root files

The above options can be applied to other directories with different options set relative to each other. There is also a <Directory> section without a defined directory, and all options set in it will be superiorly applied to all others below.

Securing the service from the client side

Here, we will secure a given directory by giving access only to selected users. There are the following options for restricting access to users:

AuthType - Defines the authentication type

AuthName - Defines the comment displayed to the user when logging in

AuthUserFile - Sets the file used to store user logins and passwords

AuthGroupFile - Sets the file to store logins and passwords for a group

Require - Sets which groups and users can log in

We will practice the above with an example. We secure the main page provided by the web server, making it available only to user User01.

Step 1 - In the <Directory> directive, we add the parameters:

<Directory "/var/www/html">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from 192.168.56.102
AuthType Basic
AuthName "Secured page not for you"
AuthUserFile /etc/httpd/userfile
Require user user01

</Directory>

Step 2 - Creating the userfile file

# htpasswd -cm /etc/httpd/userfile user01
New password:
Re-type new password:
Adding password for user user01

The -c option causes the file to be created, and we use it once if the file does not exist yet. The next option, -m, uses MD5 encryption when saving passwords to the file, so they are not stored in plain text.

Step 3 - Restarting the web server

# service httpd restart

Step 4 - Checking operation in the browser

We should be asked for a login and password, and after entering the password and login, we will see the page.

Another option is to allow access to the main page, while requiring login when opening other subpages.

Step 1 - In the configuration file, we make further changes

Options Indexes FollowSymLinks

AllowOverride authconfig

Order allow,deny

Allow from 192.168.56.1

AuthType Basic

AuthName "Secured page not for you"

AuthUserFile /etc/httpd/userfile

Require user user01

</Directory>

Step 2 - Creating a location with a subpage

In the /var/www/html directory, we create a new directory: # mkdir katalog in which the secured page will be.

Step 3 - In the created directory, we create a .htaccess file

# vi .htaccess

entering the content into the file:

AuthType Basic

AuthName "You do not have access to this file without logging in"

AuthGroupFile /etc/httpd/groupfile

Require group hr_users

Step 4 - Creating several users

# htpasswd -m /etc/httpd/userfile hr01

New password:

Re-type new password:

Adding password for user hr01

# htpasswd -m /etc/httpd/userfile hr02

New password:

Re-type new password:

Adding password for user hr02

Step 5 - Creating the groupfile file

We create the file: # vim /etc/httpd/groupfile in which we enter:

hr_users: hr01 hr02

Step 6 - Restarting the web server

# service httpd restart

Step 7 - Checking operation

In the browser, you can see the main page, but after going to the directory, there will be a request to log in.

Sharing pages from user home directories

We can also enable sharing pages from user home directories on the web server.

To do this, you must:

# mkdir public_html (create a subdirectory in the user's home directory)

# chmod 701 /home/user01/

# chmod 705 -R /home/user01/public_html/

After doing the above, you need to check the SELinux settings

# getsebool -a | grep httpd

allow_httpd_anon_write --> off

allow_httpd_mod_auth_ntlm_winbind --> off

allow_httpd_mod_auth_pam --> off

allow_httpd_sys_script_anon_write --> off

httpd_builtin_scripting --> on

httpd_can_check_spam --> off

httpd_can_network_connect --> off

httpd_can_network_connect_cobbler --> off

httpd_can_network_connect_db --> off

httpd_can_network_memcache --> off

httpd_can_network_relay --> off

httpd_can_sendmail --> off

httpd_dbus_avahi --> on

httpd_enable_cgi --> on

httpd_enable_ftp_server --> off

httpd_enable_homedirs --> off

httpd_execmem --> off

httpd_read_user_content --> off

httpd_setrlimit --> off

httpd_ssi_exec --> off

httpd_tmp_exec --> off

httpd_tty_comm --> on

httpd_unified --> on

httpd_use_cifs --> off

httpd_use_gpg --> off

httpd_use_nfs --> off

By changing the appropriate option:

# setsebool -P httpd_enable_homedirs=1

Checking the changes made:

# getsebool -a | grep httpd

...

httpd_enable_homedirs --> on

...

Now you can check the operation in the browser:

http://192.168.56.101/~user01/

Remember to use the ~ sign before the username.

HTTPS CONFIGURATION - SSL

Besides normal sites, we can also have secure sites using the HTTPS protocol. Configuring secure sites in Apache is simple. For secure sites, we need the mod_ssl package, so if it is not in the system, it must be installed. If the package is installed in the system, we will have access to the configuration file /etc/httpd/conf.d/ssl.conf, which contains configuration parameters for securing the web server.

Let's check what we can configure in this file:

# grep -v ^# /etc/httpd/conf.d/ssl.conf

LoadModule ssl_module modules/mod_ssl.so

Listen 443

SSLPassPhraseDialog builtin
SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300
SSLMutex default
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
<VirtualHost _default_:443>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

The most important options in this file are: Listen and the parameters defined between the <VirtualHost _default_:443></VirtualHost> tags.

By default, secure sites are placed on virtual hosts (which is very good because they can operate independently of existing sites)

You should also pay attention to two options:

SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

These options define and point to the location of files containing the keys used for sharing secure sites. Although the default options will work as they are after installation, if we change the IP address or the pair of domain names, it becomes necessary to generate a new certificate and key. To generate certificates and keys, you must install the crypto-utils package. Generating keys and certificates is not a topic for the RHCE exam.

Step 1 - Creating iptables firewall rules

# iptables -I INPUT 5 -p tcp -m tcp --dport 443 -j ACCEPT
# iptables -I INPUT 5 -p tcp -m tcp --dport 80 -j ACCEPT
(if it wasn't opened earlier)

Step 2 - Saving iptables settings

# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
[root@RHEL01 ~]# service iptables restart
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: [ OK ]

Step 3 - Restarting the iptables service

# service iptables restart

iptables: Flushing firewall rules: [ OK ]

iptables: Setting chains to policy ACCEPT: filter [ OK ]

iptables: Unloading modules: [ OK ]

iptables: Applying firewall rules: [ OK ]

CGI APPLICATION

Here, in a few steps, I will show how to run a CGI application in the Apache server.

Step 1 - Creating a directory for the application

# mkdir /var/www/web-app

Step 2 - Placing a file with a sample application in the created directory

# cd /var/www/webapp

# vim app.sh

app.sh

            #!/usr/bin/perl

            print "Content-type: text/html\n\n";

            print "Hello, world!\n";

Step 3 - In the configuration file /etc/httpd/conf/httpd.conf, we add the entry:

ScriptAlias /webapp "/var/www/webapp"

Options ExecCGI FollowSymLinks

Order allow,deny

Allow from all

</Directory>

Step 4 - Checking if the file syntax is correct

# service httpd configtest

Syntax OK

Step 5 - Setting appropriate permissions on the directory

# chmod -R 755 /var/www/webapp/

Step 6 - Restarting the web server service

# service httpd restart

VIRTUAL HOSTS

A great advantage of the Apache web server is the ability to run multiple sites on one web server. This is done by configuring virtual hosts. The configuration is located in the main Apache configuration file httpd.conf in the third section:

NameVirtualHost - Specifies the name or IP address for the virtual host

ServerAdmin - Specifies the email address for the webmaster

DocumentRoot - specifies the directory for virtual host files

ServerName - Defines the URL for the virtual host

ErrorLog - specifies the error log file location

CustomLog - specifies the custom log location

To run a virtual host in the Apache server, you need to add the following entry in the last part of the httpd.conf configuration file:

Uncomment the line: NameVirtualHost *:80

<VirtualHost *:80>

</VirtualHost>

By creating an empty virtual host, we prevent overwriting settings for the local web server, so that after entering the site address leading to files located in the default /var/www/html location, the sites will work correctly. Next, we configure the virtual host.

<VirtualHost *:80>

ServerAdmin webmaster@station1.example.com
DocumentRoot /StronyWWW/
ServerName stronywww.example.com
ErrorLog logs/stronywww.example.com-error_log
CustomLog logs/stronywww.example.com-access_log common

<Directory "/StronyWWW" >

AllowOverride None
Order Allow,Deny
Allow from 192.168.0

</Directory>

</VirtualHost>

Pay attention to the lines:

ServerName - the site address under which the files will be visible

<Directory "/file location" > - the path to the web files for the given virtual host

Allow from - specifying who has permission to view the sites.

Also, remember that the created directory, in this case /Stronywww , must have the appropriate SELinux context.

system_u:object_r:httpd_sys_content_t:s0 StronyWWW

We can take care of the appropriate context by referring to it with the chcon command:

chcon --reference /var/www/html/ /StronyWWW/

The above configuration allows viewing sites from the default directory and from the /Stronywww directory at the address http://stronywww.example.com (remember to add appropriate entries to the /etc/hosts files on the machines from which you will test the operation).

Securing access to a virtual host is done the same way as in the default server, i.e., by setting appropriate parameters in the <Directory> directive.

AllowOverride authconfig

and creating a .htaccess file in which we add sample entries:

AuthType Basic

AuthName "You do not have access to this file without logging in"

AuthUserFile /Stronywww/.userfile

Require user user01

Creating the .userfile file

# htpasswd -cm /Stronywww/.userfile user01
New password:
Re-type new password:
Adding password for user user01

CGI applications in virtual hosts

Step 1 - Creating a directory for your own application

# mkdir /var/www/moje-cgi

Step 2 - Setting the correct context

# chcon --reference /var/www/cgi-bin /var/www/moje-cgi

Step 3 - Creating the application and placing it in the /var/www/moje-cgi directory

# vim /var/www/moje-cgi/app.pl

in the app.pl file enter:

#!/usr/bin/perl

print "Content-type: text/html\n\n";

print "Hello, world!\n";

Step 4 - Giving the application execution permissions

# chmod +x /var/www/moje-cgi/app.pl

Step 5 - In the /etc/httpd/conf/httpd.conf file, we create a virtual host by adding the entry:

<VirtualHost *:80>

ServerAdmin webmaster@aplikacja.example.com

DocumentRoot /var/www/moje-cgi

ServerName aplikacja.example.com

ErrorLog logs/aplikacja.example.com-error_log

CustomLog logs/aplikacja.example.com-access_log common

ScriptAlias /cgi-bin/ /var/www/moje-cgi/

Options +ExecCGI

AddHandler cgi-script cgi pl

</Directory>

</VirtualHost>

Special attention should be paid to the entries contained between the <Directory></Directory> tags. It is important to remember the dash that appears in the AddHandler cgi-script cgi pl line. Without the dash, during the http service restart, we will not see any error or information about bad syntax. It is different if the final cgi pl are missing, in which case we will see an error.

After saving the httpd.conf file and restarting the httpd service, you can see the result:

# elinks http://aplikacja.example.com/app.pl

Remembering to add the appropriate entry in the /etc/hosts file

192.168.56.101 host1.example.com strona1.example.com strona2.example.com aplikacja.example.com

Linux RHCE - Web Server - Apache Web Server

Comments

Explore

Labels

Blog archive

Z bloga