Good Linux Security Practices
By adhering to some simple rules, you can decrease your chance of
having your linux box compromised. Don't wait to get burned.
- How to stay up-to-date on RH-Ath security patches (eg, sub to
linux-announce, etc)
- Whether or not to keep a linux box online 24-7 (eg, if remote
access not necessary)
- Why not to use old Slackware
- Consequences of having local non-kerberized accounts
(cleartext passwords)
- When, why, and how to get a srvtab (not everyone reads the
linux-athena doc)
sit's notes on Slackware problems:
Unfortunately, linux-dev no longer supports Slackware in any way shape
or form. When we introduced RedHat-Athena last year, we encouraged
people to upgrade and we told them Slackware was bad. The Slackware
security issue was briefly discussed at a meeting Monday. The decision was
basically a confirmation of the existing policy --- no help will be
given to Slackware users. It would be too much work to come up with some
equivalent of update.pl for Slackware. There is surely documentation on
securing (Linux) machines out there on the net which will just as
applicable to Athena-ized Slackware machines.
Taking off the linux-dev hat, I feel that it is important that
Next House residents are made aware of this. goblin has already notified
users of his machine that they should change their password but there
are doubtless others who have been compromised and not been notified.
Mail should be sent to next house residents with some appropriately
dire warnings. I would be willing to draft/send this letter if needed.
(Or, I can provide the address to use to the person who will be writing
the letter.) I also think it might even be worth it to send mail to
netusers mentioning this problem.
nygren's comments on slackware breakins
Over the past few weeks, I've heard reports of a number of break-ins
to Linux machines on campus. This is substantial increase over
break-in reports I've heard of in any previous period.
The pattern seems to be:
* User logs in insecurely over the net
* Someone logs in using the sniffed password as the user
* I'd guess that the attacker then tried to get root
access using some security holes
* Once root access is obtained, a sniffer is installed
* Iterate
I haven't seen any evidence of anything other than the first through
stages (I've only had one attacked machine to look at and I couldn't
find anything suspicious).
We may want to try collecting statistics and mounting a campaign to
find out what security holes are being exploited. We should
also do more to educate users about the dangers of sending their
password over the net in the clear.
Kevin's message on how people break slackware boxes
Recently several old Slackware machines on MITNet have been
compromised. The method is always the same. Most slackware machine
owners are not even aware of the potential problems.
Should we take the inititive to warn Slackware users and to
convince these users to switch to RedHat...or at least
fix affected binaries?
The quinessential attack:
1.) Sniff password
2.) Login to a machine, oh gee it's slackware
3.) Download souce from www.rootshell.com
4.) Compile
5.) Overflow SUID root programs su, ping, SuperProbe, etc
6.) Run a sniffer, snarf data, goto step 1.
amu on how to keep up-to-date on RH security patches
Red Hat usually releases updated packages in response to news of
security holes. If you are running Red Hat-Athena 4.0 (the latest
released version), you can run
/mit/linux/redhat/redhat-4.0.0/i386/updates/update.pl
periodically to install the updates.
ftp://ds.internic.net/rfc/rfc2196.txt for the Site Security Handbook
for administrators.
gangan on fake email problems
Hi,
When my PC is running Linux (Redhat Athena), apparently, my friend was
able to send ficticious emails in my email address off the Linux mail
server (what ever it is), ie the email appears as if it was sent by me from
my machine. He is also able to telnet into my machine, ie it becomes a
public server?? How can I restrict telnet accesses and prevent my machine
from being used as a mail server by others? I'm new to Linux, so detailed
instructions will be appreciated.
Terence
drapper's response:
To: Terence Gan
Cc: linux-help@MIT.EDU
Subject: Re: Security problems
In-Reply-To: Your message of "Fri, 19 Sep 1997 13:31:41 EDT."
<3.0.2.32.19970919133141.00dc5b70@po7.mit.edu>
Date: Fri, 19 Sep 1997 14:58:42 EDT
Well I am not that experienced, but one could either change
the port of default telnet in /etc/services file or even better
install tcp_wrappers and then use IP checking though /etc/hosts.allow
and /etc/hosts.deny to enable or disable telnet access to your
machine.
The fact that he sent email from your machine is probably done
because you have telnet port 25 enabled. For more help use man
inetd.conf and hosts.allow. For the beggining I would suggest
installing tcp_Wrappers (I think they are installed by default when
you chose Athena Redhat installation). Then find the following line in
your /etc/inetd.conf file:
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
And replace it by:
telnet stream tcp nowait root /usr/sbin/tcpd /etc/athena/telnetd -a
off
After that edit /etc/hosts.allow and /etc/hosts.deny entering the IP
addresses you would/wouldn't like to access your machine
Nick
More notes on RH security patches:
Red Hat recently released more packages to fix some security holes.
If you are running Red Hat-Athena 4.2 (which is still in beta; please
be patient), you should upgrade manually to the latest packages in
/mit/linux/redhat/redhat-4.2/i386/updates.
If you are running Red Hat-Athena 4.0.0, you should attach linux and
run /mit/linux/redhat/redhat-4.0.0/i386/updates/update.pl as root,
especially if you haven't lately. Note that running this may destroy
local customizations; if you wish to preserve them, you should copy
your versions of the files in question somewhere safe first. You
should also edit /etc/inetd.conf and put a # at the beginning of the
line that starts "finger". (There's a known hole in the finger
daemon, but Red Hat hasn't released a version of the appropriate
package that works with 4.0.0.) Finally, you should reboot for all
changes to take effect.
If you are running anything else, we recommend that you upgrade to Red
Hat-Athena 4.0.0 and then follow the above procedure.
If you have a Red Hat-based system, you can determine which version
you're running by viewing /etc/redhat-release.
Thank you.
To: linux-announce@MIT.EDU
Subject: Re: update script reminder
References:
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: amu@MIT.EDU (Aaron M. Ucko)
Date: 23 Sep 1997 01:55:13 -0400
In-Reply-To: amu@MIT.EDU's message of "23 Sep 1997 00:01:11 -0400"
Message-Id:
Lines: 18
X-Mailer: Gnus v5.5/Emacs 20.1
amu@MIT.EDU (Aaron M. Ucko) writes:
> should also edit /etc/inetd.conf and put a # at the beginning of the
> line that starts "finger". (There's a known hole in the finger
> daemon, but Red Hat hasn't released a version of the appropriate
> package that works with 4.0.0.) Finally, you should reboot for all
It seems that the finger security hole only occurs when /etc/passwd
doesn't have an entry for nobody, so you don't need to disable finger
after all; just add
nobody:*:99:99:Nobody:/:/bin/false
to /etc/passwd (and /etc/passwd.local if present) if no line in it
starts "nobody:". I apologize for that false alarm.
To: Bryan W Che
Cc: linux-help@MIT.EDU
Subject: Re: linux question
References: <199709290330.XAA13207@PIGTAIL.MIT.EDU>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: amu@MIT.EDU (Aaron M. Ucko)
Date: 28 Sep 1997 23:40:26 -0400
In-Reply-To: Bryan W Che's message of "Sun, 28 Sep 1997 23:30:42 EDT"
Message-Id:
Lines: 16
X-Mailer: Gnus v5.5/Emacs 20.1
Bryan W Che writes:
> Hi, I was just wondering: Are the only ways to gain root access on
> a linux box (1) to login as root at the terminal (2) telnet to the
> machine as a user and then type "su"?
No. If root has a .klogin file listing kerberos principals, people
with tickets for those principals can rlogin to your machine as root
without a password; if you choose to do this, I *strongly* recommend
that you ask accounts for a root instance
(i.e. bryanche.root@ATHENA.MIT.EDU; case matters) and list that rather
than your null instance in the .klogin. Additionally, machines may
have security holes people can exploit to gain root access.
--
Aaron M. Ucko (finger amu@monk.mit.edu) [Stark raving sane]