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