Cheat Sheet
Articles and Tips:
01 Oct 2005
This is the final article in a four-part series started several months ago on the certifications from LPI, the (Linux Professional Institute). The previous three articles gave an overview of the certifications and focused on two of the four exams (101 and 102) you must pass to obtain Level I (Junior Level Administrator) and one of the two exams (201) you must pass to obtain Level II (Intermediate Level Administrator) certification. Both levels require passing two exams that are predominantly multiple choice, but peppered with difficult fill-in-the-blank questions. (See past issues of Novell Connection.)
This article focuses on the topics making up the final test required to complete the Level II certification: Exam 202. Not all of the topics are evenly weighted, so take weighting into account and focus your study time accordingly if you find yourself in a pinch. The weighting (roughly equivalent to percentages) of each of the seven topics on this exam follows:
Topic
|
Weighting
|
System Security |
20 |
Mail & News |
18 |
Networking Configuration |
16 |
DNS |
16 |
Web Services |
12 |
Network Client Management |
12 |
Network Troubleshooting |
2 |
Note: The numbers add to 96 rather than to 100 because of an inexact correlation between the weighting and percentages.
Note: A quick glance at the topics should immediately draw your attention to the fact that this is a networking exam. If your focus is on system administration and not network administration, this exam is not for you.
If you want to break down the areas to study even further, consider the weighting of each objective and organize them by importance. When this is done, the results are as shown in Table 1.
This article examines the concepts and utilities and their purposes, which you must know for this exam. The topics are presented in order of their overall weighting on the exam.
System Security
Within this topic is a fairly even division between the theoretical and practical. You are expected to understand the descriptive side of security concepts (network address translation, common practices and so on), as well as how to actually implement prescriptive measures using a few commands. Table 2 lists the topics to know for this section of the test.
Mail and News
While these topics might appear simplistic, they make up the second highest weighting on this exam. Know that every major Linux distribution includes some type of mail server, and the exam focuses more on sendmail rather than anything simpler, such as Postfix. You should know that the Simple Mail Transfer Protocol (SMTP) is used to send mail between mail servers and that mail is retrieved by clients using the Post Office Protocol (POP) and/or Internet Message Access Protocol (IMAP). You can find more information on the workings of sendmail at sendmail.org.
SMTP is an IP-based protocol that runs on port 25, while POP3, which is the latest version, uses port 110, and IMAP uses port 143. If you don't need the server to act as a mail server, it is highly recommended that you disable the SMTP service. The primary configuration file for sendmail is /etc/sendmail.cf. Within that file, it can specify other files to be used for specific purposes, the most common of which are:
/etc/aliases--for raw aliases of local users/accounts. The syntax is alias: user. If there are more users than one, their names are separated by commas.
/etc/aliases.db--is the database for aliases
/etc/mail/genericstable--add entries to this file for the outside world to see the generic ISP address instead of the local one
/etc/mail/virtusertable--add aliases for virtual domains hosted on the same server
/var/state/sendmail.st--statistics about operations
/var/spool/mqueue--the mail queue
You can use the following utilities with sendmail:
mailq--shows the status of what exists in the mail queue
newaliases--builds/rebuilds the /etc/aliases file
sendmail--the service can also be called as an executable to show values and perform operations
Table 1: The weighting of each exam objective
Objective
|
Topic Area
|
Weight (dbl for percent)
|
Basic Networking Configuration |
Network Configuration |
5 |
Using Sendmail |
Mail & News |
4 |
Advanced Network Configuration and Troubleshooting |
Network Configuration |
3 |
Managing Mail Traffic |
Mail & News |
3 |
Create and Maintain DNS Zones |
DNS |
3 |
Securing a DNS Server |
DNS |
3 |
Security Tasks |
System Security |
3 |
Basic BIND 8 Configuration |
DNS |
2 |
Implementing a Web Server |
Web Services |
2 |
Maintaining a Web Server |
Web Services |
2 |
Implementing a Proxy Server |
Web Services |
2 |
DHCP Configuration |
Network Client Management |
2 |
PAM Authentication |
Network Client Management |
2 |
Configuring a Router |
System Security |
2 |
Securing FTP Servers |
System Security |
2 |
Secure shell (OpenSSH) |
System Security |
2 |
Configuring Mailing Lists |
Mail & News |
1 |
Serving News |
Mail & News |
1 |
NIS Configuration |
Network Client Management |
1 |
LDAP Configuration |
Network Client Management |
1 |
TCP_wrappers |
System Security |
1 |
Troubleshooting Network Issues |
Network Troubleshooting |
1 |
You should also know the Internet News Daemon (innd) is used for NNTP (Network News Transfer Protocol) feeds. It runs on port 119. Majordomo2 is the latest version of the list server.
Procmail is a Unix/Linux mail processing utility that has the ability to filter mail based on a number of criteria. Though the FAQ for procmail is called a mini-faq, the document is anything but small and can be found at: www.zer0.org/procmail/mini-faq.html.
Networking Configuration
Most of the utilities under this domain have appeared before on other exams. (See Table 3.) They appear again because LPI wants to make certain you are familiar with this handful of utilities.
DNS
To understand the Domain Name System (DNS), you must first grasp the concept of name resolution and why it is important. It's safe to say that most people can't remember a large number of 32-bit binary numbers. This is a shame in many ways, for it is by using unique 32-bit binary numbers that every host on the Internet is able to differentiate itself one from another. Converting it to a decimal number helps a bit, but not much.
The simplest solution is to use Fully Qualified Domain Names, such as www.novell.com. Because the host name closely resembles the company name, the odds are much better that you'll be able to memorize this entity than if it were a digital number or binary number. What's needed is the means to translate the text into the digital number.
There are two ways of resolving host names to IP addresses. Keep in mind that in all cases, the resolution is to IP addresses because they are the unique values that truly identify the site/host. Regardless of the resolution method implemented, all resolution is done by applications and occurs at the seventh layer (Application) of the OSI model.
Many years ago (when TCP/IP was new), networks were small consisting of only a handful of hosts at each site. There might have been dozens of users accessing the network, but they were doing so on dumb terminals connected to a host. The majority of users' work would be done on one host, with an occasional need to interact with another host, such as sending e-mail to another user, access a file, and so forth.
In those days--and in that environment if it still exists today--the usage of /etc/hosts files are ideal for name resolution. HOSTS files are static ASCII-text files that must reside on each host and hold the information needed to resolve names in the form of columns. As ASCII text files, you can create and edit HOSTS files with any text editor, including the simplest ones each operating system offers. Use the pound sign (#) as a comment character. It causes the line to be ignored from the location the character is found to the end of the line.
In the early days of the Internet, a single HOSTS file was routinely updated and downloaded to all hosts for name resolution. The major problem with the HOSTS file method of resolution, though, is that it must exist on every host, and changes must be made to every copy to take effect.
DNS, or Domain Name Service/Server, solves this problem for large networks. Instead of putting an ASCII file locally for every host to use, the hosts access a server that resolves the name for them. First introduced in 1984, it allows the host names to reside in a database that can be distributed among multiple servers. The distribution decreases the load on any one server and allows for more than one point of administration. It also allows the database size to be virtually unlimited because more servers can be added to handle additional parts of the database.
Configuring a client to use DNS is simply a matter of supplying it with the IP address of the server offering this service. On operating systems such as Linux, you can specify the DNS server in the ASCII file resolv.conf found in the /etc directory.
Table 2 system security topic
Topic
|
Comment
|
.rhosts and .shosts |
Host-based authentication is accomplished through the use of these files. The use of the .rhosts file carries over to the early days of TCP/IP and the rlogin server: entries in this file allow(ed) users to go from server to server without needing to authenticate again as long as the remote host that the user is currently on is a trusted host. The .shosts file serves the same purpose but replaces insecurity for security and works with the SSH secure shell. Related files include hosts.allow and hosts.deny, which are polar opposites of each other. |
/etc/passwd, /etc/services, inetd.conf, routed, tcpd, xinetd |
Knowledge of these standard files/services has been required since the beginning level exams and there is nothing new about them you need to know here. |
/etc/ssh/sshd_config |
The standard SSH server configuration file is /etc/ssh/sshd_config. In addition to it, the /etc/ssh/ssh_config file serves as a system-wide configuration file for the SSH client. Look through both of them and know their syntax before signing up for the exam. |
/proc/sys/net/ipv4 |
The settings within here can be used for a variety of configuration purposes. For example, to turn on IP forwarding, simply set the value of ip_forward to 1: echo "1" > /proc/sys/net/ipv4/ip_forward (when off, the value is zero). |
~/.ssh/identity.pub and ~/.ssh/authorized_keys |
To set up SSH between two hosts at different sites, you can create the identity.pub file and append it to the authorized_keys file. A great source of information on this is posted on Charles Curley's Notes on OpenSSH at www.charlescurley.com/OpenSSH.html. |
chroot |
The chroot utility, mentioned when studying for the 201 exam, allows you to run a command with a different root directory. That topic is expanded upon for this exam and you should be familiar with the concept of a chroot jail which restricts untrusted applications to running within a specified area only. |
Configure an FTP server |
You need to know how to configure an anonymous server for downloads only, uploads only, and for both purposes, as well as configure each that does not allow for anonymous connections. Given a scenario, you should know which configuration option works best. For example, a publishing house needing to get chapters from authors in the field to be edited in-house would need an FTP server that allows the authors to upload files, but not download anything and security measures need to be in place to keep one author from seeing the entries posted by another. Know the intricacies of ftpaccess, ftpgroups, and ftpusers. You must also know how to test for the presence of anonymous FTP servers. A great article on Linux FTP Server Setup can be found at www.siliconvalleyccie.com/linux-hn/ftp-server.htm. |
Configure filtering rules |
Filters work as restrictions, limiting what traffic is allowed through, and are often mentioned in conjunction with server/service hardening. Filter rules can also be applied on internal users, limiting what they can access outside the network. This reduces the chances of their stumbling across a virus or other miscreant at a questionable site and increases (theoretically) their productivity. |
Configure sshd |
The sources mentioned already should be referenced in order to understand how to configure OpenSSH. Topics to pay particular attention to are how to allow/deny root logins and enable/disable X forwarding. You also need to know how to "configure port forwarding to tunnel an application protocol over SSH, configure SSH to support the SSH protocol versions 1 and 2, disable non-root logins during system maintenance, configure trusted clients for SSH logins without a password, and make multiple connections from multiple hosts to guard against loss of connection to remote host following configuration changes." |
Configure tcpwrappers |
The tcpwrappers package attempts to overcome the default insecure nature of TCP/IP by providing daemons (tcpd, tcpdchk, tcpdmatch and so on) that can be configured to allow connections to specified servers from only certain hosts or subnets. |
IP masquerading |
Masquerading occurs when a user attempts to have their host appear as if it is another. Thus, an untrusted host tries to look as if it is a trusted one. To combat this, you should severely limit what is in /etc/exports. |
ipchains and iptables |
ipchains are used to create a firewall on Linux 2.2.x and iptables is a generic implementation that basically superceded it as of 2.4.x. Both allow packet filtering based upon defined rules and then accept or deny traffic as you specify (accept all packets from other networks within your organization, but deny packets from private networks, for example). |
Kerberos |
Kerberos uses "realms" and distributed keys to implement cryptography through a Key Distribution Center (KDC). For this exam, you should know how to install and configure Kerberos. Documentation for doing so can be found at howtos.linux.com/howtos/Kerberos-Infrastructure-HOWTO/install.shtml. |
Network Address Translation and Private Network Addresses |
The Internet Assigned Numbers Authority (IANA) specified three blocks of IP addresses in RFC 1918 that are set aside for the purpose of private network addressing: Class A: 10.0.0.0 to 10.255.255.255 Class B: 172.16.0.0 to 172.31.255.255 Class C: 192.168.0.0 to 192.168.255.255 NAT is the service that makes it possible for a server to translate between a private host on a network and a public address. |
Nmap, PortSentry, Snort and Tripwire |
nmap is a generic scanner that can look for open ports on the local computer or any other computer and report back its findings. PortSentry, on the other hand, is used to block port scans and vulnerability probes on a single computer and is essentially the opposite of nmap. Snort is a packet sniffer, used to monitor network activity and throw up alerts when intrusions from outside are a possibility. Tripwire goes beyond PortSentry and Snort in capabilities and notifies the administrator when suspicious activity occurs. You can get more information on it at Tripwire. It is important to stay current on the IDS (Intrustion Detection System) configuration, regardless of the software used, and be responsive to new vulnerabilities as they become available. You can keep on top of security issues by monitoring your vendor's site as well as those of CERT, originally an acronym for Computer Emergency Response Team and now a division of Carnegie Mellon Software Engineering Institute at www.cert.org. If you suspect a problem on your own network and need to contact CERT, you can do so via e-mail to cert@cert.org, or through regular mail at: CERT Coordination Center / Software Engineering Institute / Carnegie Mellon University / Pittsburgh, PA 15213-3890. It is also highly recommended that you subscribe to the BUGTRAQ mailing list which can be done by sending an e-mail to listserv@securityfocus.com with a blank subject and in the body indicate "SUBSCRIBE BUGTRAQ". |
DNS Structure
The name system is based on hierarchical names in a tree-type structure that closely resembles a directory structure. Resolution is done through the use of a combination of domains and hostnames into Fully Qualified Domain Names--FQDNs. The domain can be one of several possibilities, the most common being:
com--commercial enterprise
edu--educational institution
gov--government
mil--military
net--network provider
org--organization/original/not-for-profit
Table 3 Networking configuration topic
Topic
|
Comment
|
arp |
Shows the entries in the Address Resolution table. |
arpwatch |
A utility that monitors changes in Ethernet/IP address pairings. |
ifconfig |
Displays the TCP/IP configuration parameters. |
lsof |
Lists open files. |
nc |
This file, within the /usr/bin directory, is also commonly known as Netcat--a utility that allows you to read and write across network connections and is particularly useful for debugging. |
netstat |
Displays network status information. |
ping |
Displays echo messages to show whether or not a host can be reached. |
route |
Displays the routing table. |
tcpdump |
A utility that allows you to monitor network traffic and analyze packets flowing through an interface in promiscuous mode. |
Table 4 Network troubleshooting topics
Utility
|
Purpose
|
dig |
Shows DNS entries. |
dmesg |
Print out the bootup messages. |
host |
A utility for looking up host name information on DNS. |
hostname |
Shows, or allows you to set the system hostname. |
ifconfig |
Displays the TCP/IP configuration parameters. |
netstat |
Displays network status information. |
nslookup |
A utility for interactively querying name servers. It works in conjunction with the resolv.conf file, which holds the initial domain name and name server address settings. |
ping |
Displays echo messages to show whether or not a host can be reached. |
route |
Displays the routing table. |
traceroute |
Displays the route taken to reach a remote host. |
All of these domains are representative of entities within the United States. If the entity resides outside the United States, then the domain becomes an abbreviation (typically two letters) for the host country. While there are dozens of such abbreviations, some of those most common include:
au--Australia
de--Germany
es--Spain
fr--France
il--Israel
pr--Puerto Rico
su--Soviet Union
uk--United Kingdom
The hostname can be only the name of the host to contact or can include subdomains as well. For example, www.novell.com is considered a Fully Qualified Domain Name because it includes the domain (.com), and the hostname (novell).
An FQDN of download.novell.com contains additional information. While the domain stays the same (.com), it must now find the network novell, and then the host download beneath that.
DNS Zones
With the enormous number of hosts and sites on the Internet, it is not possible for a single server to hold all the address resolutions needed regardless of the capabilities of the database. Instead of a single server, DNS resolution for the Internet is performed by a number of servers, each responsible for a zone.
By using multiple servers/multiple zones, the load and the administrative burden of managing the database is diffused. Administrators manage only the DNS database records stored in their zones, which can be any portion of the domain name space. For each zone, there is a primary server that is responsible for all updates and one or more secondary servers. Any changes made to the zone file must be made on the primary server because the zone file on the secondary server(s) is a read-only copy. Zones are copied from the primary to the secondary name servers through replication (also known as zone transfer).
In addition to primary and secondary, there are also servers known as cachingonly servers. A caching-only DNS Server doesn't have zone files and its only function is to make DNS queries, return the results and cache them. While primary and secondary servers always have a file locally, when a caching-only server first starts, it has no stored DNS information. It builds this information over time as it caches results of queries made after the server starts.
DNS Records
Each record within the DNS zone file consists of a number of entries. The entries are also known as Resource Records and can vary ever so slightly, but the following sections examine the most common record types.
SOA Record
Every database file starts with an SOA (Start Of Authority) record. This record identifies the zone and contains a number of other parameters including:
source host--the name of the primary server (with the read/write copy of the file)
contact e-mail--e-mail address for the administrator of the file
serial number--the incrementing version number of the database
refresh time--the delay in seconds that secondary servers wait before checking for changes to the database file
retry time--the time in seconds a secondary server waits before another attempt if replication fails
expiration time--the number of seconds on secondary servers before the old zone information is deleted
time to live (TTL)--the number of seconds a caching-only server can cache resource records from this database file before discarding them and performing another query
NS Record
The Name Server record simply specifies the other name servers for the domain, or maps a domain name to that of the primary server for the zone.
A Record
The Address Record holds the IP address of the name.
CNAME Record
The Canonical Name Record is an alias field allowing you to specify more than one name for each TCP/IP address. For example, the CNAME record for ftp.novell.com would indicate that it is an alias for download.novell.com.
MX Record
The Mail Exchanger record specifies the name of the host that processes mail for this domain.
HINFO Record
The Host Record is the record that actually specifies the TCP/IP address for a specified host. All hosts that have static TCP/IP addresses should have an entry in this database.
PTR Record
Pointer records are used for reverse lookup entries. They specify the IP address in reverse order and the corresponding host name.
Web Services
Apache is a World Wide Web server to Linux in the same way that Internet Information Server is a WWW server for Windows NT/2000. You can devote years to learning the intricacies of this service.
Apache is included with most Linux implementations, but if you don't have it, you can get it from www.apache.org.
The primary daemon running Apache is httpd and it, like the others, is started by the inetd when networking begins. If you want Apache to start automatically when the system is booted, add it to the default runlevel's directory.
The exam objectives specify the need to know how to mange the httpd files, which is an important point because in the newest version of Apache, there is only one configuration file: httpd.conf. In older versions, httpd.conf looked for additional values in two other files:
access.conf--allowed certain pages of the Web site to be restricted to individual users or groups
srm.conf--which specified the root directory for the Web site
If you make changes to the configuration file(s) and need those changes read immediately, you can kill the httpd with the kill -1|SIGHUP command to force rereading the files upon restart.
One important consideration when using Apache, or any Web server, is you need to verify valid entries in the /etc/services file for WWW services.
Network Client Management
Four main topics are beneath this section: DHCP, LDAP, PAM and NIS. Let's briefly look at each one.
DHCP
You can manually enter the needed values for TCP/IP configuration each time you add a host to the network, or you can use the DHCP (Dynamic Host Configuration Protocol) service. With DHCP, you don't need to enter any values when adding new hosts to the network. A server hosting the DHCP Daemon (dhcpd) holds a range of addresses, known as a scope, and can lease IP addresses out to clients. The lease duration is configurable from a short time up to indefinitely. So long as "forever" is not used, the client will regularly attempt to renew the lease it's using if possible. If the server does not hear it, the client will try again at regular intervals all the way up until the lease expires. When the lease expires, it goes back into the scope and the client must obtain another lease anew. After every expiration, when a client requests an address, it always tries to get the one it had last time if it is available.
LDAP
LDAP (Lightweight Directory Access Protocol) is used to make access to directory services possible. OpenLDAP is the most popular implementation of LDAP for the Linux environment, and it allows you to organize entries into a hierarchical tree with all the expected objects such as distinguished names and relative distinguished names.
Object classes within LDAP are defined in schema files, which are found in /etc/openldap/ schema and contain the following classes:
Root: the root of the directory tree
c: countries
o: organizations
ou: organizational units
dc: domain components
You can find complete administration information for OpenLDAP at OpenLDAP in the Admin Guide and the Quick Start Guide. For this exam, know that the configuration files are under the /etc/openldap directory and the two primary files are:
slapd.conf, which is the main configuration file, and
ldap.conf, which is the default configuration for the clients.
PAM
To increase security, Pluggable Authentication Modules (PAM) can act as intermediaries between users and applications. Once a user is authorized in PAM, they are free to access the applications that are available to them. The beauty of this arrangement is that you can change any one element in the process and not affect anything else. For example, suppose you are requiring users to enter a password to authenticate themselves and then giving them access to ten applications. You can change the authentication method from a password to a fingerprint scan and then allow them the access to the applications without having to reconfigure anything but the authentication method.
Global files are beneath /etc/security. Individual configuration files for PAM modules are under /etc/pam.d. The names which appear here have the same name as the utility with which they are associated. When a user uses one of these applications, a check is made in this directory for an associated configuration file. If found, it is read and acted upon.
Some of the configuration files are only a single line, while some are longer. Each line in the file has four fields. The first field identifies the module type. The second is the control flag. The third field lists the modules to use, and the fourth field (optional) lists any needed arguments.
The module type has four possible values:
account--this identifies a need to see if the user has permission to use the service they want.
auth--this identifies a need to check the user's authenticity, most often done with a password.
password--this allows a change in the access/authentication token, again, usually done by issuing a password.
session--this is the module type used to govern the session between the application and the user.
The control flags have four possible values:
optional--the success or failure of this flag has no adverse consequences.
required--the flag must be marked successful before being allowed to continue. Any other associated flags are processed upon failure, then the user is told there was a problem.
requisite--similar to required, except no other associated flags are processed upon a failure and the user is immediately told there was a problem.
sufficient--if the flag is successful, no other modules need to be processed (this is sufficient). If there is a failure, there are no direct consequences.
The modules themselves are identified in the third field and reside in /lib/security on most systems, and /lib64/security on 64-bit platforms. Any arguments that are needed can be passed, with the most common being debug and nullok. The debug argument is used to enable debugging, while nullok is used to allow empty passwords to be counted as legitimate entities.
NIS
The Network Information Service (NIS) acts as a giant phone book, or Yellow Pages, to resources distributed across the network. NIS acts so much like a directory in fact, that most of the files and utilities begin with the letter yp as a carryover from when it was known as that. The three components of NIS are:
Master server--there must be at least one running the ypserv program and holding the configuration files.
Slave servers--these are optional and not used in small networks. When used, they act as intermediaries on behalf of the master server in processing requests.
Clients--these run the ypbind program and retrieve data from the server.
An NIS network is organized into domains with the /etc/defaultdomain file defining the domain and /etc/yp.conf holding the server address. Common resources mapped with NIS include user information (/etc/passwd), group information (/etc/group) and services (/etc/services), though you can add many more.
You should know a number of utilities that work with NIS:
ypdomainname--shows the name of the NIS domain
ypmatch--queries the key field of a map and shows the results
yppasswd--changes the user password on the NIS server
yppoll--shows the ID number of the NIS map
ypwhich--shows the NIS server the client uses
Network Troubleshooting
Surprisingly, there is not a single utility within this topic that has not already appeared elsewhere on this exam or in one of the previous three exams that you have to take to prepare for this one. Table 4 offers no surprise and lists the utilities to know for this domain.
Summary
This article completes the coverage of the LPI certifications as it looked at the last exam--of two--that you must pass to become certified as an intermediate-level administrator. If you want to test yourself, take the sample questions for the 202 exam on the LPI site at www.lpi.org/en/tasks_202.html. Most of all, good luck with that certification and keep learning!
About the Author
Emmett Dulaney is the author of the Novell Certified Linux Professional (CLP) Study Guide (ISBN: 0-672-32719-8) by Novell Press. He is also finishing the Novell Linux Desktop 9 Administrator's Handbook (ISBN: 0-672-32790-2) for Novell Press. He holds a number of other certifications in addition to LPI.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.