Detecting the location of a host on an unmanaged network

I want to demonstrate a solution to the problem, which is considered impossible in principle by the majority of networkers. It is about calculating the physical location of a host in an unmanaged network. The unmanaged network means the network on unmanaged switches, and the location definition is the answer:

"Such a host is connected to the switch, which is located here"

Immediately stipulate the input conditions:
')
- I am an administrator, that is, I know the network topology;
- I have a base of subscribers whose connection points are known to me.

Violations of the network topology, as well as scam on the part of subscribers (ip exchange, change of connection point) to a certain extent, reduce the accuracy of the result. Nevertheless, I regularly use this algorithm in my network and it shows fairly accurate data.

What is the difficulty?

The unmanaged network is a black box, any ethernet frame that comes to you does not have any information through which switches it went through. An uncontrolled switch is a transparent device, it does not change the frames in any way, it only sends them to the necessary (in his opinion) ports.

Thus, we cannot get information about the path of passage either from ethernet frames or from switches.

In fact, this is not entirely true. We cannot request information from the switches, but we have the opportunity to change their behavior and analyze the result.

As you know, every unmanaged switch has a mac-port correspondence table. This table is updated by each incoming frame using a very simple algorithm: which port the frame has come to, the mac-address from the src-mac field of the current frame is attached to that port. In the future, any incoming frame with a dst-mac like the current one will be sent strictly to the port associated with this mac.

In the process, the table of mac-addresses may change if the frame with exactly the same src-mac enters a different port. In this case, the old information is "forgotten." Usually this situation occurs when you reconnect the cables. The detection algorithm is based on this “feature”.

I will not delay with the theory and bring it.

So. We have an uncontrollable switch garland (the harsh reality of small home networks), choose one of the branches. At the end of this thread choose any subscriber. I call him an agent. It performs a key role - the search for an unknown host (in the scripts I call it hacker) will occur at the server-agent site. Thus, it is desirable to choose the most distant subscriber as an agent.

The iteration begins:

1) Arp requests are requested for agent ip and hacker ip. Ip can be located in different logical subnets, for us it does not matter. The important thing is
that by arp-requests we “translate” the network to its normal state, since in the future we will destabilize it a little.

2) We take from the base of any subscriber a location that we know. I call it user. We perform ethernet-spoofing by sending arp-request:

src-mac - hacker mac
src-ip - it doesn't matter (you can hacker or fake ip)
dst-mac - user mac
dst-ip - user ip (you can fake ip)

The purpose of this package is to “reprogram” the ports (change the table of MAC addresses) in the chain of switches from the server to the user with the Mac hacker. If someone on the “reprogrammed” site sends a packet to the hacker’s MAC, it will be received by our server and not by the hacker.

3) An arp-request is sent to the agent:

src-mac - hacker mac
src-ip - it doesn't matter (you can hacker or fake ip, it’s important that agent is in the subnet)
dst-mac - agent mac
dst-ip - agent ip

With this package, we force the agent to respond to an arp request that supposedly came from a hacker.

It is necessary to note a very important point: protocol encapsulation. The fact is that the arp request has its own data, but it is “packed” into an ethernet frame that has its own data. In particular, src-mac with the standard use of arp-request, which is the same in the arp-package, that in the ethernet-frame. Unlike the previous packet, we need to implement exactly arp-spoofing, but not ethernet! Those. In the ethernet frame src-mac should be our server, and in the arp package src-mac = hacker mac. If this condition is met, the switches through which the frame will pass will not change their MAC address tables.

4) On the server, we switch to promiscuous mode (that is, we do not drop packets that go to us, but not to our address) and monitor the arp-reply.
If a:
a) we get a package directed to hacker mac - then geographically hacker is located between the user and the server
b) do not receive - probably hacker is behind user

In the 2nd case there is no absolute guarantee, so you need to repeat all the points several times to increase the probability, and also take into account the data when testing on other subscribers.

In the figure we have a chain of 4 switches. The red line indicates the packet passing path in point 2. As a result, the macro port of the switch closest to the server will be “reprogrammed” so that it will think “the hacker is connected to port No. 1”. No other switches will change their state as the packet will not pass through them.

After the server -> agent request (point 3), the latter sends the answer to the hacker’s mac since src-mac has been replaced. Since on the Hacker-Agent site all switches didn’t change their state, the packet would reach the hacker unhindered.


In the case where User is on the Hacker-Agent site, the agent’s response will come to the server:


5) Go to step 1 and select the next user

At the end of testing, we have a table: user - received / not received a response from the agent. If you put the data on the card (and my script does just that), the administrator instantly eliminates minor deviations (usually they are not) and gets a very accurate result: the hacker is at the junction of the blocks received / not received a response.

Everything that I have described here, I repeat, I have implemented in practice: the scripts are written in perl (use Net :: Packet; use Net :: Packet :: Dump;).