I have installed suricata behind the proxy server. I add the client source IP address to the proxy using the xff header. I also set the eve log on the suricata using x-forwarded-for and everything is fine in the eve log. However, I have a problem if I write a rule with a specific IP address. Nothing is written to the log. The same issue for geoip.
Sample rules (This is just an example):
client source IP: 22.214.171.124
proxy source IP:126.96.36.199
A) alert http any any -> any any (msg: “TEST IP”; sid: 1; rev: 1;)
B) alert http 188.8.131.52 any -> any any (msg: “TEST with SOURCE IP”; sid: 2; rev: 1;)
Example A works fine and is written to the log with the correct client source IP address.
Example B does not work and is not written to the log at all.
If I write a rule ( C ) with a source proxy IP address, everything works. I see the original client source IP address in the eve log (184.108.40.206)
C) alert http 220.127.116.11 any -> any (msg: “TEST with SOURCE IP”; sid: 2; rev: 1;)
Is there any way for both rules and geoip to work with the xff header and not with the source proxy IP address?
I apologize for my English.
Please does anyone know how to solve this? It’s causing me a lot of trouble on the network.
From the comments in the suricata.yaml file related to xff settings:
# HTTP X-Forwarded-For support by adding an extra field or overwriting
# the source or destination IP address (depending on flow direction)
# with the one reported in the X-Forwarded-For HTTP header. This is
# helpful when reviewing alerts for traffic that is being reverse
# or forward proxied.
I assume you have set the xff options for the eve.json log output.
My understanding of the above quote is that Suricata will rewrite the source or destination IP in the logging logic based on xff headers, but not in the matching logic. This makes some sense.
A rule like
alert ip 18.104.22.168 any -> $HOME_NET any ([...] would be evaluated by Suricata during layer 3 packet parsing before Suricata has any knowledge about HTTP headers.
I believe Suricata theoretically could replace the source IP with an IP from the xff header for
alert http rules, but I don’t think that’s the case. I might be wrong though.
Devs are welcome to correct me.
Hi yes you understand that correctly. I hope you are wrong because if you have right the function like geoip, iprep etc… are unusable behind the proxy.
Unfortunately @syoc is correct. The xff functionality currently only applies to output.
Using xff (and similar headers) in the detection engine would be quite a bit of work. Just overwriting the data in the packet would be tricky and risky too. Headers can be easily faked, and they might be used to bypass controls. Also, modifying packets would also affect things like pcap logging, IPS, etc.
To support this I think it’d be best to extend keywords like geoip/iprep, etc to have logic for xff specifically, though how this would look would definitely need careful thought.
So I created two new topics after your advice. The newly created topics are: Geoip / iprep doesn’t work correctly with X-Forwarded-For (xff) and Check https connection. Thank you.