XFF and Syslog Output

Help
1

Folks,

Please bear with me if this has been addressed before, but I haven’t been able to find it. I realize that you can make the eve.json output rewrite the source IP with the XFF (X-Forwarded-For) IP. In the old days before unified2 was deprecated, I used to do this for unified2 as well, and that had barnyard2 syslog these over to our SIEM. Of course, unified2 support is gone, and now I’m using the built-in syslog functionality in Suricata. Is there any way to make Suri rewrite the source IP with XFF IP in the syslog messages? I tried just copying the xff portion of suricata.yaml down to the syslog area, but it didn’t seem to have any effect. Thanks!

2

Hi,

Have you tried adding this yaml key under the syslog config definition?
Not tried it myself so might not work.

3

Yes - it currently looks like this:

----------------

  # a line based alerts log similar to fast.log into syslog
  - syslog:
      enabled: yes
      # reported identity to syslog. If ommited the program name (usually
      # suricata) will be used.
      identity: "suricata"
      facility: local5
      level: Info
      #level: Info ## possible levels: Emergency, Alert, Critical,
                   ## Error, Warning, Notice, Info, Debug
      xff:
        enabled: yes
        mode: overwrite
        deployment: forward
        header: X-Forwarded-For

----------------

It doesn’t throw any errors, it also doesn’t rewrite the IP address in the alerts to syslog.

4

Can you try it with the eve.json output and compare it?

5

I am also doing eve.json output (different use-case) - that does the XFF rewrite correctly. It’s part of what is leading to the confusion - our SOC looks at the SIEM and sees the unrewritten address (coming via syslog), and then uses a utility which is based on the eve.json output that has the correctly rewritten source. Needless to say, they have a difficult time reconciling the two.

6

In that case I would recommend to file a bug report at the redmine Overview - Suricata - Open Information Security Foundation since it seems to be only an issue with the syslog output. Provide as much details as possible.

The syslog is not used much anymore, besides the general suricata process log, since eve.json offers much more. Any reason why you use both? If it’s crucial I would always try to rely on the eve.json output as the best supported.

7

Honestly? I’d rather not be using it, but my organization uses IBM QRadar - that don’t appear to have log parsing for native Suricata eve.json - but it parses fine if you send the traditional syslog output (because it looks like Snort). I would much rather be done with that output as well, but my hands are somewhat tied at the moment due to the SIEM.

8

Not even general JSON parsing? That’s bad. It should be fixed but might also be better to write a small tool to convert eve.json to whatever QRadar likes :slight_smile: