Moved security page from man 1 to man 7

2 files changed, 476 insertions, 2 deletions

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 <bsd.prog.mk>
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.
+