Differences
This shows you the differences between two versions of the page.
|
ep:labs:04:contents:tasks:ex5 [2019/10/22 09:08] radu.mantu [05. [25p] NetfilterQueue] |
ep:labs:04:contents:tasks:ex5 [2025/02/11 23:36] (current) cezar.craciunoiu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 05. [25p] NetfilterQueue ==== | + | ==== 05. [10p] Feedback ==== |
| - | 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. If you've never heard of netfilter, here is a short description from the project's documentation: //"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. |
| - | + | ||
| - | 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. Install any dependencies that you may need as you go (e.g. scapy, openssh-server, etc). Also, download the {{:ep:labs:04:contents:tasks:netfilterqueue_examples.zip|demo scripts}} unless you want to write them yourselves. | + | |
| - | + | ||
| - | <code bash> | + | |
| - | $ sudo apt install -y python3-pip wireshark openssh-server libnetfilter-queue1 libnetfilter-queue-dev nfqueue-bindings-python | + | |
| - | $ pip3 install NetfilterQueue | + | |
| - | </code> | + | |
| - | + | ||
| - | === [10p] 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> | + | |
| - | + | ||
| - | 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 | + | |
| - | + | ||
| - | Take a look at the script and try to understand how it works. | + | |
| - | + | ||
| - | === [15p] Task B - TLS downgrade & Wireshark === | + | |
| - | + | ||
| - | So we know how **Netfilter Queues** work. In this task we will use **wireshark** to detect abnormal traffic. But first, a bit of information on what kind of attack we are looking at. | + | |
| - | + | ||
| - | 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 }} | + | |
| - | + | ||
| - | 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? | + | |
