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

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
SECURITY(7)	   FreeBSD Miscellaneous Information Manual	   SECURITY(7)

NAME
     security -- introduction to security under	FreeBSD

DESCRIPTION
     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
     issue.

     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.  You do
     not want to overbuild your	security or you	will interfere with the	detec-
     tion side,	and detection is one of	the single most	important aspects of
     any security mechanism.  For example, it makes little sense to set	the
     schg flags	(see chflags(1)) on every system binary	because	while this may
     temporarily protect the binaries, it prevents an attacker who has broken
     in	from making an easily detectable change	that may result	in your	secu-
     rity mechanisms not detecting the attacker	at all.

     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.
     Attacks 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 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
     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 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
     take.

     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
     install a backdoor.  Many of the root holes found and closed to date
     involve 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
     because it	will not close off the hole the	attacker used to break in 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

SECURING THE ROOT ACCOUNT AND SECURING STAFF ACCOUNTS
     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
     direct 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
     appropriate 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 hav-
     ing 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 intruder 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
     accounts 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(1) 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
     secure 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
     secure 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).

SECURING ROOT -- ROOT-RUN SERVERS AND SUID/SGID	BINARIES
     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
     example, running an old version of	imapd(8) or popper(8) 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	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 run-
     ning 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
     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 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) (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 gen-
     erally 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 account.  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 key-
     board-simulation feature, the intruder can	potentially generate a data
     stream that causes	the user's terminal to echo a command, which is	then
     run as that user.

SECURING USER ACCOUNTS
     User accounts are usually the most	difficult to secure.  While you	can
     impose draconian access restrictions on your staff	and *-out their	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.

SECURING THE PASSWORD FILE
     The only sure fire	way is to *-out	as many	passwords as you can and use
     SSH or Kerberos for access	to those accounts.  Even though	the crypted
     password file (/etc/spwd.db) can only be read by root, it may be possible
     for 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).

SECURING THE KERNEL CORE, RAW DEVICES, AND FILE	SYSTEMS
     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
     secure level, at least securelevel	1.  The	securelevel can	be set with a
     sysctl(8) on the kern.securelevel variable.  Once you have	set the
     securelevel 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
     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.  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.

CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC
     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
     another (often centralized) limited-access	system.	 Writing your security
     scripts on	the extra-secure limited-access	system makes them mostly
     invisible to potential attackers, and this	is important.  In order	to
     take maximum advantage you	generally have to give the limited-access box
     significant 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	con-
     nected 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
     often.  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 inappro-
     priate 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 and devices on those partitions is	a good
     idea.  The	nodev and nosuid options (see mount(8))	are 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
     intruder has actually broken into a system, assuming the file is still
     intact 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.

PARANOIA
     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.

SPECIAL	SECTION	ON DoS ATTACKS
     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
     machine 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
     machine 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
     otherwise.

     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-
     son.

     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
     internal 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	ser-
     vice 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
     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
     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 spring-
     board 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 effective-
     ness of these sorts of attacks.  The last major class of springboard
     attacks is	related	to certain internal inetd(8) 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	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 ker-
     nel detects that the cached route table has gotten	too big	it will	dynam-
     ically 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 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 suffi-
     cient to protect the route	table from attack.

ACCESS ISSUES WITH KERBEROS AND	SSH
     There are a few issues with both Kerberos and SSH that need to be
     addressed if you intend to	use them.  Kerberos5 is	an excellent authenti-
     cation 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
     entities logging in from specific machines.

SEE ALSO
     chflags(1), find(1), md5(1), netstat(1), openssl(1), ssh(1), xdm(1),
     group(5), ttys(5),	accton(8), init(8), sshd(8), sysctl(8),	syslogd(8),
     vipw(8)

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

FreeBSD	10.1		      September	18, 1999		  FreeBSD 10.1

NAME | DESCRIPTION | SECURING THE ROOT ACCOUNT AND SECURING STAFF ACCOUNTS | SECURING ROOT -- ROOT-RUN SERVERS AND SUID/SGID BINARIES | SECURING USER ACCOUNTS | SECURING THE PASSWORD FILE | SECURING THE KERNEL CORE, RAW DEVICES, AND FILE SYSTEMS | CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC | PARANOIA | SPECIAL SECTION ON DoS ATTACKS | ACCESS ISSUES WITH KERBEROS AND SSH | SEE ALSO | HISTORY

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=security&sektion=7&manpath=FreeBSD+5.3-RELEASE>

home | help