GL550 Enterprise Linux Security Administration

GL550ENTERPRISELINUX SECURITYADMINISTRATIONRHEL6 SLES11

The contents of this course and all its modules and related materials, including handouts toaudience members, are copyright ©2013 Guru Labs L.C.

No part of this publication may be stored in a retrieval system, transmitted or reproduced in anyway, including, but not limited to, photocopy, photograph, magnetic, electronic or other record,without the prior written permission of Guru Labs.

This curriculum contains proprietary information which is for the exclusive use of customers of GuruLabs L.C., and is not to be shared with personnel other than those in attendance at this course.

This instructional program, including all material provided herein, is supplied without any guaranteesfrom Guru Labs L.C. Guru Labs L.C. assumes no liability for damages or legal action arising fromthe use or misuse of contents or details contained herein.

Photocopying any part of this manual without prior written consent of Guru Labs L.C. is a violationof federal law. This manual should not appear to be a photocopy. If you believe that Guru Labstraining materials are being photocopied without permission, please email [email protected] orcall 1-801-298-5227.

Guru Labs L.C. accepts no liability for any claims, demands, losses, damages, costs or expensessuffered or incurred howsoever arising from or in connection with the use of this courseware. Alltrademarks are the property of their respective owners.

Version: GL550S-R6S11-D01

ii

Table of ContentsChapter 1SECURITY CONCEPTS 1

Basic Security Principles 2RHEL6 Default Install 3RHEL6 Firewall 5SLES11 Default Install 6SLES11 Firewall 7SLES11: File Security 8Minimization – Discovery 9Service Discovery 10Hardening 12Security Concepts 13Lab Tasks 14

1. Removing Packages Using RPM 152. Firewall Configuration 173. Process Discovery 224. Operation of the setuid() and capset() System Calls 245. Operation of the chroot() System Call 28

Chapter 2SCANNING, PROBING, AND MAPPING VULNERABILITIES 1

The Security Environment 2Stealth Reconnaissance 3The WHOIS database 4Interrogating DNS 5Discovering Hosts 6Discovering Reachable Services 7Reconnaissance with SNMP 8Discovery of RPC Services 10Enumerating NFS Shares 11Nessus Insecurity Scanner 12Configuring OpenVAS 14Lab Tasks 15

1. NMAP 162. OpenVAS 203. Advanced nmap Options 24

Chapter 3PASSWORD SECURITY AND PAM 1

Unix Passwords 2Password Aging 3

Auditing Passwords 4PAM Overview 5PAM Module Types 6PAM Order of Processing 7PAM Control Statements 9PAM Modules 10pam_unix 11pam_cracklib.so 12pam_pwcheck.so 13pam_env.so 14pam_xauth.so 15pam_tally2.so 16pam_wheel.so 17pam_limits.so 18pam_nologin.so 19pam_deny.so 20pam_warn.so 21pam_securetty.so 22pam_time.so 23pam_access.so 24pam_listfile.so 25pam_lastlog.so 26pam_console.so 27Lab Tasks 29

1. John the Ripper 302. Cracklib 343. Using pam_listfile to Implement Arbitrary ACLs 394. Using pam_limits to Restrict Simultaneous Logins 425. Using pam_nologin to Restrict Logins 456. Using pam_access to Restrict Logins 497. su & pam 53

Chapter 4SECURE NETWORK TIME PROTOCOL (NTP) 1

The Importance of Time 2Hardware and System Clock 3Time Measurements 4NTP Terms and Definitions 5Synchronization Methods 6NTP Evolution 7Time Server Hierarchy 8

iii

Operational Modes 9NTP Clients 10Configuring NTP Clients 12Configuring NTP Servers 14Securing NTP 15NTP Packet Integrity 16Useful NTP Commands 17Lab Tasks 18

1. Configuring and Securing NTP 192. Peering NTP with Multiple Systems 23

Chapter 5KERBEROS CONCEPTS AND COMPONENTS 1

Common Security Problems 2Account Proliferation 3The Kerberos Solution 4Kerberos History 5Kerberos Implementations 6Kerberos Concepts 7Kerberos Principals 8Kerberos Safeguards 9Kerberos Components 10Authentication Process 11Identification Types 12Logging In 13Gaining Privileges 15Using Privileges 17Kerberos Components and the KDC 19Kerberized Services Review 20Kerberized Clients 21KDC Server Daemons 22Configuration Files 23Utilities Overview 24

Chapter 6IMPLEMENTING KERBEROS 1

Plan Topology and Implementation 2Kerberos 5 Client Software 3Kerberos 5 Server Software 4Synchronize Clocks 5Create Master KDC 6Configuring the Master KDC 7KDC Logging 9

Kerberos Realm Defaults 11Specifying [realms] 12Specifying [domain_realm] 13Allow Administrative Access 14Create KDC Databases 15Create Administrators 16Install Keys for Services 17Start Services 18Add Host Principals 19Add Common Service Principals 20Configure Slave KDCs 21Create Principals for Slaves 22Define Slaves as KDCs 23Copy Configuration to Slaves 24Install Principals on Slaves 25Create Stash on Slaves 26Start Slave Daemons 27Client Configuration 28Install krb5.conf on Clients 29Client PAM Configuration 30Install Client Host Keys 32Lab Tasks 33

1. Implementing Kerberos 34

Chapter 7ADMINISTERING AND USING KERBEROS 1

Administrative Tasks 2Key Tables 3Managing Keytabs 4Managing Principals 6Viewing Principals 7Adding, Deleting, and Modifying Principals 8Principal Policy 9Overall Goals for Users 10Signing In to Kerberos 11Ticket types 12Viewing Tickets 13Removing Tickets 14Passwords 15Changing Passwords 16Giving Others Access 17Using Kerberized Services 19Kerberized FTP 20

iv

Enabling Kerberized Services 21OpenSSH and Kerberos 22Lab Tasks 23

1. Using Kerberized Clients 242. Forwarding Kerberos Tickets 313. OpenSSH with Kerberos 36

Chapter 8SECURING THE FILESYSTEM 1

Filesystem Mount Options 2NFS Properties 3NFS Export Option 4NFSv4 and GSSAPI Auth 5Implementing NFSv4 6Implementing Kerberos with NFS 8GPG – GNU Privacy Guard 10File Encryption with OpenSSL 12File Encryption With encfs 13Linux Unified Key Setup (LUKS) 14Lab Tasks 16

1. Securing Filesystems 172. Securing NFS 213. Implementing NFSv4 254. File Encryption with GPG 335. File Encryption With OpenSSL 376. LUKS-on-disk format Encrypted Filesystem 40

Chapter 9AIDE 1

Host Intrusion Detection Systems 2Using RPM as a HIDS 3Introduction to AIDE 4AIDE Installation 5AIDE Policies 6AIDE Usage 7Lab Tasks 8

1. File Integrity Checking with RPM 92. File Integrity Checking with AIDE 12

Chapter 10ACCOUNTABILITY WITH KERNEL AUDITD 1

Accountability and Auditing 2Simple Session Auditing 3

Simple Process Accounting & Command History 5Kernel-Level Auditing 6Configuring the Audit Daemon 9Controlling Kernel Audit System 10Creating Audit Rules 11Searching Audit Logs 13Generating Audit Log Reports 14Audit Log Analysis 15Lab Tasks 16

1. Auditing Login/Logout 172. Auditing File Access 223. Auditing Command Execution 27

Chapter 11SELINUX 1

DAC vs. MAC 2Shortcomings of Traditional Unix Security 3AppArmor 4SELinux Goals 5SELinux Evolution 6SELinux Modes 7Gathering Information 8SELinux Virtual Filesystem 9SELinux Contexts 10Managing Contexts 11The SELinux Policy 12Choosing an SELinux Policy 13Policy Layout 14Tuning and Adapting Policy 15Booleans 16Permissive Domains 18Managing File Contexts 19Managing Port Contexts 20SELinux Policy Tools 21Examining Policy 23SELinux Troubleshooting 25SELinux Troubleshooting Continued 27Lab Tasks 29

1. Exploring SELinux Modes [R6] 302. SELinux Contexts in Action [R6] 333. Managing SELinux Booleans [R6] 364. Creating Policy with Audit2allow [R6] 415. Creating & Compiling Policy from Source [R6] 48

v

Chapter 12SECURING APACHE 1

Apache Overview 2httpd.conf – Server Settings 3Configuring CGI 5Turning Off Unneeded Modules 6Delegating Administration 7Apache Access Controls (mod_access) 8HTTP User Authentication 10Standard Auth Modules 11HTTP Digest Authentication 12Authentication via SQL 13Authentication via LDAP 15Authentication via Kerberos 16Scrubbing HTTP Headers 17Metering HTTP Bandwidth 18Lab Tasks 19

1. Hardening Apache by Minimizing Loaded Modules 202. Scrubbing Apache & PHP Version Headers 243. Protecting Web Content 274. Using the suexec Mechanism 335. Enabling SSO in Apache with mod_auth_kerb 39

Chapter 13SECURING POSTGRESQL 1

PostgreSQL Overview 2PostgreSQL Default Config 3Configuring SSL 4Client Authentication Basics 5Advanced Authentication 7Ident-based Authentication 8Lab Tasks 9

1. Configure PostgreSQL 102. PostgreSQL with SSL 143. PostgreSQL with Kerberos Authentication 174. Securing PostgreSQL with Web Based Applications 20

Appendix ASECURING EMAIL SYSTEMS 1

SMTP Implementations 2Security Considerations 3chrooting Postfix 4Email with GSSAPI/Kerberos Auth 5

Lab Tasks 61. Postfix In a Change Root Environment 7

vi

Typographic Conventions

The fonts, layout, and typographic conventions of this book have beencarefully chosen to increase readability. Please take a moment tofamiliarize yourself with them.

A Warning and Solution

