Network Setup and Utilities

Prabhaker Mateti

Abstract: This is a refresher lecture. It should enable you to do the Linux router setup experiment in the OSIS lab. We describe a number of essential network setup utilities such as ping, traceroute, ifconfig, route. We suggest the use of newly emerging standard net clients such as ssh.

Other Internet Security Lectures by Mateti

Table of Contents

1. Educational Objectives
2. Network Setup and Utilities
   1. Network Card Drivers
   2. Configuring the Interface
   3. Setting up Routes
   4. Proxy Server
   5. Secure Shell, ssh
3. Lab Experiment
   1. Setup a Router
4. Acknowledgements
5. References

Educational Objectives

1. Make the student experience setting up a network and a Linux router.
2. Introduce a number of essential network setup utilities such as ping, traceroute, ifconfig, route.
3. Use newly emerging standard net clients such as ssh.

Network Setup and Utilities

This is a refresher lecture. It should enable you for the Linux router setup experiment in the OSIS lab.  Look up the man pages for details on the commands mentioned: dmesg, modprobe, ifconfig, route, etc. Even more basic details are in Mateti's Local Area Networks.

Network Card Drivers

The Linux kernel you will be booting is modularized.  Only the must-have modules are linked together into the kernel.  All other modules are loaded as needed.  The command lsmod lists the modules currently loaded. The command lspci lists the cards/devices attached to the PCI bus.

Configuring the Interface

Each network device needs to be assigned an IP address. The choice of the IP address may be done statically or dynamically via DHCP. The command spelled ifconfig (called ipconfig in Windows) assigns the IP address and sets other parameters. The relevant files in this context are:

/etc/iftab
/etc/network/interfaces
/etc/init.d/network*

Setting up Routes

An OS maintains an internal table, known as the routing table, that describes where the network packets that are in the OS buffers should be sent in the next hop. The route command manipulates this table. A simple host (i.e., non-router) in our lab, while in "normal" use for all classes (which ignores the second network card even though physically plugged-in) has the following:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.17.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.17.111  0.0.0.0         UG    0      0        0 eth0

You can tell that this host has an IP address on the 192.168.17.0 network, and its router is 192.168.17.111.

The router for our lab is quite simple:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
130.108.17.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.17.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         130.108.17.1    0.0.0.0         UG    0      0        0 eth1

Proxy Server

A proxy server (or simply, a proxy) P is a go-between for a client C that wishes to obtain the services of  a server S.  To the client C, P appears as a server.  P  receives requests from C.  It can apply various rules in deciding whether or not it should get that request honored and or log such requests.  P then conveys that request to S as thought the request originated from P. To the server S, P appears as a client.  The server S is wholly unaware that the request originated from C.

Secure Shell, ssh

We recommend that ssh be used in place of telnet, rlogin, rsh, rcp, etc.  Normal IP traffic has the following weaknesses that can be exploited to compromise security:  (a) weak authentication based on IP addresses that can be spoofed or reusable passwords that can be sniffed; (b) no privacy packets can be sniffed; (c) no integrity protection connections can be hijacked. Secure Shell (SSH) was designed to address these problems by providing a stronger authentication mechanism to identify both hosts and users and to enable secure connections between machines for executing commands and remote shells between them.

The current method (IPv4) of communicating between machines allows anyone to sniff the packets on the network. Passwords and all data are sent along in plain text and can be readily captured and analyzed. Secure shell foils sniffing attempts by encrypting the packets (using ciphers) and by only allowing connections with known machines (using RSA public key technology to authenticate). In general, it does not trust the network. However, an attacker can gain root access, through other means, to either the local machine or the remote machine.

Lab Experiment

Setup a Router

All work should be carried out in Operating Systems and Internet Security (OSIS) Lab, 429 Russ.   No other WSU facilities are allowed. Re-connect the machines the way they were before leaving the Lab.

For this lab, use the PCs numbered 19 to 30.

Objective:  Connect four machines (P0 .. P3) in the lab in a chain so that the middle two (P1 and P2) of them will behave like a router and set up the routing tables so as to TCP connect any machine (card) in the LAN with any other machine (card).

1. Prepare for this lab by reading Mateti's Local Area Networks.  This explains RJ-45 connectors, cross over cables, etc. 
2. Look up the man pages for details on the commands mentioned: dmesg, modprobe, ifconfig, route, etc.
3. Make sure the PCs you chose are properly shut down, and are now powered off.  Connect the PCs as described below.  It is safe to connect/ disconnect network cables while the machines are powered on, but because of the physical movement involved while connecting the cables, it is possible that there will be power cable disconnection etc, and hence it is safer to start with the machines powered off.
4. As you know, each of these PCs Pi have two or more NICs.  We will be using two NICs on P1 and P2, but one only on P0 and P3. Be sure that two cards are connected properly by a cross over cable. E.g., the NICs on P2 will be connected as follows: N11 of P1 to N21 of P2, and N22 of P2 to N32 of P3.
5. Power the machines, let them boot into the CEG429 Linux setup, and login as root. Verify that the booted OS has recognized the two cards present on the machine.  If you watch carefully the boot messages, you will see messages regarding an eth0 device and an eth1 device . Run the command dmesg to re-examine the boot messages. See the note below regarding where (top/bottom) the two connectors are located.
6. Verify and re-load if necessary the modules for the NICs.
7. Verify that IP forwarding is enabled on the PCs P1 and P2 by doing
      cat /proc/sys/net/ipv4/ip_forward
   If it outputs a 0, enable forwarding as follows
      echo 1 > /proc/sys/net/ipv4/ip_forward
8. Assign an IP address to each of the NICs. Decide what addresses in the 192.168.*.* range would work.
9. First test the two cards present on the machine by pinging each card (i.e., its IP address) on the machine. Then try pinging a machine (i.e., its card) that is present on the network, connected by cable directly to the card. Then try pinging a machine that is connected indirectly through an intermediate machine. The final routing tables should be setup so that any any two PCs can ping each other. Do not use routed.
10. Turn in a description of how you did all the above, a witness report by a fellow student, and an explanation of every piece of the data output by the following commands:
        ifconfig -a
  route -n
11. Include a "personal experience" with above story in your description.
12. Restore the connections of the machines you used.

Which Card is eth0? eth1?

Our OSIS lab machines in 2008 have four network cards in each:  two Broadcom Gigabit devices with tg3 drivers, and two Realtek Gigabit devices with via-rhine drivers.  Our OSIS lab machines in 2007 had two network cards in each:  the e100 is a driver for the builtin, and the 3c59x is a driver for the add-on card.

When a PC has multiple cards, the determination of which is eth0, eth1, eth2, etc. is (generally) by the order in which their driver modules are loaded. There are several commands and configuration files that are helpful in this context:

1. The command dmesg re-displays the boot messages. Among other things, the order of NIC discovery will be in these messages.
2. The lsmod command lists all loaded modules.
3. Look for the presence of a file /etc/iftab and examine its contents. Using the following content of /etc/iftab, we can make the naming of ethX independent of the order of discovery.

   eth0 driver e100
eth1 driver 3c59x

   Note that not all distributions may have this /etc/iftab file. If you find that a particular Linux distro did them the other way round, you can mentally note which is what and adjust, or do the following.
   
   rmmod -f e100
rmmod -f 3c59x

modprobe e100
ifconfig eth0 arguments

modprobe 3c59x
ifconfig eth1 arguments
 

4. The command lspci lists devices attached to the PCI bus.  Look for "Ethernet" in its output.
5. The command lsusb lists devices attached to the USB bus.  Some 802.11-wireless "cards" of laptops are listed by this.
6. The command ethtool -i eth2, for example, lists the kernel device named eth2, what its driver is, etc.

Acknowledgements

This work was supported in part by NSF DUE-9951380.

References

1. Prabhaker Mateti, Local Area Networks A basic intro.  What is NIC? What is 192.168.*.*? Etc.   Do the  lab procedure based on the above if you never setup a LAN.  This is part of your prerequisites.
2. Yechiam Yemini, "The Network Book," http://www.cs.columbia.edu/netbook/ This is a textbook aimed at juniors and seniors.  The first few chapters are highly readable.  Required Reading: Chapters 1 and 2.
3. Prabhaker Mateti, Linux Notes,  It describes Linux in two minutes and has pointers to further Linux info.  Recommended Reading.
4. Prabhaker Mateti, OSIS Lab. It describes our OSIS Lab at Wright State U.  Recommended Reading.
5. http://www.ssh.com/support/downloads/secureshellwks/non-commercial.html  Windows ssh client.  Linux: Most distributions include ssh and sshd.