Security practices have changed significantly in the last decade. It used to be sufficient to set up firewall rules to close the intranet off from the internet. Nowadays, companies rely more and more on cloud services, remote access and peer-to-peer communications. This alone makes maintaining company network much more difficult. Especially, the peer-to-peer software applications are posing significant challenge to a network administrator. In order to be able to exchange packets with the hosts outside as directly as possible they use interesting methods to punch holes in firewalls, which shouldn’t actually be allowing for such communication.
This not only complicates the network administrator’s job, but has significant security implications. One would think that utilizing a SIEM product, it would be easy to write a rule to detect such communication and alert the SOC. We, at Black Stratus, are frequently receiving requests for assistance with such tasks. However, to successfully implement a rule to detect a specific peer-to-peer communication, one must first understand how the communication happens in the first place.
I would like to provide an example of how Skype can successfully establish connection between two hosts, both behind NAT firewalls.Image may be NSFW.
Clik here to view.
Back in 2006, there was an article in Heise Online by Jürgen Schmidt, titled “The hole trick – How Skype & Co. get round firewalls“. This text is based on the explanation provided in that article. I am also borrowing the images from the original piece.
As every network and security professional knows, firewalls usually block all incoming communications except selected, specific ports corresponding to the services allowed. Outgoing traffic is usually allowed, but sometimes also restricted to a range of ports. In addition to that, firewalls must allow packets for the connections already established to go through, both ways. Skype, and other similar software, tricks the firewall to believe that a connection has been established, to which it should allocate subsequent incoming data packets.
It is possible because Skype uses UDP for data transfer, which is a connectionless protocol. In case of TCP, packets include additional connection information, but with UDP, a firewall sees only the addresses and ports of the source and destination systems. Any incoming UDP packet, which matches a NAT table entry, will be passed to the inside of the network. In order to perform this trick, Skype software needs to connect to the Skype server first. It’s done via the outgoing TCP connection. The Skype server therefore knows the IP address of a Skype user that is trying to establish the call. The actual telephone connections do not run via the Skype server, if possible, the clients exchange data directly.
Following the example from the source article, let’s assume that Alice calls Bob over Skype. Skype server knows from the incoming query, that Alice is currently registered at the IP address 1.1.1.1 and checks that her audio data comes from UDP port 1414. The Skype server sends this information to Bob’s Skype client, which, according to its database, is currently registered at the IP address 2.2.2.2 and uses UDP port 2828.
Bob’s Skype program then sends an UDP packet to 1.1.1.1 port 1414. This establishes a hole in Bob’s network firewall. The packet is discarded by Alice’s firewall. However, Bob’s firewall thinks that the connection has been established and anything which comes from 1.1.1.1 port 1414 addressed to Bob’s IP address 2.2.2.2 and port 2828 is the response to the query which has just been sent.
The next step is when the Skype server send the information about Bob to Alice. Her Skype application attempts to contact Bob at 2.2.2.2:2828. Bob’s firewall sees the recognized sender address and passes the apparent response on to Bob’s PC – and his Skype phone rings.
This is a simplified summary of how this process works. For details please refer to the original article. You can see from the above example that writing a correlation rule to detect such traffic is not trivial. Skype uses both TCP connection to a Skype server and UDP connection to the other party to successfully establish the call. Without inspecting the packet contents and relying solely on the router logs, it may not be possible to know for sure that there is a Skype communication occurring.
The post Peer-to-Peer Communication Challenges in the Cloud appeared first on .