Demonstrate how to restrict access

Table of Contents

  1. Introduction
  2. Restricting Access by IP Address
  3. Restricting Access by HTTP Method
  4. Implementing HTTP Basic Authentication
  5. Using the Auth Request Module for Subrequest-Based Authentication
  6. Combining Multiple Access Restrictions
  7. URI-Based Access Restrictions
  8. Conclusion

1. Introduction

Access control is a critical component of web server security. In NGINX Plus, administrators commonly restrict access to resources using IP-based rules, HTTP method limitations, standard user/password authentication, and even advanced subrequest-based authorization. These methods help protect sensitive areas of a website, prevent unauthorized access, and mitigate attacks such as brute force or distributed denial-of-service (DDoS) attacks. This article discusses various approaches to implement access restrictions in NGINX Plus, complete with practical code examples and visual representations. The configurations and code snippets are supported by documentation and technical guidelines.

2. Restricting Access by IP Address

NGINX utilizes the ngx_http_access_module to control which client IP addresses can access server resources. The allow and deny directives are used to grant or refuse access based on the client's IP address or network. The rules are evaluated in order, making it essential to define the directives carefully.

2.1 IP-Based Configuration Example

Below is an example configuration to restrict an administrative area to specific IP ranges:

location /admin {  
    # Deny a specific IP address  
    deny 192.168.1.2;  
    # Allow a specific IP range (CIDR notation)  
    allow 192.168.1.0/24;  
    # Allow local access for maintenance  
    allow 127.0.0.1;  
    # Deny all other IP addresses  
    deny all;  
}

In this configuration:

This method ensures that only permitted IP addresses can interact with the /admin URI, thereby bolstering security.

2.2 Visual Comparison: IP-Based Access Control

Directive Description Example Value
deny Denies access to the specified IP or subnet deny 192.168.1.2;
allow Grants access for the specified IP or subnet allow 192.168.1.0/24;
deny Denies access for any IP not previously allowed deny all;

Table 1: Comparison of IP-Based Access Directives
This table summarizes the roles of the allow and deny directives used in NGINX IP-based access control. The example illustrates how specific addresses are granted or rejected based on their values.

3. Restricting Access by HTTP Method

In some scenarios, you may wish to restrict access based on the HTTP method used to make a request. This is particularly useful when certain methods (e.g., POST, PUT, DELETE) need to be limited to authorized clients.

3.1 Method Restriction Using limit_except

NGINX provides the limit_except block for limiting HTTP methods. For instance, if you wish to allow only GET and HEAD requests to a sensitive endpoint, you can use the following configuration:

location /sensitive {  
    limit_except GET HEAD {  
        deny all;  
    }  
    # Process allowed GET and HEAD requests normally  
    proxy_pass http://backend_server;  
}

In this configuration, only GET and HEAD requests are processed; all other methods (such as POST, PUT, DELETE) are denied access automatically. This approach is particularly effective for public resources where modifying operations should be prevented.

3.2 Considerations for HTTP Method Restrictions

4. Implementing HTTP Basic Authentication

HTTP Basic Authentication is a straightforward method to restrict access by validating a username and password. NGINX provides the ngx_http_auth_basic_module to implement this kind of access control. With this method, users are prompted for credentials before they can access protected URIs.

4.1 Creating a Password File

Before applying HTTP Basic Authentication, you must create a password file containing user credentials. Tools such as apache2-utils (for Debian/Ubuntu) or httpd-tools (for RHEL/CentOS) are typically used. The following command creates a password file and adds a user:

sudo htpasswd -c /etc/apache2/.htpasswd user1

After multiple entries, the file may look like this:

$ cat /etc/apache2/.htpasswd  
user1:$apr1$/woC1jnP$KAh0SsVn5qeSMjTtn0E9Q0  
user2:$apr1$QdR8fNLT$vbCEEzDj7LyqCMyNpSoBh/  
user3:$apr1$Mr5A0e.U$0j39Hp5FfxRkneklXaMrr/

This process securely stores usernames along with hashed passwords.

4.2 Configuring Basic Authentication in NGINX

Once the password file is created, integrate it into your NGINX configuration using the auth_basic and auth_basic_user_file directives:

location /protected {  
    auth_basic "Administrator's Area";  
    auth_basic_user_file /etc/apache2/.htpasswd;  
    proxy_pass http://backend_protected;  
}

Here, when a client accesses the /protected location, they are prompted to provide a username and password that match the entries in the .htpasswd file.

4.3 Security Considerations

5. Using the Auth Request Module for Subrequest-Based Authentication

For more advanced access control, NGINX Plus supports client authorization using the ngx_http_auth_request_module. This module performs a subrequest to an authentication server, and access is granted only if the subrequest returns a 2xx status code.

5.1 Auth Request Configuration Example

The configuration below demonstrates how to set up an authentication subrequest:

location /private/ {  
    auth_request /auth;  
    proxy_pass http://backend_private;  
}  

location = /auth {  
    proxy_pass http://authentication_server;  
    proxy_pass_request_body off;  
    proxy_set_header Content-Length "";  
    proxy_set_header X-Original-URI $request_uri;  
}

In this example:

5.2 Workflow of Auth Request Process

The following diagram illustrates the process flow for using the auth request module to verify client access:

