Security of Interactive and Automated Access Management Using Secure Shell (SSH)

Transcription

1 Security f Interactive and Autmated Access Management Using Secure Shell (SSH) Tatu Ylnen Paul Turner Karen Scarfne Murugiah Suppaya This publicatin is available free f charge frm:

2 Security f Interactive and Autmated Access Management Using Secure Shell (SSH) Tatu Ylnen SSH Cmmunicatins Security Helsinki, Finland Paul Turner Venafi Salt Lake City, UT Karen Scarfne Scarfne Cybersecurity Cliftn, VA Murugiah Suppaya Cmputer Security Divisin Infrmatin Technlgy Labratry This publicatin is available free f charge frm: Octber 2015 U.S. Department f Cmmerce Penny Pritzker, Secretary Natinal Institute f Standards and Technlgy Willie May, Under Secretary f Cmmerce fr Standards and Technlgy and Directr

3 Natinal Institute f Standards and Technlgy Internal Reprt pages (Octber 2015) This publicatin is available free f charge frm: Certain cmmercial entities, equipment, r materials may be identified in this dcument in rder t describe an experimental prcedure r cncept adequately. Such identificatin is nt intended t imply recmmendatin r endrsement by NIST, nr is it intended t imply that the entities, materials, r equipment are necessarily the best available fr the purpse. There may be references in this publicatin t ther publicatins currently under develpment by NIST in accrdance with its assigned statutry respnsibilities. The infrmatin in this publicatin, including cncepts and methdlgies, may be used by Federal agencies even befre the cmpletin f such cmpanin publicatins. Thus, until each publicatin is cmpleted, current requirements, guidelines, and prcedures, where they exist, remain perative. Fr planning and transitin purpses, Federal agencies may wish t clsely fllw the develpment f these new publicatins by NIST. Organizatins are encuraged t review all draft publicatins during public cmment perids and prvide feedback t NIST. All NIST Cmputer Security Divisin publicatins, ther than the nes nted abve, are available at Cmments n this publicatin may be submitted t: Natinal Institute f Standards and Technlgy Attn: Cmputer Security Divisin, Infrmatin Technlgy Labratry 100 Bureau Drive (Mail Stp 8930) Gaithersburg, MD ii

4 Reprts n Cmputer Systems Technlgy The Infrmatin Technlgy Labratry (ITL) at the Natinal Institute f Standards and Technlgy (NIST) prmtes the U.S. ecnmy and public welfare by prviding technical leadership fr the Natin s measurement and standards infrastructure. ITL develps tests, test methds, reference data, prf f cncept implementatins, and technical analyses t advance the develpment and prductive use f infrmatin technlgy. ITL s respnsibilities include the develpment f management, administrative, technical, and physical standards and guidelines fr the cst-effective security and privacy f ther than natinal security-related infrmatin in Federal infrmatin systems. Abstract Users and hsts must be able t access ther hsts in an interactive r autmated fashin, ften with very high privileges. This is necessary fr a variety f reasns, including file transfers, disaster recvery, privileged access management, sftware and patch management, and dynamic clud prvisining. Accessing ther hsts is ften accmplished using the Secure Shell (SSH) prtcl. The SSH prtcl supprts several mechanisms fr interactive and autmated authenticatin. Management f this access requires prper prvisining, terminatin, and mnitring prcesses. Hwever, the security f SSH keybased access has been largely ignred t date. This publicatin assists rganizatins in understanding the basics f SSH interactive and autmated access management in an enterprise, fcusing n the management f SSH user keys. Keywrds access cntrl; authenticatin; autmated access management; device authenticatin; interactive access management; Secure Shell (SSH); user authenticatin Acknwledgments The authrs wish t thank their clleagues wh reviewed drafts f this dcument and cntributed t its technical cntent. Trademark Infrmatin All registered trademarks r trademarks belng t their respective rganizatins. iii

5 Table f Cntents 1. Intrductin Purpse and Scpe Audience Dcument Structure The Basics f Access Management and Autmated Access Management The Basics f SSH Prtcl Basics Cmmn SSH Use Cases Server Authenticatin Client Authenticatin Passwrd Authenticatin Hst-Based Authenticatin Kerbers Authenticatin Public Key Authenticatin User Authenticatin Summary Vulnerabilities in SSH-Based Access Vulnerable SSH Implementatin Imprperly Cnfigured Access Cntrls Stlen, Leaked, Derived, and Unterminated Keys Backdr Keys Unintended Usage Pivting Lack f Knwledge and Human Errrs Recmmended Practices fr Management SSH Security Plicies and Prcedures Secure SSH Implementatin SSH Identity and Authrized Keys SSH Key-Based Access Prvisining, Life Cycle, and Terminatin Prcesses Establish Cntinuus Mnitring and Audit Prcesses Inventry and Remediate Existing SSH Servers, Keys, and Trust Relatinships Autmate Prcesses Educate Executive Management SSH-Based Access Management Planning and Implementatin Identify Needs Design the Slutin Implement and Test Prttype Deply the Slutin Manage the Slutin Slutin Planning and Deplyment...28 Appendix A NIST SP Cntrls Mapping...29 Appendix B Cybersecurity Framewrk Subcategry Mapping...34 Appendix C SSH Key Management Tl Selectin...36 iv

6 Appendix D Acrnyms and Abbreviatins...40 Appendix E Glssary...41 Appendix F References...44 v

