Thoughts & questions about responsibility for network traffic

Sun Dec 2 07:14:13 PST 2001

As those who have seen some of my ramblings & rants regarding email & spam
may recall, I tend to be borderline fascist (phrased charitably) with
respect to tolerance of obvious intent to abuse services such as email.

And when I try to report spam to postmaster@ a domain in question, I
tend to react rather negatively if said mail bounces.  Indeed, I read
RFCs 822 & 2821 to indicate that failure to accept such mail (with rare
exceptions granted in the more recent 2821) is a violation of the
specification (as well as intent) of the RFCs in question.  In such a
situation, when it has been clearly demonstrated to me that no one is
acting as being responsible for the email that emanates from the domain,
I tend to place an entry in sendmail's access.db, rejecting any attempt
from any machine in the domain to connect to the SMTP server I control,
with a message such as

	550 You need a postmaster to send mail

(Yes, there are problems with this approach:  primarily, it does not
provide a way for a site that has "seen the light" to redeem itself
automatically.  On the other hand, I also set up postmaster@ the domains
served by the SMTP server in question as accepting mail from anyone,
with a delay-check specification, so they shouldl be able to send mail
to postmaster@<my_domain> to mention that they've fixed the problem.  Of
course, that only addresses technical issues; human pride tends to be a
casualty in such an approach.)

I've carried this approach a bit further in a couple of ways:  the first
isn't directly applicable to the questions that come later, but ought to
be relevant for folks who subscribe to baylisa-jobs; the second starts
down what some folks make consider a "slippery slope," and things get a
little more interesting around there.

That baylisa-jobs application of the above is reasonably straightforward:
When someone tries to post to baylisa-jobs with obviously proscribed
content (typically, "here is our hotlist of available consultants" or
some such), I used to send a (reasonably) polite message back saying
something to the effect that "this isn't appropriate content for
baylisa-jobs; please read http://www.baylisa.org/lists for more
information on what is and is not appropruate for baylisa-jobs."

And I after failiing to get a single response that indicated a glimmer
of comprehension (over a period of a few months), I gave up, and decided
that the computer could do the job at least as effectively (and with
less hassle on my part).  Accordingly, I started placing entries in the
access.db for baylisa.org -- usually for the entire domain, but
sometimes just for specific users -- so that mail from the domain (or
user) and destined for @baylisa.org would be rejected with the message:

550 Read http://www.baylisa.org/lists and send apology to postmaster at baylisa.org

I did get one person who responded to that one (and we worked out the
problem); the far more general case is that the individuals in question
persist in blindly trying to spam baylisa-jobs at baylisa.org, never
(apparently) caring that not only is their spam not being received here
(baylisa.org), but it's choking whatever system they are using to try to
inject the spam into the Internet.

At least it's no longer a baylisa.org problem at that point.  :-}

Now we start in the direction of a slippery slope:  when I report spam,
it is the case more often that not that one or more Web sites will be
"spamvertised".  Accordingly, I make an attempt to also report the abuse
in question to abuse@ the domain of the Web server, as well as the
listed contact(s) for the netblock in question (obtained via WHOIS
query).

Now, I realize that keeping WHOIS contact information current is often
not a high priority in many organizations.  On the other hand, I'm
sufficiently old-fashioned that I think that the concept of
"responsibility" is, and ought to be, still relevant to what happens on
the Internet (and elesewhere, but I digress).

Accordingly, if I cannot contact any contact for a given netblock (or if
the infamous "[no mailbox]" is listed for the contact), and I can't
determine a "parent netblock" with valid contact information, I also
place the netblock in sendmail's access.db, blocking further attempts to
send email from the netblock in question to the SMTP server(s) I control.

Of course, in these cases, the folks don't really care about SMTP
traffic; they do HTTP{,S}....  And I've thought about blocking HTTP{,S}
traffic to their netblocks from mine, but have yet to implement it
(well, mostly).

Mind you, these aren't things I do especially lightly:  the purpose of
the Internet is to foster communication.  It is *not*, however, to
foster abuse.

Which brings me to something related to all of this....  A while back,
there was a vulnerability found with the SSH-1 protocol, and an exploit
for a weakness in (as I recall) the CRC-32 calculations was unleashed.
More recently, I've seen some traffic (on FreeBSD-related lists) about a
purported "weakness" in SSH; some traffic suggests that it's merely a
revisiting of the old weakness, while other traffic suggests something
else (but unspecified).

Meanwhile, I get the summaries of denied traffic not only from my own
home firewall, but from my mother's.  And when I see patterns of
attempts, that arouses some awareness.  For example:

Dec  1 01:09:16 janus /kernel: ipfw: 20000 Deny TCP 64.45.27.101:22 63.193.123.122:22 in via dc0
Dec  1 01:09:42 ns /kernel: ipfw: 3000 Deny TCP 64.45.27.101:22 63.195.89.198:22 in via ed0
Dec  1 01:23:57 janus /kernel: ipfw: 20000 Deny TCP 64.45.60.83:22 63.193.123.122:22 in via dc0
Dec  1 01:24:43 ns /kernel: ipfw: 3000 Deny TCP 64.45.60.83:22 63.195.89.198:22 in via ed0
Dec  1 11:30:21 janus /kernel: ipfw: 20000 Deny TCP 213.15.136.51:22 63.193.123.122:22 in via dc0
Dec  1 11:31:01 ns /kernel: ipfw: 3000 Deny TCP 213.15.136.51:22 63.195.89.198:22 in via ed0

("janus" is my firewall; "ns" is my mother's.  Each is on Pac*Bell
residential DSL, with a grandfathered static IP address.)

The first 4 entries were all from the same netblock (2 addresses).
Yesterday, I sent a message to the listed WHOIS contact for that
netblock, explaining that I had no reason to believe that any harm had
come of this, but on the other hand, there was no legitimate reason for
the attempt, either, and it was quite unwelcome.  I further mentioned
that the attempt may indicate that one or more systems on the netblock
were compromised.

I received a bounce-o-gram for my efforts.

This morning, I sent a message off to the listed WHOIS (RIPE) contact
for the 3rd pair of probes, with similar content.  I (also) received a
bounce-o-gram in response to that message.

So at this point, I'm wondering if it might be appropriate to consider
blocking access from the netblocks in question -- not just to the SMTP
server, but at the firewall, with an ICMP "administratively prohibited"
response.  It may reasonably be considered that this is a rather extreme
response; on the other hand, I believe that we need a bit more
responsibility in the Internet.

Also, there is certainly no "one size fits all" response for this:
what is acceptable for the personal networks in question may well be
inappropriate for certain other networks... or so I would expect.
So I suppose the question turns out to be "under what circumstances
would blocking all traffic from a given netblock be appropriate?"  For
some folks, I expect that the answer would be "Never!  The very thought
is anathema!" and for others, responses are more likely varied.

So I'm interested in what my colleagues think about this.

Cheers,
david (resume at http://www.catwhisker.org/~david/resume.ps)
-- 
David H. Wolfskill				david at catwhisker.org
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.