Apache Server Vulnerabilities

Apache server

The Apache Web Server

The Apache HTTP Server is a web server application based on NCSA HTTPd. Development of Apache began in early 1995 after work on the NCSA code stalled, and it quickly overtook HTTPd as the dominant web server, and has been the most popular web server in use since April 1996. As of June 2013, Apache was estimated to server 54.2 percent of all active websites, so if you come across a website, there’s a better than even chance that it’s hosted by an Apache server (this site is).

The Apache server supports a variety of features. Many of these features are implemented as compiled modules which extend the core functionality. Some common language interfaces support Perl, Python, Tcl, and PHP. Other features include Secure Sockets Layer and Transport Layer Security support. Because the source code is freely available, anyone can adapt the server for specific needs, and there is a large public library of Apache server add-ons.

Although the main design goal of the Apache server is not to be the fastest web server, Apache does have performance similar to other high-performance web servers. Instead of implementing a single architecture, Apache provides a variety of MultiProcessing Modules (MPMs) which allow Apache to run in a process-based, hybrid (press and thread) or event-hybrid mode, to better match the demands of each particular infrastructure. The multi-threaded architecture implemented in Apache 2.4 should provide for performance equivalent or slightly better than event-based webservers.

Apache Server Vulnerabilities

All software systems have the same general types of vulnerability and Apache is no different. It can be adversely affected by any one of the following problems: [1] poor application configuration; [2] unsecured web-based code; [3] inherent Apache security flaws, and [4] fundamental OS vulnerabilities.

Apache has many default settings that require modification for secure operation. Nearly all configuration information for Apache Web server exists within the httpd.conf file and associated Include files. Because many configuration options exist within these files, it can be easy to make configuration errors that expose the application to attack.

The second manner in which vulnerabilities are exposed is via poorly implemented code on the Apache server. Often, Web developers are far more concerned with business functionality than the security of their code. For instance, poorly written dynamic web pages can be easy denial of service (DoS) targets for attackers, should coded limitations be absent from back-end database queries. Simply publishing confidential or potentially harmful information without authentication can provide enemies with ammunition for attack. For these reasons, you must review and understand not only the Apache application but the information and functionality being delivered via the system.

As with Microsoft’s IIS server, vulnerabilities can exist within the Apache server’s application code itself. There are many means by which hackers can breach or disable an Apache system, such as:

  • Denial of Service (DoS)
  • Buffer overflow attacks
  • Attacks on vulnerable scripts
  • URL manipulation

Occasionally, Apache security flaws are discovered and announced by Apache or by various security groups. The Apache development team is typically quick to respond and distribute patches in response to such events. For this reason, it is critical that you be vigilant in your attention to security newsgroups and to Apache’s security advisory site.

Another source of vulnerability within an Apache web server could occur as a result of foundational security flaws in the OS on which Apache is installed. Apache can be run on just about any OS. You should be very familiar with the specific security vulnerabilities for any OS on which you run Apache.

In the next article, we will discuss the merits of patching and securing the OS as a means of securing your Apache server.

External Links:

The official Apache web site

Apache HTTP Server at Wikipedia

The official Apache Software Foundation web site

Apache web server resource site

Network Security: Disabling Services

network securityI thought it might be a good idea to do a series of articles on network security, and to kick it off I’m going to cover disabling unnecessary services. This article assumes your network is running Linux, at least for services.

As a Linux administrator you will want to know and define the following elements:

  • The role of the server (web, database, proxy, etc.)
  • Services that are required to perform a specific server role (e.g. Apache)
  • Ports required to be opened (e.g. port 80 for HTTP)

All the other services should be disabled and all other ports should be closed. When these tasks are performed, the server becomes a specialized server to play only the designated role.

To ensure network security by hardening a server, you must first disable any unnecessary services and ports. The process involves removing any unnecessary services, such as rlogin, and locking down unnecessary Transmission Control Protocol or User Datagram Protocol (TCP/UDP) ports. Once these services and ports are secure, you must then regularly maintain the system.

Network Security: Controlling Services

Different Linux distributions have different front ends to control services. For example, in Red Hat Linux, you can enable and disable services by navigating to System -> Administration -> Services and opening the Service Configuration utility. From there, you may select or deselect the services, start, stop or restart them and edit the run level of individual services. Although most modern Linux distros have enhanced their GUIs to cover most of the administrative tasks, it is important for admins to know how to perform the tasks without a GUI.

Linux has greater network security than most operating systems; even so, the Linux kernel is being constantly updated and there are undoubtedly many security vulnerabilities that have not yet been discovered. Most Linux services are not vulnerable to this exploits; however, an administrator can reduce the risk by removing unnecessary services. Virtually every Linux distribution includes many services, so it makes sense that administrators customize the system to meet their or their company’s needs, as removing unnecessary services also removes risk and thus improves network security.

No matter what distribution of Linux you are using, the /etc/inetd.d or /etc/xinetd.d directory (for some newer releases, including Red Hat). This is the default configuration file for the inetd (or xinetd) daemon. This files in this directory enable you to specify the daemons to start by default and supply the arguments that correspond to the desired style of functioning for each daemon. It controls many services, include File Transfer Protocol (FTP) and Telnet. It determines what services are available to the system what services are available to the system. inetd or xinetd is a super server listening for incoming network activity for a range of services. It determines the actual nature of the service being requested and launches the appropriate server.

The /etc/inetd.conf (or /etc/xinetd.conf) directs requests for services to the /etc/inetd.d (or /etc/xinetd.d) directory. Each service has a configuration in this directory. If a service is commented out in its specified configuration file, the service is unavailable. Because inetd/xinted is so powerful, for optimal network security only the root should be able to configure its services.

Network Security: Disabling Telnet, FTP and rlogin

While most admins find in convenient to log in remotely their Linux/Unix machines over a network for administrative purposes, in a high-network security environment, only physical access may be permitted for administering a server. In this case, you should disable the Telnet interactive login utility. Because of security vulnerabilities in FTP, you should disable it as well, and use SFTP (Secure FTP) if necessary. To accomplish these two objectives, do the following:

  • Edit the /etc/inetd.d/telnet (or xinetd.d/telnet) file by opening the file, using vi or the editor of your choice
  • Comment out the service telnet line by adding a number sign (#) before service telnet
  • Write and quit the file
  • Restart inetd or xinetd by entering:
    /etc/rc.d/init.d/inetd restart
    or for xinetd:
    /etc/rc.d/xinit.d/xinetd restart
  • Attempt to log onto the system using Telnet. You should fail.
  • Diable the FTP service using the same method.
  • Attempt to access the system via FTP. You should fail.

The remote login (rlogin) service is enabled by default in the /etc/inetd.d/rlogin (or /etc/xinetd.d/rlogin) file. Rlogin has security vulnerabilities because it can bypass the password prompts to access a system remotely. There are two services associated with rlogin: login and RSH (remote shell). To disable these services you have to open the rlogin file and comment out the service login line, and then open the rsh file and comment out the service shell line. Restart xinetd to ensure your system is no longer offering these services. Disabling these three services will go a long way towards improving network security on your Linux server.

External links:

inetd at Wikipedia

© 2013 David Zientara. All rights reserved. Privacy Policy