Mitigating the WASC Web Security Threat Classification with Apache / Page 4

[previous] [next]

Mitigating the WASC Web Security Threat Classification with Apache

» Failure URL. Similar to the technique mentioned previously, you could also create a Mod_Security filter that would trigger a 401 status code if the authentication program sends the client to a specific "failure" URL. Here is an example filter:

Anti-Brute Force Code

Apache doesn't natively have any capability to track failed login attempts for specific user accounts. The best way to track that, outside of updating the application's code, is to use the 401 CGI scripts to send emails to security personnel. In this scenario, the recipient of the email will have to apply some analysis to identify Brute Force attacks against specific accounts. The best way to identify and react to an automated Brute Force attack against your site is to use Mod_Dosevasive. We touched on the high-level concepts of the module in Chapter 5, "Essential Security Modules for Apache;" however, now it is time to get into more detail and practical tips.

Mod_Dosevasive works equally well whether it is facing an application layer DoS attack or a Brute Force attack against one or more accounts. This is due to the similarity of request characteristics from the web server's perspective when these two attacks are executed. They both have a mapping of a remote IP address connecting to a certain URL. In the case of a Brute Force attack, the URL just happens to have access controls implemented that require authentication. Mod_Dosevasive is not aware of this authentication, but is still effective in identifying this as an automated attack due to the velocity of requests received in the time interval observed.

When Mod_Dosevasive identifies an attack, it will deny (blackhole) the offending IP address for the time period specified in the DOSBlockingPeriod directive. This method has its uses; however, IP address restrictions must also be used with caution. Blocking a NATed proxy IP Address may prevent a large portion of legitimate user traffic as well. The main problem here is that only using the client IP address and URI as associations causes false positives. In order to better identify unique clients who may be connecting behind a proxy server, we can include the "User-Agent" information to the hash token. This creates a hash token of – Remote IP_User-Agent->URI. This extra variable will help us to avoid denying innocent clients. Here is a small snippet of the source code from before the update:

Here is the updated code:

While this concept does provide some level of protection from denying legitimate clients who happen to be behind a proxy, it does open up one more issue. What if an attacker were to update their DoS attack script to use rotating User-Agent fields? Sound too far fetched? Well, it isn't. In Chapter 10, "Open Web Proxy Honeypot," I present concrete evidence of an attacker using this same strategy when using my Apache Open Proxy Honeypot. So, how do we combat this? I spoke with the Mod_Dosevasive creator, and the consensus was to implement code that will set a threshold on the total number of different User-Agent fields allowed per IP Address in the timeframe specified. This will catch attackers who are using rotating/spoofed User-Agent fields. By the time this book comes out, the updated code we have discussed here should be available either from the Mod_Dosevasive web site or from my personnel site.

References

• Brute Force Attack, Imperva Glossary
• iDefense: Brute-Force Exploitation of Web Application Session ID's [PDF], by David Endler—iDEFENSE Labs

Insufficient Authentication

Insufficient Authentication occurs when a web site permits an attacker to access sensitive content or functionality without having to properly authenticate. Web-based administration tools are a good example of web sites providing access to sensitive functionality. Depending on the specific online resource, these web applications should not be directly accessible without having the user required to properly verify their identity.

To get around setting up authentication, some resources are protected by "hiding" the specific location and not linking the location into the main web site or other public places. However, this approach is nothing more than "Security Through Obscurity." It's important to understand that simply because a resource is unknown to an attacker, it still remains accessible directly through a specific URL. The specific URL could be discovered through a Brute Force probing for common file and directory locations (/admin, for example), error messages, referrer logs, or perhaps documented in help files. These resources, whether they are content or functionality driven, should be adequately protected.

Insufficient Authentication Example

Many web applications have been designed with administrative functionality location directory off the root directory (/admin/). This directory is usually never linked to anywhere on the web site, but can still be accessed using a standard web browser. Because the user or developer never expected anyone to view this page since it's not linked, adding authentication is often overlooked. If an attacker were to simply visit this page, he would obtain complete administrative access to the web site.

Apache Countermeasures for Insufficient Authentication

Relying on "Security by Obscurity" is a recipe for disaster. I much prefer "Security with Obscurity." This means that it is a reasonable step to not publicly link to these administration functions of your web site; however, this should not be the only means of security that you apply. As discussed in Chapter 4, "Configuring the httpd.conf File," we can implement both host-based and user-based access control to these URLs. Using the (/admin/) directory from the example, we can implement appropriate access control with the following directives in the httpd.conf file:

This directive container for the "/admin/" location will force the following:

The connection must be over SSL. Uses Digest Authentication. The username "admin" and the correct password must be supplied.

[previous] [next]

URL: