This article can also be found in the Premium Editorial Download "Information Security magazine: Negative exposure: Web scanners reveal unknown holes."
Download it now to read this article plus other related content.
Everyone uses an Internetwork router to connect to the Internet. A router's first job is to route, transparently and seamlessly directing packets from one network to another.
But a router can do much more. First of all, if you know how to describe "bad" behavior, a router can look for it in Internetwork traffic. For example, if you can associate certain IP addresses with the network interfaces of a router, the router can tell you if an outside computer is pretending to be inside your network--a classic IP spoofing attack.
Routers can also be configured to address source-routed address requests in packets. These are packets that basically say, "You see where it has my IP address here in this field? Well, when you send packets back to me, don't check your routing table or anyone else's to send me the packet. Instead, send it to this other address here."
Another security feature of routers is the ability to filter. Filtering applies policy to packets, declaring what is permitted and denied by using rules that specify...
- Network interface: Which network did this packet come from?
- Source: What IP address did it come from?
- Destination: Where does it want to go?
- Packet type
- Protocol: What language to talk--for example, HTTP for Web traffic or SMTP for e-mail.
- Port to use: matches the packet with a particular service running on a computer--for example, e-mail is usually on port 25, Web runs over port 80.
Picture a simple Internet gateway to a private network. The connection to the Internet is a border router whose internal interface is connected to our service network--the DMZ. Connected to that same network are a Web server and an enterprise firewall, which in turn is connected to the private network.
First, the router should be configured to block stupid hacker tricks, such as IP spoofing. Though the firewall could certainly handle these attacks, why bother it with this "kid stuff?" Blocking such attacks at the router means the Web server doesn't have to worry about whether the packet address is spoofed.
Also, the security policy should list what network services are allowed between our networks and the Internet. The router can be used to allow required services and deny everything else.
Next, we can tune the router to the needs of the DMZ. What traffic should be going to the Web server in the DMZ? Answer: nothing but Web traffic. So, we configure the router to allow HTTP and SSL traffic to ports 80 and 443 from the Internet to the Web server, and nothing else.
How about packets originating at the Web server hitting the router on the way to the Internet? There shouldn't be any, right? Only responses to outside requests should be permitted. So, we tell the router to permit only HTTP and SSL from the router to the Internet, and only in response to outside requests.
The enterprise firewall is also on the DMZ. The router filters should be configured to deny anything that the enterprise firewall denies. So, even though our enterprise firewall can detect a port scan, we tell the router to look for this common practice, which can be a prelude to an attack. That way, if the firewall gets port-scanned, we know something is very, very wrong. Port-scanning the router may be commonplace--for many organizations, it's a daily occurrence. But if someone is able to port-scan the firewall, we know he has effectively circumvented the router's controls, which should sound a "this should never happen" alarm.
Yes, "belt and suspenders" is an old idea. But in an era when more servers and applications are being opened up to the Internet, we have to rely on complementary security controls to reduce our risk while maintaining usability.
1Firewalls and Internet Security: Repelling the Wily Hacker (Addison-Wesley, 1994).
About the author:
Fred Avolio is president and founder of Avolio Consulting, a Maryland-based computer and network security consulting firm.
This was first published in January 2003