[LINK] Security of old RedHat systems
Robin Whittle
rw at firstpr.com.au
Mon Dec 13 18:21:31 EST 2004
Adam, if I put all my energy into the security of my computers I would
probably do a great job, and get a lot less done in other areas which
really matter to me. I am attracted to the idea of not fixing
non-broken things, and to the idea that maybe all the bugs had been
smoked out of whatever I am running, but it doesn't seem realistic.
I received detailed, really helpful, responses off-list from Howard
Lowndes, Craig Sanders, Stil and Glen Turner. Thanks very much for this
support! Here are some highlights:
Stil and Glen suggested the Fedora Legacy program:
http://www.fedoralegacy.org
which provides free updates for RH 9.0, using a program called "yum" or
the more complex "apt".
I am setting this up on my local machine and if all is well, will do the
same on my San Francisco machine.
FedoraLegacy.org supports RH 7.3 but not 7.2.
I understand I can upgrade my 7.2 system using the 7.3 CD-ROMs, which I
have, and there is a fair chance that the whole system will work pretty
well. I have never tried this, but it seems like a good approach now,
after doing a complete bootable clone of the hard drive(s), which is my
standard backup practice anyway. (I boot from the RH 7.3 installation
CD-ROM and use "cat /dev/hda > /dev/hdc".)
"yum" can use a proxy server, as did up2date, but the details are in a
shell variable, rather than the config file:
http_proxy="http://123.45.67.89:6588"; export http_proxy
yum update
I configured it to update the kernel too.
Dependencies resolved
I will do the following:
[install: kernel 2.4.20-37.9.legacy.i686]
[update: cups 1:1.1.17-13.3.0.6.legacy.i386]
[update: samba-client 2.2.12-0.90.2.legacy.i386]
[update: samba-common 2.2.12-0.90.2.legacy.i386]
[update: php 4.2.2-17.7.legacy.i386]
[update: libpng10 1.0.13-11.i386]
[update: ethereal 0.10.3-0.90.4.legacy.i386]
[update: cups-libs 1:1.1.17-13.3.0.6.legacy.i386]
[update: httpd-manual 2.0.40-21.17.legacy.i386]
[update: lha 1.14i-9.4.legacy.i386]
[update: sysklogd 1.4.1-14.legacy.9.i386]
[update: libpng10-devel 1.0.13-11.i386]
[update: utempter 0.5.5-2.RHL9.0.i386]
[update: mozilla-mail 37:1.4.3-0.9.1.legacy.i386]
[update: php-mysql 4.2.2-17.7.legacy.i386]
[update: netpbm-devel 9.24-10.90.3.legacy.i386]
[update: mozilla-nspr 37:1.4.3-0.9.1.legacy.i386]
[update: samba 2.2.12-0.90.2.legacy.i386]
[update: netpbm 9.24-10.90.3.legacy.i386]
[update: mozilla-nss 37:1.4.3-0.9.1.legacy.i386]
[update: mozilla 37:1.4.3-0.9.1.legacy.i386]
[update: cvs 1.11.2-24.legacy.i386]
[update: mc 1:4.6.0-14.9.i386]
[update: libpng-devel 2:1.2.2-20.i386]
[update: tcpdump 14:3.7.2-7.9.3.legacy.i386]
[update: netpbm-progs 9.24-10.90.3.legacy.i386]
[update: php-ldap 4.2.2-17.7.legacy.i386]
[update: rsync 2.5.7-2.legacy.9.i386]
[update: httpd 2.0.40-21.17.legacy.i386]
[update: tripwire 2.3.1-17.2.legacy.9.i386] <<<
[update: libpng 2:1.2.2-20.i386]
[update: mod_ssl 1:2.0.40-21.17.legacy.i386]
[update: libpcap 14:0.7.2-7.9.3.legacy.i386]
[update: php-imap 4.2.2-17.7.legacy.i386]
It sucks when a computer program uses "I" either to refer to itself or
to the person using the computer.
There's lots of stuff to update. I rebooted and everything seems to be
fine (though I haven't really tested much), running the new kernel by
default. (/boot/grub/grub.conf)
At present I don't need bleeding edge software, so for now, I would
prefer to keep existing systems going rather then upgrading them
(reinstalling completely?) to Fedora http://fedora.redhat.com. Fedora
has a relatively short lifetime (18 months from release to end of
security updates) and I would be happy to get another two or more years
from the existing systems if I can.
I can't upgrade the http://www.servepath.com San Francisco RH 9.0 server
- it is a live machine I can't physically access. Perhaps I will rent a
second server, with Free BSD or a recent Debian installation, and spend
some time configuring it and copying data before ending the rental on
the current server.
Howard wrote:
> If you have Tripwire locked down tight then that is a good move.
> I assume your base reference files are on RO media.
These machines don't have any read only storage.
The Tripwire executable is in an unusual place with a different name, so
a hacker would need to search every file by its content to find the
Tripwire binary to replace with a hacked version. The database Tripwire
keeps of the reference directory structure and MD5 hashes for existing
files is, as far as I know, readable by the Tripwire program but cannot
be written in a valid manner except with a matching key, which Tripwire
generates and stores. The key for writing the database is protected by
a passphrase which only I know. So as far as I know, it is impossible
for a hacker to generate or alter this database file in a way that
Tripwire will decipher without problems. I haven't scrutinised all
this, but the code is open source and I assume it is well written:
http://www.tripwire.org http://sourceforge.net/projects/tripwire/
I am using version 2.3.1-17 on the RH 9.0 machines and 2.3.1-5 on the RH
7.2 machine. Nothing much seems to have changed since 2001.
The current "stable" version of Debian is 3.0 "Woody" which was released
in July 2002:
http://www.debian.org/releases/
Craig Sanders wrote that the current "testing" version is nearing
completion to be the next "stable" version - to be called "sarge". I
guess that whenever this is released, I will be tempted to install it on
my desktop machine.
For the local mailserver (nameserver, webserver etc.) machine and for
the San Francisco server, I guess a minimal Debian installation, or
FreeBSD (Servepath can do either) or NetBSD would be good.
I understand that NetBSD is very highly respected. I haven't
investigated the arguments for and against NetBSD, FreeBSD and OpenBSD.
There's a stupendous graphic history of Unix at
http://www.levenez.com/unix/
Maybe a place to compare notes on the BSDunices is:
http://www.freebsdforums.org
A new version NetBSD 2.0 was released a few days ago:
http://www.netbsd.org/Releases/formal-2.0/
NetBSD 2.0 enforces non-executable mappings on many platforms. This
means that the process stack and heap mappings are non-executable
by default, making exploitation of potential buffer overflows
harder.
I don't know if this would work for x86 systems, but it would greatly
reduce the vulnerability of the system. It is my impression that buffer
overflows enabling execution of code supplied by the attacker are the
greatest single kind of security vulnerability in otherwise well-written
software.
I haven't done totally organised packet filtering (also known, loosely
and I suspect incorrectly as a "firewall") on the RH 9.0 machines.
Craig suggested that beyond such filtering/firewalling that I could
implement "port-knocking":
http://www.google.com.au/search?hl=en&q=tcp+port+knocking
http://www.portknocking.org/view/primer
All connections to services such as SSH are blocked, except for IP
addresses from which a sequence of "port-knocking" packets have recently
been received. The firewall (or filter or whatever) looks for a
pre-arranged, secret, sequence of properly formatted packets being sent
to a particular sequence of TCP (I guess, rather than UDP) ports and
then makes the SSH port available for packets from that IP address.
This is analogous to pressing or dialling numbers on a combination lock.
Craig wrote that the large number of RH 7.2, 7.3 and 9.0 servers means
that whatever faults lie within them will be found and exploited
eventually. The list of updates above makes it clear there are problems
to be found.
My nameserver is bind and MTA (Message Transfer Agent, the "mailserver")
is Postfix, with Courier IMAP, Courier Maildrop for mail filtering, and
an older version of the relatively obscure Postman Web-mail system:
http://www.firstpr.com.au/web-mail/
Backup from one local machine to the other is via a cron job and script
to tar-gz files and write them via NFS to the other machine. NFS and
SAMBA is set up to operate only over the local network, and I use packet
filtering on the Telstra connection to stop NFS and SAMBA access from
the outside.
X on the desktop RH 9.0 machine is probably open for access over the LAN
(XDMCP).
I haven't completely sorted out what services are available on my
machines. I don't have any printers attached, and maybe I should find
out what "lpr" is and disable it.
Glen Turner advised that I should protect against attacks run from local
user accounts - because many attacks gain normal user access, and then
use a second exploit to upgrade this to root. I agree with this and all
the other advice I have noted above.
Glen suggested looking at two repackagings of the costly Red Hat
Enterprise Linux:
CentOS http://www.caosity.org/projects/centos
Whitebox http://whiteboxlinux.org
Thanks again!
- Robin http://www.firstpr.com.au
More information about the Link
mailing list