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

FreeBSD Manual Pages


home | help
SECURITY(7)	   FreeBSD 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

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

     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

     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	``insecure'' 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(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
     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).

     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)
     (ports/mail/popper) is like giving	a universal root ticket	out to the
     entire world.  Never run a	server that you	have not checked out care-
     fully.  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.  Depending on whether you	are installing a new system or upgrad-
     ing an existing system, the special user accounts used by these sandboxes
     may not be	installed.  The	prudent	sysadmin would research	and implement
     sandboxes for servers whenever 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
     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)
     (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
     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	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.  The kernel debugger may not be entered
	   using the debug.kdb.enter sysctl.  A	panic or trap cannot be	forced
	   using the debug.kdb.panic and other sysctl's.

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

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

     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
     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 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-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 every-
     thing under 4000 off in my	firewall (except for certain specific inter-
     net-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.

     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.

     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.

FreeBSD	Ports 11.2	       December	25, 2013	    FreeBSD Ports 11.2


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

home | help