7 1. Intrductin 1.1 Purpse and Scpe The purpse f this dcument is t assist rganizatins in understanding the basics f Secure Shell (SSH) and SSH access management in an enterprise, fcusing n the management f SSH user keys. 1.2 Audience This dcument is fr security managers, engineers, administratrs, and thers wh are respnsible fr planning, acquiring, testing, implementing, and maintaining SSH slutins. Prtins f the dcument may be f interest t executives and SSH users. 1.3 Dcument Structure The remainder f this dcument is rganized int the fllwing sectins and appendices: Sectin 2 discusses the basics f access management and autmated access management. Sectin 3 examines the basics f SSH. Sectin 4 describes the primary categries f vulnerabilities in SSH user key management. Sectin 5 lists recmmended practices fr SSH-based access management. Sectin 6 explains planning and implementatin prcesses fr SSH-based access management. Sectin 7 discusses slutin planning and deplyment. Appendix A prvides a mapping t NIST Special Publicatin (SP) Revisin 4 security cntrls. 1 Appendix B prvides a mapping t Cybersecurity Framewrk Versin 1.0 subcategries. Appendix C lists criteria fr selecting and prcuring tls fr managing SSH keys. Appendix D defines selected acrnyms and abbreviatins used in the dcument. Appendix E defines selected terms used in the dcument. Appendix F lists references. 1 NIST SP Revisin 4, Security and Privacy Cntrls fr Federal Infrmatin Systems and Organizatins, April 2013 (updated ), 1

8 2. The Basics f Access Management and Autmated Access Management Cntrlling access t infrmatin systems is critical fr infrmatin security. Access cntrls exist n many levels and use many technlgies. The levels include physical restrictins n access t hardware; lgical cntrls fr accessing netwrk interfaces, hardware management prts n servers, virtualizatin hypervisrs, perating system (OS) user accunts, and infrmatin thrugh database systems; and lgical cntrls implemented by applicatins. Infrmatin security (cnfidentiality, integrity, and availability) is cmprmised if cntrls at any f these levels fail. Breaches at different levels have different implicatins. Generally, a breach at the hardware, hypervisr, r OS level is mre serius than a breach at the applicatin level. Fr example, breaking int a database accunt n a server may permit reading, mdifying, and destrying any data in a database, bypassing nrmal database-level cntrls. Breaking int a rt (administratr) accunt generally permits ding this t all data n all accunts n the system, plus installing deeply hidden backdrs, mdifying the perating system, crrupting data, r rendering the system unbtable. Mst perating systems use user accunts as the primary unit f access cntrl. In this dcument, a user accunt means an OS level user accunt unless therwise specified. User accunts crrespnd t peple (including system administratrs) and service accunts are used fr running applicatin sftware r are used internally by the OS. It is wrth nting that many applicatins implement their wn user accunts that d nt crrespnd t OS level user accunts (they essentially share the service accunt f the applicatin); hwever, such applicatin-level accunts are generally beynd the scpe f this dcument. User accunts may be stred in a centralized repsitry (e.g., Active Directry [AD] r Lightweight Directry Access Prtcl [LDAP]) r may be cnfigured lcally n a system. A user accunt defined lcally is generally distinct n each system (separate passwrd, separate hme directry, etc.), even if the same accunt name is used n multiple cmputers, while user accunts defined in a centralized repsitry are ften available n mre than ne cmputer and share the same hme directry (n a netwrked file system). Service accunts are very cmmnly lcal accunts, and accunts fr peple are ften stred in a directry. In a very real sense, access cntrl is the essence f infrmatin security. Other security technlgies primarily exist t implement and enfrce access cntrls, make it harder t analyze and attack access cntrl systems, limit the impact f actual breaches, evaluate the current state f prtectins, detect suspicius activity, cunteract undesired activity, r help analyze what happened after the fact. The critical balance in infrmatin security is between the need t grant access and the need t limit access. Cnsequently, access must be prvisined (based n prper justificatin fr that level f access) and it must be eventually terminated (e.g., when an emplyee leaves the rle that justified the access, when a client system r applicatin requiring autmated access is decmmissined). Access t hsts has becme increasingly autmated. Examples f this autmatin include file transfers, disaster recvery, privileged access management, sftware and patch management, and dynamic clud prvisining. This autmatin invlves transferring data and executing cmmands, such as having hsts recnfigure ther hsts. Thus, hsts must access ther hsts, ften with very high privileges. Unfrtunately, there has been little planning and versight f autmated and interactive machine-tmachine access cntrl. Instead, such access has been added and cnfigured n an ad hc basis by system administratrs, vendrs, and integratrs as part f ther prjects, withut frmal access cntrl lifecycle management (e.g., standardized prvisining and terminatin prcesses, access tken management (e.g., peridic passwrd changes)). This publicatin explres the field f SSH-based access management, with a strng fcus n security issues and hw t best address them. 2

9 3. The Basics f SSH Secure Shell (SSH) is a prtcl fr securely lgging int a remte hst and executing cmmands n that hst (e.g., administrative cmmands). What distinguishes the SSH prtcl frm earlier remte administratin prtcls, such as telnet, remte shell (rsh), remte lgin (rlgin), and remte cpy (rcp), is its built-in supprt fr rbust security features such as secure user and device authenticatin and transmissin encryptin. SSH has almst cmpletely taken the place f these insecure remte administratin prtcls. Tday, SSH sftware is natively included and used as the primary remte administratin mechanism fr many perating systems and devices, including Linux, Unix, ruters, firewalls, netwrk appliances, security appliances, and ther systems. It is als embedded behind the scenes int a wide variety f Infrmatin Technlgy (IT), netwrking, and security technlgies, including file transfer, systems management, identity management, and privileged access management. In additin t manually remtely cnnecting t and managing hsts and devices, SSH is used fr integrating hsts and autmating their peratin. This sectin examines the basics f Secure Shell (SSH) versin 2.0. First, Sectin 3.1 explres SSH prtcl basics. Next, Sectin 3.2 discusses the mst cmmn use cases fr SSH, including the use case scenari f interest in this publicatin: user and autmated access. Sectin 3.3 examines SSH server authenticatin, while Sectin 3.4 details SSH client authenticatin. 3.1 Prtcl Basics The SSH prtcl has a typical client/server architecture. An SSH client applicatin n hst A initiates a cnnectin t an SSH server applicatin n hst B. These tw hsts negtiate encryptin algrithms fr their transmissins, then establish a sessin key and perfrm device authenticatin fr the server hst (hst B) 2, and finally send client (r user) authenticatin credentials (e.g., username and passwrd) t the server. Assuming that this authenticatin succeeds, an SSH cnnectin is said t be established between the hsts, ready fr use. The current versin f the SSH prtcl is 2.0. Earlier versins f the prtcl have serius knwn vulnerabilities that preclude their use. Fr mre infrmatin n the frmal definitin f the SSH prtcl versin 2.0, see [RFC4251], [RFC4252], [RFC4253], and [RFC4254]. All references t the SSH prtcl in this publicatin are t versin 2.0 unless explicitly stated therwise. 3.2 Cmmn SSH Use Cases There are three cmmn use cases fr SSH: Interactive use. SSH is used fr managing and cnfiguring Unix and Linux cmputers, netwrking equipment, and varius ther types f hsts remtely. SSH is als used fr running applicatins remtely (particularly text-based legacy applicatins). File transfers. SSH is used as the fundatin f the Secure Cpy (scp) and Secure File Transfer Prtcl (SFTP) prtcls. These prtcls are used t transfer files between hsts while leveraging the security capabilities built int SSH. 2 The primary purpse f authenticating the server is t prevent man-in-the-middle attacks. 3

