Welcome to the third lesson of Securing Your NGINX Server! In our previous lessons, we learned how to protect resources using authentication and how to control request rates with rate limiting. Today, we're adding another essential layer to your security toolkit: blocking malicious traffic based on IP addresses and user agent signatures.

This lesson focuses on identifying and rejecting suspicious clients before they can interact with your application. You'll learn how to block specific IP addresses, deny entire ranges using CIDR notation, and filter out known malicious bots and scanning tools. By the end, you'll have practical techniques for keeping unwanted traffic away from your server.

While authentication and rate limiting protect against legitimate users acting improperly, some threats come from sources that should never reach your application at all. Consider these real-world scenarios:

Attackers often probe servers from known malicious IP ranges, searching for vulnerabilities to exploit. Automated tools like sqlmap attempt SQL injection attacks, while various scanners probe for security weaknesses. These tools frequently identify themselves through their user agent strings, making them detectable and blockable.

The advantage of blocking at this level is efficiency: NGINX can reject malicious requests immediately, before they consume server resources or reach your application code. This early rejection protects both your server's performance and your application's security.

The simplest form of IP blocking uses the deny directive to reject traffic from a specific address. Let's start with a basic configuration:

This configuration blocks the IP address 198.51.100.23 while permitting all other clients. The deny directive appears first, followed by allow all, which permits any address not explicitly denied. The order here matters significantly: NGINX processes these directives sequentially, stopping at the first match.

When a request passes the IP checks, try_files forwards it to the named location @root, which handles the actual response. This separation keeps your access control logic distinct from your response handling.

Often, malicious traffic originates from entire IP ranges rather than isolated addresses. NGINX supports CIDR (Classless Inter-Domain Routing) notation for blocking these ranges efficiently:

The notation 203.0.113.0/24 blocks all IP addresses from 203.0.113.0 through 203.0.113.255, a total of 256 addresses. The /24 indicates that the first 24 bits of the address are fixed, while the remaining 8 bits can vary. This approach is particularly useful when dealing with known malicious networks or cloud provider ranges frequently used for attacks.

When NGINX sits behind a reverse proxy or load balancer, the incoming connection appears to originate from the proxy rather than the actual client. This creates a problem for IP-based blocking because you'll see the proxy's IP instead of the attacker's real address:

The set_real_ip_from directive tells NGINX to trust the IP address 127.0.0.1 as a legitimate proxy. When requests arrive from this trusted source, NGINX will extract the real client IP from the header specified by real_ip_header, which in this case is X-Forwarded-For. This configuration ensures your deny directives block the actual client rather than the proxy.

This setup is particularly useful for testing: you can send requests from localhost while simulating different client IPs by including the X-Forwarded-For header in your requests.

Many malicious tools identify themselves through distinctive user agent strings. We can detect and block these patterns using a regular expression check:

The if directive evaluates the built-in variable $http_user_agent, which contains the client's User-Agent header. The ~* operator performs a case-insensitive regular expression match against the pattern (badbot|sqlmap|scanner). When a match occurs, NGINX immediately returns a 403 Forbidden status, rejecting the request.

While the if directive has some limitations and can cause issues in certain contexts, this particular usage pattern (checking a request header and returning a response) is safe and effective for blocking known threats.

Now let's see how these techniques work together in a complete server configuration:

This configuration creates a layered defense:

• First, it checks the user agent string and blocks known malicious tools.
• Then, for requests that pass the user agent check, it evaluates the IP-based deny rules in the location block.
• Finally, legitimate clients are forwarded to the @root location, which returns the normal response.

The user agent check happens at the server level, applying to all locations, while the IP blocking rules are specific to the root location. The set_real_ip_from and real_ip_header directives allow the server to properly identify client IPs even when they're provided via the X-Forwarded-For header.

When a legitimate client connects from an allowed IP address with a normal user agent, they receive the expected response:

The request passes both security checks: the user agent doesn't match any blocked patterns, and the IP address isn't in the denied list. NGINX processes the request normally, forwards it to the @root location, and returns the configured response of "OK."

When NGINX detects either a denied IP address or a malicious user agent, it immediately rejects the request with a 403 status:

The 403 Forbidden status clearly indicates that the server understood the request but refuses to authorize it. This happens automatically without requiring any application code, providing an efficient barrier against known threats. The blocked client receives no information about your application's structure or functionality, limiting their ability to find vulnerabilities.

You've now mastered essential techniques for blocking malicious traffic at the NGINX level. You have learned how to deny specific IP addresses and ranges using CIDR notation, preserve real client IPs when behind proxies, and filter out requests based on suspicious user agent patterns. These methods complement the authentication and rate-limiting skills from previous lessons, creating a comprehensive security posture.

Together, IP blocking and user agent filtering form your first line of defense, stopping obvious threats before they can probe your application. Remember that while these techniques are effective against known attackers and automated tools, they work best as part of a broader security strategy that includes the other methods we've covered.

Now it's your turn to put these concepts into action! The practice exercises ahead will challenge you to configure various blocking rules, helping you develop confidence in protecting your servers from real-world threats.