Wiretap with Wireshark

Step 1: Providing the infrastructure to reach the data we want to monitor

Since the Integrated Communication System and all IP communication systems work on the network, in order to monitor the network traffic, you must either have access to the system we will monitor or you must be able to listen on the switch to which the relevant system is connected.


For this listening process; You need to *mirror a port on the smart switch*through which the conversation passes to the port your computer is connected to. Then you can start Wireshark and listen, as I have shown above using Wireshark. There is one more important thing to be aware of here. If you mirror the switch traffic in this way, but you cannot listen to the network traffic (often used in "sniff"), check if the Capture all in promiscous mode option is selected in the Capture Options section of Wireshark. This parameter must be selected in order to see the traffic of other Ethernet cards.


Step 2: Capturing a phone call in Wireshark

Wireshark can now be started after setting the network side. When the call is made after that, if there is no problem in the configuration, the call should be visible in the logs. I'm launching a software-based phone application (Karel YT500) on my own computer to make it easier to do, and the application is automatically enrolling SIP communications. With the software based phone application YT500, communication such as phone call, instant messaging, video call, video conference, audio conference is possible. I use this conversation to make a phone call different from what you will technically make with an IP phone.

Actually, Wireshark could also be used to detect problems in the registration phase of this app / IP phone, but in order not to go too far from the article, I will only show you a review of one call (conversation) in this article.


It's like the interface of a software based phone application. I'm launching my other other Wireshark to monitor Ethernet traffic.



We dial the number to call from the phone application and bring up the call:


These blue packets flowing during the call are seen because they are detected with RTP protocol wireshark and are automatically colored with blue. It is the protocol by which RTP voice packets are carried. In our information section, G.711 PCMU contains codec information to which voice packets are transported. The G.711 codec does not perform any action on voice packets. Therefore CPU / DSP usage is very low and very easy to listen to (that's why I conducted the conversation with this codec).
Since I do not use any encryption during communication, we will be able to transfer calls.
Once the meeting is complete, we stop Wireshark to start the analysis:



Information that the meeting has ended, also that the blue packets are no longer flowing. Now we have caught the phone call.

Step 3: Analysis of SIP IP Phone Call

Now we can move on to the analysis by hand interview. First of all, I type sip in the Filter section and press Enter to see if we are capturing the SIP traffic:

Interpreted SIP messages have been intercepted. Wireshark UDP displays SIP messages in Blue.

From the top INVITE sip: 100ucap.karel.com.tr line, we can see that a call has been initiated to the number 100 from the IP address 192.168.76.133. If we right the Session Initiation Protocol section in the bottom window and click Expand All, we can see all kinds of detailed information about this message on wireshark. Generally, these sections need to be examined in detail to solve the problem.
I would like to share some basic information about this priority SIP with you. We need to see how a seamless call works with priority SIP for call sample retrieval.
To analyze the call, let's remove the SIP filter we just made on Wireshark and press Enter again. Then let's write Phone Calls together with VoIP Calls.



In this menu, Wireshark shows us its abilities and automatically detects and reveals the phone calls in the packages caught to us:


All we have to do is to learn that we will watch and click on the options we want to do.
Only one call was found, if there were more calls in the captured packets, we would see the thief one after the other. I can see who initiated the call from the From section (from Onur Erisgen's number 6143), and from the To section, I can see the dialed number (that is, 100 was called). After I select the call, I first want to show the operation of the Stream derived context call:



Flow option shows us the flow of the call very clearly. So that we can see the call clean in this way

INVITATION: It is the type of message used for the call (Used for other purposes, this is off topic). The number to which a call is attempted is displayed on the right-hand side. The SDP is the part in which the sender specifies which audio codecs it supports, from which IP address / port it will send audio (ie RTP) packets.

100 Tries: It is the message indicating that the other party has received the Invite message and started the process.

407 Proxy Verification Required:Indicates that the other party does not allow calls without authentication. The initiator of the call must initiate the call again with the key received with this message, the SIP password, MD5 and an Invite message containing it.

ACK:The initiating the call confirms this request with ACK message.

INVITATION: A new call with a SIP password is restarted with the same information.

100 Attempting: The other party is notified with the message 100 Trying that the transaction has been started regarding this message.

200 OK:The information that the other party has answered the call is indicated to the person who initiated the call. The content of this message also includes an SDP section. SDP specifies with which codec the call is made (according to the first incoming SDP, this and the common codec are shown) and from which IP address / port the call will be made.
Note: The place we were looking for was an announcement number, if there was an IP phone on the other side, 180 before the 200 OK message
The ringing message would come. So the caller would hear the ringing tone

RTP (g711U): Voice packets with g711u codec starts to be sent to the remote (from 192.168.124.124) to the originating party.

ACK: When the other party sends the ACK message, it indicates that the invitation is ready. Some systems will not initiate the call without this ACK message. Others, on the other hand, do not receive an ACK message, but find a problem after a while and end the call.

RTP (g711U): Voice packets from 192.168.76.133 IP address started to be sent with the g711U codec Sometimes a faulty codec is seen or it can be seen that voice packets are sent to a different IP address. Solving these issues solves the problem.

BYE: 192.168.76.133 IP address is ending the conversation. Sometimes calls can be cut off on their own. We can solve this type of conversation by taking a log as in the log.

200 OK: The other party states that the call has been terminated and has performed the transaction.

Step 4: Listening to the Interview
Problems are often solved by analyzing a SIP call. However, sometimes we may encounter problems with sound quality. Wireshark can also be used to listen to this conversation.
Now for this process, I close the Flow window and click on the VoIP Calls window due to Player.

Then I click the Decode button in the window that appears and Wireshark decodes the sound packs as follows.



Here, when we select both aspects and play, we can listen to the conversation on our computer and examine whether there is a problem with the outgoing audio.



Step 5: Prevent interception and monitoring of calls:

The applications I explained this outfit; When detecting, troubleshooting software in good faith.

Communication in your organization, for some reason, technically prevent the realization of these applications, your communication system and its related components should be able to support this.

SRTP support is also available to prevent audio packets from listening on the network. Thanks to SRTP, voice packets carried in the network traffic will be encrypted and interception connections will not be possible.

Again, another feature of the UCAP system is that; Unlike many system communications, voice packets in a conversation between two IP phones or between an external line and an IP phone cannot pass through the server. Thus, even a person infiltrating the server will not be able to listen to the voice packets.
Finally, I want to add one more:

Even if SRTP is not used, you may not be able to directly listen to compressed or HD calls as described. It is actually still possible to listen to such conversations. All that is required is; The relevant codec may have been developed to be played via Wireshark or another application.
So

This Is a very HQ tutorial. I didn't think most of It was possible.

Did you write It yourself?