Back/Cybersecurity/Networking & Protocols

Networking & Protocols

Every attack and every defence happens over a network. Understanding TCP/IP, DNS, HTTP, and packet analysis is the foundational knowledge that makes all security work possible — offensive or defensive.

Beginner

TCP/IP & OSI Model

How data moves across the internet. The seven-layer OSI model and the TCP/IP stack every security professional must know.

Intermediate

Wireshark & Packet Analysis

Capture and analyse live network traffic. Identify attacks, debug protocols, and see what data is actually being sent.

Beginner

DNS, HTTP & TLS

The protocols that power the web. How DNS resolves names, how HTTP requests work, and how TLS encrypts them.

Intermediate

Network Scanning

Nmap, port scanning, service enumeration, and building a complete picture of a target network.

Intermediate

Cryptography Fundamentals

Symmetric and asymmetric encryption, hashing, digital signatures, and PKI — the mathematics protecting all secure communications.

Advanced

BGP & Enterprise Routing

BGP Autonomous Systems, OSPF, RPKI route origin validation, MPLS, and Internet peering architecture.

Intermediate

Cloud VPC & Virtual Networking

AWS/GCP VPCs, subnets, NAT gateways, Security Groups vs NACLs, Flow Logs, Transit Gateways, and Route53.

Intermediate

Wireless & Mobility Security

802.11 Wi-Fi frames, WPA2/WPA3 SAE 4-way handshakes, 802.1X Enterprise, RADIUS, EAP, and Rogue AP detection.

Interview Scenarios

Real-world questions for Networking & Protocols

1How do you diagnose a server where TCP connections are hanging in SYN_RECV state?
A high count of SYN_RECV states indicates a SYN Flood DDoS attack (half-open connection queue exhaustion). To diagnose: Run netstat -anp | grep SYN_RECV or ss -t -a state syn-recv. To fix: Enable SYN cookies in Linux sysctl (sysctl -w net.ipv4.tcp_syncookies=1), reduce SYN-ACK retries (net.ipv4.tcp_synack_retries=2), and configure rate-limiting firewall rules via iptables/firewalld.
2If hosts on a subnet can ping local IPs but cannot reach external domain names or 8.8.8.8, how do you fix it?
1. Check IP routing & gateway: Run ip route to verify default gateway (0.0.0.0 via gateway IP). If missing, add it via ip route add default via . 2. Check ARP: Run arp -an to verify gateway MAC resolution. 3. Check DNS: If pinging 8.8.8.8 works but domain names fail, check /etc/resolv.conf for valid nameserver entries and test resolution with dig +short A google.com.
3How do you isolate cleartext passwords or sensitive tokens from a 500MB PCAP file without opening the full Wireshark GUI?
Use TShark via the command line with display filters and field extraction to avoid GUI memory crashes: tshark -r capture.pcap -Y "http.request.method == POST" -T fields -e ip.src -e http.host -e http.file_data | grep -iE "pass|pwd|user|token|auth". For FTP or POP3 cleartext traffic: tshark -r capture.pcap -Y "ftp.request.command == PASS or pop3.request.command == PASS".
4If an external security scan flags your HTTPS website for weak SSL/TLS ciphers, how do you identify and fix it?
1. Diagnose: Run openssl s_client -connect domain.com:443 -cipher NULL,EXCH,DES,RC4 or use Nmap nmap --script ssl-enum-ciphers -p 443 domain.com. 2. Fix: Update your web server configuration (Nginx / Apache) to disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1, enforcing TLS 1.2 and TLS 1.3 only with AEAD ciphers: ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;.
5How do you detect if an attacker is using DNS Tunneling to exfiltrate stolen data from your network?
Inspect DNS query logs or PCAP traces for: 1. Unusually long QNAME subdomains (e.g. a3f910d8c2...secret.attacker.com). 2. High frequency of TXT or NULL record queries. 3. High volume of unique subdomains under a single apex domain. 4. High entropy in subdomain strings. Fix/Mitigate: Implement DNS Sinkholing, enforce strict outbound DNS filtering to authorized internal resolvers only, and deploy Snort/Suricata rules detecting high-entropy DNS subdomains.
6If application traffic experiences severe throughput degradation due to TCP Retransmissions and ZeroWindow events, how do you troubleshoot?
1. Capture: Record traffic with tcpdump (tcpdump -i eth0 -w dump.pcap). 2. Analyze: Run tshark -r dump.pcap -Y "tcp.analysis.flags" to isolate Dup ACKs, Retransmissions, and ZeroWindow flags. A ZeroWindow indicates the receiver's socket buffer is full. 3. Fix: Increase socket buffer limits in Linux sysctl (net.ipv4.tcp_rmem = 4096 87380 16777216, net.ipv4.tcp_wmem = 4096 65536 16777216) and inspect application event loops for blocking thread calls.
7How do you detect and mitigate a BGP Route Hijacking attack targeting your public IP prefixes?
1. Detection: Monitor global BGP routing tables via RPKI (Resource Public Key Infrastructure) validation and BGP monitoring services (e.g. BGPmon / RIPE RIS) for unauthorized Autonomous System (AS) path announcements. 2. Mitigation: Publish Route Origin Authorizations (ROAs) for all advertised IP prefixes, enforce RPKI Route Origin Validation (ROV) with your Tier-1 transit providers, and request upstream ISPs to filter invalid BGP prefix announcements.
8How do you calculate CIDR subnet boundaries for a /22 network and divide it into four equal /24 subnets?
A /22 mask provides 2^(32-22) = 1,024 IP addresses (1,022 usable hosts). To split a /22 network (e.g. 10.0.0.0/22): Subnet 1: 10.0.0.0/24 (10.0.0.1 - 10.0.0.254), Subnet 2: 10.0.1.0/24 (10.0.1.1 - 10.0.1.254), Subnet 3: 10.0.2.0/24 (10.0.2.1 - 10.0.2.254), Subnet 4: 10.0.3.0/24 (10.0.3.1 - 10.0.3.254). Broadcast addresses for each are .255, and network addresses are .0.
9How do you detect an ARP Cache Poisoning (Man-in-the-Middle) attack on a local switch segment?
1. Detection: Run arpwatch or inspect Wireshark/TShark for duplicate MAC addresses mapped to multiple IP addresses or rapid gratuitous ARP replies (tshark -Y "arp.duplicate-address-detected"). 2. Mitigation: Configure Dynamic ARP Inspection (DAI) on Layer-2 switches to validate ARP packets against a trusted DHCP Snooping binding database, dropping unauthorized ARP responses.
10If an IPsec VPN tunnel fails during Phase 1 or Phase 2 negotiation, how do you troubleshoot using CLI utilities?
1. Phase 1 (IKE SA): Check swanctl --log or journalctl -u strongswan. A failure in Phase 1 indicates mismatched IKE pre-shared keys (PSK), mismatched main/aggressive mode settings, or unresolvable gateway IPs. 2. Phase 2 (Child SA / ESP): If Phase 1 succeeds but Phase 2 fails, verify local/remote subnet definitions (traffic selectors) and ensure PFS (Perfect Forward Secrecy) Diffie-Hellman groups match on both endpoints.