Blocking HTTP Requests via IPTables | NOC.org

Overview: HTTP Blocking with IPTables

IPTables operates at the network and transport layers of the networking stack, but with the right modules it can also inspect application-layer content within packets. This capability makes it possible to block HTTP requests based on specific strings, domain names, URL patterns, or host headers, even though IPTables is fundamentally a packet filter rather than an application-layer firewall.

There are several scenarios where blocking HTTP requests at the IPTables level is useful: preventing your server from communicating with known malicious domains, blocking outbound connections to command-and-control servers, filtering incoming requests based on host headers, or restricting specific types of HTTP traffic as part of a broader firewall strategy. While a Web Application Firewall (WAF) is typically better suited for application-layer filtering, IPTables provides a lightweight option when a WAF is not available or as an additional defense layer.

String Matching with IPTables

The -m string module allows IPTables to search for specific byte sequences within the payload of network packets. This is the foundation for blocking HTTP requests based on content such as domain names, host headers, or URL paths.

Basic Syntax

iptables -A [CHAIN] -p tcp --dport [PORT] -m string --string "search term" --algo [bm|kmp] -j [TARGET]

Key parameters:

• --string "text" — The string to search for in the packet payload. This is case-sensitive by default.
• --algo bm or --algo kmp — The string matching algorithm to use. bm (Boyer-Moore) is generally faster for longer patterns, while kmp (Knuth-Morris-Pratt) can be more efficient for shorter patterns. Both produce the same results; the choice affects only performance.
• --hex-string — An alternative to --string that allows you to specify the search pattern in hexadecimal notation. Useful for matching binary content or special characters.
• --from and --to — Limit the search to a specific byte range within the packet. This improves performance by avoiding scanning the entire packet.

Blocking by Domain Name / Host Header

HTTP/1.1 requests include a Host header that specifies the domain name the client is requesting. You can use string matching to block requests containing specific host headers:

Block Incoming Requests for a Specific Domain

# Block incoming HTTP requests with a specific Host header
iptables -A INPUT -p tcp --dport 80 -m string --string "Host: malicious-site.com" --algo bm -j DROP

# Block incoming HTTPS requests (only works if TLS is terminated before iptables, e.g., at a load balancer)
# Note: For encrypted HTTPS traffic, iptables cannot inspect the payload
iptables -A INPUT -p tcp --dport 443 -m string --string "malicious-site.com" --algo bm -j DROP

Important limitation: String matching only works on unencrypted traffic. For HTTPS connections, the HTTP headers are encrypted within the TLS tunnel, so IPTables cannot inspect the Host header. You can still match the SNI (Server Name Indication) extension in the TLS ClientHello, which is sent in plaintext, but this requires matching the raw bytes of the SNI field.

Block Outbound Requests to a Specific Domain

# Prevent your server from making HTTP requests to a specific domain
iptables -A OUTPUT -p tcp --dport 80 -m string --string "Host: bad-domain.com" --algo bm -j DROP

# Block outbound connections to a known C2 server
iptables -A OUTPUT -p tcp --dport 80 -m string --string "malware-c2.example.com" --algo bm -j DROP
iptables -A OUTPUT -p tcp --dport 443 -m string --string "malware-c2.example.com" --algo bm -j DROP

Blocking Specific Ports

The most straightforward way to block HTTP traffic is by port:

Block All HTTP Traffic

# Block all incoming HTTP requests
iptables -A INPUT -p tcp --dport 80 -j DROP

# Block all incoming HTTPS requests
iptables -A INPUT -p tcp --dport 443 -j DROP

# Block all outgoing HTTP/HTTPS requests from the server
iptables -A OUTPUT -p tcp --dport 80 -j DROP
iptables -A OUTPUT -p tcp --dport 443 -j DROP

Block HTTP on Non-Standard Ports

# Block common alternative HTTP ports
iptables -A INPUT -p tcp --dport 8080 -j DROP
iptables -A INPUT -p tcp --dport 8443 -j DROP
iptables -A INPUT -p tcp --dport 8888 -j DROP

