IP-based access control (allow/deny) in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the effect of this nginx configuration snippet?

Given the following nginx configuration inside a server block, what will happen when a client with IP 192.168.1.10 tries to access the server?

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

Nginx

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

A The client will get a 404 Not Found error.

B The client is denied access because deny all overrides allow.

C The client with IP 192.168.1.10 is allowed access because it matches the allowed subnet.

D The client will be redirected to another location.

💡 Hint

Remember that nginx processes allow and deny directives in order and stops at the first match.

In nginx, allow and deny directives are checked in order, stopping at the first match. Here, 'allow 192.168.1.0/24' is first and matches the client IP 192.168.1.10, so access is allowed. The later 'deny all' is not evaluated for this client.

❓ Configuration

intermediate

Which nginx configuration denies all IPs except 10.0.0.5?

Select the correct nginx configuration snippet that denies access to all IPs except the single IP 10.0.0.5.

A

allow 10.0.0.5;
deny all;

B

allow all;
deny 10.0.0.5;

C

deny 10.0.0.5;
allow all;

D

deny all;
allow 10.0.0.5;

💡 Hint

The order of allow and deny directives matters in nginx.

In nginx, directives are checked in order. 'allow 10.0.0.5;' first matches and allows that IP, then 'deny all;' denies everyone else. This means only 10.0.0.5 is allowed, all others denied.

❓ Troubleshoot

advanced

Why does this nginx config block all IPs including allowed ones?

You have this nginx config:

location /secure {
  deny all;
  allow 192.168.0.0/16;
}

But clients from 192.168.1.100 are still denied access. What is the reason?

Nginx

location /secure {
  deny all;
  allow 192.168.0.0/16;
}

A Nginx requires 'satisfy any;' directive to allow exceptions.

B The subnet 192.168.0.0/16 does not include 192.168.1.100.

C The deny all directive overrides allow regardless of order.

D The order of deny and allow is wrong; deny all should come after allow.

💡 Hint

Check the order of allow and deny directives and how nginx processes them.

Nginx processes allow and deny directives in order. If 'deny all;' is first, it denies all clients immediately, so the later 'allow' is ignored. The correct order is to put 'allow' first, then 'deny all;' to allow exceptions.

🔀 Workflow

advanced

What is the correct workflow to restrict access to a web app by IP in nginx?

Which sequence of steps correctly describes how to restrict access to a web application by IP address using nginx?

A Edit nginx config to add allow/deny directives, test config syntax, reload nginx service.

B Restart nginx service, edit config, test syntax, reload service.

C Edit config, reload nginx without testing syntax, check logs for errors.

D Test config syntax, restart nginx service, edit config, reload service.

💡 Hint

Think about safe steps to avoid downtime or errors.

The safe workflow is to edit the config, test syntax with 'nginx -t', then reload nginx to apply changes without downtime. Restarting before editing or skipping syntax test risks errors or downtime.

🧠 Conceptual

expert

What is the effect of combining 'allow' and 'deny' directives with 'satisfy any;' in nginx?

Consider this nginx configuration snippet:

location / {
  satisfy any;
  allow 10.1.1.0/24;
  deny all;
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

What is the behavior for a client from IP 10.1.1.50?

Nginx

location / {
  satisfy any;
  allow 10.1.1.0/24;
  deny all;
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

A Client must provide password regardless of IP because auth_basic always applies.

B Client from 10.1.1.50 is allowed without password because IP allow passes satisfy any.

C Client is denied access because deny all overrides allow with satisfy any.

D Client is allowed only if password matches and IP is allowed.

💡 Hint

'satisfy any;' means only one condition must be met to allow access.

With 'satisfy any;', nginx allows access if either IP allow or auth_basic passes. Since client IP 10.1.1.50 is in allowed subnet, it bypasses password prompt and is allowed immediately.

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