|Security expert, Mark Edmead|
These days almost every company has e-mail and connections to the Internet. They're essential business tools, but they can also open the door to malicious traffic. Perimeter security is key when it comes to protecting your corporate network from that traffic.
Let's first define a typical Internet connection infrastructure. On one end you have the very public Internet, and on the other end you have your very private corporate network. Machines in your corporate network require access to the Internet for sending e-mail, browsing, transferring files and so on. There could be multiple connection requests from the Internet to your corporate network, such as sending e-mails to your e-mail server or sending HTTP requests to your Web server.
Because you don't know who is trying to enter your corporate network from the Internet, you need to have some way of not only blocking unwanted traffic but also a way to monitor -- and alert you if needed -- of any unwanted or malicious traffic that manages to bypass your initial line of defenses. This is where intrusion-detection systems (IDS) come in.
As a minimum form of perimeter protection, most companies install a firewall. One of the jobs of a firewall is to block unwanted traffic from entering your corporate network. For many corporate (or small/home office) network configurations, having just a firewall is sufficient. But what happens if a packet manages to get through? How will you know there's a problem?
Say, for instance, your firewall is configured to block everything except port 80 for HTTP sessions. You might think this is a secure configuration. The problem is, however, that although the firewall will block everything except port 80, it blocks only at the port level. It does not have the ability to block on the message payload. What do I mean by that? Many hacks against Web servers (especially Microsoft IIS) involve the use of special string commands in the HTTP command sent to the server. So it is easy for an attacker to send a malicious command in the http connection string (i.e. http://insert the malicious code here). As far as the firewall is concerned, the connection request is valid (since it does allow HTTP connections), but the string being sent is the real problem. The IDS traps the string BEFORE it hits the internal network.
IDS analysis can be done in two ways. One is called signature-based IDS. It is similar to virus signatures. Attacks are detected by watching for certain actions being performed (looking for known patterns). Another method is called statistical analysis, where it uses deviations from normal system-usage patterns that require baseline information.
Robert Graham published a very detailed IDS FAQ where he answers the question, "How do firewalls
fit in with the rest of my perimeter security framework?" The answers are:
- Put firewalls between areas of the network with different security requirements (i.e. between Internet-local network, between users-servers, between company-partners, etc.).
- Use network-vulnerability scanners to double-check firewalls and to find holes that intruders can exploit.
- Use host policy scanners to make sure they conform to accepted practices (i.e. latest patches).
- Use network intrusion-detection systems and other packet-sniffing utilities to see what is actually going on.
- Use host-based intrusion-detection systems and virus scanners to flag successful intrusions.
- Create an easy-to-follow policy that clearly states the response to intrusions.
The important concept to remember is that you should not rely on just one device to offer complete protection. You should implement what is called defense in depth. That means having many layers of protection. Just because you have a gate around your house, it does not mean you don't need to have a lock on the front door. If an attacker is determined, he will continue to try to get into your system. But that does not mean you need to make it easy for him!
Great article on IDS by Lance Spitzner.
About the author
Mark Edmead, CISSP, SSCP, TICSA, is president of MTE Software, Inc., and has more than 25 years of experience in software development, product development and network systems security. He is co-author of the book Windows NT: Performance, Monitoring and Tuning published by McMillan Press and editor of the SANS Business Continuity/Disaster Recovery Plan Step-by-Step Guide.
This was first published in February 2002