10 Pint-t-pint tunneling. SSH can be used t implement a virtual private netwrk (VPN) tunnel t prtect data transmitted between tw hsts. One r bth f these hsts may be acting as a gateway fr ther hsts behind it. This publicatin cvers all f these use cases in the cntext f user and autmated access. Autmated access refers t accessing a hst frm anther hst in an autmated fashin (withut human interventin). SSH is frequently used fr autmated access fr a variety f purpses, including managing large IT envirnments, integrating applicatins, and prvisining virtual machines in clud services. Autmated access is cmmnly used with functinal accunts, system accunts, service accunts, and ther nn-interactive user accunts (smetimes als called nn-user accunts). Such accunts are used by perating systems, server applicatins (e.g., databases), and ther applicatins fr running prcesses. Autmated access is als frequently used fr file transfer functins. Autmated access may be unrestricted, allwing any cmmands t be executed, r may be limited t specific cmmands r peratins, such as file transfers (perhaps limited t a specific directry). Organizatins shuld limit autmated access s that nly the necessary cmmands can be executed and nly the necessary resurces can be engaged. 3.3 Server Authenticatin The cnfidentiality and integrity f SSH rely n strng authenticatin f bth the SSH server and client. Authenticatin f the SSH server by the client is perfrmed with public key cryptgraphy via public keys explicitly trusted by the client r certificates issued by a certificatin authrity public keys are mre cmmnly used than certificates. 3 Hst Keys Private & public keys fr HstB Knwn Hsts File Public key fr HstB HstB Public Key Private Key HstA User1 1 4 Figure 3-1: Prcess fr Initially Trusting an SSH Server s Public Key 3 X.509v3 cmpliant hst certificates are a useful alternative fr hst keys in large envirnments and make hst key rtatin much easier. 4

11 Figure 3-1 illustrates the prcess fr initially trusting an SSH server s public key: 1. User1 initiates its first lgin t HstB. 2. HstA cnnects t HstB. 3. HstB sends its public key t HstA The public key sent by HstB is displayed fr User1. User1 verifies that it is the crrect public key fr HstB by cmparing it against the value received via a different cmmunicatin channel. 5. HstA stres HstB s public key in User1 s knwn hsts file alng with the name f HstB in rder t authenticate HstB during future cnnectins withut prmpting the user t verify that the key is the crrect public key fr HstB. 6. HstA authenticates HstB using HstB s public key and establishes an encrypted cnnectin with HstB. Nte: If the User1 accunt is being used by an autmated prcess, the user wh reviews the public key n first cnnectin is typically the administratr fr the autmated prcess. T avid this prcess, the administratr can preppulate the knwn hsts file with HstB s public key. Care must be taken by users and administratrs in ensuring that the crrect public keys fr each server are trusted as knwn hst keys t prevent man-in-the-middle attacks. In additin, a man-in-the-middle attack can als be launched if the attacker is able t get a cpy f the server s private key. Wherever pssible, users shuld have limited ability t change knwn hst key cnfiguratins. In additin, knwn hsts files shuld be hashed t minimize infrmatin available t ptential attackers. 3.4 Client Authenticatin Client authenticatin refers t the authenticatin f interactive users (administratrs and ther users) r autmated prcesses perating n SSH clients. Authenticatin ccurs fr a particular accunt n the server. The SSH prtcl supprts several mechanisms fr authenticating users, including passwrds, hst-based authenticatin, Kerbers, and public key authenticatin. All these authenticatin methds fundamentally rely n sme secret infrmatin, and when used fr autmated access, this secret infrmatin must be stred lcally r be therwise accessible. One r mre client authenticatin methds can be enabled n each SSH server. Each authenticatin methd features prs and cns fr security and flexibility these prs/cns are ften different fr interactive users and autmated prcess. Organizatins must carefully evaluate and select the client authenticatin methd(s) that are apprved fr use in their envirnment, disabling thers. This sectin briefly discusses these frms f client authenticatin, fcusing n their relevancy and apprpriateness fr interactive users and autmated prcesses Passwrd Authenticatin There are tw kinds f passwrd authenticatin mechanisms in SSH: basic passwrd authenticatin and keybard-interactive authenticatin. Basic passwrd authenticatin is a legacy methd defined by the SSH prtcl standards. Keybard-interactive authenticatin is used in mst mdern envirnments, and can supprt challenge-respnse authenticatin and ne-time passwrds in additin t traditinal passwrd authenticatin. LDAP may be used in lieu f lcal credential databases (e.g., passwrd files) t reduce the number f passwrds users must remember and manage. With bth passwrd and keybard-interactive 4 An SSH server may have mre than ne public/private key pair if multiple algrithms (e.g., RSA, DSA, ECDSA) are supprted n the server. 5

