Security: Threats; Firewalls


Cryptography protects a conversation, but it doesn't decide who is allowed to have one. Today we start on the other half of security: who the adversaries are and what they want, and then the most widely deployed defensive device on the Internet. A firewall is conceptually simple — look at a packet, decide whether it may pass — but the interesting part is how much of the stack you have to understand to write a good rule, and how much you give up if you only look at one packet at a time. We'll also build a working packet filter as a Linux kernel module, which is a good way to see that a firewall is just code sitting in the path a packet already takes.

Slides from class

Files:

Additional information:

Agenda

These notes cover the threat landscape, the four kinds of firewall, building a packet filter with Netfilter and loadable kernel modules, using iptables, and adding stateful inspection. Intrusion detection and penetration testing come in the following classes.

Notes

Threats and threat actors

A useful way to organize threats is along three axes. Threats are natural or human; human threats are benign or malicious; and malicious threats are random or directed.

An important practical point: it is not always clear when an attack is underway. A system failure could be natural or a directed attack, and often you don't find out until afterward. Worth asking yourself: have you ever been harmed by a security failure, and could you tell whether it was malicious, or whether you were targeted specifically?

Disaster recovery (DR) is an organization's plan for recovering from threats. One opinion from the slides worth taking seriously: large tomes are not useful. A document that tries to anticipate every possible disaster will not match the situation you actually face. Better to have a general plan for contingencies plus checklists for which services to restore in what order.

Who the adversaries are

Anderson's list is spies, crooks, geeks, and terrorists. Who's missing? Corporations. They collect and analyze enormous amounts of information about you, legally.

The canonical example: Target determined a young woman was pregnant before her father did. Every online purchase shares information with a retailer, purchases are tied to your credit card and browsing habits, and retailers also buy demographic data from other sources. Target noticed that women on its baby registry bought a lot of lotion around the second trimester, and in the first 20 weeks bought vitamins, unscented soap, and cotton balls. Using 25 products as predictors — cocoa-butter lotion, a large purse that could double as a diaper bag, zinc and magnesium supplements gave an 87% chance of a due date within four months — it sent coupons to likely customers. A father confronted the store for encouraging his daughter's pregnancy, then learned the truth. Target now interleaves pregnancy coupons with unrelated ones to seem less unsettling. Did it work? Sales went from $44B to $67B after profiling. Did Target break any laws? What about the social media companies doing more of this with less disclosure?

Goals, and the kill chain

Adversary goals generally amount to compromising the CIA triad, in service of: financial gain, espionage (government or corporate), sabotage, political or ideological motives, reputational damage, or loss of business via denial of service.

The cyber kill chain and the MITRE ATT&CK framework describe the phases of an attack, the point being to understand the process well enough to interrupt it at some stage.

Take the reconnaissance phase, where adversaries learn as much as possible about a network. The standard methodology — and you'll write a tool like this in Lab 5, with nmap as the reference implementation:

  1. Check for live systems, giving a list of hosts on the network. Ping can do this.
  2. Check for open ports. Different machines run different services, and services use standard ports (ssh on 22), so open ports reveal what's listening.
  3. Scan around the IDS. Don't be noisy; avoid detection.
  4. Perform banner grabbing to learn the OS and the versions of running services.
  5. Scan for vulnerabilities by checking those versions against the CVE (Common Vulnerabilities and Exposures) database.
  6. Draw network diagrams.

Notice that steps 1–4 are things we've already covered as legitimate operational tools. The techniques are identical; only the intent differs.

Botnets

A botnet ("robot network") is a large collection of compromised devices commanded by a command-and-control server. Devices are recruited by trojan or virus, or simply by having default passwords, and then wait for instructions. You can rent time on a botnet for a denial of service attack.

Mirai is the case study. Enormous numbers of Internet-connected devices used default credentials, and Mirai compromised hundreds of thousands of them quickly. In 2016 it was used for a distributed denial of service (DDoS) attack that flooded the DNS provider Dyn, overwhelming its servers so that users couldn't reach many websites. (Recall that from the DNS day — this is the same incident from the other side.) Mirai and its variants are still active, with updated versions using TOR for command-and-control anonymity. The lesson is unglamorous: change your default passwords.

P > D + R

