Configuring OpenSSH

Configuring OpenSSH



SSH server (sshd)




/etc/ssh/sshd_config 


Directives:

- AllowUsers

- DenyUsers

- HostKey

- ListenAddress

- PermitRootLogin

- Port

- Protocol







SSH client 





/etc/ssh/ssh_config





file.







The





/etc/ ssh/ssh_config 






file is used to specify default parameters for all users running ssh on the system.





A user can override these defaults using the





~/.ssh/ssh_config 






file in his or her home directory.






The precedence for ssh client configuration settings are as follows:





1. Any command-line options included with the ssh command at the shell prompt



2. Settings in the ~/.ssh/ssh_config file



3. Settings in the /etc/ssh/ssh_config file










Connect




ssh –l user_name ip_address





Don’t forget the –l parameter. If you don’t, the SSH client will
attempt to authenticate you to the remote system using the same
credentials you used to authenticate to the local system.







Encryption III

Encryption V

Configuring SSH to Use Public Key Authentication



In addition to authenticating to the SSH server with a username and
password combination, you can also configure your sshd daemon to allow
authentication using an RSA or DSA public key.


For this to work, the public key of the user on the client system must be stored in the



~/.ssh/ authorized_keys 



file in the home directory of the user on the server system that you will 
authenticate as. To do this, you need to securely copy the public key from 
the client system to the server system. The private key, of course, remains
on the client system.




If you configure the SSH server to use public key authentication:


a) The SSH client tells the SSH server which public key should be used for
    authentication when the SSH session is initially established.

b)The SSH server then checks to see if it has that client’s public key; if
    it does, it will generate a random number and encrypt it with that
    public key.

c) It then sends the encrypted number to the client, which
   decrypts it using the private key associated with the public key.

d) The client then calculates an MD5 checksum of the number it received from
     the server.

e) It sends the checksum back over the SSH server system,
    which then calculates its own MD5 checksum of the number it originally
    sent. If the two checksums match, the user is automatically logged in.



To configure public key authentication, the first thing you need to do
is create the public/ private key pair on the client system so that
you can send the public key to the SSH server. This can be done using
the



ssh-keygen 



command. Complete the following:





1. At the shell prompt of the client system, enter



ssh-keygen –t rsa




or



ssh-keygen –t dsa



depending on which encryption method your SSH server supports. To be safe,
you can simply use both commands to make two key pairs—one for RSA encryption
and the other for DSA encryption.





2. When prompted for the file in which the private key will be saved,
press enter to use the default filename of 



~/.ssh/id_rsa 



or



~/.ssh/id_dsa




The associated public key will be saved as




~/.ssh/id_rsa.pub 



or



~/.ssh/id_dsa.pub




respectively.


3. When prompted, enter a passphrase for the key. It is important that
    you use a passphrase. If you don’t, then anyone who manages to get a
    copy of your key files could authenticate to the SSH server without
    being required to enter a passphrase. Assigning a passphrase to the
    key renders the key useless if someone doesn’t know it.


    At this point, your key pair is created. An example of creating an RSA
    key pair is shown here:


    rtracy@ws1:~> ssh-keygen -t rsa
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/rtracy/.ssh/id_rsa): Enter
   passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/rtracy/.ssh/id_rsa. Your
   public key has been saved in /home/rtracy/.ssh/id_rsa.pub. The key
   fingerprint is: ba:14:48:14:de:fd:42:40:f2:4b:c8:8b:03:a4:6d:fc
   rtracy@ws1
   The key's randomart image is:


+--[ RSA 2048]----+
| . +oo |
|oo + = o |
|o + = + o |
|o++o . |
| oEoS. |
| . o. |
|o|
| .. |
|.|
+-----------------+



rtracy@ws1:~>



The next thing you need to do is to copy the public key you just
created to the SSH server. 



An easy (and secure) way to do this is to use the 



scp 


command you learned about earlier in this chapter. The
syntax is




scp ~/.ssh/key_name.pub   user_name@address_of_SSH_server:filename





In the example shown here, the RSA public key for the local rtracy
user on WS1 is copied to the home directory of the rtracy user on WS3
and saved in a file named keyfile:



rtracy@ws1:~> scp ~/.ssh/id_rsa.pub ws3:keyfile
Password:



id_rsa.pub                                    100%  392     0.4KB/s   00:00
rtracy@ws1:~>


At this point, the contents of the key file you just copied need to be
appended to the end of the 



~/.ssh/authorized_keys 


file in the home directory of the user you will connect to the SSH server as.



An easy way to do this is to connect to the SSH server system using a standard
(password- authenticated) SSH session and then use the cat command to
append the contents of the key file to the end of the



~/.ssh/authorized_keys 



file in the user’s home directory. An example of how to do this is shown here:


rtracy@ws1:~> ssh -l rtracy ws3
Password:
Last login: Thu Jun  2 15:05:34 2011 from 192.168.1.84
rtracy@WS3:~> mkdir ~/.ssh
rtracy@WS3:~> cat keyfile >> ~/.ssh/authorized_keys
rtracy@WS3:~>


In this example, I logged in to the WS3 system via an SSH connection
as the remote rtracy user and then created the hidden .ssh directory
in that user’s home directory. I had to create the directory because
it didn’t exist yet. If the .ssh directory already exists, you can
skip this step and just append the contents of the key file to the end
of the authorized_keys file. 



Notice in the example that I used the cat command with the >> redirection 
characters to add the contents of the file named keyfile to the end of the authorized_keys file.





In this example, the authorized_keys file didn’t exist yet, so the
redirection process automatically created it for me. Because of this,
I could have actually just used a single > redirection character
because the file didn’t exist.




If, on the other hand, the authorized _keys file does already exist,
it’s very important that you remember to use the >> redirection
characters instead of >. Remember, using >> will append the output of
the command to the end of the specified file. Using a single
redirection > character will overwrite the entire file with the output
of the command. That wouldn’t be a good thing if the authorized_keys
file already had several keys in it that you wanted to keep.




You can now test the configuration to see if public key authentication
works. If you’re still logged in to an SSH session with the SSH
server, exit out of it. Then establish a new SSH session with the
server. You should be prompted for the key file’s passphrase instead
of a username and password, as shown in Figure 18-9.





Once you enter the passphrase, you will be authenticated to the SSH
server. Notice in the next example that no password was requested to
establish the SSH session:




rtracy@ws1:~> ssh -l rtracy ws3
Last login: Thu Jun  2 16:13:39 2011 from 192.168.1.84
rtracy@WS3:~>



If desired, you can use the



ssh-agent 



command to eliminate the need to enter the passphrase every time you establish 
an SSH connection.



Complete the following:




1. At the shell prompt of your client system, enter



ssh-agent bash


2. At the shell prompt, enter


   ssh-add ~/.ssh/id_rsa 


   or


   ssh-add ~/.ssh/id_dsa



   depending on which key file you have created.




3. When prompted, enter the key file’s passphrase. When you do, you
   should be prompted that the identity has been added. An example
   follows:

      rtracy@ws1:~> ssh-agent bash
      rtracy@ws1:~> ssh-add ~/.ssh/id_rsa
      Enter passphrase for /home/rtracy/.ssh/id_rsa:
      Identity added: /home/rtracy/.ssh/id_rsa (/home/rtracy/.ssh/id_rsa)
      rtracy@ws1:~>



    Once this is done, the ssh-agent process stores the passphrase in
    memory. It then listens for SSH requests and automatically provides
    the key passphrase for you when requested.














LX0-104 Exam Objectives (X)

Encryption IV

Tunneling Traffic Through SSH

