sphinx-project.eu / Blog  / SPHINX Attack and Behaviour Simulators: PART II Capturing Network Traffic

SPHINX Attack and Behaviour Simulators: PART II Capturing Network Traffic

One of the core functionalities of the ABS component of SPHINX Toolkit is to produce a simulation of network traffic of a system and deliver user behaviour analysis. In order to simulate traffic in the first place, it is essential that the component is able to capture real traffic produced inside real network infrastructures. Hence the SPHINX ABS component follows specific technical methodological steps to conduct network traffic capturing processes inside the infrastructure provided by pilot partners, who ensure data anonymisation and privacy aligned with the legal prerequisites followed by the project.

The sample pilot infrastructure that is utilised to capture network traffic is inspired by DYPE5’s real hospital network infrastructure as the NTUA team visited their premises in the City of Larissa, during February 2020. The team inspected some of the basic components of the network there while they also interacted with the technical staff of the hospital in order to obtain a first view of the architecture of hospital networking infrastructure. The diagram below depicts an indicative example view of the DYPE5 network infrastructure. The Syzefxis node refers to the National Network of Public Administration which offers to Greek public sector entities efficient interconnection to the Internet, firewall services and lastly access to high-quality web services.

Traffic Sniffing from Pilot Networks

The network traffic capturing tool used in the case of SPHINX Pilot is Wireshark. Wireshark is an open-source packet sniffer and analyser, running on most UNIX-like and Windows platforms.

Based on the example of the infrastructure of SPHINX’s pilot case, there are two scenarios that should be taken into account to capture traffic from a subnet:

  1. The subnet contains a proxy server or firewall through which all the traffic is flowing. In this case Wireshark can be installed on this server. After starting Wireshark, the network interface that receives the network traffic has to be selected. Wireshark will automatically capture from the interface. To save the PCAP file, the capturing has to be stopped and the menu option File->Save has to be selected.
  2. The subnet contains a switch with a port analyzer. Using the example in Figure 8, to capture traffic directly from the switch, SPAN has to be configured as described in the respective Cisco guide. A computer with Wireshark installed is connected to SPAN in order to capture the mirrored traffic, following the same principle as in scenario a).

One important issue to consider is that, for high volume network traffic, the PCAP file will become large. To manage this situation, the PCAP file should be rotated every GB or hour, depending on preferences. This can be done from Wireshark->Capture->Options->Output->Check Create a new file automatically.

The equivalent cli command for this capturing is:

tshark –interface enp0s3 –ring-buffer filesize:1048576 -n -w out.pcapng

Flow Metadata Extraction from Captured Traffic

In order to analyse the network traffic, it is not always necessary to have the full packets captured by Wireshark. It is sufficient to have a summarization of the network traffic flows containing relevant features (ie flow start date, duration, protocol, source and destination IP and port, number of bytes etc.). This can be realized using protocols like NetFlow, IPFIX, sampled NetFlow, sFlow etc.

Continuing the example above, in order to configure NetFlow on Cisco switch, the relevant Cisco guide should be used:

Netflow does not capture whole traffic as PCAP but only specified “what and where” query.

In order to manually extract NetFlow information from the pcap file there a few possible approaches.

  1. Create a virtual replica of the real network. The virtual network should contain an OpenvSwitch instance. Open vSwitch hat has support for exporting NetFlow, sFlow, IPFIX etc. The traffic is then replayed and NetFlow information is extracted from the virtual switch.
  2. Use the netflow exporter CicFlowMeter
  3. Use the netflow exporter NProbe, which supports NetFlow v9 and also includes layer 7 protocols.

More information about the network traffic capturing of SPHINX ABS component can be found in Deliverable 5.4 that is publicly available here.