logo elektroda
logo elektroda
X
logo elektroda

Passive tap (tap) of fast ethernet - IP "listening in"

TechEkspert 8205 15
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
  • Passive tap (tap) of fast ethernet - IP "listening in"
    Sometimes during deployment, it is necessary to capture network traffic between devices to resolve a problem to remove obstacles. In the case where one of the devices is a computer running software, it is often enough to have Wireshark software installed and check where the problem is. If we want to check the traffic between devices, it is necessary to intercept the transmission from the port of one of the devices.
    In professional solutions, we can use the "port mirroring" function on the switch and we can "copy" traffic from the selected port / ports / vlan to another selected port where we connect the computer, eg with Wireshark software. In this way, we can intercept traffic at the interface speed, i.e. 1Gb / s or more (e.g. 10Gb / s), but at higher speeds there are significant requirements for devices that intercept and analyze the tested network traffic.

    How can we deal in the "field" when we urgently need to examine the traffic between two devices in the LAN and we do not have a managed switch with the "mirror port" function, and we cannot install traffic analysis software on the devices (e.g. it is a router / printer pair / disk array / switch etc.).
    Once a popular way was to use the outdated 10Mb / s hub, nowadays these types of devices are less available and limited bandwidth can be a problem.

    We can use the 100Mb / s (fast Ethernet) passive tap method, which will allow intercepting network traffic between devices. It is a solution beyond all standards, which can even damage the equipment (in extreme cases). You can also "separate" yourself from the tap for greater security, e.g. with a fast Ethernet switch for ~ 40 PLN.
    Use of the solution is at your own risk, but sometimes such a simple "tap" can be useful when troubleshooting network communication problems.

    To prepare the "branch" I used two double 8P8C (RJ45) sockets,
    to begin with, we connect the pins of one socket with the socket in the other module:
    1 - 1 (TX +)
    2 - 2 (TX-)
    3 - 3 (RX +)
    6 - 6 (RX-)
    Passive tap (tap) of fast ethernet - IP "listening in"

    We get an "extension" that can work in the FastEthernet standard.

    Then, in both modules, branch the transmission lines to the second socket. In one socket the transmitting pair (1,2), in the other socket a receiving pair (3,6). The pairs are branched to terminals 3,6 (RX +, RX-).
    1 (TX +) - 3 (RX +)
    2 (TX-) - 6 (RX-)

    3 (RX +) - 3 (RX +)
    6 (RX-) - 6 (RX-)
    Passive tap (tap) of fast ethernet - IP "listening in"

    After closing the sockets, it is worth marking them so that the internal wiring diagram is clear to everyone:
    Passive tap (tap) of fast ethernet - IP "listening in"

    Connect the device to the "Device" socket with a straight cable (patch), e.g. in the EIA / TIA T586B standard,
    connect the existing cable connected to the interface of the device to the "Uplink" socket.

    On Tap sockets we can intercept one-way transmissions "from the device" or "to the device". Connect a straight cable to the "Tap" socket and connect it to the network card in the computer with the Wireshark program installed. ifwe want to intercept the transmission in both directions at the same time, we need two network interfaces on the computer analyzing the traffic.

    Due to the common AUTO MDI-MDIX (connection detection with a straight / patch or crossover / crossover cable), the transmission direction available on the Tap terminals is determined experimentally.
    In my case, the traffic "from device to Uplink" was available on the "Tap" socket next to the "Uplink" socket, while the "Uplnik to device" traffic was available on the "Tap" socket next to the "Device" socket.

    Passive Tap can be used only at your own risk (risk of damage / interference), in home conditions the "tap" may be useful to check the traffic between our home router and the operator's device with an Ethernet interface. You can check what communication is established by the home router and what traffic is coming to the WAN interface from the Internet. Attackers may try to use flaws in the software of cheap routers to build botnets or try, for example, to redirect us to a fake bank website, etc. Checking the router's communication with the Internet can detect anomalies. The device can be useful for education and experimenting with the LAN and for detecting problems with the devices launched (e.g. enc28j60).

    What do you think about such a primitive way to analyze network traffic?
    About Author
    TechEkspert
    Editor
    Offline 
    TechEkspert wrote 6274 posts with rating 4919, helped 16 times. Been with us since 2014 year.
  • ADVERTISEMENT
  • #2 17218663
    rb401
    Level 39  
    TechEkspert wrote:
    What do you think about such a primitive way to analyze network traffic?


    The fact that you showed that it works and this is mainly about (because the hardware itself is trivial) about the overall operation of such a system, i.e. also from the software side, etc., has a great value and it's very nice on your part that you put it here, thanks. And an easy thing to do when needed.
    I even think of a more "compact" concept, ie using the corpse of some broken switch or something similar (as long as it has less than 4 sockets), Cutting the paths, eg with a dremel, and connecting the sockets with wires soldered to them. Then one box, not two, would be handy. But it is still a secondary detail depending on what is at hand at the moment.

    At the moment I am bothering with such a thing, can a Wireshark like this "bind" packets from two network networks to show them as single transmissions in the sense of eg TCP?
  • #3 17218925
    TechEkspert
    Editor
    Can be quite miniaturized, for example, as you write using sockets from damaged equipment,
    you can also use only RJ45 plugs. I used the surface-mounted sockets because they had a full box, and it took a moment to press the wires with a patch knife.

    As for the order of packets in Wireshark, I suspect that in my application the "time" column was sufficient,
    in other cases a packet sequence number may be useful in analyzing a particular link?
  • ADVERTISEMENT
  • #4 17219546
    krru
    Level 33  
    rb401 wrote:

    At the moment I am bothering with such a thing, can a Wireshark like this "bind" packets from two network networks to show them as single transmissions in the sense of eg TCP?


    Since you need a computer with two network cards anyway, you just need to install "bridge" software on it to logically connect network cards with each other and record the transmission through one. No weird adapters will be needed.
  • #5 17219571
    rb401
    Level 39  
    krru wrote:
    Since you need a computer with two network cards anyway, you just need to install "bridge" software on it to logically connect network cards with each other and record the transmission through one. No weird adapters will be needed.


    Also a very nice idea for "wiretapping". But maybe this simple hardware tap can have some advantages in some situations as well. For example, that there is no risk of any interference with packets (some TTL or Ethernet layer addresses etc.) that the bridge and the card crossing can (or possibly must) change. Also, for example, with this hardware solution, only slightly modifying it (by adding a "splitter" on the other side), you can make a double tap-computer monitoring connection with only one cable.

    But your proposal also gave me an indirect concept, whether in this hardware solution presented by my colleague TechEkspert, it would not be possible to connect these network cards with this bridge. Then, by tracking the traffic on one of the cards, you could see all the bugged traffic and have synchronized packets so that you could easily see all connections, eg TCP.
    It is true that the cards would send "nowhere", but it does not matter. But I don't know if and how such a thing would work out in practice.
  • #6 17219625
    Gruby__
    Level 16  
    All in all, this can be slightly reduced. Use a LAN tee like this one:

    Passive tap (tap) of fast ethernet - IP "listening in"

    And build a cable

    Passive tap (tap) of fast ethernet - IP "listening in"
  • #7 17220072
    rb401
    Level 39  
    Gruby__ wrote:


    And build a cable

    Passive tap (tap) of fast ethernet - IP "listening in"


    It's not really about that. Because it's not about splitting, but joining parallel to the line. But your suggestion of using such a tee is not bad.
    Because by properly preparing two such tees, one can make a tap with a transition to two strands of one cable, and from the other, a splitter for these two strands for two cables for two network cards. And it will be very elegant. Admittedly, not in terms of compliance with standards, etc. But what is not done for science.
    And it's important that it works, as shown by the author of this thread.
  • ADVERTISEMENT
  • #8 17220084
    Gruby__
    Level 16  
    But that's what a tee does. Splits the signal into two of the same. So you can connect the source on one side, the receiver on the other and pull the tx and rx out of the third socket using the cable shown in the diagram (for two network card connectors). And then you don't need two tees ;)

    Passive tap (tap) of fast ethernet - IP "listening in"

    EDIT :O of course I mean a RJ45 tee, not a splitter

    Passive tap (tap) of fast ethernet - IP "listening in"
  • #9 17220112
    rb401
    Level 39  
    Gruby__ wrote:
    But that's what a tee does.


    Your diagram suggests something else. But you are right here that such a tee can be used as a tap without any modification, and from it a standard 1: 1 cable can go towards the eavesdropping computer. However, from the computer side, a second tee is necessary to switch from one cable to two and it is necessary to modify it to cut off the transmission direction from the eavesdropping network cards (because it will get chaos) and to enter one of the cards with the RX receiver pins on the second twisted pair than the second card has RX connected.
    So the second "tee" should have a diagram as you originally drew here. A tap is a tee without modification.
    So what you have in the first drawing is ok. And the diagram would apply to the second "tee" (in appearance, because it would not be a tee).
  • #10 17220548
    TechEkspert
    Editor
    I will also mention that to remove some of the problems, it was enough to analyze the packets from one tap sent by the device using a laptop with one network interface and Wireshark.
    On a computer with two network interfaces in Wireshark, it was enough to select both cards, start the capture and that's it,
    we get packages from both tabs in one "window", packages are probably sorted by arrival time and that was sufficient in this case.

    Of course, it is most convenient to use a switch that can be configured to forward packets from selected ports or the entire vlan, with one port we handle the registration of all communication between devices. But you have to have it in place ...
  • ADVERTISEMENT
  • #11 17220581
    rb401
    Level 39  
    TechEkspert wrote:
    On a computer with two network interfaces in Wireshark, it was enough to select both cards, start the capture and that's it,


    And some more questions. How did you configure the IP address of these cards (because DHCP would not be able to find out)? I mean, is it possible to listen to packets from a completely different network (with a different address) than the network of these cards.

    How long did you have tapu cables to these cards, because it is known that in the parameters of wave lines, such an attachment will severely damage them?
  • #12 17220594
    TechEkspert
    Editor
    As for IP, they get APIPA without DHCP, but it is accidentally selected, it is better to configure fixed addresses, and set a filter in Wireshark that cuts out these IP addresses just in case.
    You can set the IP and mask to be in the listening subnet, but it doesn't really matter because we set the cards to promiscuous mode (mixed mode) and we intercept any traffic.

    As for the length, the original cable for the device was about 5m, the cable connecting the splitter with the device is about 3m, while the tap cables are 2x1m. I think that you could "regenerate" the signal with a cheap fast etherent switch for several dozen PLN.
  • #13 17220889
    IS
    Level 18  
    I wonder if cheap switches with little memory can be forced to act as a HUB after flooding with false MAC addresses. They used to be attacked like that.
  • #14 17221099
    vayo
    Level 14  
    krru wrote:
    Since you need a computer with two network cards anyway, you just need to install "bridge" software on it to logically connect network cards with each other and record the transmission through one. No weird adapters will be needed.


    I am of exactly the same opinion. In such cases, I use an additional USB card. I must admit that I was not even aware of the possibility of linking a card with only RX connected. I like the concept itself as a curiosity, but in practice I will not use it.
  • #15 17221994
    TechEkspert
    Editor
    Port mirroring is sometimes used in production, e.g. for recording calls in a callcenter, regardless of the Voip solutions used. RTP packets and signaling go to the recorder which composes the data into the recordings of consultants' calls.

    The data LED is somewhat similar to the described solution. A device that allows one-way communication and galvanic separation. Interestingly, a data diode encased in a suitable proxy allows you to simulate two-way traffic. For example, you can make a system for receiving e-mails, ensuring that no information from the protected system comes back to the sender or the attacker.
  • #16 17228943
    Anonymous
    Anonymous  

Topic summary

The discussion revolves around methods for capturing network traffic between devices, particularly in scenarios where quick troubleshooting is necessary. Users explore various techniques, including the use of Wireshark for packet analysis and the implementation of hardware taps using modified switches or RJ45 plugs. Suggestions include creating a compact tap from damaged equipment, utilizing bridge software on computers with multiple network cards, and employing LAN tees for signal splitting. The conversation also touches on the importance of packet order in analysis, the configuration of network cards, and the potential for using inexpensive switches as hubs. Additionally, the use of port mirroring in production environments, such as call centers, is mentioned, along with the concept of data diodes for one-way communication.
Summary generated by the language model.
ADVERTISEMENT