I asked a number of security related questions in an email a week
ago, and would like to summarize responses, as well as relate the
things I am doing here to try to minimize our security risks.
Fortunately, I get some great help and advice from our campus Sun
support; even so, please keep in mind that I am definitely a novice
on this issue.
The following will be most useful to you if you do not, as we do
not, have a firewall. We are considering this pathway, but there
are serious implementation issues with firewalls and the free
communications normally demanded at an academic site. I am also
considering placing a secure router (prevents all but named IP
addresses from getting through) plus a dedicated modem (allowing
entry without going through the campus dial-ins); this seems a
simpler task to implement than a Linux-based firewall.
Tcp-wrappers is another option that I have not looked hard
enough at yet.
Anyway, I have done the following to our Sun's, which are not
at this time behind firewalls, routers, or tcp_wrappers:
1. Installed the latest recommended Sun patch cluster; many (most?)
are patches fixing security issues.
2. Turned off all unused services in /etc/inetd.conf. I spent a lot
of time figuring out which appeared OK to turn off, so I'll list
all those I've turned off along with a brief description--please
keep in mind that your configuration might well need to be
different. Please also note that I am quite a novice at this;
I've put a question mark following services that I am still
uncertain are really ok to disable:
ftp - file transfer protocol
telnet - remote connection protocol
tnamed - DARPA name server protocol
rshd - remote shell server
rlogind - remote login server (disables rlogin)
rexecd - remote execution server
comsat - biff server; listens for mail
talkd - server for talk program
uucp - Unix-to-unix copy (turn off if at all possible!)
finger - info on local & remote users (turn this off!)
time - time synchronization utility (?)
echo - used primarily for testing
discard - used primarily for testing
daytime - used primarily for testing
chargen - used primarily for testing
rquotad - remote quota daemon
rusersd - gives out user info
sprayd - spray server (port packet transfer info)
rstatd - kernal statistics server (performance monitor)
KCMS - kcms library, remote host initiated
cachefs - cache file system (not system cache); appears
to not be used by VNMR (?)
kerbd - generates/validates kerberos tickets
rpc.cmsd - calendar manager service for CDE
rpc.ttdbserverd - Tooltalk for CDE (?)
3. Some of the above deserve special mention. I have disabled ftp
and telnet from all but one workstation (just too convenient to
live without completely). But on that workstation, I make sure
no root (su) is performed while telneting in. Anytime I need root,
I go through ssh (secure shell). I've had a few people tell me
rlogin is ok if implemented with .rhost; the university computer
security people do not agree (ie., they see rlogin as a security
risk). uucp and finger are clear security risks, and should be
disabled if at all possible. rquotad and rpc.cmsd are likely used
by many people, but not here at UW.
4. Disable sendmail if you are not using it. Do this by removing
the file /etc/rc2.d/S88sendmail (I made a copy of the rc2.d
directory, just in case). The S files in rc2.d start services
upon booting; K files kill the services on shutdown.
5. Increase the minimum required password length (longer is better!:).
Change the value of PASSLENGTH to 7 in /etc/default/passwd.
6. Install tripwire to assist in identifying intrusions: see
http://www.tripwiresecurity.com/ for more info. Installing
tripwire right, and monitoring it can be time consuming.
7. Install ssh, to give encrypted passwords.
8. Install crack, to find easily cracked passwords on the system.
Somewhat infringes on user privacy, but since the last two
break-ins I have had were due to bad passwords, I'm not giving
users any options here (I do warn them when I make the account
up that I will be using crack).
9. Share file systems (read-only to spectrometer consoles) via
the automounting system: /etc/auto_master, /etc/auto_direct,
and /etc/dfs/dfstab control access.
Well, that's what I've done. No doubt one could spend their whole
life (and of course a bunch of people do!) on this stuff. But
most of the above is straight-forward to do, and makes me feel a
bit better about our systems.
Most of the comments I received can be reasonably summarizing
by stating that all the industrial users that responded to me were
inside firewalls. And many academic sites are using some form of
protection, at least with ssh and some with tcp_wrappers; a number
are considering firewalls. Below I've attached two excellent
sets of suggestions I received [with some comments from me in
square braces].
Crackers are crazed rodents, and need to get a life!
["hackers are hell" sounded better, rudi :]
________________________________________________________________________
From: Rudi Nunlist <rnunlist@purcell.cchem.berkeley.edu>
Attacks at UCB seem to be platform neutral, spanning Sun, Linux, SGI,
and the occasional screen turning blue on Winslow boxes.
Please note that _hackers_ are not the problem, _crackers_ are. There is
a substantial difference between the two.
[My apologize to benevolent hackers out there; I really did not
understand the distinction, which makes sense, earlier.]
It seems that in academic institutions, network security is often taken
lightly (at least, until after stuff happened). While many/most NMR
jocks may well be overwhelmed, most campuses or departments have
expertise available.
Firewalls in academia are (I think) probably the exception, I think that
networked collaborations between different campuses would be
substantially more difficult. This puts security concerns at a
lower layer, perhaps mostly at the end user level.
A number of strategies have kept us out of trouble (so far ....):
o Basically, only configure network services you really need, and
restrict those to trusted hosts/users.
o Allow traffic out of the facility, but severely restrict/secure
traffic coming in.
o Use a generic account for nmr users, and keep it logged in. This
reduces security risks to very few accounts. It also keeps overall
administration simple.
[I tried this, but just doesn't work for our facility; I keep over
60 accounts active at any single time, and bad passwords are my
number one worry. Joe Vaughn at Florida State does something I
used to do; assign passwords and ask users to stick with them.
I would still do this, but the users then use that password on less
secure systems, and we'd still be compromised if those systems get
cracked. I finally decided setting a forced password change (every
120 days) and running crack was preferable here.]
o Run password checkers.
o Use the systems to do science stuff, and stay away from using it as
your mail/web/talk/ftp server.
o Have system backups in case you do need to re-install from scratch
(for any reason).
o Check your log files.
o Check put www.rootshell.com fort an overview of how your favorite
platform can be cracked.
______________________________________________________________________
From: Steve Philson <philson@nmr.chem.umn.edu>
We use only ssh on most internal machines, and do not allow remote
access to the spectrometer computers at all (except via ssh from
another lab machine). In the present environment, I would never allow
access from the outside to a console machine (though some of them do
NFS share data directories read-only). Another computer provides
scheduling, status of instruments and autosampler queues, ftp, web and
email service; only lab personnel have shell access. Another one
still is for off-line processing, which is accessible from a countable
number of Xterminals outside the lab (they must arrange with me first
to get access for a specific computer/printer combo).
Most universities are under constant attack these days from crackers,
and the best defense is to provide as few services as possible, limit
those you must provide, and monitor everything (including the
integrity of your system files, e.g. with tripwire or something
similar). I haven't done everything I should, but am trying to make
things as secure as possible. I also have routing for most internal
machines set so that access outside my subnet is impossible.
Our departmental e-mail machine was broken into a few months ago,
probably through holes in the pop daemon we were running. It was
owned by someone in Brazil for over a month before we discovered it,
and we had to re-install OS and make new passwords for everyone in the
department.
I might consider setting up a firewall of some sort when our network
configuration changes (I currently have my own router port for the nmr
lab, and am almost alone on a class C subnet, which will change soon).
----------------------------------------------------------
Charlie Fry Tel: (608)262-3182
Director, MR Facility Fax: (608)262-0381
Chem. Dept., Univ. Wisconsin
Madison, WI 53706 USA email: fry@chem.wisc.edu
----------------------------------------------------------