Lab Questions

 < Day Day Up > 



Lab 1

1. 

You have a growing network of Linux computers, and have to maintain users and passwords on each of these computers on a daily basis. You're having to update administrative files such as /etc/passwd on a number of computers. What can you do to simplify your task?

you can set up an nis server to maintain a common database of usernames and passwords. this should include at least the basic password database files, such as /etc/passwd, /etc/group, /etc/shadow, and /etc/gshadow, as defined in the /var/yp/makefile configuration file. before you can set up an nis server, you need to make sure you have the packages that you need, specifically the ypserv and yp-tools rpm packages. you can check and install these packages using the rpm command, as described throughout the book. once installed, you ll want to start the ypserv service in the /etc/rc.d/init.d directory. you ll also want to use the chkconfig command to make sure this service starts the next time you boot this computer. you ll need to set up an nis domain name with the domainname command. you can then configure the nis master server with the following command: # /var/lib/yp/ypinit -m this command assumes the local computer should also be configured as an nis client on the given network. you re then prompted to enter the hostnames of other computers that you want to add to the nis domain. on a larger network, it can be helpful to have a backup for the nis master server. if the nis master server hostname is nismaster, you can set this up with the following command: # /var/lib/yp/ypinit -s nismaster you can then set up clients by configuring the ypbind service on each computer on the nis domain. make sure that the ypbind service starts the next time each computer restarts with a command such as: # chkconfig --level 35 ypbind on

Answers

1. 

You can set up an NIS server to maintain a common database of usernames and passwords. This should include at least the basic password database files, such as /etc/passwd, /etc/group, /etc/shadow, and /etc/gshadow, as defined in the /var/yp/Makefile configuration file.

Before you can set up an NIS server, you need to make sure you have the packages that you need, specifically the ypserv and yp-tools RPM packages. You can check and install these packages using the rpm command, as described throughout the book. Once installed, you'll want to start the ypserv service in the /etc/rc.d/init.d directory. You'll also want to use the chkconfig command to make sure this service starts the next time you boot this computer.

You'll need to set up an NIS domain name with the domainname command. You can then configure the NIS master server with the following command:

# /var/lib/yp/ypinit -m

This command assumes the local computer should also be configured as an NIS client on the given network. You're then prompted to enter the hostnames of other computers that you want to add to the NIS domain.

On a larger network, it can be helpful to have a backup for the NIS master server. If the NIS master server hostname is NISmaster, you can set this up with the following command:

# /var/lib/yp/ypinit -s NISmaster

You can then set up clients by configuring the ypbind service on each computer on the NIS domain. Make sure that the ypbind service starts the next time each computer restarts with a command such as:

# chkconfig --level 35 ypbind on 

Lab 2

2. 

You want to set up a RHEL 3 computer as a secure Web server. To keep that system secure, you'll want to configure an appropriate firewall, and disable any services that you don't need. What should you do?

if you want to set up a rhel 3 computer as a secure web server, it s a straightforward process. you ll want to set up a firewall to block all but the most essential ports. this should include tcp/ip ports 80 and 443, which allow outside computers to access your regular and secure web services. the easiest way to set this up is with the text-mode red hat security level configuration tool, which you can start with the lokkit no change to this in rhel? or redhat-config-securitylevel-tui commands ( lokkit is now a front-end to redhat-config-securitylevel-tui ). once you re in the red hat tool, take the following steps: a. enable the firewall. this configures a basic set of firewall rules that prohibits access except for requests that come from inside the firewall. b. click customize. this opens the firewall configuration customize window. in the allow incoming section, activate the www (http) option. this allows outside access to your regular web site. c. in the other ports text box, type the following, which opens the ports associated with a standard secure web service: 443:tcp,443,udp d. click ok. click ok again to exit from the firewall configuration tool. e. enter the following command to check your resulting firewall. # iptables -l f. once you ve configured a web service as described in chapter 7 , you ll be able to access both the regular and secure web servers from remote computers.

Answers

2. 

If you want to set up a RHEL 3 computer as a secure Web server, it's a straightforward process. You'll want to set up a firewall to block all but the most essential ports. This should include TCP/IP ports 80 and 443, which allow outside computers to access your regular and secure Web services.

The easiest way to set this up is with the text-mode Red Hat Security Level configuration tool, which you can start with the lokkit no change to this in RHEL?or redhat-config-securitylevel-tui commands (lokkit is now a 'front-end' to redhat-config-securitylevel-tui). Once you're in the Red Hat tool, take the following steps:

  1. Enable the firewall. This configures a basic set of firewall rules that prohibits access except for requests that come from inside the firewall.

  2. Click Customize. This opens the Firewall Configuration - Customize window. In the Allow Incoming section, activate the WWW (HTTP) option. This allows outside access to your regular Web site.

  3. In the Other Ports text box, type the following, which opens the ports associated with a standard secure Web service:

    443:tcp,443,udp
  4. Click OK. Click OK again to exit from the Firewall Configuration tool.

  5. Enter the following command to check your resulting firewall.

    # iptables -L
  6. Once you've configured a Web service as described in Chapter 7, you'll be able to access both the regular and secure Web servers from remote computers.

Lab 3

3. 

You want to make sure even the root user has to enter the root password when opening Red Hat administrative tools. You can do this by modifying the appropriate file in the /etc/pam.d directory. Try this out with the Red Hat Security Configuration tool.

to make lab work, you ll need to modify the security level configuration tool using the redhat-config-securitylevel file in the /etc/pam.d directory. open this file in the text editor of your choice. the first two commands allow users to start this tool automatically: authsufficientpam_rootok.so authsufficientpam_timestamp.so the first command checks if you re the root user. the second command checks to see if you ve opened the given tool recently, based on the conditions of the pam_timestamp module. if you deleted (or commented out) these commands, all users, including the root user, will have to enter the root password when opening this tool. to do so, take the following steps: a. open the red hat security level configuration tool in a command line in your gui. make sure it opens normally. when it does, close it without making any changes to your current firewall. b. back up the current pam module for the security level configuration tool to your home directory: # cp /etc/pam.d/redhat-config-securitylevel ~ c. open the file in /etc/pam.d in the text editor of your choice. comment out the first two commands in this file. d. save the file. if you re not already logged into the gui as the root user, log out of the gui. log back into the gui as root. e. try opening the red hat security level configuration tool. click main menu | system settings | security level. what happens?

Answers

3. 

To make lab work, you'll need to modify the Security Level Configuration tool using the redhat-config-securitylevel file in the /etc/pam.d directory. Open this file in the text editor of your choice. The first two commands allow users to start this tool automatically:

auth    sufficient    pam_rootok.so auth    sufficient    pam_timestamp.so

The first command checks if you're the root user. The second command checks to see if you've opened the given tool recently, based on the conditions of the pam_timestamp module. If you deleted (or commented out) these commands, all users, including the root user, will have to enter the root password when opening this tool. To do so, take the following steps:

  1. Open the Red Hat Security Level Configuration tool in a command line in your GUI. Make sure it opens normally. When it does, close it without making any changes to your current firewall.

  2. Back up the current PAM module for the Security Level Configuration tool to your home directory:

    # cp /etc/pam.d/redhat-config-securitylevel ~
  3. Open the file in /etc/pam.d in the text editor of your choice. Comment out the first two commands in this file.

  4. Save the file. If you're not already logged into the GUI as the root user, log out of the GUI. Log back into the GUI as root.

  5. Try opening the Red Hat Security Level Configuration tool. Click Main Menu | System Settings | Security Level. What happens?

Lab 4

4. 

In this lab, you'll see how you can limit access to specific users through the PAM listfile module. In this lab, you'll limit access to the Secure Shell that's covered in Chapter 11. Assume that you have four users on your system: michael, donna, randy, and nancy, and want to limit access to randy and nancy. What do you need to do to make this happen?

to limit access to a pam configured tool to specific users, you need a bit of help from the pam listfile.so module, /etc/security/pam_listfile.so. with the following steps, i m assuming that you need to configure the four specified users; you can configure existing users of your choice. a. create the users michael, donna, randy, and nancy. set up passwords for these users. there are a number of ways to do so; i believe the simplest is with the following commands. naturally, you ll need to enter an appropriate password for each user when prompted. # useradd michael; passwd michael # useradd donna; passwd donna # useradd nancy; passwd nancy # useradd randy; passwd randy b. navigate to the /etc/pam.d directory. look to see if the sshd file exists; if not, you ll have to install it from the openssh-server rpm. while the technique is described in chapter 11 , it is no different from the technique used to install other services throughout this book. it should already be installed by default on a rhel 3 server computer. c. open the /etc/pam.d/sshd file in the text editor of your choice. by default, the first two commands should look like: auth required pam_stack.so service=system-auth auth required pam_nologin.so d. after the final auth command, enter the auth command that you need to point to a file with allowed users. (you could certainly use the sense=deny switch and configure a file with disallowed users.) auth required pam_listfile.so onerr=succeed item=user \ sense=allow file=/etc/special e. since you want users nancy and randy to have access to the secure shell service, you ll want to add their usernames to the /etc/special configuration file, one username per line. f. try logging into the secure shell service with a prohibited username such as michael: # ssh michael@localhost g. if you haven t logged into the secure shell service before from this computer, you ll be prompted to verify the authenticity of the unknown computer. since it s the local computer, you can assume it s reasonably safe; type yes and press enter . h. enter user michael s password. what happens? can you get access? i. press ctrl-c to exit from the secure shell login process. try again with donna s username and password. what happens? is this what you expected? j. try again with the allowed users. k. what happens if you return to the /etc/pam.d/sshd file and change sense=allow to sense=deny ?

Answers

4. 

To limit access to a PAM configured tool to specific users, you need a bit of help from the PAM listfile.so module, /etc/security/pam_listfile.so. With the following steps, I'm assuming that you need to configure the four specified users; you can configure existing users of your choice.

  1. Create the users michael, donna, randy, and nancy. Set up passwords for these users. There are a number of ways to do so; I believe the simplest is with the following commands. Naturally, you'll need to enter an appropriate password for each user when prompted.

    # useradd michael; passwd michael # useradd donna; passwd donna # useradd nancy; passwd nancy # useradd randy; passwd randy
  2. Navigate to the /etc/pam.d directory. Look to see if the sshd file exists; if not, you'll have to install it from the openssh-server RPM. While the technique is described in Chapter 11, it is no different from the technique used to install other services throughout this book. It should already be installed by default on a RHEL 3 server computer.

  3. Open the /etc/pam.d/sshd file in the text editor of your choice. By default, the first two commands should look like:

    auth required   pam_stack.so service=system-auth auth required   pam_nologin.so
  4. After the final auth command, enter the auth command that you need to point to a file with allowed users. (You could certainly use the sense=deny switch and configure a file with disallowed users.)

    auth required pam_listfile.so onerr=succeed item=user \ sense=allow file=/etc/special
  5. Since you want users nancy and randy to have access to the Secure Shell service, you'll want to add their usernames to the /etc/special configuration file, one username per line.

  6. Try logging into the Secure Shell service with a prohibited username such as michael:

    # ssh michael@localhost
  7. If you haven't logged into the Secure Shell service before from this computer, you'll be prompted to verify the authenticity of the unknown computer. Since it's the local computer, you can assume it's reasonably safe; type yes and press ENTER.

  8. Enter user michael's password. What happens? Can you get access?

  9. Press CTRL-C to exit from the Secure Shell login process. Try again with donna's username and password. What happens? Is this what you expected?

  10. Try again with the allowed users.

  11. What happens if you return to the /etc/pam.d/sshd file and change sense=allow to sense=deny?

Lab 5

5. 

You want to set up Telnet service on your internal LAN, accessible only to one specific IP address. You want to block access from outside the LAN. Assume that your LAN's network address is 192.168.1.0, and the IP address of the computer that should get access is 192.168.1.33. For the purpose of this lab, feel free to substitute the IP address of a second Linux computer on your network. What do you do?

when you set up any xinetd service such as telnet, there are several steps in the process. you ll need to modify the xinetd telnet configuration file, and set up filtering in one of three ways: in the /etc/xinetd.d/telnet configuration file, through tcp_wrappers, or the appropriate firewall commands: a. first, you want to enable telnet. make sure that the krb5-telnet rpm is installed. b. activate telnet. use the chkconfig telnet on command to revise the /etc/xinetd.d/telnet configuration script. c. edit the /etc/xinetd.d/telnet configuration file. add the only_from = 192.168.1.33 line. (if you have another computer on your network with a private ip address, substitute accordingly in all steps in this lab.) d. save the configuration file and reload the xinetd service script with the service xinetd reload command. try accessing telnet from the local computer. what happens? e. try accessing telnet from the computer with the ip address of 192.168.1.33. what happens? try again from a different computer on your lan. f. restore the previous /etc/xinetd.d/telnet configuration file. don t forget to reload the xinetd service script with the service xinetd reload command. g. edit /etc/hosts.deny. add the telnetd : all except 192.168.1.33 line. h. try accessing telnet from the computer with the ip address of 192.168.1.33. what happens? try again from a different computer on your lan. i. restore the previous /etc/hosts.deny file. j. save any existing iptables chains. back up /etc/sysconfig/iptables, if that file currently exists to ~/bak.iptables. k. flush current firewall rules with the iptables -f command. l. block the telnet port, 23, for all ip addresses except 192.168.1.33 with the iptables -a inpu t -s ! 192.168.1.33 -p tcp --dport 23 -j drop command. m. try accessing the telnet server from the computer with the ip address of 192.168.1.33. what happens? try again from a different computer on your lan. n. flush current firewall rules with the iptables -f command. o. restore any previous firewall rules with the iptables-restore - ~/bak.iptables command. p. bonus lab: repeat these commands for other services and networks.