12 authenticatin, usernames, passwrds, and challenge respnses are sent frm the client (HstA) t the server (HstB) acrss the encrypted SSH cnnectin. This prtects the credentials in transit acrss the netwrk but they are still subject t cmprmise in a man-in-the-middle attack. Passwrd authenticatin is mre cmmnly used fr interactive users, but less cmmnly fr autmated access, althugh it is smetimes seen with hard-cded passwrds in scripts and management systems. Hst Keys Private & public keys fr HstB Knwn Hsts File Public key fr HstB HstA User Credentials HstB Figure 3-2: Passwrd Authenticatin Prcess Figure 3-2 illustrates the passwrd authenticatin prcess: 1. User1 initiates a lgin t HstB. 2. HstA authenticates HstB using the HstB public key stred in User1 s knwn hsts file and establishes an encrypted cnnectin with HstB User1 is prmpted fr a username and passwrd and ptentially ther credentials (fr keybardinteractive authenticatin) required by HstB. 4. The credentials are sent t HstB ver the encrypted cnnectin. HstB authenticates User1 by verifying the credentials prvided by User1. Fr interactive users, passwrd authenticatin prvides users mbility, as they can enter their passwrd anywhere frm which they have SSH access. Hwever, if interactive users are required t remember and manage different passwrds fr multiple systems, it can create administrative and security challenges. Passwrd authenticatin is generally nt recmmended fr autmated prcesses because it desn t prvide the level f access cntrl available with ther authenticatin methds, especially public key authenticatin. If passwrd authenticatin is used fr interactive users r autmated access, the passwrds shuld be rtated frequently in accrdance with the server rganizatin s passwrd plicy (which shuld als cntain requirements such as minimum passwrd length, minimum passwrd cmplexity, etc.) 5 This step is described abve in Server Authenticatin. It is included here t prmte understanding f when server authenticatin ccurs during the passwrd authenticatin prcess. 6

13 3.4.2 Hst-Based Authenticatin Hst-based authenticatin uses a server hst's (HstA) hst key the key typically used by clients t verify the server s identity t authenticate that server (HstA) t anther server (HstB) and t vuch fr the identity f the user (User1) n the client side server (HstA). A cnfiguratin file (.shsts) can be used with any user accunt n the destinatin server (HstB) t specify which users n which hsts can lg int that accunt withut further authenticatin. Knwn Hsts File Public key fr A Hst Hst AKey B HstA shsts Cnfiguratin HstA User1 1 4 Hst Keys Private & public keys fr HstA 3 HstB HstA User1 2 Figure 3-3 illustrates hst-based authenticatin: Figure 3-3: Hst-Based Authenticatin 1. The administratr fr HstB places the public key fr HstA in the knwn hsts file n HstB and cnfigures the shsts (e.g. ~/.shsts r shsts.equiv) t allw User1 t authenticate frm HstA. 2. User1 starts t lgin t HstB. 3. HstA authenticates t HstB using the hst key fr HstA. 4. HstB cnfirms in the shsts cnfiguratin that User1 is authrized t access the target accunt n HstB frm HstA. Hst-based authenticatin des nt permit cnfiguring cmmand restrictins limits n what can be dne n the destinatin server when accessed. Because f this, it is nt recmmended fr autmated access. Hst-based authenticatin is nt recmmended fr interactive users because it des nt present an interactive lgin, which is nt generally cnsidered a gd practice, especially fr accunts with elevated privileges Kerbers Authenticatin Kerbers (usually tgether with an LDAP-based directry, such as Active Directry) implements single sign-n within a Windws dmain r Kerbers realm, and allws user accunts and credentials t be stred in a centralized directry. A user authenticates t the directry and then is able t access any accunt with the same name n SSH-based machines that are jined t the same dmain r realm. On ne hand, this can be beneficial fr single sign-n and a single pint fr managing user accunts, including 7

14 the ability t disable the accunt centrally and remve all access. On the ther hand, such single sign-n implies that nce a user has authenticated t an accunt using Kerbers, it is pssible t lg in t any ther server that has the same accunt name and is in the same dmain (with Kerbers authenticatin enabled) withut further authenticatin. This can easily create lts f unwanted implicit trust relatinships. Anther cncern is that currently widely used SSH implementatins d nt supprt cmmand restrictins fr Kerbers. Hst Keys Private & public keys fr HstB Knwn Hsts File Public key fr HstB 2 HstB Key Distributin Center (KDC) HstA User1 1 Figure 3-4: Kerbers Authenticatin Figure 3-4 illustrates Kerbers authenticatin with SSH: 1. User1 authenticates t the Kerbers Key Distributin Center (KDC) and receives a ticket, which HstA stres fr future authenticatins. 2. User1 ges t cnnect t HstB. HstA prvides the ticket t HstB, which it uses t authenticate User1. Kerbers includes a user s IP address(es) within authenticatin tickets t ensure that these tickets cannt be cpied and reused by an attacker n anther system. This feature f Kerbers prevents SSH man-inthe-middle attacks. Hwever, in envirnments where netwrk address translatin (NAT) firewalls are used, access will be denied when attempting t access a hst n the ther side f a firewall. In rder t enable access acrss NAT firewalls, Kerbers must be cnfigured t allw tickets that d nt include IP addresses, which pens the vulnerability f tickets t being cpied and reused. T facilitate authenticatin fr autmated prcesses, many SSH Kerbers implementatins prvide the ptin fr credentials t be stred in a file n the client called a keytab file. This enables autmated lgn withut user interventin. Access t keytab files shuld be restricted t prevent credentials frm being cmprmised and used fr unauthrized access frm the same system r a different system. Fr interactive users, Kerbers is best suited fr envirnments where users require access t several servers, because it prvides mre secure authenticatin than passwrd authenticatin, single sign-n fr users, and single pint f accunt management (enabling/disabling, etc.). Hwever, cntrls must be put in place t limit implicit access and ensure that users nly have intended access. Autmated prcesses shuld generally have limited, explicit access t a limited number f specific hsts. The exceptin may be management systems that require autmated access t a large number f hsts. In 8

