Networking

Why Walmart asks this: The JD requires "strong understanding of networking (TCP/IP, firewalls, VPNs, IDS/IPS)"; every security capability at Walmart (Intrusion Analyst, Network Engineer II, Data Assurance) is built on packet-level fundamentals. Walmart Global Tech India loops are documented asking exactly these — OA MCQs on CN and Technical 1 questions like Hub vs Switch and "What happens when you type google.com?". Highest-yield topic for a cybersecurity intern.

2. Core Concepts

2.1 OSI 7 Layers vs TCP/IP 4 Layers

TCP/IP 4 layers: Application (OSI 5–7), Transport, Internet (OSI 3), Network Access (OSI 1–2). Mnemonic bottom-up: Please Do Not Throw Sausage Pizza Away.

Encapsulation: each layer adds a header — Ethernet → IP → TCP → TLS → HTTP. Knowing which header holds what is how you read a Wireshark packet in seconds.

How to use the model: OSI is a troubleshooting tool, not a stack you implement. When something breaks, work the layers in order — link and interface (L1), port, MAC and VLAN (L2), address, mask and route (L3), port and handshake (L4), then the application — and stop where the evidence stops changing. Security controls map the same way: a network firewall is L3–L4, a WAF is L7, TLS sits between transport and application, and an IDS decodes whatever layer it is fed.

The encapsulation walkthrough, top header first (one HTTPS request): Ethernet (src/dst MAC, EtherType 0x0800) → IPv4 (10.0.4.130 → CDN IP, TTL 64, proto 6) → TCP (51422 → 443, flags SYN) → TLS (ClientHello, SNI=www.walmart.com) → HTTP/2 (GET /). Reading top-down tells you where the traffic is going; reading bottom-up shows what an attacker could rewrite at each layer — MAC (spoofing), IP (spoofing/reflection), port (filter evasion), SNI (routing/filtering), request (injection).

2.2 TCP 3-Way Handshake + Teardown

Client                                 Server
  |--- SYN seq=1000 ------------------->|   I want to connect, first byte 1000
  |<-- SYN-ACK seq=5000 ack=1001 -------|   OK, mine is 5000, got your 1000
  |--- ACK ack=5001 ------------------->|   Got your 5000 — ESTABLISHED
  |<============== data ===============>|
  |--- FIN seq=x ---------------------->|   4-way teardown: each direction closes
  |<-- ACK ack=x+1 ---------------------|   independently
  |<-- FIN seq=y -----------------------|
  |--- ACK ack=y+1 -------------------->|

• Why 3 and not 2: both sides must synchronize ISNs and confirm the peer received that synchronization. Two messages can't prove the server got the client's ACK.
• RST = abrupt abort (closed port, firewall reject, attack). A closed port replies RST, ACK; a dropped port replies nothing (timeout).
• SYN flood: thousands of SYNs never ACKed exhaust the half-open table. Defense: SYN cookies, short SYN timeout, rate limits, scrubbing.

ISN randomization is a security control. Initial sequence numbers are chosen unpredictably (RFC 6528 requires a cryptographic hash plus a secret) so an off-path attacker cannot forge a segment that fits inside a real session; the sequence-prediction attacks against early stacks are why the rule exists.

Half-open connections are visible if you know where to look. ss -tan state syn-recv lists connections that sent SYN but are still waiting for the final ACK (summary: ss -s; legacy counters: netstat -s). A handful is normal; thousands of entries from many sources, or a SYN_RECV count climbing against the backlog, is a flood in progress — enable SYN cookies and rate limiting.

Likely interview question: "An attacker is on the path — can they hijack the session?" Model answer: on-path, yes: they can inject a segment with the correct 4-tuple and sequence numbers, and they can always inject a RST to kill the connection. Off-path it is much harder because the ephemeral port and sequence numbers must be guessed, which is why blind spoofing is used for reflection (DNS/NTP amplification) rather than takeover. TLS hides the payload but does not stop a forged reset.

2.3 TCP vs UDP

Interview line: "TCP buys reliability with latency; UDP buys latency and lets the app decide reliability — which is why DNS uses UDP by default and switches to TCP when the answer exceeds the negotiated UDP buffer (classically 512 B, 1232 B with EDNS0 today) or for zone transfers, and why HTTP/3 rebuilt reliability on UDP with QUIC."

Flow control and congestion control solve different problems. The receive window stops a fast sender from overrunning a slow receiver — a window of zero pauses sending until it reopens. Congestion control (slow start, AIMD, BBR) stops the sender from overrunning the network, which is why throughput ramps up instead of starting at line rate. Both are investigation fingerprints: a host advertising a tiny or zero window can stall a server, and a sender that never backs off under loss behaves like a flood.

"UDP is unreliable" needs a qualifier. The datagram service is unreliable; the application can build reliability on top of it. QUIC numbers, acknowledges and retransmits inside an encrypted UDP flow, and DNS retries or switches to TCP. The safe phrasing: "UDP hands control to the application."

2.4 IP, Subnetting, CIDR, NAT

• IPv4 32-bit; IPv6 128-bit (no NAT needed; IPsec supported but not automatic — originally MUST, now SHOULD per RFC 6434/8504).
• CIDR /n = first n bits network. Hosts = 2^(32−n) − 2 (network + broadcast reserved). Exception: /31 = 2 usable (RFC 3021, point-to-point), /32 = 1 host route.

Example: 10.0.4.130/26 → block size 64 → subnets .0/.64/.128/.192 → host is in 10.0.4.128/26, broadcast .191, usable .129–.190.

