Chapter 4.

TCP/IP
 TCP/IP stands for Transmission Control Protocol/Internet Protocol and is a suite of
communication protocols used to interconnect network devices on the internet.
TCP/IP is also used as a communications protocol in a private computer network (an
intranet or extranet).

 TCP/IP specifies how data is exchanged over the internet by providing end-to-end
communications that identify how it should be broken into packets, addressed,
transmitted, routed and received at the destination. TCP/IP requires little central
management and is designed to make networks reliable with the ability to recover
automatically from the failure of any device on the network.

 The two main protocols in the IP suite serve specific functions. TCP defines how
applications can create channels of communication across a network. It also manages
how a message is assembled into smaller packets before they are then transmitted
over the internet and reassembled in the right order at the destination address.
 Common TCP/IP Protocols include the following:
• Hypertext Transfer Protocol (HTTP) handles the communication between a

web server and a web browser.

• HTTP Secure handles secure communication between a web server and a web
browser.

• File Transfer Protocol handles transmission of files between computers.

⚫ TCP/IP uses the client-server model of communication in which a user or

machine (a client) is provided a service, like sending a webpage, by another
computer (a server) in the network.
⚫ Collectively, the TCP/IP suite of protocols is classified as stateless, which means
each client request is considered new because it is unrelated to previous
requests. Being stateless frees up network paths so they can be used
continuously.
 How to set up a Linux Box on your Network
 Connecting your Linux computer to a network is pretty straightforward, except when it is
not. In this article I discuss the main network configuration files for Red Hat-based Linux
distributions, and take a look at the two network startup services: the
venerable network startup, and the controversial Network Manager.

 Linux easily manages multiple network interface adapters. Laptops typically include both
wired and wireless interfaces, and may also support WiMax interfaces for cellular
networks. Linux desktop computers also support multiple network interfaces, and you
can use your Linux computer as a multi-network client, or as a router for internal
networks; such is the case with a couple of my own systems.

Interface Configuration Files

⚫ Every network interface has its own configuration file in the /etc/sysconfig/network-scripts directory. Each
interface has a configuration file named ifcfg-<interface-name>X, where X is the number of the interface,
starting with zero or 1 depending upon the naming convention in use; for example /etc/sysconfig/network-
scripts/ifcfg-eth0 for the first Ethernet interface.
⚫ Most of the other files in the /etc/sysconfig/network-scripts directory are scripts used to start, stop and
perform various network configuration activities.
⚫ Each interface configuration file is bound to a specific physical network interface by the MAC address of
the interface.
 Network Interface Naming Conventions
⚫ The naming conventions for network interfaces used to be simple, uncomplicated, and, I
thought, easy. Using ethX made sense to me and was easy to type. It did not require extra
steps to figure out what long and obscure name belonged to an interface. Unfortunately,
adding a new interface often forced the renaming of network interfaces, which broke
scripts and configurations. That has all changed, more than once.

⚫ After a short stint with some long and unintelligible network interface names, we now
have a third set of naming conventions which seem only marginally better. Names
like ethX are still used by CentOS 6.x.

⚫ The newest naming conventions, with names like eno1 and enp0s3 are used by RHEL 7,
CentOS 7, and more recent releases of Fedora.

Configuration file examples

⚫ This example network interface configuration file, ifcfg-eth0, defines a static IP address
configuration for a CentOS 6 server installation.
⚫ This file starts the interface on boot, assigns it a static IP address, defines a

domain and network gateway, specifies two DNS servers, and does not allow
non-root users to start and stop the interface.

⚫ The following interface configuration file, ifcfg-eno1, provides a DHCP

configuration for a desktop workstation.

⚫ In this second configuration file example, the DHCP entries, IP address, the search

domain, and all other network information are not defined because they are
supplied by the DHCP server. Configuration items like the DNS servers can be
overridden in the interface configuration file by adding DNS1 and DNS2 lines.

⚫ In both interface configuration files, the HWADDR line specifies the MAC address

of the physical network interface. This binds the physical interface to the interface
configuration file. You must change the MAC address in the file if you replace the
interface.

⚫ There are a couple ways to locate the MAC address of a NIC. I usually use the
ifconfig command which shows all installed NICs, thier MAC address and various
statistics. Many new NICs have their MAC address printed on the box or labelled
on the NIC itself.
 However, most interface configuration files are generated automatically during
installation or when the NIC is first detected after being newly installed, and the
MAC address is included as part of the new interface configuration file.

 The ONBOOT line specifies that the interface is to be activated at startup time. If
this line is changed to "no" the interface will have to be activated either manually,
or by NetworkManager after a user logs in.

 The USERCTL line specifies that non-privileged users cannot manage the
interface; that is they cannot turn it on and off. Setting this parameter to "yes"
allows regular users to activate and deactivate the interface.

 Notice that the lines in the interface configuration files are not sequence-sensitive,
and work just fine in any order. By convention, the option names are in uppercase
and the values are in lowercase. Option values can be enclosed in quotes, but that
is not necessary unless the value is more than a single word or number.
 Configuration Options
There are many configuration options for the interface configuration files. These are some of the
more common options:
• DEVICE: The logical name of the device, such as eth0 or enp0s2.
• HWADDR: The MAC address of the NIC that is bound to the file, such as 00:16:76:02:BA:DB
•ONBOOT: Start the network on this device when the host boots. Options are yes/no. This is
typically set to "no" and the network does not start until a user logs in to the desktop. If you need
the network to start when no one is logged in, set this to "yes".

