Chapter 9: Networking and Network Security

9.1 Why.

Welcome to Chapter 9.

I am Ravindra Bagale.

Raju drew two boxes on paper: app and database. He drew one straight line between them. He had no engineering degree. He had confidence. "Packets will find the way," he said.

Guru-ji took the pencil and drew a third box labeled vendor laptop, then a dashed arrow from that laptop straight into the database. "In a flat network, every cable is a hallway. The vendor who came to fix the air conditioner should not greet the card data. Swiggy restaurants, Paytm wallets, Amazon orders, BHIM UPI intents, WhatsApp messages, Zomato menus, Netflix streams, Infosys client projects, and PayFast checkouts all need walls. The wall is not rude. The wall is the product."

Raju erased the dashed arrow. He put a firewall box in the middle and labeled the only allowed path: app tier to database port. Guru-ji nodded. "That label is network security. TCP carries the bytes. TLS wraps them so a listener on the wire reads noise. DNS names the door. Segmentation decides which rooms connect. Without that picture, Chapter 8's hardened host still sits in an open warehouse."

9.2 What.

OSI and TCP/IP, without theatre. People teach seven OSI layers and four TCP/IP layers. Remember the jobs. Link moves frames on a local segment. Internet moves packets between networks with IP. Transport delivers ports and reliability ideas with TCP or lighter UDP. Application is HTTP, DNS, and the rest. ARP finds a MAC for an IPv4 neighbor on a LAN. NDP does related work for IPv6. You do not need to recite every header field. You need to know which layer your control sits on. A firewall rule on port 443 is transport and application adjacent. A VPC route is network. A cable mistake is physical, and it still ruins your day.

IPv4, IPv6, routing, NAT, DNS, DHCP. Addresses name interfaces. CIDR describes networks: a prefix and a length. Route tables say where packets go next. A gateway is the next hop out. NAT rewrites addresses so many private hosts share a public identity, or so a cloud service presents a stable front. DHCP hands out addresses. DNS turns names into addresses. If DNS lies, users walk into the wrong shop. If DHCP is open to anyone on a hostile LAN, addresses and options can be poisoned. Defend the management of these services as carefully as you defend SSH.

TCP handshakes, TLS, HTTP. TCP starts with a handshake so both sides agree to talk. TLS then negotiates keys and authenticates the server with a certificate, and sometimes the client too. After TLS, HTTP requests ride inside the encrypted tunnel. HTTPS is that pairing. HTTP/2 and HTTP/3 change framing and sometimes the underlying transport; the security idea remains: encrypt on the wire, verify who you are speaking to, and do not send secrets on plain cleartext on networks you do not trust. Pin your minimum TLS version in server config on systems you own. Turn off ancient ciphers your lab scanner still flags.

Subnetting, route tables, gateways, proxies. Split address space so app, data, and management are not one soup. Public subnets hold load balancers. Private subnets hold apps and databases. A proxy or egress gateway can force outbound traffic through inspection. An ingress controller or reverse proxy terminates TLS and forwards to the app. Write the routes on paper before you click the console. A wrong default route can send private traffic on a tour of the internet.

Firewalls, stateful versus stateless, security groups, NACLs. A stateful firewall remembers a connection and allows the reply. A stateless filter judges each packet alone. Cloud security groups are usually stateful and attach to instances or network interfaces. Network ACLs are often stateless and attach to subnets. Use deny-by-default. Allow the few ports you need from the few sources you need. Log rejected attempts that matter. Do not open 0.0.0.0/0 to a database port because a tutorial wanted convenience. Convenience is how Target-shaped stories begin.

VPN, IPsec, WireGuard, SSH tunnels, bastions. A VPN extends a private network across an untrusted path with encryption. IPsec and WireGuard are common families. An SSH tunnel can forward a single port for a lab session; it is not a replacement for a designed VPN, and it must not become a forgotten back door. A bastion host is the controlled door for operators. Prefer short-lived access through an identity-aware path when you have it. MFA on the VPN identity matters. A password that never expires on a VPN account is a gift.

Load balancers, reverse proxies, ingress, egress. North-south traffic enters and leaves the city. East-west traffic moves between services inside. Load balancers spread north-south load and often terminate TLS. Egress controls stop a compromised app from calling every address on the internet. Allow lists for outbound payment partners beat open egress. Ingress should not forward admin ports.

Segmentation and microsegmentation. Segmentation is the big walls: VPC, subnet, VLAN, security zone. Microsegmentation is finer: this pod may speak only to that pod on that port. Zero Trust Network Access says identity and device posture matter more than sitting on the "right" IP. You still need the walls. Identity without segmentation leaves a stolen token free to wander.

DNS security. DNSSEC adds signatures so a resolver can detect tampered answers when the chain is deployed. Split-horizon DNS gives internal names different answers than the public ones. DNS rebinding tricks a browser into treating an external name as an internal address; frameworks and browsers harden against this, and you should not invent a lab that practices the trick against someone else's network. Monitor for sudden DNS changes on domains you own. Protect registrar accounts with MFA.

