Securing a Linux Web Server

    Date28 Apr 2015
    CategoryFeatures
    281556
    Posted ByAnthony Pell

    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 the listing as the Safe Browsing check only scans sites once a day for changes.

    040512 1427 TheImportan1

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

    The server signature is also displayed on any 404 pages:

    040512 1427 TheImportan2

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

     

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

    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. <a href="http://intenseschool.com/boot_camp/red_hat/rhcsa_boot_camp.php">Red Hat</a> 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:

     

    # system-config-firewall-tui

    040512 1427 TheImportan3

    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:

     

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

    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:

     

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

    Locate files that are 777 on your server:

     

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

    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:

    040512 1427 TheImportan4

    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. For more information about Linux security in general, InfoSec Institute offers several popular linux certification courses.

    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.

    Scott Miller is a security researcher for InfoSec Institute. InfoSec Institute is a security training company that has helped over 18,000 information security professionals since 1998.

    You are not authorised to post comments.

    Comments powered by CComment

    LinuxSecurity Poll

    Do you read our distribution advisories on a regular basis?

    No answer selected. Please try again.
    Please select either existing option or enter your own, however not both.
    Please select minimum 0 answer(s) and maximum 3 answer(s).
    /component/communitypolls/?task=poll.vote&format=json
    23
    radio
    [{"id":"84","title":"Yes, for a single distribution","votes":"0","type":"x","order":"1","pct":0,"resources":[]},{"id":"85","title":"Yes, for multiple distributions","votes":"5","type":"x","order":"2","pct":62.5,"resources":[]},{"id":"86","title":"No","votes":"3","type":"x","order":"3","pct":37.5,"resources":[]}]["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"]["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"]350
    bottom200

    We use cookies to provide and improve our services. By using our site, you consent to our Cookie Policy.