On Mon, 21 Feb 2000, Dave Harris wrote:

> Yes, my ISP does use filtering on their cisco routers but they won't tell me at
> what depth
> and fair enough.

Insist that they at least verify that directed broadcasts and
{strict,loose} source routing are *not* passed.  I'd want to insist on
ingress filtering to my network, but then I'd probably insist on owning
the router and doing the rules myself.  The last company I was at had
about 110 small to medium sized independent business units, and that was
my standard for every one of them.

> I take your point about defense in depth, however, I'm of the opinion that routers
> should route
> and firewalls should firewall. If your firewall can't stop evil packets getting
> into your network then
> get one that does. Isn't that the point?

In an ideal world it might be.  However, software is complex enough, and
TCP/IP has enough oddities that it just makes sense to have two
independent implementations doing the work.  That's why it's not only a
good idea, it's what's done at 100% of the well-secured sites on the
Internet.  

> Could you tell me your arguments for and against re router filtering or direct me
> to some
> literature on the subject?

For router filtering is pretty easy.  Routers are designed to deal with
packets, so doing filtering there is actually more efficient than doing it
on a host (but then I'm one of those "firewalls should _really_ be
application layer gateways" people.)  Also, after you've run a firewall
for a while, your threshold of what constitutes a problem gets higher.  I
generally only log router filtered packets when I have a specific event
going on.  That means that anything that does reach my firewall logs is
serious enough to merit my time and energy- it's evil enough to get past
the outside layer, it's evil enough to hunt them down.  This has the added
benifit of helping to stop log-filling attacks from getting through, or at
least to make the threshold high enough that log space isn't as critical a
resource as normal.

My typical access list for an outside screening router has probably about
80 rules (Filter out broadcast, multicast, RFC1918 addresses, anything
but net-facing machines...), and I've run it on Cisco 4700 series routers
for a few thousand interactive Web users and ~25,000-35,000 mail users
without seeing a major performance difference.  On Cisco gear (at least a
while ago- it may have changed for the better, but I've been unable to
confirm) outbound access lists are fast switched, inbound access lists
(are/were) process switched.  Avoid inbound unless necessary and it'll be
ok.

I'm sure this is covered in the scads of firewall literature out there-
unfortunately, I've not read a firewall book in more than 5 years.  It's a
common enough practice that when I say "outside screening router" to
anyone I've met who's worked with firewalls they immediately know what I
mean.  

Cisco has a nice document on their site that covers securing their routers
and access lists, I think it's something like "Cisco Internet Security"
and it pre-dates their PIX offering.  I'd be very, very surprised if it
wasn't covered in Building Internet Firewalls.  It's partially covered in
the Firewalls FAQ at: http://www.interhack.net/pubs/fwfaq/ under the
screened subnet portion.

There are exactly zero instances where I wouldn't place filtering on the
outside router.  I can log from there if I need to, the performance issues
aren't there as far as I can tell, and it's easy.  It gives me a
maintanance window for my firewall, means that someone internal hosing a
firewall rule doesn't give away the castle, and the router has to be there
anyway.  I can also have two seperate people managing each, giving me a
personnel safety valve if it's applicable to the environment.

The nominal disadvantages are that it's a second machine to manage the
configuration of, someone will have to grab some filter rules and vet
them, and troubleshooting of new and complex things that don't fit 
in the current ruleset requires router access.

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.]

Reply via email to