• IPADDR: The IPAddress assigned to this NIC such as 192.168.0.10

• BROADCAST: The broadcast address for this network such as 192.168.0.255
• NETMASK: The netmask for this subnet such as the class C mask 255.255.255.0
• NETWORK: The network ID for this subnet such as the class C ID 192.168.0.0
• SEARCH: The DNS domain name to search when doing lookups on unqualified hostnames such
as "example.com"
•BOOTPROTO: The boot protocol for this interface. Options are static, DHCP, bootp, none. The
"none" option defaults to static.
• GATEWAY: The network router or default gateway for this subnet, such as 192.168.0.254
• ETHTOOL_OPTS: This option is used to set specific interface configuration items for the network
interface, such as speed, duplex state, and autonegotiation state. Because this option has several
independent values, the values should be enclosed in a single set of quotes, such as: "autoneg off speed 100
duplex full".
• DNS1: The primary DNS server, such as 192.168.0.254, which is a server on the local network. The DNS
servers specified here are added to the /etc/resolv.conf file when using NetworkManager, or when the
peerdns directive is set to yes, otherwise the DNS servers must be added to /etc/resolv.conf manually and
are ignored here.
• DNS2: The secondary DNS server, for example 8.8.8.8, which is one of the free Google DNS servers. Note
that a tertiary DNS server is not supported in the interface configuration files, although a third may be
configured in a non-volatile resolv.conf file.
• TYPE: Type of network, usually Ethernet. The only other value I have ever seen here was Token Ring but
that is now mostly irrelevant.
• PEERDNS: The yes option indicates that /etc/resolv.conf is to be modified by inserting the DNS server
entries specified by DNS1 and DNS2 options in this file. "No" means do not alter the resolv.conf file. "Yes"
is the default when DHCP is specified in the BOOTPROTO line.
• USERCTL: Specifies whether non-privileged users may start and stop this interface. Options are yes/no.
• IPV6INIT: Specifies whether IPV6 protocols are applied to this interface. Options are yes/no.
 If the DHCP option is specified, most of the other options are ignored. The only
required options are BOOTPROTO, ONBOOT and HWADDR. Other options that
you might find useful, that are not ignored, are the DNS and PEERDNS options if
you want to override the DNS entries supplied by the DHCP server.

The Deprecated Network File

There is one old and now deprecated file you might encounter. The network file usually
contains only a single comment line for current releases of Fedora, RHEL, and CentOS. It
is located in /etc/sysconfig and was used in the past to enable or disable networking. It was
also used to set the networking host name as shown in the following example:
NETWORKING=yes
HOSTNAME=host.example.com
This file has been present but unused in Fedora since release 19. It is still used in
RHEL/CentOS 6.x, but is no longer used in RHEL/CentOS 7.x. The network hostname is
now set in the /etc/hostname file.
 Other Network Files
⚫ The /etc/sysconfig/network-files directory contains many other files, all of
which are usually executable BASH scripts rather than configuration files.
This is, to me at least, one of the bothersome exceptions to the Linux
Filesystem Hierarchical Standard (FHS) which explicitly states that only
configuration files and not executable files are to be located in the /etc tree.

⚫ One other network configuration file you might find

in /etc/sysconfig/network-files is the route-<interface> file. If you want to set
up static routes on a multi-homed system, create a route file for each
interface. For example, the following file is named route-eth0, and defines
routes for that specific interface to both networks and individual hosts.
⚫

⚫
 . Configuring it is also a complex task.
Not every network, especially the small and home office network, can
afford it.
 Linux provides a zero-cost solution for the IP forwarding. If you have a
Linux system in your network, you can use it for the IP forwarding. The
below section explains this process step by step with a practical
example.
 For demonstration purpose, I will use three systems named as; Linux
(RHEL 7.2), PC-A (Windows 7), and PC-B (Ubuntu 18.4). I will use the
Linux system as the router and will use the remaining two systems (PC-
A and PC-B) to simulate the two different networks.
⚫ The following image shows the IP configuration of the PC-A (Windows 7).
The following image shows the IP configuration of the PC-B (Ubuntu 18.04).
 Since the process of setting IP address varies in each OS and you
can use any OS to simulate the different networks, it's not feasible
for me to provide step by step instructions for each OS. However, if
you are using the Linux system for testing, you can follow the same
steps which I will use to configure the IP address on my Linux
system.

 Setting IP configuration on Linux system

 For this section, I assume that you have two or more PCs
configured with different IP networks. If you have multiple PCs in
each network, make sure each PC of each network uses the same
default gateway IP address.
The following image shows the LAB with IP configuration.
⚫ Make a list of all gateway IPs which you assigned in your network. For example,
in our LAB I have two networks and the default gateway IPs of both are;
192.168.1.1 and 172.168.1.1.
⚫ Now, configure all these gateway IP addresses in the Linux system. You can use
an individual network interface (LAN) for each gateway IP or can use a single
network interface for all gateway IPs. For example, in my LAB, I have two
gateway IPs. I can assign both gateway IPs to a single network interface or can
assign them to two separate network interfaces individually.
⚫ Since Linux allows us to configure multiple IP addresses on a single network
interface, the second option would be a waste of resources.
⚫ To configure gateway IPs on Linux, use the following steps.
⚫ Login from the root account and run the nmtui command.
 Select "Edit a connection" option and press the Enter key

