hack sun book hack proofing sun solaris phần 4 potx

Securing Your Users • Chapter 4 105 Admintool allows easy configuration of these options for each user. However, managing a large number of accounts with Admintool would be cumbersome and time-consuming. It is better to understand how Solaris determines account and authentication policy, in order to ease configuration for large domains. Three key files determine how Solaris user authentication and policy operate. The first, /etc/default/login, controls a variety of security settings at login.Table 4.2 explains the purpose and security implications of each of these settings. Table 4.2 Login Policy Variables Variable Purpose CONSOLE If set to YES, this restricts root logins to the system console. Root cannot log in over rlogin, rsh, or Telnet. This does not prevent a user login followed by su. This feature is useful to prevent mistakes by novice systems administrators or to prevent the use of an .rhosts file created to automate a task. SYSLOG If set, root logins are logged at LOG_AUTH and multiple failed login attempts are logged at LOG_CRIT. UMASK Initial shell umask. By default, 022. More restrictive sites may want to set this to 027 or 077. SLEEPTIME The time to wait, in seconds, before a login failure is returned and another login may be attempted. The default is four seconds; the maximum is five. Setting this value to zero can simplify brute-forcing of accounts or denial of service by exhausting processes or ptys. TIMEOUT Sets the length of time, in seconds, before an incomplete login attempt is rejected. ALLOW_AGED_PASSWORD If set, and a password has expired, the user will still be permitted to log in. If set to NO, an expired password that has not been changed will reject a login attempt. PASSREQ If set, a login account will require a password. This feature forces certain accounts to be accessed only by su, which provides a useful audit trail. www.syngress.com Continued 158_HPsun_04 10/4/01 5:10 PM Page 105 106 Chapter 4 • Securing Your Users PATH Sets the initial path for a login process. This can provide security or convenience. The default value errs on the side of security by providing a limited search path to regular commands. The second file, /etc/default/su, controls the behavior of the su command in a manner similar to that of /etc/default/login.Table 4.3 shows the options available for this file. Table 4.3 Policy Variables for the su Command Variable Purpose SULOG If present, this variable specifies the file to which all su attempts are logged. It is valuable to periodically gen- erate reports from this file. CONSOLE If YES, all attempts to su root are logged to the system console. SYSLOG and PATH Same as shown in Table 4.2, for /etc/default/login. The last file, /etc/default/passwd, controls password policy. Its options are simple: the minimum and maximum length of time, in weeks, that a password is valid, and the minimum number of characters acceptable for a new password. Sites that make large use of password expiration policy may want to adjust the WARNWEEKS value, which isn’t shown in the file, to give users ample oppor- tunity to change their passwords. During a login, Solaris checks /etc/pam.conf for a service name (see the PAM section). If one is found, the PAM modules specified for that service are loaded. In the case of pam_unix, which handles traditional UNIX authentication, the PAM solicits a username and password through the appropriate interface (tty or dtlogin, for example). Solaris must then recover the user’s credentials in order to validate that the user exists and has presented the correct password.This begins a search process through files, NIS, or NIS+, which is controlled by /etc/nsswitch.conf.A typical entry for password hash searches (as returned to the getpwnam [3C] and getspnam [3C] calls) in /etc/nsswitch.conf is: passwd: files nis www.syngress.com Table 4.2 Continued Variable Purpose 158_HPsun_04 10/4/01 5:10 PM Page 106 Securing Your Users • Chapter 4 107 This search order implies that /etc/passwd and /etc/shadow are searched first for the user’s credentials. If no entries are found, NIS is searched next. If no entries are found there, the system call fails and the user is rejected as unknown. Otherwise, the password presented at login time is hashed and that hash is com- pared with that returned by the search. If they match, the user is authenticated and login proceeds. There are other valid entries in nsswitch.conf. Entering nisplus causes a search of the NIS+ password database.The keyword compat may be used, with no other options, to cause the system to operate in a mode compatible with BSD password file syntax for netgroup inheritance (see sidebar). Other PAM modules may operate differently, but the majority of user authentication schemes in use involve gathering a username and password from the user, providing that to an authentication service for validation, and then accepting or denying the login as appropriate.There are other feasible methods, but the overwhelming majority of e-mail clients, secure shell clients, FTP clients and the like are designed with username/password pairs in mind. Kerberos is dif- ferent in that it uses cryptographic credentials for authentication; that will be dis- cussed later in the chapter. As is the case with any form of authentication that uses reusable credentials, services that are subject to network eavesdropping pose a serious security risk. Secure alternatives exist for shell access, X-windows connection forwarding, POP and IMAP access, and file transfers.These alternatives, usually a Secure Shell client or an SSL-capable mail client, protect passwords from network spies by cryptographically covering the entire channel.Any clear text service that operates with reusable passwords is at risk for snooping. (One-time password systems like OPIE, S/key, or secured are the exception.) Authenticating Users with NIS and NIS+ NIS is probably the most common network information resource used today. Originally known as the Yellow Pages (YP), NIS has roots that lead back to the earliest days of Sun Microsystems.As one would expect from a piece of tech- nology so old, it is well-understood and reliable, but also full of security holes. NIS+, a direct descendent of NIS, seeks to address some of the performance and security issues inherent in the original system. This section will discuss some of the security issues inherent to distributed authentication systems in general. Individual differences between NIS and NIS+ are less important than a best practices overview of the risks they represent.The www.syngress.com 158_HPsun_04 10/4/01 5:10 PM Page 107 108 Chapter 4 • Securing Your Users same risks are present in LDAP, though this increasingly common technology reduces them further. Good practices include the following: ■ Keep root accounts local.While a common UID 0 account in NIS makes systems administration easier, it is more exposed to attack. ■ NIS and NIS+ masters should be limited-access machines. Not only does this free the machine from running user processes, it prevents direct exposure of the maps. ■ NIS masters should use the /var/yp/securenets file to ensure that only known clients can successfully ypbind. NIS slave servers should use securenets files and local ypservers with an entry of localhost, and be bound to themselves. ■ Disable /var/yp/Makefile on NIS slaves.Though this is not a security issue, an accidental push from a slave server could cause difficulty in diagnosing problems. ■ Use shadow passwords where possible, as they reduce the exposure of password hashes.Tools like John the Ripper and Crack are able, with modern CPUs, to brute-force hundreds of passwords within days. ■ NIS and NIS+, even when using SecureRPC and data encryption stan- dard (DES) keys for authentication, should be confined to networks over which administrators have strict control. In particular, Universities should never make NIS available to student networks. ■ NIS and NIS+ depend heavily on RPC. Consider Weitse Venema’s portmapper replacement, which brings tcpwrapper-like functionality to RPC.Another option is ipfilter, which, by functioning as a kernel-level packet filter, can significantly restrict access to RPC services. ■ Use SecureRPC, which relies on DES keys to encrypt and authenticate transactions. ■ NIS+ servers should run at Security Level 2, except under rare circum- stances.At Security Level 2, full authentication and access-checking is enabled, using DES auth and encryption. Security principles for both NIS and NIS+ boil down to this: trust single machines rather than entire networks, keep regular users away from the information stores, authenticate access to information stores with SecureRPC, and use firewalls, ipfilter, or portmapper replacements to control who accesses your services. www.syngress.com 158_HPsun_04 10/4/01 5:10 PM Page 108 Securing Your Users • Chapter 4 109 Authenticating Users with Kerberos Kerberos, named for the 3-headed canine guardian of Hades in classical mythology, is intended to provide a high degree of security by authenticating users, services, and hosts. Kerberos is an authentication system, originally designed www.syngress.com A Server All Your Own It is sometimes useful, for reasons of security or reliability, to have a server that does not allow access to regular users. Solaris carries forward a handy trick from the BSD days of SunOS 4 in the form of compatibility mode. To use compatibility mode to create a limited-access machine, create a new netgroup named sysadmin users by adding the following lines to the end of /etc/netgroup: sysadminusers \ (,scarter,) Then, use view to edit /etc/password on the limited access machine and add the following lines to the end of that file: +@sysadminusers:x::::: +:x:::::/bin/false The pwconv utility isn’t very good at translating the above into /etc/shadow correctly, so edit that file manually to append the following: +@sysadminusers::10530:::::: +::10530:::::: This syntax tells Solaris to inherit all the users belonging to the sysadmin users netgroup, while replacing the shells of everyone else with the invalid entry, /bin/false. All that’s left is to enable compatibility mode by changing the passwd line of /etc/nsswitch.conf to read: passwd: compat Now systems administrators can log in normally, but everyone else, even people with otherwise-valid accounts, will be rejected by the unusable shell. Tools & Traps… 158_HPsun_04 10/4/01 5:10 PM Page 109 110 Chapter 4 • Securing Your Users at MIT. It was intended to prevent network eavesdropping while authenticating users to machines and vice versa. It is not an encryption system, though its nature facilitates the use of encryption because a secret key is known by both the server and the user. Kerberos is a third-party authentication system.This means, essentially, that a trusted third party in the form of the KDC both trusts and is trusted by you.The computer or service to which you are authenticating also trusts the KDC. Because the KDC is able to identify you securely, and the remote computer believes the judgment of the KDC, that machine trusts you as well.A similar pro- cess works in reverse to ensure that you are connecting securely to the machine and the service (rlogin, rsh, FTP, etc.) you expect. In this section, we will briefly cover how Kerberos works, then discuss the Sun Enterprise Authentication Mechanism (SEAM) product, its installation and www.syngress.com The Importance of Time Kerberos uses the workstation time to help identify the current user. Kerberos tickets have fixed lifetimes, and are not valid before their issue timestamp or after their expiration. These mechanisms prevent replay attacks, where a hacker reuses an eavesdropped ticket to masquerade as a valid user. Though Kerberos includes several mechanisms to prevent replay attacks, it is critical that all workstations and servers on your net- work have the correct time and that time be synchronized closely with the Kerberos Key Distribution Center (KDC). Fortunately, Solaris provides xntpd for this purpose. The network time daemon communicates with higher-level timeservers to determine the correct time, adjusts for clock skew, and keeps workstations on the same time as peer hosts. Large Kerberos sites usually use a GPS clock for a timeserver. For most locations, a few servers configured to poll a reliable Internet timeserver like the Washington Naval Observatory or NIST are sufficient. Other servers and workstations can, in turn, poll these servers for the correct time. A list of NIST time servers can be found at www.boulder .nist.gov/timefreq/service/time-servers.html. Tools & Traps… 158_HPsun_04 10/4/01 5:10 PM Page 110 Securing Your Users • Chapter 4 111 configuration, and how it can be used to secure your network.We’ll also discuss some of the pitfalls and security risks associated with Kerberos. To understand Kerberos and its strengths as an authentication system, we need to look at a conventional service, such as rlogin.When a client initiates an rlogin connection, rlogin sends the name of the local user to the server for identifica- tion. If the server trusts the client or the user (through hosts.equiv or an .rhosts file), the connection is allowed and the user logs in. In the event that no host- based trust is present, the user is forced to present a password as identification. One problem with this is that the password travels in the clear on the network, where any eavesdropper can easily obtain it. Furthermore, this system assumes that there are circumstances in which a remote host can be implicitly trusted simply by virtue of its IP address. The Secure Shell (SSH) mitigates some of these problems through the use of encryption.The server end of the connection is identified by public key cryptog- raphy. If the server’s public key matches the one previously cached by the client, the user can be certain that he has reached the correct host.All authentication credentials (and indeed the entire connection) travel over an encrypted channel. This would seem to be ideal but, in fact, suffers from two significant weaknesses. First, SSH includes no mechanism for securely identifying a remote host to a client for that initial connection.The user must assume that he has reached the intended destination, and keep a copy of the public key first presented. If an attacker can redirect that initial session, he can control all future sessions without giving the client any noticeable signs of trouble. Second, SSH, like its insecure counterparts, is a based on a disclosing authentication system.That is, a password is disclosed during the authentication process, and thus may be captured and reused by a compromised server. Kerberos seeks to address both of these issues; it is a nondisclosing authenti- cation system that provides a mechanism to securely identify each end of the connection. When a user is first added to the KDC, their initial password is used to gen- erate a unique hash, which is stored by that server.The account creation process, through kadmin, is secure, and the passwords are not recoverable.When a user first logs in, the login process contacts the KDC and requests a Ticket Granting Ticket (TGT).This ticket contains information like the username, the validity period of the ticket, some cryptographic identifiers of the KDC that issued it, etc. The entire ticket is then encrypted, using the stored hash as the secret key.A login is successful when the login process, using the password you provided, is able to decrypt and store that ticket locally in what Kerberos calls a credentials www.syngress.com 158_HPsun_04 10/4/01 5:10 PM Page 111 112 Chapter 4 • Securing Your Users cache. As you are the only person in possession of the correct password with which to decrypt that ticket, you have been correctly identified.A file previously placed on your workstation called a keytab identifies your machine and is used during the login process to ensure that the TGT it just received came from the real KDC. In this way, the Kerberos server has granted you its trust and ensured that the machine you just logged in to is the one it identified once before. Most importantly, your password is never disclosed to the KDC and it never travels across the network, even in encrypted form.This is one of the fundamental tenets of Kerberos and, as we’ll see later, a weakness to its widespread adoption. Now that you have a TGT, let’s attempt to sort out the series of events set in motion by the login process for a typical service, like a Kerberized rlogin.The Kerberos server generates a random session key along with an identifier for the remote service and encrypts this with your session key, which is now stored in your TGT. It also stores that session key, along with your username, in a ticket which is encrypted with the service key owned by the remote server.When your copy of rlogin receives both tickets, it decrypts yours, using the key stored in the TGT, to recover the session key. Rlogin can’t decrypt the other ticket; only the remote server can do that. So rlogin takes the current time, encrypts that with the session key as proof that you posses a valid TGT, and sends this new ticket, along with the other undecipherable one, to the server. When the remote server receives these two tickets, it decrypts the first one with its own key, recovering the random session key. It can then use this key to recover the time you sent. If its time matches your time, within a little slop to allow for slightly different clocks, the server has proof that you are who you say you are. As only the server you tried to contact could possibly recover the session key, you can be certain that you have connected to the correct host.As an added benefit, each side of the connection now has a unique, random key which can be guaranteed secure from eavesdropping or tampering and may now be used to encrypt the rlogin connection.You never had to type your password and, as long as your TGT is valid, you never will. At no time in this exchange was your pass- word revealed to the remote service or to the KDC. It’s a complex chain of events, but when correctly implemented it provides an immensely powerful authentication system. Sun’s SEAM package brings Kerberos to Solaris. SEAM provides the pam_krb5 module that performs authentications, plus Kerberized versions of the FTP, rlogin, rsh, rcp, and Telnet services. During the SEAM installation process, a new Kerberos realm is created. Realms are roughly the Kerberos equivalents of NIS or NIS+ domains.They represent a collection of user and administrator authentication data, www.syngress.com 158_HPsun_04 10/4/01 5:10 PM Page 112 Securing Your Users • Chapter 4 113 service credentials, and host-identifying keytabs.At installation time, SEAM will create a properly formatted krb5.conf, similar to the following: [libdefaults] default_realm = INCOMING-TRAVELLER.COM [realms] INCOMING-TRAVELLER.COM { kdc = kdc.incoming-traveller.com admin_server = kdc.incoming-traveller.com } [domain_realm] .incoming-traveller.com = INCOMING-TRAVELLER.COM [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log The incoming-traveller.com realm holds all of the Kerberos authentication data.The domain_realm section is used by Kerberos to map hostnames to a Kerberos realm.The realm section gives the hostname of the Key Distribution Center that will handle authentication credentials. KDCs come in two forms: master and slave.The master KDC contains user principals, which are the Kerberos equivalents of an account, service principals, administrator principals, and host keytabs.The slave KDC receives periodic updates of this data over a secure, authenticated process. Slave Key Distribution Centers are used to ensure redundancy and authentication performance. To gain access to the Kerberized versions of common utilities, along with some Kerberos-specific commands, users should prepend /usr/krb5/bin to their PATH environments. SEAM provides a Kerberos PAM to handle ticket management at login. When a user logs in, through the dtlogin for example, the PAM gathers a user- name and password from the user and requests a Ticket Granting Ticket from the KDC.The krb5.conf is used by the PAM to locate the correct KDC for the cur- rent realm. If the authentication is successful, the PAM stores the ticket in a cre- dentials cache in /tmp, in a form readable only by the user.The klist command shows what credentials are present and each one’s lifetime: www.syngress.com 158_HPsun_04 10/4/01 5:10 PM Page 113 114 Chapter 4 • Securing Your Users % /usr/krb5/bin/klist -f Ticket cache: /tmp/krb5cc_3551 Default principal: scarter@INCOMING-TRAVELLER.COM When using Kerberos, the default logout process should contain the kdestroy command. Kdestroy simply deletes the credentials cache from /tmp. File permis- sions are all that prevent someone from masquerading as another user for the life- time of the TGT. It is imperative that these caches be removed by kdestroy at logout. SEAM provides a series of Kerberized commands that take advantage of this unique authentication mechanism. Sites whose users make regular use of Kerberized and conventional hosts may have interoperability problems, as the Kerberized commands may not always communicate correctly with non- Kerberos-aware services on other hosts. The rlogin, rsh, rcp, and Telnet commands operate in the same ways as their non-Kerberized equivalents, but provide two new benefits: once you have obtained a TGT, these commands will not prompt for a password for the validity period of that ticket.This provides true single-sign-on. Users log in once and, for the next few hours, never have to retype their password.Additionally, by using the -x option, these commands can, in strong contrast to their conventional counter- parts, encrypt the entire session. Kerberos: Is it Really a Dog? Kerberos was originally developed at MIT, long before the Internet became popular or very many people owned computers. MIT had the advantage of excellent in-house development and, most importantly, an environment where Kerberos evolved right alongside increasing demand for computers. Under those circumstances, widespread use of Kerberos went hand-in-hand with widespread use of computing resources. Detractors point out that its fundamental tenet, the policy that gives Kerberos its unsurpassed resistance to snooping, is also its greatest weakness. That the password is never on the network is a difficult reality to achieve in this day of Web browsers, mixed platform environments, and a plethora of e-mail clients. Even in the UNIX world, where local cre- dentials caches and Kerberized software is easy to develop and deploy, Notes from the Underground… Continued 158_HPsun_04 10/4/01 5:10 PM Page 114 [...]... requisite /usr/lib/security/su_group0.so.1 www.syngress.com 119 158_HPsun_ 04 120 10 /4/ 01 5:10 PM Page 120 Chapter 4 • Securing Your Users Figure 4. 2 Adding a User to Group Root Figure 4. 3 Configuring the su_group0 PAM Your pam.conf should now look like Figure 4. 3 www.syngress.com 158_HPsun_ 04 10 /4/ 01 5:10 PM Page 121 Securing Your Users • Chapter 4 This is an excellent example of a case where misuse or accidental... www.syngress.com 139 158_HPsun_05 140 10 /4/ 01 5:32 PM Page 140 Chapter 5 • Securing Your Files be critical or confidential—to leave a system.You can disable the automountd daemon by stopping the service (/etc/rc2.d/S74autofs stop) and then rename the link from S74autofs to s74autofs, or you can go all the way and remove the packages that support automounting.These are SUNWvolr, SUNWvolu, and SUNWvolg If you don’t... are shown in Table 4. 4 Table 4. 4 Module Type Values Module Type Description Auth Password Account This module is used to perform authentication The module changes or resets authentication credentials Account modules perform account management, including expiration and locking Session management modules Session www.syngress.com 117 158_HPsun_ 04 118 10 /4/ 01 5:10 PM Page 118 Chapter 4 • Securing Your Users... 158_HPsun_ 04 10 /4/ 01 5:10 PM Page 119 Securing Your Users • Chapter 4 requisite could, for example, allow any user in group root to su without presenting a password.Therefore, systems administrators should be especially wary of this flag In our first example, we’ll restrict su attempts to those administrators who are part of group root.This feature originally appeared in BSD-style UNIX systems like SunOS 4. .. password, soliciting a new one, and updating the system accordingly Let’s look more closely at the following line from Figure 4. 1: login auth www.syngress.com required /usr/lib/security/pam_unix.so.1 158_HPsun_ 04 10 /4/ 01 5:10 PM Page 117 Securing Your Users • Chapter 4 Figure 4. 1 The pam.conf File The service column generally consists of the name of the service being provided Obvious cases include FTP,Telnet,... validity periods As long as a TGT is valid, the user will not have to enter a password to connect to Kerberized services.This feature is called singlesign-on www.syngress.com 123 158_HPsun_ 04 1 24 10 /4/ 01 5:10 PM Page 1 24 Chapter 4 • Securing Your Users By allowing for the secure exchange of a secret key between the KDC, a service, and the user, Kerberos makes encrypted versions of common applications like... password entries) to an www.syngress.com 125 158_HPsun_ 04 126 10 /4/ 01 5:10 PM Page 126 Chapter 4 • Securing Your Users hour for group or host entries.To reduce this latency, change the positivetime-to-live value, which is in seconds, in /etc/nscd.conf.Then, restart nscd: # /etc/init.d/nscd stop # /etc/init.d/nscd start www.syngress.com 158_HPsun_05 10 /4/ 01 5:32 PM Page 127 Chapter 5 Securing Your Files... the Pluggable Authentication Modules With the introduction of Solaris 2.6, Sun embraced one of the most powerful authentication concepts to come along in recent years Pluggable Authentication Modules (PAM), originally a Linux concept, abstract the authentication process www.syngress.com 115 158_HPsun_ 04 116 10 /4/ 01 5:10 PM Page 116 Chapter 4 • Securing Your Users away from programs like su, login, ftpd,... is unable to present a valid SecurID PIN and tokencode will be rejected by the IMAP server www.syngress.com 121 158_HPsun_ 04 122 10 /4/ 01 5:10 PM Page 122 Chapter 4 • Securing Your Users Summary Reliable user authentication methods and policies are at the heart of any secure system Solaris provides many tools for improving authentication security and flexibility It allows for a wide range of configurations... and effective id will be changed For a complete discussion on RBAC, please see Sun s security white paper, RBAC in the Solaris Operating Environment, available at www .sun. com/ software/whitepapers/ Changing Default Settings We’ve all faced the daunting task of cleaning up after a base Solaris install.We’ve all wondered why Sun chose to leave so many things so wide open But as the old saying goes, “Ours . /usr/lib/security/su_group0.so.1 www.syngress.com 158_HPsun_ 04 10 /4/ 01 5:10 PM Page 119 120 Chapter 4 • Securing Your Users Your pam.conf should now look like Figure 4. 3. www.syngress.com Figure 4. 2 Adding a User to Group Root Figure 4. 3 Configuring. what credentials are present and each one’s lifetime: www.syngress.com 158_HPsun_ 04 10 /4/ 01 5:10 PM Page 113 1 14 Chapter 4 • Securing Your Users % /usr/krb5/bin/klist -f Ticket cache: /tmp/krb5cc_3551 Default. develop and deploy, Notes from the Underground… Continued 158_HPsun_ 04 10 /4/ 01 5:10 PM Page 1 14 Securing Your Users • Chapter 4 115 SEAM also provides the kpasswd command to facilitate password