Logstash-output-syslog questions / improvements for central log hub towards other SIEM/Compliancy tool

Elastic Stack Logstash
1

Hi All,

Currently working on a project to replace a syslog-ng product ( balabit) in front of a SIEM solution, which centrally receives all messages and if needed forwards that unique event towards the SIEM in the compliant syslog format or LEEF/CEF format using a tcp plugin with leef/cef codec. In logstash we do alot of filtering and use elasticsearch/kibana for engineers to search and analyze. The SIEM is currently mainly used for compliancy reports and SOC. We cannot phase out the SIEM yet with Elastic unfortunately :sleepy:

Currently we use the syslog output plugin but I found out some things that can matter. I think the first two can be easily changed in the code (already tested this), but the third looks hard to implement.

  • TIMESTAMP that is used is not compliant with RFC3164, because the day should not have a zero-padded for day of the month, so dd should be d instead.

Example Feb 5 17:32:18 is correct and Feb 05 17:32:18 is incorrect if I read the RFC3164 well and after testing I see some formatting issues.

See section 5.4 at https://www.ietf.org/rfc/rfc3164.txt

Can this be changed in the plugin code ?

  • When testing various syslog streams we see that the plugin always wants a PID , but a pid is optional when reading the section 5.3, 5.4 at https://www.ietf.org/rfc/rfc3164.txt. Easiest is only insert PID with brackets ( tag[123]: after the %{pid} is available. We already have some situations that a PID (including brackets) are not in the message like following <167>May 4 14:23:23 server1 Vpxa: verbose vpxa[FFFCAB70]

Can this be changed in the plugin code ?

  • Other option I want to build in seems to be not that easy. If we forward a message we really should spoof the IP address of the %{host} field. In that case the SIEM is identifying the event source as ip source instead of our central/relay logstash agents. Syslog-NG has such option called source spoofing. It seems to be only possible with UDP, which is not that reliable.

Is it hard to add this to the plugin functionality ?

Did somebody else already implement such solution in front of a SIEM, such as qradar or Arcsight ? Which want to share practices ofcourse.

2

@arnold79
The date change request seems reasonable - especially given that the plugin offers a rfc3164 compliance mode.

I will reply to the other ideas in due course.

FYI This is a community maintained plugin and AFAIK @breml is the maintainer.

1 Like
3

Hi guy,

Thanks for your fast reaction and including @breml . About that the ${pid} is optional is also mentioned in the https://www.ietf.org/rfc/rfc3164.txt, see the su example 1 below (so to be rfc3164 compliance also). For third topic I'm indeed agree it's not related to the rfc3164 compliance, then a nice2have to implement a real relay solution.

Example 1 see (https://www.ietf.org/rfc/rfc3164.txt)

    <34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick
    on /dev/pts/8

This example shows an authentication error in an attempt to acquire
additional privileges. It also shows the command attempted and the
user attempting it. This was recorded as an original message from
the device called mymachine. A relay receiving this would not make
any changes before sending it along as it contains a properly
formatted PRI part and TIMESTAMP field in the HEADER part. The TAG
value in this example is the process "su". The colon has terminated
the TAG field and is the first character of the CONTENT field. In
this case, the process id (pid) would be considered transient and
anyone looking at this syslog message would gain no useful
information from knowing the pid. It has not been included so the
first two characters of the CONTENT field are the colon and a space
character.

4

I agree the PID is optional - according to the RFC3164.

1 Like
5

According to section 4.1.2 of RFC3164 (RFC 3164 - The BSD Syslog Protocol), the days lower than 10 MUST be prefixed with a space (so there are two spaces between the month and the digit for the day).

If the day of the month is less than 10, then it MUST be represented as a space and then the number.

This is not supported by sprintf, which is currently used to format the date in https://github.com/logstash-plugins/logstash-output-syslog/blob/master/lib/logstash/outputs/syslog.rb#L168 and therefore we will have to implement this on our own... So if you (@arnold79) already have working code, it would be nice, if you could provide this (PR in github, gist, etc.).

To have the PID optional, that is, it is only included, if there is present, does not look like a big problem.

The spoofing of the source ip address of the source system is not possible with TCP at all and there is currently no option within the UDP output, which would allow to change the source ip, If it is at all possible, I can not tell.

1 Like
6

Hi @breml . I did some minor testing on my sandbox VM, so better testing is preferred. Tomorrow I want to test it in the customer development environment. See below my github link

If you see some improvements or better/efficient code please replace this, I'm not a hardcore Ruby-master :smile_cat:

7

Hi @breml I did some additional testing with various dates ( with and without 2 spaces ) and updated the rspec file according that all tests succeed. Also updated the version (to 3.0.2) on my clone so you can validate this version. Hopefully this saves you guys some work :slight_smile:

Modified version https://github.com/avwsolutions/logstash-output-syslog/

Tomorrow I will test it at the customer location. I will let you guys know how the tests went.

8

Any update @arnold79?

9

Hi @Loek @breml I've tested our updates, which gave us the expected results. I've openened a PR in github.com see https://github.com/logstash-plugins/logstash-output-syslog/pull/37 .

Have a nice weekend

10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.