BBS水木清华站∶精华区
发信人: bibble (什么), 信区: Linux
标 题: Security-HOWTO
发信站: BBS 水木清华站 (Sat Apr 3 23:27:16 1999)
Linux Security HOWTO
Kevin Fenzi, kevin@scrye.com & Dave Wreski, dave@nic.com
v0.9.11, 1 May 1998
This document is a general overview of security issues that face the
administrator of Linux systems. It covers general security philosophy
and a number of specific examples of how to better secure your Linux
system from intruders. Also included are pointers to security related
material and programs. NOTE: This is a beta version of this document.
Improvements, constructive criticism, additions and corrections are
gratefully accepted. Please mail your feedback to both authors. Be
sure and include "Linux", "security" or "HOWTO" in the subject line of
your mail to avoid spam filters and to bring your mail to the quick
attention of the authors.
______________________________________________________________________
Table of Contents
1. Introduction
1.1 New Versions of this Document
1.2 Feedback
1.3 Disclaimer
1.4 Copyright Information
2. Overview
2.1 Why Do We Need Security?
2.2 How Secure Is Secure?
2.3 What Are You Trying to Protect?
2.4 Developing A Security Policy
2.5 Means of Securing Your Site
2.5.1 Host Security
2.5.2 Your Network Security
2.5.3 Security Through Obscurity
2.6 Organization of This Document
3. Physical Security
3.1 Computer locks
3.2 BIOS Security
3.3 Boot Loader Security
3.4 xlock and vlock
3.5 Detecting Physical Security Compromises
4. Local Security
4.1 Creating New Accounts
4.2 Root Security
5. Files and Filesystem Security
5.1 Umask Settings
5.2 File Permissions
5.3 Integrity Checking with Tripwire
5.4 Trojan Horses
6. Password Security & Encryption
6.1 PGP and Public Key Cryptography
6.2 SSL, S-HTTP, HTTPS and S/MIME
6.3 Linux x-kernel IPSEC Implementation
6.4 SSH (Secure Shell), stelnet
6.5 PAM - Pluggable Authentication Modules
6.6 Cryptographic IP Encapsulation (CIPE)
6.7 Kerberos
6.8 Shadow Passwords.
6.9 Crack and John the Ripper
6.10 CFS - Cryptographic File System and TCFS - transparent cryptographic File System
6.11 X11, SVGA and display security
6.11.1 X11
6.11.2 SVGA
6.11.3 GGI (Generic Graphics Interface project)
7. Kernel Security
7.1 Kernel Compile Options
7.2 Kernel Devices
8. Network Security
8.1 Packet Sniffers
8.2 System services and tcp_wrappers
8.3 Verify Your DNS Information
8.4 identd
8.5 SATAN , ISS, and Other Network Scanners
8.6 Sendmail, qmail and MTA's.
8.7 Denial of Service Attacks
8.8 NFS (Network File System) Security.
8.9 NIS (Network Information Service) (formerly YP).
8.10 Firewalls
9. Security Preparation (before you go on-line)
9.1 Make a Full Backup of Your Machine
9.2 Choosing a Good Backup Schedule
9.3 Backup Your RPM or Debian File Database
9.4 Keep Track of Your System Accounting Data
9.5 Apply All New System Updates.
10. What To Do During and After a Breakin
10.1 Security Compromise under way.
10.2 Security Compromise has already happened
10.2.1 Closing the Hole
10.2.2 Assessing ude authority over other machines on the network.
Remember that you should only use the root account for very short
specific tasks and should mostly run as a normal user. Running as root
all the time is a very very very bad idea.
Several tricks to avoid messing up your own box as root:
o When doing some complex command, try running it first in a non
destructive way...especially commands that use globbing: ie, you
are going to do a "rm foo*.bak", instead, first do: "ls foo*.bak"
and make sure you are going to delete the files you think you are.
Using echo in place of destructive commands also sometimes works.
o Some people find it helpfull to do a "touch /-i" on their systems.
This will make commands like: "rm -rf *" ask you if you really want
to delete all the files. (It does this by your shell resolving the
"-i" file first, and treating it as the -i option to rm.) This will
not help with rm statements with no * in them. ;(
o Only become root to do single specific tasks. If you find yourself
trying to figure out how to do something, go back to a normal user
shell until you are sure what needs to be done by root.
o The command path for the root user is very important. The command
path, or the PATH environment variable, defines the location the
shell searches for programs. Try and limit the command path for
the root user as much as possible, and never use '.', meaning 'the
current directory', in your PATH statement. Additionally, never
have writable directories in your search path, as this can allow
attackers to modify or place new binaries in your search path,
allowing them to run as root the next time you run that command.
o Never use the rlogin/rsh/rexec (called the r-utilities) suite of
tools as root. They are subject to many sorts of attacks, and are
downright dangerous run as root. Never create a .rhosts file for
root.
o The /etc/securetty file contains a list of terminals that root can
login from. By default (on Red Hat Linux) this is set to only the
local virtual consoles(vtys). Be very careful of adding anything
else to this file. You should be able to login remotely as your
regular user account and then 'su' if you need to (hopefully over
ssh or other encrypted channel), so there is no need to be able to
login directly as root.
o Always be slow and deliberate running as root. Your actions could
affect a lot of things. Think before you type!
If you absolutely positively need to allow someone (hopefully very
trusted) to have superuser access to your machine, there are a few
tools that can help. Sudo allows users to use their password to access
a limited set of commands as root. This would allow you to, for
instance, let a user be able to eject and mount removable media on
your Linux box, but have no other root privileges. sudo also keeps a
log of all successfull and unsuccessful sudo attempts, allowing you to
track down who used what command to do what. For this reason sudo
works well even in places where a number of people have root access,
but use sudo so you can keep track of changes made.
Although sudo can be used to give specific users specific privileges
for specific tasks, it does have several shortcomings. It should be
used only for a limited set of tasks, like restarting a server, or
adding new users. Any program that offers a shell escape will give
the user root access. This includes most editors, for example. Also,
a program as innocous as /bin/cat can be used to overwrite files,
which could allow root to be exploited. Consider sudo as a means for
accountability, and don't expect it to replace the root user yet be
secure.
5. Files and Filesystem Security
A few minutes of preparation and planning ahead before putting your
systems online can help to protect your system, and the data that is
stored on them.
o There should never be a reason for user's 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 user's home
partitions, as well as /var, which prohibit execution of programs,
and creation of character or block devices, which should never be
necessary anyway.
o If you are exporting filesystems using NFS, be sure to configure
/etc/exports with the most restrictive access possible. This means
not using wildcards, not allowing root write access, and mounting
read-only wherever possible.
o Configure your user's file-creation umask to be as restrictive as
possible. Commonly used settings are 022, 033, and the most
restrictive 077, and are added to /etc/profile.
o 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. For example, limits
for group `users' might look like this:
@users hard core 0
@users hard nproc 50
@users hard rss 5000
This says to prohibit the creation of core several pieces. The problem with this is that the port numbers are
only stored in the first fragment. This means that someone can
insert information into the remaining packets for your connection
that aren't supposed to be there.
o IP: syn cookies (CONFIG_SYN_COOKIES)
SYN Attack is a denial of service (DoS) attack that consumes all
the resources on your machine, forcing you to reboot. We can't
think of a reason you wouldn't normally enable this.
o Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING)
This is an option that is available in the 2.1 kernel series that
will sign NCP packets for stronger security. Normally you can
leave it off, but it is there if you do need it.
o IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK)
This is a really neat option that allows you to analyze the first
128 bytes of the packets in a userspace program, to determine if
you would like to accept or deny the packet, based on its validity.
7.2. Kernel Devices
There are a few block and character devices available on Linux that
will also help you with security.
The two devices /dev/random and /dev/urandom are provided by the
kernel to retrieve random data at any time.
Both /dev/random and /dev/urandom should be secure enough to use in
generating PGP keys, SSH challenges, and other applications where
secure random numbers are requisite. Attackers should be unable to
predict the next number given any initial sequence of numbers from
these sources. There has been a lot of effort put in to ensuring that
the numbers you get from these sources are random in every sense of
the word random.
The only difference is that /dev/random runs out of random bytes and
it makes you wait for more to be accumulated. Note that on some
systems, it can block for a long time waiting for new user-generated
entry to be entered into the system. So you have to use care before
using /dev/random. (Perhaps the best thing to do is to use it when
you're generating sensitive keying information, and you tell the user
to pound on the keyboard repeatedly until you print out "OK, enough".)
/dev/random is high quality entropy, generated from measuring the
inter-interrupt times etc. It blocks until enough bits of random data
are available.
/dev/urandom is similar, but when the store of entropy is running low,
it'll return a cryptographically strong hash of what there is. This
isn't as secure, but it's enough for most applications.
You might read from the devices using something like:
root# head -c 6 /dev/urandom | uuencode -
This will print six random characters on the console, suitable for
password generation.
See /usr/src/linux/drivers/char/random.c for a description of the
algorithm.
Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel
for helping me (Dave) with this.
8. Network Security
Network security is becoming more and more important as people spend
more and more time connected. Compromising network security is often
much easier than physical or local, and is much more common.
There are a number of good tools to assist with network security, and
more and more of them are shipping with Linux distributions.
8.1. Packet Sniffers
One of the most common ways intruders gain access to more systems on
your network is by employing a packet sniffer on a already compromised
host. This "sniffer" just listens on the Ethernet port for things like
"Password" and "Login" and "su" in the packet stream and then logs the
traffic after that. This way, attackers gain passwords for systems
they are not even attempting to break into. Clear text passwords are
very vulnerable to this attack.
EXAMPLE: host A has been compromised. Attacker installs a sniffer.
Sniffer picks up admin logging into host B from Host C. It gets the
admins personal password as they login to B. Then, the admin does a
'su' to fix a problem. They now have the root password for Host B.
Later the admin lets someone telnet from his account to host Z on
another site. Now the attacker has a password/login on host Z.
In this day and age, the attacker doesn't even need to compromise a
system to do this, they could also bring a laptop or pc into a
building and tap into your net.
Using ssh or other encrypted password methods thwarts this attack.
Things like APOP for pop accounts also prevents this attack. (Normal
pop logins are very vulnerable to this, as is anything that sends
clear text passwords over the wire.)
8.2. System services and tcp_wrappers
As soon as you put your Linux system on ANY network the first thing to
look at is what services you need to offer. Services that you do not
need to offer shoerver: A program that deals with external servers on behalf
of internal clients. Proxy clients talk to proxy servers, which
relay approved client requests on to real servers, and relay
answers back to clients.
o Denial of Service: A denial of service attack is when an attacker
consumes the resources on your computer for things it was not
intended to be doing, thus preventing normal use of your network
resources to legimite purposes.
o Buffer Overflow: Common coding style is never to allocate buffers
"large enough" and not checking for overflows. When such buffers
are overflows, the executing program (daemon or set-uid program)
can be tricked in doing some other things. Generally this works by
overwriting a function's return address on the stack to point to
another location.
o IP Spoofing: IP-Spoofing is a complex technical attack that is made
up of several components. It is a security exploit that works by
tricking computers in a trust-relationship that you are someone
that you really aren't. There is an extensive paper written by
daemon9, route, and infinity in the Volume Seven, Issue Fourty-
Eight issue of Phrack Magazine.
o Authentication: The property of knowing that the data received is
the same as the data that was sent and that the claimed sender is
in fact the actual sender.
o Non-repudiation: The property of a receiver being able to prove
that the sender of some data did in fact send the data even though
the sender might later desire to deny ever having sent that data.
13. Frequently Asked Questions
1. Is it more secure to compile driver support directly into the
kernel, instead of making it a module?
Answer: Some people think it is better to disable the ability to
load device drivers using modules, because an intruder could load a
trojan module or himself load a module that could affect system
security.
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.
Modules are for dynamically loading support for a particular device
that may be infrequently used. On server machines, or firewalls
for instance, this is very unlikely to happen. For this reason, it
would make more sense to compile support directly into the kernel
for machines acting as a server. Modules are also slower than
support compiled directly in the kernel.
2. Logging in as root from a remote machine always fails.
Answer: See the section on 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. Don't forget, potential intruders have time on
their side, and can run automated programs to find your password.
3. How do I enable shadow passwords on my Red Hat 4.2 or 5.0 Linux
box?
Answer: Shadow passwords is a mechanism for storing your password
in a file other than the normal /etc/passwd file. This has several
advantages. The first one is that the shadow file, /etc/shadow, is
only readable by root, unlike /etc/passwd, which must remain
readable by everyone. The other advantage is that as the
administrator, you can enable or disable accounts without everyone
knowing the status of other users accounts.
The /etc/passwd file is then used to store user and group names,
used by programs like `/bin/ls' to map the user ID to the proper
username in a directory listing.
The /etc/shadow file then only contains the username and his/her
password, and perhaps accounting information, like when the account
expires, etc.
To enable shadow passwords, run 'pwconv' as root, and /etc/shadow
should now exist, and be used by applications. Since you are using
RH 4.2 or above, the PAM modules will automatically adapt to the
change from using normal /etc/passwd to shadow passwords without
any other change.
Since your interested in securing your passwords, perhaps you would
also be interested in generating good passwords to begin with. For
this you can use the `pam_cracklib' module, which is part of PAM.
It runs your password against the Crack libraries to help you
decide if it is too easily guessable by password cracking programs.
4. How can I enable the Apache SSL extensions?
Answer:
1.Get SSLeay 0.8.0 or later from
ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL
2.Build and test and install it!
3.Get Apache 1.2.5 source
4.Get Apache SSLeay extensions from here
<ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.5+ssl_1.13.tar.gz>
5.Unpack it in the apache-1.2.5 source directory and patch Apache
as per the README.
6.Configure and build it.
You might also try Replay Associates which has many pre-built
packages, and is located outside of the United States.
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 back and
forth 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 programs useradd, usermod, and userdel can be used to add,
delete and modify user accounts. The programs groupadd, groupmod,
and groupdel will do the same for groups.
o Group passwords can be created using gpasswd.
All these programs are 'shadow-aware' -- that is; if you enable
shadow it will use /etc/shadow for password information, otherwise
it won't.
See the respective man pages for further information.
6. How can I password protect specific HTML documents using Apache?
I bet you didn't know about http://www.apacheweek.org did you?
You can find information on User Authentication at
http://www.apacheweek.com/features/userauth as well as other web
server security tips from
http://www.apache.org/docs/misc/security_tips.html
14. Conclusion
By subscribing to the security alert mailing lists, and keeping
current, you can do a lot towards securing your machine. If you pay
attention to your log files and run something like tripwire regularly,
you can do even more.
A reasonable level of computer security is not difficult to maintain
on a home machine. More effort is required on business machines, but
Linux can indeed be a secure platform. Due to the nature of Linux
development, security fixes often come out much faster than they do on
commercial operating systems, making Linux an ideal platform when
security is a requirement.
15. Thanks to
Information here is collected from many sources. Thanks to the
following that either indirectly or directly have contributed:
Rob Riggs <rob@DevilsThumb.com>
S. Coffin <scoffin@netcom.com>
Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu>
Roelof Osinga <roelof@eboa.com>
Kyle Hasselbacher <kyle@carefree.quux.soltec.net>
"David S. Jackson" <dsj@dsj.net>
"Todd G. Ruskell" <ruskell@boulder.nist.gov>
Rogier Wolff <R.E.Wolff@BitWizard.nl>
--
网内存知己 比邻若天涯
※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 162.105.181.204]
BBS水木清华站∶精华区