Attacks don't respect clean layer boundaries
Real attackers don't open a textbook and decide to target "Layer 4 today." They pick an objective, steal credentials, stay persistent, disrupt a service and move up and down the stack however they need to. A man-in-the-middle attack might start at Layer 2 with ARP spoofing, then exploit a Layer 6 weakness like an outdated TLS configuration to actually read the intercepted traffic. A phishing campaign starts at Layer 7, but the malware it delivers might then scan the network at Layer 3 and move laterally at Layer 2.
That said, mapping any technique to its primary layer is still one of the fastest ways to orient yourself during an investigation. It narrows which logs to pull, which tools are relevant, and which team owns the response.
Complete attack reference
| Layer | Common attacks | Primary defences |
|---|---|---|
| Layer 7: Application | SQL Injection, XSS, CSRF, Directory Traversal, malicious API abuse | Input validation, parameterised queries, WAF, MFA, HTTPS, patching |
| Layer 6: Presentation | SSL Stripping, Certificate Spoofing, Weak Cipher Exploitation | HSTS, modern TLS configuration, valid certificates, disable legacy versions |
| Layer 5: Session | Session Hijacking, Session Fixation, Session Replay, CSRF | Regenerate session IDs on login, timeouts, Secure/HttpOnly/SameSite cookies |
| Layer 4: Transport | SYN Flood, Port Scanning, UDP Flood, TCP Reset attacks | SYN cookies, rate limiting, stateful firewalls, IDS/IPS |
| Layer 3: Network | IP Spoofing, BGP Hijacking, ICMP Floods, ping sweeps | Ingress/egress filtering, uRPF, RPKI, ICMP rate limiting |
| Layer 2: Data Link | ARP Spoofing, MAC Flooding, VLAN Hopping, MAC Spoofing | Dynamic ARP Inspection, port security, 802.1X |
| Layer 1: Physical | Wiretapping, cable tampering, rogue access points, signal jamming | Physical access controls, WIDS, disable unused ports, tamper-evident cabling |
Attacks that span multiple layers
Man-in-the-Middle
Typically starts at Layer 2: ARP spoofing repositions the attacker on the traffic path so packets flow through them. But being in the middle is only useful if the attacker can actually read the traffic, which requires exploiting a Layer 6 weakness: either SSL stripping to downgrade HTTPS to plain HTTP, or getting the victim to accept a fraudulent certificate. The attack crosses two layers to work.
DDoS
Modern DDoS campaigns often hit multiple layers simultaneously. Volumetric floods at Layer 3/4 overwhelm bandwidth and connection state. Application-layer floods at Layer 7 target specific web endpoints with legitimate-looking requests that consume backend resources rather than raw bandwidth, much harder to filter because the traffic looks real. Effective mitigation requires visibility at every layer, not just one.
Malware command-and-control
A piece of malware delivered via a phishing email (Layer 7) will almost always communicate outbound using Layer 7 protocols HTTPS is popular because it blends into normal traffic and is encrypted. Detection depends on Application Layer inspection: TLS metadata analysis, DNS query patterns, and HTTP behaviour rather than any lower-layer signature. The initial compromise and the ongoing communication both live at the top of the stack.
Defence in depth: what it actually means
No single layer's controls are sufficient on their own. A perfectly tuned firewall at Layer 3/4 won't stop a SQL injection at Layer 7. A WAF covering Layer 7 won't stop someone tapping a cable in an unlocked server room. The argument for defence in depth is straightforward: stack independent controls at multiple layers so that a failure at one doesn't result in a full compromise.
| Security control | Layer(s) protected |
|---|---|
| Web Application Firewall (WAF) | Layer 7 |
| TLS / certificate management | Layer 6 (interacts with Layer 4) |
| Session management controls | Layer 5 (implemented at Layer 7) |
| Stateful firewall / IDS / IPS | Layers 3–4 |
| Router ACLs / RPKI | Layer 3 |
| Dynamic ARP Inspection / port security | Layer 2 |
| Physical access controls / WIDS | Layer 1 |
Troubleshooting with the OSI Model
When something stops working, the OSI stack gives you a checklist. Instead of guessing, you work through the layers systematically until you find where the problem actually lives.
Three approaches
Bottom-up, start at Layer 1 (is the cable plugged in?) and work upward. Thorough but slow if the problem is clearly higher up.
Top-down, start at Layer 7 and work downward. Efficient when the symptom is specific to one application.
Divide-and-conquer, start in the middle, typically at Layer 3 or 4, and branch based on what you find. Most experienced engineers default to this because it isolates problems fastest.
Tools by layer
| Layer | Useful tools |
|---|---|
| Layer 7: Application | Browser dev tools, application logs, curl, Burp Suite |
| Layer 6: Presentation | openssl s_client, browser certificate viewer, Wireshark (TLS inspection) |
| Layer 5: Session | Application/session logs, load balancer logs, identity provider logs |
| Layer 4: Transport | netstat, ss, Wireshark (TCP flags), Nmap |
| Layer 3: Network | ping, traceroute / tracert, ip route |
| Layer 2: Data Link | arp -a, switch MAC address tables, cable testers |
| Layer 1: Physical | Link lights, cable testers, physical inspection |
Walkthrough: "the website is down"
Using divide-and-conquer on one of the most common complaints in IT:
Can the user reach other sites? If yes, the problem is specific to this service, not the local network or internet connection. This immediately rules out Layers 1–3 on the user's side.
Does DNS resolve the domain? Run nslookup or dig. If it returns the wrong IP, the problem is DNS, a Layer 7 protocol with infrastructure-level impact.
Can you ping the server's IP? If not, the problem is at Layer 3 or below, routing, firewalls, or the server itself being down.
Does the relevant port respond? If ping works but port 443 doesn't, the problem is at Layer 4: a firewall is blocking it, or the web service isn't running.
Does the TLS handshake complete? If the port responds but HTTPS fails, check for an expired or misconfigured certificate Layer 6.
Is the server returning an error? HTTP 500 or similar errors mean the network is fine but something is broken inside the application Layer 7, and now an application team problem rather than a network team problem.
By the end of this process you know not just that something is broken, but exactly which team needs to fix it.
Reading packets in Wireshark
Wireshark is where the OSI Model stops being theoretical. It captures real network traffic and shows you every layer of encapsulation as a structured breakdown you can expand and inspect field by field.
For a typical HTTPS request, the packet details pane shows something like: Frame → Ethernet II → Internet Protocol Version 4 → Transmission Control Protocol → Transport Layer Security. Each section maps to one OSI layer. Expanding Ethernet II shows the source and destination MAC addresses. Expanding IP shows source and destination IP addresses. Each layer's header fields are right there.
Essential display filters
| Filter | What it shows |
|---|---|
ip.addr == 192.168.1.10 | All traffic to or from a specific IP |
tcp.port == 443 | All HTTPS traffic |
dns | All DNS queries and responses |
arp | All ARP traffic, useful for spotting spoofing |
tcp.flags.syn == 1 && tcp.flags.ack == 0 | New TCP connection attempts, useful for spotting SYN floods |
tls.handshake.type == 1 | TLS ClientHello messages |
http.response.code == 500 | Server-side application errors |
A practical way to build intuition: capture your own traffic while visiting a website over HTTPS, then filter on dns, then tcp.flags.syn==1, then tls.handshake.type==1 in that order. You'll see the DNS resolution, TCP handshake, and TLS negotiation from Part 2 laid out as actual packets, in the exact order they occurred.
The SOC analyst's view
A Security Operations Centre analyst doesn't get to choose which layer an alert shows up at. One alert might be a WAF flagging a SQL injection attempt at Layer 7; the next might be a switch reporting a MAC address flapping between ports at Layer 2. The OSI Model gives analysts a shared mental map for triaging whatever comes in.
| Layer | Typical SOC data sources |
|---|---|
| Layer 7: Application | WAF logs, application logs, EDR/antivirus alerts, email security gateway |
| Layer 6: Presentation | Certificate monitoring, TLS inspection proxies |
| Layer 5: Session | Identity provider logs, session and token audit logs |
| Layer 4: Transport | Firewall logs, NetFlow/sFlow data, IDS/IPS alerts |
| Layer 3: Network | Router and firewall logs, BGP monitoring, DDoS mitigation dashboards |
| Layer 2: Data Link | Switch logs, wireless controller logs, NAC systems |
| Layer 1: Physical | Badge access logs, CCTV, facilities and physical security systems |
Multi-layer incident walkthrough
Scenario: an alert fires, a workstation is communicating with a known malicious domain.
Step 1 (Layer 7): DNS and proxy logs confirm the query and show what, if anything, was downloaded or sent outbound.
Step 2 (Layer 7): email security logs show the user received a phishing email with a malicious attachment shortly before the alert. Delivery method confirmed.
Step 3 (Layer 5): identity provider logs are checked for concurrent sessions or unusual authentication attempts from the compromised account, in case credentials were also harvested.
Step 4 (Layers 3–4): firewall and NetFlow logs confirm the outbound connection's destination IP, port, and data volume, determining whether exfiltration occurred.
Step 5 (Layers 2–3): switch and internal firewall logs are reviewed for lateral movement, did the compromised workstation attempt to reach other internal systems?
Step 6: Containment: with a layered picture now in hand, the analyst isolates the workstation at Layer 2/3, disables the compromised account at Layer 5/7, and blocks the malicious domain and IP at Layer 3/7. A coordinated response built on evidence gathered across the whole stack.
Quick-reference cheat sheet
| Layer | Name | PDU | Key protocols | Key devices |
|---|---|---|---|---|
| 7 | Application | Data | HTTP, HTTPS, DNS, SMTP, SSH | End hosts, WAFs |
| 6 | Presentation | Data | TLS/SSL, JPEG, UTF-8 | End hosts, TLS proxies |
| 5 | Session | Data | Session tokens, RDP, SSH sessions | End hosts |
| 4 | Transport | Segment / Datagram | TCP, UDP | Stateful firewalls |
| 3 | Network | Packet | IP, ICMP, OSPF, BGP | Routers, Layer 3 switches |
| 2 | Data Link | Frame | Ethernet, ARP, VLANs | Switches, access points |
| 1 | Physical | Bit | Cabling, fibre, radio | NICs, hubs, repeaters |
| Attack | Layer |
|---|---|
| SQL Injection, XSS, CSRF | Layer 7: Application |
| SSL Stripping, Certificate Spoofing | Layer 6: Presentation |
| Session Hijacking, Session Fixation | Layer 5: Session |
| SYN Flood, Port Scanning, UDP Flood | Layer 4: Transport |
| IP Spoofing, BGP Hijacking, ICMP Floods | Layer 3: Network |
| ARP Spoofing, MAC Flooding, VLAN Hopping | Layer 2: Data Link |
| Wiretapping, Signal Jamming, Rogue Access Points | Layer 1: Physical |
Common questions
How does a firewall's function change depending on which layer it operates at?
A traditional Layer 3/4 firewall filters by IP address, port number, and connection state. It has no idea what the traffic actually says. A Web Application Firewall at Layer 7 inspects the content of HTTP requests and can catch things like SQL injection or XSS that a lower-layer firewall would pass straight through. Both are necessary, they protect different things.
What's the difference between a SYN flood and an application-layer DDoS?
A SYN flood exhausts connection state at Layer 4 by never completing TCP handshakes, forcing the server to hold thousands of half-open connections until it runs out of resources. An application-layer DDoS sends complete, valid-looking requests at Layer 7 that get all the way through to the application before consuming resources. The second type is much harder to block because the traffic is technically legitimate until it hits the backend.
Why is HTTPS more secure than HTTP, technically?
HTTPS wraps HTTP in TLS, which provides three things plain HTTP doesn't: confidentiality (the data is encrypted so intermediaries can't read it), integrity (a tamper-evident MAC means modifications are detectable), and authentication (the server's certificate proves you're talking to who you think you are, not an impostor). HTTP provides none of these.
What does defence in depth actually mean in practice?
It means not relying on any single control, because every control has failure modes. Physical security fails if an attacker gets past the door. Network segmentation fails if an attacker is already inside. Encryption fails if a certificate is compromised. Layering independent controls at every level means that a failure in one place doesn't hand an attacker the keys to everything.