Jeremiah Kristal wrote:
I find it even more interesting how often I see 10.177.180.0/24 showing up
in smurf logs. Is there some equipment that defaults to this network,
some manual that uses this as an example, or is there a specific LAN that
gets hit on every major smurf attack? If it's really one network, you
would think we could find and provide clue to the operator(s).
It could be leaking to the Internet in _some_ places (but it isn't here).
It might be internal to the attacker's network, in which case the attacker
is using his bandwidth to wage the attack. It might be internal to the
ISP of the attacker, in which case he's just using his ISP's bandwidth
(the attacker could still wage this from an analog dialup). It could be
remotely possible that it is internal to mindspring, but for that to be,
that network would have to be announced from mindspring (highly doubtful)
and get to the attacker's network (highly doubtful), or maybe the attacker
is actually a mindspring customer (echo requests go out, massive replies
come back) but this would make it way to easy to track down and mindspring
surely has filters on their dialups to block spoofing. One other possible
cause is that the attacker is spoofing those replies as a secret signature.
All outgoing packets from my network are denied unless their source is one
of my netblocks. Obviously the attacker is using someone who will not or
cannot do that.
<<snip discussion about how clueful operators filter RFC1918 addresses>>
I agree that clueful operators filter RFC1918 addresses at their borders
and that they do not accept advertisements for RFC1918 space, however,
there is a specific network (10.177.180/24) that appears again and again
in smurf logs. I find it rather interesting that with 65k available /24s
in the 10/8 space, one specific /24 pops up much more often than any
other. Granted it's not that large an amplifier, but it seems odd that
even an RFC1918 network would be used as an amplifier for this long
without someone finding and securing it.
Jeremiah
On Mon, Jan 11, 1999 at 12:14:04PM -0500, Jeremiah Kristal put this into my mailbox:
<<snip discussion about how clueful operators filter RFC1918 addresses>>
Granted it's not that large an amplifier, but it seems odd that
even an RFC1918 network would be used as an amplifier for this long
without someone finding and securing it.
If that were true, we wouldn't have smurf attacks at all. There are
still many, many clueless or otherwise incompetent ISPs and/or companies
out there (many of whom are large ISPs and/or telcos who should know better
but don't) who have many, many smurf-amplifier netblocks. Heck, the US
Military has half of the entries at netscan.org (and they're supposedly
the ones worried about "cyber-terrorism").
I've come to the unfortunate conclusion that very few people seem to care
about system and network security until they are directly affected because of
something they neglected. If it were otherwise, you wouldn't see "well-known"
sites such as Yahoo, the NY Times, starwars.com &etc. getting hacked
week after week.
Much as I hate to say it, this seems to be one area where industry
self-regulation has utterly failed. I don't know what would be a better
solution; I hate to suggest government regulation. But I'm at a loss here.
-dalvenjah
The only way to prevent most of such attacks is to have STRICT
RESTRICTION for frauding SRC addresses over most of ISP.
While most ISP (including the greatest scientific and education networks)
does allow any their user to sent packets with foreint SRC address, no
any chance to stop this kind of computing hooliganian. Fortunately (!)
for now it's not more than children's games, but what's if
someone try to use it as a weapon... the result can be terrible.
What's about this strange 10.xxx addresses - it can be (1) frauded
addresses (I don't think so), and (2) someone have their non-public
network working in the global address space (withouth external routing
for INCOMING packets but with the possibility to send packets).
The other way (not too good one but the only while there is not strict
filtering policy) to prevent this is to have some kind of stamping
allowing to backtrack frauded packets over the ISP.
Perhaps its time to publicize these smurf amplifiers. Maybe CNET or
someone would like to run a front page article explaining how US tax
dollars are being used to enable denial of service attacks on private
corporations on the internet.
Its time to enforce ip spoofing rules. Any network found sourcing packets
that dont belong to them should be disconnected until they install proper
filters. Anyone found leaking rfc1918 addresses should be disconnected too
until they fix their filters.
Or perhaps someone would like to take a proactive approach at scanning for
smurfable networks and closing them before the script kiddies find them?
Maybe nanog members could pitch in fees to hire someone full time to scan
for smurf networks and shut them down.
-Dan
There are at least 2 different teams already doing this. The trouble is,
who has the authority to disconnect smurf amp networks? Nobody,
really...but the reality is that if an RBL-like system were setup for
smurf amp networks, and if some of the larger backbones subscribed to it,
smurf amp networks would get fixed real fast.
Can any of the readers working for backbones (like UUNet, Sprint, C&W)
speak up and tell us if there's a chance in hell their networks would
subscribe to such a service?
----don't waste your cpu, crack rc5...www.distributed.net team enzo---
Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or
Network Administrator | nestea'd...whatever it takes
Florida Digital Turnpike | to get the job done.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key________
There are at least 2 different teams already doing this. The trouble is,
who has the authority to disconnect smurf amp networks?
Their upstream?
Nobody, really...but the reality is that if an RBL-like system were
setup for smurf amp networks, and if some of the larger backbones
subscribed to it, smurf amp networks would get fixed real fast.
This would be WONDERFUL. Something that takes a list of smurf nets and
feeds them into a bgp->blackhole system?
I notice that contacting the smurf amplifier directly is often pointless
due to unresponsive staff or bad ARIN contact info... but getting their
upstream to pull their connection out of the wall gets their 100%
attention REAL quick. Response time goes from weeks to minutes.
-Dan
This might not be allowed under existing service contracts. Most
providers probably have provisions to disconnect for network abuse...but
not for cluelessness.
----don't waste your cpu, crack rc5...www.distributed.net team enzo---
Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or
Network Administrator | nestea'd...whatever it takes
Florida Digital Turnpike | to get the job done.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key________
Jeremiah Kristal wrote:
> I find it even more interesting how often I see 10.177.180.0/24 showing up
> in smurf logs.
It could be leaking to the Internet in _some_ places (but it isn't here).
It might be internal to the attacker's network, in which case the attacker
is using his bandwidth to wage the attack. It might be internal to the
ISP of the attacker, in which case he's just using his ISP's bandwidth
(the attacker could still wage this from an analog dialup).
Those are all possible, but...
It could be remotely possible that it is internal to mindspring, but for
that to be, that network would have to be announced from mindspring
(highly doubtful) and get to the attacker's network (highly doubtful),
or maybe the attacker is actually a mindspring customer (echo requests
go out, massive replies come back) but this would make it way to easy to
track down and mindspring surely has filters on their dialups to block
spoofing.
Actually we aren't currently using the 10/8 network at all, so that's not
it.
One other possible cause is that the attacker is spoofing those replies
as a secret signature.
That's possible too, however the most likely explanation is that there is
an amplifying network out there somewhere that has this 10.177.180.0/24
network on the same Ethernet segment as some other, publicly accessible
network. Remember that when a directed broadcast is sent to an Ethernet
(assuming that directed broadcast is turned on in the router) that the NIC
will convert it to a MAC broadcast. Most (all?) OS's don't actually check
to see if the destination IP address is actually the broadcast of the
subnet that they are on, they just respond.
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.
> Or perhaps someone would like to take a proactive approach at scanning for
> smurfable networks and closing them before the script kiddies find them?
There are at least 2 different teams already doing this. The trouble is,
who has the authority to disconnect smurf amp networks? Nobody,
really...but the reality is that if an RBL-like system were setup for
You can public the access list for outgoing links discarding initial
packets to this amlifyer, A lot of ISP are ready to install such lists.
Or the other idea - if someone install BGP anouncing this addresses as
the /32 hosts (like RBL does for spam relays) anyone can block this
addresses to NULL and avoid attempts to run smurf from their customers.
smurf amp networks, and if some of the larger backbones subscribed to it,
smurf amp networks would get fixed real fast.
Can any of the readers working for backbones (like UUNet, Sprint, C&W)
speak up and tell us if there's a chance in hell their networks would
subscribe to such a service?
It's of great interest. Through, pay attention to:
(1) to call 'smurf' broken servers are used;
(2) most of such servers are in non-commercial networks (scientific, for
example);
(3) such networks often have their own peering relations instead of using
UUnet and other monsters for the service.
----don't waste your cpu, crack rc5...www.distributed.net team enzo---
Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or
Network Administrator | nestea'd...whatever it takes
Florida Digital Turnpike | to get the job done.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key________
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Government regulation is clearly the solution. Then everyone would have
networks as well-run as the U.S. military...
Speaking as an ISP with lots of small business customers who don't know
what a smurf attack is, much less why they should want to prevent them,
I've found that the easiest solution to this in dealing with customers
whose routers we don't manage is to stick in a filter on our router
upstream from them, blocking any smurfable broadcast addresses. Most of
our customers have just one or two subnets, so that's pretty easy, but it
wouldn't scale all that well to customers with larger, more complex
networks, especially if they're changing their network configuration
somewhat frequently. In that case, though, there's usually somebody there
who I can at least attempt to explain why open broadcast addresses are a
problem to.
-Steve
Possibly. I don't know of anyone who's tried suing over a smurf attack.
If I could afford the lawyer and the court time I'd do it myself.
All we really need is one or two good cases to establish some case law;
then the rest of us can have some legal precedent to point to and say
"If you don't fix your networks, you're screwed."
-dalvenjah
Should be considered a form of DoS, which is covered by the Computer Fraud
and Abuse Act... but only if you can meet the damage amounts, which are
pretty high. State computer fraud statutes are also a possible means of
going after them, although jurisdictional issues loom larger. Still, those
provide remedies against the attacker, not necessarily against the site
utilized in the attack.
-Ray
The problem, of course, at least where smurf amplifiers are concerned, is
that many ISP's are *better* configured than the military. 
Who was it
that said a day or two ago that a majority of smurf amplifiers are being run
by military sites?