RE: [fw-wiz] Inspecting routers
From: Ben Nagy (ben@iagu.net)
Date: 11/26/02
- Next message: Symon Thurlow: "RE: [fw-wiz] Outlook Web Access - Paranoid?"
- Previous message: Mark L. Evans: "[fw-wiz] Outlook Web Access - Paranoid?"
- In reply to: Pierre-Yves: "[fw-wiz] Inspecting routers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Ben Nagy" <ben@iagu.net> To: "'Pierre-Yves'" <tchoubou_fr@yahoo.fr>, <firewall-wizards@honor.icsalabs.com> Date: Tue Nov 26 16:14:17 2002
> -----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
- Next message: Symon Thurlow: "RE: [fw-wiz] Outlook Web Access - Paranoid?"
- Previous message: Mark L. Evans: "[fw-wiz] Outlook Web Access - Paranoid?"
- In reply to: Pierre-Yves: "[fw-wiz] Inspecting routers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
