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.  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 a hacker who	has broken in
     from making an easily detectable change that may result in	your security
     mechanisms	not detecting the hacker at all.

     System security also pertains to dealing with various forms of attack,
     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

	   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, D.O.S. attacks are brute-force mechanisms
     that attempt to crash or otherwise	make a machine unusable	by overwhelm-
     ing its servers or	network	stack.	Some D.O.S. attacks try	to take	advan-
     tages 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	ker-
     nel.  Attacks on servers can often	be fixed by properly specifying	op-
     tions 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 then	a D.O.S. attack.  Many
     sysadmins still run standard telnetd, rlogind, rshd, and ftpd servers on
     their machines.  These servers, by	default, do not	operate	over encrypted
     connections.  The result is that if you have any moderate-sized user
     base, one or more of your users logging into your system from a remote
     location (which is	the most common	and convenient way to login to a sys-
     tem) will have his	or her password	sniffed.  The attentive	system admin
     will analyze his remote access logs looking for suspicious	source ad-
     dresses 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	hacker to cleanup after	him-
     self, so most hackers do install backdoors.  This gives you a convenient
     way to detect the hacker.	Making it impossible for a hacker to install a
     backdoor may actually be detrimental to your security because it will not
     close off the hole	the hacker found 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

     Don't bother securing staff accounts if you haven't secured the root ac-
     count.  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) command.  For	example, make
     sure that your pty's are specified	as being unsecure in the `/etc/ttys'
     file so that direct root logins via telnet	or rlogin are disallowed.  If
     using other login services	such as	sshd, make sure	that direct root lo-
     gins are disabled there as	well.  Consider	every access method - services
     such as ftp 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' 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 intruder has gotten	hold of	your password file and can break into
     a staff account.  While having the	wheel mechanism	is better then having
     nothing at	all, it	isn't 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, indirectly, root, even	if root	has a crypted password
     associated	with it).  Staff members get into their	staff accounts through
     a secure login mechanism such as kerberos(1) or ssh(1) using a pri-
     vate/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 login through secure access	meth-
     ods that you have setup.  You can thus force all staff members to use se-
     cure, encrypted connections for all their sessions	which closes an	impor-
     tant 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
     shouldn't be running any.	In order for your workstation to be reasonably
     secure you	should run as few servers as possible, up to and including no
     servers at	all, and you should run	a password-protected screen blanker.
     Of	course,	given physical access to a workstation an attacker can break
     any sort of security you put on it.  This is definitely a problem that
     you should	consider but you should	also consider the fact that the	vast
     majority of break-ins occur remotely, over	a network, from	people 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 effect all the machine the staff member may have an account on.  If
     a staff member's account gets compromised,	the ability to instantly
     change his	password on all	machines should	not be underrated.  With 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 sys-
     tem can require that the user choose a new	password after a certain pe-
     riod 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 or popper is like giving a univer-
     sal root ticket out to the	entire world.  Never run a server that you
     have not checked out carefully.  Many servers do not need to be run as
     root.  For	example, the ntalk, comsat, and	finger daemons can be run in
     special user `sandboxes'.	A sandbox isn't	perfect	unless you go to a
     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 at-
     tacker must break through,	the lower the likelihood of his	success.  Root
     holes have	historically been found	in virtually every server ever run as
     root, including basic system servers.  If you are running a machine
     through which people only login via sshd and never	login via telnetd or
     rshd or rlogind, then turn	off those services!

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

     There are a number	of other servers that typically	do not run in sand-
     boxes: sendmail, popper, imapd, ftpd, and others.	There are alternatives
     to	some of	these, but installing them may require more work then you are
     willing to	put (the convenience factor strikes again).  You may have to
     run these servers as root and rely	on other mechanisms to detect 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, 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 (which is
     typically suid) vulnerable.  It is	better to be safe then 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 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 pty's, including
     pty's used	by users who login 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 fea-
     ture, 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.

     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'
     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 device compiled in.

     But even if you turn off the bpf 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 device or other sniffing device on a running ker-
     nel.  To avoid these problems you have to run the kernel at a higher se-
     cure level, at least securelevel 1.  The securelevel can be set with a
     sysctl on the kern.securelevel variable.  Once you	have set the se-
     curelevel to 1, write access to raw devices will be denied	and special
     chflags flags, such as `schg', will be enforced.  You must	also ensure
     that the `schg' flag is set on critical startup binaries, directories,
     and script	files -	everything that	gets run up to the point where the se-
     curelevel 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.

     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 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 then stop him in order to give the detection side of the equation
     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 hackers, 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 the
     client-box	files boxes at least once a day, and to	test control 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-ac-
     cess machine knows	is valid, it should scream at a	sysadmin to go check
     it	out.  A	good security script will also check for inappropriate suid
     binaries and for new or deleted files on system partitions	such as	/ and

     When using	ssh rather then	NFS, writing the security script is much more
     difficult.	  You essentially have to scp the scripts to the client	box in
     order to run them,	making them visible, and for safety you	also need to
     scp the binaries (such as find) that those	scripts	use.  The ssh daemon
     on	the client box may already be compromised.  All	in all,	using ssh may
     be	necessary when running over unsecure links, but	it's 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

     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 breakin
     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 effect	convenience, and can
     add security features that	do effect 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 hacker 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 isn't much you can do about modern spoofed
     packet attacks that saturate your network,	you can	generally limit	the
     damage by ensuring	that the attacks cannot	take down your servers.

	   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.  Inetd	(see inetd(8)) has several options to limit this sort
     of	attack.	 It should be noted that while it is possible to prevent a ma-
     chine from	going down it is not generally possible	to prevent a service
     from being	disrupted by the attack.  Read the inetd manual	page carefully
     and pay specific attention	to the -c, -C, and -R options.	Note that
     spoofed-IP	attacks	will circumvent	the -C option to inetd,	so typically a
     combination of options must be used.  Some	standalone servers have	self-
     fork-limitation parameters.

     Sendmail has its -OMaxDaemonChildren option which tends to	work much bet-
     ter than trying to	use sendmail's load limiting options due to the	load
     lag.  You should specify a	MaxDaemonChildren parameter when you start
     sendmail high enough to handle your expected load but no so high that the
     computer cannot handle that number	of sendmails without falling on	its
     face.  It is also prudent to run sendmail in queued mode
     (-ODeliveryMode=queued) and to run	the daemon (sendmail -bd) separate
     from the queue-runs (sendmail -q15m).  If you still want realtime deliv-
     ery you can run the queue at a much lower interval, such as -q1m, but be
     sure to specify a reasonable MaxDaemonChildren option for that sendmail
     to	prevent	cascade	failures.

     Syslogd can be attacked directly and it is	strongly recommended 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-

     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 (if you are primary for a zone),
     ntalkd, sendmail, and other internet-accessible services.	If you try to
     configure the firewall the	other way - as an inclusive or permissive
     firewall, there is	a good chance that you will forget to `close' a	couple
     of	services or that you will add a	new internal service and forget	to up-
     date 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.por-
     trange sysctl's (sysctl -a	| fgrep	portrange), which can also ease	the
     complexity	of your	firewall's configuration.  I usually use a normal
     first/last	range of 4000 to 5000, and a hiport range of 49152 to 65535,
     then block	everything under 4000 off in my	firewall (except for certain
     specific internet-accessible ports, of course).

     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	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 at-
     tacker 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-internal
     test services.

     Spoofed packet attacks may	also be	used to	overload the kernel route
     cache.  Refer to the net.inet.ip.rtexpire,	rtminexpire, and rtmaxcache
     sysctl parameters.	 A spoofed packet attack that uses a random source IP
     will cause	the kernel to generate a temporary cached route	in the route
     table, viewable with `netstat -rna	| fgrep	W3'.  These routes typically
     timeout in	1600 seconds or	so.  If	the kernel detects that	the cached
     route table has gotten too	big it will dynamically	reduce the rtexpire
     but will never decrease it	to less	then rtminexpire.  There are two prob-
     lems:  (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	con-
     nected to the internet via	a T3 or	better it may be prudent to manually
     override both rtexpire and	rtminexpire via	sysctl(8).  Never set either
     parameter to zero (unless you want	to crash the machine :-)).  Setting
     both parameters to	2 seconds should be sufficient to protect the route
     table from	attack.

     There are a few issues with both kerberos and ssh that need to be ad-
     dressed if	you intend to use them.	 Kerberos V is an excellent authenti-
     cation protocol but the kerberized	telnet and rlogin 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 to an unsecure	machine, your keys becomes exposed.  The actual	keys
     themselves	are not	exposed, but ssh installs a forwarding port for	the
     duration of your login and	if a hacker 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), kerberos(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)

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

BSD			      September	18, 1999			   BSD


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

home | help