Published: 01 Mar 2005
BITS & BOLTS
Conventional routers are the perfect network security auditing device. Take advantage of what they see.
|Scripts: Simple Log Parsing|
Routers see everything that crosses your network. They direct the flow from LAN to LAN, and--with their access control lists (ACLs)--can regulate access to network segments. But, you're not getting the most out of your routers unless you're using them to help audit your security devices.
Router logs are a treasure trove of security intelligence that, with proper analysis, can help you be proactive and correct firewall configuration errors, tune IDSes and measure your network's security posture. The concept is simple: Compare what arrives at your enterprise's front door with what actually gets through.
Routers can locally store logs, but they have storage limits. The first step is to create a syslog server to collect external and internal router logs; the server can also consolidate logs from multiple routers for efficient reviews. From there, you can audit just about any device that generates logs, but we'll focus on firewalls and IDSes. First, though, let's see how you can use scripts to cut the job down to size.
Follow the Script
Dumping router logs into a readable text file is easy. Pulling logs from every border and internal router, then parsing them for meaningful, actionable intelligence isn't as simple.
Scripts can automate the retrieval of router logs and parse them on a regular schedule. These scripts should reflect your security policies--basically what kinds of traffic shouldn't be allowed. Key types of external traffic to look for are RPC and SNMP queries and NetBIOS scans, none of which should legitimately be coming into your network. In the case of NetBIOS, closing TCP/UDP ports 135-139 and 445 can head off a potential attack foreshadowed by a light probing.
The testing scripts can be written in any language and created at the same time as rule sets. However, scripts written in PERL using the simple grep command are quickly modifiable and easy to use. Grep is a powerful complement to a scripting language because it lets you quickly isolate important traffic. It would be almost impossible, for example, to see a DNS attack through 20,000 log entries; however, by parsing the data to show only the 30 lines associated with the DNS, the attack becomes much easier to spot. (See "Simple Log Parsing".)
A firewall is only as good as its rule set. Creating and maintaining effective rule sets is difficult, and even the best degrade over time. The first indication of a problem is usually a compromise, such as a worm burrowing through the network.
You can use the internal and external router logs to flag and correct many rule set problems before they become problems. The external router logs will show all Internet traffic attempting to enter your network, and the internal logs will show what traffic actually got through. If the firewall is correctly configured, the internal router logs will show only the traffic that your external firewall rule sets are designed to let through. Conversely, the presence of restricted protocols will reveal rule-set errors.
Since firewalls are generally configured to log traffic that's blocked or violates policy, a misconfigured firewall may pass along dangerous traffic without recording it--but your routers will.
By aggressively monitoring the logs, you can detect and correct errors and misconfigurations before they are exploited.
Proving IDSes Work
IDS false positives act as the proverbial boy who cried wolf, draining IT security resources to hunt phantoms and, eventually, undermining security managers' confidence in their IDS's ability to issue accurate, actionable alerts.
By monitoring router logs, you can fine-tune your IDS configurations to reduce false positives and refine IDS intelligence by verifying attacks and identifying their sources.
An IDS is essentially a sniffer with signatures for identifying suspicious and/or prohibited activities. Thus, at some level, IDS and router logs will show similar information. The big difference is that a router can distinguish traffic's ingress and egress points, while the IDS simply sees the traffic. This becomes increasingly important when dealing with multiple network routers, since the router logs can provide information for making more informed response decisions.
For example, in the case of a worm outbreak, an IDS only sees that there's malicious traffic traversing the network. Since the IDS may only log the one or two entries that triggered the signature--performance trumps logging--you wouldn't see all of the traffic. But, the router log would show that the source of the worm is the extranet connection to your partner organization, not your Internet-facing firewall.
What's tricky is getting this information and making it meaningful. Scripts can pull the logs at regular intervals, allowing you to compare their entries to what's seen by the IDS. Some IDSes allow you to write scripts that pull router logs for near-real-time verification of suspicious activity and alerts.
While routers can be used to audit firewalls and IDSes, the same principles can be applied network-wide to any device that generates logs.
Since many organizations run VPN concentrators parallel to firewalls, router logs can reveal attempted attacks against the VPN device; since VPN logs typically record only successful transactions, they won't yield the same information.
Routers can also complement honeypots. A honeypot is designed as a hacker target and usually has limited or no security protection. Router logs can be used to audit honeypots, just as they are used on "live" security devices, giving security managers an added level of intelligence on attack methods and sources.
Routers can be more than just traffic cops: They're investigators, auditors and enforcers. While they're not robust as a security solution, they can augment and enhance the security provided by core network security devices.