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
ifconfig, iwconfig, iwlist, nc, netstat, ping, route,
traceroute.ssh.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.
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.
lsmod lists all loaded modules.lspci lists devices attached to the PCI bus.
Look for "Ethernet" in its output.lsusb lists devices attached to the USB bus.
Some 802.11-wireless "cards" of laptops are listed by this.ethtool -i eth2, for example, lists the kernel
device named eth2, what its driver is, etc.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.
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:
dmesg re-displays the boot
messages. Among other things, the order of NIC discovery will be
in these messages./etc/iftab and
examine its contents.
/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
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
/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
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
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 eth1You 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
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.
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.
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).
192.168.*.* range
would work. Assign IP addresses to the NICs as needed. routed. Any two machines should be able to ping
each other. Record the results of these pings.ifconfig -a; route -nroot 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).
This work was supported in part by NSF DUE-9951380.