Network Security Basics¶

Network security is mostly about controlling who can talk to what, protecting the conversation while it happens, and noticing when the shape of the traffic changes. The tools are broad; the principles are simple.

This is a defensive cheat sheet. It focuses on protecting services and traffic, not on attacking them.

The Basic Goals¶

Network security usually aims to protect:

Confidentiality — the traffic and services are not readable by unauthorized parties.
Integrity — data is not altered in transit or in place without detection.
Authenticity — you have reasonable assurance you are talking to the intended party.
Availability — services remain reachable for legitimate users.

One control rarely does all of this. TLS helps confidentiality and integrity and supports authenticity. Firewalls help control who can reach what. Monitoring helps detect abuse.

TLS and HTTPS¶

TLS is the foundation for protecting traffic on the internet.

What TLS gives you¶

Encryption in transit
Server authentication through certificates
Integrity protection for the session

TLS does not solve everything. It does not fix bad authentication, weak application logic, or exposed data at rest.

Certificates¶

A certificate binds a public key to an identity, and is signed by a certificate authority or otherwise trusted by the client.

Common practical points: - Use certificates from a trusted CA for public services. - Use valid, non-expired certificates. - Match the certificate identity to the service. - Automate renewal where possible. - Protect private keys.

Self-signed certificates can be appropriate for internal systems, but they do not give the same trust guarantees as a public CA-backed certificate. They are useful, but they require the client to trust them explicitly.

HTTPS basics¶

HTTPS is HTTP over TLS. For web services: - Use HTTPS for anything handling sensitive data or user interaction. - Redirect HTTP to HTTPS where appropriate. - Avoid mixed content where possible. - Keep TLS configuration updated and avoid known-weak options.

Common mistakes¶

Using expired certificates
Misconfigured certificate names
Turning off validation in client code "to make it work"
Treating internal traffic as automatically safe
Ignoring TLS for services that will eventually be exposed

Certificates in Practice¶

Generate a key and CSR¶

For a certificate request:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr

This is a simplified example. Exact key type and size should match your policy and the service's needs.

Inspect a certificate¶

openssl x509 -in cert.pem -text -noout

Check a server's TLS setup¶

openssl s_client -connect example.com:443 -brief

These tools are useful for debugging and verification.

Renewal¶

Treat certificate renewal as an operational task, not a one-time setup. Automation reduces the chance of an embarrassing expiration outage.

Firewalls¶

A firewall filters or controls network traffic according to rules.

Host firewall vs network firewall¶

Host firewall — runs on the machine itself, controlling traffic to and from that host.
Network firewall — sits at a network boundary, controlling traffic between zones.

Both can be useful. A host firewall limits what reaches a server even if the network around it changes.

Default deny¶

A safe default posture is: - Deny inbound traffic by default. - Allow only what is needed. - Allow outbound as appropriate, with care.

Default-deny reduces the number of ways a service can be reached.

Rule discipline¶

Be specific.
Document why a rule exists.
Review rules periodically.
Remove rules that are no longer needed.
Avoid "allow everything" rules unless you have a temporary, well-understood reason.

A rule that stays forever "just in case" is often a future incident.

Ports and Services¶

Know what is listening¶

Before exposing a machine, know which services are reachable.

sudo ss -tlnp

or

sudo netstat -tlnp

You should be able to explain every listening port.

Common port concepts¶

Lower-numbered ports are often used by well-known services.
A listening port means a service is ready to accept connections.
Not every service needs to be reachable from everywhere.
"It is running" is not the same as "it should be exposed."

Exposure review¶

Ask: - Who needs to reach this service? - From where? - Over what protocol? - With what authentication? - What happens if it is exposed more widely than intended?

If you cannot answer these, you are probably overexposed.

Network Segmentation¶

Segmentation means dividing a network into zones so that a compromise in one area does not automatically give access to everything.

Why segment¶

Limit lateral movement
Separate production from development
Isolate sensitive services
Separate user-facing services from internal infrastructure
Reduce the impact of a compromised host

Common zones¶

Public-facing edge
Application tier
Data tier
Management/admin network
Internal services not meant for general access

The exact design depends on size and risk. Even a simple split between "public" and "internal" is better than one flat network for everything.

Segmentation is not a silver bullet¶

If an attacker gets enough credentials or a vulnerable service inside a zone, segmentation can be bypassed or eroded. Treat it as one layer among many.

DNS¶

DNS translates names to addresses and is part of almost every network interaction.

Security-relevant points¶

DNS can be abused for exfiltration or tunneling in some scenarios.
DNS responses can be spoofed if not protected.
Internal DNS misconfigurations can leak information or break services.
Domain ownership matters for many trust decisions.

Operational basics¶

Use secure DNS configuration for services you control.
Monitor for unexpected DNS changes.
Keep domain registration and DNS hosting under controlled access.
Be careful with internal name exposure.

DNS is not glamorous, but many incidents involve DNS misconfiguration or abuse.

VPNs and Remote Access¶

A VPN creates an encrypted tunnel between networks or between a host and a network.

What a VPN can help with¶

Encrypting traffic over untrusted networks
Restricting access to internal resources
Centralizing remote access control

What a VPN does not do¶

It does not make the endpoint safe.
It does not replace authentication.
It does not fix insecure services behind it.
It does not eliminate the need for monitoring.

Remote access hygiene¶

Use strong authentication for remote access.
Limit who can connect.
Log access.
Revoke access promptly when roles change.
Prefer managed access patterns over long-lived broad access.

SSH Over the Network¶

SSH is often the primary remote admin path.

Network-level considerations: - Restrict where SSH is reachable from. - Prefer key-based authentication. - Consider bastion hosts for sensitive environments. - Watch for brute-force patterns in logs. - Disable or limit root access as appropriate.

SSH is a network service like any other: expose it deliberately, not accidentally.

Intranet is Not Automatically Safe¶

A common mistake is to assume that "internal" means "trusted."

Internal networks should still be treated with suspicion when: - An attacker may already be inside - A service is misconfigured - Credentials are compromised - A host is infected - The network is larger or more complex than you think

Zero trust is an extreme, but the underlying idea is useful: do not assume safety just because traffic is internal.

Monitoring Network Behavior¶

Good network visibility helps you notice abuse and misconfiguration.

Things to watch: - Unexpected listening services - Unusual outbound connections - Connections to unfamiliar hosts or ports - Sudden spikes in traffic - Repeated failed access attempts - Changes in DNS or service endpoints

Logs, flow data, and host telemetry together give a better picture than any one source.

Common Mistakes¶

Exposing services without deciding who should reach them
Assuming internal traffic needs no protection
Using self-signed or expired certificates in production without a real plan
Leaving old firewall rules lying around
Running unnecessary services on exposed hosts
Ignoring certificate renewal until there is an outage
Treating HTTPS as a substitute for authentication and authorization
Forgetting to secure management interfaces

cybersecurity-fundamentals — the broader security mindset
linux-security — hardening the host behind the network controls
owasp-basics — application-layer risks that network controls cannot fully prevent
cryptography-basics — the crypto underneath TLS and certificates
linux-commands — the commands used to inspect ports and connections

Official Documentation¶

TLS and OpenSSL: man s_client, man x509, and the OpenSSL documentation for your version
SSH: man ssh, man sshd_config
Firewall tools: documentation for ufw, firewalld, nftables, or iptables as appropriate
DNS: your domain registrar and DNS provider documentation, plus man dig and man host where relevant

Network security is built from many small, boring decisions. Make them deliberately.

Last Updated¶

2026-09-06 — Initial version.