Network Security Fundamentals

A junior embedded role at a company whose entire product line is network security appliances will assume you can talk about why the product exists, not just how sockets work -- this topic is that context.

A firewall's basic job is deciding whether to allow or block traffic based on rules, and the two broad approaches differ in how much they understand about what they're looking at. A packet-filtering (stateless) firewall looks at each packet in isolation -- source/destination IP, port, protocol -- and decides per-packet, which is fast but blind to context: it can't tell a legitimate reply packet from an unsolicited one arriving on the same port. A stateful firewall tracks active connections and only allows traffic that's part of a connection it already approved (or a genuinely new, permitted request), which closes that gap at the cost of more memory and processing per connection. A next-generation firewall (NGFW) goes further still, inspecting traffic up through the application layer -- which application protocol this actually is, not just which port it claims to use -- which is roughly the category Fortinet's own products compete in.

A DDoS (distributed denial-of-service) attack aims to exhaust a target's capacity -- bandwidth, connection slots, CPU -- using traffic from many sources at once, which is exactly what makes it hard to block with a simple IP-based rule: there's no single bad IP to drop. Mitigations lean on rate limiting, traffic scrubbing, and absorbing volume across distributed infrastructure rather than any single clever rule.

A man-in-the-middle (MITM) attack positions the attacker between two parties who believe they're talking directly to each other, able to read or alter traffic in transit. This is precisely the class of attack TLS is designed to prevent -- certificate validation is what stops an attacker from transparently impersonating the server, which is also why a security appliance terminating HTTPS to inspect it has to actively manage that trust relationship rather than sidestep it.

Buffer overflows, from the C topic earlier in this track, are a network security issue too, not just a memory-safety one -- a huge share of historical remote-code-execution vulnerabilities are a network service reading attacker-controlled input into a fixed buffer with no length check. This is exactly why input validation and safe string handling are treated as a security property of network-facing C code, not just a correctness nicety: the code parsing untrusted packets is the code with the most to lose from getting it wrong.

The principle of least privilege applies as much to a running service as to a person: a network daemon should run with only the permissions and network access it actually needs, so that if it is compromised, the blast radius is bounded by what that specific service was allowed to touch -- not the whole device.