One of the key security issues you must deal with as a system
administrator is the fact that many commonly used network protocols
transfer information as clear text. Good examples of this are the POP3
and IMAP daemons we discussed in the preceding chapter. We noted that
for your Linux MTA to download e-mail messages to client systems, you
must first enable either your POP3 or IMAP daemon via xinetd. Once
done, end users can use an e-mail client to connect to the MTA and
download their mail using the appropriate protocol. The problem,
however, is the fact that both of these daemons transfer data as clear
text by default. That means the usernames and passwords users send to
authenticate to the MTA are sent as clear text along with all the con-
tents of their e-mail messages. This allows anyone with a sniffer to
capture packets and view the contents of the transmissions.



The good news is SSH can be used to encrypt clear-text traffic by
tunneling it through an SSH connection. When client software for the
tunneled protocol (such as an e-mail client using POP3) establishes a
connection with the local SSH client, the traffic is encrypted using
SSH and tunneled through to the SSH server. On the SSH server end, the
traffic is decrypted and then forwarded to the appropriate target
service (in this case, the POP3 daemon). This is great, because the
information is encrypted before being transmitted, even though the
original protocol (in this case, POP3) doesn’t support encryption.




Let’s walk through an example of how you can use SSH to tunnel POP3 traffic:



1. Make sure the ssh client is installed on the local system where the
   e-mail client will run.


2. Make sure the sshd daemon is installed and running on the POP3 server.


3. Ensure IP port 22 is open on the server where sshd is running.


4. On the system where sshd is running, switch to root and edit the
 


  /etc/ssh/sshd_config 



   file.


5. Locate the AllowTcpForwarding parameter, uncomment it if necessary,
   and then set it to a value of yes. An example is shown here:



    AllowTcpForwarding  yes



6. Save your changes to the file and exit the editor.


7. Restart the sshd daemon by entering systemctl restart sshd at the
   shell prompt (as root).



8. Switch to the client system.



9. Create a local ssh tunnel from a local high IP port (in this
   example, port 2345) to port 110 on the POP3 server using the following
   command (enter the remote user’s password when prompted):



    ssh -f -N -L 2345:pop3_host_address:110 user_name@pop3_host_address




   The options specified in this command do the following:



   • –N and –f 

     Tell ssh not to execute a command remotely on the server
      and to run in the background after prompting for the remote user’s
      password


   • –L 

      Specifies three things:

      • The local port to be used for the client end of the tunnel (in
        this case, 2345)

      • The hostname or IP address of the remote POP3 server

      • The port on the remote server that will be used for the server
        end of the tunnel (in this case, 110)



   You don’t have to use port 2345. You can use the same port on both
   ends if desired. However, be aware that you will need to switch to the
   root user if you want to use a port number less than 1024 on the
   client side of the tunnel. These are called privileged ports.



10. With the tunnel established, configure the local e-mail client
    program to retrieve mail from the local system on the port you
    configured for the client end of the SSH tunnel. In this example, you
    would configure it to get mail from the local system’s IP address on
    port 2345. An example of how to do this with the Evolution e-mail
    client is shown in Figure 18-6.


    Note that I used the hostname of the local host, not the POP3 server, in the Server field.
    I also added the port number of the workstation end of the tunnel to the end of the
    hostname.




At this point, when the client uses the POP3 protocol to download new
messages, the SSH client on the local system will encrypt the request
and forward it to the SSH server through the SSH tunnel you
established. The SSH server will receive the request, decrypt it, and
then pass the data on to the local port 110, where the POP3 daemon is
listening. The cool thing about this process is that it is completely
transparent to the e-mail client software. As far as it’s concerned,
it’s retrieving e-mail from a local POP3 server.



You can test the tunnel you created using the telnet command from the
client end of the tunnel. The syntax is


telnet localhost client_tunnel_port


Here’s an example:



telnet localhost 2345



When you do this, you should see a connection established with the remote system where the POP3 daemon is running. An example is shown in Figure 18-7.




You can also tunnel your X server traffic to remote X clients using an SSH connection. This is important because unencrypted X traffic provides an attacker with a gold mine of information that he or she can use to compromise your systems.






To configure a remote X client without encryption, you can use the
following procedure:


1. On the remote X client, enter



   xhost +X_server_hostname



   This tells the client to accept connections from the X server.



2. On the X server, enter



   DISPLAY=X_client_hostname:0.0



   and then enter



   export DISPLAY



   This tells the X server to display its output on the remote X client.




3. From the X client, use the ssh client to access the shell prompt on
   the X server and then run the graphical application you want displayed
   on the X client. For example, you could enter gedit at the shell
   prompt to remotely display the gedit text editor. You could also enter
   office at the shell prompt to remotely display the OpenOffice.org
   suite.








This procedure works, but all the X traffic is transmitted
unencrypted. This isn’t good. Instead, you should use SSH to tunnel
the X server traffic between the X server and the X client. You can do
this using one of the following options:



• Use the –X option with the ssh client program.


• Set the 


ForwardX11 


option to a value of 


yes


in the


 /etc/ssh/ssh_config 


  file on the X client system.




Once this is done, you then need to set the


X11Forwarding 


option to



yes 



in the



/etc/ssh/sshd_config 



file on the X server system.












LX0-104 Exam Objectives (X)

Encryption III

Configuring OpenSSH


To use ssh, you must first install the openssh package on your system
from your distribution media. This package includes both the sshd
daemon and the ssh client. OpenSSH is usually installed by default on
most Linux distributions. You can use the package management utility
of your choice to verify that it has been installed on your system.



The process of configuring OpenSSH involves configuring both the SSH
server and the SSH client.


You configure the sshd daemon using the



/etc/ssh/sshd_config 



file.



The ssh client, on the other hand, is configured using the



/etc/ssh/ssh_config file 



or the



~/.ssh/ssh_config




file.





Let’s look at configuring the SSH server (sshd) first. There are many
directives within the



/etc/ssh/sshd_config 



file. The good news is that after you install the openssh package, the default parameters work
very well in most circumstances. To get sshd up and running, you shouldn’t have to make many changes to the sshd_config file. Some of the more useful parameters in this file include those shown in Table 18-1.

The ssh client on a Linux system is configured using the



/etc/ssh/ssh_config



file.





The



/etc/ ssh/ssh_config 




file is used to specify default parameters for all users running ssh on the system.



A user can override these defaults using the



~/.ssh/ssh_config 




file in his or her home directory. The precedence for ssh client configuration
settings are as follows:





1. Any command-line options included with the ssh command at the shell prompt


2. Settings in the ~/.ssh/ssh_config file


3. Settings in the /etc/ssh/ssh_config file






As with the sshd daemon, the default parameters used in the ssh_config
file usually work without a lot of customization. However, some of the
more useful parameters that you can use to customize the way the ssh
client works are listed in Table 18-2.

Of course, before you can connect to an SSH server, you must open up



port 22 


in the host- based firewall of the system where sshd is
running. For example, in Figure 18-4, the YaST Firewall module has
been loaded on a SUSE Linux Enterprise Server 10 system and configured
to allow SSH traffic through.






After configuring your firewall, you can load the ssh client on your
local computer and connect to the sshd daemon on the remote Linux
system by entering




ssh –l user_name ip_address




TIP


Don’t forget the –l parameter. If you don’t, the SSH client will
attempt to authenticate you to the remote system using the same
credentials you used to authenticate to the local system. If the
credentials are the same onboth the client and server systems, you’ll
still be able to authenticate. But if they aren’t, you won’t be able
to authenticate.






