[RC5] was: Win32: feature creep
vort at resnet124.unm.edu
Fri Nov 21 11:31:56 EST 1997
> Jason Bechtel was heard saying:
> >First, I realize that the policy is that the client should
> >not be run on machines without approval from the owners, but I go to a
> >*rather* large school with vast computing facilities and no one would
> >really notice. And besides, the client wouldn't have all of these
> >stealth features if it wasn't expected to be used surreptitiously...
> The reason the client can run in stealth mode is so that it can be
> run BY administrators without attracting the attention of their
> USERS. If you don't have responsibility for a machine, find a person
> who does and get their permission. There are *NO* exceptions to this.
> You have made two assumptions that are completely baseless. First,
> you've assumed that the administrator(s) of the machines would not
> notice. That's a dangerous assumption and is most likely false. Let
> me tell you how stealth clients are usually found:
> 1) Machine begins behaving strangely (for any number of reasons
> which you and I both know have nothing to do with the client).
> 2) Administrator starts problem solving using the shotgun approach
> and noses around looking for warning signs.
> 3) Client is found (it's not that hard...) and assumed to be the
> of the problem.
> 4) User who placed the client on the box is [ Fired | Denied Access
> Humiliated | Pusished ] for interfering with the smooth operation
> of the machine.
> 5) Original strange behavior persists in machine in absence of the
> client, but said user has so ostracized themselves from
> the sysadmins that it's far too late now.
> 6) Admin is so frustrated and now has a serious grudge
> against all of us and will probably never consider
> joining the effort. We are now lumped into the same
> group as people who use ftp:/incoming as a warez site
> and who download 90mb of pr0n to their homedirs.
> You've also made the unspoken assumption that the
> administrators are too dumb / too short-sighted to be interested in
> this effort themselves. Let me tell you, if you can convince your
> administrator to join your team, the amount of cpu power they will be
> able to amass will stun and astonish you.
speaking for myself , as a Sys-Admin for the CS dept. here at UNM, i can
say that I got involved in cracking rc5-56 because one of my users was
running a client on some of our more underpowered machines during the day
and really killing the CPU. at first we were concerned with names like
crackit (they had renamed the clients) and such we thought we had some
luser trying to break password files, but on further investigation
we found out about it, and got involved in cracking ourselves ( ourselves
being more of the Admins in the dept). currently my setup works like this
i have a script that runs 8am-1am and checks to see if anyone is logged into
the given machine, if so, it sends a SIGSTOP to the rc5 client, if no one
is currently logged on it sends a SIGCONT. if a machine is rebooted
at some point i have another script that logs in, checks to see if any
rc5 client ( mine or anyone elses) is running, and if not it copies over
a new crontab, makes sure that i have an rc5 client installed on that machine
and starts it cracking... if i have gotten nothing else from this project
then its been a learning experience for automated job control.
http;//flux.unm.edu - Modern scooter website!
I have plenty of common sense, i just choose to ignore it. -Calvin
"Look for clues inside the baby's head, hear the words yet to be said,
cue the music fade to black, no such thing as no payback" - PWEI
To unsubcribe, send 'unsubscribe rc5' to majordomo at llamas.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5