1. “OT systems are isolated (air-gapped) from IT or the internet.”
   Reality: Modern OT is often connected to corporate networks for monitoring and remote access,
   making them reachable by attackers.
2. “Legacy OT systems can’t be hacked.”
   Reality: Older PLCs/RTUs lack authentication and encryption, making them vulnerable even
   if not originally designed for online use.
3. “Availability is the only thing that matters.”
   Reality: Integrity (correct process control) and confidentiality (e.g., recipe data) are also
   critical. Attacks can cause unsafe conditions even when systems stay “up.”
4. “Standard IT security tools will protect OT just fine.”
   Reality: Traditional antivirus and patching can break fragile OT systems or require downtime
   plants can’t afford; OT needs tailored security measures.
5. “Physical security = cybersecurity.”
   Reality: Remote exploits via vendor VPNs, phishing, or infected maintenance laptops can bypass
   physical barriers.
6. “Once you set up firewalls, you’re safe.”
   Reality: Misconfigurations, shared credentials, and unmonitored conduits can let attacks pass;
   security needs monitoring, detection, and layered defenses.

UDP flood attacks exploit the lack of connection control in the User Datagram Protocol. Unlike TCP, UDP doesn’t manage sessions, track connections, or limit traffic. Attackers take advantage by sending large numbers of UDP packets to various ports on a target.

If no application listens on a given port, the system often replies with an ICMP “Destination Unreachable” message. These replies consume bandwidth and processing power. Attackers also spoof source IP addresses to hide their identity and misdirect response traffic.

UDP floods resemble sudden spikes in legitimate traffic, but the cause differs. DDoS attacks are intentional and hostile, while user surges are natural. Many modern attacks also use amplification. An attacker sends small UDP requests to servers like DNS, NTP, or memcached, using the victim’s IP. The servers respond with much larger messages to the victim, greatly increasing the impact.

One major case was the 2018 attack on GitHub using memcached servers, which hit 1.3 Tbps. Even without amplification, a UDP flood can saturate a target if the upstream network pushes more traffic than the target can absorb.

Key Packet Indicators:

UDP floods involve a high rate of UDP packets aimed at one or many ports on a target. These packets have an IP protocol value of 17 (ip.proto==17) and no flags, unlike TCP. Attackers often target either known service ports to overload them or random ports to trigger ICMP “destination unreachable” replies. They usually spoof or randomize the source IP and port. In basic floods, the payload carries junk or is nearly empty, since the goal is volume. An important sign is an unusual spike in UDP traffic, especially if the system usually handles mostly TCP. A web server that typically sees 95% TCP traffic showing a jump in UDP, especially to odd ports, should raise concern. A related sign is a surge of ICMP Type 3 messages going out from the victim to spoofed sources. Monitoring tools should track UDP packet rates and bandwidth. A sharp rise above normal levels often signals a flood. If many destination ports on the target are hit rapidly, it may look like a scan but is more likely an attack meant to drain resources. Normal UDP traffic follows known patterns tied to services like DNS (port 53) or VoIP. It usually includes a clear request and response. UDP flood traffic, by contrast, is random or targets ports that cause heavy load. It often doesn’t expect a reply. Amplified floods, like DNS-based ones, use small queries to trigger large responses from third-party servers. This results in large UDP packets hitting the victim, often marked with a source port of 53. A pattern of high UDP volume, frequent ICMP “port unreachable” replies, or broad port targeting points strongly to a flood attack.

Wireshark:

Relationships are like CSVs—one wrong delimiter, and it all breaks.

CSV stands for Comma-Separated Values. It’s a plain text format that stores tables. Each line holds one record, and fields within a record are split by commas. Many programs use CSV files because they’re easy to create, read, and move between systems. To work with CSV data from the command line, especially for filtering and analyzing, csvkit is a useful tool. Down are easy commands for basic CSV file EDA:

Step 1: Install or upgrade csvkit (in windows 11)

pip install --upgrade csvkit

Step 2: Extract rows where the “Attack_type” column contains “Normal”

csvgrep -c "Attack_type" -r "Normal" data.csv > normal_rows.csv

