Differences
This shows you the differences between two versions of the page.
|
ep:labs:061:contents:tasks:ex3 [2025/02/11 23:54] cezar.craciunoiu |
ep:labs:061:contents:tasks:ex3 [2026/04/07 02:13] (current) radu.mantu |
||
|---|---|---|---|
| Line 7: | Line 7: | ||
| === [10p] Task A - A packet's journey === | === [10p] Task A - A packet's journey === | ||
| - | Install **pwru** on your system. Check that the minimum requirements stated on the Github page are met. Note that this tool is already provided by some public package repos (e.g.: **pacman: extra/**). | + | **Installation — build from source** |
| + | |||
| + | Pre-built packages are no longer maintained for most distributions, so you'll build ''pwru'' from source. All you need is a Go compiler and ''make''. | ||
| + | |||
| + | <code bash> | ||
| + | # Install Go if you don't have it | ||
| + | $ sudo apt install golang-go # Ubuntu/Debian | ||
| + | # or follow https://go.dev/dl/ for the latest version | ||
| + | |||
| + | # Clone and build | ||
| + | $ git clone https://github.com/cilium/pwru.git | ||
| + | $ cd pwru | ||
| + | $ make | ||
| + | $ sudo mv pwru /usr/local/bin/ | ||
| + | |||
| + | |||
| + | The build takes about a minute on first run (Go downloads dependencies). The result is a statically linked binary with no runtime dependencies. | ||
| + | |||
| + | **Minimum requirements** (check before running): | ||
| + | |||
| + | * Linux kernel ≥ 5.5 (for BTF support): ''uname -r'' | ||
| + | * BTF enabled: ''ls /sys/kernel/btf/vmlinux'' — file must exist | ||
| + | * ''bpf'' filesystem mounted: ''mount | grep bpf'' | ||
| + | |||
| + | If BTF is missing, ''pwru'' will fail immediately with a clear error message.</code> | ||
| Now, trace all outgoing DNS queries to the Google DNS (i.e.: ''8.8.8.8'') and perform one using **dig**. Add relative timestamps to the individual trace entries, to get an idea of the computational cost of each operation. | Now, trace all outgoing DNS queries to the Google DNS (i.e.: ''8.8.8.8'') and perform one using **dig**. Add relative timestamps to the individual trace entries, to get an idea of the computational cost of each operation. | ||
| Line 14: | Line 38: | ||
| <note important> | <note important> | ||
| - | Be careful of local DNS caches, especially on Ubuntu. | + | **Ubuntu users:** local DNS caching via ''systemd-resolved'' may intercept your query before it reaches the network. If ''pwru'' shows nothing, try: |
| + | <code bash> | ||
| + | $ sudo systemd-resolve --flush-caches | ||
| + | </code> | ||
| + | or target ''127.0.0.53'' to confirm caching is the issue. | ||
| </note> | </note> | ||
| Line 35: | Line 63: | ||
| Check out this [[https://makelinux.github.io/kernel/map/|map of the kernel subsystems]], but note that the best source of information is always [[https://elixir.bootlin.com/linux/latest/source|RTFS]]. | Check out this [[https://makelinux.github.io/kernel/map/|map of the kernel subsystems]], but note that the best source of information is always [[https://elixir.bootlin.com/linux/latest/source|RTFS]]. | ||
| </note> | </note> | ||
| + | |||
| + | To structure your analysis, answer these questions in order: | ||
| + | |||
| + | - **Where does the packet originate?** Which function is the first to appear in the trace? What layer of the network stack does it correspond to? | ||
| + | - **How does it reach the IP layer?** Identify the transition from the socket/transport layer to the IP layer. Which function marks this boundary? | ||
| + | - **What does Netfilter do here?** Identify ''nf_hook_slow'' in the trace. Which Netfilter hook point does it correspond to (refer back to Figure 1 from Task 01)? | ||
| + | - **How does it leave the machine?** Identify the function responsible for handing the packet to the network device driver. What happens after this point? | ||
| + | - **What changed with the DROP rule?** Compare the two traces side by side. At which function does the path diverge? | ||
| + | |||
