identify hostname

Rusty Zickefoose wrote:

I've got to go with Pete K. on this one. In our current, cidr-ized world, it
is simply not possible for an upstream provider to determine what is, or is
not, a broadcast address in a downstream network. This is something that needs
to be implemented from the edge in, not from the core out.

I'll second the agreement.

I know my own subnetting strategy, and I also know what blocks I assign
to my customers. Although few of my customers are sophisticated enough
to subnet them on their own, even if we go do it for them (which is one
of the services we offer) this is not something that we record in the
database that will be used to build all our configurations.

I do have an access list deny for incoming destinations to *.*.*.255
since I do know that the only customer we have with larger than a /24
from us (via cw.net) also happens to have nothing larger than /26 in
their network. AFAIK, today, smurfers are only using *.*.*.255. They
would have to track a lot more information to use others, so for now
I can generally expect that deny to prevent us from being an amplifier.

As more and more *.*.*.255's get blocked, smurfer kiddies may look for
other broadcast addresses as well. It may come down to literally having
to build an access list from my assignment database. Of course those
smaller subnets will typically have fewer hosts to amplify from, but
when servers are carefully concentrated in a subnet, there can still
be a lot.

I cannot expect C&W to block *.*.*.255 incoming for me. Even though in
my case it would cause no problems, in the case of others, it can, and
they have no reason (or database) to know which is which. But when the
smurfers start using 127, 63, etc., that won't do any good, and I don't
want them blocking those all the way down to /30's (let's just cut the
IPv4 address space in half).

I do block outgoing sources with addresses other than our network blocks.
Thus we can't be the source of an amplified attack other than an attack
on our own network, or only amplified here, which limits it to our pipe
size, and makes tracking it (to here) very easy. Such blocking helps on
forgeries, too.

I would expect the backbones to do broadcast address blocking in their
own subnet space where a lot of broadcast replyable servers exist (surely
their Cisco routers aren't replying to broadcasts since that is easy to
turn off). But these can be thought of as an "edge", anyway, and they
do know the subnet mask there.

I do have an access list deny for incoming destinations to *.*.*.255
since I do know that the only customer we have with larger than a /24
from us (via cw.net) also happens to have nothing larger than /26 in
their network. AFAIK, today, smurfers are only using *.*.*.255. They
would have to track a lot more information to use others, so for now I
can generally expect that deny to prevent us from being an amplifier.

It's not difficult to find subnet broadcast addresses, since few routers
(if they even support it) are configured to filter ICMP replies. If there
isn't already software out there, it will take all of a few hours to add
broadcast-finding code to the smurfing software in existence.

I find the parallel between Internet attacks and terrorist activities very
interesting. Though they are obviously not related as far as humanitarian
issues go, they both require so much effort to track and prevent one
wonders if it's even possible. When you consider that a single 28.8k (or
even 2.4k, I guess) dial-up connection can cripple whole organizations,
and the only defense is to get every router to filter or at least block
directed broadcasts, it's very frustrating.

Similar to the scenario that a single person with a few small devices or
an aerosol can can maim or kill tens or hundreds of people. The most
frustrating difference is that I suspect that most terrorists have some
concept of what they're doing and how it impacts their victims; I suspect
that many of the people who smurf or mail bomb or ping-flood or crack a
system have little understanding of the real impact of their actions (this
based on the number of times I've seen someone hack a Unix machine and get
root access, then not know what to do and leave tracks all over the
place--best when they use a Linux cracker kit to break into a BSDI
machine, and then they don't know how to proceed).

Obviously a lot of these issues could be resolved if ISP/NSP's installed
address-verification filters in the core and at the edges of their
networks, but that translates into more load for already-loaded routers,
and who's going to do that. And again, the scaling and management issues,
not to mention the fact that many organizations may not have a capable
router or the expertise to do this.

And as long as it's someone else, it's just news and never would happen to
you anyways...

Pete.

==>I do have an access list deny for incoming destinations to *.*.*.255
==>since I do know that the only customer we have with larger than a /24
==>from us (via cw.net) also happens to have nothing larger than /26 in
==>their network. AFAIK, today, smurfers are only using *.*.*.255. They

They also tend to use *.*.*.0. You wouldn't believe the number of hosts
that still respond to the old all-zeros broadcast address.

/cah

I'm afraid that in my experience, that's not true at all. I've seen smurf
attacks bounced off of networks as small as /30's and all the way up to
one network that was a /22, as well as everything inbetween, and I'm not
just talking about the last /30 in a /24 either.

Brandon Ross Network Engineering 404-815-0770 800-719-4664
Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com
                                                            ICQ: 2269442

Stop Smurf attacks! Configure your router interfaces to block directed
broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.

Guys,

Why not make your down-stream fill out a *complete* IN-ADDR.ARPA file which
lists their sub-net bcast and base addresses? That way yo could use the DNS
system itself to find those addresses.

this makes sense...until someone gets lazy, and takes a week to filter,
and the smurf brats catch on, and start querying DNS to find amplifiers.

-Taz

That won't work for them because you are using the same data to build
filters. In fact, you can do it in a script, automate the whole thing..

theoretically speaking.

-Taz