Firewall Wizards mailing list archives
RE: Inspecting routers
From: "Ben Nagy" <ben () iagu net>
Date: Tue, 26 Nov 2002 20:56:47 +0100
-----Original Message----- From: firewall-wizards-admin () honor icsalabs com [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf Of Pierre-Yves Sent: Monday, November 25, 2002 9:45 AM To: firewall-wizards () honor icsalabs com Subject: [fw-wiz] Inspecting routers Hi, One of my customers is migrating part of it's Internet architecture. We are aiming at a several-layered target, something like : Internet | External access router | Web services zone | Internal access router | Internal network There are _no_ outgoing connexions from the internal network to the Internet through those links (those connexions go to another ISP and route). The only trafic crossing the internal access router will be administration traffic (internal to web systems) and data requests (web systems to internal databases).
Maybe think about a "real" firewall for your web services zone to internal traffic. That's probably the only place you'll benefit much from smart inspection of any kind.
The "web services zone" hosts several load balanced web systems, with reverse proxies and the like. No DNS/SMTP servers in this zone. Currently "pure web zone", and it should stay so. Throughput to the internet customers is a major constraint. Both routers have quite extensive IP filters (well, the external one basically has "deny if not TCP/80 or TCP/443 targeted to the web servers").
You really should skip extensive filters if you can help it. Small ACLs are good ACLs. Do _not_ implement one of the "from the net" ACLs that spends 20 lines filtering bogon networks. I don't know if you're using Cisco gear, so this next bit may be of no use to you... If you want super-fast filtering based on pure stateless TCP/IP then you can do better than access lists in many cases - the fastest tend to be the traffic policing / NBAR type solutions, followed by the routing to null0, followed by ACLs, in some cases. This is possibly only relevant if you have a giant pipe to the net, though. I have seen a 7200 being 'mildly vexed' at the height of code red (it was using some static ACLs to unsuccessfully block stuff), but when we shifted to NBAR with flow switching everything was good. (Actually that's a complete lie - the router collapsed in a screaming heap and we were there until midnight trying to stop the crash-on-post cycle, manically drinking scotch and convincing the TAC to get us a bleeding edge IOS image now, as in now, as in this very second, but _after_ that everything was good. (I know you're all thinking that it's wrong to enable major new features on production routers, yes, yes, their net connection was fragged anyway).) Anyway, I digress. The point is that you should probably check out some of the Cisco docco to find out if there is a faster way to do what you need, if speed really is a concern. My info is a little out of date at the moment. Also check things like unreachables (don't send them if you want super-fast performance) and other basic stuff that any CCNP+ can tell you.
The customer is currently thinking about inspecting routers, to go "one step further than plain filtering". First question, does this low-level inspection really buy anything wrt security ?
Externally - probably not. The only argument for it is that you could catch some weird malformed stuff which might otherwise cause stupid web servers to pull down their pants. Given that I'm sure you're using a good webserver which has been carefully and lovingly configured by a security expert in line with best practice documents then for this simple case "inspection" or other intelligent filtering won't buy you much.
Secondly, I advise him to put his inspection stuff on the internal access router, where 1/ the throughput is far lower than on the external router 2/ we know exactly what should cross here 3/ if anything unusual comes this way, all hell should and will break loose. Would this be the best place to inspect packets ?
A router level "inspection" is probably going to be next to useless. If you want "better" security here you'd be better off (IMO) looking at either a firewall that can do something intelligent with the data stream, or more properly, an IDS system that will tell you when unexpected traffic is knocking at your parlour door.
What would we gain (or loose) by putting inspection on the external router ?
Gain - extra security blanket and defence in depth for your webservers, protecting against a subset of the packets which are legit (headed for the right port), but malformed and malicious. Lose - Speed. Simplicity. Elegance. l33t cred.
Tia, -- Pierre-Yves
In short, my take on 'inspection' on routers is that it's just a tiny bit of TCP/IP rightness checking, fragment reassembly etc. It's nice, but it's expensive. The security delta when you're protecting hardened systems is small and the speed cost is often big. In what sounds like a professional style setup you should worry most about hardening your web boxes and making sure you know, quickly, if one of them gets hacked. Them being part of the Next Big Worm never makes customers happy. Cheers, -- Ben Nagy Network Security Specialist Mb: +41792504687 PGP Key ID: 0x1A86E304 _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Inspecting routers Pierre-Yves (Nov 25)
- Re: Inspecting routers Lorens Kockum (Nov 25)
- Re: Inspecting routers Mikael Olsson (Nov 25)
- Re: Inspecting routers Kyle R. Hofmann (Nov 25)
- Re: Inspecting routers Lorens Kockum (Nov 26)
- Re: Inspecting routers Ng Pheng Siong (Nov 26)
- RE: Inspecting routers Ben Nagy (Nov 26)
- Re: Inspecting routers Lorens Kockum (Nov 25)