You are not logged in. Login Now
 0-24   25-49   50-74   75-99   100-124   125-149   150-174   175-199   200-224 
 225-249   250-264         
 
Author Message
steve
Banning a site from Grex; a discussion of when to do this Mark Unseen   Nov 30 17:18 UTC 1998

   I have just done something that I've never done before on
Grex, which is to block an entire site from Grex.  I find this
sufficiently disturbing that I think we should talk about it
here in coop, as a matter of policy.

   I'll say right here that I sincerely hope that this is not
a permenent solution, and perhaps the readers of coop will have
some ideas about this, in general.

   This site in question is a technical school in India; I don't
think the exact name of it is relevant, but if people want I'll
say it.  This site has been the source of four fork bomb attacks
that I know of in the last three months.  There are a great many
users from this site during Asian awake hours, and unforunately,
their IP address has become more and more noticed, every time I
sent out mail asking that graphical files not be downloaded, or
responding to a harassment request, etc. [Aftword: at least four
fork bombs--there could have been more (sfa)]

   The fork bomb incidents are what bother me the most, and have
crippled Grex during those periods.  Just today, Monday 11/30 when
I checked the system I saw a load average of 77 (ten times higher
than normal) and it was yet another fork bomb from this particular
site.  This particular bomb ran for approximately 1:40, from 10AM
to 11.40AM.

   Normally, when staff finds something like this, staff will
first kill the bomb (or reboot if truely nasty) then disable
the particular tool, then contact the site's administrators where
the vandal came from to tell them about this.

   This particular site is different, in that this is a gateway
of some kind, and I've yet been able to get a response from whom
I believe are the administrators of the site.  Further, in eight
requests from various people from this site about a contact email
address, only one was willing to give me something--the others
refused.  I found that unusual.

   I have never seen this behavior before.  ANY site with a large
number of people coming in from it is going to have problems,
obviously.  At each UM football game there are nn people arrested,
nn people with heart attacks, etc.  Bad things happen with any
clump of people.  But in this particular case, there are incidents
that hurt Grex--the fork bombs--and I can't get a response from
the people who maintain the site, the site doesn't offer 'ident'
information so we can't know who is who from that address, and
given the number of fork bombs (and importation of other various
vandal tools), I'd have to say that the good-to-vandal ratio
from this site is far lower than others.  Please believe me when
I say I am distressed to say this.

   Obviously, we will try to contact the site administrators further
and we will succeed, eventually.  But I'd like feedback from the
community about the action taken here.  Before I did this I talked
to one other staffer, who agreed that blocking was a reasonable
measure in the short term.

   I'm beginning to think Grex needs a new position, one of
"Grex ambassador", someone who is able to talk to staff about
technical issues, but whose main job is to contact other sites
about problems, and let that be their main task for Grex.  Still,
it doesn't solve the immediate problem of what to do, right now.

   I have never done this before.  I've never felt the need to.