15 practice, Kerbers is rarely used fr autmated prcesses and is nt recmmended due t the risks f implicit access and the lack f cmmand restrictins Public Key Authenticatin Public key authenticatin in SSH uses user keys r certificates t authenticate a cnnectin with user keys being the mst cmmnly used methd. Such keys can be cnfigured fr bth interactive users and autmated prcesses, and they authrize the user r prcess t access a user accunt in an infrmatin system. An interactive user r autmated prcess n an SSH client (HstA) has a user key called an identity key, typically an RSA r DSA private key, and the server (HstB) must have the crrespnding public key cnfigured as an authrized key fr a user accunt t which access will be prvided. Any user r prcess in pssessin f the identity key is then allwed t lg int that user accunt n the server and perfrm actins under the privileges cnfigured fr the accunt. Knwn Hsts File Public key fr HstB Identity Keys Public & private keys fr User Hst Keys Private & public keys fr HstB Authrized Keys Public Key fr User1 2 HstB HstA User1 3 Figure 3-5 illustrates SSH public key authenticatin: Figure 3-5: Public Key Authenticatin 1. User1 r an administratr generates an identity key (and crrespnding public key) fr User1. 2. The HstB administratr stres User1 s public key as an authrized key in the User1 accunt n HstB. 3. User1 starts t lgin t HstB. 4. HstA cnnects t HstB and attempts t authenticate User1 t HstB using User1 s identity key. 5. HstB authenticates User1 using the authrized key stred in User1 s accunt n HstB. Many SSH implementatins supprt cnfiguring restrictins fr authrized keys. These may be used fr limiting what can be dne n the server using the key (cmmand restrictins) and fr limiting the IP addresses frm which the key can be used (surce restrictins). 9

16 Knwn Hsts File Public key fr HstB Identity Keys Public & private keys fr User1 2 Hst Keys Private & public keys fr HstB Authrized Keys Public Key fr User1 Frm= Cmmand = date 1 HstB 3 Mn Dec 22 06:07:11 MST 2014 HstA ( ) User1 Figure 3-6: Public Key Authenticatin with Surce and Cmmand Restrictins Figure 3-6 illustrates public key authenticatin with surce and cmmand restrictins: 1. The administratr fr HstB cnfigures the authrized key fr User1 t nly allw authenticatin t HstB frm address and run the date cmmand nce authenticated. 2. User1 authenticates t HstB frm HstA (IP address ). 3. HstB executes the date cmmand and then terminates User1 s cnnectin. An imprtant advantage f public key authenticatin is that it des nt create implicit trust relatinships, nly expressly defined trust relatinships, and the permitted access can be reliably determined by inspecting the destinatin hst. 6 This is very imprtant fr being able t clearly determine and audit wh can access each system and accunt. Hwever, if the deplyment f authrized keys is nt cntrlled and tracked, users can create unauthrized trust relatinships and access that can be explited. Fr interactive users, the identity key is usually stred n a smartcard r in a passphrase-prtected file n a client device. If the identity key is prtected by a passphrase, it is encrypted by a key derived frm the passphrase. When SSH user keys are used fr autmated access, hwever, the identity key is usually stred as an unencrypted file (with n passphrase) in the file system. 7 Given that the files grant access t servers, they cntain sensitive data. Public key authenticatin is the recmmended authenticatin mechanism fr autmated access with SSH due t the cmmand and surce restrictins that are available and the ability t mre readily prevent implicit trust. Public key authenticatin is by far the mst frequently used methd f SSH autmated access as f this writing. 6 An exceptin is OpenSSH's prprietary certificate authenticatin, which des nt allw reliably auditing wh can access a hst by inspecting just that hst. There is n hardened Certificate Authrity slutin fr OpenSSH, and mst envirnments have n systematic tracking r directry f issued OpenSSH certificates. Thus if the hst trusts an OpenSSH certificate signing key, it is ften nt pssible t reliably determine wh is able t access the hst. 7 There is n ne present t supply the passphrase fr decrypting the identity key fr autmated access by prcesses. Hardcding the passphrase in scripts wuld prvide little additinal security (see als NIST SP IA-5(7)), and btaining it frm a vault in a script wuld als prvide limited additinal security and wuld be quite a maintenance burden. 10

