March 26, 2012 at 21:26Unmanaged network location discovery
I want to demonstrate a solution to a problem that most “networkers” consider impossible in principle. It is about calculating the physical location of a host in an unmanaged network. An unmanaged network means a network on unmanaged switches, and a location is the answer:
“such a host is connected to the switch located here” I will
immediately stipulate the input conditions:
- I am an administrator, that is, I know the network topology;
- I have a database of subscribers whose connection points are known to me.
Violations of the network topology, as well as fraud by subscribers (ip exchange, change of connection point) to some extent reduce the accuracy of the result. However, I regularly use this algorithm on my network and it shows fairly accurate data.
An 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 unmanaged switch is a transparent device; it does not change frames in any way, it only directs them to the necessary ports (in his opinion).
Thus, we can not get information about the path 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, each unmanaged switch has a mac-port mapping table. This table is updated by each incoming frame according to a very simple algorithm: which port the frame came to, the mac address from the src-mac field of the current frame is bound to that port. In the future, any incoming frame with dst-mac like the current one will be sent strictly to the port associated with this mac.
In the process, the mac address table may change if a frame with exactly the same src-mac enters a different port. In this case, the old information is “forgotten”. Typically, this situation occurs when you reconnect the cables. The detection algorithm is based on this “feature”.
So. We have an uncontrollable garland of switches (the harsh reality of small home networks), we select one of the branches. At the end of this thread, select any subscriber. I call him an agent. It plays a key role - the search for an unknown host (in scripts I call it hacker) will occur on the server-agent site. Thus, it is desirable to select the most remote subscriber as an agent.
The iteration begins:
1) Arp-requests request the ip of the agent and the ip of the hacker. Ip can be in different logical subnets, for us it doesn’t matter. The important thing is
that we “translate” the network into its normal state by arp-requests, since in the future we will destabilize it a bit.
2) We take from the base of any subscriber, the location that we know. I call him user. We carry out 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 “ reprogram "ports (change the table of MAC addresses) in the chain of switches from the server to user with the hacker poppy. If someone sends a packet to the hacker's MAC on the network in the “reprogrammed” section, it will be received by our server, and not by the hacker.
3) Arp-request is sent to the agent:
src-mac - hacker mac
src-ip - it doesn’t matter (you can use hacker or fake ip, it is important that agent’s subnet is used)
dst-mac - agent mac
dst-ip - agent ip
With this package, we force the agent to respond to the arp-request, which allegedly came from a hacker.
A very important point to note: protocol encapsulation. The fact is that an 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 in the arp packet, that in the ethernet frame are the same. Unlike the previous package, we need to implement 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, then the switches through which the frame passes will not change their MAC address tables.
4) On the server, we switch to promiscuous mode (that is, we do not discard packets that go to us, but not to our address) and monitor arp-reply.
If:
a) we get a packet directed to hacker mac - it means geographically hacker is between user and server
b) we don’t get - probably hacker is behind user
In the 2nd case there is no absolute guarantee, therefore it is necessary to repeat all points several times to increase the probability, and also take into account data when testing on other subscribers.
In the figure we have a chain of 4 switches. The red line indicates the path of the packet in step 2. As a result, the table “reprograms” the pop-up table of the switch closest to the server so that it thinks “the hacker is connected to port No. 1”. No other switches will change their state because the packet will not pass through them.
After the server -> agent request (point 3), the latter sends a response to the hacker’s poppy because src-mac has been superseded. Since all switches did not change their state on the Hacker-Agent section, the packet will easily reach the hacker.
In the case when 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 response from the agent. If you put the data on the card (and my script does so), the administrator instantly eliminates small deviations (usually they are not) and gets a very accurate result: the hacker is at the junction of the blocks received / not received an answer.
All 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;).
“such a host is connected to the switch located here” I will
immediately stipulate the input conditions:
- I am an administrator, that is, I know the network topology;
- I have a database of subscribers whose connection points are known to me.
Violations of the network topology, as well as fraud by subscribers (ip exchange, change of connection point) to some extent reduce the accuracy of the result. However, I regularly use this algorithm on my network and it shows fairly accurate data.
What is the difficulty?
An 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 unmanaged switch is a transparent device; it does not change frames in any way, it only directs them to the necessary ports (in his opinion).
Thus, we can not get information about the path 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, each unmanaged switch has a mac-port mapping table. This table is updated by each incoming frame according to a very simple algorithm: which port the frame came to, the mac address from the src-mac field of the current frame is bound to that port. In the future, any incoming frame with dst-mac like the current one will be sent strictly to the port associated with this mac.
In the process, the mac address table may change if a frame with exactly the same src-mac enters a different port. In this case, the old information is “forgotten”. Typically, this situation occurs when you reconnect the cables. The detection algorithm is based on this “feature”.
I will not drag out the theory and bring it.
So. We have an uncontrollable garland of switches (the harsh reality of small home networks), we select one of the branches. At the end of this thread, select any subscriber. I call him an agent. It plays a key role - the search for an unknown host (in scripts I call it hacker) will occur on the server-agent site. Thus, it is desirable to select the most remote subscriber as an agent.
The iteration begins:
1) Arp-requests request the ip of the agent and the ip of the hacker. Ip can be in different logical subnets, for us it doesn’t matter. The important thing is
that we “translate” the network into its normal state by arp-requests, since in the future we will destabilize it a bit.
2) We take from the base of any subscriber, the location that we know. I call him user. We carry out 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 “ reprogram "ports (change the table of MAC addresses) in the chain of switches from the server to user with the hacker poppy. If someone sends a packet to the hacker's MAC on the network in the “reprogrammed” section, it will be received by our server, and not by the hacker.
3) Arp-request is sent to the agent:
src-mac - hacker mac
src-ip - it doesn’t matter (you can use hacker or fake ip, it is important that agent’s subnet is used)
dst-mac - agent mac
dst-ip - agent ip
With this package, we force the agent to respond to the arp-request, which allegedly came from a hacker.
A very important point to note: protocol encapsulation. The fact is that an 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 in the arp packet, that in the ethernet frame are the same. Unlike the previous package, we need to implement 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, then the switches through which the frame passes will not change their MAC address tables.
4) On the server, we switch to promiscuous mode (that is, we do not discard packets that go to us, but not to our address) and monitor arp-reply.
If:
a) we get a packet directed to hacker mac - it means geographically hacker is between user and server
b) we don’t get - probably hacker is behind user
In the 2nd case there is no absolute guarantee, therefore it is necessary to repeat all points several times to increase the probability, and also take into account data when testing on other subscribers.
In the figure we have a chain of 4 switches. The red line indicates the path of the packet in step 2. As a result, the table “reprograms” the pop-up table of the switch closest to the server so that it thinks “the hacker is connected to port No. 1”. No other switches will change their state because the packet will not pass through them.
After the server -> agent request (point 3), the latter sends a response to the hacker’s poppy because src-mac has been superseded. Since all switches did not change their state on the Hacker-Agent section, the packet will easily reach the hacker.
In the case when 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 response from the agent. If you put the data on the card (and my script does so), the administrator instantly eliminates small deviations (usually they are not) and gets a very accurate result: the hacker is at the junction of the blocks received / not received an answer.
All 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;).