>We definitely have had problems with network security. Some
>blame for our problems must go to my predecessor and myself, but
>much also goes to Sun for not having a very secure OS.
>
>I have been facility manager at UW-Madison for about 18 months. We
>have a mixed environment, Brukers (AM, AC, WP) and two Varian Unity's.
>Having a Bruker background, I had a lot to learn on the Unity's.
>Unfortunately, I learned most about the SunOS after we were invaded by
>hackers that caused problems country-wide in Jan-Feb 95. Our Sun's had
>gapping holes in the OS that let the hackers install password
>sniffing and use our machines as FTP routers (they may have been
>doing more, but these two we found). It took me well
>over 50 hours of work to clean up the workstations, and with the
>help of our computer center on campus, install 24 patches (about
>half bug fixes, about half for security) to our current SunOS
>4.1.3_U1.
>
>I can give you more details if you wish, but let me summarize
>with the following:
>1. If you have Sun's, and are inexperienced as a manager of this
> OS (as I was!!), beware. You should get comfortable with the OS
> before connecting the systems up.
>2. If you have SGI's, the security issues are less, so you're
> probably ok.
>3. Being on the net is great. Although I spent a lot of time
> learning how to make our systems secure, I've never really considered
> taking them off the net. However, we do have a PC network (Novell)
> that is on its own net, and I have installed only a simple ftp
> server on it that serves ok. Even though I like being on the
> net, I do not allow non-console root logins, restrict su priviledges,
> do not allow cross-mounting to
> any machine that is not directly under my control, and carefully
> control passwords and remote usage, in addition to the patches
> mentioned previously.
>
>Hope this helps; the main message is to not take security issues
>too lightly. Unfortunately, the world is not as simple as we
>might wish. I don't think there's any reason to not connect to
>the net, but it's a good idea to make sure you have the right
>setup in place before doing so.
I have not hooked my NMR network to the internet because of these types
of problems.
For anyone interested in hooking NMR systems to the internet, regardless
of operating system used [there are holes in IRIX also which Dan Farmer
or Wietse Venema could describe to you in great detail], I have the following
general recommendations [note: some url's change name from time to
time. I've given the latest ones I have. Usually, a notice that a url's
contents have been moved to a new name is stored somewhere at the old
url, so if something's not there, look at a readme type file]:
1. Read Cheswick, W.R., and Bellovin, S.M., __Firewalls and Internet
Security__, Addison Wesley (1994)
2. Read Curry, D.A., __Improving the Security of Your Unix System__,
SRI International Report No. ITSTD-721-FR-90-21 (1990). Appendix A:
Security Checklist is very critical.
3. Get a copy of Farmer, D., and Venema, W., __Improving the Security
of Your Site by Breaking Into It__ from the url
ftp://ftp.win.tue.nl/pub/security/
4. Either do manually the tests suggested in the Farmer and Venema
article or get a copy of SATAN 1.1.1 from the same site [or secure mirror
thereof] to do them automatically. Or get ISS from the url
ftp://ftp.uu.net/usenet/comp.sources.misc/volume39/iss/
or the url ftp://aql.gatech.edu/pub/security/iss/
to do many, but not all, of the same tests.
5. Get the TAMU tiger scripts from Texas A&M Univ. through the url
ftp://net.tamu.edu/pub/security/TAMU/
and run this on each of your systems.
6. As an alternative to the tiger scripts, get COPS [Farmer and Spafford,
1990] from the url ftp://ftp.cert.org/pub/tools/cops/
and run this on each of your systems.
7. Get Crack [Alec Muffett of SUN] from the url
ftp://ftp.cert.org/pub/tools/crack/
and check your users' passwords against dictionaries from the url
ftp://sable.ox.ac.uk/pub/wordlists/
[this is a lot of dictionaries used by crossword puzzle fanatics]
[The Finnish dictionary used to crack quite a number of my users' passwords]
8. On NMR console host computers especially, I turn off the following
internet "services" because they either give out too much information
or they are too insecure to run. They can be turned off by halting inetd,
commenting out the lines in /etc/inetd.conf and restarting inetd [I just
routinely run without them on all my systems because I never use them
anyway.]
a. finger, systat, netstat, rusersd -- too much information
b. uucp, shell, exec, comsat, tftp, talk, rexd
c. mountd [run separately as daemon. doesn't need inetd invocations]
d. ypupdated --NIS [formerly called yellow pages] is an
invitation
to crackers which I refuse to run.
9. Comment out the initiation of sendmail in /etc/rc.local because of
sendmail bugs referenced in CERT and 8LGM reports. You can pick
up CERT advisories at the url ftp://info.cert.org/pub/
There's something called Mail.local.c which should be run instead of
/bin/mail on BSD 4.3 based unices such as Solaris 1.x
10. Eliminate all .rhosts files and maintain a strict policy of prohibition
of .rhosts It just gives exploitable holes. The NMR console should not
trust anybody outside the local NMR network, and that can be set in
hosts.equiv if you even really dare give that much trust.
11. NFS Export files read only and only to designated hosts if you NFS
export at all.
12. Get a good firewall with the capability of checking that messages from
outside your local NMR network are not masquerading as messages from
inside your local NMR network [called IP spoofing], and put it between
your local NMR network and your internet connection. This means that
the firewall will have two ports with two different IP addresses, one for
the inside, and another for the outside [sometimes called dual hosted].
Make sure IP forwarding is turned off when you set this up [requires
setting options "IPFORWARDING=0xffffffff" in the kernel configuration
file for Solaris 1.x, or the command ndd -set /dev/ip ip_forwarding 0
for Solaris 2.x. I don't know other *nixes well enough to know how
they do it.] Among other things your firewall should do is packet filtering.
Check the file tech_tips/packet_filtering for what IP port numbers to block
at the url ftp://ftp.cert.org/pub/tech_tips
13. Delete the "secure" entry for all devices listed in /etc/ttytab to compel
login from non-root accounts only thus forcing use of su with password
entry to gain root status. This gives you a log entry showing who last
tried to become root and helps you catch the would be cracker before
a successful break in.
14. The last line in your passwd file [/etc/passwd ] should read
-::::::
The last line of your group file [/etc/group ] should not have a + in it.
/etc/hosts.equiv should not have a + in it.
I'm sure I've forgotten to mention something important, so check the
references I've given for more information.
Also, it is helpful to read the usenet newsgroups comp.security.misc
comp.security.unix and comp.security.announce [CERT posts their
warnings and advisories in the announce group.]
I know this was long. I'm very sorry for that, but I hope it was helpful.
Sincerely,
-- Bruce D. Ray bray@indyvax.iupui.edu Operations Director NMR Center IUPUI Physics Dept. 402 N. Blackford St. Indianapolis, IN 46202-3273voice: 317-274-6914 fax: 317-274-2393