# Block a range of ports
iptables -A INPUT -p tcp --dport 8000:8999 -j DROP

INPUT vs OUTPUT Chain Usage

Understanding when to use the INPUT chain versus the OUTPUT chain is critical for effective HTTP blocking:

INPUT Chain

The INPUT chain processes packets destined for the local server. Use it to block incoming HTTP requests from external clients:

• Block specific clients from accessing your web server
• Block requests with suspicious host headers
• Block traffic from specific IP ranges
• Filter unwanted user agents or request patterns

# Block a specific IP from accessing the web server
iptables -A INPUT -p tcp --dport 80 -s 198.51.100.0/24 -j DROP \
  -m comment --comment "Block: abusive scanner network"

# Block requests containing a specific URL path
iptables -A INPUT -p tcp --dport 80 -m string --string "GET /wp-login" --algo bm -j DROP \
  -m comment --comment "Block: WordPress login probes"

OUTPUT Chain

The OUTPUT chain processes packets originating from the local server. Use it to control what your server can connect to over HTTP:

• Prevent compromised software from phoning home to command-and-control servers
• Restrict which external APIs or services your server can contact
• Block outbound web requests from services that should not be making them
• Prevent data exfiltration over HTTP/HTTPS

# Only allow outbound HTTP to specific trusted destinations
iptables -A OUTPUT -p tcp --dport 80 -d 151.101.0.0/16 -j ACCEPT \
  -m comment --comment "Allow: outbound HTTP to CDN"
iptables -A OUTPUT -p tcp --dport 443 -d 151.101.0.0/16 -j ACCEPT \
  -m comment --comment "Allow: outbound HTTPS to CDN"

# Block all other outbound HTTP/HTTPS
iptables -A OUTPUT -p tcp --dport 80 -j DROP \
  -m comment --comment "Block: all other outbound HTTP"
iptables -A OUTPUT -p tcp --dport 443 -j DROP \
  -m comment --comment "Block: all other outbound HTTPS"

FORWARD Chain

The FORWARD chain processes packets being routed through the server (when the server acts as a gateway or router). This is relevant for blocking HTTP on servers that route traffic for other machines on the network:

# Block HTTP forwarding for specific internal hosts
iptables -A FORWARD -p tcp --dport 80 -s 10.0.1.50 -j DROP \
  -m comment --comment "Block: no HTTP for quarantined host"

Practical Examples

Block WordPress Scanning Probes

# Block common WordPress exploitation attempts
iptables -A INPUT -p tcp --dport 80 -m string --string "wp-login.php" --algo bm -j DROP
iptables -A INPUT -p tcp --dport 80 -m string --string "xmlrpc.php" --algo bm -j DROP
iptables -A INPUT -p tcp --dport 80 -m string --string "wp-admin" --algo bm -j DROP

Block Specific HTTP Methods

# Block TRACE method (potential security risk)
iptables -A INPUT -p tcp --dport 80 -m string --string "TRACE /" --algo bm -j DROP

# Block DELETE method
iptables -A INPUT -p tcp --dport 80 -m string --string "DELETE /" --algo bm -j DROP

Block Requests with Empty or Missing Host Header

# Many automated tools and scanners do not set proper Host headers
# Block HTTP/1.0 requests without Host header by blocking the specific pattern
iptables -A INPUT -p tcp --dport 80 -m string --string "HTTP/1.0" --algo bm \
  ! -m string --string "Host:" --algo bm -j DROP

Block by IP and Port Combination

# Block a list of known bad IPs from HTTP access
for ip in 198.51.100.10 198.51.100.20 203.0.113.50; do
  iptables -A INPUT -p tcp --dport 80 -s $ip -j DROP \
    -m comment --comment "Block: known scanner $ip"
  iptables -A INPUT -p tcp --dport 443 -s $ip -j DROP \
    -m comment --comment "Block: known scanner $ip"