17 3.4.5 User Authenticatin Summary There are many cnsideratins t take int accunt when selecting authenticatin methds fr SSH acrss an enterprise. Table 3-1 summarizes the majr security and peratinal cnsideratins fr the user authenticatin methds described in this sectin in cmmnly used SSH implementatins. Generally, the gal shuld be t select a single methd fr all authenticatins r ne methd fr all interactive users and ne fr all autmated prcesses. Hwever, this is nt always pssible based n the ptins available in deplyed SSH systems and sftware. Fr autmated prcesses, public key authenticatin is the recmmended methd based n its additinal security features. Fr interactive users, public key authenticatin with smartcards prvides the best security. Fr file-based public key authenticatin with interactive users, if passphrase strength fr interactive user identity keys stred in files (instead f smartcards) cannt be enfrced, weak passphrases may put identity keys at risk f cmprmise. In these cases, passwrd r Kerbers authenticatin, where passwrd strength can be enfrced, may prvide higher security. The use f keytab files with Kerbers fr interactive users is nt recmmended. If multiple authenticatin methds will be enabled, it is critical t put cntrls in place t prevent unintended access. Fr example, if Kerbers is selected fr interactive users and public key authenticatin fr autmated prcesses, it is critical t ensure that the names f system accunts fr autmated prcesses are nt the same as accunts in the central directry. And, cnversely, it is als critical that users be prevented frm cnfiguring authrized keys that wuld allw them circumvent cntrls enfrced via Kerbers. Table 3-1: Cmparing Authenticatin Methds Passwrd Hst-Based Kerbers Public Key Supprts Prtability (User nt required t carry credential frm system t system) Yes Yes Yes Yes/N 8 Prvides Single Sign-On N N Yes Yes Enfrces Cmmand Restrictins N N N Yes Prevents Man-in-the-Middle 9 N Yes Yes Yes Minimizes Implicit Access Yes/N 10 Yes N Yes Supprts NAT Envirnments Yes Yes N Yes 11 8 If the identity key fr an interactive user is stred n a smartcard, the user can easily and securely carry it frm system t system. If it is stred in a passphrase-prtected file, the user must cpy the file t each client frm which he r she accesses SSH servers. 9 This assumes that best practices are being fllwed. Fr example, if the server s public key is nt prperly validated, a manin-the-middle attack is pssible with any authenticatin methd. 10 When passwrd r keybard-interactive authenticatin is used with LDAP, implicit access can ccur when an accunt n a hst unexpectedly has the same name as an accunt in the LDAP directry. 11 Surce restrictins must be cnfigured t use the address n the server side f the NAT device. 11

18 4. Vulnerabilities in SSH-Based Access Because SSH is the primary secure access methd used fr administratin and autmated prcesses n missin critical systems, its security is crucial. The systems managed via SSH include Unix and Linux systems, ruters, firewalls, security appliances, Unix partitins n mainframes, and ther netwrk devices. The privileges granted t users and autmated prcesses via SSH are typically elevated ften rt level privileges. 12 A number f vulnerabilities arise bth fr users and autmated prcesses if prper prvisining, terminatin, and mnitring prcesses are nt implemented. The security f SSH-based autmated access, and even interactive access, has been largely ignred t date. Many rganizatins dn't even knw hw many SSH keys they have cnfigured t grant access t their infrmatin systems r wh has cpies f thse keys. The accunts assciated with these keys ften grant far mre access than is actually needed, such as allwing executin f any cmmand r transfer f files t any directry. Als, in many rganizatins, system administratrs cnfigure new keys withut any apprvals r crdinatin, and may use them t circumvent auditing f privileged access and maintenance. Sme large enterprises have hundreds f thusands r even millins f SSH user keys n their systems fr autmated access, which ften prvide many mre entry pints nt servers than the interactive user accunts d. Als, a sizable percentage f these keys typically grant access t administrative/rt accunts r sensitive accunts, such as thse string database files r critical sftware. SSH is als ften used fr cmmunicatins with ther rganizatins, external systems, r independent users. A clsely related issue is the trust relatinships that these keys establish within and between systems, even between rganizatins. Sme f these trust relatinships may be undesirable r vilate plicies, such as leading frm develpment and test systems int prductin systems, r crssing frm a lw-impact system t a high-impact system withut requiring any additinal authenticatin. Mst imprtantly, SSH key-based trust relatinships can enable an attacker wh cmprmises ne system t quickly mve (r pivt) frm ne system t anther and spread thrugh an rganizatin individual trust relatinships ften cllectively frm webs f trust acrss an rganizatin s systems. Althugh the security implicatins f pr SSH key management have been knwn fr sme time, the scpe f the prblem fr autmated access has nt been widely understd r acknwledged. Fr example, mst rganizatins d nt have SSH key management r SSH-based autmated access as part f their assessment prgrams, even thugh fr many rganizatins SSH-based autmated access has already becme central t their identity and access management peratins. This sectin describes the primary categries f vulnerabilities in SSH-based interactive and autmated access with a particular fcus n user keys used t grant access in public key authenticatin. The recmmendatins presented in subsequent sectins f this dcument are intended t address these vulnerabilities. The categries f vulnerabilities described in this sectin are as fllws: Vulnerable SSH implementatin Imprperly cnfigured access cntrls Stlen, leaked, derived, and unterminated SSH user keys Backdrs (unaudited user keys) Unintended usage f user keys 12 Althugh access t rt accunts via SSH is generally nt allwed, administratrs will leverage sud and ther tls t elevate their privileges fr many peratins nce lgged in via SSH. 12

19 Pivting Lack f knwledge and human errrs 4.1 Vulnerable SSH Implementatin An SSH server r client implementatin culd have vulnerabilities that allw it t be explited in rder t gain unauthrized access t cmmunicatins r systems. These vulnerabilities culd be any f the fllwing types: Sftware flaws in the SSH implementatin (i.e., cding errrs) Cnfiguratin weaknesses (fr example, allwing the use f weak encryptin algrithms) Prtcl weaknesses (fr example, supprting the use f SSH versin 1) 4.2 Imprperly Cnfigured Access Cntrls In its rle f enabling administratin f systems via elevated privileges including rt SSH is highly susceptible t enabling unauthrized access due t imprperly cnfigured access cntrls. Mst SSH implementatins prvide a brad number f ptins fr cnfiguring and cntrlling access, sme f which are prvided by the SSH sftware and thers thrugh cmpnents with which the SSH sftware integrates, including the underlying OS, pluggable authenticatin mdule (PAM), Kerbers, and ther security cmpnents. Althugh pwerful, imprperly cnfigured access cntrls can inadvertently enable SSH access directly t the rt accunt, unauthrized access t ther accunts due t implicit access enabled via Kerbers, the ability t elevate privileges by manipulating the envirnment, and ther accessbased vulnerabilities. An administratr may, fr example, prperly cnfigure SSH but incrrectly cnfigure PAM r nt sufficiently limit permissins at the OS fr the accunt being accessed. Furthermre, each OS, appliance, device, r applicatin that supprts SSH features different ptins and methds fr cntrlling access, further cmplicating effrts t ensure security. 4.3 Stlen, Leaked, Derived, and Unterminated Keys Stlen, leaked, derived, and unterminated identity keys pse a similar prblem t stlen, leaked, derived, and unterminated interactive user accunt credentials. Anyne wh may have btained a cpy f an identity key by cpying it frm a hst, by accessing a backup, by having malware harvest keys, by perfrming factring t derive a key, etc. may use that key t attempt t gain unauthrized access t a user accunt n ne r mre servers in the rganizatin. Once access t a user accunt has been gained, it is generally pssible t access and mdify any data fr that user accunt including reading and mdifying the memry f prcesses running under that user accunt, and mdifying any executable prgrams wned by that user accunt. 4.4 Backdr Keys Many rganizatins mandate that all privileged access t their servers take place thrugh a privileged access management system that recrds all actins perfrmed. Unfrtunately, SSH public key authenticatin can be used t create a backdr that bypasses the privileged access management system. This is dne as easily as generating a new key pair and adding a new authrized key t an authrized keys file; authrized keys files are ften nt audited, s an added key may remain unnticed fr years. The crrespnding identity key can then be used t lg int the server using any SSH client withut the privileged access management system recrding the ensuing activity. 13

20 4.5 Unintended Usage Users may, intentinally r unintentinally, use identity keys fr purpses fr which they were nt intended. An example is using an identity key that was nly intended t be used fr autmated file transfers t tunnel traffic (thus cncealing it frm netwrk security cntrls). 4.6 Pivting Malware can be engineered t use SSH keys t spread when autmated access is allwed. The mesh f interactive and autmated access relatinships is s dense in many cases that it is likely that an attack can spread (pivt) t mst servers in an rganizatin after penetrating the first few servers, especially if ther attack vectrs are used t escalate privileges. See Figure 4-1 fr an illustratin f pivting. Initial intrusin Subsequent pivting Figure 4-1: Pivting Enabled by Chained SSH Trust Relatinships 4.7 Lack f Knwledge and Human Errrs One f the greatest nging challenges t the security f SSH-based systems is the ptential fr human errr due t the cmplexity f SSH management and the lack f knwledge many administratrs have regarding secure SSH cnfiguratin and management. An authrized key may inadvertently be deplyed incrrectly n a hst, such as t a rt accunt instead f a regular user accunt, thus granting unnecessary privileges. Peple are knwn t make human errrs when manually setting up new trust relatinships. Such errrs can g undetected fr years. Als, sme key setups invlve thusands f hsts, and while it is easy t miss ne r mre hsts when cpying an authrized key t s many hsts manually, debugging such errrs can be very time cnsuming. Als, when manually fixing prblems, administratrs are likely t just cpy the missing keys t the prper accunts withut, fr example, checking whether they have accidentally been cpied t the rt accunt. 14

21 5. Recmmended Practices fr Management Effectively securing SSH access cnsists f defining clear plicies and implementing management, peratinal, and technical security cntrl prcesses t address already deplyed SSH systems, privileges, and user keys, and ensure that new SSH systems and user keys are prperly deplyed and tracked. The bjective f management is t imprve security as ecnmically as pssible by fllwing the NIST SP recmmended practices fr access cntrl with respect t interactive and autmated access using SSH. Operatinal prcesses can be ptimized by autmating SSH user key setups and remvals and related apprval, dcumentatin, mnitring, and audit prcesses. In particular, it is pssible t integrate a key management system with a ticketing r change tracking system. If requests fr prvisining interactive r autmated access are made using a predefined template, a key management system can autmatically d the prvisining nce the request has been apprved, thus reducing labr. Certain prvisining requests may tuch thusands f hsts, and sme rganizatins are knwn t use persn-years annually n manual prvisining. An SSH access management prject may als include either selectin and acquisitin f sftware tls t aid in the prcess r develpment f autmatically r manually executed scripts. 5.1 SSH Security Plicies and Prcedures Plicies and prcedures play a critical rle in SSH security by establishing cnsistent baseline requirements acrss the diverse systems and envirnments where SSH is deplyed, including rapidly evlving clud envirnments. The definitin f plicies shuld clearly spell ut rles and respnsibilities in rder t prevent misunderstandings that result in security lapses and t ensure accuntability. It is critical t educate all SSH stakehlders (system administratrs, security prfessinals, business applicatin wners, etc.) n SSH security plicies and prcesses Secure SSH Implementatin Althugh the hardening f SSH implementatins is utside the scpe f this dcument, it is wrth nting a few areas where plicies and prcedures shuld be defined t mitigate the significant vulnerabilities that can emerge due t pr implementatin and management. Other NIST publicatins and industry standards shuld be cnsulted as references fr defining plicies in the fllwing areas: Only enabling SSH server functinality n systems where it is abslutely required. Keeping SSH server and client implementatins fully up t date acrss all systems. Hardening SSH server and client implementatins, including disabling SSH v1 prtcl, disabling unapprved authenticatin methds, preventing implicit access by limiting SSH accessible accunts and grups (including rt), disabling prt frwarding, limiting access t envirnment variables, using apprved ciphers, prperly cnfiguring supprting subsystems (e.g., PAM), and enfrcing SSH inactivity timeuts Unfrtunately, it is nt always pssible t harden SSH implementatins (e.g., n appliances and embedded devices). In these cases, cmpensating cntrls can be used t mitigate the vulnerabilities, such as implementing virtual private netwrk (VPN) tunnels t encapsulate the ptentially vulnerable SSH traffic. 15

