Suricata + Reverse Proxy (HTTPD/Apache)

For anyone interested in this:

I’m using a combination of nftables (with NFQUEUE) and Suricata. Initially, I encountered issues where Suricata wasn’t detecting my HTTP/HTTPS traffic.

It turned out the solution was quite simple, I discovered that the way the ruleset is configured is crucial for ensuring proper traffic inspection.

My current working configuration:

include "/etc/nftables/variables.conf"

table ip filter {
	set blocked_countries {
		type ipv4_addr
		flags interval
	}
	
	chain prerouting {
		type nat hook prerouting priority -100; policy accept;
		iifname $WAN tcp dport 18443 dnat to $QBITTORRENT:18443
		iifname $WAN tcp dport 8888 dnat to $MYSQL:3306
		ip saddr $BRABEN-OVPN-USER2 ip daddr $MYSQL tcp dport 8888 dnat to $MYSQL:3306
		queue num 0 bypass
	}
	
	chain input {
		type filter hook input priority 0; policy drop;
		tcp dport { 80, 443 } queue num 0 bypass
		tcp sport { 80, 443 } queue num 0 bypass
		ct state established,related accept
		iifname "lo" queue num 0
		ip saddr @blocked_countries drop
		ip saddr $LAN-SUBNET tcp dport 53 accept
		ip saddr $LAN-SUBNET udp dport 53 accept
		ip saddr $VPN-SUBNET tcp dport 53 accept
		ip saddr $VPN-SUBNET udp dport 53 accept
		ip saddr $COMPANY-WAN tcp dport 22 accept
		ip saddr $BRABEN-OVPN-USER1 tcp dport 22 accept
		iifname $LAN tcp dport 22 accept
		iifname $LAN udp dport 68 accept
		iifname $LAN udp sport 67 udp dport 68 accept
		udp dport 1194 accept
	}

	chain forward {
		type filter hook forward priority 10; policy drop;
		ip saddr @blocked_countries drop
		ip daddr @blocked_countries drop
	
		# queue everything to Suricata
		queue num 0 bypass
	}
	
	chain postrouting {
		type nat hook postrouting priority 0; policy accept;
		oifname $WAN ct state established,related,new masquerade
	}

	chain output {
		type filter hook output priority 0; policy accept;
		ip daddr @blocked_countries drop
#		ip protocol tcp queue num 0 bypass
		tcp dport {80, 443} queue num 0 bypass
		tcp sport {80, 443} queue num 0 bypass
	}
}

I believe this configuration has potential for improvement, but I’m still in the process of testing and learning.

Currently, the issue is resolved, as Suricata is now successfully detecting traffic to and from the reverse proxy.

If I understand correctly, when someone connects to my WAN IP or via an FQDN defined in a virtual host file, the TLS handshake is managed by the reverse proxy. After that, the traffic is sent unencrypted to the backend web server within the same network. My plan is to enable encryption for this internal traffic by generating certificates and configuring TLS between the reverse proxy and the backend servers.

Regards,
Steven