From 5f658e4d70a33a47ba297f39d60e1d37c62ef753 Mon Sep 17 00:00:00 2001 From: dillon Date: Sun, 20 Dec 1998 20:12:17 +0000 Subject: Moved security page from man 1 to man 7 --- share/man/man7/Makefile | 4 +- share/man/man7/security.7 | 474 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 476 insertions(+), 2 deletions(-) create mode 100644 share/man/man7/security.7 diff --git a/share/man/man7/Makefile b/share/man/man7/Makefile index 86357ed..e0e17ef 100644 --- a/share/man/man7/Makefile +++ b/share/man/man7/Makefile @@ -1,9 +1,9 @@ # @(#)Makefile 8.1 (Berkeley) 6/5/93 -# $Id: Makefile,v 1.7 1997/11/09 06:05:45 obrien Exp $ +# $Id: Makefile,v 1.8 1998/11/26 00:21:24 jkoshy Exp $ #MISSING: eqnchar.7 ms.7 term.7 MAN7= ascii.7 clocks.7 environ.7 hier.7 hostname.7 intro.7 mailaddr.7 \ - man.7 mdoc.7 mdoc.samples.7 operator.7 ports.7 + man.7 mdoc.7 mdoc.samples.7 operator.7 ports.7 security.7 MLINKS= intro.7 miscellaneous.7 .include diff --git a/share/man/man7/security.7 b/share/man/man7/security.7 new file mode 100644 index 0000000..5451090 --- /dev/null +++ b/share/man/man7/security.7 @@ -0,0 +1,474 @@ +.\" 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.3 1998/12/20 20:05:44 dillon Exp $ +.\" +.Dd December 30, 1993 +.Dt SECURITY 7 +.Os +.Sh NAME +.Nm security +.Nd introduction to security under FreeBSD +.Sh DESCRIPTION +.Pp +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 +.Pp +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 +.Pp +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 +.Pp +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 +.Pp +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 SPECIAL SECTION ON D.O.S. ATTACKS +.Pp +This section covers Dential of Service attacks. A DOS attack is typically +a packet attack. While there isn't much you can do about modern spoofed +packet attacks that saturate your network, you can generally limit the damage +by ensuring that the attacks cannot take down your servers. +.Bl -enum -offset indent +.It +Limiting server forks +.It +Limiting springboard attacks (ICMP response attacks, ping broadcast, etc...) +.It +Kernel Route Cache +.El +.Pp +A common DOS attack is against a forking server that attempts to cause the +server to eat processes, file descirptors, and memory until the machine +dies. Inetd (see inetd(8)) has several options to limit this sort of attack. +It should be noted that while it is possible to prevent a machine from going +down it is not generally possible to prevent a service from being disrupted +by the attack. Read the inetd manual page carefully and pay specific attention +to the -c, -C, and -R options. Note that spoofed-IP attacks will circumvent +the -C option to inetd, so typically a combination of options must be used. +Some standalone servers have self-fork-limitation parameters. +.Pp +Sendmail has its -OMaxDaemonChildren option which tends to work much +better then trying to use sendmail's load limiting options due to the +load lag. You should specify a MaxDaemonChildren parameter when you start +sendmail high enough to handle your expected load but no so high that the +computer cannot handle that number of sendmails without falling on its face. +It is also prudent to run sendmail in queued mode (-ODeliveryMode=queued) +and to run the daemon (sendmail -bd) separate from the queue-runs +(sendmail -q15m). If you still want realtime delivery you can run the queue +at a much lower interval, such as -q1m, but be sure to specify a reasonable +MaxDaemonChildren option for that sendmail to prevent cascade failures. +.Pp +Syslogd can be attacked directly and it is strongly recommended that you use +the -s option whenever possible, and the -a option otherwise. +.Pp +You should also be fairly careful +with connect-back services such as tcpwrapper's reverse-identd, which can +be attacked directly. You generally do not want to use the reverse-ident +feature of tcpwrappers for this reason. +.Pp +It is a very good idea to protect internal services from external access +by firewalling them off at your border routers. The idea here is to prevent +saturation attacks from outside your LAN, not so much to protect internal +services from root network-based root hacks. Always configure an exclusive +firewall, i.e. 'firewall everything *except* ports A, B, C, D, and M-Z'. This +way you can firewall off all of your low ports except for certain specific +services such as named (if you are primary for a zone), ntalkd, sendmail, +and other internet-accessible services. +If you try to configure the firewall the other +way - as an inclusive or permissive firewall, there is a good chance that you +will forget to 'close' a couple of services or that you will add a new internal +service and forget to update the firewall. You can still open up the +high-numbered port range on the firewall to allow permissive-like operation +without compromising your low ports. Also take note that FreeBSD allows you to +control the range of port numbers used for dynamic binding via the various +net.inet.ip.portrange sysctl's (sysctl -a | fgrep portrange), which can also +ease the complexity of your firewall's configuration. I usually use a normal +first/last range of 4000 to 5000, and a hiport range of 49152 to 65535, then +block everything under 4000 off in my firewall ( except for certain specific +internet-accessible ports, of course ). +.Pp +Another common DOS attack is called a springboard attack - to attack a server +in a manner that causes the server to generate responses which then overload +the server, the local network, or some other machine. The most common attack +of this nature is the ICMP PING BROADCAST attack. The attacker spoofed ping +packets sent to your LAN's broadcast address with the source IP address set +to the actual machine they wish to attack. If your border routers are not +configured to stomp on ping's to broadcast addresses, your LAN winds up +generating sufficient responses to the spoofed source address to saturate the +victim, especially when the attacker uses the same trick on several dozen +broadcast addresses over several dozen different networks at once. Broadcast +attacks of over a hundred and twenty megabits have been measured. A second +common springboard attack is against the ICMP error reporting system. By +constructing packets that generate ICMP error responses, an attacker can +saturate a server's incoming network and cause the server to saturate its +outgoing network with ICMP responses. This type of attack can also crash the +server by running it out of mbuf's, especially if the server cannot drain the +ICMP responses it generates fast enough. The FreeBSD kernel has a new kernel +compile option called ICMP_BANDLIM which limits the effectiveness of these +sorts of attacks. The last major class of springboard attacks is related to +certain internal inetd services such as the udp echo service. An attacker +simply spoofs a UDP packet with the source address being server A's echo port, +and the destination address being server B's echo port, where server A and B +are both on your LAN. The two servers then bounce this one packet back and +forth between each other. The attacker can overload both servers and their +LANs simply by injecting a few packets in this manner. Similar problems +exist with the internal chargen port. A competent sysad will turn off all +of these inetd-internal test services. +.Pp +Spoofed packet attacks may also be used to overload the kernel route cache. +Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache sysctl +parameters. A spoofed packet attack that uses a random source IP will cause +the kernel to generate a temporary cached route in the route table, viewable +with 'netstat -rna | fgrep W3'. These routes typically timeout in 1600 +seconds or so. If the kernel detects that the cached route table has gotten +too big it will dynamically reduce the rtexpire but will never decrease it to +less then rtminexpire. There are two problems: (1) The kernel does not react +quickly enough when a lightly loaded server is suddenly attacked, and (2) The +rtminexpire is not low enough for the kernel to survive a sustained attack. +If your servers are connected to the internet via a T3 or better it may be +prudent to manually override both rtexpire and rtminexpire via sysctl(8). +Never set either parameter to zero (unless you want to crash the machine :-)). +Setting both parameters to 2 seconds should be sufficient to protect the route +table from attack. + +.Sh SEE ALSO +.Pp +.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 , +.Xr sysctl 8 +.Sh HISTORY +The +.Nm +manual page was originally written by Matthew Dillon and first appeared +in FreeBSD-3.0.1, December 1998. + -- cgit v1.1