College of Engineering & CS
Wright State University
Dayton, Ohio 45435-0001 |
Network Setup and Utilities
|
| |
|
|
| |
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 work is supported in part by NSF DUE-9951380. |
|
- Educational Objectives
- Network Setup and Utilities
- Network Card Drivers
- Configuring the Interface
- Setting up Routes
- Proxy Server
- Secure Shell, ssh
- Lab Experiment
- Setup a Router
- Acknowledgements
- References
- This is typically the first lab with a goal of becoming familiar with our
lab setup.
- Introduce a number of essential network setup utilities such as
ping,
traceroute, ifconfig, route.
- Make the student experience setting up a network and a Linux router.
- Use newly emerging standard net clients such as
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.
The Linux kernel you will be booting is modularized. Only the must-have
modules are linked together into the kernel. All other modules are
dynamically loaded as needed. The command lsmod lists the
modules currently loaded. The command dmesg re-displays the
boot messages which contain identification strings of various devices that the
kernel has detected.
As of MAr 2001, our lab PCs have a built-in NIC, a 100Mb/s 3Com 905B
(physically the top one, Linux driver module name 3c59x), and another NIC
(near the bottom) 10 Mb/s, either 3Com 509 (driver module name 3c509), or
Linksys (driver module tulip).
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 NT) assigns the IP address and sets other
parameters. It can also show the current settings; here is an
example. Read the man pages etc, and learn the meaning every piece of data
shown.
eth0 Link encap:Ethernet HWaddr 00:C0:4F:79:34:6B
inet addr:192.168.17.112 Bcast:192.168.17.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:553667 errors:0 dropped:0 overruns:0 frame:0
TX packets:805490 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:19 Base address:0xec00
eth1 Link encap:Ethernet HWaddr 00:20:AF:D8:37:53
inet addr:130.108.17.112 Bcast:130.108.17.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4281174 errors:11 dropped:0 overruns:0 frame:11
TX packets:704655 errors:0 dropped:0 overruns:0 carrier:2
collisions:8232 txqueuelen:100
Interrupt:10 Base address:0x300
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:53 errors:0 dropped:0 overruns:0 frame:0
TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
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. E.g., here is the output of
route -n executed on a machine in my office.
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
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 130.108.17.1 0.0.0.0 UG 0 0 0 eth1
The table can be understood as follows. Consider an IP packet that has a
destination IP address of D. We choose the first row in the table above
that matches as follows. If D & genmask == Destination in that row,
send the packet via the interface shown in that row. [The & is
bit-wise-and.] If the gateway entry in that row is non-zero, the address given
there is that of the immediately next gateway that packet should be sent to.
So, a packet with a destination address of say 192.168.17.45 will be sent out
via eth0; a packet with a destination address of 130.108.17.232 will be sent out
via eth1; and, finally, a packet with a destination address of 144.32.232.123 is
sent out via eth1 because of the last row.
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 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
never trusts the network. Should an attacker gain root access to your machine
through another means, however, SSH can then be compromised also. The
encryption method, and indeed whether or not encryption is even turned on, is a
settable parameter. Make sure you choose the values that will properly protect
your system.
If the remote machine doesn't support ssh it will then fall back to
using the r-programs, after first informing the user that the communication will
not encrypted. Note that SSH does not protect you from anyone
having root access on your local machine or on the server machine. Root on
either of these machines could monitor your session or replace programs with
Trojans. So basic security on the client and server machines still needs to be
maintained.
All work should be carried out in Operating Systems and Internet Security (OSIS)
Lab, 429 Russ. No other WSU facilities are allowed.
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).
- For this lab, use the PCs numbered 19 to 30. As you know each of
these PCs Pi has two NICs; call them Ni1, Ni2. The Ni1 NICs happen to be
100Mb/s 3Com 905B (physically the top one, Linux driver module name 3c59x),
and the Ni2 (near the bottom) are 10 Mb/s either 3Com 509 (driver module
name 3c509), or Linksys (driver module tulip).
- Look up the man pages for details on the commands mentioned:
dmesg,
modprobe, ifconfig, route, etc. These commands are in the
/sbin directory. So, invoke the following to extend your PATH:
export PATH=$PATH:/sbin
- We will be using both 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 to N21, and N22 to N32.
- 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 (top) and an eth1 device
(bottom). Run the command
dmesg to re-examine the boot
messages.
- Verify and re-load if necessary the modules for the NICs: 3c59x, and
3c509.
- 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
- Assign an IP address to each of the NICs. Decide what addresses in the
192.168.*.* range would work. I strongly suggest the last (i.e., the
fourth) number be the same as the number on the box of the PC.
- 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.
- 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
- 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.
- 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.
- Prabhaker Mateti, Linux Notes,
You may want to read this. It describes Linux in two minutes and has
pointers to further Linux info.
- Prabhaker Mateti, OSIS
Lab. You may want to read this. It describes our OSIS Lab.
- Secure shell implementations: Windows 9x/NT: An SSH Extension to
Teraterm, http://www.zip.com.au/~roca/ttssh.html.
Unix: http://www.ssh.org/