TCP/IP - Intro to the IP Protocols
Sockets: socket programming
nmap: Ethical Hacker article
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.
Administration - continuation of my introductory course with system administration focus
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.
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
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)
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
Various services and the server programs and protocols they use.
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.
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)
Network Address + 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 220.127.116.11 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.
Routing - important formulations of
the "route" command
Add route to a machine (host route):
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:
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
Packet capture files from the "wireshark"
in-class exercise for you
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:
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:
Screenshot of Microsoft Network Monitor courtesy of a former student. Compare the interface with Wireshark's.
Handout - explaining use of class computers.
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.
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
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.
you get the 'L'?