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.8 2007/02/19 11:10:11 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 223effect all the machine 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 kern.securelevel variable. Once you have 350set the securelevel to 1, write access to raw devices will be denied and 351special chflags flags, such as 352.Sq schg , 353will be enforced. You must also ensure 354that the 355.Sq schg 356flag is set on critical startup binaries, directories, and 357script files - everything that gets run up to the point where the securelevel 358is set. This might be overdoing it, and upgrading the system is much more 359difficult when you operate at a higher secure level. You may compromise and 360run the system at a higher secure level but not set the schg flag for every 361system file and directory under the sun. Another possibility is to simply 362mount / and /usr read-only. It should be noted that being too draconian in 363what you attempt to protect may prevent the all-important detection of an 364intrusion. 365.Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC 366When it comes right down to it, you can only protect your core system 367configuration and control files so much before the convenience factor 368rears its ugly head. For example, using chflags to set the schg bit 369on most of the files in / and /usr is probably counterproductive because 370while it may protect the files, it also closes a detection window. The 371last layer of your security onion is perhaps the most important - detection. 372The rest of your security is pretty much useless (or, worse, presents you with 373a false sense of safety) if you cannot detect potential incursions. Half 374the job of the onion is to slow down the attacker rather than stop him 375in order to give the detection side of the equation a chance to catch him in 376the act. 377.Pp 378The best way to detect an incursion is to look for modified, missing, or 379unexpected files. The best 380way to look for modified files is from another (often centralized) 381limited-access system. 382Writing your security scripts on the extra-secure limited-access system 383makes them mostly invisible to potential hackers, and this is important. 384In order to take maximum advantage you generally have to give the 385limited-access box significant access to the other machines in the business, 386usually either by doing a read-only NFS export of the other machines to the 387limited-access box, or by setting up ssh keypairs to allow the limit-access 388box to ssh to the other machines. Except for its network traffic, NFS is 389the least visible method - allowing you to monitor the filesystems on each 390client box virtually undetected. If your 391limited-access server is connected to the client boxes through a switch, 392the NFS method is often the better choice. If your limited-access server 393is connected to the client boxes through a hub or through several layers 394of routing, the NFS method may be too insecure (network-wise) and using ssh 395may be the better choice even with the audit-trail tracks that ssh lays. 396.Pp 397Once you give a limit-access box at least read access to the client systems 398it is supposed to monitor, you must write scripts to do the actual 399monitoring. Given an NFS mount, you can write scripts out of simple system 400utilities such as 401.Xr find 1 402and 403.Xr md5 1 404It is best to physically md5 the client-box files boxes at least once a 405day, and to test control files such as those found in 406.Pa /etc 407and 408.Pa /usr/local/etc 409even more often. When mismatches are found relative to the base md5 410information the limited-access machine knows is valid, it should scream at 411a sysadmin to go check it out. A good security script will also check for 412inappropriate suid binaries and for new or deleted files on system partitions 413such as 414.Pa / 415and 416.Pa /usr 417.Pp 418When using ssh rather than NFS, writing the security script is much more 419difficult. You essentially have to 420.Pa scp 421the scripts to the client box in order to run them, making them visible, and 422for safety you also need to scp the binaries (such as find) that those scripts 423use. The ssh daemon on the client box may already be compromised. All in all, 424using ssh may be necessary when running over unsecure links, but it's also a 425lot harder to deal with. 426.Pp 427A good security script will also check for changes to user and staff members 428access configuration files: 429.Pa .rhosts , 430.Pa .shosts , 431.Pa .ssh/authorized_keys 432and so forth... files that might fall outside the purview of the MD5 check. 433.Pp 434If you have a huge amount of user disk space it may take too long to run 435through every file on those partitions. In this case, setting mount 436flags to disallow suid binaries and devices on those partitions is a good 437idea. The 438.Sq nodev 439and 440.Sq nosuid 441options 442(see 443.Xr mount 8 ) 444are what you want to look into. I would scan them anyway at least once a 445week, since the object of this layer is to detect a break-in whether or 446not the breakin is effective. 447.Pp 448Process accounting 449(see 450.Xr accton 8 ) 451is a relatively low-overhead feature of 452the operating system which I recommend using as a post-break-in evaluation 453mechanism. It is especially useful in tracking down how an intruder has 454actually broken into a system, assuming the file is still intact after 455the break-in occurs. 456.Pp 457Finally, security scripts should process the log files and the logs themselves 458should be generated in as secure a manner as possible - remote syslog can be 459very useful. An intruder tries to cover his tracks, and log files are critical 460to the sysadmin trying to track down the time and method of the initial 461break-in. One way to keep a permanent record of the log files is to run 462the system console to a serial port and collect the information on a 463continuing basis through a secure machine monitoring the consoles. 464.Sh PARANOIA 465A little paranoia never hurts. As a rule, a sysadmin can add any number 466of security features as long as they do not affect convenience, and 467can add security features that do affect convenience with some added 468thought. Even more importantly, a security administrator should mix it up 469a bit - if you use recommendations such as those given by this manual 470page verbatim, you give away your methodologies to the prospective 471hacker who also has access to this manual page. 472.Sh SPECIAL SECTION ON D.O.S. ATTACKS 473This section covers Denial of Service attacks. A DOS attack is typically 474a packet attack. While there isn't much you can do about modern spoofed 475packet attacks that saturate your network, you can generally limit the damage 476by ensuring that the attacks cannot take down your servers. 477.Bl -enum -offset indent 478.It 479Limiting server forks 480.It 481Limiting springboard attacks (ICMP response attacks, ping broadcast, etc...) 482.It 483Kernel Route Cache 484.El 485.Pp 486A common D.O.S. attack is against a forking server that attempts to cause the 487server to eat processes, file descriptors, and memory until the machine 488dies. Inetd 489(see 490.Xr inetd 8 ) 491has several options to limit this sort of attack. 492It should be noted that while it is possible to prevent a machine from going 493down it is not generally possible to prevent a service from being disrupted 494by the attack. Read the inetd manual page carefully and pay specific attention 495to the 496.Fl c , 497.Fl C , 498and 499.Fl R 500options. Note that spoofed-IP attacks will circumvent 501the 502.Fl C 503option to inetd, so typically a combination of options must be used. 504Some standalone servers have self-fork-limitation parameters. 505.Pp 506Sendmail has its 507.Fl OMaxDaemonChildren 508option which tends to work much 509better than trying to use sendmail's load limiting options due to the 510load lag. You should specify a 511.Cm MaxDaemonChildren 512parameter when you start 513sendmail high enough to handle your expected load but no so high that the 514computer cannot handle that number of sendmails without falling on its face. 515It is also prudent to run sendmail in queued mode 516.Pq Fl ODeliveryMode=queued 517and to run the daemon 518.Pq Cm sendmail -bd 519separate from the queue-runs 520.Pq Cm sendmail -q15m . 521If you still want realtime delivery you can run the queue 522at a much lower interval, such as 523.Fl q1m , 524but be sure to specify a reasonable 525.Cm MaxDaemonChildren 526option for that sendmail to prevent cascade failures. 527.Pp 528Syslogd can be attacked directly and it is strongly recommended that you use 529the 530.Fl s 531option whenever possible, and the 532.Fl a 533option otherwise. 534.Pp 535You should also be fairly careful 536with connect-back services such as tcpwrapper's reverse-identd, which can 537be attacked directly. You generally do not want to use the reverse-ident 538feature of tcpwrappers for this reason. 539.Pp 540It is a very good idea to protect internal services from external access 541by firewalling them off at your border routers. The idea here is to prevent 542saturation attacks from outside your LAN, not so much to protect internal 543services from network-based root compromise. Always configure an exclusive 544firewall, i.e.\& 545.So 546firewall everything *except* ports A, B, C, D, and M-Z 547.Sc . 548This 549way you can firewall off all of your low ports except for certain specific 550services such as named 551(if you are primary for a zone), 552ntalkd, sendmail, 553and other internet-accessible services. 554If you try to configure the firewall the other 555way - as an inclusive or permissive firewall, there is a good chance that you 556will forget to 557.Sq close 558a couple of services or that you will add a new internal 559service and forget to update the firewall. You can still open up the 560high-numbered port range on the firewall to allow permissive-like operation 561without compromising your low ports. Also take note that 562.Dx 563allows you to 564control the range of port numbers used for dynamic binding via the various 565net.inet.ip.portrange sysctl's 566.Pq Li "sysctl -a | fgrep portrange" , 567which can also 568ease the complexity of your firewall's configuration. I usually use a normal 569first/last range of 4000 to 5000, and a hiport range of 49152 to 65535, then 570block everything under 4000 off in my firewall 571(except for certain specific 572internet-accessible ports, of course). 573.Pp 574Another common D.O.S. attack is called a springboard attack - to attack a server 575in a manner that causes the server to generate responses which then overload 576the server, the local network, or some other machine. The most common attack 577of this nature is the ICMP PING BROADCAST attack. The attacker spoofs ping 578packets sent to your LAN's broadcast address with the source IP address set 579to the actual machine they wish to attack. If your border routers are not 580configured to stomp on ping's to broadcast addresses, your LAN winds up 581generating sufficient responses to the spoofed source address to saturate the 582victim, especially when the attacker uses the same trick on several dozen 583broadcast addresses over several dozen different networks at once. Broadcast 584attacks of over a hundred and twenty megabits have been measured. A second 585common springboard attack is against the ICMP error reporting system. By 586constructing packets that generate ICMP error responses, an attacker can 587saturate a server's incoming network and cause the server to saturate its 588outgoing network with ICMP responses. This type of attack can also crash the 589server by running it out of mbuf's, especially if the server cannot drain the 590ICMP responses it generates fast enough. The 591.Dx 592kernel has a new kernel 593compile option called ICMP_BANDLIM which limits the effectiveness of these 594sorts of attacks. The last major class of springboard attacks is related to 595certain internal inetd services such as the udp echo service. An attacker 596simply spoofs a UDP packet with the source address being server A's echo port, 597and the destination address being server B's echo port, where server A and B 598are both on your LAN. The two servers then bounce this one packet back and 599forth between each other. The attacker can overload both servers and their 600LANs simply by injecting a few packets in this manner. Similar problems 601exist with the internal chargen port. A competent sysadmin will turn off all 602of these inetd-internal test services. 603.Pp 604Spoofed packet attacks may also be used to overload the kernel route cache. 605Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache sysctl 606parameters. A spoofed packet attack that uses a random source IP will cause 607the kernel to generate a temporary cached route in the route table, viewable 608with 609.Sq netstat -rna \&| fgrep W3 . 610These routes typically timeout in 1600 611seconds or so. If the kernel detects that the cached route table has gotten 612too big it will dynamically reduce the rtexpire but will never decrease it to 613less then rtminexpire. There are two problems: (1) The kernel does not react 614quickly enough when a lightly loaded server is suddenly attacked, and (2) The 615rtminexpire is not low enough for the kernel to survive a sustained attack. 616If your servers are connected to the internet via a T3 or better it may be 617prudent to manually override both rtexpire and rtminexpire via 618.Xr sysctl 8 . 619Never set either parameter to zero 620(unless you want to crash the machine :-)). 621Setting both parameters to 2 seconds should be sufficient to protect the route 622table from attack. 623.Sh ACCESS ISSUES WITH KERBEROS AND SSH 624There are a few issues with both kerberos and ssh that need to be addressed 625if you intend to use them. Kerberos V is an excellent authentication 626protocol but the kerberized telnet and rlogin suck rocks. There are bugs that 627make them unsuitable for dealing with binary streams. Also, by default 628kerberos does not encrypt a session unless you use the 629.Fl x 630option. Ssh encrypts everything by default. 631.Pp 632Ssh works quite well in every respect except when it is set up to 633forward encryption keys. 634What this means is that if you have a secure workstation holding 635keys that give you access to the rest of the system, and you ssh to an 636unsecure machine, your keys becomes exposed. The actual keys themselves are 637not exposed, but ssh installs a forwarding port for the duration of your 638login and if a hacker has broken root on the unsecure machine he can utilize 639that port to use your keys to gain access to any other machine that your 640keys unlock. 641.Pp 642We recommend that you use ssh in combination with kerberos whenever possible 643for staff logins. Ssh can be compiled with kerberos support. This reduces 644your reliance on potentially exposable ssh keys while at the same time 645protecting passwords via kerberos. Ssh keys 646should only be used for automated tasks from secure machines (something 647that kerberos is unsuited to). We also recommend that you either turn off 648key-forwarding in the ssh configuration, or that you make use of the 649.Pa "from=IP/DOMAIN" 650option that ssh allows in its 651.Pa authorized_keys 652file to make the key only usable to entities logging in from specific 653machines. 654.Sh SEE ALSO 655.Xr chflags 1 , 656.Xr find 1 , 657.Xr md5 1 , 658.Xr netstat 1 , 659.Xr openssl 1 , 660.Xr ssh 1 , 661.Xr xdm 1 , 662.Xr group 5 , 663.Xr ttys 5 , 664.Xr accton 8 , 665.Xr init 8 , 666.Xr kerberos 8 , 667.Xr sshd 8 , 668.Xr sysctl 8 , 669.Xr syslogd 8 , 670.Xr vipw 8 671.Sh HISTORY 672The 673.Nm 674manual page was originally written by 675.An Matthew Dillon 676and first appeared 677in 678.Fx 3.1 , 679December 1998. 680