Port scans can be a sign of many attacks. A port scan is used to collect information about the scanned ports. For example, consider a SYN scan in which a TCP packet with SYN flag set is sent to the destination host. If the port at the destination is open, it will respond with either a SYN-ACK packet (if it is accepting the connection) or a RST packet (if it denies the connection). If the port is closed, it will respond with an ICMP packet indicating the port is unreachable. Usually, if botnet zombies are installed stealthily on a system, their communications may generate a port scan.
TCP communication is controlled by flag state. Therefore, a sniffer module is required to collect the network traffic. This traffic is then filtered to identify the TCP packets. The system extracts each type of flag state for each packet and aggregates the number of each packet type for each flow count in each time window period. Then features are extracted for each flow from each flow state aggregate. The number of flows generated in each time window varies, depending on the number of connections made and the duration of the time window [48, 95, 142]..
The number of flows generated in each time period can be very large and difficult to represent in real time using visualisation techniques. Sonification has the potential to offer real-time traffic representation. The sounds produced are based on events derived from the flow features and can potentially enable the operator to recognise changes in the traffic behaviours. An initial set of flow features was chosen to create events, and these events are represented by different sounds in a soundscape. As traffic passes through the network the soundscape changes in response.
Ohsita et al [115] classified TCP flows into five groups as shown in Table 4.1. This classification assists with the design of events based on traffic features. Table 4.2 shows the result of their experiment of traffic classification where they used the traffic generated by the internet in their campus network for five days period [115]. The experiment supports our intention to monitor TCP/IP traffic.
Soniya and Wiscy [142] used packet counts and neural networks for detecting SYN scans. Detection relied on the three-way handshake mechanism for establishing and termination of the connection. The experiment was based on detecting a TCP SYN port scan on a single machine. Information in the TCP flags was used to define the behaviour of a legitimate connection. Any deviation from the defined normal behaviour (which was used to train to a neural network) is used to detect the scan attack. The experiment tracked various flag counts in both directions as follows:
60 SoNSTAR
Table 4.1 TCP flows classification [115]
Group Description of flows
Group N Flows that completed the 3-way handshake and were closed normally by a FIN or RST packet at the end of the connection.
Group Rs Flows terminated by a RST packet before a SYN/ACK packet was received from the destination host. These flows were terminated this way because the destination host was not available for the service specified in the SYN request. Group Ra Flows terminated by a RST packet before an ACK packet for the SYN/ACK packet was received. These flows were terminated this way because the SYN/ACK packets were sent to a host that was not on the Internet.
Group Ts Flows containing only SYN packets. These flows are not terminated explicitly (i.e., by RST/FIN packets) but by a timeout. There were three reasons that flows could be classified into this group. One was that the destination node did not respond with a SYN packet. A second was that the source address of the SYN packet was spoofed and the destination sent the SYN/ACK packet to the spoofed address. The third was that all of the SYN/ACK packets were discarded by the network (e.g., because of network congestion).
Group Ta Flows containing only SYN and its SYN/ACK packets. Like Group Ts flows, these flows were terminated by a timeout. In this case, however, it was because all the ACK packets were dropped.
Table 4.2 TCP classification of flows [115]
Group Number of flows Percentage Group N 18,147,469 85.1 Group Rs 622,976 2.9
Group Ra 75,432 0.3
Group Ts 2,435,228 11.4
4.4 SoNSTAR Requirements and Design 61
• C1 is the count of incoming SYN packets. • C2 is the count of outgoing SYN-ACK packets. • C3 is the count of outgoing RST packets. • C4 is the count of outgoing SYN packets. • C5 is the count of incoming SYN-ACK packets. • C6 is the count of outgoing FIN packets.
• C7 is the count of incoming FIN packets.
SoNSTAR system has been developed to represent the behaviour of flows in network traffic at the end of a specific time window. The system collects the packet counts for each flag type for each flow during the time window. One of the contributions is the creation of a new type of traffic flow, called “IP flow” to represent the network connections based on the packet counts and the number of flows. An IP flow is identified by collecting the packet counts based on on the flag types of all the traffic between two hosts.