IP-based access control (allow/deny) in Nginx - Step-by-Step Execution

Process Flow - IP-based access control (allow/deny)

Request arrives

↓

Check client IP

↓

Is IP allowed?

No→Is IP denied?

↓

Allow request

The server checks the client's IP against allow and deny rules to decide if the request is allowed or blocked.

Execution Sample

Nginx

location / {
    allow 192.168.1.0/24;
    deny all;
}

This config allows requests from 192.168.1.0/24 and denies all others.

Process Table

Step	Client IP	Check allow	Check deny	Decision
1	192.168.1.10	Matches allow 192.168.1.0/24	Not checked (allowed)	Allow request
2	10.0.0.5	No match	Matches deny all	Block request
3	192.168.2.1	No match	Matches deny all	Block request
4	192.168.1.255	Matches allow 192.168.1.0/24	Not checked (allowed)	Allow request
5	127.0.0.1	No match	Matches deny all	Block request
6	End of requests	-	-	Stop checking

💡 Requests are allowed if IP matches allow rules; otherwise denied if matching deny rules or denied by default.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	Final
client_ip	-	192.168.1.10	10.0.0.5	192.168.2.1	192.168.1.255	127.0.0.1	-
allow_check	-	true	false	false	true	false	-
deny_check	-	false	true	true	false	true	-
decision	-	allow	deny	deny	allow	deny	-

Key Moments - 3 Insights

Why does the server allow 192.168.1.10 but deny 192.168.2.1 even though both are private IPs?

Because 192.168.1.10 matches the allow rule (192.168.1.0/24), so it is allowed immediately. 192.168.2.1 does not match allow, so it falls through to deny all and is blocked (see execution_table rows 1 and 3).

What happens if an IP matches both allow and deny rules?

Nginx processes allow rules first. If an IP matches allow, it is allowed immediately without checking deny rules (see execution_table row 1 and 4). Deny rules are only checked if allow rules do not match.

Why is 'deny all;' needed after 'allow 192.168.1.0/24;'?

Because without 'deny all;', requests from IPs not in the allowed range would be allowed by default. 'deny all;' blocks all other IPs not explicitly allowed (see execution_table rows 2, 3, 5).

Visual Quiz - 3 Questions

Look at the execution table. What is the decision for client IP 10.0.0.5 at step 2?

A Allow request

B Check next rule

C Block request

D No decision yet

💡 Hint

Refer to execution_table row 2 under 'Decision' column.

At which step does the client IP match the allow rule?

A Step 3

B Step 1

C Step 2

D Step 5

💡 Hint

Check 'Check allow' column in execution_table for 'Matches allow' text.

If we remove 'deny all;', what would happen to client IP 127.0.0.1 at step 5?

A It would be allowed

B It would be blocked

C It would cause an error

D It would be logged but no decision

💡 Hint

Look at execution_table row 5 and consider the effect of removing 'deny all;'.

Concept Snapshot

IP-based access control in nginx:
- Use 'allow <IP or CIDR>;' to permit IPs
- Use 'deny <IP or all>;' to block IPs
- Nginx checks allow rules first, then deny rules
- If no allow matches, deny rules apply
- 'deny all;' blocks all IPs not allowed
- Order matters: allow then deny

Full Transcript

This visual execution shows how nginx uses IP-based access control with allow and deny directives. When a request arrives, nginx checks the client's IP against allow rules first. If the IP matches an allow rule, the request is allowed immediately. If not, nginx checks deny rules. If the IP matches a deny rule, the request is blocked. If no rules match, the default is to allow unless 'deny all;' is specified. The example config allows IPs in 192.168.1.0/24 and denies all others. The execution table traces five example IPs through these checks, showing which are allowed or blocked. Key moments clarify why some IPs are allowed or denied and the importance of rule order. The quiz tests understanding of decisions at specific steps and the effect of removing deny rules.

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