Contents

Chapter 1

Network Security Fundamentals

Network security is built on a simple premise: control what traffic is allowed into and out of your systems, and verify that your controls work. Every layer — perimeter, host firewall, service hardening, detection — assumes the layer before it has been bypassed.

The Defense-in-Depth Model

A production network faces threats at multiple levels:

Perimeter — The edge router or cloud security group that separates your network from the internet. This is your first line of defense, but it's also the most likely to be compromised.

Host firewall — The iptables or nftables ruleset running on each server. This assumes the perimeter has been breached and enforces a default-deny policy regardless of network position.

Service hardening — SSH configuration, TLS settings, application-level access controls. This layer secures individual services against compromise even if network controls are bypassed.

Detection — IDS/IPS, audit logging, and anomaly detection. This layer identifies when the preceding layers have failed.

Default-Deny vs Default-Allow

The single most impactful change you can make is switching from default-allow to default-deny. In a default-allow policy, all traffic is permitted unless explicitly blocked. A single misconfiguration opens your entire network. In a default-deny policy, only explicitly permitted traffic is allowed. Everything else is logged and dropped.

Apply default-deny at every layer: security groups, host firewalls, application middleware, and egress filtering.

Network Segmentation

Segment your network into zones based on function and risk:

Public/DMZ — Services that face the internet. Web servers, API gateways, load balancers.

Application — Services that process business logic but don't directly face the internet. Application servers, message queues.

Data — Databases, data warehouses, backup storage. The most sensitive zone.

Management — Admin access points, jump boxes, monitoring infrastructure. Strictly controlled access.

Each zone should have its own firewall rules. Traffic between zones must be explicitly permitted and logged.

Chapter 2

Host Firewall & Segmentation

The host firewall is the most critical security control on any Linux server. It enforces policy at the closest point to the workload and remains effective even if the network perimeter is compromised.

iptables vs nftables

Linux offers two firewall frameworks. iptables is the legacy system with separate tools for IPv4, IPv6, and bridging. nftables is the modern replacement with a unified syntax, better performance, and atomic rule replacement.

Choose nftables for new deployments. It provides:

  • A single nft command for all address families
  • Atomic ruleset loading (no brief window without rules)
  • Named sets and maps for cleaner rule organization
  • Better performance on high-traffic systems

This product includes both so you can use whichever your distribution supports.

Building a Default-Deny Ruleset

A default-deny host firewall follows this pattern:

# Default policy: drop all incoming and forwarding traffic
# Default policy: allow all outgoing (restrict later)

# Allow established/related connections (responses to outbound)
# Allow loopback interface traffic
# Allow SSH from management network only
# Allow specific service ports (HTTP/HTTPS, etc.)
# Log and drop everything else

Every rule includes a reason in its comment. Every service port is explicitly documented. No catch-all "allow all" rules exist.

Zone-Based Segmentation

For multi-service environments, implement zone segmentation using nftables sets:

zone_dmz = { web-server-01, web-server-02 }
zone_app = { app-server-01, app-server-02 }
zone_data = { db-primary, db-replica }

Define inter-zone policies: DMZ can initiate connections to App on specific ports. App can initiate connections to Data on specific ports. No zone can initiate connections to Management. Management can initiate connections to all zones for administration.

Safe Application

When applying firewall rules remotely, always use a dead-man's switch: schedule a job that flushes the rules after 2 minutes, then apply the new ruleset. If the rules lock you out, the flush job runs and restores access. Cancel the flush job after confirming the rules work.

Chapter 3
🔒 Available in full product

IDS/IPS with Suricata

Chapter 4
🔒 Available in full product

VPN & Remote Access Hardening

Chapter 5
🔒 Available in full product

Verification & Monitoring

You’ve reached the end of the free preview

Get the full Network Security Toolkit and unlock everything.

All Chapters

Get the complete guide with every chapter unlocked, including code samples, diagrams, and best practices.

Full Tool Suite

Access all interactive tools with complete data, all workload profiles, and the full scenario library.

Source Files

Downloadable source code, configuration files, and working examples from every chapter.

Lifetime Updates

Free updates for life. Every new chapter, tool, and improvement included.

Buy Now — $49 →
📦 Free sample included — download another copy for the full product.
Network Security Toolkit v1.0.0 — Free Preview