A common problem with computer training and reference materials isthe confusion of the numbers "zero" and "one" with the letters "oh" and"ell". To avoid this confusion, this book uses a fixed-width font that makeseach letter and number distinct.

Typefaces Used and Their Meanings

The following typeface conventions have been followed in this book:

fixed-width normal ⇒ Used to denote file names and directories. Forexample, the /etc/passwd file or /etc/sysconfig/directory. Alsoused for computer text, particularily command line output.

fixed-width italic ⇒ Indicates that a substitution is required. Forexample, the string stationX is commonly used to indicate that thestudent is expected to replace X with his or her own station number,such as station3.

fixed-width bold ⇒ Used to set apart commands. For example, thesed command. Also used to indicate input a user might type on thecommand line. For example, ssh -X station3.

fixed-width bold italic ⇒ Used when a substitution is requiredwithin a command or user input. For example, ssh -X stationX.

fixed-width underlined ⇒ Used to denote URLs. For example,http://www.gurulabs.com/.

variable-width bold ⇒ Used within labs to indicate a required studentaction that is not typed on the command line.

Occasional variations from these conventions occur to increase clarity.This is most apparent in the labs where bold text is only used to indicatecommands the student must enter or actions the student must perform.

0 OThe number

"zero".The letter

"oh".

1 lThe number

"one".The letter

"ell".

vii

Typographic Conventions

Terms and Definitions

The following format is used to introduce and define a series of terms:

deprecate ⇒ To indicate that something is considered obsolete, withthe intent of future removal.

frob ⇒ To manipulate or adjust, typically for fun, as opposed to tweak.grok ⇒ To understand. Connotes intimate and exhaustive knowledge.hork ⇒ To break, generally beyond hope of repair.hosed ⇒ A metaphor referring to a Cray that crashed after the

disconnection of coolant hoses. Upon correction, users were assuredthe system was rehosed.

mung (or munge) ⇒ Mash Until No Good: to modify a file, oftenirreversibly.

troll ⇒ To bait, or provoke, an argument, often targeted towards thenewbie. Also used to refer to a person that regularly trolls.

twiddle ⇒ To make small, often aimless, changes. Similar to frob.

When discussing a command, this same format is also used to show anddescribe a list of common or important command options. For example,the following ssh options:

-X ⇒ Enables X11 forwarding. In older versions of OpenSSH that donot include -Y, this enables trusted X11 forwarding. In newer versionsof OpenSSH, this enables a more secure, limited type of forwarding.

-Y ⇒ Enables trusted X11 forwarding. Although less secure, trustedforwarding may be required for compatibility with certain programs.

Representing Keyboard Keystrokes

When it is necessary to press a series of keys, the series of keystrokeswill be represented without a space between each key. For example, thefollowing means to press the "j" key three times: jjj

When it is necessary to press keys at the same time, the combination willbe represented with a plus between each key. For example, the followingmeans to press the "ctrl," "alt," and "backspace" keys at the same time:Ó¿Ô¿×. Uppercase letters are treated the same: Ò¿A

Line Wrapping

Occasionally content that should be on a single line, such as commandline input or URLs, must be broken across multiple lines in order to fiton the page. When this is the case, a special symbol is used to indicateto the reader what has happened. When copying the content, the linebreaks should not be included. For example, the following hypotheticalPAM configuration should only take two actual lines:

password required /lib/security/pam_cracklib.so retry=3a type= minlen=12 dcredit=2 ucredit=2 lcredit=0 ocredit=2

password required /lib/security/pam_unix.so use_authtok

Representing File Edits

File edits are represented using a consistent layout similar to the unifieddiff format. When a line should be added, it is shown in bold with aplus sign to the left. When a line should be deleted, it is shown struckout with a minus sign to the left. When a line should be modified, itis shown twice. The old version of the line is shown struck out with aminus sign to the left. The new version of the line is shown below theold version, bold and with a plus sign to the left. Unmodified lines areoften included to provide context for the edit. For example, the followingdescribes modification of an existing line and addition of a new line tothe OpenSSH server configuration file:

File: /etc/ssh/sshd_config #LoginGraceTime 2m- #PermitRootLogin yes+ PermitRootLogin no+ AllowUsers sjansen #StrictModes yes

Note that the standard file edit representation may not be used when itis important that the edit be performed using a specific editor or method.In these rare cases, the editor specific actions will be given instead.

viii

Lab Conventions

Lab Task Headers

Every lab task begins with three standard informational headers:"Objectives," "Requirements," and "Relevance". Some tasks also include a"Notices" section. Each section has a distinct purpose.

Objectives ⇒ An outline of what will be accomplished in the lab task.Requirements ⇒ A list of requirements for the task. For example,

whether it must be performed in the graphical environment, orwhether multiple computers are needed for the lab task.

Relevance ⇒ A brief example of how concepts presented in the labtask might be applied in the real world.

Notices ⇒ Special information or warnings needed to successfullycomplete the lab task. For example, unusual prerequisites or commonsources of difficulty.

Command Prompts

Though different shells, and distributions, have different promptcharacters, examples will use a $ prompt for commands to be run asa normal user (like guru or visitor), and commands with a # promptshould be run as the root user. For example:

$ whoamiguru$ su -Password: password# whoamiroot

Occasionally the prompt will contain additional information. For example,when portions of a lab task should be performed on two different stations(always of the same distribution), the prompt will be expanded to:

stationX$ whoamigurustationX$ ssh [email protected]@stationY’s password: passwordstationY# whoamiroot

Variable Data Substitutions

In some lab tasks, students are required to replace portions of commandswith variable data. Variable substitution are represented using italic fonts.For example, X and Y.

Substitutions are used most often in lab tasks requiring more than onecomputer. For example, if a student on station4 were working with astudent on station2, the lab task would refer to stationX and stationY

stationX$ ssh [email protected]

and each would be responsible for interpreting the X and Y as 4 and 2.

station4$ ssh [email protected]

Truncated Command Examples

Command output is occasionally omitted or truncated in examples. Thereare two type of omissions: complete or partial.

Sometimes the existence of a command’s output, and not its content, isall that matters. Other times, a command’s output is too variable toreliably represent. In both cases, when a command should produceoutput, but an example of that output is not provided, the followingformat is used:

$ cat /etc/passwd. . . output omitted . . .

In general, at least a partial output example is included after commands.When example output has been trimmed to include only certain lines,the following format is used:

$ cat /etc/passwdroot:x:0:0:root:/root:/bin/bash. . . snip . . .clints:x:500:500:Clint Savage:/home/clints:/bin/zsh. . . snip . . .

ix

Lab Conventions

Distribution Specific Information

This courseware is designed to support multiple Linux distributions.When there are differences between supported distributions, eachversion is labeled with the appropriate base strings:

R ⇒ Red Hat Enterprise Linux (RHEL)S ⇒ SUSE Linux Enterprise Server (SLES)U ⇒ Ubuntu

The specific supported version is appended to the base distributionstrings, so for Red Hat Enterprise Linux version 6 the complete stringis: R6.

Certain lab tasks are designed to be completed on only a sub-set ofthe supported Linux distributions. If the distribution you are using is notshown in the list of supported distributions for the lab task, then youshould skip that task.

Certain lab steps are only to be performed on a sub-set of the supportedLinux distributions. In this case, the step will start with a standardizedstring that indicates which distributions the step should be performed on.When completing lab tasks, skip any steps that do not list your chosendistribution. For example:

[R4] This step should only be performed on RHEL4.1)Because of a bug in RHEL4's Japanese fonts...

Sometimes commands or command output is distribution specific. Inthese cases, the matching distribution string will be shown to the left ofthe command or output. For example:

