On Wed, 4 Feb 2004, Marcus J. Ranum wrote:
> CIO:
> "So, why aren't we applying any controls to outgoing traffic?"
> Security guy:
> "Because we can't make the networking guys do it. They say
> it can't be done!"
> CIO:
> "Get the networking guys in here!"
> Networking guy:
> "You rang?"
> CIO:
> "Let's put some access controls in outgoing traffic, OK?"
> Networking guy:
> "Can't do it. It'd KILL PERFORMANCE!"
Funnily enough- I've seen the exact same dialog probably more than 100
times for _ingress_ filtering. At one point, I had a whole "Cisco
switching modes and extended access lists" dance I'd go through to
convince someone that the border router they already owned could do just
fine blocking a lot of stuff that didn't need to show up inside the DMZ.
I think we're over that hurdle for the most part now, so it's time to
tackle egress filtering again. :)
> > On routers the complaint is that it takes up too many resources
> >and slows the box down to a crawl.
>
> Which, of course means "you bought the wrong box" not "take out
> the filters" but nobody wants to hear that particular song. And, mythical
> router/switch slowdowns are the primary historical reason why almost
> nobody has any internal segmentation or security partitioning. And why
> so many organizations become crusty toast as soon as a worm gets
> through their crunchy shell and into their soft chewy interior.
It's not just "You bought the wrong box," it's "You don't know jack about
the box you bought!" I remember doing an incident response gig at a large
customer site and going through the "You can block >85% of your risk on
your router, we can make the change in place and not drop a packet, and it
won't impact performance- just give me a chance" thing-
Spent time with the router guy, popped up a set of filter rules we
_thought_ would work, starting with the big permits, then ending with a
permit any any log - to profile the traffic- ran that set for half an
hour, caught one machine he'd missed, dropped a new permit, then took out
the permit any any log. Router CPU was about the same (>90% of traffic
matched the first rule,) and they were way better off than when they'd
started. Zero downtime, minimal risk, and it was the right thing to do.
Time to talk them into it- 1.5 hours, time to implement, 2 minutes to
build the ruleset, 20 minutes to profile the traffic, 2 seconds to
implement and 2 minutes to switch rulesets. Granted, they already had a
log server and were logging from the router.
> A user interface problem. Simple policies are simple to encode
> in rules. Byzantine policies are difficult. Simple policies are also
> easier to audit and faster to execute. They're also derided as
> "draconian". Eventually we will call them "darwinian"
I've talked to people who changed router filtering rules 8x a day (!)
I've always been of the opinion that if you've got a complex or
often-changed config, you messed up bigtime.
> The virii, worms, and trojans will do it, since appealing to reason appears
> to have failed.
It's VIRUSES Mr. Skript Kiddie :-P
http://www.perl.com/language/misc/virus.html
/me ducks
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts_at_patriot.net which may have no basis whatsoever in fact."
probertson_at_trusecure.com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Received on Feb 04 2004
Intro
