Traffic encryption in Linux

[Carding]

There are many ways to bypass blocking sites and ensure online privacy. Terms like TOR, VPN, and proxy are well-known. You don't need any special knowledge to connect and configure them, but there are also more elegant solutions. Today I will talk about the method of bypassing locks in Linux with traffic masking and show you several scripts for automating this. They can be easily transferred to the Raspberry Pi to make a smart router.

This article is not a guide. It is written solely for the purpose of introducing you to some routing functionality on Linux systems. Author of the article and site editors www.spy-soft.net they do not bear any responsibility for the result of using the methods and techniques described here.

Linux provides a huge set of routing features and configuration tools. Experienced sysadmins know this and use the Linux Arsenal to the fullest. But even many advanced users do not realize how much convenience all these wonderful features can bring. Today we will create routing tables and describe the rules for passing through them, as well as automate the administration of these tables. So, our creative plans:

• let's decide what we need: install the necessary packages and find out why they are needed;
• let's study the General principle of the bundle's operation;
• setting up a secure VPN channel using OpenVPN + stunnel;
• let's make lists of addresses and describe their application areas;
• creating a script for quickly adding a domain or IP address to IPSet lists, adding it to the routing table and including it in the redirect rules;
• we use SSH to provide a secure communication channel to these of your Internets.

Traffic encryption in Linux
What will we need to make everything work, and preferably comfortable? Of course, iptables, where without it. Another iproute2, it will allow us to create a bunch of tables. IPSet is required in order not to make a garden out of a set of iptables rules.

What is what

• iptables is a command-line utility. Basic firewall management tool for Linux kernels.
• iproute2 is a set of utilities for managing network device parameters in the Linux kernel.
• IPSet-a tool for working with lists of IP addresses and network ports in a network filter. Generates a list in a special format for transmission to the firewall.
• stunnel is a tool for organizing encrypted connections for clients or servers that do not support TLS or SSL. Stunnel intercepts unencrypted data that should have been sent to the network and encrypts it. The program works on both Unix and Windows systems. As encryption, it uses OpenSSL to implement the basic TLS and SSL Protocol.
• OpenVPN-a VPN server that supports encryption using the OpenSSL library. Client parts are available on almost all platforms. It can work through proxies such as Socks, HTTP, NAT, and network filters.

You can find a lot of information about all these utilities on the Internet, and with examples of settings in a variety of ways. We will use iptables for marking packets. We will have two configuration options. The first is when the machine running the crawl is itself connected to the VPN. The second option is when there is a node on the network (a virtual machine, Raspberry Pi, or any other host with Linux) that plays the role of a router. Next, we will analyze these options in a little more detail.

Briefly about two options
The client and server will establish an encrypted communication channel on port 443 (stunnel) and transmit inside OpenVPN on port 995th. From the outside, it should look like regular HTTPS

Illustration of how stunnel + OpenVPN works

And here you can implement two connection schemes.

Option 1. On the client machine, iptables will mark packets with a certain flag if the addresses in the packets and IPSet lists match, and pass them for routing.

Next, the packets marked with this flag will be sent using a pre-created routing table, while the rest will follow the default route. We will use the console or a small script to correct this list of addresses. Depending on the situation, there may be several lists.

Option 2. The client will be a host on the local network (a virtual machine, Raspberry Pi, or some other device). It will be specified as the primary gateway on computers that need to access resources via VPN. After receiving a request for an IP address from the list, the gateway will enable NAT and send such traffic to the VPN. The rest of the traffic will be routed to the default gateway without NAT.

For Linux systems, we can leave the default gateway and set IPSet and iproute2, and then configure them in the same way as the settings of the "intermediate" host router. In this case, at the client level, traffic will be selected using the same IPSet list. That is, what is in the list will be sent to the intermediate host router and then to the VPN. The rest will be routed by default.

Implementation
Let's assume that somewhere far away in the cloud, we already have a VPS server running Ubuntu or Debian. In other distributions, the differences will most likely only be in the installation of the necessary packages. This host will be used as a VPN server in our configuration. There are plenty of recommendations on which VPS is best to use on the Internet for different budgets, with different configurations and conditions.

Install OpenVPN, stunnel, and git on the server:

sudo apt install openvpn stunnel4 git

Next, we will use a ready-made script to configure the OpenVPN server. You can, of course, configure everything manually, and I advise you to do just that. Information on how to properly configure OpenVPN is easy to find on the Web. But if you need to get the result very quickly and you don't want to mess around, then here's a quick solution.

git clone https://github.com/Nyr/openvpn-install.git
cd openvpn-install
sudo ./openvpn-install.sh

We get the installation script and run it. It will help you create custom keys and certificates, and if necessary, change the network address. Everything is very accessible and clear. At the output, we will get one file for each user, inside which there will be a configuration key and certificates (server and user). Passing this file to the client.

Open the OpenVPN server configuration file and edit it. Select the appropriate port the one that will be available for connection on the server. It is better to use a more or less inconspicuous port (I chose 995, usually mail ports are left open), so that the client can be guaranteed to connect to the VPN server.

Here's what our config will look like:

The next step is to set up stunnel:

sudo nano /etc/stunnel/stunnel.conf

Everything is simple here:

• we describe where the logs will be saved;
• enter the name of the service in any form;
• choose whether the device is running in server or client mode. In this case, client = no indicates the server mode;
• accept = 443 specifies the port that we will connect to from the outside (port 443 was chosen for a reason - in 99% of cases it is always open, it is easier to pretend to be ordinary HTTPS, and we will not be noticed even at DPI).

Generating keys and certificates for stunnel:

sudo openssl req -nodes -new -days 365 -newkey rsa:1024 -x509 -keyout stunnelsrv.pem -out stunnel.pem

At this stage, it is important to remember that we have OpenVPN on port 995 proto tcp, dev tun0 and stunnel on port 443 running on the server side. All other settings are standard.

Going to the client:

sudo apt install iproute2 ipset stunnel4 git openvpn

Everything you need has been set up, and now we are configuring stunnel on the client side:

Here we specify where to output logs, client mode is enabled. Using the accept Directive, we tell you which address and port to send the connection to and where the stunnel client should actually connect (the connect option). Well, which certificate to use.

Passing the OpenVPN client file from the server. We check the settings: port 995, proto tcp, dev tun0 is used. A very important point: we need to declare a route to our VPS through the default gateway. Otherwise, stunnel will establish a connection, then the VPN will connect and try to redirect everything to the tunnel, but stunnel will no longer be able to work, since the host and port will be unavailable. We also disable redirection of all traffic to the VPN, check the connection address and port. The address of the VPN server in the config will be 127.0.0.1 — that is, localhost. It is assumed that stunnel has already forwarded the required client port. You should get something like the following:

So, OpenVPN and stunnel are installed and configured on the server and client. Secure connection is established. Next, we will consider each option in turn.

Option 1: VPN client on the user's machine
First of all, we will create a list of IP addresses that we will use next:

sudo ipset -N vpn iphash

Adding a single test address to it:

sudo ipset -A vpn 8.8.8.8

Now we need to label packets with destination addresses that match the list.

sudo iptables - OUTOUT -t mangle -m set --match-set vpn dst -j MARK --set-mark (1 или 0x1)

As a result of our actions, iptables will start marking such traffic if the destination address matches the address from The ipset list. Next, we will create a new routing table. to do this, we will write it in the /etc/iproute2/rt_tables file with a priority higher than default (253):

252 vpn

Now you need to create a rule and route for labeled packets.

sudo ip rule add table vpn prio 1000 fwmark (1 or 0x1)
sudo ip route add table vpn dev tun0 default

Don't forget to enable itrp_filter

to ensure asymmetric routing, we also allow packet forwarding between interfaces, in case someone needs to grant access to private resources on the local network.

sudo sysctl net.ipv4.tcp_fwmark_accept=1
sudo sysctl net.ipv4.conf.all.rp_filter=2
sudo net.ipv4.ip_forward=1

Now enable NAT for traffic that is routed to the VPN.

sudo iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE

If you need to provide access from the local network via your VPN, the iptables rule needs to be slightly tweaked, namely transferred to another chain.

sudo iptables -I PREROUTING -t mangle -m set --match-set tovpn dst -j MARK --set-mark 0x1

As a result, we get that all addresses from The ipset VPN list go through a secure connection, while the rest are routed through the default route.

Thank you all for your attention!

 

[Jollier]

When working over a secure connection (the simplest example is HTTPS), all traffic between communicating points in the network is encrypted on the sender's side and decrypted on the recipient's side. Traffic going in both directions is encrypted. In order to encrypt and decrypt it, you need a pair of keys (asymmetric encryption). The public key is used for encryption and is transmitted to the recipient of the data, and the private key for decryption, it remains with the sender. Thus, the nodes between which an SSL connection is established exchange public keys. Further, to improve performance, a single key is formed, which is sent already encrypted and used for both encryption and decryption on both sides (symmetric encryption).

