Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
SECURITY(7)	     BSD Miscellaneous Information Manual	   SECURITY(7)

     security -- introduction to security under	FreeBSD

     Security is a function that begins	and ends with the system administra-
     tor.  While all BSD multi-user systems have some inherent security, the
     job of building and maintaining additional	security mechanisms to keep
     users "honest" is probably	one of the single largest undertakings of the
     sysadmin.	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 simul-
     taneous processes and many	of these processes operate as servers -- mean-
     ing 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 is-

     Security is best implemented through a layered onion approach.  In	a nut-
     shell, what you want to do	is to create as	many layers of security	as are
     convenient	and then carefully monitor the system for intrusions.

     System security also pertains to dealing with various forms of attacks,
     including attacks that attempt to crash or	otherwise make a system	unus-
     able but do not attempt to	break root.  Security concerns can be split up
     into several categories:

	   1.	Denial of Service attacks (DoS)

	   2.	User account compromises

	   3.	Root compromise	through	accessible servers

	   4.	Root compromise	via user accounts

	   5.	Backdoor creation

     A denial of service attack	is an action that deprives the machine of
     needed resources.	Typically, DoS attacks are brute-force mechanisms that
     attempt to	crash or otherwise make	a machine unusable by overwhelming its
     servers or	network	stack.	Some DoS 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.	At-
     tacks on servers can often	be fixed by properly specifying	options	to
     limit the load the	servers	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.  It may not be able to take your machine
     down, but it can fill up your Internet pipe.

     A user account compromise is even more common than	a DoS attack.  Many
     sysadmins still run standard telnetd(8), rlogind(8), rshd(8), and ftpd(8)
     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 log in
     to	a system) will have his	or her password	sniffed.  The attentive	system
     administrator will	analyze	his remote access logs looking for suspicious
     source addresses even for successful logins.

     One must always assume that once an attacker has access to	a user ac-
     count, 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 impor-
     tant because without access to root the attacker cannot generally hide
     his tracks	and may, at best, be able to do	nothing	more than mess with
     the user's	files or crash the machine.  User account compromises are very
     common because users tend not to take the precautions that	sysadmins

     System administrators must	keep in	mind that there	are potentially	many
     ways to break root	on a machine.  The attacker may	know the root pass-
     word, 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.  If	an attacker has	found
     a way to break root on a machine, the attacker may	not have a need	to in-
     stall a backdoor.	Many of	the root holes found and closed	to date	in-
     volve a considerable amount of work by the	attacker to clean up after
     himself, so most attackers	do install backdoors.  This gives you a	conve-
     nient way to detect the attacker.	Making it impossible for an attacker
     to	install	a backdoor may actually	be detrimental to your security	be-
     cause it will not close off the hole the attacker used to break in	the
     first place.

     Security remedies should always be	implemented with a multi-layered
     "onion peel" approach and can be categorized as follows:

	   1.	Securing root and staff	accounts

	   2.	Securing root -- root-run servers and SUID/SGID	binaries

	   3.	Securing user accounts

	   4.	Securing the password file

	   5.	Securing the kernel core, raw devices, and file	systems

	   6.	Quick detection	of inappropriate changes made to the system

	   7.	Paranoia

     Do	not bother securing staff accounts if you have not 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.
     This does not mean	that you should	remove the password.  The password is
     almost always necessary for console access	to the machine.	 What it does
     mean is that you should not make it possible to use the password outside
     of	the console or possibly	even with a su(1) utility.  For	example, make
     sure that your PTYs are specified as being	"unsecure" in the /etc/ttys
     file so that direct root logins via telnet(1) or rlogin(1)	are disal-
     lowed.  If	using other login services such	as sshd(8), make sure that di-
     rect root logins are disabled there as well.  Consider every access
     method -- services	such as	ftp(1) often fall through the cracks.  Direct
     root logins should	only be	allowed	via the	system console.

     Of	course,	as a sysadmin 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 ap-
     propriate staff accounts to the "wheel" group (in /etc/group).  The staff
     members placed in the wheel group are allowed to su(1) to root.  You
     should never give staff members native wheel access by putting them in
     the wheel group in	their password entry.  Staff accounts should be	placed
     in	a "staff" group, and then added	to the wheel group via the /etc/group
     file.  Only those staff members who actually need to have root access
     should be placed in the wheel group.  It is also possible,	when using an
     authentication method such	as Kerberos, to	use Kerberos's .k5login	file
     in	the root account to allow a ksu(1) to root without having to place
     anyone at all in the wheel	group.	This may be the	better solution	since
     the wheel mechanism still allows an intruder to break root	if the in-
     truder has	gotten hold of your password file and can break	into a staff
     account.  While having the	wheel mechanism	is better than having nothing
     at	all, it	is not necessarily the safest option.

     An	indirect way to	secure the root	account	is to secure your staff	ac-
     counts by using an	alternative login access method	and *'ing out the
     crypted password for the staff accounts.  This way	an intruder may	be
     able to steal the password	file but will not be able to break into	any
     staff accounts or root, even if root has a	crypted	password associated
     with it (assuming,	of course, that	you have limited root access to	the
     console).	Staff members get into their staff accounts through a secure
     login mechanism such as kerberos(8) or ssh(1) using a private/public key
     pair.  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 key pair with SSH, you must generally se-
     cure the machine you are logging in from (typically your workstation),
     but you can also add an additional	layer of protection to the key pair by
     password protecting the keypair when you create it	with ssh-keygen(1).
     Being able	to *-out the passwords for staff accounts also guarantees that
     staff members can only log	in through secure access methods that you have
     set up.  You can thus force all staff members to use secure, encrypted
     connections for all their sessions	which closes an	important hole used by
     many intruders: that of sniffing the network from an unrelated, less se-
     cure machine.

     The more indirect security	mechanisms also	assume that you	are logging in
     from a more restrictive server to a less restrictive server.  For exam-
     ple, if your main box is running all sorts	of servers, your workstation
     should not	be running any.	 In order for your workstation to be reason-
     ably secure you should run	as few servers as possible, up to and includ-
     ing 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 prob-
     lem that you should consider but you should also consider the fact	that
     the vast majority of break-ins occur remotely, over a network, from peo-
     ple who do	not have physical access to your workstation or	servers.

     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 immedi-
     ately affect all the machines 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 dis-
     crete 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).

     The prudent sysadmin only runs the	servers	he needs to, no	more, no less.
     Be	aware that third party servers are often the most bug-prone.  For ex-
     ample, running an old version of imapd(8) or popper(8)
     (ports/mail/popper) is like giving	a universal root ticket	out to the en-
     tire 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 talkd(8),
     comsat(8),	and fingerd(8) daemons can be run in special user "sandboxes".
     A sandbox is not perfect unless you go to a large amount 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 log in
     via sshd(8) and never log in via telnetd(8), rshd(8), or rlogind(8), then
     turn off those services!

     FreeBSD now defaults to running talkd(8), comsat(8), and fingerd(8) in a
     sandbox.  Another program which may be a candidate	for running in a sand-
     box is named(8).  The default rc.conf includes the	arguments necessary to
     run named(8) in a sandbox in a commented-out form.	 Depending on whether
     you are installing	a new system or	upgrading an existing system, the spe-
     cial user accounts	used by	these sandboxes	may not	be installed.  The
     prudent sysadmin would research and implement sandboxes for servers when-
     ever possible.

     There are a number	of other servers that typically	do not run in sand-
     boxes: sendmail(8), popper(8), imapd(8), ftpd(8), and others.  There are
     alternatives to some of these, but	installing them	may require more work
     than 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 de-
     tect break-ins that might occur through them.

     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(1),	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 occasionally found	in these bina-
     ries.  A root hole	was found in Xlib in 1998 that made xterm(1)
     (ports/x11/xterm) (which is typically SUID) vulnerable.  It is better to
     be	safe than sorry	and the	prudent	sysadmin 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(1)	binary.	 SGID
     binaries can be almost as dangerous.  If an intruder can break an SGID-
     kmem binary the intruder might be able to read /dev/kmem and thus read
     the crypted password file,	potentially compromising any passworded	ac-
     count.  Alternatively an intruder who breaks group	"kmem" can monitor
     keystrokes	sent through PTYs, including PTYs used by users	who log	in
     through secure methods.  An intruder that breaks the "tty"	group can
     write to almost any user's	TTY.  If a user	is running a terminal program
     or	emulator with a	keyboard-simulation feature, the intruder can poten-
     tially generate a data stream that	causes the user's terminal to echo a
     command, which is then run	as that	user.

     User accounts are usually the most	difficult to secure.  While you	can
     impose draconian access restrictions on your staff	and *-out their	pass-
     words, 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 due	to the extra adminis-
     tration and technical support required, but still a very good solution
     compared to a crypted 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 an intruder to	obtain read access to that file	even if	the attacker
     cannot obtain root-write access.

     Your security scripts should always check for and report changes to the
     password file (see	CHECKING FILE INTEGRITY	below).

     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(4)
     device.  An intruder will commonly	attempt	to run a packet	sniffer	on a
     compromised machine.  You do not need to give the intruder	the capability
     and most systems should not have the bpf(4) device	compiled in.

     But even if you turn off the bpf(4) device, you still have	/dev/mem and
     /dev/kmem to worry	about.	For that matter, the intruder can still	write
     to	raw disk devices.  Also, there is another kernel feature called	the
     module loader, kldload(8).	 An enterprising intruder can use a KLD	module
     to	install	his own	bpf(4) device or other sniffing	device on a running
     kernel.  To avoid these problems you have to run the kernel at a higher
     security level, at	least level 1.	The security level can be set with a
     sysctl(8) on the kern.securelevel variable.  Once you have	set the	secu-
     rity level	to 1, write access to raw devices will be denied and special
     chflags(1)	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	secu-
     rity level	is set.	 This might be overdoing it, and upgrading the system
     is	much more difficult when you operate at	a higher security level.  You
     may compromise and	run the	system at a higher security level but not set
     the schg flag for every system file and directory under the sun.  Another
     possibility is to simply mount / and /usr read-only.  It should be	noted
     that being	too draconian in what you attempt to protect may prevent the
     all-important detection of	an intrusion.

     The kernel	runs with five different security levels.  Any super-user
     process can raise the level, but no process can lower it.	The security
     levels are:

     -1	   Permanently insecure	mode - always run the system in	insecure mode.
	   This	is the default initial value.

     0	   Insecure mode - immutable and append-only flags may be turned off.
	   All devices may be read or written subject to their permissions.

     1	   Secure mode - the system immutable and system append-only flags may
	   not be turned off; disks for	mounted	file systems, /dev/mem and
	   /dev/kmem may not be	opened for writing; /dev/io (if	your platform
	   has it) may not be opened at	all; kernel modules (see kld(4)) may
	   not be loaded or unloaded.

     2	   Highly secure mode -	same as	secure mode, plus disks	may not	be
	   opened for writing (except by mount(2)) whether mounted or not.
	   This	level precludes	tampering with file systems by unmounting
	   them, but also inhibits running newfs(8) while the system is	multi-

	   In addition,	kernel time changes are	restricted to less than	or
	   equal to one	second.	 Attempts to change the	time by	more than this
	   will	log the	message	"Time adjustment clamped to +1 second".

     3	   Network secure mode - same as highly	secure mode, plus IP packet
	   filter rules	(see ipfw(8), ipfirewall(4) and	pfctl(8)) cannot be
	   changed and dummynet(4) or pf(4) configuration cannot be adjusted.

     The security level	can be configured with variables documented in

     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.  For example,	using chflags(1) to set	the schg bit
     on	most of	the files in / and /usr	is probably counterproductive because
     while it may protect the files, it	also closes a detection	window.	 The
     last layer	of your	security onion is perhaps the most important --	detec-
     tion.  The	rest of	your security is pretty	much useless (or, worse,
     presents you with a false sense of	safety)	if you cannot detect potential
     incursions.  Half the job of the onion is to slow down the	attacker
     rather than stop him in order to give the detection layer a chance	to
     catch him in the act.

     The best way to detect an incursion is to look for	modified, missing, or
     unexpected	files.	The best way to	look for modified files	is from	an-
     other (often centralized) limited-access system.  Writing your security
     scripts on	the extra-secure limited-access	system makes them mostly in-
     visible to	potential attackers, and this is important.  In	order to take
     maximum advantage you generally have to give the limited-access box sig-
     nificant access to	the other machines in the business, usually either by
     doing a read-only NFS export of the other machines	to the limited-access
     box, or by	setting	up SSH keypairs	to allow the limit-access box to SSH
     to	the other machines.  Except for	its network traffic, NFS is the	least
     visible method -- allowing	you to monitor the file	systems	on each	client
     box virtually undetected.	If your	limited-access server is connected to
     the client	boxes through a	switch,	the NFS	method is often	the better
     choice.  If your limited-access server is connected to the	client boxes
     through a hub or through several layers of	routing, the NFS method	may be
     too insecure (network-wise) and using SSH may be the better choice	even
     with the audit-trail tracks that SSH lays.

     Once you give a limit-access box at least read access to the client sys-
     tems it is	supposed to monitor, you must write scripts to do the actual
     monitoring.  Given	an NFS mount, you can write scripts out	of simple sys-
     tem utilities such	as find(1) and md5(1).	It is best to physically
     md5(1) the	client-box files boxes at least	once a day, and	to test	con-
     trol files	such as	those found in /etc and	/usr/local/etc even more of-
     ten.  When	mismatches are found relative to the base MD5 information the
     limited-access machine knows is valid, it should scream at	a sysadmin to
     go	check it out.  A good security script will also	check for inappropri-
     ate SUID binaries and for new or deleted files on system partitions such
     as	/ and /usr.

     When using	SSH rather than	NFS, writing the security script is much more
     difficult.	 You essentially have to scp(1)	the scripts to the client box
     in	order to run them, making them visible,	and for	safety you also	need
     to	scp(1) the binaries (such as find(1)) that those scripts use.  The
     sshd(8) daemon on the client box may already be compromised.  All in all,
     using SSH may be necessary	when running over unsecure links, but it is
     also a lot	harder to deal with.

     A good security script will also check for	changes	to user	and staff mem-
     bers access configuration files: .rhosts, .shosts,	.ssh/authorized_keys
     and so forth, files that might fall outside the purview of	the MD5	check.

     If	you have a huge	amount of user disk space it may take too long to run
     through every file	on those partitions.  In this case, setting mount
     flags to disallow SUID binaries on	those partitions is a good idea.  The
     nosuid option (see	mount(8)) is what you want to look into.  I would scan
     them anyway at least once a week, since the object	of this	layer is to
     detect a break-in whether or not the break-in is effective.

     Process accounting	(see accton(8))	is a relatively	low-overhead feature
     of	the operating system which I recommend using as	a post-break-in	evalu-
     ation mechanism.  It is especially	useful in tracking down	how an in-
     truder has	actually broken	into a system, assuming	the file is still in-
     tact after	the break-in occurs.

     Finally, security scripts should process the log files and	the logs them-
     selves should be generated	in as secure a manner as possible -- remote
     syslog can	be very	useful.	 An intruder tries to cover his	tracks,	and
     log files are critical to the sysadmin trying to track down the time and
     method of the initial break-in.  One way to keep a	permanent record of
     the log files is to run the system	console	to a serial port and collect
     the information on	a continuing basis through a secure machine monitoring
     the consoles.

     A little paranoia never hurts.  As	a rule,	a sysadmin can add any number
     of	security features as long as they do not affect	convenience, and can
     add security features that	do affect convenience with some	added thought.
     Even more importantly, a security administrator should mix	it up a	bit --
     if	you use	recommendations	such as	those given by this manual page	verba-
     tim, you give away	your methodologies to the prospective attacker who
     also has access to	this manual page.

     This section covers Denial	of Service attacks.  A DoS attack is typically
     a packet attack.  While there is not 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.

	   1.	Limiting server	forks

	   2.	Limiting springboard attacks (ICMP response attacks, ping
		broadcast, etc.)

	   3.	Kernel Route Cache

     A common DoS attack is against a forking server that attempts to cause
     the server	to eat processes, file descriptors, and	memory until the ma-
     chine dies.  The inetd(8) server has several options to limit this	sort
     of	attack.	 It should be noted that while it is possible to prevent a ma-
     chine from	going down it is not generally possible	to prevent a service
     from being	disrupted by the attack.  Read the inetd(8) manual page	care-
     fully and pay specific attention to the -c, -C, and -R options.  Note
     that spoofed-IP attacks will circumvent the -C option to inetd(8),	so
     typically a combination of	options	must be	used.  Some standalone servers
     have self-fork-limitation parameters.

     The sendmail(8) daemon has	its -OMaxDaemonChildren	option which tends to
     work much better than trying to use sendmail(8)'s load limiting options
     due to the	load lag.  You should specify a	MaxDaemonChildren parameter
     when you start sendmail(8)	high enough to handle your expected load but
     not so high that the computer cannot handle that number of	sendmail's
     without falling on	its face.  It is also prudent to run sendmail(8) in
     "queued" mode (-ODeliveryMode=queued) and to run the daemon ("sendmail
     -bd") separate from the queue-runs	("sendmail -q15m").  If	you still want
     real-time 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(8) to prevent cascade failures.

     The syslogd(8) daemon can be attacked directly and	it is strongly recom-
     mended that you use the -s	option whenever	possible, and the -a option

     You should	also be	fairly careful with connect-back services such as tcp-
     wrapper's reverse-identd, which can be attacked directly.	You generally
     do	not want to use	the reverse-ident feature of tcpwrappers for this rea-

     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 pre-
     vent saturation attacks from outside your LAN, not	so much	to protect in-
     ternal services from network-based	root compromise.  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(8)	(if you	are primary for	a
     zone), talkd(8), sendmail(8), 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-num-
     bered port	range on the firewall to allow permissive-like operation with-
     out 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 net.inet.ip.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).

     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 spoofs 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	at-
     tacker uses the same trick	on several dozen broadcast addresses over sev-
     eral dozen	different networks at once.  Broadcast attacks of over a hun-
     dred and twenty megabits have been	measured.  A second common springboard
     attack is against the ICMP	error reporting	system.	 By constructing pack-
     ets 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 effective-
     ness of these sorts of attacks.  The last major class of springboard at-
     tacks is related to certain internal inetd(8) services such as the	UDP
     echo service.  An attacker	simply spoofs a	UDP packet with	the source ad-
     dress 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	sysadmin will turn off all of these
     inetd(8)-internal test services.

     Spoofed packet attacks may	also be	used to	overload the kernel route
     cache.  Refer to the net.inet.ip.rtexpire,	net.inet.ip.rtminexpire, and
     net.inet.ip.rtmaxcache sysctl(8) variables.  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 de-
     tects that	the cached route table has gotten too big it will dynamically
     reduce the	rtexpire but will never	decrease it to less than 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	pru-
     dent 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 pro-
     tect the route table from attack.

     There are a few issues with both Kerberos and SSH that need to be ad-
     dressed if	you intend to use them.	 Kerberos5 is an excellent authentica-
     tion protocol but the kerberized telnet(1)	and rlogin(1) suck rocks.
     There are bugs that make them unsuitable for dealing with binary streams.
     Also, by default Kerberos does not	encrypt	a session unless you use the
     -x	option.	 SSH encrypts everything by default.

     SSH works quite well in every respect except when it is set up to forward
     encryption	keys.  What this means is that if you have a secure worksta-
     tion holding keys that give you access to the rest	of the system, and you
     ssh(1) to an unsecure machine, your keys become exposed.  The actual keys
     themselves	are not	exposed, but ssh(1) installs a forwarding port for the
     duration of your login and	if an attacker has broken root on the unsecure
     machine he	can utilize that port to use your keys to gain access to any
     other machine that	your keys unlock.

     We	recommend that you use SSH in combination with Kerberos	whenever pos-
     sible for staff logins.  SSH can be compiled with Kerberos	support.  This
     reduces your reliance on potentially exposable SSH	keys while at the same
     time protecting passwords via Kerberos.  SSH keys should only be used for
     automated tasks from secure machines (something that Kerberos is unsuited
     to).  We also recommend that you either turn off key-forwarding in	the
     SSH configuration,	or that	you make use of	the from=IP/DOMAIN option that
     SSH allows	in its authorized_keys file to make the	key only usable	to en-
     tities logging in from specific machines.

     chflags(1), find(1), md5(1), netstat(1), openssl(1), ssh(1), xdm(1)
     (ports/x11/xorg-clients), group(5), ttys(5), accton(8), init(8), sshd(8),
     sysctl(8),	syslogd(8), vipw(8)

     The security manual page was originally written by	Matthew	Dillon and
     first appeared in FreeBSD 3.1, December 1998.

BSD			       September 8, 2006			   BSD


Want to link to this manual page? Use this URL:

home | help