$ grep -i linux /etc/*-release | cut -d: -f2Red Hat Enterprise Linux Server release 6.0 (Santiago)[R6]SUSE Linux Enterprise Server 11 (i586)[S11]

Action Lists

Some lab steps consist of a list of conceptually related actions. Adescription of each action and its effect is shown to the right or underthe action. Alternating actions are shaded to aid readability. For example,the following action list describes one possible way to launch and usexkill to kill a graphical application:

Ô¿Å Open the "Run Application" dialog.

xkillÕ Launch xkill. The cursor should change,usually to a skull and crossbones.

Click on a window of the application to kill.Indicate which process to kill by clicking onit. All of the application’s windows shoulddisappear.

Callouts

Occasionally lab steps will feature a shaded line that extends to a notein the right margin. This note, referred to as a "callout," is used to provideadditional commentary. This commentary is never necessary to completethe lab succesfully and could in theory be ignored. However, calloutsdo provide valuable information such as insight into why a particularcommand or option is being used, the meaning of less obvious commandoutput, and tips or tricks such as alternate ways of accomplishing the taskat hand.

On SLES10, the sux commandcopies the MIT-MAGIC-COOKIE-1so that graphical applicationscan be run after switchingto another user account. TheSLES10 su command did notdo this.

$ sux -[S10]Password: password# xclock

Chapter

1SECURITYCONCEPTS

ContentBasic Security Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2RHEL6 Default Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3RHEL6 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5SLES11 Default Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6SLES11 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7SLES11: File Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Minimization – Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Security Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Lab Tasks 14

1. Removing Packages Using RPM . . . . . . . . . . . . . . . . . . 152. Firewall Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173. Process Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224. Operation of the setuid() and capset() System Calls . . 245. Operation of the chroot() System Call . . . . . . . . . . . . . . 28

1-2

Basic Security Principles

Minimization – Remove unneeded componentsHardening – Lock down remaining componentsSimplify

Minimization

One of the most important principles of security is that ofminimization. In short, a service can not be attacked if it is notpresent on the system. When evaluating the security of a system,every installed component should be viewed as a potential securityrisk. Due to the complexity of modern computing systems andsoftware, the risks associated with installing a program can bedifficult, if not impossible, to predict. History has shown repeatedlythat even seemingly innocuous services can lead to back doors andholes in your system's security. When attempting to secure a system,start by determining exactly what set of services are needed on themachine, then begin the process of eliminating all unneededelements from the system.

Minimization is hampered somewhat by the fact that increases insystem performance (faster hardware) coupled with strongcompetition to add new features to the operating system andsoftware often result in a default install that has a huge number ofinstalled and running services. This problem is further exacerbated byserver and service consolidation efforts often taken by systemadministrators; ultimately yielding machines running so many thingsthat securing them becomes next to impossible. For example, RedHat Linux prior to version 8.0 would automatically configure allservices installed to start up automatically on boot. The assumptionwas that if you installed it you must want to run it. However, nowservices are not configured to start automatically on boot and youmust manually configure services.

Hardening

Once a system has been stripped down to just the absolutelynecessary components, hardening of those remaining componentscan commence. The goal of hardening is to use both general purpose(operating system functions) and application specific techniques tolimit the access provided by each remaining service. When hardeninga system, you should carefully consider exactly who should be ableto access a service and exactly what level of access they will require.Typically hardening of a service must be balanced with ease of useas the two concepts are often mutually exclusive. Because properlysecured services are typically more difficult to use, many vendorsship with fairly lax security defaults out-of-the-box. It is only recently(as security has become more of a focus) that vendors have startedto ship services with more secure default configurations.

Eschew Unnecessary Complexity→ SimplifyIf several techniques exist to secure a system or service, you shouldgenerally use the simplest method that meets your requirements.Carefully consider the trade-offs in deploying complex securitymodels. While a complex model may offer benefits in configurationflexibility or performance, it will also be more prone tomisconfiguration or have unforeseen interactions that ultimately leadto service or system compromise.

1-3

RHEL6 Default Install

RHEL6 Custom Package Selection• Default• Custom• Upgrade

Not all dependencies are specified• Mandatory• Default• Optional

Installation and Upgrade

The installation program (Anaconda) installs packages which can behelpful for a user getting started with RHEL6. Each installed packageposes a possible security risk. Where such a large number ofpackages are installed by default, a more secure system can be builtby limiting the packages which are installed.

A system upgrade, as opposed to an installation, will upgradeinstalled packages, resolving package dependencies as needed.Package changes may result in new dependencies and additionalpackages after upgrading.

Accessing Package Groups During Installation

The installation allows arbitrary selection of software. The final stateof the machine will depend entirely on selections made here. It isalways possible to add/remove packages with yum after installationhas completed, but from a security-focused point of view, it's helpfulto start out with a small set of packages. The work required to filterthrough hundreds of packages, removing those that are not needed,exceeds the amount of work to install new packages as required.

When asked to specify additional tasks for which the system shouldinclude support, clicking the Customize now button provides a list ofpackage groups available for installation as seen in the followingscreenshot. Additionally, each package group can be furthercustomized by clicking on the Optional packages button afterselecting each package group.

1-4

Detailed information about what packages are installed for eachpackage group can be obtained from the *comps-rhel6*.xml filesfound on the first installation DVD. These XML files are used by theinstaller to define which individual packages are installed for eachpackage group (e.g. X Window System, Graphical AdministrationTools) available for selection during the install.

On the RHEL6 installation media, these files are located at:

y /HighAvailability/repodata/*-comps-rhel6-*.xmly /LoadBalancer/repodata/*-comps-rhel6-LoadBalancer.xmly /ResilientStorage/repodata/*-comps-rhel6-*.xmly /Server/repodata/*-comps-rhel6-Server.xml

1-5

RHEL6 Firewall

Default firewall:• lokkit --enabled --service=ssh

All loopback traffic acceptedAll outbound connections allowedOnly inbound SSH connections permitted

Firewall configuration• service iptables (start|status|stop|save)

/etc/sysconfig/iptables/etc/sysconfig/iptables-config

• service ip6tables (start|status|stop|save)/etc/sysconfig/ip6tables/etc/sysconfig/ip6tables-config

Default Firewall Configuration

The default RHEL6 firewall provides a basic firewall for trustednetworks. This firewall is excellent for laptops, workstations, andhome servers, but should be expanded on, or replaced, forproduction servers. The Red Hat firewall utilizes stateful packetfiltering rules, allowing all established and related inbound traffic. Thefirewall is also configured to explicitly allow inbound SSH traffic. Allother traffic through the INPUT (and FORWARD) chain is rejected. Alloutbound traffic is accepted.

Loading Firewall Configuration

The /etc/sysconfig/iptables-config and/etc/sysconfig/ip6tables-config files control the behavior of the/etc/rc.d/init.d/iptables and /etc/rc.d/init.d/ip6tablesservice scripts, respectively. Configuration options include loadingand unloading of Netfilter kernel modules and saving of the firewallstate when stopping or restarting the services.

The firewall configuration is stored in two files:/etc/sysconfig/iptables and /etc/sysconfig/ip6tables. Eachtime the system boots, the /etc/init.d/iptables and/etc/init.d/ip6tables scripts load their respective configuration.See iptables-restore(8) and ip6tables-restore(8).

libvirtd will dynamically add rules to the firewall configuration tosupport virtual machines configured with virt-manager. These rulesare removed when libvirtd is stopped.

Managing Firewall Configuration

Red Hat provides custom tools for automating the configuration offirewall settings. These tools provides Netfilter options to allow trafficto trusted services, as well as more advanced options, such as IPmasquerading and port forwarding.

lokkit ⇒ Part of the system-config-firewall-base package, this isa simple Python script that can configure your firewall from thecommand line.

system-config-firewall ⇒ Provided by a separate package, this isa graphical tool that does the same as lokkit.

system-config-firewall-tui ⇒ A text based, interactive program,similar to the lokkit program of past releases of Red HatEnterprise Linux. It provides the same functionality as thesystem-config-firewall, and the current lokkit, command.

Defaults to tools provided by the system-config-firewall packagesare configured in the /etc/sysconfig/system-config-firewall file.The system-config-firewall, system-config-firewall-tui, andlokkit commands write the /etc/sysconfig/iptables and/etc/sysconfig/ip6tables files. Manually editing these files riskshaving your edits being overwritten.

There are also problems with using the iptables and ip6tablescommands: forgetting to run service ip{,6}tables save aftermaking changes, overwriting changes to the existing firewall rulesfile(s), or saving dynamic libvirtd rules to the static persistentconfiguration.

1-6

SLES11 Default Install

SLES Defaults• Service Location Protocol (SLP) server running and accepting

network connectionsCommon Defaults• SSH server listens for inbound connections• Firewall enabled by default• No development tools installed

SUSE Linux Enterprise Server Default Install

A default installation will enable an SSH daemon accepting networkconnections, a default firewall will be enabled, and no developmenttools, such as a compiler, will be installed.

The OpenSLP service location protocol server is installed andlistening for client connections. The SLP protocol is an industrystandard unicast and multicast protocol for clients to be able toautomatically find network resources based on resource type and atextual description rather than having to use an IP address orhostname. IP based Novell Netware networks use SLP as areplacement for SAP.

The following services are registered with SLP by default:

y SSHy VNCy NTPy Samba

Although all those services are registered with OpenSLP, only theSSH daemon is actually started by default.

1-7

SLES11 Firewall

SuSEfirewall2• Also for easy deployment of complicated firewall rules• Network Interfaces, IP networks mapped to three zones:• External Network / Internal Network / DMZ• /etc/sysconfig/SuSEfirewall2 or YaST firewall module

The SUSE Firewall

Compared to other firewalls that only support end host configuration,the SUSE firewall is much more sophisticated and supports firewallconfiguration where multiple network interfaces are installed. Eachnetwork interface on the firewall needs to be assigned to one ofthree zones:

External Network ⇒ Network interface(s) facing the Internet.Internal Network ⇒ Network interface(s) facing internal hosts that

may or may not be using RFC1918 IP addresses and require NAT.DMZ Network ⇒ Network interface(s) containing hosts that can be

reached by hosts on the external and internal networks, butcannot initiate connections into the internal networks.

By default no traffic is allowed inbound from the external networkand any desired protocols and ports must be explicitly allowed.

The configuration of the SUSE firewall can be done by manuallyediting the variables contained within the well commented/etc/sysconfig/SuSEfirewall2 script, or via a wizard interface withthe YaST firewall module.

Starting with SUSE Linux 9.2, it is possible to configure the firewallduring installation.

1-8

SLES11: File Security

Tightening of file and directory permissions• Four modes supported• easy, secure, paranoid, local• easy is default, secure enables trusted group, paranoid designed

for a no-user application server, local allows an admin to specifyadditional permissions

• /etc/permissions.*

Tightening File and Directory Permissions

A typical Linux installation has a few hundred thousand files on it. Thepermissions must be set so that applications function properly, whileat the same time preventing insecure permissions that allowtampering or access to confidential information. SLES11 ships withthe /usr/bin/chkstat program, which maintains the integrity of fileownership, group membership, and permissions of files.

SLES11 ships with four files that correspond to four security modes:

y /etc/permissions.easyy /etc/permissions.securey /etc/permissions.paranoidy /etc/permissions.local

Which mode to use is defined by the PERMISSION_SECURITY variablein the /etc/sysconfig/security file. Whenever SuSEconfig is run,the permissions are reapplied.

The "easy" mode corresponds to traditional permissions, while"secure" requires that users be a member of the trusted group to runcertain commands like crontab and cardctl, along with a generaltightening of permissions, while still enabling a multi-user system tofunction. The "paranoid" mode strips all setuid and setgid bits fromexecutables and isn't meant to function properly for a given situationwithout customization. It is intended for applications servers thathave no users who login interactively. The "local" mode is intended asa template for administrators when they add custom softwarepackages, for example those installed to the /usr/local/ filesystem.

1-9

Minimization – Discovery

Discovering installed software• rpm -q• find or locate

Discovering Installed Software

The process of minimization involves identifying exactly whatsoftware is needed on a system and then ensuring that only thatnecessary software is present. Most installs make use of the basepackage groups that contain various individual packages. Often youwill find that you need some, but not all of the packages provided bya package group. When this happens, you can either skip thepackage group, choosing rather to select the individual packages, orinstall the package group and remove unneeded packages manuallypost-install.

The rpm command can also be used on a system to collectinformation about installed packages and remove unneededpackages. Useful example rpm commands include:

command example description

rpm -qa List all packages installed on the system.

rpm -qi package List detailed information about the package.

rpm -ql package List all file provided by the package.

rpm -qf file List the package name that provided a file.

rpm -qlp file.rpm List all files contained in file.rpm package.

rpm -e package Remove (erase) the listed

Software not Installed via Packages

Software installed from RPM packages is generally easy to track andmanage. When software has been installed via other means(compiled from source, etc.) it is generally more difficult to track allchanges and files provided by the software and cleanly remove them.One thing that can help this situation is using the--prefix=/pathname option when running the configure script priorto compile. Always using some common known base path(/usr/local, /opt, etc.) can help ensure that programs files aregrouped and isolated in a known location facilitating later removal.

The find and locate commands can be helpful in tracking down filesfor removal. The find command supports the -exec and -ok optionsto run an arbitrary command on files matched by the search criteria.Suppose, for instance, that you are attempting to remove installedsoftware that has all of its files owned by a specific user or groupaccount (not uncommon for daemons). The following find commandsyntax might be used:

# find /base/path -user username -exec rm {} \;

1-10

Service Discovery

chkconfignetstatsslsofps

Locating Running Processes

In addition to searching the filesystem and RPM database for lists ofinstalled packages and files, A wide variety of commands exist thatcan help locate running processes:

The chkconfig command is a simple way to get a list of whatservices are currently configured to start on boot in the variousrun-levels:

# chkconfig --list | grep onkeytable 0:off 1:on 2:on 3:on 4:on 5:on 6:offatd 0:off 1:off 2:off 3:on 4:on 5:on 6:offsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off. . . snip . . .

Check all running processes with the ps command. Possibleexamples include: ps -efw or ps auxw. During minimization, everyrunning process should be considered a potential threat andeliminated if possible. One simple rule-of-thumb: if the process list ismore than one screen of output, or contains processes whosepurpose is unknown, then continue to evaluate the list.

The ss command, and the older netstat, can be used to discoverwhat processes are listening on network ports. Any services listeningon the network should be carefully scrutinized as they represent alarger potential security vulnerability. Similar information about whatprocesses have bound network sockets can be obtained using thelsof command as shown in the following examples:

# netstat -taupeActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program nametcp 0 0 *:ssh *:* LISTEN root 8168 3579/sshdtcp 0 0 localhost:ipp *:* LISTEN root 8299 3601/cupsdtcp 0 0 localhost:smtp *:* LISTEN root 8845 3705/master. . . snip . . .# ss -taupeNetid State Recv-Q Send-Q Local Address:Port Peer Address:Porttcp LISTEN 0 128 *:ssh *:* users:(("sshd",3579,3)) ino:8168 sk:f4aa7a80tcp LISTEN 0 128 127.0.0.1:ipp *:* users:(("cupsd",3601,3)) ino:8299 sk:f441d080tcp LISTEN 0 100 127.0.0.1:smtp *:* users:(("master",3705,12)) ino:8845 sk:f441d580

1-11

# lsof -iCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEsshd 3579 root 3u IPv4 8168 0t0 TCP *:ssh (LISTEN)cupsd 3601 root 3u IPv4 8299 0t0 TCP localhost:ipp (LISTEN)cupsd 3601 root 5u IPv4 8302 0t0 UDP *:ippmaster 3705 root 12u IPv4 8845 0t0 TCP localhost:smtp (LISTEN)

1-12

Hardening

Packet filtering• Netfilter

General service wrapping• TCP wrappers• (x)inetd

PAM

Hardening of Remaining Services

Once the minimization process is complete, and all unneededservices have been removed or at least turned off, hardening of theremaining services can begin. Much of service hardening will beservice specific, but several general solutions exist that can be usedto increase the security of a wide variety of services.

Packet Filtering

The Linux kernel includes the Netfilter packet filtering system, arobust, versatile solution that, in its current incarnation, includes bothstateless and stateful packet filtering, NAT, and much more. Packetfiltering can ensure that only specific types of traffic can reachservices you designate.

General Service Wrapping

Often, if an application's built in security features are inadequate, theservice can be wrapped inside another simple process that canperform additional checks to increase security. Wrapping can alsoprovide a single unified way of configuring security for an otherwisediverse set of services. The most commonly used service wrapper iscalled TCP Wrappers and was written by Weitse Venema. TCPWrappers was frequently used by a Unix super-server (a servicedispatcher), like inetd, that would make a call to the wrapperprogram (tcpd) which would only allow the client to connect to thewrapped service if the connection met with certain defined IPaddress based checks. As an example, the following compares a

client attempting to FTP to an unprotected server and a serveremploying TCP Wrappers:

Unwrapped server:

y FTP client → listening inetd host → FTP server

TCP Wrapped server:

y FTP client → listening inetd host → tcpd → FTP server

Newer Unix super-servers, like xinetd, typically have their ownbuilt-in methods for limiting connections.

PAM

The Pluggable Authentication Modules system acts as an abstractionlayer between applications and the actual methods used to performthe authentication. On a modern Linux system, most networkservices and applications that need to perform authentication are builtto take advantage of PAM. This allows simple changes to theservice's PAM configuration file(s), modifying the methods used forauthentication, and providing a powerful tool for increasing systemsecurity.

1-13

Security Concepts

Dropping privileges• setuid()• Capabilities

chroot

Minimizing Service Capabilities

One important principle of security is that of limiting the level ofaccess granted to only that which is absolutely required to performthe task. Unix systems traditionally have had something of a problemhere due to a lack of granularity with user access rights. Essentially,there is the root user (who is all powerful) and everyone else. Certainsystem tasks require that a process be running as the root user forthem to succeed. An excellent example of this is the fact that onlyprocesses running as the root user are allowed to bind to TCP andUDP ports 0-1023. Because of this, many network services are forcedto run as the root user even though they require root's elevatedprivileges only for binding to the reserved port.

The setuid() System Call

A general technique used by network services to help limit exposureis to start as the root user (allowing binding to reserved ports), andthen use the setuid() system call to change its security context andrun as some unprivileged user. After this has occurred, it isimpossible for the program to regain root privileges.

Capabilities

Linux also implements support for capabilities as originally defined inthe POSIX 1003.1e draft standard. Capabilities allow a far moregranular allocation of access to applications. The capabilitiessupported by Linux are documented and described in thecapability.h file, located in the kernel source package. Programs

written to take advantage of the capabilities scheme can use systemcalls to drop certain capabilities when they are no longer needed,greatly limiting the potential for damage should the service becompromised or have a bug. The libcap package includes thecommands sucap, and execcap for wrapping arbitrary programs andusing the capabilities model. Also included are the getpcaps andsetpcaps programs for listing and changing the capabilities ofrunning processes.

[R6] The following applies to RHEL6 only:

In RHEL6, the capability.h header file is found in the kernel-develpackage. It can also be found in the kernel-headers package.

[S11] The following applies to SLES11 only:

In SLES11, the capability.h header file is contained in thekernel-source package.

The chroot Command

A final general technique used by programs to help restrict the levelof access is that of changing the program's apparent root directoryfor filesystem access. This is done via use of the chroot() systemcall, or its corresponding user-space chroot command. Running aprocess in a change rooted directory helps keep processes frommodifying files outside of its defined root.

1-14

Lab 1Estimated Time:R6: 35 minutes

S11: 35 minutesTask 1: Removing Packages Using RPMPage: 1-15 Time: 5 minutesRequirements: b (1 station)

Task 2: Firewall ConfigurationPage: 1-17 Time: 5 minutesRequirements: bb (2 stations) c (classroom server)

Task 3: Process DiscoveryPage: 1-22 Time: 5 minutesRequirements: b (1 station)

Task 4: Operation of the setuid() and capset() System CallsPage: 1-24 Time: 10 minutesRequirements: b (1 station)

Task 5: Operation of the chroot() System CallPage: 1-28 Time: 10 minutesRequirements: b (1 station) c (classroom server)

1-15

Objectivesy Use the rpm command to discover what software packages are installed

on the system.y Identify the dependency chain to identify how to remove unneeded

packages.

Requirementsb (1 station)

RelevanceFrom a security perspective, it is important to know what is installed andneeded on a computer. Removing programs that are not needed helps toprotect against vulnerabilities.

Lab 1

Task 1Removing Packages UsingRPMEstimated Time: 5 minutes

As the root user, run the following command from a terminal to list the names of1)all the packages that are currently installed on the system:

$ rpm -qa | less. . . output omitted (press 'q' to quit when done) . . .

How many packages are currently installed on the system?2)

$ rpm -qa | wc -l. . . output omitted . . .

Suppose that you are trying to remove any unneeded software from the system.3)In exploring the filesystem you encounter the file /usr/bin/openssl. You want toevaluate whether you can safely remove this file. Start by using the rpm commandto discover what package provides the file, and what other files are included inthe package:

$ rpm -qilf /usr/bin/openssl | less. . . output omitted (press 'q' to quit when done) . . .

Based on the proceeding step you now know a little more about what the4)openssl package does. You still do not know if other applications on the systemmight use it. To see if it can safely be removed (without breaking otherapplications due to dependencies), run the following command to detect first leveldependencies:

1-16

$ rpm -q --whatrequires opensslPackages that rely on files provided by the opensslpackage.

report-0.18-7.el6.i686[R6]postfix-2.6.6-2.el6.i686[R6]openssl-certs-0.9.8h-27.1.30[S11]perl-Crypt-SSLeay-0.57-1.15.1[S11]limal-ca-mgm-1.5.22-0.2.15[S11]dirmngr-1.0.2-1.19[S11]cryptconfig-0.3-68.8.17[S11]. . . snip . . .

Removing the openssl package would break the packages listed in the preceding5)step. If you are still intent on removing the openssl package (and all the packagesthat depend on it), then start the recursive process of determining what otherpackages depend on those just discovered:

$ for i in $(rpm -q --whatrequires openssl | paste -s)> do rpm -q --whatrequires $i> doneno package requires report-0.18-7.el6.i686[R6]no package requires postfix-2.6.6-2.el6.i686[R6]no package requires openssl-certs-0.9.8h-27.1.30[S11]no package requires perl-Crypt-SSLeay-0.57-1.15.1[S11]no package requires limal-ca-mgm-1.5.22-0.2.15[S11]no package requires dirmngr-1.0.2-1.19[S11]no package requires cryptconfig-0.3-68.8.17[S11]

In this case, there are no further dependencies. If there were, it would benecessary to repeat this process.

After completing this recursive search, you might be tempted to think that you6)have a complete list of "what breaks" if the openssl package is removed. The truestory is that the openssl package actually provides more than just the opensslcommand. To get the whole list of first level dependencies for files provided bythe openssl package, run the following:

$ rpm -q --whatrequires $(rpm -q --provides openssl) | sort | uniq | more

Note that this list is not complete, either. This is because the work of recursivelydetermining what things are provided by each of the listed packages, and whatother packages might depend on them, also needs to be done.

1-17

Objectivesy Explore the use of the lokkit program for simple firewall configuration.y Explore the use of yast for a default firewall configuration.

Requirementsbb (2 stations) c (classroom server)

RelevanceConfiguring a simple firewall can be very good for a first line of defenseagainst many security issues.

Lab 1

Task 2Firewall ConfigurationEstimated Time: 5 minutes

The following actions require administrative privileges. Switch to a root login1)shell:

$ su -lPassword: makeitso Õ

Install the telnet-server package to be used for testing the firewall.2)

# yum install -y finger telnet telnet-server[R6]# rug install -y telnet-server[S11]. . . output omitted . . .

Turn on the telnet service:3)

# chkconfig telnet on# service xinetd restart. . . output omitted . . .

Verify network connectivity:4)Where 'Y' is replaced with the station number of yourlab partner.

# ping 10.100.0.Y. . . output omitted (+C to end) . . .# telnet 10.100.0.YTrying 10.100.0.Y...Connected to stationY.example.com (10.100.0.Y).Escape character is 'ˆ]'.. . . snip . . .login: guru

1-18

Password: work Õ[[email protected] guru]$ logout

After both lab partners have completed the previous step, list the current5)iptables policies:

# iptables -n -LChain INPUT (policy ACCEPT)target prot opt source destinationChain FORWARD (policy ACCEPT)target prot opt source destinationChain OUTPUT (policy ACCEPT)target prot opt source destination

[R6] This step should only be performed on RHEL6.6)Use the lokkit program to activate a simple firewall:

-q=quietly (without interaction)# lokkit --enabled -q

[S11] This step should only be performed on SLES11.7)Use YaST to activate a default firewall:

# yast2 firewall

Go to the Interfaces spoke.

Set all interfaces to External Zone.Go back to the Start-Up spoke.

Select Enable Firewall Automatic Starting.

Select Save Settings and Restart Firewall Now.

Select Next and Finish.

[R6] This step should only be performed on RHEL6.8)Verify that the firewall policy is in effect:

# iptables -n -L

1-19

Notice the default policy is still ACCEPT, so "undefined"traffic is still permitted.

Chain INPUT (policy ACCEPT)

Allow return traffic for connections established by thismachine.

target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 statea RELATED,ESTABLISHED

Allow all ICMP traffic.ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 All traffic to loopback interface is allowed.ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 Be transparent dropping packets by responding with arejection message.

REJECT all -- 0.0.0.0/0 0.0.0.0/0a reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)target prot opt source destinationREJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)target prot opt source destination

[R6] This step should only be performed on RHEL6.9)Verify that the firewall policy is stored for use on next boot:

# cat /etc/sysconfig/iptables# Firewall configuration written by system-config-firewall# Manual customization of this file is not recommended.*filter:INPUT ACCEPT [0:0]:FORWARD ACCEPT [0:0]:OUTPUT ACCEPT [0:0]-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT-A INPUT -p icmp -j ACCEPT-A INPUT -i lo -j ACCEPT-A INPUT -j REJECT --reject-with icmp-host-prohibited-A FORWARD -j REJECT --reject-with icmp-host-prohibitedCOMMIT

[S11] This step should only be performed on SLES11.10)Examine the firewall policy created:

# less /etc/sysconfig/SuSEfirewall2

1-20

. . . output omitted . . .# iptables -n -L | less. . . output omitted . . .# iptables -t mangle -n -L. . . output omitted . . .# iptables -t nat -n -L. . . output omitted . . .

[R6] This step should only be performed on RHEL6.11)Once both lab partners have reached this point, use telnet to verify that bothfirewall configurations are working:

# telnet stationYTrying 10.100.0.Y...

Blocked by the packet filtering of their firewall.telnet: connect to address 10.100.0.Y: No route to hosttelnet: Unable to connect to remote host: No route to host

[S11] This step should only be performed on SLES11.12)Once both lab partners have reached this point, use telnet to verify that bothfirewall configurations are working:

# telnet stationYTrying 10.100.0.Y.... . . very long time . . .

Blocked by the packet filtering of their firewall.telnet: connect to address 10.100.0.Y: Connection timed out

Test the firewall policy by attempting to connect to the finger and ssh servers:13)

Denied by firewall and should fail.# finger @stationY. . . very long time . . .

Denied by firewall and should fail.# ssh stationY. . . very long time . . .

Cleanup

Disable the telnet service:14)

# chkconfig telnet off

1-21

[R6] This step should only be performed on RHEL6.15)Stop the firewall and remove it from the boot process.

# lokkit --disabled

[S11] This step should only be performed on SLES11.16)Stop the firewall and remove it from the boot process. Commit the change.

# SuSEfirewall2 offSuSEfirewall2: batch committing...SuSEfirewall2: Firewall rules unloaded.

Administrative privileges are no longer required; exit the root shell to return to an17)unprivileged account:

# exit

1-22

Objectivesy Identify running processesy Disable and un-install unneeded software


RelevanceWhen deploying any service, especially ones that listen on the network,best security practice is to disable any unneeded functionality. This wayattackers will have less surface area to attack.

Lab 1

Task 3Process DiscoveryEstimated Time: 5 minutes



Identify which services are currently configured for the various run-levels:2)

A useful trick here if you want to see only servicesconfigured to start is to pipe the output through egrep':[[:space:]]*on'.

# chkconfig --list. . . snip . . .auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off. . . snip . . .

Notice that all of the xinetd based services do not listrun-levels.

xinetd based services: chargen-dgram: off chargen-stream: off. . . snip . . .

Use the chkconfig command to turn off some unneeded services:3)Since all xinetd services are turned off, xinetd is nolonger needed and should be turned off, as well.

# chkconfig xinetd off# chkconfig bluetooth off[R6]# chkconfig slpd off[S11]# chkconfig nscd off[S11]

Check to see which services are bound and listening on the network:4)

# ss -taupn | grep LISTEN

1-23

. . . snip . . .tcp LISTEN 0 128 *:111 *:* users:(("rpcbind",1340,8))tcp LISTEN 0 128 :::22 :::* users:(("sshd",1617,4)). . . snip . . .

Use lsof to obtain a list of open socket handles. This information is the same as5)provided by netstat, just formatted differently:

# lsof -iCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMErpcbind 3194 root 6u IPv4 7525 0t0 UDP *:sunrpcrpcbind 3194 root 7u IPv4 7529 0t0 UDP *:fcp-udprpcbind 3194 root 8u IPv4 7530 0t0 TCP *:sunrpc (LISTEN)rpcbind 3194 root 9u IPv6 7532 0t0 UDP *:sunrpcrpcbind 3194 root 10u IPv6 7562 0t0 UDP *:fcp-udprpcbind 3194 root 11u IPv6 7563 0t0 TCP *:sunrpc (LISTEN). . . snip . . .

Completely remove a service stopped in the previous step, along with other6)dependencies that are not needed (or wanted) on the system:

# rpm -e xinetderror: Failed dependencies:[R6] xinetd is needed by (installed) telnet-server-1:0.17-46.el6.i686[R6]# rpm -e xinetd telnet-server[R6]. . . snip . . .[R6]


# exit

1-24

Objectivesy Examine a daemon's use of the setuid() and capset() system calls to

increase security.


RelevanceThe setuid() and capset() system calls can be used by developers onLinux for applications that run or start as the root user to dropunnecessary privileges. It is important to understand how these systemcalls work in order to be able understand how security techniquesinvolving these calls are implemented on Linux.

Lab 1

Task 4Operation of the setuid() andcapset() System CallsEstimated Time: 10 minutes



The machine should currently be running the ntp service (started as part of the2)standard classroom install). Verify that the process is running:

The [n] character class is used so the grep commanddoes not observe itself looking for ntp. If confused,removed the square brackets and compare the result.

# ps -ef | grep [n]tpntp 2827 1 0 Dec18 ? 00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid[R6]ntp 3279 1 0 Dec18 ? 00:00:00 /usr/sbin/ntpd -p /var/lib/ntp/var/a[S11] run/ntp/ntpd.pid -u ntp -i /var/lib/ntp

Identify the user and group (both real and effective) the ntpd process is running3)as:

# ps -C ntpd -o comm,pid,ruser,euser,rgroup,egroupCOMMAND PID RUSER EUSER RGROUP EGROUPntpd 2827 ntp ntp ntp ntp

Notice that the ntpd process is running as the ntp user and group. From earlierexamination with lsof and other commands you have seen that ntpd is bound toUDP port 123 (a privileged reserved port). Also, the ntpd process must be able tochange the system clock—a task that a normal unprivileged user can not normallydo.

1-25

How does the ntpd process running as an unprivileged user do the two things4)(bind to port 123, and set system time) that traditionally only the root user cando?

Result:

Discover the methods used by ntpd to run securely. Start by killing the running5)ntpd process, then use the strace command to gather information about whatsystem calls it makes as it starts:

# killall ntpd# cd /tmp

Start the NTP daemon logging all system calls to thentp-calls file.

# strace -f ntpd -u ntp:ntp -g 2> ntp-calls &[1] 4784

Use grep to extract a few specific lines from the captured strace output:6)

# grep -n bind ntp-calls | grep AF_INET151:bind(16, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("0.0.0.0")}, 16) = 0161:bind(17, {sa_family=AF_INET6, sin6_port=htons(123), inet_pton(AF_INET6, "::", &sin6_addr),a sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0180:bind(18, {sa_family=AF_INET6, sin6_port=htons(123), inet_pton(AF_INET6, "fe80::21b:21ff:fe24:fae6",a &sin6_addr), sin6_flowinfo=0, sin6_scope_id=if_nametoindex("eth0")}, 28) = 0193:bind(19, {sa_family=AF_INET6, sin6_port=htons(123), inet_pton(AF_INET6, "::1", &sin6_addr),a sin6_flowinfo=0, sin6_scope_id=1}, 28) = 0207:bind(20, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("127.0.0.1")}, 16) = 0222:bind(21, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("10.100.0.X")}, 16) = 0

The ntpd process is actually binding to port 123 for a few configured IPaddresses. Remember, that the process was launched as root. At this point it isstill running as root and can therefore bind to the privileged port.

Use grep to list the capabilities calls ntpd made:7)

# grep -n capset ntp-calls315:capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_TIME, CAP_NET_BIND_SERVICE|CAP_SYS_TIME,a CAP_NET_BIND_SERVICE|CAP_SYS_TIME}) = 0

A short time later the ntpd process is making use of the capset() system call toreset its capabilities, dropping everything except for the

1-26

CAP_NET_BIND_SERVICE|CAP_SYS_TIME capability that it needs to modify thesystem clock. At this point the ntpd process no longer has any of the othercapabilities normally associated with root owned processes (bind reserved ports,raw sockets, etc.).

Use grep to also list the previous few lines following the capabilities call made by8)ntpd:

# grep -n -B 5 capset ntp-calls310-setgid32(104) = 0311-setresgid32(-1, 104, -1) = 0312-setuid32(74) = 0313-setresuid32(-1, 74, -1) = 0314-capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)315:capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_TIME, CAP_NET_BIND_SERVICE|CAP_SYS_TIME,a CAP_NET_BIND_SERVICE|CAP_SYS_TIME}) = 0

Examining the system calls immediately before the capset() reveals that the ntpdprocess uses the setgid32() and setuid32() system calls to change its effectiveuser and group to the ntp user.

Examine ntpd /proc/PID/status to see the results of these calls:9)

# cat /proc/$(pgrep ntpd)/statusName: ntpdState: S (sleeping)Tgid: 25443Pid: 25443PPid: 1TracerPid: 25441

A quick check in /etc/passwd and /etc/group revealsthat the UID and GID correspond to the ntp user.

Uid: 74 74 74 74Gid: 104 104 104 104. . . snip . . .

All capability sets (Inherited, Permitted, and Effective)have been cleared with only the CAP_SYS_TIME flagremaining. A listing of the capabilities can be found inthe file capability.h found in the kernel source tree.

CapInh: 0000000002000000CapPrm: 0000000002000000CapEff: 0000000002000000. . . snip . . .

1-27

Clean up:

Kill the running strace and restart the service normally.10)

# killall ntpd# service ntpd start[R6]# service ntp start[S11]


# exit

1-28

Objectivesy Examine the security implications of chroot().

Requirementsb (1 station) c (classroom server)

RelevanceThe chroot() system call has been used since the early days of Unix toisolate daemons into a particular directory. This is done to limit the impactof a security breach. It is important to understand how chroot() worksunder Linux as a security technique and how it is used by some services.Nowadays SELinux is able to provide equivalent, or better, security withoutthe need to maintain and update binaries and libraries within a dedicatedchroot directory.

Lab 1

Task 5Operation of the chroot()System CallEstimated Time: 10 minutes



Install packages needed for this lab task:2)

# yum install -y busybox[R6]# zypper install -y busybox[S11]

List the working and root directories for the currently running shell:3)

# cd /tmp/The $$ variable contains the PID of this shell.# ls -l /proc/$$/{cwd,root}current working directory (cwd) is set to /tmp.lrwxrwxrwx 1 root root 0 Dec 22 23:29 /proc/3122/cwd -> /tmproot directory is still set to the filesystem root of /.lrwxrwxrwx 1 root root 0 Dec 22 23:29 /proc/3122/root -> /

Set up a simple chroot-ready directory to run some programs in:4)

# mkdir jail# cd jail# cp /sbin/busybox .[R6]# cp /usr/bin/busybox .[S11]

1-29

# cp /bin/bash .# file *bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked a[R6] (uses shared libs), for GNU/Linux 2.6.18, strippedbash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4,a[S11] dynamically linked (uses shared libs), strippedbusybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked a (uses shared libs), stripped

Dynamically linked executables require their needed libraries in order to start. In5)order to use dynamically linked executables in a chroot environment, the librariesthey use need to be copied into the chroot directory. Use the ldd command to listshared library dependencies:

# ldd * linux-gate.so.1 => (0x00d2d000)[R6] libtinfo.so.5 => /lib/libtinfo.so.5 (0x00b94000)[R6] libdl.so.2 => /lib/libdl.so.2 (0x00347000)[R6] libc.so.6 => /lib/libc.so.6 (0x001b9000)[R6] /lib/ld-linux.so.2 (0x00193000)[R6]busybox:[R6] not a dynamic executable[R6]bash:[S11] linux-gate.so.1 => (0xffffe000)[S11] libreadline.so.5 => /lib/libreadline.so.5 (0xb76df000)[S11] libdl.so.2 => /lib/libdl.so.2 (0xb76da000)[S11] libc.so.6 => /lib/libc.so.6 (0xb7579000)[S11] libncurses.so.5 => /lib/libncurses.so.5 (0xb753c000)[S11] /lib/ld-linux.so.2 (0xb7740000)[S11]busybox:[S11] linux-gate.so.1 => (0xffffe000)[S11] libselinux.so.1 => /lib/libselinux.so.1 (0xb783f000)[S11] libc.so.6 => /lib/libc.so.6 (0xb76de000)[S11] libdl.so.2 => /lib/libdl.so.2 (0xb76d9000)[S11] /lib/ld-linux.so.2 (0xb7884000)[S11]

Examining the output of the ldd, obtain a list of the required libraries and copy6)them into the chroot jail/ directory:

# mkdir lib

1-30

# cp /lib/{lib{tinfo,dl,c},ld-linux}.so.? lib/[R6]# cp /lib/{lib{readline,ncurses,dl,c},ld-linux}.so.? lib/[S11]

Note that on a production system the system administrator needs to take care toupdate the files in the chroot when the original file is updated (for security hole orbug fixes).

Use the chroot command to lock the spawned shell into the chroot directory and7)use busybox to explore the directory:

Start the bash shell chrooted to the /tmp/jaildirectory.

# chroot /tmp/jail /bash

Within the chroot directory, /bin/ls does not exist.# /bin/lsbash: /bin/ls: No such file or directory

Use the bash built in echo to at least see what existsin the current directory.

# echo *

Look, there is busybox!bash busybox libBusybox has built-in implementations of many commoncommands. Obtain a list of what is available:

# /busybox. . . snip . . .Currently defined functions: [, [[, acpid, addgroup, adduser, adjtimex, ar, arp, arping, ash, awk, basename, beep, blkid, brctl, bunzip2, bzcat, bzip2, cal, cat, catv, chat, chattr, chgrp, chmod, chown, chpasswd, chpst, chroot, chrt, chvt,. . . snip . . .

Run the ls built into busybox.# /busybox ls -aldrwxr-xr-x 3 0 0 1024 Dec 18 09:24 .drwxr-xr-x 3 0 0 1024 Dec 18 09:24 ..-rwxr-xr-x 1 0 0 722684 Dec 18 09:10 bash-rwxr-xr-x 1 0 0 1920480 Dec 18 09:00 busyboxdrwxr-xr-x 2 0 0 1024 Dec 18 09:24 lib

Use busybox to create a test directory.# /busybox mkdir testThe change directory "command" is built into bash.# cd testFrom the perspective within the chroot directory, pwdshows the process is running in /test/. From outsidethe chroot environment, it is really in /tmp/jail/test/.

# /busybox pwd/test

With the bash process still running chrooted, open another terminal window and8)run this command to examine its current and root directories:

# ls -l /proc/$(pgrep -xf /bash)/{cwd,root}lrwxrwxrwx 1 root root 0 Dec 23 02:45 /proc/3822/cwd -> /tmp/jail/testlrwxrwxrwx 1 root root 0 Dec 23 02:45 /proc/3822/root -> /tmp/jail

1-31

Close the chroot shell running in the other terminal window:9)

# exit

Chapter

8SECURING THEFILESYSTEM

ContentFilesystem Mount Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 2NFS Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3NFS Export Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4NFSv4 and GSSAPI Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Implementing NFSv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Implementing Kerberos with NFS . . . . . . . . . . . . . . . . . . . . . 8GPG – GNU Privacy Guard . . . . . . . . . . . . . . . . . . . . . . . . . . 10File Encryption with OpenSSL . . . . . . . . . . . . . . . . . . . . . . . 12File Encryption With encfs . . . . . . . . . . . . . . . . . . . . . . . . . . 13Linux Unified Key Setup (LUKS) . . . . . . . . . . . . . . . . . . . . . . 14Lab Tasks 16

1. Securing Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172. Securing NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213. Implementing NFSv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254. File Encryption with GPG . . . . . . . . . . . . . . . . . . . . . . . . . 335. File Encryption With OpenSSL . . . . . . . . . . . . . . . . . . . . 376. LUKS-on-disk format Encrypted Filesystem . . . . . . . . . 40

8-2

Filesystem Mount Options

Linux supports advanced filesystem mount options• Can be used to increase security• /etc/fstab

The noexec option• Prevents execution of binaries

The nosuid option• Doesn't honor SUID bits on binaries

The nodev option• Doesn't honor block or character device files

Controlling Binaries Executed on the System

Most break-ins, and system damage, occur when binaries areintroduced, and executed, by end users. With Linux, this can beprevented by careful partitioning and by use of the noexec mountoption.

To successfully implement this, every directory that users can writeto should be on a filesystem mounted with the noexec option. Caremust be taken that system binaries are on separate non-user writablefilesystems and mounted normally.

With such a setup in place, users will only be allowed to executebinaries that the system administrator installs in the normal systemexecutable directories. These are typically /bin/, /sbin/, /usr/bin/,/usr/sbin/, /home/user/bin/, /usr/local/bin/, and/usr/local/sbin/.


On SLES11, /usr/lib/mit/sbin/ and /usr/lib/mit/bin/ are thebinary directories for kerberos enabled binaries.

Protection from Removable Media

A common attack on Unix was for an attacker, on the client system,to place an SUID root shell binary on removable media. The attackermounts the media (such as a USB thumb drive), and creates SUIDand SGID root shells on it:

# mkdir /usbdrive/rootshells# cp /bin/zsh /usbdrive/rootshells# cp /bin/ksh /usbdrive/rootshells# cp /bin/ash /usbdrive/rootshells# chmod 6755 /usbdrive/rootshells/*

Taking the USB drive to the victim's computer and by mounting thatremovable media via automatic mounting software, the attacker couldrun the executable and gain root privileges on the system. Anothervariation involves placing a device file somewhere on the filesystemcorresponding with the block device containing the root filesystemand having it be world writable. A smart attacker could use that tomodify files from the backside, and create security holes that couldlater be compromised.

Use of the noexec, nosuid, and nodev options can offer protectionfrom this attack. At a minimum, the nosuid and nodev options shouldbe on the floppy, CD-ROM and other removable media configurationlines in the /etc/fstab file.

8-3

NFS Properties

NFS version 2 and 3• Place trust at the host level• Protection of files is performed by the client host by examining

UID/GID of files on NFS export and comparing it to local usersEvil or compromised root account on client can access all filesexported by server

NFS version 4• Supports GSSAPI and server side enforcement of strong user

authenticationAttacker can use writable NFS export to place executable files on theserver

NFS Replacements

Invented by Sun Microsystems, NFS is the native network file sharingmechanism for Unix systems. Historically, the security of NFS v2/3has been built on the assumption of unified administrative control ofall clients and servers. An attacker who takes over a client machine orbrings a laptop into an NFS environment can have complete accessto all files exported by the NFS server.

The first step in securing NFS is to use NFSv4. NFS v4 is a secure,Kerberized version of NFS that authenticates the remote users on theclient host and performs access controls on the server.

The SUID root Shell NFS Attack

If an attacker has a normal user shell account on an NFS server, androot access on an NFS client, it is possible that an attacker cansubvert and gain root access on the server. The attacker copies aSUID root shell to the remotely mounted NFS share. Then theattacker logs in to his normal user account via telnet or ssh on theserver and executes the shell, gaining root access.

Some modern shells such as bash address this potential issue byimmediately dropping root rights when launched by any non-rootuser.

Other commonly-used shells such as ksh do not address the SUIDattack so it remains important to take special care when configuringthe server to squash all files created or accessed by root on theclient machines.

8-4

NFS Export Option

The /etc/exports File• Defines shares on server• Access control possible• Additional options available on per exported directory basis

Userid mapping• root_squash (default)• all_squash• no_root_squash

Typical /etc/exports file

File: /etc/exports/rootfs/netbsd zulu(rw,no_root_squash)/proj mis*.example.com(rw)/usr *.local.domain(ro) @trusted(rw)/home kiosk(rw,all_squash,anonuid=150,anongid=100)/pub (ro,insecure,all_squash)/distros *(ro)

As shown in the example, many options are available when exportingfilesystems via NFS. Careful use of options can greatly increasesecurity.

Client(OPTS)

The first parameter is the client list. It can be specified via an IPaddress, hostname or network with /XX netmask. Wildcards can beused, often times in conjunction with DNS domain names. NISnetgroups can be specified with an @ sign.

Root Squashing

To prevent the SUID shell attack, normally all client access as rootare remapped to a different UID/GID. This different UID/GID can bedefined with the anonuid and anongid options. In rare cases whereyou don't want the remapping to occur, you can specifyno_root_squash. All remote access can be squashed with theall_squash option.

Allowing NAT clients to connect

The insecure option allows access from clients sourced from highport numbers. This is useful to allow clients who are behind NATboxes.

8-5

NFSv4 and GSSAPI Auth

New NFS Protocol Design• Single TCP port for all traffic 2049• Single exported filesystem – "pseudo filesystem"• First Linux NFS protocol to support GSSAPI/Kerberos auth• Solves NFS security problems

New Additional Daemons• Server – rpc.idmapd / rpc.svcgssd• Client – rpc.idmapd / rpc.gssd

Available in RHEL6/SLES11

The NFSv4 Protocol Improvements

The NFS protocol has been improved and revised several times sinceits original inception. The fourth version introduces several newfeatures and has been highly anticipated.

Some of the notable new features include the operation of all RPCprotocols over TCP port 2049. This simplifies the firewalling,tunneling, and network address translation of the NFS protocol.

A Linux NFSv4 server exports a single pseudo filesystem that theclients see as /. The server administrator chooses a single directoryon its filesystem to be the top level of the NFSv4 pseudo filesystem.If directories outside of that directory tree need to be exported thenthey must be bind mounted into that directory tree.

One problem that has caused trouble for NFS over the years is thefact that it communicates raw UID and GID numbers over the wire. Ifthere are three users: dax, bailey, and sydney and the accounts existon both the NFS server and client but were created in a differentorder so that the UIDs and GIDs don't match up then sharing files viaNFS will be problematic. The files will show up as the wrong usersand groups. The usual solution is to enforce UIDs and GIDs to matchvia manual validation or the use of a directory service such as NIS orLDAP. NFSv4 solves this problem by sending actual username andgroupname strings over the wire instead of numerical UIDs/GIDs. Thisway as long as the same users and group exists, then file sharing willwork as expected. This is akin to how Windows CIFS operates.

On Linux, NFSv4 is the first NFS version to support GSSAPI/Kerberosauthentication. This provides strong host and user authenticationkeeping unauthorized computers and users away from NFS shareddata. Only computers within a Kerberos realm that have thenfs/[email protected] principal in their local keytab can mount designatedshares from the NFS server. Additionally users can only access fileson the NFS server if they have a TGT and service ticket. This preventsa compromised or malicious root user from switching to a user'saccount while they are not logged in and accessing the user's files onthe NFS server.

Additionally GSSAPI enables integrity checked and encrypted NFStraffic.

New NFSv4 Daemons

NFSv4 transmits usernames and groups across the wire thatultimately must be mapped back to the actual UID and GID of thatuser and group. This mapping is handled by a new daemon,rpc.idmapd. It must be running on both the client and server. It has aconfiguration file /etc/idmapd.conf where settings can be adjusted ifthe normally suitable defaults aren't sufficient.

When using NFSv4 with GSSAPI authentication additional daemonsmust be running on the client and server to link transactions tospecific GSSAPI credentials. The server daemon is rpc.svcgssd andthe client is rpc.gssd. These are only required if GSSAPIauthentication is being used.

8-6

Implementing NFSv4

NFSv4 Server pre kernel 2.6.33 and nfs-utils v1.2.2• NFSv4 exports require the fsid=0 export option• rpc.idmapd running

NFSv4 Server post kernel 2.6.33+ and nfs-utils v1.2.2+• All shares in /etc/exports shared v2/v3/v4• pseudo-root automatically created if fsid=0 not used• rpc.idmapd running

NFSv4 Client• Must use -t nfs4 option to mount command

Default with nfs-utils v1.2.2+• Mount pseudo-root (/) from server or sub directory• rpc.idmapd running

NFSv4 Behavior Change

How to deploy and use NFSv4 on Linux has changed significantly.With Linux kernel 2.6.32+ and nfs-utils 1.2.2+ NFSv4 is nowtreated and administered just like NFSv2/v3. In this text, "ModernNFSv4" referes to this updated behavior, while "Historical NFSv4"refers to the previous behavior.

Deploying NFSv4

NFSv4 doesn't require the traditional RPC daemons such asrpc.statd, rpc.mountd, rpc.rquotad, and rpc.lockd to be running.However, it is helpful to have rpc.mountd running so that showmount-e works from the clients.

NFSv4 introduces a new requirement of rpc.idmapd. Make sure thatit is started on both the client and server.


RHEL6 uses the SysV init script (/etc/init.d/nfs) to control NFSserver services. The rpc.idmapd daemon is controlled by the/etc/init.d/rpcidmapd script.


SLES11 uses a single unified SysV init script(/etc/init.d/nfsserver) to control NFS server services. Therpc.idmapd daemon will be started by this script if the/etc/sysconfig/nfs file contains the NFS4_SUPPORT="yes" configstatement (the default).

Historical NFSv4 Exports

A single NFSv4 export, the pseudo-root, is created by adding a line tothe /etc/exports file in this form:

File: /etc/exports+ /srv/export *(rw,fsid=0,no_subtree_check,async)

The key option is fsid=0, which designates the share as the top levelof the NFSv4 pseudo filesystem.

Modern NFSv4 Exports

With modern NFSv4, all shares listed in /etc/exports will be sharedwith all three NFS protocol versions, 2, 3, and 4. A pseudo-rootfilesystem may also be manually defined as before, but this is nolonger commonly done. When not manually defined, a pseudo-rootfilesystem will be automatically created that shares the actual /filesystem. Security is maintained as only the specific shareddirectories are visible in the pseudo-root filesystem.

Historical NFSv4 Mounting

From the client perspective, mounting an NFSv4 export is nearly thesame as mounting any NFS export. The one difference is that thefilesystem type must be specified as nfs4 (including in /etc/fstab),otherwise an NFSv3 or v2 mount request will occur:

# mount -t nfs4 server:/ /mnt

8-7

Modern NFSv4 Mounting

From the client perspective, mounting an NFSv4 export is exactly thesame as v3 or v2. The system will attempt a v4 mount first, and thenfallback to a v3 and v2 attempt if failure occurs. With modern NFSv4behavior, v4 shares can exist outside the pseudo-root filesystem andthose are typically mounted directly:

# mount server:/srv/export /mnt

8-8

Implementing Kerberos with NFS

GSSAPI/Kerberos Requirements• NFSv3 or NFSv4• Additional export and mount options• Proper Kerberos principals created and RPC GSS daemons

running on client and server

Enabling Secure NFSv4 with GSSAPI/Kerberos Authentication

All NFS server and clients in a realm should have an nfs/[email protected] principal created and installed in the /etc/krb5.keytab fileon each system. A computer doesn't need such a principal created ifit will not be doing NFS.


Enable the starting of the gss server and client daemons(rpc.svcgssd and rpc.gssd respectively) by first editing or creatingthe /etc/sysconfig/nfs file and adding the line:

File: /etc/sysconfig/nfs+ SECURE_NFS=yes


Enable the starting of the gss server and client daemons(rpc.svcgssd and rpc.gssd respectively) by first editing or creatingthe /etc/sysconfig/nfs file and adding the line:

File: /etc/sysconfig/nfs+ NFS_SECURITY_GSS="yes"

Launch Necessary Daemons on Server

Next it's necessary to launch the daemons with their SysV init scripts.First start the services on the server:


# service rpcidmapd start. . . output omitted . . .# service rpcsvcgssd start. . . output omitted . . .# service nfs start. . . output omitted . . .


# service nfsserver start. . . output omitted . . .

Launch Necessary Daemons on client

Next, the client-side daemons must be started with their SysV initscripts:


# /etc/init.d/rpcidmapd start. . . output omitted . . .# /etc/init.d/rpcgssd start. . . output omitted . . .


# service nfs start. . . output omitted . . .

8-9

Configuring the Server Exports

On the server, special export syntax must be used in /etc/exports.For example:

File: /etc/exports+ /dir1 gss/krb5(rw,fsid=0,no_subtree_check,sync)+ /dir2 gss/krb5i(rw,fsid=0,no_subtree_check,sync)+ /dir3 gss/krb5p(rw,fsid=0,no_subtree_check,sync)

y The first line requires Kerberos host and user authentication.y The second line allows integrity checking of all traffic to be

enabled.y The third line allows encryption of all traffic to be enabled.

If you wanted Kerberos authentication, integrity checking, andencryption to be required, then you would only list the last line. Notethat you currently cannot limit connections by IP address; however,only computers within the Kerberos realm will be able to mount theexport. Using IP Tables to firewall port 2049 can overcome this exportsyntax limitation.

Mount Shares on the Client

When the server has been properly configured and exported anynumber of directories over NFS, client machines are able to view theserver's export list. The export list is a list of available NFS sharesdetailing the mount options available per each client. The export listcan be obtained using the showmount command:

# showmount -e stationYExport list for stationY:/export gss/krb5i. . . output omitted . . .

On the client, special options must be passed to the mountcommand to indicate which Kerberos mode to use when mounting.The modes correspond with the three available export options on theserver. Again, note that the server doesn't have to offer all three.

The option that must be used is -osec=mode. Consider the followingthree examples:

# mount -t nfs4 -osec=krb5 server:/ /mnt/server# mount -t nfs4 -osec=krb5i server:/ /mnt/server# mount -t nfs4 -osec=krb5p server:/ /mnt/server

There is also a kernel requirement on both the server and client thatmust be satisfied before starting this process. The rpcsec_gss_krb5kernel module must be loaded. If this kernel module isn't loaded (orcompiled into the kernel) then the gss daemons will not start.


In RHEL6, the /etc/init.d/rpcgssd init script is responsible forchecking to see if the rpcsec_gss_krb5 kernel module is alreadyloaded, and if it's not, loads it.

8-10

GPG – GNU Privacy Guard

Encrypting and decrypting filesSignaturesConfigurationAgents

GPG and Public/Private Key Pairs

Using asymmetric encryption in GPG requires the generation of apublic/private key pair. A file encrypted with one key can only bedecrypted with the other key from the pair.

To generate a key pair use the following command:

$ gpg --gen-key

After answering a few questions, the key pair will be generated. thiskey pair will be used to encrypt, decrypt, and sign messages.

Encrypting files is accomplished by gpg with the -e option:

$ gpg -e filename

This command asks for a public key of the user for which the file willbe encrypted. The encrypted file by default will be namedfilename.gpg

GPG and Symmetric Encryption

GPG can also use symmetric encryption. Symmetric encryption usesthe same key or passphase for both encryption and decryption. Sincesymmetric encryption puts all the security in the passphase, a strongpassphrase must be used. One of the downsides to symmetricencryption is the difficulty in securely sharing the passphrase with theintended recipient.

To encrypt a file using symmetric encryption use this command:

$ gpg -c filename

This command will ask for a passphrase to encrypt the file with. Oncethe passphrase has been entered twice, the resulting file will benamed filename.gpg. Note that the source file is not modified orremoved.

Decrypting Files

If a file has been encrypted using a public key, then the private keywill be required for decrypting the file. If a file was encrypted using apassphrase the passphrase will be required for decryption. Thefollowing command can be used to decrypt files:

$ gpg -d filename

The file will by default be decrypted to STDOUT. To override thisfunctionality, the option -o filename can be used.

8-11

GPG Signatures

A benefit of using asymmetric encryption is the ability to generatedigital signatures. When a file is encrypted with a user's private key,the only key that will decrypt the file is that user's correspondingpublic key. If someone can decrypt a file with that user's public key,they are assured it came from that user (assuming that user's privatekey remains secure). The secrecy and protection of private keys isparamount.

Signing a file is done with this command:

$ gpg -s filename

The resulting file will have been encrypted with your private key,making it difficult to read. A clear text signature can be created withthis command:

$ gpg --clearsign filename

Verifing a Signature

When you decrypt a document the signature is automatically verifiedand you will be warned the signature isn't valid. To verify thesignature only without decrypti

GL550 Enterprise Linux Security Administration › docs › 1-37-00015-000-01-22-13 › ... · NTP...

Documents

Transcript of GL550 Enterprise Linux Security Administration › docs › 1-37-00015-000-01-22-13 › ... · NTP...

ARMORED 2014 MERCEDES-BENZ GL550 4MATIC SUV ......ARMORED 2014 MERCEDES-BENZ GL550 4MATIC SUV VIN:4JGDF7DE4EA302130 The Premium Warranty offered by Alpine Armoring on this vehicle

Configuring the SELinux Policy - NSA.gov · Configuring the SELinux Policy greater efficiency, the policy enforcement code of SELinux typically handles security identifiers (SIDs)

Manual Ntp

Conﬁguring use case models in product families

Security Guide - SUSE Linux Enterprise Server 15 SP1€¦ · Configuring a NIS Master Server 20 • Configuring a NIS Slave Server 25 3.2 Configuring NIS Clients 26 4 Setting Up

Introduction to Policy-Based Routing Conﬁguring …ptgmedia.pearsoncmg.com/imprint_downloads/cisco/bookreg/...Conﬁguring Policy-Based Routing 7 The set ip default next-hop ip-address

NTP Brochure

Conﬁguring and Troubleshooting Hardware Devices …ptgmedia.pearsoncmg.com/images/0735709688/samplechapter/073570… · OBJECTIVES CHAPTER 3 Conﬁguring and Troubleshooting Hardware

A Systematic Method for Conﬁguring VLSI Networks …ncs.ethz.ch/pubs/pdf/Neftci_etal11.pdfARTICLE Communicated by Ralph Etienne-Cummings A Systematic Method for Conﬁguring VLSI

Conﬁguring MDaemon for Centralized Spam Blocking and Filteringforum.uranus.com.vn/Resource/Documents/Mdaemon_ConfiguringFor... · Conﬁguring MDaemon for Centralized Spam Blocking

Configuring and Troubleshooting Hardware Devices and Drivers · “Configuring and Troubleshooting Hardware Devices and Drivers”: Configure hardware devices.. This objective

NTP 334.009

Ntp Slides

Conﬁguring Ethernet Interfaces

NTP Syllabus

Installing, Conﬁguring, and Running the Open edX Platform ... · Installing, Conﬁguring, and Running the Open edX Platform - Dogwood Release, Release •Subscribe to announcements

NTP Associate Director’s Report · 2020-07-20 · NTP Associate Director’s Report Brian R. Berridge, DVM, PhD, DACVP NTP Associate Director. Scientific Director, Division of NTP.

Manually Conﬁguring Outlook 2013 for Hosted Exchange 2016

Configuring NTP · Configuring NTP ThischapterdescribeshowtoconfiguretheNetworkTimeProtocol(NTP)onCIscoMDS9000Family switches. • InformationAboutNTP,page1 • PrerequisitesforNTP,page3