From 324304dcd07ea93e19c83b92fa42aed62589b42a Mon Sep 17 00:00:00 2001 From: dillon Date: Sun, 20 Dec 1998 20:11:25 +0000 Subject: Moving security page to section 7 --- share/man/man1/Makefile | 4 +- share/man/man1/security.1 | 474 ---------------------------------------------- 2 files changed, 2 insertions(+), 476 deletions(-) delete mode 100644 share/man/man1/security.1 diff --git a/share/man/man1/Makefile b/share/man/man1/Makefile index e54e3a5..f1ed384 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.5 1998/12/19 09:33:03 dillon Exp $ +# $Id: Makefile,v 1.6 1998/12/20 06:27:00 bde Exp $ -MAN1= cd.1 intro.1 security.1 wait.1 +MAN1= cd.1 intro.1 wait.1 MLINKS= intro.1 introduction.1 .include diff --git a/share/man/man1/security.1 b/share/man/man1/security.1 deleted file mode 100644 index 9bca730..0000000 --- a/share/man/man1/security.1 +++ /dev/null @@ -1,474 +0,0 @@ -.\" 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.2 1998/12/20 19:49:43 dillon Exp $ -.\" -.Dd December 30, 1993 -.Dt SECURITY 1 -.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