Security Introduction

In this lesson we cover web security fundamentals focused on an Nginx environment. You’ll learn why HTTPS matters, how TLS protects data in transit, which HTTP security headers to use, how to restrict access with Nginx basic authentication, ways to allow or block traffic with Nginx directives, and a brief overview of automating IP blocking with Fail2Ban. Roadmap — what you’ll accomplish in this module:

Why HTTPS matters for web security and SEO, and why plain HTTP is unsafe for production.
How SSL/TLS secures data in transit and the high-level mechanics of the protocol.
Useful HTTP security headers and how to apply them in Nginx.
Protecting parts of your site with Nginx basic authentication.
Allowing and blocking traffic using Nginx allow / deny directives.
A short overview of Fail2Ban for automated IP blocking (demo limitations noted).

A presentation slide titled "Objectives" listing three points: (1) why HTTPS matters for web security and SEO, (2) how SSL/TLS secures data transmission, and (3) HTTP headers and their applications. The slide features a blue-green gradient left panel with colored numbered markers.

Why HTTPS and TLS

HTTPS (HTTP over TLS) protects confidentiality and integrity of data exchanged between clients and servers. It also increases user trust and can improve SEO ranking.
Avoid plain HTTP for public-facing production services. Use HTTP only for constrained internal testing where the risk is accepted.

For local development: mkcert

For local and playground environments you can use mkcert to create locally-trusted certificates. Public CAs such as Let’s Encrypt require a real DNS name and public accessibility, so mkcert is more convenient for local testing.

mkcert is a developer tool that generates locally-trusted TLS certificates. For production, prefer CA-signed certificates such as those from Let’s Encrypt and Certbot, which require a valid domain and DNS verification.

Quick mkcert example (local dev)

# Install mkcert (example for macOS with Homebrew)
brew install mkcert nss

# Create and install the local CA (one-time)
mkcert -install

# Generate a certificate for localhost and custom dev hostnames
mkcert localhost dev.localhost
# Produces files like: localhost+1.pem and localhost+1-key.pem

TLS at a glance

TLS authenticates the server (and optionally clients), negotiates a protocol version and cipher suite, and derives symmetric session keys to encrypt traffic.
The handshake exchanges key material and verifies identities, then all subsequent traffic is encrypted.
Best practices: use TLS 1.2 or 1.3, prefer modern cipher suites (AEAD ciphers like AES-GCM or ChaCha20-Poly1305), enable HSTS in production, and disable old insecure protocols/ciphers.

HTTP security headers — what to use and why The most useful headers to reduce common web attack surface:

Header	Purpose	Example / Recommended value
`Strict-Transport-Security` (HSTS)	Forces browsers to use HTTPS for the domain	`max-age=31536000; includeSubDomains; preload`
`Content-Security-Policy` (CSP)	Restricts sources for scripts, styles, images, mitigating XSS	`default-src 'self'; script-src 'self' 'nonce-...';`
`X-Frame-Options`	Prevents clickjacking by restricting embedding	`SAMEORIGIN`
`X-Content-Type-Options`	Prevents MIME sniffing	`nosniff`
`Referrer-Policy`	Controls what referrer information is sent	`no-referrer-when-downgrade` or `strict-origin-when-cross-origin`
`Permissions-Policy`	Controls access to browser features (camera, microphone)	`geolocation=(), camera=()`

Note: X-XSS-Protection is deprecated and ignored by many modern browsers; rely on a well-crafted Content-Security-Policy instead. Example Nginx server block that adds common security headers:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/certs/example.com.pem;
    ssl_certificate_key /etc/nginx/certs/example.com-key.pem;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header X-XSS-Protection "1; mode=block" always;

    # Consider adding a Content-Security-Policy (CSP) tailored to your app
    # add_header Content-Security-Policy "default-src 'self';" always;

    # ... other configuration ...
}

Protecting a site with Nginx basic authentication

Use HTTP basic auth for staging sites, admin areas, or simple access control when more robust identity systems are not available.
For production-grade authentication use OAuth/OIDC or similar identity providers.

Steps to enable basic auth:

Create an htpasswd file (requires htpasswd, provided by apache2-utils on Debian/Ubuntu or httpd-tools on RHEL/CentOS):

# Create the password file and add a user
htpasswd -c /etc/nginx/.htpasswd alice
# Enter and confirm the password when prompted

Configure Nginx to require the password for a location:

location /admin {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # ... other directives ...
}

Blocking and allowing traffic with Nginx

Use allow and deny directives to restrict clients by IP address or CIDR range. Combine with basic auth for layered protection.

Example: allow only a local network and loopback, then deny all other clients:

location /admin {
    # Allow only the local network and loopback
    allow 192.168.1.0/24;
    allow 127.0.0.1;
    deny all;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

A presentation slide titled "Objectives" with a blue gradient left panel listing two items: "04 Protecting a website with basic authentication" and "05 Blocking potentially harmful traffic." The slide also shows a small © Copyright KodeKloud note.

Fail2Ban overview

Fail2Ban monitors log files (for example Nginx access/auth logs or system authentication logs) and can add temporary firewall rules to block IPs that show malicious patterns (e.g., repeated failed login attempts).
Commonly used to mitigate brute-force attacks and automated scanners.
Note: many online lab or restricted environments cannot run Fail2Ban fully due to limited permissions or missing firewall utilities; in those cases, study the configuration examples and test where permitted.

Do not rely solely on HTTP basic authentication for strong security. For production-grade authentication consider using OAuth/OIDC or other robust authentication systems. Basic auth is still useful for simple or internal use-cases.

Wrap-up and next steps

You learned the core components: HTTPS/TLS, important HTTP security headers, simple access control with basic auth, IP filtering with Nginx, and an introduction to Fail2Ban.
Next: apply these configurations in hands-on examples — generate certificates, enable TLS in Nginx, add the security headers, and test access controls in a controlled environment.

Links and references

mkcert: https://github.com/FiloSottile/mkcert
Let’s Encrypt: https://letsencrypt.org/
Certbot: https://certbot.eff.org/
htpasswd documentation: https://httpd.apache.org/docs/current/programs/htpasswd.html
Fail2Ban: https://www.fail2ban.org/
Nginx documentation: https://nginx.org/en/docs/

Introduction

Install & Config

Intermediate Config

Security

Performance

Conclusion

Security Introduction

Watch Video