[When last I checked, the HOWTO maintainers were continuing
to
ignore _all_ of these corrections. -- RM]
From: rick@linuxmafia.com
To: kevin@tummy.com,
dave@linuxsecurity.com
Date: [some time around April 2000]
Hello, guys. You may remember me as the fellow who pointed out
the AIDE
integrity-checker (http://www.cs.tut.fi/~rammer/aide.html)
for the
Security HOWTO.
In http://www.linuxdoc.org/HOWTO/Security-HOWTO-5.html#ss5.3
, 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.[1]
I therefore hope you will revise the Security HOWTO, to remedy
the
impression it gives to the contrary.
[...]
[1] To update the above e-mail: Late in the year 2000,
Tripwire, Inc.
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.
Date: Sun, 21 May 2000 23:30:42 -0700
To: kevin@tummy.com,
dave@linuxsecurity.com
Subject: More suggestions/corrections for Security HOWTO
User-Agent: Mutt/1.1.5i
The list below ended up being a lot longer than I expected. If
you'd
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
are
flush-left.)
-- 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.