For example, if I wanted to connect to a remote Linux system with a
hostname of fedora (which has an IP address of 10.0.0.85) as the user
student using the ssh client on a local computer system, I would enter



ssh –l student fedora 



at the shell prompt. This is shown in Figure 18-5.






Notice in Figure 18-5 that I was prompted to accept the public key
from the fedora host because this was the first time I connected to
this particular SSH server. Once done, I was authenticated to the
remote system as the student user (notice the change in the shell
prompt). At this point, I have full access to the shell prompt on
fedora and I can complete any task that I could if I were sitting
right at the console of the remote system. To close the connection, I
just enter exit at the shell prompt.









LX0-104 Exam Objectives (X)

Securing I

Configuring xinetd and inetd


In this part of this chapter, you learn how to configure Linux
“super-daemons.” Most Linux distributions install a wide variety of
network services during the system installation process. Most of these
services, such as Telnet, are very handy and provide a valuable
service. However, they aren’t needed most of the time. We need a way
to provide these services when requested but then unload them when
they aren’t needed, saving memory, reducing CPU utilization, and
increasing the overall security of the system.



Depending on your distribution, there are two ways to do this. The
following options are discussed here:



• Configuring xinetd
• Configuring inetd





Configuring xinetd

Many Linux distributions include a special daemon called xinetd that
can be used to manage a number of different network services. In this
part of this chapter, you learn how to configure and use xinetd. We’ll
discuss the following topics:



• How xinetd works
• Configuring xinetd network services
• Using TCP Wrappers



Let’s begin by discussing how the xinetd daemon works.



How xinetd Works

The xinetd daemon is a super-daemon. It’s called a super-daemon
because it acts as an intermediary between the user requesting network
services and the daemons on the system that provide the actual
service. This is shown in Figure 17-26.




When a request for one of the network services managed by xinetd
arrives at the system, it is received and processed by xinetd, not the
network daemon being requested. The xinetd daemon then starts the
daemon for the requested service and forwards the request to it. When
the request has been fulfilled and the network service is no longer
needed, xinetd unloads the daemon from memory.




Some of the network services managed by xinetd include the following:



• chargen
• daytime
• echo
• ftp
• pop3
• rsync
• smtp




Configuring xinetd Network Services


As with all the network services I’ve discussed, the xinetd
configuration files are stored in /etc. The xinetd daemon itself is
configured using the



/etc/xinetd.conf 


file. Generally speaking, you won’t need to make many changes to this file. The default
configuration usually works very well.



At the end of this file you will notice a directive that reads



includedir /etc/xinetd.d



This line tells the xinetd daemon to use the configuration files in
/etc/xinetd.d. These files tell xinetd how to start each service when
requested. Each of these files is used to configure the startup of a
particular service managed by xinetd.


For example, the 


vsftpd file 


in


/etc/xinetd.d 


is used to configure the vsftpd FTP server daemon. The xinetd configuration
settings for vsftpd in this file are shown here:



service ftp
{

socket_type     = stream
protocol        = tcp
wait            = no
user            = root
server          = /usr/sbin/vsftpd

# server_args        =
# log_on_success     += DURATION USERID
# log_on_failure     += USERID
# nice               = 10
   disable            = yes


}




This file doesn’t configure the daemon itself. It only tells xinetd
how to start up the daemon. The actual configuration file for the
vsftpd daemon itself is in /etc/vsftpd.conf.


One of the most important parameters in the 


/etc/xinetd.d/vsftpd



file is the disable directive.


This directive specifies whether or not xinetd is allowed to start the
daemon when requested.



In the preceding example, this directive is set to yes, which means the daemon will not 
be started when requested. 



The daemon to actually start is specified by the 


server = directive


In the example, xinetd will start the /usr/sbin/vsftpd daemon. 


server          = /usr/sbin/vsftpd



To enable this daemon, you need to edit this file and change the disable
parameter to a value of no.



disable            = no




After changing a value in any of the files in /etc/xinetd.d, you need to 
restart the xinetd daemon using its init script in /etc/rc.d/init.d or /etc/init.d.



TIP  If you enable a service provided by xinetd, you’ll need to create
an exception in your Linux system’s host firewall to allow traffic for
the IP port used by the daemon.






Using TCP Wrappers


If you enable a particular service using its configuration file in the
/etc/xinetd.d/ directory, any host can connect to it through xinetd.



However, depending on how your system is deployed, you may need to
control access to these network services. You may want to limit access
to only a specific set of hosts and deny access to everyone else.



If this is the case, you need to configure these services to use TCP
Wrappers, which are used by xinetd to start and run the network
services using a set of configuration files that specify who can and
who can’t access the service.




To use TCP Wrappers, you first need to enable the functionality in
each service’s configuration file in /etc/xinetd.d. Do the following:



1. Verify that the tcpd package has been installed on your Linux system.


2. Open the appropriate configuration file in a text editor.


3. Comment out the existing server = line from the file.


4. Add the following line:


     server      = /usr/sbin/tcpd


This will cause xinetd to start the tcpd daemon instead of the service
daemon itself.



5. Add the following line:


     server_args       = path_to_daemon


This tells the tcpd daemon to then run the requested network daemon.
In the example shown here, the /etc/xinetd.d/telnet file has been
configured to run the vsftpd daemon within a TCP Wrapper:



service ftp
     {
# #
socket_type     = stream
protocol        = tcp
wait            = no
user            = root
# server          = /usr/sbin/vsftpd


server          = /usr/sbin/tcpd
server_args     = /usr/sbin/vsftpd


# log_on_success     += DURATION USERID
# log_on_failure     += USERID
# nice               = 10
   disable            = no

}



6. Save the file and restart the xinetd daemon.





Next, you need to create your access controls. The tcpd daemon uses
the 



/etc/hosts.allow 


and


/etc/hosts.deny 



files to specify who can access the services it manages.



Entries in /etc/hosts.allow are allowed access.


Hosts in /etc/hosts.deny are not allowed access. 



The syntax for both of these files is



service: host_addresses



As these files are processed, the search stops as soon as a matching
condition is found in a file. Files are no longer processed after this
occurs. The following steps occur in the order shown:


• Access will be granted if a matching entry is found in the
  /etc/hosts.allow file.

• If not, access will be denied if a matching entry is found in the
  /etc/hosts.deny file.

• If this does not occur, access will be granted.




For example, suppose you needed to configure the /etc/hosts.allow file
to allow access to the vsftpd daemon for just a few specific hosts.
The following entry grants access to the vsftpd service to hosts with
the IP addresses of 192.168.1.10 and 192.168.1.102.



vsftpd:     192.168.1.10, 192.168.1.102




Some distributions use the inetd daemon instead of xinetd. This daemon
works in much the same manner as xinetd. Let’s learn how it works
next.







Configuring inetd


The inetd daemon is a super-daemon like xinetd, but it is typically
used on older Linux distributions. Like xinetd, the inetd daemon acts
as a mediator for connection requests to network services running on
the Linux host. It accepts connection requests from client systems,
starts the requested service, and then forwards the requests from
clients to the newly started daemon. When the transaction is complete
and the connection from the client is terminated, the daemon is
stopped on the Linux host.



As we discussed with xinetd, managing the network services on your
Linux host in this way has advantages and disadvantages. Key among
these is the fact that it conserves system memory and CPU resources.
The network daemon is started only when it is needed. When it isn’t
needed, it’s removed from memory until it is requested again. However,
this benefit comes at a cost in terms of latency. When a service is
requested by a client, the client must wait for a short period of time
while the necessary daemon is loaded and the connection established.
Therefore, inetd (and xinetd) should only be used to manage network
services that are needed only occasionally on the system.