Select available Ethernet (network interface) from the left pane and the Edit option from
the right pane and hit the Enter key.
Set IP configuration as explained in the following image.
⚫ When adding IPs, in step2, make sure you add IP with the subnet-

mask in slash notation. Slash notation is the other way to write the
subnet mask along with the IP address.

⚫ Select the Quit option and press Enter key.

  Restart the network service.

 The nmtui tool, which we used to set the IP configuration, automatically

applies all changes when quit form it. So, technically we don't need to
restart the network service. We use this command to verify that everything
is configured properly. Confirm the IP configuration. To print the IP
configuration of all network interfaces, use the "ip addr" command.
⚫ At this point, systems from different networks can access the default

gateway, but they can't access the system of another network. To verify
connectivity between systems and gateway, you can use the ping command.

⚫ The following image shows connectivity between PC-A and the default
gateway.
The following image shows connectivity between PC-B and the default gateway.
 Enabling IP forwarding on Linux
⚫ Run the following command to enable the IP forwarding.

⚫ This command enables IP forwarding in the current session. It does not make a change
in that configuration file which Linux reads at the startup. By default, the state of IP
forwarding is disabled in the configuration file. It means Linux will automatically
disable the IP forwarding again when you will restart the system.
⚫ To enable IP forwarding permanently, run the following command.

⚫ Once the IP forwarding is enabled, Linux works as the router. It forwards all
incoming data packets to their correct destination.
⚫ To verify this, test connectivity between the PCs of different networks.
⚫ The following image confirms connectivity between PC-A and PC-B from the
Windows (PC-A) system.
 The following image verifies connectivity between PC-B and PC-A from the
Ubuntu (PC-B) system.
 How to configure an Apache web server
 Installation and configuration of the Apache web server must be performed as
root.
 Configuring the firewall also needs to be performed as root.
 Using a browser to view the results of this work should be done as a non-root
user. (I use the user student on my virtual host.)

Installation

 The Apache web server is easy to install. With one command, you can install it
and all necessary dependencies:
$ dnf install httpd
 All the configuration files for Apache are located
in /etc/httpd/conf and /etc/httpd/conf.d.
 The data for websites you'll run with Apache is located in /var/www by default,
but you can change that if you want.
 The primary Apache configuration file is /etc/httpd/conf/httpd.conf. It contains
a lot of configuration statements that don't need to be changed for a basic
installation. In fact, only a few changes must be made to this file to get a basic
website up and running. The file is very large so, rather than clutter this article
with a lot of unnecessary stuff, I will show only those directives that you need
to change.
 First, take a bit of time and browse through the httpd.conf file to familiarize
yourself with it. One of the things I like about Red Hat versions of most
configuration files is the number of comments that describe the various sections
and configuration directives in the files. The httpd.conf file is no exception, as
it is quite well commented. Use these comments to understand what the file is
configuring.
 The first item to change is the Listen statement, which defines the IP address
and port on which Apache is to listen for page requests. Right now, you just
need to make this website available to the local machine, so use
the localhost address. The line should look like this when you finish:
 Listen 127.0.0.1:80
 With this directive set to the IP address of the localhost, Apache will listen
only for connections from the local host. If you want the web server to listen
for connections from remote hosts, you would use the host's external IP
address.
 The DocumentRoot directive specifies the location of the HTML files that
make up the pages of the website. That line does not need to be changed
because it already points to the standard location. The line should look like
this:
 DocumentRoot "/var/www/html“
 The Apache installation RPM creates the /var/www directory tree. If you
wanted to change the location where the website files are stored, this
configuration item is used to do that. For example, you might want to use a
different name for the www subdirectory to make the identification of the
website more explicit. That might look like this:
 DocumentRoot "/var/mywebsite/html“
 These are the only Apache configuration changes needed to create a simple
website. For this little exercise, only one change was made to
the httpd.conf file—the Listen directive. Everything else is already
configured to produce a working web server.
 One other change is needed, however: opening port 80 in our firewall. I
use iptables as my firewall, so I change /etc/sysconfig/iptables to add a
statement that allows HTTP protocol. The entire file looks like this:

 The line I added is the third from the bottom, which allows incoming traffic on port 80.
Now I reload the altered iptables configuration.
[root@testvm1 ~]# cd /etc/sysconfig/ ; iptables-restore iptables
 Create the index.html file
 The index.html file is the default file a web server will serve up when you
access the website using just the domain name and not a specific HTML
file name.
 In the /var/www/html directory, create a file with the name index.html.
Add the content Hello World. You do not need to add any HTML markup
to make this work.
 The sole job of the web server is to serve up a stream of text data, and the
server has no idea what the date is or how to render it. It simply transmits
the data stream to the requesting host.

 After saving the file, set the ownership to apache.apache.

[root@testvm1 html]# chown apache.apache index.html
 Start Apache
 Apache is very easy to start. Current versions of Fedora use systemd.
Run the following commands to start it and then to check the status of the
server:
 The BIND DNS software is one of the most reliable and proven ways to
configure name resolution on a Linux system. Having been around since the
1980s, it remains the most popular Domain Name Server (DNS) currently in
use.
 Follow along with the instructions below to get BIND DNS set up and
configured on your own server.

In this lesson we will learn:

 How to install BIND on major Linux distros
 How to create a DNS zone file
 How to configure address to name mappings
 How to check BIND zone file and configuration
 How to start or restart the BIND DNS service
 How to test a BIND configuration with dig command
Configuring and Testing a BIND nameserver on Linux
 Before diving into all of the BIND configuration, it's helpful to have some context of how we