But given the impact of a fork bomb (and remember, its affects
go on, after it stops, as mail then floods in that couldn't before)
I think I am acting in Grex's best interest.

   Ideas would be welcome.
264 responses total.
steve
response 1 of 264: Mark Unseen   Nov 30 17:52 UTC 1998

   I've just sent yet another piece of mail off to the site.
mta
response 2 of 264: Mark Unseen   Nov 30 18:13 UTC 1998

I dunnoe, Steve -- it doesn't sound there was much else you could have done
in the short term...

I think the idea of Grex Ambassador is a good one.
rcurl
response 3 of 264: Mark Unseen   Nov 30 18:39 UTC 1998

Even the most beneficient kingdoms built moats around their castles. 
I think Steve did the right thing, with much forebearance. It is also
consistent to try to contact the site to have them control this behavior.
I don't think we need expend a great deal of tolerance upon an outlaw
and out-of-control operation.
dpc
response 4 of 264: Mark Unseen   Nov 30 18:54 UTC 1998

Steve, you did the right thing!
krj
response 5 of 264: Mark Unseen   Nov 30 19:19 UTC 1998

Ah, so the latest forkbomb is what was dragging down performance 
this morning.
 
I agree that if a site will not control users who have a bad impact 
on Grex, we have to defend ourselves.   (I'm thinking especially 
about technical attacks here, not harrassment issues.)
Staff might want to prepare a form letter to send out if we get 
any inquiries from users who have been site-blocked from reaching us.
The letter would basically explain Grex's position and urge the 
correspondent to have a responsible party at the site get in touch 
with Grex staff.
mdw
response 6 of 264: Mark Unseen   Nov 30 19:20 UTC 1998

Actually, this isn't the first site that we've had to block on grex.
The 2 usual reasons we block sites seems to be (a) people who send spam,
and (b) fork bombs.  A 3rd much less common reason is to block fingerd;
occasionally somebody sets up a cron job or script on some other machine
on the internet that does endless remote fingers to grex, wasting
network bandwidth.
krj
response 7 of 264: Mark Unseen   Nov 30 19:29 UTC 1998

(What I meant to say in conclusion: we need to try to enlist the 
"good" users from this site in our cause, if it's possible.)
mdw
response 8 of 264: Mark Unseen   Nov 30 19:42 UTC 1998

We have a standard form letter for fork bombs.  The wording has evolved
over time, based on feedback from various sites.  The letter generally
goes out to a list list of places, including "whois" contact
information, postmaster@ and abuse@, and includes the next level out
ISP.  The letter generally goes out well before blocking a site.  We
generally would not block a site unless the problem continues and (1)
the site doesn't respond, (2) the site responds and indicates it can't
control their users (for instance, they grant anonymous internet
access), or (3) the user is *SO* persistent there is no other way to
keep the system available for legitimate use (rare, as most vandals
disappear at the first sign of staff activity.) Most incidents get
resolved before we need to block a site.
scott
response 9 of 264: Mark Unseen   Nov 30 21:12 UTC 1998

I think cutting off the site was appropriate.  Hopefully, "good" users 
of that system will pester their admins about why they can't access 
Grex, and result in some action on reducing abuses from their site.
richard
response 10 of 264: Mark Unseen   Nov 30 22:51 UTC 1998

this is not ethical policy, because (although in this case it is
highly unlikely) site blocking could block paying members of grex
from accessing this site.  Site blocking should therefore not occur
absent a member vote to approve such an action.  Staff cannot 
presume to know which sites paying members use to come to grex and
therefore should not block any site without member approval.
rcurl
response 11 of 264: Mark Unseen   Nov 30 23:02 UTC 1998

Have any members been blocked from Grex by this action?
jiffer
response 12 of 264: Mark Unseen   Nov 30 23:52 UTC 1998

I have to agree that if the sys admin of this ISP are not responding / or
cannot control thier users, then it only seems "safest" for GREX as a *whole*
to block this site.  I think it should be a last resort.I also think that GREX
staff would not bring up this issue if it wasn't a last resort.  Sad as it
is, there are people out there that don't give a rat's tail about the stuff
they do to other systems.
other
response 13 of 264: Mark Unseen   Dec 1 00:22 UTC 1998

if it turns out that paid members are unable to get into grex because their
site has been blocked, then we should be ready to refund dues, either on a
pro-rata basis or in toto, to those users.  this should be dependent upon a
request from the user rather than being grex-initiated, though.

i vehemently disagree with richard's position above.  site blocking should
be done exactly as steve has done it: *very* reluctantly, and after repeated
failures to both respond to communications and desist in vandalous attacks.
additionally, such notification as this item is quite appropriate.

the only concern i have is that we should establish some sort of process for
the re-evaluation of blocked sites, with an eye toward unblocking them if they
should have a collective change of attitude and behaviour.

perhaps this should include mail to the site administration requiring that
they send us a copy of their enacted disciplinary policy before we will
consider allowing them access to our system again.  also, direct contact
information for those individuals responsible for the enforcement of that
policy should be required.

frankly, until and unless these simple requirements are met (assuming that
only a system which creates problems of this kind would even need to implement
a disciplinary policy), i see no reason to consider unblocking a site once
we have gone to the *extreme* measure of blocking it in the first place.

a decision not made lightly should not be reversed lightly either.
i
response 14 of 264: Mark Unseen   Dec 1 00:49 UTC 1998

I think you did the right thing, steve.  Providing good basic free service
to *many* people is one of our most important goals, vandals can greatly
reduce our ability to do that, so we're stuck throwing out some good
apples with the bad to save the barrel.

I like the way you're handling this on grex, too.  


I've no idea what technical issues are involved, but it would be nice if
grex could respond with a "We're very sorry, but due to..." message when
users from that site attempted a connection.  
wgm
response 15 of 264: Mark Unseen   Dec 1 01:20 UTC 1998

What's a fork bomb?
davel
response 16 of 264: Mark Unseen   Dec 1 02:33 UTC 1998

A program intended to eat system resources until none are left for anyone
else.
steve
response 17 of 264: Mark Unseen   Dec 1 04:19 UTC 1998

   A fork bomb does what Dave said, by splitting off a copy ("forking")
itself, which wakes up and makes copies of itself, too.  A form of
cybernetic cancer I suppose.  Eventually, the system becomes so bogged
down that little else happens.

   Here on Grex, we've changed some things such that no one person
can grab "everything".  Thus today when the load average was at 77,
things were rather miserable but things still ran, however slowly.

   ...Still trying to contact the system administrators of the site
in question.
scg
response 18 of 264: Mark Unseen   Dec 1 05:28 UTC 1998

All too often, system administrators don't feel like they have much of an
incentive to respond to people from other sites, but will generally feel some
sort of heat if they're unresponsive to their own customers/users.  As long
as we're clear in any response we give that this is something we've been
forced to do due to the lack of response from that site's administrators, but
that we will be happy to unblock it if they fix the problem, that seems likely
to get users from there (if they care) to start demanding that their system
administrators fix the problem, which will hopefully have a positive effect.

I think STeve's been far more patient about this than I would have been.  I
would have blocked the site a long time ago.  At this point, I really don't
think think there's much else we could do, to keep Grex working well for
everybody else.
mdw
response 19 of 264: Mark Unseen   Dec 1 06:25 UTC 1998

I don't see what the possible presence of a paying member has to do with
anything.  Members don't "contract" for services.  They "donate" to
support grex.  The fact that a paying member *might* be using an
incompetent ISP who doesn't care about vandals isn't and shouldn't be
our responsibility.  Giving a refund in this case would be like giving a
refund because the member's computer broke.  It should be the member's
responsibility, and it's certainly in the member's best interests, to
find another ISP that does a better job of handling vandals.

Something to keep in mind with all this, is that dealing with these
incidents is already incredibly time-consuming on the part of staff.  It
can take hours to go through the system logs, pull together all the
information available about the vandal's activities on grex, where they
came from, and how to get in touch with the places they came from, then
to compose a message pulling together all the various log entries and to
send it off.  (This is even *with* the canned boiler plate fork bomb
template.) After this, it's a matter of waiting, first for the site to
respond (it often takes 24 hours, or sometimes several days, before a
site will respond, and some sites never respond.)  In the cases were we
end up blocking things, this process often repeats itself, which means a
whole new mail message has to be composed, with the new log file
entries.  This process can in some cases take months to resolve.
steve
response 20 of 264: Mark Unseen   Dec 1 08:43 UTC 1998

  Most unforunately, Marcus is entirely too right about the time
factor involved in dealing with dreck like this.

  I'm not entirely sure what we should do, should blocking
a site ever get a member.  I'd sure want us to explain the
situation to him/her, and see how we affected that person.
There might not be a contract implied here, but I'd want to
talk to the person and let them know exactly what was going
on.

    Good news on the communications front: I've just sent a
long letter to an admin there who might be able to help us,
so I elected to do that rather than sleep tonight.

   We'll see what happens next.
krj
response 21 of 264: Mark Unseen   Dec 1 16:41 UTC 1998

At risk of drift, I will throw out an old proposal of mine:  it is time 
to consider making shell access available via application only.
 
The argument that we need to provide exposure to a Unix programming 
environment is greatly lessened with the rise of the free PC unixes such
as Linux.  And if anyone still wants to work on programming issues
on grex: well, they can apply for the shell account.
 
Balanced against this is the enormous amount of staff time sucked up 
dealing with malicious users.  The Internet puts us in a different 
situation in term of open access, and we're too attractive to vandals.
 
rcurl
response 22 of 264: Mark Unseen   Dec 1 17:23 UTC 1998

Re #19: Marcus misses the point that a member could be instantaneously
disenfranchised without prior notice by this action. This could have
been ameliorated by first notifying any members on the system that it
was about to be banned, and informing them they would have to find
another ISP. (I think this might all be kind of theoretical - we
haven't been told yet whether any members were using the site.)

aruba
response 23 of 264: Mark Unseen   Dec 1 19:55 UTC 1998

We currently have one member in India, and that is sisiro.  Judging from the
wtmp file he logs in from a number of different IP addresses, so I don't know
how to tell if he has been blocked by cutting off this site.  (His last login
was 11/20).  Perhaps someone who knows the name of the site that was blocked
should write to him and ask?  I see that his mail is being forwarded to 
hotmail.com.
steve
response 24 of 264: Mark Unseen   Dec 1 20:03 UTC 1998

   Good point, Mark.  I just checked, and that user has never
logged in from the site in question.
 0-24   25-49   50-74   75-99   100-124   125-149   150-174   175-199   200-224 
 225-249   250-264         
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss