Redirecting traffic to a remote sniffer using iptables + iproute2
After buying their first smartphone, people usually notice that mobile spending increases slightly. This is usually due to the fact that the "smart" phone "goes to the Network" without the knowledge of the owner. Of course, to solve this problem is simple - install special utilities to block connections to GPRS / HSDPA access points or buy an unlimited Internet access tariff and forget. Faced with the described situation, I first of all became interested in what the phone was looking for on the Net and, most importantly, what it sends to the Net. The latter is especially relevant in connection with recent news .
To view the traffic that the smartphone sends to the network, you need a special program - sniffer .
Sometimes you can just install it on your phone. This is the most reliable way, but it is not always available.
If the smartphone has Wi-Fi, then you can use additional devices - for example, connect it via Wi-Fi to a router or computer with a sniffer, or, if you do not have access to a router with Wi-Fi, connect it to an unsecured Wi-Fi network and analyze all traffic from the third computer.
Consider the most typical case - a home network managed by a normal access point with a Wi-Fi (DSL modem or router), the parameters of which do not want to change. Most home access points are running Linux, which can be accessed easily, for example, via telnet.
This note will tell you how to redirect all traffic from a smartphone (or from any other host on the network) to a Linux computer for learning so that it is invisible to the device under study.
It does not describe how Netfilter or iproute2 works. This information is easy to find on the Internet - at the end of the note there are links where you can read about it. There is just one more way to elegantly apply these tools, which, I hope, will provide an opportunity to feel all their power and simplicity.
')
Total we have:
The action plan is simple: using iproute2, we create on the router a separate routing table and a rule that will use it for all traffic from the smartphone. Let us specify in the table the default gateway - a host with a sniffer:
Important! Two rules with the same priority are not allowed. First you need to check if there is another rule with the same priority:
The number for the
Table (
A host with a sniffer should redirect all traffic to the network. NAT can do this easily. Further, this traffic will easily pass through the same router and will go to its destination - after all, the IP address now has a different sender address and will not get into our routing table:
That seemed to be all. You can run a sniffer on your computer and filter traffic by IP address 192.168.1.3.
But such a scheme has a significant drawback: the traffic that was intended for the router itself will not get to the sniffer. For example, DNS. Sometimes, it is important, for example, to determine which server is 74.125.39.188 (mtalk.google.com), on which the smartphone continuously sends something. To do this, use iptables again. Judging by the scheme from the iptables manual, in order for this traffic to be redirected (got into the right branch) as a result of routing, you need to change its destination address to
Commands that configure redirection (FORWARD table) will be skipped - after all, it should already work on the router in normal mode :)
On the sniffer host, we change the destination address back:
It should be noted that on the sniffer host, traffic will fall under masquerading (MASQUERADE), that is, the source address of the packets will also change. As a result, the packets should move according to the following scheme (above the arrows, the host numbers of the sender and receiver of the packet are indicated, the sequence is from top to bottom):
However, this option does not work when the computer and the smartphone are in the same segment, and the router acts as a network bridge . Then, according to the routing table on the sniffer host, the return traffic will be sent directly to the recipient, and the recipient's operating system, the smartphone, should ignore it, because the sender's address will not be the one to which the connection is established:
The way out of this situation is simple - to redirect these packets to the router again, in the same way that redirection to the sniffer was done:
Receiving this “problem” traffic, the Netfilter router using the state detection mechanism (nf_conntrack module), “recognizes” in it the connections that were changed using DNAT and replaces the address of the receiver of the packets with the original one. Further packets are sent to the recipient as if nothing had happened.
Final scripts:
To view the traffic that the smartphone sends to the network, you need a special program - sniffer .
Sometimes you can just install it on your phone. This is the most reliable way, but it is not always available.
If the smartphone has Wi-Fi, then you can use additional devices - for example, connect it via Wi-Fi to a router or computer with a sniffer, or, if you do not have access to a router with Wi-Fi, connect it to an unsecured Wi-Fi network and analyze all traffic from the third computer.
Consider the most typical case - a home network managed by a normal access point with a Wi-Fi (DSL modem or router), the parameters of which do not want to change. Most home access points are running Linux, which can be accessed easily, for example, via telnet.
This note will tell you how to redirect all traffic from a smartphone (or from any other host on the network) to a Linux computer for learning so that it is invisible to the device under study.
It does not describe how Netfilter or iproute2 works. This information is easy to find on the Internet - at the end of the note there are links where you can read about it. There is just one more way to elegantly apply these tools, which, I hope, will provide an opportunity to feel all their power and simplicity.
')
Total we have:
- A network with a router on Linux and the shell available on it (for example, for my case - a modem from Stream, access is described here ). Network IP Address: 192.168.1.1.
- A computer with any Linux distribution. Why Linux? Because almost all Linux distributions include the iptables and iproute2 utilities and the tcpdump sniffer, with which you can solve almost all network tasks. But the sniffer is better to use with the GUI. For example, Wireshark. IP address: 192.168.1.2.
- Actually, the device under study is a smartphone connected to our network. IP address: 192.168.1.3.
The action plan is simple: using iproute2, we create on the router a separate routing table and a rule that will use it for all traffic from the smartphone. Let us specify in the table the default gateway - a host with a sniffer:
# ROUTER=192.168.1.1 SLEUTH=192.168.1.2 SUSPECT=192.168.1.3 TABLE=14 ip rule add from $SUSPECT table $TABLE priority 5 ip route add default via $SLEUTH table $TABLE Important! Two rules with the same priority are not allowed. First you need to check if there is another rule with the same priority:
ip rule listThe number for the
priority should be chosen smaller - the smaller the value, the higher the priority. My first four were busy.Table (
$TABLE ), you can select any unused. Whether the table is used, can be viewed using the ip route list table $TABLE command.A host with a sniffer should redirect all traffic to the network. NAT can do this easily. Further, this traffic will easily pass through the same router and will go to its destination - after all, the IP address now has a different sender address and will not get into our routing table:
# ROUTER=192.168.1.1 SLEUTH=192.168.1.2 SUSPECT=192.168.1.3 sysctl -w net.ipv4.ip_forward="1" iptables -I FORWARD -s $SUSPECT -j ACCEPT iptables -I FORWARD -d $SUSPECT -j ACCEPT iptables -t nat -I POSTROUTING -s $SUSPECT -j MASQUERADE That seemed to be all. You can run a sniffer on your computer and filter traffic by IP address 192.168.1.3.
But such a scheme has a significant drawback: the traffic that was intended for the router itself will not get to the sniffer. For example, DNS. Sometimes, it is important, for example, to determine which server is 74.125.39.188 (mtalk.google.com), on which the smartphone continuously sends something. To do this, use iptables again. Judging by the scheme from the iptables manual, in order for this traffic to be redirected (got into the right branch) as a result of routing, you need to change its destination address to
PREROTING : # iptables -t nat -I PREROUTING -s $SUSPECT -d $ROUTER -j DNAT --to-destination $SLEUTH Commands that configure redirection (FORWARD table) will be skipped - after all, it should already work on the router in normal mode :)
On the sniffer host, we change the destination address back:
# iptables -t nat -I PREROUTING -s $SUSPECT -d $SLEUTH -j DNAT --to-destination $ROUTER It should be noted that on the sniffer host, traffic will fall under masquerading (MASQUERADE), that is, the source address of the packets will also change. As a result, the packets should move according to the following scheme (above the arrows, the host numbers of the sender and receiver of the packet are indicated, the sequence is from top to bottom):
However, this option does not work when the computer and the smartphone are in the same segment, and the router acts as a network bridge . Then, according to the routing table on the sniffer host, the return traffic will be sent directly to the recipient, and the recipient's operating system, the smartphone, should ignore it, because the sender's address will not be the one to which the connection is established:
The way out of this situation is simple - to redirect these packets to the router again, in the same way that redirection to the sniffer was done:
# TABLE=15 ip rule add to $SUSPECT table $TABLE priority 7 ip route add default via $ROUTER table $TABLE Receiving this “problem” traffic, the Netfilter router using the state detection mechanism (nf_conntrack module), “recognizes” in it the connections that were changed using DNAT and replaces the address of the receiver of the packets with the original one. Further packets are sent to the recipient as if nothing had happened.
Final scripts:
# ROUTER=192.168.1.1 SLEUTH=192.168.1.2 SUSPECT=192.168.1.3 TABLE=14 ip rule add from $SUSPECT table $TABLE priority 4 ip route add default via $SLEUTH table $TABLE iptables -t nat -I PREROUTING -s $SUSPECT -d $ROUTER -j DNAT --to-destination $SLEUTH # ROUTER=192.168.1.1 SLEUTH=192.168.1.2 SUSPECT=192.168.1.3 sysctl -w net.ipv4.ip_forward="1" iptables -I FORWARD -s $SUSPECT -j ACCEPT iptables -I FORWARD -d $SUSPECT -j ACCEPT iptables -t nat -I POSTROUTING -s $SUSPECT -j MASQUERADE iptables -t nat -I PREROUTING -s $SUSPECT -d $SLEUTH -j DNAT --to-destination $ROUTER TABLE=15 ip rule add to $SUSPECT table $TABLE priority 5 ip route add default via $ROUTER table $TABLE Notes
- Both iptables and iproute2 packages must be installed on both the router and the computer, and support for netfilter and advanced routing must be included in the kernel. In most distributions and in most routers, both are accomplished. If the kernel was configured independently, then it is better to double-check their presence.
- The router, host sniffer and telephone can be located in different network segments. The main thing is that they were connected, and all the traffic from the smartphone passed through the router.
- As a smartphone in this article can be any other device that can go to the Internet via Wi-Fi or Ethernet.
- The use of the described method to collect and disseminate confidential information as well as private information about the life of a person without his consent is illegal! (Articles 137, 138 of the Criminal Code of the Russian Federation)
- Remember that even Wi-Fi-protected networks can be insecure if you are not sure that the access point is completely protected from unauthorized persons. If this is important, use data transfer protocols that support encryption, for example, HTTPS, XMPP (Jabber).
- Of course, the use of this method in relation to a computer with a full-fledged OS is easily monitored using tracroute (tracert in Windows), or simply because of a decrease in TTL packets, which is noticeable when pinging a router.
Links
Source: https://habr.com/ru/post/119356/
All Articles