are configuring our network. Refer to the following list to see how the IP addresses are
assigned to various systems on our network.

 Nameserver IP address: 192.168.135.130

 Sample domain / host: linuxconfig.org
 Authoritative nameservers for a linuxconfig.org zone: ns1.linuxconfig.org ( 192.168.0.10 )
and ns2.linuxconfig.org ( 192.168.0.11 )
 www and mail services that linuxconfig.org will point to: 192.168.0.10
 Install BIND on Major Linux Distros
 The simplest way to install the latest version of BIND (BIND9) is by using
your system's package manager.
 On a Debian or Ubuntu Linux server you can install a BIND nameserver with
the following linux command:
$ sudo apt install bind9 dnsutils
 Or with this command on CentOS, Fedora, AlmaLinux, and other RHEL-
based distros:
$ sudo dnf install bind dnsutils
 The dnsutils software is not a compulsory package to run BIND nameserver,
but we will use the dig command which is part of this package as a testing
tool of your BIND configuration.
 Creating a DNS Zone File
At this stage we will need to create a new zone file for a domain linuxconfig.org.
Follow the steps below as we do that.
 SOA Record: nameserver authoritative for a zone linuxconfig.org is
ns1.linuxconfig.org and admin.linuxconfig.org is an email address of a person
responsible for this DNS zone.

 NS Records: two nameservers for the linuxconfig.org zone are

ns[1,2].linuxconfig.org.
 MX ( Mail Exchange): linuxconfig.org mail exchange record. Number 10 means a
preference for discarding a records A - A simply means address or in other words in
linuxconfig.org's zone a ns1 would have an A ( address ) 192.168.0.10.
 CNAME Record ( Canonical Name record): restart the query using the canonical
name instead of the original name

Configure Address to Name Mappings

 At this stage, the BIND DNS server can resolve an IP address mapped to a
linuxconfig.org host. What we should do now is the teach our nameserver the
other way around, which is, to resolve a host from an IP address.
 Updating a BIND Configuration File
 At this point we should have two files ready:
 /etc/bind/zones/master/db.linuxconfig.org
 /etc/bind/zones/master/db.192.168.0
 Checking BIND's zone files and configuration
 Before we attempt to start a BIND nameserver with a new zone and
configuration, here are some tools to check to make sure we have not done
some typo or misconfiguration.
 Since the above commands have confirmed that our BIND configuration is valid,
we can start the BIND service for all of these changes to take effect.
Installing the Software on Linux
Since, Postfix is a default package in the Ubuntu repositories, we can install it easily by
using the ‘apt-get’ command. Before we install the packages, we need to update the system.
We can do this by using the below command.

Here is a sample demo, I used hanuman.com as a domain.

Here it will ask you to enter the type of the mail configuration which we want to
configure on our server. In this demo, we are going to choose “internet site” which
suits the environment.
 Configuring Postfix
 Now, we needed to change some basic settings in the Postifx main configuration.
file.

 As we discussed in above the ‘mydestination’ parameters has been modified with the
FQDN which we entered during the installation process. This holds any domains that the
installation of Postfix is responsible.

 We need to specify the ‘mynetworks’ parameter, which defines the computers which are
able to use this mail server. In general, we set to local only(127.0.0.0/8), We can modify
this by allowing the other hosts to use and send but this may be a vulnerability.
 Testing the Postfix Configuration
 We can test the server that can receive and route the emails. We can test this by
sending email to one of the email address which we mentioned in the virtual
accounts.

 We will get mail delivered to a file that matches the username in the /var/mail folder.
 By default the mail program is not installed on the Ubuntu we can install this using
the below command.
⚫ Squid is a full-featured web proxy cache server application which provides proxy and cache

services for Hyper Text Transport Protocol (HTTP), File Transfer Protocol (FTP), and other
popular network protocols. Squid can implement caching and proxying of Secure Sockets Layer

(SSL) requests and caching of Domain Name Server (DNS) lookups, and perform transparent

caching. Squid also supports a wide variety of caching protocols, such as Internet Cache

Protocol (ICP), the Hyper Text Caching Protocol (HTCP), the Cache Array Routing Protocol

(CARP), and the Web Cache Coordination Protocol (WCCP).

⚫ The Squid proxy cache server is an excellent solution to a variety of proxy and caching server

needs, and scales from the branch office to enterprise level networks while providing extensive,
granular access control mechanisms, and monitoring of critical parameters via the Simple
Network Management Protocol (SNMP). When selecting a computer system for use as a
dedicated Squid caching proxy server for many users ensure it is configured with a large
amount of physical memory as Squid maintains an in-memory cache for increased performance.
 Installation
 At a terminal prompt, enter the following command to install the Squid server:
sudo apt install squid

Configuration
 Squid is configured by editing the directives contained within
the /etc/squid/squid.conf configuration file.

 The following examples illustrate some of the directives which may be

modified to affect the behavior of the Squid server.
 sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original sudo
chmod a-w /etc/squid/squid.conf.original
 To set your Squid server to listen on TCP port 8888 instead of the default TCP port 3128,
change the http_port directive as such:
 http_port 8888
 Change the visible_hostname directive in order to give the Squid server a specific
hostname. This hostname does not necessarily need to be the computer’s hostname. In this
example it is set to weezie
 visible_hostname weezie
 The cache_dir option allows one to configure an on-disk cache, the default option is on-
memory cache. The cache_dir directive takes the following arguments:
 cache_dir <Type> <Directory-Name> <Fs-specific-data> [options]
 In the config file you can find the default cache_dir directive commented out:
#Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256
 You can just use the default option but you can also customize your cache directory, basically
changing the <Type> of this directory, it can be:
• ufs: the old well-known Squid storage format that has always been there.
• aufs: uses the same storage format as ufs, utilizing POSIX-threads to avoid blocking the main
Squid process on disk-I/O. This was formerly known in Squid as async-io.
•diskd: uses the same storage format as ufs, utilizing a separate process to avoid blocking the main
Squid process on disk-I/O.

• rock: is a database-style storage. All cached entries are stored in a “database” file, using fixed-size
slots. A single entry occupies one or more slots.
 If you want to use a different directory type please take a look at their different options.
 Using Squid’s access control, you may configure use of Internet services proxied by Squid to be
available only users with certain Internet Protocol (IP) addresses. For example, we will illustrate
access by users of the 192.168.42.0/24 subnetwork only:
 Add the following to the bottom of the ACL section of your /etc/squid/squid.conf file: acl
fortytwo_network src 192.168.42.0/24
 Then, add the following to the top of the http_access section of your /etc/squid/squid.conf file:
http_access allow fortytwo_network
 Using the excellent access control features of Squid, you may configure use of
Internet services proxied by Squid to be available only during normal business
hours. For example, we’ll illustrate access by employees of a business which is
operating between 9:00AM and 5:00PM, Monday through Friday, and which uses
the 10.1.42.0/24 subnetwork:
 Add the following to the bottom of the ACL section of
your /etc/squid/squid.conf file: acl biz_network src 10.1.42.0/24 acl biz_hours time
M T W T F 9:00-17:00
 Then, add the following to the top of the http_access section of
your /etc/squid/squid.conf file: http_access allow biz_network biz_hours
 Note: After making changes to the /etc/squid/squid.conf file, save the file and
restart the squid server application to effect the changes using the following
command entered at a terminal prompt:
 sudo systemctl restart squid.service
 Network Configuration and Information
Network Configuration Files
 The graphical helper tools edit a specific set of network configuration files, using a
couple of basic commands. The exact names of the configuration files and their
location in the file system is largely dependent on your Linux distribution and version.
However, a couple of network configuration files are common on all UNIX systems:

/etc/hosts
 The /etc/hosts file always contains the localhost IP address, 127.0.0.1, which is
used for interprocess communication. Never remove this line! Sometimes
contains addresses of additional hosts, which can be contacted without using an

external naming service such as DNS (the Domain Name Server).

 /etc/resolv.conf
search mylan.com nameserver 193.134.20.4
 The /etc/resolv.conf file configures access to a DNS server. This file
contains your domain name and the name server(s) to contact:

[bob@tux ~] grep hosts /etc/nsswitch.conf hosts: files dns

/etc/nsswitch.conf
 The /etc/nsswitch.conf file defines the order in which to contact
different name services. For Internet use, it is important
that dns shows up in the "hosts" line:
 This instructs your computer to look up hostnames and IP addresses
first in the /etc/hosts file, and to contact the DNS server if a given
host does not occur in the local hosts file.

 Other possible name services to contact are LDAP, NIS and NIS+.
 Network Configuration Commands
The ip command
 The distribution-specific scripts and graphical tools are front-ends
to ip (or ifconfig and route on older systems) to display and configure the kernel's
networking configuration.

 The ip command is used for assigning IP addresses to interfaces, for setting up routes to
the Internet and to other networks, for displaying TCP/IP configurations etcetera.
 The following commands show IP address and routing information:
Things to note:
 Two network interfaces, even on a system that has only one network interface
card: "lo" is the local loop, used for internal network communication; "eth0" is
a common name for a real interface. Do not ever change the local loop
configuration, or your machine will start mallfunctioning! Wireless interfaces
are usually defined as "wlan0"; modem interfaces as "ppp0", but there might
be other names as well.

 IP addresses, marked with "inet": the local loop always has 127.0.0.1, the
physical interface can have any other combination.
 The hardware address of your interface, which might be required as part of the
authentication procedure to connect to a network, is marked with "ether". The
local loop has 6 pairs of all zeros, the physical loop has 6 pairs of hexadecimal
characters, of which the first 3 pairs are vendor-specific.
 The ifconfig Command
 While ip is the most novel way to configure a Linux system, ifconfig is still very
popular. Use it without option for displaying network interface information:

Here, too, we note the most important aspects of the interface configuration:
•The IP address is marked with "inet addr".
•The hardware address follows the "HWaddr" tag.
Both ifconfig and ip display more detailed configuration information and a number of statistics about
each interface and, maybe most important, whether it is "UP" and "RUNNING".
 PCMCIA Commands
 On your laptop which you usually connect to the company network using the
onboard Ethernet connection, but which you are now to configure for dial-in at
home or in a hotel, you might need to activate the PCMCIA card. This is done
using the cardctl control utility, or the pccardctl on newer distributions.

 A usage example:
cardctl insert
 Now the card can be configured, either using the graphical or the command line
interface. Prior to taking the card out, use this command:
cardctl eject
 However, a good distribution should provide PCMCIA support in the network
configuration tools, preventing users from having to execute PCMCIA commands
manually.
 Network Interface Names
 On a Linux machine, the device name lo or the local loop is linked with the internal 127.0.0.1
