Apache Security - Ivan Ristic [129]
Centralized Logging
As the number of servers grows, the ability to manually follow what is happening on each individual server decreases. The "standard" growth path for most administrators is to use host-based monitoring tools or scripts and use email messages to be notified of unusual events. If you follow this path, you will soon discover you are getting too many emails and you still don't know what is happening and where.
Implementing a centralized logging system is one of the steps toward a solution for this problem. Having the logs at one location ensures you are seeing everything. As an additional benefit, centralization enhances the overall security of the system: if a single host on the network is breached the attacker may attempt to modify the logs to hide her tracks. This is more difficult when logs are duplicated on a central log server. Here are my recommendations:
Implement a central log server on a dedicated system by forwarding logs from individual servers.
Keep (and rotate) a copy of the logs on individual servers to serve as backup.
The machine you put your logs on becomes (almost) the most important machine on the network. To minimize the chances of it being breached, logging must be the only thing that machine does.
You will find that the syslog daemon installed by default on most distributions is not adequate for advanced configurations: it only offers UDP as a means of transport and does not offer flexible message routing. I recommend a modern syslog daemon such as syslog-ng (http://www.balabit.com/products/syslog_ng/). Here are its main advantages over the stock syslog daemon:
It supports reliable TCP-based logging.
It offers flexible message filtering capabilities.
It can combine reliable logging with other tools (such as Stunnel) to achieve encrypted delivery channels.
Network Monitoring
If you decide to implement central logging, that dedicated host can be used to introduce additional security to the system by implementing network monitoring or running an intrusion detection system. Intrusion detection is just another form of logging.
Network monitoring systems are passive tools whose purpose is to observe and record information. Here are two tools:
Ntop (http://www.ntop.org)
Argus (http://qosient.com/argus/)
Argus is easy to install, easy to run, and produces very compact logs. I highly recommend that you install it, even if it runs on the same system as your main (and only) web server. For in-depth coverage of this subject, I recommend Richard Bejtlich's book The Tao of Network Security Monitoring: Beyond Intrusion Detection (Addison-Wesley).
Intrusion detection system (IDS) software observes and reacts to traffic-creating events. Many commercial and open source IDS tools are available. From the open source community, the following two are especially worth mentioning:
Snort (http://www.snort.org)
Prelude (http://www.prelude-ids.org)
Snort is an example of a network intrusion detection system (NIDS) because it monitors the network. Prelude is a hybrid IDS; it monitors the network (potentially using Snort as a sensor), but it also supports events coming from other types of sensors. Using hybrid IDS is a step toward a complete security solution.
The term intrusion prevention system (IPS) was coined to denote a system capable of detecting and preventing intrusion. IPS systems can, therefore, offer better results provided their detection mechanisms are reliable, avoiding the refusal of legitimate traffic.
Intrusion detection and HTTP
Since NIDSs are generic tools designed to monitor any network traffic, it is natural to attempt to use them for HTTP traffic as well. Though they work, the results are not completely satisfying:
Encrypted communication is mandatory for any secure web application, yet network-based intrusion detection tools do not cope with SSL well.
NIDS tools operate on the network level (more specifically, the packet level). Though