22 Enfrcing least privileged access fr all SSH-accessible accunts and grups, especially fr autmated prcesses and remte access SSH Identity and Authrized Keys SSH user keys are security-sensitive cnfiguratin infrmatin fr SSH clients and servers, and their miscnfiguratin, imprper disclsure, r mdificatin may expse servers, applicatins, and infrmatin t unintended access r vulnerabilities. The fllwing plicies and prcedures are recmmended: Minimum Key Lengths and Apprved Algrithms: T prevent factring by an attacker, user keys must cnfrm t rganizatinal standards fr minimum key lengths used with apprved algrithms. NIST SP A 15 currently prvides recmmendatins fr minimum key lengths that are cnsidered secure in cnjunctin with varius algrithms. Updates t NIST SP A shuld be mnitred t ensure that the latest recmmendatins fr key lengths are being fllwed. Nte that sme lder SSH implementatins may nt supprt the key lengths recmmended by NIST SP A. Clear criteria shuld be defined fr exceptins where the use f smaller key lengths is allwed. Cryptperids (Maximum Key Lifetime): T minimize the risk f key cmprmise due t administrative turnver r imprper key management by users, the maximum time (cryptperid) that an identity key may be used befre replacement with a new key shuld be specified. NIST SP prvides recmmended cryptperids fr public/private authenticatin keys. Cryptperid plicies may take int accunt the ptential fr cmprmise based n types f use, including identity keys used fr users versus autmated prcesses, the criticality f systems that are being accessed, the envirnment where identity keys are stred (e.g., mbile laptps versus smartcard), and whether the keys are used in cnnectins that span utside the rganizatin. Identity Key Access Cntrl: T prevent cmprmise f a key by an authrized user, access cntrls n identity keys shuld be cnfigured t restrict access t the interactive user r autmated prcess t which they have been assigned. Fr autmated prcesses, plicies shuld define guidelines fr assigning access t administrative staff respnsible fr managing identity keys. Identity Key Passphrases: T prtect against cmprmise, identity keys assigned t interactive users shuld be prtected by a passphrase. Standards fr passphrase strength and changing passphrases each time a key is replaced (at the end f the cryptperid) shuld be defined. Identity Key Duplicatin: Identity keys shuld nt be duplicated (cpied t ther systems) fr interactive users and autmated prcesses. If duplicatin is allwed fr interactive users, guidelines shuld be prvided fr the acceptable lcatins where keys can be cpied and used. Authrized Key Access Cntrls: Access cntrls n authrized keys shuld ensure that nnsuperusers cannt install new authrized keys fr user accunts they use. Such new authrized keys can create backdrs, bypass privileged access auditing systems, grant permanent access, r grant access t thers, withut regards t cntrls n nn-lcal access and authrizatin bundaries. In practice this means lcking dwn keys, i.e., mving authrized keys t superuser-wned lcatins that are nt writable t nn-superusers. It is strngly recmmended that authrized keys be mved t prtected lcatins where rdinary users cannt add new r change existing keys, as well as cnfiguring SSH servers t nly lk fr keys frm thse lcatins. This is necessary fr the fllwing reasns: Maintaining cntrl f wh can access what infrmatin

23 Prperly identifying users accessing the system Preventing a user frm accessing the system after his/her accunt is terminated Ensuring that users cannt bypass privileged access systems Cntrlling remte access Enfrcing authrizatin bundaries Authrized Key Cmmand Restrictins: Authrized keys used fr autmated prcesses shuld be cnfigured with cmmand restrictins unless special apprval is given. Cmmand restrictins are particularly imprtant fr keys used fr authrizing remte file transfers t avid accidentally permitting remte terminal access and remte executin f cmmands. Fr interactive users, cmmand restrictins used in cnjunctin with scripts may be used t limit the cmmands available t users. Authrized Key Surce Restrictins: Authrized keys used fr autmated prcesses shuld be cnfigured with surce restrictins unless special apprval is given, i.e., restrictins n the client IP addresses frm which the keys can be used. This prevents an attacker wh cmprmises an identity key frm using it elsewhere n the netwrk. Surce and cmmand restrictins are a particularly imprtant cnsideratin fr SSH cnnectins that allw access frm utside the rganizatin. Replacement n Cmprmise r Reassignment: SSH keys shuld be changed when a cmprmise is suspected. In additin, identity keys used fr autmated prcesses shuld be changed prir t cryptperid expiratin whenever an administratr respnsible fr managing the keys fr ne r mre autmated prcesses has been reassigned r terminated. Usage Lgging: All SSH servers shuld be cnfigured t lg key fingerprints fr access based n SSH authrized keys. This is necessary fr perfrming the lg analysis needed fr cntinuus mnitring and frensic investigatins. Pivt Preventin: Accunts shuld nt be cnfigured with bth incming and utging identity keybased trust relatinships unless expressly needed (fr example, an apprved jump server). Fr example, if an authrized key fr IdentityKey1 is cnfigured fr accunt User1 n Server1 and that same accunt has anther identity key enabling it t authenticate t accunt User1 n Server2, an attacker wh gains access t IdentityKey1 can nw pivt frm Server1 t Server2. Incming and utging trust relatinships n a server shuld be cnfigured in separate accunts t prevent pivting. If an rganizatin has needs fr limited pivting, these implementatins shuld be apprved n a case-by-case basis. N Envirnment Crssing: SSH trust relatinships shuld nt crss release envirnment (dev, QA, prd) in rder t prevent a cmprmise in a lwer develpment r QA envirnment spreading t prductin envirnments. 5.2 SSH Key-Based Access Prvisining, Life Cycle, and Terminatin Prcesses Prvisining and cnfiguring access t an accunt fr interactive users and autmated prcesses shuld be a judged decisin, balancing the need fr access against the risks, and shuld include cnsideratin f the level f access required. It is nt acceptable fr any user r system administratr t grant user accunt access t ther users r prcesses withut prper apprval. 17