|
|
Wright State University Dayton, Ohio 45435-0001 |
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
ping, traceroute, ifconfig, route.ssh.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.
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*
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.The command spelled ifconfig
(called ipconfig in Windows) assigns the IP address and
sets other parameters.
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:
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/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
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 eth1You can tell that the lab's router send all packets whose destination is neither 130.108.17.* nor 192.168.17.* to 130.108.17.1. In the router, IP forwarding should be enabled.
cat /proc/sys/net/ipv4/ip_forward 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) 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).
dmesg, modprobe,
ifconfig, route, etc. 192.168.*.* range
would work. Assign an IP address 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 -nThis work was supported in part by NSF DUE-9951380.
| . |