alert tcp $EXTERNAL_NET any -> $HOME_NET
[25,443,465,636,992,993,995,2484] (msg:"SERVER-OTHER OpenSSL SSLv3
heartbeat read overrun attempt"; flow:to_server,established;
content:"|18 03 00|"; depth:3; detection_filter:track by_src, count 3,
seconds 1; metadata:policy balanced-ips drop, policy security-ips drop,
ruleset community, service ssl; reference:cve,2014-0160;
classtype:attempted-recon; sid:30510; rev:5;)
When you perform inline detection within electrical SCADA networks, latency is a big issue. That means you need to fully optimize the amount of checks so latency does not increase more than 3 ms. We also need to include other threats that could materialize from other threats different to malware, exploits and buffer overflows. I will detail in this diary some specific SCADA protocol packets that could be malicious traffic and cause terrible consecuences to the process infrastructure. Today I will detail malicious packets from DNP3 protocol.
The following text details DNP3 packet structure:
Source: Practical Industrial Data Communications
- Start: This is the starting delimiter of the DNP3 datalink layer. It is always set to 0x564
- Length: This is the number of bytes for user data inside the DNP3 packet, plus 5 and does not count CRC bytes.
- Control: This is the DNP3 Frame Control Byte, which provides control of data flow between the master and slave over the physical link. It identifies the type of the message and the flow direction for the communication.
- Destination: DNP3 outstations are identified by a two-byte address. These two bytes are the little-endian representation for the outstation destination address .
- Source: These two bytes are the little-endian representation for the outstation source address
- CRC: Little-endian representation of the CRC-16 DNP3. This is calculated for each block and placed in the end of it.
- Transport control: This DNP3 Frame Control Byte provides control of data flow between the master and slave in the transport level.
- Userdata for block n:
- Application Layer: Control byte: Duplicates the control byte in the transport control field.
- Application layer: Function code: Defines the function being invocated by the packet
- Application layer: structures: Defines the structures being written or queried.
- CRC: Little-endian representation of the CRC-16 DNP3 for block n user data.
1. DNP3 Warm Restart: When this packet is received by the outstation and recognize that it comes from the master, it performs a partial restart on completition of the communications sequence. If this packet is received several times per second, the IED will experiment a denial of service and won't be able to perform actions to the industrial process, send events to the HMI or receive commands from the HMI. A typical DNP3 Warm Restart packet looks like the following:
The following filters recognize these packets:
- Wireshark:
dnp3.al.func==14
- Snort:
alert tcp $DNP3_CLIENT any -> $DNP3_SERVER $DNP3_PORTS (flow:from_client,established; content:"|0E|"; offset:12; depth:1; msg:"SCADA_IDS: DNP3 Warm Restart From Authorized Client"; classtype:attempted-dos; sid:1111112; rev:1; priority:2;)
- Wireshark:
dnp3.al.func==13
- Snort:
alert tcp $DNP3_CLIENT any -> $DNP3_SERVER $DNP3_PORTS (flow:from_client,established; content:"|0D|"; offset:12; depth:1; msg:"SCADA_IDS: DNP3 Cold Restart From Authorized Client"; classtype:attempted-dos; sid:1111112; rev:1; priority:2;)
Wireshark can't fully filter this packets so the following tcpdump filter is provided: ip[52]=2 and ip[53]=0x32 and ip[54]=1
SCADA Information Security is different from the regular IT information security practices. We need to cover the specific vectors to improve the security level of the associated industrial process.
No comments:
Post a Comment