address. The computer will have a hard time making your applications work if this device is not
present; it is always there, even on computers which are not networked.
 The first ethernet device, eth0 in the case of a standard network interface card, points to your
local LAN IP address. Normal client machines only have one network interface card. Routers,
connecting networks together, have one network device for each network they serve.
 If you use a modem to connect to the Internet, your network device will probably be
named ppp0.
 There are many more names, for instance for Virtual Private Network interfaces (VPNs), and
multiple interfaces can be active simultaneously, so that the output of
the ifconfig or ip commands might become quite extensive when no options are used. Even
multiple interfaces of the same type can be active. In that case, they are numbered sequentially:
the first will get the number 0, the second will get a suffix of 1, the third will get 2, and so on.
This is the case on many application servers, on machines which have a failover configuration,
on routers, firewalls and many more.
 Checking the host configuration with netstat
 Apart from the ip command for displaying the network configuration, there's the
common netstat command which has a lot of options and is generally useful on
any UNIX system.

 Routing information can be displayed with the -nr option to the netstat command:
 This is a typical client machine in an IP network. It only has one network
device, eth0. The lo interface is the local loop.

 When this machine tries to contact a host that is on another network than its
own, indicated by the line starting with 0.0.0.0, it will send the connection
requests to the machine (router) with IP address 192.168.42.1, and it will use its
primary interface, eth0, to do this.
 Hosts that are on the same network, the line starting with 192.168.42.0, will
also be contacted through the primary network interface, but no router is
necessary, the data are just put on the network.
 Machines can have much more complicated routing tables than this one, with
lots of different "Destination-Gateway" pairs to connect to different networks.
If you have the occasion to connect to an application server, for instance at
work, it is most educating to check the routing information.
 Other Hosts
 An impressive amount of tools is focused on network management and remote
administration of Linux machines. Your local Linux software mirror will offer plenty of
those. It would lead us too far to discuss them in this document, so please refer to the
program-specific documentation.

 We will only discuss some common UNIX/Linux text tools in this section.

The host command

 To display information on hosts or domains, use the host command:
 The Ping Command
 To check if a host is alive, use ping. If your system is configured to send more than one
packet, interrupt ping with the Ctrl+C key combination:

The Traceroute Command

 To check the route that packets follow to a network host, use the traceroute command:
How to configure Dynamic Host Configuration Protocol (DHCP)
in Linux
 Dynamic Host Configuration Protocol (DHCP) is a client/server protocol that
automatically provides an Internet Protocol (IP) host with its IP address and
other related configuration information such as the subnet mask and default
gateway.

Dynamic Host Configuration Protocol (DHCP) Lease Process

 The process of leasing an IP address occurs in the following four phases:
•Discovery (Message from DHCP client to DHCP Server): The DHCP client
broadcasts a DHCP discover message on the network containing its MAC
address to find a DHCP server running in the network.

• Offer (Message from DHCP server to DHCP client): Each DHCP server on
the network that receives the request responds with a DHCP offer message. An
offered IP address is included in the message.
•Request (Message from DHCP client to DHCP Server): When a DHCP client
receives a DHCPOffer packet, it responds by broadcasting a DHCPRequest
packet that contains the offered IP address, and shows acceptance of the offered
IP address. If multiple DHCP servers respond, the client selects the first offer it
receives and broadcasts a DHCP request for the IP address. The message is
broadcast on the network because the client has not yet been assigned an IP
address; it has only been offered one.

•Acknowledge (Message from DHCP server to DHCP client): The DHCP

server responds with a DHCPACK (acknowledgment) granting the client's request
to use the IP address. The DHCPACK also contains information about any DHCP
options that have been configured on the server (such as the IP address of the
DNS server).
Dynamic Host Configuration Protocol (DHCP) configuration file (/etc/dhcpd.conf)
 ddns-update-style interim: Confirms Dynamic DHCP.
 ignore client-updates: This setting don't allow users on client computers to
change their host names.

 subnet 192.168.0.0 netmask 255.255.255.0 Describes a network with an

address of 192.168.0.0 and a subnet mask of 255.255.255.0. This allows the
local DHCP server to assign addresses in the range 192.168.0.1 to
192.168.0.254 to different computers on this network. If you've configured a
different network IP address, you'll want to change these settings accordingly.

 option routers: Lists the default router.

 option subnet-mask: Specifies the subnet mask for the local network.
 option nis-domain: Specifies the NIS domain name
 option domain-name: Domain name for the network option domain-name-
servers DNS Server for the network
 option time-offset: Lists the difference from Greenwich Mean Time.
 option ntp-servers Network Time Protocol (NTP) servers
 option netbios-name-servers: WINS (Windows Internet Name Servers) Servers.
Used for NetBIOS name resolution.

 range dynamic-bootp: BOOTP range

 default-lease-time: Specifies the lease time for IP address information, in seconds.
 max-lease-time Specifies the maximum lease time for IP address information, in
seconds.
 next-server: Boot server for network computers
Linux Dynamic Host Configuration Protocol (DHCP) leases file is

/var/lib/dhcpd/dhcpd.leases.
 Dynamic Host Configuration Protocol (DHCP) Client
Configuration
 The command used to set up a DHCP client is the "dhclient" command, or
"system-config-network" GUI tool. Make sure that the /etc/sysconfig/network
configuration file includes the following line:
NETWORKING=yes
 Next, make sure that the /etc/sysconfig/network-scripts/ifcfg-eth0 script
