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.

This article is part of Internet Security Lectures

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
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 Configuration

Each network interface card (NIC) needs to be assigned an IP address. The choice of the IP address may be done statically or dynamically via DHCP. In this course, you will often be setting up a stand-alone private LAN. So you need to learn to setup everything manually via scripts.

You may want to read the following files on the standard Linux OS installed for all classes.

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

Network Card Drivers

The Linux kernel you will be booting is modular.  Only the must-have modules are linked together into the kernel.  All other modules are loaded as needed.

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

The command spelled ifconfig (called ipconfig in Windows) assigns the IP address and sets other parameters.

Which Card is eth0? eth1?

Our OSIS lab machines in 2009 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. Look for the presence of a file /etc/iftab and examine its contents.
   1. 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
   2. Here is another example content of /etc/iftab:
      eth0 mac 00:10:18:2E:9E:10
eth1 mac 00:1A:A0:B1:72:43
eth2 mac 00:19:5B:71:E7:42
eth3 mac 00:19:5B:71:F1:9C

3. Look for the presence of /etc/udev/rules.d/70-persistent-net.rules. Here is an example content of this file.  The ATTRS{address} below is the MAC address.

         # PCI device 0x14e4:0x1659 (tg3)
         SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:10:18:2e:9d:f3", NAME="eth0"
         # PCI device 0x14e4:0x167a (tg3)
         SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1a:a0:b1:55:3f", NAME="eth1
         # PCI device 0x1106:0x3106 (via-rhine)
         SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:19:5b:71:f1:8a", NAME="eth2
         # PCI device 0x1106:0x3106 (via-rhine)
         SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:19:5b:71:e1:07", NAME="eth3
   

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

The table is used as follows.  Suppose the destination address as found in an IP datagram is DA.  DA is bitwise-ANDed with the Genmask value of a row r.  If the result (DA & Genmask[r]) equals the Desitination[r], the datagram is sent out via the device named in Iface[r].  The rows are tried in order from the first to the last.  The last row typically has a GenMask of 0.0.0.0 and Destination of 0.0.0.0; this is then known as the default route.

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

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. Look up the man pages for details on the commands mentioned: dmesg, modprobe, ifconfig, route, etc.
2. The standard connections for other classes in the OSIS Lab use eth0.  Leave these as they were.  But, do not use this network at all.
3. Make sure the PCs you chose are properly shut down, and are now powered off. 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. Connect the PCs as described below.
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.
5. Power the machines, let them boot into the CEG429 Linux setup, and login as root.
6. Verify and re-load if necessary the modules for the NICs.
7. Decide what addresses in the 192.168.*.* range would work.  Assign an IP address to the NICs as needed.
8. Verify that IP forwarding is enabled on the PCs P1 and P2. Verify that IP forwarding is disabled on the PCs P0 and P3.
9. Setup the routing tables on all four Pi. Do not use routed. Any two machines should be able to ping each other. Record the results of these pings.
10. Restore the connections of the machines you used.
11. Look up the Lab Report Template on the course homepage. Turn in a description of how you did all the above, and an explanation of every piece of the data output by the following commands: ifconfig -a; route -n

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.