Networking Every security product you own is a machine that watches, blocks or rewrites traffic. If you can trace one HTTPS request from a laptop to a server and name every hop, header and handshake on the way, most of Netskope, most of a SIEM and half of email security stop being mysterious.

Data is wrapped repeatedly on the way out and unwrapped on the way in. Posting a letter is the right mental image: your words go in a page, the page in an envelope with a street address, the envelope in a mail sack with a depot address, the sack on a lorry.

Each layer only reads its own header. A switch reads Ethernet. A router reads IP. A firewall usually reads IP + TCP. A SWG like Netskope has to break TLS to read the HTTP layer at all — which is the entire reason TLS inspection exists as a product feature.

Why security people care

• Your visibility is capped by the outermost layer you can decrypt. Everything below is just metadata.
• An attacker hiding inside an allowed layer (DNS queries, HTTPS to a legitimate CDN) is invisible to controls that only inspect the layer above.
• Log sources map to layers: firewall/flow logs = IP+TCP, proxy logs = HTTP, EDR = process that opened the socket. Correlating them is the job.

In conversation, "layer 3/4" means IP-and-port decisions (fast, blunt) and "layer 7" means content-aware decisions (slow, rich). "Layer 8" is a joke about the user.

• MAC address — burned into the network card, e.g. a4:83:e7:1c:9d:02. Only meaningful on the local segment; rewritten at every router hop. Modern OSes randomise it on Wi-Fi for privacy, which quietly breaks MAC-based NAC.
• IP address — the routable address, e.g. 10.4.2.17 or 2a00:1450::200e. Changes when you move networks.
• Port — which program on that host, e.g. 443. Server ports are conventional (80, 443, 25, 53, 3389); client ports are ephemeral and random.
• Domain name — human layer, resolved to IP by DNS. The only identifier an attacker can buy for £8.

A socket is the 5-tuple that uniquely identifies one conversation: protocol + src IP + src port + dst IP + dst port. Every firewall rule, flow log and connection table is built on this tuple — memorise it.

Private (RFC 1918) vs public

# private ranges — never routed on the internet
10.0.0.0/8          16.7M addresses — corporate/VPC default
172.16.0.0/12       1M — Docker likes 172.17.x
192.168.0.0/16      65k — home routers
169.254.0.0/16      link-local; 169.254.169.254 = cloud metadata!
127.0.0.0/8         loopback

The laptop knows the destination IP but must address the frame to a local MAC — the default gateway's. It shouts ARP: "who has 10.4.2.1?" Any machine on the segment can answer. There is no authentication in ARP at all.

VLANs slice one physical switch into isolated broadcast domains — the classic segmentation tool (guest Wi-Fi, card-data VLAN for PCI scope reduction, OT networks). Traffic between VLANs must cross a router or firewall, which is where you get to inspect and log it.

CIDR notation splits an IP into network and host parts. The number after the slash is how many leading bits are fixed.

Routing is a lookup: for each packet the host or router picks the most specific matching route. A /32 beats a /24 beats 0.0.0.0/0 (the default route, usually pointing at the internet gateway). Split-tunnel VPNs work exactly by injecting more specific routes for corporate ranges while leaving the default route alone.

# quick sanity checks you should be able to do mentally
10.4.2.17/24   -> network 10.4.2.0, hosts .1-.254, broadcast .255
is 10.4.3.9 in 10.4.2.0/24 ?  no  (third octet differs)
is 10.4.3.9 in 10.4.0.0/16 ?  yes

NAT rewrites source addresses so many private hosts share one public IP, keeping a translation table keyed on ports. Your office of 400 laptops appears to every SaaS provider as a handful of public IPs.

Consequences worth knowing: inbound connections need explicit port-forwarding or a reverse tunnel (which is why ZTNA uses outbound-only connectors); and CGNAT at ISPs means consumer IPs are shared too, so geo-IP and IP reputation are weak signals on their own.

TCP: reliable, ordered, stateful

Recognising these in tooling: a burst of SYNs with no completion = port scan or SYN flood. A connection that ends in RST immediately after the handshake often means a proxy or firewall killed it — useful when debugging why an app "randomly" fails behind Netskope.

UDP: fire and forget

No handshake, no ordering, no state. Used by DNS, DHCP, NTP, VoIP, and QUIC. Because it is stateless it is trivially spoofable, which is why UDP services are the favourites for amplification DDoS.

QUIC / HTTP/3

Google-originated, now standard: TLS 1.3 built into a UDP transport on port 443, with connection migration and faster handshakes. Security relevance is huge — many proxies and TLS-inspection engines cannot parse QUIC, so the standard practice is to block UDP/443 at the egress firewall, forcing browsers to fall back to TCP-based HTTP/2 where your SWG can see them. If someone reports "Netskope isn't logging Chrome traffic to that site", QUIC is suspect number one.

Record types you must know

DoH / DoT — encrypted DNS

DNS over HTTPS hides queries inside ordinary HTTPS to a resolver like 1.1.1.1 or dns.google. Great for privacy on hostile networks, awful for corporate visibility: it bypasses your DNS logging and DNS-layer blocking entirely. Standard enterprise posture is to disable browser DoH via policy and block known DoH endpoints, so that name resolution stays inspectable.

The chain is: leaf certificate → intermediate CA → root CA in the OS/browser trust store. Trust is transitive and entirely dependent on that store — which is precisely the hook TLS inspection uses.

What the padlock proves

• Yes: the traffic is encrypted in transit, and the server holds the private key for the name you typed.
• No: that the site is honest. paypa1-secure.com gets a free valid certificate in 90 seconds. Roughly all modern phishing is HTTPS.

SNI, ESNI/ECH

SNI is why a firewall with no decryption can still see which site you visited (but not the URL path or content). Encrypted Client Hello (ECH) hides even that — another erosion of network-only visibility, and another argument for endpoint and API-based controls.

TLS inspection, honestly

A forward proxy that inspects TLS terminates the client's session, opens its own session to the server, and re-signs certificates with a private CA that you push to every managed device. Consequences you will meet in production: certificate-pinned apps break (mobile apps, Dropbox, some updaters, many API clients), so every SWG ships a bypass list; and your proxy now holds plaintext for everything, making it a top-tier asset for both compliance scope and attacker interest.

POST /api/v2/files/upload HTTP/2
Host: app.example.com          which site (also in SNI)
Authorization: Bearer eyJhbGci…  the token worth stealing
Cookie: session=abc123          the other thing worth stealing
User-Agent: Mozilla/5.0 …       client claim, trivially forged
Content-Type: multipart/form-data a file is being uploaded
Referer: https://app.example.com/drive

Status classes: 2xx success, 3xx redirect (watch open redirects in phishing), 4xx client error (401 unauthenticated, 403 forbidden, 429 rate-limited — a burst of 401s is credential stuffing), 5xx server error.

A CASB inline policy such as "allow personal Gmail but block file uploads" is implemented exactly here: match the host, match the method and content type, inspect the body, decide. That is only possible with decryption — which ties this module back to the previous one.

Traffic steering — how you force endpoints through a proxy — is worth knowing because Netskope offers all of it: an OS-level agent/client, a PAC file, explicit proxy settings, GRE/IPsec tunnels from a branch router, or reverse-proxy interception via the IdP for unmanaged devices.

DNS

# what does this name resolve to, and who says so?
dig app.example.com A +short
dig example.com MX
dig example.com TXT              # SPF lives here
dig _dmarc.example.com TXT       # DMARC policy
dig selector1._domainkey.example.com TXT   # DKIM public key
dig @8.8.8.8 example.com +trace  # bypass local resolver, walk the hierarchy

HTTP

curl -v https://app.example.com/login        # full handshake + headers
curl -I https://app.example.com              # headers only
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://x
curl --resolve app.example.com:443:203.0.113.9 https://app.example.com
                                             # test a specific backend IP

TLS

openssl s_client -connect app.example.com:443 -servername app.example.com
# look for: issuer chain, SANs, notAfter, protocol/cipher chosen
# if the issuer is your own proxy CA, you are being inspected — expected on-prem

echo | openssl s_client -connect host:443 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Sockets and path

ss -tunap            # Linux: sockets + owning process (the pivot to EDR)
netstat -ano         # Windows equivalent; pair with tasklist /svc
lsof -i -P           # macOS: who has this port open
traceroute -T -p 443 app.example.com   # TCP traceroute; ICMP is often blocked
mtr app.example.com  # continuous path + loss, best for flaky links

Capture filters (BPF syntax) decide what gets written to disk. Display filters (Wireshark syntax) decide what you see afterwards. Different languages; using the wrong one is the classic beginner error.

# tcpdump — capture filter syntax
tcpdump -i any -nn host 203.0.113.9 and port 443 -w out.pcap
tcpdump -i any -nn 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'
   # bare SYNs = scanning
tcpdump -i any -nn -A port 53   # watch DNS in cleartext

# Wireshark — display filter syntax
tls.handshake.extensions_server_name == "app.example.com"
http.request.method == "POST" && http.content_type contains "multipart"
dns.qry.name contains "dropbox"
tcp.flags.reset == 1            # who is killing connections?
frame contains "password"

Useful Wireshark moves: Statistics → Conversations to find the top talkers, Follow → TCP Stream to read a whole exchange, and the Expert Information panel for retransmissions and resets.

The senior move is knowing which one answers the question fastest. "Did data leave?" → proxy bytes-out and SaaS audit logs. "What started it?" → EDR. "Where did it go?" → DNS plus flow. Any single source will mislead you.

Classic design assumed a hard shell and a soft interior. For a FinTech running SaaS plus cloud, that model is gone: the "network" is a laptop in a bedroom talking to APIs. Three things replace it.

• Identity as the control point — see the Identity path. Conditional access on user, device posture and risk.
• Device posture — managed, encrypted, patched, EDR healthy. Netskope and your IdP both consume this signal.
• Application-level access — ZTNA per app rather than routes into a network.

Egress filtering is still underrated. Servers should not be able to reach arbitrary internet addresses; allow-listing outbound destinations breaks most commodity C2 and exfiltration at a stroke, and produces excellent alerts when something tries. In AWS this means egress via NAT gateway plus a network firewall or proxy, with default-deny.

Microsegmentation

Restricting east-west traffic between workloads (security groups per service, not per VPC; Kubernetes NetworkPolicy). The test of a good design: compromise of one service should not grant network reachability to the database of another.

Any inline control needs traffic to physically pass through it. Options, with trade-offs:

Mature deployments layer several: agent for managed laptops, tunnel for offices, reverse proxy for contractors, API for data at rest. Netskope's page walks through each of these concretely.

• Trust store distribution — the proxy CA must land in the OS store and the stores that ignore it: Firefox, Java (cacerts), Python (certifi), Node (NODE_EXTRA_CA_CERTS), Git, and container images. Half of all "TLS inspection broke my tooling" tickets are one of these.
• Expiry management — certificates now max out around 13 months and are trending shorter. Anything not automated will eventually cause an outage at 2am.
• Revocation — CRL and OCSP are weakly enforced; short lifetimes are the real mitigation.
• mTLS — both sides present certificates. Common for service-to-service and for high-assurance API access; a strong alternative to shared secrets.

Modern C2 rarely uses a weird port. It uses HTTPS/443 to somewhere plausible, or DNS, because those are always permitted.

• Beaconing — regular check-ins with jitter. Detect on periodicity and low variance in request size, not on destination reputation. A host contacting one domain every 60s ±5% for eight hours is suspicious even if the domain is clean.
• DNS tunnelling — data encoded into subdomain labels and TXT answers. Detect on query length, entropy, query volume per domain, and rare parent domains with many unique children.
• Domain fronting / trusted-service C2 — traffic to Slack, Discord, GitHub, Google Drive, or a CDN edge that also hosts something malicious. Reputation is useless here; you need content or endpoint context. This is a strong argument for CASB app-instance awareness — distinguishing your Google tenant from a personal one.
• JA3/JA4 fingerprinting — hashes the ClientHello parameters, identifying the TLS client library even without decryption. A Python or Go TLS fingerprint from a laptop that should only run browsers is a great, cheap signal.

• Decryption bypass lists — every pinned app you exempted is a hole. Keep the list short, reviewed and documented.
• QUIC/HTTP3 — if UDP/443 is open outbound, some traffic is invisible to the proxy.
• DoH — if browsers can reach public DoH endpoints, DNS logging is partial.
• Unmanaged and personal devices — no agent, therefore only visible where they authenticate (IdP) or hit a reverse proxy.
• Cloud-to-cloud — SaaS-to-SaaS OAuth integrations never touch your network at all. Only API-based CASB and IdP app governance see them.
• Mobile — often the weakest telemetry, yet full mail and SSO access.

Writing this list down, with a compensating control per line, is exactly the artefact that turns a network conversation with a regulator or a client's TPRM team from defensive to credible.