The fortress mentality — build a strong perimeter and be safe — doesn't work anymore. One framework worth carrying:

Protection > Detection + Reaction

The point of writing it as an inequality is that protection must hold out longer than it takes you to detect a problem and react to it. Most attention goes to protection; don't forget the other two terms, because protection eventually fails and then only detection and reaction matter.

Patching

New patches arrive constantly — "Patch Tuesday" is followed by "exploit Wednesday," since a published patch tells attackers exactly what to attack in unpatched systems. You could apply patches everywhere immediately and hope nothing breaks ("patch and pray"). A more measured approach: pick the least time-sensitive part of the organization, patch half of that group on day one, see whether anything breaks, then next day finish that group and start half of another, continuing until everyone is covered.

This is imperfect and worth being honest about why: parts of the organization stay exposed for days, a problem in one group may not predict problems in another, and if a patch does break something, taking down half a group is still a serious issue. There is no clean answer here — only a choice about which risk to carry.

What firewalls are

A firewall separates trusted from untrusted network components — an inside and an outside. Often sold as a hardware appliance, though the appliance is just a computer, usually running Linux, and firewall functionality is often part of a router.

Main functions: filtering packets, redirecting traffic, and protecting against network attacks. Three requirements, each of which is a real design constraint:

That first requirement is the one that fails in practice. A firewall that can be bypassed — by a rogue access point, a personal hotspot, or a VPN tunnel — enforces nothing.

Policy dimensions

Firewall policy typically controls three things:

Three actions

On any given packet a firewall normally does one of three things:

The difference between deny and reject matters more than it looks. Rejecting is more polite and faster for legitimate users, but it confirms to a scanner that something is there. Dropping silently makes reconnaissance slower and less certain.

Filtering can happen on ingress or egress. Ingress filtering inspects traffic from outside to prevent attacks, which is the obvious case. Why filter on egress? To prevent inside users from reaching outside resources the organization doesn't want them reaching — and, less obviously, to stop compromised inside machines from exfiltrating data or joining a botnet.

Firewalls come in software versions deployed on a single computer to defend that host, and hardware versions protecting an entire organization.

Four types of firewall

1) Packet filters

A packet filter decides on a packet-by-packet basis, using information in the headers up to Layer 4 and never looking at the application payload. It does not consider whether a packet is part of an existing stream and maintains no connection state — hence the other name, stateless firewall.

Decisions are based on: source and destination IP address, source and destination port numbers, ICMP message type, and the TCP SYN and ACK bits. The primary advantages are speed and cost. These were the first firewalls invented and deployed, and they're still common in small organizations.

Two examples of what you can express:

Translating policies into settings: 

Policy                                    Firewall setting
-----------------------------------------------------------------------------
No outside Web access                     drop all outgoing packets to any IP,
                                          port 80
No incoming TCP connections except        drop all incoming TCP SYN packets to
to the public Web server                  any IP except 130.207.244.203, port 80
Prevent Web-radios eating bandwidth       drop all incoming UDP packets except
                                          DNS and router broadcasts
Prevent your network being used           drop all ICMP packets going to a
for a DoS attack                          broadcast address
Prevent your network being tracerouted    drop all outgoing ICMP TTL-expired
                                          traffic

Two of those are worth a second look. Blocking ICMP to a broadcast address defends against the smurf attack, where an attacker sends packets spoofed with a victim's source address to a broadcast address, and every host on the network replies to the victim. And blocking outgoing TTL-expired messages defeats traceroute — which is exactly the mechanism from Day 2, and explains why Dartmouth blocks traceroute.

Access control lists

Rules are expressed as an ACL: (action, condition) pairs applied top to bottom to each packet. The structure should look familiar — it's essentially OpenFlow's match-plus-action from the data plane day. 

action  source addr    dest addr      proto  sport   dport   flag
allow   222.22/16      outside        TCP    >1023   80      any
allow   outside        222.22/16      TCP    80      >1023   ACK
allow   222.22/16      outside        UDP    >1023   53      ---
allow   outside        222.22/16      UDP    53      >1023   ---
deny    all            all            all    all     all     all

Read that as a policy: rows 1–2 let users browse the web (outbound connections to port 80, and inbound replies that carry ACK); rows 3–4 let them resolve domain names (DNS requests and responses on port 53); and the final row blocks everything else. That last row matters — a default-deny at the bottom is what turns a list of permissions into a policy.

2) Stateful inspection

A stateful firewall decides based on a stream of packets rather than one packet. It tracks the state of each connection by monitoring all interactions until the connection closes, maintaining a connection state table that gives context. It inspects up to Layer 4 and is able to prevent many kinds of spoofing attack. It costs more than a packet filter.

Here's the specific weakness it fixes. The stateless rule 

allow  outside  222.22/16  TCP  80  >1023  ACK

permits packets that make no sense: a packet with destination port >1023 and the ACK bit set, arriving from outside, even though no internal host ever established a TCP connection. An attacker just sets the ACK bit. The stateless filter has no way to know better, because knowing better requires remembering something.

A stateful filter tracks each TCP connection through setup (SYN) and teardown (FIN), keeps a table of open connections, times out inactive ones, and drops non-requested packets. Walking through a TCP connection: initial state not connected; a SYN from inside creates a table entry; a SYN-ACK from outside updates it; an ACK from inside marks the connection established; traffic flows until FIN-and-ACK or timeout.

The payoff is large. Where a packet filter must leave a wide range of high ports open for replies, a stateful firewall allows traffic only on ports with a successfully established connection, drastically reducing the opportunity for spoofing.

3) Application proxy

An application proxy firewall controls access to and from a specific service, acting as an intermediary so there's no direct contact with the application. The client's connection terminates at the firewall, which initiates a separate connection to the service. Data on the connection can be analyzed all the way up to the application layer, and both requests and replies are evaluated. It can prevent sensitive information leaks. SQUID is a popular implementation.

Note that a proxy is structurally a man-in-the-middle — the same position we spent Day 12 trying to make impossible, here occupied deliberately and by your own administrator. Limitations: you must implement proxy rules for each application, and it's slower than the other types.

4) Next generation firewalls

NGFWs add capabilities up through Layer 7: deep packet inspection, understanding of application-layer protocols, VPN awareness, intrusion detection and prevention, anti-malware, web filtering, anti-spam, and anti-DoS. Two further features worth noting: they can map traffic to individuals rather than just IP addresses, and they send logs to SIEM (Security Information and Event Management) systems for correlation across an organization.

DMZs and port forwarding

Some hosts must be reachable from outside — web, email, and DNS servers — while the internal network must not be. The standard arrangement is a demilitarized zone (DMZ): put the externally reachable hosts in their own segment between two firewalls. The outer firewall controls access to the DMZ hosts, the first line of defense; the inner firewall controls access to the internal network, the second line. So a compromise of the web server doesn't hand the attacker the internal network.

Port forwarding is the low-budget alternative, common in homes without sophisticated firewalls. Most routers block unsolicited inbound traffic; a port forwarding rule allows traffic to a specific port through, forwarded to a specific internal host. For example, forward port 25565 to your Minecraft server. Be careful opening ports — recall from Day 12 that exposed devices are attacked within minutes.

Building a filter with Netfilter and LKMs

Packet filtering must happen inside the kernel; user space cannot control packet flow. So we need to change the kernel, and Linux gives us two tools for doing that without recompiling it:

The five hooks

When a packet reaches a hook, the OS checks whether any code has registered a callback there; if so it calls it, otherwise the packet passes along. The five hooks, following a packet's journey:

Code attached to a hook returns one of five verdicts:

Multiple modules can register at the same hook, and they're called in priority order, with NF_IP_PRI_FIRST being highest.

Loadable kernel modules

An LKM needs an init function, which runs when the module is loaded, and an exit function, which runs when it's removed (kMod.c): 

static int kmodule_init(void) {
        printk(KERN_INFO "Initializing this module\n");
        return 0;
}

static void kmodule_exit(void) {
        printk(KERN_INFO "Module cleanup\n");
}

module_init(kmodule_init);
module_exit(kmodule_exit);
MODULE_LICENSE("GPL");

Note printk, not printf — kernel code prints to the kernel log, not to your screen, so you read the output with dmesg. The Makefile builds against the running kernel's headers: 

obj-m += kMod.o
all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

-C specifies the directory of kernel library files, and M indicates where the external module lives. The lifecycle: 