contains the following lines (if you're using a different network device, modify
the appropriate file in /etc/sysconfig/network-scripts directory):
BOOTPROTO='dhcp’ ONBOOT='yes'

 The next time when the client is rebooted, it will get the IP address information
automatically from the DHCP server configured in the network.
 RPC-Based Services and INET Super Server
The inetd Super Server
 Programs that provide application services via the network are called network daemons.
A daemon is a program that opens a port, most commonly a well-known service port, and
waits for incoming connections on it. If one occurs, the daemon creates a child process
that accepts the connection, while the parent continues to listen for further requests. This
mechanism works well, but has a few disadvantages; at least one instance of every
possible service you wish to provide must be active in memory at all times. In addition,
the software routines that do the listening and port handling must be replicated in every
network daemon.
 To overcome these inefficiencies, most Unix installations run a special network daemon,
what you might consider a "super server." This daemon creates sockets on behalf of a
number of services and listens on all of them simultaneously. When an incoming
connection is received on any of these sockets, the super server accepts the connection
and spawns the server specified for this port, passing the socket across to the child to
manage. The server then returns to listening.
 The most common super server is called inetd, the Internet Daemon. It is started at
system boot time and takes the list of services it is to manage from a startup file
named /etc/inetd.conf. In addition to those servers, there are a number of trivial services
performed by inetd itself called internal services. They include chargen, which simply
generates a string of characters, and daytime, which returns the system's idea of the time
of day.
 A Sample /etc/inetd.conf File

 The tftp daemon is shown commented out as well. tftp implements the Trivial File
Transfer Protocol (TFTP), which allows someone to transfer any world-readable
files from your system without password checking. This is especially harmful with
the /etc/passwd file, and even more so when you don't use shadow passwords.
 Since opening a computer to network access involves many security risks,
applications are designed to guard against several types of attacks. Some
security features, however, may be flawed (most drastically demonstrated
by the RTM Internet worm, which exploited a hole in a number of
programs, including old versions of the sendmail mail daemon), or do not
distinguish between secure hosts from which requests for a particular
service will be accepted and insecure hosts whose requests should be
rejected.
 We've already briefly discussed the finger and tftp services. Network
Administrator would want to limit access to these services to "trusted hosts"
only, which is impossible with the usual setup, for which inetd provides this
service either to all clients or not at all.
 The Services and Protocols Files
 The port numbers on which certain "standard" services are offered are defined in
the Assigned Numbers RFC. To enable server and client programs to convert
service names to these numbers, at least part of the list is kept on each host; it is
stored in a file called /etc/services.An entry is made up like this:

service port/protocol [aliases]

 Here, service specifies the service name, port defines the port the service is
offered on, and protocol defines which transport protocol is used. Commonly,
the latter field is either udp or tcp. It is possible for a service to be offered for
more than one protocol, as well as offering different services on the same port as
long as the protocols are different.

 The aliases field allows you to specify alternative names for the same service.
A Sample /etc/services File
A Sample /etc/protocols File
 Remote Procedure Call (RPC)
 The general mechanism for client-server applications is provided by the Remote
Procedure Call (RPC) package. RPC was developed by Sun Microsystems and is a
collection of tools and library functions. Important applications built on top of RPC
are NIS, the Network Information System and NFS, the Network File System.
 An RPC server consists of a collection of procedures that a client can call by sending
an RPC request to the server along with the procedure parameters. The server will
invoke the indicated procedure on behalf of the client, handing back the return value,
if there is any. In order to be machine-independent, all data exchanged between client
and server is converted to the External Data Representation format (XDR) by the
sender, and converted back to the machine-local representation by the receiver. RPC
relies on standard UDP and TCP sockets to transport the XDR formatted data to the
remote host. Sun has graciously placed RPC in the public domain; it is described in a
series of RFCs.
 Sometimes improvements to an RPC application introduce incompatible changes in
the procedure call interface. Of course, simply changing the server would crash all
applications that still expect the original behavior. Therefore, RPC programs have
version numbers assigned to them, usually starting with 1, and with each new version
of the RPC interface, this counter will be bumped up. Often, a server may offer
several versions simultaneously; clients then indicate by the version number in their
requests which implementation of the service they want to use.
A Sample /etc/rpc File
 In TCP/IP networks, the authors of RPC faced the problem of mapping program
numbers to generic network services. They designed each server to provide both a
TCP and a UDP port for each program and each version. Generally, RPC
applications use UDP when sending data, and fall back to TCP only when the data
to be transferred doesn't fit into a single UDP datagram.
 Of course, client programs need to find out to which port a program number maps.
Using a configuration file for this would be too unflexible; since RPC applications
don't use reserved ports, there's no guarantee that a port originally meant to be
used by our database application hasn't been taken by some other process.
Therefore, RPC applications pick any port they can get and register it with a
special program called the portmapper daemon. The portmapper acts as a service
broker for all RPC servers running on its machine. A client that wishes to contact a
service with a given program number first queries the portmapper on the server's
host, which returns the TCP and UDP port numbers the service can be reached at.
 This method introduces a single point of failure, much like the inetd daemon does
for the standard Berkeley services. However, this case is even a little worse
because when the portmapper dies, all RPC port information is lost; this usually
means you have to restart all RPC servers manually or reboot the entire machine.
 On Linux, the portmapper is called /sbin/portmap, or
sometimes /usr/sbin/rpc.portmap. Other than making sure it is started from your
network boot scripts, the portmapper doesn't require any configuration.

Configuring Remote Login and Execution

 It's often very useful to execute a command on a remote host and have input or