The inetd daemon is configured using the 



/etc/inetd.conf 



file. Unlike the xinetd daemon, all the services managed by inetd are configured in
this single configuration file. 



Each line in this file configures a single service to be managed by inetd. The syntax used in 
inted.conf is shown here:



service_name  socket_type  protocol  flags  user  executable  arguments




Each of the parameters in this line is described in Table 17-6. Here
is a sample entry in inetd.conf for the vsftpd daemon:

ftp    stream    tcp    nowait    ftp      /usr/sbin/tcpd     vsftpd




Notice in this example that you can use TCP Wrappers with inetd just
as you did with xinetd. In this example, when a client tries to
establish an FTP connection with this Linux host, the inetd daemon
will start the tcpd daemon and pass to it the name of the actual
daemon to be started (vsftpd) as a server argument. As with xinetd,
using TCP Wrappers with inetd allows you to control access to the
network services running on the host using




the



/etc/hosts.allow 



and



/etc/ hosts.deny 



files.










LX0-104 Exam Objectives (V and U, 323, 647 - 689)

Controlling User Access IV

Configuring User Limits

You can impose limits on how many times users may log in, how much CPU
time they can consume, and how much memory they can use on a Linux
system. This can be done in two ways:



• Using pam_limits to restrict access to resources

• Using ulimit to restrict access to resources





Using pam_limits to Restrict Access to Resources


You can limit user access to Linux system resources using a Pluggable
Authentication Modules (PAM) module called pam_limits, which is
configured using the


/etc/security/limits.conf



file. This file contains resource limits that you can configure using the following
syntax:



domain     type     item     value



This syntax is described here:



• domain 

   Describes the entity to which the limit applies. You can use
   one of the following values:

        • user Identifies a specific Linux user
        • @group_name Identifies a specific Linux group
        • * Specifies all users


• type 

  Defines a hard or soft limit. A hard limit cannot be exceeded.
  A soft limit can be temporarily exceeded.


• item 

  Specifies the resource being limited. You can use the values
  shown in Table 17-1.



• value 

  Specifies a value for the limit.





For example, to configure the rtracy user with a soft CPU limit of 15
minutes, you would open the


/etc/security/limits.conf 


file in a text editor and then enter the following:



rtracy     soft     cpu     15



This limit could be useful if the user is running a CPU-intensive
program that is hogging cycles away from other users. Likewise, you
could also limit the rtracy user to a maximum of two concurrent logins
by entering the following in the file:



rtracy     hard     maxlogins     2



This would prevent any logins to the system as the rtracy user after
two initial logins were successful.



In addition to using pam_limits, you can also limit user access to
system resources using the ulimit command. Let’s look at how this is
done next.




Using ulimit to Restrict Access to Resources


You can also use the ulimit command to configure limits on system
resources. However, be aware that the limits you configure with ulimit
are applied only to programs launched from the shell prompt. The
syntax for using ulimit is ulimit options limit. You can use the
following options with ulimit:


• –a

view the current value for all resource limits



• –c   (max size files)

Sets a limit on the maximum size of core files in blocks. If you set
this limit to a value of 0, core dumps on the system are disabled.


• –f   (max created files)

Sets a limit on the maximum size (in blocks) of files created by the shell.


• –n   (max open files)

 Sets a limit on the maximum number of open file descriptors.


• –t (max cpu time)

Sets a limit on the maximum amount of CPU time (in seconds) a process may use.


• –u (max processes)

Sets a limit on the maximum number of processes available to a single user.


• –d (max data)

Sets a limit on the maximum size (in KB) of a process’s data segment in RAM.


• –m (max resident)

Sets a limit on the maximum resident size (in KB) of a process in RAM.


• –s (max stack size)

Sets a limit on the maximum stack size (in KB).


• –H

Sets a hard resource limit.


• –S

 Sets a soft resource limit.




You can use the –a option with the ulimit command to view the current
value for all resource limits. This is shown in Figure 17-5.






You can also use ulimit to set resource limits. For example, to set a
soft limit of 50 processes, you would enter



ulimit –S –u 50 



at the shell prompt. The current user could then own no more than 50
concurrent shell processes.

















LX0-104 Exam Objectives (V and U, 323, 647 - 689)

Controlling User Access II

To root or Not to root?


As we discussed earlier in this book, every Linux system, whether a
workstation or a server, includes a default superuser account named
root. This account has full access to every aspect of the system. As
such, it should be used with great care. In this part of this chapter,
we’ll discuss the following:



• Proper use of the root user account

• Using su

• Using sudo





Let’s begin by discussing the proper way to use the root user account.



Proper Use of the root User Account

One of the key mistakes made by new Linux users is excessive use of
the root user account. There’s a time and a place when the root user
account should be used. However, most of your work on a Linux system
should be done as a non-root user account. The rule of thumb that you
should follow is this: only use root when absolutely necessary. If a
task can be completed as a non-root user, then it should be done so.




Why is the proper use of the root user account of concern? A few pages
back, we discussed the risks of leaving a logged-in system unattended.
Imagine the havoc an intruder could wreak if they were to happen upon
an unattended system that was logged in as root! All of the data on
the system could be accessed and copied. Major configuration changes
could be made to the daemons running on the system. Heaven only knows
what kind of malware could be installed.



In a nutshell, a system logged in as root represents a serious
security risk. Leaving such a system unattended represents a critical
security risk. Everyone, including the system administrator (that’s
you!), should have a standard user account that they always use to log
in to the system.


If you find that you need root-level access while working on the
system, you can use the su command to temporarily gain root-level
privileges to the system. Let’s discuss how this is done next.





Using su

By now, you should already know how su works. We’ve used it countless
times in this book’s exercises. This command allows you to change to a
different user account at the shell prompt. The syntax for using su is



su options user_account


If no user account is specified in the command, su assumes you want to switch to the root user account. Some of  the more useful options you can use with su include the following:


• –

Loads the user’s environment variables. Notice that we’ve always
used the su – command to switch to the root user account. This changes
to root and loads root’s environment variables.


• –c command 

Switches to the user account and runs the specified command.

• –m 

Switches to the user account but preserves the existing environment variables.



The su command will be your best friend as a Linux administrator.
However, there are times when other users may need root-level access.
You can use sudo to give them limited root access. Let’s discuss how
sudo works next.





Using sudo

Suppose you have a power user on your Linux system. This user may be a
programmer, a project manager, or a database administrator. Users in
this category may frequently need to run some root-level commands. But
do you really want to give them your root password? Probably not. You
want them to be able to run a limited number of commands that require
root privileges, but you don’t want them to have full root access.
This can be done using sudo.



The sudo command allows a given user to run a command as a different
user account. As with su, it could be any user account on the system;
however, it is most frequently used to run commands as root. The sudo
command uses the


/etc/sudoers 


file to determine what user is authorized to run which commands. This file uses the following aliases
to define who can do what:



• User_Alias  Specifies the users who are allowed to run commands

• Cmnd_Alias  Specifies the commands that users are allowed to run

• Host_Alias  Specifies the hosts users are allowed to run the commands on

• Runas_Alias Specifies the usernames that commands may be run as



To edit your


/etc/sudoers 


file, you need to run the


visudo 


command as your root user. The /etc/sudoers  file is loaded in your default editor, which is usually vi. Your changes are written to


/etc/sudoers.tmp 

until committed. This is shown in Figure 17-3.



On most distributions, the sudoers file is configured by default such
that users must supply the root password when using sudo. Obviously,
this configuration doesn’t accomplish anything. If the user already
knows the root password, what’s the point of configuring sudo? This
configuration is specified by the following lines in sudoers:



# In the default (unconfigured) configuration, sudo asks for the root password.
# This allows use of an ordinary user account for administration of a freshly
# installed system. When configuring sudo, delete the two
# following lines:


Defaults targetpw   # ask for the password of the target user i.e. root
ALL     ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults
targetpw'!


1.

To fix this, comment out the two lines specified here in the sudoers
file. Then you can begin your sudoers configuration in the file.
First, you need to use User_Alias to define an alias containing the
user accounts (separated by commas) you want to allow to run commands.
The syntax is


User_Alias alias = users

For example, to create an alias named PWRUSRS that contains the tux,
rtracy, and ksanders user accounts, you would enter the following in
the /etc/sudoers file:



User_Alias PWRUSRS = student, ksanders, rtracy




TIP All alias names must start with a capital letter!




2.

You next need to use Cmnd_Alias to define an alias that contains the
commands (using the full path) that you want the users you just
defined to be able to run. Separate multiple commands with commas. For
example, if your users are programmers who need to be able to kill
processes, you could define an alias named KILLPROCS that contains
your kill command, as shown here:


Cmnd_Alias KILLPROCS = /bin/kill, /usr/bin/killall





3.

Then you need to use Host_Alias to specify what systems the users can
run the commands on. For example, to let them run the commands on a
system named WS1, you would use the following:

Host_Alias MYHSTS = openSUSE



4.

Finally, you need to glue these aliases together to define exactly
what will happen. The syntax is

User_Alias Host_Alias = (user) Cmnd_Alias



Using the aliases just defined, you could allow the specified users to
run the specified commands on the specified hosts as root by entering

PWRUSRS     MYHSTS = (root) KILLPROCS




To exit the editor, press esc and then enter :exit. 

The visudo utility will check your syntax and inform you if you’ve made any errors. At
this point, the users you defined can execute the commands you
specified as root by entering sudo command at the shell prompt.


For example, the rtracy user could kill a process named vmware-toolbox
(owned by root) by entering


sudo killall vmware-toolbox


at the shell prompt. After the rtracy user supplies his password, the process will
be killed.








LX0-104 Exam Objectives (V and U, 323, 647 - 689)

Groups

Groups


The /etc/shadow File With most Linux distributions that use local
authentication, your users’ passwords will be stored in encrypted
format in the /etc/shadow file. This file is linked to the /etc/passwd
file we discussed previously. Each of the user accounts listed in
/etc/passwd has a corresponding entry in /etc/shadow, as shown in this
example:



openSUSE:~ # cat /etc/shadow
...
root:$2a$05$h03HfGFSi2i8GlotOYgreeBelUlHc.z/2KxyQQF7RSo./TdLOrDJa:15035::::::
sshd:*:14796:0:99999:7:::
uucp:*: 16015::::::
wwwrun:*: 16015::::::
hsaez:$6$JbgjOmU1SXu1$ON0iVUmsrzvVxd7D2AeYbriZ1gDRS/W/
xnoeXVzcBkZIeNSJMAKFWfMvl4RvWki0HIQLrfV6bkNIAk6vCEOyP0:16392:0:99999:7:::
ksanders:$2a$05$KL1DbTBqpSEMiL.2FoI3ue4bdyR.eL6GMKs7MU6.nZl5SCC7/
REUS:15043:0:99999:7:::
rtracy:$6$L58Cq/vWQJaM$u7.1.UmlGVquz6qQ0LaHXQzbTgc6kC6uc1sR/GgelNjbF/
FqJUkwmhVdxO3Qxs3HgXQJLIptYJ4HD7bvMoxbd0:16392:0:99999:7:::





As with /etc/passwd, each user account is represented by a single line
in the /etc/shadow file. Each record is composed of the following
fields, each separated by a colon:



Username:Password:Last_Modified:Min_Days:Max_Days:Days_Warn:Disabled_Days:Expire



For example, the record for ksanders is as follows:



ksanders:$2a$05$KL1DbTBqpSEMiL.2FoI3ue4bdyR.eL6GMKs7MU6.nZl5SCC7/
REUS:15043:0:99999:7:::




Here’s what each of these fields contains:



• Username 

This is the user’s login name from /etc/passwd.


• Password

This is the user’s password in encrypted format. In the
preceding example, the password for ksanders is M3linux273. However,
to prevent someone from accessing the /etc/shadow file and grabbing
the user passwords from it, it is stored in encrypted format. You may
notice that all of the system user accounts have a simple asterisk in
this field (*). This indicates that these accounts aren’t allowed to
log in to the system. For example, if I tried to log in to my system
as ftp, I would be denied access even though the ftp user account
exists.


• Last_Modified 

This field displays the number of days since January
1, 1970, that the password was last changed. In this example, it has
been 15,043 days.


• Min_Days 

This field displays the minimum number of days required
before a password can be changed. In this example, it is set to 0
days.


• Max_Days 

This field displays the maximum number of days before a
password must be changed. In this example, it is set to 99,999 days.
Effectively, this means a password change isn’t required.


• Days_Warn 

This field displays the number of days prior to password
expiration that the user will be warned of the pending expiration. In
this case, it’s set to 7 days.


• Disabled_Days 

This field displays the number of days to wait after a
password has expired to disable the account. In this example, it’s set
to a null value.


• Expire 

This field displays the number of days since January 1, 1970,
after which the account will be disabled. In this example, it is set
to a null value, indicating the account never expires.





As you can see, it is very important that these two files stay
synchronized with each other. If they get out of whack, then it’s
possible that a user may not be able to log in or a service may not be
able to access the file system correctly.



The good news is that these files usually stay in sync as they are
supposed to without any intervention on the part of the administrator.
The only times I’ve seen these two files become unsynchronized is when
the administrator decides to manually edit these files with a text
editor. I strongly discourage this practice. Your Linux system
includes a wide variety of utilities that are used to manage user
accounts and passwords on your system. (We’ll discuss how to use these
utili- ties later in this chapter.) You should always use these
utilities instead of a text editor to manage user accounts. Doing so
will ensure that both files are edited appropriately and stay
synchronized with each other.



To verify your /etc/passwd and /etc/shadow files, you can use the



pwck



command at the shell prompt. This utility will verify each line in the
two files and make sure they are valid. Any errors are reported on the
screen, as shown in this example:



openSUSE:/ # pwck
Checking '/etc/passwd'
User 'pulse': directory '/var/lib/pulseaudio' does not exist.
User 'usbmux': directory '/var/lib/usbmuxd'  does not exist.
Checking '/etc/shadow'.




As you can see, pwck found that the home directories specified for the
pulse and usbmux system user accounts don’t exist. Everything else
checked out. If, for some reason, the


/etc/passwd



and the


/etc/shadow 


files are out of synchronization, you can use the


pwconv 



command at the shell prompt to fix the files.



This utility will add any missing user accounts from /etc/passwd to /etc/shadow.









LX0-104 Exam Objectives (V and U, 323, 647 - 689)

Troubleshooting Network VII

Using Name Resolution Tools


Using DNS for name resolution works great—unless it doesn’t work
correctly, that is. Then it can be a royal inconvenience for you
because your end users won’t be able to check their stock prices or
manage their fantasy baseball team. Fortunately, there are several
tools you can use to troubleshoot name resolution on your network:



• dig
• host
• getent



dig

You can use the Domain Information Groper (dig) utility to perform a
DNS lookup on your DNS server and display detailed information about
the hostname being resolved and about the DNS server itself. If you
don’t specify a particular DNS server with the dig command, the DNS
servers configured in the resolv.conf file will be used. The syntax is



