Skip to content

modbus TCP SCADA #1

Latest
Compare
Choose a tag to compare
@tjcruz-dei tjcruz-dei released this 10 Jan 21:23
· 55 commits to master since this release
027b207

Citation Request

Frazão, I. and Pedro Henriques Abreu and Tiago Cruz and Araújo, H. and Simões, P. , "Denial of Service Attacks: Detecting the frailties of machine learning algorithms in the Classification Process", in 13th International Conference on Critical Information Infrastructures Security (CRITIS 2018), ed. Springer, Kaunas, Lithuania, September 24-26, 2018, Springer series on Security and Cryptology , 2018. DOI: 10.1007/978-3-030-05849-4_19

Description

This dataset was generated on a small-scale process automation scenario using MODBUS/TCP equipment, for research on the application of ML techniques to cybersecurity in Industrial Control Systems. The testbed emulates a CPS process controlled by a SCADA system using the MODBUS/TCP protocol. It consists of a liquid pump simulated by an electric motor controlled by a variable frequency drive (allowing for multiple rotor speeds), which in its turn controlled by a Programmable Logic Controller (PLC). The motor speed is determined by a set of predefined liquid temperature thresholds, whose measurement is provided by a MODBUS Remote Terminal Unit (RTU) device providing a temperature gauge, which is simulated by a potentiometer connected to an Arduino. The PLC communicates horizontally with the RTU, providing insightful knowledge of how this type of communications may have an effect on the overall system. The PLC also communicates with the Human-Machine Interface (HMI) controlling the system.

The testbed diagram is depicted here:
testbed.pdf

Capture list

All the attack use cases provided in the aforementioned URL are organized along three ZIP files:

1- “captures1” contains the captured traces for the following scenarios:

  • nominal state (no attacks, normal testbed operation - folder “clean”)
  • ARP-based, Main-in-the-Middle attack (folder “mitm”)
  • modbus query flooding (folders “modbusQuery*”)
  • ICMP flooding (folder “pingFloodDDoS”)
  • TCP SYN flooding (folder “tcpSYNFloodDDoS”)

2- “captures2” and “captures3” contain the captured traces for the following scenarios, with several attack and capture time spans:

  • Modbus query flooding (folders “modbusQueryFlooding”)
  • ICMP flooding (folder “pingFloodDDoS”)
  • TCP SYN flooding (folder “tcpSYNFloodDDoS”)

File naming criteria

For each file, the naming format is:
<capture interface>dump-<attack>-<attack subtype>-<attack duration>-<capture duration>

For instance:
eth2dump-mitm-change-15m-0,5h_1.pcap refers to a capture on interface eth2 for a MITM attack where data is being changed on-the-fly. This attack was executed during 15 minutes, over a 0.5 hour capture timeframe”

If you need further information or assistance, please contact:
-pha@dei.uc.pt (Pedro Abreu)
-tjcruz@dei.uc.pt (Tiago Cruz)

File Information:

All trace captures are encoded in the PCAP file format, version 2.4 (header bytes “d4 c3 b2 a1”) [2]. The pcap format is open and universally supported by tools such as Wireshark [3] or tcpdump [4]. These tools provide their own packet dissectors (to decode the packet contents).

Also, Kudos for Brian Boosz, from BreakPoint Labs (https://breakpoint-labs.com) for pointing out an issue with the MiTM captures: in the capture1 file, the "read" traces were incorrectly pruned and, thus, devoid of any MiTM evidence.