Greetings, netscan.org now has a list of the ASNs announcing the most smurf amplifiers, available at: http://netscan.org/most-active-asns.html It's not currently being dynamically generated, but it will be in the next few weeks, when we will probably increase it to show the top 1000 and perhaps add more information (email address, number of amps, average amplification, amps as a percentage of total class Cs being announced). Also, we're in the process of emailing the administrators of these ASNs; about 20 have been notified so far and the other top ~230 will be emailed this week. Each email includes an introduction and current list of amplifiers from that ASN. It's sent to the ASN admin contact and where possible, the NOC, abuse, and/or security contacts, since many backbones have different departments for each. We're also working on a list of amps sorted by ASN. In the meantime, if you administrate or are responsible for an ASN, email sysop@netscan.org for a list of its amplifiers. The other lists - one complete list sorted by IP address, one sorted by # of responses, and a short list of the biggest top 2048 amps - are regenerated each night with results from that day's scans. Every day, all known amplifiers are rechecked and periodically all routed class Cs are checked. The main netscan.org site links to these lists as well as information on the attack. Cheers, Troy
On Sat, 23 Sep 2000, Troy Davis wrote:
Greetings,
netscan.org now has a list of the ASNs announcing the most smurf amplifiers, available at: http://netscan.org/most-active-asns.html
It's not currently being dynamically generated, but it will be in the next few weeks, when we will probably increase it to show the top 1000 and perhaps add more information (email address, number of amps, average amplification, amps as a percentage of total class Cs being announced).
Can someone explain to me why it is ok to blindly scan other peoples networks without their permission for smurf amplifiers and post the results, while doing the same for SMTP servers has met with heavy criticism? The question is *not* intended as a flame, I would just really like to understand the reasoning that makes one apparently acceptable and the other not. Thanks.
On Sat, 23 Sep 2000, Patrick Greenwell wrote:
On Sat, 23 Sep 2000, Troy Davis wrote:
Greetings,
netscan.org now has a list of the ASNs announcing the most smurf amplifiers, available at: http://netscan.org/most-active-asns.html
It's not currently being dynamically generated, but it will be in the next few weeks, when we will probably increase it to show the top 1000 and perhaps add more information (email address, number of amps, average amplification, amps as a percentage of total class Cs being announced).
Can someone explain to me why it is ok to blindly scan other peoples networks without their permission for smurf amplifiers and post the results, while doing the same for SMTP servers has met with heavy criticism?
The question is *not* intended as a flame, I would just really like to understand the reasoning that makes one apparently acceptable and the other not.
Thanks.
IMHO, both types of scans serve to benefit the operator of the network/service that is scanned, IF and only _IF_ that operator takes action to correct any problems that may be detected/reported. To more specifically answer your question though, I consider it to be less intrusive for someone to send an ICMP echo request to the broadcast/network address of every CIDR bit boundry of networks on our backbone and count the replies than for someone to randomly scan for SMTP servers and then subject those servers to a massive relay test. The SMTP testing represents more load on hosts and the network than the SMURF testing. --- John Fraizer EnterZone, Inc
[ On Saturday, September 23, 2000 at 21:52:52 (-0400), John Fraizer wrote: ]
Subject: Re: netscan.org update
To more specifically answer your question though, I consider it to be less intrusive for someone to send an ICMP echo request to the broadcast/network address of every CIDR bit boundry of networks on our backbone and count the replies than for someone to randomly scan for SMTP servers and then subject those servers to a massive relay test. The SMTP testing represents more load on hosts and the network than the SMURF testing.
I doubt it. There's almost certainly more traffic generaged by a smurf amplifier test than by relay tests over the same networks, especially if there are indeed smurf amplifiers on that network! Think about it! Troy's real answer aside: The difference is that smurf amplifiers normally only take down IRC, while spam relayers blast us all! :-) hmmm.... that would indicate the response should be the opposite, now wouldn't it, or is it that more *network* operators use IRC than email? :-) What would be interesting would be to correlate the amplifier list with data from a similar true open relay test *scan*. I'd bet it's high. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Sun, Sep 24, 2000 at 12:05:22PM -0400, Greg A. Woods wrote:
The difference is that smurf amplifiers normally only take down IRC, while spam relayers blast us all! :-)
hmmm.... that would indicate the response should be the opposite, now wouldn't it, or is it that more *network* operators use IRC than email? :-)
On a more serious note, abusing an open relay server doesn't wreck (as much) network havoc on the target and fill the pipes of everyone involved. Spam is annoying, being at the wrong end of the attack is devastating. Can we get something like MAPS-RBL BGP that we can peer with that exports the list of currently known amplifier netblocks? I'd subscribe instantly. -- Bill Fumerola - Former Packet Magnet (irc.lsl.com) billf@chimesnet.com / billf@FreeBSD.org PS. Yes, yes, spam fills up pipes and hard disks, blah blah...
On Sun, 24 Sep 2000, Bill Fumerola wrote:
On Sun, Sep 24, 2000 at 12:05:22PM -0400, Greg A. Woods wrote:
The difference is that smurf amplifiers normally only take down IRC, while spam relayers blast us all! :-)
hmmm.... that would indicate the response should be the opposite, now wouldn't it, or is it that more *network* operators use IRC than email? :-)
On a more serious note, abusing an open relay server doesn't wreck (as much) network havoc on the target and fill the pipes of everyone involved. Spam is annoying, being at the wrong end of the attack is devastating.
Can we get something like MAPS-RBL BGP that we can peer with that exports the list of currently known amplifier netblocks?
Avi Freedman talked about setting something like this up a while back, but I don't think he ever got the time to do so.
On Sun, 24 Sep 2000, Bill Fumerola <billf@chimesnet.com> wrote:
Can we get something like MAPS-RBL BGP that we can peer with that exports the list of currently known amplifier netblocks?
We've been considering such a feed but wonder whether any backbones would accept it. I'll take this opportunity to do a straw poll. It wouldn't make a practical dent in traffic unless one or more transit or large end-user providers used it, protecting their downstream customer links. At last count, there are 66317 smurf-amplifying /24s; of course, they'd be aggregated where possible in the announcements. So if you administer a transit-providing organization that would seriously consider using a BGP blackhole feed of smurf-amplifying /24s, email me. Include your AS and a round estimate of the size of your backbone (or customer base, or organization, or something). Also, if you would use it but with some limitations, send that. One opton would be to have a second feed of only those networks with more than, say, 10 responses (8908 /24s) or to make filtering an optional feature based on special customer request. I'll summarize replies next week. I can see the marketing already -- "Sign up with us and avoid the fate of Yahoo, Ebay.." Cheers, Troy
On Sun, 24 Sep 2000, Troy Davis wrote:
links. At last count, there are 66317 smurf-amplifying /24s; of course, they'd be aggregated where possible in the announcements.
Why aggregrate ? You could just announce the /32's of the actual broadcast addresses, and cause much less damage to other resources on that network. Also if you do aggregrate, your blackhole route will probabally be less specific then the 'real' route, so the 'real' route and not the blackhole one is what would get used. -James
On Sun, 24 Sep 2000, James A. T. Rice <James_R-nanog@jump.org.uk> wrote:
Why aggregrate ? You could just announce the /32's of the actual broadcast addresses, and cause much less damage to other resources on that network.
/32 announcements filter the pre-amplification (attacker -> amplifier) traffic, which very likely takes a different path than post-amplification (amplifier -> victim) traffic. Since using 1.2.3.255 as an amplifier can result in responses from other IPs within 1.2.3.0/24 (and occasionally even other netblocks), if the attacker <-> amplifier path doesn't accept the BGP feed, the attack will happen regardless of whether the victim's upstream accepts the BGP feed. The /24 announcements filter [most of] the actual flood as well as the amplifiers.
Also if you do aggregrate, your blackhole route will probabally be less specific then the 'real' route, so the 'real' route and not the blackhole one is what would get used.
Good point. Unaggregated /24s would be the way to go. To keep the number of routes managable, we would probably announce just those with a high amplification ( > 10x). Cheers, Troy
On Sun, 24 Sep 2000, Troy Davis wrote:
/32 announcements filter the pre-amplification (attacker -> amplifier) traffic, which very likely takes a different path than post-amplification (amplifier -> victim) traffic. Since using 1.2.3.255 as an amplifier can result in responses from other IPs within 1.2.3.0/24 (and occasionally even other netblocks), if the attacker <-> amplifier path doesn't accept the BGP feed, the attack will happen regardless of whether the victim's upstream accepts the BGP feed.
The /24 announcements filter [most of] the actual flood as well as the amplifiers.
If you want to filter the flood rather than the pre-amplification, you'd be trying to filter by source IP, rather than nullroute on destination ip, which would require either policy routing, which is relativly expensive, or something along the lines of ciscos ip verify unicast reverse path, which you'd be lucky if you found an interface 'safe' to use it on. This would be a LOT more work for people to set up than nullrouting the /32 broadcast addresses. -James
It's sounding like what we're working our way around to is that two separate BGP feeds would be needed: 1) One with an announcement of all of the /32s which are broadcast addresses of amplifier networks, so that operators can route traffic _destined_ for those /32s to Null0. 2) Another with an announcement of all of the whole blocks of amplifier addresses, so that operators who choose to can create policy-routes which specify that traffic _originating_ from those addresses (and which are _also_ ICMP echo-replies, perhaps) gets policy routed to Null0. I'd guess that feed #1 would be an easy sell, and that many fewer people would use feed #2 as well, but both seem like good ideas. -Bill
On Sun, 24 Sep 2000, James A. T. Rice <James_R-nanog@jump.org.uk> wrote:
or something along the lines of ciscos ip verify unicast reverse path, which you'd be lucky if you found an interface 'safe' to use it on. This would be a LOT more work for people to set up than nullrouting the /32 broadcast addresses.
Indeed, I was thinking backwards. /32s it will be. There seems to be at least some interest, so we will try to set this up. Thanks, Troy
For whatever reason Cisco's will TAKE null routes to classful broadcasts, however, they will not propagate them. You'll need a Juniper/GateD Box/whatever to push out the routes... And you would only want to null/discard the /32 of the actual ampilifier, not the entire netblocks I would imagine. If you null/discarded the entire /24...well that would make some quite unhappy customers...The object should be not to stop the smurf once it is ongoing, but to prevent it from ever happening... On another note, Troy if you need help with anything...Let me know I'd like to get as many amp sites off the net as possible.. On Sun, 24 Sep 2000, James A. T. Rice wrote:
On Sun, 24 Sep 2000, Troy Davis wrote:
links. At last count, there are 66317 smurf-amplifying /24s; of course, they'd be aggregated where possible in the announcements.
Why aggregrate ? You could just announce the /32's of the actual broadcast addresses, and cause much less damage to other resources on that network.
Also if you do aggregrate, your blackhole route will probabally be less specific then the 'real' route, so the 'real' route and not the blackhole one is what would get used.
-James
As would I. I think a large number of people would. Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - raistlin@tacorp.net - jslagle@toledolink.com - WHOIS JS10172 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GE d-- s:+ a-- C++ UL+++ P--- L+++ E- W- N+ o-- K- w--- O M- V PS+ PE+++ Y+ PGP t+ 5 X+ R tv+ b+ DI+ D G e+ h! r++ y+ ------END GEEK CODE BLOCK------ On Sun, 24 Sep 2000, Bill Fumerola wrote:
On a more serious note, abusing an open relay server doesn't wreck (as much) network havoc on the target and fill the pipes of everyone involved. Spam is annoying, being at the wrong end of the attack is devastating.
Can we get something like MAPS-RBL BGP that we can peer with that exports the list of currently known amplifier netblocks?
I'd subscribe instantly.
On Sat, 23 Sep 2000, Patrick Greenwell <patrick@cybernothing.org> wrote:
Can someone explain to me why it is ok to blindly scan other peoples networks without their permission for smurf amplifiers and post the results, while doing the same for SMTP servers has met with heavy criticism?
Honestly, it's because we haven't been issued a cease-and-desist order or been sued and lost. Practically, receiving a smurf attack is more costly and bothersome than receiving a piece of spam. Both are annoying but only one can wreck my day. The damage caused by DoS attacks makes for more willingness to accept minor annoyances of scans, mostly firewalls being tripped. That's the reason that netscan.org receives very little criticism -- network administrators would rather have it than not. On the legal front, lack of exposure plays a part. MAPS is much better known than all of the smurf scanning projects combined, especially to non-technical people. MAPS also offers RBL services that can be easily used for blocking traffic and, for some, that translates to lost dollars. So the non-technicals count how many beans they lose from RBL and compare it to the beans they'd pay lawyers to sue. At some point, RBL has enough users that the scale tips and a lawsuit is cost effective. RBL annoys lawsuit-happy folks that perhaps MAPS RSS doesn't. Netscan.org hasn't created a BGP blackhole announcement out of lack of time and because, at least while some significant sites are on it, we doubt many people would use it. Interestingly, looking at the top smurf-announcing ASNs, an average American backbone could block easily half of them and barely notice. As far as criticism, we haven't seen much (and have received a lot of feedback). We regularly receive complaints about scans triggering firewalls, but after a reply, users understand the goal is and don't mind. CERT is the only group that has really been annoyed with the scanning, and even they seem to have stopped emailing. Very few people are annoyed at being listed, but most of our emails go to admins of larger networks, not single-site admins who may think "Gargamel" when told of smurfing. Cheers, Troy
On Sat, Sep 23, 2000 at 08:19:58PM -0700, Troy Davis wrote:
Netscan.org hasn't created a BGP blackhole announcement out of lack of time and because, at least while some significant sites are on it, we doubt many people would use it. Interestingly, looking at the top smurf-announcing ASNs, an average American backbone could block easily half of them and barely notice.
I've been very quiet on the scanning for smurf amps thing... which is contrary to my nature :-) However, I would really not like to see a BGP based listing of smurf amps based on results from scanning. E-mailing network operators who have smurf amps that happen to not have been abused (maybe its a /30 with little bandwidth) smacks of UBE to me... and you shouldn't be listing without notification... -- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header
On Mon, 25 Sep 2000, John Payne wrote:
On Sat, Sep 23, 2000 at 08:19:58PM -0700, Troy Davis wrote:
Netscan.org hasn't created a BGP blackhole announcement out of lack of time and because, at least while some significant sites are on it, we doubt many people would use it. Interestingly, looking at the top smurf-announcing ASNs, an average American backbone could block easily half of them and barely notice.
I've been very quiet on the scanning for smurf amps thing... which is contrary to my nature :-)
However, I would really not like to see a BGP based listing of smurf amps based on results from scanning.
E-mailing network operators who have smurf amps that happen to not have been abused (maybe its a /30 with little bandwidth) smacks of UBE to me... and you shouldn't be listing without notification...
-- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header
John, The problem is that while some operators may not have been aware of their problem, if they are not aware of the problem at-large, they are, IMHO, not worthy of announcing to the global internet at large and as such, we should not be listening to their announcements. If, once they figure out they're being filtered, they decide to take care of their problems, they will be removed from the BGP feed. The SMURF problem is years old. People who don't look for this on their own networks and prevent it before it starts are AS MUCH if not MORE a part of the problem as the script kiddies. So, to sum it up, I disagree. To back this up, if you find a SMURF amplifier on my network, please feel free to add ip as-path access-list WHATEVER deny 13944 to your filters. We check our network constantly and have NEVER been the originator of, or a transit AS for a SMURF attack of _ANY) size. --- John Fraizer EnterZone, Inc
John; IMHO they are in complicity with harming the network fabric and that of their competitors by allowing such disruption of routing. "The SMURF problem is years old. People who don't look for this on their own networks and prevent it before it starts are AS MUCH if not MORE a part of the problem as the script kiddies". -- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | |--------------------------------| Henry R. Linneweh
"Henry R. Linneweh" wrote:
John; IMHO they are in complicity with harming the network fabric and that of their competitors by allowing such disruption of routing.
"The SMURF problem is years old. People who don't look for this on their own networks and prevent it before it starts are AS MUCH if not MORE a part of the problem as the script kiddies".
Implementing RFC 2827 (ingress filtering) and RFC 2644 (disabling directed broadcast) is more than just a nice idea. These are both BCPs, since they both represent methods for limiting damage to the Internet. When negotiating contracts with downstream clients, perhaps adding language that insists on implementation of these would be worthwhile? The documents were written and given BCP status so that the community can refer to them and hopefully increase the number of sites that comply. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com
Daniel; I believe you have hit upon a novel idea that has a lot of merit, its time has come. 1) Implementing RFC 2827 (ingress filtering) and RFC 2644 (disabling directed broadcast) is more than just a nice idea. These are both BCPs, since they both represent methods for limiting damage to the Internet. 2) When negotiating contracts with downstream clients, perhaps adding language that insists on implementation of these would be worthwhile? I believe this is in everyones best interest and a very worthwhile pursuit. The documents were written and given BCP status so that the community can refer to them and hopefully increase the number of sites that comply. -- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | |--------------------------------| Henry R. Linneweh
On Tue, Sep 26, 2000 at 01:13:35AM -0400, John Fraizer wrote:
The problem is that while some operators may not have been aware of their problem, if they are not aware of the problem at-large, they are, IMHO, not worthy of announcing to the global internet at large and as such, we should not be listening to their announcements.
So you wouldn't mind if people started scanning your network for other problems, say... rootable boxes? Without being able to break into remote boxes, kiddies wouldn't be able to launch smurf attacks of sizes to worry about. I'm not saying that having a list is a bad idea. But it should be a list of amps that have been found using logs from attacks, not by going out and scanning for them -- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header
On Tue, 26 Sep 2000, John Payne wrote:
On Tue, Sep 26, 2000 at 01:13:35AM -0400, John Fraizer wrote:
The problem is that while some operators may not have been aware of their problem, if they are not aware of the problem at-large, they are, IMHO, not worthy of announcing to the global internet at large and as such, we should not be listening to their announcements.
So you wouldn't mind if people started scanning your network for other problems, say... rootable boxes? Without being able to break into remote boxes, kiddies wouldn't be able to launch smurf attacks of sizes to worry about.
random and not-so-random scans against our network are met with quite a few suprises for the scanner. It's NOT an exercise that I recommend. As a matter of fact, it's quite a BAD idea. Beyond that, your assumption is completely in error about the kiddies needing rooted boxes to launch successful and quite large SMURF attacks. DSL and cable modems make it quite easy for them to do so. --- John Fraizer EnterZone, Inc
On Tue, Sep 26, 2000 at 04:19:03PM -0400, John Fraizer wrote:
On Tue, 26 Sep 2000, John Payne wrote:
On Tue, Sep 26, 2000 at 01:13:35AM -0400, John Fraizer wrote:
The problem is that while some operators may not have been aware of their problem, if they are not aware of the problem at-large, they are, IMHO, not worthy of announcing to the global internet at large and as such, we should not be listening to their announcements.
So you wouldn't mind if people started scanning your network for other problems, say... rootable boxes? Without being able to break into remote boxes, kiddies wouldn't be able to launch smurf attacks of sizes to worry about.
random and not-so-random scans against our network are met with quite a few suprises for the scanner. It's NOT an exercise that I recommend. As a matter of fact, it's quite a BAD idea.
So why are you advocating scanning for smurf amps?
Beyond that, your assumption is completely in error about the kiddies needing rooted boxes to launch successful and quite large SMURF attacks. DSL and cable modems make it quite easy for them to do so.
Oh... well... not having experience with cable or dsl, I had assumed that cable and dsl were source filtered. My bad -- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header
On Tue, Sep 26, 2000 at 01:44:15PM -0700, John Payne wrote:
Oh... well... not having experience with cable or dsl, I had assumed that cable and dsl were source filtered. My bad
No, that would be a sign of responsibility on the part of several providers of which a fair majority of abuse originates. @home would do the world a big favor by ingress filtering, but I don't see that happening with the current clue level of people I've dealt with over there. -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org
On Tue, 26 Sep 2000, John Payne wrote:
few suprises for the scanner. It's NOT an exercise that I recommend. As a matter of fact, it's quite a BAD idea.
So why are you advocating scanning for smurf amps?
Sending a single ICMP echo-request to every /30 boundry inside our network and those of our customers and counting the replies doesn't bother me at all. It is about as non-intrusive as you get. If someone doesn't want people sending ICMP echo-request to their network, they need to block it at the borders. If they do that, even if they have amp nets inside, they won't be available for abuse from the outside. For those of us who sell transit, it's not an option to block ICMP at the border. Our customers like to be able to do ping tests, blah blah blah. In any case, I find scanning for SMURF amps and scanning for vulnerabilities to be quite different. Liken it to the Gas company driving up and down your street with a sniffer looking for leaks (SMURF amps) and someone walking up to every house in the neighborhood with a ladder and testing the second story windows looking for those that are unlocked. They are two completewly different things and just as scanning for exploitable holes on our net earns a nasty suprise, walking into my yard with a ladder and trying my windows will get you shot! --- John Fraizer EnterZone, Inc
John Fraizer writes:
If someone doesn't want people sending ICMP echo-request to their network, they need to block it at the borders. If they do that, even if they have amp nets inside, they won't be available for abuse from the outside.
Only from ICMP echo-request based DDoS', others will still be available. They'd have to block all traffic to their broadcast addresses, which is pretty much what ``no directed broadcast'' does anyway.
In any case, I find scanning for SMURF amps and scanning for vulnerabilities to be quite different.
Can't say I agree, since in fact they are both "vulnerabilities". This is already too damn close to the usual thread about the other active scan for my comfort. /mark
On Fri, 13 Oct 2000, Mark Milhollan - Franklin Employee wrote:
John Fraizer writes:
If someone doesn't want people sending ICMP echo-request to their network, they need to block it at the borders. If they do that, even if they have amp nets inside, they won't be available for abuse from the outside.
Only from ICMP echo-request based DDoS', others will still be available. They'd have to block all traffic to their broadcast addresses, which is pretty much what ``no directed broadcast'' does anyway.
Um, did I say anything about other types of DDoS? The thread, which is nearly three weeks old BTW, was about netscan.org and scanning for SMURF amp nets.
In any case, I find scanning for SMURF amps and scanning for vulnerabilities to be quite different.
Can't say I agree, since in fact they are both "vulnerabilities".
I would have hoped that you would have read the entire thread prior to composing your reply. Had you done so, perhaps your opinion might be different. In any case, the thread has been quiet for weeks now.
This is already too damn close to the usual thread about the other active scan for my comfort.
/mark
So why stir it more? --- John Fraizer EnterZone, Inc
On Tue, 26 Sep 2000, John Payne wrote:
I'm not saying that having a list is a bad idea. But it should be a list of amps that have been found using logs from attacks, not by going out and scanning for them
The problem with reasonable sized smurfs is that you can't just casually log them and trace back. If I want to go after open mail relays I can just look at the headers of spam I personally get and trace these back to the providers. Logging 10-100 Mb/s smurfs (which we see several per day) on the other hand is not something you can just do and trace back. That level of traffic tends to melt whatever you try to log it with unless you throw a bit of time and hardware into preparing to log it. Of course when it's 50 machines scattered across the Internet all spoofing random source addresses then don't even bother. -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz Senior Network/System Admin | | Home: simon@darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
On Sat, Sep 23, 2000 at 06:39:37PM -0700, Patrick Greenwell wrote:
Can someone explain to me why it is ok to blindly scan other peoples networks without their permission for smurf amplifiers and post the results, while doing the same for SMTP servers has met with heavy criticism?
A large part of it is probably that very few administrators set of warning bells on a single ping, but a substantial fraction of mail administrators get floods of e-mail warnings from the mail testing programs, wasting their time and energy. When you scan properly locked down boxes in a way that fills an admins mailbox they get testy. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
2000-09-23-21:39:37 Patrick Greenwell:
Can someone explain to me why it is ok to blindly scan other peoples networks without their permission for smurf amplifiers and post the results, while doing the same for SMTP servers has met with heavy criticism?
How about, allowing IP Directed Broadcast may let your machines help to shut down connectivity somewhere, but it doesn't show up in peoples' mailboxes. Spammers have collected such a rabid hatred that allowing your company to be associated with them in any way, even aiding and abetting, gets you shunned something fierce, it can generate ill-will enough to push a company over the edge and out of business. Being a smurf amplifier will never be known to customers of most organizations; and even if they heard, they wouldn't understand what it meant. So it doesn't generate the rabid hatred. Getting listed with ORBS not only means your email gets blocked, it also raises a fear that your site is likely to be featured in a major spam torrent, and you are likely to catch a lot of the flak and ill-will that follows; the pain inflicted on you is great, so you whine loudly and try to blame ORBS for your neglect. Being listed as a smurf-amplifier may get your site used to take out other nets, but it won't earn you customers leaving and staying away in droves. Does anybody have any evidence one way or another on whether spammers do or don't use ORBS to find relays? -Bennett
[ On Sunday, September 24, 2000 at 18:14:44 (-0400), Bennett Todd wrote: ]
Subject: Re: netscan.org update
Does anybody have any evidence one way or another on whether spammers do or don't use ORBS to find relays?
I still get relayed spam that is not blocked by ORBS. This would tend to suggest that some spammers are still searching for their own relays, but of course doesn't say anything about whether or not other spammers are using ORBS to find relays. If I were a spammer I wouldn't use ORBS to find relays (why bother? there are lots more out there and the ORBS ones are more likely to be blocked already), but then I've never really had much luck trying to think like a spammer in the past.... -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (16)
-
Bennett Todd -
Bill Fumerola -
Bill Woodcock -
Daniel Senie -
dies -
Henry R. Linneweh -
James A. T. Rice -
Jason Slagle -
John Fraizer -
John Payne -
Leo Bicknell -
Mark Milhollan - Franklin Employee -
Patrick Greenwell -
Simon Lyall -
Troy Davis -
woods＠weird.com