Re: [fw-wiz] Botnets, IRC servers and firewalls?

From: Paul Robertson (
Date: 02/04/04

  • Next message: Don Parker: "[fw-wiz] Efficiently detecting obfuscated shell code"
    To: "Marcus J. Ranum" <>
    Date: Wed, 4 Feb 2004 11:14:37 -0500 (EST)

    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

    /me ducks

    Paul D. Robertson "My statements in this message are personal opinions which may have no basis whatsoever in fact." Director of Risk Assessment TruSecure Corporation
    firewall-wizards mailing list

  • Next message: Don Parker: "[fw-wiz] Efficiently detecting obfuscated shell code"