With the significant prevalence of Linux web servers globally, security is often touted as a strength of the platform for such a purpose. However, a Linux based web server is only as secure as its configuration and very often many are quite vulnerable to compromise. While specific configurations vary wildly due to environments or specific use, there are various general steps that can be taken to insure basic security considerations are in place. . Many risks are possible from a compromise including using the web server into a source of malware, creating a spam-sending relay, a web or TCP proxy, or other malicious activity. The operating system and packages can be fully patched with security updates and the server can still be compromised based purely on a poor security configuration. Security of web applications first begins with configuring the server itself with strict security in mind. Many will often deploy various layers such as a WAF, IDS, or Mod Security to react in real time to various hacking and threats for HTTP requests. However, securing the entire server and any running services with a high level of security in mind is the first fundamental step to avoid the risk of being hacked or compromised. With the abundance of malware being installed into web applications hosted on Linux based servers (such as the many recent timthumb.php WordPress plugin vulnerabilities), it is clear many servers are configured with little or no security in mind. For users of personal blogs, a compromise is often an embarrassment and inconvenience. However for small and large businesses, having a site or blog of your company serving up malware from a compromise is a loss of business and creates a very poor reflection of your company's IT services on the public as well as potential clients. Web servers that are compromised and serving malware often are then very quickly flagged in Google's Safe Browsing listing which most all major browsers subscribe. When flagged, often 24 hours or more are needed to clear thelisting as the Safe Browsing check only scans sites once a day for changes. Do not let this happen to your company's website! Information Leakage The first and relatively trivial configuration changes that should be made are to disable any information leakage from your server. All Linux distributions have poor default configurations in regards to information leakage for Apache and other services. While most dismiss this as not a concern, the less information you broadcast to a hacker, the better. Every request to your Apache web server can reply back with information such as the exact OpenSSL version, PHP version, and many other items. While some applications like OpenSSH require the broadcasting of their version in the banner for operation, there is no functional reason for Apache to broadcast its version number to the world, and likewise nor any other related Apache modules. Fetching the HTTP headers with curl from as an example can provide the following information publicly: $ curl -I HTTP/1.1 200 OK Date: Sun, 25 Mar 2012 02:11:54 GMT Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 Phusion_Passenger/2.2.11 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Python/2.5.2 Last-Modified: Mon, 15 Dec 2008 03:07:18 GMT ETag: "c622-f16-45e0d23f9c580" Accept-Ranges: bytes Content-Length: 3862 Content-Type: text/html The server signature is also displayed on any 404 pages: The following changes can be made to eliminate both Apache and PHP from disclosing their version information. Apache configurations: ServerTokens Prod ServerSignature Off TraceEnable Off Header unset ETag FileETag None PHP configurations to be made in php.ini: expose_php = Off display_errors = Off track_errors = Off html_errors = Off After making those changes and restarting Apache, the same curl command to fetch HTTP headers now provides minimal information: $ curl -I HTTP/1.1 200 OK Date: Sun, 25 Mar 2012 02:13:01 GMT Server: Apache Last-Modified: Sat, 24 Jul 2010 18:21:28 GMT Accept-Ranges: bytes Content-Length: 15 Vary: Accept-Encoding Content-Type: text/html Review Additional Running Services It is critical to review and disable any services running on the host that are not required. Many often run a 'web server' and unknowingly are running many other various services which all need to be reviewed and secured. If other services are running on the same web server, the banner for those services should be edited to remove any broadcast of the version number or other non-required information that is leak. Other services one might run might include SMTP (Postfix banner, or Sendmail banner), SSH (ssh suffix banner), or even DNS (BIND also has a banner!). While these services may be completely separate from any web application or web server, be aware that they too broadcast version information and can often provide additional information to a potential hacker. Nmap can be used to quickly scan open services running on the host and also report back the banner being advertised by each service. The nmap command to use is: $ sudo nmap -sV [target] Below is a particularly exposing Linux server with many services open to the internet, all broadcasting version information in the banners: $ sudo nmap -sV Password: Starting Nmap 5.51 ( https://nmap.org/ ) at 2012-03-24 21:46 EDT Nmap scan report for (192.168.1.120) Host is up (0.051s latency). rDNS record for 192.168.1.120: test. Not shown: 986 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.1p1 Debian 5 (protocol 2.0) 25/tcp open smtp Postfix smtpd 53/tcp open domain ISC BIND 9.6-ESV-R4 80/tcp open http Apache httpd 2.2.9 ((Debian) DAV/2 SVN/1.5.1 Phusion_Passenger/2.2.11 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Pyth...) 110/tcp open ssh OpenSSH 5.1p1 Debian 5 (protocol 2.0) 111/tcp open rpcbind 135/tcp filtered msrpc 139/tcp filtered netbios-ssn 443/tcp open ssl/http Apache httpd2.2.9 ((Debian) DAV/2 SVN/1.5.1 Phusion_Passenger/2.2.11 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Pyth...) 445/tcp open netbios-ssn Samba smbd 3.X (workgroup: HOME) 465/tcp open ssl/smtp Postfix smtpd 587/tcp open smtp Postfix smtpd 1720/tcp filtered H.323/Q.931 4444/tcp filtered krb524 Service Info: Host: ; OS: Linux Below are a few common services that could also be running on your web host which can have the banner configured to reveal a minimal amount of information: Disable SSH banner suffix Debian and Ubuntu allow users to disable the Debian version suffix of the SSH banner by setting the following in /etc/ssh/sshd_config: DebianBanner no Disable Postfix banner The banner for Postfix is easily configurable in /etc/postfix/main.cf by editing the following line as desired: smtpd_banner = Hello! Hopefully samba is not open to the internet, but the samba server banner is configurable in /etc/samba/smb.conf server string = Samba Server Version %v Remove Version from BIND banner Use this configuration in your named.conf to disable the broadcast of the version: options { version "Not disclosed"; } Firewall Considerations All Linux servers should make use of the built-in software firewall which in most cases is iptables.
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 haveaccess 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: https://www.apache.org/ . Fortify your Ubuntu-based Apache web server by deploying crucial access restrictions and robust authentication measures to thwart potential threats.. Apache Security, Ubuntu Server, Access Control, Authentication, Security Practices. . Anthony Pell
Get the latest Linux and open source security news straight to your inbox.