In my homelab, I have Traefik being my reverse proxy and Nginx doing my HTTP services and Suricata is inspecting, and when an alert is generated with XFF enabled it alerts according to this config:
- eve-log:
enabled: yes
filetype: syslog
identity: "suricata"
facility: local5
level: Info
metadata: yes
pcap-file: false
community-id: true
community-id-seed: 0
xff:
enabled: yes
mode: extra-data
deployment: reverse
header: X-Forwarded-For
types:
- alert:
payload: yes
payload-buffer-size: 4kb
payload-printable: yes
packet: no
# metadata: no
metadata:
app-layer: true
flow: true
rule:
metadata: true
raw: true
reference: true
http-body: no
http-body-printable: no
websocket-payload: no
websocket-payload-printable: no
tagged-packets: yes
The notes about XFF Forward and Reverse are:
# Two proxy deployments are supported: "reverse" and "forward". In
# a "reverse" deployment the IP address used is the last one, in a
# "forward" deployment the first IP address is used.
In one alert looking for malicious incoming traffic to a web server the order of the Hosts is:
"xff": "1.2.3.4, 192.168.2.3",
1.2.3.4 == external host browsing my HTTP server
192.168.2.3 == my reverse proxy
The notes around XFF say, ‘reverse’ == last, and ‘forward’ == first - and I wanted to mention that it would appear I would have to ‘mis-configure’ my Suricata according to the notes to get the desired outcome for this alert with respect to the incoming nature of the traffic/alert.
It appears that if the alert fires on the outgoing traffic/response from the http server, the XFF is parsed correctly given the config syntax comment, but if the alert fires on the incoming traffic it appears to still show both values in the XFF and otherwise uses the Last entry as the Alert instead of the first that is the source of the traffic.
Would be happy to dig into this further, I just happened to notice it recently, running Suricata 8.0.3.