Apache Security - Ivan Ristic [183]
Though most vendors are focusing on supporting HTTP, the concept of application firewalls can be applied to any application and protocol. Commercial products have become available that act as proxies for other popular network protocols and for popu: There is no ID/IDREF binding for IDREF 'swtadn-CHP-7-ITERM-525'. lar databases. (Zorp, at http://www.balabit.com/products/zorp/, available under a commercial and open source license, is one such product.)
Learn more about intrusion detection to gain a better understanding of common problems. I have found the following resources useful:
"Intrusion Detection FAQ" by SANS (http://www.sans.org/resources/idfaq/)
Managing Security with Snort & IDS Tools by Kerry J. Cox and Christopher Gerg (O'Reilly)
Is Intrusion Detection the Right Approach?
Sometimes there is a controversy as to whether we are correct to pursue this approach to increasing security. A common counterargument is that web intrusion detection does not solve the real problem, and that it is better to go directly to the problem and fix weak web applications. I agree with this opinion generally, but the reality is preventing us from letting go from IDS techniques:
Achieving 100-percent security is impossible because we humans have limited capabilities and make mistakes.
Attempting to approach 100-percent security is not done in most cases. In my experience, those who direct application development usually demand features, not security. Attitudes are changing, but slowly.
A complex system always contains third-party products whose quality (security-wise) is unknown. If the source code for the products is unavailable, then you are at the mercy of the vendor to supply the fixes.
We must work with existing vulnerable systems.
As a result, I recommend we raise awareness about security among management and developers. Since awareness will come slowly, do what you can in the meantime to increase security.
Log-Based Web Intrusion Detection
I already covered one form of web intrusion detection in Chapter 8. Log-based web intrusion detection makes use of the fact that web servers produce detailed access logs, where the information about every request is kept. It is also possible to create logs in special formats to control which data is collected. This cost-effective method introduces intrusion detection to a system but there is a drawback. Log-based web intrusion detection is performed only after transactions take place; therefore, attack prevention is not possible. Only detection is. If you can live with that (it is a valid decision and it depends on your threat model), then you only need to take a few steps to implement this technique:
Make sure logging is configured and takes place on all web servers.
Optionally reconfigure logging to log more information than that configured by default.
Collect all logs to a central location.
Implement scripts to examine the logs regularly, in real time or in batch mode (e.g., daily).
That is all there is to it. (Refer to Chapter 8 for a detailed discussion.)
Real-Time Web Intrusion Detection
With real-time intrusion detection, not only can you detect problems, but you can react to them as well. Attack prevention is possible, but it comes with a price tag of increased complexity and more time required to run the system. Most of this chapter discusses the ways of running real-time web intrusion detection. There are two approaches:
Network-based
One network node screens HTTP traffic before it reaches the destination.
Web server-based
An intrusion detection agent is embedded within the web server.
Which of these two you choose depends on your circumstances. The web server-based approach is easy to implement since it does not mandate changes to the network design and configuration. All that is needed is the addition of a module to the web server. But if you have many web servers, and especially if the network contains proprietary web servers, then having a single place from which to perform intrusion