[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
19990625: next mcidasx terminal + security
- Subject: 19990625: next mcidasx terminal + security
- Date: Mon, 28 Jun 1999 09:30:30 -0600
Hi Alan,
On Jun 25, 3:45pm, Unidata Support wrote:
> Subject: 19990625: next mcidasx terminal + security
> >From: alan anderson <address@hidden>
> >Organization: St. Cloud State
> >Keywords: 199906252026.OAA25997 McIDAS Solaris x86
>
> >Also, my campus system person noted that there have been several breakins
> >by hackers to machines on our campus recently and asked "what are you guys
> >doing about security?"
Probably the easiest and best way to dramatically improve your system
security is to comment all unnecessary services in /etc/inetd.conf. We
have commented all but the following lines originally in the file;
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
shell stream tcp nowait root /usr/sbin/tcpd in.rshd
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
You note that the sixth field is modified from the original to include
what is commonly referred to as TCP wrappers. Their primary purpose is
to limit which hosts can even connect to these services listed above.
Most of our systems can only receive connections from our local network.
Be sure not to comment the mcidas adde stuff if you use it!
Other possibilities include moving/modifying files in /etc/rc{2,3}.d
to reduce the number of running programs. This also has the side
effect of reducing system load. For example in /etc/rc3.d, I move
both S76snmpdx and S77dmi to another file name. As long as they don't
begin with "S", the programs won't start, so you could move S77dmi to
OLD_S77dmi. In /etc/rc2.d, I move S85power and modify the sendmail
configuration to remove the "-bd" flag. This will allow for outgoing
mail, but not incoming. This works for us since we receive all our
email on a central server.
Let me know if you are interested and I will create a tar file that
would include the required binaries and sample configuration files.
> >As you might guess, my department has not been doing
> >anything about this. I know there is a potential for very bad things to
> >happen, but what should we be doing?
>
> o keeping up on OS patches
> o developing a program to change account passwords on a regular basis
> o keeping the numbers of people that have root access limited (but
> you can trust us :-)
As Tom mentioned, keeping an eye on patches is helpful. If you are mostly
worried about outsiders causing a problem, TCP wrappers will solve most of
your problem. Since you are on a campus network, you may have an internal
problem to deal with too... Keeping tight control over account access
should solve most of that problem. Making sure that your network is
secure is probably the largest problem you would have with students.
It is possible that someone can plug into your network and watch the
information packets going by on the wire. This is the easiest way to steal
passwords since they are mostly un-encrypted.
> >Is there software available to provide protection?
>
> The OS has a number of things already built in. As to whether or not
> you would want to install a firewall, I will have to defer to our
> system administrator, Mike Schmidt.
Lots and lots of software, but the above should solve most of the problem.
Let me know if I can be of any assistance.
mike