Download - GL550 Enterprise Linux Security Administration › docs › 1-37-00015-000-01-22-13 › ... · NTP Clients 10 Conﬁguring NTP Clients 12 Conﬁguring NTP Servers 14 Securing NTP

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 root@stationYroot@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 root@stationY

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

station4$ ssh root@station2

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→ Simplify

If 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 (<CTRL>+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 Õ[guru@stationY 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/FQDN@REALM 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/FQDN@REALMKerberos 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 decrypting the document, the followingcommand can be used:

$ gpg --verify filename

Configuration

The gpg command creates and uses the ~/.gnupg directory. Most ofthe files in the directory are binary (and most are encrypted). Thesecan only be modified using the appropriate gpg options. However, the~/.gnupg/gpg.conf is text and can be edited to match personalpreferences.

All settings found in ~/.gnupg/gpg.conf are the same as thelong-options as specificed in the gpg man page, without the leading--. Common settings to add to your ~/.gnupg/gpg.conf include:

File: ~/.gnupg/gpg.conf # Set the default key to be used, # useful if you have multiple keypairs.+ default-key name # Turn off the copyright notice+ no-greeting # if using a keyserver it can be listed here.+ keyserver hkp://subkeys.pgp.net

Other files commonly found in the ~/.gnupg/ directory:

secring.gpg ⇒ The secret keyring. You should backup this file.pubring.gpg ⇒ The public keyring. You should backup this file.trustdb.gpg ⇒ The trust database.

Using GPG-Agent

When using public/private key pairs having to retype your passphraseconstantly becomes an annoyance. gpg-agent is a long runningdaemon that will silently cache your passphase in the backgroundand supply it to gpg as needed. Starting gpg-agent can be done withthis command:

$ eval $(gpg-agent --daemon)

To have gpg-agent start automatically when you login to X you canadd the previous example to your ~/.xsession file. If you are notrunning X, you can have gpg-agent started by adding the following toyour ~/.bash_profile file:

$ gpg-agent --daemon --enable-ssh-supporta--write-env-file "${HOME}/.gpg-agent-info"

8-12

File Encryption with OpenSSL

OpenSSL—Secure Sockets Layer• uses many different key mechanisms• can use symmetric or asymmetric keys• also functions as a network SSL tool

OpenSSL

OpenSSL originally was a library for encrypting data being sent oversome type of network connection; it has since been extended toencrypt files using a symmetric algorithm. The openssl tool in Linuxsupports a number of encryption ciphers.

Encrypting Files

To encrypt a file using openssl the following enc function can beused:

# openssl enc -bf -a -in inputfile -out outputfile

The options:

enc ⇒ use the encryption function of OpenSSL-bf ⇒ use the BlowFish encryption algorithm-a ⇒ use base64 encoding

To obtain a list of supported algorithms, run:

# openssl enc -h

Since the blowfish cipher is symmetric, it is not necessary togenerate a key pair.

Decrypting Files

To decrypt a file using openssl the enc function can also be usedwith the -d option:

# openssl enc -d -bf -a -in inputfile -out outputfile

SSL Network client

openssl as it was originally designed also works as an ssl client orserver. This functionality can be useful in troubleshooting problematicssl servers. To connect to a ssl port on a server the s_clientfunction can be used:

# openssl s_client -host www.gurulabs.com -port 443CONNECTED(00000003)depth=0 /C=US/ST=Utah/L=West Bountiful/O=Guru Labs L.C./CN=a

www.gurulabs.com/[email protected]=0 /C=US/ST=Utah/L=West Bountiful/O=Guru LabsL.C./CN=www.gurulabs.com/[email protected] return:1---Certificate chain 0 s:/C=US/ST=Utah/L=West Bountiful/O=Guru LabsL.C./CN=www.gurulabs.com/[email protected]. . . output omitted . . .

8-13

File Encryption With encfs

FUSE encfs• Encrypts files, not file systems• User space tool, not requiring root

encfs

encfs is a cryptographic filesystem in user-space for Linux. Thebenefit is that it works on files, not filesystems. Seehttp://www.arg0.net/encfs.

One interesting use of the encfs filesystem is to have a singlebackend directory containing sets of files that have been encryptedwith different passwords. In this case, the same backend directorycan even be mounted simultaneously at different mount points, oreven by different users, exposing at each mount point only the set offiles encrypted by the corresponding password.

The following example shows creating and then mounting a newencrypted backend directory and populating it with a file. Note thatsince it is normally not useful to directly access the encrypted files inthe backend directory it is often created as a hidden directory asshown here:

$ encfs ~/.crypt-backend ~/cryptThe directory "/home/bcroft/.crypt-backend/" does nota

exist. Should it be created? (y,n) yThe directory "/home/bcroft/crypt" does not exist.a

Should it be created? (y,n) yCreating new encrypted volume.Please choose from one of the following options: enter "x" for expert configuration mode, enter "p" for pre-configured paranoia mode, anything else, or an empty line will select standard mode.

?> pParanoia configuration selected.Configuration finished. The filesystem to be created hasthe following properties:Filesystem cipher: "ssl/aes", version 2:2:1. . . output omitted . . .New Encfs Password: secretpassword ÕVerify Encfs Password: secretpassword Õ$ echo "This will be encrypted" > crypt/private$ ls -l crypt/private-rw-rw-r--. 1 bcroft bcroft 23 2010-02-22 14:35 crypt/private$ fusermount -u crypt/$ ls -l crypt/total 0$ ls -l .crypt-backend/total 4-rw-rw-r--. 1 bcroft bcroft 39 2010-02-22 14:35a

qP-wkQ7WXqLhsP3q21YrjIj2


This package is available since RHEL5 through the Extra Packages forEnterprise Linux (EPEL) repository.


openSUSE includes encfs. SUSE Linux Enterprise Server does notinclude the encfs package. However, it can be added through theopenSUSE Build Service.

8-14

Linux Unified Key Setup (LUKS)

What is LUKS?Why LUKS?Using LUKS• BACKUP YOUR DATA!• dm-crypt and cryptsetup• /etc/crypttab

What is LUKS?

LUKS is a standard format for disk encryption in Linux. LUKS-on-diskis not only compatible among most distributions, it also providessecurity of data with simplicity. One major benefit is that LUKS storessetup information in the partition header, which allows for bettersecurity as well as seamless migration of data.

Why LUKS?

LUKS-on-disk format has several benefits with regard to security:

y The ability to revoke a passphrase/keyfile (without having tore-encrypt data)y Defends from low entropy attacksyMulti-keyfile/passphrase supporty Currently available in many Linux distributions

The LUKS-on-disk format is built upon the kernel device mapper andimplemented by the dm-mod and dm-crypt kernel modules. Whenpassed the proper options, dmsetup can be used directly to create anencrypted block device. The cryptsetup command was introduced tomake creating and managing encrypted devices easier and has beenextended to support LUKS.

Preparing Drives

If the drive has ever been used in the past and contained sensitivedata it should be erased. With modern hard drives, a quick pass ofwriting zeros to the entire drive should be sufficient. For older drives,or SSD drives, several passes are recommended.

# dd if=/dev/zero of=/dev/vg_s1/crypt_lv #fill with zeros# shred -v -z -n 25 /dev/vg_s1/crypt_lv #25 passes of data

Depending on the level of plausible deniability needed, the blockdevice should then be filled with random data. This data can then beencrypted to further hide patterns that may appear in thepseudo-random data (frustrating cyrptographic analysis).

# dd if=/dev/urandom of=/dev/vg_s1/crypt bs=4096

Initializing LUKS

cryptsetup initializes the partition and sets up the passphrase. Inaddition, it will create and set up dm-crypt managed device-mappermappings to make management of the encrypted device easier.cryptsetup can set up, remove, add, or change keyfiles and keyphrases; it's also used to open and close the encrypted device.

# cryptsetup --verify-passphrase luksFormat /dev/vg_s1/crypt_lv

WARNING!========This will overwrite data on /dev/vg_s1/crypt_lv irrevocably.

Are you sure? (Type uppercase yes): YESEnter LUKS passphrase: passphrase ÕVerify passphrase: passphrase Õ

Using cryptsetup with the luksOpen option will open the LUKSdevice and set up a mapping to a particular name. The passphrase

8-15

will be verified.

# cryptsetup luksOpen /dev/vg_s1/crypt_lv cryptEnter passphrase for /dev/vg_s1/crypt_lv: passphrase Õ

A successful luksOpen command will cause the kernel device mapperto create a new block device with the specified name.

Creating and Mounting the Encrypted Filesystem

To create a new filesystem on the device and make it mountautomatically on boot:

# mkfs -t ext4 -L crypt /dev/mapper/cryptmke2fs 1.41.12 (17-May-2010)Filesystem label=crypt. . . snip . . .# echo "crypt /dev/vg_s1/crypt_lv" >> /etc/crypttab# echo "/dev/mapper/crypt /data/crypt ext4 defaults 1 2" >> /etc/fstab

When the system boots, the user will be prompted for a passphrasewhich, if given correctly, will unlock the filesystem.

8-16


S11: 85 minutesTask 1: Securing FilesystemsPage: 8-17 Time: 10 minutesRequirements: b (1 station)

Task 2: Securing NFSPage: 8-21 Time: 20 minutesRequirements: bb (2 stations)

Task 3: Implementing NFSv4Page: 8-25 Time: 30 minutesRequirements: bb (2 stations)

Task 4: File Encryption with GPGPage: 8-33 Time: 5 minutesRequirements: b (1 station)

Task 5: File Encryption With OpenSSLPage: 8-37 Time: 5 minutesRequirements: b (1 station)

Task 6: LUKS-on-disk format Encrypted FilesystemPage: 8-40 Time: 15 minutesRequirements: b (1 station)

8-17

ObjectivesyModify filesystem mounting options to increase system security


RelevanceWhen access to the filesystem of a system is given, additional security atthe filesystem level should be considered. One way this can beaccomplished is by mounting different parts of the filesystem withdifferent options. Some options might include noexec (nothing executablecan be run within the filesystem), nodev (character and block specialdevices aren't honored), and ro (the filesystem is set to read-only.)

Lab 8

Task 1Securing FilesystemsEstimated Time: 10 minutes



[R6] This step should only be performed on RHEL6.2)Examine the existing partitioning and filesystem layout:

# dfFilesystem 1K-blocks Used Available Use% Mounted on/dev/mapper/vg_stationX-lv_root 2064208 223248 1736104 12% /tmpfs 1555132 88 1555044 1% /dev/shm/dev/sda1 495844 29034 441210 7% /boot/dev/mapper/vg_stationX-lv_tmp 1032088 34096 945564 4% /tmp/dev/mapper/vg_stationX-lv_usr 4128448 1915068 2003668 49% /usr/dev/mapper/vg_stationX-lv_var 1032088 126364 853296 13% /var

[S11] This step should only be performed on SLES11.3)Examine the existing partitioning and filesystem layout:

8-18

# dfFilesystem 1K-blocks Used Available Use% Mounted on/dev/sda5 2071384 245660 1720500 13% /devtmpfs 1523428 112 1523316 1% /devtmpfs 1523428 88 1523340 1% /dev/shm/dev/sda1 101086 29845 66022 32% /boot/dev/sda8 303344 10297 277386 4% /tmp/dev/sda3 6198436 2215040 3668524 38% /usr/dev/sda6 1517920 113800 1327012 8% /var/dev/sda2 10325780 154268 9646992 2% /var/lib/xen

Examine the default mounting options in place. Note that the strategy in use4)allows for a number of security enhancing techniques to be used:

Look at the mounting options for each mount pointlisted (column 4).

# cat /etc/fstab. . . output omitted . . .

Backup the /etc/fstab so changes can be reverted at the end of the lab task:5)

# cp /etc/fstab /etc/fstab.bak

[R6] This step should only be performed on RHEL6.6)Use your favorite editor to modify the contents of the /etc/fstab file. Locateeach of the lines shown below, and modify the mounting options, changing thedefaults to those indicated:

File: /etc/fstab- UUID=c868419e-75fc-4b77-a188-3c57a21d2f7f /boot ext4 defaults 1 2+ UUID=c868419e-75fc-4b77-a188-3c57a21d2f7f /boot ext4 nodev,nosuid 1 2- /dev/mapper/vg_stationX-lv_tmp /tmp ext4 defaults 1 2+ /dev/mapper/vg_stationX-lv_tmp /tmp ext4 noexec,nodev,nosuid 1 2- /dev/mapper/vg_stationX-lv_usr /usr ext4 defaults 1 2+ /dev/mapper/vg_stationX-lv_usr /usr ext4 ro,nodev 1 2- /dev/mapper/vg_stationX-lv_var /var ext4 defaults 1 2+ /dev/mapper/vg_stationX-lv_var /var ext4 noexec,nodev 1 2 /dev/mapper/vg_stationX-lv_swap swap swap defaults 0 0- tmpfs /dev/shm tmpfs defaults 0 0+ tmpfs /dev/shm tmpfs noexec,nodev,nosuid 0 0

8-19

[S11] This step should only be performed on SLES11.7)Use your favorite editor to modify the contents of the /etc/fstab file. Locateeach of the lines shown below, and modify the mounting options changing thedefaults to those indicated:

