On Fri, 16 Jun 2000, Joe Dauncey wrote:
> The main problem we have seen from our concerns is that the logging on the router is
>awful. You need to allocate sufficient buffer space, and
> you could easily lose it. However, if you have a local UNIX box you can
> bung all your logging straight to it using syslog. It's not too bad when
> you do that. You can log all denies on the access list, and you can also
> log all CBAC connections. However, I am not sure what you would need to
> do to log other traffic. I guess set an access list up as a 'permit all
> log', or to some lesser degree.
Ideally, screening routers drop packets you're not interested in at all.
I've always been dubious about the value of logging at a packet screen for
"normal" operations. It's worth noting that syslog isn't reliable and can
be flooded and drop stuff. I know that some people think that there's
merit to "advanced warning", but the sites I've dealt with in the past had
such a high threshold of bad stuff that it never seemed worth the hassle
of doing it well (which includes writing a lot of heuristic log scanning
software.)
> There are also some anti-DoS measures, which are quite good. They've got
> some fairly flexible rules to govern inbound SYN connections and the
> like.
I know these are in the ISP feature set, they may also be in the normal IP
images these days. If you're just looking for that, you may want to see
if you can get hold of the ISP image. (Actually, more to the point see if
you can license the ISP image, AFAIR they're all available on CCO for
download.)
> To sum it up I have two main issues. As a router with a firewall feature I
> think it is really good. As a firewall on a router I am not so
> impressed. Too much is hardcoded with no chance to see what is really
It depends on what you consider a "firewall," and what the organization
needs to protect. Web-based organizations may find some of the features
more attractive than traditional IOS filtering. Personally, I think
IPFilter has demonstrated that it's a better filter than a router, but
I've no qualms with still using a router as the firest line of defense,
but in my designs that's generally is a "drop and don't log" defense, with
a second "better" filtering solution behind it with logging for anyone
tenacious enough to throw bad stuff beyond the outer screen or to
compromise external somewhat protected hosts.
> going on. My second issue is more to do with the people who support it.
> A few times now I have seen router people trying to do firewall security
> with a Cisco router, but without really a clue. As the firewall world
In my experience, I've more of a problem with Novell or NT
admins-without-clue trying to do firewalling than with router admins who
at least tend to understand what it is they're blocking. I've also found
router admins easier to impart clue on because their default workset is
normally "keep things running smoothly" not "try to gain bonus points
doing special stuff for VPs." Obviously others' experiences will be
different.
> and the router world have always been slightly different there are a lot
> of vital security skills that have not yet permeated across to the
> router world (the case is also vice versa, but not an issue here). The
> router people tend to think that if they can do routers then they can do
> firewalls, and so if they know IOS then they can configure a secure IOS
Funny, my experience is that most router admins will not assume they know
something irregardless of the interface where most server admins will
assume that since they understand the GUI they know what they're doing.
I've also found router admins less inclined to trust the box- especially
if they lived through Source Route Bridging, Appletalk routing and the
early IPX days.
Irregardless, I'd recommend FFS for "harder filtering routers than normal"
and not "instead of a more comprehensive firewall."
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
