Re: Filter routers? (was Re:logs)

["Paul D. Robertson" <paul () compuwar net>]

On Thu, 30 Sep 2004, Kevin wrote:

> How common is it to deploy filter routers to pre-process traffic
> before it gets to the firewalls?  How elaborate do you get with these
> ACLs?

I've always considered it a necessity.  We encourage it for our Risk
Management Program customers.  Given the efficiency of screens these days,
it makes a lot of sense to me, but you have to be smart about the rules-
allowing the heaviest permitted traffic first.

> Simple "ingress" filtering at the DMZ is a best practice, and it's not
> uncommon to additionally do "egress filtering, usually in the same DMZ
> router.  Over the past few years I've become more of a fan of
> additionally deploying "Intranet" filter routers on the private
> network, to deal with default route traffic towards the Internet
> firewalls from inside.

Inside and outside screening routers have been part of a dual screened
bastion host architecture, once a pretty common example configuration.

> At the DMZ, I find little value in logging denied traffic.  It makes
> sense to me to simply deny the "noise", traffic which would otherwise
> increase the load on firewalls, (generating and writing deny log
> events) to no real end.

That's the thrust of my side of the logging conversation.

> Primarily this "noise" consists of packets with spoofed source
> addresses -- any packet claiming to come from an internal address,
> from RFC1918 address space, or from certain IANA-Reserved blocks;
> Anything matching these sources must be spoofed, cannot readily be
> traced back to the source.  Other than some interesting statistics,
> logging spoofed sources doesn't do much for me, for security.

Just a note that the reserved blocks may be leaks, not spoofed- even I've
broken the "don't put it on the outside" rule for RFC1918 interface rules
when spinning up a critical new router path.  Also, some load balancing
configurations may expose those and loopback- it's still mostly
uninteresting traffic, but it's not necessarily spoofed or backscatter from
spoofs.

> Additionally, I prefer to drop inbound traffic destined for subnets
> and protocols which I know we do not use (We need to advertise IP
> space that is not actively used due to limitations on BGP
> advertisements).  For example, permit IPSEC protocols towards the
> subnet where VPN devices are known to live, permit TCP/UDP/ICMP
> towards currently active subnets which are supposed to be visible to
> the Internet, then just drop everything else.

That's always been a part of my methodology.

> Normally I wouldn't include TCP ports in the filter router ACL (that's
> the firewall's job), but very recently I've caved on this stance,
> added entries to specifically drop TCP 135-139 and 445.  IMHO, nobody
> in their right mind would expose these ports to the Internet, and the
> deny logs on the firewalls were becoming a real hassle (as I mentioned
> in my message Re:logs, 75% of the inbound firewall events were denied
> TCP SYN packets from Microsoft worms on these ports).

I've always added TCP and UDP port based filters for allowed traffic, then
dropped everything else on either a screening router, or a secondary
packet screen on the outside of my proxy firewall, other than when i
wanted to "play" with someone scanning a large address space, where I'd
turn on RSTs for a particular kiddie's scanning address just to fill up
their logs.

> In a perfect world, I could request upstream ISPs apply these filters
> on their end of the pipe, conserving our valuable WAN bandwidth for
> more desirable traffic.

Indeed.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards