Pass to the onion country. We raise Wi-Fi with proxying the traffic of client devices through Tor.

[Lord777]

In this article, we'll look at how to configure a Wi-Fi hotspot with automatic anonymization of all outgoing traffic over the Tor network, as well as take a look at some useful examples of its use for both a simple user and a security researcher.

Why do we need Tor AP?​

Recently, against the background of massive blocking of IP addresses, fewer and fewer people continue to doubt whether proxying and anonymization mechanisms are needed in their everyday life. There are more and more free VPN clients, but, as practice shows, not all of them are safe to completely trust: either the quality of the implementation is lame, or the developers are not too conscientious.

As you know, Tor provides out of the box both a proxying mechanism (read: bypassing locks) and an advanced anonymity mechanism. All communication between nodes in the Tor network is encrypted, and the connection to the target node is established through at least three randomly selected nodes. Taking Tor as a basis and automating all the processes that occur when connecting to an access point (hereinafter referred to as AP), as a result, we will get a very interesting tool, the benefits of which are by no means limited to bypassing locks ...

AP Initial Configuration​

To create a point, we need some device on which to run an operating system (a virtual machine is also quite useful). Any Linux distribution is suitable as the operating system that controls the point. Specifically, I will be using Debian-based. To turn it all into an AP, you need a Wi-Fi adapter.

If all this is done, you can proceed with the initial configuration. So, first of all, we connect the Wi-Fi adapter. The output ip addr show wlan0 (wlan0 is the name of the adapter interface, it may be different) should be the same as in the screenshot.

At the moment, the network interface is not configured. First of all, we activate Wi-Fi, freeing it from the influence of the ubiquitous Network Manager:

At the moment, the network interface is not configured. First of all, we activate Wi-Fi, freeing it from the influence of the ubiquitous Network Manager:

$ sudo nmcli radio wifi off

Now let's select and assign an IP address to the adapter interface, all addresses from the mask of which will be assigned to client devices in the future:
# ip addr add 10.0.0.1/24 dev wlan0

The third point we will put the adapter into AP mode: we will do this in one of the most common ways - using the hostapd utility, which allows you to configure a software access point. Hostapd is available in most of the stock repositories.

$ sudo apt-get install hostapd

Next, you need to create a config for hostapd (./hostapd.conf):
## Adapter interface name

After that, it will already be possible to run hostapd to put the Wi-Fi adapter into AP mode with the described configuration:
# hostapd ./hostapd.conf

Hostapd and Network Manager​

In some versions of hostapd, there is a bug related to blocking the Network Manager interface and not allowing AP to start. Running hostapd results in the following error:
Interface wlan0 wasn't started

The bug and a possible work-round are described in detail here.

However, for obvious reasons, it will not yet be possible to connect to the point in the usual way.

To eliminate these causes, you will need another utility - dnsmasq, which will allow you to deploy DHCP and DNS services. DHCP is of more interest right now. Install dnsmasq from the standard repository:

$ sudo apt-get install dnsmasq

Dnsmasq also needs pre-configuration (./dnsmasq.conf):
## Interface for listening to DHCP requests

We start the DHCP server as part of dnsmasq:
# dnsmasq -C ./dnsmasq.conf

Now connection to the AP becomes possible from any device. In order for our point to finally work as usual, it remains to answer the main question: where will the point get access to the Internet from. To get an answer, I suggest taking a look at the diagram below. Most readers who have come into contact with the setup of networks in one way or another will notice a fairly familiar scheme for connecting networks on it. This is the method we will use.

As you can see from the figure, you need another network interface to access the Internet. This can be either an Ethernet connection (eth0) or a second Wi-Fi module (wlan1). For example, when creating an AP from a virtual machine, such an interface is created automatically (eth0). Now we have everything ready, except for the communication between the interfaces (indicated by the red line). This link is the forwarding of packets from one interface to another. For testing the performance of our AP, the usual NAT mechanism will still work:

$ sudo sysctl -w net.ipv4.ip_forward = 1

At this stage, the AP is working as usual: it accepts clients and provides them with Internet access from the IP address given to us by our provider. This is great, of course, but not enough for our purposes. So now is the time to redirect all client traffic to Tor.

Secondary AP Configuration​

Before redirecting all AP traffic to Tor, you need to install Tor itself:

$ sudo apt-get install tor

And configure it as a Transparent Proxy using the config file (located here: / etc / tor / torrc):
## Enable access to onion resources

These settings are enough for our needs, so we can run Tor as a service:

$ sudo service tor start

At the moment, the output netstat -tunapl should be something like the screenshot below. We see all the services we have launched at the moment.

Open ports on AP

If we connect to the AP now, we will still be accessing the Internet from our home IP, so all that remains is to enable proxying through Tor using iptables:
# Redirect all TCP traffic

You also need to remove the previous rule that enables masquerade between network interfaces (NAT):

$ sudo iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

With two new rules, we have achieved the following: substitution of the destination of all TCP traffic at the moment packets appear on the network interface of the Wi-Fi adapter and redirecting DNS requests (UDP protocol). Spoofed Destination - A running Tor service with Transparent Proxy. It is worth noting that these two rules complete the iptables configuration. Now you can make sure that the configured Tor AP is working by visiting 2ip.ru from any device connected to it.

RPi as AP​

Malinka is perfect as an AP control device: just a few additional actions with automatic deployment of the configuration at system startup (systemd, initV), and all that remains is to plug the USB cable into the "socket" to turn on the point at any time.

Practical application of AP​

Having our own AP, to which client devices connect, by default we get the ability to monitor all traffic on our network, both passive and active. Tor redirection is just one of the applications of AP in applications.

Client device traffic analysis​

Perhaps the most obvious option that immediately comes to mind. Nobody forbids launching Wireshark or tcpdump on AP and capturing traffic of a specific client or all client devices at once until the traffic is redirected to Tor. Capabilities for capture are limited only by the level of security of the end device, user and application. The topic is quite well-known, so we will not dwell on it in detail.

Capture Traffic by MAC Address on AP

Analysis of network activity of applications​

In information security, the task often arises to analyze the network activity of a particular application. For example, we have a mobile application that uses several hosts known to us. We want to use the black box method to check if the application is making any hidden transmissions to additional remote hosts. Moreover, we cannot do this on the device itself - there are no corresponding rights at the OS level. But we have an AP that is completely under control and with maximum rights! Its use will be almost the same as analyzing traffic on a target device.

Let's try to investigate the performance of the application without hidden access to any additional resources. In advance, we have disabled all other sources of side traffic generated from other applications. In this case, hidden transmissions do not have to be malicious - they can be anti-spam mechanisms (control that the application API is actually used from a mobile device), advertising, and so on. We can pass traffic using the white box method - everything that is not allowed is prohibited:

$ sudo iptables -t nat -F

Thus, we allowed only traffic from three hosts of a certain device to enter Tor, all other traffic will not leave the wlan0 interface, and therefore nothing hidden will be transmitted. All that remains is to make sure that the application does not have defects.

Blocking specific hosts​

In this case, a good solution would be to issue a message that the host is blocked on our network. To do this, you can raise a web server and redirect clients from a blocked resource to a page with a message. To block resources over HTTPS, you will need to at least generate a self-signed certificate and configure the web server to work over the HTTPS protocol. Blocking can be done directly in the NAT table:

$ sudo iptables -t nat -I PREROUTING 1 -i wlan0 -p tcp -d m.vk.com --dport 80 -j DNAT --to-destination 192.168.1.82:80

Blocking ad networks to increase anonymity​

It has long been known that ad network scripts try to secretly collect as much information as possible about site visitors, thus posing an additional threat to anonymity. Fortunately, on our own AP, we can, by default, block for clients from associating ad scripts with ad networks. To do this, I propose to return to the dnsmasq utility: as one of the options in its config, the utility offers an additional source of DNS information (along with / etc / hosts). Let's change the Dnsmasq config file (./dnsmasq.conf):

...

The contents of the file have exactly the same format as / etc / hosts, so there should be no problems with filling it. You can choose the source of blocked resources yourself from the repository on GitHub - there you can find hosts files for blocking of various scales (in the largest assembly there were about 71 thousand different hosts).

Conclusion​

In such a simple way, we created an access point, all traffic of which is “hiding” behind Tor, and as a nice bonus, we got the opportunity to “juggle” all traffic passing through it for our own purposes - both good and bad.