output from that command be read from, or written to, a network connection. The
traditional commands used for executing commands on remote hosts
are rlogin, rsh and rcp.

 The ssh package provides replacements called slogin, ssh, and scp.
 Each of these commands spawns a shell on the remote host and allows the
user to execute commands. Of course, the client needs to have an account on
the remote host where the command is to be executed. Thus, all these
commands use an authentication process.
 The r commands use a simple username and password exchange between the
hosts with no encryption, so anyone listening could easily intercept the
passwords. The ssh command suite provides a higher level of security: it uses
a technique called Public Key Cryptography, which provides authentication
and encryption between the hosts to ensure that neither passwords nor session
data are easily intercepted by other hosts.
 It is possible to relax authentication checks for certain users even further. For
instance, if you frequently have to log into other machines on your LAN, you
might want to be admitted without having to type your password every time.
 This was always possible with the r commands, but the ssh suite allows you to do
this a little more easily. It's still not a great idea because it means that if an
account on one machine is breached, access can be gained to all other accounts
that user has configured for password-less login, but it is very convenient and
people will use it. Let's talk about removing the r commands and getting ssh to
work instead.

Disabling the r; Commands

 Start by removing the r commands if they're installed. The easiest way to
disable the old r commands is to comment out (or remove) their entries in
the /etc/inetd.conf file. The relevant entries will look something like this:
 Installing and Configuring SSH
The SSH Daemon
 The sshd daemon is the program that listens for network connections
from ssh clients, manages authentication, and executes the requested command.
It has one main configuration file called /etc/ssh/sshd_config and a special file
containing a key used by the authentication and encryption processes to
represent the host end. Each host and each client has its own key.
 A utility called ssh-keygen is supplied to generate a random key. This is usually
used once at installation time to generate the host key, which the system
administrator usually stores in a file called /etc/ssh/ssh_host_key. Keys can be
of any length of 512 bits or greater. By default, ssh-keygen generates keys of
1024 bits in length, and most people use the default. To generate a random key,
you would invoke the ssh-keygen command like this:

 # ssh-keygen -f /etc/ssh/ssh_host_key
 You will be prompted to enter a passphrase. However, host keys must not
use a passphrase, so just press the return key to leave it blank. The
program output will look something like:

 You will find at the end that two files have been created. The first is
called the private key, which must be kept secret and will be
in /etc/ssh/ssh_host_key. The second is called the public key and is one
that you can share; it will be in /etc/ssh/ssh_host_key.pub.
 It's important to make sure the permissions of the configuration files are correct
to ensure that system security is maintained. Use the following commands:

 The final stage of sshd administration daemon is to run it. Normally you'd create
an rc file for it or add it to an existing one, so that it is automatically executed at
boot time. The daemon runs standalone and doesn't require any entry in
the /etc/inetd.conf file. The daemon must be run as the root user.
 The syntax is very simple: /usr/sbin/sshd The sshd daemon will automatically
place itself into the background when being run. You are now ready to
accept ssh connections.
 The SSH Client
 There are a number of ssh client programs: slogin, scp and ssh. They each read the same
configuration file, usually called /etc/ssh/ssh_config. They each also read configuration
files from the .ssh directory in the home directory of the user executing them. The most
important of these files is the .ssh/config file, which may contain options that override
those specified in the /etc/ssh/ssh_config file, the .ssh/identity file, which contains the
user's own private key, and the corresponding .ssh/identity.pub file, containing the user's
public key. Other important files are .ssh/known_hosts and .ssh/authorized_keys; we'll talk
about those later in "Using ssh". First, let's create the global configuration file and the user
key file. /etc/ssh/ssh_config is very similar to the server configuration file. The rest of the
configuration options are detailed in the sshd manpage.

 You can add sections that match specific hosts or groups of hosts. The parameter to the
"Host" statement may be either the full name of a host or a wildcard specification, as we've
used in our example, to match all hosts. We could create an entry that used, for
example, Host *.vbrew.com to match any host in the vbrew.com domain.
 Example SSH Client Configuration File

 You should ask each of your users to run the ssh-keygen command just once to ensure their
key file is created correctly. The ssh-keygen will create their ~/.ssh/ directories for them
with appropriate permissions and create their private and public keys
in .ssh/identity and .ssh/identity.pub, respectively.A sample session should look like:
 Now ssh is ready to run.
 Using SSH
 We should now have the ssh command and it's associated programs installed
and ready to run. Let's now take a quick look at how to run them. First, we'll try
a remote login to a host. We can use the slogin program in much the same way
as we used the rlogin program in our example earlier in the book. The first time
you attempt a connection to a host, the ssh client will retrieve the public key of
the host and ask you to confirm its identity by prompting you with a shortened
version of the public key called a fingerprint.

 The administrator at the remote host should have supplied you in advance with
its public key fingerprint, which you should add to your .ssh/known_hosts file.
If the remote administrator has not supplied you the appropriate key, you can
connect to the remote host, but ssh will warn you that it does have a key and
prompt you whether you wish to accept the one offered by the remote host.
 Assuming that you're sure no one is engaging in DNS spoofing and you
are in fact talking to the correct host, answer yes to the prompt.
 The relevant key is then stored automatically in
your .ssh/known_hosts and you will not be prompted for it again. If, on
a future connection attempt, the public key retrieved from that host
does not match the one that is stored, you will be warned, because this
represents a potential security breach.
 A first-time login to a remote host will look something like: