UCLA Linux Networking Tools and Techniques

This Website (http://dmorgan1.bol.ucla.edu/linuxclasses.html) will be used to communicate with you. Announcements, grade reports, and assignments will be posted here. The site can be viewed from an internet-connected browser anywhere. You are responsible for awareness of the information posted here.

Thank you - for your interest in linux and this course. I hope you have a better understanding of the underlying foundation of networks and can apply it in your work and projects. (11/29)

Related linux/unix classes - that may interest you.

System Administration - continuation of my introductory course with system administration focus
Shell scripting - further depth into the subject and the practice
Advanced Linux/Unix: Security - theory and practice

Schedule: the courses tend to be offered every other quarter. There may be variations but this is the general expectation. If you are interested please "stay tuned" to the class schedule as UCLA Extension publishes it. Or if you email me I can let you know what we are putting in the pipeline.
System administration - probable Spring 17
Networking - probable Spring 17
Scripting - Winter 17
Security - Winter 17

Content:
System administration - see website from most recent quarter and course outline
Shell scripting - see website from most recent quarter and course outline
Security - not previously taught at UCLA Extension but will be derived from extensive materials I have compiled from teaching security elsewhere, and will be lab-heavy. (11/29)

Special topic - at your request; tunnels and VPNs
We will do an exercise collectively in class to construct a VPN on DETER
slides exercise instructions (11/29)

Endterm/final - is a take-home exam. It is multiple-choice, open book. Submit your answers to all the questions following these preparation and submittal instructions (you will use ftp to deposit your answer file in your "assignments" subdirectory on "unexgate" machine; create it if it isn't already there; here's how. See posting entitled "Remote Unix system" at the bottom of this page.). Please name your file "endterm.txt". I will grade these using an automated script, so the format of the answer is critical to intelligibility, as is the case (lowWednesday December 7. (11/22)

Important name service files on linux computers -
/etc/hosts gives "mappings" that pair IP addresses with names
/etc/resolv.conf gives the system the IP address of a name server to use (11/22)

Sample captures courtesy of wireshark.org - in order to study a protocol in Wireshark you could use that protocol while simultaneously capturing it. Or you can take the captured results of others' activities without having to run the protocol of interest yourself. For example, if the kerberos authentication protocol interests you but you have no account on any kerberos server so can't run it yourself, you can grab krb-816.zip which holds a full trace of kerberos in operation, and open it up in Wireshark for scrutiny. Many such pre-captured protocols are available on the site (above "Sample captures" link). (5/19)

Homework -
reading -do the remaining reading. (11/22)

Delayed "midterm" - is a take-home exam. It is multiple-choice, open book. Submit your answers to all the questions following these preparation and submittal instructions (deposit your answer file in your "assignments" subdirectory on "homework" machine; create it if it isn't already there; here's how. See posting entitled "Remote Unix system" at the bottom of this page.). Please name your file "midterm.txt". I will grade these using an automated script, so the format of the answer is critical to intelligibility, as is the case (lower) of the filename. -due on unexgate.dmorgan.us by end-of-day next Wednesday November 30 (11/22)

TCP (and UDP) Ports you should know
Q: where do the "well-known port" numbers come from?
A: IANA (Internet Assigned Numbers Authority)

Q: what are the well-known port assignments?
A: the list is long (cf., /etc/services on any linux box or equivalent C:\WINDOWS\system32\drivers\etc\services on XP)
note: udp and tcp ports are separate/independent; udp port 53 is not tcp port 53

Q: which ones should we know for this class?
A: 21, 22, 23, 25, 53(udp), 80, 110, 123 (look up what service each belongs to, above)
(11/1)

Various services and the server programs and protocols they use.

Service	Server	Linux executable	Protocol used
name	BIND	/usr/sbin/named	dns
web	APACHE	/usr/sbin/httpd	http
MS sharing	SAMBA	/usr/sbin/smbd	smb
address	DHCP	/usr/sbin/dhcpd	dhcp
socket demo	CHOMPER	/opt/socketdemo/byteme	none
letter upgrade	letter upgrade	server4	none, really

(11/1)

Port numbers are different from process ID numbers (PIDs). I stress that port numbers serve as process identifiers. They do, but so do PIDs. PIDs are process identifiers to the operating system. Port numbers are process identifiers to the network, specifically to its transport layer who is responsible for effecting process-to-process connections (given machine-to-machine connections provided already by the transport layer's underlying helper, the network layer). All processes have a PID. Not all processes have a port number, only those that sign up or register to get one from the transport layer explicitly (think bind function call by a server) or implicitly (think connect function call by a client). The netstat program is the utility that reports on port numbers:

Note the difference between port and PID numbers. For example the first process reported has port number 7 but PID number 7441.

Note also the difference between the tcp port numbers (upper) versus udp port numbers (lower). In addition to tcp port number 7, udp port number 7 appears too. In this case, the same process is using both (namely 7441, an instance of the xinetd program). Note that xinetd appears 3 times. In addition to the 2 port 7s it also uses tcp port 19 (though not udp port 19). Use of tcp and udp ports are independent of each other.

Note that a "state" is given for each tcp port, but not for any udp port. That's beacuse these states are a characteristic of the tcp protocol that the udp protocol doesn't have. Note that the sshd program has 2 process instances running, under PIDs 7080 and 7302. The former is in LISTEN and the latter in ESTABLISHED state. To make this screen shot from that linux machine, I ssh'd to it from my Windows machine. 7302 is the software process on the other end that's holding up the connection I'm using. Windows has its own process holding up my end. It has a port number too, but that would only be shown by running netstat or equivalent in Windows not linux. The port number for the connection on the Windows side (and the process ID too) are local to the Windows machine. The linux machine cannot locally determine them.

The other sshd process, 7080, is listening for potential requests that might come in for other connections to be set up. sshd fields any incoming tcp segment with 22 inscribed in its destination port field. But it distinguishes those that should be processed as part of my up-and-running connection, and those that should not, per their source port field values-- mine if 1081. sshd with PID 7302 gets mine, sshd with PID 7080 gets the others. (10/25)

Please (re)view these slides showing the positioning and interrlationship among clients and servers on one hand, the network stack software on the other, and the operating systems when 2 computers communicate. (10/25)

Addresses, functions - you know them. Don't get them mixed up.

(10/25)

Homework -
~~do - "subnet partitioning," course outline section 7 Homework column. Turn in on paper in class October 25~~
do -the assignment at the link entitled "MAC vs IP addresses" in section 3 of the course outline. -due on unexgate.dmorgan.us by end-of-day next Wednesday October 26
do - "IP packet delivery," course outline section 3 Homework column. due on paper in class Thursday 10/25
The two above assignments focus on the same understanding.
- keep current with all the reading, through course outline section 4.
- view the online "Network calculators" links at left. (10/18)

Golden rules for deciding how to ship a packet (Forte Systems "IP packet delivery"):

We reviewed the concept behind the "IP packet delivery": if IP thinks a destination IP address is local it arps for that IP address, if not it arps for the IP address of its default router (which comes from the routing table). Everything hinges on what "local" means. That is a function of the given destination address, the local address, and the local netmask. Network calculators and/or the linux "ipcalc" command can help you recreate IP's "thinking process" in this regard for particular subnets, addresses, and netmasks.

A related description of the thinking process comes from a textbook I use in another class, and recommend as a good reference that is particularly well balanced between being technical and yet clear, Computer Networks and Internets, Douglas Comer. (4/28)

Grades - published, at link at left entitled "Grade reports." Where are the assignments? (10/11)

Homework
do - the "network legality" assignment in the Homework column for topic #3 in the course outline. Due on the server by end-or-day next Weds 10/19. (10/11)

Network Address + Netmask = Subnet
It's useful to think of a network (a.k.a. subnet) as being defined by a position, and an extent measured from that position, on the continuum of IP addresses represented as a number line. A network is definitively identified by a 2-component ID. The first is its network address and the second is its netmask.

It is the network address that establishes the position or starting point of the address range or block that is the network. And it is the netmask that establishes its extent or size. As an example consider a network whose network address is 64.52.25.224 and whose netmask is 255.255.255.224 (the one that signifies "thirty-two" as size). The number line below is a microscopic segment of the number line for the whole internet. That number line is 4 billion addresses in length (because with 32 bits 4 billion is the number of distinct address values that can be composed). Here, with the first 24 bits of our address (64.52.25) we are narrowing in on a particular little 256-address segment within that number line. Within the segment, the network address further positions us with final precision. This idea of sectioning off the 4 billion addresses into separately addressable subordinate pieces is called subnetting, and the resulting pieces or address groups are called subnets.

64.52.25.224/255.255.255.224:

(10/11)

Routing - important formulations of the "route" command
Three kinds of routes can appear in a routing table: host route for a specified individual machine, network route for a specified grouping of them, default route as catch-all for everything (unspecified) else. Here are the four key linux command formulations by which you add such routes to a routing table. Though there are 3 kinds of routes, note that 4 command formulations appear. We mentioned the concept of gateways (machines other than the destination, to which you would send the destination's packets for forwarding). That accounts for there being 2 network route formulations below. One is for the case where the routed-to network is the one you yourself are plugged into, the other for the case where that network is "foreign" or "elsewhere" to you.

Add route to a machine (host route):
route add –host 192.168.4.2 eth0
Add route to a group of machines (network route - local)
route add –net 192.168.4.0 netmask 255.255.255.0 eth0
Add route to a group of machines (network route - gatewayed)
route add –net 192.168.5.0 netmask 255.255.255.0 gw 192.168.4.1
Add route to “any and all” (default route)
route add default gw 192.168.4.1

Study these commands intently and try to internalize the semantic meaning they embody. (10/11)

Windows route command - differs in syntax and scope somewhat from the linux command of the same name. But it is kindred in spirit and operates on the very same internet protocol (though not the same coded implementation of it). The internet protocol is defined outside Microsoft and outside linux. Both Microsoft and linux programmers have taken their hand to writing programs that do what the protocol defines. Including a "route" command to manipulate the protocol's route table. In Windows, open a command box and execute "route print" if you wish to see the route table. (10/11)

Network size for common netmasks:

Netmask:	# of one bits:	# of zero bits:	Implied network size:
255.255.255.0	24	8	256 (254)
255.255.255.128	25	7	128 (126)
255.255.255.192	26	6	64 (62)
255.255.255.224	27	5	32 (30)
255.255.255.240	28	4	16 (14)
255.255.255.248	29	3	8 (6)
255.255.255.252	30	2	4 (2)

(10/11)

Homework - do the assignment at the link entitled "tcpdump filters" in section 3 of the course outline. due in class on paper next week Tuedsday October 11. (10/4)

Quote tcpdump filters - when you use them on the command line. Putting them in single quotes will prevent certain characters they often contain from being acted on my the shell to alter the command. Which you do not want. So instead of
tcpdump -nti eth0 tcp[13] & 0x03 != 0 it's tcpdump -nti eth0 'tcp[13] & 0x03 != 0'
(10/4)

Packet capture files from the "wireshark" in-class exercise for you
I performed the exercise while running Wireshark and saved the traffic into capture files. You can open my files in Wireshark, to replay and analyze what I did.

The IP addresses of the machines I used were 192.168.1.10 and 192.168.1.12. Those are reflected in the captures. Get the files (unzip) then open them in Wireshark. You can then ponder the questions the exercise asks and use the captures to help you understand. The files are:
for section 4: echo-udp.cap echo-tcp.cap
for section 7: login-telnet.cap login-ssh.cap
for section 8: http.cap

Satisfy yourself you have a pretty good idea what you are looking at. In particular, compare the header structures you see in the captured frames with the ones mapped out in the TCP/IP Pocket Reference Guide. And, practice using Wireshark's "Follow TCP stream" feature, found by right-clicking on packets in the packet list pane. It will starkly and unmistakably extract the password used in the telnet login session. And it will reveal the content of the web page obtained in the http browse session. There is nothing to turn in. (10/4)

Screencast of "Capture a cleartext password" - from section 7 of the Wireshark exercise. It asks you to both telnet and ssh into a server, in order to observe the transit of the password in cleartext (with telnet) versus ciphertext (with ssh). I performed the dual-login myself and made a short screencast of my activity. Please view it (and please don't use telnet anymore!). (10/4)

Undersea cabling - former student Philip Postovoit did the service of researching cabling quite thoroughly. Of the many links about it he sent me, I found particularly interesting:
submarine cable map (click individual cables)
manufacture, shipboard loading, seabed laying youtube video
Haut débit en eau profonde (French)
"Contrary to conventional wisdom, satellites play a minimal role in the operation of the internet. Nearly 99% of international phone and data traffic goes through [submarine cables] like ours." Patricia Boulanger, Alcatel Submarine Networks
(9/23)

Screenshot of Microsoft Network Monitor courtesy of a former student. Compare the interface with Wireshark's.

Birth of the internet - at UCLA's Boelter Hall room 3420. Here, of optional and casual interest (but hey! it's interesting!) is a BBC radio interview about it (first 9 minutes).

Homework
do - course outline topic 2 homework, ethernet frames. due on server end-of-day Wednesday October 5.

Handout - explaining use of class computers.

Homework
read - see the readings listed in course outline topics 1, 2, and 3. This is a lot of reading, but get moving on it as all of it is relevant to what we have talked about or will (automating network configuration; arp; tcpdump/wireshark). In particular see Brown (the more practical/applied of our 2 textbooks), who talks about the ifconfig and route commands. (3/31)

Functional layering - the famous "Open Systems Interconnect" model is depicted below. Somebody once had the idea that maybe there could be a way to get independent computer systems of different types to be able to exchange information with one another. The diagram blueprints the idea for "how in the world are we going to make that work??" That idea is the subject of this course.

(4/1)

Course outline - with approximate weekly topic coverage corresponded to related readings, homework assignments, and in-class slides I will use.

RFCs - "Request for Comment" protocol definition documents
note the section in the left column under heading entitled "Protocols." These link primarily to the protocols' rfc's. rfc stands for Request for Comnment. A protocol's rfc is its defining functional definition in the form of a historical document that was written as an engineering blueprint before the protocol was implemented. Implementations then arose from programmer efforts following the blueprint as a guide. rfc's therefore contain the big picture rationale for their protocols. Sometimes they are too detailed for our purposes, but sometimes they are illuminating. Look over the ARP rfc.

A Remote Unix system will be available for your use.

Using ssh (secure shell). ssh is an important tool you will use for interacting with remote computers. For that you will need an ssh client. There are a number of ssh client alternatives.

Running linux at home.
Bootable Fedora 20 on USB for you to burn - I made a suitable, persistent image recently. If you bring an 8GB or larger USB flash drive to class (empty of anything you care about) we can burn my image to your drive for you to boot from in the future.

Eniac - 1946