In Dec 98 Charlie Fry posted an (excellent) summary of computer
security issues. I implemented many of them, but due to problems
this summer, had to re-visit the issue. After re-loading software
from tape, I tightened security even more.
1) Installed all new SGI patches (not really possible for 5.3)
2) Installed tcp wrappers. This turned out to be surprisingly
easy. A person from the computer center came over and did it on one
system, and then I installed it on the others. He didn't tell me
where he got the code from ("do a web search") but we did the
default installation, and it has already repelled an invader. With
tcp wrappers, you can give the system a list of specific names/ips
to allow connection to. All others get a "connection refused"
message. At the moment I allow connection from all .unm.edu
systems- that may change if necessary. Installation took less than
15 minutes- including rebooting the computer. I really recommend
this.
3) Make a "live" backup of SYSLOG. Every time something is written
to SYSLOG, it is also written to another file. There are ways (not
implemented) to hide this file. This step was done so that if my
"friend" came back, and got in, he/she/it could not erase records.
4) Close down even more stuff from /etc/inetd.conf
#ftp stream tcp nowait root /usr/etc/tcpd /usr/etc/ftpd
-l
ftp is turned off on spectrometers, left on on the data station -
but protected by tcp
telnet stream tcp nowait root /usr/etc/tcpd
/usr/etc/telnetd
on (too useful to turn off) but with tcp
#shell
#login
#exec
#finger
#http
#wn-http
all of these are off as I don't need rlogin type stuff, and
these are not webservers
bootp
off on data station, I have it on for spectrometers, since
the acquision computer boots off the
main computer. (I haven't tried turning it off.)
tftp
comp center said to leave this on
#ntalk
tcpmux
again, suggested to leave this on
#echo
#discard
#chargen
#daytime
#time
not needed
sgi-dgl
don't know
#uucp
major security hole
mountd/1
sgi_mountd/1
rstatd/1-3
I cross mount disks all over the place, so I think I need
these.
#walld/1
#rusersd/1
#rquotad/1
#sprayd/1
bootparam/1
internal, so should be OK?
#ypupdated/1
#rexd/1
#sgi_videod/1
sgi_fam/1
I tried turning this off. Not a good idea.
#sgi_toolkitbus/1
sgi_snoopd/1
#sgi_pcsd/1
sgi_pod/1
sgi_xfsmd/1
tcpmux/sgi_scanner
tcpmux/sgi_printer
I don't know about these.
5) I have secure shell on my pc, not not yet on the SGIs.
6) I have run "crack" (passwd cracking program) in the past. I am
not now, because the last thing I want an intruder to get is a list
of cracked passwds- although when running it I check output daily
and change offending passwds on the spot. Users must come to me to
be allowed to change their passwd (after a security lecture.)
Break-ins: In July, someone go into the two SGIs running 6.2. I
discovered this because I was logged on as me, and needed to be
God. I typed "su" and I was God- no passwd needed. It turns out
that my intruder had modified /.rhosts to be ++ this allows (among
other things) god privileges to any legal user without knowing root
passwd. As far as I could determine, all that had been done was to
edit (not erase) SYSLOG to remove the records of his/her/its
connection. The comp center suggested a "buffer overflow" trap
as the entryway (whatever buffer overflow means). I changed
/.rhosts back to normal and went on vacation.
Both 6.2 SGIs crashed while I was away, and had to be power-cycle
rebooted.
When I returned, I logged onto one of the systems as root, and "had
mail" Since I have cron jobs running I expected mail. What I had
was hundreds, if not thousands, of messages about "bind address in
use". Also, SYSLOG had a line every minute for almost two weeks
with the same error message. Investigation found: /.rhosts
modified again; cron/root erased(!!) and replaced with one line:
to start rpc.ilisten (whatever that is) every minute; SYSLOG edited;
rpc.ilisten and rpc.irix installed in /etc/bin and that is about
it. I took reloaded software from tape (risky, but the tape was
from April, well before this started), took them off the internet,
and did the above security things.
I have had one "probe" since then- but I don't think it was my old
"friend". (It tried all three systems, and the above stuff was done
only to 6.2, not 5.3) The comp center person does not feel that
this was a "smart" hacker- just someone with a "smart" script. I
can think of several ways he could have used my systems for a long
time without me noticing- but I won't post them. Editing SYSLOG was
a cute trick- and the reason we are making a copy. Again, I won't
post what exactly we did, but it only took about 2 minutes. With a
hidden copy, we may be able to trace him if he gets in again.
Today's lesson: there are always new scripts and new ways for them
to get in. Eternal vigilance and all that: (I check the systems
almost daily now.)
Karen Ann
-- Karen Ann Smith karenann@unm.edu Manager, NMR Facility Adj. Asst. Prof. Dept. of Chemistry Clark Hall University of New Mexico Albuquerque, NM 87131 505.277.4031 url: http://www.unm.edu/~karenann Want an out-of-this-world screen-saver? Join SETI at home and harness your unused cpu! http://setiathome.ssl.berkeley.edu/ "Something that has a one-in-a-million chance of happening... happens once every second at 1 MHz."