diff options
Diffstat (limited to 'share')
| -rw-r--r-- | share/man/man1/Makefile | 4 | ||||
| -rw-r--r-- | share/man/man1/intro.1 | 3 | ||||
| -rw-r--r-- | share/man/man1/security.1 | 356 |
3 files changed, 360 insertions, 3 deletions
diff --git a/share/man/man1/Makefile b/share/man/man1/Makefile index 6084116..b70797f 100644 --- a/share/man/man1/Makefile +++ b/share/man/man1/Makefile @@ -1,7 +1,7 @@ # @(#)Makefile 8.1 (Berkeley) 6/5/93 -# $Id: Makefile,v 1.3 1997/03/07 03:27:49 jmg Exp $ +# $Id: Makefile,v 1.4 1997/04/14 10:24:14 wosch Exp $ -MAN1= cd.1 intro.1 wait.1 +MAN1= cd.1 intro.1 wait.1 security.1 MLINKS= intro.1 introduction.1 .include <bsd.prog.mk> diff --git a/share/man/man1/intro.1 b/share/man/man1/intro.1 index cbb1fdb..11069f0 100644 --- a/share/man/man1/intro.1 +++ b/share/man/man1/intro.1 @@ -30,7 +30,7 @@ .\" SUCH DAMAGE. .\" .\" @(#)intro.1 8.2 (Berkeley) 12/30/93 -.\" $Id: intro.1,v 1.9 1997/04/22 05:52:54 jmg Exp $ +.\" $Id: intro.1,v 1.10 1997/06/13 21:11:27 max Exp $ .\" .Dd December 30, 1993 .Dt INTRO 1 @@ -59,6 +59,7 @@ The exit values and their meanings are explained in the individual manuals. Traditionally, the value 0 signifies successful completion of the command. .Sh SEE ALSO +.Xr security 1 , .Xr apropos 1 , .Xr man 1 , .Xr intro 2 , diff --git a/share/man/man1/security.1 b/share/man/man1/security.1 new file mode 100644 index 0000000..b6310e2 --- /dev/null +++ b/share/man/man1/security.1 @@ -0,0 +1,356 @@ +.\" Copyright (c) 1991, 1993 +.\" The Regents of the University of California. All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. All advertising materials mentioning features or use of this software +.\" must display the following acknowledgement: +.\" This product includes software developed by the University of +.\" California, Berkeley and its contributors. +.\" 4. Neither the name of the University nor the names of its contributors +.\" may be used to endorse or promote products derived from this software +.\" without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" @(#)security.1 8.2 (Berkeley) 12/30/93 +.\" $Id: security.1,v 1.10 1997/06/13 21:11:27 max Exp $ +.\" +.Dd December 30, 1993 +.Dt SECURITY 1 +.Os +.Sh NAME +.Nm security +.Nd introduction to security under FreeBSD +.Sh DESCRIPTION +Security is a function that begins and ends with the system administrator. +While all +.Bx +systems are inherently multi-user capable, the job of building and +maintaining security mechanisms to keep those users 'honest' is probably +one of the single largest undertakings of the sysad. Machines are +only as secure as you make them, and security concerns are ever competing +with the human necessity for convenience. UNIX systems, +in general, are capable of running a huge number of simultanious processes +and many of these processes operate as servers - meaning that external entities +can connect and talk to them. As yesterday's mini-computers and mainframes +become today's desktops, and as computers become networked and internetworked, +security becomes an ever bigger issue. +.Pp +Security concerns can be split up into several categories: +.Bl -enum -offset indent +.It +Denial of service attacks +.It +User account compromises +.It +Root Hacks through accessible servers +.It +Root Hacks via user accounts +.El +.Pp +A denial of service attack is an action that deprives the machine of needed +resources. Typically, D.O.S. attacks are brute-force mechanisms that attempt +to crash or otherwise make a machine unusable by overwhelming its servers or +network stack. Some D.O.S. attacks try to take advantages of bugs in the +networking stack to crash a machine with a single packet. The latter can +only be fixed by applying a bug fix to the kernel. Attacks on servers can +often be fixed by properly specifying options to servers to limit the load +they incur on the system under adverse conditions. Brute-force network +attacks are harder to deal with. A spoofed-packet attack, for example, is +nearly impossible to stop short of cutting your system off from the internet. +.Pp +A user account compromise is even more common then a D.O.S. attack. Many +sysops still run standard telnetd, rlogind, rshd, and ftpd servers on their +machines. These servers, by default, do not operate over encrypted +connections. The result is that if you have any moderate-sized user base, +one or more of your users logging into your system from a remote location +(which is the most common and convenient way to login to a system) will +have his or her password sniffed. The attentive system admin will analyze +his remote access logs occassionally looking for suspicious source addresses +even for successful logins. +.Pp +One must always assume that once an attacker has access to a user account, +the attacker can break root. However, the reality is that in a well secured +and maintained system, access to a user account does not necessarily give the +attacker access to root. The distinction is important because without access +to root the attacker cannot generally hide his tracks and may, at best, be +able to remove that user's files and crash the machine, but not touch anyone +else's files. +.Pp +System administrators must keep in mind that there are several ways to break +root on a machine. The attacker may know the root password, the attacker +may find a bug in a root-run server and be able to break root over a network +connection to that server, or the attacker may know of a bug in an suid-root +program that allows the attacker to break root once he has broken into a +user's account. +.Pp +Security remedies are always implemented in a multi-layered 'onion peel' +approach and can be categorized as follows: +.Bl -enum -offset indent +.It +Securing root and staff accounts +.It +Securing root - root-run servers and suid/sgid binaries +.It +Securing user accounts +.It +Securing the password file +.It +Securing the kernel core, raw devices, and filesystems +.It +Checking file integrity: binaries, config files, and so forth +.It +Paranoia +.El +.Sh SECURING THE ROOT ACCOUNT AND SECURING STAFF ACCOUNTS +.Pp +Don't bother securing staff accounts if you haven't secured the root +account. Most systems have a password assigned to the root account. The +first thing you do is assume that the password is 'always' compromised. +To secure the root account you make sure that it is not possible to login +to the root account using the root password from a random user account or +over the network. If you haven't already, configure telnetd, rlogind, and +all other servers that handle login operations to refuse root logins, period, +whether the right password is given or not. Allow direct root logins only +via the system console. The '/etc/ttys' file comes in handy here and is +secure by default on most systems, but a good sysad always checks to make sure. +.Pp +Of course, as a sysad you have to be able to get to root, so we open up +a few holes. But we make sure these holes require additional password +verification to operate. One way to make root accessible is to add appropriate +staff accounts to the wheel group (in /etc/group). The staff members placed +in the wheel group are allowed to 'su' to root. You should never give staff +members native wheel access via their entry in the password file... put staff +in a 'staff' group or something and only add those that really need root to +the wheel group. Unfortunately the wheel mechanism still allows a hacker to +break root if the hacker has gotten hold of your password file - he need only +break the root password and the password of one of the staff accounts that +happens to be in the wheel group. So while the wheel mechanism is useable, +it isn't much safer then not having a wheel group at all. +.Pp +An indirect way to secure the root account is to secure your staff accounts +by using an alternative login access method and *'ing out the crypted password +for the staff accounts. This way a hacker may be able to steal the password +file but will not be able to break into any staff accounts (or, indirectly, +root, even if root has a crypted password associated with it). Staff members +get into their staff accounts through a secure login mechanism such as +kerberos(1) or ssh(1) (see /usr/ports/security/ssh) using a private/public +keypair. When you use something like kerberos you generally must secure +the machines which run the kerberos servers and your desktop workstation. +When you use a public/private keypair with ssh, you must generally secure +the machine you are logging in FROM (typically your workstation), but you can +also add an additional layer of protection to the keypair by password +protecting the keypair when you create it with ssh-keygen(1). Being able +to *-out the passwords for staff accounts also guarentees that staff members +can only login through secure access methods that you have setup. You can +thus force all staff members to use secure, encrypted connections for +all their sessions which closes an important hole used by many hackers: That +of sniffing the network from an unrelated, less secure machine. +.Pp +The more indirect security mechanisms also assume that you are logging in +from a more restrictive server to a less restrictive server. For example, +if your main box is running all sorts of servers, your workstation shouldn't + be running any. In order for your workstation to be reasonably secure +you should run as few servers as possible, up to and including no servers +at all, and you should run a password-protected screen blanker. + Of course, given physical access to +a workstation an attacker can break any sort of security you put on it. +This is definitely a problem that you should consider but you should also +consider the fact that the vast majority of breakins occur remotely, over +a network, from peopl who do not have physical access to your workstation or +servers. +.Pp +Using something like kerberos also gives you the ability to disable or +change the password for a staff account in one place and have it immediately +effect all the machine the staff member may have an account on. If a staff +member's account gets compromised, the ability to instantly change his +password on all machines should not be underrated. With discrete passwords, +changing a password on N machines can be a mess. You can also impose +re-passwording restrictions with kerberos: not only can a kerberos ticket +be made to timeout after a while, but the kerberos system can require that +the user choose a new password after a certain period of time (say, once a +month). +.Sh SECURING ROOT - ROOT-RUN SERVERS AND SUID/SGID BINARIES +.Pp +The prudent sysop only runs the servers he needs to, no more, no less. Be +aware that third party servers are often the most bug-prone. For example, +running an old version of imapd or popper is like giving a universal root +ticket out to the entire world. Never run a server that you have not checked +out carefully. Many servers do not need to be run as root. For example, +the ntalk, comsat, and finger daemons can be run in special user 'sandboxes'. +A sandbox isn't perfect unless you go to a hellofalot of trouble, but the +onion approach to security still stands: If someone is able to break in +through a server running in a sandbox, they still have to break out of the +sandbox. The more layers the attacker must break through, the lower the +likelihood of his success. Root holes have historically been found in +virtually every server ever run as root, including basic system servers. +If you are running a machine through which people only login via sshd and +never login via telnetd or rshd or rlogind, then turn off those services! +.Pp +FreeBSD now defaults to running ntalkd, comsat, and finger in a sandbox. +Another program which may be a candidate for running in a sandbox is +named(8). The default rc.conf includes the arguments necessary to run +named in a sandbox in a commented-out form. Depending on whether you +are installing a new system or upgrading an existing system, the special +user accounts used by these sandboxes may not be installed. The prudent +sysop would research and implement sandboxes for servers whenever possible. +.Pp +There are a number of other servers that typically do not run in sandboxes: +sendmail, popper, imapd, ftpd, and others. There are alternatives to +some of these, but installing them may require more work then you are willing +to put (the convenience factor strikes again). You may have to run these +servers as root and rely on other mechanisms to detect breakins that might +occur through them. +.Pp +The other big potential root hole in a system are the suid-root and sgid +binaries installed on the system. Most of these binaries, such as rlogin, +reside in /bin, /sbin, /usr/bin, or /usr/sbin. While nothing is 100% safe, +the system-default suid and sgid binaries can be considered reasonably safe. +Still, root holes are occassionaly found in these binaries. A root hole +was found in Xlib in 1998 that made xterm (which is typically suid) vulnerable. +It is better to be safe then sorry and the prudent sysad will restrict suid +binaries that only staff should run to a special group that only staff can +access, and get rid of (chmod 000) any suid binaries that nobody uses. A +server with no display generally does not need an xterm binary. Sgid binaries +can be almost as dangerous. If a hacker can break an sgid-kmem binary the +hacker might be able to read /dev/kmem and thus read the crypted password +file, potentially compromising any passworded account. A hacker that breaks +the tty group can write to almost user's tty. If a user is running a terminal +program or emulator with a talk-back feature, the hacker can potentially +generate a data stream that causes the user's terminal to echo a command, which +is then run as that user. +.Sh SECURING USER ACCOUNTS +User accounts are usually the most difficult to secure. While you can impose +draconian access restrictions on your staff and *-out their passwords, you +may not be able to do so with any general user accounts you might have. If +you do have sufficient control then you may win out and be able to secure the +user accounts properly. If not, you simply have to be more vigilant in your +monitoring of those accounts. Use of ssh and kerberos for user accounts is +more problematic, but still a very good solution compared to a crypted +password. +.Sh SECURING THE PASSWORD FILE +The only sure fire way is to *-out as many passwords as you can and +use ssh or kerberos for access to those accounts. Even though the +crypted password file (/etc/spwd.db) can only be read by root, it may +be possible for a hacker to obtain read access to that file even if the +attacker cannot obtain root-write access. +.Pp +Your security scripts should always check for and report changes to +the password file (see 'Checking file integrity' below). +.Sh SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS +If an attacker breaks root he can do just about anything, but there +are certain conveniences. For example, most modern kernels have a +packet sniffing device driver built in. Under FreeBSD it is called +the 'bpf' device. A hacker will commonly attempt to run a packet sniffer +on a compromised machine. You do not need to give the hacker the +capability and most systems should not have the bpf device compiled in. +Unfortunately, there is another kernel feature called the Loadable Kernel +Module interface. An enterprising hacker can use an LKM to install +his own bpf device or other sniffing device on a running kernel. If you +do not need to use the module loader, turn it off in the kernel config +with the NO_LKM option. +.Pp +But even if you turn off the bpf device, and turn off the module loader, +you still have /dev/mem and /dev/kmem to worry about. For that matter, +the hacker can still write raw devices. To avoid this you have to run +the kernel at a higher secure level... at least securelevel 1. The securelevel +can be set with a sysctl on the kern.securelevel variable. Once you have +set the securelevel to 1, write access to raw devices will be denied and +special chflags flags, such as 'schg', will be enforced. You must also ensure +that the 'schg' flag is set on critical startup binaries, directories, and +script files - everything that gets run up to the point where the securelevel +is set. This might be overdoing it, and upgrading the system is much more +difficult when you operate at a higher secure level. You may compromise and +run the system at a higher secure level but not set the schg flag for every +system file and directory under the sun. +.Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC +.Pp +When it comes right down to it, you can only protect your core system +configuration and control files so much before the convenience factor +rears its ugly head. The last layer of your security onion is perhaps +the most important - detection. +.Pp +The only correct way to check a system's file integrity is via another, +more secure system. It is fairly easy to setup a 'secure' system: you +simply do not run any services on it. With a secure system in place you +can then give it access to other system's root spaces via ssh. This may +seem like a security breech, but you have to put your trust somewhere and +as long as you don't do something stupid like run random servers it really +is possible to build a secure machine. When I say 'secure' here, I assuming +physical access security as well, of course. Given a secure machine with +root access on all your other machines, you can then write security scripts +ON the secure machine to check the other machines on the system. The most +common way of checking is to have the security script scp(1) over a find +and md5 binary and then ssh a shell command to the remote machine to md5 +all the files in the system (or, at least, the /, /var, and /usr partitions!). +The security machine copies the results to a file and diff's them against +results from a previous run (or compares the results against its own +binaries), then emails each staff member a daily report of differences. +.Pp +Another way to do this sort of check is to NFS export the major filesystems +from every other machine to the security machine. This is somewhat more +network intensive but also virtually impossible for a hacker to detect +or spoof. +.Pp +A good security script will also check for changes to user and staff members +access configuration files: .rhosts, .shosts, .ssh/authorized_keys, and +so forth... files that might fall outside the pervue of the MD5 check. +.Pp +A good security script will check for suid and sgid binaries on all +filesystems and report their absolute existance as well as a diff against +the previous report or some baseline (say, make a baseline once a week). +While you can turn off the ability to run suid and sgid binaries on certain +filesystems through the 'nosuid' option in fstab/mount, you cannot turn this +off on root and anyone who breaks root can just install their binary their. +If you have a huge amount of user disk space, though, it may be useful to +disallow suid binaries and devices ('nodev' option) on the user partitions +so you do not have to scan them for such. I would scan them anyway, though, +at least once a week, since the object of this onion layer is detection of +a breakin. +.Pp +Process accounting (see accton(1)) is a relatively low-overhead feature of +the operating system which I recommend using as a post-breakin evaluation +mechanism. It is especially useful in tracking down how a hacker has +actually broken root on a system, assuming the file is still intact after +the breakin occurs. +.Pp +Finally, security scripts should process the log files and the logs themselves +should be generated in as secured a manner as possible - remote syslog can be +very useful. A hacker tries to cover his tracks, and log files are critical +to the sysop trying to track down the time and method of the initial breakin. +.Sh PARANOIA +A little paranoia never hurts. As a rule, a sysop can add any number +of security features as long as they do not effect convenience, and +can add security features that do effect convenience with some added +thought. +.Sh SEE ALSO +.Xr ssh 1 , +.Xr sshd 1 , +.Xr kerberos 1 , +.Xr accton 1 , +.Xr xdm 1 , +.Xr syslogd 1 , +.Xr chflags 1 , +.Xr find 1 , +.Xr md5 1 +.Sh HISTORY +The +.Nm +manual page first appeared in FreeBSD-3.0.1, December 1998. |
