Government scrutiny is headed our way

Mailman List Mirror (Read Only)
1

Government scrutiny is headed our way
http://www.fcw.com/pubs/fcw/1998/0615/fcw-frontcyber-6-15-1998.html

The feds are worried that it is too hard to track down cyber attackers.
Although the article doesn't say this explicitly I expect that it won't be
long before we see politicians calling for some sort of mandated tracing
capabilities between network providers

And since IOPS http://www.iops.org/ is hosted by a government funded
agency located on the outskirts of DC, I expect that it will be involved
in this whole thing.

If we could track attacks to their source more quickly, then government
would not feel the need to intervene. This may require some changes to
router software but unless network operators ask for the changes, the
manufacturers will not do it.

We need some sort of protocol that will recursively track spoofed source
address packets back to their source one hop at a time. Given a
destination address the protocol would track it to the previous hop router
and recurively initiate the same tracking procedure on that router. Once
the attack is tracked to the source, the probe would unroll and report the
results to all routers along the probe path for logging or reporting.

We have seen that when misconfigured equipment can be quickly identified,
such as the smurf amplifiers, then we can apply pressure and get things
fixed. Similarly if we can quickly identify the source of a spoofed source
address attack then we can apply pressure to get filters in place and have
people arrested or secure an insecure machine as the case may be.

2

It is about goddamn time, and I hope the government DOES get involved.

Try calling ANY of the major NOCs to get a smurf traced. Good luck. I
have yet to have even attacks going on for more than an hour successfully
traced back to their source.

3

It is about goddamn time, and I hope the government DOES get involved.

Obviously you're out of meds, Karl. :slight_smile:

Try calling ANY of the major NOCs to get a smurf traced. Good luck. I
have yet to have even attacks going on for more than an hour successfully
traced back to their source.

Didn't say there wasn't a problem. Just don't let's go _there_, ok?
-- j

4

No, we need to go there.

"Voluntary" cooperation isn't working, because the major NOCs don't
cooperate. Like ever. I've given up reporting these and just block the
amplifiers, because it is POINTLESS to spend 30 minutes on hold to get a
NOC person on the phone who either refuses assistance or refuses to
escalate the matter to someone who knows what to do.

Since they don't cooperate, the only two defenses are:

