Re: security issues.....

[Stephen J. Turnbull <nospam [at] sk.tsukuba.ac.jp>]

For those who know the usual cypherpunk[1] song-and-dance, I'll just
remark that the Security-HOWTO (typically in /usr/[share/]doc/HOWTO/)
is quite up-to-date. My favorite reference is Bellovin and Cheswick,
_Firewalls and Internet Security_. A bit dated, but a good read.

Details on the current question.

>>>>> robert == robert <robert [at] mckay.com> writes:

[A lot of useful stuff. No addition or clarification needed.]

robert> In short running any sort of service is going to leave you
robert> potentially vulnerable.

This is extremely important. If you are running telnetd and ftpd and
your users, including yourself, are logging in over the Internet, then
_anybody_ between your client and your server could have your
passwords. That includes root if you do things like su in a telnet
session. And _anybody_ can in fact include the whole Internet if your
DNS and/or router is successfully attacked (I have seen it done to at
least two large US regional ISPs).

If you know who is going to be logging into your machine from the
Internet, and expect them to do so from Un*x boxen, I suggest turning
off telnetd and ftpd, and using ssh (secure [r]sh) and scp (secure
cp) instead. These are available in turnkey binaries for most Linux
distributions and the free *BSDs, and autoconfiguring source
distributions for Unix. It is probably possible to use those programs
from Win* boxen, but I don't know of binary distributions and have
never built them for that platform.

These programs are extremely easy to use once configured, as the
high-security parts are automated on the principle that the local
machine is fairly secure. The main loss in convenience is FTP
browsing; scp requires you to know which file you want, subject to
wild-carding, just like rcp.

These programs are extremely secure on the net, because no
authorization information is ever passed in the clear by the programs
themselves, and in the default mode all communications are encrypted,
so passwords for su etc cannot be sniffed from the connection
either.

Alternatively, if you want to maintain the convenience of telnet and
ftpd for the local network, you can use ipchains(8) or tcp-wrappers
(tcpd(8)) to limit the external accessibility of those servers. One
friend prefers xinetd(8) to the equivalent combination inetd(8) +
tcpd(8).

robert> Your security program was probably just complaining that
robert> you were running the services at all, rather than that it
robert> had detected a vulnerable server on your machine.

A good audit should tell you exactly what kind of vulnerability it
detected. If it doesn't tell you what your problem is, you can't
address it effectively.

robert> All the same you might want to check out www.cert.org and
robert> search for your servers and see if there have been any
robert> reports for them.

This does require a fair amount of sophistication. For example, the
same version number means different things for different
distributions. It is not uncommon that the difference between
server-<x>.<y>-<z>.i386.rpm and server-<x>.<y>-<z+1>.i386.rpm is the
application of a security patch. On the other hand, Red Hat has been
known to back out features from a given upstream release <x>.<y>
because they are incompatible with new, improved unreleased features
(gag, hack, blow chunks). AFAIK they've never done that with a
security patch, but I don't trust Red Hat version numbers anymore.
(Note: I don't need to, I now use Debian. Red Hat probably have got
their act together on that. But with security, probably isn't good
enough to bother with.)

Read the Security-HOWTO (130kB) and something like Cheswick and
Bellovin first. If you're not up to that, then the information at
CERT is likely going to be unclear and confusing.

Footnotes:
[1] I'm just a wannabe.

--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
/- /System.old /apps /bin /boot /dev /etc /home /lib /lost+found /misc /mnt /net /proc /root /sbin /share /tmp /usr /var What's the big deal about the millennium? .............................
.... There are still 362 shopping days left until the millennial epoch! */

Start your own FREE mailing list at

&copy; 2000 Microsoft Corporation. All Rights Reserved