On Mon, 7 May 2001, Gavin wrote: > I would like to know if you or anyone else in the expert group have ever > used the progeam called JOHN THE RIPPER to I want to install it and do some > security checks (passwords for other users) . If you have used it before > could you please give me the pro's and con's using this software. I've found that this type of program is usually fairly useless to overall security, and often results in worse security because efforts are diverted away from more pressing issues. Eg., I've seen installations where the users use insecure protocols (eg., ftp, rsh, telnet), showing their password in the clear to anyone who cares to listen, where the top focus of the security team was finding out who had weak passwords and who was looking at naughty websites. The main usefulness of this sort of thing will be in a NIS environment where everyone can see everyone's encrypted password, and to check for user accounts with the same account name as password, or with a password containing a word from the GECOS field (usually used for the user's full name) Otherwise, you already have to be root to even see the encrypted passwords of the users. As for that particular program, I haven't used it, but it may not work against Linux Mandrake passwords, anyway (my box uses md5, for instance, and I think it may assume standard Unix DES-encrypted passwords) Likewise FreeBSD defaults to md5, and OpenBSD defaults to the even more computationally intense Blowfish. > > A book I'm reading now is call REAL WORLD LINUX SECURITY, Intrusion > Prevention, Detection, and Recovery. by Bob Toxen, and it suggested I try > using it to see how secure the passwords my friends employees are using. also > if anyone has read the book linux hacking exposed, please give me your > feedback. > I've read through a "Hacking Exposed" type book a friend at work has. It seemed more oriented toward showing admins that, yes, script kiddie tools do exist, and are trivially easy to use and, toward teaching the next crop of script kiddies the basics needed to get started, as opposed to a real help to securing your site. Sure, there were tidbits here and there, but the title of the book was accurate being "Hacking Exposed" rather than something such as "Securing Unix". I believe the most pressing concerns are: 1) Do not allow any logins (ftp, web, telnet, etc) that are not secured. If your users need to upload web pages, for instance, you can use mod_dav + mod_ssl to do this securely. If they need to upload files to shell accounts, the newer OpenSSH's come with an sftp client and server. Secure login can be done using OpenSSH. IMAP daemons can be wrapped using stunnel. 2) Audit which ports are open. Turn off the daemons you're not using. For the ones you are using, but only need access to at the office (eg., print server services), firewall accordingly. 3) Audit setuid binaries. This can require some experimentation, which is what a test system can be helpful for. Ideally, as few programs as possible will have setuid bit turned on. 4) Use secure daemons. Not all daemons are created equal. Eg., qmail and postfix were both designed from the ground up for security. Sendmail was not. Likewise with BIND vs djbdns. You can also chroot and run BIND at a lower privilege (there's a mini-HOWTO on the subject at the LDP - http://www.linuxdoc.org/ ) 5) Pay attention to security notices. Apply patches to affected services. If you used the principles in 4, you may have limited your exposure here (eg., for the BIND exploit of the month, BIND could not have been used to compromise the whole machine, if you had set it up in a chroot environment running as ann on-root user) > > Thanks for your help. > No problem. > > Sincerely, > > Gavin (Japan) > -pete
