So now that we seen multiple tools, each in its own small little realm, what could be done if we take them and harvest the benefit of each of them? First we need to remember that the goal here is to monitor your systems and not to defend them—monitoring is not defense but is knowing what is going on. To integrate all the tools together, we first need to see them as agents giving little pieces of information to a central system that can correlate them to transform information to intelligence. After all, having a lot of information means nothing if you can't extract value from it. This is usually the point of failure in a network monitoring implementation.
To be sure to cover the most angles, we need those agents to be deployed in a way that provides good information and a low ratio of noise. That could mean removing highly false positive signatures that could affect your global view by inserting too much useless information. So each sensor should have different kinds of signatures or configurations to meet its specific needs. Table 19-1 lists a quick example that specifies the network position of the sensor and the general concept of the rules.
Table 19-1. Example network
Sensor position | Description |
|---|---|
HoneyNet (Public) | Should use unassigned IP addresses on the public network, and all access should be recorded and monitored, since traffic is likely malicious. |
HoneyNet (Private) | Should use unassigned IP addresses on the private network (server room), and all access should be recorded and monitored, since traffic is likely malicious. |
Honey sensor | In front of HoneyNet (Private or Public). Should monitor for all incoming communications. Can use generic exploit detection signatures to catch new exploits (NOP sled, format string, huge buffer) since the traffic should be low. |
Frontline sensor | In front of the firewall line, the frontline sensors should primarily look for port scans, brute force password attacks, systems identification, and firewalking. Here the goal is to find who is after you. |
Server sensor | In front of servers. Should monitor for attacks specific to the network, monitoring only for attacks that could be successful. This restriction comes from the high traffic load. |
VPN/Wi-Fi | Just after the VPN/Wi-Fi (after decryption). Monitor for weird access to internal network in case VPN/Wi-Fi was compromised. Also monitor for what VPN/Wi-Fi users should specifically not do. |
User sensor | Outgoing user network connections. Should monitor for either non-approved network usage (porn, chat, warez, P2P) or information leakage from inside the network. |
The last piece of such a setup would be to have a system to analyze and correlate as much as possible all those logs to be able to extract intelligence from them. This system should be able to handle a large volume of logs and provide a means to dig through them; for example, a syslog daemon with a search engine such as Splunks. Also since syslog is pretty simple to use, it is always possible to preprocess different logs to reduce the amount of information to search or to do some basic correlation.
Also, try to always isolate the monitoring system from the rest of the network. The more systems you have, the more risk there is to compromise one of them. Nothing is more satisfying to a hacker then using your monitoring/defense system to get in. Also, making sure that those sensors cannot transmit information on the network they monitor by cutting half the cable (transmit wire) is sometimes a good idea.
Last but not least, going from information to intelligence requires human power. Having all those systems in place but no qualified personnel to harness their power is not likely to offer an awesome ROI. Network monitoring is not a simple plug-and-pray solution, but when done correctly, it can provide you with very good intelligence on how to defend your network and your assets.
—Nicolas Beauchesne