Networks Lab
WIRESHARK
Wireshark is a software for capturing and analyzing network traffic. It captures the traffic on a specified network interface on the machine where it is being executed. The traffic can be saved in a file for later analysis, possibly on a different machine.
Wireshark is a powerful tool with many capabilities and constitutes “the” choice for professionals. Wireshark may also be useful for learning purposes. In this case, it is important to carefully balance the complexity of Wireshark, the complexity of real network traffic and the learning objectives.
For a very quick intro to Wireshark look at the slides above; at the end there are a few simple questions based on a DNS capture.
Wireshark Labs
The “Wireshark Labs” freely available on-line as a supplement to the book “Computer Networking: A Top Down Approach - Jim Kurose, Keith Ross” are an excellent suite of examples. Each of the labs consists of a document with step-by-step instructions for capturing packets from a live connection and for analyzing important properties of the captured traffic. Furthermore, for each lab, a file with traffic already captured is available.
Before looking at the labs, please read the notes below carefully.
Computer Networks 2
Students are strongly advised to execute autonomously the following Wireshark labs (see above), in the specified order:
Getting started
TCP
The first lab can be executed at the very beginning of the course. The second lab can be executed after the early lectures on TCP, more or less in parallel with those lectures.
Execution of these labs is not a requirement for the exam. There will be no formal control over whether they have actually been carried out. Their execution may be very useful to students irrespective of the exam, though.
The NAT lab might be useful but it probably does not add very much to the other labs. If a student wanted to execute further labs, those suggested below for Computer Networks 1 could perhaps be more useful than the NAT one.
These two YouTube videos are extremely useful and warmly suggested:
Intro to Wireshark: Basics + Packet Analysis! (16 minutes) provides a very concise introduction to Wireshark focused on TCP. I find it excellent. At the end it discusses a component of congestion control (fast retransmit) not discussed in the course, but I warmly suggest viewing this video anyway. Basically, if A has to send many segments to B and A receives several segments with the same acknowledgment number, that probably means that one segment has been lost, but only one (since B is sending several ack's, it means that B is receiving segments; but since all those segments carry the same ack number, then probably there is a small gap in B's RX-buffer); in this case A sends only what appears to be the missing segment.
Wireshark Tip 1: TCP Reassembly Setting (4 minutes) provides a configuration tip that may be useful when analyzing HTTP traffic. Understanding the problem and the configuration setting solved is not difficult but not trivial either. Full details can be found here, but even applying the tip without understanding exactly what happens behind the scenes may be very useful anyway (basically, a process may send multiple application messages and TCP may not align these messages with segments; as a result, a segment may contain part of an application message and part of the next one; when the next one is an HTTP Response, Wireshark in default configuration would not annotate the segment as "200 ok" but it would annotate it in a hard-to-understand way).
Computer Networks 1
The current structure of this course makes the exam quite heavyweight. Adding Wireshark labs might subtract time and might be distracting. If a student is sufficiently motivated and interested, though, autonomous execution of the following Wireshark labs may be very helpful: it may improve the understanding of some key concepts and it may make the overall topic “more concrete”.
Getting started
DNS
HTTP
Ethernet and ARP.
IP and/or ICMP.
All these labs should be done in the second part of the course, even those about DNS and HTTP. They can be executed in any order, except for the “Getting started” lab that must be the first one. Labs 4 and 4 should be done after the lectures on traceroute (the fragmentation section of Lab 5 should not be done, as it is based on concepts not included in the course).
The DHCP lab should not be executed and its reading may even be misleading (the course describes DHCP in a very over-simplified way: the real DHCP is quite different from the one described in the lectures).
BURP
Burp is a software for application security testing of web applications. It consists of a proxy on the machine where it is being executed with a graphical interface for analyzing and modifying HTTP traffic, sending HTTP requests automatically based on modifications specified by the user and so on.
Burp is a powerful tool with many capabilities and constitutes “the” choice for professionals. Burp may also be useful for learning purposes. In this case, it is important to carefully balance the complexity of Burp, the complexity of real network traffic and the learning objectives.
For a very quick intro to Burp look at the document in the collection below. The document contains also an introduction to the OWASP Juicy Shop, a web application containing many vulnerabilities that has been developed for learning purposes. The document discusses in detail a few of those vulnerabilities.
Burp is not strictly necessary for any activity.
Regarding Computer Networks 2, it is necessary for the optional activity 4 (MITM with SSLStrip) and it may be useful for analyzing TLS traffic of smartphone apps and websites (see the description of Burp with HTTPS at the beginning of the document describing activity 4).
MAN-IN-THE-MIDDLE (MITM) LABS
The documents below describe the basic steps for:
Using a PC as a platform for analyzing the network traffic of a “device”. The device may be a smartphone, another PC, or any other device with IP connectivity: Kindle, PS4, Chromecast, Internet of Things, whatever (with some limitations, though: devices that do not communicate only with DNS and HTTP/HTTPS and whose DNS configuration cannot be modified, require software tools and configuration operations more complex than those described in these documents).
Installing a fully functional DNS server on a PC.
Installing a fully functional web server with HTTPS support on a PC.
Connecting a smartphone to a fake website, that is, to a copy hosted on a PC of a real website.
Inspecting and modifying the traffic between a browser and a web server (even on HTTPS).
The steps and suggestions in the various documents refer to a PC running Windows 10 and a smartphone running Android 9.
Important
The documents are not meant to be step-by-step guides:
Execution of most steps will require some thought (e.g., how to make sure that “the device sends its DNS requests to the IP address of the PC”?).
Some steps will work smoothly and some others could not work as expected. Some amount of personal work will certainly be required.
It is strongly suggested to invent and apply a form of self-discipline for working. Take note of the most important problems, what worked and what did not. Take note of important command parameters, websites and alike. Take time to cleanup your notes periodically.
Even more important
The traffic originated by a real “device” is usually very complex and, in practice, can be understood only in minimal part for two basic reasons:
A lot of traffic travels on TLS and thus cannot be decrypted while in transit.
The real traffic includes components that in Computer Networks 1/2 are not covered, or are covered in a simplified form (i.e., there is something missing), or are covered in an over-simplified form (i.e., different from the reality).
Learning to cope with such a complexity is an essential skill for a modern engineer. One has to figure out autonomously which things can be understood and which ones cannot; which things must be analyzed in more depth and which ones could be analyzed but may be omitted. This know-how can only be built with personal experience, patience, thought (and Google).
Computer Networks 2
Labs 1, 2, 3 are guides for the project required for the exam (the "Strict Transport Security" appendix in 3 is not required for the exam).
The other labs are not a requirement for the exam. They may be very useful for better understanding the corresponding topics and make them more concrete. Their execution requires some time and motivation, though.
Computer Networks 1
None of the labs listed below is a requirement for the exam.
Execution of the Web server lab may be very helpful (for motivated students, as observed above for Wireshark).
Execution of the MITM on smartphone might be feasible at the end of the course. However, this lab is complex and time-consuming. I do not recommend its execution.
Execution of the other labs requires the knowledge of topics not covered in Computer Networks 1.
The only exception is the "Rogue CA" lab. Reading the lab up to that section (included) may be helpful for improving the understanding of HTTPS and of certification authorities, even without actually executing the lab.