Differences
This shows you the differences between two versions of the page.
|
ep:labs:061:contents:tasks:ex1 [2025/02/11 23:53] cezar.craciunoiu |
ep:labs:061:contents:tasks:ex1 [2026/04/06 21:51] (current) maria.popescu2812 [01. [20p] Primer / Reminder] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 01. [40p] Primer / Reminder ==== | + | ==== 01. [20p] Primer / Reminder ==== |
| <note tip> | <note tip> | ||
| - | //Pro tip #1//: since you'll be using **man** a lot in this exercise, add this to your //.bashrc// or //.zshrc//: | + | //Pro tip #1//: since you'll be using **man** a lot in this exercise, |
| + | install **neovim**, and export this environment variable (in //.bashrc// | ||
| + | or //.zshrc// to change the **man** pager. **neovim** has very good | ||
| + | built-in syntax highlighting. | ||
| <code bash> | <code bash> | ||
| - | # color schemes for man pages | + | export MANPAGER='nvim +Man!' |
| - | man() { | + | |
| - | LESS_TERMCAP_mb=$'\e[1;34m' \ | + | |
| - | LESS_TERMCAP_md=$'\e[1;32m' \ | + | |
| - | LESS_TERMCAP_so=$'\e[1;33m' \ | + | |
| - | LESS_TERMCAP_us=$'\e[1;4;31m' \ | + | |
| - | LESS_TERMCAP_me=$'\e[0m' \ | + | |
| - | LESS_TERMCAP_se=$'\e[0m' \ | + | |
| - | LESS_TERMCAP_ue=$'\e[0m' \ | + | |
| - | command man "$@" | + | |
| - | } | + | |
| </code> | </code> | ||
| - | Source the file and test that it works. | + | Export the environment variable (source the shell config file) and test that it works. |
| </note> | </note> | ||
| - | === [20p] Task A - tcpdump === | + | |
| + | === eBPF — quick recap === | ||
| + | |||
| + | Both tools in this section rely on **eBPF** under the hood, so it's worth a 60-second refresher before we start. | ||
| + | |||
| + | eBPF (extended Berkeley Packet Filter) is a virtual instruction set built into the Linux kernel. You write a small program, the kernel verifies it for safety (no infinite loops, no bad memory access), JIT-compiles it to native code, and attaches it to a hook point — a socket, a syscall, a kernel function entry, a network interface, etc. The program runs in kernel space without you having to write a kernel module. | ||
| + | |||
| + | Originally (1994), BPF existed only to filter network packets for tools like ''tcpdump'': instead of copying every packet to userspace and discarding most of them there, you push a filter program into the kernel and only the matching packets cross the boundary. The "extended" part arrived around 2004 with 64-bit architectures, bringing wider registers, more map types, and JIT support. | ||
| + | |||
| + | Today eBPF is used for packet filtering (''tcpdump'', ''iptables'' BPF match), system profiling (''bpftrace'', Cilium, Netflix's FlameScope), and network policy enforcement in Kubernetes clusters. You already used it in Lab 05 for I/O tracing. In this lab you'll see it appear in two more places: inside ''tcpdump'''s filter compiler and in the ''iptables'' BPF match module. | ||
| + | |||
| + | === [10p] Task A - tcpdump === | ||
| **tcpdump** is a network traffic monitoring tool. At its core, it uses **libpcap** which in turn uses a technology called **Extended Berkley Packet Filter (eBPF)**. | **tcpdump** is a network traffic monitoring tool. At its core, it uses **libpcap** which in turn uses a technology called **Extended Berkley Packet Filter (eBPF)**. | ||
| Line 59: | Line 64: | ||
| </solution> | </solution> | ||
| - | === [20p] Task B - iptables === | + | === [10p] Task B - iptables === |
| **iptables** is a configuration tool for the kernel packet filter. | **iptables** is a configuration tool for the kernel packet filter. | ||
| Line 153: | Line 158: | ||
| Also, use this [[https://www.mankier.com/8/nfbpf_compile|man page]] rather than installing it separately. | Also, use this [[https://www.mankier.com/8/nfbpf_compile|man page]] rather than installing it separately. | ||
| + | </note> | ||
| + | |||
| + | <note important> | ||
| + | **Table matters** | ||
| + | |||
| + | This rule uses the ''TTL'' target, which is only valid in **a certain table**. If you forget it, ''iptables'' will accept your command silently and still fail at kernel level. You won't see an error in the terminal — you'll see this: | ||
| + | |||
| + | <code> | ||
| + | iptables: Invalid argument. Run `dmesg' for more information. | ||
| + | </code> | ||
| + | |||
| + | Check ''dmesg'' whenever ''iptables'' gives you "Invalid argument". You'll find the actual error there. | ||
| + | |||
| + | This is intentional behavior: the kernel module that handles the TTL target implements a **rule check callback** that validates the structure received from userspace. It doesn't trust you. If something is wrong, it logs to the kernel ring buffer — so ''dmesg'' is always your first stop when debugging ''iptables'' rules. | ||
| </note> | </note> | ||
