The Importance of Securing a Linux Web Server

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.

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

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 the listing 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:

[sourcecode]

$ curl -I example.com

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

[/sourcecode]

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:

[sourcecode]

ServerTokens Prod

ServerSignature Off

TraceEnable Off

Header unset ETag

FileETag None

[/sourcecode]

PHP configurations to be made in php.ini:

[sourcecode]

expose_php = Off

display_errors = Off

track_errors = Off

html_errors = Off

[/sourcecode]

After making those changes and restarting Apache, the same curl command to fetch HTTP headers now provides minimal information:

[sourcecode]

$ curl -I example.com

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

[/sourcecode]

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:

[sourcecode]

$ sudo nmap -sV [target]

[/sourcecode]

Below is a particularly exposing Linux server with many services open to the internet, all broadcasting version information in the banners:

[sourcecode]

$ sudo nmap -sV example.com

Password:

Starting Nmap 5.51 ( http://nmap.org ) at 2012-03-24 21:46 EDT

Nmap scan report for example.com (192.168.1.120)

Host is up (0.051s latency).

rDNS record for 192.168.1.120: test.example.com

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 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...)

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: example.com; OS: Linux

[/sourcecode]

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:

[sourcecode]

DebianBanner no

[/sourcecode]

Disable Postfix banner

The banner for Postfix is easily configurable in /etc/postfix/main.cf by editing the following line as desired:

[sourcecode]

smtpd_banner = Hello!

[/sourcecode]

Hopefully samba is not open to the internet, but the samba server banner is configurable in /etc/samba/smb.conf

[sourcecode]

server string = Samba Server Version %v

[/sourcecode]

Remove Version from BIND banner

Use this configuration in your named.conf to disable the broadcast of the version:

[sourcecode]

options {

version "Not disclosed";

}

[/sourcecode]

Firewall Considerations

All Linux servers should make use of the built-in software firewall which in most cases is iptables. Red Hat makes a very easy command line interface for managing the firewall. There is no longer a need to write intricate iptables scripts unless there is a particular need or desire to do so. Debian and Ubuntu incorporate an application called ufw which is a command line interface for iptables. Using ufw, simple commands can open or close ports again without the need of being an iptables wizard.

Red Hat's firewall management tool:

[sourcecode]

# system-config-firewall-tui

[/sourcecode]

Regardless if additional firewalls are in place, the host internal software firewall should always be enabled. Only allowed services should be able to communicate in and out of specified ports and network interfaces. Consider if a company's perimeter firewall is compromised. Then the only layer of defense would be that of the software firewall on the host. And similarly, if the host is compromised through a web application, restricting access of network traffic of that host will provide some protection against island hopping or other intrusions.

Disabling ICMP - Not Required

Many administrators will often disable or filter ICMP requests, though this has no security benefits. In the case of something like DNS, ICMP requests are actually used in the DNS spec to query if a server is available before sending the DNS request. ICMP replies are extremely beneficial to web servers as well and can serve in troubleshooting a web server that appears to not be responding to HTTP requests. The threat of a ping flood is minimal today. Unless the attacker has considerably larger network bandwidth than the target, the flood attempt is going to cause little effect. Ping echo replies take very little CPU from the target to reply so it is perhaps a bit like throwing many small pebbles in attempt to take down a brick wall. This is why most DoS attacks today focus on HTTP requests instead of ICMP so to drive up CPU and memory usage from the web server which is far more effective to execute. In short, there is no reason to disable ICMP.

Permissions

File and directory permissions in Linux is often a confusing topic which leads to differing views, especially in the case of web directories and files. The worst advice, which should never be followed, is to change files or folders to 777. This allows anyone in the world to execute or write to your server. The best example of this is rogue Wordpress plugins that malicious hackers push to servers via a simple HTTP POST command. If directory permissions are 777, this allows anyone to then read, write, or execute anything in that directory including posting malicious code.

Many Wordpress users in particular have been recently compromised by a malicious plugin which was installed because users incorporated 777 permissions on the Wordpress installation.

Below is an example log of an attacker remotely installing a remote exploit plugin directly to the Wordpress plugin directory with a single HTTP POST request:

[sourcecode]

xx.xx.xxx.xxx - - [06/Mar/2012:03:17:41 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)"

[/sourcecode]

In general, directories should be 750 or 755. Files should be 644 or 640.

The following commands can be used to locate problematic directories and files on your web server which are 777.

Locate directories that are 777 on your server:

[sourcecode]

$ sudo find /var/www/ -type d -perm -002

[/sourcecode]

Locate files that are 777 on your server:

[sourcecode]

$ sudo find /var/www/ -type f -perm -002

[/sourcecode]

Apart from the read/write/execute permissions, ownership permission also needs attention. The web directory on your server should not be owned by the apache user. A regular user should be the owner of the web directory, and the group should be the apache user. Even if the read/write/execute permissions are accurate, a rogue or runaway process or php application can then have full access to make changes to your entire web directory.

This ownership change can make the push button upgrades for Drupal and Wordpress problematic unfortunately. In being security mindful, it is best to temporarily change ownership to the apache user for the purposes of applying upgrades through a web interface, and then change the ownership back to a regular user after push button upgrades are complete.

Below is an example hacker administration page for a server that was compromised from poor permissions where the apache user was the owner and group:

PHP Applications

Running PHP on a Linux server is required for many popular applications such as Drupal, Wordpress, and others. New vulnerabilities are found in not only poorly written PHP code but in the language itself at an alarming rate. Since PHP if often paired along with MySQL a PHP compromise can mean a compromise of the accompanying MySQL database for the web server. For these purposes, it is critical to be on top of any PHP software or plugin updates. Do not install or use PHP code from unknown sources. For blogging software, minimize the number of plugins or extensions in use. If a plugin or add-on is not activated or in use for the blog or website, remove the unused files from the server.

Insure that 404 pages for the server do not provide any extraneous information and do not interpret what was put in the URL bar. Visit a random 404 page on the web server as a test such as http://example.com/asdf. The results of the 404 page should only provide a generic 'Sorry, that page was not found' and not try to interpret or relay results that the user placed in the URL bar. 404 pages that allow user input manipulation are an entry point for attackers to craft XSS and other malicious attempts.

Monitoring Logs

Logs are a critical part for monitoring the security of a web server. Many tools exist in Linux distributions to automate log monitoring. The application logwatch sends a daily email report of all of the logs on the server to inform on varying log entries such as the number of emails sent, potential web attackers and IPs causing errors in Apache logs, to ssh attempts and other aspects.

In a large corporate environment it is common to send logwatch emails along with other mail directed to the root user (cron errors, and other system messages) to a single company email list. Administrators in the company then subscribe to that single email list to stay informed of any alarming notifications in various servers' logs for the company.

Additional Resources

The NSA has in the past published many documents on hardening and securing Red Hat Linux servers which can also apply to other distributions. At time of this blog post, the NSA has taken down links to these guides. However the document is still available at this location:

http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

Conclusions

Linux is a popular operating system for web servers and web hosting and is unfortunately likewise a popular target for compromise. Consideration for strict security is needed to ensure attacks and attempts for inserting malicious code are to be avoided. Taking care to reduce information leakage, restrict permissions, keep PHP and other applications updated, and monitor all server logs will help keep the administrator on top of any attack vectors to avoid compromise.