How do they do it? Usually - on the same channel through which the protected traffic will go further. Moreover, the exchange of keys takes place in an open mode. In the case of HTTPS, the server key is associated with a certificate that the user is prompted to view and accept. And this certificate can be intercepted by any intermediate server, on the path of which there is a certificate in clear text (proxy, router).

To further "read" all user traffic, the intermediate server replaces the certificate with its own. Those. it just connects itself to the client with its own certificate, and at the same time connects to the remote server. The client receives a "left" certificate from a malicious server, and the browser informs the user about the danger (such certificates are always unsigned). The user is left with a choice: accept the certificate and work with the site, or refuse to accept it, but then work with the site will no longer work. Sometimes users ignore the contents of the certificates altogether and automatically accept any given to them.

If the user accepts a forged certificate, then the traffic will go according to the following pattern:

client <= SSL connection => listening server <= SSL connection => destination server

Those. the intermediate server will receive all your "secure" traffic in cleartext. It is also worth noting that the transfer of the certificate occurs at the beginning of each HTTPS session.

In the case of secure SSH, the first time you connect to the server, the server key is stored on the client, and the client key is stored on the server. These keys are transferred between the data client-server only once, on the first connection. If, in this case, SSH traffic is attempted to be intercepted, then both the client and the server will refuse the connection due to a key mismatch. Since the keys can be transferred between the client and the server in a roundabout way (over a secure channel or on an external medium), this method of connection is relatively secure. It can only be blocked by forcing the user to work in the open.

It is worth noting that so-called "enterprise information security solutions" have been on sale for a long time, which intercept all traffic passing through an office proxy server and "read" it. Programs look for the presence of certain phrases or information of a certain type in the data stream from browsers, mail programs, ftp clients, messengers of office employees. Moreover, these programs are able to distinguish and process correctly the most different types of information interaction with servers. Among other things, they also check secure SSL traffic by spoofing certificates. I came across the development of one of these systems almost directly.

But there are ways to escape total surveillance. Through the established SSH connection, you can send any necessary traffic, which will go from the SSH server in the open form to the endpoint. This method is called SSH tunneling. This way you can secure the passage of traffic over an unsecured channel, but this approach makes sense only if you have a trusted server with an SSH daemon set up and configured for tunneling. Moreover, it is quite simple to organize it. The SSH client connects to the server, is configured to listen on any given port on the local machine. This client will provide the SOCKS5 proxy service, i.e. its use can be configured in any browser, email programs, IMs, etc. Through the SSH tunnel, packets go to the server, and from there they go to the target server. The scheme is as follows:

[localhost: client <=> proxy] <== SSH connection ==> server <=> target server

Another way to protect traffic is a VPN channel. It is easier and more convenient to use than SSH tunneling, but it is more difficult in the initial installation and configuration. The main convenience of this method is that there is no need to register proxies in programs. And some software does not support a proxy at all, therefore only VPN will do.

In practice, there are two options for working. The first is buying a VPN account, which is sold specifically for this purpose (encrypting traffic over an insecure channel). In this case, accounts are usually sold, which must be connected via PPTP (a regular VPN, which is implemented, for example, in Windows) or L2TP.

The second option is to buy a VDS server (virtual dedicated server) with any Linux distribution on board and set up a VPN server on it. VDS can be Russian or American (just don't forget about overseas pings), cheap (from $ 5) and weak, or expensive and more powerful. An OpenVPN server is installed on the VDS , and the OpenVPN client is installed on the computer. There is even a guish version of the client for Windows.

If you decide to use the OpenVPN option, that is, for example, this simple step-by-step instruction on how to raise a server (Debian). Installing the client is even easier, especially on Windows. There is only one nuance worth noting. If all traffic needs to be allowed through the created VPN connection, then you need to register the default gateway to the VPN gateway (the redirect-gateway parameter in the client's config), and if only part of the traffic (to certain hosts), then you can write normal static routes to these hosts ( by IP; for example, route add -p 81.25.32.25 10.7.0.1).

For the OpenVPN connection, key exchange occurs in manual mode, i.e. it is absolutely safe to transport them from the server to the client.

Thus, SSH and VPN connections can almost completely guarantee the safety of your traffic when traveling over an unsecured channel. The only problem that can arise in this case is the ban on SSL traffic on the corporate firewall. If SSL traffic is allowed to at least one of any port (usually the default 443), then you can potentially raise both the SSH tunnel and the VPN connection by configuring the appropriate daemon on your VDS for this port.