Require directive in your virtual host file or use .htaccess to deny access from specific IP ranges like 201.17.83.xxx and 10.0.1.xxx. This method provides immediate protection against known malicious sources by rejecting their HTTP requests at the server level before they reach your application logic.
Identifying Malicious Traffic Sources
Before implementing blocks, it is crucial to verify that the identified IP addresses are indeed the source of the attack. Apache access logs provide a detailed record of incoming requests, including the client IP, timestamp, requested URL, and HTTP status code. By analyzing these logs, you can pinpoint patterns such as high-frequency requests, attempts to access sensitive files, or unusual user-agent strings associated with the suspicious IPs. In this scenario, the logs indicate activity from201.17.83.xxx and 10.0.1.xxx. The 201.17.83.xxx range appears to be a public IP block, potentially originating from external attackers. Conversely, 10.0.1.xxx falls within the private IPv4 address space defined by RFC 1918. If your web server is exposed to the internet, seeing internal private IPs in public-facing logs might indicate NAT (Network Address Translation) issues, proxy configurations, or spoofed headers. It is essential to distinguish between direct attacks and misconfigured proxies to ensure you are not blocking legitimate traffic from your own infrastructure.
Blocking IPs via Virtual Host Configuration
The most robust way to block IPs in Apache 2.4 is through the main configuration or virtual host files. This approach ensures that the rules are applied consistently across all directories served by that specific virtual host. You should edit the relevant<VirtualHost> block in your Apache configuration directory, typically located at /etc/apache2/sites-available/ on Debian-based systems or /etc/httpd/conf.d/ on Red Hat-based systems.
Inside the virtual host definition, add a <Directory> or <Location> block to specify the access control rules. Use the Require directive to explicitly deny the identified IP ranges. For example, to block the 201.17.83.0/24 subnet and the 10.0.1.0/24 subnet, you would use the following syntax:
<RequireAll>
Require all granted
Require not ip 201.17.83.0/24
Require not ip 10.0.1.0/24
</RequireAll>
Require all granted) except for those matching the specified IP ranges. After saving the changes, you must reload the Apache service for the new rules to take effect. On systemd-based systems, run sudo systemctl reload apache2 or sudo systemctl reload httpd. Always test the configuration with apachectl configtest before reloading to prevent syntax errors from taking down your site.
Using .htaccess for Directory-Level Blocking
If you do not have access to the main Apache configuration files, or if you need to apply blocking rules to a specific directory rather than the entire virtual host, you can use the.htaccess file. This method is particularly useful for shared hosting environments where users cannot modify the global server configuration. Place the .htaccess file in the root directory of your website or the specific subdirectory you wish to protect.
The syntax for denying IPs in .htaccess uses the Deny and Allow directives, which operate on a different logic than the Require directive used in virtual hosts. To block specific IPs, you first allow all users and then deny the malicious ones:
Order Allow,Deny
Allow from all
Deny from 201.17.83.0/24
Deny from 10.0.1.0/24
Order directive is deprecated in Apache 2.4. In modern Apache versions, you should use Require inside .htaccess as well, similar to the virtual host method:
<RequireAll>
Require all granted
Require not ip 201.17.83.0/24
Require not ip 10.0.1.0/24
</RequireAll>
AllowOverride directive in your main Apache configuration allows .htaccess files to override access controls. If AllowOverride is set to None, your .htaccess rules will be ignored. For more granular control, you can also whitelist trusted IPs while blocking others, as discussed in our guide on User Access Whitelisted Using .htaccess File in Apache 2.4 Still Cannot See Internet Site?.
Handling Private IP Ranges and Proxies
The presence of10.0.1.xxx in your public logs warrants special attention. Since this is a private IP range, it should never appear on the public internet unless it is being translated or proxied. If your server is behind a reverse proxy like Nginx or Cloudflare, the real client IP might be obscured, and the proxy's internal IP could be logged instead. In such cases, blocking 10.0.1.xxx might block your own infrastructure or legitimate users depending on your network topology.
Verify your proxy configuration to ensure that the X-Forwarded-For header is correctly populated. If you are using a reverse proxy, consider configuring Apache to trust the proxy's IP and log the actual client IP from the header. This prevents confusion and ensures that your blocking rules target the true source of the attack. Additionally, check if the 10.0.1.xxx range corresponds to your internal monitoring tools or CI/CD pipelines that might be triggering the service page unintentionally.
Verifying the Block and Monitoring
After applying the blocking rules, it is important to verify that they are working as intended. You can use command-line tools likecurl to simulate requests from the blocked IPs if you have access to machines within those networks. Alternatively, monitor your Apache error logs for 403 Forbidden responses from the targeted IPs. A successful block should result in these clients receiving a 403 status code when attempting to access your site.
Continue to monitor your access logs for any new attacking IPs or changes in behavior. Attackers often rotate their IP addresses, so maintaining a dynamic list of blocked IPs might be necessary. Consider integrating automated tools like Fail2ban to dynamically update your firewall rules based on log analysis. For more information on automating crawler and bot blocking, refer to our article on Fail2ban: Updating apache-badbots.conf for Debian 12 to Block Traffic from Crawlers.
Frequently Asked Questions
How do I unblock an IP address after blocking it?
To unblock an IP, simply remove the corresponding Require not ip or Deny from line from your Apache configuration or .htaccess file. After editing, reload the Apache service to apply the changes immediately.
Can I block IPs based on country instead of specific addresses?
Yes, you can use the ModGeoIP module to block traffic based on geographic location. However, this requires downloading and maintaining a GeoIP database, which may impact performance and accuracy compared to specific IP blocking.
Why am I still seeing traffic from blocked IPs?
If blocked IPs continue to appear, check if they are using a different IP address or if they are accessing your site through a proxy. Also, verify that your Apache configuration was reloaded correctly and that there are no conflicting rules overriding your block.
Is it safe to block private IP ranges like 10.x.x.x?
Blocking private IP ranges is generally safe only if you understand your network architecture. If your server is behind a NAT or proxy, these IPs might represent legitimate internal traffic. Always verify the source of these requests before applying broad blocks.
What is the difference between .htaccess and virtual host blocking?
Virtual host blocking applies to the entire site and is more efficient, while .htaccess allows for per-directory rules. Virtual host configurations are processed faster because they are read once at startup, whereas .htaccess is read for every request.