Hardening Web Servers
Hardening Web Servers: Web servers are one of the favorite areas for attackers to exploit because of the reach they have.
If an attacker can gain access to a popular web server and take advantage of a weakness there, they have the opportunity to reach thousands, if not hundreds of thousands, of users who access the site.
By targeting a web server, the attacker can actually affect all the connections from user’s web browsers and inflict harm far beyond the one machine they compromised.
Web servers were originally simple in design and used primarily to provide HTML text and graphics content.
Modern web servers allow database access, chat functionality, streaming media, and virtually every other type of service that can be contemplated.
This diversity gives websites the ability to provide rich and complex capabilities to web surfers.
Every service and capability supported on a website is potentially a target for exploitation. Make sure that they are kept up with the most current software standards.
You must also make certain that you are allowing users to have only the minimal permissions necessary to accomplish their tasks.
If users are accessing your server via an anonymous account has only the permission needed to view web pages and nothing more.
Two particular areas of interest with web servers are filters and controlling access to executable scripts.
Filters allow you to limit the traffic that is allowed through. Limiting traffic to only that which is required for your business can help ward off attacks.
NOTE: A good set of filters can also be applied to your network to prevent users from accessing sites other than those that are business related.
Not only does this increase productivity, but it also decrease the likelihood of users obtaining a virus from questionable site.
Executable scripts, such as those written in PHP, Python, various flavors of Java, and Common Gateway Interface (CGI) scripts, often run at elevated permission levels.
Under most circumstances this is not a problem because the user is returned to their regular permission level at the conclusion of the execution.
Problem arises, however, if the user can break out of the script while at the elevated level. From an administrator’s stand point, the best course of action is to verify that all scripts on your server have been thoroughly tested, debugged, and approved for use.
TIP: On all web servers, one account is created when services are installed that is used to represent the anonymous user.
Rights assigned to this account apply to all anonymous web users. With IIS, for example, that account is IUSR_computername, whereas in Apache it can be any account that you choose to assign as the anonymous user (often nobody, apache, or webusers).