Good day,
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: 1.2.3.4
proxy source IP:5.6.7.8
A) alert http any any -> any any (msg: “TEST IP”; sid: 1; rev: 1;)
B) alert http 1.2.3.4 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 (1.2.3.4)
C) alert http 5.6.7.8 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?
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 1.2.3.4 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.
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.
Hello Guys,
Well I’m running into the same problem these days and my Suricata sensor is installed behind a proxy. So how to make it alert with the real IP addresses but not the proxy IP.
thanks
The statement from above is still valid. You can use the xff option but besides that you will still see the actual IPs since that is how the traffic looks like. You could also sniff on the other side of the proxy in addition to that and correlate the events.