This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--1358972926-497506793-791576659=:3088
Content-Type: TEXT/PLAIN; charset=US-ASCII
Well, as usual, I must apologize for the delay.
My thanks go out to the following folks:
"Charles H. Buchholtz" <chip@eniac.seas.upenn.edu>
Alexander Haiut <alx@black.bgu.ac.il>
Dave Fetrow <fetrow@biostat.washington.edu>
Gene Rackow <rackow@mcs.anl.gov>
George Pallas <gpallas@freenet.columbus.oh.us>
Jesse Adam <jaa@pollux.GEOG.UCSB.EDU>
Kai Grossjohann <grossjoh@linus.informatik.uni-dortmund.de>
Michael Myers <mmyers@willamette.edu>
Rich Chung <rlc@syl.nj.nec.com>
bern@penthesilea.uni-trier.de (Jochen Bern)
brett@gti.net (Brett K. Lynch)
dotty@hobbes.tgivan.wimsey.bc.ca (Dotty Pon)
leon@orbotech.co.il (Leon Koll)
perryh@pluto.rain.com (Perry Hutchison)
phubbard@baosc.com (Phil Hubbard x6177)
scott hollatz <shollatz@d.umn.edu>
sdr@rdga3.att.com (S. D. Raffensberger 52882 (RD))
Basically, I've decided to go with my original policy (change the
cracked passwd's user's shell to a phoney that prints out a message
and notifies me of the attempt) with one addition: I'm now running
yppasswdd with the '-noshell' option so that shells can't be changed
remotely (since that daemon is *stupid* enough not to check whether
the *original* shell is in /etc/shells!).
Here's what folks told me:
From: dotty@hobbes.tgivan.wimsey.bc.ca (Dotty Pon)
> You can expire the user's password so that the next time they
> login, they must change their password before they can get
> onto the system. Is this an acceptable solution?
This is not an acceptable solution. What if the next person who tries
to login as that user is a cracker? S/He just changes the passwd to a
new one, and then the *real* user can't use it, but the cracker still
can.
Not a wise move, IMO.
From: Alexander Haiut <alx@black.bgu.ac.il>
> Yes. If there are xterminals running xdm connected to your machine,
> and these people have access to them, then ~/.xsession file may be
> used to log into the system.
Not a concern here (no xdm), but the rest of you may want to take note...
From: bern@penthesilea.uni-trier.de (Jochen Bern)
> Better implement a "proactive passwd" which won't accept weak Passwords
> in the first Place.
I'm doing this (we already run npasswd, but it's dictionaries are
considerably smaller than crack's -- I'm going to arrange for both
programs to use the same dictionaries).
> PCNFS has the (faulty) Method of allowing Access iff the Shell's Filename
> ends in 'sh'.
I'd heard of this. My phoney shell's name doesn't end in 'sh$' so I'm OK.
> ... as a Sidenote: To disable an Account *completely*, remember to
> take Care of WWW Pages, Mail Aliases, Crontabs, ...
Good point, but (in this case) I don't want to remove the account,
just disable it until a better password is given.
From: leon@orbotech.co.il (Leon Koll)
> Could you send me this shell script ?
see attached.
From: "Charles H. Buchholtz" <chip@eniac.seas.upenn.edu>
> I also chmod 0 their home directory, because I have many people who
> don't use their account on my machine, but log in to other machines
> which NFS mount their home directory. Since the remote machine uses a
> different password, you might say that there's no problem with this,
> but I use the same "account locking" procedure for every type of
> situation, and I got into trouble when people were actively using
> their account and had no idea that it was locked. For example, the
> lock where I say, "your account has been deleted. If you still need
> this account contact me immediately!".
I control all of the machines that can access my users' home dirs, so
this doesn't apply here, but it's an important point to bear in mind
for the future.
> [another vote for pro-active passwd changing program]
From: Rich Chung <rlc@syl.nj.nec.com>
> [recommends getting a larger crak dictionary]
I've got 8M worth of foreign dictionaries here -- if anyone wants,
they're ftp'able: ftp://ftp.econ.yale.edu/pub/lturetsk/crack/.
From: sdr@rdga3.att.com (S. D. Raffensberger 52882 (RD))
> I believe users who have .rhosts files can still log in
> no matter how you mess with the passwd file. They can
> simply use "rsh machine /bin/sh" and it will probably
> let them in.
Not so. Any commands that a user attempts to rsh will be passed to his
shell -- if his shell doesn't interpret commands, those commands go to
the bit-bucket.
From: Michael Myers <mmyers@willamette.edu>
>[re-iterates the above point about NFS]
From: Gene Rackow <rackow@mcs.anl.gov>
> Truth is, it will depend on what kind of machines you have on the net, and how
> they are configured. For example if you support machines running NeXT-Step,
> then you need to * out the passwd as well or someone can sit down
> and login at the NeXT console. It ignores the shell field of the passwd file
> when it starts the window system. You can do alot by clicking on stuff.
Sounds like another version of the xdm point above. Doesn't apply
here, but I'll bear it in mind for the future.
> Are you running YP/NIS on your net? If so, then you also want to * it out
> as anyone can change the shell to whatever they want fairly easily. The
> yppasswd daemon does little to authenticate things if you know the users
> passwd.
Like I said above, I'm now running yppasswdd with the '-noshell'
option. Thanks for pointing that out.
Perhaps the folks at SUN would be good enough to add some intelligence
to that daemon.
> Another thing to worry about is are you sure you are talking to the
> real owner of the account? Cracker bob greps for your special shell from
> the passwd file and calls in for a new passwd on "his" account.
Well, they have to come see me in person and show a Yale ID (although
those should be easy to fake).
From: phubbard@baosc.com (Phil Hubbard x6177)
> [another vote for npasswd]
From: George Pallas <gpallas@freenet.columbus.oh.us>
> No, it really isn't enough, but as long as you're dealing with "weak"
> passwords, and as long as the matter gets cleaned up within a day or
> two, you should be able to skate by. COMPROMISED passwords are a
> different matter. If you know an account's password has been compromised,
> disable it IMMEDIATELY, using the asterisked password field or similar.
> You may also want to remove the user's .rhosts file, if any, in that
> case.
Not the case I'm worried about. .rhosts is another story...
From: Dave Fetrow <fetrow@biostat.washington.edu>
> [yet another vote for npasswd]
From: brett@gti.net (Brett K. Lynch)
> Please, for you own security, disable the login COMPLETELY, by placing a
> '*' in the pass field, as you mentioned. There are several ways to
> abort any C script, and the risk is simply not worth it. Also, of course,
> at least run C2, and something like Passwd+ or NPassword to make your
> job a bit easier.
I don't see what the risk would be, and there is some value in having
the user see the bad login message (although if they keep trying their
passwd and fail, they'll probably end up contacting me anyway ;-).
From: Jesse Adam <jaa@pollux.GEOG.UCSB.EDU>
> i don't have an answer for you but putting a '*' in the password field
> does not necessarily prevent users from logging in. they can still
> login provided they have created ~/.rhosts to enable remote login from
> another host (presumably from a host where your [NIS]password file
> is not used on that host)
True. I guess the most secure thing is to * out the passwd *and* to
give them a bad shell.
From: Kai Grossjohann <grossjoh@linus.informatik.uni-dortmund.de>
> [one more vote for npasswd]
From: perryh@pluto.rain.com (Perry Hutchison)
> Re disabling an account by changing the shell to something that's not
> in /etc/shells, even if you * out the password, their cron jobs will
> still run and I think they can still rsh in if they have a ~/.rhosts .
> That's all I've thought of offhand.
Cron jobs are a good point, but I'm not too worried about that
(assuming that the cron jobs were put it by the real users and not a
cracker).
.rhosts, as noted above, won't work w/a non-shell.
--------------------------------------------------------------------
My thanks to all who responded.
LT
,-----------------------------------------------------.
| Yale Economics Dep't | Lenny Turetsky |
| System Administrator | lturetsk@econ.yale.edu |
|-------------------------+---------------------------|
| My employers paid for some of my time and energy. |
| My opinions were never for sale. |
`-----------------------------------------------------'
--1358972926-497506793-791576659=:3088
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=nosh
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SUN.3.91.950131132419.3088M@aida.econ.yale.edu>
Content-Description:
IyEvYmluL3NoDQojDQoNCiMgbm9zaCAtLSB0aGUgbm9uLXNoZWxsDQojIChj
KSBMZW5ueSBUdXJldHNreSAobHR1cmV0c2tAZWNvbi55YWxlLmVkdSkgMTk5
NC05NQ0KDQojIHRoaXMgaXMgYSBzaGVsbCBzY3JpcHQgaW50ZW5kZWQgdG8g
YmUgdXNlZCBhcyBhIHBob25leSBzaGVsbCBpbiBwYXNzd2QgDQojIGZpbGVz
IGZvciB1c2VycyB3aG9zZSBhY2NvdW50cyBhcmUgYmVpbmcgZGlzYWJsZWQu
DQoNCiMgZmVhdHVyZXM6DQojCXByaW50cyBvdXQgYSBtZXNzYWdlIGZpbGUg
Y29udGFpbmVkIGluOg0KIwkJYGRpcm5hbWUgJDBgLy4uL2xpYi9gYmFzZW5h
bWUgJDBgLm1zZw0KIwl0aGUgYWR2YW50YWdlIG9mIHRoaXMgaXMgdGhhdCB5
b3UgY2FuIG1ha2UgbGlua3MgdG8gaXQgYW5kIGhhdmUgaXQgDQojCXByaW50
IG91dCBkaWZmZXJlbnQgbWVzc2FnZXMuDQojDQojCWZvciBleGFtcGxlLCBp
ZiBpdCBpcyBjYWxsZWQgYXM6DQojCQkvdXNyL2xvY2FsL2Jpbi9iYWRfbG9n
aW4NCiMJaXQgd2lsbCBwcmludCB0aGUgbWVzc2FnZSBjb250YWluZWQgaW46
DQojCQkvdXNyL2xvY2FsL2xpYi9iYWRfbG9naW4ubXNnDQojDQojIG5vdGVz
IGFib3V0IG1lc3NhZ2UgZmlsZXM6DQojCW1lc3NhZ2UgZmlsZXMgd2lsbCBi
ZSBwcmludGVkIGFzIHRob3VnaCB0aGV5IHdlcmUgYmVpbmcgcHJpbnRlZCBi
eQ0KIwlhIC9iaW4vc2ggJ2NhdCA8PCBFT0YgfCBmbXQgLXMnIGNvbW1hbmQu
IFRoaXMgbWVhbnMgdGhhdCBiYWNrc2xhc2hlcyANCiMJYXQgdGhlIGVuZHMg
b2YgbGluZXMgd2lsbCBjYXVzZSB0aGVtIHRvIGJlIGpvaW5lZCB3aXRoIHRo
ZSBuZXh0IGxpbmUsDQojCWNvbW1hbmRzIGluIGJhY2txdW90ZXMgd2lsbCBw
cmludCBvdXQgdGhlaXIgb3V0cHV0LCBhbmQgJFZBUnMgd2lsbA0KIwliZSBp
bnRlcnByZXR0ZWQuDQoNCiMgVGhpcyBwcm9ncmFtIGlzIGJlaW5nIHJlbGVh
c2VkIHRvIHRoZSBwdWJsaWMgb24gdGhlIGNvbmRpdGlvbiB0aGF0IG5vIA0K
IyBjaGFuZ2VkIHZlcnNpb25zIG9mIGl0IHdpbGwgYmUgZGlzdHJpYnV0ZWQg
d2l0aG91dCB0aGUgYXV0aG9yJ3MgZXhwcmVzcywgDQojIHdyaXR0ZW4gY29u
c2VudA0KDQp0cmFwICcnIDEgMiAzIDQgNSA2IDcgOCA5IDEwIDExIDEyIDEz
IDE0IDE1DQoNCk1PREU9ImBiYXNlbmFtZSAkMGAiDQpCSU5fRElSPSJgZGly
bmFtZSAkMGAiDQpMSUJfRElSPSIke0JJTl9ESVJ9Ly4uL2xpYiINCg0KIyBB
ZGRlZCBieSBWQUgNCiMgTW9kaWZpZWQgYnkgTFQNCi91c3IvbG9jYWwvbGli
L3RvX2xvZ2ZpbGUgbG9naW5fbG9nZmlsZSAiJHtVU0VSfSIgIiR7TU9ERX06
YGhvc3RuYW1lYDoJYHdobyBhbSBpIHwgc2VkICdzL1sgCV0qWyAJXS8gL2cn
YCINCg0KRklMRT0iJHtIT01FfS8ubWFpbHJjIg0KaWYgWyAtZiAke0ZJTEV9
IF0NCnRoZW4NCgkJQkFDS1VQPSIke0ZJTEV9LiQkIg0KCW12ICR7RklMRX0g
JHtCQUNLVVB9ICYmXA0KCQlFWElUX0NNRD0ibXYgJHtCQUNLVVB9ICR7RklM
RX0gOyAke0VYSVRfQ01EOi1leGl0fSINCmZpDQoNCk1haWwgLWkgLW4gLXMg
IkJBRCBMT0dJTiBBVFRFTVBUIGJ5ICR7VVNFUn0iIHN5c2FkbWluIDw8LSBE
T05FDQoJdHlwZToJJHtNT0RFfQ0KDQoJVVNFUjoJYHdob2FtaWANCglIT1NU
OglgaG9zdG5hbWVgLmBkb21haW5uYW1lYA0KCVRJTUU6CWBkYXRlYA0KCUhP
VzoJYHR0eWANCg0KCU9USEVSUzoNCgkJYHdob2ANCg0KCVBST0NFU1NFUzoN
CgkJYHBzIGF1eHd3d3dgDQpET05FDQoNCmNsZWFyDQplY2hvDQplY2hvDQoo
ZWNobyAnY2F0IDw8IERPTkUnOyBjYXQgJHtMSUJfRElSfS8ke01PREV9Lm1z
ZzsgZWNobyBET05FKSB8IC9iaW4vc2ggfCBmbXQgLXMNCmVjaG8NCmVjaG8N
Cg0Kc2xlZXAgNQ0KZXZhbCAke0VYSVRfQ01EOi1leGl0fQ0K
--1358972926-497506793-791576659=:3088--
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:15 CDT