IDS/IPS, packet capture, flow logs. Flow logs tell you who talked to whom. Packet capture shows the bytes when you need depth. IDS watches and alerts. IPS can block. In cloud estates, enable VPC flow logs. In a lab, practice tcpdump on traffic you generate yourself. Capturing other people's traffic without permission is not a lesson in this course.

DDoS, rate limiting, bot mitigation. Floods exhaust bandwidth, connections, or application capacity. Rate limits shed abusive clients. Bot mitigation challenges automation. CDNs and specialized DDoS services absorb volumetric noise for many public sites. Design so a single instance is not the only shield. Chapter 3 already named denial of service as a STRIDE word. Here you place the network controls.

Service mesh and mTLS. In a mesh, sidecars wrap service calls with mutual TLS and identity. The service account or SPIFFE-style identity replaces "anyone on the flat network." You still authorize the object. Encryption of the hop is not authorization of the order id.

Trace a packet on paper. Client on the internet, DNS to your name, TCP to the load balancer on 443, TLS handshake, HTTP to the reverse proxy, hop to the app subnet, app queries the database subnet on the database port, reply returns. At each arrow write the control: security group, certificate, and authentication. If an arrow has no control, draw a red question mark. That mark is your homework.

Target-shaped segmentation lesson, without the crime script. A vendor network that can reach a point-of-sale network is a missing wall. Payment systems belong behind strict allow lists. Analytics systems that need sales data get a cleaned feed, not a cable into the till. Write that as a diagram for a shop in the shape of Amazon or Swiggy. Do not write how to traverse someone else's plant network.

IPv6 awareness. Dual-stack hosts may be reachable on IPv6 even when you only wrote IPv4 firewall rules. If you enable IPv6, filter it with the same care. If you disable it, do so on purpose and consistently. Surprise addresses are surprise doors.

Proxies and inspection. A forward proxy can authenticate outbound users. A reverse proxy protects inbound apps. TLS inspection on enterprise egress is a policy choice with privacy and trust implications; if you terminate TLS to inspect, you become part of the trust chain and must protect that inspector like a CA-adjacent system. Document the choice. Do not invent silent interception on networks you do not administer.

WhatsApp-shaped and BHIM UPI-shaped traffic. Chat and payment apps teach the same network morals at different stakes. Message contents and payment intents both deserve encryption in transit, pinned trust where mobile pins apply, and backends that do not expose admin APIs on the same edge that serves the world. Zomato and Swiggy live on the same morals for customer personal data and partner portals. Netflix-shaped streaming adds volume: DDoS and bot controls become part of availability, which is part of security.

Lab traceroute ethic. Tools that map paths are fine on your lab and on paths you are authorized to study. They are not a license to map a stranger's estate. When this course says "trace client-to-application packets," it means packets you caused on infrastructure you own.

Security group examples for a lab, as sentences not as attack material. The edge load balancer accepts 443 from the world, or from your office IP during early testing. The app group accepts only the load balancer's group on the app port. The database group accepts only the app group on the database port. The bastion group accepts SSH only from your admin IP. The bastion may SSH to the app group. Nobody else may. Write those five sentences in your notebook before you click. Then implement them twice: once in the cloud console or Terraform-shaped file, once on the host firewall. When they disagree, the wider one wins for the attacker. Make them agree.

East-west stories. Microservices in an Amazon-shaped shop talk constantly. If every pod can reach every pod, a single stolen process identity can browse the mesh. Network policies that default deny, then allow named pairs, shrink that blast. A service mesh adds mTLS so a fake caller without the right identity fails the handshake. Paytm-shaped payment workers should not accept "mark paid" from a random report generator on the same cluster. Infosys on a multi-tenant platform must keep client A traffic from client B's namespace. The diagram from Chapter 3 returns here with IP and identity crayons.

DHCP and rogue devices on a lab LAN. On a home lab switch you own, notice how easy it is for a new device to get an address. In an enterprise, 802.1X and inventory reduce surprise. For DevSecOps, the lesson is: treat newly seen MAC addresses and newly seen flows as interesting. Flow logs make "newly seen" visible. Without logs, the hallway is dark.

Certificate names and HTTP Host headers. TLS checks the name. Virtual hosts check the Host header. Misaligned names cause either outages or dangerous fallbacks. In your lab, issue a certificate for the exact name you browse. Do not disable verification to "make it work" and then forget. Chapter 10 will deepen PKI. Here, know that HTTPS without verification is theatre.

DDoS layers in one paragraph. Volumetric floods fill pipes. Protocol floods exhaust state tables. Application floods request expensive work. Defenses sit at the ISP or CDN for volume, at the load balancer for connection discipline, and at the app for expensive-query limits. Rate limits from Chapter 3 meet network controls here. Bots that create fake Swiggy-shaped orders or fake PayFast checkouts are business and network problems together.

Documentation that survives handoff. Paste a simple mermaid-free diagram into the repo as the SVG you already have, plus a markdown table of rules. When someone asks why port 5432 is open from the app group, the table answers in one line. Tribal memory is not a control.

9.3 How.

1. Write "own lab only" and draw the trust zones: internet, edge, app, data, and management.
2. Allocate CIDR blocks so zones do not overlap by accident.
3. Place the load balancer in the public edge and the database in private data with no public IP.
4. Write security group rules as numbered allow lines with source, port, and reason.
5. Deny by default everything you did not list.
6. Terminate TLS at the edge with a valid certificate you control in the lab.
7. Force HTTP to redirect to HTTPS on the lab web server.
8. Set a minimum TLS version and cipher suite policy your lab scanner accepts.
9. Enable flow logs or the equivalent on the lab virtual network.
10. Generate your own HTTP traffic and capture it with tcpdump on the lab interface; confirm you see TLS records, not clear passwords.
11. Add a host firewall that mirrors the cloud rules so a mis-associated security group is not your only hope.
12. Create a bastion or use an identity-aware cloud shell pattern; do not expose SSH from 0.0.0.0/0 if you can avoid it.
13. If you use a VPN into the lab, turn on MFA at the identity provider.
14. Split DNS so internal names are not published on the public zone by mistake.
15. Protect the domain registrar account with MFA and a registered lock if offered.
16. Rate-limit the lab login endpoint so a noisy script from your own test machine gets a 429.
17. Draw east-west rules: app may reach database port; app may not reach the management subnet.
18. If you run two app services, deny cross-talk except on the ports you name.
19. Document egress: which external hosts the app may call, such as a payment partner API shape.
20. Review one week of flow logs for unexpected pairs of talkers.
21. Practice failing a rule on purpose in the lab and watching the drop counter or log line.
22. Tear down temporary debug rules the same day you add them.

23. Stop before any packet leaves toward a company network you do not own.

24. Write a one-page network threat model: spoofing on the wire, tampering in transit, information disclosure on cleartext, denial of service floods, and elevation via flat east-west paths.

25. For each of those five, write one control you already placed in the lab diagram.
26. Schedule a calendar reminder to review temporary firewall rules every Friday.
27. If you use WireGuard or IPsec into the lab, store the peer keys in a secrets manager pattern from Chapter 10, not in a chat paste.
28. Confirm IPv6 rules match IPv4 intent, or document that IPv6 is off on purpose.
29. Stop again. No scanning of Netflix, WhatsApp, Amazon, or any foreign network.

9.4 A real public incident.

Name. Target Corporation payment-card breach.

Date. Intrusion activity related to the breach was publicly tied to November and December 2013. Target announced the breach in December 2013, with further public detail in the weeks that followed.

Source. Target's December 2013 public statements, the U.S. Senate Committee on Commerce, Science, and Transportation's 2014 staff report on the Target data breach, and contemporary reporting by Krebs on Security. This chapter summarizes those public accounts. It does not provide a method to recreate the intrusion.

What happened. Attackers obtained a foothold through credentials connected to a third-party vendor that provided facilities services. Public reporting described movement from that foothold into parts of Target's network that reached systems related to point-of-sale, and the theft of payment-card data affecting roughly forty million card accounts, with additional records of personal information discussed in later figures around seventy million people. Firewalls and monitoring existed. Segmentation between vendor access, corporate systems, and payment environments was not strong enough to stop the path. A vendor should be able to do a job without inheriting a hallway into the till.

How to stop.

1. Cut the path between compromised vendor access and payment systems.
2. Rotate credentials and keys that may have been used.
3. Take affected point-of-sale systems through a clean rebuild process under incident command.
4. Work with card brands and banks on fraud monitoring.
5. Tell customers and regulators as required.

How to prevent it again.

1. Segment vendor access into its own zone with allow lists that name only the systems that vendor must reach.
2. Keep payment networks separate from general corporate and facilities networks.
3. Monitor east-west flows for new talkers.
4. Require MFA and least privilege on any remote access path.
5. Practice tabletop exercises where a vendor laptop is assumed lost.
6. Build the diagram in your own lab. Do not probe a retailer's network.

This is for learning only, and only inside a system you are allowed to test.

9.5 A simple picture.

Internet, edge, app, data. Allowed arrows only. A vendor dashed line that tries to skip the walls is blocked.

9.6 A short animation.

Client and server wave through a TLS handshake. Then the bytes are ciphertext. Clear secrets do not walk that road.

9.7 Conclusion.

Raju redrew the line. The database no longer shared a hallway with the world. Guru-ji closed the pencil box. "Packets are honest. They go where the routes and rules allow. Your job is to make the allowed set small. In Chapter 10 we protect the keys that TLS and the apps demand: secrets, certificates, and the PKI chain that says who to trust."

• TCP/IP names the path. TLS wraps the bytes. DNS names the door.
• Firewalls and security groups deny by default and allow with reasons.
• Segmentation stops a vendor zone from greeting a payment zone.
• Flow logs and captures on your own traffic teach what the rules really did.
• Target, December 2013, is the segmentation lesson.
• Own lab only.

END OF CHAPTER 9 MASTER CLASS