Step 3: View structure and summary stats of the filtered file

csvstat ransomware_rows.csv

Step 4: Check for missing or summary stats in the “dns.qry.name.len” column (same as step 3 but here for specific column)

csvstat -c "dns.qry.name.len" normal_rows.csv

Step 5: See frequency distribution for “dns.qry.name.len”

csvcut -c "dns.qry.name.len" normal_rows.csv | csvstat --freq

In IT network traffic, granularity refers to the level of detail at which network data is capturered or monitored.

High Granularity (packet-level):
Tracks network traffic at the packet level. Shows details for each connection and short-term changes. Helps with precise monitoring and troubleshooting. Needs more storage and processing power.

Datasets examples:

Low Granularity (flow-level):
Groups traffic data over longer periods. Shows general patterns and long-term trends. Misses specific events but helps spot broader shifts in behavior.

Datasets examples:

My TCP relationship status? It’s complicated, SYN but no ACK!!

TCP SYN Flood Attack exploits the fundamental weakness in TCP’s three-way handshake mechanism. During normal TCP connection establishment, a client sends a SYN packet, the server responds with SYN-ACK, and the client completes the handshake with an ACK. The server maintains connection state in a backlog queue during this process.

In a SYN flood, which is a type of volumetric DDoS attack, the attackers send a large number of SYN packets with fake source IP addresses. These spoofed packets prevent the server’s SYN-ACK replies from reaching a real client, leaving many half-open connections. The server reserves memory and processing power for each attempt, quickly filling its connection queue.

Once the queue is full, new legitimate requests can’t get through, blocking access. The attack is efficient because it takes little effort to send spoofed SYNs, but the server has to commit real resources for each one. The method exploits TCP’s stateful design, where a server must track each incoming connection. Unlike bandwidth attacks, this one overwhelms the server’s ability to manage new connections.

Key Packet Indicators:

As mentioned above, in a SYN flood, the attacker sends a large number of TCP SYN packets, which are normally used to start a connection, but never completes the handshake. These packets often have fake or inconsistent source IP addresses and ports. The destination port is usually an open service port, like TCP port 80 on a web server, because open ports force the server to allocate resources for each request.

Normal TCP connections use a three-way handshake: SYN, SYN-ACK, and ACK. But in a SYN flood, most packets are SYNs without matching ACKs. The server replies with SYN-ACKs, then waits. Its backlog of half-open connections fills up quickly. Packet captures show many SYNs, lots of SYN-ACKs, and few or no final ACKs. On the server, many connections remain in the SYN_RECV state, visible with tools like netstat.

Since the SYNs often use spoofed IPs, filtering by source is hard. These packets might have odd TTL values or uncommon IP options, but that’s not always the case. The TCP headers may also contain abnormal values, like a sequence number of 0, but this varies.

The main indicator is the skewed traffic pattern: a flood of SYNs with few ACKs or RSTs in return. In normal traffic, SYNs make up a small share. In a SYN flood, they dominate. You might also see some RST packets, often from real IP owners reacting to unexpected SYN-ACKs.

TCP flag analysis helps too. A stream of packets with only the SYN flag and no matching ACK or RST from the client side stands out. Some real clients abort incomplete connections with RST, but spoofed IPs often trigger stray RSTs instead.

This lopsided SYN-to-ACK ratio and the lack of full handshakes are the core signs of a SYN flood.

Wireshark:

• To find all SYNs without ACK: tcp.flags.syn==1 and tcp.flags.ack==0
•  Statistics → Conversations → TCP → Sort by “Packets”

KDD99:

1. Granularity
2. Size (samples/flows/records)
3. Feature Set
4. Volume (Time Span)
5. Attack Taxonomy & Coverage
6. Represenation
7. Class Distribution
8. License
9. Data Collection Method
10. Temporal Splits & Benchmarking Support
11. Relevance & Currency
12. Labeled

UNSW-NB15 Dataset:

1. Granularity
2. Size (samples/flows/records)
3. Feature Set
4. Volume (Time Span)
5. Attack Taxonomy & Coverage
6. Represenation
7. Class Distribution
8. License
9. Data Collection Method
10. Temporal Splits & Benchmarking Support
11. Relevance & Currency
12. Labeled

CICIDS2017:

1. Granularity
2. Size (samples/flows/records)
3. Feature Set
4. Volume (Time Span)
5. Attack Taxonomy & Coverage
6. Represenation
7. Class Distribution
8. License
9. Data Collection Method
10. Temporal Splits & Benchmarking Support
11. Relevance & Currency
12. Labeled

CSEIDS2018:

1. Granularity
2. Size (samples/flows/records)
3. Feature Set
4. Volume (Time Span)
5. Attack Taxonomy & Coverage
6. Represenation
7. Class Distribution
8. License
9. Data Collection Method
10. Temporal Splits & Benchmarking Support
11. Relevance & Currency
12. Labeled

CICDDoS2019:

1. Granularity
2. Size (samples/flows/records)
3. Feature Set
4. Volume (Time Span)
5. Attack Taxonomy & Coverage
6. Represenation
7. Class Distribution
8. License
9. Data Collection Method
10. Temporal Splits & Benchmarking Support
11. Relevance & Currency
12. Labeled

Edge-IIoT:

& Data Type, Size & Volume, Attack Taxonomy & Coverage, Feature Set & Representation, Class Distribution & Imbalance, Data Collection Method / Source / Operational Context, Temporal Splits & Benchmarking Support, Relevance & Currency

1. Granularity
2. Size (samples/flows/records)
3. Feature Set
4. Volume (Time Span)
5. Attack Taxonomy & Coverage
6. Represenation
7. Class Distribution
8. License
9. Data Collection Method
10. Temporal Splits & Benchmarking Support
11. Relevance & Currency
12. Labeled

 “I support freedom of expression, no matter whose, so I oppose DDoS attacks regardless of their target… they’re the poison gas of cyberspace.”
– John Perry Barlow

Definitions:

A Denial-of-Service (DoS) attack is a malicious attempt to disrupt the availability of a service or resource by overwhelming it with illegitimate traffic or requests, typically from a single source. In a classic DoS scenario, one host (or a single attacker) sends a flood of packets or exploits a vulnerability to exhaust the target’s network bandwidth, CPU, memory, or other resources, thereby denying service to legitimate users.

Distributed Denial-of-Service (DDoS) attack is essentially a large-scale DoS attack launched simultaneously from multiple compromised machines (hence “distributed”) to overwhelm the target. In a DDoS, an attacker typically controls a network of zombie hosts (a botnet) which collectively send traffic or requests to the victim, amplifying the attack power far beyond a single machine’s capacity.

Differences:

1. Number of Attack Sources: A DoS attack comes from one host or a small group under one attacker’s control. A DDoS attack involves many distributed sources, often hundreds or thousands, acting together.
2. Scale and Impact: DDoS attacks generate much more traffic than a DoS. They can overwhelm high-bandwidth connections and large server clusters.
3. Attack Complexity: DDoS attacks often use several tactics at once. Attackers first infect devices with malware to build a botnet. Then they control these bots through command servers and launch a coordinated attack.
4. Attribution and Evasion: DDoS traffic comes from many unrelated IPs. These are often spoofed or from infected devices like IoT gadgets and servers. This makes traceback hard. DoS attacks are easier to trace and block, though attackers may still spoof their IPs or use anonymity networks. Some DDoS attackers rent botnets through “booter” services.
5. Mitigation Difficulty: A DoS attack may be stopped by blocking one IP. A DDoS attack is harder to stop. It requires advanced tools to filter traffic from many sources. These include DDoS protection systems, scrubbing centers, or content delivery networks. Smarter tools like traffic anomaly detection or challenge-response checks help separate attack traffic from real users.

Common DoS and DDoS Attacks:

Over the years, attackers have developed numerous tools to automate DoS and DDoS attacks. These range from simple single-host scripts to complex distributed botnet frameworks. Table 1 summarizes some well-known attacks, the typical OSI layer or protocol they target, and a brief description: