You can guard your Web server from misuse and malicious attack by tracking HTTP sessions, or by using SSL. You can also prepare for hackers with booby traps or software weapons. However, consider for a moment that your Apache server may not just be a Web server. There may be other services running, and on a network that means an intruder may use alternative means to crack your server. Thus, for the network administrator, Web site or server security is inconsequential, as the focus should always be on overall network security. Keep this big picture in mind and consider the following prudent network security measures.
Apache’s mission in life is to service HTTP on a server. By definition, Apache is running on a server that hosts HTTP applications, probably Web sites, even if other things are also going on in the background. It is often (but not always) true that this Apache server will be part of a larger network, perhaps including other Apache HTTP servers as well as servers hosting a broader range of services.
In this environment, Apache is keeping its ear to the ground for HTTP requests on port 80 (and port 443, if you’re running SSL). Industry continuity in this area is maintained by a “standard” list of Internet Assigned Numbers Authority (IANA) port assignments, and you can scan your ports to compare active port numbers with this list. The various services running on the servers in your network can therefore be identified and “authorized” with such a comparison.
How do you do this scanning? You have a network status utility called netstat. It will list all the services running on a server that are, at any moment, waiting for requests. This is useful, but inconvenient if you have multiple servers: netstat is purely a local utility. If you want to get network status on a particular nonlocal server, use nmap.
# nmap [scan type] [options] <host IP>
It will list open ports on a specified server and is useful for anticipating network intrusion. You basically see whatever a potential intruder sees, in terms of possible points of entry. Think of it this way: If you’ve got your Web stuff locked down, but the intruder is still determined to crack the server, a port scan will give the intruder a list of other services that might be vulnerable. And by doing regular port scans, you can be one step ahead.
What does the hacker use?
Hackers can use telnet, or some similar utility, to ferret out your server’s range of services one at a time. They can find out other administrative information—such as which version of Apache you’re using—while they’re at it.
Thinking about it from this point of view, what you really want is for your servers to be anonymous to everyone but you! This is easier to achieve than you might think. You can foil attempts to scope out your server’s software versions and service activities with the ServerTokens directive. This directive is found in your Apache configuration (httpd.conf) and informs the server to limit its self-disclosure. There are four modes, ranging from all-known-information to name-only. You can check to see what the server is saying about itself, before and after the application of this directive, by running # telnet <host IP>, or by doing a version check with # httpd –v. In addition, server information is also appended to error messages. You can get rid of this information by turning off the ServerSignature directive.
Other server targets
Now that you know how to look for nefarious network activity and understand how an intruder is looking at your network, think about the other vulnerable services running on your servers. Two obvious at-risk services are smtp and ftp. Often these services are enabled when they aren’t needed (and on an Apache HTTP server, they are unnecessary). See if any such services are coming up when you restart the server with a port scan. If something is there that doesn’t need to be, go into system startup and modify it to disable these services.
While the above method is fine for dealing with unnecessary protocols, what about non-HTTP services that legitimately require port access? How can you guard against intrusion if you can’t disable the service? The solution is to borrow access control capabilities from the server software of other servers. For instance, you can establish a buffer server between your Apache server and your network gateway and screen inbound requests by protocol, thus giving the non-HTTP services on your Apache server a guardian one step out from the server itself. You must research the access control capabilities of the buffer server’s administrative software in order to know specifically how to do this on your network.
There is also the concept of a reverse proxy server, an interim server that acts as an agent for the Apache HTTP server. This is a variation on the theme above, enabling a single access point for all your Apache traffic (even if you have multiple Apache servers) and coordinating external port screening activity with the firewall. One advantage is that the intruder will never see the actual IP of any of your Apache servers—they’ll only see the IP of the reverse proxy.
Check the OS
Beyond these concepts, you may wish to examine the protocol security features of your server’s operating system. It may seem that with the steps above, and various other security measures you’ve put in place, that you’re as well-protected as you need to be. But a single successful attack is all it will take to convince you that there’s always more you can do.