1.\" Copyright (c) 1998 Matthew Dillon. Terms and conditions are those of 2.\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in 3.\" the source tree. 4.\" 5.\" $FreeBSD: src/share/man/man7/security.7,v 1.13.2.11 2002/04/13 02:04:44 keramida Exp $ 6.\" $DragonFly: src/share/man/man7/security.7,v 1.10 2007/09/14 23:47:53 swildner Exp $ 7.\" 8.Dd September 18, 1999 9.Dt SECURITY 7 10.Os 11.Sh NAME 12.Nm security 13.Nd introduction to security under 14.Dx 15.Sh DESCRIPTION 16Security is a function that begins and ends with the system administrator. 17While all 18.Bx 19multi-user systems have some inherent security, the job of building and 20maintaining additional security mechanisms to keep users 21.Sq honest 22is probably 23one of the single largest undertakings of the sysadmin. Machines are 24only as secure as you make them, and security concerns are ever competing 25with the human necessity for convenience. 26.Ux 27systems, 28in general, are capable of running a huge number of simultaneous processes 29and many of these processes operate as servers - meaning that external entities 30can connect and talk to them. As yesterday's mini-computers and mainframes 31become today's desktops, and as computers become networked and internetworked, 32security becomes an ever bigger issue. 33.Pp 34Security is best implemented through a layered onion approach. In a nutshell, 35what you want to do is to create as many layers of security as are convenient 36and then carefully monitor the system for intrusions. You do not want to 37overbuild your security or you will interfere with the detection side, and 38detection is one of the single most important aspects of any security 39mechanism. For example, it makes little sense to set the 40.Pa schg 41flags 42(see 43.Xr chflags 1 ) 44on every system binary because while this may temporarily protect the 45binaries, it prevents a hacker who has broken in from making an 46easily detectable change that may result in your security mechanisms not 47detecting the hacker at all. 48.Pp 49System security also pertains to dealing with various forms of attack, 50including attacks that attempt to crash or otherwise make a system unusable 51but do not attempt to break root. Security concerns can be split up into 52several categories: 53.Bl -enum -offset indent 54.It 55Denial of service attacks 56.It 57User account compromises 58.It 59Root compromise through accessible servers 60.It 61Root compromise via user accounts 62.It 63Backdoor creation 64.El 65.Pp 66A denial of service attack is an action that deprives the machine of needed 67resources. Typically, D.O.S. attacks are brute-force mechanisms that attempt 68to crash or otherwise make a machine unusable by overwhelming its servers or 69network stack. Some D.O.S. attacks try to take advantages of bugs in the 70networking stack to crash a machine with a single packet. The latter can 71only be fixed by applying a bug fix to the kernel. Attacks on servers can 72often be fixed by properly specifying options to limit the load the servers 73incur on the system under adverse conditions. Brute-force network 74attacks are harder to deal with. A spoofed-packet attack, for example, is 75nearly impossible to stop short of cutting your system off from the Internet. 76It may not be able to take your machine down, but it can fill up Internet 77pipe. 78.Pp 79A user account compromise is even more common then a D.O.S. attack. Many 80sysadmins still run standard telnetd, rlogind, rshd, and ftpd servers on their 81machines. These servers, by default, do not operate over encrypted 82connections. The result is that if you have any moderate-sized user base, 83one or more of your users logging into your system from a remote location 84(which is the most common and convenient way to login to a system) 85will 86have his or her password sniffed. The attentive system admin will analyze 87his remote access logs looking for suspicious source addresses 88even for successful logins. 89.Pp 90One must always assume that once an attacker has access to a user account, 91the attacker can break root. However, the reality is that in a well secured 92and maintained system, access to a user account does not necessarily give the 93attacker access to root. The distinction is important because without access 94to root the attacker cannot generally hide his tracks and may, at best, be 95able to do nothing more than mess with the user's files or crash the machine. 96User account compromises are very common because users tend not to take the 97precautions that sysadmins take. 98.Pp 99System administrators must keep in mind that there are potentially many ways 100to break root on a machine. The attacker may know the root password, 101the attacker 102may find a bug in a root-run server and be able to break root over a network 103connection to that server, or the attacker may know of a bug in an suid-root 104program that allows the attacker to break root once he has broken into a 105user's account. If an attacker has found a way to break root on a machine, 106the attacker may not have a need to install a backdoor. 107Many of the root holes found and closed to date involve a considerable amount 108of work by the hacker to cleanup after himself, so most hackers do install 109backdoors. This gives you a convenient way to detect the hacker. Making 110it impossible for a hacker to install a backdoor may actually be detrimental 111to your security because it will not close off the hole the hacker found to 112break in the first place. 113.Pp 114Security remedies should always be implemented with a multi-layered 115.Sq onion peel 116approach and can be categorized as follows: 117.Bl -enum -offset indent 118.It 119Securing root and staff accounts 120.It 121Securing root - root-run servers and suid/sgid binaries 122.It 123Securing user accounts 124.It 125Securing the password file 126.It 127Securing the kernel core, raw devices, and filesystems 128.It 129Quick detection of inappropriate changes made to the system 130.It 131Paranoia 132.El 133.Sh SECURING THE ROOT ACCOUNT AND SECURING STAFF ACCOUNTS 134Don't bother securing staff accounts if you haven't secured the root 135account. Most systems have a password assigned to the root account. The 136first thing you do is assume that the password is 137.Sq always 138compromised. This does not mean that you should remove the password. The 139password is almost always necessary for console access to the machine. 140What it does mean is that you should not make it possible to use the password 141outside of the console or possibly even with a 142.Xr su 1 143command. 144For example, make sure that your pty's are specified as being unsecure 145in the 146.Sq Pa /etc/ttys 147file 148so that direct root logins via telnet or rlogin are disallowed. If using 149other login services such as sshd, make sure that direct root logins are 150disabled there as well. Consider every access method - services such as 151ftp often fall through the cracks. Direct root logins should only be allowed 152via the system console. 153.Pp 154Of course, as a sysadmin you have to be able to get to root, so we open up 155a few holes. But we make sure these holes require additional password 156verification to operate. One way to make root accessible is to add appropriate 157staff accounts to the wheel group 158(in 159.Pa /etc/group ) . 160The staff members placed 161in the wheel group are allowed to 162.Sq su 163to root. You should never give staff 164members native wheel access by putting them in the wheel group in their 165password entry. Staff accounts should be placed in a 166.Sq staff 167group, and then added to the wheel group via the 168.Sq Pa /etc/group 169file. Only those staff members who actually need to have root access 170should be placed in the wheel group. It is also possible, when using an 171authentication method such as kerberos, to use kerberos's 172.Sq Pa .k5login 173file in the root account to allow a 174.Xr ksu 1 175to root without having to place anyone at all in the wheel group. This 176may be the better solution since the wheel mechanism still allows an 177intruder to break root if the intruder has gotten hold of your password 178file and can break into a staff account. While having the wheel mechanism 179is better then having nothing at all, it isn't necessarily the safest 180option. 181.Pp 182An indirect way to secure the root account is to secure your staff accounts 183by using an alternative login access method and *'ing out the crypted password 184for the staff accounts. This way an intruder may be able to steal the password 185file but will not be able to break into any staff accounts (or, indirectly, 186root, even if root has a crypted password associated with it). Staff members 187get into their staff accounts through a secure login mechanism such as 188.Xr kerberos 8 189or 190.Xr ssh 1 191using a private/public 192key pair. When you use something like kerberos you generally must secure 193the machines which run the kerberos servers and your desktop workstation. 194When you use a public/private key pair with ssh, you must generally secure 195the machine you are logging in FROM 196(typically your workstation), 197but you can 198also add an additional layer of protection to the key pair by password 199protecting the keypair when you create it with 200.Xr ssh-keygen 1 . 201Being able 202to *-out the passwords for staff accounts also guarantees that staff members 203can only login through secure access methods that you have setup. You can 204thus force all staff members to use secure, encrypted connections for 205all their sessions which closes an important hole used by many intruders: That 206of sniffing the network from an unrelated, less secure machine. 207.Pp 208The more indirect security mechanisms also assume that you are logging in 209from a more restrictive server to a less restrictive server. For example, 210if your main box is running all sorts of servers, your workstation shouldn't 211be running any. In order for your workstation to be reasonably secure 212you should run as few servers as possible, up to and including no servers 213at all, and you should run a password-protected screen blanker. 214Of course, given physical access to 215a workstation an attacker can break any sort of security you put on it. 216This is definitely a problem that you should consider but you should also 217consider the fact that the vast majority of break-ins occur remotely, over 218a network, from people who do not have physical access to your workstation or 219servers. 220.Pp 221Using something like kerberos also gives you the ability to disable or 222change the password for a staff account in one place and have it immediately 223affect all the machines the staff member may have an account on. If a staff 224member's account gets compromised, the ability to instantly change his 225password on all machines should not be underrated. With discrete passwords, 226changing a password on N machines can be a mess. You can also impose 227re-passwording restrictions with kerberos: not only can a kerberos ticket 228be made to timeout after a while, but the kerberos system can require that 229the user choose a new password after a certain period of time 230(say, once a month). 231.Sh SECURING ROOT - ROOT-RUN SERVERS AND SUID/SGID BINARIES 232The prudent sysadmin only runs the servers he needs to, no more, no less. Be 233aware that third party servers are often the most bug-prone. For example, 234running an old version of imapd or popper is like giving a universal root 235ticket out to the entire world. Never run a server that you have not checked 236out carefully. Many servers do not need to be run as root. For example, 237the ntalk, comsat, and finger daemons can be run in special user 238.Sq sandboxes . 239A sandbox isn't perfect unless you go to a large amount of trouble, but the 240onion approach to security still stands: If someone is able to break in 241through a server running in a sandbox, they still have to break out of the 242sandbox. The more layers the attacker must break through, the lower the 243likelihood of his success. Root holes have historically been found in 244virtually every server ever run as root, including basic system servers. 245If you are running a machine through which people only login via sshd and 246never login via telnetd or rshd or rlogind, then turn off those services! 247.Pp 248.Dx 249now defaults to running ntalkd, comsat, and finger in a sandbox. 250Another program which may be a candidate for running in a sandbox is 251.Xr named 8 . 252The default rc.conf includes the arguments necessary to run 253named in a sandbox in a commented-out form. Depending on whether you 254are installing a new system or upgrading an existing system, the special 255user accounts used by these sandboxes may not be installed. The prudent 256sysadmin would research and implement sandboxes for servers whenever possible. 257.Pp 258There are a number of other servers that typically do not run in sandboxes: 259sendmail, popper, imapd, ftpd, and others. There are alternatives to 260some of these, but installing them may require more work than you are willing 261to put 262(the convenience factor strikes again). 263You may have to run these 264servers as root and rely on other mechanisms to detect break-ins that might 265occur through them. 266.Pp 267The other big potential root hole in a system are the suid-root and sgid 268binaries installed on the system. Most of these binaries, such as rlogin, 269reside in 270.Pa /bin , 271.Pa /sbin , 272.Pa /usr/bin , 273or 274.Pa /usr/sbin . 275While nothing is 100% safe, 276the system-default suid and sgid binaries can be considered reasonably safe. 277Still, root holes are occasionally found in these binaries. A root hole 278was found in Xlib in 1998 that made xterm 279(which is typically suid) 280vulnerable. 281It is better to be safe then sorry and the prudent sysadmin will restrict suid 282binaries that only staff should run to a special group that only staff can 283access, and get rid of 284.Pq Li "chmod 000" 285any suid binaries that nobody uses. A 286server with no display generally does not need an xterm binary. Sgid binaries 287can be almost as dangerous. If an intruder can break an sgid-kmem binary the 288intruder might be able to read 289.Pa /dev/kmem 290and thus read the crypted password 291file, potentially compromising any passworded account. Alternatively an 292intruder who breaks group kmem can monitor keystrokes sent through pty's, 293including pty's used by users who login through secure methods. An intruder 294that breaks the tty group can write to almost any user's tty. If a user 295is running a terminal 296program or emulator with a keyboard-simulation feature, the intruder can 297potentially 298generate a data stream that causes the user's terminal to echo a command, which 299is then run as that user. 300.Sh SECURING USER ACCOUNTS 301User accounts are usually the most difficult to secure. While you can impose 302Draconian access restrictions on your staff and *-out their passwords, you 303may not be able to do so with any general user accounts you might have. If 304you do have sufficient control then you may win out and be able to secure the 305user accounts properly. If not, you simply have to be more vigilant in your 306monitoring of those accounts. Use of ssh and kerberos for user accounts is 307more problematic due to the extra administration and technical support 308required, but still a very good solution compared to a crypted password 309file. 310.Sh SECURING THE PASSWORD FILE 311The only sure-fire way is to *-out as many passwords as you can and 312use ssh or kerberos for access to those accounts. Even though the 313crypted password file 314.Pq Pa /etc/spwd.db 315can only be read by root, it may 316be possible for an intruder to obtain read access to that file even if the 317attacker cannot obtain root-write access. 318.Pp 319Your security scripts should always check for and report changes to 320the password file 321(see 322.Sq Checking file integrity 323below). 324.Sh SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS 325If an attacker breaks root he can do just about anything, but there 326are certain conveniences. For example, most modern kernels have a 327packet sniffing device driver built in. Under 328.Dx 329it is called 330the 331.Sq bpf 332device. An intruder will commonly attempt to run a packet sniffer 333on a compromised machine. You do not need to give the intruder the 334capability and most systems should not have the bpf device compiled in. 335.Pp 336But even if you turn off the bpf device, 337you still have 338.Pa /dev/mem 339and 340.Pa /dev/kmem 341to worry about. For that matter, 342the intruder can still write to raw disk devices. 343Also, there is another kernel feature called the module loader, 344.Xr kldload 8 . 345An enterprising intruder can use a KLD module to install 346his own bpf device or other sniffing device on a running kernel. 347To avoid these problems you have to run 348the kernel at a higher secure level, at least securelevel 1. The securelevel 349can be set with a sysctl on the 350.Va kern.securelevel 351variable. Once you have 352set the securelevel to 1, write access to raw devices will be denied and 353special chflags flags, such as 354.Sq schg , 355will be enforced. You must also ensure 356that the 357.Sq schg 358flag is set on critical startup binaries, directories, and 359script files - everything that gets run up to the point where the securelevel 360is set. This might be overdoing it, and upgrading the system is much more 361difficult when you operate at a higher secure level. You may compromise and 362run the system at a higher secure level but not set the schg flag for every 363system file and directory under the sun. Another possibility is to simply 364mount / and /usr read-only. It should be noted that being too draconian in 365what you attempt to protect may prevent the all-important detection of an 366intrusion. 367.Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC 368When it comes right down to it, you can only protect your core system 369configuration and control files so much before the convenience factor 370rears its ugly head. For example, using chflags to set the schg bit 371on most of the files in / and /usr is probably counterproductive because 372while it may protect the files, it also closes a detection window. The 373last layer of your security onion is perhaps the most important - detection. 374The rest of your security is pretty much useless (or, worse, presents you with 375a false sense of safety) if you cannot detect potential incursions. Half 376the job of the onion is to slow down the attacker rather than stop him 377in order to give the detection side of the equation a chance to catch him in 378the act. 379.Pp 380The best way to detect an incursion is to look for modified, missing, or 381unexpected files. The best 382way to look for modified files is from another (often centralized) 383limited-access system. 384Writing your security scripts on the extra-secure limited-access system 385makes them mostly invisible to potential hackers, and this is important. 386In order to take maximum advantage you generally have to give the 387limited-access box significant access to the other machines in the business, 388usually either by doing a read-only NFS export of the other machines to the 389limited-access box, or by setting up ssh keypairs to allow the limit-access 390box to ssh to the other machines. Except for its network traffic, NFS is 391the least visible method - allowing you to monitor the filesystems on each 392client box virtually undetected. If your 393limited-access server is connected to the client boxes through a switch, 394the NFS method is often the better choice. If your limited-access server 395is connected to the client boxes through a hub or through several layers 396of routing, the NFS method may be too insecure (network-wise) and using ssh 397may be the better choice even with the audit-trail tracks that ssh lays. 398.Pp 399Once you give a limit-access box at least read access to the client systems 400it is supposed to monitor, you must write scripts to do the actual 401monitoring. Given an NFS mount, you can write scripts out of simple system 402utilities such as 403.Xr find 1 404and 405.Xr md5 1 406It is best to physically md5 the client-box files boxes at least once a 407day, and to test control files such as those found in 408.Pa /etc 409and 410.Pa /usr/local/etc 411even more often. When mismatches are found relative to the base md5 412information the limited-access machine knows is valid, it should scream at 413a sysadmin to go check it out. A good security script will also check for 414inappropriate suid binaries and for new or deleted files on system partitions 415such as 416.Pa / 417and 418.Pa /usr 419.Pp 420When using ssh rather than NFS, writing the security script is much more 421difficult. You essentially have to 422.Pa scp 423the scripts to the client box in order to run them, making them visible, and 424for safety you also need to scp the binaries (such as find) that those scripts 425use. The ssh daemon on the client box may already be compromised. All in all, 426using ssh may be necessary when running over unsecure links, but it's also a 427lot harder to deal with. 428.Pp 429A good security script will also check for changes to user and staff members 430access configuration files: 431.Pa .rhosts , 432.Pa .shosts , 433.Pa .ssh/authorized_keys 434and so forth... files that might fall outside the purview of the MD5 check. 435.Pp 436If you have a huge amount of user disk space it may take too long to run 437through every file on those partitions. In this case, setting mount 438flags to disallow suid binaries and devices on those partitions is a good 439idea. The 440.Sq nodev 441and 442.Sq nosuid 443options 444(see 445.Xr mount 8 ) 446are what you want to look into. I would scan them anyway at least once a 447week, since the object of this layer is to detect a break-in whether or 448not the breakin is effective. 449.Pp 450Process accounting 451(see 452.Xr accton 8 ) 453is a relatively low-overhead feature of 454the operating system which I recommend using as a post-break-in evaluation 455mechanism. It is especially useful in tracking down how an intruder has 456actually broken into a system, assuming the file is still intact after 457the break-in occurs. 458.Pp 459Finally, security scripts should process the log files and the logs themselves 460should be generated in as secure a manner as possible - remote syslog can be 461very useful. An intruder tries to cover his tracks, and log files are critical 462to the sysadmin trying to track down the time and method of the initial 463break-in. One way to keep a permanent record of the log files is to run 464the system console to a serial port and collect the information on a 465continuing basis through a secure machine monitoring the consoles. 466.Sh PARANOIA 467A little paranoia never hurts. As a rule, a sysadmin can add any number 468of security features as long as they do not affect convenience, and 469can add security features that do affect convenience with some added 470thought. Even more importantly, a security administrator should mix it up 471a bit - if you use recommendations such as those given by this manual 472page verbatim, you give away your methodologies to the prospective 473hacker who also has access to this manual page. 474.Sh SPECIAL SECTION ON D.O.S. ATTACKS 475This section covers Denial of Service attacks. A DOS attack is typically 476a packet attack. While there isn't much you can do about modern spoofed 477packet attacks that saturate your network, you can generally limit the damage 478by ensuring that the attacks cannot take down your servers. 479.Bl -enum -offset indent 480.It 481Limiting server forks 482.It 483Limiting springboard attacks (ICMP response attacks, ping broadcast, etc...) 484.It 485Kernel Route Cache 486.El 487.Pp 488A common D.O.S. attack is against a forking server that attempts to cause the 489server to eat processes, file descriptors, and memory until the machine 490dies. Inetd 491(see 492.Xr inetd 8 ) 493has several options to limit this sort of attack. 494It should be noted that while it is possible to prevent a machine from going 495down it is not generally possible to prevent a service from being disrupted 496by the attack. Read the inetd manual page carefully and pay specific attention 497to the 498.Fl c , 499.Fl C , 500and 501.Fl R 502options. Note that spoofed-IP attacks will circumvent 503the 504.Fl C 505option to inetd, so typically a combination of options must be used. 506Some standalone servers have self-fork-limitation parameters. 507.Pp 508Sendmail has its 509.Fl OMaxDaemonChildren 510option which tends to work much 511better than trying to use sendmail's load limiting options due to the 512load lag. You should specify a 513.Cm MaxDaemonChildren 514parameter when you start 515sendmail high enough to handle your expected load but no so high that the 516computer cannot handle that number of sendmails without falling on its face. 517It is also prudent to run sendmail in queued mode 518.Pq Fl ODeliveryMode=queued 519and to run the daemon 520.Pq Cm sendmail -bd 521separate from the queue-runs 522.Pq Cm sendmail -q15m . 523If you still want realtime delivery you can run the queue 524at a much lower interval, such as 525.Fl q1m , 526but be sure to specify a reasonable 527.Cm MaxDaemonChildren 528option for that sendmail to prevent cascade failures. 529.Pp 530Syslogd can be attacked directly and it is strongly recommended that you use 531the 532.Fl s 533option whenever possible, and the 534.Fl a 535option otherwise. 536.Pp 537You should also be fairly careful 538with connect-back services such as tcpwrapper's reverse-identd, which can 539be attacked directly. You generally do not want to use the reverse-ident 540feature of tcpwrappers for this reason. 541.Pp 542It is a very good idea to protect internal services from external access 543by firewalling them off at your border routers. The idea here is to prevent 544saturation attacks from outside your LAN, not so much to protect internal 545services from network-based root compromise. Always configure an exclusive 546firewall, i.e.\& 547.So 548firewall everything *except* ports A, B, C, D, and M-Z 549.Sc . 550This 551way you can firewall off all of your low ports except for certain specific 552services such as named 553(if you are primary for a zone), 554ntalkd, sendmail, 555and other internet-accessible services. 556If you try to configure the firewall the other 557way - as an inclusive or permissive firewall, there is a good chance that you 558will forget to 559.Sq close 560a couple of services or that you will add a new internal 561service and forget to update the firewall. You can still open up the 562high-numbered port range on the firewall to allow permissive-like operation 563without compromising your low ports. Also take note that 564.Dx 565allows you to 566control the range of port numbers used for dynamic binding via the various 567net.inet.ip.portrange sysctl's 568.Pq Li "sysctl -a | fgrep portrange" , 569which can also 570ease the complexity of your firewall's configuration. I usually use a normal 571first/last range of 4000 to 5000, and a hiport range of 49152 to 65535, then 572block everything under 4000 off in my firewall 573(except for certain specific 574internet-accessible ports, of course). 575.Pp 576Another common D.O.S. attack is called a springboard attack - to attack a server 577in a manner that causes the server to generate responses which then overload 578the server, the local network, or some other machine. The most common attack 579of this nature is the ICMP PING BROADCAST attack. The attacker spoofs ping 580packets sent to your LAN's broadcast address with the source IP address set 581to the actual machine they wish to attack. If your border routers are not 582configured to stomp on ping's to broadcast addresses, your LAN winds up 583generating sufficient responses to the spoofed source address to saturate the 584victim, especially when the attacker uses the same trick on several dozen 585broadcast addresses over several dozen different networks at once. Broadcast 586attacks of over a hundred and twenty megabits have been measured. A second 587common springboard attack is against the ICMP error reporting system. By 588constructing packets that generate ICMP error responses, an attacker can 589saturate a server's incoming network and cause the server to saturate its 590outgoing network with ICMP responses. This type of attack can also crash the 591server by running it out of mbuf's, especially if the server cannot drain the 592ICMP responses it generates fast enough. The 593.Dx 594kernel has a new kernel 595compile option called ICMP_BANDLIM which limits the effectiveness of these 596sorts of attacks. The last major class of springboard attacks is related to 597certain internal inetd services such as the udp echo service. An attacker 598simply spoofs a UDP packet with the source address being server A's echo port, 599and the destination address being server B's echo port, where server A and B 600are both on your LAN. The two servers then bounce this one packet back and 601forth between each other. The attacker can overload both servers and their 602LANs simply by injecting a few packets in this manner. Similar problems 603exist with the internal chargen port. A competent sysadmin will turn off all 604of these inetd-internal test services. 605.Pp 606Spoofed packet attacks may also be used to overload the kernel route cache. 607Refer to the 608.Va net.inet.ip.rtexpire , 609.Va net.inet.ip.rtminexpire , 610and 611.Va net.inet.ip.rtmaxcache 612sysctl 613parameters. A spoofed packet attack that uses a random source IP will cause 614the kernel to generate a temporary cached route in the route table, viewable 615with 616.Sq netstat -rna \&| fgrep W3 . 617These routes typically timeout in 1600 618seconds or so. If the kernel detects that the cached route table has gotten 619too big it will dynamically reduce the rtexpire but will never decrease it to 620less then rtminexpire. There are two problems: (1) The kernel does not react 621quickly enough when a lightly loaded server is suddenly attacked, and (2) The 622rtminexpire is not low enough for the kernel to survive a sustained attack. 623If your servers are connected to the internet via a T3 or better it may be 624prudent to manually override both rtexpire and rtminexpire via 625.Xr sysctl 8 . 626Never set either parameter to zero 627(unless you want to crash the machine :-)). 628Setting both parameters to 2 seconds should be sufficient to protect the route 629table from attack. 630.Sh ACCESS ISSUES WITH KERBEROS AND SSH 631There are a few issues with both kerberos and ssh that need to be addressed 632if you intend to use them. Kerberos V is an excellent authentication 633protocol but the kerberized telnet and rlogin suck rocks. There are bugs that 634make them unsuitable for dealing with binary streams. Also, by default 635kerberos does not encrypt a session unless you use the 636.Fl x 637option. Ssh encrypts everything by default. 638.Pp 639Ssh works quite well in every respect except when it is set up to 640forward encryption keys. 641What this means is that if you have a secure workstation holding 642keys that give you access to the rest of the system, and you ssh to an 643unsecure machine, your keys becomes exposed. The actual keys themselves are 644not exposed, but ssh installs a forwarding port for the duration of your 645login and if a hacker has broken root on the unsecure machine he can utilize 646that port to use your keys to gain access to any other machine that your 647keys unlock. 648.Pp 649We recommend that you use ssh in combination with kerberos whenever possible 650for staff logins. Ssh can be compiled with kerberos support. This reduces 651your reliance on potentially exposable ssh keys while at the same time 652protecting passwords via kerberos. Ssh keys 653should only be used for automated tasks from secure machines (something 654that kerberos is unsuited to). We also recommend that you either turn off 655key-forwarding in the ssh configuration, or that you make use of the 656.Pa "from=IP/DOMAIN" 657option that ssh allows in its 658.Pa authorized_keys 659file to make the key only usable to entities logging in from specific 660machines. 661.Sh SEE ALSO 662.Xr chflags 1 , 663.Xr find 1 , 664.Xr md5 1 , 665.Xr netstat 1 , 666.Xr openssl 1 , 667.Xr ssh 1 , 668.Xr xdm 1 , 669.Xr group 5 , 670.Xr ttys 5 , 671.Xr accton 8 , 672.Xr init 8 , 673.Xr kerberos 8 , 674.Xr sshd 8 , 675.Xr sysctl 8 , 676.Xr syslogd 8 , 677.Xr vipw 8 678.Sh HISTORY 679The 680.Nm 681manual page was originally written by 682.An Matthew Dillon 683and first appeared 684in 685.Fx 3.1 , 686December 1998. 687