Differences
This shows you the differences between two versions of the page.
|
ep:labs:04:contents:tasks:ex1 [2021/11/02 13:45] radu.mantu |
ep:labs:04:contents:tasks:ex1 [2023/10/29 21:08] (current) radu.mantu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 01. [30p] Primer / Reminder ==== | + | ==== 01. [40p] Primer / Reminder ==== |
| <note tip> | <note tip> | ||
| Line 20: | Line 20: | ||
| </note> | </note> | ||
| - | === [10p] Task A - tcpdump === | + | === [20p] 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 28: | Line 28: | ||
| At first, the whole idea was to compile packet filtering programs and attach them to sockets in kernelspace. These programs would filter out packets that userspace processes would not be interested in. Consequently, this would reduce the quantity of data copied over the kernelspace/userspace boundary, only to ultimately be discarded. | At first, the whole idea was to compile packet filtering programs and attach them to sockets in kernelspace. These programs would filter out packets that userspace processes would not be interested in. Consequently, this would reduce the quantity of data copied over the kernelspace/userspace boundary, only to ultimately be discarded. | ||
| - | 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. Ask your assistant if you want to know more about **eBPF** tracing (not part of the lab, don't panic!) | + | 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. |
| == The Task == | == The Task == | ||
| Line 65: | Line 65: | ||
| The system as a whole provides many functionalities that are grouped by **tables**: //filter, nat, mangle, raw, security//. If you want to alter a packet header, you place a rule in the //mangle// table. If you want to mask the private IP address of an internal host with the external IP address of the default gateway, you place a rule in the //nat// table. Depending on the table you choose, you will gain or lose access to some chains. If not specified, the default is the //filter// table. | The system as a whole provides many functionalities that are grouped by **tables**: //filter, nat, mangle, raw, security//. If you want to alter a packet header, you place a rule in the //mangle// table. If you want to mask the private IP address of an internal host with the external IP address of the default gateway, you place a rule in the //nat// table. Depending on the table you choose, you will gain or lose access to some chains. If not specified, the default is the //filter// table. | ||
| - | **Chains** are basically lists of rules. The five built-in chains are //PREROUTING, FORWARD, POSTROUTING, INPUT, OUTPUT//. Each of these corresponds to certain locations in the network stack where packets trigger **Netfilter hooks** ([[https://elixir.bootlin.com/linux/latest/source/net/ipv4/ip_input.c#L540|here]] is the //PREROUTING// kernel hook as an example -- not that hard to add one, right?) For a selected chain, the order in which the rules are evaluated is determined primarily by the priority of their tables and secondarily by the user's discretionary arrangement (i.e.: order in which rules are inserted). | + | **Chains** are basically lists of rules. The five built-in chains are //PREROUTING, FORWARD, POSTROUTING, INPUT, OUTPUT//. Each of these corresponds to certain locations in the network stack where packets trigger **Netfilter hooks** ([[https://elixir.bootlin.com/linux/v6.5.9/source/net/ipv4/ip_input.c#L569|here]] is the //PREROUTING// kernel hook as an example -- not that hard to add one, right?) For a selected chain, the order in which the rules are evaluated is determined primarily by the priority of their tables and secondarily by the user's discretionary arrangement (i.e.: order in which rules are inserted). |
| {{ :ep:labs:04:contents:tasks:iptables_path.png?800 |}} | {{ :ep:labs:04:contents:tasks:iptables_path.png?800 |}} | ||
| + | <html> | ||
| + | <center> | ||
| + | <b>Figure 1:</b> Netfilter hooks; each has a subset of associated tables. Tables categorize the actions (i.e.: targets) taken when a match occurs. E.g: NAT cannot be performed on the FORWARD chain. When multiple rules exist on the same chain, their processing order is primarily determined by the priority of the table they are defined in. | ||
| + | </center> | ||
| + | </html> | ||
| A **rule** consists of two entities: a sequence of match criteria and a jump target. | A **rule** consists of two entities: a sequence of match criteria and a jump target. | ||
| Line 73: | Line 78: | ||
| The **jump target** represents an action to be taken. You are most likely familiar with the built-in actions such as //ACCEPT// or //DROP//. These actions decide the ultimate fate of the packet and are final (i.e.: rule iteration stops when these are invoked). However, there are also extended actions (see ''man iptables-extensions(8)'') that are not terminal verdicts and can be used for various tasks such as auditing, forced checksum recalculation or removal of Explicit Congestion Notification (ECN) bits. | The **jump target** represents an action to be taken. You are most likely familiar with the built-in actions such as //ACCEPT// or //DROP//. These actions decide the ultimate fate of the packet and are final (i.e.: rule iteration stops when these are invoked). However, there are also extended actions (see ''man iptables-extensions(8)'') that are not terminal verdicts and can be used for various tasks such as auditing, forced checksum recalculation or removal of Explicit Congestion Notification (ECN) bits. | ||
| - | The **match criteria** of every rule are checked to determine if the jump target is applied. The way this is designed is very elegant: every type of feature (e.g.: l3 IP address vs l4 port) that you can check has a match callback function defined in the kernel. If you want, you can write your own such function in a Linux Kernel Module (LKM) and thus extend the functionality of **iptables** ([[https://inai.de/documents/Netfilter_Modules.pdf|Writing Netfilter Modules]] with code example). However, you will need to implement a userspace shared library counterpart. When you start an **iptables** process, it searches in ///usr/lib/xtables/ // and automatically loads certain shared libraries (note: this path can be overwritten or extended using the //XTABLES_LIBDIR// environment variable). Each library there must do three things: | + | The **match criteria** of every rule are checked to determine if the jump target is applied. The way this is designed is very elegant: every type of feature (e.g.: Layer 3 IP address vs Layer 4 port) that you can check has a match callback function defined in the kernel. If you want, you can write your own such function in a Linux Kernel Module (LKM) and thus extend the functionality of **iptables** ([[https://inai.de/documents/Netfilter_Modules.pdf|Writing Netfilter Modules]] with code example). However, you will need to implement a userspace shared library counterpart. When you start an **iptables** process, it searches in ///usr/lib/xtables/ // and automatically loads certain shared libraries (note: this path can be overwritten or extended using the //XTABLES_LIBDIR// environment variable). Each library there must do three things: |
| * define **iptables** flags for the new criteria that you want to include. | * define **iptables** flags for the new criteria that you want to include. | ||
| * define help messages for when ''**iptables** %%--%%help'' is called (its help message is an amalgamation of each library's help snippet). | * define help messages for when ''**iptables** %%--%%help'' is called (its help message is an amalgamation of each library's help snippet). | ||
| Line 93: | Line 98: | ||
| <note tip> | <note tip> | ||
| + | |||
| + | **multiport**, **owner** modules | ||
| + | |||
| <code bash> | <code bash> | ||
| $ man 8 iptables-extensions | $ man 8 iptables-extensions | ||
| </code> | </code> | ||
| - | |||
| - | **multiport**, **owner** modules | ||
| </note> | </note> | ||
| Line 129: | Line 135: | ||
| <note tip> | <note tip> | ||
| + | **bpf** module | ||
| + | |||
| <code bash> | <code bash> | ||
| $ man 8 iptables-extensions nfbpf_compile | $ man 8 iptables-extensions nfbpf_compile | ||
| </code> | </code> | ||
| - | |||
| - | **bpf** module | ||
| ---- | ---- | ||
| - | If you are working on Ubuntu, there is a chance that **nfbpf_compile** did not come with the **iptables** package. You can still install this manually: | + | If you are working on Ubuntu, there is a chance that **nfbpf_compile** did not come with the **iptables** package (oh Canonical... maybe there's something in the //Universe// repos?). \\ |
| + | Anyway, you can still install it manually: | ||
| <code bash> | <code bash> | ||
