Re: Botnets, IRC servers and firewalls?

["Marcus J. Ranum" <mjr () ranum com>]

> egress filtering is basically what is being discussed here, and has long
> been recommended, and long been rejected by the mass majority for quite
> sometime.

Time was that I'd explain the value of egress filtering to non-technical
managers and they'd immediately grab their security people and the
dialog went like this:
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!"

Whenever I was present for those discussions I'd ask the networking
guy to share the results of his tests that indicated it was a performance
problem. Then the networking guy would start sizing me up for a
Marcus-sized voodoo doll.

I think I've seen this drama play itself out maybe 100 times in the
last 16 years. The actors are always different and some of them
have put in oscar-winning performances, but the end result is always
the same: permissive outgoing traffic.

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

Darwin had more profound things to say about this, but the executive
summary is "they'll figure it out eventually."

> more complex rules to keep up with

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"

> the fear that a needed strategic app/protocol might be blocked
> inadvertantly

That's a problem of bad application design and poor network
planning. I mean, what kind of idiots would have a strategic
app that they didn't know about? Never mind. :)

> time/staffing issues make it just too much to impliment

Simple policies take seconds to implement. But after all
the other objections are confronted, this is usually the last
one that gets thrown up.

> lack of buy in from the powers that be

In the past I found that "the powers that be" are pretty easy
to explain the problem to, and, once they "get it" they are
shocked at the level of egress that is currently being allowed.
Usually, it takes a few weeks of the performance bullsh*t and
all the other flak of excuses being thrown up to erode the
"buy in"

You forgot the other big argument that gets thrown up
whenever egress filtering is discussed, "Nobody ELSE does it!"
followed by some mumbo jumbo about it not being a necessary
best practice blah blah blah Darwin blah blah...

> ingress filtering has proved to be useful in limiting the risks an
> organization has to endure and battle.  The job now, is to convince the
> powers that be and the folks that admin the defensive devises that egress
> filtering would have prevented or dramatically reduced the costs
> associated with a large number of the viri/trojans in circulation the past
> 2-4 years, as well as those still in the thought processes of those folks
> that release these beasts.

The virii, worms, and trojans will do it, since appealing to reason appears
to have failed.

>  It's amazing how one can get folks to
> understand the importance of packet flow in one direction needs to be
> evaluated and limited, and yet frustrating that translating that logic in
> the other direction can be fraught with either total rejection of the
> concept, or a poo-poo'ing of the risks, even after faced with the costs of
> cleanup.  Then come the champions of user education, a goood concept that
> has proved to be costly in and of itself, let alone, well, frustrating...

I did an IDS tutorial at Interop last year and about a week after
my class I got a call at home late one night from a panicked
admin who had been in my tutorial. One of the things I had suggested
was using egress filters with permit and log policies to get an idea
of what was going out through the firewall. He had discovered a
'bot net of at least 3,000 nodes in their 12 campus network with
20,000 desktops and servers. He didn't like my advice ("Change your
name and move to Afghanistan") and is probably still trying to clean
it up. Performance, rules complexity, administrative overhead,
blah blah Darwin, blah blah blah Darwin.

User education is a neat concept but I think it's just a feel-good
measure. We used to waste countless thousands of dollars trying
to "educate the end users" when in reality we could have spent
small amounts of dollars to simply control their actions. Why
educate 'em? Tell 'em how it works and by the way there IS no
alternative. It'll be interesting to see where this all ends up. With
the vast migration of white collar jobs from the US to the (former)
third world, the employment landscape might become one in
which "You want Internet? Are you kidding? You don't rate it. We
expect 8 hours/day of productivity out of you and web surfing is
not in your job description. If you don't like it, go to HR and
complain to Mr Darwin." Back at my last job we used to have a
policy that barred instant messenger programs and chat
programs across the perimeter. Turns out that was probably
a visionary policy for its day. Of course I had a constant
battle with some employees who kept finding ways to tunnel
the stuff over HTTP, etc. Educate users? They don't need an
education, they need a good beating(*)

mjr.
(* That was going to be the "December" calendar entry for the
2004 computer security calendar but at the last minute I decided
on "Patches" instead.) 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards