An end to spam through Graphnet

[ 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! :wink:

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? :wink:

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! :wink:

[[ I can forward copies of my original post to isp-mail-filter too if
that's desired.... ]]

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].

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.

In as much as filtering each dial-up port to only allow packets from
its own source address is an operational issue.. :slight_smile: 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.

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.

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

>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.