$ make
$ sudo insmod kMod.ko          # insert the module
$ lsmod | grep kMod            # list installed modules
kMod        16384    0
$ sudo rmmod kMod              # remove it
$ dmesg | tail
[ 2969.190306] Initializing this module
[ 3005.730520] Module cleanup

A telnet filter

Goal: block telnet traffic, which is TCP on port 23. Which hook? The reasoning matters more than the answer. To block outbound telnet from this host, LOCAL_OUT and POST_ROUTING are both reasonable, and traffic from this computer traverses POST_ROUTING anyway. LOCAL_IN would block inbound telnet instead. FORWARD would block telnet from other computers routed through us. Each hook implies a different policy, so pick the one matching the policy you want.

Registration (telnetFilter.c): 

static struct nf_hook_ops telnetFilterHook;

int setUpFilter(void) {
        printk(KERN_INFO "Registering a Telnet filter.\n");
        telnetFilterHook.hook     = telnetFilter;          // callback function
        telnetFilterHook.hooknum  = NF_INET_POST_ROUTING;  // which hook
        telnetFilterHook.pf       = PF_INET;               // IPv4
        telnetFilterHook.priority = NF_IP_PRI_FIRST;       // priority
        nf_register_net_hook(&telnetFilterHook);
        return 0;
}

void removeFilter(void) {
        printk(KERN_INFO "Telnet filter is being removed.\n");
        nf_unregister_net_hook(&telnetFilterHook);
}

module_init(setUpFilter);
module_exit(removeFilter);

And the callback itself: 

unsigned int telnetFilter(void *priv, struct sk_buff *skb,
                 const struct nf_hook_state *state)
{
  struct iphdr *iph;
  struct tcphdr *tcph;
  iph = ip_hdr(skb);
  tcph = (void *)iph + iph->ihl*4;
  if (iph->protocol == IPPROTO_TCP && tcph->dest == htons(23)) {
    printk(KERN_INFO "Dropping telnet packet to %d.%d.%d.%d\n", ...);
    return NF_DROP;
  } else {
    return NF_ACCEPT;
  }
}

Several things here reward attention, because they're the payoff for everything we learned about headers:

In the demo, with the hook set to NF_INET_LOCAL_IN so that inbound telnet is blocked: a secondary machine can telnet in successfully; then on the primary, make and sudo insmod telnetFilter.ko; the secondary's next telnet attempt is blocked, and dmesg | tail on the primary shows the drop being logged; then sudo rmmod telnetFilter and telnet works again.

iptables

Writing kernel modules for every rule would be miserable. Linux ships a built-in firewall, iptables, built on top of Netfilter: you enter commands in user space, and the kernel-space component xtables — which has access to Netfilter's five hooks — installs the corresponding kernel-side rules. No compiling required.

Tables and chains

iptables organizes functionality into tables by what you're trying to do, and chains that correspond to Netfilter's hooks:

The chains map directly onto hooks: INPUT = LOCAL_IN, FORWARD = FORWARD, OUTPUT = LOCAL_OUT, plus PREROUTING and POSTROUTING. Filtering applications only need three of the five hooks (INPUT, FORWARD, OUTPUT); all five are available for mangling. As a packet moves through each chain, iptables checks for matching rules and executes them, normally resulting in ACCEPT, REJECT, DROP, or LOG.

Command anatomy

The general form, which looks forbidding at first and then stops being so: 

$ iptables [-t filter] -A CHAIN <rule> -j <action>

Reading it piece by piece:

Examples

Block one address from talking to a network: 

$ sudo iptables -A INPUT -s 192.168.30.6 -d 192.168.0.0/16 -j DROP

Open SSH and HTTP: 

$ sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
$ sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Note the double dash on --dport. And note the semantics of ordering: rules are evaluated in order, and once a packet matches an ACCEPT rule it proceeds — even if a later rule would have dropped it. Rule order is policy.

Set default policies with -P (no -j needed): 

$ sudo iptables -P INPUT DROP
$ sudo iptables -P OUTPUT DROP
$ sudo iptables -P FORWARD DROP

That's default-deny: everything is dropped unless some rule allows it. Combined with the ordering rule above, the standard pattern is to set a default-deny policy and then append the specific permissions you want. (Be careful doing this over SSH.)

Allow all outgoing TCP: 

$ sudo iptables -A OUTPUT -p tcp -j ACCEPT

Limits and statistics

iptables can do more than accept and drop. Rate limiting ICMP: 

$ sudo iptables -A INPUT -p icmp -m limit --limit 10/min --limit-burst 5 -j ACCEPT

-m limit loads the limit module, --limit 10/min allows ten ICMP packets per minute, and --limit-burst 5 initially allows five. Statistical matching: 

$ sudo iptables -A INPUT -m statistic --mode random --probability .50 -j DROP
$ sudo iptables -A INPUT -m statistic --mode nth --every 3 -j DROP

The first drops packets with 50% probability, the second every third packet. Randomized matching can also be used constructively — for load balancing across servers. Rules can also act based on process owner.

Modifying packets uses the mangle table. To add five to the TTL: 

$ sudo iptables -t mangle -A PREROUTING -j TTL --ttl-inc 5

Note the two choices being made: mangle rather than filter because we're changing the packet rather than judging it, and PREROUTING so that all packets are changed before anything else happens.

Listing, deleting, resetting

# list all rules for a table
$ sudo iptables -t filter -L
$ sudo iptables -t filter -L --line-numbers

Chain INPUT (policy ACCEPT)
num  target  prot opt source     destination
1    ACCEPT  tcp  --  anywhere   anywhere    tcp dpt:http

# flush (remove) all rules for a table
$ sudo iptables -t nat -F

# remove rule 1 from the INPUT chain
$ sudo iptables -D INPUT 1

--line-numbers is what makes targeted deletion practical, since you delete by number. Commands can be collected into a shell script for convenience — clean_up.sh resets everything to defaults: 

#!/bin/sh
# Set up all the default policies to ACCEPT packets
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
# Flush all existing configurations
iptables -F

iptables is extremely powerful and we've barely scratched the surface.

Stateful inspection with conntrack

Recall the two rules opening ports 22 and 80. There's a gap: an adversary can send TCP packets from port 80 to inside clients that never established a connection. The stateless rule can't tell the difference.

The conntrack module adds state tracking, with four states:

So add a rule accepting only traffic belonging to a connection that already exists: 

$ sudo iptables -A INPUT -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

The full pattern, for a firewall forwarding traffic, is to allow SYN packets to exactly the services you're offering, allow anything belonging to an existing connection, and default-deny the rest: 

# allow SYN packets to ports 22 and 80
$ sudo iptables -A FORWARD -p tcp --dport 22 --syn -m conntrack --ctstate NEW -j ACCEPT
$ sudo iptables -A FORWARD -p tcp --dport 80 --syn -m conntrack --ctstate NEW -j ACCEPT

# allow TCP packets belonging to an existing connection
$ sudo iptables -A FORWARD -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# default policy
$ sudo iptables -P FORWARD DROP

That's the whole stateful idea in four commands: connections may only begin in ways you explicitly permit, and after that the firewall remembers.

Exercises

Write iptables rules to:

Then, for each rule you wrote: which chain did you use and why, and would the rule still work if it were appended after a broad ACCEPT rule? Test your answers on the VM, and use clean_up.sh to reset between attempts.

Terms

Not a comprehensive reference — the textbook has much more — but these are the terms from Day 14 that will keep coming back.

