ISBN: 9781467549400 (Paperback Edition) ASIN: B00BLP0V6G (eBook Edition)
|
This book covers three main objectives: 1) to provide a resource to IT administrators who intend to take the new Red Hat Certified System Administrator (EX200) and the Red Hat Certified Engineer (EX300) exams and pass them; 2) to provide a quick and valuable on-the-job resource to Linux/UNIX administrators and programmers and DBAs working in the Linux environment; and 3) to provide an easy-to-understand guide to novice and non-RHEL administrators who intend to learn RHEL. This book is divided into RHCSA and RHCE sections based on the exam objectives. It includes 21 chapters in total and is structured to facilitate readers to grasp concepts, understand implementation procedures, and learn commands, tools, configuration files, log files, and service daemons involved. The RHCSA Section (chapters 1 to 13) covers all the topics required to prepare for the RHCSA exam. Information presented includes general Linux concepts, basic commands, archiving, compression, file manipulation, file security, text editors, shell features, awk programming, hardware management, local installation, package administration, virtualization, network installation, automated installation, boot procedures, kernel management, user & group administration, disk partitioning, file system & swap management, basic firewall, SELinux, TCP Wrappers, basic networking, network interfaces, and DNS, DHCP, and LDAP client configuration. The RHCE Section (chapters 14 to 21) covers all the topics required to prepare for the RHCE exam. Information presented includes automating with scripting, building an rpm package, resource utilization reporting, network logging, advanced firewall, iSCSI, DNS server, Kerberos, routing, Internet services, kernel parameters, NTP client, email, NFS, Samba, FTP, Apache web server, and secure shell server. Each chapter in the book begins with a list of major topics and exam objectives covered in the chapter and ends with a summary followed by review questions and practice lab exercises. Throughout the book, tables, figures, and screen shots have been furnished for ease of understanding. This book includes one sample exam for RHCSA and one sample exam for RHCE in the appendix, and you are expected to accomplish them on your systems using the knowledge and skills gained from reading this book and practicing the exercises and labs presented. |
Certification Resources for Exams EX200 and EX300
|
Exam objective "Build a simple RPM that packages a single file" has been removed from the list of current exam objectives. The Red Hat Certified System Administrator (RHCSA) and the Red Hat Certified Engineer (RHCE) certification exams are performance-based, hands-on practical exams designed for IT professionals. These exams are presented in electronic format. During the exams, the candidates do not have access to the Internet or other printed or electronic documentation except for what comes standard with the RHEL6 operating system software. The official exam objectives are listed at http://www.redhat.com/training/courses/ex200/examobjective for RHCSA and that for RHCE at http://www.redhat.com/training/courses/ex300/examobjective. Visit the URLs for up-to-date and more in-depth information. The exam objectives are covered in sufficient detail in the chapters throughout this book. A list of the exam objectives is presented below along with chapter numbers where the objectives are discussed. RHCSA Specific Skills: Understand and Use Essential Tools:
Operate Running Systems
Configure Local Storage
Create and Configure File Systems
Deploy, Configure, and Maintain Systems
Manage Users and Groups
Manage Security
RHCE Specific Skills: System Configuration and Management
Network Services Network services are an important subset of the exam objectives. RHCE candidates should be capable of meeting the following objectives for each of the network services listed below:
HTTP/HTTPS (chapter 21)
DNS (chapter 16)
FTP (chapter 20)
NFS (chapter 19)
SMB (chapter 20)
SMTP (chapter 18)
SSH (chapter 21)
NTP (chapter 17)
|
|
Firewall A firewall is a protective layer that is configured between a private and a public network to segregate traffic. There are several types of firewalls one of which performs data packet filtering. A data packet is formed as a result of a process called encapsulation whereby the header information is attached to a message during the formation of a packet. The header includes information such as source and destination IP addresses, port, and type of data. Based on pre-defined rules, a firewall intercepts each inbound and outbound data packet, inspects its header information, and decides whether to allow the packet to pass through. A port is defined in the /etc/services file for each network service available on the system, and are typically standardized across all network operating systems including RHEL. Some common services and the ports they listen on are: ftp on port 21, ssh on 22, telnet on 23, postfix on 25, http on 80, and ntp on port 123. RHEL comes standard with a host-based packet-filtering firewall software called iptables that can be used to control the flow of data packets. Another major use of iptables in RHEL is to provide support for Network Address Translation (NAT), which is explained in detail in Chapter 14 “Advanced Firewall, TCP Wrappers, Usage Reporting & Remote Logging”.
# rpm –qa | grep iptables The configuration file for the iptables firewall is the iptables file located in the /etc/sysconfigdirectory and the /etc/rc.d/init.d/iptables is the startup script, which reads the configuration file and loads the rules defined in it. The configuration file may be customized using a text editor, the iptables command, the lokkit command, or the Firewall Configuration tool (system-config-firewall or system-config-firewall-tui). Understanding the iptables Configuration File As mentioned, the /etc/sysconfig/iptables file is the configuration file for the iptables firewall. This file contains all necessary rules needed to control the inbound and outbound traffic on the system. An excerpt from this file is shown below: # cat /etc/sysconfig/iptables Iptables allows you to define tables containing groups of rules called chains with each table related to a different type of packet processing. In the output above, one default table called filter is defined, which includes three pre-defined chains (INPUT, FORWARD, and OUTPUT) with the INPUT chain containing several rules. Each inbound and outbound packet goes through at least one of the configured chains. Packets destined for the local system use the INPUT chain, packets originated from the local system use the OUTPUT chain, and packets that need to be routed to a different network use the FORWARD chain. Chains have a policy called target, which can have a value such as ACCEPT, REJECT, DROP, and LOG. The ACCEPT policy allows a packet to pass through, the REJECT policy throws a packet away and sends a notification back, the DROP policy simply throws a packet away without sending a notification, and the LOG policy sends packet information to the rsyslogd daemon for logging. Also notice the string “state” in the file contents above. Some of the common states are NEW, ESTABLISHED, RELATED, and INVALID. The NEW state identifies packets that are not part of an existing communication, the ESTABLISHED state indicates that the packets are part of an existing communication, the RELATED state signifies packets generated in relation with some other existing communication, and the INVALID state identifies packets that do not match other states. The first rule in the configuration file above will continue to accept all inbound connection requests, the second rule will accept incoming ICMP requests, the third rule will accept all inbound connection requests on the loopback interface, the fourth rule will accept all new matching TCP requests received on port 22, and the last two rules will reject any network packets from any source with the icmp-host-prohibited rejection reason sent back to the source system. It is imperative that you modify the default iptables rules to match the requirements of packet filtering associated with application accessibility. The iptables Command The iptables command is used to modify the firewall rules on the system. This command supports several options, some of which are listed and described in Table 12-1.
Run the iptables command with the –L option to list the rules currently in place on the system: # iptables –L The above output indicates that the INPUT, FORWARD, and OUTPUT chains are set to ACCEPT all traffic as explained in the previous sub-section. Managing iptables Service Start and Stop The iptables service can be started, restarted, and stopped manually. It can also be configured to start automatically at specific run levels. To start the iptables service: # service iptables start iptables: Applying firewall rules: [ OK ] To restart the iptables service: # service iptables restart iptables: Flushing firewall rules: [ OK ] To stop the iptables service: # service iptables stop iptables: Flushing firewall rules: [ OK ] To enable the iptables service to autostart at each system reboot: # chkconfig iptables on To check the status of the iptables service: # service iptables status Table: filter Exercise 12-1: Add and Manage iptables Rules In this exercise, you will first delete all existing rules and then append rules to the filter table to allow inbound HTTP traffic on port 80, reject outbound ICMP traffic without sending a notification back, and forward all inbound traffic to 192.168.2.0/24 network. You will insert a rule to allow the first and subsequent incoming FTP connection requests on port 21 and append a rule to disallow all outgoing connection requests on port 25. You will save all these rules in the /etc/sysconfig/iptables file and make necessary settings so that these rules are loaded each time you reboot the system in multiuser mode. You will restart the iptables service and run the command to ensure that the new rules have taken place. 1. Run the iptables command with the –F option to remove all existing rules: # iptables –F 2. Append a rule to the filter table to allow inbound HTTP traffic on port 80: # iptables –t filter –A INPUT –p tcp --dport 80 –j ACCEPT 3. Append a rule to reject outbound ICMP traffic without sending a notification back: # iptables –A OUTPUT –p icmp –j DROP 4. Append a rule to forward all inbound traffic to 192.168.2.0/24 network: # iptables –A FORWARD –d 192.168.2.0/24 –j ACCEPT 5. Insert a rule to allow the first and subsequent incoming FTP connection requests on port 21: # iptables –I INPUT –m state --state NEW –p tcp --dport 21 –j ACCEPT 6. Append a rule to disallow all existing and new outgoing connection requests on port 25: # iptables –A OUTPUT –m state --state NEW –p tcp --dport 25 –j DROP 7. Save the rules in the /etc/sysconfig/iptables file and restart the firewall to activate the new rule: # service iptables save ; service iptables restart 8. Set the iptables firewall service to autostart at each system reboot, and validate: # chkconfig iptables on 9. Issue the iptables command and check whether the new rules have taken effect: # iptables –L Security Enhanced Linux Security Enhanced Linux (SELinux) is an implementation of the Mandatory Access Control(MAC) architecture developed by the National Security Agency (NSA), with the assistance of other organizations and Linux community, for enhanced, granular security controls in Linux. MAC provides an added layer of protection on top of the standard Linux Discretionary Access Control (DAC) security architecture which includes file and directory permissions, ACLs, and so on. With DAC in use, world-readable user home directories with potentially sensitive data could become the target of unauthorized access. SELinux limits this access by adding appropriate controls on the home directories so that they can only be accessed by authorized processes and users. The added security controls are stored in contexts (or labels) and are applied on files, processes, and users. SELinux controls are fine-grained meaning that if one service on the system is compromised, other services will remain intact. SELinux Contexts for Files, Processes, and Users SELinux contexts define security attributes set on individual files, processes, and users. There are generally four types of attributes associated with the contexts and are referred to as subject, object, action, and level. The subject attribute represents a process or a user, the object attribute identifies a role, the action attribute determines a type, and the level determines the SELinux security level in the form of sensitivity:category. RHEL 6 supports multiple sensitivity levels starting from s0 with 1024 different categories within each sensitivity level. SELinux allows you to set security policies using type enforcement and role-based access control (RBAC). The type enforcement element identifies the domains for processes and the types for files. The RBAC, or simply a role, element controls which domains and types can be accessed. Each subject has an associated domain and each object within the domain has an associated type. Likewise, each subject has an associated role to ensure that the system and user processes are separated. By default, any process or service that is not explicitly permitted is denied. Use the –Z option with the ll, ps, and id commands to view the current security contexts on files, processes, and users respectively. The following shows the four attributes currently set on the install.log file and the Desktop directory in the /root directory: # ll –Z /root The subject (user) field in the output provides an SELinux user name (system_u, unconfined_u, root, user_u, etc.) that is mapped to a Linux user (root in this case); the object (role) field defines an SELinux role (object_r, system_r, etc.); the action (type) field determines an SELinux type (admin_home_t, user_home_t, etc.); and the level (level) field determines the level of sensitivity & category used as defined in the /etc/selinux/targeted/setrans.conf file. Contexts for all files in the system are stored in the /etc/selinux/targeted/contexts/files/file_contexts file. Notice the dot next to the public execute permission in the first column of the output of the llcommand. This dot tells you that the SELinux context is set on this file or directory. By default, files created in a directory inherit the security contexts set on the directory. If a file is moved to another directory, it takes its security contexts with it, which may differ from the destination directory’s contexts. In the same manner, you can use the –Z option with the ps command to view the SELinux contexts for running processes: # ps –eZ The subject (user) field in the output provides an SELinux user name (system_u, unconfined_u, root, user_u, etc.) that is mapped to a Linux user; the object (role) field defines an SELinux role (object_r, system_r, etc.) associated with the system process such as daemons; the action (type) field determines what sort of protection is applied to the process (init_t, httpd_t, public_content_t, sshd_exec_t, kernel_t, etc.); and the level (level) field determines the level of sensitivity & category used. Any process that is unprotected will have the action set to unconfined_t. Likewise, you can use the –Z option with the id command to view the security contexts associated with your Linux user account: # id –Z If you run the above command as a normal user, you will get the same output. In RHEL, all Linux users, including root, run unconfined by default, which entails that they have full access to the system and are only restricted by the DAC restrictions. The above output indicates that the root user is mapped to the SELinux unconfined_u user (subject), running as unconfined_r role (role) in the unconfinred_t domain (type) with sensitivity level 0 (level). SELinux user mappings with Linux users may be viewed using the semanage command. But before you are able to do that, ensure that packages policycoreutils and policycoreutils-python are installed on the system. These packages include several SELinux management commands such as restorecon, chcon, secon, setfiles, semodule, and semanage. You may also want to install the policycoreutils-gui package so that you can manage SELinux graphically using the SELinux Configuration tool system-config-selinux. # rpm –qa | grep policycoreutils If any of these packages are missing on the system, use one of the package management commands explained in Chapter 06 “Package Management” to install it. Execute the semanage command with the login –l arguments to view the default user mappings: # semanage login –l The above output shows Linux users in the first column mapped to SELinux users in the second column, and the associated sensitivity & category level in the third column. As stated above, all users including the root user run unconfined by default. If you want to switch a user such as user1 into the staff_u role, run the semanage command. The following example first runs the id command with the –Z option to confirm that user1 is running unconfined and then it switches the role: $ id –Z Now log off and log back in as user1 and run the id command with the –Z option again to confirm the change: $ id –Z SELinux Configuration File The key configuration file for SELinux is /etc/selinux/config and the default contents of it are displayed below: # cat /etc/selinux/config The SELINUX directive in the file defines the activation mode for SELinux. Enforcing activates SELinux and allows or denies actions based on configured settings. Permissive activates SELinux, but permits all actions. It records all security violations; however, it does not hinder actions being taken. This mode is useful from a troubleshooting perspective, and developing or tuning SELinux security policy. The third option is to completely disable it. When activated in the enforcing mode, the SELINUXTYPE directive dictates the type of policy to be enforced. SELinux supports two policies: targeted and mls (multi-level security). With the targeted policy in place, you can modify SELinux restrictions set on files, processes, and users. The mls policy, on the other hand, allows you to tighten security at more granular levels. The default policy in RHEL6 is the targeted policy. |
||||||||||||||||||||||||||||||||||||||||||
| Chapter 01: Local Installation Configuring Network Interfaces: 12(ii). The IP address is 192.168.2.200. Chapter 02: Basic Linux Commands Answers to Chapter Review Questions: Answer to #1 is correct, however, it should say "False. The wall command ......." Answers to Chapter Review Questions: Answer to #22 is "False". LAB 2-2: The last sentence should be read as "What additional information does the id command provide that the groups command does not." Chapter 03: Files & Directories Page 76 under Comparing File Contents: testfile2 contains "apple" and not "Apple". Page 78 the first find command example should be: find /dev -iname vol* (and not vg00*) Answers to Chapter Review Questions: Remove #12, and read #13 as #12, #14 as #13, and so on. Answers to Chapter Review Questions: Answer to #14 should be read as: "The egrep command provided will display all lines from the /etc/passwd file containing the words root or qemu." Answers to Chapter Review Questions: Answer to #15 is: ". . . . . . . sorted by month and day." Chapter 04: File Permissions, Text Editors, Text Processors & The Shell Page 92: The last paragraph should be read as "The pre-defined initial permissions ................. Even if the umask is set to 000, the new ....... " Exercise 4-3: Step #3 is: usermod -G sdatagrp aghori usermod -G sdatagrp user1 Page 115: Paragraph #5 should be read as "The HISTSIZE variable is pre-defined in the /etc/profile initialization file. The EDITOR ....." Page 119: The second command line should be: $ ll /etc | grep -v root | grep -iv apr | nl Answers to Chapter Review Questions: Answer to #7 is "False". Chapter 05: Processes, Scheduling & Basic Hardware Page 133 at the very beginning, the argument passed to the pgrep and pidof commands is "crond" and not "smbd" Page 135 the second sentence in the last paragraph should be read as "This means that, by default, all users are authorized to submit an at and cron job." Answers to Chapter Review Questions: Answer to #9 is "False". Chapter 06: Package Management Page 158 under Querying One or More Packages, the correct command in the second example is "rpmquery -f /bin/zsh". Exercises 6-4 and 6-5: You do not need to download and install createrepo package for these exercises. Page 171 under Installing and Updating Packages and Package Groups, the last example description should read "To update the virtualization group to the latest version:" Answer to Q4 "The rhn_register command". Lab 2, the path to be used should be /var/yum/repos.d/local. Chapter 07: Virtualization & Network Installation Exercise 7-1 and 7-2: If the semanage command is not available on your system, install the policycoreutils-python package using yum. Exercise 7-1 and 7-2: If you wish to unmount the iso image, you will need to run "cd .." to move out of the /mnt directory. Exercise 7-5: If the network installation cannot find the install.img file, try disabling the firewall (Exercises 7-1 and 7-2 whichever applies) or, open port (21 or 80) without limiting it to the 192.168 network (iptables -I INPUT -p tcp --dport 80 -j ACCEPT). Chapter 08: Linux Boot Process & Kernel Management Page 214: The first example under The shutdown command should be read "shutdown -r 5". Page 223 under Sequencer, Configuration and Initialization Directories heading: There are seven sequencer directories and not six. Answer to Question #8: The location of the grub.efi file on UEFI-based systems is /boot/efi/EFI/redhat. Chapter 09: Disk Partitioning Exercise 9-3 Step #6: The grep command should be run for "vdb" and not "vda". Exercise 9-5 Step #2: Specify the End as 3001m. Exercise 9-7: Delete only vdc2 (leave vdc1 intact) Exercise 9-11: Remove lvol0 logical volume also as part of this exercise. Managing Disk Space Using the LVM Configuration Tool: By default, this tool is not installed. Use the yum command to install the system-config-lvm package from a configured repository. Answer to Question #19: False Lab 9-3: Use vdb and vdc disks for this lab. Chapter 10: File Systems & Swap In the description of the second column under the "Automatically Mounting a file system at System Reboots", the second sentence is "In the case of a swap partition, you will see ................. " Exercise 10-4 Step 4 should say "Run the fsck command and specify the location of the first backup superblock to repair the primary superblock:" Exercise 10-6 should be read as "In Exercise 6-5 of Chapter 06 ................." Answer to Q40: " ............. to the owner of file and user2, ....... " Chapter 11: Users & Groups Exercise 11-6 step 3 should state "Substitute user2 and user3 ....... " Chapter 12: Firewall & SELinux Page 354: 3rd paragraph last line: .... unconfined_t domain (type) .... Table 12-2: chcon command. The description should be read as "Changes the SELinux security context on files. Changes do not survive file system relabeling." Table 12-2: semanage command. The description should be read as "Manages SELinux policies. Changes survive file system relabeling." Exercise 12-3 Step 9, the command is "semanage fcontext -a -s xxxx" Answers to Chapter Review Questions: Answer to #10 is "The REJECT policy sends a notification back while the DROP policy does not". Question #13 should be read as "Which command can be used to ensure modified SELinux contexts survive file system relabeling, chcon or semanage?" Chapter 13: Networking, Network Interfaces & DNS, DHCP and LDAP Clients The last paragraph in Summary should have "LDAP" in the second line and not DHCP. Chapter 18: Electronic Mail Exercise 18-1 Step 8: The command to check the syntax is postfix (and not postconf). Chapter 21: Apache Web Server & Secure Shell Server Exercise 21-2 step 4: The directory location is /var/www/insider/webcontents. |