Covers core networking concepts and the security controls used to protect data and services across the network stack. Candidates should understand the open systems interconnection model and the Internet Protocol suite, including responsibilities and behaviors at the physical, data link, network, transport, and application layers. Be able to explain transmission control protocol packet flow, ports and sockets, network address translation, and how client server interactions use protocols such as Hypertext Transfer Protocol, Hypertext Transfer Protocol Secure, Domain Name System, and Dynamic Host Configuration Protocol. Understand how encryption and authentication are applied at different protocol layers, including Secure Sockets Layer and Transport Layer Security, the role of certificate authorities and digital certificates, and how the Transport Layer Security handshake protects data in transit. Be able to distinguish secure and insecure protocols, describe common network attack patterns such as eavesdropping, man in the middle, spoofing, and distributed denial of service, and articulate mitigation techniques including virtual private networks, secure configuration of services, segmentation, and basic host and network hardening. Candidates should also know fundamental controls such as stateful and stateless firewalls, proxying, and secure remote access, and be familiar with detection and troubleshooting tools and techniques such as packet capture, flow analysis, packet logging, and traffic inspection.
EasyTechnical
41 practiced
Define and contrast the following network attack patterns: eavesdropping, man-in-the-middle (MITM), IP or ARP spoofing, and distributed denial-of-service (DDoS). For each attack, give one realistic mitigation or detection control an Information Security Analyst could implement (e.g., encryption, DAI, ingress filtering, rate-limiting, scrubbing centers).
Sample Answer
**Eavesdropping (Passive interception)** - Definition: Attacker quietly captures network traffic to read sensitive data (e.g., sniffing plaintext HTTP, unencrypted Wi‑Fi). - Contrast: Passive — attacker doesn't alter packets. - Mitigation/Detection: Enforce TLS everywhere (HSTS, certificate pinning) and monitor for unusual plaintext credential transmissions with a SIEM rule.**Man‑in‑the‑Middle (Active interception and alteration)** - Definition: Attacker intercepts and can modify or inject traffic between endpoints (e.g., Wi‑Fi rogue AP, HTTPS proxy with forged cert). - Contrast: Active vs eavesdropping; can alter sessions. - Mitigation/Detection: Deploy TLS mutual auth or HTTP public key pinning; detect via anomalous certificate chains or TLS fingerprint mismatches in IDS.**IP/ARP Spoofing** - Definition: Attacker forges source IP/MAC to impersonate hosts or redirect traffic (ARP cache poisoning). - Contrast: Layer 2/3 identity falsification enabling MITM or bypass. - Mitigation/Detection: Enable Dynamic ARP Inspection (DAI), use static ARP for critical devices, and log ARP anomalies.**DDoS (Resource exhaustion)** - Definition: Distributed flood of traffic or requests to overwhelm bandwidth, CPU, or application resources. - Contrast: Availability-focused, volumetric or state‑exhaustion attack. - Mitigation/Detection: Use upstream scrubbing/anycast CDN, rate‑limit, and set traffic anomaly alerts in NDR/SIEM.Each control above is practical for an Information Security Analyst to tune, monitor, and validate.
MediumTechnical
40 practiced
You see the following tcpdump snippet (timestamps shortened):12:00:01.000000 IP 10.0.0.5.54321 > 203.0.113.10.443: Flags [S], seq 1000, length 012:00:01.010000 IP 203.0.113.10.443 > 10.0.0.5.54321: Flags [S.], seq 2000, ack 1001, length 012:00:01.020000 IP 10.0.0.5.54321 > 203.0.113.10.443: Flags [R], seq 1001, length 0Interpret what likely happened here. What are at least three plausible causes for the immediate RST from the client after SYN-ACK? Describe the next investigative steps and what additional data sources you would collect to confirm the root cause.
Sample Answer
**Brief interpretation**The trace shows a three-way handshake started by client 10.0.0.5 (SYN), server 203.0.113.10 replied (SYN+ACK), and the client immediately sent a RST. That indicates the client refused or didn’t recognize the SYN-ACK — the TCP connection was aborted before being established.**Three plausible root causes**- Application/socket closed: the client process that initiated the SYN exited or closed the socket before receiving the SYN-ACK, so the OS discarded the half-open state and sent RST.- Local firewall/endpoint security: host-based firewall or EDR blocked/terminated the connection upon seeing the server response, producing an RST.- Asymmetric NAT or connection tracking mismatch: NAT device or stateful firewall lacks a matching session (e.g., mapping expired or different external IP), so client TCP stack sees SYN-ACK as unsolicited and resets; or the SYN-ACK was spoofed (server IP spoof) and rejected.- Other possibilities: race condition (simultaneous open), TCP options/mss/seq mismatch, or middlebox (IPS) actively resetting.**Investigation steps & data to collect**- Obtain full pcap (both client-side and server-side) around the timestamps to see packet payloads, TCP options, retransmits, TTLs, IP IDs.- Collect host logs from 10.0.0.5: syslog, endpoint protection/EDR alerts, application logs, netstat/tcp states, process start/stop times.- Check network device logs: NAT/edge firewall connection-tracking, IPS/IDS alerts, firewall rules changes, and NAT timeouts.- Capture tcpdump on the server to confirm it received SYN and whether it saw the RST; compare IP/port addresses and sequence/ack values.- Query SIEM for correlated events (scans, spikes, failed connections) and check for recent config changes or deployments.- Reproduce from the client while running verbose logging and packet capture; test with and without endpoint protection/firewall to isolate.- If spoofing suspected, check for source-IP anomalies, multiple SYN-ACKs, and routing asymmetry (traceroutes from both ends).These steps will distinguish benign client-side closes from policy/middlebox interference or malicious spoofing.
MediumTechnical
42 practiced
Describe how ARP spoofing (ARP poisoning) can be used for local man-in-the-middle attacks. Provide at least three detection or mitigation techniques you would deploy in a switched LAN (for example: dynamic ARP inspection, static ARP entries, arpwatch). Describe limitations of each technique and how an analyst would verify an attack is occurring.
Sample Answer
**Brief attack description**ARP spoofing: attacker sends forged ARP replies on a LAN to associate their MAC with another host’s IP (gateway or victim), causing traffic to be routed through attacker’s NIC — enabling local MITM (eavesdrop, modify, drop).**Detection / Mitigation techniques**1. Dynamic ARP Inspection (DAI)- What: Switch validates ARP against DHCP snooping binding table; drops invalid ARP.- Limitation: Requires DHCP snooping enabled and correct bindings; doesn’t help for static IPs; added config/CPU on switches.2. Static ARP entries / IP-to-MAC binding on critical hosts- What: Configure fixed ARP mappings on servers/gateway.- Limitation: Not scalable for many hosts; operational overhead; vulnerable to local admin compromise.3. arpwatch + SIEM correlation- What: Host-based/service that logs MAC↔IP changes and alerts on frequent changes; integrate with SIEM to detect bursts of gratuitous ARPs.- Limitation: False positives in mobile/VM environments; needs tuning.Additional: switch port-security (limit MACs per port), IDS/IPS signatures for ARP poisoning, and network segmentation.**How an analyst verifies an attack**- Observe rapid/gratuitous ARP replies on mirror/span port or packet capture (tcpdump/wireshark): repeated ARP replies mapping gateway IP to multiple MACs.- Check switch CAM table for flapping MACs across ports (show mac address-table).- Correlate logs: DHCP snooping denies, DAI drops, arpwatch alerts, and unexpected ARP TTL-less traffic.- Active test: send ARP probe for target IP and inspect authoritative response; use arping from a trusted host to confirm mismatch.Use these signals together to reduce false positives and then isolate offending port/device.
HardSystem Design
38 practiced
Design a secure remote-access architecture for 300 distributed employees that follows zero-trust principles. The environment includes SaaS applications, internal web applications, and an on-prem datacenter. Your design should cover identity and access controls, device posture verification, network controls (VPN vs agent-based ZTNA), logging/visibility, scalability and resilience. Provide a migration path from a legacy VPN and a list of measurable success criteria.
Sample Answer
**Clarify requirements & constraints**- 300 remote employees; mix SaaS, internal web apps, on‑prem datacenter; must follow Zero Trust; replace legacy VPN gradually; high availability and logging for detection/response.**High-level architecture**- Identity plane: Central IdP (Azure AD / Okta) with SAML/OIDC, enforced MFA (phishing-resistant: FIDO2 / TOTP backup), conditional access policies.- Access plane: Agent-based ZTNA client (Cloud SWG/SASE + ZTNA like Zscaler/AppGate) for device‑initiated connections; per‑app micro‑segmentation for internal web apps via reverse proxy connectors into datacenter.- Device posture: Endpoint agent (MDM + EDR — Intune + Defender/Carbon Black) reporting posture (patch level, disk encryption, AV, firewall); posture attested to IdP/Access Broker via device certs.- Network controls: Decommission full‑tunnel VPN; keep split‑tunnel short‑term for legacy hosts behind secure jumpbox; prefer agent ZTNA for least privilege access.- Logging & visibility: Central SIEM (Splunk/Elastic) ingest logs from IdP, ZTNA, MDM, EDR, SWG, firewall, and datacenter NAC; EDR telemetry + network flow (NetFlow) for threat hunting.- Scalability & resilience: Cloud SASE with regional PoPs, active‑active connectors into datacenter, redundant IdP with disaster recovery, autoscaled agents/services.**Data flow (simplified)**User → Agent/ZTNA → IdP conditional access → Posture attestation → Short‑lived access token → Per‑app broker → SaaS or on‑prem app**Migration path**1. Baseline: Inventory apps, legacy VPN usage, identify apps supporting modern auth.2. Pilot (50 users): Deploy IdP SSO + MFA + posture checks for high‑risk group; deploy ZTNA to pilot group; route internal app access via app proxy.3. Expand: Migrate SaaS apps to SSO; move internal web apps behind reverse proxies; enforce posture and block legacy auth gradually.4. Phase out VPN: Move remaining VPN users to jumpbox/ZTNA; decommission VPN when usage ≈0.5. Post‑migration: Harden, run red team, continuous tuning.**Measurable success criteria**- 100% SaaS apps on SSO + MFA within 6 months- Reduction of VPN active users to 0 in 90 days after pilot completion- 100% endpoints compliant with posture policy (patch, encryption, EDR)- Mean time to detect (MTTD) < 15 minutes; mean time to respond (MTTR) < 2 hours- No successful lateral movement in purple team tests; reduction in high‑severity incidents by 60% year over year- 99.95% access availability (SLA) for remote users**Role-specific actions I’d perform**- Tune SIEM rules and dashboards for ZTNA, IdP, EDR signals; create playbooks for conditional access incidents; run daily review of posture failures and escalate remediation; coordinate phased rollout and user training.
EasyTechnical
36 practiced
Describe the TCP three-way handshake in detail (SYN, SYN-ACK, ACK). Include which TCP flags and sequence/acknowledgement behaviors are used. As an analyst, how does understanding the handshake help you detect a SYN flood or suspicious connection patterns? Describe one mitigation (e.g., SYN cookies, connection rate-limiting) and how it defends against the attack.
Sample Answer
**Definition & steps (three-way handshake)** - Client -> Server: SYN set, Seq = x, Ack = 0 — starts connection. - Server -> Client: SYN+ACK set, Seq = y, Ack = x+1 — server acknowledges client's SYN and sends its own. - Client -> Server: ACK set, Seq = x+1, Ack = y+1 — client acknowledges server's SYN. Sequence numbers advance by one for the SYN/ACKed byte; ACKs reflect next expected byte.**Why this matters to an analyst** - Normal flow: brief SYN then SYN+ACK then ACK completes within ms–s. - SYN flood indicator: many SYNs from same or spoofed IPs with few/no corresponding ACKs; large SYN-to-ESTABLISHED ratio; many half-open sockets in connection-tracking tables. I monitor SYN/ACK-to-ACK ratios, connection state counts, and unusual source diversity in NetFlow/pcap.**Example detection signals** - Spike in incoming SYNs (> baseline threshold) - High COUNT(TCP state = SYN_RECV) on servers/load balancers - Low return ACKs and many SYNs from sequential/invalid source ports (possible spoofing)**Mitigation — SYN cookies (how it defends)** - Instead of allocating state on SYN, server encodes necessary state into the initial sequence number in the SYN+ACK (a cookie). Only when a valid ACK returns does the server rebuild state. This prevents resource exhaustion because memory isn’t consumed for spoofed/never-completing handshakes. Works well with connection rate-limiting and firewall rules to reduce attack impact.**Operational notes** - Combine SYN cookies with rate-limiting, IP reputation, and connection-tracking thresholds. - Monitor for collateral effects (SYN cookies can limit TCP options like large window scaling).
Unlock Full Question Bank
Get access to hundreds of Network Fundamentals and Security interview questions and detailed answers.
