[RC5] [admin] Learn from others' mistakes...

David McNett nugget at slacker.com
Thu Jan 15 13:57:59 EST 1998


I have been *extremely* busy this morning, devoting considerable time
and energy towards a task which I do not enjoy.  This task does not make
me money, nor does it get us any closer to a working DES stats server.

A herein-unnamed system operator, employed by the local county government
of a fine state somewhere in the united states made the decision to
ignore his common sense, the stated distributed.net policy, and our FAQ
by installing the RC5 client on a file server that he was in charge of
maintaining.

The client ran just fine, unnoticed and chugging along for quite some time.
It didn't interfere at all with the operation of the server and didn't
affect any user processes.

However, the file server developed some problems.  It started to lock up.
Processes would hang.  The vendor was called in to honour the support
contract and repair this machine which many city and county employees 
relied upon to do their jobs.  Now, you and I and this system operator
know that the problems are completely unrelated to the presence of our
faithful little client.  The vendor, however, has neither the time, 
inclination, or motivation to be informed about the distributed.net effort
and, upon discovery of the client believed that it had found the source
of the server lockups.

The net result: The support contract was terminated because the county 
office violated the terms of their support agreement by introducing an
unknown and unsupported application to the server.  All support fees
paid are forfeit.  Before they can initiate a new support agreement, the
county will have to pay thousands of dollars to re-install the operating
system and data files and a complete security audit will have to be 
performed.  Irrespective of the fact that we all *know* that the client
has not compromised the integrity of the network, this is a legitimate
and understandable reaction on the part of the vendor.

Needless to say, despite the this operator's manager (to whom I've been
speaking) and her valiant efforts, it looks as if he will be losing his
job over the matter.  The state has lost time and money and stands to lose
much more if I cannot convince the vendor that our client has done no damage
and alleviate their understandable concerns.  It will probably be several
weeks before this issue is resolved completely at much cost to all parties
involved.

Not to mention the fact that it makes us look like a band of irresponsible
hackers.  Despite the fact that distributed.net is not directly responsible
for this tragic chain of events, I am working very hard to try to minimize
the damage done to the innocent parties involved.

The saddest part of all, and further validation of our stated policies is 
that this system operator's manager told me that she was overall quite
impressed by distributed.net; Had this operator approached her with the idea
of running the client on some machines she would have allowed it to occur on
those machines not restricted by the service agreement.

Once again, for the record, there is NEVER, EVER justification or sufficent
cause to run the client on any machine which you don't own or are not directly
responsible for.  If there is any question, it is ALWAYS better to err on the
side of prudence and NOT install the client.  Lets hope that others can learn
from this tragic example and that we never have to go through this again.

-/\/
 ________________________________________________________________________
|David McNett      |To ensure privacy and data integrity this message has|
|nugget at slacker.com|been encrypted using dual rounds of ROT-13 encryption|
|Birmingham, AL USA|Please encrypt all important correspondence with PGP!|
--
To unsubcribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list