Operating System Security
Optional Labs
0Handouts:
Optional Labs
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 1-1: Understanding the /etc/securetty file
In this lab, you will examine a PAM component, the /etc/securetty file.
1. Boot into Linux as root. Open a Telnet client and attempt to log on to your
partner's system as root. This attempt should fail, because the /etc/securetty
file disallows it.
2. Make a copy of the /etc/securetty file:
host# cp /etc/securetty /etc/securetty.orig
3. Now, move the /etc/securetty file to the /root directory:
host# mv /etc/securetty /root/securetty
4. Make sure that the /etc/securetty file no longer exists.
5. Have your partner log on to your system directly as root. Was he or she
successful?
6. Now, move the /root/securetty file back to /etc/securetty.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 1-2: Denying Telnet access using the
/etc/nologin file
In this lab, you will use another PAM element, the /etc/nologin file, to deny
Telnet access.
1. Use touch to create a file named /etc/nologin.
2. Enter the following text:
*********************************************
Access denied. Contact your Security Manager.
*********************************************
3. Using a non-root account, try to access this system using Telnet.
4. Have your partner try to access your system.
5. With your /etc/nologin file still present, open an FTP session to your partner's
server.
6. Notice that the session is successful because the nologin file applies only to
Telnet-based logon sessions.
7. When you are finished experimenting, delete the /etc/nologin file.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 2-1: Pruning users and determining system
state in Linux
1. Boot into Linux and log on as root.
2. Use the /usr/sbin/useradd program to add the following users:
•
sales
•
marketing1
•
marketing2
3. Use the passwd command to create passwords for each user.
4. Log in as root and change to the /etc/home directory.
5. Notice that home directories have been created for the sales and marketing
users.
6. Log out as root and log in as these users.
7. Log out and log back in as root.
8. As root, use the /usr/sbin/userdel command to remove the sales user:
/usr/sbin/userdel
9. The sales user has been removed. Change to the /home/ directory. You should
still see the home directory for the sales user. Still in the /home/ directory,
issue the following command:
rm -fr sales
Warning: Be extremely careful when using the -fr options with the rm command.
These options cause the rm command to delete everything you specify. For
example, rm will delete all files, directories and sub-directories.
10. Still as root, use the /usr/sbin/userdel -r command to remove the
marketing1 and marketing2 users:
/usr/sbin/userdel -r marketing1
/usr/sbin/userdel -r marketing2
11. List the /home/ directory. You will see that these user directories are no
longer present.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
12. Still as root, add a group:
/usr/sbin/groupadd ciw
13. Delete this group:
/usr/sbin/groupdel ciw
14. Now, read your hard drive’s configuration:
cat /etc/fstab
15. Consider saving this information so that you know the system’s original state.
16. To discover the open processes on your system, issue the following command:
ps aux > processes.txt
17. Use the less command to view this file:
less processes.txt
18. Scroll up and down this file using the up and down arrow keys on your
keyboard. When you are finished viewing these processes, press q.
19. Now, have a partner log in to your system and run the top command.
20. While your partner is logged in, issue the following command:
ps aux > processes2.txt
21. You now have two files that are essentially snapshots of your system’s state.
The /usr/bin/diff command compares the contents of two files to
determine the differences between the two. Issue the following command:
/usr/bin/diff processes processes2
22. What do these files tell you about how your system state has changed?
23. System modules allow your Linux system to use NICs, sound cards, and other
devices. You do not want anyone to install additional modules without your
permission. The fact that additional modules have been installed could point
to illicit activity. You should create a baseline that allows you to determine
what modules are installed. Now, use the /sbin/lsmod command to view the
modules currently installed on your system. Now, issue the following
command to store this information:
/sbin/lsmod > modules.info
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
24. Now you can run lsmod in the future and compare the output to this file.
25. Now, use the lsof command to list all open files on the system:
/usr/sbin/lsof | less
26. Because Linux treats everything as if it were a file, the lsof command lists
open processes, files and even network connections. Scroll down the file by
pressing the down arrow key. If you want to scan this list quickly, press the
space bar to have the less command scroll down the information a screen at a
time.
27. When you are finished, press q.
28. The lsof command is quite versatile. For example, you can list files opened
by a specific user. Create an account named lsoftest, give it a password, and
have your partner log in to your system using this account. After your partner
has logged in, issue the following command:
lsof –ulsoftest | less
29. You should see a list of all files (including modules, login files, and terminals)
that this user has opened, simply because this user has logged in.
30. You can also see the activity associated with an IP address. For example,
suppose your system’s IP address is 192.168.2.1. To view all activity
emanating from 192.168.2.4, you would issue the following command:
lsof -i@192.168.2.4
Now, use this command to trace the changes your partner’s connection makes to
your system’s state.
Note: You can also check for Ipv6 addresses:
lsof -i@[0:1:2:3:4:5:6:7]
31. You can also use lsof to see remote connections to a port on your host. Have
your partner connect to your system using Telnet. Start the Telnet daemon, if
necessary. When your partner has connected, issue the following command:
lsof -i TCP@partner’sipaddress
The above lists all TCP-based connections from your partner's system to your
own system.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
32. To terminate any connection to an IP address, you can use lsof in
conjunction with the kill command to instantly log off any user. Make sure
your partner is logged on, then try the following command:
kill -9 `/usr/sbin/lsof -i@partnersipaddress`
Note: You must use the backtic character (`) and not the apostrophe character.
The backtic character is above the TAB key.
This command will terminate all logged-in users from the remote system with the
IP address of 192.168.2.4.
You can learn more about how to create additional lsof commands by consulting
its man page.
33. Now, use the find command to search and list the writeable files on your
system:
find / ! -type l \( -perm -0006 \) -exec ls -l {} \;
Note: This command has find search the root directory (/) for all files that are
world-readable and -writeable (i.e., any file that has both the read and write bit
set for all users). It then lists those files (-exec ls). The final expressions are
essential to the –exec option. Issue the man find command for additional
information.
34. To list only files in the /root/ directory, you can modify the command as
follows:
find /root/ ! -type l \( -perm -0006 \) -exec ls -l {} \;
35. To save this information to a file, you would issue the following command:
find /root/ ! -type l \( -perm -0006 \) -fls save.txt
In this lab, you learned how to prune users and groups, as well as how to
document the state of your Linux system.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 2-2: Renaming default Windows 2000
accounts
1. Log on to Windows 2000.
2. Open the Local Security Policy snap-in.
3. In the Security Settings | Local Policies | Security Options section, select the
Rename administrator account value.
4. Enter root into the Local policy setting dialog box, then click OK.
5. Log off and try to log back on as administrator. You will not be able to do so.
Log on as root, then open the Computer Management snap-in to verify that
the administrator account has been completely renamed.
6. When you are finished, change the Rename administrator account value to
administrator, so that the system is back to its default. This step is necessary to
prevent confusion in future labs.
7. Using the Security Policy snap-in, rename the guest account.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 2-3: Creating a second root account in
Linux
In this lab, you will create a second account that has root privileges. You cannot
completely remove the root account without affecting the daemons that run on the
system. However, you can create a second root account for login purposes.
1. Boot into Linux and log in as root.
2. Make a copy of the /etc/passwd file and name it /etc/passwd.orig. This step is
necessary in case something goes wrong, and also because you will need to
return your system to its default to avoid problems in future labs:
host# cp /etc/passwd /etc/passwd.orig
3. Use the /usr/sbin/useradd and /usr/bin/passwd commands to create a
new user named administrator:
/usr/sbin/useradd administrator
/usr/bin/passwd administrator
4. Now, edit the /etc/passwd file so that the root entry reads as follows:
root:x:0:0:root:/root:/bin/false
5. Edit the administrator entry so that it reads as follows:
administrator:x:0:0::/home/administrator:/bin/bash
6. Close the /etc/passwd file, making sure to save your changes.
7. Log out and try to log back in as root. You will not be able to do so. However,
all system daemons can still use the root account. You have simply disabled
all terminal access to the root account.
8. Log in as administrator. Stop a few services and add a few users. You will be
able to do so, because your administrator account is now defined as the "root"
account. Remember, daemons do not look for the text string of "root." They
look for the UID of the user who is administering the service.
Note: For the sake of convenience, you may want to modify the environment of
this new account so that it behaves like that of the root account. For example,
compare the .bashrc and .bash_profile files for each account to see the changes
you will have to make. Note also that if you want to use the su command, you will
have to specify the new root account. For example, type su administrator,
instead of just su.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
9. To avoid confusion in future labs, replace the existing /etc/passwd file with
the original:
host# cp /etc/passwd.orig /etc/passwd
Note: Failure to perform this last step may cause problems in future labs.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 3-1: Copying and moving files
In this lab, you will move and copy files between two Windows 2000 partitions.
After the files are copied or moved, you will determine how these changes affect
the files' security settings.
Note: To perform this lab, you must have two partitions on your hard drive.
1. Log on as administrator.
Note: If you have renamed the administrator account earlier and not changed this
value back to the default, then log on using the proper account name.
2. Using Windows Explorer, create a folder called Source in the C:\ folder.
3. Create a folder called Dest1 in the C:\ folder.
4. Create a folder called Dest2 in the D:\ folder.
5. Assign Full Control access of C:\Source to Group1.
6. Remove the Everyone group access from C:\Source.
7. Assign Full Control access of C:\Dest1 to Group2.
8. Remove the Everyone group access from C:\Dest1.
9. Assign Read access of D:\Dest2 to Group3.
10. Remove the Everyone group access from D:\Dest2.
11. Create a file called Test1.Txt in C:\Source.
12. Create a file called Test2.Txt in C:\Source.
13. Create a file called Test3.Txt in C:\Source.
14. Create a file called Test4.Txt in C:\Source.
15. Examine the permissions for all of the test files in C:\Source.
16. Open a Command Prompt.
17. Using your command prompt, access the C:\Source directory.
18. Copy Test1.Txt to C:\Dest1.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
19. Move Test2.Txt to C:\Dest1.
20. Copy Test3.Txt to D:\Dest2.
21. Move Test4.Txt to D:\Dest2 using the following command:
move test4.txt
d:\dest2
22. Using Windows Explorer, note the permissions on each test file in C:\Dest1
and D:\Dest2.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 3-2: Finding setuid and setgid programs in
your Linux system
1. Try the following command and search for setuid/setgid commands
available on your system:
host# find / \( -perm +4000 \) -exec ls -l {} \;
Note: In the preceding command, the find command is told to search the root
directory (i.e., the entire hard drive), which is known in UNIX systems as /. The
first \ and / characters escape the -perm +4000 from the shell. The + sign has the
find function search for files that have setuid permissions or higher. If these
characters were not present, the find command would fail. The -exec command
has find then use the ls -l command. The {} \; characters tell find to use the
ls -l command to provide a long listing of the files that it finds.
2. If you want to discover both setuid/setgid and files that have at least read
permission bits set in the Other field, you would enter the following
command:
host# find / \( -perm +4000 -o -perm +2000 \) -exec ls -l {}
\;
Note: The preceding command is similar to that in Step 1, except that it uses the
-o command, which searches for permissions of 4000 or greater (setuid/setgid) or
2000 or greater. As a result, you will see files that have bits set in the Other field,
as well as any setuid or setgid bits.
3. Graphical Linux tools exist to help you issue some simplified find
commands. One is called kfind, and is part of the KDE desktop. If you have
the KDE desktop installed, open a terminal in the X Window environment and
issue the following command:
kfind &
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
4. When the kfind GUI appears, have kfind search all files on the system.
Make sure the Name&Location is selected, enter an asterisk in the Named
field, and a forward slash in the Look in field, as shown in Figure OL3-1.
Figure OL3-1: Selecting all system files in kfind
5. Select the Advanced tab and select the SUID executable files option.
6. Click the start button (
).
7. After the search is complete, you will see a list of SUID executable files, as
shown in Figure OL3-2.
Figure OL3-2: Listing suid executable files in kfind
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 4-1: Installing setup files for the Linux
Security Analyzer agent on Windows 2000
In this lab, you will install the Linux Red Hat 7.0 agent setup files on Windows
2000. Although the agents appear to be written for Linux 6.0, they will work for
any version of Red Hat between 6.0 and 7.0. After you install the agent setup files
on Windows 2000, you will install them on your partner's Linux system in the
next lab.
Note: One partner in each group should complete this lab. The system must have
the FTP service running. If you were using Windows NT 4.0, you would also need
the Windows NT 4.0 Option Pack, because an FTP server is the most convenient
way to transfer files between your NT and Linux systems.
1. Desktop: Open Windows Explorer.
Access the WebTrends Security Analyzer Agent for Red Hat Linux
installation file (AgentLinux60.exe) from your instructor or download it from
http://www.webtrends.com.
To install the Linux agent, double-click the AgentLinux60.exe file.
2. Select OK at the Linux Agent Setup Install window to begin the process. The
Linux agent setup files will install on Windows 2000.
Note: In the next part of this lab, you will copy the Linux agent setup files to your
FTP server.
3. Open Windows Explorer, if necessary.
4. Copy the file wsa_agent-3.5.linux60.i586.rpm from the default installation
directory:
C:\Program Files\WebTrends Security
Analyzer\wsa_agents\Linux60\
to the following directory:
C:\Inetpub\ftproot\
5. Close Windows Explorer.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 4-2: Installing and configuring a Security
Analyzer Linux Agent
In this lab, you will install and configure a Security Analyzer Linux Agent on
your partner's system.
Note: One partner in each group should complete this lab in Linux. The Linux
system will access the agent setup files from the Windows 2000 system's FTP
service.
1. Linux: Log on as root.
2. Linux: At the prompt, enter the following commands:
Host# ftp [partner's IP address]
Name: anonymous
Password: ftp
ftp> bi
ftp> get wsa_agent-3.5.linux60.i586.rpm
ftp> bye
3. Linux: Enter the following command in the same directory as the WebTrends
agent you just downloaded. Verify that the file exists in the current directory
by entering:
Host# ls
You will see the following file among several others:
wsa_agent-3.5.linux60.i586.rpm
4. Linux: Enter the command:
Host# rpm -ivh wsa_agent-3.5.linux60.i586.rpm
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
You will receive a message to run the configure.sh command in the
/usr/local/wsa directory. However, you must first create an agent.dat file. To
accomplish these procedures, run the commands:
Host# cd /usr/local/wsa
Host# touch agent.dat
Host# ./configure.sh
5. Enter Y to start the server at system startup. Enter Y to start the agent now.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 4-3: Scanning a Linux system from
Windows Console
In this lab, you will scan the Linux agent from the Security Analyzer Console.
1. Add a new profile by selecting File | New profile. Note: If you are using the
demo version, you should delete the "Intermediate Security Analysis" profile
because the demo version allows only six profiles.
2. In the Profile Description field, enter Partner Computer. In the Security Test
Policy section, select Critical Security Analysis, as shown in Figure OL4-1.
Figure OL4-1: Adding new profile
3. Select Next. In the Hosts To Scan section, click the Add button. Enter your
partner's IP address (the system with the Linux agent installed) in the Starting
address field. Click OK. You will scan only one host in this lab.
4. Click Finish. The Partner Computer profile you have created will appear in
the Security Analyzer window.
5. Select the Partner Computer profile and click Scan. Choose the New Scan
radio button and select OK. The scan will take several minutes. A new
window titled WSA—Partner Computer will display the results.
6. Select the Vulnerabilities tab, which will display the security risks on your
partner's Linux system. Scroll through the high-risk vulnerabilities on your
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
partner's system. If none exist, open the medium- and low-risk vulnerabilities.
In some cases, you may receive only one risk: the low-risk vulnerability
SMTP service enabled.
7. Select the Fixes Needed tab. A list of recommendations to secure your system
from high-risk vulnerabilities appears. You may receive only one fix: Remove
Unnecessary Services: SMTP. In the next lesson, you will implement this fix
and other recommendations to secure Linux systems.
8. Close the WSA—Partner Computer window.
9. Create a report and analyze the results.
10. When you are finished, exit the WebTrends Security Analyzer.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 5-1: Using Bastille
In this lab, you will use the latest version of Bastille appropriate to your version of
Linux. This lab assumes the use of the X-Window version of Bastille. If you
prefer, you can install the text-only version.
1. Log on as root and enter X-Windows by entering startx at the command
prompt. If your system defaults to an X-Window interface, log on directly as
root.
2. Obtain the Bastille RPM or tarball as well as all supporting files. If your
instructor does not have the files, go to the following sites:
•
http://www.bastille-linux.org/
•
http://bastille-linux.sourceforge.net
3. Using Bastille, make the following changes to your system:
•
Using the FilePermissions module, disable the r-tools, and configure your
system so that ping and traceroute are available only to root.
•
Using the BootSecurity module, take the necessary steps to enhance your
server's physical security.
•
Use the SecureInetd module to create a consistent policy for your Xinetd
daemons.
•
When you are finished, click the EndScreen menu, click the Yes radio
button, and begin writing these changes to your system
•
Using the Logging module, configure additional logging modules.
4. After you have made these settings, test them by logging on as a non-root
user. See if you can use ping and traceroute.
5. Reboot the system and experiment with the Linux single-user mode.
In this lab, you have experimented with the Bastille application. You now have
used a tool that can help you apply standard policies to all of your Linux systems.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
Optional Lab 5-2: Exercising granular authentication
control in Linux
In this lab, you and a partner will edit the /etc/pam.d/login file to invoke the
/lib/security/pam_access.so module. You will then edit the
/etc/security/access.conf file to limit access to the system based on user and
location.
1. Make a copy of the /etc/pam.d/login file and name it /etc/pam.d/login.orig .
2. Make a copy of the /etc/security/access.conf file and name it
/etc/security/access.conf.orig.
Note: Failure to make these copies can result in difficulties later.
3. Using a text editor, open the /etc/pam.d/login file.
4. Enter the following line, if it is not already present:
account
required
/lib/security/pam_access.so
5. Now that you have enabled the loading of the /lib/security/pam_access.so
module, you can edit the /etc/security/access.conf file. (Open this file with a
text editor.)
6. Enter the following line at the bottom of the file:
-:ALL:ALL EXCEPT LOCAL
7. Have your partner try to access your system using Telnet.
8. This connection should fail because you have denied logon access to all users
from all remote locations.
Note: If you were to enter -:ALL:ALL and log off, all accounts, including root,
would be denied access to the entire system. The only remedy for this lockout is to
boot into single-user mode, or use an X-Windows login, then edit the file so that
at least root can access the console.
9. Place a comment in front of the -:ALL:ALL EXCEPT LOCAL entry (use the #
character).
10. Create two new user accounts named access1 and access2 . Make sure you
give each account the password password.
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07
Operating System Security
Optional Labs
11. Now, enter a new line in /etc/security/access.conf that reads as follows:
-:ALL EXCEPT access1 root:ALL
12. Have your partner log on as access1. Your partner should be successful.
13. Now, have your partner log on as access2. Note that your partner can log on
as access1, but not as access2, or as any other user name except root.
14. Alter the entry in /etc/security/access.conf as follows:
-:ALL EXCEPT access1 access2 root:ALL
15. Test this entry by having your partner log on as access1 and access2. Both
accounts should now be able to log on.
16. If time permits: Edit the entry so that only access1 and access2 can remotely
log on from your domain:
-:ALL EXCEPT access1 access2:your_DNS_domain_name
17. When you are finished experimenting, either edit the existing file to comment
out all lines, or copy access.conf.orig so that it becomes access.conf .
© 2002 ProsoftTraining All Rights Reserved.
Version 3.07