File: /etc/fstab- UUID=395a623f-64f2-492f-b72a-4401c506f533 /boot ext3 acl,user_xattr 1 2+ UUID=395a623f-64f2-492f-b72a-4401c506f533 /boot ext3 acl,user_xattr,nodev,nosuid 1 2- UUID=8a39aa59-df38-4c25-9da8-4e4b06d80a02 /tmp ext3 acl,user_xattr 1 2+ UUID=8a39aa59-df38-4c25-9da8-4e4b06d80a02 /tmp ext3a acl,user_xattr,noexec,nodev,nosuid 1 2- UUID=3ec94de0-4c70-4e5c-9855-271759516c89 /usr ext3 acl,user_xattr 1 2+ UUID=3ec94de0-4c70-4e5c-9855-271759516c89 /usr ext3 acl,user_xattr,ro,nodev 1 2- UUID=344c5acf-c754-4659-badc-91f15a9be57b /var ext3 acl,user_xattr 1 2+ UUID=344c5acf-c754-4659-badc-91f15a9be57b /var ext3 acl,user_xattr,noexec,nodev 1 2- UUID=be1b8777-10f4-4cbc-8b4a-78a380795fd0 /var/lib/xen ext3 acl,user_xattr 1 2+ UUID=be1b8777-10f4-4cbc-8b4a-78a380795fd0 /var/lib/xen ext3a acl,user_xattr,nosuid,noexec,nodev 1 2

Remount the modified filesystems so the changes take effect:8)

# for i in /tmp /usr /varÕ> do mount -o remount $iÕ> doneÕ

Try a few quick tests to verify that the new mount options are functioning:9)

# touch /usr/testfileFail because /usr/ is now mounted read-only.touch: creating `/usr/testfile': Read-only file system

# cp /bin/bash /tmp# /tmp/bash

Fails because /tmp/ is mounted noexec.-bash: /tmp/bash: Permission denied# mknod -m 777 /var/disk b 3 0# strings /var/disk

Fails because /var/ is mounted nodev.strings: /var/disk: Permission denied

Since all filesystems that are writable to normal users are now mounted noexec,even if a user downloads and compiles a program, it will not run. Even better, if

8-20

an attacker is able to compromise a user's account, the attacker will not be ableto download and run exploits or other programs.

Cleanup

Cleanup so that future lab tasks are not impacted:10)

# mv -f /etc/fstab.bak /etc/fstab

Remount the modified filesystems so the cleanup changes take effect:11)

# for i in /tmp /usr /varÕ> do mount -o remount $iÕ> doneÕ

8-21

Objectivesy Create an NFS export with a potential security problemy Secure the NFS share

Requirementsbb (2 stations)

RelevanceNFS is a way to share files across the network. In doing so, caution mustbe taken with the options that are given to the directories that are shared.Suppose that you have root access on your own station, but not on theNFS server. If an unprivileged account is accessible on the remote NFSserver, and given insecure settings on the export, access can be easilygained on the NFS server by running the appropriate commands.

Lab 8

Task 2Securing NFSEstimated Time: 20 minutes

Create a directory to be shared via NFS:1)

# mkdir -p /export/insecure

Add the following line to /etc/exports to share the /export/insecure directory:2)

File: /etc/exports+ /export/insecure 10.100.0.0/24(no_root_squash,rw,sync)

Start the NFS server:3)

# service nfs start[R6]

Starting NFS services: [ OK ][R6]

Starting NFS quotas: [ OK ][R6]

Starting NFS daemon: [ OK ][R6]

Starting NFS mountd: [ OK ][R6]

# service nfsserver start[S11]

. . . snip . . .[S11]

mountd statd nfsd sm-notify done[S11]

Wait until your lab partner reaches this point before proceeding.4)

8-22

Mount the filesystem being exported by your lab partner's system:5)If you do not see the export in the list, then work withyour lab partner to isolate and fix the fault in theirexported filesystem.

# showmount -e 10.100.0.YExport list for 10.100.0.Y:/export/insecure 10.100.0.0/24

Create a directory and mount the NFS share of stationY:6)

# mount 10.100.0.Y:/export/insecure /mnt/

Create a root owned SUID editor on the remote station:7)

# cp /usr/bin/vim /mnt/# chmod u+s /mnt/vim# ls -l /mnt/total 2088-rwsr-xr-x 1 root root 2132744 May 13 13:49 vim

Execute the exploit:8)

# ssh [email protected]: work ÕLast login: Tue Oct 21 15:43:07 2008 from stationX.example.com

You could then modify your guru UID to be zero, or addanother backdoor account, etc. Carefully exit vim byrunning :q!

$ /export/insecure/vim /etc/passwd

Log back out of the remote system:9)

# exit. . . output omitted . . .


Disconnect from the remote NFS share:11)

# umount /mnt/

8-23

Create a new more secure share:12)

# mkdir /export/secure# chmod 1777 /export/secure

Edit the /etc/exports and change the mounting options:13)

File: /etc/exports- /export/insecure 10.100.0.0/24(no_root_squash,rw)+ /export/secure 10.100.0.0/24(rw,sync)

Reload the NFS daemons:14)

# service nfs reload[R6]

# service nfsserver reload[S11]

. . . output omitted . . .[S11]

# showmount -e localhostExport list for localhost:/export/secure 10.100.0.0/24


Now that your lab partner has setup the new secure export, mount it and verify16)that the exploit done in step 8 will no longer work. Because the new share hasthe root_squash option (default), all writes as UID 0 will be remapped to UID65534 (the NFS-Nobody account):

# cd# mount -t nfs -o rw 10.100.0.Y:/export/secure /mnt/# cd /mnt/# touch testfile# ls -l testfile-rw-r--r-- 1 nfsnobody nfsnobody 0 Oct 21 2008 testfile[R6]

-rw-r--r-- 1 nobody nogroup 0 Nov 25 14:27 testfile[S11]

8-24

Bonus

Note that the current state can still be exploited, allowing the NFS server to gain17)root access to the NFS client system (instead of vice-versa as was previouslydemonstrated). Assuming your lab partner has completed the above steps, andhas your /export/secure share mounted, you could place an SUID root ownedbinary in your /export/secure directory and then log in to the NFS client (as guru)and execute it (since they are mounting the share).

Some modern shells such as bash have been designed to address this issue.Upon execution, they immediately drop root privileges if executed by a non-rootuser.

If time permits, work with your lab partner to try the above. The fix to the abovedescribed exploit is for the client to mount the export with more secure options.For example:

# mount -t nfs -o rw,nosuid,nodev 10.100.0.Y:/export/secure /mnt/export/

Now the client won't honor SUID binaries exported by the server, protecting theNFS client from a potentially malicous NFS server.


# exit

8-25

Objectivesy Configure a NFSv4 exporty Setup a NFSv4 share with GSSAPI/Kerberos authenticationy Examine the security properties of the share


RelevanceNFSv4 is easier to firewall, works better over WAN connections, andsupports GSSAPI/Kerberos authentication providing strong host and userauthentication keeping unauthorized computers and users away from NFSshared data. Knowing how to deploy NFSv4 will allow you to reap thebenefits.

Lab 8

Task 3Implementing NFSv4Estimated Time: 30 minutes



