*WARNING* Configuration of your router with the following file may cause multiple configuration errors. Do not configure your router with the following information. Recently today, Nap.Net's coprorate mail exhanger (does not support relaying) was e-mail bombed. Upon tracking this down, we found that the attack was sourcing from kaiwan.com. Our NOC contacted thier contact per InterNIC database, and asked them about the attack, thinking it might have been relayed through them or such. However, the nice gentleman on the phone (read irony into that please) said that that in fact was not the case. The had a script that when it identifies SPAM, it parses the header, retrieves the path of the spam, gets the contact info from the InterNIC database, and then sends multiple emails out to the path of the SPAM for each one received. An automated Denial of Service attack. How nice. Kaiwan.com has been completely uncooperative. Nap.Net has a strict AUP, and has agressively addressed any SPAM complaints addressed against any of it's downstream customers. However, unfortunately a customer must SPAM at least once before we can identify such SPAM. Automated scripts like this are of no help, and in fact possibly cause more harm than help. Just an FYI, it was either steam here, or add a network statement to my BGP config that contains more specific routes of kaiwan.com. This seemed a little less drastic. Chris A. Icide ---------------------------------------------------------------------- Chris A. Icide Genuity, Inc. / Nap.Net, L.L.C. Sr. Network Engineer 4041 North Central Ave. Suite 400 602-207-6409 Phoenix, AZ 85012 - Notice: NVRAM invalid, possibly due to write erase. Press RETURN to get started! - PGP Keys located at pgpkeys.mit.edu or http://nap.net/~chris/keys.html ----------------------------------------------------------------------
On Tue, Nov 18, 1997 at 10:26:58PM +0000, Chris A. Icide wrote:
*WARNING* Configuration of your router with the following file may cause multiple configuration errors. Do not configure your router with the following information.
Recently today, Nap.Net's coprorate mail exhanger (does not support relaying) was e-mail bombed. Upon tracking this down, we found that the attack was sourcing from kaiwan.com. Our NOC contacted thier contact per InterNIC database, and asked them about the attack, thinking it might have been relayed through them or such. However, the nice gentleman on the phone (read irony into that please) said that that in fact was not the case. The had a script that when it identifies SPAM, it parses the header, retrieves the path of the spam, gets the contact info from the InterNIC database, and then sends multiple emails out to the path of the SPAM for each one received. An automated Denial of Service attack. How nice.
Kaiwan.com has been completely uncooperative. Nap.Net has a strict AUP, and has agressively addressed any SPAM complaints addressed against any of it's downstream customers. However, unfortunately a customer must SPAM at least once before we can identify such SPAM. Automated scripts like this are of no help, and in fact possibly cause more harm than help.
Just an FYI, it was either steam here, or add a network statement to my BGP config that contains more specific routes of kaiwan.com. This seemed a little less drastic.
Hmmm... We are implementing a customer-selectable bounce option to our "spamblock" technology which will do something like this, but not nearly that obnoxious. The spamblocker will make ONE attempt to send to the "From" header the bounce message. IF THAT FAILS, it will send ONE copy of the bounce to postmaster and abuse on the MACHINE which LAST relayed the mail to us. The only way the abuse and postmaster mailboxes will get hit is if the From line is forged or otherwise unusable for replies. But, if someone relays off you, you WILL get one message per spam until you fix the relay problem. I think this is perfectly reasonable. One spam, one complaint. Again, this is a configurable option on the customer end. We are currently defaulting to ditch SPAM silently; the customer will have to *ASK* for bounce behavior. The message from the bounce system will have a system default, but also be overrideable on a customer-by-customer basis. Thus, you CAN get a bounce which is an ASCIIzed middle finger, for example :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
participants (2)
-
Chris A. Icide
-
Karl Denninger