Introduction
In recent years we have seen a shift from traditional network protection systems and software installed on network stations and servers, to artificial intelligence-based network protection systems that monitor the network traffic, and by identifying behavioral patterns of network traffic, we locate and block problematic endpoints. In this article, I will briefly explain some common anomality’s and how to identify them, along with some examples and demonstrations.
Proper behavior of network applications
As we all know, there are many applications that work on the network – office applications, databases, web browsing, phone calls and video calls, and more. These applications send information over the network, and the form of information transfer has a certain pattern. These patterns include things like:
- Packet sizes and traffic direction, transport protocols – UDP, TCP, or QUIC/GQUIC
- Interactivity, that is how interactive the information is, i.e., whether the traffic is similar in both directions.
- The information structure, i.e., whether what goes through the packets is really supposed to be there.
- How many requests are sent to the server and how many are answered?
- Should the traffic really be there, is the traffic reasonable, are we familiar with it is IP addresses and TCP/UDP port numbers, and so on.
Let us look at some examples, starting with the simple and clear ones moving to the more complex (and interesting…) examples.
First example – HTTP/HTTPs traffic
In normal web browsing, we will see the following traffic:
- TCP Connection establishment, that is Syn, SYN-ACK, and ACK that establish the TCP connection.
- In the case of HTTPs, which is HTTP encrypted with SSL/TLS, there will be several smaller packets to establish the SSL/TLS encryption.
- Usually, we will see an HTTP GET request, and then, as we see in the next figure, a pattern of several large packets from the server down to the client, TCP ACK back from the client to the server, and so on.
In the next figure, we see the traffic when browsing an unencrypted HTTP site.
In both examples we see similar traffic patterns – session establishment and then data transfer, that is large packets of 1506 Bytes in the first example and 1414 Bytes in the second, both in the client direction.
Second example – DNS traffic
Domain Name Service, DNS, is a protocol where we send DNS Query asking for the IP address of a particular website, and we get a response with the address or multiple addresses of the website. In the following screenshot, we see an example.
You can see here several patterns – small packets in the queries (70-80Bytes), medium-size packets in the responses (around 500Bytes), queries and responses to the queries (no refuses for example), and then down to the right we see a large percentage of the DNS packets – 2.5% from the total number of packets.
Third example – Databases traffic
In databases, as seen in the following screenshot, we see the establishment of a TCP connection, and then highly interactive traffic between the Client (192.168.20.88) and Server (192.168.10.80). We also see small to medium packet sizes (up to several hundred bytes), and when there are no glitches (as in Packet number 14 which took the server 19 seconds to respond ..) the time between packets will be relatively small.
Forth example – Email traffic
Email traffic is mail messages in the download or upload direction, so what we will see are large packets, sent in the upload or the download direction. In the case of multiple messages, we will see “peaky” traffic. In the next figure, we see an example of email traffic.
What to look for – abnormal traffic behavior and how it looks like
Now that we have seen proper work patterns, let us see how we identify when there is a problem. First by looking at traffic changes, and then, looking in packets content.
Before looking for anomality’s, it is important to be familiar with the network structure – who the servers are, who works with them, what are the applications, and so on. Usually, we see standard things: browsing in TCP Ports 80/8080/443, emails in TCP Ports 25/110, working with Microsoft file sharing and other network protocols in TCP/UDP Ports 137/138/139/445, network protocols like RSTP for streaming applications, OSPF for routing, working with Google Cloud with QUIC/GQUIC, IP phones/video calls in SIP/RTP and so on.
What to look for? Let us start with the simple things. We will use the Protocols Hierarchy under the Statistics menu in Wireshark and see what goes on in the network. Do not forget – what you see is at the point where data was captured.
In the screenshot above we see standard protocols – STP, Nortel Discovery Protocol, many NetBIOS protocols and packets, HTTP, and so on. What is worth checking out are the Dropbox packets and whether they are in the organization’s policy to allow connectivity to Dropbox.
Another type of suspicious traffic pattern is scanning of various types. In the next figure, we see a simple type of TCP port scan. We see that 192.168.1.101 tries to connect to TCP ports on 192.168.1.103. It starts from port 13, 21, 22, 23 and counts up sequentially. When we see 6 packets on every trial, 3 packets from AàB and 3 packets back from bàA, this is usually A sends 3 SYN packets to B, and B blocks them with 3 Resets.
In the next example, we see a Ping (ICMP) scan, in which we see 192.168.110.5 scans the network, starting from 192.170.5.0, 192.170.5.1, and so on. This was a typical worm that scans the network, and the moment someone answers this Ping request, it will be also infected and starts its own scan.
Suspicious work patterns are also a transfer pattern that is unusual for a particular protocol. For example, setting up a Tunnel within DNS, as seen in the following example. In these cases, we usually see DNS Queries with very-large Packets:
Of course, it will be also easy to detect brute-force attacks. in the following example, we see how the attacker tries to guess internal servers at the attacked ISP. In this case, the attacker was filtered and after a few seconds of access to the provider, it was also blocked by ISP protection systems.
In the next example we also see something strange: DNS query with 22,616 questions:
In the next one, we see thousands of emails arriving from unknown servers (in the example we see only a small part of the file).
Summary
We saw some examples of “good” patterns, and we saw some patterns we should suspect. You can find thousands of examples on the Internet, and if you will capture packets in your network you will probably find packets and connections you will have to check where they come from. It is always a good idea to monitor your network and look for things you are not familiar with.