done

Performance Considerations

String matching in IPTables has performance implications that you should consider:

• CPU overhead: Each packet passing through a string match rule requires the kernel to search the packet payload. On high-traffic servers, many string match rules can measurably increase CPU usage.
• Rule ordering: Place string match rules after simpler rules (like IP-based blocks) to reduce the number of packets that need string inspection. IP-based checks are much faster than string searches.
• Use --from and --to: Limiting the byte range that is searched improves performance. HTTP Host headers are typically within the first 500 bytes of the request, so you can limit the search: --from 0 --to 500.
• Prefer IP-based blocking: When possible, block by IP address rather than by string matching. Resolving a domain to its IP addresses and blocking those IPs is more efficient than matching the domain name in every packet.

# More efficient: limit search range
iptables -A INPUT -p tcp --dport 80 -m string --string "Host: bad-site.com" --algo bm --from 0 --to 500 -j DROP

# Even more efficient: block by IP instead
iptables -A INPUT -p tcp --dport 80 -s 198.51.100.55 -j DROP

When to Use IPTables vs. Other Solutions

IPTables-based HTTP blocking is a useful tool but is not always the best choice. Here is how it compares to alternatives:

IPTables vs. .htaccess

• IPTables: Blocks at the kernel level before the request reaches the web server. More efficient for IP-based blocks and reduces web server load. Cannot inspect decrypted HTTPS content.
• .htaccess: Blocks at the Apache level after the request is received and (for HTTPS) decrypted. Can inspect all HTTP headers, perform regex matching, and use Apache modules for complex rules. Easier to manage but only works with Apache.

IPTables vs. WAF

• IPTables: Lightweight, kernel-level, and always available on Linux. Limited application-layer inspection. Cannot handle encrypted traffic inspection.
• WAF: Purpose-built for application-layer security. Can inspect decrypted HTTPS traffic, understand HTTP semantics, detect XSS, SQL injection, and other attacks. Much more capable but requires additional software. Consider a WAF solution for comprehensive web application protection.

IPTables vs. Nginx/Apache Configuration

• IPTables: Best for IP-based blocks, port restrictions, and basic string matching. Works regardless of which web server you run.
• Web server config: Better for user agent blocking, URL rewriting, conditional redirects, and rules that need access to parsed HTTP headers. Works with decrypted HTTPS content.

Combining Approaches

In practice, a layered approach works best:

1. IPTables (first layer): Block known bad IPs, enforce port restrictions, apply rate limiting. This reduces the volume of traffic your web server needs to handle.
2. Web server configuration (second layer): Block by user agent, enforce URL restrictions, handle redirects and rewrites. This addresses application-layer concerns.
3. WAF (third layer): Inspect request content for injection attacks, detect automated tools, enforce rate limits per URL or session. This provides the deepest level of protection.

Logging Blocked Requests

Always log blocked HTTP requests so you can analyze attack patterns and verify that legitimate traffic is not being caught:

# Log before dropping
iptables -A INPUT -p tcp --dport 80 -m string --string "Host: bad-site.com" --algo bm \
  -j LOG --log-prefix "HTTP-BLOCKED: " --log-level 4
iptables -A INPUT -p tcp --dport 80 -m string --string "Host: bad-site.com" --algo bm -j DROP

Regularly review your firewall logs to identify false positives and adjust your rules accordingly.

Summary

IPTables provides a versatile toolkit for blocking HTTP requests at the kernel level, from simple port-based blocks to content-aware string matching. Use the INPUT chain to filter incoming requests and the OUTPUT chain to control outbound connections. While IPTables is effective for IP-based blocking and basic string matching, a WAF or web server configuration is better suited for complex application-layer filtering. Layer your defenses by combining IPTables with web server rules and a WAF for comprehensive HTTP security. For related firewall configuration topics, see our guides on rate limiting and default block policies.

Need comprehensive web protection? Explore NOC.org plans to get started.