dig @dns_server hostname



An example is shown in Figure 15-18.




The output from dig is considerably more extensive than that displayed
by other DNS troubleshooting tools such as nslookup and host. The
dig command returns the IP address associated with the hostname in the
ANSWER SECTION. It also lists the authoritative name server for the
hostname and zone in the AUTHORITY SECTION.


You can use the following options with dig:



• a 

Resolve A record information

• ptr 

Resolve a PTR record

• cname

Resolve CNAME record information

• in 

Resolve Internet record information

• mx

Resolve MX record information

• soa 

Resolve start of authority information





You can also use the host command to resolve hostnames.

Whereas the dig command provides extensive name resolution information, host
provides simple, quick information. The syntax is similar to that used
with dig. You enter


host hostname DNS_server 


at the shell prompt.


Again, if you don’t specify a DNS server, the default DNS server specified in


/etc/resolv.conf 


will be used.





An example of using host is shown here:


openSUSE:/ # host www.google.com
www.google.com has address 74.125.239.49
www.google.com has address 74.125.239.48
www.google.com has address 74.125.239.50
www.google.com has address 74.125.239.52
www.google.com has address 74.125.239.51
www.google.com has IPv6 address 2607:f8b0:4005:800::1011



getent

In addition to host and dig, you can also use getent to test your name
resolution system. One of the weaknesses of the host and dig commands
is that they don’t actually follow the same process for name
resolution as applications and services running on your system do.


If an application such as a web browser needs to resolve a hostname to an
IP address, it first queries your 


/etc/hosts 



file. If an entry for the host in question can’t be found there, it uses the DNS server you
configured to resolve the hostname.



However, the dig and host commands don’t do this. They skip the hosts
file completely and go directly to your DNS server to test name
resolution. This is an issue of concern! Many phishing and pharming
attacks exploit the hosts file to redirect URLs to malicious websites
where users’ personal information can be gleaned. As you can see,
using host or dig will not reveal such an attack because they don’t
look at the hosts file.



The good news is that getent does. The syntax for using getent to test
name resolution is to enter


getent hosts hostname 


at the shell prompt.


An example is shown next:



openSUSE:/ # getent hosts router1
10.0.0.1        router1



In this example, an entry for the router1 hostname exists in the hosts
file, so getent was able to grab it and display it on the screen.


If the hosts file doesn’t have an entry for the hostname specified, it
will try to resolve it via DNS, just like a regular application would.
An example is shown next:



openSUSE:/ # getent hosts www.nebo-tech.com
98.139.135.199  sbsfe-p11.geo.mf0.yahoodns.net www.nebo-tech.com



TIP The getent command can query any data configured in your 


/etc/nsswitch.conf 



file. For example, you can enter


getent passwd 


at the shell prompt to pull entries  out of your passwd file.









LX0-104 Exam Objectives (T)

Configuring Network VI

Configuring IPv6


Before we move on in this chapter, we need to spend some time
discussing IPv6 address configuration. There are actually several
configuration options when it comes to IPv6 addressing. The first is
to use static assignment. As with IPv4, static IPv6 address
assignments require you to manually assign the entire 128-bit IPv6
address and prefix to the host. 



This can be done from the shell prompt using a command-line utility such as 



ifconfig 


or



ip



Alternatively, you can manually enter the address and prefix in the appropriate
interface configuration file in 



/etc/sysconfig/network



Another configuration option is to use static partial assignment.
Using this method, the prefix is statically assigned, but the
interface ID portion of the address is automatically generated using
the host’s MAC address.




Another configuration option is to use stateless auto-configuration,
which is affectionately called SLAC. Using SLAC, we allow IPv6 hosts
to automatically generate their own interface ID, but we require them
to obtain a correct prefix and default gateway address from a network
router (usually the default gateway) using the Neighbor Discovery
Protocol (NDP). NDP uses the following messages for autoconfiguration:



• Router solicitation (RS) messages are sent from network hosts
  requesting that any listening router respond.


• Router advertisement (RA) messages are sent by the router in
  response to RS messages received from network hosts. These messages
  inform the network hosts of the correct IPv6 prefix they should use,
  along with the default gateway address.



NDP is also used by network hosts to discover the MAC address of other
interfaces on the network, thus completely replacing the ARP when
using IPv6. However, NDP cannot provide network hosts with the address
of your DNS server. It can only provide the network prefix and the
default gateway address.




The final IPv6 address configuration option is to use DHCP. As with
IPv4, IPv6 address assignments can be made automatically using an
updated version of DHCP called DHCPv6. Because IPv6 has so many more
configuration options than IPv4, DHCPv6 operates in a different
manner. There are two different modes:



• Stateful DHCPv6

Configures the DHCP server to provide each IPv6 DHCP
client with an IP address, the default gateway address, and the DNS
server IP address. The DHCP server tracks the status of each IPv6 DHCP
client, hence the name stateful.


• Stateless DHCPv6

Does not assign IPv6 addressees to IPv6 clients,
nor does not track their status. In this configuration, the DHCPv6
server simply assigns the DNS server IP address to network hosts.
Obviously, stateless DHCPv6 does not provide a complete addressing
solution. Instead, it must be used in conjunction with other IPv6
address assignment schemes, such as SLAC.


When an IPv6 host boots up, it follows the process described next to
configure an address on its network interface:


1. The host automatically generates an IPv6 link-local address using
   the link-local prefix (which usually starts with FE80) combined with
   an interface ID derived from its MAC address.


2. The host sends a neighbor solicitation (NS) message addressed to
   its own link-local address to make sure another host on the network
   isn’t already using it.


3. The host sends out a multicast RS message, which should be received
   by all routers on the same network segment. If no routers respond, the
   host attempts to use stateful DHCPv6 to receive an IPv6 address.


4. If a router receives the RS message, it then sends a multicast RA
   message to all hosts on the network segment. The RA message identifies
   how the IPv6 address is to be configured. Possible options include the
   following:


   • Obtain all IPv6 configuration information from a DHCPv6 server. If
     this is the case, the host sends out a REQUEST message to any
     listening DHCPv6 server.

   • Use stateless autoconfiguration to get the prefix and default
     gateway from the RA message and to generate the interface ID portion
     of its address automatically. The address of the DNS must then be
     obtained from a DHCPv6 server.


5. If a static IPv6 address has been configured or if stateful
   autoconfiguration has been used, the host sends an NS message to make
   sure no one else is using its address.








LX0-104 Exam Objectives (T)

Configuring Network V

Configuring Name Resolver Settings



When configuring IP settings for a network interface, you also need to
specify the system’s host- name and the IP address of your DNS server.
Because you are most likely a savvy Internet user, you know that you
can use domain names to navigate to particular hosts on the Web.
However, your Linux system (or any other operating system, for that
matter) actually can’t work with the alphanumeric domain names that we
are used to.





For example, when you open a browser window and enter
http://www.google.com in the URL field, your browser, IP stack, and
operating system have no clue where to go to get the requested
information. To make this work, your local system needs to first
resolve these domain names into IP addresses.





In the old days, basic hostname-to-IP-address resolution was performed
by the 


/etc/hosts 


file, which contains IP-address-to-hostname mappings.




NOTE

The /etc/hosts file still exists on Linux systems. In fact, it is
the first name resolver used by default. 

Only if a record for the requested domain name doesn’t exist in the hosts file 
will the operating system then try to resolve the hostname using DNS. Because
of this, you have to manage your hosts file very carefully. Many
network hacks exploit this function of the operating system. A
malicious website or malware may try to rewrite your hosts file with
name mappings that point you to fake websites on the Internet that
look like your favorite auction or banking site but instead are
elaborate phishing websites designed to steal your personal
information.




