[When last I checked, the HOWTO maintainers were continuing
ignore _all_ of these corrections. -- RM]
Hello, guys. You may remember me as the fellow who pointed out
integrity-checker (http://www.cs.tut.fi/~rammer/aide.html) for the
, you guys
state: "You can find the open sourced version of Tripwire at
http://www.tripwire.org ...." Um, no, you cannot. Tripwire remains
a PROPRIETARY product, with a _viewable-source_ (as opposed to open
source) licence. This _may_ change, but the signs aren't good.
I therefore hope you will revise the Security HOWTO, to remedy
impression it gives to the contrary.
 To update the above e-mail: Late in the year 2000,
released a new version of Tripwire under the GNU GPL. Unfortunately,
it turned out to be a poorly portable C++ hairball with no autoconf
support, which accounts in part for the contining popularity of AIDE
and another GPLed newcomer, Integrit.
The list below ended up being a lot longer than I expected. If
like me to just edit your LinuxDoc or DocBook originals, I could --
just after I finish a distribution roundup for Marjorie Richardson.
(Below, quotations from the HOWTO are indented. Comments
-- Rick M.
3.3 Boot Loader Security lilo password option: You might want to add that /etc/lilo.conf should be set to permissions "600", if you use this. 3.5 Detecting Physical Security Compromises The first thing to always note is when your machine was rebooted. Might want to suggest that the sysadmin's .bash_profile include invoking "uptime". Make sure you remove inactive accounts A few words about how to identify inactive accounts (e.g., using /usr/bin/lastlog) would be helpful, here. Be aware when/where they login from, or should be logging in from. You can suggest they control this using hosts.allow & hosts.deny, including the need to compile sshd to use libwrap. (I see you cover this in section 8.2.) 4.2 Root Security Provide your users with a default alias to the rm command to ask for confirmation for deletion of files. You know, personally, I would have included this suggestion only to stress what a _bad idea_ it is. Users become accustomed to the alias, and then suffer disaster when they work in an environment that lacks it. Never use the rlogin/rsh/rexec suite of tools (called the r-utilities) as root. They are subject to many sorts of attacks, and are downright dangerous when run as root. Never create a .rhosts file for root. Just a thought: I'm considering adding a line to /usr/sbin/adduser, to create a root-owned, zero-length .rhosts file in new users' directories. This is useful for sites whose security policy classes the r-utilities as too dangerous for any user. (I like your PAM trick, section, 6.5, to do the same thing. Neat!) Any program that offers a shell escape will give root access to a user invoking it via sudo. An anecdote about sudo: At Linuxcare, when we rebuilt some of the servers, one of my sysadmins told me I had no need to possess the root passwords. (I was his boss.) I gave him a funny look, but he was right: /etc/sudoers gave me the right to do anything necessary, while maintaining a superior record of what everyone did as root. So, sudo _definitely_ provides accountability benefits even on processes having shell escapes. There should never be a reason for users' home directories to allow SUID/SGID programs to be run from there. Use the nosuid option in /etc/fstab for partitions that are writable by others than root. You may also wish to use nodev and noexec on users' home partitions, as well as /var, thus prohibiting execution of programs, and creation of character or block devices, which should never be necessary anyway. There are other directories you (arguably) missed. Here's my /etc/fstab: # /etc/fstab: static file system information. # #
/dev/sda2 / ext2 defaults,errors=remount-ro 0 1 /dev/sdb3 none swap sw 0 0 proc /proc proc defaults 0 0 /dev/sda1 /boot ext2 ro,noauto,nouser,noexec,nosuid,nodev 0 2 /dev/sda3 /usr ext2 ro,nodev 0 2 /dev/sda4 /usr/local ext2 defaults 0 2 /dev/sdb1 /var ext2 rw,nosuid,nodev 0 2 /dev/sdb2 /tmp ext2 rw,nosuid,nodev 0 2 /dev/sdb4 /home ext2 rw,nosuid,nodev 0 2 /dev/fd0 /mnt/floppy ext2 noauto 0 0 I would argue against noexec for /home, as users should be entitled to populate ~/bin. Set filesystem limits instead of allowing unlimited as is the default. You can control the per-user limits using the resource-limits PAM module and /etc/pam.d/limits.conf. Setting limits via /etc/login.defs provides the exact same facilities. 5.3 Integrity Checking Another very good way to detect local (and also network) attacks on your system is to run an integrity checker like Tripwire, Aide or Osiris. These integrety checkers ^ Typo alert. It also repeats, three paragraphs further on. 5.4 Trojan Horses "Trojan Horses" are named after the fabled ploy in Homer's "Iliad". The idea is that a cracker distributes a program or binary that sounds great, and encourages other people to download it and run it as root. Then the program can compromise their system while they are not paying attention. While they think the binary they just pulled down does one thing (and it might very well), it also compromises their security. You should take care of what programs you install on your machine. Redhat provides MD5 checksums and PGP signatures on it's RPM ^ Typo alert: You mean "its". 6.1 PGP and Public-Key Cryptography [...] There is a project working on a free re-implementation of pgp with open source. GnuPG is a complete and free replacement for PGP. Because it does not use IDEA or RSA it can be used without any restrictions. GnuPG is nearly in compliance with OpenPGP. It is fully in compliance with OpenPGP, and has reached version 1.0 without exaggeration. You can thus probably stop referring to it as "a project working on". 6.2 SSL, S-HTTP, HTTPS and S/MIME It might be worth mentioning that _any_ network protocol can be retrofitted with SSL, including, say, POP3, using Rick Kaseguma's sslwrap utility. It calls Eric Young's ssleay libarry. http://www.rickk.com/sslwrap/ Also, somewhere in the HOWTO, you should consider mentioning that Security Dynamics's USA patent on the RSA algorithm expires on 2000-09-20, which will improve the USA legal climate for SSL, SSH, RC5, https, S/MIME, and probably a number of other things. 6.3 Linux IPSEC Implementations As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions. As of the 2000-01-14 Export Administration Regulations amendments, it's legal again, and the USA kernel.org sites now carry some crypto. But it might be worth mentioning that some crypto kernel patches are available only at ftp://ftp.kerneli.org/pub/linux/kerneli/net-source/, and 2.2 and earlier International Kernel Patches in directories off ftp://ftp.kerneli.org/pub/linux/kerneli/ (I see you do mention the related Web page in section 7.) 6.4 ssh (Secure Shell) and stelnet ssh and stelnet are suite's of programs ^ Typo alert: You mean "suites". There are several ssh implementiations now. The original commercial implementation by Data Fellows can be found at The ssh home page can be found at http://www.datafellows.com. ^ Typo alert. The excellent Openssh implementation is based on a early version of the datafellows ssh and has been totally reworked to not include any patented or propriatary peices. It is free and under a BSD liscence. ^ ^ ^ Typo typo typo. ;-> You can also use ssh from your Windows workstation to your Linux ssh server. There are several freely available Windows client implementations, I have a list of all known versions (server and client) for all platforms, at http://linuxmafia.com/pub/linux/security/ssh-clients 6.11 X11, SVGA and display security [...] You can also use ssh (see ssh , above) to allow secure X connections. It might be worth mentioning that a non-root user can run X programs as root by first sshing to root@localhost. ssh X-forwarding works even there! 7.2 2.2 Kernel Compile Options You realise you're soon going to need a section on netfilter/iptables, right? Want me to write one? 8.2 System services and tcp_wrappers [...] If you know you are not going to use some particular package, you can also delete it entirely. rpm -e packagename under the Red Hat distribution will erase an entire package. Under debian dpkg --remove does the same thing. ^ ^ Typo alert. You mean "Debian, ". You should check /etc/rc.d/rc[0-9].d (on Red Hat; /etc/rc[0-9].d on Debian), and see if any of the servers started in those directories are not needed. The files in those directories are actually symbolic links to files in the directory /etc/rc.d/init.d (on Red Hat; /etc/init.d on Debian). Renaming the files in the init.d directory disables all the symbolic links that point to that file. If you only wish to disable a service for a particular run level, rename the appropriate symbolic link by replacing the upper-case S with a lower-case s, like this: That's exactly what I do. Red Hat now tells admins to use chkconfig, which disables by turning S into K, enables by turning K into S -- in all applicable runlevels. I prefer your method, but you should be aware of what those guys are doing lately. Most Linux distributions ship with tcp_wrappers "wrapping" all your TCP services. Again, if admins add new services such as sshd, they may want to configure the source tree to include libwrap (and PAM support). 8.9 NIS (Network Information Service) (formerly YP). [...] There is a much more secure replacement for NIS, called NIS+. Yes, but there isn't _really_ NIS+ support for Linux. What little is in glibc2.1 isn't in any way a decent NIS+ implementation. I came up with a secure and satisfactory replacement for NIS/NIS+ at Linuxcare: Set up a master reference /etc/passwd /etc/shadow, /etc/group set on a designated machine (with backup), and then propagate it out to all other machines via rsync over ssh. Replace /usr/bin/passwd with a wrapper that ssh'es to the master machine, runs _its_ /usr/bin/passwd, and then forces an rsync update to all machines. (There were a few other utilities that had to be replaced with similar wrappers, including chfn and chsh.) rsync's efficiency makes this practical. 9.1 Make a Full Backup of Your Machine [...] If you have less than 650mb of data to store on a partition, a CD-R copy of your data is a good way to go But only if you have a spare 650 MB partition to build the ISO9660 image file. People tend to overlook that. Also, any backup regimen needs periodic test restores. This should be mentioned. 9.2 Choosing a Good Backup Schedule A six-tape cycle is easy to maintain. This includes four tapes for during the week, one tape for even Fridays, and one tape for odd Fridays. Perform an incremental backup every day, and a full backup on the appropriate Friday tape. If you make some particularly important changes or add some important data to your system, a full backup might well be in order. I'd strongly recommend differential backups over incremental ones. With your incremental scheme, the Thursday tape is useless if the Monday, Tuesday, _or_ Wednesday tape has a defect. And so on. 9.3 Backup Your RPM or Debian File Database FYI, the Debian equivalent of /var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm is /var/lib/dpkg/status . It's an ASCII text file (and easy to repair if necessary, by the way). 13. Frequently Asked Questions [...] However, in order to load modules, you must be root. The module object files are also only writable by root. This means the intruder would need root access to insert a module. If the intruder gains root access, there are more serious things to worry about than whether he will load a module. I believe the main concern is that the cracker's processes might become _undetectable_ if implemented as substitutes for real kernel modules. 2. Why does logging in as root from a remote machine always fail? Answer: See Root Security. This is done intentionally to prevent remote users from attempting to connect via telnet to your machine as root, which is a serious security vulnerability, because then the root password would be transmitted, in cleartext, across the network. That's not it: If the user telnets in as a non-root user and su's to root, the root password will _still_ be transmitted in cleartext across the network. The real reason is to ensure that a record is kept of which remote username became root, by forcing the two-step process described above. Of course, cautious admins will ssh in rather than telnet in -- and disable root-user ssh access in /etc/sshd_config . 3.How do I enable shadow passwords on my Red Hat 4.2 or 5.x Linux box? Answer: To enable shadow passwords, run pwconv as root, pwconv and pwunconv are _not_ Red Hat-specific. They exist for (as far as I know) all distributions. 4.How can I enable the Apache SSL extensions? Good news! You can remove the references to (specifically) Apache 1.2.5, as your method is valid for later versions, as well. 5.How can I manipulate user accounts, and still retain security? Answer: The Red Hat distribution, especially RH5.0, contains a great number of tools to change the properties of user accounts. o The pwconv and unpwconv programs can be used to convert between shadow and non-shadowed passwords. o The pwck and grpck programs can be used to verify proper organization of the passwd and group files. o The useradd, usermod, and userdel programs can be used to add, delete and modify user accounts. The groupadd, groupmod, and groupdel programs will do the same for groups. o Group passwords can be created using gpasswd. Again, none of these utilities is specific to, or original to, Red Hat.