threat taxonomy
Natural vs. human; benign vs. malicious; random vs. directed. Useful because the defense and the recovery plan differ by category, and because you often can't tell which category you're in until afterward.
disaster recovery (DR)
An organization's plan for recovering from threats. More useful as a general contingency plan plus service-restoration checklists than as an exhaustive catalog of scenarios.
threat actors
Script kiddies (pre-made scripts, no funding), hacktivists (agenda-driven), organized crime (money, well funded), governments (extremely sophisticated), insiders (knowledge and a grudge) — and corporations, which collect data legally.
APT (Advanced Persistent Threat)
A well-resourced, patient, typically state-backed adversary that maintains long-term access rather than seeking a quick result.
cyber kill chain / MITRE ATT&CK
Frameworks describing the phases of an attack, so defenders can identify where to interrupt it.
reconnaissance
The information-gathering phase: find live systems, find open ports, avoid the IDS, grab banners for OS and version information, check versions against CVE, and diagram the network. nmap is the standard tool.
CVE
Common Vulnerabilities and Exposures: the public database mapping software versions to known vulnerabilities.
botnet / command-and-control
A network of compromised devices awaiting instructions from a C&C server, often recruited via default passwords, and rentable for attacks.
Mirai / DDoS
The IoT botnet that compromised hundreds of thousands of devices using default credentials and, in 2016, flooded the DNS provider Dyn in a distributed denial of service attack, making many websites unreachable.
P > D + R
Protection must exceed Detection plus Reaction. A reminder that perimeter protection alone is insufficient, since protection eventually fails.
firewall
A device separating trusted from untrusted networks, filtering packets and redirecting traffic. Requires that all inter-zone traffic pass through it, that only policy-authorized traffic pass, and that the firewall itself be hardened.
accept / deny / reject
Pass the packet; silently stop it; or stop it and notify the sender via ICMP. Dropping silently gives a scanner less information than rejecting.
ingress / egress filtering
Inspecting inbound traffic to prevent attacks, or outbound traffic to prevent access to unwanted resources and to catch exfiltration from compromised hosts.
packet filter (stateless firewall)
Decides per packet using headers up to Layer 4 — addresses, ports, ICMP type, TCP SYN/ACK bits — without payload inspection or connection state. Fast and cheap.
ACL (access control list)
Ordered (action, condition) pairs applied top to bottom, structurally the same as OpenFlow match-plus-action. Typically ends with a default-deny row.
smurf attack
Sending packets spoofed with the victim's source address to a broadcast address, so every host's reply floods the victim. Blocked by dropping ICMP to broadcast addresses.
stateful firewall
Tracks each connection's state in a connection table (SYN through FIN, with timeouts), so it can drop packets that "make no sense" — such as an ACK for a connection that was never established.
application proxy firewall
Terminates the client's connection at the firewall and opens a separate connection to the service, allowing analysis up to Layer 7. Requires per-application rules and is slower. SQUID is one implementation.
NGFW
Next generation firewall: deep packet inspection, Layer 7 awareness, VPN awareness, IDS/IPS, anti-malware, web filtering, anti-spam, anti-DoS, per-individual attribution, and SIEM log export.
DMZ
A segment between two firewalls holding hosts that must be reachable from outside (web, email, DNS), so that compromising one doesn't expose the internal network.
port forwarding
A rule allowing unsolicited inbound traffic on a specific port through to a specific internal host. Common in homes, and a real exposure.
Netfilter
The Linux kernel framework providing hooks along a packet's path where code can be registered to inspect or modify it.
Netfilter hooks
PRE_ROUTING (just arrived), LOCAL_IN (for this host), FORWARD (for another host), LOCAL_OUT (generated here), POST_ROUTING (last point before leaving). Which one you choose determines what your rule actually filters.
Netfilter verdicts
NF_ACCEPT, NF_DROP, NF_QUEUE (hand to user space), NF_STOLEN (hold, e.g. fragments), NF_REPEAT.
LKM (loadable kernel module)
Code dynamically inserted into the running kernel with insmod and removed with rmmod, with module_init and module_exit functions. Use printk and read output with dmesg.
sk_buff
The kernel structure holding an entire packet, passed to a Netfilter callback.
iptables / xtables
The user-space command and its kernel-space counterpart, built on Netfilter, letting you install filtering rules without writing kernel modules.
tables and chains
Tables organize rules by purpose (filter, mangle, nat); chains correspond to Netfilter hooks (INPUT, FORWARD, OUTPUT, PREROUTING, POSTROUTING). Filtering needs only the first three.
iptables rule order
Rules are evaluated top to bottom, and a packet matching an ACCEPT proceeds even if a later rule would drop it. Ordering is policy.
default policy (-P)
The action for packets matching no rule. -P INPUT DROP gives default-deny, the usual starting point for a restrictive firewall.
conntrack
The iptables module tracking connection state, with states NEW, ESTABLISHED, RELATED, and INVALID, used via -m conntrack --ctstate.

Credit: Most information on this page is from Computer Networking: A Top-Down Approach, 9th edition by Kurose and Ross, or from Internet Security: A Hands-on Approach" by Du.
This page was generated by Claude from in-class slides.