IP-based access control (allow/deny) in Nginx - Deep Dive

Overview - IP-based access control (allow/deny)

What is it?

IP-based access control is a way to let or block users from accessing a website or service based on their IP address. It works by checking the visitor's IP against a list of allowed or denied IPs. If the IP matches the rules, access is granted or denied accordingly. This helps control who can reach your server.

Why it matters

Without IP-based access control, anyone on the internet could try to access your server, including bad actors or unwanted visitors. This could lead to security risks, overload, or data leaks. Using IP allow or deny rules helps protect your resources by filtering traffic early, saving resources and improving security.

Where it fits

Before learning IP-based access control, you should understand basic networking concepts like IP addresses and how web servers work. After this, you can learn about more advanced security methods like firewalls, authentication, and rate limiting.

Mental Model

Core Idea

IP-based access control is like a security guard checking a guest list to decide who can enter a building based on their address.

Think of it like...

Imagine a club with a bouncer who only lets in people whose names are on the guest list or blocks those who are banned. The IP address is like the guest's name, and the allow/deny rules are the lists the bouncer uses.

┌─────────────────────────────┐
│ Incoming Request with IP    │
├──────────────┬──────────────┤
│ Check IP in  │              │
│ Allow List?  │              │
├──────────────┴──────────────┤
│ Yes → Allow Access           │
│ No → Check Deny List         │
├──────────────┬──────────────┤
│ In Deny List? │              │
├──────────────┴──────────────┤
│ Yes → Deny Access            │
│ No → Default Action (Allow) │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding IP Addresses

Concept: Learn what an IP address is and how it identifies devices on the internet.

An IP address is a unique number assigned to every device connected to the internet. It looks like 192.168.1.1 (IPv4) or a longer hexadecimal string (IPv6). Servers use IP addresses to know where to send data and to identify who is connecting.

Result

You can recognize IP addresses and understand they represent devices on the network.

Knowing what an IP address is helps you understand how servers can allow or block access based on these addresses.

2

Foundation

Basics of nginx Configuration

Concept: Learn how nginx uses configuration files to control server behavior.

nginx uses text files to set rules for how it handles web traffic. These files have blocks like 'server' and 'location' where you can add settings. Changes here affect who can access your website and how requests are processed.

Result

You can find and edit nginx configuration files to control server settings.

Understanding nginx config structure is essential before adding IP-based access rules.

3

Intermediate

Using allow and deny Directives

🤔Before reading on: do you think 'allow' rules override 'deny' rules or vice versa? Commit to your answer.

Concept: Learn how to write allow and deny rules in nginx to control access by IP.

In nginx, you use 'allow' to specify IPs that can access and 'deny' to block IPs. For example: allow 192.168.1.0/24; deny all; This means allow all IPs in 192.168.1.x and block everyone else. The order matters: nginx checks rules top to bottom and stops at the first match.

Result

You can write simple IP allow/deny rules to control access.

Knowing the order of rules is key to avoid accidentally blocking or allowing wrong IPs.

4

Intermediate

Applying IP Rules to Server and Location

🤔Before reading on: do you think IP rules apply globally or can they be set per URL path? Commit to your answer.

Concept: Learn how to apply IP-based access control to the whole server or specific parts of a website.

You can put allow/deny rules inside a 'server' block to control access to the whole site, or inside a 'location' block to control access to specific pages or folders. For example: server { location /admin { allow 10.0.0.0/8; deny all; } } This allows only IPs from 10.0.0.0/8 to access /admin and blocks others.

Result

You can restrict access to sensitive parts of your site by IP.

Applying rules at different levels gives flexible control over who can see what.

5

Intermediate

Combining Multiple IP Rules

🤔Before reading on: if an IP matches both allow and deny rules, which one wins? Commit to your answer.

Concept: Learn how nginx processes multiple allow and deny rules together.

nginx checks rules in order. If an IP matches an allow rule first, access is granted immediately. If it matches a deny rule first, access is denied immediately. If no rules match, the default is to allow access. Example: allow 192.168.1.0/24; deny 192.168.1.100; deny all; Here, 192.168.1.100 is allowed because it matches the allow rule first, even though there is a deny rule later. The order and first match rule is critical.

Result

You understand how to write complex rules that combine allow and deny.

Rule order and matching logic prevent conflicts and unexpected access.

6

Advanced

Using CIDR Notation for IP Ranges

🤔Before reading on: do you think CIDR notation covers single IPs or ranges? Commit to your answer.

Concept: Learn how to specify IP ranges using CIDR notation in nginx rules.

CIDR notation lets you specify a block of IP addresses with a base IP and a mask. For example, 192.168.1.0/24 means all IPs from 192.168.1.0 to 192.168.1.255. This helps write concise rules to allow or deny many IPs at once. Example: allow 10.0.0.0/8; deny all; Allows all IPs starting with 10.x.x.x and blocks others.

Result

You can efficiently control access for large IP ranges.

Using CIDR reduces complexity and errors compared to listing many IPs individually.

7

Expert

Handling Proxy and Real Client IPs

🤔Before reading on: do you think nginx sees the visitor's real IP by default when behind a proxy? Commit to your answer.

Concept: Learn how to correctly apply IP-based access control when nginx is behind proxies or load balancers.

When nginx is behind a proxy, it sees the proxy's IP, not the visitor's real IP. To fix this, you must configure nginx to read the real client IP from headers like X-Forwarded-For using the 'real_ip' module. Example: set_real_ip_from 192.168.0.0/16; real_ip_header X-Forwarded-For; Then IP-based allow/deny rules use the real client IP, not the proxy's IP.

Result

You can enforce IP rules accurately even behind proxies.

Understanding how proxies affect IP visibility prevents security holes where blocked IPs bypass rules.

Under the Hood

nginx processes incoming requests by reading the client's IP address from the network connection. It then compares this IP against the allow and deny lists in the configuration. The first matching rule determines if access is granted or denied. If no rules match, access is allowed by default. When behind proxies, nginx can be configured to extract the real client IP from HTTP headers to apply rules correctly.

Why designed this way?

The allow/deny system is simple and fast, designed to filter requests early before processing them fully. This reduces server load and improves security. The order-based matching allows flexible rules without complex logic. Handling proxies separately keeps the core logic simple while supporting modern architectures.

┌───────────────┐
│ Client Request│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ nginx receives │
│ IP address    │
└──────┬────────┘
       │
       ▼
┌─────────────────────────────┐
│ Check allow/deny rules in   │
│ order from config           │
├──────────────┬──────────────┤
│ Match allow? │ Yes → Allow  │
│              │ No           │
│ Match deny?  │ Yes → Deny   │
│              │ No           │
└──────────────┴──────────────┘
       │
       ▼
┌───────────────┐
│ Default allow │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does 'deny all' always override 'allow' rules? Commit yes or no.

Common Belief: Many think 'deny all' always blocks everyone, ignoring allow rules.

Reality: 'deny all' only applies if no previous allow rule matched. nginx processes rules top to bottom and stops at the first match.

Why it matters: Misunderstanding this causes admins to accidentally block all users or fail to block unwanted IPs.

Quick: Does nginx see the visitor's real IP by default behind proxies? Commit yes or no.

Common Belief: People often believe nginx always sees the real client IP.

Reality: By default, nginx sees the proxy's IP, not the real client IP, unless configured with the real_ip module.

Why it matters: Without correct setup, IP-based rules can be bypassed or misapplied, causing security risks.

Quick: Can you use hostnames instead of IPs in allow/deny rules? Commit yes or no.

Common Belief: Some think you can use domain names in allow/deny directives.

Reality: nginx only accepts IP addresses or CIDR ranges in allow/deny rules, not hostnames.

Why it matters: Trying to use hostnames leads to configuration errors or ignored rules.

Quick: Does the order of allow and deny rules matter? Commit yes or no.

Common Belief: Many believe order does not affect rule evaluation.

Reality: nginx evaluates rules in order and stops at the first match, so order is critical.

Why it matters: Incorrect order can cause unintended access or blocks, leading to security holes or user frustration.

Expert Zone

1

nginx stops checking rules after the first match, so placing deny rules before allow can block IPs unintentionally.

2

Behind multiple proxies, the X-Forwarded-For header can contain several IPs; nginx uses the last trusted IP, which requires careful configuration.

3

Using large IP ranges with CIDR can accidentally allow or deny more IPs than intended if the mask is too broad.

When NOT to use

IP-based access control is not suitable for user-level authentication or complex security policies. Use it mainly for network-level filtering. For user identity, use authentication systems like OAuth or JWT. For dynamic or large-scale IP management, consider firewall rules or cloud security groups instead.

Production Patterns

In production, IP allow/deny is often combined with authentication to protect admin areas. It is also used to whitelist internal networks or block known malicious IP ranges. Many setups use the real_ip module to handle proxies and load balancers correctly. Rules are kept simple and documented to avoid accidental lockouts.

Connections

Firewall Rules

IP-based access control in nginx is similar to firewall rules that filter traffic at the network level.

Understanding firewall concepts helps grasp how nginx filters requests early to protect servers.

Authentication Systems

IP-based access control complements authentication by filtering traffic before user identity is checked.

Knowing the difference helps design layered security where IP filtering reduces load on authentication.

Postal Mail Delivery

Like IP filtering, postal services route or block mail based on address rules.

This cross-domain view shows how address-based filtering is a universal method to control access.

Common Pitfalls

#1 Blocking all IPs unintentionally by placing 'deny all;' before allow rules.

Wrong approach:

deny all;
allow 192.168.1.0/24;

Correct approach:

allow 192.168.1.0/24;
deny all;

Root cause:

Misunderstanding that nginx stops checking rules after the first match, so deny all first blocks everyone.

#2 Using hostnames instead of IPs in allow/deny directives.

Wrong approach:

allow example.com;
deny all;

Correct approach:

allow 203.0.113.0/24;
deny all;

Root cause:

nginx does not resolve hostnames in these directives; only IPs or CIDR ranges are valid.

#3 Not configuring real_ip module behind proxies, causing wrong IPs to be checked.

Wrong approach:

allow 203.0.113.5;
deny all; # but nginx sees proxy IP, not real client

Correct approach:

set_real_ip_from 192.168.0.0/16;
real_ip_header X-Forwarded-For;
allow 203.0.113.5;
deny all;

Root cause:

Assuming nginx sees the real client IP by default when behind proxies.

Key Takeaways

IP-based access control in nginx filters incoming requests by checking their IP addresses against allow and deny lists.

The order of allow and deny rules matters because nginx stops checking after the first match.

CIDR notation lets you specify IP ranges efficiently, reducing rule complexity.

Behind proxies, you must configure nginx to read the real client IP to apply rules correctly.

IP-based access control is a simple but powerful first layer of security that complements other methods like authentication.