|
|
RPM is a software management tool originally created by Red Hat, and later GNU'ed and given to the public (http://www.rpm.org/). It forms the core of administration on most systems, since one of the major tasks for any administrator is installing and keeping software up to date. Various estimates place most of the blame for security break-ins on bad passwords, and old software with known vulnerabilities. This isn't exactly surprising one would think, but while the average server contains 200-400 software packages on average, one begins to see why keeping software up to date can be a major task.
The man page for RPM is pretty bad, there is no nice way of putting it. The book "Maximum RPM" (ISBN: 0-672-31105-4) on the other hand is really wonderful (freely available at http://www.rpm.org/ in post script format). I would suggest this book for any Red Hat administrator, and can say safely that it is required reading if you plan to build RPM packages. The basics of RPM are pretty self explanatory, packages come in an rpm format, with a simple filename convention:
package_name-package_version-rpm_build_version-architecture.rpm
nfs-server-2.2beta29-5.i386.rpm
would be “nfs-server”, version “2.2beta29” of “nfs-server”, the fifth build of that rpm (i.e. it has been packaged and built 5 times, minor modifications, changes in file locations, etc.), for the Intel architecture, and it’s an rpm file.
Command Function
-q Queries Packages / Database for info
-i Install software
-U Upgrades or Installs the software
-e Extracts the software from the system (removes)
-v be more Verbose
-h Hash marks, a.k.a. done-o-dial
Command Example |
Function |
rpm -ivh package.rpm |
Install 'package.rpm', be verbose, show hash marks |
rpm -Uvh package.rpm |
Upgrade 'package.rpm', be verbose, show hash marks |
rpm -qf /some/file |
Check which package owns a file |
rpm -qpi package.rpm |
Queries 'package.rpm', lists info |
rpm -qpl package.rpm |
Queries 'package.rpm', lists all files |
rpm -qa |
Queries RPM database lists all packages installed |
rpm -e package-name |
Removes 'package-name' from the system (as listed by rpm -qa) |
Red Hat Linux 5.1 shipped with 528 packages, and Red Hat Linux 5.2 shipped with
573, which when you think about it is a heck of a lot of software (SuSE 6.0
ships on 5 CD's, I haven’t bothered to count how many packages). Typically you
will end up with 2-300 packages installed (more apps on workstations, servers
tend to be leaner, but this is not always the case). So which of these should
you install and which should you avoid if possible (like the r services
packages). One thing I will say, the RPM's that ship with Red Hat distributions
are usually pretty good, and typically last 6-12 months before they are found to
be broken.
There is a list of URL's and mailing lists where distribution specific errata and updates are available later on in this document.
The Debian package system is a similar package to RPM, however lacks some of the functionality, although overall it does an excellent job of managing software packages on a system. Combined with the dselect utility (being phased out) you can connect to remote sites, scroll through the available packages, install them, run any configuration scripts needed (like say for gpm), all from the comfort of your console. The man page for dpkg "man dpkg" is quite extensive.
The general format of a Debian package file (.deb) is:
packagename_packageversion-debversion.deb
ncftp2_2.4.3-2.deb
Unlike rpm files .deb files are not labeled for architecture as well (not a big deal but something to be aware of).
Command Function:
-I Queries Package
-i Install software
-l List installed software (equiv. to rpm -qa)
-r Removes the software from the system
Command Example |
Function |
dpkg -i package.deb |
Install package.deb |
dpkg -I package.deb |
Lists info about package.deb (rpm -qpi) |
dpkg -c package.deb |
Lists all files in package.deb (rpm -qpl) |
dpkg -l |
Shows all installed packages |
dpkg -r package-name |
Removes 'package-name' from the system (as listed by dpkg -l) |
Debian has 1500+ packages available with the system. You will learn to love dpkg
(functionally it has everything necessary, I just miss a few of the bells and
whistles that rpm has, on the other hand dselect has some features I wish rpm
had).
There is a list of URL's and mailing lists where distribution specific errata is later on in this document.
Most modern Linux distributions use a package management system to install, keep track of and remove software on the system. There are however many exceptions, Slackware does not use a true package management system per se, but instead has precompiled tarballs (a compressed tar file containing files) that you simply unpack from the root directory to install, some of which have install script to handle any post install tasks such as adding a user. These packages can also be removed, but functions such as querying, comparing installed files against packages files (trying to find tampering, etc.) is pretty much not there. Or perhaps you want to try the latest copy of X, and no-one has yet gotten around to making a nice .rpm or .deb file, so you must grab the source code (also usually in a compressed tarball), unpack it and install it. This present no more real danger then a package as most tarballs have MD5 and/or PGP signatures associated with them you can download and check. The real security concern with these is the difficulty in sometimes tracking down whether or not you have a certain piece of software installed, determining the version, and then removing or upgrading it. I would advise against using tarballs if at all possible, if you must use them it is a good idea to make a list of files on the system before you install it, and one afterwards, and then compare them using 'diff' to find out what file it placed where. Simply run 'find /* > /filelist.txt' before and 'find /* > /filelist2.txt' after you install the tarball, and use 'diff -q /filelist.txt /filelist2.txt > /difflist.txt' to get a list of what changed. Alternatively a 'tar -tf blah.tar' will list the contents of the file, but like most tarballs you'll be running an executable install script/compiling and installing the software, so a simple file listing will not give you an accurate picture of what was installed or modified. Another method for keeping track of what you have installed via tar is to use a program such as ‘stow’, stow installs the package to a separate directory (/opt/stow/) for example and then creates links from the system to that directory as appropriate. Stow requires that you have Perl installed and is available from: http://www.gnu.ai.mit.edu/software/stow/stow.html.
Command |
Function |
tar -tf filename.tar |
Lists files in filename.tar |
tar -xf filename.tar |
Extracts files from filename.tar |
Something I thought I would cover semi-separately is checking the integrity of software that is retrieved from remote sites. Usually people don’t worry, but recently ftp.win.tue.nl was broken into, and the TCP_WRAPPERS package (among others) was trojaned. 59 downloads occurred before the site removed the offending packages and initiated damage control procedures. You should always check the integrity of files you download from remote sites, some day a major site will be broken into and a lot of people will suffer a lot of grief.
RPM packages can (and typically are) PGP signed by the author. This signature can be checked to ensure the package has not been tampered with or is a trojaned version. This is described in great deal in chapter 7 of “Maximum RPM” (online at http://www.rpm.org/), but consists of adding the developers keys to your public PGP keyring, and then using the –K option which will grab the appropriate key from the keyring and verify the signature. This way, to trojan a package and sign it correctly, they would have to steal the developers private PGP key and the password to unlock it, which should be near impossible.
dpkg supports MD5, so you must somehow get the MD5 signatures through a trusted channel (like PGP signed email). MD5 ships with most distributions.
Many tarballs are distributed with PGP signatures in separate ASCII files, to verify them add the developers key to your keyring and then use PGP with the –o option. This way to trojan a package and sign it correctly, they would have to steal the developers private PGP key and the password to unlock it, which should be near impossible. PGP for Linux is available from: ftp://ftp.replay.com/.
Another way of signing a package is to create an MD5 checksum. The reason MD5 would be used at all (since anyone could create a valid MD5 signature of a trojaned software package) is that MD5 is pretty much universal and not controlled by export laws. The weakness is you must somehow distribute the MD5 signatures in advance securely, and this is usually done via email when a package is announced (vendors such as Sun do this for patches).
There are a variety of tools available for automatic installation of rpm files.
AutoRPM is probably the best tool for keeping rpm’s up to date, simply put you point it at an ftp directory, and it downloads and installs any packages that are newer then the ones you have. Please keep in mind however if someone poisons your DNS cache you will be easily compromised, so make sure you use the ftp site’s IP address and not its name. Also you should consider pointing it at an internal ftp site with packages you have tested, and have tighter control over. AutoRPM requires that you install the libnet package Net::FTP for Perl and is available from: http://www.kaybee.org/~kirk/html/linux.html.
Rhlupdate will also connect to an ftp site and grab any needed updates, the same caveats apply as above, and again it requires that you install the libnet package Net::FTP for Perl and is available at: ftp://missinglink.darkorb.net/pub/rhlupdate/.
RpmWatch is a simple Perl script that will install updates for you, note it will not suck down the packages you need so you must mirror them locally, or make them accessible locally via something like NFS or CODA. RpmWatch is available from: http://www.iaehv.nl/users/grimaldo/info/scripts/.
dpkg has a very nice automated installer called ‘apt’, in addition to installing software it will also retrieve and install software required to fulfill dependencies, you can download it from: http://www.debian.org/Packages/stable/admin/apt.html.
No tools found, please tell me if you know of any (although beyond mirroring, automatically unpacking and running “./configure ; make ; make install”, nothing really comes to mind).
installwatch monitor what a program does, and logs any changes it makes to the system to syslog. Its similar to the “time” program in that it runs the program in a wrapped form so that it can monitor what happens, you run the program as “installwatch /usr/src/something/make” for example (optionally you can use the “–o filename” to log to a specific file). installwatch is available from: http://datanord.datanord.it/~pdemauro/installwatch/.
instmon is run before and after you install a tarball / tgz package (or any package for that matter). It generates a list of files changed that you can later use to undo any changes. It is available from: http://hal.csd.auth.gr/~vvas/instmon/.
Another way to deal with packages/etc. is to convert them. There are several utilities to convert rpm files to tarballs, rpm’s to deb’s, and so on.
alien is probably the best utility around for converting files, it handles rpm’s, deb’s and tarballs very well. You can download it from: http://kitenet.net/programs/alien/.
slurp takes an interesting approach, it behaves somewhat like installwatch, but also has some of the features of alien. It monitors the system as you install a package, and creates an rpm file from this. You can get slurp from: http://students.vassar.edu/~jajohnst/slurp/.
One major problem with Linux is finding software that did not ship with your distribution. Searching the Internet is a pain. There are some resources however that can ease the pain:
Linux is not susceptible to viruses in the same ways that a Dos/Windows or Mac platform is. In UNIX, security controls are a fundamental part of the operating system. For example users are not allowed to write promiscuously to any location in memory that they choose to, something that Dos/Windows and the Mac allow.
To be fair there are viruses for UNIX. However the only Linux one I have seen was called "bliss", had an uninstall option ("--uninstall-please") and had to be run as root to be effective. Or to quote an old Unix favorite "if you don't know what an executable does, don't run it as root". Worms are much more prevalent in the UNIX world, the first major occurrence being the Morris Internet worm which exploited a vulnerability in sendmail. Current Linux worms exploit broken versions of imapd, sendmail, WU-FTPD and other daemons. The simplest fix is to keep up to date and not make daemons accessible unless necessary. These attacks can be very successful especially if they find a network of hosts that are not up to date, but typically their effectiveness fades out as people upgrade their daemons. In general I would not specifically worry about these two items, and there is definitely no need to buy anti-virus software for Linux.
Worms have a long and proud tradition in the UNIX world, by exploiting known security holes (generally, very few exploit new/unknown holes) and replicating they can quickly mangle a network(s). There are several worms currently making their way around Linux machines, mostly exploiting old Bind 4.x and old IMAP software. Defeating them is as easy as keeping software up to date.
Trojan horses are also popular. Recently ftp.win.tue.nl was broken into and the TCP_WRAPPERS package (among others) was modified to email passwords to an anonymous account. This was detected when someone checked the PGP signature of the package and found that it wasn't quite kosher. Moral of the story? Use software from trusted sites, and check the PGP signature(s).
Back up your data, format and reinstall the system from known good media. Once an attacker has root on a Linux system they can literally do anything, from compromising gcc/egcs to loading interesting kernel modules at boot time. Do not run untrusted software as root. Check the PGP signatures on files you download, etc. An ounce of prevention will pretty much block the spread of viruses, worms and trojans under Linux.
The easiest method for dealing with viruses and the like is to use system integrity tools such as tripwire, L5, and Gog&Magog, you will be able to easily find which files have been compromised and restore/replace/update them. There are also many Anti-Virus scanners available for Linux (but generally speaking there aren’t any Linux viruses).
As stated above viruses aren’t a real concern in the Linux world, however virus scanners that run on Linux can be useful. Filtering email / other forms of content at the gateways to your network (everyone has Windows machines) can provide an extra line of defense since the platforms providing the defense against the threat cannot be compromised by that threat (hopefully). You may also wish to scan files stored on Linux file servers that are accessed by Windows clients. Luckily there are several good anti-virus programs available for Linux.
Sophos Anti-Virus is a commercial virus scanner that runs on a variety of Windows and UNIX platforms. It is free for personal use and relatively inexpensive for commercial use. You can get it at: http://www.sophos.com/.
AntiVir is another commercial virus scanner that runs on a variety of Windows platforms and Linux. You can get it from: http://www.hbedv.com/.
This whole guide exists because Linux and the software running on Linux systems is either insecurely written, or insecurely setup. Many issues, such as buffer overruns, are due to bad programming and carelessness. These problems become especially bad when the software in question is setuid to run as root, or any other privileged group. There are a variety of techniques, and other measures that can be taken to make software safer.
This document covers a variety of techniques to make programs more secure, as well as some pretty low level items like inherited trust, sharing credentials, and so on. This document is available at: http://www.whitefang.com/sup/ and I highly recommend reading it if you plan to program in Linux (or UNIX in general).
Secure Internet Programming (SIP) is a laboratory (for lack of a better word) that studies computer security, and more specifically problems with mobile code such as Java and ActiveX. They have a number of interesting projects going, and many publications online that make excellent reading. If you are going to be writing Java code I would say you have to visit this site: http://www.cs.princeton.edu/sip/.
|
Written by Kurt Seifried |