1. Black-hole detected amplifier networks (what we're doing here).

2. Government intervention to slap penalties on those who don't
cooperate with such reports, and vendors who don't make it
possible for NOCs to cooperate *reasonably*.

I'd really like it if this didn't have to happen. Seriously. But as long
as network operators decide to play stupid when they are hit with these
requests, and/or just tell you to bite it (and I've heard both) then the
two above steps are both reasonable and necessary.

5

> Didn't say there wasn't a problem. Just don't let's go _there_, ok?

No, we need to go there.

"Voluntary" cooperation isn't working, because the major NOCs don't
cooperate. Like ever. I've given up reporting these and just block the
amplifiers, because it is POINTLESS to spend 30 minutes on hold to get a
NOC person on the phone who either refuses assistance or refuses to
escalate the matter to someone who knows what to do.

Since they don't cooperate, the only two defenses are:

1. Black-hole detected amplifier networks (what we're doing here).

Indeed. And what I think is the best approach. Kick 'em in the
nads^Wnets.

2. Government intervention to slap penalties on those who don't
cooperate with such reports, and vendors who don't make it
possible for NOCs to cooperate *reasonably*.

Governments have a demonstrated habit of not building such constraints
so as to incent (I hate that word, but can't think of an acceptable
synonym just now) the _right_ changes in behavior patterns -- this is
the same discussion as was just had about Usenet cancel messages a
couple hours ago.

I'd really like it if this didn't have to happen. Seriously. But as long
as network operators decide to play stupid when they are hit with these
requests, and/or just tell you to bite it (and I've heard both) then the
two above steps are both reasonable and necessary.

I think that the approach here is to find the executive level people to
whom those people report, and explain to _them_ that if they don't get
their houses in order, the government is likely to do it for them.

Cheers,
-- jra

6

> > Didn't say there wasn't a problem. Just don't let's go _there_, ok?
>
> No, we need to go there.
>
> "Voluntary" cooperation isn't working, because the major NOCs don't
> cooperate. Like ever. I've given up reporting these and just block the
> amplifiers, because it is POINTLESS to spend 30 minutes on hold to get a
> NOC person on the phone who either refuses assistance or refuses to
> escalate the matter to someone who knows what to do.
>
> Since they don't cooperate, the only two defenses are:
>
> 1. Black-hole detected amplifier networks (what we're doing here).

Indeed. And what I think is the best approach. Kick 'em in the
nads^Wnets.

Not really. The best approach is to nail a few of these folks with felony
indictments for the denial of service attacks, and the theft of the
amplifier network's services. That would stop this practice cold.

> 2. Government intervention to slap penalties on those who don't
> cooperate with such reports, and vendors who don't make it
> possible for NOCs to cooperate *reasonably*.

Governments have a demonstrated habit of not building such constraints
so as to incent (I hate that word, but can't think of an acceptable
synonym just now) the _right_ changes in behavior patterns -- this is
the same discussion as was just had about Usenet cancel messages a
couple hours ago.

> I'd really like it if this didn't have to happen. Seriously. But as long
> as network operators decide to play stupid when they are hit with these
> requests, and/or just tell you to bite it (and I've heard both) then the
> two above steps are both reasonable and necessary.

I think that the approach here is to find the executive level people to
whom those people report, and explain to _them_ that if they don't get
their houses in order, the government is likely to do it for them.

That's not my (or your) job. If they're not on notice by now, they deserve
what they get. Frankly, I hope that the government does their job for them
due to the simple fact that I'm getting tired of taking defensive postures
on this thing.

Its time for network operators to get aggressive. We already filter on our
dial connections (including ISDN) to prevent out-of-range addresses from
being spoofed. THIS IS SIMPLE TO DO ON ALL MODERN HARDWARE. Yet we're one
of the VERY few ISPs who bother with this.

We're looking into implementing filtering on ALL ingress paths, including
dedicated line, as soon as we can come up with a tool to manage it
automatically. The dial side is trivial and as such I can't understand
how ANYONE can have an excuse for not doing that - at this point.

7

On Tue, Jun 16, 1998 at 03:21:11PM -0400, Jay R. Ashworth put this into my mailbox:

I think that the approach here is to find the executive level people to
whom those people report, and explain to _them_ that if they don't get
their houses in order, the government is likely to do it for them.

Sounds good. Now we just need someone to send around a press release
stating that 1 out of 3 (asshole statistic) corporations, government
organizations, and educational institutions are unwittingly helping
Cyber-Terrorists commit their evil deeds; and 25% of those (another
asshole statistic) don't care that they're aiding and abetting
these criminals.

Basically, we want to shame these companies into fixing their networks.
Public image is a killer.

Sensationalism can be your friend, if used right }:>

-dalvenjah

8

Government scrutiny is headed our way
http://www.fcw.com/pubs/fcw/1998/0615/fcw-frontcyber-6-15-1998.html

The feds are worried that it is too hard to track down cyber attackers.
Although the article doesn't say this explicitly I expect that it won't be
long before we see politicians calling for some sort of mandated tracing
capabilities between network providers

Since it's already difficult to track down attacks, I feel that any
intervention on THIS MATTER would be welcomed by many people. What we
must be cautious about is giving the goverment too much power in this
matter. I fear big goverment, this often means more taxes, and
inefficiency.

And since IOPS http://www.iops.org/ is hosted by a government funded
agency located on the outskirts of DC, I expect that it will be involved
in this whole thing.

If we could track attacks to their source more quickly, then government
would not feel the need to intervene. This may require some changes to
router software but unless network operators ask for the changes, the
manufacturers will not do it.

I agree with you fully. I feel that few networks practice good security.
Network Engineers and Operators need to be more proactive when it comes to
security. In my last gig, I had a small network but we had a secure
network and we prosecuted to the fullest extent of the LAW. That's what
need to happen. If we can avoid government interventions to make this
happen then let's do it.

We need some sort of protocol that will recursively track spoofed source
address packets back to their source one hop at a time. Given a
destination address the protocol would track it to the previous hop router
and recurively initiate the same tracking procedure on that router. Once
the attack is tracked to the source, the probe would unroll and report the
results to all routers along the probe path for logging or reporting.

I have few questions about this. Do we run it on the router? If yes what
type CPU and Memory load can we expect? We must realise that the router
are usually doing full BGP with upstreams and processing many different
things on locally. Anything we do cannot take way from the proformance of
a router.

We have seen that when misconfigured equipment can be quickly identified,
such as the smurf amplifiers, then we can apply pressure and get things
fixed. Similarly if we can quickly identify the source of a spoofed source
address attack then we can apply pressure to get filters in place and have
people arrested or secure an insecure machine as the case may be.

--
Michael Dillon - Internet & ISP Consulting
Memra Communications Inc. - E-mail: michael@memra.com
http://www.memra.com - *check out the new name & new website*

Cheers
Moe H.

9

> We need some sort of protocol that will recursively track spoofed source
> address packets back to their source one hop at a time. Given a
> destination address the protocol would track it to the previous hop router
> and recurively initiate the same tracking procedure on that router. Once
> the attack is tracked to the source, the probe would unroll and report the
> results to all routers along the probe path for logging or reporting.
>
I have few questions about this. Do we run it on the router?

At least part of this needs to be run on the router but part of it could
be run on a workstation.

If yes what type CPU and Memory load can we expect?

Limited load. This tracing needs to be limited similar to the way that
UNIX shells limit resource consumption with the ulimit command. And there
needs to be some sort of rudimentary trust relationship set up, perhaps to
only allow traces to be initiated by a router that has a BGP peering
session in place.

We must realise that the router
are usually doing full BGP with upstreams and processing many different
things on locally. Anything we do cannot take way from the proformance of
a router.

I agree. If a peer initiates too many traces in a given timeframe then
extra ones should be silently ignored. A trace should start with human
intervention, i.e. a NOC employee runs some trace utility on a workstation
that initiates a trace probe on their own routers and the probe propogates
through the network until it succeeds or fades due to too many probes at
one spot at the same time. In most cases a single victim will contact a
single upstream and ask for a single probe. The only time probe activity
would hit its limits would be if a single attacker was simultaneously
attacking a large number of sites. If even one of the probes succeeds in
flushing out the attack source then it will be useful even if many probes
must fail to limit the load on the routers.

10

For those who don't bother filtering "because it's too hard or too
complicated", if you don't want or can't afford to put the work into tight
ingress filtering on all interfaces, it's really easy to just say "our IP
blocks are A, B, and C. Allow input with source addresses in A, B, or C,
deny everything else." That will at least protect the rest of the
internet from your lusers.

On IOS, aren't packets going through ip access-group filters (that don't
do logging) fast switched as of some point in 11.2? If ingress filtering
no longer has to put a huge burdon on router CPUs, it would be nice to see
ingress filtering on the routers backbone providers talk to customers
with. Don't tell me it's too much of an administrative problem. None of
my current backbone providers will listen to BGP advertisements that
haven't been arranged in advance (either by email or phone). If I can't
advertise the space, why should I be allowed to spoof source addresses
from it?

11

> We're looking into implementing filtering on ALL ingress paths, including
> dedicated line, as soon as we can come up with a tool to manage it
> automatically. The dial side is trivial and as such I can't understand
> how ANYONE can have an excuse for not doing that - at this point.

For those who don't bother filtering "because it's too hard or too
complicated", if you don't want or can't afford to put the work into tight
ingress filtering on all interfaces, it's really easy to just say "our IP
blocks are A, B, and C. Allow input with source addresses in A, B, or C,
deny everything else." That will at least protect the rest of the
internet from your lusers.

Right. That's what we do on the dial plant today, because there isn't a
syntax available on our RAS hardware which says "allow anything with this
RADIUS assigned or dynamic address block (depending on the account) and deny
everything else". So we have to relax the filters to be "allow anything from
netblocks A, B, and C, block everything else" since the syntax we really
want isn't available.

We do that for all dial and ISDN inbound connections today, and have been
for a long time.

Still, that's good enough. You can't launch a DOS attack against ANOTHER
provider from our plant this way. We also have directed broadcasts shut
off network-wide, so attempts to bounce pingstorms off our internal plant
(even to internal targets) don't work either.

That's the 95th percentile solution, and is a hell of a lot more than most
other ISPs do. Most don't do ANY filtering of any kind. I've tested this
against accounts on other providers, and most will happily forward packets
with ANY source address from dial customers.

Add throw-away accounts to that and you've just created the existing monster
called "The Smurf". Wow, I wonder how that happened?

On IOS, aren't packets going through ip access-group filters (that don't
do logging) fast switched as of some point in 11.2? If ingress filtering
no longer has to put a huge burdon on router CPUs, it would be nice to see
ingress filtering on the routers backbone providers talk to customers
with. Don't tell me it's too much of an administrative problem. None of
my current backbone providers will listen to BGP advertisements that
haven't been arranged in advance (either by email or phone). If I can't
advertise the space, why should I be allowed to spoof source addresses
from it?

We've yet to have trouble traced to any of our dedicated line customers. If
we had, we'd have implemented the filtering a LONG time ago, administrative
pain in the ass or not!

We HAVE had the alarms go off for packets which were spoofed from dial
customers (and were blocked by the filters). That's a great way to get
your account whacked around here (get caught attempting to launch a DOS
attack at someone)

Our approach on the dial plant is simple - if its not from one of our
netblocks, it doesn't go out - period. Now you can still spoof, but
only an address that is local to us (and thus can be traced completely
on a local basis)

If your dial plant is all dynamic address (ours is mixed) then the filters
can be a lot tighter - if its not in the pool for that RAS device, it gets
bounced.

ALL RAS devices in common use today (ie: Lucent, ASCEND, CISCO, etc) have
this capability, and virtually all previous-generation ones (ie: Netblazers)
can do this as well. And if you're unlucky enough to have something that
can't, you can STILL do the same filtering at the boundary between the RAS
and the rest of your network (like the CISCO that feeds the plant that your
RAS boxes sit on).

There simply is no excuse for not doing ingres filtering for dial customers
in today's environment. The bitrates are low enough and the RAS boxes good
enough that claims that "I don't have the CPU for it" are plain bullshit,
even on last-generation hardware (ie: Netblazers).

I understand the CPU problems filtering ingress on a DS-3 to a customer,
for example, if the box has a bunch of other interfaces. But in that case
you should insist (contractually) that the *CUSTOMER* router have the
filters on ITS interface which talks to you, and TEST it from time to time.

12

It's my (probably forlorn) hope that the proposed Internet Board (or
whatever they'll call the registry board proposed in the White Paper) will
have some enforcement authority

          OR

An "Internet Governing Board" would be created that would have the
authority to say "You are not playing nice...no connectivity to the rest of
the 'Net for you until you get your stuff together".

I see a sort of informal court setup that one could complain to about
offensive networks AFTER attempts to deal with the network itself have
failed. The IGB would then have the authority to verify the problem and
the lack of resolution and order the offender be cut off at the NSP, or
blackholed at the NAPs, or whatever appropriate, until they solve their
problem.

Think what a nicer place the 'Net would be if there were an agency that
could FORCE those who refuse to cooperate in our grand cooperative venture
to play nice or not play at all.

What do spammers and nails have in common? They're both intended for
hammering.

Dean Robb
PC-Easy
On-site computer services
(757) 495-EASY [3279]

13

Paul Vixie.

:slight_smile:

Cheers,
-- jra

14

It's a good start! :slight_smile:

What do spammers and nails have in common? They're both intended for
hammering.

Dean Robb
PC-Easy
On-site computer services
(757) 495-EASY [3279]