Securing your system (was: /etc/issue, ssltelnet)
Hi Norman,
I can't say much about the /etc/issue file since I've never really dealt
with it. If you figure out what do about the issue file, could you
please let me know, too. By the way, this is the first time I've ever
noticed a /etc/issue.net file. Is this new to hamm, or was it in bo, too?
Anyway, what I've done on some of our systems is the following:
- Disable all insecure incoming connections in /etc/inetd.conf or
xinetd.conf, whichever you are using:
- shell, login, exec - (rsh, rlogin, rexec)
- finger, tftp, bootps, rusersd, telnet, ftp
I'm sure there are others but these were the ones that stood out the most.
Of course, all outgoing connections would still work, such as rlogins and
telnets. I tend to prefer ssh over ssltelnet. IMHO, it provides better
security. Forcing connections via Secure Shell is preferrable but not
always possible since some of our users can't always use a machine that
has the ssh clients installed when they are "away." The same goes for
ssltelnet. To my understanding, ssltelnet only works securely if both
sides are using ssltelnet/d. Why bother trying to provide an encrypting
telnet if the machine they are using doesn't provide an encrypting telnet
or if they are just going to type their password over the clear during an
ftp session (unless you are using sslftp). In such cases, we've provided
them with one time passwords (OTPs), meaning that we would have to
reenable telnetd and ftpd in inetd.conf. Using OTPs allows a user to type
a password as clear text over the net without worrying about password
sniffers since the password would only be used once. The next time the
user logs in, he/she would enter the OTP next on the list. This is great,
although slightly tedious at first since the OTPs tend to be long. No big
deal if you take into account it is more secure then standard telnets. A
pretty good OTP package that I've used is called OPIE. OPIE provides OTP
replacements for in.logind (for incoming telnets), in.ftpd and su (for
more secure su-ing). There is a Debian package for it, although it is
slightly outdated, last time I checked.
In general, we try to use a combination of Secure Shell and one time
passwords (for those w/o access to ssh clients).
It doesn't seem possible to get 100% security, but the above steps should
make things a bit more secure.
Sorry if you already knew all of this.
-Ossama
--
E-mail the word "unsubscribe" to debian-user-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@debian.org .
Reply to: