NANOG folk: Over the past few weeks, I have noticed an influx of SPAM(tm) transmitted by UUNet dynamic IP dial-up users (read: MSN, Earthlink, GTE, etc.) and relayed using Earthlink SMTP relays. Am I turning senile prematurely, or has anyone else noticed this influx? Also, how easy would it be for Earthlink and other nationwide "ISP's" (or more accurately, UU/PSI resellers) to do the following? This would not stop SPAM(tm) dead in its tracks, but I figure it would make it easier to hold spammers accountable at least... unless, of course, they use throw-away accounts, in which case there is not much that can be done... - institute anti-spam rules on their SMTP relays, i.e. only relay mail reporting to be from earthlink.net and the virtual domains they host - only allow SMTP relaying from IP's assigned to *their customers* dynamically (cross-reference Radius logs?) Constructive feedback would be greatly appreciated! Together, we CAN make a difference. Regards, Adam
At 4:42 PM -0800 12/30/97, Adam Rothschild wrote:
NANOG folk:
Over the past few weeks, I have noticed an influx of SPAM(tm) transmitted by UUNet dynamic IP dial-up users (read: MSN, Earthlink, GTE, etc.) and relayed using Earthlink SMTP relays. Am I turning senile prematurely, or has anyone else noticed this influx?
Also, how easy would it be for Earthlink and other nationwide "ISP's" (or more accurately, UU/PSI resellers) to do the following? This would not stop SPAM(tm) dead in its tracks, but I figure it would make it easier to hold spammers accountable at least... unless, of course, they use throw-away accounts, in which case there is not much that can be done...
- institute anti-spam rules on their SMTP relays, i.e. only relay mail reporting to be from earthlink.net and the virtual domains they host
- only allow SMTP relaying from IP's assigned to *their customers* dynamically (cross-reference Radius logs?)
Constructive feedback would be greatly appreciated! Together, we CAN make a difference.
Regards, Adam
We require all of our cutomers' users to authenticate themselves, i.e., their current IP address with us via a POP connection before they're allowed to use our SMTP servers. Once a successful POP login has been completed, that "authorization" is good for 30 minutes. Because we've done this, our service has been 100% free from unauthorized relaying while at the same time keeping our relays totally open for our customers' customers no matter where they've connecting. This was essential for us to implement because we're a mail service provider for Internet service providers, all of our direct customers are ISPs, and we have no control over the networks that those ISPs' users come in from. -- Wayne D. Correia Critical Path Inc. tel: +1-415-543-2800 CTO 320 First Street fax: +1-415-543-2830 San Francisco, CA 94105 pcs: +1-415-826-6000 "we handle the world's email" http://www.criticalpath.net
NANOG folk:
Over the past few weeks, I have noticed an influx of SPAM(tm) transmitted by UUNet dynamic IP dial-up users (read: MSN, Earthlink, GTE, etc.) and relayed using Earthlink SMTP relays. Am I turning senile prematurely, or has anyone else noticed this influx?
Yeah, I've seen some of it.
Also, how easy would it be for Earthlink and other nationwide "ISP's" (or more accurately, UU/PSI resellers) to do the following? This would not stop SPAM(tm) dead in its tracks, but I figure it would make it easier to hold spammers accountable at least... unless, of course, they use throw-away accounts, in which case there is not much that can be done...
- institute anti-spam rules on their SMTP relays, i.e. only relay mail reporting to be from earthlink.net and the virtual domains they host
Um..I think "the virtual domains they host" may be the tricky bit. I don't know how UU/PSI do their mail serving, but if Earthlink has its d/u customers point to a UU/PSI relay for SMTP delivery, there's the matter of keeping everyone's records up to date. OTOH, if Earthlink (or whomever - Earthlink is just an example, here) points its customers towards something like mail.earthlink.net for SMTP relay, see below....
- only allow SMTP relaying from IP's assigned to *their customers* dynamically (cross-reference Radius logs?)
Good idea, although I think it may have some negative impacts on performance. Again, there's also the matter of keeping everyone's records in sync. mail.earthlink.net seems to have some basic relay filters in place, although I'm not sure what their complete ruleset is. Take a look at somebody like Xcom (hi, marty!) - www.xcom.net. I'm not affiliated with them in any way, but it looks like what they do may be useful. A Layer 2 approach means that you can assign only _your own_ IPs to dialin customers, which cuts out the aforementioned Radius cross-reference.
Constructive feedback would be greatly appreciated! Together, we CAN make a difference.
Regards, Adam
eric
OTOH, if Earthlink (or whomever - Earthlink is just an example, here) points its customers towards something like mail.earthlink.net for SMTP relay, see below....
They run their own SMTP relays... some sort of round robin setup, servers named after different countries of the world. So, the ball is in their court, so to speak.
Take a look at somebody like Xcom (hi, marty!) - www.xcom.net. I'm not affiliated with them in any way, but it looks like what they do may be useful. A Layer 2 approach means that you can assign only _your own_ IPs to dialin customers, which cuts out the aforementioned Radius cross-reference.
That's certainly an idea worth considering, if you are not distributed accross a gazillion Ascend MAX TNT units (for UU anyways, duno what PSI uses.. anyone?)... But I digress... -=Adam
- only allow SMTP relaying from IP's assigned to *their customers* dynamically (cross-reference Radius logs?)
I have heard that uunet and PSI don't provide enough information in real time for their POP farm ISP customers to tell the difference between their own customers and other random users of the same POP farms, much less tell which user is on which IP so they can stamp outgoing mail. Is that still true? Speaking of POP farms, the other major one is IBM -- how much real-time info do they provide? And since we're on this topic, at NANOG in Scottsdale we suggested that ISPs firewall in their users so the only port 25 connections they can make are to the ISP's own SMTP server, so the ISP can stamp outgoing mail with the actual sender ID and possibly do volume monitoring and choking. (You could either block connections or other systems, or warp them to your own servers, and you'd need provision for exceptions for people who send in a signed AUP, etc.) How far is that from being feasible for POP farm customers? -- John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com, Village Trustee and Sewer Commissioner, http://iecc.com/johnl, Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47
John R. Levine writes:
And since we're on this topic, at NANOG in Scottsdale we suggested that ISPs firewall in their users so the only port 25 connections they can make are to the ISP's own SMTP server, so the ISP can stamp outgoing mail with the actual sender ID and possibly do volume monitoring and choking. (You could either block connections or other systems, or warp them to your own servers, and you'd need provision for exceptions for people who send in a signed AUP, etc.) How far is that from being feasible for POP farm customers?
It is pretty easy to filter port 25 connections from the ranges in question. I will also point out that many of the recent "smurf" attacks and similar problems people are having on the net would be gone if people would just carefully filter internal/external addresses on their border machines, that is, prevent packets claiming to be from "inside" networks from coming in from the "outside", and prevent packets claiming to be from "outside" networks from going out from the "inside". The latter will stop your network from *ever* being the source of a wide variety of packet forgery attacks, and is necessary to being a good network citizen. The former will stop your network from being the subject of a wide variety fo packet forgery attacks, and is necessary to make your customers even remotely safe on the net. I've been thinking of surveying randomly selected networks to see how many people are actually taking these (critical and necessary) steps. Perry
I will also point out that many of the recent "smurf" attacks and similar problems people are having on the net would be gone if people would just carefully filter internal/external addresses on their border machines, that is, prevent packets claiming to be from "inside" networks from coming in from the "outside", and prevent packets claiming to be from "outside" networks from going out from the "inside". The latter will stop your network from *ever* being the source of a wide variety of packet forgery attacks, and is necessary to being a good network citizen. The former will stop your network from being the subject of a wide variety fo packet forgery attacks, and is necessary to make your customers even remotely safe on the net.
I strongly recommend such filtering in sections 5.7 and 5.8 of my "Security Expectations for Internet Service Providers" draft ftp://ds.internic.net/internet-drafts/draft-ietf-grip-isp-02.txt and we've heard Paul plug ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-03.txt here many times. To answer Owen comments regarding the difficulty of filtering for transit providers, I argue that filtering should happen as close to the actual hosts as possible. Tom. -- Tom Killalea (425) 649-7417 NorthWestNet tomk@nwnet.net
In message <199801051756.JAA17924@cypress.nwnet.net>, Tom Killalea writes:
A regular reader of your mailing list forwarded this to me :
I will also point out that many of the recent "smurf" attacks and similar problems people are having on the net would be gone if people would just carefully filter internal/external addresses on their border machines, that is, prevent packets claiming to be from "inside" networks from coming in from the "outside", and prevent packets claiming to be from "outside" networks from going out from the "inside". The latter will stop your network from *ever* being the source of a wide variety of packet forgery attacks, and is necessary to being a good network citizen. The former will stop your network from being the subject of a wide variety fo packet forgery attacks, and is necessary to make your customers even remotely safe on the net.
There are two chances of 'upholding the address space integrity' of the Internet; assuming the current service model with Customer --> ISP ----> Internet Core The first one is on the IGP level, where the addresses assigned inside the network of the ISP is routed towards the customer. These addresses should be enforced on the interface between the ISP and the customer; and they frequently are. The major obstacle for this are scaling issues related to routing and filtering. I am network manager for a pretty much medium-sized ISP, with around 1700 internal network blocks; 600 of which come from dynamic sources. (RADIUS; variuos routing protocols). Given that a stock router will run out of filter lists long before the 600 mark I see major scaling problems here. (Outside of our network we show around 30 BGP network aggregates). This must be database driven, properly authenticicated, and fast enough to be able to track re-routing in the network. This technology does not exist, and will have to be designed, implemented on standard hardware and rolled out into production networks to get proper address integrity on the Internet. The second chance is between the ISP and the Internet Core. Here BGP is used for interaction, and the BGP aggregates should be nailed up. Filter lists to match these are relatively easy to generate, but it means that some core routers will evaluate filter lists for some 10-100 megabits of traffic. Current routers can do that up to the low two-digit megabits, so for a medium-sized ISP far outside of the US we can use this approach; but for the large players this is a non-starter.
I strongly recommend such filtering in sections 5.7 and 5.8 of my "Security Expectations for Internet Service Providers" draft ftp://ds.internic.net/internet-drafts/draft-ietf-grip-isp-02.txt and we've heard Paul plug ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-03.txt here many times.
To answer Owen comments regarding the difficulty of filtering for transit providers, I argue that filtering should happen as close to the actual hosts as possible.
Tom. -- Tom Killalea (425) 649-7417 NorthWestNet tomk@nwnet.net
-- ___ === / / / __ ___ _/_ === Morten Reistad, Network Manager === /--- / / / / /__/ / === EUnet Norway AS, Sandakerveien 64, Oslo === /___ /__/ / / /__ / === <Morten.Reistad@Norway.EU.net> === Connecting Europe since 1982 === phone +47 2209 2940
On Wed, 7 Jan 1998, Morten Reistad wrote:
I am network manager for a pretty much medium-sized ISP, with around 1700 internal network blocks; 600 of which come from dynamic sources. (RADIUS; variuos routing protocols). Given that a stock router will run out of filter lists long before the 600 mark I see major scaling problems here. (Outside of our network we show around 30 BGP network
You need to do this as close to the edge as possible. Do you have routers with 600 customer links directly connected? If you did, then it might only be feasible to require that your customers filter their traffic such that they cannot send bogus source traffic to you...and have stiff penalties in their service contracts for failure to maintain such filters. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
In message <Pine.LNX.3.95.980107222357.167l-100000@inorganic5.fdt.net>, Jon Lewis writes:
On Wed, 7 Jan 1998, Morten Reistad wrote:
I am network manager for a pretty much medium-sized ISP, with around 1700 internal network blocks; 600 of which come from dynamic sources. (RADIUS; variuos routing protocols). Given that a stock router will run out of filter lists long before the 600 mark I see major scaling problems here. (Outside of our network we show around 30 BGP network
You need to do this as close to the edge as possible. Do you have routers with 600 customer links directly connected? If you did, then it might only be feasible to require that your customers filter their traffic such that they cannot send bogus source traffic to you...and have stiff penalties in their service contracts for failure to maintain such filters.
We have routers with ISDP PRI links, where the routing information arrives from RADIUS via a CHAP login. There are 600 routed objects in the RADIUS database, as well as 10k+ non-routed (dynamic IP) objects. Every ISDN router therefore has a potential 600 directly attached neighbors; although no router has more than 60 links at any one time. Some common equipment may handle this just barely; other is wholly inadequate. We DO filter on the other edge too, (towards peering partners). We currently have approx 10 megabit worth of external traffic in two locations; and filtering works. I doubt we can do this with 10 times this traffic. Because of this filtering spoofing will be between clients that have a contractual relationship with us; and we can easily go after them in the judicial system; and we have this covered in the contracts. All routers we ship have anti- spoofing filterlists configured too, but we only have such a relation to around half of our customers. My point is that both approaches have huge scaling problems; easily evident for a medium-size ISP. (Although we are part of EUnet International the national operations are pretty autonomous). If things are this evident for us, it must be a nightmare for the bigger ISP's with lots more routed objects. I would appreciate some thought on how to address this issue on a bigger scale.
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
-- ___ === / / / __ ___ _/_ === Morten Reistad, Network Manager === /--- / / / / /__/ / === EUnet Norway AS, Sandakerveien 64, Oslo === /___ /__/ / / /__ / === <Morten.Reistad@Norway.EU.net> === Connecting Europe since 1982 === phone +47 2209 2940
On Thu, 8 Jan 1998, Morten Reistad wrote:
We have routers with ISDP PRI links, where the routing information arrives from RADIUS via a CHAP login. There are 600 routed objects in the RADIUS database, as well as 10k+ non-routed (dynamic IP) objects. Every ISDN router therefore has a potential 600 directly attached neighbors; although no router has more than 60 links at any one time. Some common equipment may handle this just barely; other is wholly inadequate.
So if you only have 60 links at a time, it can probably handle 60 really short access-lists. The trick is how to create appropriate filter lists on the fly. People have been requesting "automatic" filters where the access-server unless overridden creates a filter based on the routes it has for a particular interface. Hopefully, they're actually working on this...or at least thinking about it. As an "it's better than nothing" solution, unless you have too many network blocks, you can at least put in your various routers filter lists that allow forwarding of all possibly valid source addresses, but block absolutely bogus ones (i.e. source addresses from networks that are not yours). This would allow some level of spoofing within your own network, but protect the rest of the world. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
I collect some spammer accountibng here; and I saw a lot of spam been sent from UUnet's, MCI's and Sprint's dialup addresses to some mail-relays. If someone want to get this collected spam messages, I can do it for him in near future. PS. Don't kill anyone, but investigate him and poisone him to the half-live state -:). It's the best idea I know... But I don't think it's the best place for the such discussions. On Tue, 30 Dec 1997, Adam Rothschild wrote:
Date: Tue, 30 Dec 1997 19:42:07 -0500 From: Adam Rothschild <asr@millburn.net> To: nanog@merit.edu Subject: Attack of the Killer Spam
NANOG folk:
Over the past few weeks, I have noticed an influx of SPAM(tm) transmitted by UUNet dynamic IP dial-up users (read: MSN, Earthlink, GTE, etc.) and relayed using Earthlink SMTP relays. Am I turning senile prematurely, or has anyone else noticed this influx?
Also, how easy would it be for Earthlink and other nationwide "ISP's" (or more accurately, UU/PSI resellers) to do the following? This would not stop SPAM(tm) dead in its tracks, but I figure it would make it easier to hold spammers accountable at least... unless, of course, they use throw-away accounts, in which case there is not much that can be done...
- institute anti-spam rules on their SMTP relays, i.e. only relay mail reporting to be from earthlink.net and the virtual domains they host
- only allow SMTP relaying from IP's assigned to *their customers* dynamically (cross-reference Radius logs?)
And what would you get? It's not problem for any spammer to bye 100 dialup accounts around USA, and use (legally) all this UUnet's, MCI's etc mail relays...
Constructive feedback would be greatly appreciated! Together, we CAN make a difference.
Regards, Adam
participants (9)
-
Adam Rothschild -
Alex P. Rudnev -
Eric Osborne -
johnl＠iecc.com -
Jon Lewis -
Morten Reistad -
Perry E. Metzger -
Tom Killalea -
Wayne D. Correia