Creating and testing a firewall in Linux, Part 2.1. Introduction to the second part. We look at the network and protocols. Wireshark
Content of the first part:
The content of the second part:
2.1 - Introduction to the second part. We look at the network and protocols. Wireshark.
2.2 - Firewall Tables. Transport Layer. TCP structures, UDP. Extend the firewall.
2.3 - Expanding functionality. We process data in user space. libnetfilter_queue.
2.4 - Bonus. We study the real Buffer Overflow attack and prevent it with the help of our Firewall.
In the previous part, we wrote a simple kernel module, char device driver, equipped it with an interface to communicate with the user space through the read / write char device and sysfs operations, and most importantly, added an orderly interception of all traffic. In this part, we dive a little into the firewall theme, and also look at how to make our program more advanced.
')
Attention! If for you the words "protocols", TCP \ IP, Wireshark are not new - you have nothing to do here :)
Before we continue, I would like to say just a few words about the work of the network (as well as information on the topic of tons) for those who did not deal with this topic at all.
In order for one package to get from one device (computer, phone, router ...) to another, certain rules are needed that determine the procedure for its transportation. These rules are called protocols. As an example, if you want to fly from St. Petersburg to Tel Aviv, you go to the airport, approach the counter, register you there, send you to another counter, they also do the right things, send you further, and so on until you get off in glorious tel aviv. In networks, a package also goes through different stages, depending on the network and other factors. Theoretically, the OSI model (read here ), which describes all the stages, is defined, practically everything is a little different. Look at the picture:
( image source )
When a client sends a packet to the server, the packet passes several instances (again in the classical theoretical cases). Application - for example, a browser. He adds some data, for example, a photo that you want to upload to the social. network. Transport - here two protocols are common - TCP and UDP. They have big differences, but at this stage it is important for us that each of them adds information in order to perform its functions (for example, so that all packets arrive in the order sent). Network - here the most common protocol is IP, it is responsible for ensuring that packets are transmitted through different routers in large networks. It will forward the packet to your provider, then to another server, then to another, and at the end to the end point. Link is used to route packets on small networks, and Physical is a very low level, more associated with individual bits in your network card.
The same thing happens in our virtual network. At the IP protocol level, only two fields will be important to us: IP source — who sends the packet; IP destination — where the packet is sent. At the TCP level, we will only be interested in the source port, destination port. A port is a specific identification number of the connection (for example, when your browser connects to a remote server, it does so with source port = 12345 at destination port = 80. The destination port for known services is reserved and known in advance.
Example:
Host2 sends the host1 packet from port 12345 to port 80:
The data packet got on the network card 10.0.3.1, after which the firewall forwarded it to 10.0.2.1 (yes, the same forwarding from the first part, as fw knew where to send it - a separate topic, it is easy to find on the Internet).
And finally, host1 receives a data packet, sees that its IP address is registered in the src ip field, so it takes it for itself (and does not send it anywhere else).
It is important to note! Srp ip, des tip, src port, dest port, TCP / UDP - five of these data is enough to uniquely identify any communication session (often talking about four data, without a protocol, which is not entirely true, because the port numbers tcp and udp may match). That is, it cannot be in a normal network, where everything is by the rules, two connections with the same 5th above described data at the same time!
I think this is enough for the reader who does not have knowledge of the work of networks to continue reading the article.
Important 2! The above is intended to give a minimum of intuition and is far from a complete and accurate picture, although it reflects the main foundations of networks (for example, the Internet).
As a practice, you can use a widespread program for listening to the network (which, by the way, works according to the same principles as the firewall in this series of articles). It is both under linux, and under windows, and is distributed free of charge.
Let's watch live on the package. So, we start wireshark and we listen to our DHCP output:
I launched a browser and went to google:
In general, for those who have never tried, I strongly advise you to play here, because, besides connecting to google.com, you can see everything, everything that happens on the network, all the protocols that work in it and ensure its stable work including DNS and lower level. You can see that without doing anything, I already own more than 1000 packages. I will use the filter to find those that relate directly to the connection to google.com
And double-click in a separate window:
This is how it looks. From above, you can see all the OSI levels used (what I wrote above), and below I highlighted the data related to the IP protocol, including the most important IP source for us, IP destination. At the application level (browser), the topmost one, you can see that we send a GET / HTTP/1.1 request to google.com, that is, we request a page (the HTTP protocol details can also be easily found on the Internet), as well as various settings of our system ( language, encodings, etc.).
At the TCP level, we see source port = 52983, destination port = 80 and some other flags that can be read on the Internet.
In conclusion: the article is written mainly for those who do not understand the networks at all, and is intended to prepare for the following parts. The practical part of it can be a starting point for those who have never “felt” the network, but always wanted to do it.
In the next part we will talk about the firewall tables, the difference between statefull vs stateless firewall, and also see how from our module you can get access to the fields I wrote about above.
Creating a lab, architecture Netfilter, char device, sysfs
1.1 - Creating a virtual lab (so that we have where to work, I will show how to create a virtual network on your computer. The network will consist of 3 Linux ubuntu machines).
1.2 - Writing a simple module in Linux. Introducing Netfilter and intercepting traffic with it. We combine everything together, we test.
1.3 - Writing a simple char device. Adding a virtual file system - sysfs. Writing user interface. We combine everything together, we test.
1.2 - Writing a simple module in Linux. Introducing Netfilter and intercepting traffic with it. We combine everything together, we test.
1.3 - Writing a simple char device. Adding a virtual file system - sysfs. Writing user interface. We combine everything together, we test.
The content of the second part:
2.1 - Introduction to the second part. We look at the network and protocols. Wireshark.
2.2 - Firewall Tables. Transport Layer. TCP structures, UDP. Extend the firewall.
2.3 - Expanding functionality. We process data in user space. libnetfilter_queue.
2.4 - Bonus. We study the real Buffer Overflow attack and prevent it with the help of our Firewall.
Part 2
In the previous part, we wrote a simple kernel module, char device driver, equipped it with an interface to communicate with the user space through the read / write char device and sysfs operations, and most importantly, added an orderly interception of all traffic. In this part, we dive a little into the firewall theme, and also look at how to make our program more advanced.
')
Part 2.1 Introduction to the network. From theory to practice.
Attention! If for you the words "protocols", TCP \ IP, Wireshark are not new - you have nothing to do here :)
Before we continue, I would like to say just a few words about the work of the network (as well as information on the topic of tons) for those who did not deal with this topic at all.
In order for one package to get from one device (computer, phone, router ...) to another, certain rules are needed that determine the procedure for its transportation. These rules are called protocols. As an example, if you want to fly from St. Petersburg to Tel Aviv, you go to the airport, approach the counter, register you there, send you to another counter, they also do the right things, send you further, and so on until you get off in glorious tel aviv. In networks, a package also goes through different stages, depending on the network and other factors. Theoretically, the OSI model (read here ), which describes all the stages, is defined, practically everything is a little different. Look at the picture:
( image source )
When a client sends a packet to the server, the packet passes several instances (again in the classical theoretical cases). Application - for example, a browser. He adds some data, for example, a photo that you want to upload to the social. network. Transport - here two protocols are common - TCP and UDP. They have big differences, but at this stage it is important for us that each of them adds information in order to perform its functions (for example, so that all packets arrive in the order sent). Network - here the most common protocol is IP, it is responsible for ensuring that packets are transmitted through different routers in large networks. It will forward the packet to your provider, then to another server, then to another, and at the end to the end point. Link is used to route packets on small networks, and Physical is a very low level, more associated with individual bits in your network card.
The same thing happens in our virtual network. At the IP protocol level, only two fields will be important to us: IP source — who sends the packet; IP destination — where the packet is sent. At the TCP level, we will only be interested in the source port, destination port. A port is a specific identification number of the connection (for example, when your browser connects to a remote server, it does so with source port = 12345 at destination port = 80. The destination port for known services is reserved and known in advance.
Example:
Host2 sends the host1 packet from port 12345 to port 80:
The data packet got on the network card 10.0.3.1, after which the firewall forwarded it to 10.0.2.1 (yes, the same forwarding from the first part, as fw knew where to send it - a separate topic, it is easy to find on the Internet).
And finally, host1 receives a data packet, sees that its IP address is registered in the src ip field, so it takes it for itself (and does not send it anywhere else).
It is important to note! Srp ip, des tip, src port, dest port, TCP / UDP - five of these data is enough to uniquely identify any communication session (often talking about four data, without a protocol, which is not entirely true, because the port numbers tcp and udp may match). That is, it cannot be in a normal network, where everything is by the rules, two connections with the same 5th above described data at the same time!
I think this is enough for the reader who does not have knowledge of the work of networks to continue reading the article.
Important 2! The above is intended to give a minimum of intuition and is far from a complete and accurate picture, although it reflects the main foundations of networks (for example, the Internet).
Part 2.1 Introduction to the network. Practice
As a practice, you can use a widespread program for listening to the network (which, by the way, works according to the same principles as the firewall in this series of articles). It is both under linux, and under windows, and is distributed free of charge.
Let's watch live on the package. So, we start wireshark and we listen to our DHCP output:
I launched a browser and went to google:
In general, for those who have never tried, I strongly advise you to play here, because, besides connecting to google.com, you can see everything, everything that happens on the network, all the protocols that work in it and ensure its stable work including DNS and lower level. You can see that without doing anything, I already own more than 1000 packages. I will use the filter to find those that relate directly to the connection to google.com
And double-click in a separate window:
This is how it looks. From above, you can see all the OSI levels used (what I wrote above), and below I highlighted the data related to the IP protocol, including the most important IP source for us, IP destination. At the application level (browser), the topmost one, you can see that we send a GET / HTTP/1.1 request to google.com, that is, we request a page (the HTTP protocol details can also be easily found on the Internet), as well as various settings of our system ( language, encodings, etc.).
At the TCP level, we see source port = 52983, destination port = 80 and some other flags that can be read on the Internet.
In conclusion: the article is written mainly for those who do not understand the networks at all, and is intended to prepare for the following parts. The practical part of it can be a starting point for those who have never “felt” the network, but always wanted to do it.
In the next part we will talk about the firewall tables, the difference between statefull vs stateless firewall, and also see how from our module you can get access to the fields I wrote about above.
Source: https://habr.com/ru/post/316086/
All Articles