Network Setup and Utilities

Prabhaker Mateti

Abstract: This is a basic 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 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 ifconfig, iwconfig, iwlist, nc, netstat, ping, route, traceroute.
  3. Use standard net clients such as ssh.

Network Setup and Utilities

This is a refresher lecture. It should enable you to do the Linux router setup experiment either in the OSIS lab, or in your own personal home setup. 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.

We mention path names of certain files. Note that depending on the distribution used, some of these files may not exist, or may have different path names.

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.

Which Card is eth0? eth1?

Our OSIS lab machines (2010+) 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 motherboard builtin, and the 3c59x is a driver for the add-on card. Some of the details below will make better sense if you know this. ]

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/*-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
    

IP Address Assignment

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. Modern OS often use DHCP to discover the IP addresses and routes. In this course, most of the experiments will be conducted on isolated LANs of just a few machines with no DHCP server. So, we must assign IP addresses and setup routes manually. We are assuming that you have scripting skills to automate this for each lab experiment.

Please become familiar with how the standard Linux OS installed "for all classes" in the OSIS Lab sets up the network cards on our machines.

The command spelled ifconfig (called ipconfig in Windows) assigns the IP address and sets other parameters. Here are path names of a few relevant files for you to get started.

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

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 extra network cards, if any, 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 OSIS 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
You can tell that the OSIS lab's router send all packets whose destination is neither 130.108.17.* nor 192.168.17.* to 130.108.17.1.

In a host that is to behave as a router, IP forwarding should be enabled. Check with
   cat /proc/sys/net/ipv4/ip_forward
If it outputs a 0, enable forwarding as follows
   echo 1 > /proc/sys/net/ipv4/ip_forward

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) 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. The standard connections for other classes in the OSIS Lab (typically) use eth0.  Leave these as they were.  But, do not use this network at all. In the network card counts below eth0 is excluded.
  2. 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.
  3. As you know, each of these PCs 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 Pi and P(i+1) are connected properly by a cross over cable, or if using straight cables connected properly through a switch.
  4. Power the machines, let them boot into the CEG429 Linux setup, and login as root.
  5. Verify and re-load if necessary the modules for the NICs.
  6. Decide what addresses in the 192.168.*.* range would work.  Assign IP addresses to the NICs as needed.
  7. Verify that IP forwarding is enabled on the PCs P1 and P2. Verify that IP forwarding is disabled on the PCs P0 and P3.
  8. 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.
  9. In the turn in, include an explanation of every piece of the data output by the following commands: ifconfig -a; route -n
  10. 5 Bonus Points: Start ssh server. Successfully ssh-login as root and also as user named knoppix in Knoppix. You are expected to learn the details on your own by reading, not by asking others (including Big Brother Google).
  11. 5 Bonus Points: Demonstrate through a cut-and-paste of output that you have learned to use netcat (nc) and netstat productively.

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. Prabhaker Mateti, Linux Notes,  It describes Linux briefly and has pointers to further Linux info.  Required Reading.
  3. Prabhaker Mateti, OSIS Lab. It describes our OSIS Lab at Wright State U.  Required Reading.
  4. http://www.ssh.com/support/downloads/secureshellwks/non-commercial.html  Windows ssh client.  Linux: Most distributions include ssh and sshd.
  5. Search the web for "putty".  This is an open source telnet and SSH Client for Windows and Unix platforms. Recommended Download.

Copyright © 2010 • pmateti@wright.edu Other Internet Security Lectures by Mateti