Learn / Networking Fundamentals / Reading Traffic
Watching Packets
First Bit is still up for grabs: be the first to finish this room.
Every connection you've made so far left a trail of packets on the wire. A capture shows you exactly what crossed it: which machines talked, which ports they used, and, wherever the traffic isn't encrypted, every byte they said to each other. It's the closest thing networking has to a video recording, and it settles arguments that log files can't.
In this room you'll learn to read tcpdump output, then watch a sensor on Lena's machine send something it would rather you didn't see.
CYB//RANGE Live lab
Log in to launch this room's lab.
Task 1 What's on the wire
Data doesn't cross a network in one piece. It's cut into packets, and every packet is wrapped in headers, one per layer, that say where it's going and what it is.
The headers sit one inside the next, outermost first:
| Header | Carries | Read by |
|---|---|---|
| Ethernet | MAC addresses | the machines on this segment |
| IP | source and destination IP addresses | every router along the way |
| TCP or UDP | source and destination ports | the program at each end |
Whatever is left after the headers is the payload: the data the program actually meant to send.
A capture tool reads whole packets straight off an interface, headers and payload together, before any program gets a look at them. That's why capturing is a privileged thing to do. Normally only root can, because anyone who can capture on an interface can read everything on it that isn't encrypted, including other people's traffic. On this machine tcpdump has been given that one permission and nothing else.
What is one chunk of data crossing a network called? (One word.)
Log in or sign up to answer. 5 pts
******
Task 2 Reading tcpdump output
tcpdump prints one line per packet:
$ tcpdump -i lo -n
14:02:11.483927 IP 127.0.0.1.51234 > 127.0.0.1.9100: Flags [S], seq 1902847362, length 0
14:02:11.483951 IP 127.0.0.1.9100 > 127.0.0.1.51234: Flags [S.], seq 88136402, ack 1902847363, length 0
Left to right: the time, the protocol, then source address.port > destination address.port, then what the packet is carrying.
| Option | Means |
|---|---|
-i lo |
capture on this interface |
-n |
leave addresses as numbers |
-c 20 |
stop after twenty packets |
-A |
print each payload as text as well |
-r notes.pcap |
read a saved capture instead of an interface |
-n is worth making a habit. Without it tcpdump looks up a name for every address it sees, which is slow, and puts your own lookups on the wire in the middle of the traffic you're trying to read.
Two interfaces matter on most machines. eth0 carries traffic to and from other machines, and lo carries the traffic a machine sends to itself. Programs sitting on the same box talk to each other over lo, and it's easy to forget that this is real traffic, capturable like any other. Plenty of things that would never be sent across a network in the clear are sent in the clear over lo.
Task 3 Try it on a real machine
Lena keeps an eye on the monitoring here. A sensor uploads a reading to a collector every couple of seconds, and she wants to know exactly what travels with it.
- Press Launch in CybRange at the top of this page, then Open terminal next to
boxonce it's ready. You're logged in aslena. - Watch the loopback interface:
tcpdump -i lo -n -c 20. Which addresses and ports keep coming back? - Narrow it to the collector:
tcpdump -i lo -n port 9100. A short conversation should repeat every few seconds. - The upload is plain text. Add
-Aand read what the sensor actually sends. Asking the collector yourself withnc 127.0.0.1 9100gets you nothing: it never repeats what it was told.
The sensor uploads to a collector on this machine. Which port does the collector listen on?
Log in or sign up to answer. 10 pts
****