Answers

5. 

When you set up any xinetd service such as Telnet, there are several steps in the process. You'll need to modify the xinetd Telnet configuration file, and set up filtering in one of three ways: in the /etc/xinetd.d/telnet configuration file, through tcp_wrappers, or the appropriate firewall commands:

  1. First, you want to enable Telnet. Make sure that the krb5-telnet RPM is installed.

  2. Activate Telnet. Use the chkconfig telnet on command to revise the /etc/xinetd.d/telnet configuration script.

  3. Edit the /etc/xinetd.d/telnet configuration file. Add the only_from = 192.168.1.33 line. (If you have another computer on your network with a private IP address, substitute accordingly in all steps in this lab.)

  4. Save the configuration file and reload the xinetd service script with the service xinetd reload command. Try accessing Telnet from the local computer. What happens?

  5. Try accessing Telnet from the computer with the IP address of 192.168.1.33. What happens? Try again from a different computer on your LAN.

  6. Restore the previous /etc/xinetd.d/telnet configuration file. Don't forget to reload the xinetd service script with the service xinetd reload command.

  7. Edit /etc/hosts.deny. Add the telnetd : ALL EXCEPT 192.168.1.33 line.

  8. Try accessing Telnet from the computer with the IP address of 192.168.1.33. What happens? Try again from a different computer on your LAN.

  9. Restore the previous /etc/hosts.deny file.

  10. Save any existing iptables chains. Back up /etc/sysconfig/iptables, if that file currently exists to ~/bak.iptables.

  11. Flush current firewall rules with the iptables -F command.

  12. Block the Telnet port, 23, for all IP addresses except 192.168.1.33 with the iptables -A INPUT -s ! 192.168.1.33 -p tcp --dport 23 -j DROP command.

  13. Try accessing the Telnet server from the computer with the IP address of 192.168.1.33. What happens? Try again from a different computer on your LAN.

  14. Flush current firewall rules with the iptables -F command.

  15. Restore any previous firewall rules with the iptables-restore < ~/bak.iptables command.

  16. Bonus Lab: Repeat these commands for other services and networks.

Lab 6

6. 

You want to set up a secure Web server on your corporate LAN that supports inbound requests from your LAN and the Internet, but you do not want any of these requests from the Internet to get into your intranet. What can you do?

 scenario 1: cost is not an object. this means you can build a dmz using two firewalls and a separate web server, all running linux. you should have the web server dedicated only to the web. you configure two more linux hosts, each with two network cards, and essentially isolate the intranet behind one firewall. you then put the web server in the middle, placing the second firewall between the web server and the internet. you configure the firewall on the intranet with ip masquerading to ensure anonymity for all your intranet hosts. scenario 2: you have one old computer available, and the web server is a separate computer. use your one computer as the firewall between you and the internet and only forward http packets to the web server ip address directly; use nat for all intranet requests going out to the internet for http and ftp. disallow all other services.

Answers

6. 

Scenario 1: Cost is not an object. This means you can build a DMZ using two firewalls and a separate Web server, all running Linux. You should have the Web server dedicated only to the Web. You configure two more Linux hosts, each with two network cards, and essentially isolate the intranet behind one firewall. You then put the Web server in the middle, placing the second firewall between the Web server and the Internet. You configure the firewall on the intranet with IP masquerading to ensure anonymity for all your intranet hosts.

Scenario 2: You have one old computer available, and the Web server is a separate computer. Use your one computer as the firewall between you and the Internet and only forward HTTP packets to the Web server IP address directly; use NAT for all intranet requests going out to the Internet for HTTP and FTP. Disallow all other services.



 < Day Day Up > 



RCHE Red Hat Certified Engineer Linux Study Guide[c] Exam (Rh302)
RCHE Red Hat Certified Engineer Linux Study Guide[c] Exam (Rh302)
ISBN: 71765654
EAN: N/A
Year: 2003
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net