The hosts file contains one line per host record. The syntax is



IP_address host_name alias



For example, consider the following hosts file entry:



192.168.1.1 mylinux.mydom.com mylinux



This record resolves either the fully qualified DNS name of
mylinux.mydom.com or the alias (CNAME) of mylinux to an IP address of
192.168.1.1. Usually this file only contains the IP address and
hostname of the local system, but you can add other entries too.




Using the hosts file to resolve hostnames works just fine; however, it
really isn’t feasible as the sole means of name resolution. The file
would have to be huge in order to resolve all the domain names used by
hosts on the Internet. In addition, you would have to manually add,
remove, and modify hostname mappings in the file whenever a domain
name changed on the Internet. What a nightmare! Can you imagine trying
to manage this type of hosts file for an entire network of users?




A better option is to submit the domain name to a DNS server. When a
DNS server receives a name resolution request, it matches the domain
name submitted with an IP address and returns it to the requesting
system. Your system can then contact the specified host using its IP
address. Here’s how it works:



1. The system needing to resolve a hostname sends a request to the DNS
   server it has been configured to use on

IP port 53.


If the DNS server is authoritative for the zone where the requested hostname resides,
it responds with the appropriate IP address. If not, the process
continues on to step 2.


NOTE A DNS server is considered to be authoritative if it has a record
for the domain name being requested in its database of name mappings.



2. The DNS server sends a request to a root-level DNS server. There
   are 13 root-level DNS servers on the Internet. Every DNS server is
   automatically configured with the IP addresses of these servers. These
   root-level DNS servers are configured with records that resolve to
   authoritative DNS servers for each top-level domain (.com, .gov, .edu,
   .au, .de, .uk, .ca, and so on).


3. The root-level DNS server responds to your DNS server with the IP
   address of a DNS server that is authoritative for the top-level domain
   of the domain name you are trying to resolve.


4. Your DNS server sends the name resolution query to the DNS server
   that is authoritative for the hostname’s top-level domain (such as
   .com).


5. The top-level domain DNS server responds to your DNS server with
   the IP address of a DNS server that’s authoritative for the DNS zone
   of the hostname you need to resolve.

6. Your DNS server sends a name resolution request to the DNS server
   that’s authoritative for the zone where the hostname you are trying to
   resolve resides.


7. The authoritative DNS server responds to your DNS server with the
   IP address for the hostname.


8. Your DNS server responds to your system with the IP address mapped
   to the hostname, and the respective system is contacted using this IP
   address.



NOTE Once this process happens for a particular name mapping, most DNS
servers will cache the mapping for a period of time. That way, if a
resolution request for the same hostname is received again, they can
respond directly to the client without going through this whole
process again.




Therefore, to make this system work, you must provide your system with
the IP address of the DNS server you want it to use. This is
configured in the


/etc/resolv.conf 


file. This file defines the search prefix and the name servers to use. Here is some
sample content from my openSUSE system’s resolv.conf file:



search mydom.com
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 192.168.2.1



As you can see in this example, the file contains two types of entries:


• search 

Specifies the domain name that should be used to fill out
incomplete hostnames. For example, if you were to try to resolve a
hostname of WS1, the name will be automatically converted to the fully
qualified domain name of WS1.mydom.com. The syntax is search domain.



• nameserver 

Specifies the IP address of the DNS server you want to
use for name resolution. You can configure up to three DNS servers. If
the first server fails or is otherwise unreachable, the next DNS
server is used. The syntax is



nameserver DNS_ server_IP_address




You can use the



/etc/nsswitch.conf



(name service switch) file to define the order in which services will be used for name resolution.
Here are the two lines of the file you need to be concerned with:



hosts:        files dns
networks:     files dns



These two entries specify that the /etc/hosts file (files) is
consulted first for name resolution. If there is no applicable entry,
the query is then sent to the DNS server (dns) specified in the
resolv.conf file.


TIP You can use the



hostname 



command at the shell prompt to show or set the system’s hostname. You can also use the



dnsdomainname 



command to show the system’s DNS domain name.










LX0-104 Exam Objectives (S)

Configuring Network IV

Configuring Routing Parameters




You may have noticed that we didn’t configure two important IP
parameters in the preceding topics in this chapter: the default
gateway router address and the DNS server address.



Using the IP protocol, routers do just what their name implies: they
route data across multiple networks to deliver information to a
destination host. Routers operate at the Network layer and are used to
connect various networks together.




Routers are usually implemented in conjunction with a gateway. The
router hardware itself may be as simple as a computer system with two
NICs installed, or it may be a specialized hardware appliance
dedicated to routing.




One of the key jobs performed by routers is to determine the best way
to get information to the right destination host. To do this, a router
maintains a routing table of available routes. Routers use an
algorithm that evaluates distance, cost, and network status to
determine the best route to the destination host. Even if it isn’t
configured as a router, every Linux system maintains a routing table
in RAM that it uses to determine where to send data on a network.




When you’re configuring networking parameters on a Linux system, one
of the key tasks you need to perform is to configure the default
router address. The default router is the default location packets
are sent to if they are addressed to a host that doesn’t reside on the
local network segment.


Your default gateway router address is stored in the 



/etc/sysconfig/network/routes 



file, shown here:




openSUSE:/ # cat /etc/sysconfig/network/routes
default 10.0.0.1 - ens32




The syntax for specifying the default route in this file is


default router_IP_address



Notice in the preceding example that the default gateway router address is set to 10.0.0.1.




TIP  If you have more than one NIC installed and each interface needs
its own routing configuration (for example, if each NIC is connected
to a different network), you can define an additional routing
configuration file in 


/etc/sysconfig/network/ 



named



ifroute-interface_name





The syntax for adding a route to the routes file is shown next:




DESTINATION       GATEWAY          NETMASK   INTERFACE     [TYPE]





DESTINATION

The first column contains the route’s destination. It may contain the
IP address or DNS hostname of a network or host. Entering default in
this column indicates the route is the default route.


NOTE  I recommend you use IP addresses, not DNS names, in this file. If
your DNS server were to go down or become unreachable, routing would
be gone!



GATEWAY

The second column contains the IP address of the router through which
the specified host or a network can be reached. In this column,
specify the IP address of a router that can route the information to
the remote network or host.




NETMASK

The third column contains the netmask for the network or host behind
the router. The fourth column applies the route to a specific
interface. If nothing is specified, the route applies to all
interfaces.


NOTE If you want to leave a column in this file blank, be sure to
enter a dash (-).




[TYPE]

The fifth column is optional. It is used to specify the route type.
You can enter one of the following:


   • unicast The route specifies a real path to the destination route.

   • local The destination is the localhost. Packets sent to this route
     are looped back and delivered to the local machine.

   • broadcast The destination is a broadcast address. Packets sent to
     this route are sent as link broadcasts.

   • multicast Used for multicast routing. This type of route is not
     typically used with most routing tables.

  • unreachable Configures the route destination as unreachable. Packets
    sent to this route are silently dropped.




Here is a sample entry in a routes file:



207.68.156.51     207.68.145.45     255.255.255.0    ens32



After making any changes to the routes file, you will need to restart
your network interface by entering


ifdown interface


followed by


ifup interface




For your LPIC-1/CompTIA Linux+ exam, you also need to be familiar with
how to manage routes with the route command at the shell prompt. You
use the route command to display or modify the routing table on the
Linux host. If you enter


route 


without options, it simply displays the current routing table, as shown in this example:




 openSUSE:/ # route
