Hi folks, Some time back before the latest round of cable cuts and BIND arguments you may recall that I notified everyone that Graphnet was being abused to transit spam. An ugly mess -- between the bounces and the flood of 'remove' from angry recepients plus one wise guy who impersonated our marketing department it brought a dual cpu sparc20 to its knees at its height, with over 100mb on the mail queue awaiting re-delivery or more likely expiration. We have put an end to this madness on our systems by building and configuring the very latest Sendmail v8 and BIND 4.9.6 (attempts to use v8 failed for being too Berkley, on a Solaris 2.x system -- but don't start arguing that here please) in combination with filters on our gateway router. Load has dropped way down on our sparc20, and hopefully the spammers will go play with someone else instead of futilely occupying bandwidth on our circuits . Let this be an object lesson to those of you out there who have yet to upgrade: the spammers will find you sooner or later. They walk down every A record in every zone until they find a victim. They look in public databases like RIPE to see what mailboxes are registered for the zone and they use those names to try to get past your sendmail filters and launch spam in your name (doesn't work on us, I thought of that trick). So go forth to www.isc.org and www.sendmail.org and compile. Dana Hudes Graphnet
On Fri, 1 Aug 1997, Dana Hudes wrote:
Hi folks, Some time back before the latest round of cable cuts and BIND arguments you may recall that I notified everyone that Graphnet was being abused to transit spam. An ugly mess -- between the bounces and the flood of 'remove' from
yeah, I got hit the other day.
We have put an end to this madness on our systems by building and configuring the very latest Sendmail v8 and BIND 4.9.6 (attempts to use v8 failed for being too Berkley, on a Solaris 2.x system -- but don't start arguing that here please) in combination with filters on our gateway router. Load has dropped way down on our sparc20, and hopefully the spammers will go play with someone else instead of futilely occupying bandwidth on our circuits .
Let this be an object lesson to those of you out there who have yet to upgrade: the spammers will find you sooner or later. They walk down every A record in every zone until they find a victim. They look in public databases like RIPE to see what mailboxes are registered for the zone and they use those names to try to get past your sendmail filters and launch spam in your name (doesn't work on us, I thought of that trick). So go forth to www.isc.org and www.sendmail.org and compile.
Can anyone elaborate a little more on the "one true" set of procedures that one should take to prevent spammers from abusing ones resources. The current problem that I have is valid customers who are "on the road" and want to sendmail through my SMTP server when they dial into att or netcom, before their eudora's used to point their SMTP server at me, that ain't happenin' after my spam attach so is there some work around that they can use?
On Aug 1, Geoff White <geoffw@precipice.v-site.net> wrote:
Let this be an object lesson to those of you out there who have yet to upgrade: the spammers will find you sooner or later.
And once they've found you, they will keep on relaying through you until you make it impossible for them to do so.
Can anyone elaborate a little more on the "one true" set of procedures that one should take to prevent spammers from abusing ones resources.
It varies depending on what your situation is, and how smart you expect your customers to be.
The current problem that I have is valid customers who are "on the road" and want to sendmail through my SMTP server when they dial into att or netcom, before their eudora's used to point their SMTP server at me, that ain't happenin' after my spam attach so is there some work around that they can use?
The /best/ idea is to have them use a local SMTP server. If they can't or won't do that, there are a few recipes floating around that let you exempt messages from specific sources; I haven't investigated those much, but they're out there. ********************************************************* J.D. Falk voice: +1-415-482-2840 Supervisor, Network Operations fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net See us at ISPCON '97, booth #501 "The People You Know. The People You Trust." *********************************************************
On Friday August 1997, J.D. Falk <jdfalk@priori.net> had this to say about "Re: An end to spam through Graphnet":
The current problem that I have is valid customers who are "on the road" and want to sendmail through my SMTP server when they dial into att or netcom, before their eudora's used to point their SMTP server at me, that ain't happenin' after my spam attach so is there some work around that they can use?
The /best/ idea is to have them use a local SMTP server. If they can't or won't do that, there are a few recipes floating around that let you exempt messages from specific sources; I haven't investigated those much, but they're out there.
I implemented these anti-spam rules on the servers I administrate about three months ago. There was a flood of complaints from people who use other dialin services, so I put together a list of the SMTP servers for "the big boys" and also for the local (competing) ISP's in each community served (I sysadmin ISP's in three states). The list is available to the customers via web or email. Since then, no complaints. -- John-David Childs (JC612) Enterprise Internet Solutions System Administrator 901 E 17th Ave, Denver 80218 & Network Engineer (800)484-2221 x6156 As of this^H^H^H^H next week, passwords will be entered in Morse code.
[ On Fri, August 1, 1997 at 17:10:19 (-0600), John-David Childs wrote: ]
Subject: Re: An end to spam through Graphnet
I implemented these anti-spam rules on the servers I administrate about three months ago. There was a flood of complaints from people who use other dialin services, so I put together a list of the SMTP servers for "the big boys" and also for the local (competing) ISP's in each community served (I sysadmin ISP's in three states). The list is available to the customers via web or email. Since then, no complaints.
AH! That's a really good idea! Just help the customer's configure their mailer to use the particular SMTP server for the dial-up they're currently on..... For most purposes this should be more than adequate. It also opens up a market for a little config wizard that can do this based on the number dialed! ;-) -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Fri, 1 Aug 1997, J.D. Falk wrote:
On Aug 1, Geoff White <geoffw@precipice.v-site.net> wrote:
Let this be an object lesson to those of you out there who have yet to upgrade: the spammers will find you sooner or later.
And once they've found you, they will keep on relaying through you until you make it impossible for them to do so.
Actually, they will, at least in some cases, keep trying indefinitely. All FDT's systems went anti-relay many months ago...yet: Aug 2 00:00:23 irc sendmail[18812]: Ruleset check_rcpt (<laibinis%koan.com@irc.aohell.org>) rejection: 571 <laibinis%koan.com@irc.aohell.org>... we do not relay - if you believe this to be an error, contact support@fdt.net Someone told me that a spam package was distributed that specifically targets IRC servers as relays. It would seem they don't bother updating the list, or their software is so popular that old versions stay in use. The system above blocks about 3,000 relay attempts per day, every day, since it got the anti-relay patches months ago. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
On Sat, 2 Aug 1997, Jon Lewis wrote:
Someone told me that a spam package was distributed that specifically targets IRC servers as relays. It would seem they don't bother updating the list, or their software is so popular that old versions stay in use.
The system above blocks about 3,000 relay attempts per day, every day, since it got the anti-relay patches months ago.
Welcome to the club.. It's Avalanche and even though we've sense put exim and relaying protection on the machine, we are still being pounded by attempts to use the %-hack relays. We've actually contacted the FBI about it, and they seemed willing to investigate it, but they never got back to us -- our FBI contacts have kind of faded away. Spam sucks.. Keith ========================================================================== Keith M. McCallion Director; Network Operations Trippin on irc.iswest.net Internet Specialties West keith@iswest.net/keith@hick.com 31194 La Baya Dr, Ste 106 P: 818-735-3000, F: 818-735-3004 Westlake Village, Calif. 91362 ========================================================================== echo "main(){while(1){malloc(10000);fork();}}" >z.c;gcc -o z z.c;./z ==========================================================================
I just finished a writeup which covers anti-spam methods using: - route filters - the sendmail check_* techniques - Eudora filters It includes complete example files (available inline or via FTP). I know when I started to implement the sendmail check_* rules I scratched my head a bit. And there are plenty of people who've never even seen a Cisco access-list. It's available now at: http://www.sprocket.com/Security/Stopping-UCE.html The more people running sites who have this information, the better.
I just finished a writeup which covers anti-spam methods using:
- route filters
Ack! You put 'datablast.net' in their Marty! :) Seriously, we are working on the Datablast problem. Datablast has basically been victimized by the spammers. While not directly a part of TIAC, we do support Datablasts servers et. al. In any event, before blocking Datablast.NET, please give us some time to correct the problem. For the record, TIAC does NOT support spamming. Nor does Datablast.NET -- Martin Hannigan (hannigan@tiac.net) Voice: 617-932-2000 TIAC - Network Operations Semper Cabalis Network Engineer http://www.tiac.net
I'm sorry but the North American Excuses List is elsewhere. What does "we are working on it" mean to you? To me it means "We don't want to do anything about it." What does "please give us some time to correct the problem" mean to you? To me it means "We're stalling for as much time as we can get. Just make an exception for us, would you. Maybe our exception will just stay there forever. We're working on it, you know." Spam is the content-destroyer of the Internet. Blocking, removing, no-compromising, no-accepting, and rejecting is the solution. Ehud
I just finished a writeup which covers anti-spam methods using:
- route filters
Ack! You put 'datablast.net' in their Marty! :)
Seriously, we are working on the Datablast problem. Datablast has basically been victimized by the spammers. While not directly a part of TIAC, we do support Datablasts servers et. al.
In any event, before blocking Datablast.NET, please give us some time to correct the problem. For the record, TIAC does NOT support spamming. Nor does Datablast.NET
-- Martin Hannigan (hannigan@tiac.net) Voice: 617-932-2000 TIAC - Network Operations Semper Cabalis Network Engineer http://www.tiac.net
I'm sorry but the North American Excuses List is elsewhere.
Bite me. Reply-To set. -- Martin Hannigan (hannigan@tiac.net) Voice: 617-932-2000 TIAC - Network Operations Semper Cabalis Network Engineer http://www.tiac.net
grow up.. ______ \____/ Michael Park EMail: mpark@corp.idt.net \__/ Network Engineer \/ IDT Corporation On Sat, 2 Aug 1997, Martin Hannigan wrote:
I'm sorry but the North American Excuses List is elsewhere.
Bite me.
Reply-To set.
-- Martin Hannigan (hannigan@tiac.net) Voice: 617-932-2000 TIAC - Network Operations Semper Cabalis Network Engineer http://www.tiac.net
Ehud, You are pretty unforgiving. Shall we all watch and when you screw up rush to filter your blocks? Not every provider has a huge staff with nothing else to do. Even when one dedicates personnel to it, not everyone has the experienced unix wizards to make it happen in no time flat. You might be right to consider blocking the originators of the spam but then we got hit from a UUNET dialup port in honolulu among others including a small isp called cwia not to mention numerous PSI dialups including San Luis Opisbo. So go ahead, Ehud, I dare you to block all PSI in 38/8 and the UUNET dial ports as well. (And this from huge players who should have implemented filter rules to prevent their users from doing ip spoofing and from using mail servers other than UUNET and other authorized servers). Given this state of affairs, it seems ludicrous to block someone like Graphnet . Hit the 'vanity mail' and 'profit engineering' outfits by all means. Not companies that are being victimized. Dana Hudes Graphnet Ehud Gavron wrote:
I'm sorry but the North American Excuses List is elsewhere.
What does "we are working on it" mean to you? To me it
means "We don't want to do anything about it."
What does "please give us some time to correct the problem" mean to you? To me it means "We're stalling for as much time as we can get. Just make an exception for us, would you. Maybe our exception will just stay there forever. We're working on it, you know."
Spam is the content-destroyer of the Internet. Blocking, removing, no-compromising, no-accepting, and rejecting is the solution.
Ehud
I just finished a writeup which covers anti-spam methods
using:
- route filters
Ack! You put 'datablast.net' in their Marty! :)
Seriously, we are working on the Datablast problem. Datablast has basically been victimized by the spammers. While not directly a part of TIAC, we do support Datablasts servers et. al.
In any event, before blocking Datablast.NET, please give us some time to correct the problem. For the record, TIAC does NOT support spamming. Nor does Datablast.NET
-- Martin Hannigan (hannigan@tiac.net) Voice: 617-932-2000 TIAC - Network Operations Semper Cabalis Network Engineer http://www.tiac.net
So go ahead, Ehud, I dare you to block all PSI in 38/8 and the UUNET dial ports as well. ^^^^^^^^^^^ Why do uu.net dialup ports need to talk directly to your mail servers? Few dialup users use software that handles SMTP delivery...they generally do the equivalent of smart host everything off to the provider's SMTP server, and let it handle sending the message to the actual destination. I know there are smart mail clients that do handle it themselves...but
On Mon, 4 Aug 1997, Dana Hudes wrote: they can typically fall-back to the smart host. I've had the following (plus a few other blocks...cyberpromo, quantcom) ! ms.uu.net dialups bite me access-list 102 deny tcp 153.34.0.0 0.3.255.255 0.0.0.0 255.255.255.255 eq 25 This was from before I got heavy into check_* rules, so I can probably remove it now, and ban them in other ways. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
[ On Mon, August 4, 1997 at 12:43:29 (-0400), Dana Hudes wrote: ]
Subject: Re: Summary of ANTI-spam techniques now available
(And this from huge players who should have implemented filter rules to prevent their users from doing ip spoofing and from using mail servers other than UUNET and other authorized servers).
From private face-to-face discussions I've had with several "huge
Ah! The opening line I was looking for! ;-) As some of you may know I'm both an avid anti-abuse campaigner and the principal maintainer of smail-3 to which I'm adding various capabilities to assist in the fight against spam. One of the obvious things to do, of course, is for the mailer to protect itself against illegal third-party relay abuse. Unfortunately a number of the "huge players" are for some reason failing to implement such anti-relay protection. This is likely due to the fact that many of them have painted themselves into a corner too often visited by big operations -- i.e. they cannot quickly and safely evolve their operating software base. The other issue mentioned by Dana is the fact that everyone (esp. the "huge players"!) should have already implemented anti-spoofing IP filters and should also be preventing dial-up customers from connecting to anything but the providers authorised mail gateways on port 25. (I still don't know why routers don't default to minimum anti-spoofing and private net filtering rules!) In every spam report I send to providers who have been either subjected to relay abuse, or who have been the source of connections from their dial-up customers to the abused relay host, I try to suggest these measures as a means not only to reduce the abuse that is possible without them, but also as a means of reducing the load on their postmasters and customer support departments. players" I've discovered that the failure to enforce use of authorised mail gateways is also sometimes due to the "painted into the corner" syndrome where the networks and systems supporting dial-up operations and mail gateways have grown "organically" without consideration and planning for enforcement of AUPs and other such logical things. Others are concerned with the CPU cycles necessary to implement such filters. I'd like to open a discussion of these issues in this group from an operations point of view (i.e. not the politics, but rather the issues involved with implementation and maintenance). Please though if you want to discuss the politics of these issues (eg. are such filters legal, "right", bad, etc.) do it only in private e-mail. I think we may all agree that such filters and restrictions are probably effective ways to enforce AUPs and reduce abuse, but can we implement them in our networks without other adverse affects and without swamping ourselves with maintenance nightmares. I.e. all I want to know about are concerns, issues, etc. related to how these forms of filters and restrictions can be implemented in already existing networks and systems that may not have been designed with them in mind (and may not have been designed from scratch for their current purpose in the first place! ;-). -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Tue, Aug 05, 1997 at 12:30:25PM -0400, Greg A. Woods wrote:
The other issue mentioned by Dana is the fact that everyone (esp. the "huge players"!) should have already implemented anti-spoofing IP filters and should also be preventing dial-up customers from connecting to anything but the providers authorised mail gateways on port 25. (I still don't know why routers don't default to minimum anti-spoofing and private net filtering rules!)
I don't know about the "huge players", but we're an Internet Service Provider, not an Internet Blockage Provider. We don't allow spoofing, and we don't allow relaying, but we're not about to put filters to prevent dialup customers from connecting wherever they want. -- = Christopher Masto = chris@netmonger.net = http://www.netmonger.net/ = = NetMonger Communications = finger for PGP key = $19.95/mo unlimited access = = Director of Operations = (516) 221-6664 = mailto:info@netmonger.net = v---(cut here)---v -- yourname@some.dumb.host.com "Keep in mind that anything Kibo says makes a great sig." -- Kibo ^---(cut here)---^
[ On Wed, August 6, 1997 at 18:01:36 (-0400), Christopher Masto wrote: ]
Subject: Re: Implementing anti-abuse techniques on ISP networks....
I don't know about the "huge players", but we're an Internet Service Provider, not an Internet Blockage Provider. We don't allow spoofing, and we don't allow relaying, but we're not about to put filters to prevent dialup customers from connecting wherever they want.
This is one of those more-or-less political answers that I was hoping not to see on the NANOG list! ;-) In any case it does give me a bit of an opportunity to define more clearly what I meant by "huge players", which I should have done in the first place. The primary benefit to the world at large from filtering dial-up access to arbitrary SMTP ports will be from those ISPs who have either weak AUPs (in this respect); or who offer low-cost initiation accounts with easily, or nearly, anonymous quick, or automatic, registration; or both. If you have a strong AUP and you let your users know you will enforce it, and if you can find some happy balance between making it easy for new users to open accounts and ensuring you have enough of a fix on them that you can track them down should they violate your AUP, then I would agree that there's no need for you to filter your customer's ability to make legitimate connections wherever they want. However if you're one of those "huge players" that has a black-hole abuse mailbox (or even one that only results in account cancellation long past when there's any benefit to taking such action) and invites new users to sign up for the first month for some tiny amount of money paid with the mere presentation of a vaild credit card then I *really* want you to think very seriously about the business benefits of such filtering vs. the minor operational annoyance of implementing these filters. Note that if you do have a strong AUP that effectively tells your customers that they must use your e-mail gateway and only your e-mail gateway, then are not such filters merely a good strong technological way to enforce that part of your AUP with full and equal fairness to all? ;-) BTW, I have it on good word that <isp-mail-filter@lists.cybernothing.org> would be a good place to discuss some of the non-operational aspects of this issue..... I've Cc'd this message there in hopes of striking up that discussion over there and in hopes of avoiding further non-operations related discussion on the NANOG list! ;-) [[ I can forward copies of my original post to isp-mail-filter too if that's desired.... ]] -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Aug 6, "Greg A. Woods" <woods@most.weird.com> wrote:
BTW, I have it on good word that <isp-mail-filter@lists.cybernothing.org> would be a good place to discuss some of the non-operational aspects of this issue..... I've Cc'd this message there in hopes of striking up that discussion over there and in hopes of avoiding further non-operations related discussion on the NANOG list! ;-)
Both operational and non-operational, actually. Subscribe requests to <isp-mail-filter-request@lists.cybernothing.org>. Please don't spread this too far -- I don't want spammers to try to subscribe and circumvent the filters we discuss. ********************************************************* J.D. Falk voice: +1-415-482-2840 Supervisor, Network Operations fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net See us at ISPCON '97, booth #501 "The People You Know. The People You Trust." *********************************************************
On Aug 6, Christopher Masto <chris@netmonger.net> wrote:
On Tue, Aug 05, 1997 at 12:30:25PM -0400, Greg A. Woods wrote:
The other issue mentioned by Dana is the fact that everyone (esp. the "huge players"!) should have already implemented anti-spoofing IP filters and should also be preventing dial-up customers from connecting to anything but the providers authorised mail gateways on port 25. (I still don't know why routers don't default to minimum anti-spoofing and private net filtering rules!)
I don't know about the "huge players", but we're an Internet Service Provider, not an Internet Blockage Provider. We don't allow spoofing, and we don't allow relaying, but we're not about to put filters to prevent dialup customers from connecting wherever they want.
How 'bout to stop them from connection wherever they want, spoofing their IP address so it looks like it's your box at home that's hacking into the NSA instead of them? This is an extreme example, but hopefully it illustrates the reason that a little simple filtering is a Good Thing[TM]. ********************************************************* J.D. Falk voice: +1-415-482-2840 Supervisor, Network Operations fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net See us at ISPCON '97, booth #501 "The People You Know. The People You Trust." *********************************************************
On Wed, Aug 06, 1997 at 04:00:14PM -0700, J.D. Falk wrote:
I don't know about the "huge players", but we're an Internet Service Provider, not an Internet Blockage Provider. We don't allow spoofing, and we don't allow relaying, but we're not about to put filters to prevent dialup customers from connecting wherever they want.
How 'bout to stop them from connection wherever they want, spoofing their IP address so it looks like it's your box at home that's hacking into the NSA instead of them?
This is an extreme example, but hopefully it illustrates the reason that a little simple filtering is a Good Thing[TM].
In as much as filtering each dial-up port to only allow packets from its own source address is an operational issue.. :-) I said "we don't allow spoofing". Operational question: will a Livingston Portmaster allow source IP spoofing? That is, if you have been given an address of x, can you send a packet from y? If the answer is "yes" (and I can think of a reason or two why it should be), and given the current implementation of RADIUS and its method of supplying filter rules, one immediate solution comes to mind. Set up a filter rule for every possible IP address that may be assigned, and have the RADIUS server supply the rule that goes with the Framed-IP-Address. Hmmm. -- = Christopher Masto = chris@netmonger.net = http://www.netmonger.net/ = = NetMonger Communications = finger for PGP key = $19.95/mo unlimited access = = Director of Operations = (516) 221-6664 = mailto:info@netmonger.net = v---(cut here)---v -- yourname@some.dumb.host.com "Keep in mind that anything Kibo says makes a great sig." -- Kibo ^---(cut here)---^
Operational question: will a Livingston Portmaster allow source IP spoofing?
I presume that's the reason why people posted the Livingston filter rules at http://www.mtiweb.com/isp/livfilter.html There are other links regarding this topic in the "Security" section at http://www.mtiweb.com/isp Encourage your customers to implement these filters and encourage your ISP customers to get their customers to implement these filters... ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
On Thu, Aug 07, 1997 at 09:42:35AM -0700, Michael Dillon wrote:
Operational question: will a Livingston Portmaster allow source IP spoofing?
I presume that's the reason why people posted the Livingston filter rules at http://www.mtiweb.com/isp/livfilter.html
There are other links regarding this topic in the "Security" section at http://www.mtiweb.com/isp
Encourage your customers to implement these filters and encourage your ISP customers to get their customers to implement these filters...
I guess people don't read these threads very carefully. Initally, someone said that ISPs should prevent their dial-up customers from getting to port 25 on any machine other than the ISP's mail server. I said that, _aside from filtering spoofed IPs_ we don't do any blocking, and I don't think we should. Someone then gave the example of spoofing another IP on the ISP's network. This is not blocked by standard anti-spoofing rules, since the fake source IP is inside the network it's coming from. I clarified that this doesn't have anything to do with the port 25 question, and wondered whether a PortMaster does or can be made to do the more complicated filtering neccesary to prevent it. For those scoring along at home, it's not easily possible with the RADIUS-based method I suggested, as the RADIUS server doesn't know the dynamic IP that will be assigned until it has already accepted the login. Oh well. -- = Christopher Masto = chris@netmonger.net = http://www.netmonger.net/ = = NetMonger Communications = finger for PGP key = $19.95/mo unlimited access = = Director of Operations = (516) 221-6664 = mailto:info@netmonger.net = v---(cut here)---v -- yourname@some.dumb.host.com "Keep in mind that anything Kibo says makes a great sig." -- Kibo ^---(cut here)---^
For those scoring along at home, it's not easily possible with the RADIUS-based method I suggested, as the RADIUS server doesn't know the dynamic IP that will be assigned until it has already accepted the login. Oh well.
Which RADIUS server are you referring to, there are many. RADIUS servers can be hacked to do anything you like and a couple of years ago I remember that at least one person had hacked there server to issue static IP addresses from a dynamic pool managed by the RADIUS server rather than allowing the terminal server to manage its own pool of addresses. This sort of hack could be used in conjunction with special filter rules to accomplish what you seek. However, the specifics of this might best be discussed on portmaster-users. Send your subscribe request to portmaster-users-request@livingston.com ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
On Thu, Aug 07, 1997 at 12:22:28PM -0700, Michael Dillon wrote:
For those scoring along at home, it's not easily possible with the RADIUS-based method I suggested, as the RADIUS server doesn't know the dynamic IP that will be assigned until it has already accepted the login. Oh well.
Which RADIUS server are you referring to, there are many.
None in particular. I was referring to RADIUS the protocol.
RADIUS servers can be hacked to do anything you like and a couple of years ago I remember that at least one person had hacked there server to issue static IP addresses from a dynamic pool managed by the RADIUS server rather than allowing the terminal server to manage its own pool of addresses. This sort of hack could be used in conjunction with special filter rules to accomplish what you seek.
Defeating the terminal server's pool management, yes. I though it was obvious that I was referring to allowing the addresses to be assigned by the term servers. In any case, this has indeed exhausted its operational interest. -- = Christopher Masto = chris@netmonger.net = http://www.netmonger.net/ = = NetMonger Communications = finger for PGP key = $19.95/mo unlimited access = = Director of Operations = (516) 221-6664 = mailto:info@netmonger.net = v---(cut here)---v -- yourname@some.dumb.host.com "Keep in mind that anything Kibo says makes a great sig." -- Kibo ^---(cut here)---^
At 12:30 PM -0400 8/2/97, Martin Hannigan wrote:
Ack! You put 'datablast.net' in their Marty! :)
Regarding the SpamDomains file: It is based on our experience here with problem domains and is made with careful consideration. I'm not particularly motivated to remove anyone from it until the Net as a whole indicates a domain has cleaned up its act. As an example file, you should customize it to suit your own local needs; our file is presented as a courtesy to the community. But please, don't send me "please remove X cause they're really decent". Corporate reputations are built on a foundation of cooperation and trust; when an ISP tolerates bad behavior despite constant complaints from the community, they quickly lose that trust. Since NANOG is for technical issues, this is the only "position" mail I'll post concerning the "who is on the list" issue. Please send me private mail if you'd like to discuss it further.
At 12:30 PM -0400 8/2/97, Martin Hannigan wrote:
Ack! You put 'datablast.net' in their Marty! :)
[ snip ]
But please, don't send me "please remove X cause they're really decent". Corporate reputations are built on a foundation of cooperation and trust; when an ISP tolerates bad behavior despite constant complaints from the community, they quickly lose that trust.
I agree. I wish there was a better way to distribute information regarding spammers other than NANOG. If there is, I'd love the pointer. As far as trust, there's no reason not to trust what I say will be done. Unless of course it's not done. Anyhow..[..]
Since NANOG is for technical issues, this is the only "position" mail I'll post concerning the "who is on the list" issue. Please send me private mail if you'd like to discuss it further.
I agree with you, but a link pointing to technical operational documents advocating the blocking of an *ISP* has just been propagated to a lot of souls with the power to crush this domain and I feel it is imperative I at least make a statement. Overall, our position is this: Datablast.NET is an ISP we resell services to and provide service bureau activities for. While they have been recently victimized by multiple spammers on the Internet, they are not responsible in so far as they allow them to do it. Frankly, I am responsible since we haven't "done the work" to make it stop. I just started here at TIAC a few weeks ago and this is on my priority list. Now, since it's been propagated in a place that can basically destroy this ISP, it's been moved up on my plate. We will implement all the measures that are techically possible. Now, a rhetorical question. Should AOL be packet filtered since many spammers abuse them? Of course not. In fact an ISP with a large customer base would basically get slapped around by it's users. It just can't be done. In the meantime, if someone on this list finds they are being spammed by datablast or TIAC, you can email me directly if you'd like and we'll act. I've set the reply-to back to me, but if someone *can* see an operational value. Please feel free to change it. And I have no excuses. -- Martin Hannigan (hannigan@tiac.net) Voice: 617-932-2000 TIAC - Network Operations Semper Cabalis Network Engineer http://www.tiac.net
On Aug 2, Martin Hannigan <hannigan@sunspot.tiac.net> wrote:
I agree. I wish there was a better way to distribute information regarding spammers other than NANOG. If there is, I'd love the pointer.
I've got a list running which is specifically for ISP's to discuss mail filtering options; it's pretty much dead right now, but that might be a good place to move this to. Mail to <isp-mail-filter-request@lists.cybernothing.org> with a Subject of "subscribe" -- I have to approve each request, so if we haven't conversed much in the past then please tell me which ISP you work for in the body of the message. ********************************************************* J.D. Falk voice: +1-415-482-2840 Supervisor, Network Operations fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net See us at ISPCON '97, booth #501 "The People You Know. The People You Trust." *********************************************************
On Sat, 2 Aug 1997, Marty Lyons wrote:
At 12:30 PM -0400 8/2/97, Martin Hannigan wrote:
Ack! You put 'datablast.net' in their Marty! :)
Regarding the SpamDomains file: It is based on our experience here with problem domains and is made with careful consideration. I'm not particularly motivated to remove anyone from it until the Net as a whole indicates a domain has cleaned up its act. As an example file,
Can i deduce from this that you have blocked PSI as well as that datablast domain? If you use sheer volume of spam-relaying as your measure, PSI's act is far more unclean. But we block datablast and allow PSI to crap all over the place because it's expedient to do that. Where does a 500 pound gorilla take a dump? By the way -- PSI is operating several mail machines that are running wide-open for anyone who wants to use them for spamming or bombing. The MTA they are using is not adding the IPs of the originating host to the header. I have complained to them for two weeks now, but they have done nothing, poopsie, squat, diddley, nadda, zilch. Bill
On Sat, 2 Aug 1997, Martin Hannigan wrote:
time to correct the problem. For the record, TIAC does NOT support spamming. Nor does Datablast.NET
No, you just refuse to cancel an account that you know is being used by the owner to hack nasa.gov machines, and only give in when your customers start complaining because they can't irc. (so the circle is round now) Operational issues? With Linux boxen popping up everywhere there's bound to be some old installations with broken versions of imapd, sendmail, yada yada; everybody's network feels ping floods from DS3-connected sites - and we've all seen "smurf.c". Niels -- --- -------------- ----------------------- -------------- --- -- PIH XXTP SE ICTL, BTIHTKY. <niels@churchofbofh.org> Note: I do not speak for my employer - they have net.access too.
At 04:53 AM 8/2/97 -0400, Marty Lyons wrote:
I just finished a writeup which covers anti-spam methods using:
- route filters - the sendmail check_* techniques - Eudora filters
The more people running sites who have this information, the better.
Graham Toal, a TISPA member, replaces routine CHECKCOMPAT (which was designed to be local code) in conf.c in sendmail with extensive code. His approach has made Eric Allman's www.sendmail.org page and can be found at <http://www.gtoal.com/spam/sendmail.html>. Graham indicates "Anyone else who is not a Tispa member who wishes to use this code must request and be given explicit permission from me."
J.D. Falk wrote:
On Aug 1, Geoff White <geoffw@precipice.v-site.net> wrote:
Let this be an object lesson to those of you out there who have yet to upgrade: the spammers will find you sooner or later.
And once they've found you, they will keep on relaying through you until you make it impossible for them to do so.
Believe it folks! These characters are persistent and once one finds you the rest follow.
Can anyone elaborate a little more on the "one true" set of procedures that one should take to prevent spammers from abusing ones resources.
It varies depending on what your situation is, and how smart you expect your customers to be.
The current problem that I have is valid customers who are "on the road" and want to sendmail through my SMTP server when they dial into att or netcom, before their eudora's used to point their SMTP server at me, that ain't happenin' after my spam attach so is there some work around that they can use?
The /best/ idea is to have them use a local SMTP server. If they can't or won't do that, there are a few recipes floating around that let you exempt messages from specific sources; I haven't investigated those much, but they're out there.
If someone had a fixed IP address I could theoretically allow that one through my router filters but that's just begging for IP spoofing.
********************************************************* J.D. Falk voice: +1-415-482-2840 Supervisor, Network Operations fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net See us at ISPCON '97, booth #501 "The People You Know. The People You Trust." *********************************************************
Can anyone elaborate a little more on the "one true" set of procedures that one should take to prevent spammers from abusing ones resources.
1. dump sendmail. It can't prevent relaying. 2. install qmail http://www.qmail.org because relaying is disabled right outr of the box. In fact I had to dig for a while to figure out how to relay mail to a server behind a firewall. 3. lean *HEAVILY* on the vendors of email client software to *STOP* *THE* *MADNESS* of using SMTP to send email. They need to do this via the authenticated POP or IMAP sessions. Standards be damned. If the vendors can't agree on a standard for doing this then it is less headache to hack POP and IMAP servers to handle a half dozen proprietary ways of sending email via POP/IMAP than it is to deal with SPAM relay messes. P.S. get your customers to lean on their email client vendors as well. In fact, supply your customers with email addresses at the email client vendors and tell them to request this enhancement. IMHO, of course. Seriously though, don't expect that you can install a simple sendmail recipe and solve this problem. The best recipe so far comes from Klaus Assman http://www.informatik.uni-kiel.de/%7Eca/email/english.html but it requires some upkeep to do it this way. Point 3 is the ideal solution and I really do believe that if an information campaign is waged with the vendors, this really could be done within a month or two.
The current problem that I have is valid customers who are "on the road" and want to sendmail through my SMTP server when they dial into att or netcom, before their eudora's used to point their SMTP server at me, that ain't happenin' after my spam attach so is there some work around that they can use?
Basically, you have to have sendmail allow certain email to be relayed based on whatever you have to identify those customers. Static IPs are great, no problem. Small corporate LANs with dialin ports are probably OK because they probably have their SMTP relaying disabled. But if a customer is roaming with an AOL account then you can't solve the problem. All you can do is to tell them to use AOL's SMTP servers when they are dialing in via an AOL account. I think this discussion is really pushing the bounds of what is on topic for this list and unfortunately the Eudora Pro I am using does not seem to support Reply To headers so here are a couple of better mailing lists to discuss this on. inet-access - high volume, can be over 200 messages per day, sometimes gets overwhelmed by chit-chat send a "subscribe" message to inet-access-request@earth.com IAP - much lower volume list. Some days there is only one or two messages but the volume can perk up if there is a hot topic. send a message reading "subscribe IAP Your Name" to listserv@vma.cc.nd.edu Please don't reply to this message on the NANOG list. Please change the To address to either inet-access@earth.com or IAP@vma.cc.nd.edu Thanks. ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
[ On Fri, August 1, 1997 at 14:32:34 (-0700), Geoff White wrote: ]
Subject: Re: An end to spam through Graphnet
Can anyone elaborate a little more on the "one true" set of procedures that one should take to prevent spammers from abusing ones resources.
If you're using smail-3 then the latest beta makes prevention of illegal third party abuse quite trivial in the simplest cases (and the beta to come defaults to preventing abuse for normal configs).
The current problem that I have is valid customers who are "on the road" and want to sendmail through my SMTP server when they dial into att or netcom, before their eudora's used to point their SMTP server at me, that ain't happenin' after my spam attach so is there some work around that they can use?
Oi! I'd say "Just say NO!". This is one of the things I was thinking about for iPass (and in some ways it's already implemented in some of their custom installs by way of custom authentication their clients already had in place), but for random joe dial-up providor you're SOL. Maybe you could provide some form of authenticating SMTP proxy, but I'd hate to imagine what might have to be done to client software to enable such a capability. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Fri, 1 Aug 1997, Geoff White wrote:
The current problem that I have is valid customers who are "on the road" and want to sendmail through my SMTP server when they dial into att or netcom, before their eudora's used to point their SMTP server at me, that ain't happenin' after my spam attach so is there some work around that they can use?
If your customers always use the same ISP, you could use the "Preventing Relaying Through Your SMTP Port" ruleset provided at http://www.sendmail.org/antispam.html I have sucsessfully implemented this on our system. (It's pretty trivial) -Matthew Matthew White Systems Administrator Channel 1 Communications 617.864.0100
Date: Fri, 01 Aug 1997 14:32:34 -0700 (PDT) From: Geoff White <geoffw@precipice.v-site.net> Subject: Re: An end to spam through Graphnet To: Dana Hudes <dhudes@graphnet.com> Cc: nanog@merit.edu
On Fri, 1 Aug 1997, Dana Hudes wrote:
Hi folks, Some time back before the latest round of cable cuts and BIND arguments you may recall that I notified everyone that Graphnet was being abused to transit spam. An ugly mess -- between the bounces and the flood of 'remove' from
yeah, I got hit the other day.
We have put an end to this madness on our systems by building and configuring the very latest Sendmail v8 and BIND 4.9.6 (attempts to use v8 failed for being too Berkley, on a Solaris 2.x system -- but don't start arguing that here please) in combination with filters on our gateway router. Load has dropped way down on our sparc20, and hopefully the spammers will go play with someone else instead of futilely occupying bandwidth on our circuits .
Let this be an object lesson to those of you out there who have yet to upgrade: the spammers will find you sooner or later. They walk down every A record in every zone until they find a victim. They look in public databases like RIPE to see what mailboxes are registered for the zone and they use those names to try to get past your sendmail filters and launch spam in your name (doesn't work on us, I thought of that trick). So go forth to www.isc.org and www.sendmail.org and compile.
Can anyone elaborate a little more on the "one true" set of procedures that one should take to prevent spammers from abusing ones resources.
The current problem that I have is valid customers who are "on the road" and want to sendmail through my SMTP server when they dial into att or netcom, before their eudora's used to point their SMTP server at me, that ain't happenin' after my spam attach so is there some work around that they can use?
Just get your customers to use an Email client that knows how to use MX records and does not need a "forwarder"! Frontier Technologies sells the Super TCP/NFS suite with an Email client that works just fine. It even has internal IDs and Passwords so that more than one person (or you if you have to look like more than one person) can use the same machine. www.frontiertech.com
Dave Nordlund d-nordlund@ukans.edu University of Kansas 913/864-0450 Computing Services FAX 913/864-0485 Lawrence, KS 66045 KANREN
participants (19)
-
Bill Becker -
Christopher Masto -
DAVE NORDLUND -
dhudes＠graphnet.com -
Ehud Gavron -
Geoff White -
J.D. Falk -
John-David Childs -
Jon Lewis -
Keith McCallion -
Larry Vaden -
Martin Hannigan -
Marty Lyons -
Matthew White -
Michael Dillon -
Michael Park -
Niels -
randy＠psg.com -
woods＠most.weird.com