How to subnet on paper in four steps: (1) convert the prefix to a block size — /26 → 2^(32−26) = 64; (2) list subnet boundaries at multiples of the block size (.0 .64 .128 .192); (3) the network address is the boundary at or below the host address and the broadcast is the next boundary minus one; (4) everything between is usable.

What NAT hides and what it does not: SNAT/PAT makes outbound traffic look like it came from one address, so external hosts cannot initiate back in and topology stays hidden — useful, but not access control. A header-only device sees only the translated address, so attribution depends on NAT logs. CGNAT puts many subscribers behind one public IP, which breaks inbound connections and makes IP reputation coarse.

• Private (RFC 1918): 10/8, 172.16/12, 192.168/16. APIPA 169.254/16 = DHCP failed. Loopback 127/8.
• Public = globally routable, ISP-assigned; RFC 1918 ranges stay private behind NAT/CGNAT. IPv6: GUA global (2001:db8::1/64 form), link-local fe80::/10 (auto-configured, like APIPA), ULA fc00::/7 (like RFC 1918). NDP replaces ARP.
• NAT: rewrites IP/port at the boundary. SNAT (outbound), DNAT/port-forward (inbound), PAT (many-to-one). Hides topology; not a firewall.

2.5 ARP + Spoofing

ARP maps IP → MAC within a LAN: broadcast "Who has 192.168.1.1? Tell 192.168.1.50" to ff:ff:ff:ff:ff:ff, owner replies unicast; cached (ip neigh, arp -a).

ARP spoofing/poisoning: attacker floods forged replies claiming the gateway IP maps to its MAC → all LAN traffic flows through attacker = MITM. Defenses: Dynamic ARP Inspection (DAI) + DHCP snooping, static ARP for gateways, port security, encryption (TLS) so interception yields ciphertext.

How to watch ARP: ip neigh (or arp -a) prints the cache; arping -I eth0 192.168.1.1 sends one request and prints the reply, to confirm a MAC at a point in time. In Wireshark, arp.opcode == 2 shows replies and the expert info flags one MAC answering for several IPs.

The attack step by step: (1) the attacker sends a gratuitous ARP reply telling the victim the gateway IP is at the attacker's MAC; (2) the victim overwrites its cache; (3) the attacker poisons the gateway the same way with the victim's IP; (4) traffic now flows through the attacker, who forwards it with IP forwarding enabled so nothing visibly breaks — that silence is why it survives; (5) the attacker captures metadata and cleartext, and can modify unencrypted traffic.

Likely interview question: "How would you stop ARP spoofing across a campus switch fleet?" Model answer: Dynamic ARP Inspection with DHCP snooping bindings on access ports validates replies; port security and 802.1X keep unknown devices off; static ARP protects critical gateways; VLANs shrink the blast radius; and monitoring catches gratuitous-ARP storms. Be clear that TLS is damage control, not detection.

2.6 DHCP, ICMP, Traceroute

• DHCP DORA: Discover → Offer → Request → ACK. Server port 67, client 68. Lease renews at 50%/87.5%. Risk: rogue DHCP hands out a malicious gateway/DNS → MITM; defend with DHCP snooping.
• ICMP types: 0 echo reply, 3 unreachable, 8 echo request, 11 TTL exceeded. ping = 8/0; traceroute sends TTL=1,2,3… and records each hop's type-11 reply. Linux traceroute uses UDP high ports; Windows tracert uses ICMP; traceroute -T uses TCP SYN to bypass ICMP-blocking firewalls. ICMP tunnels (ptunnel) are an exfil channel — odd/large payloads are a SOC detection.

What DORA actually grants: an address for a fixed lease plus gateway, DNS, domain and often NTP/boot options. The client renews at T1 (50% of lease) to the granting server and retries at T2 (87.5%) with a broadcast; if both fail the lease expires and the host drops to APIPA. A relay (ip helper-address) forwards requests between subnets.

Rogue DHCP is a small change with a big payoff. A laptop running a DHCP server on an access port hands victims a valid-looking lease plus an attacker-controlled gateway and DNS server, so the attacker sees every name the host resolves and can route or blackhole traffic. Defences: DHCP snooping (only trusted uplink ports may send Offers/ACKs), port security or 802.1X, and alerts on DHCP server traffic from user VLANs. Snooping also enables DAI, so it pays twice.

Likely interview question: "A host gets 169.254.x.x — what is wrong?" Model answer: APIPA means the DHCP exchange failed, so check pool exhaustion and scope on the server, the relay if the client is on another subnet, and the port, VLAN and cable locally. Confirm with a capture showing a Discover with no Offer, then compare a working neighbour.

2.7 DNS: Records, Resolution, Attacks, Monitoring

Resolution: Browser cache → OS cache/hosts → configured resolver (client query is recursive — "give me the final answer"). The resolver walks iteratively: root → .com TLD → authoritative NS → answer, cached by TTL.

Attacks: - Spoofing/cache poisoning: forged replies or a race (Kaminsky) inject a fake A record, redirecting users. Mitigations: DNSSEC, randomized TXID/source port, 0x20 encoding, DoH/DoT (privacy, but blind spots enterprise monitoring). - DNS tunneling: data in subdomain labels (aGVsbG8.evil.com), answers in TXT/NULL. Tools: iodine, dnscat2, Cobalt Strike DNS beacon. Signals: query names > ~50 chars, high-entropy/base32 labels, 100+ unique subdomains/hour to one parent domain, sustained TXT/NULL, steady beacon intervals. Splunk analytic: dc(query) + avg(len(query)) by src_ip, parent domain → threshold. - DGA/fast-flux: algorithmically generated C2 domains → high NXDOMAIN rate per host. - Why SOC cares: DNS is usually allowed outbound and rarely inspected — the easiest covert channel, and cheap high-signal telemetry. Log src_ip, qname, qtype, rcode, answer, ts; force clients through controlled resolvers; block direct :53 egress.

Why caches make poisoning effective: every cache in the chain (browser, OS, stub, recursive resolver) shortens the next lookup, but a poisoned recursive resolver serves the fake answer to every client behind it until the TTL expires. That is why hardening targets the resolver — randomized transaction IDs and source ports, DNSSEC validation, 0x20 encoding.

Likely interview question: "One host produces an NXDOMAIN burst — benign or malicious?" Model answer: inspect the names first. Random-looking labels sharing a suffix point to DGA or a DNS beacon; repeated failures on one broken name usually mean a misconfigured application. Correlate with the endpoint process via EDR, check whether other hosts hit the same parent domain, and treat a steady cadence of unique labels as C2 until proven otherwise. Contain by sinkholing at the resolver rather than blocking DNS.

2.8 HTTP/HTTPS

• Methods: GET reads, POST submits, PUT replaces, PATCH partially updates, DELETE removes, HEAD is GET without a body, OPTIONS advertises capabilities, TRACE echoes the request (TRACE/OPTIONS are often disabled because they can reflect credentials or map the app).
• Status codes: 200 OK and 201 Created succeed; 301/302 redirect (open redirects are an abuse vector); 304 cached copy still valid; 400 malformed request; 401 authentication missing or failed; 403 authenticated but not authorized; 404 not found (a flood of 404s is path enumeration); 405 method not allowed; 429 rate limited; 500/502/503 server failures whose spike often means a successful application-layer DoS.
• Headers: Host, User-Agent, Cookie/Set-Cookie (HttpOnly, Secure, SameSite), Authorization, X-Forwarded-For (client-spoofable — trust only behind your proxy), CSP, Strict-Transport-Security.

Headers are the web layer's security controls. HttpOnly blocks JavaScript cookie theft, Secure restricts the cookie to TLS, SameSite=Lax/Strict limits cross-site sending (CSRF), CSP constrains script sources, HSTS forces HTTPS, and X-Forwarded-For must only be trusted when your own proxy adds it. A quick review finding: a session cookie set without Secure and HttpOnly, or an app trusting the first X-Forwarded-For value it receives.

Likely interview question: "401 vs 403 — what is the difference?" Model answer: 401 is an authentication problem and the client should re-authenticate; 403 is an authorization decision for an already-identified user, so re-authenticating will not help. A resource returning 403 to one user and 200 to another is normal RBAC; it flipping to 200 when an object ID in the request changes is broken access control (IDOR). - Sessions: server issues a random session ID (in a cookie) — rotate it at login, set idle + absolute timeouts. Fixation = attacker plants a known ID before login; hijacking = steals the ID (XSS, cleartext sniffing). - HTTPS = HTTP over TLS on 443 → confidentiality, integrity, server authentication. TLS does not fix SQLi/XSS — that's the WAF.

2.9 TLS 1.2 vs 1.3 + HSTS

Flow: TCP → ClientHello (random, ciphers, SNI, key_share) → ServerHello + key share (everything after is encrypted in 1.3) → Certificate + CertificateVerify (signs transcript, proves private key) → Finished (HMAC over full transcript) → app data. Forward secrecy = a stolen server private key can't decrypt past recorded sessions.

Analyst notes: SNI, ALPN, IPs, timing and sizes stay visible; cipher/version visible in ServerHello; cert only visible in TLS 1.2 captures or with SSLKEYLOGFILE. Flag TLS 1.0/1.1 and SSLv3 as findings.

HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload forces HTTPS for that domain, defeating SSL-strip downgrade. preload ships the domain in browser hardcoded lists.

PKI in 60s: chain = leaf → intermediate(s) → root (root pre-installed in the OS/browser trust store; clients verify chain, hostname, expiry). Inspect with openssl s_client -showcerts; monitor expiry to avoid outages. Revocation: CRL / OCSP (stapling = server fetches and staples the OCSP response — faster + private). Flag as findings: RC4, 3DES (Sweet32), CBC (Lucky13), SHA-1, TLS_RSA_* (no forward secrecy), TLS 1.0/1.1/SSLv3.

Forward secrecy with a concrete timeline: under static RSA key exchange, an attacker records two years of traffic, later steals the server's private key, and decrypts all of it. With (EC)DHE the private key only signs the exchange — each session has an ephemeral secret that is discarded — so the recordings stay unreadable. This is why the model answer to "why TLS 1.3?" leads with mandatory forward secrecy.

Where defenders go blind: SNI, destination IPs, byte counts, timing and the DNS lookups before the connection stay visible on TLS 1.3; certificate details need a TLS 1.2 capture or key material, and Encrypted Client Hello hides the inner SNI. When those signals disappear, endpoint telemetry and flow metadata become the primary evidence instead.

2.10 SSH

Port 22. Phases: TCP → version banner → KEX (curve25519/ECDH → session keys) → server host-key signature (client checks known_hosts; mismatch = possible MITM) → auth (publickey preferred, password weak, MFA) → encrypted channels (session, -L/-R/-D tunnels). Hardening: PermitRootLogin no, PasswordAuthentication no, keys+passphrase, AllowUsers, fail2ban, MFA/certs, ship auth.log to SIEM. SSH tunnels are uninspectable — SOC watches volume/duration anomalies.

Why known_hosts is not a nuisance prompt: the first connection asks you to trust the server's public key and stores it. A later key change is exactly what a man-in-the-middle looks like, so stop and verify out of band — a genuine rebuild and an attack are indistinguishable from the client side.

Tunnel shapes and why the SOC watches them: ssh -L 8080:internal-app:80 user@jump forwards a local port through the jump host; -R publishes a local service remotely (common in support and in attacks); -D 1080 opens a SOCKS proxy for arbitrary destinations. All three can carry traffic no other control inspects, so baseline SSH destinations, volumes and durations per host.

2.11 FTP / SMTP / SMB / RDP

2.12 Top 30 Ports (memorize)

Also know: 465 SMTPS, 853 DNS-over-TLS (DoT) — SOC-relevant with the DoH/DoT discussion in §2.7.

FTP is the clearest "why encryption matters" story. Credentials and files cross in cleartext — control on 21, data on 20 (active) or a random high port (passive) — so ftp || ftp-data plus tcp contains "PASS" recovers them in Wireshark. SFTP on 22 or FTPS on 990 replaces it, and passive mode plus NAT needs the firewall to understand the data channel.

SMTP's three ports do three jobs. 25 is server-to-server relay, 587 is authenticated client submission (STARTTLS), 465 is implicit TLS submission. Phishing triage reads the Received chain top to bottom, compares Return-Path with the visible From, and checks SPF, DKIM and DMARC alignment — a message can pass SPF and still be phishing if it is not aligned with the displayed domain.

SMB and RDP are the two Windows services that keep appearing in incidents. SMB 445 was the propagation path for EternalBlue/WannaCry because it reached untrusted networks; RDP 3389 is a top initial-access method because credentials are guessed, sprayed or bought. Neither belongs on the public internet — put them behind a VPN or jump host, restrict sources, require MFA, and log authentication attempts.

2.13 Firewalls: Stateless vs Stateful vs NGFW vs WAF

How a stateful firewall makes a decision: when the first outbound SYN matches a policy, the device creates a session entry holding the 5-tuple, TCP state and timeouts; return packets are matched to that entry instead of the rulebase, so replies need no inbound rule of their own. A bare inbound ACK with no session is dropped as out-of-state, which is why half-open scans (nmap -sS) and spoofed-ACK probes appear in logs differently from a full connect.

A concrete rule pair to practise on: permit tcp 10.20.0.0/24 any eq 443 log is specific enough to audit; permit ip any any above it makes every later rule unreachable and is equivalent to having no policy at all. The skill being tested is spotting the broad rule, proving what it shadows, and writing impact rather than just flagging it.

Firewall rule review checklist: default-deny at the end; no any-any permits; named src/dst/service objects not raw IPs; shadowed rules (unreachable behind a broader earlier rule) removed; redundant/duplicate removed; unused rules (zero hits 90 days) decommissioned after owner confirmation; risky services (Telnet/FTP/SMB/RDP/SNMP) never exposed to lower-trust zones; logging on deny and sensitive permits; every rule has owner/ticket/expiry; emergency any-any rules time-boxed; specific-before-general ordering; management plane unreachable from user nets; recertify at least every 6 months where PCI applies.

2.14 IDS vs IPS vs SIEM vs SOAR vs EDR

Hook: IDS sees, IPS stops, SIEM correlates, SOAR acts, EDR lives on the endpoint. Signature = known-bad (fast, misses zero-days). Anomaly = deviation from baseline (finds new attacks, noisy). Heuristic/behavioral = suspicious patterns (PowerShell spawning cmd.exe).

The trade-offs behind those detection types: signatures are fast and precise but only see what someone has already written a rule for; anomaly detection can catch novel behaviour but needs a tuned baseline or it floods the queue; behavioral rules such as "Office spawns PowerShell, which then makes an outbound connection" sit between the two and are what most EDR detections actually are. In the queue, value comes from correlation: one failed login is noise; failed logins, then a success from a new country, then a large upload is an incident.

Where each product sits in the evidence chain: the IDS/IPS sees the wire, the firewall the connection and its action, the proxy the URL, the EDR the process and its parent, and the SIEM is the only place those views meet. Practise that handoff line.

2.15 VPN: IPsec vs SSL

Mnemonic: IPsec = network-to-network; SSL VPN = user-to-network/app. ZTNA (per-app access, identity+device posture) is the modern replacement for broad VPN trust.

How IPsec negotiates, in two phases: IKE phase 1 builds an authenticated, encrypted channel between the peers and establishes a shared secret; phase 2 negotiates the security association that protects data — ESP, algorithms, key lifetimes, and which traffic is "interesting." Tunnel mode encapsulates the whole original packet, which is why site-to-site uses it and why internal addresses stay hidden. ESP provides confidentiality plus integrity; AH is integrity-only and does not survive NAT.

Gotchas that make good interview material: overlapping private ranges at both ends (both sites on 10.0.0.0/8), NAT-T on UDP 4500 when a device translates ESP, and MTU/PMTUD problems because tunnelling adds headers. Remote-access VPNs often run TLS over 443 precisely so they pass hotel and airport networks that block IPsec.

2.16 VLANs, Segmentation, and How to Prove It

A VLAN is a logical L2 broadcast domain on shared hardware; 802.1Q adds a 4-byte tag. Access port = one VLAN; trunk port = many. Inter-VLAN traffic must cross an L3 device (router/L3 switch/firewall) — that's where policy lives. Microsegmentation does the same inside workloads/VPCs (security groups, Kubernetes NetworkPolicies, service mesh). Purpose: limit lateral movement and blast radius.

How to prove segmentation works: (1) review topology + ACLs; (2) run authorized scans from inside each zone across the boundary both directions — expected ports must time out/refuse; (3) query flow logs/NetFlow/Zeek for successful cross-zone traffic that policy forbids; (4) test alternate paths (IPv6, management VLANs, trunk misconfig) and confirm default-deny; (5) keep dated evidence: scan output, rule export, flow query, diagram. Repeat quarterly and after changes.

2.17 Zero Trust

Never trust, always verify; assume breach; least privilege; verify explicitly per request (identity + device posture + context); microsegment; no "trusted internal network." Building blocks: IdP + MFA, device compliance, per-app access instead of network access, mTLS east-west, full logging, continuous re-evaluation. Kills the "castle-and-moat" failure mode where one foothold = full network access.

2.18 Proxy vs Reverse Proxy vs Load Balancer

• Forward proxy fronts clients: hides client IPs, URL filtering, egress logging, caching.
• Reverse proxy fronts servers: TLS termination, caching, hiding origin, can host the WAF.
• Load balancer: L4 (TCP/UDP, fast, IP:port) vs L7 (HTTP-aware routing by path/host/cookie, health checks). Often one device does all three.
• NAT gateway (e.g., cloud NAT): managed SNAT letting private subnets reach the internet — L3, no URL filtering, no inbound-initiated connections; unlike a forward proxy (L7, URL-aware).

2.19 Attacks: MITM, SYN Flood, DDoS, IP Spoofing

• MITM: ARP spoofing, DNS spoofing, rogue Wi-Fi/evil twin, SSL strip, BGP hijack. Defenses: TLS + cert validation + HSTS, DAI, pinning, MFA, monitoring.
• SYN flood: half-open exhaustion (see 2.2). Defenses: SYN cookies, backlog tuning, rate limiting, scrubbing.
• DDoS — L3/L4 volumetric (UDP/ICMP floods, DNS/NTP amplification via spoofed sources) vs L7 application (HTTP flood, slowloris, credential stuffing — looks legitimate). Defenses: anycast/CDN absorption, scrubbing, rate limits + CAPTCHA, autoscaling, WAF bot rules.
• IP spoofing: forged source IP enables amplification/reflection and bypasses IP allowlists. Defenses: BCP38/uRPF ingress filtering, never trust source IP, return-path checks. Blind TCP spoofing needs ISN guessing because the attacker can't see replies.
• Replay: resending a captured valid message; defenses are nonces, timestamps, TLS anti-replay (0-RTT needs server-side anti-replay).

A DDoS case in three phases, because the answer is layered: volumetric floods (spoofed UDP/ICMP, DNS/NTP/memcached amplification) saturate the pipe, so mitigation is upstream — anycast/CDN absorption and scrubbing. State-exhaustion attacks (SYN flood, fragments, TLS handshake exhaustion) burn firewall and load-balancer tables, so mitigation is SYN cookies, connection limits and timeouts. Application-layer floods (request floods, slowloris, credential stuffing) look like real users and are stopped with WAF rules, rate limits and bot management. Name the phase before the control. Amplification works because a small spoofed UDP query to an open resolver produces a large reply at the victim, which is why BCP38/uRPF at the source is the structural fix. Likely question: "Bandwidth normal, CPU high?" Answer: suspect an L7 flood; check request rate per endpoint, connection states, WAF logs and load-balancer connections, then apply WAF/bot controls.

2.20 Hub vs Switch vs Router

2.21 IPv6 Security

IPv6 removes NAT as an addressing necessity, which breaks assumptions: global unicast addresses are routable, fe80::/10 link-local exists on every interface, fc00::/7 ULA replaces RFC 1918, and internal hosts often hold globally routable addresses — so "behind NAT" is not a control, every host and cloud security group needs its own inbound policy, and every IPv4 rule needs an IPv6 twin or the rule set is an open door on the other stack. Neighbor Discovery (ICMPv6 133–137) replaces ARP and is equally unauthenticated: forged Neighbor Advertisements poison the neighbor cache — IPv6 ARP spoofing and MITM — and a rogue Router Advertisement can claim the default gateway or advertise a bogus prefix. Defences: RA Guard (RFC 6105, updated by RFC 7113) on access ports not facing a router, SEND (RFC 3971) for cryptographic signing, DHCPv6-Shield (RFC 7610) against rogue DHCPv6 servers, host firewalls on internal servers, and no unneeded Teredo/6to4/ISATAP tunnels, which can bypass IPv4-only controls. Interview one-liner: ARP spoofing becomes NDP cache poisoning plus rogue RAs; only the defence names change.

2.22 QUIC and HTTP/3 from a Security View

HTTP/3 (RFC 9114) runs over QUIC (RFC 9000), a transport built on UDP 443 with TLS 1.3 integrated into the handshake (RFC 9001). It merges transport and crypto setup — one round trip to usable, 0-RTT on resumption — and gives each stream independence, so one lost packet does not block every response unlike TCP head-of-line blocking; connections also survive a client IP change (connection migration). Security consequences: forward secrecy and AEAD are mandatory; almost the whole header is encrypted; an Initial packet must be at least 1200 bytes; and a server may send at most three times the bytes it has received from an unvalidated address until a Retry token proves the client, which caps UDP amplification. Caveats: 0-RTT data is replayable unless the server enforces anti-replay and restricts it to idempotent requests, and blocking UDP 443 silently forces clients back to TCP. Interview one-liner: defenders keep SNI (unless ECH), DNS history, destination IPs, sizes and timing, but lose URL/path inspection; HTTP/3 is reliable because QUIC reimplements reliability inside the encrypted UDP flow, not because UDP is reliable.

2.23 Cloud VPC Networking for a Retail Giant

Walmart's own security leadership and public coverage describe a hybrid estate across Google Cloud, Azure and a private cloud with edge infrastructure. The clouds share one model: a virtual private cloud (VPC) is an address space split into subnets per availability zone; public subnets route to an internet gateway; private subnets reach the internet only through an outbound-only NAT gateway (the PAT equivalent, not a firewall); and VPC-to-VPC or cloud-to-on-prem traffic crosses peering, a transit gateway/hub or private endpoints. Nothing is reachable unless a route and a permission both allow it. Security groups vs NACLs (the exam question): a security group is stateful and attached to an instance — allow-only, and return traffic is automatic; a network ACL is stateless and attached to a subnet, so both directions need explicit rules and it can deny specific ranges. Same stateful/stateless split as §2.13. Store, corporate, e-commerce and internal-app networks are separate trust zones, and flow logs plus security-group rules are how you prove what crossed a boundary; Walmart's security leadership describes moving segmentation from network location to identity so policy follows the workload. Interview one-liner: a VM in a private subnet reaches the internet through NAT but stays unreachable inbound until a route, a security group and a subnet ACL all permit it.

2.24 Full Walkthrough: What Happens When You Type walmart.com

Q2 gives the generic nine steps; run them once on Walmart's domain. Observations below are from a live curl -sI https://www.walmart.com and are examples, not constants. The browser parses the URL, applies stored HSTS (the live response returns strict-transport-security: max-age=31536000, so a returning visitor's http:// request is upgraded before it leaves the machine) and redirects walmart.com → www.walmart.com. Resolution goes stub → recursive resolver → root → .com → authoritative NS; today www.walmart.com resolves to *.akamaiedge.net, an Akamai edge chosen by geo/anycast, so origins are not directly exposed. Then TCP 443 and a TLS handshake with SNI www.walmart.com; the live response is HTTP/2 (x-ak-protocol: h2, cache-status: Hit), served from edge cache rather than origin. The retail layers around it: DDoS absorption at the edge, bot management in front of inventory drops and login, WAF rules in front of search and cart APIs, login rate limiting against credential stuffing, and separation between the storefront and payment/order systems — all of which becomes CDN/WAF, flow and load-balancer logs for the SOC. How to use it: deliver the generic path, then add the retailer details so the answer shows business context.

3. Real Interview Q&A (model answers)

Q1. Hub vs switch vs router? (documented Walmart India question) Hub: L1, floods every frame to all ports, one collision domain — sniffable by anyone. Switch: L2, MAC table, forwards only to the right port; each port its own collision domain; VLANs split broadcast domains. Router: L3, routes between subnets by IP, breaks broadcast domains, and is where ACL/NAT/firewall enforcement starts.

Q2. What happens when you type google.com and press Enter? (documented Walmart India question) (1) Browser parses the URL, checks its HSTS list → may upgrade to HTTPS. (2) Cache chain: browser → OS stub resolver → hosts; on miss, recursive query to the configured resolver, which iteratively asks root → .com TLD → Google's authoritative NS and returns an A/AAAA record (cached by TTL). (3) Routing: destination isn't local → default gateway; ARP resolves the gateway MAC. (4) TCP SYN → SYN-ACK → ACK on 443, or race QUIC/HTTP3 over UDP 443. (5) TLS 1.3 handshake: ClientHello (SNI, key_share) → ServerHello + encrypted cert → keys derived → Finished. (6) HTTP GET / HTTP/2 with Host, cookies, UA. (7) Server/CDN returns 200 or redirect. (8) Browser parses HTML, fetches CSS/JS/images, builds DOM, paints. (9) Connection kept alive or FIN/ACK teardown. Add NAT, load balancer, and caching as the scale layers.

Q3. TCP 3-way handshake — why 3, not 2? SYN(seq=x) → SYN-ACK(seq=y, ack=x+1) → ACK(ack=y+1). Both sides must synchronize ISNs and confirm the peer received the synchronization; 2 messages can't prove the server received the client's confirmation. Teardown is 4-way because each direction closes independently; RST aborts.

Q4. TCP vs UDP for video call, DNS, file transfer? Video: UDP — a dropped frame beats a stalled retransmit. DNS: UDP by default; TCP on truncation (classically 512 B, 1232 B with EDNS0) and for zone transfers. File transfer: TCP — integrity and ordering matter. QUIC shows the modern pattern: UDP transport with reliability implemented in the application.

Q5. Host shows 169.254.x.x — what's wrong? APIPA/link-local means no DHCP lease. Check the DHCP server/scope, VLAN, switch port, and cabling; the host self-assigned instead of reaching the network.

Q6. How does traceroute work? Sends packets with TTL=1,2,3…; each router decrements TTL and, at zero, returns ICMP Type 11 (Time Exceeded) with its IP. Source logs hop IPs and RTT. Linux uses UDP high ports, Windows ICMP, -T TCP SYN. * * * = a hop drops/rate-limits ICMP, not necessarily a failure.

Q7. Explain ARP spoofing, how you'd detect and stop it. Attacker sends forged ARP replies mapping the gateway IP to its own MAC, poisoning victim caches so traffic transits the attacker for MITM. Detect: one MAC claiming multiple IPs, gratuitous-ARP storms, inconsistent ARP entries, arpwatch/SIEM alerts. Stop: Dynamic ARP Inspection + DHCP snooping, static gateway ARP, port security, segmentation, TLS so intercepted traffic stays encrypted.

Q8. Which DNS records matter for email security? MX (delivery), SPF TXT (v=spf1 … -all), DKIM TXT (public key verifying signatures), DMARC TXT (_dmarc, p=none/quarantine/reject + reporting). Weak SPF or DMARC p=none is a common phishing finding.

Q9. How would you detect DNS tunneling from logs? Query names > ~50 chars; high-entropy/base32-like labels; 100+ unique subdomains to one parent domain per hour; sustained TXT/NULL queries; steady beacon intervals; one host resolving little else. Splunk: aggregate dc(query) and avg(len(query)) by src_ip + parent domain, threshold, then enrich with threat intel/Shannon entropy. Contain: block the domain, sinkhole at the resolver, isolate the host, force client DNS through controlled resolvers.

Q10. Stateless vs stateful firewall? Stateless evaluates each packet against a static ACL with no memory — fast but can't distinguish replies, forcing broad rules. Stateful keeps a connection table, auto-permits replies to outbound flows, validates flags/sequence, and times out idle sessions. NGFW adds L7 app/identity + IPS; WAF specializes in HTTP.

Q11. What do you check in a firewall rule review? Default-deny at bottom; no any-any or oversized CIDR permits; named objects not raw IPs; shadowed rules; redundant rules; zero-hit rules (90+ days); risky services exposed to untrusted zones; deny/sensitive-permit logging; owner/ticket/expiry on every rule; specific-before-general order; management access restricted. Output is a findings register with evidence, risk, owner, action.

Q12. IDS vs IPS vs SIEM vs SOAR vs EDR? IDS = passive, alerts on signatures/anomalies. IPS = inline, can drop/reset. SIEM = central aggregation + correlation (Splunk) pulling IDS/IPS/firewall/EDR/AD logs together. SOAR = playbooks automating response (enrich, block, ticket). EDR = endpoint telemetry + response (isolate host, kill process). Detect / prevent / correlate / automate / endpoint.

Q13. VPN: IPsec vs SSL, site-to-site vs remote access? IPsec (L3): IKE negotiates, ESP encrypts/integrity-protects, tunnel mode for site-to-site, NAT-T on 4500. SSL/TLS VPN (L7, 443): clientless browser or thin client for remote users through restrictive firewalls. Site-to-site joins networks; remote-access joins devices. ZTNA is replacing broad VPN trust with per-app access.

Q14. Guest VLAN host can reach the payment server — investigate? Confirm with an authorized scan/traceroute and flow logs (real path vs false positive). Check the L3 ACL between VLANs, trunk/native-VLAN config for hopping, VRFs/default gateways, and whether the VLANs share an L2 path via a misconfigured port. Inspect firewall hit counters and recent change tickets. Evidence: pcaps both sides, ACL config, flow records. Fix the rule/ACL, re-test (must fail), add monitoring for cross-zone traffic.

Q15. How would you prove segmentation to an auditor? Document zones + permitted flows; export config showing default-deny; run authorized cross-zone scans both directions showing timeouts/refusals; query flow logs for forbidden successful traffic; test alternate paths (IPv6, management VLAN); date-stamp all evidence. An untested boundary is just a diagram.

Q16. What is HSTS and what attack does it stop? Strict-Transport-Security: max-age=…; includeSubDomains; preload tells browsers to use HTTPS only for that domain for max-age, so an attacker can't SSL-strip the initial http:// request to a cleartext version. Preload hardcodes it before first visit. It doesn't fix mixed content or a compromised CA.

Q17. Suspected SYN flood — how do you investigate in Wireshark? Filter tcp.flags.syn == 1 && tcp.flags.ack == 0; use Statistics → Conversations to see one source/range hitting many ports with no completed handshakes; look for repeated SYN-ACK retransmits and huge spoofed-source diversity. Correlate firewall/netflow and service health, then apply SYN cookies/rate limits/scrubbing.

Q18. Walk through a pcap of a suspicious host. Scope by host (ip.addr == x), protocol hierarchy for composition, DNS for odd/long names, TCP conversations for outbound destinations/beacons, TLS SNI/certs for self-signed or new domains, cleartext protocols for credentials, large transfers at odd hours, periodic traffic. Pivot pcap → firewall/NetFlow/DNS logs → endpoint telemetry.

Q19. Why does DNS need both UDP and TCP? UDP by default: one round trip, cheap for the majority of small queries. TCP kicks in when the response doesn't fit the negotiated UDP buffer — classically 512 B (RFC 1035), 1232 B with EDNS0 today — the server sets the TC bit and the client retries over TCP; zone transfers (AXFR) always use TCP. So blocking TCP/53 breaks large answers and transfers.

Q20. Internal app offers TLS 1.0 and TLS_RSA_WITH_3DES_EDE_CBC_SHA — severity and fix? Medium-high: no forward secrecy (a stolen static RSA key decrypts all recorded sessions) plus weak crypto (3DES = Sweet32, CBC = Lucky13, SHA-1). Fix: disable TLS 1.0/1.1 and static-RSA suites; allow only TLS 1.2/1.3 with ECDHE + AES-GCM/ChaCha20-Poly1305, then re-verify with nmap --script ssl-enum-ciphers -p 443.

4. Hands-On: Commands, Wireshark Filters, Nmap Scans

Linux commands

ip addr show                     # interfaces + IPs
ip route show                    # routing table / default gateway
ip neigh                         # ARP cache
# netstat -tulpn is deprecated on Linux → modern replacement: ss -tulpn
ss -tulpn                        # listening TCP/UDP sockets + owning process
ss -tan state established        # active connections
tcpdump -i eth0 -nn -c 50        # first 50 packets, no name resolution
tcpdump -i eth0 -nn 'tcp port 443 and host 1.1.1.1'
tcpdump -i eth0 -nn -A 'tcp port 80' | grep -i 'pass\|user'   # cleartext creds check
dig google.com A +short          # DNS lookup
dig +trace google.com            # watch root → TLD → authoritative resolution
dig -x 8.8.8.8                   # PTR reverse lookup
nslookup -type=TXT _dmarc.example.com
traceroute -T -p 443 target.com  # TCP traceroute past ICMP blocks
curl -vI https://example.com     # headers + TLS info
openssl s_client -connect example.com:443 -tls1_3 -servername example.com
nmap -sV --script ssl-enum-ciphers -p 443 example.com   # cert + cipher audit
sudo ss -s                       # socket summary (SYN-flood symptoms)