This lab task requires two computers in the same Kerberos realm. The following2)users, and Kerberos principals, should exist: usera, userb, and userc. Each usershould have a home directory inside of /srv/home/.

[S11] This step should only be performed on SLES11.3)Install the NFS server, which will be needed later in the lab:

# sudo zypper install -y nfs-kernel-server. . . output omitted . . .

The /srv/ directory will be the top level of the NFSv4 pseudo-filesystem. Create a4)subdirectory in it that is writable by all users, and has the sticky bit set to preventusers from manipulating other user's files:

# mkdir -p /srv/tmp# chmod 1777 /srv/tmp

8-26

As a prerequisite to demonstrating kerberos security later in the lab, modify the5)permissions of exported user home directories to allow full access for eachrespective user, but not for any other user:

# chmod 700 /srv/home/user{a,b,c}

Share the /srv/ directory to the classroom network using NFSv4. Using a text6)editor, add the following line to your /etc/exports file:

File: /etc/exports+ /srv 10.100.0.0/24(fsid=0,rw,no_subtree_check,sync)

Restart the standard NFS daemons as well as the new NFSv4 required7)rpc.idmapd:

# service nfs restart[R6]

. . . output omitted . . .[R6]

# service rpcidmapd restart[R6]


# service nfsserver restart[S11]

. . . output omitted . . . [S11]

Wait until the previous steps have been performed on stationY before continuing.8)

[R6] This step should only be performed on RHEL6.9)Mount the NFSv4 pseudo filesystem using NFSv2/3:

# mount -t nfs stationY:/ /mnt/# df -hT | tail -n1stationY:/ nfs 2.0G 230M 1.7G 13% /mnt

[S11] This step should only be performed on SLES11.10)Attempt to mount the NFSv4 pseudo filesystem using NFSv2/3 (this is expected tofail):

8-27

This fails because using NFSv3, the correct path to theexport would instead be stationY:/srv

# mount -t nfs stationY:/ /mnt/mount.nfs: access denied by server while mounting stationY:/# umount /mnt/

Perform the mount again, this time specifying the use of NFSv4:11)

# mount -t nfs4 stationY:/ /mnt/

Verify that the mount was successful using the NFSv4 protocol:12)

# mount | grep nfs4. . . snip . . .stationY:/ on /mnt type nfs4 (rw,addr=10.100.0.Y,clientaddr=10.100.0.X)

Unmount the NFSv4 share in preparation for re-configuring it to require13)GSSAPI/Kerberos authentication:

# umount /mnt

[R6] This step should only be performed on RHEL6.14)Configure the system so that the NFS init script will start the needed additionaldaemons:

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

When using NFSv4 with GSSAPI/Kerberos authentication, additional daemonsmust be started. These daemons pass authentication credential information to thekernel.

[S11] This step should only be performed on SLES11.15)Enable launching the idmapd and rpc.gssd daemons for NFSv4 mounts notconfigured in /etc/fstab:

File: /etc/sysconfig/nfs- NFS_START_SERVICES=""+ NFS_START_SERVICES="yes"

8-28

[S11] This step should only be performed on SLES11.16)Configure the system so that the NFS init script will start the needed additionaldaemons:

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

When using NFSv4 with GSSAPI/Kerberos authentication, additional daemonsmust be started. These daemons pass authentication credential information to thekernel.

Before starting the daemons, verify that the nfs/FQDN@REALM Kerberos principal17)has been installed in the local keytab:

# klist -kte /etc/krb5.keytab. . . snip . . . 2 10/13/11 11:49:38 nfs/[email protected] (DES cbc mode with CRC-32)

rpc.svcgssd should be started on servers and rcp.gssd should be started on18)clients. Since your computer will be serving both roles, start them both:

# service rpcgssd start[R6]


# service rpcsvcgssd start[R6]


# service nfsserver restart[S11]

. . . output omitted . . .[S11]

# service nfs start[S11]

. . . output omitted . . . [S11]

Modify the NFSv4 share in the /etc/exports file so that GSSAPI/Kerberos19)authentication with integrity checking is required:

File: /etc/exports- /srv 10.100.0.0/24(fsid=0,rw,no_subtree_check,sync)+ /srv gss/krb5i(fsid=0,rw,no_subtree_check,sync)

8-29

Reexport all directories:20)

# exportfs -r

Wait until the previous steps have been performed on stationY before continuing.21)

Attempt to mount the remote share without specifying GSSAPI/Kerberos22)authentication (expecting it to fail):

# mount -t nfs4 stationY:/ /mnt/mount.nfs4: access denied by server while mounting stationY:/

Try again, this time using the -osec=krb5 option to specify GSSAPI/Kerberos23)authentication (still expecting an error):

# mount -t nfs4 -osec=krb5 stationY:/ /mnt/mount.nfs4: mounting stationY:/ failed, reason given by server: No such file or directory

It still doesn't work—the server export requires integrity checking. Try again with24)the security properties the server requires:

# mount -t nfs4 -osec=krb5i stationY:/ /mnt/

The mount succeeds. Note that this would not succeed if the client machinedidn't have a NFS kerberos principal in its keytab. Only members of the Kerberosrealm are able to mount the filesystem.

Create a file and verify that it appears:25)

# echo "randomdata" > /mnt/tmp/file.txt# ls -al /mnt/tmptotal 24drwxrwxrwt 2 root root 4096 Dec 23 17:18 .drwxr-xr-x 4 root root 4096 Dec 23 16:41 ..-rw-r--r-- 1 nfsnobody nfsnobody 11 Dec 23 17:18 file.txt[R6]

-rw-r--r-- 1 nobody nobody 11 Dec 23 17:18 file.txt[S11]

8-30

The exported directory structure contains directories only accessible to their26)GSSAPI authenticated owners. Try to examine the directories as root:

# ls -al /mnt/home/total 48drwxr-xr-x 6 root root 4096 Dec 23 16:14 .drwxr-xr-x 4 root root 4096 Dec 23 16:41 ..drwx------ 2 testuser testuser 4096 Dec 23 15:34 testuserdrwx------ 2 usera usera 4096 Dec 23 16:14 useradrwx------ 2 userb userb 4096 Dec 23 16:14 userbdrwx------ 2 userc userc 4096 Dec 23 16:14 userc

Try to display the contents of one of the home directories:27)

# ls -al /mnt/home/userals: /mnt/home/usera/: Permission denied[R6]

ls: cannot open directory /mnt/home/usera: Permission denied[S11]

Since NFS has traditionally squashed the root user, some errors are expected.28)The standard workaround is for the root user to become the desired user via thesu command, and then read that user's files:

# su - usera

Verify the user has no Kerberos tickets, specifically a Ticket-granting ticket (TGT),29)then attempt to display the contents of that user's home directory:

$ klistklist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_301)Kerberos 4 ticket cache: /tmp/tkt301klist: You have no tickets cached$ ls -al /mnt/ls: /mnt/: Permission denied[R6]

ls: cannot access /mnt/: Permission denied[S11]

The user, without being Kerberos authenticated, is unable to even access the toplevel directory of the mounted filesystem.

8-31

Obtain Kerberos credentials as usera and attempt to access usera's files on the30)mounted filesystem:

$ kinitPassword for [email protected]: pass Õ$ ls -al /mnt/home/useratotal 40[R6]

drwx------ 2 usera usera 4096 Dec 23 16:14 .[R6]

total 56[S11]

drwx------ 2 usera users 4096 Dec 23 16:14 .[S11]

drwxr-xr-x 6 root root 4096 Dec 23 16:14 ... . . snip . . .

The files were successfully accessed with Kerberos. Now the root user could suto the usera account and access that user's NFS files.

View the Kerberos tickets that are in the ticket cache:31)

$ klistTicket cache: FILE:/tmp/krb5cc_301Default principal: [email protected]

Valid starting Expires Service principal10/13/11 14:01:04 10/14/11 14:01:04 krbtgt/[email protected] renew until 10/13/11 14:01:0410/13/11 14:01:04 10/14/11 14:01:04 nfs/[email protected] renew until 10/13/11 14:01:04

Kerberos 4 ticket cache: /tmp/tkt301klist: You have no tickets cached

Destroy your tickets and see if you are still able to access the NFS files:32)

$ kdestroy$ ls -al /mnt/home/userals: cannot access /mnt/home/usera: Permission denied[R6]

total 56[S11]

8-32

Note you are still able to access the NFS files.kdestroy doesn't clear the cache. Instead, the ticketwill be cached until it expires. A future version of theKerberos utilities and NFS code will make use of a newin-kernel crypto-keyring system to resolve this issue.

drwx------ 4 usera users 4096 Jan 20 16:34 .[S11]

drwxr-xr-x 6 root root 4096 Jan 26 15:08 ..[S11]

. . . snip . . .[S11]

Exit the shell to return to the root user.33)

$ exit

Cleanup

To avoid conflicts with other lab tasks unmount the share and remove your34)exported filesystems:

# umount /mnt# > /etc/exports# exportfs -r

[S11] This step should only be performed on SLES11.35)Return the idmapd and rpc.gssd daemons to their default configuration:

File: /etc/sysconfig/nfs- NFS_START_SERVICES="yes"+ NFS_START_SERVICES=""


# exit

8-33

Objectivesy Generate a GPG public/private key pairy Encrypt and decrypt a file using GPG


RelevanceGNU Privacy Guard (GPG) is an encryption tool based on public/privateasymmetric keys. GPG can be used to encrypt files on the filesystem.

Lab 8

Task 4File Encryption with GPGEstimated Time: 5 minutes

[S11] This step should only be performed on SLES11.1)SLES11 uses GnuPG2 by default, which requires gpg-agent. Run the followingbefore moving on to the next step.

$ eval `gpg-agent --daemon`

Before you can start using GPG to encrypt files you have to generate a2)public/private key pair. Login as the guru user and then run the followingcommand:

$ gpg --gen-key. . . snip . . .Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only)Your selection? 1DSA keypair will have 1024 bits.ELG-E keys may be between 1024 and 4096 bits long.What keysize do you want? (2048) ÕRequested keysize is 2048 bitsPlease specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n yearsKey is valid for? (0) Õ

8-34

Key does not expire at allIs this correct (y/n)? y

GnuPG needs to construct a user ID to identify your key.

Real name: Guru Von GurusteinEmail address: [email protected]: The guru example user.You selected this USER-ID: "Guru Von Gurustein (The guru example user.) <[email protected]>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? OYou need a Passphrase to protect your secret key.Enter passphrase: secret ÕRepeat passphrase: secret Õ

If your system hasn't built up and stored enoughrandom data in the entropy pool, this step may requireyou to jiggle the mouse, use the keyboard, or causedisk IO in order to continue. This may take some time.

We need to generate a lot of random bytes. It is a good idea to performsome other action (type on the keyboard, move the mouse, utilize thedisks) during the prime generation; this gives the random numbergenerator a better chance to gain enough entropy.

gpg: key C1E4335C marked as ultimately trustedpublic and secret key created and signed.

gpg: checking the trustdbgpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust modelgpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1upub 2048R/C1E4335C 2011-05-27 Key fingerprint = B8B5 2D2C 5AA3 9672 9DEC 36AD CCB7 CF74 C1E4 335C uid Guru Von Gurustein (The guru example user.) <[email protected]>sub 2048R/CDD3151A 2011-05-27

Create a testfile.txt using your favorite text editor containing the following:3)

File: testfile.txt+ This is a test file.+ It will be encrypted soon.

Encrypt your newly created file using the guru user's public key:4)

$ gpg -e testfile.txt

8-35

You did not specify a user ID. (you may use "-r")

Current recipients:

Enter the user ID. End with an empty line: guru. . . output omitted . . .Enter the user ID. End with an empty line: Õ

Try to read the newly encrypted file, and delete the original source file:5)

$ strings testfile.txt.gpgy{@AbICS7 {}5{5@\D1kD`h

shred overwrites the file's data blocks many times (25by default) with random data, then removes the file.

$ shred -u testfile.txt

Decrypt the file to the terminal:6)

$ gpg -d testfile.txt.gpg

You need a passphrase to unlock the secret key foruser: "Guru Von Gurustein (The guru example user.) <[email protected]>"2048-bit RSA key, ID CDD3151A, created 2011-05-27 (main key ID C1E4335C)

Enter passphrase: secret Õgpg: encrypted with 2048-bit RSA key, ID CDD3151A, created 2011-05-27 "Guru Von Gurustein (The guru example user.) <[email protected]>"This is a test file.It will be encrypted soon.

Decrypt the file output to another file:7)

$ gpg -o testfile.txt -d testfile.txt.gpg

You need a passphrase to unlock the secret key foruser: "Guru Von Gurustein (The guru example user.) <[email protected]>"2048-bit RSA key, ID CDD3151A, created 2011-05-27 (main key ID C1E4335C)Enter passphrase: secret Õgpg: encrypted with 2048-bit RSA key, ID CDD3151A, created 2011-05-27

8-36

"Guru Von Gurustein (The guru example user.) <[email protected]>"$ cat testfile.txtThis is a testfile.It will be encrypted soon.

8-37

Objectivesy Encrypt and decrypt a file using OpenSSL


RelevanceOpenSSL is an open source implementation of the SSL protocol. TheOpenSSL package includes many useful utilities. One of these utilities isable to encrypt or decrypt files.

Lab 8

Task 5File Encryption With OpenSSLEstimated Time: 5 minutes

The openssl command can perform many different cryptographic related tasks.1)The ability to encrypt data using a symmetric cipher is one such task. View a listof supported cipher types:

$ openssl enc -h. . . snip . . .Cipher Types-aes-128-cbc -aes-128-cfb -aes-128-cfb1-aes-128-cfb8 -aes-128-ecb -aes-128-ofb-aes-192-cbc -aes-192-cfb -aes-192-cfb1-aes-192-cfb8 -aes-192-ecb -aes-192-ofb-aes-256-cbc -aes-256-cfb -aes-256-cfb1-aes-256-cfb8 -aes-256-ecb -aes-256-ofb-aes128 -aes192 -aes256-bf -bf-cbc -bf-cfb-bf-ecb -bf-ofb -blowfish. . . snip . . .

The man page for enc has a description for each cipher type.

If you have not already done so, create a testfile.txt using your favorite text2)editor containing the following:

File: testfile.txt+ This is a test file.+ It will be encrypted soon.

8-38

Use the openssl command with the Blowfish cipher to encrypt the existing3)testfile.txt:

$ openssl enc -bf -in testfile.txt -out testfile.txt.bfenter bf-cbc encryption password:secret ÕVerifying - enter bf-cbc encryption password:secret Õ

Try to read the newly encrypted file, and delete the original source file:4)

$ strings testfile.txt.bfSalted__).z#o$ shred -u testfile.txt

Reverse the operation decrypting the file:5)

$ openssl enc -bf -d -in testfile.txt.bf -out testfile.txtenter bf-cbc decryption password:secret Õ$ cat testfile.txtThis is a testfile.It will be encrypted soon.



Create a triple DES encrypted archive of the /etc/ directory:7)

# tar -cz /etc/* 2> /dev/null | openssl enc -des3 > /tmp/etc.tar.gz.des3enter des-ede3-cbc encryption password:secret ÕVerifying - enter des-ede3-cbc encryption password:secret Õ

Verify the integrity of the encrypted archive:8)

# openssl enc -des3 -d -in /tmp/etc.tar.gz.des3 | tar tvz

8-39

enter des-ede3-cbc decryption password:secret Õ. . . output omitted . . .


# exit

8-40

Objectivesy Create and format a LUKS encrypted filesystemy Provide access to the filesystem with multiple keys


RelevanceLUKS-on-disk format provides for entire filesystem encryption. Multiplekeys can be used to decrypt and mount the same filesystem.

Lab 8

Task 6LUKS-on-disk formatEncrypted FilesystemEstimated Time: 15 minutes



To begin, a new partition will need to be created. This partition will be used to2)secure the home directory of the new user privuser:

Note the last partition currently on the disk.# fdisk -l /dev/sda | tail -1In this example output, the last partition is 2./dev/sda2 64 4526 35840000 8e Linux LVM

# fdisk /dev/sda. . . snip . . .Command (m for help): nCommand action e extended p primary partition (1-4)

If the last partition is 3, then partition 4 should becreated as an extended partition, filling all availablespace. This will require the addition of a logical drive(/dev/sda5) for the 500 MB filesystem.

pPartition number (1-4): 3 First cylinder (4526-19457, default 4526): Õ Using default value 4526Last cylinder, +cylinders or +size{K,M,G} (4526-19457, default 19457): +500M

Command (m for help): p. . . snip . . .

In this example output, the newly created partition is 3(one more than the final partition number just noted).

/dev/sda3 4526 4590 516151 83 Linux

Command (m for help): w. . . output omitted . . .# partx -a /dev/sda

8-41

. . . output omitted . . .# grep sdaN /proc/partitions 8 3 516151 sdaN

Note the number assigned to the new partition (N).

Prepare and encrypt the newly created partition:3)

This may take several minutes.# dd if=/dev/urandom of=/dev/sdaN bs=1M. . . output omitted . . .# cryptsetup --verify-passphrase luksFormat /dev/sdaN

WARNING!========This will overwrite data on /dev/sdaN irrevocably.

Are you sure? (Type uppercase yes): YESEnter LUKS passphrase: my pass phrase ÕVerify passphrase: my pass phrase ÕCommand successful.

Create an encrypted mapped device which points to /dev/sdaN using device4)mapper. The cryptsetup command provides the userland functionality:

# cryptsetup luksOpen /dev/sdaN secure_homeEnter LUKS passphrase: my pass phrase Õkey slot 0 unlocked.[S11]

Command successful.[S11]

Verify that the device mapper has now created the new device/dev/mapper/secure_home: ls /dev/mapper/secure_home.

Create an ext3 filesystem on top of /dev/mapper/secure_home. Give it a5)filesystem label of /secure/home:

# mkfs -t ext3 -L /secure/home /dev/mapper/secure_home. . . output omitted . . .

Set the default mount options in the superblock of the filesystem to always mount6)with support for POSIX ACL and user-specified extended attributes. Also turn offautomatic checking by disabling the maximal mount count and interval settings:

8-42

# tune2fs -l /dev/mapper/secure_home | grep "Default mount options:"Note that there are currently no default mount optionsspecified in the filesystem superblock.

Default mount options: (none)# tune2fs -c 0 -i 0 -o acl,user_xattr /dev/mapper/secure_home. . . output omitted . . .# tune2fs -l /dev/mapper/secure_home | grep "Default mount options:"

Note the newly set default mount options.Default mount options: user_xattr acl

Create a new /etc/crypttab file with the following entry to allow for automatic7)mounting on boot:

File: /etc/crypttab+ secure_home /dev/sdaN none

Create the directory where the privuser's encrypted home will be mounted:8)

# mkdir /srv/secure_home/

Modify /etc/fstab (adding a line to the end) to allow automatic mounting of the9)new encrypted filesystem of boot:

File: /etc/fstab+ /dev/mapper/secure_home /srv/secure_home ext3 defaults 0 2

Verify that the filesystem mounts cleanly using the new fstab entry:10)

# mount /srv/secure_home && mount | grep '/srv/secure_home'/dev/mapper/secure_home on /srv/secure_home type ext3 (rw)

Create the account for the security conscious user:11)

# useradd privuser -m -d /srv/secure_home/privuser# passwd privuserChanging password for user privuser.New UNIX password: thepassword ÕBad password: it is based on a dictionary wordRetype new UNIX password: thepassword Õpasswd: all authentication tokens updated successfully.[R6]

Password changed.[S11]

8-43

[S11] This step should only be performed on SLES11.12)Configure cryptsetup to run on boot:

# chkconfig boot.crypto on

Reboot the machine, during the bootup, on the console of the system it will13)pause and ask for the passphrase, supply the passphrase:

my pass phrase Õ

Login as the privuser and verify the encrypted home directory is automatically14)mounted. After verifying, Logout of the privuser account.

Cleanup:



Remove the encrypted partition, so that future lab tasks are not impacted.16)

# pkill -9 -u privuser# umount /srv/secure_home/# cryptsetup luksClose /dev/mapper/secure_home# rm -f /etc/crypttab# sed -i '/secure_home/d' /etc/fstab# parted /dev/sda rm N# partx -d /dev/sda


# exit

Appendix

ASECURING EMAILSYSTEMS

1-2

SMTP Implementations

Sendmail• Historical MTA

Legacy of security problemsExim• SMail derived replacement for Sendmail• Default for many applications on Debian

Postfix• Secure• Easy to configure• Excellent performance• LSB/Sendmail compatibility• Default for enterprise Linux distributions

SMTP Implementations

The two most widely used SMTP implementations are Sendmail andPostfix. Sendmail is the oldest available SMTP implementation andhistorically the most widely used SMTP implementation. Sendmail isa Unix standard, and so Linux vendors still supply it today. ClassicallyIt is was implemented as a monolithic binary which runs as root inorder to bind port 25. Starting with the 8.12 release of Sendmail, itdoesn't require SUID root anymore and has two daemons, one ofwhich runs as user smmsp. This partly addresses the monolithicnature.

Because of the large convoluted and largely monolithic code base,Sendmail has historically been riddled with security holes. Because ofthis in recent years a great deal of effort has been placed onSendmail security concerns and Sendmail security has greatlyimproved.

Postfix, in contrast, is a much newer MTA which was designed withsecurity as its primary design goal. Developed by Wietse Venema, thesecurity expert who also wrote TCP Wrappers, Postfix is implementedas a team of daemons, each of which handle specific functions andonly have the minimal amount of privilege necessary to carry outthose functions. As a result, Postfix has a stellar security record. Inaddition, Postfix is far easier to configure that Sendmail, and is alsothe fastest MTA currently available.

1-3

Security Considerations

Unauthorized RelayingPlain Text AuthenticationPlain Text Protocols• SMTP, POP3, IMAP

Stored Passwords in MUAsExploitable flaws in MTAsBad Email• SPAM• Viruses

Security Considerations

Regardless of which MTA is chosen, several common securityconsiderations will have to be addressed. All MTAs have thecapability to bind TCP ports on network interfaces and listen forincoming connections. This behavior should be carefully restricted tominimize system exposure. Modern distributions of RHEL6/SLES11are good in this regard and out of the box only listen on the loopbackinterface by default.

In addition, to function as an MTA, a mail server must acceptconnections from MUAs for which it is supposed to send mail.Historically, MTAs have accepted connections from all MUAs, asituation which has directly led to the proliferation of UCE(Unsolicited Commercial Email, sometimes referred to as "spam"). Forthis reason, responsible vendors ship MTAs configured not to relaytraffic for any clients. Postfix and Sendmail will need to be modifiedto allow relaying from trusted client addresses.

When MUAs login via POP3 or IMAP to retrieve email they transmit ausername and password over the wire in plain text. An attacker witha network capture utility somewhere along the path between theclient and server can easily obtain the username and password.MTAs and MUAs should be configured to use a secure mechanismfor transmitting credentials and ideally enforcing the securemechanism.

Many emails contain confidential or sensitive information. Thestandard email protocols, SMTP, POP3, IMAP4 transmit all data in the

clear even if the credentials were transmitted securely. Forconfidentiality it is better if the entire session is encrypted and notjust during the credential transmission phase.

In order to avoid having the username password stolen by a virus orspyware is it advisable to not have the MUA store credentials in a fileon the disk as is often done. One alternate is to have the users typetheir password every time they launch their MUA. This can be a biginconvenience for users and deploying a secure sign on solution suchas Kerberos is likely the best solution for an organization.

Many system compromises are first due to a compromise in anetwork daemon, historically this was often the MTA. The MTAshould be configured in advance as locked down andcompartmentalized as possible.The Postfix daemons supportchrooting so as to limit the fallout from a compromise.

Today, the ability to filter email at the MTA is also becoming a majorsecurity issue. UCE has passed the point of being an annoyance andentered the realm of a security threat. In addition, the proliferation ofviruses which affect poorly written MUAs (Microsoft Outlook andMicrosoft Outlook Express in particular) has had major securityimplications for the desktop. Filtering out email viruses at the MTAcan help increase enterprise security by preventing infections. Manycommercial anti-SPAM and anti-virus solutions exist. The mostpopular open source products are Spamassassin and ClamAV.

1-4

chrooting Postfix

All processes except for daemons that deliver mail locally may bechange rootedUseful as an extra layer of protection for processes which access thenetwork:• smtp• smtpd

A Postfix change rooted daemon resolves all filenames relative to thePostfix queue directory• /var/spool/postfix/

Chrooting configured on per daemon basis in master.cf

chroot

The chroot() system call is useful when trying to develop securesoftware. If a process is locked within a change rooted directory, itcannot access files outside of that directory, so it cannot be used todo things like access /etc/shadow if a cracker manages to find asecurity hole in the program.

Postfix makes extensive use of this chroot() function. All processesexcept for local (the local system MDA) use chroot(), and can beconfigured via /etc/postfix/master.cf to change root to/var/spool/postfix if desired. However, Postfix is not changerooted by default.

The default directory to which Postfix changes root is/var/spool/postfix. Because many of the Postfix daemons willconsider this directory to be /, it has to have a partial copy of thesystem configuration and library files under it./var/spool/postfix/etc/ would contain essential configuration files(such as services and resolv.conf), /var/spool/postfix/lib/would contain essential system libraries (such as libresolv.so), andso forth. These libraries and configuration files need to be current. Ifthey ever get out of sync (such as by changing the system's DNSservers), Postfix will warn that the two differ. In that case, they willneed to be synchronized manually.


The /usr/share/doc/postfix-*/examples/chroot-setup/LINUX2example script can be modified to create the Postfix chrootenvironment. Copy this script to /etc/postfix/chroot-update. Editthe /etc/postfix/master.cf configuration file to enable thedaemons you want to be run from within the chroot. Restart Postfix.

If Postfix is using SMTP Auth with saslauthd, the/var/run/saslauthd/ directory must also be found within Postfix'schroot. First edit the /etc/sysconfig/saslauthd init configurationfile, SOCKETDIR variable, then create the appropriate directories, andlet SELinux know of the change:.

# semanage fcontext -a -t saslauthd_var_run_ta"/var/spool/postfix/var/run/saslauthd(/.*)?"

# mkdir -p /var/spool/postfix/var/run/saslauthd/# chcon -t var_run_t /var/spool/postfix/var/run/# chcon -t saslauthd_var_run_t /var/spool/postfix/vara

/run/saslauthd


The /usr/share/doc/packages/postfix-doc/README.SuSE filedocuments how to configure SuSEconfig to maintain a Postfixchange root environment. Be aware that SuSEconfig does not copythe /etc/krb5.conf Kerberos configuration, if using a Kerberosrealm. Also, we have found that having the virtual and lmtpdaemons in a chroot may require a complicated configuration, andthus may not be worth the added security.

1-5

Email with GSSAPI/Kerberos Auth

GSSAPI/Kerberos Authentication• Supported by SASL• Supported SASL mechanism by Postfix and Cyrus IMAP

Required Kerberos Principals• smtp/FQDN@REALM• imap/FQDN@REALM

Configuration flexibility• Can offer GSSAPI/Kerberos authentication in addition to or in

place of traditional PLAIN/LOGIN authenticationEvolution and Outlook MUA support• Kmail support in KDE v3.4

Postfix GSSAPI/Kerberos SMTP Authentication Configuration

After the smtp Kerberos service principal has been created, it needsto be added to a private keytab file on the Postfix host. By default,Postfix will look at the default /etc/krb5.keytab system file. Oneway to solve this is to make sure Postfix's SMTP daemon is in achroot. Then create the /var/spool/postfix/etc/krb5.keytab file.

This way even though Postfix opens the default keytab from its pointof view, it's actually a separate private keytab file. When runningPostfix chrooted, be sure that the/var/spool/postfix/etc/krb5.conf file exists and is a copy of/etc/krb5.conf. Also, the directory /var/spool/postfix/var/tmp/must exist and have permissions 1777. This is required for Kerberosto save its session replay cache files. Remember that saslauthdmust also work from within the Postfix chroot.

If Postfix is not chrooted, then the environment variable KRB5_KTNAMEmust be set within the Postfix SysV init script with the path to thekeytab file. Then within Postfix's main.cf file the environment variablemust be imported using the configuration setting:

File: /etc/postfix/main.cf+ import_environment = KRB5_KTNAME=/etc/krb5.keytab-smtp...

The final change needed for Postfix GSSAPI/Kerberos support is tomodify the sasl2/smtpd.conf file so the mech_list option includesgssapi. For example:

[R6] File: /etc/sasl2/smtpd.conf

[S11] File: /usr/lib/sasl2/smtpd.conf+ mech_list: PLAIN LOGIN GSSAPI

If you want to only support GSSAPI/Kerberos, then have GSSAPI bethe only value listed.

Cyrus IMAP GSSAPI/Kerberos Authentication Configuration

The Cyrus server uses the Kerberos principal imap/FQDN@REALM. LikePostfix, Cyrus IMAP requires its own private keytab. It must bereadable by the user cyrus.

Once the keytab file has been created, modify the /etc/imapd.conffile and include the configuration setting to define the keytab location:

File: /etc/imapd.conf+ sasl_keytab: /etc/krb5.keytab-cyrusimap

Then in the same file modify the list of advertised SASL mechanismsto include gssapi, for example:

File: /etc/imapd.conf+ sasl_mech_list: PLAIN GSSAPI

List Postfix if your policy dictates GSSAPI/Kerberos onlyauthentication, then have GSSAPI be the only value listed.

1-6


S11: 10 minutesTask 1: Postfix In a Change Root EnvironmentPage: 1-15 Time: 10 minutesRequirements: bb (2 stations)

1-7

ObjectivesyModify Postfix's SysV Init script to setup and maintain the proper

environment for chrooting Postfix daemons each time it starts.y Configure Postfix to chroot some of its daemons.y Send email to a lab partner's system.


RelevancePostfix can be run within a change rooted environment. Running Postfix inthis manner will add a layer between the application and the operatingsystem by only allowing the application to have access to just part of adirectory tree, and not the complete filesystem.

Lab 1

Task 1Postfix In a Change RootEnvironmentEstimated Time: 10 minutes

Make sure that Postfix is listening on the external interface:1)

# postconf -e 'inet_interfaces = all'# service postfix restart. . . output omitted . . .

[R6] This step should only be performed on RHEL6.2)A file containing functions that will create and maintain the needed files anddirectories, has been placed in the /labfiles/ directory on the system. Copy thisfile into the /etc/init.d/ directory:

# cp /labfiles/postfix-chroot /etc/postfix/chroot-update# chmod 755 /etc/postfix/chroot-update

[S11] This step should only be performed on SLES11.3)YaST can setup and maintain a change rooted environment for Postfix. Modify the/etc/sysconfig/postfix file to enable this function:

1-8

File: /etc/sysconfig/postfix # Start postfix services chrooted, that are able to run chrooted? # Note: if you want SuSEconfig to maintain the chroot jail, you # also have to set POSTFIX_UPDATE_CHROOT_JAIL to yes #- POSTFIX_CHROOT="no"+ POSTFIX_CHROOT="yes" ## Type: yesno ## Default: no ## Config: postfix # # Set this to yes, if SuSEconfig should setup the chroot jail itself #- POSTFIX_UPDATE_CHROOT_JAIL=no+ POSTFIX_UPDATE_CHROOT_JAIL=yes

[S11] This step should only be performed on SLES11.4)The SuSEconfig script used to set up and maintain the Postfix chroot omitssupport for kerberos inside of the chroot directory. Enable kerberos in the chrootby adding these lines to the /sbin/conf.d/SuSEconfig.postfix file:

File: /sbin/conf.d/SuSEconfig.postfix mkdir -p /var/spool/postfix/proc if ! grep /var/spool/postfix/proc /proc/mounts &< /dev/null; then mount -t proc proc /var/spool/postfix/proc fi++ #Kerberos+ cpifnewer /etc/krb5.conf etc+ mkdir -p var/tmp+ chmod 1777 var/tmp+ # PAM

1-9

[S11] This step should only be performed on SLES11.5)Execute the SuSEconfig script to set up the chroot environment for Postfix. It willalso modify the /etc/postfix/master.cf to turn on chrooting for many Postfixcomponents:

# SuSEconfig --module postfix. . . output omitted . . .

[S11] This step should only be performed on SLES11.6)The SuSEconfig script is quite thorough in chrooting. It chroots two deliverycomponents virutal and lmtp that causes uneeded complication. Revert thosetwo components back to not being chrooted:

File: /etc/postfix/master.cf # ========================================================================= # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # =========================================================================- virtual unix - n y - - virtual+ virtual unix - n n - - virtual- lmtp unix - - y - - lmtp+ lmtp unix - - n - - lmtp

[R6] This step should only be performed on RHEL6.7)Use a text editor to adjust the /etc/postfix/master.cf file so that Postfix willrun its smtpd daemon in the chroot environment:

File: /etc/postfix/master.cf # ========================================================================= # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # =========================================================================- smtp inet n - n - - smtpd+ smtp inet n - y - - smtpd

Restart Postfix to make these changes take effect:8)

# service postfix restartShutting down postfix: [ OK ]Starting postfix: [ OK ]

Have a lab partner send email to the chrooted email server:9)

# echo "This message was sent to your chrooted Postfix" | mailx -s "Test Message" guru@stationY

Verify that the message was received on the email server machine. Use the mailx10)command to read guru's messages:

# su - guru$ mailx? 1. . . output omitted . . .? q$ exit