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

From: Paul Robertson (proberts_at_patriot.net)
Date: 02/04/04

  • Next message: Don Parker: "[fw-wiz] Efficiently detecting obfuscated shell code"
    To: "Marcus J. Ranum" <mjr@ranum.com>
    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

    http://www.perl.com/language/misc/virus.html

    /me ducks

    Paul
    -----------------------------------------------------------------------------
    Paul D. Robertson "My statements in this message are personal opinions
    proberts@patriot.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


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

    Relevant Pages

    • Re: Cisco 837 Adsl to public IP
      ... ip of the main remote router. ... ip nat inside source route-map nonat interface Dialer1 overload ... access-list 101 permit ip 10.10.10.0 0.0.0.255 any ... ip inspect name ethernetin cuseeme timeout 3600 ...
      (comp.dcom.sys.cisco)
    • Re: Liteweight needs confirmation: SBS config of Mulitple NIC
      ... match access-group 112 ... access-list 9 permit yada..yada...yada ... Tried to ping the Cisco router from the Firebox, ... Pinged SBS server and it worked. ...
      (microsoft.public.windows.server.sbs)
    • Re: VPN problems from Linksys WAG54G to Netscreen 208 using netscreen client
      ... > IPsec filtering is on and the router asks for my username and password. ... set ffilter src-ip 2.2.2.2** ... the 445 or the SQL traffic because your WAG think's it's not good Internet ...
      (comp.security.firewalls)
    • Re: Airport dropping connection
      ... filtering, and the MAC address of the computer from which you connect ... is not allowed, the computer will *appear* to be connected, but the router ... Have you examined the Airport passwordstored in your MacBook ...
      (comp.sys.mac.portables)
    • Re: Advanced Settings
      ... So it SHOULD be set to "Permit All" for the 3 boxes--correct? ... my REAL problem is that I am not able to login to my router. ... I can ping the default gateway and ping external sites--I can browse ... > solve it instead of blindly trying to fix it yourself. ...
      (microsoft.public.windowsxp.network_web)