Network Security
Network security isn't one firewall or one magic appliance. It's a pile of mostly unglamorous things working together: segmentation, locked-down management access, route filtering, logging, patching, and the discipline to keep it all tidy. The goal is simple to say: limit what an attacker, or just a misbehaving device, can reach.
Start with segmentation
On a flat network, everything trusts everything. That's a big blast radius. I like splitting things up by what they do and how much I trust them:
- Management interfaces
- Servers and storage
- Workstations and laptops
- Phones, cameras, and building systems
- Guest and untrusted Wi-Fi
- Backups and recovery systems
- Anything public-facing
The catch: making VLANs doesn't make anything more secure by itself. If the router happily routes between all of them, you've organized your network, not isolated it. The security comes from controlling what's allowed between the zones.
Default-deny where it counts
Between trust zones, toward management interfaces, and inbound from the Internet, I want default-deny: only allow what I've written down a reason for. For every rule, I like to know the source, destination, protocol, port, what it's for, and who asked for it. That last part matters a lot when you're cleaning up rules a couple of years later.
Example ACL
ip access-list extended USERS_TO_SERVERS permit tcp 10.20.0.0 0.0.0.255 host 10.50.0.25 eq 443 permit udp 10.20.0.0 0.0.0.255 host 10.1.0.53 eq domain permit tcp 10.20.0.0 0.0.0.255 host 10.1.0.53 eq domain deny ip any 10.50.0.0 0.0.0.255 log permit ip any any
Users can reach the web server on 443 and DNS (both UDP and TCP), everything else headed for the server subnet gets dropped and logged, and other traffic passes.
Lock down management access
If someone gets into your switches and routers, nothing else matters much. My list:
- SSH, HTTPS, and APIs. No Telnet, no plain HTTP.
- Only allow management from a dedicated subnet or over a VPN.
- Everybody gets their own account, backed by central authentication. No shared "admin."
- MFA wherever the platform supports it.
- Turn off services and interfaces you aren't using.
- Send config changes and logins to central logging.
- Back up configs, and actually test restoring one.
Layer 2 protections
Access switches have a bunch of features that stop spoofing, loops, and random devices:
- Port security: limits which MAC addresses can use a port.
- DHCP snooping: only trusted ports can answer DHCP. Kills rogue DHCP servers dead.
- Dynamic ARP Inspection: checks ARP against the DHCP snooping table, which stops ARP spoofing.
- IP Source Guard: drops traffic from addresses that don't match what the port was given.
- BPDU Guard: shuts down an edge port if a switch shows up on it. Turn this on everywhere users plug in.
- 802.1X: devices or users have to authenticate before they get network access.
Routing security
- Authenticate routing neighbors where you can.
- Use passive interfaces so nobody can start an OSPF adjacency from a user port.
- Filter routes at every trust boundary.
- Set max-prefix limits on BGP sessions.
- Use RPKI to check where public routes come from.
- Make sure internal, default, and infrastructure routes never leak to customers or peers.
Don't forget IPv6
IPv6 needs the same attention as IPv4. A common mistake is blocking it at the edge and forgetting it's running inside, where nobody's watching. Think about rogue router advertisements, Neighbor Discovery, DHCPv6, and whether your v4 and v6 firewall rules actually match.
Plan for DDoS before it happens
Mid-attack is a bad time to go looking for your upstream's NOC number. Write these down ahead of time: provider contacts, mitigation thresholds, blackhole communities, what normal traffic looks like, which prefixes need protecting, and how to move traffic to a scrubbing service. And remember: your firewall can't help if the attack has already filled the pipe upstream of it.
The ongoing stuff
- Keep an inventory of devices, software versions, and support status.
- Patch through a controlled process.
- Get rid of default passwords and shared admin accounts.
- Go through firewall and ACL rules and remove what's no longer needed.
- Watch for config changes and failed logins.
- Test config backups and out-of-band access.
- Keep emergency contacts and rollback steps written down.
- Make sure monitoring covers IPv4 and IPv6.
Don't overdo it
Every control costs you something to run. I'd rather have a design that's strict but still understandable at 2 a.m. during an outage. Rules nobody can explain, "temporary" exceptions from three years ago, and mystery policy routing all end up being security risks on their own.
Last Modified: October 12, 2026, 11:41 am