Doh! That should have read: ftp://ftp.mindspring.net/users/bross/smurfsources On Sat, 9 Jan 1999, Quan Nguyen wrote:
On Sat, 9 Jan 1999, Brandon Ross wrote:
Since a couple folks have asked for it, and I think the list is a bit large to send to the entire list, I've put the list up for anonymous ftp at:
ftp://www.mindspring.net/users/bross/smurfsources
I got this. My network is 132.206.0.0/26.
% ftp www.mindspring.net ftp: connect to address 207.69.200.96: Connection refused Trying 207.69.200.97... ftp: connect: Connection refused ftp> quit
Quan,
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.
Brandon Ross wrote:
ftp://ftp.mindspring.net/users/bross/smurfsources
I find it slightly interesting that some private addresses were in the list. There were some addresses in 10/8, 172.16/12, and 192.168/16. Thus the source of the attack must have had some addresses in these private network ranges reachable somehow, either internally in the network the attacker(s) originate, or routes leaking onto the internet. If the former, that would mean they had the capacity from that internal network to carry the forged echo requests as well as those private sourced echo replies. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
On Sat, 9 Jan 1999, Phil Howard wrote:
Brandon Ross wrote:
ftp://ftp.mindspring.net/users/bross/smurfsources
I find it slightly interesting that some private addresses were in the list. There were some addresses in 10/8, 172.16/12, and 192.168/16. Thus the source of the attack must have had some addresses in these private network ranges reachable somehow, either internally in the network the attacker(s) originate, or routes leaking onto the internet. If the former, that would mean they had the capacity from that internal network to carry the forged echo requests as well as those private sourced echo replies.
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). Jeremiah
On Mon, 11 Jan 1999, 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).
Jeremiah
Clue should also be provided to the network operators who actually listen to route advertisements for these networks. We use private address space here for various things, some of which are even production, but you've never once seen us leak the advertisements for them. And if we did make the mistake of allowing them out, no one should ever listen to us about them. Blocking traffic from reserved space at your borders and not listening to route advertisements for reserved space should be common practice. I would hope anyone clueful enough to be on this list would know this already. -- Joseph Shaw - jshaw@insync.net NetAdmin/Security - Insync Internet Services Free UNIX advocate - "I hack, therefore I am."
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. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
On Mon, 11 Jan 1999, Phil Howard wrote: <<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
Jeremiah Kristal wrote:
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.
My biggest suspicion is that the clueless script kiddie(s) involved did a scan for amplifiers w/o regard to RFC1918 (the number of addresses in RFC1918 is a mere 0.476% of the whole possible range), and never filtered them out. They perhaps did make the attack slightly worse than w/o, so maybe leaving them in was intended. Now if we can identify who has 10.177.180/24 internally, we could be getting somewhere. One thing that could be useful when reducing attack sniff data to a list of addresses is to produce a frequency of occurrence for each address. There may be wide ranges in the frequencies. If 10.177.180/24 shows up very rarely compared to the rest, that could indicate that the attack is originating on a relatively low speed network with 10.177.180/24 being behind that network. OTOH, if it is about the same, then the bandwidth for that network would be relatively high. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
On Mon, Jan 11, 1999 at 12:14:04PM -0500, Jeremiah Kristal put this into my mailbox:
On Mon, 11 Jan 1999, Phil Howard wrote:
<<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 -- Dalvenjah FoxFire (aka Sven Nielsen) May the schwartz be with you! Founder, the DALnet IRC Network e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
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. On Mon, 11 Jan 1999, Dalvenjah FoxFire wrote:
Date: Mon, 11 Jan 1999 10:13:51 -0800 From: Dalvenjah FoxFire <dalvenjah@DAL.NET> To: Jeremiah Kristal <jeremiah@fs.IConNet.NET> Cc: Phil Howard <phil@whistler.intur.net>, bross@mindspring.net, nanog@merit.edu Subject: Re: Huge smurf attack
On Mon, Jan 11, 1999 at 12:14:04PM -0500, Jeremiah Kristal put this into my mailbox:
On Mon, 11 Jan 1999, Phil Howard wrote:
<<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
-- Dalvenjah FoxFire (aka Sven Nielsen) May the schwartz be with you! Founder, the DALnet IRC Network
e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
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)
On Mon, 11 Jan 1999, Dalvenjah FoxFire wrote:
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").
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
On Mon, 11 Jan 1999, Dan Hollis wrote:
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 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________
On Mon, 11 Jan 1999, Jon Lewis wrote:
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
On Mon, 11 Jan 1999, Dan Hollis wrote:
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.
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________
Jon Lewis wrote:
This might not be allowed under existing service contracts. Most providers probably have provisions to disconnect for network abuse...but not for cluelessness.
Then we need to re-classify having an open broadcast amplifier as an abuse. If we can get upstreams and backbones to give a formal 30 day notice, then start cutting lines ... OTOH, what about just declaring that X.X.X.{0,255} is off limits regardless of the network size? It would take just 2 access list entries to make those addresses in networks larger than /24 to be mostly useless. There aren't that many LANs out there that would have real non-broadcast use on these addresses, anyway. I block these coming in to my network as destinations, and I'm tempted to block them as sources, as well. Once these addresses are indeed off limits, then the next step is to get backbones to put in the access lists. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
Phil Howard wrote:
Jon Lewis wrote:
This might not be allowed under existing service contracts. Most providers probably have provisions to disconnect for network abuse...but not for cluelessness.
Then we need to re-classify having an open broadcast amplifier as an abuse. If we can get upstreams and backbones to give a formal 30 day notice, then start cutting lines ...
I think this could easily be classified as abuse or abuse through negligence (reckless endangerment?). Provider contracts should specify that downstreams must deal with ingress filtering and must ensure their networks will not respond to directed broadcasts from outside.
OTOH, what about just declaring that X.X.X.{0,255} is off limits regardless of the network size? It would take just 2 access list entries to make those addresses in networks larger than /24 to be mostly useless. There aren't that many LANs out there that would have real non-broadcast use on these addresses, anyway. I block these coming in to my network as destinations, and I'm tempted to block them as sources, as well. Once these addresses are indeed off limits, then the next step is to get backbones to put in the access lists.
No. This is not a good plan. There are indeed networks out there with supernetted LANs. I consult for a large research institution which uses /22 masks for all subnets, and heavily uses them. The chances of clobbering perfectly legitimate addresses is real. Beyond this, there are plenty of /25 networks that'll do a perfectly good job of playing smurf-amplifier. The solution isn't to apply access lists. The proper answer to this is to disable directed broadcasts on the routers themselves. It'd be helpful if routers came out of the box with this feature disabled by default. Perhaps folks should talk with their router vendors of choice and ask for this change. I have submitted a draft into the IETF process to require this change, updating RFC 1812 (router requirements). Unfortunately directed broadcasts, like ingress filtering, are items that have to be properly dealt with at the edges of the network. I do wonder if we will start seeing network providers' legal departments start taking notice of the situation. Negligence in operating a network and becoming an unwitting accessory to a crime might raise the level of urgency in getting folks to address both ingress filtering and directed broadcast issues. I would prefer to see this handled by the technical folks without getting the legal types into the fray, but worry that some will not take the urgency to heart. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
On Mon, 11 Jan 1999, Daniel Senie wrote:
Then we need to re-classify having an open broadcast amplifier as an abuse. If we can get upstreams and backbones to give a formal 30 day notice, then start cutting lines ... I think this could easily be classified as abuse or abuse through negligence (reckless endangerment?). Provider contracts should specify that downstreams must deal with ingress filtering and must ensure their networks will not respond to directed broadcasts from outside.
Speaking of negligence, I am disappointed at the backbones who continue to route rfc1918 addresses, and wacko addresses like 0.0.0.0 and 255.255.255.255. It is REALLY all that much to ask you guys to null0 route these networks? Sheesh. -Dan
I think it's time to do a technical refresh for those of you who think routing 0.0.0.0, 10/8, 172.16/12, 192.168/16, etc. to null0 will solve the smurf problem. Not so. Routing in the Internet is done on a DESTINATION basis. The reason you see 0.0.0.0 and/or 255.255.255.255 devices in a smurf is that many times there are IP-capable network devices never configured within some networks which will respond with their default IP address (0.0.0.0 or 255.255.255.255). I have 205.166.195.0/24. Let's say I put some manageable hub on the wire, but never configure it -- its default IP address remains at 0.0.0.0. Remember that the spoofed echo-request packet is sent to 205.166.195.255. If directed broadcasts are on, the router sending the packet onto the wire will send it to the broadcast MAC address. Because it was a broadcast, this device then responds to the originally spoofed source address, with a *source* IP address of 0.0.0.0. Unless you're using a feature such as unicast RPF checking, a router doesn't care what source address you're using -- it gets the packet to its destination. RFC 2267 gives informative guidelines on how to configure networks to prevent source-spoofed addresses from exiting the network. This has limited scalability, though, as you move closer to the core -- as you stack a few service providers together, it gets pretty difficult to manage those filters. Unicast RPF-checking is a very good way to automatically filter source spoofs; however, it only works at the edge of the network, because multi-homing can cause traffic to be dropped if this check is enabled in the wrong place. Now, with that said, I agree that providers should be filtering routing announcements, whether it be through static routes or distribute-lists; however, it will not keep packets with source addresses of 0.0.0.0 or 255.255.255.255 from being delivered to you. /cah On Mon, Jan 11, 1999 at 08:23:44PM -0800, Dan Hollis wrote: ==>On Mon, 11 Jan 1999, Daniel Senie wrote: ==>> > Then we need to re-classify having an open broadcast amplifier as an ==>> > abuse. If we can get upstreams and backbones to give a formal 30 day ==>> > notice, then start cutting lines ... ==>> I think this could easily be classified as abuse or abuse through ==>> negligence (reckless endangerment?). Provider contracts should specify ==>> that downstreams must deal with ingress filtering and must ensure their ==>> networks will not respond to directed broadcasts from outside. ==> ==>Speaking of negligence, I am disappointed at the backbones who continue to ==>route rfc1918 addresses, and wacko addresses like 0.0.0.0 and ==>255.255.255.255. ==> ==>It is REALLY all that much to ask you guys to null0 route these networks? ==> ==>Sheesh. ==> ==>-Dan
On Mon, 11 Jan 1999, Daniel Senie wrote:
The proper answer to this is to disable directed broadcasts on the routers themselves. It'd be helpful if routers came out of the box with this feature disabled by default. Perhaps folks should talk with their router vendors of choice and ask for this change. I have submitted a draft into the IETF process to require this change, updating RFC 1812 (router requirements).
I'm happy to say that progress is being made in this area. When a vendor comes to us for the first time, one of things I tell them is that we will not buy their hardware until they ship with directed broadcast disabled by default. We've had a lot of success in this area, we'd have even more if others would do the same. 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.
On Mon, Jan 11, 1999 at 10:30:41PM -0500, Daniel Senie wrote:
OTOH, what about just declaring that X.X.X.{0,255} is off limits regardless of the network size? It would take just 2 access list entries to make those addresses in networks larger than /24 to be mostly useless. There aren't that many LANs out there that would have real non-broadcast use on these addresses, anyway. I block these coming in to my network as destinations, and I'm tempted to block them as sources, as well. Once these addresses are indeed off limits, then the next step is to get backbones to put in the access lists.
No. This is not a good plan. There are indeed networks out there with supernetted LANs. I consult for a large research institution which uses /22 masks for all subnets, and heavily uses them. The chances of clobbering perfectly legitimate addresses is real. Beyond this, there are plenty of /25 networks that'll do a perfectly good job of playing smurf-amplifier. The solution isn't to apply access lists.
Since Phil's on my side of this argument, I'll jump back in. What percentage of the hosts on the internet occupy an address with a non-broadcast .0 or .255 last octet? What percentage of smurfs would be stopped bu outbound filters on those octets? Which is a bigger win? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
On Mon, 11 Jan 1999, Phil Howard wrote:
OTOH, what about just declaring that X.X.X.{0,255} is off limits regardless of the network size? It would take just 2 access list entries to make those addresses in networks larger than /24 to be
Lots of smurf amps are smaller than /24, and there are plenty of networks larger than /24. ----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________
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 On Mon, 11 Jan 1999, Jon Lewis wrote:
On Mon, 11 Jan 1999, Dan Hollis wrote:
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.
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________
-- Steve Gibbard WWNet System Administration +1 734 513-7707 x 2009 http://www.wwnet.net
On Mon, 11 Jan 1999, Dan Hollis wrote:
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)
Dalvenjah FoxFire wrote:
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").
And most of the clueless ones can't seem to keep what talent they do happen to get. But the cause may not necessarily be lack of talent that knows what to do (I'd like to think so as that does raise job prospects, but reality is that it probably is not).
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.
The cause seems to be that short-term thinking has prevailed over long-term thinking. Is it due to lack of oxygen (it's those ties) or just the fact that this industry is growing so rapidly? At least I do what I can with the lack of resources and finances I have to deal with.
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.
What self-regulation? I don't recall any at all. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
On Mon, 11 Jan 1999, Dalvenjah FoxFire wrote:
Heck, the US Military has half of the entries at netscan.org (and they're supposedly the ones worried about "cyber-terrorism").
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.
Government regulation is clearly the solution. Then everyone would have networks as well-run as the U.S. military... -- Michael Dillon - E-mail: michael@memra.com Check the website for my Internet World articles - http://www.memra.com
On Tue, Jan 12, 1999 at 05:37:17AM -0800, Michael Dillon wrote:
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.
Government regulation is clearly the solution. Then everyone would have networks as well-run as the U.S. military...
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? -- Steve Sobol [sjsobol@nacs.net] Part-time Support Droid [support@nacs.net] NACS Spaminator [abuse@nacs.net] Proud resident of Cleveland Heights, Ohio, the coolest place on earth. http://www.ClevelandHeights.com
On Mon, 11 Jan 1999, Phil Howard wrote:
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.
participants (14)
-
Alex P. Rudnev -
Brandon Ross -
Craig A. Huegen -
Dalvenjah FoxFire -
Dan Hollis -
Daniel Senie -
Jay R. Ashworth -
Jeremiah Kristal -
Joe Shaw -
Jon Lewis -
Michael Dillon -
Phil Howard -
Steve Gibbard -
Steven J. Sobol