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.

Practice

1. What does the allow directive do in an nginx configuration?

easy

A. It permits access to specified IP addresses or ranges.

B. It blocks access to specified IP addresses or ranges.

C. It redirects users to another URL.

D. It logs the IP addresses of visitors.

Solution

1. Step 1: Understand the purpose of allow

   The allow directive in nginx is used to specify which IP addresses or ranges are permitted to access the server or location.

2. Step 2: Compare with other directives

   Unlike deny which blocks IPs, allow explicitly permits them.

3. Final Answer:

   It permits access to specified IP addresses or ranges. -> Option A

4. Quick Check:

   allow means permit access [OK]

Hint: Allow means permit access, deny means block access [OK]

Common Mistakes:

• Confusing allow with deny
• Thinking allow redirects users
• Assuming allow logs IPs

2. Which of the following is the correct syntax to deny access to IP 192.168.1.10 in nginx?

easy

A. allow 192.168.1.10;

B. deny 192.168.1.10;

C. block 192.168.1.10;

D. reject 192.168.1.10;

Solution

1. Step 1: Identify the correct directive for blocking IPs

   In nginx, the directive to block or deny access is deny.

2. Step 2: Check syntax correctness

   The correct syntax is deny IP_address; with a semicolon at the end.

3. Final Answer:

   deny 192.168.1.10; -> Option B

4. Quick Check:

   deny blocks IP = deny 192.168.1.10; [OK]

Hint: Use 'deny IP;' to block access in nginx [OK]

Common Mistakes:

• Using 'allow' instead of 'deny'
• Using invalid directives like 'block' or 'reject'
• Missing semicolon at the end

3. Given this nginx config snippet inside a location /admin block:

allow 10.0.0.0/24;
deny all;

What happens when a user with IP 10.0.0.15 tries to access /admin?

medium

A. Access is denied because the IP is not explicitly allowed.

B. Access is denied because deny all overrides allow.

C. Access is allowed only if the user has a valid cookie.

D. Access is allowed because the IP is in the allowed range.

Solution

1. Step 1: Understand the order of allow and deny

   nginx checks allow and deny rules in order. If an IP matches an allow rule, access is granted even if deny all follows.

2. Step 2: Check if IP matches allowed range

   IP 10.0.0.15 is inside 10.0.0.0/24, so it matches the allow rule.

3. Final Answer:

   Access is allowed because the IP is in the allowed range. -> Option D

4. Quick Check:

   Allow matched before deny all = access allowed [OK]

Hint: Allow rules take priority before deny all [OK]

Common Mistakes:

• Assuming deny all always blocks
• Ignoring IP range matching
• Thinking cookies affect IP access control

4. You wrote this nginx config inside a server block:

deny 192.168.0.0/16
allow all;

But all IPs are denied access. What is the problem?

medium

A. You need to reload nginx after changes.

B. The order of deny and allow is wrong; allow should come first.

C. Missing semicolon after deny directive causes config error.

D. The IP range 192.168.0.0/16 is invalid.

Solution

1. Step 1: Check syntax for missing semicolons

   nginx requires semicolons at the end of each directive. The deny line is missing a semicolon, causing the config to fail.

2. Step 2: Understand effect of syntax error

   Without proper syntax, nginx may ignore or misinterpret rules, leading to unexpected blocking of all IPs.

3. Final Answer:

   Missing semicolon after deny directive causes config error. -> Option C

4. Quick Check:

   Every directive needs semicolon [OK]

Hint: Always end nginx directives with semicolon [OK]

Common Mistakes:

• Ignoring missing semicolon errors
• Thinking order alone causes issue
• Assuming IP range is invalid

5. You want to allow access only from IP 203.0.113.5 and block everyone else for /secure location. Which nginx config snippet achieves this correctly?

hard

A. location /secure {
allow 203.0.113.5;
deny all;
}

B. location /secure {
deny all;
allow 203.0.113.5;
}

C. location /secure {
allow all;
deny 203.0.113.5;
}

D. location /secure {
deny 203.0.113.5;
allow all;
}

Solution

1. Step 1: Understand correct order of allow and deny

   nginx processes allow and deny in order. To allow one IP and block others, allow must come first, then deny all.

2. Step 2: Verify each option

   location /secure {
     allow 203.0.113.5;
     deny all;
   }

   correctly allows 203.0.113.5 then denies all others.

   location /secure {
     deny all;
     allow 203.0.113.5;
   }

   denies all first, so no one is allowed. Options A and D misuse allow and deny directives.

3. Final Answer:

   location /secure { allow 203.0.113.5; deny all; } -> Option A

4. Quick Check:

   Allow specific IP then deny all others [OK]

Hint: Allow first, then deny all to restrict access [OK]

Common Mistakes:

• Reversing allow and deny order
• Allowing all then denying one IP
• Misusing deny and allow directives