HTTP Vulnerability Scan Protection

• HTTP protection overview
• How to enable HTTP protection
• Detection rules
• Advanced settings

RdpGuard monitors Microsoft IIS, Apache HTTP Server and nginx access logs for requests that may indicate vulnerability scanning, such as repeated requests for missing pages or attempts to find exposed credentials and repository files. When detections from an IP address reach your configured blocking limit, RdpGuard temporarily blocks that address.

HTTP protection uses a set of detection rules to identify suspicious requests. Start with the standard rules, then adjust them to the paths and applications hosted on your server. If your websites are behind a reverse proxy, also review the proxy settings to identify and block the original client.

1. Open RdpGuard Dashboard and click HTTP under Monitored protocols.

   

   The HTTP Protection Settings dialog will open:

   

2. Select Enable HTTP protection and choose your Web server: Microsoft IIS, Apache HTTP Server or nginx.

3. Click Add... and select the folders containing your access logs. You can add multiple folders. Select an entry to Edit... or Remove it.

4. Leave Override standard detection rules unchecked to use the defaults, then click Save. Check View, Show event log in RdpGuard Dashboard for monitoring errors.

IIS log directories

Select each site's log folder, for example C:\inetpub\logs\LogFiles\W3SVC1. The number after W3SVC is the IIS site ID. Choose the folder containing the actual log files, rather than the parent LogFiles folder: RdpGuard does not scan subfolders.

Enable W3C logging in IIS. Include Client IP Address (c-ip), URI Stem (cs-uri-stem) and HTTP Status (sc-status) for the standard rules. Custom rules may require additional fields, as listed below.

Apache access log directories

Select the access log directory configured in Apache, for example C:\Apache24\logs. Add each directory separately; subfolders are not scanned. RdpGuard supports the Common and Combined access log formats, with a numeric client IP address in the first field. Combined logs also include the Referer and User-Agent fields needed by rules that use those values. See the Apache logging documentation for the format definitions.

nginx access log directories

Select nginx as the web server and add the directory containing its access logs, for example C:\nginx\logs. Subfolders are not scanned. Use nginx's default combined log format, with the numeric client IP address in the first field. It includes all fields supported by HTTP detection rules.

access_log logs/access.log combined;

RdpGuard handles nginx's default \xXX escaping, including UTF-8 text. Custom layouts with extra or reordered fields, JSON logs and compressed logs are not supported. See the nginx logging documentation for logging configuration details.

Select Override standard detection rules to edit the rules. Your custom set replaces the standard rules; it is not added to them. Keep any standard rules you still need in the custom set, or clear the checkbox to return to the defaults.

Write one rule per line. A line beginning with # is a comment. Each rule contains one or more comma-separated conditions, using = for a match or != for an exclusion. Values are case-sensitive and support * for any number of characters and ? for a single character.

Uri=/*.zip,Uri!=/download/*

This example matches requests for ZIP files, except those under /download/. All conditions on a line must match (AND); any matching rule can produce a detection (OR). A single request can match several rules and contribute to each one, so overlapping rules can produce more than one detection for the same request.

Supported fields and their corresponding IIS W3C field names:

• Method - HTTP method, such as GET or POST (cs-method).
• Uri - requested path, without the query string (cs-uri-stem).
• Query - query string, without the leading ? (cs-uri-query).
• UserName - authenticated user name (cs-username).
• UserAgent - client User-Agent value (cs(User-Agent)).
• Referer - referring URL (cs(Referer)).
• Status - HTTP status code, such as 404 (sc-status).

Make sure your log format includes the fields used by your rules. Apache Common logs do not contain Referer or User-Agent values; use Combined logs for rules that depend on them.

Threshold

Without Threshold, each matching request produces one detection for that rule. Add a positive integer threshold to group several matches from the same IP into one detection. For example:

Status=404,Threshold=15

This rule produces one detection for every 15 HTTP 404 responses to requests from the same IP address. It does not block the address after 15 requests by itself: blocking still depends on the detection limit configured in RdpGuard. If that limit is 3 and no other rules contribute, this rule alone needs 45 matching requests before the address is blocked, assuming the counters have not reset.

A threshold helps avoid treating an occasional broken link as a scan attempt. For a path that has no legitimate use on your website, you may choose a rule without a threshold. Configure the blocking limit and counter reset interval in Tools, Options, on the General tab.

Sample rules

The following rules match the current standard set. Archive and WordPress checks are commented out. Enable them only if requests to those paths should be treated as scanning on your websites; otherwise, you could block legitimate visitors.

# Count every 15 HTTP 404 responses as one detection
Status=404,Threshold=15

# Scan for secrets, environment files and repository metadata
Uri=*/.aws*
Uri=*/.env*
Uri=*/.git*
Uri=*/.hg/*
Uri=*/.svn*
Uri=*/.vscode*

# Optional: archive scans (check your legitimate downloads first)
#Uri=/*.bz2
#Uri=/*.tar.gz
#Uri=/*.tgz
#Uri=/*.7z
#Uri=/*.zip,Uri!=/download/*
#Uri=/*.rar

# Optional: WordPress scans (leave disabled if you use WordPress)
#Uri=*/wp-content/*
#Uri=*/wp-admin/*
#Uri=*/wp-includes/*
#Uri=*/wp-json/*
#Uri=*/wp-config*
#Uri=*/wp-login.php*

Click Advanced settings... in HTTP Protection Settings to open Advanced HTTP Settings. The X-Forwarded-For options below apply to IIS logs.

Read the client IP address from the X-Forwarded-For field

By default, RdpGuard uses Client IP Address (c-ip) from the IIS log. Behind a reverse proxy, this is usually the proxy's address. Enable this option to use the logged X-Forwarded-For value instead. If it contains several addresses, RdpGuard uses the first one.

Configure your trusted proxy to supply the real client IP and prevent clients from injecting their own first address into the header. Restrict direct access to IIS so requests cannot bypass the proxy. See Configuring IIS to Detect Client IP Behind a Proxy for the IIS logging setup.

Use the connection IP address if X-Forwarded-For is missing

Enable this option to use c-ip when the X-Forwarded-For value is missing. Leave it off if every request comes through a proxy: falling back to the connection address can cause the proxy itself to be blocked.

Click OK, then Save in HTTP Protection Settings to apply the changes.

For Apache, RdpGuard reads the IP address from the first field of each access log entry; these X-Forwarded-For checkboxes do not affect Apache logs. Configure Apache to write the original client IP there, using a trusted proxy setup such as mod_remoteip.

For nginx, RdpGuard also uses the first field of each access log entry ($remote_addr in the standard combined format). The X-Forwarded-For checkboxes do not affect nginx logs. Behind a proxy, ensure this field contains the original client IP using a trusted proxy configuration.

Blocking requests when using X-Forwarded-For

Reading X-Forwarded-For identifies the client, but does not change where blocking happens. When the connection to your server comes from a reverse proxy, a Windows firewall rule for the original client IP will not block that proxied connection.

Block the client at the proxy. For IIS, you can also use IIS IP Address and Domain Restrictions with Proxy Mode and RdpGuard Custom Actions as shown below.

Configuring Custom Actions in RdpGuard

This example adds and removes IPv4 deny entries for one IIS website. Replace Your Web Site in both commands with the site's name in IIS Manager.

1. Install the IIS IP and Domain Restrictions role service if it is not installed.
2. In IIS Manager, select the website, open IP Address and Domain Restrictions, click Edit Feature Settings... and select Enable Proxy Mode. This requires IIS 8.0 or later. See Microsoft's IP Security documentation.
3. Run RdpGuard Dashboard as administrator and open Tools, Custom Actions / Notifications. Add the two actions below.

IP Blocked action

• Event: IP Blocked
• Task: Execute program
• Path: C:\Windows\System32\inetsrv\appcmd.exe

Arguments:

set config "Your Web Site" /section:system.webServer/security/ipSecurity /+"[ipAddress='%IP%',allowed='false']" /commit:apphost

IP Unblocked action

• Event: IP Unblocked
• Task: Execute program
• Path: C:\Windows\System32\inetsrv\appcmd.exe

Arguments:

set config "Your Web Site" /section:system.webServer/security/ipSecurity /-"[ipAddress='%IP%']" /commit:apphost

Save the actions. After a local detection triggers a block, verify that the deny entry appears for the selected IIS site and requests from that client are denied through the proxy. When RdpGuard unblocks the address, the second action removes the entry.

These actions handle future IP Blocked and IP Unblocked events from local detections; they do not synchronize the existing blocked list or addresses blocked only through IP Cloud.