Differences
This shows you the differences between two versions of the page.
|
ep:labs:061:contents:tasks:ex1 [2025/04/08 13:45] radu.mantu |
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> | ||
| Line 14: | Line 14: | ||
| </note> | </note> | ||
| - | === [20p] Task A - tcpdump === | ||
| - | <spoiler> | + | === 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 25: | Line 34: | ||
| Today, **eBPF** is used heavily for system profiling by companies such as Netflix and Facebook. Linux has had a kernel VM capable of running and statically analyzing **eBPF** code since around 2006. **tcpdump** is one of the few examples that still use it for its original purpose. | Today, **eBPF** is used heavily for system profiling by companies such as Netflix and Facebook. Linux has had a kernel VM capable of running and statically analyzing **eBPF** code since around 2006. **tcpdump** is one of the few examples that still use it for its original purpose. | ||
| - | |||
| - | </spoiler> | ||
| == The Task == | == The Task == | ||
| Line 57: | Line 64: | ||
| </solution> | </solution> | ||
| - | === [20p] Task B - iptables === | + | === [10p] Task B - iptables === |
| - | + | ||
| - | <spoiler> | + | |
| **iptables** is a configuration tool for the kernel packet filter. | **iptables** is a configuration tool for the kernel packet filter. | ||
| Line 83: | Line 88: | ||
| * provide an initialization function for the structure containing the rule parameters; this structure will end up in the kernel's rule chain. | * provide an initialization function for the structure containing the rule parameters; this structure will end up in the kernel's rule chain. | ||
| So when you want to test the efficiency of the **iptables** rule evaluation process, keep in mind that each rule may imply the invocation of multiple callbacks such as [[https://elixir.bootlin.com/linux/latest/source/net/netfilter/xt_tcpudp.c#L66|this]]. | So when you want to test the efficiency of the **iptables** rule evaluation process, keep in mind that each rule may imply the invocation of multiple callbacks such as [[https://elixir.bootlin.com/linux/latest/source/net/netfilter/xt_tcpudp.c#L66|this]]. | ||
| - | |||
| - | </spoiler> | ||
| == The Task (1) == | == The Task (1) == | ||
| Line 155: | 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> | ||
