Differences
This shows you the differences between two versions of the page.
|
ep:labs:04:contents:tasks:ex5 [2020/08/15 19:02] gheorghe.petre2608 [05. [30p] NetfilterQueue] |
ep:labs:04:contents:tasks:ex5 [2025/02/11 23:36] (current) cezar.craciunoiu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 05. [30p] NetfilterQueue ==== | + | ==== 05. [10p] Feedback ==== |
| - | <note tip> | + | |
| - | A tool that you have previously used is **iptables**. This user space tool interacts with the packet filtering framework that is implemented in the kernel (i.e. [[https://www.netfilter.org/|netfilter]]) in order to allow you to specify your firewall rules. | + | |
| - | **Netfilter** is a framework for packet mangling, outside the normal Berkeley socket interface. It has four parts. Firstly, each protocol defines “hooks” (IPv4 defines 5) which are well-defined points in a packet’s traversal of that protocol stack. At each of these points, the protocol will call the netfilter framework with the packet and the hook number. | + | Please take a minute to fill in the **[[https://forms.gle/NpSRnoEh9NLYowFr5 | feedback form]]** for this lab. |
| - | </note> | + | |
| - | + | ||
| - | In this exercise, we introduce **Netfilter Queues**, an **iptables** target (also part of the netfilter project). What's interesting about this tool is that the hook that it inserts in the network protocol stack does not immediately decide what happens to the packet, based only on the usual vectors (protocol, src/dst IP, src/dst port, etc). Instead, it sends the packet to a user space process for analysis. All packets are buffered and the user space process can retrieve them, evaluate their contents and decide whether to **ACCEPT, DROP or RETURN** them. The messages do not need to be evaluated in the order that they were received. Moreover, the process can even alter the packets and ask the kernel to use the modified version (this happens to be very useful when implementing [[https://en.wikipedia.org/wiki/Man-in-the-middle_attack|MitM]] attacks). | + | |
| - | + | ||
| - | Next, we will look at two examples of **Netfilter Queue** analysis programs that also alter the traffic. First, download the {{:ep:labs:04:contents:tasks:netfilterqueue_examples.zip|demo scripts}}. Also, make sure that you install all dependencies before starting the tasks: | + | |
| - | + | ||
| - | <code bash> | + | |
| - | $ sudo apt update | + | |
| - | $ sudo apt install -y python3-pip wireshark openssh-server libnetfilter-queue1 libnetfilter-queue-dev nfqueue-bindings-python python3-scapy | + | |
| - | $ pip3 install NetfilterQueue | + | |
| - | </code> | + | |
| - | + | ||
| - | === [15p] Task A - DNS hijack === | + | |
| - | + | ||
| - | In this task we will intercept **all DNS responses** and alter the returned IP address for a certain domain name. Before proceeding with the following commands, make sure you have a ssh server running on your machine (we will mess around with that later on). The main goal is to understand how it all works, so make sure you read the script. | + | |
| - | + | ||
| - | If you feel that you need a better understanding of the DNS message format, check out [[https://routley.io/posts/hand-writing-dns-messages/|Let's hand write DNS messages]]. | + | |
| - | + | ||
| - | <code bash> | + | |
| - | $ dig +short fep.grid.pub.ro | + | |
| - | $ sudo iptables -I INPUT -p udp --sport 53 -j NFQUEUE --queue-num 1 | + | |
| - | $ sudo ./mitm-dns fep.grid.pub.ro. 127.0.0.1 | + | |
| - | + | ||
| - | $ dig +short fep.grid.pub.ro | + | |
| - | $ ssh student@fep.grid.pub.ro | + | |
| - | Password: student | + | |
| - | $ sudo iptables -D INPUT 1 | + | |
| - | </code> | + | |
| - | + | ||
| - | <note> | + | |
| - | Let's take a look at what just happened: | + | |
| - | * first, we use **dig** to obtain the IP address of //fep.grid.pub.ro// and it should be //141.85.241.99// or something along those lines | + | |
| - | * next, we add an **iptables** rule: //redirect all UDP incoming traffic that originated from port 53 to queue number 1 for validation in userspace// | + | |
| - | * then, we run the python3 script that will subscribe to queue number 1 and will replace all DNS reponses to fep's domain with 127.0.0.1 | + | |
| - | * after checking the IP again with **dig**, we notice that the script worked | + | |
| - | * what may be a possible implication? Well... let's try connecting to //fep// via **ssh** | + | |
| - | * finally, we stop the script and delete the **iptables** rule | + | |
| - | </note> | + | |
| - | + | ||
| - | === [15p] Task B - TLS downgrade & Wireshark === | + | |
| - | <note tip> | + | |
| - | **TLS** is a cryptographic protocol meant to provide secure communication over a network (e.g. //https//). All sessions that use this protocol start with a //TLS handshake// (see figure below). When the client contacts the server, it sends a //Client Hello//. This message includes a list of supported encryption algorithms. The server receives this message, chooses the best encryption algorithm (that it also knows) and responds with a //Server Hello//, containing the chosen algorithm. | + | |
| - | + | ||
| - | {{ :ep:labs:04:contents:tasks:tls-handshake-protocol.png?600 }} | + | |
| - | </note> | + | |
| - | + | ||
| - | So we know how **Netfilter Queues** and **TLS** work. In this task we will use **wireshark** to detect abnormal traffic. This time, our script will intercept all //Client Hello// messages and replace the supported cipher suite list with a single (weaker) item that the server will be forced to select. Let's try to connect to //ocw.cs.pub.ro// and see what cipher suite it normally chooses: | + | |
| - | + | ||
| - | <code bash> | + | |
| - | $ echo | openssl s_client -connect ocw.cs.pub.ro:443 | + | |
| - | </code> | + | |
| - | + | ||
| - | The answer should be //ECDHE-RSA-AES256-GCM-SHA384//. Now, make sure you have **wireshark** installed and get a network capture of this unaltered handshake. Save it for later. | + | |
| - | + | ||
| - | Next, set up the **iptables** rule and run the process: | + | |
| - | + | ||
| - | <code bash> | + | |
| - | $ sudo iptables -I OUTPUT -p tcp --dport 443 -j NFQUEUE --queue-num 1 | + | |
| - | $ sudo ./mitm-tls_downgrade.py | + | |
| - | + | ||
| - | $ sudo iptables -D OUTPUT 1 | + | |
| - | </code> | + | |
| - | + | ||
| - | Try to capture the //Client Hello// once again with **wireshark**. Place the two captures side by side and identify the cipher suites lists. Which algorithm did our script force the server to accept? | + | |
