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.