flowchart TD  
    A["Client Request to /private/"] --> B["NGINX Consults /auth via auth_request"]  
    B --> C{"Authentication Server Response Code"}  
    C -- "2xx (Success)" --> D["Access Granted, Proxy to Backend Service"]  
    C -- "401 or 403" --> E["Access Denied, Return Error to Client"]  
    C -- "Other Codes" --> F["Return Error (Error Handling)"]  
    F --> END["END"]

Figure 1: Authentication Subrequest Flowchart
This flowchart clearly represents the step-by-step process where NGINX makes a subrequest for authentication and determines access based on the returned HTTP status code.

5.3 Advantages of Subrequest-Based Authentication

6. Combining Multiple Access Restrictions

To meet complex security requirements, NGINX Plus can combine several access restrictions. For example, you might require that a client both come from an allowed IP range and pass authentication.

6.1 Example Configuration with Combined Restrictions

The following configuration demonstrates how to enforce both IP-based restrictions and HTTP Basic Authentication using the satisfy directive:

location /api {  
    satisfy all;  
    
    # IP-based access restrictions  
    allow 192.168.1.1/24;  
    allow 127.0.0.1;  
    deny 192.168.1.2;  
    deny all;  
    
    # HTTP Basic Authentication  
    auth_basic "Administrator's Area";  
    auth_basic_user_file /etc/apache2/.htpasswd;  
    
    proxy_pass http://backend_api;  
}

In this configuration:

6.2 Benefits of Combined Methods

6.3 Visualization: Combined Access Control Logic

Below is a table summarizing the requirements for access in the combined configuration:

Requirement Description Example Directive
IP Allow List Only specified IP ranges or addresses are allowed allow 192.168.1.1/24; / allow 127.0.0.1;
IP Denial List Specific IP addresses are explicitly denied deny 192.168.1.2;
Authentication Requirement Client must provide valid HTTP Basic credentials auth_basic "Administrator's Area";
Combined Requirement (satisfy all) Both IP and authentication criteria must be met satisfy all;

Table 2: Combined Access Control Requirements
This table provides an at-a-glance summary of the different criteria that a client must meet for access when using combined restrictions.

7. URI-Based Access Restrictions

URI-based restrictions allow administrators to isolate and protect specific sections of a website by configuring different location blocks. This method is essential when only parts of a website require heightened security.

7.1 Example: Making Public and Private Areas Distinct

In many web applications, it is desirable to open a section of the website (e.g., a public blog or documentation) while protecting sensitive administrative interfaces. Consider the following configuration:

server {  
    listen 80;  
    server_name example.com;  
    
    # Global Basic Authentication for the entire site  
    auth_basic "Restricted Content";  
    auth_basic_user_file /etc/apache2/.htpasswd;  
    
    # Public part of the website without authentication  
    location /public/ {  
        auth_basic off;  
    }  
    
    # Protected area for administrative use  
    location /admin/ {  
        auth_basic "Administrator's Area";  
        auth_basic_user_file /etc/apache2/.htpasswd;  
    }  
}

In this setup, the global level applies authentication for most of the website, but the /public/ location explicitly disables it using the auth_basic off directive. This configuration enables clear segregation between secure and public areas based on the URI.

7.2 Securing REST APIs with URI-Based Rules

For REST APIs, URI-based restrictions are also useful. An API endpoint might integrate both IP-based filtering and authentication, ensuring that only trusted clients can perform certain operations. Using a combination of methods through separate location blocks or using regular expression matching can create a robust, granular access control mechanism.

8. Conclusion

Implementing access restrictions in NGINX Plus is essential for securing web applications and infrastructure. We have discussed a variety of techniques, each with its own strengths and use cases:

Key Findings

Figure 2: Access Restriction Methods Overview

flowchart TD  
    A["Access Request"] --> B["IP-Based Check"]  
    B --> C{"IP Allowed?"}  
    C -- Yes --> D["Proceed to HTTP Method Check"]  
    C -- No --> E["Access Denied"]  
    D --> F{"Method Allowed?"}  
    F -- Yes --> G["Authentication Check"]  
    F -- No --> E  
    G --> H{"Credentials Valid?"}  
    H -- Yes --> I["Access Granted"]  
    H -- No --> E

This flowchart illustrates how a client request is sequentially evaluated through IP filtering, HTTP method validation, and authentication, ensuring that only requests meeting all criteria are granted access.

By carefully incorporating these methods into your NGINX Plus configuration, you can create a flexible and robust access control system that addresses a wide range of security needs. Each technique can be used separately or in combination, allowing for tailored solutions that suit the specific requirements of your environment. The code snippets and visual aids provided here serve as practical examples to help you implement these security measures effectively.

In summary, effective access restrictions require a layered approach. By leveraging the built-in modules of NGINX Plus, such as ngx_http_access_module, ngx_http_auth_basic_module, and ngx_http_auth_request_module, administrators are equipped to defend against unauthorized access while ensuring legitimate traffic is properly handled. Future enhancements may include integrating OpenID Connect for even stronger authentication than what HTTP Basic offers, and automating IP allow/deny lists based on dynamic threat intelligence.

To maximize the security benefits, always review and test your NGINX configuration in a controlled environment before deploying it to production. Regular audits, updates to access lists, and monitoring of authentication logs will ensure that your server remains resilient against evolving threats.