Kernel IP routing table
Destination    Gateway     Genmask           Flags Metric Ref   Use Iface
default        10.0.0.1    0.0.0.0           UG    0      0     0 ens32
10.0.0.0       *           255.255.255.0     U     0      0     0 ens32
loopback       *           255.0.0.0         U     0      0     0 lo



You can add routes to the host’s route table by entering



route add –net network_address netmask netmask gw router_address



For example, suppose you need to add a route to the 192.168.2.0/24 network through
the router with an IP address of 10.0.0.254. You could do this by
entering



route add –net 192.168.2.0 netmask 255.255.255.0 gw 10.0.0.254 



at the shell prompt.



You can also remove existing routes from the routing table on a Linux
host using the route command. This is done by entering



route del –net network_address netmask netmask gw router_address 



at the shell prompt.


For example, suppose you want to remove the route just added in the
preceding paragraph. You could do this by entering



route del –net 192.168.2.0 netmask 255.255.255.0 gw 10.0.0.254 



at the shell prompt.



You can also use route to set the default route. This is done by
entering



route add default gw router_address 



at the shell prompt. For example, if you want to add 10.0.0.254 as your default gateway router,
you would enter




route add default gw 10.0.0.254 



at the shell prompt.




TIP    Changes made with the route command are not persistent! If you
want the route changes to be persistent across reboots, you need to
add them to your



/etc/sysconfig/network/routes 



file.



You can also use the ip command at the shell prompt to manage routing.
For example, to view the routing table, you can enter ip route show at
the shell prompt, as shown here:


openSUSE:/ # ip route show
default via 10.0.0.1 dev ens32
10.0.0.0/24 dev ens32  proto kernel  scope link  src 10.0.0.83
127.0.0.0/8 dev lo  scope link




You can also use the ip command to add a static route to the routing
table. This is done by entering



ip route add network/prefix via router_ip_address dev interface 



at the shell prompt. In the following example shown, I’ve added a route to the
192.168.5.0/24 network through a router with an IP address of 10.0.0.254:





openSUSE:/ # ip route add 192.168.5.0/24 via 10.0.0.254 dev ens32
openSUSE:/ # ip route show
default via 10.0.0.1 dev ens32
10.0.0.0/24 dev ens32  proto kernel  scope link  src 10.0.0.83
127.0.0.0/8 dev lo  scope link
192.168.5.0/24 via 10.0.0.254 dev ens32





You can also remove a route from the routing table by entering



ip route del network/prefix 



at the shell prompt.


For example, to remove the 192.168.5.0/24 route I just added, I would enter



ip route del 192.168.5.0/24








LX0-104 Exam Objectives (S)

Configuring Network III

Configuring IPv4 Parameters


Remember that you need to configure your network interface with four
parameters in order for the system to participate on an IP-based
computer network. These include the following:


• IP address
• Subnet mask
• Default gateway router address
• DNS server address



There are two different ways to do this, as discussed in Table 15-2.




If you want to statically assign IP address parameters to a Linux
system, you can use the ifconfig command. If


ifconfig 


is entered without any options, it displays the current status of all network
interfaces in the system, as shown in Figure 15-10.




NOTE When you run ifconfig, you’ll notice that your system probably
has two or more interfaces listed, not just one. The extra interface
labeled lo is the loopback interface and is usually assigned a special
IP address of 127.0.0.1. This is a virtual interface, not an actual
hardware interface. It’s used for internal communications, for
diagnostics, and so on.




Notice in Figure 15-10 that two network interfaces are displayed:


ens32 and lo.


The ens32 interface is the Ethernet network interface installed in the system.


The lo interface is the local loopback virtual network interface.

The lo interface is required for many Linux services to run properly, so don’t tinker with it.


Notice in Figure 15-10 that ifconfig also displays extensive information about each
network interface. Some of the more important parameters include those
shown in Table 15-3.




In addition to displaying information about a particular network
interface, ifconfig can also configure the network interface with the
IP address parameters discussed earlier. The syntax for using ifconfig
is

ifconfig interface ip_address netmask subnet_mask broadcast broadcast_ address 

For example, suppose I want to assign the ens32
interface an IP address of 192.168.1.1, a subnet mask of
255.255.255.0, and a broadcast address of 192.168.1.255. I would enter


ifconfig ens32 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 

at the shell prompt.


It’s important to remember that this IP address assignment isn’t
persistent. 

If you reboot the system, it will be lost. To make it
persistent, you need to configure a special file in the


/etc/sysconfig/network 

directory.

For example, the file used to configure the Ethernet interface on my system is named


ifcfg-ens32


NOTE On some distributions, this file will be named using the MAC
address of the NIC. For example,


ifcfg-eth-id-00:0c:29:d1:52:d4


would be the configuration file for the Ethernet interface in the system
with a MAC address of 00:0C:29:D1:52:D4, which will be the first
interface if there is only one NIC installed. Other distributions will
name this file using the alias assigned to the interface, such as
eth0, ens1, and so on.




This file is used to configure the interface when the system is
powered on. Sample parameters for this interface are shown here:


openSUSE:~ # cat /etc/sysconfig/network/ifcfg-ens32
BOOTPROTO='dhcp'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU=''
NAME='82545EM Gigabit Ethernet Controller (Copper)'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'




Some of the configuration options you can use in this configuration
file are listed in Table 15-4.




The lines for IPADDR, NETMASK, NETWORK, and BROADCAST are not required
if BOOTPROTO is set to “dhcp”.

The

/etc/hostname

file configures your Linux system’s hostname. After making any changes to these files,
you will need to restart your network interface to apply the changes. To
do this, simply enter 


ifdown interface 


followed by


ifup interface


where interface is the alias of the interface, such as ens32.





This is all well and good if you want to use a static address
assignment, but what if you want to get an address dynamically from a
DHCP server? You can configure your network interface to do this using
the


dhclient 


command at the shell prompt. The syntax for using this command is


dhclient interface


For example, you could enter


dhclient ens32


to specify that your interface get its IP address information
dynamically from a DHCP server. This is shown in Figure 15-11.




Notice in Figure 15-11 that the dhclient utility broadcasted a
DHCPREQUEST packet on the ens32 interface. In response, the DHCP
server with an IP address of 10.0.0.1 sent a DHCPACK packet back with
an IP address of 10.10.0.83 that was assigned to the ens32 interface.





Another utility you can use to manage IP addressing on a Linux system
is the ip command. For example, to view your current configuration,
you can enter


ip addr show 


at the shell prompt, as shown here:



openSUSE:/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:0c:29:b0:9f:b5 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.83/24 brd 10.0.0.255 scope global ens32
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:feb0:9fb5/64 scope link
       valid_lft forever preferred_lft forever



To use the


ip 


command to configure IP addressing parameters, enter


ip addr add ip_address dev interface 


at the shell prompt. For example, to set the IP address assigned to my ens32 network interface to
10.0.0.84, I would enter



ip addr add 10.0.0.84 dev ens32



To remove an IP address from an interface, just enter



ip addr del ip_address dev interface 



at the shell prompt.






You can also use the ip command to disable and enable a network
interface in the system.


To disable an interface, enter


ip link set interface down 


at the shell prompt.


To bring a disabled interface back online, enter



ip link set interface up



at the shell prompt.








In addition to the command-line utilities discussed here, most Linux
distributions provide some kind of graphical interface you can use to
configure your network interfaces. For example, on SUSE Linux, you can
use the Network Settings YaST module to configure your network board
as well as the IP address information assigned to it. This module is
shown in Figure 15-12.








LX0-104 Exam Objectives (S)