Red Hat Enterprise Linux 7 Security Guide [pdf]

Red Hat Enterprise Linux 7 Security Guide

A Guide to Securing Red Hat Enterprise Linux 7

Mirek Jahoda Martin Prpič Yoana Ruseva

Ioanna Gkioka Tomáš Čapek Miroslav Svoboda

Robert Krátký Stephen Wadeley

Red Hat Enterprise Linux 7 Security Guide

A Guide to Securing Red Hat Enterprise Linux 7 Mirek Jahoda Red Hat Customer Content Services [email protected] Ioanna Gkioka Red Hat Customer Content Services [email protected] Robert Krátký Red Hat Customer Content Services Martin Prpič Red Hat Customer Content Services Tomáš Čapek Red Hat Customer Content Services Stephen Wadeley Red Hat Customer Content Services Yoana Ruseva Red Hat Customer Content Services Miroslav Svoboda Red Hat Customer Content Services

Legal No tice Copyright © 2017 Red Hat, Inc. This document is licensed by Red Hat under the Creative Commons AttributionShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. All other trademarks are the property of their respective owners.

Abstract This book assists users and administrators in learning the processes and practices of securing workstations and servers against local and remote intrusion, exploitation, and malicious activity. Focused on Red Hat Enterprise Linux but detailing concepts and techniques valid for all Linux systems, this guide details the planning and the tools involved in creating a secured computing environment for the data center, workplace, and home. With proper administrative knowledge, vigilance, and tools, systems running Linux can be both fully functional and secured from most common intrusion and exploit methods.

T able o f Co nt e nt s

T able o f Co ntents

. .hapt ⁠C . . . .e.r. 1. . .O . .ve . .r.vie . .w . .o. f. Se . . .c.ur . .it. y. .T.o.pic . . .s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . ⁠1 .1. What is C om puter Security? 3 ⁠1 .2. Security C ontrols 4 ⁠1 .3. Vulnerability Assessm ent 5 ⁠1 .4. Security Threats 9 ⁠1 .5. C om m on Exploits and Attacks 12

. .hapt ⁠C . . . .e.r. 2. . . Se ..c . ur . . it . .y. T . .ips . . .f .o.r.Ins . . .t.allat . . . .io. n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 .......... ⁠2.1. Securing BIO S 17 ⁠2.2. P artitioning the Disk 17 ⁠2.3. Installing the Minim um Am ount of P ackages Required 18 ⁠2.4. Restricting Network C onnectivity During the Installation P rocess 19 ⁠2.5. P ost-installation P rocedures 19 ⁠2.6. Additional Resources 19

. .hapt ⁠C . . . .e.r. 3. . . Ke ..e . .ping . . . .Yo . . ur . . .Sys . . .t.e.m . .Up-t . . . .o.-Dat . . . .e. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 .......... ⁠3 .1. Maintaining Installed Software 21 ⁠3 .2. Using the Red Hat C ustom er P ortal

25

⁠3 .3. Additional Resources

26

. .hapt ⁠C . . . .e.r. 4. .. Har . . . de . . .ning . . . . Yo . . ur . . .Sys . . .t.e.m . .wit . . .h. T. o . .o.ls. .and . . . Se . . .r.vic . . e. s. . . . . . . . . . . . . . . . . . . .28 .......... ⁠4 .1. Desktop Security 28 ⁠4 .2. C ontrolling Root Access ⁠4 .3. Securing Services ⁠4 .4. Securing Network Access

37 43 64

⁠4 .5. Securing DNS Traffic with DNSSEC ⁠4 .6. Securing Virtual P rivate Networks (VP Ns)

72 82

⁠4 .7. Using O penSSL ⁠4 .8. Using stunnel

93 99

⁠4 .9. Encryption ⁠4 .10. Using Network-Bound Disk Encryption

101 118

⁠4 .11. C hecking Integrity with AIDE ⁠4 .12. Using USBGuard

125 127

⁠4 .13. Hardening TLS C onfiguration ⁠4 .14. Using MAC sec

132 140

. .hapt ⁠C . . . .e.r. 5. . . Us . . ing . . . .Fir . .e. walls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 . .1. . . . . . . . . ⁠5.1. Introduction to firewalld 141 ⁠5.2. Installing firewalld 146 ⁠5.3. C onfiguring firewalld ⁠5.4. Using the iptables Service ⁠5.5. Additional Resources

147 175 183

. .hapt ⁠C . . . .e.r. 6. .. Sys . . . t. e .m . . Audit . . . . . ing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 . .5. . . . . . . . . ⁠U se C ases 186 ⁠6 .1. Audit System Architecture ⁠6 .2. Installing the audit P ackages ⁠6 .3. C onfiguring the audit Service ⁠6 .4. Starting the audit Service

187 187 188 189

⁠6 .5. Defining Audit Rules ⁠6 .6. Understanding Audit Log Files ⁠6 .7. Searching the Audit Log Files ⁠6 .8. C reating Audit Reports

190 197 202 203

1

Se c ur it y Guide

⁠6 .9. Additional Resources

204

. .hapt ⁠C . . . .e.r. 7. . . Co . . mplianc . . . . . . .e . .and . . . .Vulne . . . . .r.abilit . . . .y . .Sc . .anning . . . . . . wit . . .h . .O. pe . . nSCAP . . . . . . . . . . . . . . . . . .20 . .5. . . . . . . . . ⁠7.1. Security C om pliance in Red Hat Enterprise Linux ⁠7.2. Defining C om pliance P olicy ⁠7.3. Using SC AP Workbench ⁠7.4. Using oscap

205 205 214 221

⁠7.5. Using O penSC AP with Docker ⁠7.6. Using O penSC AP with Atom ic ⁠7.7. Using O penSC AP with Red Hat Satellite ⁠7.8. P ractical Exam ples ⁠7.9. Additional Resources

229 230 232 233 234

. .hapt ⁠C . . . .e.r. 8. .. Fe . . de . . .r.al. .St . .andar . . . . .ds . . and . . . .Re . . gulat . . . . .io . .ns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236 ........... ⁠8 .1. Federal Inform ation P rocessing Standard (FIP S) 236 ⁠8 .2. National Industrial Security P rogram O perating Manual (NISP O M) 238 ⁠8 .3. P aym ent C ard Industry Data Security Standard (P C I DSS) 238 ⁠8 .4. Security Technical Im plem entation Guide 238

. .ppe ⁠A . . .ndix . . . . A. . . Enc . . . r. ypt . . . io . .n. .St . .andar . . . . .ds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239 ........... ⁠A.1. Synchronous Encryption 239 ⁠A.2. P ublic-key Encryption

240

. .ppe ⁠A . . .ndix . . . . B. . . Audit . . . . . .Sys . . .t.e.m . .Re . .f.e.r.e.nc . .e. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 . .3. . . . . . . . . ⁠B.1. Audit Event Fields ⁠B.2. Audit Record Types

243 247

. .ppe ⁠A . . .ndix . . . . C. . . Re . . .vis . . io . .n. His . . . t. o. r. y. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253 ...........

2

⁠C hapt e r 1. O ve r vie w o f Se c ur it y T o pic s

Chapt er 1. Overview of Securit y Topics Due to the incre as e d re liance on powe rful, ne tworke d compute rs to he lp run bus ine s s e s and ke e p track of our pe rs onal information, e ntire indus trie s have be e n forme d around the practice of ne twork and compute r s e curity. Ente rpris e s have s olicite d the knowle dge and s kills of s e curity e xpe rts to prope rly audit s ys te ms and tailor s olutions to fit the ope rating re quire me nts of the ir organiz ation. Be caus e mos t organiz ations are incre as ingly dynamic in nature , the ir worke rs are acce s s ing critical company IT re s ource s locally and re mote ly, he nce the ne e d for s e cure computing e nvironme nts has be come more pronounce d. Unfortunate ly, many organiz ations (as we ll as individual us e rs ) re gard s e curity as more of an afte rthought, a proce s s that is ove rlooke d in favor of incre as e d powe r, productivity, conve nie nce , e as e of us e , and budge tary conce rns . Prope r s e curity imple me ntation is ofte n e nacte d pos tmorte m — after an unauthoriz e d intrus ion has alre ady occurre d. Taking the corre ct me as ure s prior to conne cting a s ite to an untrus te d ne twork, s uch as the Inte rne t, is an e ffe ctive me ans of thwarting many atte mpts at intrus ion.

No te This docume nt make s s e ve ral re fe re nce s to file s in the /lib dire ctory. Whe n us ing 64-bit s ys te ms , s ome of the file s me ntione d may ins te ad be locate d in /lib64.

1.1. What is Comput er Securit y? Compute r s e curity is a ge ne ral te rm that cove rs a wide are a of computing and information proce s s ing. Indus trie s that de pe nd on compute r s ys te ms and ne tworks to conduct daily bus ine s s trans actions and acce s s critical information re gard the ir data as an important part of the ir ove rall as s e ts . Se ve ral te rms and me trics have e nte re d our daily bus ine s s vocabulary, s uch as total cos t of owne rs hip (TCO), re turn on inve s tme nt (ROI), and quality of s e rvice (QoS). Us ing the s e me trics , indus trie s can calculate as pe cts s uch as data inte grity and high-availability (HA) as part of the ir planning and proce s s manage me nt cos ts . In s ome indus trie s , s uch as e le ctronic comme rce , the availability and trus tworthine s s of data can me an the diffe re nce be twe e n s ucce s s and failure .

1.1.1. St andardizing Securit y Ente rpris e s in e ve ry indus try re ly on re gulations and rule s that are s e t by s tandards making bodie s s uch as the Ame rican Me dical As s ociation (AMA) or the Ins titute of Ele ctrical and Ele ctronics Engine e rs (IEEE). The s ame ide als hold true for information s e curity. Many s e curity cons ultants and ve ndors agre e upon the s tandard s e curity mode l known as CIA, or Confidentiality, Integrity, and Availability. This thre e -tie re d mode l is a ge ne rally acce pte d compone nt to as s e s s ing ris ks of s e ns itive information and e s tablis hing s e curity policy. The following de s cribe s the CIA mode l in furthe r de tail: Confide ntiality — Se ns itive information mus t be available only to a s e t of pre -de fine d individuals . Unauthoriz e d trans mis s ion and us age of information s hould be re s tricte d. For e xample , confide ntiality of information e ns ure s that a cus tome r's pe rs onal or financial information is not obtaine d by an unauthoriz e d individual for malicious purpos e s s uch as ide ntity the ft or cre dit fraud.

3

Se c ur it y Guide

Inte grity — Information s hould not be alte re d in ways that re nde r it incomple te or incorre ct. Unauthoriz e d us e rs s hould be re s tricte d from the ability to modify or de s troy s e ns itive information. Availability — Information s hould be acce s s ible to authoriz e d us e rs any time that it is ne e de d. Availability is a warranty that information can be obtaine d with an agre e d-upon fre que ncy and time line s s . This is ofte n me as ure d in te rms of pe rce ntage s and agre e d to formally in Se rvice Le ve l Agre e me nts (SLAs ) us e d by ne twork s e rvice provide rs and the ir e nte rpris e clie nts .

1.2. Securit y Cont rols Compute r s e curity is ofte n divide d into thre e dis tinct mas te r cate gorie s , commonly re fe rre d to as controls: Phys ical Te chnical Adminis trative The s e thre e broad cate gorie s de fine the main obje ctive s of prope r s e curity imple me ntation. Within the s e controls are s ub-cate gorie s that furthe r de tail the controls and how to imple me nt the m.

1.2.1. Physical Cont rols Phys ical control is the imple me ntation of s e curity me as ure s in a de fine d s tructure us e d to de te r or pre ve nt unauthoriz e d acce s s to s e ns itive mate rial. Example s of phys ical controls are : Clos e d-circuit s urve illance came ras Motion or the rmal alarm s ys te ms Se curity guards Picture IDs Locke d and de ad-bolte d s te e l doors Biome trics (include s finge rprint, voice , face , iris , handwriting, and othe r automate d me thods us e d to re cogniz e individuals )

1.2.2. T echnical Cont rols Te chnical controls us e te chnology as a bas is for controlling the acce s s and us age of s e ns itive data throughout a phys ical s tructure and ove r a ne twork. Te chnical controls are far-re aching in s cope and e ncompas s s uch te chnologie s as : Encryption Smart cards Ne twork authe ntication Acce s s control lis ts (ACLs )

4

⁠C hapt e r 1. O ve r vie w o f Se c ur it y T o pic s

File inte grity auditing s oftware

1.2.3. Administ rat ive Cont rols Adminis trative controls de fine the human factors of s e curity. The y involve all le ve ls of pe rs onne l within an organiz ation and de te rmine which us e rs have acce s s to what re s ource s and information by s uch me ans as : Training and aware ne s s Dis as te r pre pare dne s s and re cove ry plans Pe rs onne l re cruitme nt and s e paration s trate gie s Pe rs onne l re gis tration and accounting

1.3. Vulnerabilit y Assessment Give n time , re s ource s , and motivation, an attacke r can bre ak into ne arly any s ys te m. All of the s e curity proce dure s and te chnologie s curre ntly available cannot guarante e that any s ys te ms are comple te ly s afe from intrus ion. Route rs he lp s e cure gate ways to the Inte rne t. Fire walls he lp s e cure the e dge of the ne twork. Virtual Private Ne tworks s afe ly pas s data in an e ncrypte d s tre am. Intrus ion de te ction s ys te ms warn you of malicious activity. Howe ve r, the s ucce s s of e ach of the s e te chnologie s is de pe nde nt upon a numbe r of variable s , including: The e xpe rtis e of the s taff re s pons ible for configuring, monitoring, and maintaining the te chnologie s . The ability to patch and update s e rvice s and ke rne ls quickly and e fficie ntly. The ability of thos e re s pons ible to ke e p cons tant vigilance ove r the ne twork. Give n the dynamic s tate of data s ys te ms and te chnologie s , s e curing corporate re s ource s can be quite comple x. Due to this comple xity, it is ofte n difficult to find e xpe rt re s ource s for all of your s ys te ms . While it is pos s ible to have pe rs onne l knowle dge able in many are as of information s e curity at a high le ve l, it is difficult to re tain s taff who are e xpe rts in more than a fe w s ubje ct are as . This is mainly be caus e e ach s ubje ct are a of information s e curity re quire s cons tant atte ntion and focus . Information s e curity doe s not s tand s till. A vulne rability as s e s s me nt is an inte rnal audit of your ne twork and s ys te m s e curity; the re s ults of which indicate the confide ntiality, inte grity, and availability of your ne twork (as e xplaine d in Se ction 1.1.1, “Standardiz ing Se curity”). Typically, vulne rability as s e s s me nt s tarts with a re connais s ance phas e , during which important data re garding the targe t s ys te ms and re s ource s is gathe re d. This phas e le ads to the s ys te m re adine s s phas e , whe re by the targe t is e s s e ntially che cke d for all known vulne rabilitie s . The re adine s s phas e culminate s in the re porting phas e , whe re the findings are clas s ifie d into cate gorie s of high, me dium, and low ris k; and me thods for improving the s e curity (or mitigating the ris k of vulne rability) of the targe t are dis cus s e d If you we re to pe rform a vulne rability as s e s s me nt of your home , you would like ly che ck e ach door to your home to s e e if the y are clos e d and locke d. You would als o che ck e ve ry window, making s ure that the y clos e d comple te ly and latch corre ctly. This s ame conce pt applie s to s ys te ms , ne tworks , and e le ctronic data. Malicious us e rs are the thie ve s and vandals of your data. Focus on the ir tools , me ntality, and motivations , and you can the n re act s wiftly to the ir actions .

1.3.1. Def ining Assessment and T est ing

5

Se c ur it y Guide

1.3.1. Def ining Assessment and T est ing Vulne rability as s e s s me nts may be broke n down into one of two type s : outside looking in and inside looking around. Whe n pe rforming an outs ide -looking-in vulne rability as s e s s me nt, you are atte mpting to compromis e your s ys te ms from the outs ide . Be ing e xte rnal to your company provide s you with the cracke r's vie wpoint. You s e e what a cracke r s e e s — publicly-routable IP addre s s e s , s ys te ms on your DMZ, e xte rnal inte rface s of your fire wall, and more . DMZ s tands for "de militariz e d z one ", which corre s ponds to a compute r or s mall s ubne twork that s its be twe e n a trus te d inte rnal ne twork, s uch as a corporate private LAN, and an untrus te d e xte rnal ne twork, s uch as the public Inte rne t. Typically, the DMZ contains de vice s acce s s ible to Inte rne t traffic, s uch as We b (HTTP) s e rve rs , FTP s e rve rs , SMTP (e -mail) s e rve rs and DNS s e rve rs . Whe n you pe rform an ins ide -looking-around vulne rability as s e s s me nt, you are at an advantage s ince you are inte rnal and your s tatus is e le vate d to trus te d. This is the vie wpoint you and your co-worke rs have once logge d on to your s ys te ms . You s e e print s e rve rs , file s e rve rs , databas e s , and othe r re s ource s . The re are s triking dis tinctions be twe e n the two type s of vulne rability as s e s s me nts . Be ing inte rnal to your company give s you more privile ge s than an outs ide r. In mos t organiz ations , s e curity is configure d to ke e p intrude rs out. Ve ry little is done to s e cure the inte rnals of the organiz ation (s uch as de partme ntal fire walls , us e r-le ve l acce s s controls , and authe ntication proce dure s for inte rnal re s ource s ). Typically, the re are many more re s ource s whe n looking around ins ide as mos t s ys te ms are inte rnal to a company. Once you are outs ide the company, your s tatus is untrus te d. The s ys te ms and re s ource s available to you e xte rnally are us ually ve ry limite d. Cons ide r the diffe re nce be twe e n vulne rability as s e s s me nts and penetration tests. Think of a vulne rability as s e s s me nt as the firs t s te p to a pe ne tration te s t. The information gle ane d from the as s e s s me nt is us e d for te s ting. Whe re as the as s e s s me nt is unde rtake n to che ck for hole s and pote ntial vulne rabilitie s , the pe ne tration te s ting actually atte mpts to e xploit the findings . As s e s s ing ne twork infras tructure is a dynamic proce s s . Se curity, both information and phys ical, is dynamic. Pe rforming an as s e s s me nt s hows an ove rvie w, which can turn up fals e pos itive s and fals e ne gative s . A fals e pos itive is a re s ult, whe re the tool finds vulne rabilitie s which in re ality do not e xis t. A fals e ne gative is whe n it omits actual vulne rabilitie s . Se curity adminis trators are only as good as the tools the y us e and the knowle dge the y re tain. Take any of the as s e s s me nt tools curre ntly available , run the m agains t your s ys te m, and it is almos t a guarante e that the re are s ome fals e pos itive s . Whe the r by program fault or us e r e rror, the re s ult is the s ame . The tool may find fals e pos itive s , or, e ve n wors e , fals e ne gative s . Now that the diffe re nce be twe e n a vulne rability as s e s s me nt and a pe ne tration te s t is de fine d, take the findings of the as s e s s me nt and re vie w the m care fully be fore conducting a pe ne tration te s t as part of your ne w be s t practice s approach.

Warning Do not atte mpt to e xploit vulne rabilitie s on production s ys te ms . Doing s o can have adve rs e e ffe cts on productivity and e fficie ncy of your s ys te ms and ne twork.

6

⁠C hapt e r 1. O ve r vie w o f Se c ur it y T o pic s

The following lis t e xamine s s ome of the be ne fits to pe rforming vulne rability as s e s s me nts . Cre ate s proactive focus on information s e curity. Finds pote ntial e xploits be fore cracke rs find the m. Re s ults in s ys te ms be ing ke pt up to date and patche d. Promote s growth and aids in de ve loping s taff e xpe rtis e . Abate s financial los s and ne gative publicity.

1.3.2. Est ablishing a Met hodology f or Vulnerabilit y Assessment To aid in the s e le ction of tools for a vulne rability as s e s s me nt, it is he lpful to e s tablis h a vulne rability as s e s s me nt me thodology. Unfortunate ly, the re is no pre de fine d or indus try approve d me thodology at this time ; howe ve r, common s e ns e and be s t practice s can act as a s ufficie nt guide . What is the target? Are we looking at one server, or are we looking at our entire network and everything within the network? Are we external or internal to the company? The ans we rs to the s e que s tions are important as the y he lp de te rmine not only which tools to s e le ct but als o the manne r in which the y are us e d. To le arn more about e s tablis hing me thodologie s , s e e the following we bs ite : https ://www.owas p.org/ — The Open Web Application Security Project

1.3.3. Vulnerabilit y Assessment T ools An as s e s s me nt can s tart by us ing s ome form of an information-gathe ring tool. Whe n as s e s s ing the e ntire ne twork, map the layout firs t to find the hos ts that are running. Once locate d, e xamine e ach hos t individually. Focus ing on the s e hos ts re quire s anothe r s e t of tools . Knowing which tools to us e may be the mos t crucial s te p in finding vulne rabilitie s . Jus t as in any as pe ct of e ve ryday life , the re are many diffe re nt tools that pe rform the s ame job. This conce pt applie s to pe rforming vulne rability as s e s s me nts as we ll. The re are tools s pe cific to ope rating s ys te ms , applications , and e ve n ne tworks (bas e d on the protocols us e d). Some tools are fre e ; othe rs are not. Some tools are intuitive and e as y to us e , while othe rs are cryptic and poorly docume nte d but have fe ature s that othe r tools do not. Finding the right tools may be a daunting tas k and, in the e nd, e xpe rie nce counts . If pos s ible , s e t up a te s t lab and try out as many tools as you can, noting the s tre ngths and we akne s s e s of e ach. Re vie w the README file or man page for the tools . Additionally, look to the Inte rne t for more information, s uch as article s , s te p-by-s te p guide s , or e ve n mailing lis ts s pe cific to the tools . The tools dis cus s e d be low are jus t a s mall s ampling of the available tools .

1.3.3.1. Scanning Host s wit h Nmap Nmap is a popular tool that can be us e d to de te rmine the layout of a ne twork. Nmap has be e n available for many ye ars and is probably the mos t ofte n us e d tool whe n gathe ring information. An e xce lle nt manual page is include d that provide s de taile d de s criptions of its options and us age . Adminis trators can us e Nmap on a ne twork to find hos t s ys te ms and ope n ports on thos e s ys te ms .

7

Se c ur it y Guide

Nmap is a compe te nt firs t s te p in vulne rability as s e s s me nt. You can map out all the hos ts within your ne twork and e ve n pas s an option that allows Nmap to atte mpt to ide ntify the ope rating s ys te m running on a particular hos t. Nmap is a good foundation for e s tablis hing a policy of us ing s e cure s e rvice s and re s tricting unus e d s e rvice s . To ins tall Nmap, run the yum install nmap command as the root us e r. 1.3.3.1.1. Using Nmap Nmap can be run from a s he ll prompt by typing the nmap command followe d by the hos t name or IP addre s s of the machine to s can: nmap For e xample , to s can a machine with hos t name foo.example.com, type the following at a s he ll prompt: ~]$ nmap foo.example.com The re s ults of a bas ic s can (which could take up to a fe w minute s , de pe nding on whe re the hos t is locate d and othe r ne twork conditions ) look s imilar to the following: Interesting ports on foo.example.com: Not shown: 1710 filtered ports PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 80/tcp open http 113/tcp closed auth Nmap te s ts the mos t common ne twork communication ports for lis te ning or waiting s e rvice s . This knowle dge can be he lpful to an adminis trator who wants to clos e unne ce s s ary or unus e d s e rvice s . For more information about us ing Nmap, s e e the official home page at the following URL: http://www.ins e cure .org/

1.3.3.2. Nessus Nessus is a full-s e rvice s e curity s canne r. The plug-in archite cture of Nessus allows us e rs to cus tomiz e it for the ir s ys te ms and ne tworks . As with any s canne r, Nessus is only as good as the s ignature databas e it re lie s upon. Fortunate ly, Nessus is fre que ntly update d and fe ature s full re porting, hos t s canning, and re al-time vulne rability s e arche s . Re me mbe r that the re could be fals e pos itive s and fals e ne gative s , e ve n in a tool as powe rful and as fre que ntly update d as Nessus.

No te The Nessus clie nt and s e rve r s oftware re quire s a s ubs cription to us e . It has be e n include d in this docume nt as a re fe re nce to us e rs who may be inte re s te d in us ing this popular application.

8

⁠C hapt e r 1. O ve r vie w o f Se c ur it y T o pic s

For more information about Nessus, s e e the official we bs ite at the following URL: http://www.ne s s us .org/

1.3.3.3. OpenVAS OpenVAS (Open Vulnerability Assessment System) is a s e t of tools and s e rvice s that can be us e d to s can for vulne rabilitie s and for a compre he ns ive vulne rability manage me nt. The OpenVAS frame work offe rs a numbe r of we b-bas e d, de s ktop, and command line tools for controlling the various compone nts of the s olution. The core functionality of OpenVAS is provide d by a s e curity s canne r, which make s us e of ove r 33 thous and dailyupdate d Ne twork Vulne rability Te s ts (NVT). Unlike Nessus (s e e Se ction 1.3.3.2, “Nessus”), OpenVAS doe s not re quire any s ubs cription. For more information about Ope nVAS, s e e the official we bs ite at the following URL: http://www.ope nvas .org/

1.3.3.4. Nikt o Nikt o is an e xce lle nt common gateway interface (CGI) s cript s canne r. Nikt o not only che cks for CGI vulne rabilitie s but doe s s o in an e vas ive manne r, s o as to e lude intrus ionde te ction s ys te ms . It come s with thorough docume ntation which s hould be care fully re vie we d prior to running the program. If you have we b s e rve rs s e rving CGI s cripts , Nikt o can be an e xce lle nt re s ource for che cking the s e curity of the s e s e rve rs . More information about Nikt o can be found at the following URL: http://cirt.ne t/nikto2

1.4. Securit y T hreat s 1.4.1. T hreat s t o Net work Securit y Bad practice s whe n configuring the following as pe cts of a ne twork can incre as e the ris k of an attack.

Insecure Archit ect ures A mis configure d ne twork is a primary e ntry point for unauthoriz e d us e rs . Le aving a trus tbas e d, ope n local ne twork vulne rable to the highly-ins e cure Inte rne t is much like le aving a door ajar in a crime -ridde n ne ighborhood — nothing may happe n for an arbitrary amount of time , but s ome one e xploits the opportunity eventually.

Broadcast Net works Sys te m adminis trators ofte n fail to re aliz e the importance of ne tworking hardware in the ir s e curity s che me s . Simple hardware , s uch as hubs and route rs , re lie s on the broadcas t or non-s witche d principle ; that is , whe ne ve r a node trans mits data acros s the ne twork to a re cipie nt node , the hub or route r s e nds a broadcas t of the data packe ts until the re cipie nt node re ce ive s and proce s s e s the data. This me thod is the mos t vulne rable to addre s s re s olution protocol (ARP) or me dia acce s s control (MAC) addre s s s poofing by both outs ide intrude rs and unauthoriz e d us e rs on local hos ts .

Cent ralized Servers

9

Se c ur it y Guide

Anothe r pote ntial ne tworking pitfall is the us e of ce ntraliz e d computing. A common cos tcutting me as ure for many bus ine s s e s is to cons olidate all s e rvice s to a s ingle powe rful machine . This can be conve nie nt as it is e as ie r to manage and cos ts cons ide rably le s s than multiple -s e rve r configurations . Howe ve r, a ce ntraliz e d s e rve r introduce s a s ingle point of failure on the ne twork. If the ce ntral s e rve r is compromis e d, it may re nde r the ne twork comple te ly us e le s s or wors e , prone to data manipulation or the ft. In the s e s ituations , a ce ntral s e rve r be come s an ope n door that allows acce s s to the e ntire ne twork.

1.4.2. T hreat s t o Server Securit y Se rve r s e curity is as important as ne twork s e curity be caus e s e rve rs ofte n hold a gre at de al of an organiz ation's vital information. If a s e rve r is compromis e d, all of its conte nts may be come available for the cracke r to s te al or manipulate at will. The following s e ctions de tail s ome of the main is s ue s .

Unused Services and Open Port s A full ins tallation of Re d Hat Ente rpris e Linux 7 contains more than 1000 application and library package s . Howe ve r, mos t s e rve r adminis trators do not opt to ins tall e ve ry s ingle package in the dis tribution, pre fe rring ins te ad to ins tall a bas e ins tallation of package s , including s e ve ral s e rve r applications . Se e Se ction 2.3, “Ins talling the Minimum Amount of Package s Re quire d” for an e xplanation of the re as ons to limit the numbe r of ins talle d package s and for additional re s ource s . A common occurre nce among s ys te m adminis trators is to ins tall the ope rating s ys te m without paying atte ntion to what programs are actually be ing ins talle d. This can be proble matic be caus e unne e de d s e rvice s may be ins talle d, configure d with the de fault s e ttings , and pos s ibly turne d on. This can caus e unwante d s e rvice s , s uch as Te lne t, DHCP, or DNS, to run on a s e rve r or works tation without the adminis trator re aliz ing it, which in turn can caus e unwante d traffic to the s e rve r or e ve n a pote ntial pathway into the s ys te m for cracke rs . Se e Se ction 4.3, “Se curing Se rvice s ” for information on clos ing ports and dis abling unus e d s e rvice s .

Unpat ched Services Mos t s e rve r applications that are include d in a de fault ins tallation are s olid, thoroughly te s te d pie ce s of s oftware . Having be e n in us e in production e nvironme nts for many ye ars , the ir code has be e n thoroughly re fine d and many of the bugs have be e n found and fixe d. Howe ve r, the re is no s uch thing as pe rfe ct s oftware and the re is always room for furthe r re fine me nt. More ove r, ne we r s oftware is ofte n not as rigorous ly te s te d as one might e xpe ct, be caus e of its re ce nt arrival to production e nvironme nts or be caus e it may not be as popular as othe r s e rve r s oftware . De ve lope rs and s ys te m adminis trators ofte n find e xploitable bugs in s e rve r applications and publis h the information on bug tracking and s e curity-re late d we bs ite s s uch as the Bugtraq mailing lis t (http://www.s e curityfocus .com) or the Compute r Eme rge ncy Re s pons e Te am (CERT) we bs ite (http://www.ce rt.org). Although the s e me chanis ms are an e ffe ctive way of ale rting the community to s e curity vulne rabilitie s , it is up to s ys te m adminis trators to patch the ir s ys te ms promptly. This is particularly true be caus e cracke rs have acce s s to the s e s ame vulne rability tracking s e rvice s and will us e the information to crack unpatche d s ys te ms whe ne ve r the y can. Good s ys te m adminis tration re quire s vigilance , cons tant bug tracking, and prope r s ys te m mainte nance to e ns ure a more s e cure computing e nvironme nt.

10

⁠C hapt e r 1. O ve r vie w o f Se c ur it y T o pic s

Se e Chapte r 3, Keeping Your System Up-to-Date for more information about ke e ping a s ys te m up-to-date .

Inat t ent ive Administ rat ion Adminis trators who fail to patch the ir s ys te ms are one of the gre ate s t thre ats to s e rve r s e curity. According to the SysAdmin, Audit, Network, Security Institute (SANS), the primary caus e of compute r s e curity vulne rability is "as s igning untraine d pe ople to maintain s e curity and providing ne ithe r the training nor the time to make it pos s ible to le arn and do the job." ⁠ [1] This applie s as much to ine xpe rie nce d adminis trators as it doe s to ove rconfide nt or amotivate d adminis trators . Some adminis trators fail to patch the ir s e rve rs and works tations , while othe rs fail to watch log me s s age s from the s ys te m ke rne l or ne twork traffic. Anothe r common e rror is whe n de fault pas s words or ke ys to s e rvice s are le ft unchange d. For e xample , s ome databas e s have de fault adminis tration pas s words be caus e the databas e de ve lope rs as s ume that the s ys te m adminis trator change s the s e pas s words imme diate ly afte r ins tallation. If a databas e adminis trator fails to change this pas s word, e ve n an ine xpe rie nce d cracke r can us e a wide ly-known de fault pas s word to gain adminis trative privile ge s to the databas e . The s e are only a fe w e xample s of how inatte ntive adminis tration can le ad to compromis e d s e rve rs .

Inherent ly Insecure Services Eve n the mos t vigilant organiz ation can fall victim to vulne rabilitie s if the ne twork s e rvice s the y choos e are inhe re ntly ins e cure . For ins tance , the re are many s e rvice s de ve lope d unde r the as s umption that the y are us e d ove r trus te d ne tworks ; howe ve r, this as s umption fails as s oon as the s e rvice be come s available ove r the Inte rne t — which is its e lf inhe re ntly untrus te d. One cate gory of ins e cure ne twork s e rvice s are thos e that re quire une ncrypte d us e rname s and pas s words for authe ntication. Te lne t and FTP are two s uch s e rvice s . If packe t s niffing s oftware is monitoring traffic be twe e n the re mote us e r and s uch a s e rvice us e rname s and pas s words can be e as ily inte rce pte d. Inhe re ntly, s uch s e rvice s can als o more e as ily fall pre y to what the s e curity indus try te rms the man-in-the-middle attack. In this type of attack, a cracke r re dire cts ne twork traffic by tricking a cracke d name s e rve r on the ne twork to point to his machine ins te ad of the inte nde d s e rve r. Once s ome one ope ns a re mote s e s s ion to the s e rve r, the attacke r's machine acts as an invis ible conduit, s itting quie tly be twe e n the re mote s e rvice and the uns us pe cting us e r capturing information. In this way a cracke r can gathe r adminis trative pas s words and raw data without the s e rve r or the us e r re aliz ing it. Anothe r cate gory of ins e cure s e rvice s include ne twork file s ys te ms and information s e rvice s s uch as NFS or NIS, which are de ve lope d e xplicitly for LAN us age but are , unfortunate ly, e xte nde d to include WANs (for re mote us e rs ). NFS doe s not, by de fault, have any authe ntication or s e curity me chanis ms configure d to pre ve nt a cracke r from mounting the NFS s hare and acce s s ing anything containe d the re in. NIS, as we ll, has vital information that mus t be known by e ve ry compute r on a ne twork, including pas s words and file pe rmis s ions , within a plain te xt ASCII or DBM (ASCII-de rive d) databas e . A cracke r who gains acce s s to this databas e can the n acce s s e ve ry us e r account on a ne twork, including the adminis trator's account. By de fault, Re d Hat Ente rpris e Linux 7 is re le as e d with all s uch s e rvice s turne d off. Howe ve r, s ince adminis trators ofte n find the ms e lve s force d to us e the s e s e rvice s , care ful configuration is critical. Se e Se ction 4.3, “Se curing Se rvice s ” for more information about s e tting up s e rvice s in a s afe manne r.

11

Se c ur it y Guide

1.4.3. T hreat s t o Workst at ion and Home PC Securit y Works tations and home PCs may not be as prone to attack as ne tworks or s e rve rs , but s ince the y ofte n contain s e ns itive data, s uch as cre dit card information, the y are targe te d by s ys te m cracke rs . Works tations can als o be co-opte d without the us e r's knowle dge and us e d by attacke rs as "s lave " machine s in coordinate d attacks . For the s e re as ons , knowing the vulne rabilitie s of a works tation can s ave us e rs the he adache of re ins talling the ope rating s ys te m, or wors e , re cove ring from data the ft.

Bad Passwords Bad pas s words are one of the e as ie s t ways for an attacke r to gain acce s s to a s ys te m. For more on how to avoid common pitfalls whe n cre ating a pas s word, s e e Se ction 4.1.1, “Pas s word Se curity”.

Vulnerable Client Applicat ions Although an adminis trator may have a fully s e cure and patche d s e rve r, that doe s not me an re mote us e rs are s e cure whe n acce s s ing it. For ins tance , if the s e rve r offe rs Te lne t or FTP s e rvice s ove r a public ne twork, an attacke r can capture the plain te xt us e rname s and pas s words as the y pas s ove r the ne twork, and the n us e the account information to acce s s the re mote us e r's works tation. Eve n whe n us ing s e cure protocols , s uch as SSH, a re mote us e r may be vulne rable to ce rtain attacks if the y do not ke e p the ir clie nt applications update d. For ins tance , v.1 SSH clie nts are vulne rable to an X-forwarding attack from malicious SSH s e rve rs . Once conne cte d to the s e rve r, the attacke r can quie tly capture any ke ys troke s and mous e clicks made by the clie nt ove r the ne twork. This proble m was fixe d in the v.2 SSH protocol, but it is up to the us e r to ke e p track of what applications have s uch vulne rabilitie s and update the m as ne ce s s ary. Se ction 4.1, “De s ktop Se curity” dis cus s e s in more de tail what s te ps adminis trators and home us e rs s hould take to limit the vulne rability of compute r works tations .

1.5. Common Exploit s and At t acks Table 1.1, “Common Exploits ” de tails s ome of the mos t common e xploits and e ntry points us e d by intrude rs to acce s s organiz ational ne twork re s ource s . Ke y to the s e common e xploits are the e xplanations of how the y are pe rforme d and how adminis trators can prope rly s afe guard the ir ne twork agains t s uch attacks . T able 1.1. Co mmo n Explo it s Explo it

12

Descript io n

No t es

⁠C hapt e r 1. O ve r vie w o f Se c ur it y T o pic s

Explo it

Descript io n

No t es

Null or De fault Pas s words

Le aving adminis trative pas s words blank or us ing a de fault pas s word s e t by the product ve ndor. This is mos t common in hardware s uch as route rs and fire walls , but s ome s e rvice s that run on Linux can contain de fault adminis trator pas s words as we ll (though Re d Hat Ente rpris e Linux 7 doe s not s hip with the m).

Commonly as s ociate d with ne tworking hardware s uch as route rs , fire walls , VPNs , and ne twork attache d s torage (NAS) appliance s . Common in many le gacy ope rating s ys te ms , e s pe cially thos e that bundle s e rvice s (s uch as UNIX and Windows .) Adminis trators s ome time s cre ate privile ge d us e r accounts in a rus h and le ave the pas s word null, cre ating a pe rfe ct e ntry point for malicious us e rs who dis cove r the account.

De fault Share d Ke ys

IP Spoofing

Se cure s e rvice s s ome time s package de fault s e curity ke ys for de ve lopme nt or e valuation te s ting purpos e s . If the s e ke ys are le ft unchange d and are place d in a production e nvironme nt on the Inte rne t, all us e rs with the s ame de fault ke ys have acce s s to that s hare d-ke y re s ource , and any s e ns itive information that it contains . A re mote machine acts as a node on your local ne twork, finds vulne rabilitie s with your s e rve rs , and ins talls a backdoor program or Trojan hors e to gain control ove r your ne twork re s ource s .

Mos t common in wire le s s acce s s points and pre configure d s e cure s e rve r appliance s .

Spoofing is quite difficult as it involve s the attacke r pre dicting TCP/IP s e que nce numbe rs to coordinate a conne ction to targe t s ys te ms , but s e ve ral tools are available to as s is t cracke rs in pe rforming s uch a vulne rability. De pe nds on targe t s ys te m running s e rvice s (s uch as rsh, telnet, FTP and othe rs ) that us e source-based authe ntication te chnique s , which are not re comme nde d whe n compare d to PKI or othe r forms of e ncrypte d authe ntication us e d in ssh or SSL/TLS.

13

Se c ur it y Guide

Explo it

Descript io n

No t es

Eave s dropping

Colle cting data that pas s e s be twe e n two active node s on a ne twork by e ave s dropping on the conne ction be twe e n the two node s .

This type of attack works mos tly with plain te xt trans mis s ion protocols s uch as Te lne t, FTP, and HTTP trans fe rs . Re mote attacke r mus t have acce s s to a compromis e d s ys te m on a LAN in orde r to pe rform s uch an attack; us ually the cracke r has us e d an active attack (s uch as IP s poofing or man-in-the -middle ) to compromis e a s ys te m on the LAN. Pre ve ntative me as ure s include s e rvice s with cryptographic ke y e xchange , one -time pas s words , or e ncrypte d authe ntication to pre ve nt pas s word s nooping; s trong e ncryption during trans mis s ion is als o advis e d.

14

⁠C hapt e r 1. O ve r vie w o f Se c ur it y T o pic s

Explo it

Descript io n

No t es

Se rvice Vulne rabilitie s

An attacke r finds a flaw or loophole in a s e rvice run ove r the Inte rne t; through this vulne rability, the attacke r compromis e s the e ntire s ys te m and any data that it may hold, and could pos s ibly compromis e othe r s ys te ms on the ne twork.

HTTP-bas e d s e rvice s s uch as CGI are vulne rable to re mote command e xe cution and e ve n inte ractive s he ll acce s s . Eve n if the HTTP s e rvice runs as a nonprivile ge d us e r s uch as "nobody", information s uch as configuration file s and ne twork maps can be re ad, or the attacke r can s tart a de nial of s e rvice attack which drains s ys te m re s ource s or re nde rs it unavailable to othe r us e rs . Se rvice s s ome time s can have vulne rabilitie s that go unnotice d during de ve lopme nt and te s ting; the s e vulne rabilitie s (s uch as buffer overflows, whe re attacke rs cras h a s e rvice us ing arbitrary value s that fill the me mory buffe r of an application, giving the attacke r an inte ractive command prompt from which the y may e xe cute arbitrary commands ) can give comple te adminis trative control to an attacke r. Adminis trators s hould make s ure that s e rvice s do not run as the root us e r, and s hould s tay vigilant of patche s and e rrata update s for applications from ve ndors or s e curity organiz ations s uch as CERT and CVE.

15

Se c ur it y Guide

Explo it

Descript io n

No t es

Application Vulne rabilitie s

Attacke rs find faults in de s ktop and works tation applications (s uch as e mail clie nts ) and e xe cute arbitrary code , implant Trojan hors e s for future compromis e , or cras h s ys te ms . Furthe r e xploitation can occur if the compromis e d works tation has adminis trative privile ge s on the re s t of the ne twork.

Works tations and de s ktops are more prone to e xploitation as worke rs do not have the e xpe rtis e or e xpe rie nce to pre ve nt or de te ct a compromis e ; it is impe rative to inform individuals of the ris ks the y are taking whe n the y ins tall unauthoriz e d s oftware or ope n uns olicite d e mail attachme nts . Safe guards can be imple me nte d s uch that e mail clie nt s oftware doe s not automatically ope n or e xe cute attachme nts . Additionally, the automatic update of works tation s oftware us ing Re d Hat Ne twork; or othe r s ys te m manage me nt s e rvice s can alle viate the burde ns of multi-s e at s e curity de ployme nts .

De nial of Se rvice (DoS) Attacks

Attacke r or group of attacke rs coordinate agains t an organiz ation's ne twork or s e rve r re s ource s by s e nding unauthoriz e d packe ts to the targe t hos t (e ithe r s e rve r, route r, or works tation). This force s the re s ource to be come unavailable to le gitimate us e rs .

The mos t re porte d DoS cas e in the US occurre d in 2000. Se ve ral highly-trafficke d comme rcial and gove rnme nt s ite s we re re nde re d unavailable by a coordinate d ping flood attack us ing s e ve ral compromis e d s ys te ms with high bandwidth conne ctions acting as zombies, or re dire cte d broadcas t node s . Source packe ts are us ually forge d (as we ll as re broadcas t), making inve s tigation as to the true s ource of the attack difficult. Advance s in ingre s s filte ring (IETF rfc2267) us ing iptables and Ne twork Intrus ion De te ction Sys te ms s uch as snort as s is t adminis trators in tracking down and pre ve nting dis tribute d DoS attacks .

[1] http://www.sans.org/security-resources/m istakes.php

16

⁠C hapt e r 2. Se c ur it y T ips f o r Ins t allat io n

Chapt er 2. Securit y Tips for Inst allat ion Se curity be gins with the firs t time you put that CD or DVD into your dis k drive to ins tall Re d Hat Ente rpris e Linux 7. Configuring your s ys te m s e cure ly from the be ginning make s it e as ie r to imple me nt additional s e curity s e ttings late r.

2.1. Securing BIOS Pas s word prote ction for the BIOS (or BIOS e quivale nt) and the boot loade r can pre ve nt unauthoriz e d us e rs who have phys ical acce s s to s ys te ms from booting us ing re movable me dia or obtaining root privile ge s through s ingle us e r mode . The s e curity me as ure s you s hould take to prote ct agains t s uch attacks de pe nds both on the s e ns itivity of the information on the works tation and the location of the machine . For e xample , if a machine is us e d in a trade s how and contains no s e ns itive information, the n it may not be critical to pre ve nt s uch attacks . Howe ve r, if an e mploye e 's laptop with private , une ncrypte d SSH ke ys for the corporate ne twork is le ft unatte nde d at that s ame trade s how, it could le ad to a major s e curity bre ach with ramifications for the e ntire company. If the works tation is locate d in a place whe re only authoriz e d or trus te d pe ople have acce s s , howe ve r, the n s e curing the BIOS or the boot loade r may not be ne ce s s ary.

2.1.1. BIOS Passwords The two primary re as ons for pas s word prote cting the BIOS of a compute r are ⁠ [2] : 1. Preventing Changes to BIOS Settings — If an intrude r has acce s s to the BIOS, the y can s e t it to boot from a CD-ROM or a flas h drive . This make s it pos s ible for the m to e nte r re s cue mode or s ingle us e r mode , which in turn allows the m to s tart arbitrary proce s s e s on the s ys te m or copy s e ns itive data. 2. Preventing System Booting — Some BIOSe s allow pas s word prote ction of the boot proce s s . Whe n activate d, an attacke r is force d to e nte r a pas s word be fore the BIOS launche s the boot loade r. Be caus e the me thods for s e tting a BIOS pas s word vary be twe e n compute r manufacture rs , cons ult the compute r's manual for s pe cific ins tructions . If you forge t the BIOS pas s word, it can e ithe r be re s e t with jumpe rs on the mothe rboard or by dis conne cting the CMOS batte ry. For this re as on, it is good practice to lock the compute r cas e if pos s ible . Howe ve r, cons ult the manual for the compute r or mothe rboard be fore atte mpting to dis conne ct the CMOS batte ry.

2.1.1.1. Securing Non-BIOS-based Syst ems Othe r s ys te ms and archite cture s us e diffe re nt programs to pe rform low-le ve l tas ks roughly e quivale nt to thos e of the BIOS on x86 s ys te ms . For e xample , the Unified Extensible Firmware Interface (UEFI) s he ll. For ins tructions on pas s word prote cting BIOS-like programs , s e e the manufacture r's ins tructions .

2.2. Part it ioning t he Disk 17

Se c ur it y Guide

Re d Hat re comme nds cre ating s e parate partitions for the /boot, /, /home/tmp, and /var/tmp/ dire ctorie s . The re as ons for e ach are diffe re nt, and we will addre s s e ach partition. /boot This partition is the firs t partition that is re ad by the s ys te m during boot up. The boot loade r and ke rne l image s that are us e d to boot your s ys te m into Re d Hat Ente rpris e Linux 7 are s tore d in this partition. This partition s hould not be e ncrypte d. If this partition is include d in / and that partition is e ncrypte d or othe rwis e be come s unavailable the n your s ys te m will not be able to boot. /home Whe n us e r data (/home) is s tore d in / ins te ad of in a s e parate partition, the partition can fill up caus ing the ope rating s ys te m to be come uns table . Als o, whe n upgrading your s ys te m to the ne xt ve rs ion of Re d Hat Ente rpris e Linux 7 it is a lot e as ie r whe n you can ke e p your data in the /home partition as it will not be ove rwritte n during ins tallation. If the root partition (/) be come s corrupt your data could be los t fore ve r. By us ing a s e parate partition the re is s lightly more prote ction agains t data los s . You can als o targe t this partition for fre que nt backups . /tmp and /var/tmp/ Both the /tmp and /var/tmp/ dire ctorie s are us e d to s tore data that doe s not ne e d to be s tore d for a long pe riod of time . Howe ve r, if a lot of data floods one of the s e dire ctorie s it can cons ume all of your s torage s pace . If this happe ns and the s e dire ctorie s are s tore d within / the n your s ys te m could be come uns table and cras h. For this re as on, moving the s e dire ctorie s into the ir own partitions is a good ide a.

No te During the ins tallation proce s s , an option to e ncrypt partitions is pre s e nte d to you. The us e r mus t s upply a pas s phras e . This pas s phras e will be us e d as a ke y to unlock the bulk e ncryption ke y, which is us e d to s e cure the partition's data. For more information on LUKS, s e e Se ction 4.9.1, “Us ing LUKS Dis k Encryption”.

2.3. Inst alling t he Minimum Amount of Packages Required It is be s t practice to ins tall only the package s you will us e be caus e e ach pie ce of s oftware on your compute r could pos s ibly contain a vulne rability. If you are ins talling from the DVD me dia, take the opportunity to s e le ct e xactly what package s you want to ins tall during the ins tallation. If you find you ne e d anothe r package , you can always add it to the s ys te m late r. For more information about ins talling the Minimal install e nvironme nt, s e e the Software Se le ction chapte r of the Re d Hat Ente rpris e Linux 7 Ins tallation Guide . A minimal ins tallation can als o be pe rforme d by a Kicks tart file us ing the --nobase option. For more information about Kicks tart ins tallations , s e e the Package Se le ction s e ction from the Re d Hat Ente rpris e Linux 7 Ins tallation Guide .

18

⁠C hapt e r 2. Se c ur it y T ips f o r Ins t allat io n

2.4. Rest rict ing Net work Connect ivit y During t he Inst allat ion Process Whe n ins talling Re d Hat Ente rpris e Linux, the ins tallation me dium re pre s e nts a s naps hot of the s ys te m at a particular time . Be caus e of this , it may not be up-to-date with the late s t s e curity fixe s and may be vulne rable to ce rtain is s ue s that we re fixe d only afte r the s ys te m provide d by the ins tallation me dium was re le as e d. Whe n ins talling a pote ntially vulne rable ope rating s ys te m, always limit e xpos ure only to the clos e s t ne ce s s ary ne twork z one . The s afe s t choice is the “no ne twork” z one , which me ans to le ave your machine dis conne cte d during the ins tallation proce s s . In s ome cas e s , a LAN or intrane t conne ction is s ufficie nt while the Inte rne t conne ction is the ris kie s t. To follow the be s t s e curity practice s , choos e the clos e s t z one with your re pos itory while ins talling Re d Hat Ente rpris e Linux from a ne twork. For more information about configuring ne twork conne ctivity, s e e the Ne twork & Hos tname chapte r of the Re d Hat Ente rpris e Linux 7 Ins tallation Guide .

2.5. Post -inst allat ion Procedures The following s te ps are the s e curity-re late d proce dure s that s hould be pe rforme d imme diate ly afte r ins tallation of Re d Hat Ente rpris e Linux. 1. Update your s ys te m. e nte r the following command as root: ~]# yum update 2. Eve n though the fire wall s e rvice , firewalld, is automatically e nable d with the ins tallation of Re d Hat Ente rpris e Linux, the re are s ce narios whe re it might be e xplicitly dis able d, for e xample in the kicks tart configuration. In s uch a cas e , it is re comme nde d to cons ide r re -e nabling the fire wall. To s tart firewalld e nte r the following commands as root: ~]# systemctl start firewalld ~]# systemctl enable firewalld 3. To e nhance s e curity, dis able s e rvice s you do not ne e d. For e xample , if the re are no printe rs ins talle d on your compute r, dis able the cups s e rvice us ing the following command: ~]# systemctl disable cups To re vie w active s e rvice s , e nte r the following command: ~]$ systemctl list-units | grep service

2.6. Addit ional Resources For more information about ins tallation in ge ne ral, s e e the Re d Hat Ente rpris e Linux 7 Ins tallation Guide .

19

Se c ur it y Guide

[2] Since system BIO Ses differ between m anufacturers, som e m ay not support password protection of either type, while others m ay support one type but not the other.

20

⁠C hapt e r 3. Ke e ping Yo ur Sys t e m Up-t o -Dat e

Chapt er 3. Keeping Your Syst em Up-t o-Dat e This chapte r de s cribe s the proce s s of ke e ping your s ys te m up-to-date , which involve s planning and configuring the way s e curity update s are ins talle d, applying change s introduce d by ne wly update d package s , and us ing the Re d Hat Cus tome r Portal for ke e ping track of s e curity advis orie s .

3.1. Maint aining Inst alled Soft ware As s e curity vulne rabilitie s are dis cove re d, the affe cte d s oftware mus t be update d in orde r to limit any pote ntial s e curity ris ks . If the s oftware is a part of a package within a Re d Hat Ente rpris e Linux dis tribution that is curre ntly s upporte d, Re d Hat is committe d to re le as ing update d package s that fix the vulne rabilitie s as s oon as pos s ible . Ofte n, announce me nts about a give n s e curity e xploit are accompanie d with a patch (or s ource code ) that fixe s the proble m. This patch is the n applie d to the Re d Hat Ente rpris e Linux package and te s te d and re le as e d as an e rratum update . Howe ve r, if an announce me nt doe s not include a patch, Re d Hat de ve lope rs firs t work with the maintaine r of the s oftware to fix the proble m. Once the proble m is fixe d, the package is te s te d and re le as e d as an e rratum update . If an e rratum update is re le as e d for s oftware us e d on your s ys te m, it is highly re comme nde d that you update the affe cte d package s as s oon as pos s ible to minimiz e the amount of time the s ys te m is pote ntially vulne rable .

3.1.1. Planning and Conf iguring Securit y Updat es All s oftware contains bugs . Ofte n, the s e bugs can re s ult in a vulne rability that can e xpos e your s ys te m to malicious us e rs . Package s that have not be e n update d are a common caus e of compute r intrus ions . Imple me nt a plan for ins talling s e curity patche s in a time ly manne r to quickly e liminate dis cove re d vulne rabilitie s , s o the y cannot be e xploite d. Te s t s e curity update s whe n the y be come available and s che dule the m for ins tallation. Additional controls ne e d to be us e d to prote ct the s ys te m during the time be twe e n the re le as e of the update and its ins tallation on the s ys te m. The s e controls de pe nd on the e xact vulne rability, but may include additional fire wall rule s , the us e of e xte rnal fire walls , or change s in s oftware s e ttings . Bugs in s upporte d package s are fixe d us ing the e rrata me chanis m. An e rratum cons is ts of one or more RPM package s accompanie d by a brie f e xplanation of the proble m that the particular e rratum de als with. All e rrata are dis tribute d to cus tome rs with active s ubs criptions through the Red Hat Subscript io n Management s e rvice . Errata that addre s s s e curity is s ue s are calle d Red Hat Security Advisories. For more information on working with s e curity e rrata, s e e Se ction 3.2.1, “Vie wing Se curity Advis orie s on the Cus tome r Portal”. For de taile d information about the Red Hat Subscript io n Management s e rvice , including ins tructions on how to migrate from RHN Classic, s e e the docume ntation re late d to this s e rvice : Re d Hat Subs cription Manage me nt.

3.1.1.1. Using t he Securit y Feat ures of Yum The Yum package manage r include s s e ve ral s e curity-re late d fe ature s that can be us e d to s e arch, lis t, dis play, and ins tall s e curity e rrata. The s e fe ature s als o make it pos s ible to us e Yum to ins tall nothing but s e curity update s .

21

Se c ur it y Guide

To che ck for s e curity-re late d update s available for your s ys te m, e nte r the following command as root: ~]# yum check-update --security Loaded plugins: langpacks, product-id, subscription-manager rhel-7-workstation-rpms/x86_64 | 3.4 kB 00:00:00 No packages needed for security; 0 packages available Note that the above command runs in a non-inte ractive mode , s o it can be us e d in s cripts for automate d che cking whe the r the re are any update s available . The command re turns an e xit value of 100 whe n the re are any s e curity update s available and 0 whe n the re are not. On e ncounte ring an e rror, it re turns 1. Analogous ly, us e the following command to only ins tall s e curity-re late d update s : ~]# yum update --security Us e the updateinfo s ubcommand to dis play or act upon information provide d by re pos itorie s about available update s . The updateinfo s ubcommand its e lf acce pts a numbe r of commands , s ome of which pe rtain to s e curity-re late d us e s . Se e Table 3.1, “Se curity-re late d commands us able with yum update info” for an ove rvie w of the s e commands . T able 3.1. Securit y-relat ed co mmands usable wit h yum updat einf o Co mmand

Descript io n

advisory [advisories]

Dis plays information about one or more advis orie s . Re place advisories with an advis ory numbe r or numbe rs . cves Dis plays the s ubs e t of information that pe rtains to CVE (Common Vulnerabilities and Exposures). security or sec Dis plays all s e curity-re late d information. severity [severity_level] Dis plays information about s e curity-re le vant package s or sev [severity_level] of the s upplie d severity_level.

3.1.2. Updat ing and Inst alling Packages Whe n updating s oftware on a s ys te m, it is important to download the update from a trus te d s ource . An attacke r can e as ily re build a package with the s ame ve rs ion numbe r as the one that is s uppos e d to fix the proble m but with a diffe re nt s e curity e xploit and re le as e it on the Inte rne t. If this happe ns , us ing s e curity me as ure s , s uch as ve rifying file s agains t the original RPM, doe s not de te ct the e xploit. Thus , it is ve ry important to only download RPMs from trus te d s ource s , s uch as from Re d Hat, and to che ck the package s ignature s to ve rify the ir inte grity. Se e the Yum chapte r of the Re d Hat Ente rpris e Linux 7 Sys te m Adminis trator's Guide for de taile d information on how to us e the Yum package manage r.

3.1.2.1. Verif ying Signed Packages All Re d Hat Ente rpris e Linux package s are s igne d with the Re d Hat GPG ke y. GPG s tands for GNU Privacy Guard, or GnuPG, a fre e s oftware package us e d for e ns uring the authe nticity of dis tribute d file s . If the ve rification of a package s ignature fails , the package may be alte re d and the re fore cannot be trus te d.

22

⁠C hapt e r 3. Ke e ping Yo ur Sys t e m Up-t o -Dat e

The Yum package manage r allows for an automatic ve rification of all package s it ins talls or upgrade s . This fe ature is e nable d by de fault. To configure this option on your s ys te m, make s ure the gpgcheck configuration dire ctive is s e t to 1 in the /etc/yum.conf configuration file . Us e the following command to manually ve rify package file s on your file s ys te m: rpmkeys --checksig package_file.rpm Se e the Product Signing (GPG) Ke ys article on the Re d Hat Cus tome r Portal for additional information about Re d Hat package -s igning practice s .

3.1.2.2. Inst alling Signed Packages To ins tall ve rifie d package s (s e e Se ction 3.1.2.1, “Ve rifying Signe d Package s ” for information on how to ve rify package s ) from your file s ys te m, us e the yum install command as the root us e r as follows : yum install package_file.rpm Us e a s he ll glob to ins tall s e ve ral package s at once . For e xample , the following commands ins talls all .rpm package s in the curre nt dire ctory: yum install *.rpm

Impo rtant Be fore ins talling any s e curity e rrata, be s ure to re ad any s pe cial ins tructions containe d in the e rratum re port and e xe cute the m accordingly. Se e Se ction 3.1.3, “Applying Change s Introduce d by Ins talle d Update s ” for ge ne ral ins tructions about applying change s made by e rrata update s .

3.1.3. Applying Changes Int roduced by Inst alled Updat es Afte r downloading and ins talling s e curity e rrata and update s , it is important to halt the us age of the old s oftware and be gin us ing the ne w s oftware . How this is done de pe nds on the type of s oftware that has be e n update d. The following lis t ite miz e s the ge ne ral cate gorie s of s oftware and provide s ins tructions for us ing update d ve rs ions afte r a package upgrade .

No te In ge ne ral, re booting the s ys te m is the s ure s t way to e ns ure that the late s t ve rs ion of a s oftware package is us e d; howe ve r, this option is not always re quire d, nor is it always available to the s ys te m adminis trator. Applicat io ns

23

Se c ur it y Guide

Us e r-s pace applications are any programs that can be initiate d by the us e r. Typically, s uch applications are us e d only whe n the us e r, a s cript, or an automate d tas k utility launch the m. Once s uch a us e r-s pace application is update d, halt any ins tance s of the application on the s ys te m, and launch the program again to us e the update d ve rs ion. Kernel The ke rne l is the core s oftware compone nt for the Re d Hat Ente rpris e Linux 7 ope rating s ys te m. It manage s acce s s to me mory, the proce s s or, and pe riphe rals , and it s che dule s all tas ks . Be caus e of its ce ntral role , the ke rne l cannot be re s tarte d without als o re booting the compute r. The re fore , an update d ve rs ion of the ke rne l cannot be us e d until the s ys te m is re boote d. KVM Whe n the qemu-kvm and libvirt package s are update d, it is ne ce s s ary to s top all gue s t virtual machine s , re load re le vant virtualiz ation module s (or re boot the hos t s ys te m), and re s tart the virtual machine s . Us e the lsmod command to de te rmine which module s from the following are loade d: kvm, kvm-intel, or kvm-amd. The n us e the modprobe -r command to re move and s ubs e que ntly the modprobe -a command to re load the affe cte d module s . Fox e xample : ~]# lsmod | grep kvm kvm_intel 143031 0 kvm 460181 1 kvm_intel ~]# modprobe -r kvm-intel ~]# modprobe -r kvm ~]# modprobe -a kvm kvm-intel Shared Libraries Share d librarie s are units of code , s uch as glibc, that are us e d by a numbe r of applications and s e rvice s . Applications utiliz ing a s hare d library typically load the s hare d code whe n the application is initializ e d, s o any applications us ing an update d library mus t be halte d and re launche d. To de te rmine which running applications link agains t a particular library, us e the lsof command: lsof library For e xample , to de te rmine which running applications link agains t the libwrap.so.0 library, type : ~]# lsof /lib64/libwrap.so.0 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pulseaudi 12363 test mem REG 253,0 42520 34121785 /usr/lib64/libwrap.so.0.7.6

24

⁠C hapt e r 3. Ke e ping Yo ur Sys t e m Up-t o -Dat e

gnome-set 12365 test mem REG /usr/lib64/libwrap.so.0.7.6 gnome-she 12454 test mem REG /usr/lib64/libwrap.so.0.7.6

253,0

42520 34121785

253,0

42520 34121785

This command re turns a lis t of all the running programs that us e TCP wrappe rs for hos t-acce s s control. The re fore , any program lis te d mus t be halte d and re launche d whe n the tcp_wrappers package is update d. syst emd Services s ys te md s e rvice s are pe rs is te nt s e rve r programs us ually launche d during the boot proce s s . Example s of s ys te md s e rvice s include sshd or vsftpd. Be caus e the s e programs us ually pe rs is t in me mory as long as a machine is running, e ach update d s ys te md s e rvice mus t be halte d and re launche d afte r its package is upgrade d. This can be done as the root us e r us ing the systemctl command: systemctl restart service_name Re place service_name with the name of the s e rvice you want to re s tart, s uch as sshd. Ot her So f t ware Follow the ins tructions outline d by the re s ource s linke d be low to corre ctly update the following applications . Red Hat Direct o ry Server — Se e the Release Notes for the ve rs ion of the Re d Hat Dire ctory Se rve r in que s tion at https ://acce s s .re dhat.com/s ite /docume ntation/e nUS/Re d_Hat_Dire ctory_Se rve r/. Red Hat Ent erprise Virt ualizat io n Manager — Se e the Installation Guide for the ve rs ion of the Re d Hat Ente rpris e Virtualiz ation in que s tion at https ://acce s s .re dhat.com/s ite /docume ntation/e nUS/Re d_Hat_Ente rpris e _Virtualiz ation/.

3.2. Using t he Red Hat Cust omer Port al The Re d Hat Cus tome r Portal at https ://acce s s .re dhat.com/ is the main cus tome r-orie nte d re s ource for official information re late d to Re d Hat products . You can us e it to find docume ntation, manage your s ubs criptions , download products and update s , ope n s upport cas e s , and le arn about s e curity update s .

3.2.1. Viewing Securit y Advisories on t he Cust omer Port al To vie w s e curity advis orie s (e rrata) re le vant to the s ys te ms for which you have active s ubs criptions , log into the Cus tome r Portal at https ://acce s s .re dhat.com/ and click on the Download Products & Updates button on the main page . Whe n you e nte r the Software & Download Center page , continue by clicking on the Errata button to s e e a lis t of advis orie s pe rtine nt to your re gis te re d s ys te ms . To brows e a lis t of all s e curity update s for all active Re d Hat products , go to Securit y → Securit y Updat es → Act ive Pro duct s us ing the navigation me nu at the top of the page .

25

Se c ur it y Guide

Click on the e rratum code in the le ft part of the table to dis play more de taile d information about the individual advis orie s . The ne xt page contains not only a de s cription of the give n e rratum, including its caus e s , cons e que nce s , and re quire d fixe s , but als o a lis t of all package s that the particular e rratum update s along with ins tructions on how to apply the update s . The page als o include s links to re le vant re fe re nce s , s uch as re late d CVE.

3.2.2. Navigat ing CVE Cust omer Port al Pages The CVE (Common Vulnerabilities and Exposures) proje ct, maintaine d by The MITRE Corporation, is a lis t of s tandardiz e d name s for vulne rabilitie s and s e curity e xpos ure s . To brows e a lis t of CVE that pe rtain to Re d Hat products on the Cus tome r Portal, log into your account at https ://acce s s .re dhat.com/ and navigate to Securit y → Reso urces → CVE Dat abase us ing the navigation me nu at the top of the page . Click on the CVE code in the le ft part of the table to dis play more de taile d information about the individual vulne rabilitie s . The ne xt page contains not only a de s cription of the give n CVE but als o a lis t of affe cte d Re d Hat products along with links to re le vant Re d Hat e rrata.

3.2.3. Underst anding Issue Severit y Classif icat ion All s e curity is s ue s dis cove re d in Re d Hat products are as s igne d an impact rating by Red Hat Product Security according to the s e ve rity of the proble m. The four-point s cale cons is ts of the following le ve ls : Low, Mode rate , Important, and Critical. In addition to that, e ve ry s e curity is s ue is rate d us ing the Common Vulnerability Scoring System (CVSS) bas e s core s . Toge the r, the s e ratings he lp you unde rs tand the impact of s e curity is s ue s , allowing you to s che dule and prioritiz e upgrade s trate gie s for your s ys te ms . Note that the ratings re fle ct the pote ntial ris k of a give n vulne rability, which is bas e d on a te chnical analys is of the bug, not the curre nt thre at le ve l. This me ans that the s e curity impact rating doe s not change if an e xploit is re le as e d for a particular flaw. To s e e a de taile d de s cription of the individual le ve ls of s e ve rity ratings on the Cus tome r Portal, vis it the Se ve rity Ratings page .

3.3. Addit ional Resources For more information about s e curity update s , ways of applying the m, the Re d Hat Cus tome r Portal, and re late d topics , s e e the re s ource s lis te d be low.

Inst alled Document at ion yum(8) — The manual page for the Yum package manage r provide s information about the way Yum can be us e d to ins tall, update , and re move package s on your s ys te ms . rpmke ys (8) — The manual page for the rpmkeys utility de s cribe s the way this program can be us e d to ve rify the authe nticity of downloade d package s .

Online Document at ion

26

⁠C hapt e r 3. Ke e ping Yo ur Sys t e m Up-t o -Dat e

Re d Hat Ente rpris e Linux 7 Sys te m Adminis trator's Guide — The System Administrator's Guide for Re d Hat Ente rpris e Linux 7 docume nts the us e of the Yum and rpm commands that are us e d to ins tall, update , and re move package s on Re d Hat Ente rpris e Linux 7 s ys te ms . Re d Hat Ente rpris e Linux 7 SELinux Us e r's and Adminis trator's Guide — The SELinux User's and Administrator's Guide for Re d Hat Ente rpris e Linux 7 docume nts the configuration of the SELinux mandatory access control me chanis m.

Red Hat Cust omer Port al Re d Hat Cus tome r Portal, Se curity — The Se curity s e ction of the Cus tome r Portal contains links to the mos t important re s ource s , including the Re d Hat CVE databas e , and contacts for Re d Hat Product Se curity. Re d Hat Se curity Blog — Article s about late s t s e curity-re late d is s ue s from Re d Hat s e curity profe s s ionals .

See Also Chapte r 2, Security Tips for Installation de s cribe s how to configure your s ys te m s e cure ly from the be ginning to make it e as ie r to imple me nt additional s e curity s e ttings late r. Se ction 4.9.2, “Cre ating GPG Ke ys ” de s cribe s how to cre ate a s e t of pe rs onal GPG ke ys to authe nticate your communications .

27

Se c ur it y Guide

Chapt er 4. Hardening Your Syst em wit h Tools and Services 4.1. Deskt op Securit y Re d Hat Ente rpris e Linux 7 offe rs s e ve ral ways for harde ning the de s ktop agains t attacks and pre ve nting unauthoriz e d acce s s e s . This s e ction de s cribe s re comme nde d practice s for us e r pas s words , s e s s ion and account locking, and s afe handling of re movable me dia.

4.1.1. Password Securit y Pas s words are the primary me thod that Re d Hat Ente rpris e Linux 7 us e s to ve rify a us e r's ide ntity. This is why pas s word s e curity is s o important for prote ction of the us e r, the works tation, and the ne twork. For s e curity purpos e s , the ins tallation program configure s the s ys te m to us e Secure Hash Algorithm 512 (SHA512) and s hadow pas s words . It is highly re comme nde d that you do not alte r the s e s e ttings . If s hadow pas s words are de s e le cte d during ins tallation, all pas s words are s tore d as a one -way has h in the world-re adable /etc/passwd file , which make s the s ys te m vulne rable to offline pas s word cracking attacks . If an intrude r can gain acce s s to the machine as a re gular us e r, he can copy the /etc/passwd file to his own machine and run any numbe r of pas s word cracking programs agains t it. If the re is an ins e cure pas s word in the file , it is only a matte r of time be fore the pas s word cracke r dis cove rs it. Shadow pas s words e liminate this type of attack by s toring the pas s word has he s in the file /etc/shadow, which is re adable only by the root us e r. This force s a pote ntial attacke r to atte mpt pas s word cracking re mote ly by logging into a ne twork s e rvice on the machine , s uch as SSH or FTP. This s ort of brute -force attack is much s lowe r and le ave s an obvious trail as hundre ds of faile d login atte mpts are writte n to s ys te m file s . Of cours e , if the cracke r s tarts an attack in the middle of the night on a s ys te m with we ak pas s words , the cracke r may have gaine d acce s s be fore dawn and e dite d the log file s to cove r his tracks . In addition to format and s torage cons ide rations is the is s ue of conte nt. The s ingle mos t important thing a us e r can do to prote ct his account agains t a pas s word cracking attack is cre ate a s trong pas s word.

No te Re d Hat re comme nds us ing a ce ntral authe ntication s olution, s uch as Re d Hat Ide ntity Manage me nt (IdM). Us ing a ce ntral s olution is pre fe rre d ove r us ing local pas s words . For de tails , s e e : Introduction to Re d Hat Ide ntity Manage me nt De fining Pas s word Policie s

4.1.1.1. Creat ing St rong Passwords Whe n cre ating a s e cure pas s word, the us e r mus t re me mbe r that long pas s words are

28

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

s tronge r than s hort and comple x one s . It is not a good ide a to cre ate a pas s word of jus t e ight characte rs , e ve n if it contains digits , s pe cial characte rs and uppe rcas e le tte rs . Pas s word cracking tools , s uch as John The Rippe r, are optimiz e d for bre aking s uch pas s words , which are als o hard to re me mbe r by a pe rs on. In information the ory, e ntropy is the le ve l of unce rtainty as s ociate d with a random variable and is pre s e nte d in bits . The highe r the e ntropy value , the more s e cure the pas s word is . According to NIST SP 800-63-1, pas s words that are not pre s e nt in a dictionary compris e d of 50000 commonly s e le cte d pas s words s hould have at le as t 10 bits of e ntropy. As s uch, a pas s word that cons is ts of four random words contains around 40 bits of e ntropy. A long pas s word cons is ting of multiple words for adde d s e curity is als o calle d a passphrase, for e xample : randomword1 randomword2 randomword3 randomword4 If the s ys te m e nforce s the us e of uppe rcas e le tte rs , digits , or s pe cial characte rs , the pas s phras e that follows the above re comme ndation can be modifie d in a s imple way, for e xample by changing the firs t characte r to uppe rcas e and appe nding "1!". Note that s uch a modification does not incre as e the s e curity of the pas s phras e s ignificantly. Anothe r way to cre ate a pas s word yours e lf is us ing a pas s word ge ne rator. The pwmake is a command-line tool for ge ne rating random pas s words that cons is t of all four groups of characte rs – uppe rcas e , lowe rcas e , digits and s pe cial characte rs . The utility allows you to s pe cify the numbe r of e ntropy bits that are us e d to ge ne rate the pas s word. The e ntropy is pulle d from /dev/urandom. The minimum numbe r of bits you can s pe cify is 56, which is e nough for pas s words on s ys te ms and s e rvice s whe re brute force attacks are rare . 64 bits is ade quate for applications whe re the attacke r doe s not have dire ct acce s s to the pas s word has h file . For s ituations whe n the attacke r might obtain the dire ct acce s s to the pas s word has h or the pas s word is us e d as an e ncryption ke y, 80 to 128 bits s hould be us e d. If you s pe cify an invalid numbe r of e ntropy bits , pwmake will us e the de fault of bits . To cre ate a pas s word of 128 bits , e nte r the following command: pwmake 128 While the re are diffe re nt approache s to cre ating a s e cure pas s word, always avoid the following bad practice s : Us ing a s ingle dictionary word, a word in a fore ign language , an inve rte d word, or only numbe rs . Us ing le s s than 10 characte rs for a pas s word or pas s phras e . Us ing a s e que nce of ke ys from the ke yboard layout. Writing down your pas s words . Us ing pe rs onal information in a pas s word, s uch as birth date s , annive rs arie s , family me mbe r name s , or pe t name s . Us ing the s ame pas s phras e or pas s word on multiple machine s . While cre ating s e cure pas s words is impe rative , managing the m prope rly is als o important, e s pe cially for s ys te m adminis trators within large r organiz ations . The following s e ction de tails good practice s for cre ating and managing us e r pas s words within an organiz ation.

4.1.1.2. Forcing St rong Passwords

29

Se c ur it y Guide

If an organiz ation has a large numbe r of us e rs , the s ys te m adminis trators have two bas ic options available to force the us e of s trong pas s words . The y can cre ate pas s words for the us e r, or the y can le t us e rs cre ate the ir own pas s words while ve rifying the pas s words are of ade quate s tre ngth. Cre ating the pas s words for the us e rs e ns ure s that the pas s words are good, but it be come s a daunting tas k as the organiz ation grows . It als o incre as e s the ris k of us e rs writing the ir pas s words down, thus e xpos ing the m. For the s e re as ons , mos t s ys te m adminis trators pre fe r to have the us e rs cre ate the ir own pas s words , but active ly ve rify that the s e pas s words are s trong e nough. In s ome cas e s , adminis trators may force us e rs to change the ir pas s words pe riodically through pas s word aging. Whe n us e rs are as ke d to cre ate or change pas s words , the y can us e the passwd command-line utility, which is PAM-aware (Pluggable Authentication Modules) and che cks to s e e if the pas s word is too s hort or othe rwis e e as y to crack. This che cking is pe rforme d by the pam_pwquality.so PAM module .

No te In Re d Hat Ente rpris e Linux 7, the pam_pwquality PAM module re place d pam_cracklib, which was us e d in Re d Hat Ente rpris e Linux 6 as a de fault module for pas s word quality che cking. It us e s the s ame back e nd as pam_cracklib. The pam_pwquality module is us e d to che ck a pas s word's s tre ngth agains t a s e t of rule s . Its proce dure cons is ts of two s te ps : firs t it che cks if the provide d pas s word is found in a dictionary. If not, it continue s with a numbe r of additional che cks . pam_pwquality is s tacke d alongs ide othe r PAM module s in the password compone nt of the /etc/pam.d/passwd file , and the cus tom s e t of rule s is s pe cifie d in the /etc/security/pwquality.conf configuration file . For a comple te lis t of the s e che cks , s e e the pwquality.conf (8) manual page .

Example 4.1. Co nf iguring passwo rd st rengt h-checking in pwquality.conf To e nable us ing pam_quality, add the following line to the password s tack in the /etc/pam.d/passwd file : password

required

pam_pwquality.so retry=3

Options for the che cks are s pe cifie d one pe r line . For e xample , to re quire a pas s word with a minimum le ngth of 8 characte rs , including all four clas s e s of characte rs , add the following line s to the /etc/security/pwquality.conf file : minlen = 8 minclass = 4 To s e t a pas s word s tre ngth-che ck for characte r s e que nce s and s ame cons e cutive characte rs , add the following line s to /etc/security/pwquality.conf: maxsequence = 3 maxrepeat = 3

30

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

In this e xample , the pas s word e nte re d cannot contain more than 3 characte rs in a monotonic s e que nce , s uch as abcd, and more than 3 ide ntical cons e cutive characte rs , s uch as 1111.

No te As the root us e r is the one who e nforce s the rule s for pas s word cre ation, the y can s e t any pas s word for the ms e lve s or for a re gular us e r, de s pite the warning me s s age s .

4.1.1.3. Conf iguring Password Aging Pas s word aging is anothe r te chnique us e d by s ys te m adminis trators to de fe nd agains t bad pas s words within an organiz ation. Pas s word aging me ans that afte r a s pe cifie d pe riod (us ually 90 days ), the us e r is prompte d to cre ate a ne w pas s word. The the ory be hind this is that if a us e r is force d to change his pas s word pe riodically, a cracke d pas s word is only us e ful to an intrude r for a limite d amount of time . The downs ide to pas s word aging, howe ve r, is that us e rs are more like ly to write the ir pas s words down. To s pe cify pas s word aging unde r Re d Hat Ente rpris e Linux 7, make us e of the chage command.

Impo rtant In Re d Hat Ente rpris e Linux 7, s hadow pas s words are e nable d by de fault. For more information, s e e the Re d Hat Ente rpris e Linux 7 Sys te m Adminis trator's Guide . The -M option of the chage command s pe cifie s the maximum numbe r of days the pas s word is valid. For e xample , to s e t a us e r's pas s word to e xpire in 90 days , us e the following command: chage -M 90 username In the above command, re place username with the name of the us e r. To dis able pas s word e xpiration, us e the value of -1 afte r the -M option. For more information on the options available with the chage command, s e e the table be low. T able 4.1. chage co mmand line o pt io ns Opt io n

Descript io n

-d days

Spe cifie s the numbe r of days s ince January 1, 1970 the pas s word was change d. Spe cifie s the date on which the account is locke d, in the format YYYY-MM-DD. Ins te ad of the date , the numbe r of days s ince January 1, 1970 can als o be us e d. Spe cifie s the numbe r of inactive days afte r the pas s word e xpiration be fore locking the account. If the value is 0, the account is not locke d afte r the pas s word e xpire s .

-E date

-I days

31

Se c ur it y Guide

Opt io n

Descript io n

-l -m days

Lis ts curre nt account aging s e ttings . Spe cify the minimum numbe r of days afte r which the us e r mus t change pas s words . If the value is 0, the pas s word doe s not e xpire . Spe cify the maximum numbe r of days for which the pas s word is valid. Whe n the numbe r of days s pe cifie d by this option plus the numbe r of days s pe cifie d with the -d option is le s s than the curre nt day, the us e r mus t change pas s words be fore us ing the account. Spe cifie s the numbe r of days be fore the pas s word e xpiration date to warn the us e r.

-M days

-W days

You can als o us e the chage command in inte ractive mode to modify multiple pas s word aging and account de tails . Us e the following command to e nte r inte ractive mode : chage The following is a s ample inte ractive s e s s ion us ing this command: ~]# chage juan Changing the aging information for juan Enter the new value, or press ENTER for the default Minimum Password Age [0]: 10 Maximum Password Age [99999]: 90 Last Password Change (YYYY-MM-DD) [2006-08-18]: Password Expiration Warning [7]: Password Inactive [-1]: Account Expiration Date (YYYY-MM-DD) [1969-12-31]: You can configure a pas s word to e xpire the firs t time a us e r logs in. This force s us e rs to change pas s words imme diate ly. 1. Se t up an initial pas s word. To as s ign a de fault pas s word, e nte r the following command at a s he ll prompt as root: passwd username

Warning The passwd utility has the option to s e t a null pas s word. Us ing a null pas s word, while conve nie nt, is a highly ins e cure practice , as any third party can log in and acce s s the s ys te m us ing the ins e cure us e r name . Avoid us ing null pas s words whe re ve r pos s ible . If it is not pos s ible , always make s ure that the us e r is re ady to log in be fore unlocking an account with a null pas s word. 2. Force imme diate pas s word e xpiration by running the following command as root: chage -d 0 username This command s e ts the value for the date the pas s word was las t change d to the e poch (January 1, 1970). This value force s imme diate pas s word e xpiration no

32

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

matte r what pas s word aging policy, if any, is in place . Upon the initial log in, the us e r is now prompte d for a ne w pas s word.

4.1.2. Account Locking In Re d Hat Ente rpris e Linux 7, the pam_faillock PAM module allows s ys te m adminis trators to lock out us e r accounts afte r a s pe cifie d numbe r of faile d atte mpts . Limiting us e r login atte mpts s e rve s mainly as a s e curity me as ure that aims to pre ve nt pos s ible brute force attacks targe te d to obtain a us e r's account pas s word. With the pam_faillock module , faile d login atte mpts are s tore d in a s e parate file for e ach us e r in the /var/run/faillock dire ctory.

No te The orde r of line s in the faile d atte mpt log file s is important. Any change in this orde r can lock all us e r accounts , including the root us e r account whe n the even_deny_root option is us e d. Follow the s e s te ps to configure account locking: 1. To lock out any non-root us e r afte r thre e uns ucce s s ful atte mpts and unlock that us e r afte r 10 minute s , add two line s to the auth s e ction of the /etc/pam.d/system-auth and /etc/pam.d/password-auth file s . Afte r your e dits , the e ntire auth s e ction in both file s s hould look like this : 1 auth required 2 auth required deny=3 unlock_time=600 3 auth sufficient 4 auth [default=die] unlock_time=600 5 auth requisite quiet_success 6 auth required

pam_env.so pam_faillock.so preauth silent audit pam_unix.so nullok try_first_pass pam_faillock.so authfail audit deny=3 pam_succeed_if.so uid >= 1000 pam_deny.so

Line s numbe r 2 and 4 have be e n adde d. 2. Add the following line to the account s e ction of both file s s pe cifie d in the pre vious s te p: account

required

pam_faillock.so

3. To apply account locking for the root us e r as we ll, add the even_deny_root option to the pam_faillock e ntrie s in the /etc/pam.d/system-auth and /etc/pam.d/password-auth file s : auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=600 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3

33

Se c ur it y Guide

even_deny_root unlock_time=600 account

required

pam_faillock.so

Whe n us e r john atte mpts to log in for the fourth time afte r failing to log in thre e time s pre vious ly, his account is locke d upon the fourth atte mpt: [yruseva@localhost ~]$ su - john Account locked due to 3 failed logins su: incorrect password To pre ve nt the s ys te m from locking us e rs out e ve n afte r multiple faile d logins , add the following line jus t above the line whe re pam_faillock is calle d for the firs t time in both /etc/pam.d/system-auth and /etc/pam.d/password-auth. Als o re place user1, user2, and user3 with the actual us e r name s . auth [success=1 default=ignore] pam_succeed_if.so user in user1:user2:user3 To vie w the numbe r of faile d atte mpts pe r us e r, run, as root, the following command: [root@localhost ~]# faillock john: When Type Source Valid 2013-03-05 11:44:14 TTY pts/0 V To unlock a us e r's account, run, as root, the following command: faillock --user --reset

Keeping Cust om Set t ings wit h aut hconf ig Whe n modifying authe ntication configuration us ing the aut hco nf ig utility, the systemauth and password-auth file s are ove rwritte n with the s e ttings from the aut hco nf ig utility. This can be avoide d by cre ating s ymbolic links in place of the configuration file s , which aut hco nf ig re cogniz e s and doe s not ove rwrite . In orde r to us e cus tom s e ttings in the configuration file s and aut hco nf ig s imultane ous ly, configure account locking us ing the following s te ps : 1. Che ck whe the r the system-auth and password-auth file s are alre ady s ymbolic links pointing to system-auth-ac and password-auth-ac (this is the s ys te m de fault): ~]# ls -l /etc/pam.d/{password,system}-auth If the output is s imilar to the following, the s ymbolic links are in place , and you can s kip to s te p numbe r 3:

34

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

lrwxrwxrwx. 1 root root 16 24. Feb 09.29 /etc/pam.d/password-auth -> password-auth-ac lrwxrwxrwx. 1 root root 28 24. Feb 09.29 /etc/pam.d/system-auth -> system-auth-ac If the system-auth and password-auth file s are not s ymbolic links , continue with the ne xt s te p. 2. Re name the configuration file s : ~]# mv /etc/pam.d/system-auth /etc/pam.d/system-auth-ac ~]# mv /etc/pam.d/password-auth /etc/pam.d/password-auth-ac 3. Cre ate configuration file s with your cus tom s e ttings : ~]# vi /etc/pam.d/system-auth-local The /etc/pam.d/system-auth-local file s hould contain the following line s : auth required deny=3 unlock_time=600 auth include auth [default=die] deny=3 unlock_time=600

pam_faillock.so preauth silent audit

account account

required include

pam_faillock.so system-auth-ac

password

include

system-auth-ac

session

include

system-auth-ac

system-auth-ac pam_faillock.so authfail silent audit

~]# vi /etc/pam.d/password-auth-local The /etc/pam.d/password-auth-local file s hould contain the following line s : auth required deny=3 unlock_time=600 auth include auth [default=die] deny=3 unlock_time=600

pam_faillock.so preauth silent audit

account account

required include

pam_faillock.so password-auth-ac

password

include

password-auth-ac

session

include

password-auth-ac

password-auth-ac pam_faillock.so authfail silent audit

4. Cre ate the following s ymbolic links : ~]# ln -sf /etc/pam.d/system-auth-local /etc/pam.d/system-auth ~]# ln -sf /etc/pam.d/password-auth-local /etc/pam.d/password-auth

35

Se c ur it y Guide

For more information on various pam_faillock configuration options , s e e the pam_faillock(8) manual page .

4.1.3. Session Locking Us e rs may ne e d to le ave the ir works tation unatte nde d for a numbe r of re as ons during e ve ryday ope ration. This could pre s e nt an opportunity for an attacke r to phys ically acce s s the machine , e s pe cially in e nvironme nts with ins ufficie nt phys ical s e curity me as ure s (s e e Se ction 1.2.1, “Phys ical Controls ”). Laptops are e s pe cially e xpos e d s ince the ir mobility inte rfe re s with phys ical s e curity. You can alle viate the s e ris ks by us ing s e s s ion locking fe ature s which pre ve nt acce s s to the s ys te m until a corre ct pas s word is e nte re d.

No te The main advantage of locking the s cre e n ins te ad of logging out is that a lock allows the us e r's proce s s e s (s uch as file trans fe rs ) to continue running. Logging out would s top the s e proce s s e s .

4.1.3.1. Locking Virt ual Consoles Using vlock Us e rs may als o ne e d to lock a virtual cons ole . This can be done us ing a utility calle d vlock. To ins tall this utility, e xe cute the following command as root: ~]# yum install vlock Afte r ins tallation, any cons ole s e s s ion can be locke d us ing the vlock command without any additional parame te rs . This locks the curre ntly active virtual cons ole s e s s ion while s till allowing acce s s to the othe rs . To pre ve nt acce s s to all virtual cons ole s on the works tation, e xe cute the following: vlock -a In this cas e , vlock locks the curre ntly active cons ole and the -a option pre ve nts s witching to othe r virtual cons ole s . Se e the vlock(1) man page for additional information.

4.1.4. Enf orcing Read-Only Mount ing of Removable Media To e nforce re ad-only mounting of re movable me dia (s uch as USB flas h dis ks ), the adminis trator can us e a udev rule to de te ct re movable me dia and configure the m to be mounte d re ad-only us ing the blo ckdev utility. This is s ufficie nt for e nforcing re ad-only mounting of phys ical me dia.

Using blockdev t o Force Read-Only Mount ing of Removable Media To force all re movable me dia to be mounte d re ad-only, cre ate a ne w udev configuration file name d, for e xample , 80-readonly-removables.rules in the /etc/udev/rules.d/ dire ctory with the following conte nt: SUBSYSTEM=="block",ATTRS{removable}=="1",RUN{program}="/sbin/blockdev -setro %N"

36

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

The above udev rule e ns ure s that any ne wly conne cte d re movable block (s torage ) de vice is automatically configure d as re ad-only us ing the blockdev utility.

Applying New udev Set t ings For the s e s e ttings to take e ffe ct, the ne w udev rule s ne e d to be applie d. The udev s e rvice automatically de te cts change s to its configuration file s , but ne w s e ttings are not applie d to alre ady e xis ting de vice s . Only ne wly conne cte d de vice s are affe cte d by the ne w s e ttings . The re fore , you ne e d to unmount and unplug all conne cte d re movable me dia to e ns ure that the ne w s e ttings are applie d to the m whe n the y are ne xt plugge d in. To force udev to re -apply all rule s to alre ady e xis ting de vice s , e nte r the following command as root: ~# udevadm trigger Note that forcing udev to re -apply all rule s us ing the above command doe s not affe ct any s torage de vice s that are alre ady mounte d. To force udev to re load all rule s (in cas e the ne w rule s are not automatically de te cte d for s ome re as on), us e the following command: ~# udevadm control --reload

4.2. Cont rolling Root Access Whe n adminis te ring a home machine , the us e r mus t pe rform s ome tas ks as the root us e r or by acquiring e ffe ctive root privile ge s us ing a setuid program, s uch as sudo or su. A s e tuid program is one that ope rate s with the us e r ID (UID) of the program's owne r rathe r than the us e r ope rating the program. Such programs are de note d by an s in the owne r s e ction of a long format lis ting, as in the following e xample : ~]$ ls -l /bin/su -rwsr-xr-x. 1 root root 34904 Mar 10

2011 /bin/su

No te The s may be uppe r cas e or lowe r cas e . If it appe ars as uppe r cas e , it me ans that the unde rlying pe rmis s ion bit has not be e n s e t. For the s ys te m adminis trator of an organiz ation, howe ve r, choice s mus t be made as to how much adminis trative acce s s us e rs within the organiz ation s hould have to the ir machine s . Through a PAM module calle d pam_console.so, s ome activitie s normally re s e rve d only for the root us e r, s uch as re booting and mounting re movable me dia, are allowe d for the firs t us e r that logs in at the phys ical cons ole . Howe ve r, othe r important s ys te m adminis tration tas ks , s uch as alte ring ne twork s e ttings , configuring a ne w mous e , or mounting ne twork de vice s , are not pos s ible without adminis trative privile ge s . As a re s ult, s ys te m adminis trators mus t de cide how much acce s s the us e rs on the ir ne twork s hould re ce ive .

37

Se c ur it y Guide

4.2.1. Disallowing Root Access If an adminis trator is uncomfortable allowing us e rs to log in as root for the s e or othe r re as ons , the root pas s word s hould be ke pt s e cre t, and acce s s to runle ve l one or s ingle us e r mode s hould be dis allowe d through boot loade r pas s word prote ction (s e e Se ction 4.2.5, “Se curing the Boot Loade r” for more information on this topic.) The following are four diffe re nt ways that an adminis trator can furthe r e ns ure that root logins are dis allowe d: Changing t he ro o t shell To pre ve nt us e rs from logging in dire ctly as root, the s ys te m adminis trator can s e t the root account's s he ll to /sbin/nologin in the /etc/passwd file . T able 4.2. Disabling t he Ro o t Shell Ef f ect s

Do es No t Af f ect

Pre ve nts acce s s to a root s he ll and logs any s uch atte mpts . The following programs are pre ve nte d from acce s s ing the root account:

Programs that do not re quire a s he ll, s uch as FTP clie nts , mail clie nts , and many s e tuid programs . The following programs are not pre ve nte d from acce s s ing the root account:

login gdm kdm xdm su ssh scp sftp

sudo FTP clie nts Email clie nts

Disabling ro o t access using any co nso le device (t t y) To furthe r limit acce s s to the root account, adminis trators can dis able root logins at the cons ole by e diting the /etc/securetty file . This file lis ts all de vice s the root us e r is allowe d to log into. If the file doe s not e xis t at all, the root us e r can log in through any communication de vice on the s ys te m, whe the r through the cons ole or a raw ne twork inte rface . This is dange rous , be caus e a us e r can log in to the ir machine as root us ing Te lne t, which trans mits the pas s word in plain te xt ove r the ne twork. By de fault, Re d Hat Ente rpris e Linux 7's /etc/securetty file only allows the root us e r to log in at the cons ole phys ically attache d to the machine . To pre ve nt the root us e r from logging in, re move the conte nts of this file by typing the following command at a s he ll prompt as root: echo > /etc/securetty To e nable securetty s upport in the KDM, GDM, and XDM login manage rs , add the following line : auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so to the file s lis te d be low:

38

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

/etc/pam.d/gdm /etc/pam.d/gdm-autologin /etc/pam.d/gdm-fingerprint /etc/pam.d/gdm-password /etc/pam.d/gdm-smartcard /etc/pam.d/kdm /etc/pam.d/kdm-np /etc/pam.d/xdm

Warning A blank /etc/securetty file doe s not pre ve nt the root us e r from logging in re mote ly us ing the Ope nSSH s uite of tools be caus e the cons ole is not ope ne d until afte r authe ntication.

T able 4.3. Disabling Ro o t Lo gins Ef f ect s

Do es No t Af f ect

Pre ve nts acce s s to the root account us ing the cons ole or the ne twork. The following programs are pre ve nte d from acce s s ing the root account:

Programs that do not log in as root, but pe rform adminis trative tas ks through s e tuid or othe r me chanis ms . The following programs are not pre ve nte d from acce s s ing the root account:

login gdm kdm xdm Othe r ne twork s e rvice s that ope n a tty

su sudo ssh scp sftp

Disabling ro o t SSH lo gins To pre ve nt root logins through the SSH protocol, e dit the SSH dae mon's configuration file , /etc/ssh/sshd_config, and change the line that re ads : #PermitRootLogin yes to re ad as follows : PermitRootLogin no T able 4.4. Disabling Ro o t SSH Lo gins

39

Se c ur it y Guide

Ef f ect s

Do es No t Af f ect

Pre ve nts root acce s s us ing the Ope nSSH s uite of tools . The following programs are pre ve nte d from acce s s ing the root account:

Programs that are not part of the Ope nSSH s uite of tools .

ssh scp sftp Using PAM t o limit ro o t access t o services PAM, through the /lib/security/pam_listfile.so module , allows gre at fle xibility in de nying s pe cific accounts . The adminis trator can us e this module to re fe re nce a lis t of us e rs who are not allowe d to log in. To limit root acce s s to a s ys te m s e rvice , e dit the file for the targe t s e rvice in the /etc/pam.d/ dire ctory and make s ure the pam_listfile.so module is re quire d for authe ntication. The following is an e xample of how the module is us e d for the vsftpd FTP s e rve r in the /etc/pam.d/vsftpd PAM configuration file (the \ characte r at the e nd of the firs t line is not ne ce s s ary if the dire ctive is on a s ingle line ): auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed This ins tructs PAM to cons ult the /etc/vsftpd.ftpusers file and de ny acce s s to the s e rvice for any lis te d us e r. The adminis trator can change the name of this file , and can ke e p s e parate lis ts for e ach s e rvice or us e one ce ntral lis t to de ny acce s s to multiple s e rvice s . If the adminis trator wants to de ny acce s s to multiple s e rvice s , a s imilar line can be adde d to the PAM configuration file s , s uch as /etc/pam.d/pop and /etc/pam.d/imap for mail clie nts , or /etc/pam.d/ssh for SSH clie nts . For more information about PAM, s e e The Linux-PAM System Administrator's Guide, locate d in the /usr/share/doc/pam-/html/ dire ctory. T able 4.5. Disabling Ro o t Using PAM Ef f ect s

Do es No t Af f ect

Pre ve nts root acce s s to ne twork s e rvice s that are PAM aware . The following s e rvice s are pre ve nte d from acce s s ing the root account:

Programs and s e rvice s that are not PAM aware .

login gdm kdm xdm ssh scp sftp FTP clie nts Email clie nts Any PAM aware s e rvice s

40

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

4.2.2. Allowing Root Access If the us e rs within an organiz ation are trus te d and compute r-lite rate , the n allowing the m root acce s s may not be an is s ue . Allowing root acce s s by us e rs me ans that minor activitie s , like adding de vice s or configuring ne twork inte rface s , can be handle d by the individual us e rs , le aving s ys te m adminis trators fre e to de al with ne twork s e curity and othe r important is s ue s . On the othe r hand, giving root acce s s to individual us e rs can le ad to the following is s ue s : Machine Misconfiguration — Us e rs with root acce s s can mis configure the ir machine s and re quire as s is tance to re s olve is s ue s . Eve n wors e , the y might ope n up s e curity hole s without knowing it. Running Insecure Services — Us e rs with root acce s s might run ins e cure s e rve rs on the ir machine , s uch as FTP or Te lne t, pote ntially putting us e rname s and pas s words at ris k. The s e s e rvice s trans mit this information ove r the ne twork in plain te xt. Running Email Attachments As Root — Although rare , e mail virus e s that affe ct Linux do e xis t. A malicious program pos e s the gre ate s t thre at whe n run by the root us e r. Keeping the audit trail intact — Be caus e the root account is ofte n s hare d by multiple us e rs , s o that multiple s ys te m adminis trators can maintain the s ys te m, it is impos s ible to figure out which of thos e us e rs was root at a give n time . Whe n us ing s e parate logins , the account a us e r logs in with, as we ll as a unique numbe r for s e s s ion tracking purpos e s , is put into the tas k s tructure , which is inhe rite d by e ve ry proce s s that the us e r s tarts . Whe n us ing concurre nt logins , the unique numbe r can be us e d to trace actions to s pe cific logins . Whe n an action ge ne rate s an audit e ve nt, it is re corde d with the login account and the s e s s ion as s ociate d with that unique numbe r. Us e the aulast command to vie w the s e logins and s e s s ions . The --proof option of the aulast command can be us e d s ugge s t a s pe cific ausearch que ry to is olate auditable e ve nts ge ne rate d by a particular s e s s ion. For more information about the Audit s ys te m, s e e Chapte r 6, System Auditing.

4.2.3. Limit ing Root Access Rathe r than comple te ly de nying acce s s to the root us e r, the adminis trator may want to allow acce s s only through s e tuid programs , s uch as su or sudo. For more information on su and sudo, s e e the Gaining Privile ge s chapte r in Re d Hat Ente rpris e Linux 7 Sys te m Adminis trator's Guide , and the su(1) and sudo(8) man page s .

4.2.4. Enabling Aut omat ic Logout s Whe n the us e r is logge d in as root, an unatte nde d login s e s s ion may pos e a s ignificant s e curity ris k. To re duce this ris k, you can configure the s ys te m to automatically log out idle us e rs afte r a fixe d pe riod of time . 1. As root, add the following line at the be ginning of the /etc/profile file to make s ure the proce s s ing of this file cannot be inte rrupte d: trap "" 1 2 3 15 2. As root, ins e rt the following line s to the /etc/profile file to automatically log out afte r 120 s e conds :

41

Se c ur it y Guide

export TMOUT=120 readonly TMOUT The TMOUT variable te rminate s the s he ll if the re is no activity for the s pe cifie d numbe r of s e conds (s e t to 120 in the above e xample ). You can change the limit according to the ne e ds of the particular ins tallation.

4.2.5. Securing t he Boot Loader The primary re as ons for pas s word prote cting a Linux boot loade r are as follows : 1. Preventing Access to Single User Mode — If attacke rs can boot the s ys te m into s ingle us e r mode , the y are logge d in automatically as root without be ing prompte d for the root pas s word.

Warning Prote cting acce s s to s ingle us e r mode with a pas s word by e diting the SINGLE parame te r in the /etc/sysconfig/init file is not re comme nde d. An attacke r can bypas s the pas s word by s pe cifying a cus tom initial command (us ing the init= parame te r) on the ke rne l command line in GRUB 2. It is re comme nde d to pas s word-prote ct the GRUB 2 boot loade r, as de s cribe d in the Prote cting GRUB 2 with a Pas s word chapte r in Re d Hat Ente rpris e Linux 7 Sys te m Adminis trator's Guide . 2. Preventing Access to the GRUB 2 Console — If the machine us e s GRUB 2 as its boot loade r, an attacke r can us e the GRUB 2 e ditor inte rface to change its configuration or to gathe r information us ing the cat command. 3. Preventing Access to Insecure Operating Systems — If it is a dual-boot s ys te m, an attacke r can s e le ct an ope rating s ys te m at boot time , for e xample DOS, which ignore s acce s s controls and file pe rmis s ions . Re d Hat Ente rpris e Linux 7 include s the GRUB 2 boot loade r on the Inte l 64 and AMD64 platform. For a de taile d look at GRUB 2, s e e the Working With the GRUB 2 Boot Loade r chapte r in Re d Hat Ente rpris e Linux 7 Sys te m Adminis trator's Guide .

4.2.5.1. Disabling Int eract ive St art up Pre s s ing the I ke y at the be ginning of the boot s e que nce allows you to s tart up your s ys te m inte ractive ly. During an inte ractive s tartup, the s ys te m prompts you to s tart up e ach s e rvice one by one . Howe ve r, this may allow an attacke r who gains phys ical acce s s to your s ys te m to dis able the s e curity-re late d s e rvice s and gain acce s s to the s ys te m. To pre ve nt us e rs from s tarting up the s ys te m inte ractive ly, as root, dis able the PROMPT parame te r in the /etc/sysconfig/init file : PROMPT=no

4.2.6. Prot ect ing Hard and Symbolic Links

42

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

To pre ve nt malicious us e rs from e xploiting pote ntial vulne rabilitie s caus e d by unprote cte d hard and s ymbolic links , Re d Hat Ente rpris e Linux 7 include s a fe ature that only allows links to be cre ate d or followe d provide d ce rtain conditions are me t. In cas e of hard links , one of the following ne e ds to be true : The us e r owns the file to which the y link. The us e r alre ady has re ad and write acce s s to the file to which the y link. In cas e of s ymbolic links , proce s s e s are only pe rmitte d to follow links whe n outs ide of world-write able dire ctorie s with s ticky bits , or one of the following ne e ds to be true : The proce s s following the s ymbolic link is the owne r of the s ymbolic link. The owne r of the dire ctory is the s ame as the owne r of the s ymbolic link. This prote ction is turne d on by de fault. It is controlle d by the following options in the /usr/lib/sysctl.d/50-default.conf file : fs.protected_hardlinks = 1 fs.protected_symlinks = 1 To ove rride the de fault s e ttings and dis able the prote ction, cre ate a ne w configuration file calle d, for e xample , 51-no-protect-links.conf in the /etc/sysctl.d/ dire ctory with the following conte nt: fs.protected_hardlinks = 0 fs.protected_symlinks = 0

No te Note that in orde r to ove rride the de fault s ys te m s e ttings , the ne w configuration file ne e ds to have the .conf e xte ns ion, and it ne e ds to be re ad after the de fault s ys te m file (the file s are re ad in le xicographic orde r, the re fore s e ttings containe d in a file with a highe r numbe r at the be ginning of the file name take pre ce de nce ). Se e the s ys ctl.d(5) manual page for more de taile d information about the configuration of ke rne l parame te rs at boot us ing the sysctl me chanis m.

4.3. Securing Services While us e r acce s s to adminis trative controls is an important is s ue for s ys te m adminis trators within an organiz ation, monitoring which ne twork s e rvice s are active is of paramount importance to anyone who adminis te rs and ope rate s a Linux s ys te m. Many s e rvice s unde r Re d Hat Ente rpris e Linux 7 are ne twork s e rve rs . If a ne twork s e rvice is running on a machine , the n a s e rve r application (calle d a daemon), is lis te ning for conne ctions on one or more ne twork ports . Each of the s e s e rve rs s hould be tre ate d as a pote ntial ave nue of attack.

4.3.1. Risks T o Services

43

Se c ur it y Guide

Ne twork s e rvice s can pos e many ris ks for Linux s ys te ms . Be low is a lis t of s ome of the primary is s ue s : Denial of Service Attacks (DoS) — By flooding a s e rvice with re que s ts , a de nial of s e rvice attack can re nde r a s ys te m unus able as it trie s to log and ans we r e ach re que s t. Distributed Denial of Service Attack (DDoS) — A type of DoS attack which us e s multiple compromis e d machine s (ofte n numbe ring in the thous ands or more ) to dire ct a coordinate d attack on a s e rvice , flooding it with re que s ts and making it unus able . Script Vulnerability Attacks — If a s e rve r is us ing s cripts to e xe cute s e rve r-s ide actions , as We b s e rve rs commonly do, an attacke r can targe t imprope rly writte n s cripts . The s e s cript vulne rability attacks can le ad to a buffe r ove rflow condition or allow the attacke r to alte r file s on the s ys te m. Buffer Overflow Attacks — Se rvice s that want to lis te n on ports 1 through 1023 mus t s tart e ithe r with adminis trative privile ge s or the CAP_NET_BIND_SERVICE capability ne e ds to be s e t for the m. Once a proce s s is bound to a port and is lis te ning on it, the privile ge s or the capability are ofte n droppe d. If the privile ge s or the capability are not droppe d, and the application has an e xploitable buffe r ove rflow, an attacke r could gain acce s s to the s ys te m as the us e r running the dae mon. Be caus e e xploitable buffe r ove rflows e xis t, cracke rs us e automate d tools to ide ntify s ys te ms with vulne rabilitie s , and once the y have gaine d acce s s , the y us e automate d rootkits to maintain the ir acce s s to the s ys te m.

No te The thre at of buffe r ove rflow vulne rabilitie s is mitigate d in Re d Hat Ente rpris e Linux 7 by ExecShield, an e xe cutable me mory s e gme ntation and prote ction te chnology s upporte d by x86-compatible uni- and multi-proce s s or ke rne ls . Exe cShie ld re duce s the ris k of buffe r ove rflow by s e parating virtual me mory into e xe cutable and non-e xe cutable s e gme nts . Any program code that trie s to e xe cute outs ide of the e xe cutable s e gme nt (s uch as malicious code inje cte d from a buffe r ove rflow e xploit) trigge rs a s e gme ntation fault and te rminate s . Exe cs hie ld als o include s s upport for No eXecute (NX) te chnology on AMD64 platforms and Inte l® 64 s ys te ms . The s e te chnologie s work in conjunction with Exe cShie ld to pre ve nt malicious code from running in the e xe cutable portion of virtual me mory with a granularity of 4KB of e xe cutable code , lowe ring the ris k of attack from buffe r ove rflow e xploits .

Impo rtant To limit e xpos ure to attacks ove r the ne twork, all s e rvice s that are unus e d s hould be turne d off.

4.3.2. Ident if ying and Conf iguring Services To e nhance s e curity, mos t ne twork s e rvice s ins talle d with Re d Hat Ente rpris e Linux 7 are turne d off by de fault. The re are , howe ve r, s ome notable e xce ptions :

44

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

cups — The de fault print s e rve r for Re d Hat Ente rpris e Linux 7. cups-lpd — An alte rnative print s e rve r. xinetd — A s upe r s e rve r that controls conne ctions to a range of s ubordinate s e rve rs , s uch as gssftp and telnet. sshd — The Ope nSSH s e rve r, which is a s e cure re place me nt for Te lne t. Whe n de te rmining whe the r to le ave the s e s e rvice s running, it is be s t to us e common s e ns e and avoid taking any ris ks . For e xample , if a printe r is not available , do not le ave cups running. The s ame is true for portreserve. If you do not mount NFSv3 volume s or us e NIS (the ypbind s e rvice ), the n rpcbind s hould be dis able d. Che cking which ne twork s e rvice s are available to s tart at boot time is not s ufficie nt. It is re comme nde d to als o che ck which ports are ope n and lis te ning. Re fe r to Se ction 4.4.2, “Ve rifying Which Ports Are Lis te ning” for more information.

4.3.3. Insecure Services Pote ntially, any ne twork s e rvice is ins e cure . This is why turning off unus e d s e rvice s is s o important. Exploits for s e rvice s are routine ly re ve ale d and patche d, making it ve ry important to re gularly update package s as s ociate d with any ne twork s e rvice . Se e Chapte r 3, Keeping Your System Up-to-Date for more information. Some ne twork protocols are inhe re ntly more ins e cure than othe rs . The s e include any s e rvice s that: Transmit Usernames and Passwords Over a Network Unencrypted — Many olde r protocols , s uch as Te lne t and FTP, do not e ncrypt the authe ntication s e s s ion and s hould be avoide d whe ne ve r pos s ible . Transmit Sensitive Data Over a Network Unencrypted — Many protocols trans mit data ove r the ne twork une ncrypte d. The s e protocols include Te lne t, FTP, HTTP, and SMTP. Many ne twork file s ys te ms , s uch as NFS and SMB, als o trans mit information ove r the ne twork une ncrypte d. It is the us e r's re s pons ibility whe n us ing the s e protocols to limit what type of data is trans mitte d. Example s of inhe re ntly ins e cure s e rvice s include rlogin, rsh, telnet, and vsftpd. All re mote login and s he ll programs (rlogin, rsh, and telnet) s hould be avoide d in favor of SSH. Se e Se ction 4.3.11, “Se curing SSH” for more information about sshd. FTP is not as inhe re ntly dange rous to the s e curity of the s ys te m as re mote s he lls , but FTP s e rve rs mus t be care fully configure d and monitore d to avoid proble ms . Se e Se ction 4.3.9, “Se curing FTP” for more information about s e curing FTP s e rve rs . Se rvice s that s hould be care fully imple me nte d and be hind a fire wall include : auth nfs-server smb and nbm (Samba) yppasswdd ypserv ypxfrd

45

Se c ur it y Guide

More information on s e curing ne twork s e rvice s is available in Se ction 4.4, “Se curing Ne twork Acce s s ”.

4.3.4. Securing rpcbind The rpcbind s e rvice is a dynamic port as s ignme nt dae mon for RPC s e rvice s s uch as NIS and NFS. It has we ak authe ntication me chanis ms and has the ability to as s ign a wide range of ports for the s e rvice s it controls . For the s e re as ons , it is difficult to s e cure .

No te Se curing rpcbind only affe cts NFSv2 and NFSv3 imple me ntations , s ince NFSv4 no longe r re quire s it. If you plan to imple me nt an NFSv2 or NFSv3 s e rve r, the n rpcbind is re quire d, and the following s e ction applie s . If running RPC s e rvice s , follow the s e bas ic rule s .

4.3.4.1. Prot ect rpcbind Wit h T CP Wrappers It is important to us e TCP Wrappe rs to limit which ne tworks or hos ts have acce s s to the rpcbind s e rvice s ince it has no built-in form of authe ntication. Furthe r, us e only IP addre s s e s whe n limiting acce s s to the s e rvice . Avoid us ing hos t name s , as the y can be forge d by DNS pois oning and othe r me thods .

4.3.4.2. Prot ect rpcbind Wit h f irewalld To furthe r re s trict acce s s to the rpcbind s e rvice , it is a good ide a to add firewalld rule s to the s e rve r and re s trict acce s s to s pe cific ne tworks . Be low are two e xample firewalld rich language commands . The firs t allows TCP conne ctions to the port 111 (us e d by the rpcbind s e rvice ) from the 192.168.0.0/24 ne twork. The s e cond allows TCP conne ctions to the s ame port from the localhos t. All othe r packe ts are droppe d. ~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop' ~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept' To s imilarly limit UDP traffic, us e the following command: ~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'

No te Add --permanent to the firewalld rich language commands to make the s e ttings pe rmane nt. Se e Chapte r 5, Using Firewalls for more information about imple me nting fire walls .

46

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

4.3.5. Securing rpc.mount d The rpc.mountd dae mon imple me nts the s e rve r s ide of the NFS MOUNT protocol, a protocol us e d by NFS ve rs ion 2 (RFC 1904) and NFS ve rs ion 3 (RFC 1813). If running RPC s e rvice s , follow the s e bas ic rule s .

4.3.5.1. Prot ect rpc.mount d Wit h T CP Wrappers It is important to us e TCP Wrappe rs to limit which ne tworks or hos ts have acce s s to the rpc.mountd s e rvice s ince it has no built-in form of authe ntication. Furthe r, us e only IP addre s s e s whe n limiting acce s s to the s e rvice . Avoid us ing hos t name s , as the y can be forge d by DNS pois oning and othe r me thods .

4.3.5.2. Prot ect rpc.mount d Wit h f irewalld To furthe r re s trict acce s s to the rpc.mountd s e rvice , add firewalld rich language rule s to the s e rve r and re s trict acce s s to s pe cific ne tworks . Be low are two e xample firewalld rich language commands . The firs t allows mountd conne ctions from the 192.168.0.0/24 ne twork. The s e cond allows mountd conne ctions from the local hos t. All othe r packe ts are droppe d. ~]# firewall-cmd --add-rich-rule 'rule family="ipv4" source NOT address="192.168.0.0/24" service name="mountd" drop' ~]# firewall-cmd --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'

No te Add --permanent to the firewalld rich language commands to make the s e ttings pe rmane nt. Se e Chapte r 5, Using Firewalls for more information about imple me nting fire walls .

4.3.6. Securing NIS The Network Information Service (NIS) is an RPC s e rvice , calle d ypserv, which is us e d in conjunction with rpcbind and othe r re late d s e rvice s to dis tribute maps of us e r name s , pas s words , and othe r s e ns itive information to any compute r claiming to be within its domain. A NIS s e rve r is compris e d of s e ve ral applications . The y include the following: /usr/sbin/rpc.yppasswdd — Als o calle d the yppasswdd s e rvice , this dae mon allows us e rs to change the ir NIS pas s words . /usr/sbin/rpc.ypxfrd — Als o calle d the ypxfrd s e rvice , this dae mon is re s pons ible for NIS map trans fe rs ove r the ne twork. /usr/sbin/ypserv — This is the NIS s e rve r dae mon. NIS is s ome what ins e cure by today's s tandards . It has no hos t authe ntication me chanis ms and trans mits all of its information ove r the ne twork une ncrypte d, including pas s word

47

Se c ur it y Guide

has he s . As a re s ult, e xtre me care mus t be take n whe n s e tting up a ne twork that us e s NIS. This is furthe r complicate d by the fact that the de fault configuration of NIS is inhe re ntly ins e cure . It is re comme nde d that anyone planning to imple me nt a NIS s e rve r firs t s e cure the rpcbind s e rvice as outline d in Se ction 4.3.4, “Se curing rpcbind”, the n addre s s the following is s ue s , s uch as ne twork planning.

4.3.6.1. Caref ully Plan t he Net work Be caus e NIS trans mits s e ns itive information une ncrypte d ove r the ne twork, it is important the s e rvice be run be hind a fire wall and on a s e gme nte d and s e cure ne twork. Whe ne ve r NIS information is trans mitte d ove r an ins e cure ne twork, it ris ks be ing inte rce pte d. Care ful ne twork de s ign can he lp pre ve nt s e ve re s e curity bre ache s .

4.3.6.2. Use a Password-like NIS Domain Name and Host name Any machine within a NIS domain can us e commands to e xtract information from the s e rve r without authe ntication, as long as the us e r knows the NIS s e rve r's DNS hos t name and NIS domain name . For ins tance , if s ome one e ithe r conne cts a laptop compute r into the ne twork or bre aks into the ne twork from outs ide (and manage s to s poof an inte rnal IP addre s s ), the following command re ve als the /etc/passwd map: ypcat -d -h passwd If this attacke r is a root us e r, the y can obtain the /etc/shadow file by typing the following command: ypcat -d -h shadow

No te If Ke rbe ros is us e d, the /etc/shadow file is not s tore d within a NIS map. To make acce s s to NIS maps harde r for an attacke r, cre ate a random s tring for the DNS hos t name , s uch as o7hfawtgmhwg.domain.com. Similarly, cre ate a different randomiz e d NIS domain name . This make s it much more difficult for an attacke r to acce s s the NIS s e rve r.

4.3.6.3. Edit t he /var/yp/securenets File If the /var/yp/securenets file is blank or doe s not e xis t (as is the cas e afte r a de fault ins tallation), NIS lis te ns to all ne tworks . One of the firs t things to do is to put ne tmas k/ne twork pairs in the file s o that ypserv only re s ponds to re que s ts from the appropriate ne twork. Be low is a s ample e ntry from a /var/yp/securenets file : 255.255.255.0

48

192.168.0.0

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

Warning Ne ve r s tart a NIS s e rve r for the firs t time without cre ating the /var/yp/securenets file . This te chnique doe s not provide prote ction from an IP s poofing attack, but it doe s at le as t place limits on what ne tworks the NIS s e rve r s e rvice s .

4.3.6.4. Assign St at ic Port s and Use Rich Language Rules All of the s e rve rs re late d to NIS can be as s igne d s pe cific ports e xce pt for rpc.yppasswdd — the dae mon that allows us e rs to change the ir login pas s words . As s igning ports to the othe r two NIS s e rve r dae mons , rpc.ypxfrd and ypserv, allows for the cre ation of fire wall rule s to furthe r prote ct the NIS s e rve r dae mons from intrude rs . To do this , add the following line s to /etc/sysconfig/network: YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835" The following rich language firewalld rule s can the n be us e d to e nforce which ne twork the s e rve r lis te ns to for the s e ports : ~]# firewall-cmd --add-rich-rule='rule address="192.168.0.0/24" invert="True" protocol="tcp" drop' ~]# firewall-cmd --add-rich-rule='rule address="192.168.0.0/24" invert="True" protocol="udp" drop'

family="ipv4" source port port="834-835" family="ipv4" source port port="834-835"

This me ans that the s e rve r only allows conne ctions to ports 834 and 835 if the re que s ts come from the 192.168.0.0/24 ne twork. The firs t rule is for TCP and the s e cond for UDP.

No te Se e Chapte r 5, Using Firewalls for more information about imple me nting fire walls with iptable s commands .

4.3.6.5. Use Kerberos Aut hent icat ion One of the is s ue s to cons ide r whe n NIS is us e d for authe ntication is that whe ne ve r a us e r logs into a machine , a pas s word has h from the /etc/shadow map is s e nt ove r the ne twork. If an intrude r gains acce s s to a NIS domain and s niffs ne twork traffic, the y can colle ct us e r name s and pas s word has he s . With e nough time , a pas s word cracking program can gue s s we ak pas s words , and an attacke r can gain acce s s to a valid account on the ne twork. Since Ke rbe ros us e s s e cre t-ke y cryptography, no pas s word has he s are e ve r s e nt ove r the ne twork, making the s ys te m far more s e cure . Se e the Logging into IdM Us ing Ke rbe ros s e ction in the Linux Domain Ide ntity, Authe ntication, and Policy Guide for more information about Ke rbe ros .

49

Se c ur it y Guide

4.3.7. Securing NFS

Impo rtant NFS traffic can be s e nt us ing TCP in all ve rs ions , it s hould be us e d with NFSv3, rathe r than UDP, and is re quire d whe n us ing NFSv4. All ve rs ions of NFS s upport Ke rbe ros us e r and group authe ntication, as part of the RPCSEC_GSS ke rne l module . Information on rpcbind is s till include d, s ince Re d Hat Ente rpris e Linux 7 s upports NFSv3 which utiliz e s rpcbind.

4.3.7.1. Caref ully Plan t he Net work NFSv2 and NFSv3 traditionally pas s e d data ins e cure ly. All ve rs ions of NFS now have the ability to authe nticate (and optionally e ncrypt) ordinary file s ys te m ope rations us ing Ke rbe ros . Unde r NFSv4 all ope rations can us e Ke rbe ros ; unde r v2 or v3, file locking and mounting s till do not us e it. Whe n us ing NFSv4.0, de le gations may be turne d off if the clie nts are be hind NAT or a fire wall. For information on the us e of NFSv4.1 to allow de le gations to ope rate through NAT and fire walls , s e e the pNFS s e ction of the Re d Hat Ente rpris e Linux 7 Storage Adminis tration Guide .

4.3.7.2. Securing NFS Mount Opt ions The us e of the mount command in the /etc/fstab file is e xplaine d in the Us ing the mount Command chapte r of the Re d Hat Ente rpris e Linux 7 Storage Adminis tration Guide . From a s e curity adminis tration point of vie w it is worthwhile to note that the NFS mount options can als o be s pe cifie d in /etc/nfsmount.conf, which can be us e d to s e t cus tom de fault options . 4.3.7.2.1. Review t he NFS Server

Warning Only e xport e ntire file s ys te ms . Exporting a s ubdire ctory of a file s ys te m can be a s e curity is s ue . It is pos s ible in s ome cas e s for a clie nt to "bre ak out" of the e xporte d part of the file s ys te m and ge t to une xporte d parts (s e e the s e ction on s ubtre e che cking in the exports(5) man page . Us e the ro option to e xport the file s ys te m as re ad-only whe ne ve r pos s ible to re duce the numbe r of us e rs able to write to the mounte d file s ys te m. Only us e the rw option whe n s pe cifically re quire d. Se e the man exports(5) page for more information. Allowing write acce s s incre as e s the ris k from s ymlink attacks for e xample . This include s te mporary dire ctorie s s uch as /tmp and /usr/tmp. Whe re dire ctorie s mus t be mounte d with the rw option avoid making the m world-writable whe ne ve r pos s ible to re duce ris k. Exporting home dire ctorie s is als o vie we d as a ris k as s ome applications s tore pas s words in cle ar te xt or we akly e ncrypte d. This ris k is be ing re duce d as application code is re vie we d and improve d. Some us e rs do not s e t pas s words on the ir SSH ke ys s o this too me ans home dire ctorie s pre s e nt a ris k. Enforcing the us e of pas s words or us ing Ke rbe ros would mitigate that ris k.

50

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

Re s trict e xports only to clie nts that ne e d acce s s . Us e the showmount -e command on an NFS s e rve r to re vie w what the s e rve r is e xporting. Do not e xport anything that is not s pe cifically re quire d. Do not us e the no_root_squash option and re vie w e xis ting ins tallations to make s ure it is not us e d. Se e Se ction 4.3.7.4, “Do Not Us e the no_root_s quas h Option” for more information. The secure option is the s e rve r-s ide e xport option us e d to re s trict e xports to “re s e rve d” ports . By de fault, the s e rve r allows clie nt communication only from “re s e rve d” ports (ports numbe re d le s s than 1024), be caus e traditionally clie nts have only allowe d “trus te d” code (s uch as in-ke rne l NFS clie nts ) to us e thos e ports . Howe ve r, on many ne tworks it is not difficult for anyone to be come root on s ome clie nt, s o it is rare ly s afe for the s e rve r to as s ume that communication from a re s e rve d port is privile ge d. The re fore the re s triction to re s e rve d ports is of limite d value ; it is be tte r to re ly on Ke rbe ros , fire walls , and re s triction of e xports to particular clie nts . Mos t clie nts s till do us e re s e rve d ports whe n pos s ible . Howe ve r, re s e rve d ports are a limite d re s ource , s o clie nts (e s pe cially thos e with a large numbe r of NFS mounts ) may choos e to us e highe r-numbe re d ports as we ll. Linux clie nts may do this us ing the “nore s vport” mount option. If you want to allow this on an e xport, you may do s o with the “ins e cure ” e xport option. It is good practice not to allow us e rs to login to a s e rve r. While re vie wing the above s e ttings on an NFS s e rve r conduct a re vie w of who and what can acce s s the s e rve r. 4.3.7.2.2. Review t he NFS Client Us e the nosuid option to dis allow the us e of a set uid program. The nosuid option dis able s the set-user-identifier or set-group-identifier bits . This pre ve nts re mote us e rs from gaining highe r privile ge s by running a s e tuid program. Us e this option on the clie nt and the s e rve r s ide . The noexec option dis able s all e xe cutable file s on the clie nt. Us e this to pre ve nt us e rs from inadve rte ntly e xe cuting file s place d in the file s ys te m be ing s hare d. The nosuid and noexec options are s tandard options for mos t, if not all, file s ys te ms . Us e the nodev option to pre ve nt “de vice -file s ” from be ing proce s s e d as a hardware de vice by the clie nt. The resvport option is a clie nt-s ide mount option and secure is the corre s ponding s e rve r-s ide e xport option (s e e e xplanation above ). It re s tricts communication to a "re s e rve d port". The re s e rve d or "we ll known" ports are re s e rve d for privile ge d us e rs and proce s s e s s uch as the root us e r. Se tting this option caus e s the clie nt to us e a re s e rve d s ource port to communicate with the s e rve r. All ve rs ions of NFS now s upport mounting with Ke rbe ros authe ntication. The mount option to e nable this is : sec=krb5. NFSv4 s upports mounting with Ke rbe ros us ing krb5i for inte grity and krb5p for privacy prote ction. The s e are us e d whe n mounting with sec=krb5, but ne e d to be configure d on the NFS s e rve r. Se e the man page on e xports (man 5 exports) for more information. The NFS man page (man 5 nfs) has a “SECURITY CONSIDERATIONS” s e ction which e xplains the s e curity e nhance me nts in NFSv4 and contains all the NFS s pe cific mount options .

4.3.7.3. Beware of Synt ax Errors

51

Se c ur it y Guide

The NFS s e rve r de te rmine s which file s ys te ms to e xport and which hos ts to e xport the s e dire ctorie s to by cons ulting the /etc/exports file . Be care ful not to add e xtrane ous s pace s whe n e diting this file . For ins tance , the following line in the /etc/exports file s hare s the dire ctory /tmp/nfs/ to the hos t bob.example.com with re ad/write pe rmis s ions . /tmp/nfs/

bob.example.com(rw)

The following line in the /etc/exports file , on the othe r hand, s hare s the s ame dire ctory to the hos t bob.example.com with re ad-only pe rmis s ions and s hare s it to the world with re ad/write pe rmis s ions due to a s ingle s pace characte r afte r the hos t name . /tmp/nfs/

bob.example.com (rw)

It is good practice to che ck any configure d NFS s hare s by us ing the showmount command to ve rify what is be ing s hare d: showmount -e

4.3.7.4. Do Not Use t he no_root _squash Opt ion By de fault, NFS s hare s change the root us e r to the nfsnobody us e r, an unprivile ge d us e r account. This change s the owne r of all root-cre ate d file s to nfsnobody, which pre ve nts uploading of programs with the s e tuid bit s e t. If no_root_squash is us e d, re mote root us e rs are able to change any file on the s hare d file s ys te m and le ave applications infe cte d by Trojans for othe r us e rs to inadve rte ntly e xe cute .

4.3.7.5. NFS Firewall Conf igurat ion NFSv4 is the de fault ve rs ion of NFS for Re d Hat Ente rpris e Linux 7 and it only re quire s port 2049 to be ope n for TCP. If us ing NFSv3 the n four additional ports are re quire d as e xplaine d be low. Co nf iguring Po rt s f o r NFSv3 The ports us e d for NFS are as s igne d dynamically by rpcbind, which can caus e proble ms whe n cre ating fire wall rule s . To s implify this proce s s , us e the /etc/sysconfig/nfs file to s pe cify which ports are to be us e d: MOUNTD_PORT — TCP and UDP port for mountd (rpc.mountd) STATD_PORT — TCP and UDP port for s tatus (rpc.s tatd) LOCKD_TCPPORT — TCP port for nlockmgr (rpc.lockd) LOCKD_UDPPORT — UDP port nlockmgr (rpc.lockd) Port numbe rs s pe cifie d mus t not be us e d by any othe r s e rvice . Configure your fire wall to allow the port numbe rs s pe cifie d, as we ll as TCP and UDP port 2049 (NFS). Run the rpcinfo -p command on the NFS s e rve r to s e e which ports and RPC programs are be ing us e d.

52

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

4.3.7.6. Secure NFS wit h Red Hat ident it y Management Ke rbe ros -aware NFS s e tup can be gre atly s implifie d in an e nvironme nt that is us ing Re d Hat Ide ntity Manage me nt which is include d in Re d Hat Ente rpris e Linux. Follow the Re d Hat Ente rpris e Linux 7 Linux Domain Ide ntity, Authe ntication, and Policy Guide , in particular Se tting up a Ke rbe ros -aware NFS Se rve r to le arn how to s e cure NFS with Ke rbe ros whe n us ing Re d Hat Ide ntity Manage me nt.

4.3.8. Securing t he Apache HT T P Server The Apache HTTP Se rve r is one of the mos t s table and s e cure s e rvice s in Re d Hat Ente rpris e Linux 7. A large numbe r of options and te chnique s are available to s e cure the Apache HTTP Se rve r — too nume rous to de lve into de e ply he re . The following s e ction brie fly e xplains good practice s whe n running the Apache HTTP Se rve r. Always ve rify that any s cripts running on the s ys te m work as inte nde d before putting the m into production. Als o, e ns ure that only the root us e r has write pe rmis s ions to any dire ctory containing s cripts or CGIs . To do this , e nte r the following commands as the root us e r: chown root chmod 755 Sys te m adminis trators s hould be care ful whe n us ing the following configuration options (configure d in /etc/httpd/conf/httpd.conf): FollowSymLinks This dire ctive is e nable d by de fault, s o be s ure to us e caution whe n cre ating s ymbolic links to the docume nt root of the We b s e rve r. For ins tance , it is a bad ide a to provide a s ymbolic link to /. Indexes This dire ctive is e nable d by de fault, but may not be de s irable . To pre ve nt vis itors from brows ing file s on the s e rve r, re move this dire ctive . UserDir The UserDir dire ctive is dis able d by de fault be caus e it can confirm the pre s e nce of a us e r account on the s ys te m. To e nable us e r dire ctory brows ing on the s e rve r, us e the following dire ctive s : UserDir enabled UserDir disabled root The s e dire ctive s activate us e r dire ctory brows ing for all us e r dire ctorie s othe r than /root/. To add us e rs to the lis t of dis able d accounts , add a s pace -de limite d lis t of us e rs on the UserDir disabled line . ServerTokens The ServerTokens dire ctive controls the s e rve r re s pons e he ade r fie ld which is s e nt back to clie nts . It include s various information which can be cus tomiz e d us ing the following parame te rs :

53

Se c ur it y Guide

ServerTokens Full (de fault option) — provide s all available information (OS type and us e d module s ), for e xample : Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2 ServerTokens Prod or ServerTokens ProductOnly — provide s the following information: Apache ServerTokens Major — provide s the following information: Apache/2 ServerTokens Minor — provide s the following information: Apache/2.0 ServerTokens Min or ServerTokens Minimal — provide s the following information: Apache/2.0.41 ServerTokens OS — provide s the following information: Apache/2.0.41 (Unix) It is re comme nde d to us e the ServerTokens Prod option s o that a pos s ible attacke r doe s not gain any valuable information about your s ys te m.

Impo rtant Do not re move the IncludesNoExec dire ctive . By de fault, the Server-Side Includes (SSI) module cannot e xe cute commands . It is re comme nde d that you do not change this s e tting unle s s abs olute ly ne ce s s ary, as it could, pote ntially, e nable an attacke r to e xe cute commands on the s ys te m.

Removing ht t pd Modules In ce rtain s ce narios , it is be ne ficial to re move ce rtain httpd module s to limit the functionality of the HTTP Se rve r. To do s o, s imply comme nt out the e ntire line which loads the module you want to re move in the /etc/httpd/conf/httpd.conf file . For e xample , to re move the proxy module , comme nt out the following line by pre pe nding it with a has h s ign: #LoadModule proxy_module modules/mod_proxy.so Note that the /etc/httpd/conf.d/ dire ctory contains configuration file s which are us e d to load module s as we ll.

54

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

ht t pd and SELinux For information, s e e the The Apache HTTP Se rve r and SELinux chapte r from the Re d Hat Ente rpris e Linux 7 SELinux Us e r's and Adminis trator's Guide .

4.3.9. Securing FT P The File Transfer Protocol (FTP) is an olde r TCP protocol de s igne d to trans fe r file s ove r a ne twork. Be caus e all trans actions with the s e rve r, including us e r authe ntication, are une ncrypte d, it is cons ide re d an ins e cure protocol and s hould be care fully configure d. Re d Hat Ente rpris e Linux 7 provide s two FTP s e rve rs : Red Hat Co nt ent Accelerat o r (tux) — A ke rne l-s pace We b s e rve r with FTP capabilitie s . vsftpd — A s tandalone , s e curity orie nte d imple me ntation of the FTP s e rvice . The following s e curity guide line s are for s e tting up the vsftpd FTP s e rvice .

4.3.9.1. FT P Greet ing Banner Be fore s ubmitting a us e r name and pas s word, all us e rs are pre s e nte d with a gre e ting banne r. By de fault, this banne r include s ve rs ion information us e ful to cracke rs trying to ide ntify we akne s s e s in a s ys te m. To change the gre e ting banne r for vsftpd, add the following dire ctive to the /etc/vsftpd/vsftpd.conf file : ftpd_banner= Re place in the above dire ctive with the te xt of the gre e ting me s s age . For mutli-line banne rs , it is be s t to us e a banne r file . To s implify manage me nt of multiple banne rs , place all banne rs in a ne w dire ctory calle d /etc/banners/. The banne r file for FTP conne ctions in this e xample is /etc/banners/ftp.msg. Be low is an e xample of what s uch a file may look like : ######### Hello, all activity on ftp.example.com is logged. #########

No te It is not ne ce s s ary to be gin e ach line of the file with 220 as s pe cifie d in Se ction 4.4.1, “Se curing Se rvice s With TCP Wrappe rs and xine td”. To re fe re nce this gre e ting banne r file for vsftpd, add the following dire ctive to the /etc/vsftpd/vsftpd.conf file : banner_file=/etc/banners/ftp.msg It als o is pos s ible to s e nd additional banne rs to incoming conne ctions us ing TCP Wrappe rs as de s cribe d in Se ction 4.4.1.1, “TCP Wrappe rs and Conne ction Banne rs ”.

55

Se c ur it y Guide

4.3.9.2. Anonymous Access The pre s e nce of the /var/ftp/ dire ctory activate s the anonymous account. The e as ie s t way to cre ate this dire ctory is to ins tall the vsftpd package . This package e s tablis he s a dire ctory tre e for anonymous us e rs and configure s the pe rmis s ions on dire ctorie s to re ad-only for anonymous us e rs . By de fault the anonymous us e r cannot write to any dire ctorie s .

Warning If e nabling anonymous acce s s to an FTP s e rve r, be aware of whe re s e ns itive data is s tore d.

4.3.9.2.1. Ano nymo us Uplo ad To allow anonymous us e rs to upload file s , it is re comme nde d that a write -only dire ctory be cre ate d within /var/ftp/pub/. To do this , e nte r the following command as root: ~]# mkdir /var/ftp/pub/upload Ne xt, change the pe rmis s ions s o that anonymous us e rs cannot vie w the conte nts of the dire ctory: ~]# chmod 730 /var/ftp/pub/upload A long format lis ting of the dire ctory s hould look like this : ~]# ls -ld /var/ftp/pub/upload drwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload Adminis trators who allow anonymous us e rs to re ad and write in dire ctorie s ofte n find that the ir s e rve rs be come a re pos itory of s tole n s oftware . Additionally, unde r vsftpd, add the following line to the /etc/vsftpd/vsftpd.conf file : anon_upload_enable=YES

4.3.9.3. User Account s Be caus e FTP trans mits une ncrypte d us e r name s and pas s words ove r ins e cure ne tworks for authe ntication, it is a good ide a to de ny s ys te m us e rs acce s s to the s e rve r from the ir us e r accounts . To dis able all us e r accounts in vsftpd, add the following dire ctive to /etc/vsftpd/vsftpd.conf: local_enable=NO 4.3.9.3.1. Rest rict ing User Acco unt s

56

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

To dis able FTP acce s s for s pe cific accounts or s pe cific groups of accounts , s uch as the root us e r and thos e with sudo privile ge s , the e as ie s t way is to us e a PAM lis t file as de s cribe d in Se ction 4.2.1, “Dis allowing Root Acce s s ”. The PAM configuration file for vsftpd is /etc/pam.d/vsftpd. It is als o pos s ible to dis able us e r accounts within e ach s e rvice dire ctly. To dis able s pe cific us e r accounts in vsftpd, add the us e r name to /etc/vsftpd/ftpusers

4.3.9.4. Use T CP Wrappers T o Cont rol Access Us e TCP Wrappe rs to control acce s s to e ithe r FTP dae mon as outline d in Se ction 4.4.1, “Se curing Se rvice s With TCP Wrappe rs and xine td”.

4.3.10. Securing Post f ix Pos tfix is a Mail Trans fe r Age nt (MTA) that us e s the Simple Mail Trans fe r Protocol (SMTP) to de live r e le ctronic me s s age s be twe e n othe r MTAs and to e mail clie nts or de live ry age nts . Although many MTAs are capable of e ncrypting traffic be twe e n one anothe r, mos t do not, s o s e nding e mail ove r any public ne tworks is cons ide re d an inhe re ntly ins e cure form of communication. Pos tfix re place s Se ndmail as the de fault MTA in Re d Hat Ente rpris e Linux 7. It is re comme nde d that anyone planning to imple me nt a Pos tfix s e rve r addre s s the following is s ue s .

4.3.10.1. Limit ing a Denial of Service At t ack Be caus e of the nature of e mail, a de te rmine d attacke r can flood the s e rve r with mail fairly e as ily and caus e a de nial of s e rvice . The e ffe ctive ne s s of s uch attacks can be limite d by s e tting limits of the dire ctive s in the /etc/postfix/main.cf file . You can change the value of the dire ctive s which are alre ady the re or you can add the dire ctive s you ne e d with the value you want in the following format: = . The following is a lis t of dire ctive s that can be us e d for limiting a de nial of s e rvice attack: smtpd_client_connection_rate_limit — The maximum numbe r of conne ction atte mpts any clie nt is allowe d to make to this s e rvice pe r time unit (de s cribe d be low). The de fault value is 0, which me ans a clie nt can make as many conne ctions pe r time unit as Pos tfix can acce pt. By de fault, clie nts in trus te d ne tworks are e xclude d. anvil_rate_time_unit — This time unit is us e d for rate limit calculations . The de fault value is 60 s e conds . smtpd_client_event_limit_exceptions — Clie nts that are e xclude d from the conne ction and rate limit commands . By de fault, clie nts in trus te d ne tworks are e xclude d. smtpd_client_message_rate_limit — The maximum numbe r of me s s age de live rie s a clie nt is allowe d to re que s t pe r time unit (re gardle s s of whe the r or not Pos tfix actually acce pts thos e me s s age s ).

57

Se c ur it y Guide

default_process_limit — The de fault maximum numbe r of Pos tfix child proce s s e s that provide a give n s e rvice . This limit can be ove rrule d for s pe cific s e rvice s in the master.cf file . By de fault the value is 100. queue_minfree — The minimum amount of fre e s pace in byte s in the que ue file s ys te m that is ne e de d to re ce ive mail. This is curre ntly us e d by the Pos tfix SMTP s e rve r to de cide if it will acce pt any mail at all. By de fault, the Pos tfix SMTP s e rve r re je cts MAIL FROM commands whe n the amount of fre e s pace is le s s than 1.5 time s the me s s age _s iz e _limit. To s pe cify a highe r minimum fre e s pace limit, s pe cify a que ue _minfre e value that is at le as t 1.5 time s the me s s age _s iz e _limit. By de fault the que ue _minfre e value is 0. header_size_limit — The maximum amount of me mory in byte s for s toring a me s s age he ade r. If a he ade r is large r, the e xce s s is dis carde d. By de fault the value is 102400. message_size_limit — The maximum s iz e in byte s of a me s s age , including e nve lope information. By de fault the value is 10240000.

4.3.10.2. NFS and Post f ix Ne ve r put the mail s pool dire ctory, /var/spool/postfix/, on an NFS s hare d volume . Be caus e NFSv2 and NFSv3 do not maintain control ove r us e r and group IDs , two or more us e rs can have the s ame UID, and re ce ive and re ad e ach othe r's mail.

No te With NFSv4 us ing Ke rbe ros , this is not the cas e , s ince the SECRPC_GSS ke rne l module doe s not utiliz e UID-bas e d authe ntication. Howe ve r, it is s till cons ide re d good practice not to put the mail s pool dire ctory on NFS s hare d volume s .

4.3.10.3. Mail-only Users To he lp pre ve nt local us e r e xploits on the Pos tfix s e rve r, it is be s t for mail us e rs to only acce s s the Pos tfix s e rve r us ing an e mail program. She ll accounts on the mail s e rve r s hould not be allowe d and all us e r s he lls in the /etc/passwd file s hould be s e t to /sbin/nologin (with the pos s ible e xce ption of the root us e r).

4.3.10.4. Disable Post f ix Net work List ening By de fault, Pos tfix is s e t up to only lis te n to the local loopback addre s s . You can ve rify this by vie wing the file /etc/postfix/main.cf. Vie w the file /etc/postfix/main.cf to e ns ure that only the following inet_interfaces line appe ars : inet_interfaces = localhost This e ns ure s that Pos tfix only acce pts mail me s s age s (s uch as cron job re ports ) from the local s ys te m and not from the ne twork. This is the de fault s e tting and prote cts Pos tfix from a ne twork attack. For re moval of the localhos t re s triction and allowing Pos tfix to lis te n on all inte rface s the inet_interfaces = all s e tting can be us e d.

58

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

4.3.10.5. Conf iguring Post f ix t o Use SASL The Re d Hat Ente rpris e Linux 7 ve rs ion of Po st f ix can us e the Do veco t or Cyrus SASL imple me ntations for SMTP Authentication (or SMTP AUTH). SMTP Authe ntication is an e xte ns ion of the Simple Mail Transfer Protocol. Whe n e nable d, SMTP clie nts are re quire d to authe nticate to the SMTP s e rve r us ing an authe ntication me thod s upporte d and acce pte d by both the s e rve r and the clie nt. This s e ction de s cribe s how to configure Po st f ix to make us e of the Do veco t SASL imple me ntation. To ins tall the Do veco t POP/IMAP s e rve r, and thus make the Do veco t SASL imple me ntation available on your s ys te m, is s ue the following command as the root us e r: ~]# yum install dovecot The Po st f ix SMTP s e rve r can communicate with the Do veco t SASL imple me ntation us ing e ithe r a UNIX-domain socket or a TCP socket. The latte r me thod is only ne e de d in cas e the Po st f ix and Do veco t applications are running on s e parate machine s . This guide give s pre fe re nce to the UNIX-domain s ocke t me thod, which affords be tte r privacy. In orde r to ins truct Po st f ix to us e the Do veco t SASL imple me ntation, a numbe r of configuration change s ne e d to be pe rforme d for both applications . Follow the proce dure s be low to e ffe ct the s e change s . Set t ing Up Do veco t 1. Modify the main Do veco t configuration file , /etc/dovecot/conf.d/10master.conf, to include the following line s (the de fault configuration file alre ady include s mos t of the re le vant s e ction, and the line s jus t ne e d to be uncomme nte d): service auth { unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix } } The above e xample as s ume s the us e of UNIX-domain s ocke ts for communication be twe e n Po st f ix and Do veco t . It als o as s ume s de fault s e ttings of the Po st f ix SMTP s e rve r, which include the mail que ue locate d in the /var/spool/postfix/ dire ctory, and the application running unde r the postfix us e r and group. In this way, re ad and write pe rmis s ions are limite d to the postfix us e r and group. Alte rnative ly, you can us e the following configuration to s e t up Do veco t to lis te n for Po st f ix authe ntication re que s ts through TCP: service auth { inet_listener { port = 12345 } } In the above e xample , re place 12345 with the numbe r of the port you want to us e .

59

Se c ur it y Guide

2. Edit the /etc/dovecot/conf.d/10-auth.conf configuration file to ins truct Do veco t to provide the Po st f ix SMTP s e rve r with the plain and login authe ntication me chanis ms : auth_mechanisms = plain login Set t ing Up Po st f ix In the cas e of Po st f ix, only the main configuration file , /etc/postfix/main.cf, ne e ds to be modifie d. Add or e dit the following configuration dire ctive s : 1. Enable SMTP Authe ntication in the Po st f ix SMTP s e rve r: smtpd_sasl_auth_enable = yes 2. Ins truct Po st f ix to us e the Do veco t SASL imple me ntation for SMTP Authe ntication: smtpd_sasl_type = dovecot 3. Provide the authe ntication path re lative to the Po st f ix que ue dire ctory (note that the us e of a re lative path e ns ure s that the configuration works re gardle s s of whe the r the Po st f ix s e rve r runs in a chro o t or not): smtpd_sasl_path = private/auth This s te p as s ume s that you want to us e UNIX-domain s ocke ts for communication be twe e n Po st f ix and Do veco t . To configure Po st f ix to look for Do veco t on a diffe re nt machine in cas e you us e TCP s ocke ts for communication, us e configuration value s s imilar to the following: smtpd_sasl_path = inet:127.0.0.1:12345 In the above e xample , 127.0.0.1 ne e ds to be s ubs titute d by the IP addre s s of the Do veco t machine and 12345 by the port s pe cifie d in Do veco t 's /etc/dovecot/conf.d/10-master.conf configuration file . 4. Spe cify SASL me chanis ms that the Po st f ix SMTP s e rve r make s available to clie nts . Note that diffe re nt me chanis ms can be s pe cifie d for e ncrypte d and une ncrypte d s e s s ions . smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous The above e xample s pe cifie s that during une ncrypte d s e s s ions , no anonymous authe ntication is allowe d and no me chanis ms that trans mit une ncrypte d us e r name s or pas s words are allowe d. For e ncrypte d s e s s ions (us ing TLS), only nonanonymous authe ntication me chanis ms are allowe d. Se e http://www.pos tfix.org/SASL_README.html#s mtpd_s as l_s e curity_options for a lis t of all s upporte d policie s for limiting allowe d SASL me chanis ms . Addit io nal Reso urces

60

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

The following online re s ource s provide additional information us e ful for configuring Po st f ix SMTP Authe ntication through SASL. http://wiki2.dove cot.org/HowTo/Pos tfixAndDove cotSASL — Contains information on how to s e t up Po st f ix to us e the Do veco t SASL imple me ntation for SMTP Authe ntication. http://www.pos tfix.org/SASL_README.html#s e rve r_s as l — Contains information on how to s e t up Po st f ix to us e e ithe r the Do veco t or Cyrus SASL imple me ntations for SMTP Authe ntication.

4.3.11. Securing SSH Secure Shell (SSH) is a powe rful ne twork protocol us e d to communicate with anothe r s ys te m ove r a s e cure channe l. The trans mis s ions ove r SSH are e ncrypte d and prote cte d from inte rce ption. Se e the Ope nSSH chapte r of the Re d Hat Ente rpris e Linux 7 Sys te m Adminis trator's Guide for ge ne ral information about the SSH protocol and about us ing the SSH s e rvice in Re d Hat Ente rpris e Linux 7.

Impo rtant This s e ction draws atte ntion to the mos t common ways of s e curing an SSH s e tup. By no me ans s hould this lis t of s ugge s te d me as ure s be cons ide re d e xhaus tive or de finitive . Se e sshd_config(5) for a de s cription of all configuration dire ctive s available for modifying the be havior of the sshd dae mon and to ssh(1) for an e xplanation of bas ic SSH conce pts .

4.3.11.1. Crypt ographic Login SSH s upports the us e of cryptographic ke ys for logging in to compute rs . This is much more s e cure than us ing only a pas s word. If you combine this me thod with othe r authe ntication me thods , it can be cons ide re d a multi-factor authe ntication. Se e Se ction 4.3.11.2, “Multiple Authe ntication Me thods ” for more information about us ing multiple authe ntication me thods . In orde r to e nable the us e of cryptographic ke ys for authe ntication, the PubkeyAuthentication configuration dire ctive in the /etc/ssh/sshd_config file ne e ds to be s e t to yes. Note that this is the de fault s e tting. Se t the PasswordAuthentication dire ctive to no to dis able the pos s ibility of us ing pas s words for logging in. SSH ke ys can be ge ne rate d us ing the ssh-keygen command. If invoke d without additional argume nts , it cre ate s a 2048-bit RSA ke y s e t. The ke ys are s tore d, by de fault, in the ~/.ssh/ dire ctory. You can utiliz e the -b s witch to modify the bit-s tre ngth of the ke y. Us ing 2048-bit ke ys is normally s ufficie nt. The Configuring Ope nSSH chapte r in the Re d Hat Ente rpris e Linux 7 Sys te m Adminis trator's Guide include s de taile d information about ge ne rating ke y pairs . You s hould s e e the two ke ys in your ~/.ssh/ dire ctory. If you acce pte d the de faults whe n running the ssh-keygen command, the n the ge ne rate d file s are name d id_rsa and id_rsa.pub and contain the private and public ke y re s pe ctive ly. You s hould always prote ct the private ke y from e xpos ure by making it unre adable by anyone e ls e but the file 's owne r. The public ke y, howe ve r, ne e ds to be trans fe rre d to the s ys te m you are going to log in to. You can us e the ssh-copy-id command to trans fe r the ke y to the s e rve r: ~]$ ssh-copy-id -i [user@]server

61

Se c ur it y Guide

This command will als o automatically appe nd the public ke y to the ~/.ssh/authorized_keys file on the server. The sshd dae mon will che ck this file whe n you atte mpt to log in to the s e rve r. Similarly to pas s words and any othe r authe ntication me chanis m, you s hould change your SSH ke ys re gularly. Whe n you do, make s ure you re move any unus e d ke ys from the authorized_keys file .

4.3.11.2. Mult iple Aut hent icat ion Met hods Us ing multiple authe ntication me thods , or multi-factor authe ntication, incre as e s the le ve l of prote ction agains t unauthoriz e d acce s s , and as s uch s hould be cons ide re d whe n harde ning a s ys te m to pre ve nt it from be ing compromis e d. Us e rs atte mpting to log in to a s ys te m that us e s multi-factor authe ntication mus t s ucce s s fully comple te all s pe cifie d authe ntication me thods in orde r to be grante d acce s s . Us e the AuthenticationMethods configuration dire ctive in the /etc/ssh/sshd_config file to s pe cify which authe ntication me thods are to be utiliz e d. Note that it is pos s ible to de fine more than one lis t of re quire d authe ntication me thods us ing this dire ctive . If that is the cas e , the us e r mus t comple te e ve ry me thod in at le as t one of the lis ts . The lis ts ne e d to be s e parate d by blank s pace s , and the individual authe ntication-me thod name s within the lis ts mus t be comma-s e parate d. For e xample : AuthenticationMethods publickey,gssapi-with-mic publickey,keyboardinteractive An sshd dae mon configure d us ing the above AuthenticationMethods dire ctive only grants acce s s if the us e r atte mpting to log in s ucce s s fully comple te s e ithe r publickey authe ntication followe d by gssapi-with-mic or by keyboard-interactive authe ntication. Note that e ach of the re que s te d authe ntication me thods ne e ds to be e xplicitly e nable d us ing a corre s ponding configuration dire ctive (s uch as PubkeyAuthentication) in the /etc/ssh/sshd_config file . Se e the AUTHENTICATION s e ction of ssh(1) for a ge ne ral lis t of available authe ntication me thods .

4.3.11.3. Ot her Ways of Securing SSH Pro t o co l Versio n Eve n though the imple me ntation of the SSH protocol s upplie d with Re d Hat Ente rpris e Linux 7 s till s upports both the SSH-1 and SSH-2 ve rs ions of the protocol for SSH clie nts , only the latte r s hould be us e d whe ne ve r pos s ible . The SSH-2 ve rs ion contains a numbe r of improve me nts ove r the olde r SSH-1, and the majority of advance d configuration options is only available whe n us ing SSH-2. Re d Hat re comme nds us ing SSH-2 to maximiz e the e xte nt to which the SSH protocol prote cts the authe ntication and communication for which it is us e d. The ve rs ion or ve rs ions of the protocol s upporte d by the sshd dae mon can be s pe cifie d us ing the Protocol configuration dire ctive in the /etc/ssh/sshd_config file . The de fault s e tting is 2. Note that the SSH-2 ve rs ion is the only ve rs ion s upporte d by the Re d Hat Ente rpris e Linux 7 SSH s e rve r. Key T ypes

62

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

While the ssh-keygen command ge ne rate s a pair of SSH-2 RSA ke ys by de fault, us ing the -t option, it can be ins tructe d to ge ne rate DSA or ECDSA ke ys as we ll. The ECDSA (Elliptic Curve Digital Signature Algorithm) offe rs be tte r pe rformance at the s ame e quivale nt s ymme tric ke y le ngth. It als o ge ne rate s s horte r ke ys . No n-Def ault Po rt By de fault, the sshd dae mon lis te ns on TCP port 22. Changing the port re duce s the e xpos ure of the s ys te m to attacks bas e d on automate d ne twork s canning, thus incre as ing s e curity through obs curity. The port can be s pe cifie d us ing the Port dire ctive in the /etc/ssh/sshd_config configuration file . Note als o that the de fault SELinux policy mus t be change d to allow for the us e of a non-de fault port. You can do this by modifying the ssh_port_t SELinux type by typing the following command as root: ~]# semanage -a -t ssh_port_t -p tcp port_number In the above command, re place port_number with the ne w port numbe r s pe cifie d us ing the Port dire ctive . No Ro o t Lo gin Provide d that your particular us e cas e doe s not re quire the pos s ibility of logging in as the root us e r, you s hould cons ide r s e tting the PermitRootLogin configuration dire ctive to no in the /etc/ssh/sshd_config file . By dis abling the pos s ibility of logging in as the root us e r, the adminis trator can audit which us e r runs what privile ge d command afte r the y log in as re gular us e rs and the n gain root rights . Using t he ⁠X Securit y ext ensio n The X s e rve r in Re d Hat Ente rpris e Linux 7 clie nts doe s not provide the X Se curity e xte ns ion. The re fore clie nts cannot re que s t anothe r s e curity laye r whe n conne cting to untrus te d SSH s e rve rs with X11 forwarding. The mos t applications we re not able to run with this e xte ns ion e nable d anyway. By de fault, the ForwardX11Trusted option in the /etc/ssh/ssh_config file is s e t to yes, and the re is no diffe re nce be twe e n the ssh -X remote_machine (untrus te d hos t) and ssh -Y remote_machine (trus te d hos t) command.

Warning Re d Hat re comme nds not us ing X11 forwarding while conne cting to untrus te d hos ts .

4.3.12. Securing Post greSQL PostgreSQL is an Obje ct-Re lational databas e manage me nt s ys te m (DBMS). In Re d Hat Ente rpris e Linux 7, the postgresql-server package provide s Po st greSQL. If it is not ins talle d, e nte r the following command as the root us e r to ins tall it: ~]# yum install postgresql-server Be fore you can s tart us ing Po st greSQL, you mus t initializ e a databas e s torage are a on dis k. This is calle d a databas e clus te r. To initializ e a databas e clus te r, us e the command initdb, which is ins talle d with Po st greSQL. The de s ire d file s ys te m location of your databas e clus te r is indicate d by the -D option. For e xample :

63

Se c ur it y Guide

~]$ initdb -D /home/postgresql/db1 The initdb command will atte mpt to cre ate the dire ctory you s pe cify if it doe s not alre ady e xis t. We us e the name /home/postgresql/db1 in this e xample . The /home/postgresql/db1 dire ctory contains all the data s tore d in the databas e and als o the clie nt authe ntication configuration file : ~]$ cat pg_hba.conf # PostgreSQL Client Authentication Configuration File # This file controls: which hosts are allowed to connect, how clients # are authenticated, which PostgreSQL user names they can use, which # databases they can access. Records take one of these forms: # # local DATABASE USER METHOD [OPTIONS] # host DATABASE USER ADDRESS METHOD [OPTIONS] # hostssl DATABASE USER ADDRESS METHOD [OPTIONS] # hostnossl DATABASE USER ADDRESS METHOD [OPTIONS] The following line in the pg_hba.conf file allows any authe nticate d local us e rs to acce s s any databas e s with the ir us e r name s : local

all

all

trust

This can be proble matic whe n you us e laye re d applications that cre ate databas e us e rs and no local us e rs . If you do not want to e xplicitly control all us e r name s on the s ys te m, re move this line from the pg_hba.conf file .

4.3.13. Securing Docker Docker is an ope n s ource proje ct that automate s the de ployme nt of applications ins ide Linux Containe rs , and provide s the capability to package an application with its runtime de pe nde ncie s into a containe r. To make your Do cker workflow more s e cure , vis it Re d Hat Ente rpris e Linux Atomic Hos t 7 Containe r Se curity Guide .

4.4. Securing Net work Access 4.4.1. Securing Services Wit h T CP Wrappers and xinet d TCP Wrappe rs are capable of much more than de nying acce s s to s e rvice s . This s e ction illus trate s how the y can be us e d to s e nd conne ction banne rs , warn of attacks from particular hos ts , and e nhance logging functionality. Se e the hos ts _options (5) man page for information about the TCP Wrappe r functionality and control language . Se e the xine td.conf(5) man page for the available flags , which act as options you can apply to a s e rvice .

4.4.1.1. T CP Wrappers and Connect ion Banners Dis playing a s uitable banne r whe n us e rs conne ct to a s e rvice is a good way to le t pote ntial attacke rs know that the s ys te m adminis trator is be ing vigilant. You can als o control what information about the s ys te m is pre s e nte d to us e rs . To imple me nt a TCP Wrappe rs banne r for a s e rvice , us e the banner option.

64

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

This e xample imple me nts a banne r for vsftpd. To be gin, cre ate a banne r file . It can be anywhe re on the s ys te m, but it mus t have s ame name as the dae mon. For this e xample , the file is calle d /etc/banners/vsftpd and contains the following line s : 220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed. The %c toke n s upplie s a varie ty of clie nt information, s uch as the us e r name and hos t name , or the us e r name and IP addre s s to make the conne ction e ve n more intimidating. For this banne r to be dis playe d to incoming conne ctions , add the following line to the /etc/hosts.allow file : vsftpd : ALL : banners /etc/banners/

4.4.1.2. T CP Wrappers and At t ack Warnings If a particular hos t or ne twork has be e n de te cte d attacking the s e rve r, TCP Wrappe rs can be us e d to warn the adminis trator of s ubs e que nt attacks from that hos t or ne twork us ing the spawn dire ctive . In this e xample , as s ume that a cracke r from the 206.182.68.0/24 ne twork has be e n de te cte d atte mpting to attack the s e rve r. Place the following line in the /etc/hosts.deny file to de ny any conne ction atte mpts from that ne twork, and to log the atte mpts to a s pe cial file : ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert The %d toke n s upplie s the name of the s e rvice that the attacke r was trying to acce s s . To allow the conne ction and log it, place the spawn dire ctive in the /etc/hosts.allow file .

No te Be caus e the spawn dire ctive e xe cute s any s he ll command, it is a good ide a to cre ate a s pe cial s cript to notify the adminis trator or e xe cute a chain of commands in the e ve nt that a particular clie nt atte mpts to conne ct to the s e rve r.

4.4.1.3. T CP Wrappers and Enhanced Logging If ce rtain type s of conne ctions are of more conce rn than othe rs , the log le ve l can be e le vate d for that s e rvice us ing the severity option. For this e xample , as s ume that anyone atte mpting to conne ct to port 23 (the Te lne t port) on an FTP s e rve r is a cracke r. To de note this , place an emerg flag in the log file s ins te ad of the de fault flag, info, and de ny the conne ction. To do this , place the following line in /etc/hosts.deny: in.telnetd : ALL : severity emerg

65

Se c ur it y Guide

This us e s the de fault authpriv logging facility, but e le vate s the priority from the de fault value of info to emerg, which pos ts log me s s age s dire ctly to the cons ole .

4.4.2. Verif ying Which Port s Are List ening It is important to clos e unus e d ports to avoid pos s ible attacks . For une xpe cte d ports in lis te ning s tate , you s hould inve s tigate for pos s ible s igns of intrus ion.

Using net st at f or Open Port s Scan Ente r the following command as root to de te rmine which ports are lis te ning for conne ctions from the ne twork: ~]# netstat -pan -A inet,inet6 | grep -v ESTABLISHED Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd tcp 0 0 192.168.124.1:53 0.0.0.0:* LISTEN 1829/dnsmasq tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1176/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1177/cupsd tcp6 0 0 :::111 :::* LISTEN 1/systemd tcp6 0 0 ::1:25 :::* LISTEN 1664/master sctp 0.0.0.0:2500 LISTEN 20985/sctp_darn udp 0 0 192.168.124.1:53 0.0.0.0:* 1829/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 977/dhclient ... Us e the -l option of the netstat command to dis play only lis te ning s e rve r s ocke ts : ~]# netstat -tlnw Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address State tcp 0 0 0.0.0.0:111 LISTEN tcp 0 0 192.168.124.1:53 LISTEN tcp 0 0 0.0.0.0:22 LISTEN tcp 0 0 127.0.0.1:631 LISTEN

66

Foreign Address 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:*

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

tcp LISTEN tcp6 LISTEN tcp6 LISTEN tcp6 LISTEN tcp6 LISTEN raw6

0

0 127.0.0.1:25

0.0.0.0:*

0

0 :::111

:::*

0

0 :::22

:::*

0

0 ::1:631

:::*

0

0 ::1:25

:::*

0

0 :::58

:::*

7

Using ss f or Open Port s Scan Alte rnative ly, us e the ss utility to lis t ope n ports in the lis te ning s tate . It can dis play more TCP and s tate information than net st at . ~]# ss -tlw etid State Recv-Q Send-Q Peer Address:Port udp UNCONN 0 0 :::* tcp LISTEN 0 128 *:* tcp LISTEN 0 5 *:* tcp LISTEN 0 128 *:* tcp LISTEN 0 128 *:* tcp LISTEN 0 100 *:* tcp LISTEN 0 128 :::* tcp LISTEN 0 128 :::* tcp LISTEN 0 128 :::* tcp LISTEN 0 100 :::*

Local Address:Port :::ipv6-icmp *:sunrpc 192.168.124.1:domain *:ssh 127.0.0.1:ipp 127.0.0.1:smtp :::sunrpc :::ssh ::1:ipp ::1:smtp

~]# ss -plno -A tcp,udp,sctp Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port udp UNCONN 0 0 192.168.124.1:53 *:* users:(("dnsmasq",pid=1829,fd=5)) udp UNCONN 0 0 *%virbr0:67 *:* users:(("dnsmasq",pid=1829,fd=3)) udp UNCONN 0 0 *:68 *:* users:(("dhclient",pid=977,fd=6)) ... tcp LISTEN 0 5 192.168.124.1:53 *:* users:(("dnsmasq",pid=1829,fd=6)) tcp LISTEN 0 128 *:22 *:* users:(("sshd",pid=1176,fd=3))

67

Se c ur it y Guide

tcp *:* tcp *:* ... sctp *:*

LISTEN

0

LISTEN

0

LISTEN

0

128 127.0.0.1:631 users:(("cupsd",pid=1177,fd=12)) 100 127.0.0.1:25 users:(("master",pid=1664,fd=13)) 5 *:2500 users:(("sctp_darn",pid=20985,fd=3))

The UNCONN s tate s hows the ports in UDP lis te ning mode . Make a s can for e ve ry IP addre s s s hown in the ss output (e xce pt for localhos t 127.0.0.0 or ::1 range ) from an e xte rnal s ys te m. Us e the -6 option for s canning an IPv6 addre s s . Proce e d the n to make e xte rnal che cks us ing the nmap tool from anothe r re mote machine conne cte d through the ne twork to the firs t s ys te m. This can be us e d to ve rify rule s in f irewalld. The following is an e xample to de te rmine which ports are lis te ning for TCP conne ctions : ~]# nmap -sT -O 192.168.122.65 Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-27 09:30 CEST Nmap scan report for 192.168.122.65 Host is up (0.00032s latency). Not shown: 998 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind Device type: general purpose Running: Linux 3.X OS CPE: cpe:/o:linux:linux_kernel:3 OS details: Linux 3.7 - 3.9 Network Distance: 0 hops OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.79 seconds The TCP conne ct s can (-sT) is the de fault TCP s can type whe n the TCP SYN s can (-sS) is not an option. The -O option de te cts the ope rating s ys te m of the hos t.

Using net st at and ss t o Scan f or Open SCT P Port s The net st at utility prints information about the Linux ne tworking s ubs ys te m. To dis play protocol s tatis tics for ope n Stre am Control Trans mis s ion Protocol (SCTP) ports , e nte r the following command as root: ~]# netstat -plnS Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address PID/Program name sctp 127.0.0.1:250 4125/sctp_darn sctp 0 0 127.0.0.1:260 127.0.0.1:250 4250/sctp_darn sctp 0 0 127.0.0.1:250 127.0.0.1:260 4125/sctp_darn

68

State LISTEN CLOSE LISTEN

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

~]# netstat -nl -A inet,inet6 | grep 2500 sctp 0.0.0.0:2500 LISTEN The ss utility is als o able to s how SCTP ope n ports : ~]# ss -an | grep 2500 sctp LISTEN 0

5

*:2500

*:*

Se e the s s (8), ne ts tat(8), nmap(1), and s e rvice s (5) manual page s for more information.

4.4.3. Disabling Source Rout ing Source routing is an Inte rne t Protocol me chanis m that allows an IP packe t to carry information, a lis t of addre s s e s , that te lls a route r the path the packe t mus t take . The re is als o an option to re cord the hops as the route is trave rs e d. The lis t of hops take n, the "route re cord", provide s the de s tination with a re turn path to the s ource . This allows the s ource (the s e nding hos t) to s pe cify the route , loos e ly or s trictly, ignoring the routing table s of s ome or all of the route rs . It can allow a us e r to re dire ct ne twork traffic for malicious purpos e s . The re fore , s ource -bas e d routing s hould be dis able d. The accept_source_route option caus e s ne twork inte rface s to acce pt packe ts with the Strict Source Routing (SSR) or Loose Source Routing (LSR) option s e t. The acce ptance of s ource route d packe ts is controlle d by s ys ctl s e ttings . Is s ue the following command as root to drop packe ts with the SSR or LSR option s e t: ~]# /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0 Dis abling the forwarding of packe ts s hould als o be done in conjunction with the above whe n pos s ible (dis abling forwarding may inte rfe re with virtualiz ation). Is s ue the commands lis te d be low as root: The s e commands dis able forwarding of IPv4 and IPv6 packe ts on all inte rface s . ~]# /sbin/sysctl -w net.ipv4.conf.all.forwarding=0 ~]# /sbin/sysctl -w net.ipv6.conf.all.forwarding=0 The s e commands dis able forwarding of all multicas t packe ts on all inte rface s . ~]# /sbin/sysctl -w net.ipv4.conf.all.mc_forwarding=0 ~]# /sbin/sysctl -w net.ipv6.conf.all.mc_forwarding=0 Acce pting ICMP re dire cts has fe w le gitimate us e s . Dis able the acce ptance and s e nding of ICMP re dire cte d packe ts unle s s s pe cifically re quire d. The s e commands dis able acce ptance of all ICMP re dire cte d packe ts on all inte rface s . ~]# /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0 ~]# /sbin/sysctl -w net.ipv6.conf.all.accept_redirects=0

69

Se c ur it y Guide

This command dis able s acce ptance of s e cure ICMP re dire cte d packe ts on all inte rface s . ~]# /sbin/sysctl -w net.ipv4.conf.all.secure_redirects=0 This command dis able s acce ptance of all IPv4 ICMP re dire cte d packe ts on all inte rface s . ~]# /sbin/sysctl -w net.ipv4.conf.all.send_redirects=0 The re is only a dire ctive to dis able s e nding of IPv4 re dire cte d packe ts . Se e RFC4294 for an e xplanation of “IPv6 Node Re quire me nts ” which re s ulte d in this diffe re nce be twe e n IPv4 and IPv6.

No te To make the s e s e ttings pe rs is te nt acros s re boots , modify the /etc/sysctl.conf file . For e xample , to dis able acce ptance of all IPv4 ICMP re dire cte d packe ts on all inte rface s , ope n the /etc/sysctl.conf file with an e ditor running as the root us e r and add a line as follows : net.ipv4.conf.all.send_redirects=0

Se e the s ys ctl man page , sysctl(8), for more information. Se e RFC791 for an e xplanation of the Inte rne t options re late d to s ource bas e d routing and its variants .

Warning Ethe rne t ne tworks provide additional ways to re dire ct traffic, s uch as ARP or MAC addre s s s poofing, unauthoriz e d DHCP s e rve rs , and IPv6 route r or ne ighbor adve rtis e me nts . In addition, unicas t traffic is occas ionally broadcas t, caus ing information le aks . The s e we akne s s e s can only be addre s s e d by s pe cific counte rme as ure s imple me nte d by the ne twork ope rator. Hos t-bas e d counte rme as ure s are not fully e ffe ctive .

4.4.3.1. Reverse Pat h Forwarding Re ve rs e Path Forwarding is us e d to pre ve nt packe ts that arrive d through one inte rface from le aving through a diffe re nt inte rface . Whe n outgoing route s and incoming route s are diffe re nt, it is s ome time s re fe rre d to as asymmetric routing. Route rs ofte n route packe ts this way, but mos t hos ts s hould not ne e d to do this . Exce ptions are s uch applications that involve s e nding traffic out ove r one link and re ce iving traffic ove r anothe r link from a diffe re nt s e rvice provide r. For e xample , us ing le as e d line s in combination with xDSL or s ate llite links with 3G mode ms . If s uch a s ce nario is applicable to you, the n turning off re ve rs e path forwarding on the incoming inte rface is ne ce s s ary. In s hort, unle s s you know that it is re quire d, it is be s t e nable d as it pre ve nts us e rs s poofing IP addre s s e s from local s ubne ts and re duce s the opportunity for DDoS attacks .

70

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

No te Re d Hat Ente rpris e Linux 7 de faults to us ing Strict Reverse Path Forwarding following the Strict Re ve rs e Path re comme ndation from RFC 3704, Ingre s s Filte ring for Multihome d Ne tworks ..

Warning If forwarding is e nable d, the n Re ve rs e Path Forwarding s hould only be dis able d if the re are othe r me ans for s ource -addre s s validation (s uch as ipt ables rule s for e xample ). rp_filter Re ve rs e Path Forwarding is e nable d by me ans of the rp_filter dire ctive . The sysctl utility can be us e d to make change s to the running s ys te m, and pe rmane nt change s can be made by adding line s to the /etc/sysctl.conf file . The rp_filter option is us e d to dire ct the ke rne l to s e le ct from one of thre e mode s . To make a te mporary global change , e nte r the following commands as root: sysctl -w net.ipv4.conf.default.rp_filter=integer sysctl -w net.ipv4.conf.all.rp_filter=integer whe re integer is one of the following: 0 — No s ource validation. 1 — Strict mode as de fine d in RFC 3704. 2 — Loos e mode as de fine d in RFC 3704. The s e tting can be ove rridde n pe r ne twork inte rface us ing the net.ipv4.conf.interface.rp_filter command as follows : sysctl -w net.ipv4.conf.interface.rp_filter=integer

No te To make the s e s e ttings pe rs is te nt acros s re boots , modify the /etc/sysctl.conf file . For e xample , to change the mode for all inte rface s , ope n the /etc/sysctl.conf file with an e ditor running as the root us e r and add a line as follows : net.ipv4.conf.all.rp_filter=2

IPv6_rpfilter

71

Se c ur it y Guide

In cas e of the IPv6 protocol the f irewalld dae mon applie s to Re ve rs e Path Forwarding by de fault. The s e tting can be che cke d in the /etc/firewalld/firewalld.conf file . You can change the f irewalld be havior by s e tting the IPv6_rpfilter option. If you ne e d a cus tom configuration of Re ve rs e Path Forwarding, you can pe rform it without the f irewalld dae mon by us ing the ip6tables command as follows : ip6tables -t raw -I PREROUTING -m rpfilter --invert -j DROP This rule s hould be ins e rte d ne ar the be ginning of the raw/PREROUTING chain, s o that it applie s to all traffic, in particular be fore the s tate ful matching rule s . For more information about the iptables and ip6tables s e rvice s , s e e Se ction 5.4, “Us ing the iptable s Se rvice ”. Enabling Packet Fo rwarding To e nable packe ts arriving from outs ide of a s ys te m to be forwarde d to anothe r e xte rnal hos t, IP forwarding mus t be e nable d in the ke rne l. Log in as root and change the line which re ads net.ipv4.ip_forward = 0 in the /etc/sysctl.conf file to the following: net.ipv4.ip_forward = 1 To load the change s from the /etc/sysctl.conf file , e nte r the following command: /sbin/sysctl -p To che ck if IP forwarding is turne d on, is s ue the following command as root: /sbin/sysctl net.ipv4.ip_forward If the above command re turns a 1, the n IP forwarding is e nable d. If it re turns a 0, the n you can turn it on manually us ing the following command: /sbin/sysctl -w net.ipv4.ip_forward=1

4.4.3.2. Addit ional Resources The following are re s ource s which e xplain more about Re ve rs e Path Forwarding. Inst alled Do cument at io n /usr/share/doc/kernel-doc-version/Documentation/networking/ip-sysctl.txt This file contains a comple te lis t of file s and options available in the dire ctory. Be fore acce s s ing the ke rne l docume ntation for the firs t time , e nte r the following command as root: ~]# yum install kernel-doc Online Do cument at io n Se e RFC 3704 for an e xplanation of Ingre s s Filte ring for Multihome d Ne tworks .

4.5. Securing DNS T raffic wit h DNSSEC 72

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

4.5. Securing DNS T raffic wit h DNSSEC 4.5.1. Int roduct ion t o DNSSEC DNSSEC is a s e t of Domain Name System Security Extensions (DNSSEC) that e nable s a DNS clie nt to authe nticate and che ck the inte grity of re s pons e s from a DNS name s e rve r in orde r to ve rify the ir origin and to de te rmine if the y have be e n tampe re d with in trans it.

4.5.2. Underst anding DNSSEC For conne cting ove r the Inte rne t, a growing numbe r of we bs ite s now offe r the ability to conne ct s e cure ly us ing HTTPS. Howe ve r, be fore conne cting to an HTTPS we bs e rve r, a DNS lookup mus t be pe rforme d, unle s s you e nte r the IP addre s s dire ctly. The s e DNS lookups are done ins e cure ly and are s ubje ct to man-in-the-middle attacks due to lack of authe ntication. In othe r words , a DNS clie nt cannot have confide nce that the re plie s that appe ar to come from a give n DNS name s e rve r are authe ntic and have not be e n tampe re d with. More importantly, a re curs ive name s e rve r cannot be s ure that the re cords it obtains from othe r name s e rve rs are ge nuine . The DNS protocol did not provide a me chanis m for the clie nt to e ns ure it was not s ubje ct to a man-in-the -middle attack. DNSSEC was introduce d to addre s s the lack of authe ntication and inte grity che cks whe n re s olving domain name s us ing DNS. It doe s not addre s s the proble m of confide ntiality. Publis hing DNSSEC information involve s digitally s igning DNS re s ource re cords as we ll as dis tributing public ke ys in s uch a way as to e nable DNS re s olve rs to build a hie rarchical chain of trus t. Digital s ignature s for all DNS re s ource re cords are ge ne rate d and adde d to the z one as digital s ignature re s ource re cords (RRSIG). The public ke y of a z one is adde d as a DNSKEY re s ource re cord. To build the hie rarchical chain, has he s of the DNSKEY are publis he d in the pare nt z one as Delegation of Signing (DS) re s ource re cords . To facilitate proof of non-e xis te nce , the NextSECure (NSEC) and NSEC3 re s ource re cords are us e d. In a DNSSEC s igne d z one , e ach resource record set (RRs e t) has a corre s ponding RRSIG re s ource re cord. Note that re cords us e d for de le gation to a child z one (NS and glue re cords ) are not s igne d; the s e re cords appe ar in the child z one and are s igne d the re . Proce s s ing DNSSEC information is done by re s olve rs that are configure d with the root z one public ke y. Us ing this ke y, re s olve rs can ve rify the s ignature s us e d in the root z one . For e xample , the root z one has s igne d the DS re cord for .com. The root z one als o s e rve s NS and glue re cords for the .com name s e rve rs . The re s olve r follows this de le gation and que rie s for the DNSKEY re cord of .com us ing the s e de le gate d name s e rve rs . The has h of the DNSKEY re cord obtaine d s hould match the DS re cord in the root z one . If s o, the re s olve r will trus t the obtaine d DNSKEY for .com. In the .com z one , the RRSIG re cords are cre ate d by the .com DNSKEY. This proce s s is re pe ate d s imilarly for de le gations within .com, s uch as redhat.com. Us ing this me thod, a validating DNS re s olve r only ne e ds to be configure d with one root ke y while it colle cts many DNSKEYs from around the world during its normal ope ration. If a cryptographic che ck fails , the re s olve r will re turn SERVFAIL to the application. DNSSEC has be e n de s igne d in s uch a way that it will be comple te ly invis ible to applications not s upporting DNSSEC. If a non-DNSSEC application que rie s a DNSSEC capable re s olve r, it will re ce ive the ans we r without any of the s e ne w re s ource re cord type s s uch as RRSIG. Howe ve r, the DNSSEC capable re s olve r will s till pe rform all cryptographic che cks , and will s till re turn a SERVFAIL e rror to the application if it de te cts malicious DNS ans we rs . DNSSEC prote cts the inte grity of the data be twe e n DNS s e rve rs (authoritative and re curs ive ), it doe s not provide s e curity be twe e n the application and the re s olve r. The re fore , it is important that the applications are give n a s e cure trans port to the ir re s olve r. The e as ie s t way to accomplis h that is to run a DNSSEC capable re s olve r on localhost and us e 127.0.0.1 in /etc/resolv.conf. Alte rnative ly a VPN conne ction to a re mote DNS s e rve r could be us e d.

73

Se c ur it y Guide

Underst anding t he Hot spot Problem Wi-Fi Hots pots or VPNs re ly on “DNS lie s ”: Captive portals te nd to hijack DNS in orde r to re dire ct us e rs to a page whe re the y are re quire d to authe nticate (or pay) for the Wi-Fi s e rvice . Us e rs conne cting to a VPN ofte n ne e d to us e an “inte rnal only” DNS s e rve r in orde r to locate re s ource s that do not e xis t outs ide the corporate ne twork. This re quire s additional handling by s oftware . For e xample , dnssec-t rigger can be us e d to de te ct if a Hots pot is hijacking the DNS que rie s and unbound can act as a proxy name s e rve r to handle the DNSSEC que rie s .

Choosing a DNSSEC Capable Recursive Resolver To de ploy a DNSSEC capable re curs ive re s olve r, e ithe r BIND or unbound can be us e d. Both e nable DNSSEC by de fault and are configure d with the DNSSEC root ke y. To e nable DNSSEC on a s e rve r, e ithe r will work howe ve r the us e of unbound is pre fe rre d on mobile de vice s , s uch as note books , as it allows the local us e r to dynamically re configure the DNSSEC ove rride s re quire d for Hots pots whe n us ing dnssec-t rigger, and for VPNs whe n us ing Libreswan. The unbound dae mon furthe r s upports the de ployme nt of DNSSEC e xce ptions lis te d in the etc/unbound/*.d/ dire ctorie s which can be us e ful to both s e rve rs and mobile de vice s .

4.5.3. Underst anding Dnssec-t rigger Once unbound is ins talle d and configure d in /etc/resolv.conf, all DNS que rie s from applications are proce s s e d by unbound. dnssec-t rigger only re configure s the unbound re s olve r whe n trigge re d to do s o. This mos tly applie s to roaming clie nt machine s , s uch as laptops , that conne ct to diffe re nt Wi-Fi ne tworks . The proce s s is as follows : Net wo rkManager “trigge rs ” dnssec-t rigger whe n a ne w DNS s e rve r is obtaine d through DHCP. Dnssec-t rigger the n pe rforms a numbe r of te s ts agains t the s e rve r and de cide s whe the r or not it prope rly s upports DNSSEC. If it doe s , the n dnssec-t rigger re configure s unbound to us e that DNS s e rve r as a forwarde r for all que rie s . If the te s ts fail, dnssec-t rigger will ignore the ne w DNS s e rve r and try a fe w available fall-back me thods . If it de te rmine s that an unre s tricte d port 53 (UDP and TCP) is available , it will te ll unbound to be come a full re curs ive DNS s e rve r without us ing any forwarde r. If this is not pos s ible , for e xample be caus e port 53 is blocke d by a fire wall for e ve rything e xce pt re aching the ne twork's DNS s e rve r its e lf, it will try to us e DNS to port 80, or TLS e ncaps ulate d DNS to port 443. Se rve rs running DNS on port 80 and 443 can be configure d in /etc/dnssec-trigger/dnssec-trigger.conf. Comme nte d out e xample s s hould be available in the de fault configuration file . If the s e fall-back me thods als o fail, dnssec-t rigger offe rs to e ithe r ope rate ins e cure ly, which would bypas s DNSSEC comple te ly, or run in “cache only” mode whe re it will not atte mpt ne w DNS que rie s but will ans we r for e ve rything it alre ady has in the cache . Wi-Fi Hots pots incre as ingly re dire ct us e rs to a s ign-on page be fore granting acce s s to the Inte rne t. During the probing s e que nce outline d above , if a re dire ction is de te cte d, the us e r is prompte d to as k if a login is re quire d to gain Inte rne t acce s s . The dnssec-trigger

74

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

dae mon continue s to probe for DNSSEC re s olve rs e ve ry te n s e conds . Se e Se ction 4.5.8, “Us ing Dns s e c-trigge r” for information on us ing the dnssec-t rigger graphical utility.

4.5.4. VPN Supplied Domains and Name Servers Some type s of VPN conne ctions can conve y a domain and a lis t of name s e rve rs to us e for that domain as part of the VPN tunne l s e tup. On Red Hat Ent erprise Linux, this is s upporte d by Net wo rkManager. This me ans that the combination of unbound, dnssect rigger, and Net wo rkManager can prope rly s upport domains and name s e rve rs provide d by VPN s oftware . Once the VPN tunne l come s up, the local unbound cache is flus he d for all e ntrie s of the domain name re ce ive d, s o that que rie s for name s within the domain name are fe tche d fre s h from the inte rnal name s e rve rs re ache d us ing the VPN. Whe n the VPN tunne l is te rminate d, the unbound cache is flus he d again to e ns ure any que rie s for the domain will re turn the public IP addre s s e s , and not the pre vious ly obtaine d private IP addre s s e s . Se e Se ction 4.5.11, “Configuring DNSSEC Validation for Conne ction Supplie d Domains ”.

4.5.5. Recommended Naming Pract ices Re d Hat re comme nds that both s tatic and trans ie nt name s match the fully-qualified domain name (FQDN) us e d for the machine in DNS, s uch as host.example.com. The Inte rne t Corporation for As s igne d Name s and Numbe rs (ICANN) s ome time s adds pre vious ly unre gis te re d Top-Le ve l Domains (s uch as .yourcompany) to the public re gis te r. The re fore , Re d Hat s trongly re comme nds that you do not us e a domain name that is not de le gate d to you, e ve n on a private ne twork, as this can re s ult in a domain name that re s olve s diffe re ntly de pe nding on ne twork configuration. As a re s ult, ne twork re s ource s can be come unavailable . Us ing domain name s that are not de le gate d to you als o make s DNSSEC more difficult to de ploy and maintain, as domain name collis ions re quire manual configuration to e nable DNSSEC validation. Se e the ICANN FAQ on domain name collis ion for more information on this is s ue .

4.5.6. Underst anding T rust Anchors In a hie rarchical cryptographic s ys te m, a trust anchor is an authoritative e ntity which is as s ume d to be trus tworthy. For e xample , in X.509 archite cture , a root ce rtificate is a trus t anchor from which a chain of trus t is de rive d. The trus t anchor mus t be put in the pos s e s s ion of the trus ting party be fore hand to make path validation pos s ible . In the conte xt of DNSSEC, a trus t anchor cons is ts of a DNS name and public ke y (or has h of the public ke y) as s ociate d with that name . It is e xpre s s e d as a bas e 64 e ncode d ke y. It is s imilar to a ce rtificate in that it is a me ans of e xchanging information, including a public ke y, which can be us e d to ve rify and authe nticate DNS re cords . RFC 4033 de fine s a trus t anchor as a configure d DNSKEY RR or DS RR has h of a DNSKEY RR. A validating s e curityaware re s olve r us e s this public ke y or has h as a s tarting point for building the authe ntication chain to a s igne d DNS re s pons e . In ge ne ral, a validating re s olve r will have to obtain the initial value s of its trus t anchors through s ome s e cure or trus te d me ans outs ide the DNS protocol. Pre s e nce of a trus t anchor als o implie s that the re s olve r s hould e xpe ct the z one to which the trus t anchor points to be s igne d.

4.5.7. Inst alling DNSSEC 4.5.7.1. Inst alling unbound In orde r to validate DNS us ing DNSSEC locally on a machine , it is ne ce s s ary to ins tall the

75

Se c ur it y Guide

DNS re s olve r unbound (or bind ). It is only ne ce s s ary to ins tall dnssec-t rigger on mobile de vice s . For s e rve rs , unbound s hould be s ufficie nt although a forwarding configuration for the local domain might be re quire d de pe nding on whe re the s e rve r is locate d (LAN or Inte rne t). dnssec-t rigger will curre ntly only he lp with the global public DNS z one . Net wo rkManager, dhclient , and VPN applications can ofte n gathe r the domain lis t (and name s e rve r lis t as we ll) automatically, but not dnssec-t rigger nor unbo und. To ins tall unbound e nte r the following command as the root us e r: ~]# yum install unbound

4.5.7.2. Checking if unbound is Running To de te rmine whe the r the unbound dae mon is running, e nte r the following command: ~]$ systemctl status unbound unbound.service - Unbound recursive Domain Name Server Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled) Active: active (running) since Wed 2013-03-13 01:19:30 CET; 6h ago The systemctl status command will re port unbound as Active: inactive (dead) if the unbound s e rvice is not running.

4.5.7.3. St art ing unbound To s tart the unbound dae mon for the curre nt s e s s ion, e nte r the following command as the root us e r: ~]# systemctl start unbound Run the systemctl enable command to e ns ure that unbound s tarts up e ve ry time the s ys te m boots : ~]# systemctl enable unbound The unbound dae mon allows configuration of local data or ove rride s us ing the following dire ctorie s : The /etc/unbound/conf.d dire ctory is us e d to add configurations for a s pe cific domain name . This is us e d to re dire ct que rie s for a domain name to a s pe cific DNS s e rve r. This is ofte n us e d for s ub-domains that only e xis t within a corporate WAN. The /etc/unbound/keys.d dire ctory is us e d to add trus t anchors for a s pe cific domain name . This is re quire d whe n an inte rnal-only name is DNSSEC s igne d, but the re is no publicly e xis ting DS re cord to build a path of trus t. Anothe r us e cas e is whe n an inte rnal ve rs ion of a domain is s igne d us ing a diffe re nt DNSKEY than the publicly available name outs ide the corporate WAN. The /etc/unbound/local.d dire ctory is us e d to add s pe cific DNS data as a local ove rride . This can be us e d to build blacklis ts or cre ate manual ove rride s . This data will be re turne d to clie nts by unbound, but it will not be marke d as DNSSEC s igne d. Net wo rkManager, as we ll as s ome VPN s oftware , may change the configuration dynamically. The s e configuration dire ctorie s contain comme nte d out e xample e ntrie s . For furthe r information s e e the unbound.conf(5) man page .

76

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

4.5.7.4. Inst alling Dnssec-t rigger The dnssec-t rigger application runs as a dae mon, dnssec-triggerd. To ins tall dnssect rigger e nte r the following command as the root us e r: ~]# yum install dnssec-trigger

4.5.7.5. Checking if t he Dnssec-t rigger Daemon is Running To de te rmine whe the r dnssec-triggerd is running, e nte r the following command: ~]$ systemctl status dnssec-triggerd systemctl status dnssec-triggerd.service dnssec-triggerd.service - Reconfigure local DNS(SEC) resolver on network change Loaded: loaded (/usr/lib/systemd/system/dnssec-triggerd.service; enabled) Active: active (running) since Wed 2013-03-13 06:10:44 CET; 1h 41min ago The systemctl status command will re port dnssec-triggerd as Active: inactive (dead) if the dnssec-triggerd dae mon is not running. To s tart it for the curre nt s e s s ion e nte r the following command as the root us e r: ~]# systemctl start dnssec-triggerd Run the systemctl enable command to e ns ure that dnssec-triggerd s tarts up e ve ry time the s ys te m boots : ~]# systemctl enable dnssec-triggerd

4.5.8. Using Dnssec-t rigger The dnssec-t rigger application has a GNOME pane l utility for dis playing DNSSEC probe re s ults and for pe rforming DNSSEC probe re que s ts on de mand. To s tart the utility, pre s s the Super ke y to e nte r the Activitie s Ove rvie w, type DNSSEC and the n pre s s Enter. An icon re s e mbling a s hips anchor is adde d to the me s s age tray at the bottom of the s cre e n. Pre s s the round blue notification icon in the bottom right of the s cre e n to re ve al it. Right click the anchor icon to dis play a pop-up me nu. In normal ope rations unbo und is us e d locally as the name s e rve r, and resolv.conf points to 127.0.0.1. Whe n you click OK on the Hotspot Sign-On pane l this is change d. The DNS s e rve rs are que rie d from Net wo rkManager and put in resolv.conf. Now you can authe nticate on the Hots pot's s ign-on page . The anchor icon s hows a big re d e xclamation mark to warn you that DNS que rie s are be ing made ins e cure ly. Whe n authe nticate d, dnssec-t rigger s hould automatically de te ct this and s witch back to s e cure mode , although in s ome cas e s it cannot and the us e r has to do this manually by s e le cting Reprobe. Dnssec-t rigger doe s not normally re quire any us e r inte raction. Once s tarte d, it works in the background and if a proble m is e ncounte re d it notifie s the us e r by me ans of a pop-up te xt box. It als o informs unbound about change s to the resolv.conf file .

4.5.9. Using dig Wit h DNSSEC

77

Se c ur it y Guide

4.5.9. Using dig Wit h DNSSEC To s e e whe the r DNSSEC is working, one can us e various command line tools . The be s t tool to us e is the dig command from the bind-utils package . Othe r tools that are us e ful are drill from the ldns package and unbo und-ho st from the unbound package . The old DNS utilitie s nslo o kup and ho st are obs ole te and s hould not be us e d. To s e nd a que ry re que s ting DNSSEC data us ing dig, the option +dnssec is adde d to the command, for e xample : ~]$ dig +dnssec whitehouse.gov ; DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-4.P2.el7 +dnssec whitehouse.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADERHEADERHEADER kmk.blob To load the trus te d ke y from the us e r-s pace blob, us e the add command again with the blob as an argume nt: ~]$ keyctl add trusted kmk "load `cat kmk.blob`" @u 268728824 The TPM-s e ale d trus te d ke y can the n be e mploye d to cre ate s e cure e ncrypte d ke ys . The following command s yntax is us e d for ge ne rating e ncrypte d ke ys :

113

Se c ur it y Guide

~]$ keyctl add encrypted name "new [format] key-type:master-key-name keylength" keyring Bas e d on the above s yntax, a command for ge ne rating an e ncrypte d ke y us ing the alre ady cre ate d trus te d ke y can be cons tructe d as follows : ~]$ keyctl add encrypted encr-key "new trusted:kmk 32" @u 159771175 To cre ate an e ncrypte d ke y on s ys te ms whe re a TPM is not available , us e a random s e que nce of numbe rs to ge ne rate a us e r ke y, which is the n us e d to s e al the actual e ncrypte d ke ys . ~]$ keyctl add user kmk-user "`dd if=/dev/urandom bs=1 count=32 2>/dev/null`" @u 427069434 The n ge ne rate the e ncrypte d ke y us ing the random-numbe r us e r ke y: ~]$ keyctl add encrypted encr-key "new user:kmk-user 32" @u 1012412758 The list s ubcommand can be us e d to lis t all ke ys in the s pe cifie d ke rne l ke yring: ~]$ keyctl list @u 2 keys in keyring: 427069434: --alswrv 1000 1000 user: kmk-user 1012412758: --alswrv 1000 1000 encrypted: encr-key

Impo rtant Ke e p in mind that e ncrypte d ke ys that are not s e ale d by a mas te r trus te d ke y are only as s e cure as the us e r mas te r ke y (random-numbe r ke y) us e d to e ncrypt the m. The re fore , the mas te r us e r ke y s hould be loade d as s e cure ly as pos s ible and pre fe rably e arly during the boot proce s s .

4.9.5.2. Addit ional Resources The following offline and online re s ource s can be us e d to acquire additional information pe rtaining to the us e of trus te d and e ncrypte d ke ys .

Inst alled Document at ion ke yctl(1) — De s cribe s the us e of the keyct l utility and its s ubcommands .

Online Document at ion Re d Hat Ente rpris e Linux 7 SELinux Us e r's and Adminis trator's Guide — The SELinux User's and Administrator's Guide for Re d Hat Ente rpris e Linux 7 de s cribe s the bas ic principle s of SELinux and docume nts in de tail how to configure and us e SELinux with various s e rvice s , s uch as the Apache HT T P Server.

114

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

https ://www.ke rne l.org/doc/Docume ntation/s e curity/ke ys -trus te d-e ncrypte d.txt — The official docume ntation about the trus te d and e ncrypte d ke ys fe ature of the Linux ke rne l.

See Also Se ction A.1.1, “Advance d Encryption Standard — AES” provide s a concis e de s cription of the Advanced Encryption Standard. Se ction A.2, “Public-ke y Encryption” de s cribe s the public-ke y cryptographic approach and the various cryptographic protocols it us e s .

4.9.6. Using t he Random Number Generat or In orde r to be able to ge ne rate s e cure cryptographic ke ys that cannot be e as ily broke n, a s ource of random numbe rs is re quire d. Ge ne rally, the more random the numbe rs are , the be tte r the chance of obtaining unique ke ys . Entropy for ge ne rating random numbe rs is us ually obtaine d from computing e nvironme ntal "nois e " or us ing a hardware random number generator. The rngd dae mon, which is a part of the rng-tools package , is capable of us ing both e nvironme ntal nois e and hardware random numbe r ge ne rators for e xtracting e ntropy. The dae mon che cks whe the r the data s upplie d by the s ource of randomne s s is s ufficie ntly random and the n s tore s it in the random-numbe r e ntropy pool of the ke rne l. The random numbe rs it ge ne rate s are made available through the /dev/random and /dev/urandom characte r de vice s . The diffe re nce be twe e n /dev/random and /dev/urandom is that the forme r is a blocking de vice , which me ans it s tops s upplying numbe rs whe n it de te rmine s that the amount of e ntropy is ins ufficie nt for ge ne rating a prope rly random output. Conve rs e ly, /dev/urandom is a non-blocking s ource , which re us e s the e ntropy pool of the ke rne l and is thus able to provide an unlimite d s upply of ps e udo-random numbe rs , albe it with le s s e ntropy. As s uch, /dev/urandom s hould not be us e d for cre ating long-te rm cryptographic ke ys . To ins tall the rng-tools package , is s ue the following command as the root us e r: ~]# yum install rng-tools To s tart the rngd dae mon, e xe cute the following command as root: ~]# systemctl start rngd To que ry the s tatus of the dae mon, us e the following command: ~]# systemctl status rngd To s tart the rngd dae mon with optional parame te rs , e xe cute it dire ctly. For e xample , to s pe cify an alte rnative s ource of random-numbe r input (othe r than /dev/hwrandom), us e the following command: ~]# rngd --rng-device=/dev/hwrng The above command s tarts the rngd dae mon with /dev/hwrng as the de vice from which random numbe rs are re ad. Similarly, you can us e the -o (or --random-device) option to choos e the ke rne l de vice for random-numbe r output (othe r than the de fault /dev/random). Se e the rngd(8) manual page for a lis t of all available options .

115

Se c ur it y Guide

To che ck which s ource s of e ntropy are available in a give n s ys te m, e xe cute the following command as root: ~]# rngd -vf Unable to open file: /dev/tpm0 Available entropy sources: DRNG

No te Afte r e nte ring the rngd -v command, the according proce s s continue s running in background. The -b, --background option (be come a dae mon) is applie d by de fault. If the re is not any TPM de vice pre s e nt, you will s e e only the Inte l Digital Random Numbe r Ge ne rator (DRNG) as a s ource of e ntropy. To che ck if your CPU s upports the RDRAND proce s s or ins truction, e nte r the following command: ~]$ cat /proc/cpuinfo | grep rdrand

No te For more information and s oftware code e xample s , s e e Inte l Digital Random Numbe r Ge ne rator (DRNG) Software Imple me ntation Guide . The rng-tools package als o contains the rngt est utility, which can be us e d to che ck the randomne s s of data. To te s t the le ve l of randomne s s of the output of /dev/random, us e the rngt est tool as follows : ~]$ cat /dev/random | rngtest -c 1000 rngtest 5 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... rngtest: bits received from input: 20000032 rngtest: FIPS 140-2 successes: 998 rngtest: FIPS 140-2 failures: 2 rngtest: FIPS 140-2(2001-10-10) Monobit: 0 rngtest: FIPS 140-2(2001-10-10) Poker: 0 rngtest: FIPS 140-2(2001-10-10) Runs: 0 rngtest: FIPS 140-2(2001-10-10) Long run: 2 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=1.171; avg=8.453; max=11.374)Mibits/s rngtest: FIPS tests speed: (min=15.545; avg=143.126; max=157.632)Mibits/s rngtest: Program run time: 2390520 microseconds

116

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

A high numbe r of failure s s hown in the output of the rngt est tool indicate s that the randomne s s of the te s te d data is ins ufficie nt and s hould not be re lie d upon. Se e the rngte s t(1) manual page for a lis t of options available for the rngt est utility. Re d Hat Ente rpris e Linux 7 introduce d the virt io RNG (Random Numbe r Ge ne rator) de vice that provide s KVM virtual machine s with acce s s to e ntropy from the hos t machine . With the re comme nde d s e tup, hwrng fe e ds into the e ntropy pool of the hos t Linux ke rne l (through /dev/random), and QEMU will us e /dev/random as the s ource for e ntropy re que s te d by gue s ts .

117

Se c ur it y Guide

Figure 4.1. T he virt io RNG device Pre vious ly, Re d Hat Ente rpris e Linux 7.0 and Re d Hat Ente rpris e Linux 6 gue s ts could make us e of the e ntropy from hos ts through the rngd us e r s pace dae mon. Se tting up the dae mon was a manual s te p for e ach Re d Hat Ente rpris e Linux ins tallation. With Re d Hat Ente rpris e Linux 7.1, the manual s te p has be e n e liminate d, making the e ntire proce s s s e amle s s and automatic. The us e of rngd is now not re quire d and the gue s t ke rne l its e lf fe tche s e ntropy from the hos t whe n the available e ntropy falls be low a s pe cific thre s hold. The gue s t ke rne l is the n in a pos ition to make random numbe rs available to applications as s oon as the y re que s t the m. The Re d Hat Ente rpris e Linux ins talle r, Anaco nda, now provide s the virt io -rng module in its ins talle r image , making available hos t e ntropy during the Re d Hat Ente rpris e Linux ins tallation.

4.10. Using Net work-Bound Disk Encrypt ion The Ne twork-Bound Dis k Encryption (NBDE) allows the us e r to e ncrypt root volume s of hard drive s on phys ical and virtual machine s without re quiring to manually e nte r a pas s word whe n s ys te ms are re s tarte d. In Re d Hat Ente rpris e Linux 7, NBDE is imple me nte d through the following compone nts and te chnologie s :

118

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

Figure 4.2. T he Net wo rk-Bo und Disk Encrypt io n using Clevis and T ang Tang is a s e rve r for binding data to ne twork pre s e nce . It make s a s ys te m containing your data available whe n the s ys te m is bound to a ce rtain s e cure ne twork. Tang is s tate le s s and doe s not re quire TLS or authe ntication. Unlike e s crow-bas e d s olutions , whe re the s e rve r s tore s all e ncryption ke ys and has knowle dge of e ve ry ke y e ve r us e d, Tang ne ve r s e e s a s ingle clie nt ke y. Tang ne ve r gains any ide ntifying information from the clie nt. The Clevis is a pluggable frame work for automate d de cryption. In NBDE, Cle vis provide s automate d unlocking of LUKS volume s . The clevis package provide s the clie nt s ide of the fe ature . A Clevis Pin is a plug-in into the Cle vis frame work. One of s uch PINs is a plug-in that imple me nts inte ractions with the NBDE s e rve r — Tang. Cle vis and Tang are ge ne ric clie nt and s e rve r compone nts to provide ne twork-bound e ncryption. In Re d Hat Ente rpris e Linux 7, the y are us e d in conjunction to e ncrypt and de crypt root volume s of hard drive s to accomplis h the Ne twork-Bound Dis k Encryption. Both clie nt- and s e rve r-s ide compone nts us e the José library to pe rform e ncryption and de cryption ope rations . The Cle vis Pin for Tang s e rve r ge ts a lis t of the Tang s e rve r's adve rtis e d as ymme tric ke ys . Alte rnative ly, s ince the ke ys are as ymme tric, a lis t of Tang’s public ke ys can be dis tribute d out of the band s o that clie nts can ope rate without acce s s to the Tang s e rve r. This mode is calle d offline provisioning. The Cle vis Pin for Tang us e s one of the public ke ys to ge ne rate a unique , cryptographically-s trong e ncryption ke y. Once the data are e ncrypte d us ing this ke y, the ke y is dis carde d. The clie nt s hould s tore the s tate produce d by this provis ioning ope ration in a conve nie nt location. This proce s s of e ncrypting data is the provisioning step. The provis ioning s tate for NBDE is s tore d in the LUKS he ade r le ve raging the luksmeta package . Whe n the clie nt is re ady to acce s s its data, it loads the me tadata produce d in the provis ioning s te p and it re s ponds to re cove r the e ncryption ke y. This proce s s is the recovery step. In NBDE, Cle vis binds a LUKS volume us ing a PIN s o that it can be automatically unlocke d. Afte r s ucce s s ful comple tion of the binding proce s s , the dis k can be unlocke d us ing the provide d Dracut unlocke r.

4.10.1. Deploying a T ang server To ins tall the tang package and its de pe nde ncie s , e nte r the following command as root: ~]# yum install tang Enable and s tart the tangd s e rvice us ing s ys te md: ~]# systemctl enable tangd.socket --now Created symlink from /etc/systemd/system/multiuser.target.wants/tangd.socket to /usr/lib/systemd/system/tangd.socket. Since tangd us e s the systemd s ocke t activation me chanis m, the s e rve r s tarts as s oon as the firs t conne ction come s in. A ne w s e t of cryptographic ke ys is automatically ge ne rate d at the firs t s tart.

119

Se c ur it y Guide

To pe rform cryptographic ope rations s uch as manual ke y ge ne ration, us e the jose utility. Ente r the jose -h command or s e e the jose(1) man page s for more information.

Example 4.3. Ro t at ing T ang Keys It is important to pe riodically rotate your ke ys . The pre cis e inte rval at which you s hould rotate the m de pe nds upon your application, ke y s iz e s , and ins titutional policy. For s ome common re comme ndations , s e e the Cryptographic Ke y Le ngth Re comme ndation page . To rotate ke ys , s tart with the ge ne ration of ne w ke ys in the ke y databas e dire ctory, typically /var/db/tang. For e xample , you can cre ate ne w s ignature and e xchange ke ys with the following commands : ~]# DB=/var/db/tang ~]# jose jwk gen -i '{"alg":"ES512"}' -o $DB/new_sig.jwk ~]# jose jwk gen -i '{"alg":"ECMR"}' -o $DB/new_exc.jwk Re name the old ke ys to have a le ading . to hide the m from adve rtis e me nt: ~]# mv $DB/old_sig.jwk $DB/.old_sig.jwk ~]# mv $DB/old_exc.jwk $DB/.old_exc.jwk Tang imme diate ly picks up all change s . No re s tart is re quire d. At this point, ne w clie nt bindings pick up the ne w ke ys and old clie nts can continue to utiliz e the old ke ys . Whe n you are s ure that all old clie nts us e the ne w ke ys , you can re move the old ke ys .

Warning Be aware that re moving the old ke ys while clie nts are s till us ing the m can re s ult in data los s . Tang us e s port 80 for communication. This port is als o wide ly-us e d for we b s e rve rs . To change Tang's port numbe r, ove rride the tangd.socket unit file us ing the s tandard systemd me chanis ms . Se e Re d Hat Ente rpris e Linux 7 Sys te m Adminis trator's Guide : Cre ating and Modifying s ys te md Unit File s for more information.

4.10.1.1. Deploying High-Availabilit y Syst ems Tang provide s two me thods for building a high-availability de ployme nt: 1. Client Redundancy (Reco mmended) Clie nts s hould be configure d with the ability to bind to multiple Tang s e rve rs . In this s e tup, e ach Tang s e rve r has its own ke ys and clie nts are able to de crypt by contacting a s ubs e t of the s e s e rve rs . Cle vis alre ady s upports this workflow through its sss plug-in. For more information about this s e tup, s e e the following man page s : tang(8), s e ction High Availability

120

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

clevis(1), s e ction Shamir's Se cre t Sharing clevis-encrypt-sss(1) Re d Hat re comme nds this me thod for a high-availability de ployme nt. 2. Key Sharing For re dundancy purpos e s , more than one ins tance of Tang can be de ploye d. To s e t up a s e cond or any s ubs e que nt ins tance , ins tall the tang package s and copy the ke y dire ctory to the ne w hos t us ing rsync ove r SSH. Note that Re d Hat doe s not re comme nd this me thod be caus e s haring ke ys incre as e s the ris k of ke y compromis e and re quire s additional automation infras tructure .

4.10.2. Deploying an Encrypt ion Client To ins tall the Cle vis pluggable frame work and its PINs on the machine with an e ncrypte d volume (clie nt), e nte r the following command as root: ~]# yum install clevis To e ncrypt plainte xt data into a JSON We b Encryption (JWE) ciphe rte xt obje ct us ing a Tang PIN, us e the clevis encrypt tang command, for e xample : ~]$ clevis encrypt tang '{"url":"http://tang.srv"}' < PLAINTEXT > JWE The advertisement contains the following signing keys: _OsIk0T-E2l6qjfdDiwVmidoZjA Do you wish to trust these keys? [ynYN] y Change the http://tang.srv URL in the pre vious e xample to match the URL of the s e rve r whe re tang is ins talle d. The JWE output file contains your e ncrypte d ciphe r te xt. This ciphe r te xt is re ad from the PLAINTEXT input file . To de crypt data, us e the clevis decrypt command and provide the ciphe r te xt (JWE): ~]$ clevis decrypt < JWE > PLAINTEXT For more information, s e e the clevis-encrypt-tang(1) man page or us e the built-in CLI he lp: ~]$ clevis Usage: clevis COMMAND [OPTIONS] clevis clevis time clevis clevis clevis

bind luks decrypt

Binds a LUKSv1 device using the specified policy Decrypts using the policy defined at encryption

encrypt http Encrypts using a REST HTTP escrow server policy encrypt sss Encrypts using a Shamir's Secret Sharing policy encrypt tang Encrypts using a Tang binding server policy

~]$ clevis decrypt Usage: clevis decrypt < JWE > PLAINTEXT

121

Se c ur it y Guide

Decrypts using the policy defined at encryption time ~]$ clevis encrypt tang Usage: clevis encrypt tang CONFIG < PLAINTEXT > JWE Encrypts using a Tang binding server policy This command uses the following configuration properties: url:

The base URL of the Tang server (REQUIRED)

thp:

The thumbprint of a trusted signing key

adv: adv:

A filename containing a trusted advertisement A trusted advertisement (raw JSON)

Obtaining the thumbprint of a trusted signing key is easy. If you have access to the Tang server's database directory, simply do: $ jose jwk thp -i $DBDIR/$SIG.jwk Alternatively, if you have certainty that your network connection is not compromised (not likely), you can download the advertisement yourself using: $ curl -f $URL/adv > adv.jws

4.10.3. Conf iguring Manual Enrollment To bind an e xis ting LUKS volume to its automation policy, ins tall the clevis-luks s ubpackage : ~]# yum install clevis-luks The n us e the clevis bind luks command, for e xample : ~]# clevis bind luks -d /dev/sda tang '{"url":"http://tang.srv"}' The advertisement contains the following signing keys: _OsIk0T-E2l6qjfdDiwVmidoZjA Do you wish to trust these keys? [ynYN] y You are about to initialize a LUKS device for metadata storage. Attempting to initialize it may result in data loss if data was already written into the LUKS header gap in a different format. A backup is advised before initialization is performed. Do you wish to initialize /dev/sda? [yn] y Enter existing LUKS password: This command pe rforms four s te ps : 1. Cre ate s a ne w ke y with the s ame e ntropy as the LUKS mas te r ke y. 2. Encrypts the ne w ke y with Cle vis .

122

⁠C hapt e r 4 . Har de ning Yo ur Sys t e m wit h T o o ls and Se r vic e s

3. Store s the Cle vis JWE obje ct in the LUKS he ade r with LUKSMe ta. 4. Enable s the ne w ke y for us e with LUKS. This dis k can now be unlocke d with your e xis ting pas s word as we ll as with the Cle vis policy. For more information, s e e the clevis-bind-luks(1) man page .

No te The binding proce dure as s ume s that the re is at le as t one fre e LUKS pas s word s lot. The clevis bind luks command take s one of the s lots . To ve rify that the Cle vis JWE obje ct is s ucce s fully place d in a LUKS he ade r, us e the luksmeta show command: ~]# luksmeta show -d /dev/sda 0 active empty 1 active cb6e8904-81ff-40da-a84a-07ab9ab5715e 2 inactive empty 3 inactive empty 4 inactive empty 5 inactive empty 6 inactive empty 7 inactive empty To e nable the e arly boot s ys te m to proce s s the dis k binding, e nte r the following commands on an alre ady-ins talle d s ys te m: ~]# yum install clevis-dracut ~]# dracut -f

4.10.4. Conf iguring Aut omat ed Enrollment Using Kickst art Cle vis can inte grate with Kicks tart to provide a fully automate d e nrollme nt proce s s . 1. Ins truct Kicks tart to partition the dis k s uch that the root partition has e nable d LUKS e ncryption with a te mporary pas s word. The pas s word is te mporary for the e nrollme nt proce s s . part /boot --fstype="xfs" --ondisk=vda --size=256 part / --fstype="xfs" --ondisk=vda --grow --encrypted -passphrase=temppass 2. Ins tall the re late d Cle vis package s by lis ting the m in the %packages s e ction: %packages clevis-dracut %end 3. Call clevis bind luks to pe rform binding in the %post s e ction. Afte rward, re move the te mporary pas s word:

123

Se c ur it y Guide

%post clevis bind luks -f -k- -d /dev/vda2 \ tang '{"url":"http://tang.srv","thp":"_OsIk0TE2l6qjfdDiwVmidoZjA"}' \ =1000 -F auid!=4294967295 -k delete Note that the -F auid!=4294967295 option is us e d to e xclude us e rs whos e login UID is not s e t. It is als o pos s ible to de fine a file s ys te m rule us ing the s ys te m call rule s yntax. The following command cre ate s a rule for s ys te m calls that is analogous to the -w /etc/shadow -p wa file s ys te m rule : ~]# auditctl -a always,exit -F path=/etc/shadow -F perm=wa

6.5.2. Def ining Execut able File Rules To de fine an e xe cutable file rule , us e the following s yntax: auditctl -a action,filter [ -F arch=cpu -S system_call] -F exe=path_to_executable_file -k key_name whe re : action and filter s pe cify whe n a ce rtain e ve nt is logge d. action can be e ithe r always or never. filter s pe cifie s which ke rne l rule -matching filte r is applie d to the e ve nt. The rule matching filte r can be one of the following: task, exit, user, and exclude. For more

193

Se c ur it y Guide

information about the s e filte rs , s e e the be ginning of Se ction 6.1, “Audit Sys te m Archite cture ”. system_call s pe cifie s the s ys te m call by its name . A lis t of all s ys te m calls can be found in the /usr/include/asm/unistd_64.h file . Se ve ral s ys te m calls can be groupe d into one rule , e ach s pe cifie d afte r its own -S option. path_to_executable_file is the abs olute path to the e xe cutable file that is audite d. key_name is an optional s tring that he lps you ide ntify which rule or a s e t of rule s ge ne rate d a particular log e ntry.

Example 6.3. Execut able File Rules To de fine a rule that logs all e xe cution of the /bin/id program, e xe cute the following command: ~]# auditctl -F exe=/bin/id -S execve -k execution_bin_id

6.5.3. Def ining Persist ent Audit Rules and Cont rols in t he /etc/audit/audit.rules File To de fine Audit rule s that are pe rs is te nt acros s re boots , you mus t e ithe r dire ctly include the m in the /etc/audit/audit.rules file or us e the augenrules program that re ads rule s locate d in the /etc/audit/rules.d/ dire ctory. The /etc/audit/audit.rules file us e s the s ame auditctl command line s yntax to s pe cify the rule s . Empty line s and te xt following a has h s ign (#) are ignore d. The auditctl command can als o be us e d to re ad rule s from a s pe cifie d file us ing the -R option, for e xample : ~]# auditctl -R /usr/share/doc/audit/rules/30-stig.rules

Def ining Cont rol Rules A file can contain only the following control rule s that modify the be havior of the Audit s ys te m: -b, -D, -e, -f, -r, --loginuid-immutable, and --backlog_wait_time. For more information on the s e options , s e e Se ction 6.5.1, “De fining Control Rule s ”.

Example 6.4. Co nt ro l Rules in audit.rules # Delete all previous rules -D # Set buffer size -b 8192 # Make the configuration immutable -- reboot is required to change audit rules -e 2 # Panic when a failure occurs

194

⁠C hapt e r 6 . Sys t e m Audit ing

-f 2 # Generate at most 100 audit messages per second -r 100 # Make login UID immutable once it is set (may break containers) --loginuid-immutable 1

Def ining File Syst em and Syst em Call Rules File s ys te m and s ys te m call rule s are de fine d us ing the auditctl s yntax. The e xample s in Se ction 6.5.1, “De fining Audit Rule s with audit ct l” can be re pre s e nte d with the following rule s file :

Example 6.5. File Syst em and Syst em Call Rules in audit.rules -w /etc/passwd -p wa -k passwd_changes -w /etc/selinux/ -p wa -k selinux_changes -w /sbin/insmod -p x -k module_insertion -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

Preconf igured Rules Files In the /usr/share/doc/audit/rules/ dire ctory, the audit package provide s a s e t of pre configure d rule s file s according to various ce rtification s tandards : 30-nispom.rules — Audit rule configuration that me e ts the re quire me nts s pe cifie d in the Information Sys te m Se curity chapte r of the National Indus trial Se curity Program Ope rating Manual. 30-pci-dss-v31.rules — Audit rule configuration that me e ts the re quire me nts s e t by Payme nt Card Indus try Data Se curity Standard (PCI DSS) v3.1. 30-stig.rules — Audit rule configuration that me e ts the re quire me nts s e t by Se curity Te chnical Imple me ntation Guide s (STIG). To us e the s e configuration file s , cre ate a backup of your original /etc/audit/audit.rules file and copy the configuration file of your choice ove r the /etc/audit/audit.rules file : ~]# cp /etc/audit/audit.rules /etc/audit/audit.rules_backup ~]# cp /usr/share/doc/audit/rules/30-stig.rules /etc/audit/audit.rules

195

Se c ur it y Guide

No te The Audit rule s have a numbe ring s che me that allows the m to be orde re d. To le arn more about the naming s che me , s e e the /usr/share/doc/audit/rules/READMErules file .

Using augenrules t o Def ine Persist ent Rules The augenrules s cript re ads rule s locate d in the /etc/audit/rules.d/ dire ctory and compile s the m into an audit.rules file . This s cript proce s s e s all file s that e nds in .rules in a s pe cific orde r bas e d on the ir natural s ort orde r. The file s in this dire ctory are organiz e d into groups with following me anings : 10 - Ke rne l and auditctl configuration 20 - Rule s that could match ge ne ral rule s but you want a diffe re nt match 30 - Main rule s 40 - Optional rule s 50 - Se rve r-s pe cific rule s 70 - Sys te m local rule s 90 - Finaliz e (immutable ) The rule s are not me ant to be us e d all at once . The y are pie ce s of a policy that s hould be thought out and individual file s copie d to /etc/audit/rules.d/. For e xample , to s e t a s ys te m up in the STIG configuration, copy rule s 10-bas e -config, 30-s tig, 31-privile ge d, and 99-finaliz e . Once you have the rule s in the /etc/audit/rules.d/ dire ctory, load the m by running the augenrules s cript with the --load dire ctive : ~]# augenrules --load augenrules --load No rules enabled 1 failure 1 pid 634 rate_limit 0 backlog_limit 8192 lost 0 backlog 0 enabled 1 failure 1 pid 634 rate_limit 0 backlog_limit 8192 lost 0 backlog 1 For more information on the Audit rule s and the augenrules s cript, s e e the audit.rules(8) and augenrules(8) man page s .

196

⁠C hapt e r 6 . Sys t e m Audit ing

6.6. Underst anding Audit Log Files By de fault, the Audit s ys te m s tore s log e ntrie s in the /var/log/audit/audit.log file ; if log rotation is e nable d, rotate d audit.log file s are s tore d in the s ame dire ctory. The following Audit rule logs e ve ry atte mpt to re ad or modify the /etc/ssh/sshd_config file : -w /etc/ssh/sshd_config -p warx -k sshd_config If the auditd dae mon is running, for e xample , us ing the following command cre ate s a ne w e ve nt in the Audit log file : ~]$ cat /etc/ssh/sshd_config This e ve nt in the audit.log file looks as follows :

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0s0:c0.c1023 key="sshd_config" type=CWD msg=audit(1364481363.243:24287): cwd="/home/shadowman" type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967 The above e ve nt cons is ts of four re cords , which s hare the s ame time s tamp and s e rial numbe r. Re cords always tart with the type= ke yword. Each re cord cons is ts of s e ve ral name=value pairs s e parate d by a white s pace or a comma. A de taile d analys is of the above e ve nt follows :

First Record type=SYSCALL The type fie ld contains the type of the re cord. In this e xample , the SYSCALL value s pe cifie s that this re cord was trigge re d by a s ys te m call to the ke rne l. For a lis t of all pos s ible type value s and the ir e xplanations , s e e Se ction B.2, “Audit Re cord Type s ”. msg=audit(1364481363.243:24287): The msg fie ld re cords : a time s tamp and a unique ID of the re cord in the form audit(time_stamp:ID). Multiple re cords can s hare the s ame time s tamp and ID if the y we re ge ne rate d as part of the s ame Audit e ve nt. The time s tamp is us ing the Unix time format - s e conds s ince 00:00:00 UTC on 1 January 1970.

197

Se c ur it y Guide

various e ve nt-s pe cific name=value pairs provide d by the ke rne l or us e r s pace applications . arch=c000003e The arch fie ld contains information about the CPU archite cture of the s ys te m. The value , c000003e, is e ncode d in he xade cimal notation. Whe n s e arching Audit re cords with the ausearch command, us e the -i or --interpret option to automatically conve rt he xade cimal value s into the ir human-re adable e quivale nts . The c000003e value is inte rpre te d as x86_64. syscall=2 The syscall fie ld re cords the type of the s ys te m call that was s e nt to the ke rne l. The value , 2, can be matche d with its human-re adable e quivale nt in the /usr/include/asm/unistd_64.h file . In this cas e , 2 is the open s ys te m call. Note that the ausyscall utility allows you to conve rt s ys te m call numbe rs to the ir human-re adable e quivale nts . Us e the ausyscall --dump command to dis play a lis ting of all s ys te m calls along with the ir numbe rs . For more information, s e e the aus ys call(8) man page . success=no The success fie ld re cords whe the r the s ys te m call re corde d in that particular e ve nt s ucce e de d or faile d. In this cas e , the call did not s ucce e d. exit=-13 The exit fie ld contains a value that s pe cifie s the e xit code re turne d by the s ys te m call. This value varie s for diffe re nt s ys te m call. You can inte rpre t the value to its human-re adable e quivale nt with the following command: ~]# ausearch --interpret --exit -13 Note that the pre vious e xample as s ume s that your Audit log contains an e ve nt that faile d with e xit code -13. a0=7fffd19c5592, a1=0, a2=7fffd19c5592, a3=a The a0 to a3 fie lds re cord the firs t four argume nts , e ncode d in he xade cimal notation, of the s ys te m call in this e ve nt. The s e argume nts de pe nd on the s ys te m call that is us e d; the y can be inte rpre te d by the ausearch utility. items=1 The items fie ld contains the numbe r of auxiliary re cords that follow the s ys call re cord. ppid=2686 The ppid fie ld re cords the Pare nt Proce s s ID (PPID). In this cas e , 2686 was the PPID of the pare nt proce s s s uch as bash. pid=3538 The pid fie ld re cords the Proce s s ID (PID). In this cas e , 3538 was the PID of the cat proce s s . auid=1000

198

⁠C hapt e r 6 . Sys t e m Audit ing

The auid fie ld re cords the Audit us e r ID, that is the loginuid. This ID is as s igne d to a us e r upon login and is inhe rite d by e ve ry proce s s e ve n whe n the us e r's ide ntity change s , for e xample , by s witching us e r accounts with the su - john command. uid=1000 The uid fie ld re cords the us e r ID of the us e r who s tarte d the analyz e d proce s s . The us e r ID can be inte rpre te d into us e r name s with the following command: ausearch -i --uid UID. gid=1000 The gid fie ld re cords the group ID of the us e r who s tarte d the analyz e d proce s s . euid=1000 The euid fie ld re cords the e ffe ctive us e r ID of the us e r who s tarte d the analyz e d proce s s . suid=1000 The suid fie ld re cords the s e t us e r ID of the us e r who s tarte d the analyz e d proce s s . fsuid=1000 The fsuid fie ld re cords the file s ys te m us e r ID of the us e r who s tarte d the analyz e d proce s s . egid=1000 The egid fie ld re cords the e ffe ctive group ID of the us e r who s tarte d the analyz e d proce s s . sgid=1000 The sgid fie ld re cords the s e t group ID of the us e r who s tarte d the analyz e d proce s s . fsgid=1000 The fsgid fie ld re cords the file s ys te m group ID of the us e r who s tarte d the analyz e d proce s s . tty=pts0 The tty fie ld re cords the te rminal from which the analyz e d proce s s was invoke d. ses=1 The ses fie ld re cords the s e s s ion ID of the s e s s ion from which the analyz e d proce s s was invoke d. comm="cat" The comm fie ld re cords the command-line name of the command that was us e d to invoke the analyz e d proce s s . In this cas e , the cat command was us e d to trigge r this Audit e ve nt. exe="/bin/cat"

199

Se c ur it y Guide

The exe fie ld re cords the path to the e xe cutable that was us e d to invoke the analyz e d proce s s . subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 The subj fie ld re cords the SELinux conte xt with which the analyz e d proce s s was labe le d at the time of e xe cution. key="sshd_config" The key fie ld re cords the adminis trator-de fine d s tring as s ociate d with the rule that ge ne rate d this e ve nt in the Audit log.

Second Record type=CWD In the s e cond re cord, the type fie ld value is CWD — curre nt working dire ctory. This type is us e d to re cord the working dire ctory from which the proce s s that invoke d the s ys te m call s pe cifie d in the firs t re cord was e xe cute d. The purpos e of this re cord is to re cord the curre nt proce s s 's location in cas e a re lative path winds up be ing capture d in the as s ociate d PATH re cord. This way the abs olute path can be re cons tructe d. msg=audit(1364481363.243:24287) The msg fie ld holds the s ame time s tamp and ID value as the value in the firs t re cord. The time s tamp is us ing the Unix time format - s e conds s ince 00:00:00 UTC on 1 January 1970. cwd="/home/user_name" The cwd fie ld contains the path to the dire ctory in which the s ys te m call was invoke d.

T hird Record type=PATH In the third re cord, the type fie ld value is PATH. An Audit e ve nt contains a PATHtype re cord for e ve ry path that is pas s e d to the s ys te m call as an argume nt. In this Audit e ve nt, only one path (/etc/ssh/sshd_config) was us e d as an argume nt. msg=audit(1364481363.243:24287): The msg fie ld holds the s ame time s tamp and ID value as the value in the firs t and s e cond re cord. item=0 The item fie ld indicate s which ite m, of the total numbe r of ite ms re fe re nce d in the SYSCALL type re cord, the curre nt re cord is . This numbe r is z e ro-bas e d; a value of 0 me ans it is the firs t ite m. name="/etc/ssh/sshd_config"

200

⁠C hapt e r 6 . Sys t e m Audit ing

The name fie ld re cords the full path of the file or dire ctory that was pas s e d to the s ys te m call as an argume nt. In this cas e , it was the /etc/ssh/sshd_config file . inode=409248 The inode fie ld contains the inode numbe r as s ociate d with the file or dire ctory re corde d in this e ve nt. The following command dis plays the file or dire ctory that is as s ociate d with the 409248 inode numbe r: ~]# find / -inum 409248 -print /etc/ssh/sshd_config dev=fd:00 The dev fie ld s pe cifie s the minor and major ID of the de vice that contains the file or dire ctory re corde d in this e ve nt. In this cas e , the value re pre s e nts the /dev/fd/0 de vice . mode=0100600 The mode fie ld re cords the file or dire ctory pe rmis s ions , e ncode d in nume rical notation as re turne d by the stat command in the st_mode fie ld. Se e the stat(2) man page for more information. In this cas e , 0100600 can be inte rpre te d as -rw------, me aning that only the root us e r has re ad and write pe rmis s ions to the /etc/ssh/sshd_config file . ouid=0 The ouid fie ld re cords the obje ct owne r's us e r ID. ogid=0 The ogid fie ld re cords the obje ct owne r's group ID. rdev=00:00 The rdev fie ld contains a re corde d de vice ide ntifie r for s pe cial file s only. In this cas e , it is not us e d as the re corde d file is a re gular file . obj=system_u:object_r:etc_t:s0 The obj fie ld re cords the SELinux conte xt with which the re corde d file or dire ctory was labe le d at the time of e xe cution.

Fourt h Record type=PROCTITLE The type fie ld contains the type of the re cord. In this e xample , the PROCTITLE value s pe cifie s that this re cord give s the full command-line that trigge re d this Audit e ve nt, trigge re d by a s ys te m call to the ke rne l. proctitle=636174002F6574632F7373682F737368645F636F6E666967 The proctitle fie ld re cords the full command-line of the command that was us e d to invoke the analyz e d proce s s . The fie ld is e ncode d in he xade cimal notation to not allow the us e r to influe nce the Audit log pars e r. The te xt de code s to the command that trigge re d this Audit e ve nt. Whe n s e arching Audit re cords with the

201

Se c ur it y Guide

ausearch command, us e the -i or --interpret option to automatically conve rt he xade cimal value s into the ir human-re adable e quivale nts . The 636174002F6574632F7373682F737368645F636F6E666967 value is inte rpre te d as x86_64. The Audit e ve nt analyz e d above contains only a s ubs e t of all pos s ible fie lds that an e ve nt can contain. For a lis t of all e ve nt fie lds and the ir e xplanation, s e e Se ction B.1, “Audit Eve nt Fie lds ”. For a lis t of all e ve nt type s and the ir e xplanation, s e e Se ction B.2, “Audit Re cord Type s ”.

Example 6.6. Addit io nal audit.log Event s The following Audit e ve nt re cords a s ucce s s ful s tart of the auditd dae mon. The ver fie ld s hows the ve rs ion of the Audit dae mon that was s tarte d. type=DAEMON_START msg=audit(1363713609.192:5426): auditd start, ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=1000 pid=4979 subj=unconfined_u:system_r:auditd_t:s0 res=success The following Audit e ve nt re cords a faile d atte mpt of us e r with UID of 1000 to log in as the root us e r. type=USER_AUTH msg=audit(1364475353.159:24270): user pid=3280 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/0 res=failed'

6.7. Searching t he Audit Log Files The ausearch utility allows you to s e arch Audit log file s for s pe cific e ve nts . By de fault, ausearch s e arche s the /var/log/audit/audit.log file . You can s pe cify a diffe re nt file us ing the ausearch options -if file_name command. Supplying multiple options in one ausearch command is e quivale nt to us ing the AND ope rator be twe e n fie ld type s and the OR ope rator be twe e n multiple ins tance s of the s ame fie ld type .

Example 6.7. Using ausearch t o Search Audit Lo g Files To s e arch the /var/log/audit/audit.log file for faile d login atte mpts , us e the following command: ~]# ausearch --message USER_LOGIN --success no --interpret To s e arch for all account, group, and role change s , us e the following command: ~]# ausearch -m ADD_USER -m DEL_USER -m ADD_GROUP -m USER_CHAUTHTOK -m DEL_GROUP -m CHGRP_ID -m ROLE_ASSIGN -m ROLE_REMOVE -i To s e arch for all logge d actions pe rforme d by a ce rtain us e r, us ing the us e r's login ID (auid), us e the following command: ~]# ausearch -ua 1000 -i

202

⁠C hapt e r 6 . Sys t e m Audit ing

To s e arch for all faile d s ys te m calls from ye s te rday up until now, us e the following command: ~]# ausearch --start yesterday --end now -m SYSCALL -sv no -i

For a full lis ting of all ausearch options , s e e the aus e arch(8) man page .

6.8. Creat ing Audit Report s The aurepo rt utility allows you to ge ne rate s ummary and columnar re ports on the e ve nts re corde d in Audit log file s . By de fault, all audit.log file s in the /var/log/audit/ dire ctory are que rie d to cre ate the re port. You can s pe cify a diffe re nt file to run the re port agains t us ing the aureport options -if file_name command.

Example 6.8. Using aureport t o Generat e Audit Repo rt s To ge ne rate a re port for logge d e ve nts in the pas t thre e days e xcluding the curre nt e xample day, us e the following command: ~]# aureport --start 04/08/2013 00:00:00 --end 04/11/2013 00:00:00 To ge ne rate a re port of all e xe cutable file e ve nts , us e the following command: ~]# aureport -x To ge ne rate a s ummary of the e xe cutable file e ve nt re port above , us e the following command: ~]# aureport -x --summary To ge ne rate a s ummary re port of faile d e ve nts for all us e rs , us e the following command: ~]# aureport -u --failed --summary -i To ge ne rate a s ummary re port of all faile d login atte mpts pe r e ach s ys te m us e r, us e the following command: ~]# aureport --login --summary -i To ge ne rate a re port from an ausearch que ry that s e arche s all file acce s s e ve nts for us e r ID 1000, us e the following command: ~]# ausearch --start today --loginuid 1000 --raw | aureport -f -summary To ge ne rate a re port of all Audit file s that are que rie d and the time range of e ve nts the y include , us e the following command: ~]# aureport -t

203

Se c ur it y Guide

For a full lis ting of all aureport options , s e e the aure port(8) man page .

6.9. Addit ional Resources For more information about the Audit s ys te m, s e e the following s ource s .

Online Sources The Linux Audit Docume ntation Proje ct page : https ://github.com/linux-audit/auditdocume ntation/wiki.

Inst alled Document at ion Docume ntation provide d by the audit package can be found in the /usr/share/doc/audit/ dire ctory.

Manual Pages audis pd.conf(5) auditd.conf(5) aus e arch-e xpre s s ion(5) audit.rule s (7) audis pd(8) auditctl(8) auditd(8) aulas t(8) aulas tlog(8) aure port(8) aus e arch(8) aus ys call(8) autrace (8) auvirt(8)

204

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

Chapt er 7. Compliance and Vulnerabilit y Scanning wit h OpenSCAP 7.1. Securit y Compliance in Red Hat Ent erprise Linux A compliance audit is a proce s s of figuring out whe the r a give n obje ct follows all the rule s writte n out in a compliance policy. The compliance policy is de fine d by s e curity profe s s ionals who s pe cify de s ire d s e ttings , ofte n in the form of a che cklis t, that are to be us e d in the computing e nvironme nt. The compliance policy can vary s ubs tantially acros s organiz ations and e ve n acros s diffe re nt s ys te ms within the s ame organiz ation. Diffe re nce s among the s e policie s are bas e d on the purpos e of the s e s ys te ms and its importance for the organiz ation. The cus tom s oftware s e ttings and de ployme nt characte ris tics als o rais e a ne e d for cus tom policy che cklis ts . Re d Hat Ente rpris e Linux provide s tools that allow for fully automate d compliance audit. The s e tools are bas e d on the Se curity Conte nt Automation Protocol (SCAP) s tandard and are de s igne d for automate d tailoring of compliance policie s .

Securit y Co mpliance T o o ls Suppo rt ed o n Red Hat Ent erprise Linux 7 SCAP Wo rkbench — The scap-workbench graphical utility is de s igne d to pe rform configuration and vulne rability s cans on a s ingle local or re mote s ys te m. It can be als o us e d to ge ne rate s e curity re ports bas e d on the s e s cans and e valuations . OpenSCAP — The o scap command-line utility is de s igne d to pe rform configuration and vulne rability s cans on a local s ys te m, to validate s e curity compliance conte nt, and to ge ne rate re ports and guide s bas e d on the s e s cans and e valuations . Script Check Engine (SCE) — SCE is an e xte ns ion to the SCAP protocol that allows adminis trators to write the ir s e curity conte nt us ing a s cripting language , s uch as Bas h, Python, or Ruby. The SCE e xte ns ion is provide d in the openscap-engine-sce package . SCAP Securit y Guide (SSG) — The scap-security-guide package provide s the late s t colle ction of s e curity policie s for Linux s ys te ms . The guidance cons is ts of a catalog of practical harde ning advice , linke d to gove rnme nt re quire me nts whe re applicable . The proje ct bridge s the gap be twe e n ge ne raliz e d policy re quire me nts and s pe cific imple me ntation guide line s . If you re quire pe rforming automate d compliance audits on multiple s ys te ms re mote ly, you can utiliz e Ope nSCAP s olution for Re d Hat Sate llite . For more information s e e Se ction 7.7, “Us ing Ope nSCAP with Re d Hat Sate llite ” and Se ction 7.9, “Additional Re s ource s ”.

7.2. Defining Compliance Policy The s e curity or compliance policy is rare ly writte n from s cratch. ISO 270 0 0 s tandard s e rie s , de rivative works , and othe r s ource s provide s e curity policy te mplate s and practice re comme ndations that s hould be he lpful to s tart with. Howe ve r, organiz ations building the irs information s e curity program ne e d to ame nd the policy te mplate s to align with the ir

205

Se c ur it y Guide

ne e ds . The policy te mplate s hould be chos e n on the bas is of its re le vancy to the company e nvironme nt and the n the te mplate has to be adjus te d be caus e e ithe r the te mplate contains build-in as s umptions which cannot be applie d to the organiz ation, or the te mplate e xplicitly re quire s that ce rtain de cis ions have to be made . Re d Hat Ente rpris e Linux auditing capabilitie s are bas e d on the Se curity Conte nt Automation Protocol (SCAP) s tandard. SCAP is a s ynthe s is of inte rope rable s pe cifications that s tandardiz e the format and nome nclature by which s oftware flaw and s e curity configuration information is communicate d, both to machine s and humans . SCAP is a multipurpos e frame work of s pe cifications that s upports automate d configuration, vulne rability and patch che cking, te chnical control compliance activitie s , and s e curity me as ure me nt. In othe r words , SCAP is a ve ndor-ne utral way of e xpre s s ing s e curity policy, and as s uch it is wide ly us e d in mode rn e nte rpris e s . SCAP s pe cifications cre ate an e cos ys te m whe re the format of s e curity conte nt is we ll known and s tandardiz e d while the imple me ntation of the s canne r or policy e ditor is not mandate d. Such a s tatus e nable s organiz ations to build the ir s e curity policy (SCAP conte nt) once , no matte r how many s e curity ve ndors do the y e mploy. The late s t ve rs ion of SCAP include s s e ve ral unde rlying s tandards . The s e compone nts are organiz e d into groups according to the ir function within SCAP as follows :

SCAP Co mpo nent s Languages — This group cons is ts of SCAP language s that de fine s tandard vocabularie s and conve ntions for e xpre s s ing compliance policy. The eXtensible Configuration Checklist Description Format (XCCDF) — A language de s igne d to e xpre s s , organiz e , and manage s e curity guidance . Open Vulnerability and Assessment Language (OVAL) — A language de ve lope d to pe rform logical as s e rtion about the s tate of the s canne d s ys te m. Open Checklist Interactive Language (OCIL) — A language de s igne d to provide a s tandard way to que ry us e rs and inte rpre t us e r re s pons e s to the give n que s tions . Asset Identification (AI) — A language de ve lope d to provide a data mode l, me thods , and guidance for ide ntifying s e curity as s e ts . Asset Reporting Format (ARF) — A language de s igne d to e xpre s s the trans port format of information about colle cte d s e curity as s e ts and the re lations hip be twe e n as s e ts and s e curity re ports . Enumerations — This group include s SCAP s tandards that de fine naming format and an official lis t or dictionary of ite ms from ce rtain s e curity-re late d are as of inte re s t. Common Configuration Enumeration (CCE) — An e nume ration of s e curity-re le vant configuration e le me nts for applications and ope rating s ys te ms . Common Platform Enumeration (CPE) — A s tructure d naming s che me us e d to ide ntify information te chnology (IT) s ys te ms , platforms , and s oftware package s . Common Vulnerabilities and Exposures (CVE) — A re fe re nce me thod to a colle ction of publicly known s oftware vulne rabilitie s and e xpos ure s . Metrics — This group compris e s of frame works to ide ntify and e valuate s e curity ris ks . Common Configuration Scoring System (CCSS) — A me tric s ys te m to e valuate

206

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

s e curity-re le vant configuration e le me nts and as s ign the m s core s in orde r to he lp us e rs to prioritiz e appropriate re s pons e s te ps . Common Vulnerability Scoring System (CVSS) — A me tric s ys te m to e valuate s oftware vulne rabilitie s and as s ign the m s core s in orde r to he lp us e rs prioritiz e the ir s e curity ris ks . Integrity — An SCAP s pe cification to maintain inte grity of SCAP conte nt and s can re s ults . Trust Model for Security Automation Data (TMSAD) — A s e t of re comme ndations e xplaining us age of e xis ting s pe cification to re pre s e nt s ignature s , has he s , ke y information, and ide ntity information in conte xt of an XML file within a s e curity automation domain. Each of the SCAP compone nts has its own XML-bas e d docume nt format and its XML name s pace . A compliance policy e xpre s s e d in SCAP can e ithe r take a form of a s ingle OVAL de finition XML file , data s tre am file , s ingle z ip archive , or a s e t of s e parate XML file s containing an XCCDF file that re pre s e nts a policy che cklis t.

7.2.1. T he XCCDF File Format The XCCDF language is de s igne d to s upport information inte rchange , docume nt ge ne ration, organiz ational and s ituational tailoring, automate d compliance te s ting, and compliance s coring. The language is mos tly de s criptive and doe s not contain any commands to pe rform s e curity s cans . Howe ve r, an XCCDF docume nt can re fe r to othe r SCAP compone nts , and as s uch it can be us e d to craft a compliance policy that is portable among all the targe t platforms with the e xce ption of the re late d as s e s s me nt docume nts (OVAL, OCIL). The common way to re pre s e nt a compliance policy is a s e t of XML file s whe re one of the file s is an XCCDF che cklis t. This XCCDF file us ually points to the as s e s s me nt re s ource s , multiple OVAL, OCIL and the Script Che ck Engine (SCE) file s . Furthe rmore , the file s e t can contain a CPE dictionary file and an OVAL file de fining obje cts for this dictionary. Be ing an XML-bas e d language , the XCCDF de fine s and us e s a vas t s e le ction of XML e le me nts and attribute s . The following lis t brie fly introduce s the main XCCDF e le me nts ; for more de tails about XCCDF, cons ult the NIST Inte rage ncy Re port 7275 Re vis ion 4.

Main XML Element s o f t he XCCDF Do cument — This is a root e le me nt that e nclos e s the whole XCCDF docume nt. It may als o contain che cklis t me tadata, s uch as a title , de s cription, lis t of authors , date of the late s t modification, and s tatus of the che cklis t acce ptance . — This is a ke y e le me nt that re pre s e nts a che cklis t re quire me nt and holds its de s cription. It may contain child e le me nts that de fine actions ve rifying or e nforcing compliance with the give n rule or modify the rule its e lf. — This ke y e le me nt is us e d for e xpre s s ing prope rtie s of othe r XCCDF e le me nts within the be nchmark. — This e le me nt is us e d to organiz e an XCCDF docume nt to s tructure s with the s ame conte xt or re quire me nt domains by gathe ring the , , and e le me nts . — This e le me nt s e rve s for a name d tailoring of the XCCDF

207

Se c ur it y Guide

be nchmark. It allows the be nchmark to hold s e ve ral diffe re nt tailorings . utiliz e s s e ve ral s e le ctor e le me nts , s uch as or , to de te rmine which e le me nts are going to be modifie d and proce s s e d while it is in e ffe ct. — This e le me nt allows de fining the be nchmark profile s outs ide the be nchmark, which is s ome time s de s irable for manual tailoring of the compliance policy. — This e le me nt s e rve s for ke e ping the s can re s ults for the give n be nchmark on the targe t s ys te m. Each s hould re fe r to the profile that was us e d to de fine the compliance policy for the particular s can and it s hould als o contain important information about the targe t s ys te m that is re le vant for the s can. — This is a child e le me nt of that is us e d to hold the re s ult of applying a s pe cific rule from the be nchmark to the targe t s ys te m. — This is a child e le me nt of that s e rve s for re me diation of the targe t s ys te m that is not compliant with the give n rule . It can contain a command or s cript that is run on the targe t s ys te m in orde r to bring the s ys te m into compliance the rule . — This is a child e le me nt of that re fe rs to an e xte rnal s ource which de fine s how to e valuate the give n rule . — This is a s e le ctor e le me nt that is us e d for including or e xcluding the chos e n rule s or groups of rule s from the policy. — This is a s e le ctor e le me nt that is us e d for ove rwriting the curre nt value of the s pe cifie d e le me nt without modifying any of its othe r prope rtie s . — This is a s e le ctor e le me nt that is us e d for s pe cifying cons traints of the particular e le me nt during policy tailoring. — This s e le ctor e le me nt allows ove rwriting prope rtie s of the s e le cte d rule s .

Example 7.1. An Example o f an XCCDF Do cument

incomplete 0.1 Profile title is compulsory

208

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

telnet-server dhcpd tftpd The telnet-server Package Shall Not Be Installed Removing the telnet-server package decreases the risk of the telnet service’s accidental (or intentional) activation yum -y remove

7.2.2. T he OVAL File Format The Ope n Vulne rability As s e s s me nt Language (OVAL) is the e s s e ntial and olde s t compone nt of SCAP. The main goal of the OVAL s tandard is to e nable inte rope rability among s e curity products . That is achie ve d by s tandardiz ation of the following thre e domains :

1. Re pre s e ntation of the targe t s ys te m configuration. 2. Analys is of the targe t s ys te m for the pre s e nce of a particular machine s tate . 3. Re porting the re s ults of the comparis on be twe e n the s pe cifie d machine s tate and the obs e rve d machine s tate . Unlike othe r tools or cus tom s cripts , the OVAL language de s cribe s a de s ire d s tate of re s ource s in a de clarative manne r. The OVAL language code is ne ve r e xe cute d dire ctly, but by me ans of an OVAL inte rpre te r tool calle d scanner. The de clarative nature of OVAL e ns ure s that the s tate of the as s e s s e d s ys te m is not accide ntally modifie d, which is important be caus e s e curity s canne rs are ofte n run with the highe s t pos s ible privile ge s .

209

Se c ur it y Guide

OVAL s pe cification is ope n for public comme nts and contribution and various IT companie s collaborate with the MITRE Corporation, fe de rally funde d not-for-profit organiz ation. The OVAL s pe cification is continuous ly e volving and diffe re nt e ditions are dis tinguis he d by a ve rs ion numbe r. The curre nt ve rs ion 5.11.1 was re le as e d in April 2015. Like all othe r SCAP compone nts , OVAL is bas e d on XML. The OVAL s tandard de fine s s e ve ral docume nt formats . Each of the m include s diffe re nt kind of information and s e rve s a diffe re nt purpos e .

T he OVAL Do cument Fo rmat s The OVAL Definitions format is the mos t common OVAL file format that is us e d dire ctly for s ys te m s cans . The OVAL De finitions docume nt de s cribe s the de s ire d s tate of the targe t s ys te m. The OVAL Variables format de fine s variable s us e d to ame nd the OVAL De finitions docume nt. The OVAL Variable s docume nt is typically us e d in conjunction with the OVAL De finitions docume nt to tailor the s e curity conte nt for the targe t s ys te m at runtime . The OVAL System Characteristics format holds information about the as s e s s e d s ys te m. The OVAL Sys te m Characte ris tics docume nt is typically us e d to compare the actual s tate of the s ys te m agains t the e xpe cte d s tate de fine d by an OVAL De finitions docume nt. The OVAL Results is the mos t compre he ns ive OVAL format that is us e d to re port re s ults of the s ys te m e valuation. The OVAL Re s ults docume nt typically contains copy of the e valuate d OVAL de finitions , bound OVAL variable s , OVAL s ys te m characte ris tics , and re s ults of te s ts that are compute d bas e d on comparis on of the s ys te m characte ris tics and the de finitions . The OVAL Directives format is us e d to tailor ve rbos ity of an OVAL Re s ult docume nt by e ithe r including or e xcluding ce rtain de tails . The OVAL Common Model format contains de finitions of cons tructs and e nume rations us e d in s e ve ral othe r OVAL s che me s . It is us e d to re us e OVAL de finitions in orde r to avoid duplications acros s multiple docume nts . The OVAL De finitions docume nt cons is ts of a s e t of configuration re quire me nts whe re e ach re quire me nt is de fine d in the following five bas ic s e ctions : definitions, tests, objects, states, and variables. The e le me nts within the de finitions s e ction de s cribe which of the te s ts s hall be fulfille d to s atis fy the give n de finition. The te s t e le me nts link obje cts and s tate s toge the r. During the s ys te m e valuation, a te s t is cons ide re d pas s e d whe n a re s ource of the as s e s s e d s ys te m that is de note d by the give n obje ct e le me nt corre s ponds with the give n s tate e le me nt. The variable s s e ction de fine s e xte rnal variable s which may be us e d to adjus t e le me nts from the s tate s s e ction. Be s ide s the s e s e ctions , the OVAL De finitions docume nt typically contains als o the generator and signature s e ctions . The generator s e ction holds information about the docume nt origin and various additional information re late d to its conte nt. Each e le me nt from the OVAL docume nt bas ic s e ctions is unambiguous ly ide ntifie d by an ide ntifie r in the following form: oval:namespace:type:ID

210

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

whe re namespace is a name s pace de fining the ide ntifie r, type is e ithe r def for de finitions e le me nts , tst for te s ts e le me nts , obj for obje cts e le me nt, ste for s tate s e le me nts , and var for variable s e le me nts , and ID is an inte ge r value of the ide ntifie r.

Example 7.2. An Example o f an OVAL Def init io ns Do cument

vim 5.10.1 2012-11-22T15:00:00+01:00 Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 7 The operating system installed on the system is Red Hat Enterprise Linux 7 /etc/redhat-release ^redhat-release ^7[^\d]

7.2.3. T he Dat a St ream Format SCAP data s tre am is a file format us e d s ince SCAP ve rs ion 1.2 and it re pre s e nts a bundle of XCCDF, OVAL, and othe r compone nt file s which can be us e d to de fine a compliance policy e xpre s s e d by an XCCDF che cklis t. It als o contains an inde x and catalog that allow s plitting the give n data s tre am into file s according to the SCAP compone nts . The data s tre am us e s XML format that cons is ts of a he ade r forme d by a table of conte nts and a lis t of the e le me nts . Each of the s e e le me nts e ncompas s e s an SCAP compone nt s uch as XCCDF, OVAL, CPE, and othe r. The data s tre am file may contain multiple compone nts of the s ame type , and thus cove ring all s e curity policie s ne e de d by your organiz ation.

Example 7.3. An Example o f a Dat a St ream Header



7.3. Using SCAP Workbench SCAP Wo rkbench (scap-workbench) is a graphical utility that allows us e rs to pe rform configuration and vulne rability s cans on a s ingle local or a re mote s ys te m, pe rform re me diation of the s ys te m, and ge ne rate re ports bas e d on s can e valuations . Note that compare d with the o scap command-line utility, SCAP Wo rkbench has only limite d functionality. SCAP Wo rkbench can als o proce s s only s e curity conte nt in the form of XCCDF and data-s tre am file s . The following s e ctions e xplain how to ins tall, s tart, and utiliz e SCAP Workbe nch in orde r to pe rform s ys te m s cans , re me diation, s can cus tomiz ation, and dis play re le vant e xample s for the s e tas ks .

7.3.1. Inst alling SCAP Workbench To ins tall SCAP Wo rkbench on your s ys te m, e nte r the following command as root: ~]# yum install scap-workbench This command ins talls all package s re quire d by SCAP Workbe nch to function prope rly, including the scap-workbench package that provide s the utility its e lf. Note that re quire d de pe nde ncie s , s uch as the qt and openssh package s , will be automatically update d to the ne we s t available ve rs ion if the package s are alre ady ins talle d on your s ys te m. Be fore you can s tart us ing SCAP Workbe nch e ffe ctive ly, you als o ne e d to ins tall or import s ome s e curity conte nt on your s ys te m. For e xample , you can ins tall the SCAP Se curity Guide (SSG) package , scap-security-guide, which contains the curre ntly mos t e volve d and e laborate s e t of s e curity police s for Linux s ys te ms . To ins tall the SCAP Se curity Guide package on your s ys te m, e nte r the following command as root: ~]# yum install scap-security-guide Afte r you ins tall scap-security-guide on your s ys te m, unle s s s pe cifie d othe rwis e , the SSG s e curity conte nt is available unde r the /usr/share/xml/scap/ssg/content/ dire ctory, and you can proce e d with othe r s e curity compliance ope rations . To find othe r pos s ible s ource s of e xis ting SCAP conte nt that might s uit your ne e ds , s e e Se ction 7.9, “Additional Re s ource s ”.

7.3.2. Running SCAP Workbench Afte r a s ucce s s ful ins tallation of both, the SCAP Wo rkbench utility and SCAP conte nt, you can s tart us ing SCAP Wo rkbench on your s ys te ms . For running SCAP Wo rkbench from

214

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

the GNOME Classic de s ktop e nvironme nt, pre s s the Super ke y to e nte r the Activities Overview, type scap-workbench, and the n pre s s Enter. The Super ke y appe ars in a varie ty of guis e s , de pe nding on the ke yboard and othe r hardware , but ofte n as e ithe r the Windows or Command ke y, and typically to the le ft of the Spacebar ke y.

Figure 7.1. Open SCAP Securit y Guide Windo w As s oon as you s tart the utility, the Open SCAP Security Guide window appe ars . Afte r a s e le ction one of the guide s , the SCAP Workbench window appe ars . This window cons is ts of s e ve ral inte ractive compone nts , which you s hould be come familiar with be fore you s tart s canning your s ys te m: File This me nu lis t offe rs s e ve ral options to load or s ave a SCAP-re late d conte nt. To s how the initial Open SCAP Security Guide window, click the me nu ite m with the s ame name . Alte rnative ly, load anothe r cus tomiz ation file in the XCCDF format by clicking Open Other Content. To s ave your cus tomiz ation as an XCCDF XML file , us e the Save Customization Only ite m. The Save All allows you to s ave SCAP file s e ithe r to the s e le cte d dire ctory or as an RPM package .

215

Se c ur it y Guide

Cust o mizat io n This combo box informs you about the cus tomiz ation us e d for the give n s e curity policy. You can s e le ct cus tom rule s that will be applie d for the s ys te m e valuation by clicking this combo box. The de fault value is (no cust o mizat io n), which me ans that the re will be no change s to the us e d s e curity policy. If you made any change s to the s e le cte d s e curity profile , you can s ave thos e change s as an XML file by clicking the Save Customization Only ite m in the File me nu. Pro f ile This combo box contains the name of the s e le cte d s e curity profile . You can s e le ct the s e curity profile from a give n XCCDF or data-s tre am file by clicking this combo box. To cre ate a ne w profile that inhe rits prope rtie s of the s e le cte d s e curity profile , click the Customize button. T arget The two radio buttons e nable you to s e le ct whe the r the s ys te m to be e valuate d is a local or re mote machine . Select ed Rules This fie ld dis plays a lis t of s e curity rule s that are s ubje ct of the s e curity policy. Expanding a particular s e curity rule provide s de taile d information about that rule . St at us bar This is a graphical bar that indicate s s tatus of an ope ration that is be ing pe rforme d. Fet ch remo t e reso urces This che ck box allows to ins truct the s canne r to download a re mote OVAL conte nt de fine d in an XML file . Dry run Us e this che ck box to ge t command line argume nts to the diagnos tics window ins te ad of running the s can. Remediat e This che ck box e nable s the re me diation fe ature during the s ys te m e valuation. If you che ck this box, SCAP Workbe nch will atte mpt to corre ct s ys te m s e ttings that would fail to match the s tate de fine d by the policy. Scan This button allows you to s tart the e valuation of the s pe cifie d s ys te m.

216

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

Figure 7.2. SCAP Wo rkbench Windo w

7.3.3. Scanning t he Syst em The main functionality of SCAP Wo rkbench is to pe rform s e curity s cans on a s e le cte d s ys te m in accordance with the give n XCCDF or data s tre am file . To e valuate your s ys te m agains t the s e le cte d s e curity policy, follow the s e s te ps : 1. Se le ct a s e curity policy by us ing e ithe r the Open SCAP Security Guide window, or Open Other Content in the File me nu and s e arch the re s pe ctive XCCDF, SCAP RPM or data s tre am file .

Warning Se le cting a s e curity policy re s ults in the los s of any pre vious cus tomiz ation change s that we re not s ave d. To re -apply the los t options , you have to choos e the available profile and cus tomiz ation conte nt again. Note that your pre vious cus tomiz ations may not be applicable with the ne w s e curity policy.

217

Se c ur it y Guide

2. To us e a pre -arrange d a file with cus tomiz e d s e curity conte nt s pe cific to your us e cas e , you can load this file by clicking on the Cust o mizat io n combo box. You can als o cre ate a cus tom tailoring file by alte ring an available s e curity profile . For more information, s e e Se ction 7.3.4, “Cus tomiz ing Se curity Profile s ”. a. Se le ct the (no customization) option if you do not want to us e any cus tomiz ation for the curre nt s ys te m e valuation. This is the de fault option if no pre vious cus tomiz ation was s e le cte d. b. Se le ct the (open customization file...) option to s e arch for the particular tailoring file to be us e d for the curre nt s ys te m e valuation. c. If you have pre vious ly us e d s ome cus tomiz ation file , SCAP Wo rkbench re me mbe rs this file and adds it to the lis t. This s implifie s re pe titive application of the s ame s can. 3. Se le ct a s uitable s e curity profile by clicking the Pro f ile combo box. a. To modify the s e le cte d profile , click the Customize button. For more information about profile cus tomiz ation, s e e Se ction 7.3.4, “Cus tomiz ing Se curity Profile s ”. 4. Se le ct e ithe r of two Target radio buttons to s can e ithe r a local or a re mote machine . a. If you have s e le cte d a re mote s ys te m, s pe cify it by e nte ring the us e r name , hos t name , and the port information as s hown in the following e xample . If you have pre vious ly us e d the re mote s can, you can als o s e le ct a re mote s ys te m from a lis t of re ce ntly s canne d machine s .

Figure 7.3. Specif ying a Remo t e Syst em 5. You can allow automatic corre ction of the s ys te m configuration by s e le cting the Remediate che ck box. With this option e nable d, SCAP Wo rkbench atte mpts to change the s ys te m configuration in accordance with the s e curity rule s applie d by the policy, s hould the re late d che cks fail during the s ys te m s can.

Warning If not us e d care fully, running the s ys te m e valuation with the re me diation option e nable d could re nde r the s ys te m non-functional. 6. Click the Scan button to initiate the s ys te m s can.

7.3.4. Cust omizing Securit y Prof iles

218

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

Afte r s e le cting the s e curity profile that s uits your s e curity policy, you can furthe r adjus t it by clicking the Customize button. This will ope n the ne w Cus tomiz ation window that allows you to modify the curre ntly s e le cte d XCCDF profile without actually changing the re s pe ctive XCCDF file .

Figure 7.4. Cust o mizing t he Select ed Securit y Pro f ile The Customization window contains a comple te s e t of XCCDF e le me nts re le vant to the s e le cte d s e curity profile with de taile d information about e ach e le me nt and its functionality. You can e nable or dis able the s e e le me nts by s e le cting or de -s e le cting the re s pe ctive che ck boxe s in the main fie ld of this window. The Customization window als o s upports undo and redo functionality; you can undo or re do your s e le ctions by clicking the re s pe ctive arrow icon in the top le ft corne r of the window. You can als o change variable s that will late r be us e d for e valuation. Find the de s ire d ite m in the Customization window, navigate to the right part and us e the Modify value fie ld.

219

Se c ur it y Guide

Figure 7.5. Set t ing a value f o r t he select ed it em in t he Cust o mizat io n windo w Afte r you have finis he d your profile cus tomiz ations , confirm the change s by clicking the Confirm Customization button. Your change s are now in the me mory and do not pe rs is t if SCAP Wo rkbench is clos e d or ce rtain change s , s uch as s e le cting a ne w SCAP conte nt or choos ing anothe r cus tomiz ation option, are made . To s tore your change s , click the Save Customization button in the SCAP Workbench window. This action allows you to s ave your change s to the s e curity profile as an XCCDF cus tomiz ation file in the chos e n dire ctory. Note that this cus tomiz ation file can be furthe r s e le cte d with othe r profile s .

7.3.5. Saving SCAP Cont ent SCAP Wo rkbench als o allows you to s ave SCAP conte nt that is us e d with your s ys te m e valuations . You can e ithe r s ave a cus tomiz ation file s e parate ly (s e e Se ction 7.3.4, “Cus tomiz ing Se curity Profile s ”) or you can s ave all s e curity conte nt at once by clicking the Save content combo box and s e le cting e ithe r the Save into a directory or Save as RPM options . By s e le cting the Save into a directory option, SCAP Wo rkbench s ave s both the XCCDF or data-s tre am file and the cus tomiz ation file to the s pe cifie d location. This can be us e ful as a backup s olution. By s e le cting the Save as RPM option, you can ins truct SCAP Wo rkbench to cre ate an RPM package containing the XCCDF or data s tre am file and cus tomiz ation file . This is us e ful for dis tributing the de s ire d s e curity conte nt to s ys te ms that cannot be s canne d re mote ly, or jus t for de live ring the conte nt for furthe r proce s s ing.

220

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

Figure 7.6. Saving t he Current SCAP Co nt ent as an RPM Package

7.3.6. Viewing Scan Result s and Generat ing Scan Report s Afte r the s ys te m s can is finis he d, thre e ne w buttons , Clear, Save Results, and Show Report, will appe ar ins te ad of the Scan button.

Warning Clicking the Clear button pe rmane ntly re move s the s can re s ults . To s tore the s can re s ults in the form of an XCCDF, ARF, or HTML file , click the Save Results combo box. Choos e the HTML Report option to ge ne rate the s can re port in human-re adable form. The XCCDF and ARF (data s tre am) formats are s uitable for furthe r automatic proce s s ing. You can re pe ate dly choos e all thre e options . If you pre fe r to vie w the s can re s ults imme diate ly without s aving the m, you can click the Show Report button, which ope ns the s can re s ults in the form of a te mporary HTML file in your de fault we b brows e r.

7.4. Using oscap 221

Se c ur it y Guide

The o scap command-line utility allows us e rs to s can the ir local s ys te ms , validate s e curity compliance conte nt, and ge ne rate re ports and guide s bas e d on the s e s cans and e valuations . This utility s e rve s as a front e nd to the Ope nSCAP library and groups its functionalitie s to module s (s ub-commands ) bas e d on the type of SCAP conte nt it proce s s e s . The following s e ctions e xplain how to ins tall o scap and pe rform the mos t common ope rations . Example s are provide d to illus trate the s e tas ks . To le arn more about s pe cific s ub-commands , us e the --help option with an o scap command: oscap [options] module module_operation [module_operation_options_and_arguments] --help whe re module re pre s e nts the type of SCAP conte nt that is be ing proce s s e d, and module_operation is a s ub-command for the s pe cific ope ration on the SCAP conte nt.

Example 7.4. Get t ing Help o n a Specif ic o scap Operat io n ~]$ oscap ds sds-split --help oscap -> ds -> sds-split Split given SourceDataStream into separate files Usage: oscap [options] ds sds-split [options] SDS TARGET_DIRECTORY SDS - Source data stream that will be split into multiple files. TARGET_DIRECTORY - Directory of the resulting files. Options: --datastream-id collection to use. --xccdf-id should be evaluated.

- ID of the datastream in the - ID of XCCDF in the datastream that

To le arn about all o scap fe ature s and the comple te lis t of its options , s e e the oscap(8) manual page .

7.4.1. Inst alling oscap To ins tall o scap to your s ys te m, e nte r the following command as root: ~]# yum install openscap-scanner This command allows you to ins tall all package s re quire d by o scap to function prope rly, including the openscap package . To be able to write your own s e curity conte nt, you s hould als o ins tall the openscap-engine-sce package , which provide s the Script Che ck Engine (SCE). The SCE is an e xte ns ion of the SCAP protocol that allows conte nt authors to write the ir s e curity conte nt us ing a s cripting language , s uch as Bas h, Python, or Ruby. Note that the openscap-engine-sce package is only available from the Optional channe l. Se e Enabling Supple me ntary and Optional Re pos itorie s .

222

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

Optionally, afte r ins talling o scap, you can che ck the capabilitie s of your ve rs ion of o scap, what s pe cifications it s upports , whe re the ce rtain o scap file s are s tore d, what kinds of SCAP obje cts you can us e , and othe r us e ful information. To dis play this information, type the following command: ~]$ oscap -V OpenSCAP command line tool (oscap) 1.0.4 Copyright 2009--2014 Red Hat Inc., Durham, North Carolina. ==== Supported specifications ==== XCCDF Version: 1.2 OVAL Version: 5.10.1 CPE Version: 2.3 CVSS Version: 2.0 CVE Version: 2.0 Asset Identification Version: 1.1 Asset Reporting Format Version: 1.1 ==== Capabilities added by auto-loaded plugins ==== SCE Version: 1.0 (from libopenscap_sce.so.8) ==== Paths ==== Schema files: /usr/share/openscap/schemas Schematron files: /usr/share/openscap/xsl Default CPE files: /usr/share/openscap/cpe Probes: /usr/libexec/openscap ==== Inbuilt CPE names ==== Red Hat Enterprise Linux - cpe:/o:redhat:enterprise_linux Red Hat Enterprise Linux 5 - cpe:/o:redhat:enterprise_linux:5 Red Hat Enterprise Linux 6 - cpe:/o:redhat:enterprise_linux:6 Red Hat Enterprise Linux 7 - cpe:/o:redhat:enterprise_linux:7 Fedora 16 - cpe:/o:fedoraproject:fedora:16 Fedora 17 - cpe:/o:fedoraproject:fedora:17 Fedora 18 - cpe:/o:fedoraproject:fedora:18 Fedora 19 - cpe:/o:fedoraproject:fedora:19 Fedora 20 - cpe:/o:fedoraproject:fedora:20 Fedora 21 - cpe:/o:fedoraproject:fedora:21 Red Hat Enterprise Linux Optional Productivity Applications cpe:/a:redhat:rhel_productivity Red Hat Enterprise Linux Optional Productivity Applications 5 cpe:/a:redhat:rhel_productivity:5 ==== Supported OVAL objects and associated OpenSCAP probes ==== system_info probe_system_info family probe_family filehash probe_filehash environmentvariable probe_environmentvariable textfilecontent54 probe_textfilecontent54 textfilecontent probe_textfilecontent variable probe_variable xmlfilecontent probe_xmlfilecontent environmentvariable58 probe_environmentvariable58 filehash58 probe_filehash58 inetlisteningservers probe_inetlisteningservers rpminfo probe_rpminfo

223

Se c ur it y Guide

partition iflisteners rpmverify rpmverifyfile rpmverifypackage selinuxboolean selinuxsecuritycontext file interface password process runlevel shadow uname xinetd sysctl process58 fileextendedattribute routingtable

probe_partition probe_iflisteners probe_rpmverify probe_rpmverifyfile probe_rpmverifypackage probe_selinuxboolean probe_selinuxsecuritycontext probe_file probe_interface probe_password probe_process probe_runlevel probe_shadow probe_uname probe_xinetd probe_sysctl probe_process58 probe_fileextendedattribute probe_routingtable

Be fore you can s tart us ing o scap e ffe ctive ly, you als o ne e d to ins tall or import s ome s e curity conte nt on your s ys te m. For e xample , you can ins tall the SCAP Se curity Guide (SSG) package , scap-security-guide, which contains the curre ntly mos t e volve d and e laborate s e t of s e curity police s for Linux s ys te ms . To ins tall the SCAP Se curity Guide package on your s ys te m, e nte r the following command as root: ~]# yum install scap-security-guide Afte r you ins tall scap-security-guide on your s ys te m, unle s s s pe cifie d othe rwis e , the SSG s e curity conte nt is available unde r the /usr/share/xml/scap/ssg/content/ dire ctory, and you can proce e d with othe r s e curity compliance ope rations . To find othe r pos s ible s ource s of e xis ting SCAP conte nt that might s uit your ne e ds , s e e Se ction 7.9, “Additional Re s ource s ”. Afte r ins talling the SCAP conte nt on your s ys te m, o scap can proce s s the conte nt whe n s upplie d with the file path to the conte nt. The o scap utility s upports SCAP ve rs ion 1.2 and is backward-compatible with SCAP ve rs ions 1.1 and 1.0, s o it can proce s s e arlie r ve rs ions of SCAP conte nt without any s pe cial re quire me nts .

7.4.2. Displaying SCAP Cont ent SCAP s tandard de fine s nume rous file formats . The o scap utility can proce s s or cre ate file s conforming to many of the formats . In orde r to furthe r proce s s the give n file with SCAP conte nt, you ne e d to unde rs tand how to us e o scap with the give n file type . If you are uns ure how to us e a particular file , you can e ithe r ope n and re ad the file , or you can us e the info module of o scap which pars e s the file and e xtracts re le vant information in human-re adable format. e nte r the following command to e xamine the inte rnal s tructure of a SCAP docume nt and dis play us e ful information s uch as the docume nt type , s pe cification ve rs ion, a s tatus of the docume nt, the date the docume nt was publis he d, and the date the docume nt was copie d to a file s ys te m: oscap info file

224

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

whe re file is the full path to the s e curity conte nt file be ing e xamine d. The following e xample be tte r illus trate s the us age of the oscap info command:

Example 7.5. Displaying Inf o rmat io n Abo ut SCAP Co nt ent ~]$ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml Document type: Source Data Stream Imported: 2014-03-14T12:22:01 Stream: scap_org.open-scap_datastream_from_xccdf_ssg-rhel7-xccdf1.2.xml Generated: (null) Version: 1.2 Checklists: Ref-Id: scap_org.open-scap_cref_ssg-rhel7-xccdf-1.2.xml Profiles: xccdf_org.ssgproject.content_profile_test xccdf_org.ssgproject.content_profile_rht-ccp xccdf_org.ssgproject.content_profile_common xccdf_org.ssgproject.content_profile_stigrhel7-server-upstream Referenced check files: ssg-rhel7-oval.xml system: http://oval.mitre.org/XMLSchema/oval-definitions-5 Checks: Ref-Id: scap_org.open-scap_cref_ssg-rhel7-oval.xml Ref-Id: scap_org.open-scap_cref_output--ssg-rhel7-cpe-oval.xml Ref-Id: scap_org.open-scap_cref_output--ssg-rhel7-oval.xml Dictionaries: Ref-Id: scap_org.open-scap_cref_output--ssg-rhel7-cpedictionary.xml

7.4.3. Scanning t he Syst em The mos t important functionality of o scap is to pe rform configuration and vulne rability s cans of a local s ys te m. The following is a ge ne ral s yntax of the re s pe ctive command: oscap [options] module eval [module_operation_options_and_arguments] The o scap utility can s can s ys te ms agains t the SCAP conte nt re pre s e nte d by both an XCCDF (The e Xte ns ible Configuration Che cklis t De s cription Format) be nchmark and OVAL (Ope n Vulne rability and As s e s s me nt Language ) de finitions . The s e curity policy can be in the form of a s ingle OVAL or XCCDF file or multiple s e parate XML file s whe re e ach file re pre s e nts a diffe re nt compone nt (XCCDF, OVAL, CPE, CVE, and othe rs ). The re s ult of a s can can be printe d to both s tandard output and an XML file . The re s ult file can the n be furthe r proce s s e d by o scap in orde r to ge ne rate a re port in a human-re adable format. The following e xample s illus trate the mos t common us age of the command.

Example 7.6. Scanning t he Syst em Using t he SSG OVAL def init io ns

225

Se c ur it y Guide

To s can your s ys te m agains t the SSG OVAL de finition file while e valuating all de finitions , e nte r the following command: ~]$ oscap oval eval --results scan-oval-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml The re s ults of the s can are s tore d as the scan-oval-results.xml file in the curre nt dire ctory.

Example 7.7. Scanning t he Syst em Using t he SSG OVAL def init io ns To e valuate a particular OVAL de finition from the s e curity policy re pre s e nte d by the SSG data s tre am file , e nte r the following command: ~]$ oscap oval eval --id oval:ssg:def:100 --results scan-ovalresults.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml The re s ults of the s can are s tore d as the scan-oval-results.xml file in the curre nt dire ctory.

Example 7.8. Scanning t he Syst em Using t he SSG XCCDF benchmark To pe rform the SSG XCCDF be nchmark for the xccdf_org.ssgproject.content_profile_rht-ccp profile on your s ys te m, e nte r the following command: ~]$ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-ccp --results scan-xccdfresults.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml The re s ults of the s can are s tore d as the scan-xccdf-results.xml file in the curre nt dire ctory.

No te The --profile command-line argume nt s e le cts the s e curity profile from the give n XCCDF or data s tre am file . The lis t of available profile s can be obtaine d by running the oscap info command. If the --profile command-line argume nt is omitte d the de fault XCCDF profile is us e d as re quire d by SCAP s tandard. Note that the de fault XCCDF profile may or may not be an appropriate s e curity policy.

7.4.4. Generat ing Report s and Guides Anothe r us e ful fe ature s of o scap is the ability to ge ne rate SCAP conte nt in a humanre adable format. The o scap utility allows you to trans form an XML file into the HTML or plain-te xt format. This fe ature is us e d to ge ne rate s e curity guide s and che cklis ts , which s e rve as a s ource of information, as we ll as guidance for s e cure s ys te m configuration. The re s ults of s ys te m s cans can als o be trans forme d to we ll-re adable re s ult re ports . The ge ne ral command s yntax is the following:

226

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

oscap module generate sub-module [specific_module/submodule_options_and_arguments] file whe re module is e ithe r xccdf or oval, sub-module is a type of the ge ne rate d docume nt, and file re pre s e nts an XCCDF or OVAL file . The following are the mos t common e xample s of the command us age :

Example 7.9. Generat ing a Guide wit h a Checklist To produce an SSG guide with a che cklis t for the xccdf_org.ssgproject.content_profile_rht-ccp profile , e nte r the following command: ~]$ oscap xccdf generate guide --profile xccdf_org.ssgproject.content_profile_rht-ccp /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml > ssg-guidechecklist.html The guide is s tore d as the ssg-guide-checklist.html file in the curre nt dire ctory.

Example 7.10 . T ransf o rming an SSG OVAL Scan Result int o a Repo rt To trans form a re s ult of an SSG OVAL s can into an HTML file , e nte r the following command: ~]$ oscap oval generate report scan-oval-results.xml > ssg-scan-ovalreport.html The re s ult re port is s tore d as the ssg-scan-oval-report.html file in the curre nt dire ctory. This e xample as s ume s that you run the command from the s ame location whe re the scan-oval-results.xml file is s tore d. Othe rwis e you ne e d to s pe cify the fully-qualifie d path of the file that contains the s can re s ults .

Example 7.11. T ransf o rming an SSG XCCDF Scan Result int o a Repo rt To trans form a re s ult of an SSG XCCDF s can into an HTML file , e nte r the following command: ~]$ oscap xccdf generate report scan-xccdf-results.xml > scan-xccdfreport.html The re s ult re port is s tore d as the ssg-scan-xccdf-report.html file in the curre nt dire ctory. Alte rnative ly, you can ge ne rate this re port in the time of the s can us ing the -report command-line argume nt: ~]$ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-ccp --results scan-xccdfresults.xml --report scan-xccdf-report.html /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

227

Se c ur it y Guide

7.4.5. Validat ing SCAP Cont ent Be fore you s tart us ing a s e curity policy on your s ys te ms , you s hould firs t ve rify the policy in orde r to avoid any pos s ible s yntax or s e mantic e rrors in the policy. The o scap utility can be us e d to validate the s e curity conte nt agains t s tandard SCAP XML s che mas . The validation re s ults are printe d to the s tandard e rror s tre am (s tde rr). The ge ne ral s yntax of s uch a validation command is the following: oscap module validate [module_options_and_arguments] file whe re file is the full path to the file be ing validate d. The only e xce ption is the data s tre am module (ds ), which us e s the sds-validate ope ration ins te ad of validate. Note that all SCAP compone nts within the give n data s tre am are validate d automatically and none of the compone nts is s pe cifie d s e parate ly, as can be s e e n in the following e xample : ~]$ oscap ds sds-validate /usr/share/xml/scap/ssg/content/ssg-rhel7ds.xml With ce rtain SCAP conte nt, s uch as OVAL s pe cification, you can als o pe rform a Sche matron validation. The Sche matron validation is s lowe r than the s tandard validation but provide s de e pe r analys is , and is thus able to de te ct more e rrors . The following SSG e xample s hows typical us age of the command: ~]$ oscap oval validate --schematron /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

7.4.6. Using OpenSCAP t o Remediat e t he Syst em OpenSCAP allows to automatically re me diate s ys te ms that have be e n found in a noncompliant s tate . For s ys te m re me diation, an XCCDF file with ins tructions is re quire d. The scap-security-guide package cons tains ce rtain re me diation ins tructions . Sys te m re me diation cons is ts of the following s te ps : 1. OpenSCAP pe rforms a re gular XCCDF e valuation. 2. An as s e s s me nt of the re s ults is pe rforme d by e valuating the OVAL de finitions . Each rule that has faile d is marke d as a candidate for re me diation. 3. OpenSCAP s e arche s for an appropriate fix e le me nt, re s olve s it, pre pare s the e nvironme nt, and e xe cute s the fix s cript. 4. Any output of the fix s cript is capture d by OpenSCAP and s tore d within the ruleresult e le me nt. The re turn value of the fix s cript is s tore d as we ll. 5. Whe ne ve r OpenSCAP e xe cute s a fix s cript, it imme diate lly e valuate s the OVAL de finition again (to ve rify that the fix s cript has be e n applie d corre ctly). During this s e cond run, if the OVAL e valuation re turns s ucce s s , the re s ult of the rule is fixed, othe rwis e it is an error. 6. De taile d re s ults of the re me diation are s tore d in an output XCCDF file . It contains two TestResult e le me nts . The firs t TestResult e le me nt re pre s e nts the s can prior to the re me diation. The s e cond TestResult is de rive d from the firs t one and contains re me diation re s ults .

228

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

The re are thre e mode s of ope ration of OpenSCAP with re gard to re me diation: online , offline , and re vie w.

7.4.6.1. OpenSCAP Online Remediat ion Online re me diation e xe cute s fix e le me nts at the time of s canning. Evaluation and re me diation are pe rforme d as a part of a s ingle command. To e nable online re me diation, us e the --remediate command-line option. For e xample , to e xe cute online re me diation us ing the scap-security-guide package , run: ~]$ oscap xccdf eval --remediate --profile xccdf_org.ssgproject.content_profile_rht-ccp --results scan-xccdfresults.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml The output of this command cons is ts of two s e ctions . The firs t s e ction s hows the re s ult of the s can prior to the re me diation, and the s e cond s e ction s hows the re s ult of the s can afte r applying the re me diation. The s e cond part can contain only fixed and error re s ults . The fixed re s ult indicate s that the s can pe rforme d afte r the re me diation pas s e d. The error re s ult indicate s that e ve n afte r applying the re me diation, the e valuation s till doe s not pas s .

7.4.6.2. OpenSCAP Of f line Remediat ion Offline re me diation allows you to pos tpone fix e xe cution. In the firs t s te p, the s ys te m is only e valuate d, and the re s ults are s tore d in a TestResult e le me nt in an XCCDF file . In the s e cond s te p, oscap e xe cute s the fix s cripts and ve rifie s the re s ult. It is s afe to s tore the re s ults into the input file , no data will be los t. During offline re me diation, OpenSCAP cre ate s a ne w TestResult e le me nt that is bas e d on the input one and inhe rits all the data. The ne wly cre ate d TestResult diffe rs only in the rule-result e le me nts that have faile d. For thos e , re me diation is e xe cute d. To pe rform offline re me diation us ing the scap-security-guide package , run: ~]$ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-ccp --results scan-xccdfresults.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml ~]$ oscap xccdf remediate --results scan-xccdf-results.xml scan-xccdfresults.xml

7.4.6.3. OpenSCAP Remediat ion Review The re vie w mode allows us e rs to s tore re me diation ins tructions to a file for furthe r re vie w. The re me diation conte nt is not e xe cute d during this ope ration. To ge ne rate re me diation ins tructions in the form of a s he ll s cript, run: ~]$ oscap xccdf generate fix --template urn:xccdf:fix:script:sh -profile xccdf_org.ssgproject.content_profile_rht-ccp --output myremediation-script.sh /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

7.5. Using OpenSCAP wit h Docker 229

Se c ur it y Guide

7.5. Using OpenSCAP wit h Docker The oscap-docker command-line utility allows us e rs to us e the oscap program to s can the ir docke r-formatte d containe r image s and containe rs almos t in the s ame way as the ir local s ys te ms . The following s e ction e xplains the ins tallation of oscap-docker and offe rs bas ic e xample s of us age . To le arn more about s ub-commands , us e the --help option with the oscapdocker or oscap commands . To e nable the s canning of image s and containe rs , you ne e d to have the docker package ins talle d, too. Se e the Ge tting Docke r in Re d Hat Ente rpris e Linux 7 chapte r of the Getting Started with Containers guide for ins tructions on ins talling Do cker. e nte r the following command to ins tall oscap-docker: # yum install openscap-utils

Example 7.12. Using o scap-do cker oscap-docker scan_target[-cve] target_identifier [oscap-arguments] Whe re scan_target is an image or a containe r to s can, and target_identifier is the name or the ID of the targe t. The s e cond of the following commands attache s a containe r image , de te rmine s the variant and ve rs ion of the ope rating s ys te m, downloads the CVE s tre am applicable to the give n s ys te m, and finally runs the vulne rability s can: # docker images REPOSITORY registry.access.redhat.com/rhel7 c453594215e4

TAG latest

IMAGE ID

# oscap-docker image-cve registry.access.redhat.com/rhel7 The s e cond of the following commands runs the OpenSCAP s can within a chroot e nvironme nt of a running containe r. The re s ults may diffe r from s canning of a containe r image due to de fine d mount points . We us e d the OVAL patch de finition com.redhat.rhsa-all.xml in this e xample . # docker ps CONTAINER ID 5ef05eef4a01 sleepy_kirch

IMAGE COMMAND NAMES registry.access.redhat.com/rhel7 "/bin/bash"

# oscap-docker container 5ef05eef4a01 oval eval com.redhat.rhsaall.xml

7.6. Using OpenSCAP wit h At omic

230

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

To ve rify all the containe r image s and containe rs pre s e nt on the s ys te m are fre e of known CVE vulne rabilitie s or common mis configurations , us e the OpenSCAP s canning capabilitie s through the atomic scan command.

At omic Scan To ins tall the atomic tool on your s ys te m for containe r manage me nt, e nte r the following command as root: # yum install atomic Afte r the atomic tool is ins talle d, you als o ne e d a s canne r. Re d Hat re comme nds choos ing the OpenSCAP-bas e d rhel7/openscap docke r image . Ins tall it by running the following command as root: # atomic install rhel7/openscap Once the OpenSCAP docke r image is in place , you can is s ue atomic scan commands . Scan the containe rs and containe r image s by running the following command as root: # atomic scan $ID Whe re $ID is the ID of the containe r. If you want to s can all containe r image s or containe rs , us e the --images or --containers dire ctive , re s pe ctive ly. To s can both type s , us e the --all dire ctive .

T he OpenSCAP Scanner The rhel7/openscap containe r image as the de fault s canne r of the atomic scan curre ntly s upports two s can type s targe ting Re d Hat Ente rpris e Linux s ys te ms only. Supporte d s can type s can be lis te d by running the following command as root: # atomic scan --scanner openscap --list The de fault s can type is CVE scan. Us e it for che cking the targe t for known s e curity vulne rabilitie s as de fine d in the CVE OVAL de finitions re le as e d by Re d Hat.

Warning The OVAL de finitions us e d by the CVE scan type are bundle d in the containe r image during the build proce s s , and as s uch are not always up-to-date . The s e cond s upporte d s can type is standards_compliance, whe re Standard Sys te m Se curity Profile of the bundle d SCAP Se curity Guide is us e d for e valuation. This is s e curity bas e line profile of Re d Hat Ente rpris e Linux.

Example 7.13. Scanning t he Co nt ainer Image wit h At o mic Scan The following e xample of the atomic scan us age s hows how to s can a Re d Hat Ente rpris e Linux image and the n lis t of all found vulne rabilitie s with --verbose dire ctive .

231

Se c ur it y Guide

# docker pull rhel7 Using default tag: latest 98a88a8b722a: Download complete # atomic scan 98a88a8b722a Container/Image Cri Imp Med Low ----------------------98a88a8b722a 0 0 0 0 # atomic scan --verbose 98a88a8b722a docker run -t --rm -v /etc/localtime:/etc/localtime -v /run/atomic/2016-10-14-06-42-55-991951:/scanin -v /var/lib/atomic/openscap/2016-10-14-06-42-55-991951:/scanout:rw,Z -v /etc/oscapd:/etc/oscapd:ro rhel7/openscap oscapd-evaluate scan --nostandard-compliance --targets chroots-in-dir:///scanin --output /scanout INFO:OpenSCAP Daemon one-off evaluator 0.1.6 WARNING:Can't import the 'docker' package. Container scanning functionality will be disabled. INFO:Creating tasks directory at '/var/lib/oscapd/tasks' because it didn't exist. INFO:Creating results directory at '/var/lib/oscapd/results' because it didn't exist. INFO:Creating results work in progress directory at '/var/lib/oscapd/work_in_progress' because it didn't exist. INFO:Evaluated EvaluationSpec, exit_code=0. INFO:Evaluated EvaluationSpec, exit_code=0. INFO:[100.00%] Scanned target 'chroot:///scanin/98a88a8b722a71835dd761c88451c681a8f1bc6e577f90d4dc8b 234100bd4861' 98a88a8b722a (registry.access.redhat.com/rhel7:latest) 98a88a8b722a passed the scan Files associated with this scan are in /var/lib/atomic/openscap/201610-14-06-42-55-991951.

No te A de taile d de s cription of the atomic command us age and containe rs is found in the Product Docume ntation for Re d Hat Ente rpris e Linux Atomic Hos t. The Re d Hat Cus tome r Portal als o provide s a guide to the Atomic command line inte rface (CLI).

7.7. Using OpenSCAP wit h Red Hat Sat ellit e Whe n running multiple Re d Hat Ente rpris e Linux s ys te ms , it is important to ke e p all your s ys te ms compliant with your s e curity policy and pe rform s e curity s cans and e valuations re mote ly from one location. This can be achie ve d by us ing Re d Hat Sate llite 5.5 or late r with the spacewalk-oscap package ins talle d on your Sate llite clie nt. The package is available from the Red Hat Net wo rk T o o ls channe l. Se e How to e nable /dis able a re pos itory us ing Re d Hat Subs cription-Manage r?

232

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

This s olution s upports two me thods of pe rforming s e curity compliance s cans , vie wing and furthe r proce s s ing of the s can re s ults . You can e ithe r us e the OpenSCAP Satellite Web Interface or run commands and s cripts from the Satellite API. For more information about this s olution to s e curity compliance , its re quire me nts and capabilitie s , s e e the Re d Hat Sate llite docume ntation.

7.8. Pract ical Examples This s e ction de mons trate s practical us age of ce rtain s e curity conte nt provide d for Re d Hat products .

7.8.1. Audit ing Securit y Vulnerabilit ies of Red Hat Product s Re d Hat continuous ly provide s OVAL de finitions for the ir products . The s e de finitions allow for fully automate d audit of vulne rabilitie s in the ins talle d s oftware . To find out more information about this proje ct, s e e http://www.re dhat.com/s e curity/data/me trics /. To download the s e de finitions , e nte r the following command: ~]$ wget http://www.redhat.com/security/data/oval/com.redhat.rhsaall.xml The us e rs of Re d Hat Sate llite 5 may find us e ful the XCCDF part of the patch de finitions . To download the s e de finitions , e nte r the following command: ~]$ wget http://www.redhat.com/security/data/metrics/com.redhat.rhsaall.xccdf.xml To audit s e curity vulne rabilitie s for the s oftware ins talle d on the s ys te m, e nte r the following command: ~]$ oscap oval eval --results rhsa-results-oval.xml --report ovalreport.html com.redhat.rhsa-all.xml The o scap utility maps Re d Hat Se curity Advis orie s to CVE ide ntifie rs that are linke d to the National Vulne rability Databas e and re ports which s e curity advis orie s are not applie d.

No te Note that the s e OVAL de finitions are de s igne d to only cove r s oftware and update s re le as e d by Re d Hat. You ne e d to provide additional de finitions in orde r to de te ct the patch s tatus of third-party s oftware .

7.8.2. Audit ing Syst em Set t ings wit h SCAP Securit y Guide The SCAP Se curity Guide (SSG) proje ct's package , scap-security-guide, contains the late s t s e t of s e curity police s for Linux s ys te ms . To ins tall the SCAP Se curity Guide package on your s ys te m, e nte r the following command as root: ~]# yum install scap-security-guide

233

Se c ur it y Guide

A part of scap-security-guide is als o a guidance for Re d Hat Ente rpris e Linux 7 s e ttings . To ins pe ct the s e curity conte nt available with scap-security-guide, us e the oscap info module : ~]$ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml The output of this command is an outline of the SSG docume nt and it contains available configuration profile s . To audit your s ys te m s e ttings , choos e a s uitable profile and run the appropriate e valuation command. For e xample , the following command is us e d to as s e s s the give n s ys te m agains t a draft SCAP profile for Re d Hat Ce rtifie d Cloud Provide rs : ~]$ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rhtccp --results ssg-rhel7-xccdf-result.xml --report ssg-rhel7-report.html /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

7.9. Addit ional Resources For more information about various s e curity compliance fie lds of inte re s t, s e e the re s ource s be low.

Inst alled Document at ion os cap(8) — The manual page for the o scap command-line utility provide s a comple te lis t of available options and the ir us age e xplanation. s cap-workbe nch(8) — The manual page for the SCAP Workbench application provide s a bas ic information about the application as we ll as s ome links to pote ntial s ource s of SCAP conte nt. s cap-s e curity-guide (8) — The manual page for scap-securit y-guide provide s furthe r docume ntation about the various available SCAP s e curity profile s . Example s how to utiliz e the provide d be nchmarks us ing the OpenSCAP utility are provide d as we ll.

Online Document at ion The Ope nSCAP proje ct page — The home page to the Ope nSCAP proje ct provide s de taile d information about the o scap utility and othe r compone nts and proje cts re late d to SCAP. The SCAP Workbe nch proje ct page — The home page to the SCAP Workbe nch proje ct provide s de taile d information about the scap-wo rkbench application. The SCAP Se curity Guide (SSG) proje ct page — The home page to the SSG proje ct that provide s the late s t s e curity conte nt for Re d Hat Ente rpris e Linux. National Ins titute of Standards and Te chnology (NIST) SCAP page — This page re pre s e nts a vas t colle ction of SCAP re late d mate rials , including SCAP publications , s pe cifications , and the SCAP Validation Program. National Vulne rability Databas e (NVD) — This page re pre s e nts the large s t re pos itory of SCAP conte nt and othe r SCAP s tandards bas e d vulne rability manage me nt data. Re d Hat OVAL conte nt re pos itory — This is a re pos itory containing OVAL de finitions for Re d Hat Ente rpris e Linux s ys te ms .

234

⁠C hapt e r 7. Co mplianc e and Vulne r abilit y Sc anning wit h O pe nSCAP

MITRE CVE — This is a databas e of publicly known s e curity vulne rabilitie s provide d by the MITRE corporation. MITRE OVAL — This page re pre s e nts an OVAL re late d proje ct provide d by the MITRE corporation. Amongs t othe r OVAL re late d information, the s e page s contain the late s t ve rs ion of the OVAL language and a huge re pos itory of OVAL conte nt, counting ove r 22 thous ands OVAL de finitions . Re d Hat Sate llite docume ntation — This s e t of guide s de s cribe s , amongs t othe r topics , how to maintain s ys te m s e curity on multiple s ys te ms by us ing Ope nSCAP.

235

Se c ur it y Guide

Chapt er 8. Federal St andards and Regulat ions In orde r to maintain s e curity le ve ls , it is pos s ible for your organiz ation to make e fforts to comply with fe de ral and indus try s e curity s pe cifications , s tandards and re gulations . This chapte r de s cribe s s ome of the s e s tandards and re gulations .

8.1. Federal Informat ion Processing St andard (FIPS) The Fe de ral Information Proce s s ing Standard (FIPS) Publication 140-2 is a compute r s e curity s tandard, de ve lope d by the U.S. Gove rnme nt and indus try working group to validate the quality of cryptographic module s . Se e the official FIPS publications he re : http://cs rc.nis t.gov/publications /Pubs FIPS.html. At the time of the Re d Hat Ente rpris e Linux 7.3 re le as e , Publication 140-3 is at Draft s tatus , and may not re pre s e nt the comple te d s tandard. The FIPS 140-2 s tandard e ns ure s that cryptographic tools imple me nt the ir algorithms prope rly. Se e the full FIPS 140-2 s tandard at http://dx.doi.org/10.6028/NIST.FIPS.140-2 for furthe r de tails on the s e le ve ls and the othe r s pe cifications of the FIPS s tandard. To s e e the comple te lis t of all FIPS 140-2 ce rtificate s , vis it http://cs rc.nis t.gov/groups /STM/cmvp/docume nts /140-1/140val-all.htm. To le arn about compliance re quire me nts , s e e the Re d Hat Gove rnme nt: Standards page .

8.1.1. Enabling FIPS Mode To make Re d Hat Ente rpris e Linux compliant with the Fe de ral Information Proce s s ing Standard (FIPS) Publication 140-2, you ne e d to make s e ve ral change s to e ns ure that accre dite d cryptographic module s are us e d. You can e ithe r e nable FIPS mode during s ys te m ins tallation or afte r it.

During t he Syst em Inst allat ion To fulfil the strict FIPS 140-2 compliance, add the fips=1 ke rne l option to the ke rne l command line during s ys te m ins tallation. With this option, all ke ys ' ge ne rations are done with FIPS-approve d algorithms and continuous monitoring te s ts in place . Afte r the ins tallation, the s ys te m is configure d to boot into FIPS mode automatically.

Impo rtant Ens ure that the s ys te m has ple nty of e ntropy during the ins tallation proce s s by moving the mous e around or by pre s s ing many ke ys troke s . The re comme nde d amount of ke ys troke s is 256 and more . Le s s than 256 ke ys troke s could ge ne rate a non-unique ke y.

Af t er t he Syst em Inst allat ion To turn your s ys te m, ke rne l and us e r s pace , into FIPS mode anytime afte r the s ys te m ins tallation, follow the s e s te ps : 1. Make s ure pre linking is dis able d. For prope r ope ration of the in-module inte grity ve rification, pre linking of librarie s

236

⁠C hapt e r 8 . Fe de r al St andar ds and Re gulat io ns

and binarie s has to be dis able d. Pre linking is done by the prelink package , which is not ins talle d by de fault. To dis able pre linking, s e t the PRELINKING=no option in the /etc/sysconfig/prelink configuration file . To dis able e xis ting pre linking on all s ys te m file s , us e the prelink -u -a command. 2. Ins tall the dracut-fips package : ~]# yum install dracut-fips For the CPUs with the AES Ne w Ins tructions (AES-NI) s upport, ins tall the dracut-fipsaesni package as we ll: ~]# yum install dracut-fips-aesni 3. Re ge ne rate the initramfs file . To e nable the in-module inte grity ve rification and to have all re quire d module s pre s e nt during the ke rne l boot, the initramfs file has to be re ge ne rate d: ~]# dracut -v -f

Warning This ope ration will ove rwrite the e xis ting initramfs file . 4. Modify boot loade r configuration. To boot into FIPS mode , add the fips=1 option to the ke rne l command line of the boot loade r. If your /boot or /boot/EFI/ partitions re s ide on s e parate partitions , add the boot= (whe re s tands for /boot or /boot/EFI) parame te r to the ke rne l command line as we ll. To ide ntify the boot partition, e nte r the following command: ~]$ df /boot Filesystem /dev/sda1

1K-blocks 495844

Used Available Use% Mounted on 53780 416464 12% /boot

To e ns ure that the boot= configuration option works e ve n if the de vice naming change s be twe e n boots , ide ntify the unive rs ally unique ide ntifie r (UUID) of the partition by running the following command: ~]$ blkid /dev/sda1 /dev/sda1: UUID="05c000f1-f899-467b-a4d9-d5ca4424c797" TYPE="ext4" Appe nd the UUID to the ke rne l command line : boot=UUID=05c000f1-f899-467b-a4d9-d5ca4424c797 De pe nding on your boot loade r, make the following change s : grub2

237

Se c ur it y Guide

Add the fips=1 and boot= options to the GRUB_CMDLINE_LINUX ke y in the /etc/default/grub file . To apply the change s to /etc/default/grub, re build the grub.cfg file as follows : On BIOS-bas e d machine s , e nte r the following command as root: ~]# grub2-mkconfig -o /boot/grub2/grub.cfg On UEFI-bas e d machine s , e nte r the following command as root: ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg z ipl (on the IBM z Sys te ms archite cture only) Add the fips=1 and boot= options to the /etc/zipl.conf to the ke rne l command line and apply the change s by running the following command as root: ~]# zipl 5. Re boot your s ys te m.

8.2. Nat ional Indust rial Securit y Program Operat ing Manual (NISPOM) The NISPOM (als o calle d DoD 5220.22-M), as a compone nt of the National Indus trial Se curity Program (NISP), e s tablis he s a s e rie s of proce dure s and re quire me nts for all gove rnme nt contractors with re gard to clas s ifie d information. The curre nt NISPOM is date d Fe bruary 28, 2006, with incorporate d major change s from March 28, 2013. The NISPOM docume nt can be downloade d from the following URL: http://www.nis pom.org/NISPOMdownload.html.

8.3. Payment Card Indust ry Dat a Securit y St andard (PCI DSS) From https ://www.pcis e curitys tandards .org/about/inde x.s html: The PCI Security Standards Council is an open global forum, launched in 2006, that is responsible for the development, management, education, and awareness of the PCI Security Standards, including the Data Security Standard (DSS). You can download the PCI DSS s tandard from https ://www.pcis e curitys tandards .org/s e curity_s tandards /pci_ds s .s html.

8.4. Securit y T echnical Implement at ion Guide A Se curity Te chnical Imple me ntation Guide (STIG) is a me thodology for s tandardiz e d s e cure ins tallation and mainte nance of compute r s oftware and hardware . Se e the following URL for more information on STIG: http://ias e .dis a.mil/s tigs /Page s /inde x.as px.

238

⁠A ppe ndix A. Enc r ypt io n St andar ds

Appendix A. Encrypt ion St andards A.1. Synchronous Encrypt ion A.1.1. Advanced Encrypt ion St andard — AES In cryptography, the Advance d Encryption Standard (AES) is an e ncryption s tandard adopte d by the U.S. Gove rnme nt. The s tandard compris e s thre e block ciphe rs , AES-128, AES-192 and AES-256, adopte d from a large r colle ction originally publis he d as Rijndae l. Each AES ciphe r has a 128-bit block s iz e , with ke y s iz e s of 128, 192 and 256 bits , re s pe ctive ly. The AES ciphe rs have be e n analyz e d e xte ns ive ly and are now us e d worldwide , as was the cas e with its pre de ce s s or, the Data Encryption Standard (DES). ⁠ [3]

A.1.1.1. AES Hist ory AES was announce d by National Ins titute of Standards and Te chnology (NIST) as U.S. FIPS PUB 197 (FIPS 197) on Nove mbe r 26, 2001 afte r a 5-ye ar s tandardiz ation proce s s . Fifte e n compe ting de s igns we re pre s e nte d and e valuate d be fore Rijndae l was s e le cte d as the mos t s uitable . It be came e ffe ctive as a s tandard May 26, 2002. It is available in many diffe re nt e ncryption package s . AES is the firs t publicly acce s s ible and ope n ciphe r approve d by the NSA for top s e cre t information (s e e the Se curity s e ction in the Wikipe dia article on AES). ⁠ [4] The Rijndae l ciphe r was de ve lope d by two Be lgian cryptographe rs , Joan Dae me n and Vince nt Rijme n, and s ubmitte d by the m to the AES s e le ction proce s s . Rijndae l is a portmante au of the name s of the two inve ntors . ⁠ [5]

A.1.2. Dat a Encrypt ion St andard — DES The Data Encryption Standard (DES) is a block ciphe r (a form of s hare d s e cre t e ncryption) that was s e le cte d by the National Bure au of Standards as an official Fe de ral Information Proce s s ing Standard (FIPS) for the Unite d State s in 1976 and which has s ubs e que ntly e njoye d wide s pre ad us e inte rnationally. It is bas e d on a s ymme tric-ke y algorithm that us e s a 56-bit ke y. The algorithm was initially controve rs ial with clas s ifie d de s ign e le me nts , a re lative ly s hort ke y le ngth, and s us picions about a National Se curity Age ncy (NSA) backdoor. DES cons e que ntly came unde r inte ns e acade mic s crutiny which motivate d the mode rn unde rs tanding of block ciphe rs and the ir cryptanalys is . ⁠ [6]

A.1.2.1. DES Hist ory DES is now cons ide re d to be ins e cure for many applications . This is chie fly due to the 56bit ke y s iz e be ing too s mall; in January, 1999, dis tribute d.ne t and the Ele ctronic Frontie r Foundation collaborate d to publicly bre ak a DES ke y in 22 hours and 15 minute s . The re are als o s ome analytical re s ults which de mons trate the ore tical we akne s s e s in the ciphe r, although the y are unfe as ible to mount in practice . The algorithm is be lie ve d to be practically s e cure in the form of Triple DES, although the re are the ore tical attacks . In re ce nt ye ars , the ciphe r has be e n s upe rs e de d by the Advance d Encryption Standard (AES). ⁠ [7] In s ome docume ntation, a dis tinction is made be twe e n DES as a s tandard and DES the algorithm which is re fe rre d to as the DEA (the Data Encryption Algorithm). ⁠ [8]

239

Se c ur it y Guide

A.2. Public-key Encrypt ion Public-ke y cryptography is a cryptographic approach, e mploye d by many cryptographic algorithms and cryptos ys te ms , whos e dis tinguis hing characte ris tic is the us e of as ymme tric ke y algorithms ins te ad of or in addition to s ymme tric ke y algorithms . Us ing the te chnique s of public ke y-private ke y cryptography, many me thods of prote cting communications or authe nticating me s s age s forme rly unknown have be come practical. The y do not re quire a s e cure initial e xchange of one or more s e cre t ke ys as is re quire d whe n us ing s ymme tric ke y algorithms . It can als o be us e d to cre ate digital s ignature s . ⁠ [9] Public ke y cryptography is a fundame ntal and wide ly us e d te chnology around the world, and is the approach which unde rlie s s uch Inte rne t s tandards as Trans port Laye r Se curity (TLS) (s ucce s s or to SSL), PGP and GPG. ⁠ [10] The dis tinguis hing te chnique us e d in public ke y cryptography is the us e of as ymme tric ke y algorithms , whe re the ke y us e d to e ncrypt a me s s age is not the s ame as the ke y us e d to de crypt it. Each us e r has a pair of cryptographic ke ys — a public ke y and a private ke y. The private ke y is ke pt s e cre t, whils t the public ke y may be wide ly dis tribute d. Me s s age s are e ncrypte d with the re cipie nt's public ke y and can only be de crypte d with the corre s ponding private ke y. The ke ys are re late d mathe matically, but the private ke y cannot be fe as ibly (ie , in actual or proje cte d practice ) de rive d from the public ke y. It was the dis cove ry of s uch algorithms which re volutioniz e d the practice of cryptography be ginning in the middle 1970s . ⁠ [11] In contras t, Symme tric-ke y algorithms , variations of which have be e n us e d for s ome thous ands of ye ars , us e a s ingle s e cre t ke y s hare d by s e nde r and re ce ive r (which mus t als o be ke pt private , thus accounting for the ambiguity of the common te rminology) for both e ncryption and de cryption. To us e a s ymme tric e ncryption s che me , the s e nde r and re ce ive r mus t s e cure ly s hare a ke y in advance . ⁠ [12] Be caus e s ymme tric ke y algorithms are ne arly always much le s s computationally inte ns ive , it is common to e xchange a ke y us ing a ke y-e xchange algorithm and trans mit data us ing that ke y and a s ymme tric ke y algorithm. PGP, and the SSL/TLS family of s che me s do this , for ins tance , and are calle d hybrid cryptos ys te ms in cons e que nce . ⁠ [13]

A.2.1. Dif f ie-Hellman Diffie –He llman ke y e xchange (D–H) is a cryptographic protocol that allows two partie s that have no prior knowle dge of e ach othe r to jointly e s tablis h a s hare d s e cre t ke y ove r an ins e cure communications channe l. This ke y can the n be us e d to e ncrypt s ubs e que nt communications us ing a s ymme tric ke y ciphe r. ⁠ [14]

A.2.1.1. Dif f ie-Hellman Hist ory The s che me was firs t publis he d by Whitfie ld Diffie and Martin He llman in 1976, although it late r e me rge d that it had be e n s e parate ly inve nte d a fe w ye ars e arlie r within GCHQ, the Britis h s ignals inte llige nce age ncy, by Malcolm J. Williams on but was ke pt clas s ifie d. In 2002, He llman s ugge s te d the algorithm be calle d Diffie –He llman–Me rkle ke y e xchange in re cognition of Ralph Me rkle 's contribution to the inve ntion of public-ke y cryptography (He llman, 2002). ⁠ [15]

240

⁠A ppe ndix A. Enc r ypt io n St andar ds

Although Diffie –He llman ke y agre e me nt its e lf is an anonymous (non-authe nticate d) ke yagre e me nt protocol, it provide s the bas is for a varie ty of authe nticate d protocols , and is us e d to provide pe rfe ct forward s e cre cy in Trans port Laye r Se curity's e phe me ral mode s (re fe rre d to as EDH or DHE de pe nding on the ciphe r s uite ). ⁠ [16] U.S. Pate nt 4,200,770, now e xpire d, de s cribe s the algorithm and cre dits He llman, Diffie , and Me rkle as inve ntors . ⁠ [17]

A.2.2. RSA In cryptography, RSA (which s tands for Rive s t, Shamir and Adle man who firs t publicly de s cribe d it) is an algorithm for public-ke y cryptography. It is the firs t algorithm known to be s uitable for s igning as we ll as e ncryption, and was one of the firs t gre at advance s in public ke y cryptography. RSA is wide ly us e d in e le ctronic comme rce protocols , and is be lie ve d to be s e cure give n s ufficie ntly long ke ys and the us e of up-to-date imple me ntations .

A.2.3. DSA DSA (Digital Signature Algorithm) is a s tandard for digital s ignature s , a Unite d State s fe de ral gove rnme nt s tandard for digital s ignature s . DSA is for s ignature s only and is not an e ncryption algorithm. ⁠ [18]

A.2.4. SSL/T LS Trans port Laye r Se curity (TLS) and its pre de ce s s or, Se cure Socke ts Laye r (SSL), are cryptographic protocols that provide s e curity for communications ove r ne tworks s uch as the Inte rne t. TLS and SSL e ncrypt the s e gme nts of ne twork conne ctions at the Trans port Laye r e nd-to-e nd. Se ve ral ve rs ions of the protocols are in wide s pre ad us e in applications like we b brows ing, e le ctronic mail, Inte rne t faxing, ins tant me s s aging and voice -ove r-IP (VoIP). ⁠ [19]

A.2.5. Cramer-Shoup Crypt osyst em The Crame r–Shoup s ys te m is an as ymme tric ke y e ncryption algorithm, and was the firs t e fficie nt s che me prove n to be s e cure agains t adaptive chos e n ciphe rte xt attack us ing s tandard cryptographic as s umptions . Its s e curity is bas e d on the computational intractability (wide ly as s ume d, but not prove d) of the de cis ional Diffie –He llman as s umption. De ve lope d by Ronald Crame r and Victor Shoup in 1998, it is an e xte ns ion of the ElGamal cryptos ys te m. In contras t to ElGamal, which is e xtre me ly malle able , Crame r–Shoup adds additional e le me nts to e ns ure non-malle ability e ve n agains t a re s ource ful attacke r. This non-malle ability is achie ve d through the us e of a collis ion-re s is tant has h function and additional computations , re s ulting in a ciphe rte xt which is twice as large as in ElGamal. [20]

A.2.6. ElGamal Encrypt ion In cryptography, the ElGamal e ncryption s ys te m is an as ymme tric ke y e ncryption algorithm for public-ke y cryptography which is bas e d on the Diffie -He llman ke y agre e me nt. It was de s cribe d by Tahe r ElGamal in 1985. ElGamal e ncryption is us e d in the fre e GNU Privacy Guard s oftware , re ce nt ve rs ions of PGP, and othe r cryptos ys te ms . ⁠ [21]

241

Se c ur it y Guide

[3] "Advanced Encryption Standard." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard [4] "Advanced Encryption Standard." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard [5] "Advanced Encryption Standard." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard [6] "Data Encryption Standard." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard [7] "Data Encryption Standard." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard [8] "Data Encryption Standard." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard [9] "P ublic-key Encryption." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/P ublickey_cryptography [10] "P ublic-key Encryption." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/P ublickey_cryptography [11] "P ublic-key Encryption." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/P ublickey_cryptography [12] "P ublic-key Encryption." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/P ublickey_cryptography [13] "P ublic-key Encryption." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/P ublickey_cryptography [14] "Diffie-Hellm an." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Diffie-Hellm an [15] "Diffie-Hellm an." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Diffie-Hellm an [16] "Diffie-Hellm an." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Diffie-Hellm an [17] "Diffie-Hellm an." Wikipedia. 14 Novem ber 2009 http://en.wikipedia.org/wiki/Diffie-Hellm an [18] "DSA." Wikipedia. 24 February 2010 http://en.wikipedia.org/wiki/Digital_Signature_Algorithm [19] "TLS/SSL." Wikipedia. 24 February 2010 http://en.wikipedia.org/wiki/Transport_Layer_Security [20] "C ram er-Shoup cryptosystem ." Wikipedia. 24 February 2010 http://en.wikipedia.org/wiki/C ram er–Shoup_cryptosystem [21] "ElGam al encryption" Wikipedia. 24 February 2010 http://en.wikipedia.org/wiki/ElGam al_encryption

242

⁠A ppe ndix B. Audit Sys t e m Re f e r e nc e

Appendix B. Audit Syst em Reference B.1. Audit Event Fields Table B.1, “Eve nt Fie lds ” lis ts all curre ntly-s upporte d Audit e ve nt fie lds . An e ve nt fie ld is the value pre ce ding the e qual s ign in the Audit log file s . T able B.1. Event Fields Event Field

Explanat io n

a0, a1, a2, a3

Re cords the firs t four argume nts of the s ys te m call, e ncode d in he xade cimal notation. Re cords a us e r's account name . Re cords the IPv4 or IPv6 addre s s . This fie ld us ually follows a hostname fie ld and contains the addre s s the hos t name re s olve s to. Re cords information about the CPU archite cture of the s ys te m, e ncode d in he xade cimal notation. Re cords the Audit us e r ID. This ID is as s igne d to a us e r upon login and is inhe rite d by e ve ry proce s s e ve n whe n the us e r's ide ntity change s (for e xample , by s witching us e r accounts with su - john). Re cords the numbe r of bits that we re us e d to s e t a particular Linux capability. For more information on Linux capabilitie s , s e e the capabilitie s (7) man page . Re cords data re late d to the s e tting of an inhe rite d file s ys te m-bas e d capability. Re cords data re late d to the s e tting of a pe rmitte d file s ys te mbas e d capability. Re cords data re late d to the s e tting of an e ffe ctive proce s s bas e d capability. Re cords data re late d to the s e tting of an inhe rite d proce s s bas e d capability. Re cords data re late d to the s e tting of a pe rmitte d proce s s bas e d capability. Re cords the path to the cgroup that contains the proce s s at the time the Audit e ve nt was ge ne rate d. Re cords the e ntire command line that is e xe cute d. This is us e ful in cas e of s he ll inte rpre te rs whe re the exe fie ld re cords , for e xample , /bin/bash as the s he ll inte rpre te r and the cmd fie ld re cords the re s t of the command line that is e xe cute d, for e xample helloworld.sh --help. Re cords the command that is e xe cute d. This is us e ful in cas e of s he ll inte rpre te rs whe re the exe fie ld re cords , for e xample , /bin/bash as the s he ll inte rpre te r and the comm fie ld re cords the name of the s cript that is e xe cute d, for e xample helloworld.sh. Re cords the path to the dire ctory in which a s ys te m call was invoke d. Re cords data as s ociate d with TTY re cords . Re cords the minor and major ID of the de vice that contains the file or dire ctory re corde d in an e ve nt.

acct addr

arch auid

capability

cap_fi cap_fp cap_pe cap_pi cap_pp cgroup cmd

comm

cwd data dev

243

Se c ur it y Guide

Event Field

Explanat io n

devmajor devminor egid

Re cords the major de vice ID. Re cords the minor de vice ID. Re cords the e ffe ctive group ID of the us e r who s tarte d the analyz e d proce s s . Re cords the e ffe ctive us e r ID of the us e r who s tarte d the analyz e d proce s s . Re cords the path to the e xe cutable that was us e d to invoke the analyz e d proce s s . Re cords the e xit code re turne d by a s ys te m call. This value varie s by s ys te m call. You can inte rpre t the value to its human-re adable e quivale nt with the following command: ausearch --interpret --exit exit_code Re cords the type of addre s s protocol that was us e d, e ithe r IPv4 or IPv6. Re cords the type of the file . Re cords the file s ys te m name flags . Re cords the file s ys te m group ID of the us e r who s tarte d the analyz e d proce s s . Re cords the file s ys te m us e r ID of the us e r who s tarte d the analyz e d proce s s . Re cords the group ID. Re cords the hos t name . Re cords the type of a Inte rne t Control Me s s age Protocol (ICMP) package that is re ce ive d. Audit me s s age s containing this fie ld are us ually ge ne rate d by ipt ables. Re cords the us e r ID of an account that was change d. Re cords the inode numbe r as s ociate d with the file or dire ctory re corde d in an Audit e ve nt. Re cords the group ID of the inode 's owne r. Re cords the us e r ID of the inode 's owne r. Re cords the numbe r of path re cords that are attache d to this re cord. Re cords the us e r de fine d s tring as s ociate d with a rule that ge ne rate d a particular e ve nt in the Audit log. Re cords the Audit rule lis t ID. The following is a lis t of known IDs :

euid exe exit

family filetype flags fsgid fsuid gid hostname icmptype

id inode inode_gid inode_uid items key list

0 1 4 5 mode msg

msgtype

name

244

— user — task — exit — exclude

Re cords the file or dire ctory pe rmis s ions , e ncode d in nume rical notation. Re cords a time s tamp and a unique ID of a re cord, or various e ve nt-s pe cific = pairs provide d by the ke rne l or us e r s pace applications . Re cords the me s s age type that is re turne d in cas e of a us e rbas e d AVC de nial. The me s s age type is de te rmine d by DBus . Re cords the full path of the file or dire ctory that was pas s e d to the s ys te m call as an argume nt.

⁠A ppe ndix B. Audit Sys t e m Re f e r e nc e

Event Field

Explanat io n

new-disk

Re cords the name of a ne w dis k re s ource that is as s igne d to a virtual machine . Re cords the amount of a ne w me mory re s ource that is as s igne d to a virtual machine . Re cords the numbe r of a ne w virtual CPU re s ource that is as s igne d to a virtual machine . Re cords the MAC addre s s of a ne w ne twork inte rface re s ource that is as s igne d to a virtual machine . Re cords a group ID that is as s igne d to a us e r. Re cords the us e r ID of the us e r that has logge d in to acce s s the s ys te m (as oppos e d to, for e xample , us ing su) and has s tarte d the targe t proce s s . This fie ld is e xclus ive to the re cord of type OBJ_PID. Re cords the command that was us e d to s tart the targe t proce s s .This fie ld is e xclus ive to the re cord of type OBJ_PID. Re cords the proce s s ID of the targe t proce s s . This fie ld is e xclus ive to the re cord of type OBJ_PID. Re cords the s e s s ion ID of the targe t proce s s . This fie ld is e xclus ive to the re cord of type OBJ_PID. Re cords the re al us e r ID of the targe t proce s s Re cords the SELinux conte xt of an obje ct. An obje ct can be a file , a dire ctory, a s ocke t, or anything that is re ce iving the action of a s ubje ct. Re cords the group ID of an obje ct. Re cords the high SELinux le ve l of an obje ct. Re cords the low SELinux le ve l of an obje ct. Re cords the SELinux role of an obje ct. Re cords the UID of an obje ct Re cords the us e r that is as s ociate d with an obje ct. Re cords the obje ct owne r's group ID. Re cords the name of an old dis k re s ource whe n a ne w dis k re s ource is as s igne d to a virtual machine . Re cords the amount of an old me mory re s ource whe n a ne w amount of me mory is as s igne d to a virtual machine . Re cords the numbe r of an old virtual CPU re s ource whe n a ne w virtual CPU is as s igne d to a virtual machine . Re cords the MAC addre s s of an old ne twork inte rface re s ource whe n a ne w ne twork inte rface is as s igne d to a virtual machine . Re cords the pre vious value of the ne twork promis cuity flag. Re cords the re al us e r ID of the us e r who s tarte d the targe t proce s s . Re cords the full path of the file or dire ctory that was pas s e d to the s ys te m call as an argume nt in cas e of AVC-re late d Audit e ve nts Re cords the file pe rmis s ion that was us e d to ge ne rate an e ve nt (that is , re ad, write , e xe cute , or attribute change )

new-mem new-vcpu new-net new_gid oauid

ocomm opid oses ouid obj

obj_gid obj_lev_high obj_lev_low obj_role obj_uid obj_user ogid old-disk old-mem old-vcpu old-net

old_prom ouid path

perm

245

Se c ur it y Guide

Event Field

Explanat io n

pid

The pid fie ld s e mantics de pe nd on the origin of the value in this fie ld. In fie lds ge ne rate d from us e r-s pace , this fie ld holds a proce s s ID. In fie lds ge ne rate d by the ke rne l, this fie ld holds a thre ad ID. The thre ad ID is e qual to proce s s ID for s ingle -thre ade d proce s s e s . Note that the value of this thre ad ID is diffe re nt from the value s of pthre ad_t IDs us e d in us e r-s pace . For more information, s e e the ge ttid(2) man page .

ppid proctitle

prom proto res result saddr sauid

ses sgid sig subj subj_clr subj_role subj_sen subj_user success suid syscall

246

Re cords the Pare nt Proce s s ID (PID). Re cords the full command-line of the command that was us e d to invoke the analyz e d proce s s . The fie ld is e ncode d in he xade cimal notation to not allow the us e r to influe nce the Audit log pars e r. The te xt de code s to the command that trigge re d this Audit e ve nt. Whe n s e arching Audit re cords with the ausearch command, us e the -i or --interpret option to automatically conve rt he xade cimal value s into the ir humanre adable e quivale nts . Re cords the ne twork promis cuity flag. Re cords the ne tworking protocol that was us e d. This fie ld is s pe cific to Audit e ve nts ge ne rate d by ipt ables. Re cords the re s ult of the ope ration that trigge re d the Audit e ve nt. Re cords the re s ult of the ope ration that trigge re d the Audit e ve nt. Re cords the s ocke t addre s s . Re cords the s e nde r Audit login us e r ID. This ID is provide d by D-Bus as the ke rne l is unable to s e e which us e r is s e nding the original auid. Re cords the s e s s ion ID of the s e s s ion from which the analyz e d proce s s was invoke d. Re cords the s e t group ID of the us e r who s tarte d the analyz e d proce s s . Re cords the numbe r of a s ignal that caus e s a program to e nd abnormally. Us ually, this is a s ign of a s ys te m intrus ion. Re cords the SELinux conte xt of a s ubje ct. A s ubje ct can be a proce s s , a us e r, or anything that is acting upon an obje ct. Re cords the SELinux cle arance of a s ubje ct. Re cords the SELinux role of a s ubje ct. Re cords the SELinux s e ns itivity of a s ubje ct. Re cords the us e r that is as s ociate d with a s ubje ct. Re cords whe the r a s ys te m call was s ucce s s ful or faile d. Re cords the s e t us e r ID of the us e r who s tarte d the analyz e d proce s s . Re cords the type of the s ys te m call that was s e nt to the ke rne l.

⁠A ppe ndix B. Audit Sys t e m Re f e r e nc e

Event Field

Explanat io n

terminal tty

Re cords the te rminal name (without /dev/). Re cords the name of the controlling te rminal. The value (none) is us e d if the proce s s has no controlling te rminal. Re cords the re al us e r ID of the us e r who s tarte d the analyz e d proce s s . Re cords the name of a virtual machine from which the Audit e ve nt originate d.

uid vm

B.2. Audit Record T ypes Table B.2, “Re cord Type s ” lis ts all curre ntly-s upporte d type s of Audit re cords . The e ve nt type is s pe cifie d in the type= fie ld at the be ginning of e ve ry Audit re cord. T able B.2. Reco rd T ypes Event T ype

Explanat io n

ACCT_LOCK

Trigge re d whe n a us e r-s pace us e r account is locke d by the adminis trator. Trigge re d whe n a us e r-s pace us e r account is unlocke d by the adminis trator. Trigge re d whe n a us e r-s pace group is adde d. Trigge re d whe n a us e r-s pace us e r account is adde d. Trigge re d whe n a proce s s e s e nds abnormally (with a s ignal that could caus e a core dump, if e nable d). Trigge re d whe n a file or a dire ctory acce s s e nds abnormally.

ACCT_UNLOCK ADD_GROUP ADD_USER ANOM_ABEND ⁠ [a] ANOM_ACCESS_FS [a] ANOM_ADD_ACCT [a]

ANOM_EXEC [a]

Trigge re d whe n a us e r-s pace account addition e nds abnormally. Trigge re d whe n a failure of the Abs tract Machine Te s t Utility (AMTU) is de te cte d. Trigge re d whe n a failure in the cryptographic s ys te m is de te cte d. Trigge re d whe n a us e r-s pace account de le tion e nds abnormally. Trigge re d whe n an e xe cution of a file e nds abnormally.

ANOM_LINK [a]

Trigge re d whe n s us picious us e of file links is de te cte d.

ANOM_LOGIN_ACCT [a]

Trigge re d whe n an account login atte mpt e nds abnormally.

ANOM_LOGIN_FAILURES [

Trigge re d whe n the limit of faile d login atte mpts is re ache d.

ANOM_AMTU_FAIL [a] ANOM_CRYPTO_FAIL [a] ANOM_DEL_ACCT [a]

a]

ANOM_LOGIN_LOCATION [ a]

ANOM_LOGIN_SESSIONS [ a]

ANOM_LOGIN_TIME [a] ANOM_MAX_DAC [a] ANOM_MAX_MAC [a]

Trigge re d whe n a login atte mpt is made from a forbidde n location. Trigge re d whe n a login atte mpt re ache s the maximum amount of concurre nt s e s s ions . Trigge re d whe n a login atte mpt is made at a time whe n it is pre ve nte d by, for e xample , pam_time. Trigge re d whe n the maximum amount of Dis cre tionary Acce s s Control (DAC) failure s is re ache d. Trigge re d whe n the maximum amount of Mandatory Acce s s Control (MAC) failure s is re ache d.

247

Se c ur it y Guide

Event T ype

Explanat io n

ANOM_MK_EXEC [a]

Trigge re d whe n a file is made e xe cutable .

ANOM_MOD_ACCT [a]

Trigge re d whe n a us e r-s pace account modification e nds abnormally. Trigge re d whe n a de vice e nable s or dis able s promis cuous mode . Trigge re d whe n a Role -Bas e d Acce s s Control (RBAC) s e lf-te s t failure is de te cte d. Trigge re d whe n a Role -Bas e d Acce s s Control (RBAC) file inte grity te s t failure is de te cte d.

ANOM_PROMISCUOUS [a] ANOM_RBAC_FAIL [a] ANOM_RBAC_INTEGRITY_ FAIL [a] ANOM_ROOT_TRANS [a] AVC AVC_PATH BPRM_FCAPS CAPSET

CHGRP_ID CHUSER_ID CONFIG_CHANGE CRED_ACQ CRED_DISP CRED_REFR CRYPTO_FAILURE_USER CRYPTO_IKE_SA CRYPTO_IPSEC_SA CRYPTO_KEY_USER CRYPTO_LOGIN CRYPTO_LOGOUT CRYPTO_PARAM_CHANGE_ USER CRYPTO_REPLAY_USER CRYPTO_SESSION CRYPTO_TEST_USER CWD DAC_CHECK DAEMON_ABORT DAEMON_ACCEPT

248

Trigge re d whe n a us e r be come s root. Trigge re d to re cord an SELinux pe rmis s ion che ck. Trigge re d to re cord the dentry and vfsmount pair whe n an SELinux pe rmis s ion che ck occurs . Trigge re d whe n a us e r e xe cute s a program with a file s ys te m capability. Trigge re d to re cord the capabilitie s be ing s e t for proce s s bas e d capabilitie s , for e xample , running as root to drop capabilitie s . Trigge re d whe n a us e r-s pace group ID is change d. Trigge re d whe n a us e r-s pace us e r ID is change d. Trigge re d whe n the Audit s ys te m configuration is modifie d. Trigge re d whe n a us e r acquire s us e r-s pace cre de ntials . Trigge re d whe n a us e r dis pos e s of us e r-s pace cre de ntials . Trigge re d whe n a us e r re fre s he s the ir us e r-s pace cre de ntials . Trigge re d whe n a de crypt, e ncrypt, or randomiz e cryptographic ope ration fails . Trigge re d whe n an Inte rne t Ke y Exchange Se curity As s ociation is e s tablis he d. Trigge re d whe n an Inte rne t Protocol Se curity As s ociation is e s tablis he d. Trigge re d to re cord the cryptographic ke y ide ntifie r us e d for cryptographic purpos e s . Trigge re d whe n a cryptographic office r login atte mpt is de te cte d. Trigge re d whe n a cryptographic office r logout atte mpt is de te cte d. Trigge re d whe n a change in a cryptographic parame te r is de te cte d. Trigge re d whe n a re play attack is de te cte d. Trigge re d to re cord parame te rs s e t during a TLS s e s s ion e s tablis hme nt. Trigge re d to re cord cryptographic te s t re s ults as re quire d by the FIPS-140 s tandard. Trigge re d to re cord the curre nt working dire ctory. Trigge re d to re cord DAC che ck re s ults . Trigge re d whe n a dae mon is s toppe d due to an e rror. Trigge re d whe n the auditd dae mon acce pts a re mote conne ction.

⁠A ppe ndix B. Audit Sys t e m Re f e r e nc e

Event T ype

Explanat io n

DAEMON_CLOSE

Trigge re d whe n the auditd dae mon clos e s a re mote conne ction. Trigge re d whe n a dae mon configuration change is de te cte d. Trigge re d whe n a dae mon is s ucce s s fully s toppe d. Trigge re d whe n an auditd dae mon inte rnal e rror is de te cte d. Trigge re d whe n the auditd dae mon re s ume s logging. Trigge re d whe n the auditd dae mon rotate s the Audit log file s . Trigge re d whe n the auditd dae mon is s tarte d. Trigge re d whe n a us e r-s pace group is de le te d Trigge re d whe n a us e r-s pace us e r is de le te d Trigge re d whe n a de vice is allocate d. Trigge re d whe n a de vice is de allocate d. Trigge re d to re cord the e nd of a multi-re cord e ve nt. Trigge re d to re cord argume nts of the execve(2) s ys te m call. Trigge re d to re cord the us e of the pipe and socketpair s ys te m calls . Trigge re d whe n an Audit fe ature change d value . Trigge re d whe n a file s ys te m re labe l ope ration is de te cte d. Trigge re d whe n a group pas s word is us e d to authe nticate agains t a us e r-s pace group. Trigge re d whe n a group account pas s word or PIN is modifie d. Trigge re d to re cord us e r-s pace group account attribute modification. Trigge re d to re cord a data inte grity ve rification e ve nt run by the ke rne l. Trigge re d to re cord a has h type inte grity ve rification e ve nt run by the ke rne l. Trigge re d to re cord a me tadata inte grity ve rification e ve nt run by the ke rne l. Trigge re d to re cord Platform Configuration Re gis te r (PCR) invalidation me s s age s . Trigge re d to re cord a policy rule .

DAEMON_CONFIG DAEMON_END DAEMON_ERR DAEMON_RESUME DAEMON_ROTATE DAEMON_START DEL_GROUP DEL_USER DEV_ALLOC DEV_DEALLOC EOE EXECVE FD_PAIR FEATURE_CHANGE FS_RELABEL GRP_AUTH GRP_CHAUTHTOK GRP_MGMT INTEGRITY_DATA ⁠ [b] INTEGRITY_HASH [b] INTEGRITY_METADATA [b] INTEGRITY_PCR [b] INTEGRITY_RULE [b] INTEGRITY_STATUS [b] IPC IPC_SET_PERM KERN_MODULE KERNEL KERNEL_OTHER LABEL_LEVEL_CHANGE LABEL_OVERRIDE LOGIN MAC_CHECK

Trigge re d to re cord the s tatus of inte grity ve rification. Trigge re d to re cord information about a Inte r-Proce s s Communication obje ct re fe re nce d by a s ys te m call. Trigge re d to re cord information about ne w value s s e t by an IPC_SET control ope ration on an IPC obje ct. Trigge re d to re cord a ke rne l module name on load or unload. Trigge re d to re cord the initializ ation of the Audit s ys te m. Trigge re d to re cord information from third-party ke rne l module s . Trigge re d whe n an obje ct's le ve l labe l is modifie d. Trigge re d whe n an adminis trator ove rride s an obje ct's le ve l labe l. Trigge re d to re cord re le vant login information whe n a us e r log in to acce s s the s ys te m. Trigge re d whe n a us e r s pace MAC (Mandatory Acce s s Control) de cis ion is made .

249

Se c ur it y Guide

Event T ype

Explanat io n

MAC_CIPSOV4_ADD

Trigge re d whe n a Comme rcial Inte rne t Protocol Se curity Option (CIPSO) us e r adds a ne w Domain of Inte rpre tation (DOI). Adding DOIs is a part of the packe t labe ling capabilitie s of the ke rne l provide d by Ne tLabe l. Trigge re d whe n a CIPSO us e r de le te s an e xis ting DOI. Adding DOIs is a part of the packe t labe ling capabilitie s of the ke rne l provide d by Ne tLabe l. Trigge re d whe n an SELinux Boole an value is change d. Trigge re d to re cord information about an IPSe c e ve nt, whe n one is de te cte d, or whe n the IPSe c configuration change s . Trigge re d whe n a ne w Linux Se curity Module (LSM) domain mapping is adde d. LSM domain mapping is a part of the packe t labe ling capabilitie s of the ke rne l provide d by Ne tLabe l. Trigge re d whe n an e xis ting LSM domain mapping is de le te d. LSM domain mapping is a part of the packe t labe ling capabilitie s of the ke rne l provide d by Ne tLabe l. Trigge re d whe n a SELinux policy file is loade d. Trigge re d whe n the SELinux mode (e nforcing, pe rmis s ive , off) is change d. Trigge re d whe n unlabe le d traffic is allowe d whe n us ing the packe t labe ling capabilitie s of the ke rne l provide d by Ne tLabe l. Trigge re d whe n a s tatic labe l is adde d whe n us ing the packe t labe ling capabilitie s of the ke rne l provide d by Ne tLabe l. Trigge re d whe n a s tatic labe l is de le te d whe n us ing the packe t labe ling capabilitie s of the ke rne l provide d by Ne tLabe l. Trigge re d to re cord a file de s criptor and flags of the mmap(2) s ys te m call. Trigge re d to re cord the mq_getattr(3) and mq_setattr(3) me s s age que ue attribute s . Trigge re d to re cord argume nts of the mq_notify(3) s ys te m call. Trigge re d to re cord argume nts of the mq_open(3) s ys te m call. Trigge re d to re cord argume nts of the mq_send(3) and mq_receive(3) s ys te m calls . Trigge re d whe n Ne tfilte r chain modifications are de te cte d. Trigge re d to re cord packe ts trave rs ing Ne tfilte r chains . Trigge re d to re cord information about a proce s s to which a s ignal is s e nt. Trigge re d to re cord file name path information. Give s the full command-line that trigge re d this Audit e ve nt, trigge re d by a s ys te m call to the ke rne l. Trigge re d whe n a us e r account is locke d.

MAC_CIPSOV4_DEL

MAC_CONFIG_CHANGE MAC_IPSEC_EVENT MAC_MAP_ADD

MAC_MAP_DEL

MAC_POLICY_LOAD MAC_STATUS MAC_UNLBL_ALLOW MAC_UNLBL_STCADD MAC_UNLBL_STCDEL MMAP MQ_GETSETATTR MQ_NOTIFY MQ_OPEN MQ_SENDRECV NETFILTER_CFG NETFILTER_PKT OBJ_PID PATH PROCTITLE RESP_ACCT_LOCK ⁠ [c] RESP_ACCT_LOCK_TIMED [c]

RESP_ACCT_REMOTE [c]

Trigge re d whe n a us e r account is locke d for a s pe cifie d pe riod of time .

ED [c]

Trigge re d whe n a us e r account is locke d from a re mote s e s s ion. Trigge re d whe n a us e r account is unlocke d afte r a configure d pe riod of time .

RESP_ALERT [c]

Trigge re d whe n an ale rt e mail is s e nt.

RESP_ACCT_UNLOCK_TIM

250

⁠A ppe ndix B. Audit Sys t e m Re f e r e nc e

Event T ype

Explanat io n

RESP_ANOMALY [c]

Trigge re d whe n an anomaly was not acte d upon.

RESP_EXEC [c] RESP_HALT [c]

Trigge re d whe n an intrus ion de te ction program re s ponds to a thre at originating from the e xe cution of a program. Trigge re d whe n the s ys te m is s hut down.

RESP_KILL_PROC [c]

Trigge re d whe n a proce s s is te rminate d.

RESP_SEBOOL [c]

Trigge re d whe n an SELinux Boole an value is s e t.

RESP_SINGLE [c]

Trigge re d whe n the s ys te m is put into s ingle -us e r mode .

RESP_TERM_ACCESS [c]

Trigge re d whe n a s e s s ion is te rminate d.

RESP_TERM_LOCK [c] ROLE_ASSIGN

Trigge re d whe n a te rminal is locke d.

ROLE_MODIFY ROLE_REMOVE SECCOMP SELINUX_ERR SERVICE_START SERVICE_STOP SOCKADDR SOCKETCALL

SYSCALL SYSTEM_BOOT SYSTEM_RUNLEVEL SYSTEM_SHUTDOWN TEST TRUSTED_APP TTY USER_ACCT USER_AUTH USER_AVC USER_CHAUTHTOK USER_CMD USER_END USER_ERR USER_LABELED_EXPORT USER_LOGIN USER_LOGOUT USER_MAC_POLICY_LOAD USER_MGMT USER_ROLE_CHANGE USER_SELINUX_ERR

Trigge re d whe n an adminis trator as s igns a us e r to an SELinux role . Trigge re d whe n an adminis trator modifie s an SELinux role . Trigge re d whe n an adminis trator re move s a us e r from an SELinux role . Trigge re d whe n a SECure COMPuting e ve nt is de te cte d. Trigge re d whe n an inte rnal SELinux e rror is de te cte d. Trigge re d whe n a s e rvice is s tarte d. Trigge re d whe n a s e rvice is s toppe d. Trigge re d to re cord a s ocke t addre s s . Trigge re d to re cord argume nts of the sys_socketcall s ys te m call (us e d to multiple x many s ocke t-re late d s ys te m calls ). Trigge re d to re cord a s ys te m call to the ke rne l. Trigge re d whe n the s ys te m is boote d up. Trigge re d whe n the s ys te m's run le ve l is change d. Trigge re d whe n the s ys te m is s hut down. Trigge re d to re cord the s ucce s s value of a te s t me s s age . The re cord of this type can be us e d by third party application that re quire auditing. Trigge re d whe n TTY input was s e nt to an adminis trative proce s s . Trigge re d whe n a us e r-s pace us e r authoriz ation atte mpt is de te cte d. Trigge re d whe n a us e r-s pace us e r authe ntication atte mpt is de te cte d. Trigge re d whe n a us e r-s pace AVC me s s age is ge ne rate d. Trigge re d whe n a us e r account pas s word or PIN is modifie d. Trigge re d whe n a us e r-s pace s he ll command is e xe cute d. Trigge re d whe n a us e r-s pace s e s s ion is te rminate d. Trigge re d whe n a us e r account s tate e rror is de te cte d. Trigge re d whe n an obje ct is e xporte d with an SELinux labe l. Trigge re d whe n a us e r logs in. Trigge re d whe n a us e r logs out. Trigge re d whe n a us e r-s pace dae mon loads an SELinux policy. Trigge re d to re cord us e r-s pace us e r account attribute modification. Trigge re d whe n a us e r's SELinux role is change d. Trigge re d whe n a us e r-s pace SELinux e rror is de te cte d.

251

Se c ur it y Guide

Event T ype

Explanat io n

USER_START USER_TTY

Trigge re d whe n a us e r-s pace s e s s ion is s tarte d. Trigge re d whe n an e xplanatory me s s age about TTY input to an adminis trative proce s s is s e nt from us e r-s pace . Trigge re d whe n an obje ct is e xporte d without SELinux labe l.

USER_UNLABELED_EXPOR T USYS_CONFIG VIRT_CONTROL VIRT_MACHINE_ID VIRT_RESOURCE

Trigge re d de te cte d. Trigge re d s toppe d. Trigge re d Trigge re d

whe n a us e r-s pace s ys te m configuration change is whe n a virtual machine is s tarte d, paus e d, or

to re cord the binding of a labe l to a virtual machine . to re cord re s ource as s ignme nt of a virtual machine . [a] All Audit event types prepended with ANOM are intended to be processed by an intrusion

detection program . [b] This event type is related to the Integrity Measurem ent Architecture (IMA), which functions best with a Trusted P latform Module (TP M) chip. [c] All Audit event types prepended with RESP are intended responses of an intrusion detection system in case it detects m alicious activity on the system .

252

⁠A ppe ndix C. Re vis io n His t o r y

Appendix C. Revision Hist ory Revisio n 1-30 T hu Jul 27 20 17 Docume nt ve rs ion for 7.4 GA publication.

Mirek Jaho da

Revisio n 1-24 Mo n Feb 6 20 17 Mirek Jaho da As ync re le as e with mis c. update s , e s pe cially in the fire walld s e ction. Revisio n 1-23 T ue No v 1 20 16 Ve rs ion for 7.3 GA publication.

Mirek Jaho da

Revisio n 1-19 Mo n Jul 18 20 16 The Smart Cards s e ction adde d.

Mirek Jaho da

Revisio n 1-18 Mo n Jun 27 20 16 The Ope nSCAP-dae mon and Atomic Scan s e ction adde d.

Mirek Jaho da

Revisio n 1-17 Fri Jun 3 20 16 As ync re le as e with mis c. update s .

Mirek Jaho da

Revisio n 1-16 Pos t 7.2 GA fixe s .

Ro bert Krát ký

T ue Jan 5 20 16

Revisio n 1-15 T ue No v 10 20 15 Ve rs ion for 7.2 GA re le as e .

Ro bert Krát ký

Revisio n 1-14.18 Mo n No v 0 9 20 15 As ync re le as e with mis c. update s .

Ro bert Krát ký

Revisio n 1-14.17 Wed Feb 18 20 15 Ve rs ion for 7.1 GA re le as e .

Ro bert Krát ký

Revisio n 1-14.15 Fri Dec 0 6 20 14 Update to s ort orde r on the Re d Hat Cus tome r Portal.

Ro bert Krát ký

Revisio n 1-14.13 T hu No v 27 20 14 Update s re fle cting the POODLE vuln.

Ro bert Krát ký

Revisio n 1-14.12 T ue Jun 0 3 20 14 Ve rs ion for 7.0 GA re le as e .

T o máš Čapek

253