Wireshark display filters (security-focused)

ip.addr == 10.0.0.5                                    # one host
ip.addr == 10.0.20.0/24                               # subnet
tcp.flags.syn == 1 and tcp.flags.ack == 0              # SYN only → scan / SYN flood
tcp.flags.reset == 1                                   # resets
tcp.analysis.retransmission                            # retransmits (loss/attack)
dns                                                    # all DNS
dns.flags.response == 0 and frame.len > 150            # long queries → tunneling
dns.qry.name contains "suspicious"                     # specific domain
dns.flags.rcode != 0                                   # NXDOMAIN etc.
tls.handshake.type == 1                               # ClientHello (SNI, ciphers)
tls.handshake.type == 2                               # ServerHello (chosen cipher/version)
tls.handshake.extensions_server_name contains "example.com"   # SNI — use contains; == misses subdomains
tls.alert_message                                     # TLS failures/downgrade
http.request                                          # HTTP requests
http.request.method == "POST"
http.response.code >= 400
tcp contains "password"                               # cleartext credential search
ftp || telnet                                         # legacy cleartext protocols
arp                                                   # ARP traffic (spoofing review)
vlan.id == 20                                         # one VLAN
tcp.stream == 5                                       # one conversation

Workflows: Follow → TCP/HTTP/TLS Stream to reassemble; Statistics → Conversations for top talkers; Protocol Hierarchy for overview; Export Objects → HTTP to extract files. Add SSLKEYLOGFILE in Preferences → Protocols → TLS to decrypt your own TLS 1.3 traffic.

Nmap scans

nmap -sn 192.168.1.0/24                   # host discovery / ping sweep
nmap -sS -p- 10.0.0.10                    # SYN half-open scan, all 65535 ports (root)
nmap -sT -p 1-1000 10.0.0.10              # TCP connect scan (no root, logged by target)
nmap -sU -p 53,67,123,161 10.0.0.10       # UDP scan (DNS/DHCP/SNMP/NTP)
nmap -sV -sC 10.0.0.10                    # version detection + default scripts
nmap -O 10.0.0.10                         # OS fingerprinting
nmap -A 10.0.0.10                         # aggressive: OS + version + scripts + traceroute
nmap -Pn 10.0.0.10                        # skip discovery (host blocks ICMP)
nmap --script vuln 10.0.0.10              # vuln NSE scripts (authorized only)
nmap --script smb-vuln-ms17-010 -p 445 10.0.0.10   # EternalBlue check
nmap -T4 -oA results 10.0.0.10            # timing + save output

Only scan systems you're authorized to test. Be ready to justify flags: -sS speed/stealth, -sT unprivileged/proxy, -sU only for UDP services you care about, -sV/-sC triage, -Pn when ICMP is filtered.

Tie-in to your resume (say this out loud)

• PeerWatch (Go P2P custom TCP protocol): "I implemented framing/sequencing on raw TCP, so I've debugged half-open connections, retransmits, and teardown at packet level — I verified each handshake and stream in Wireshark."
• Wireshark: "I use display filters and Follow TCP Stream to separate DNS/TCP/TLS and spot scanning, tunneling, and cleartext credentials."
• Judge0 sandbox networking: "The sandbox enforces network isolation; I verified egress blocks by testing from inside the container and reasoned about namespace/VLAN-style segmentation — control plane reachable, workload not."

5. One-Day Quick Revision Table

6. Common Mistakes

1. "TCP is reliable because of ACKs" and stopping — add sequencing, retransmission, flow control (window), congestion control.
2. Calling a switch a "smart hub" — hub = one collision domain and floods; switch forwards by MAC, per-port collision domains.
3. Confusing ARP (IP→MAC) with DNS (name→IP) — extremely common slip.
4. Saying NAT is a security control — it's topology hiding; stateful filtering is separate.
5. Wrong handshake order (SYN, ACK, SYN-ACK) — write it out correctly every time.
6. Claiming HTTPS is invisible to defenders — SNI, certs (on 1.2/keylog), sizes, timing, destinations are visible; TLS inspection exists.
7. Saying TLS 1.3 is always 0-RTT — 1-RTT normally; 0-RTT only on resumption and it's replayable.
8. IDS vs IPS muddle — IDS alerts, IPS blocks inline.
9. Treating SIEM as just detection — it's correlation/aggregation; SOAR automates response.
10. Calling a WAF a firewall — a WAF parses HTTP (SQLi/XSS); a network firewall doesn't.
11. VPN = encryption only — it's also authentication and authorization; ZTNA replaces broad network trust.
12. VLAN vs subnet — VLAN is L2, subnet is L3; usually mapped 1:1 but different concepts.
13. Trusting X-Forwarded-For/source IP — spoofable; trust only proxy-set values.
14. Scanning without authorization — always say "with written authorization" in scenario answers.
15. "Block DNS" for tunneling — breaks the business; detect/scope with length, entropy, and unique-subdomain cardinality instead.
16. Default-deny without ordering awareness — a permissive rule above it negates it; check shadowing.
17. Hand-waving segmentation — always end with "prove it with cross-zone scans and flow-log queries."
18. "IPv6 is just IPv4 with longer addresses" — NDP replaces ARP with the same spoofing problem, Router Advertisements can be forged, and NAT-based assumptions no longer protect anything.
19. Calling a network ACL stateful — NACLs are stateless (both directions need explicit rules); security groups are stateful. Mixing them up breaks return traffic in a design answer.
20. Saying QUIC/HTTP3 is untraceable — SNI (unless ECH), DNS history, destination IPs, sizes and timing stay visible; only URL-level inspection is largely lost.