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