racksec / srslog Goto Github PK

Currently net.Dial and tls.Dial allows connection to take forever, it can stuck setup of syslog service.

However net.Dial can be changed to net.DialWithTimeout and tls.Dial to tls.DialWithDialer passing net.Dialer.

Since TCP protocol only guarantee no data loss on the air, but the data in the TCP send buffer may lose. The RELP initialized by rsyslog aims to fix it. Could we consider to suppport RELP?

My solution needs to be FIPS-140-2 compliant, which is partly done by using a Go wrap of openssl for all cryptography instead of the standard net/crypto packages.
If a method were exposed that allowed me to add an entry to the dialers map in dialer.go, then I could register a method to call the dialer of my choice.
I've done this on a local copy of srslog. Is the any interest in adding this to the public branch?

The RFC says the syslog format is (according to the syslog-ng doc):
HEADER STRUCTURED-DATA MSG

A sample could be

<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8

that corresponds to the following format

<priority>VERSION ISOTIMESTAMP HOSTNAME APPLICATION PID MESSAGEID STRUCTURED-DATA MSG

(ref: https://www.balabit.com/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/concepts-message-ietfsyslog.html)

The RFC documentation (from IETF) says:

STRUCTURED-DATA provides a mechanism to express information in a well
defined, easily parseable and interpretable data format.  There are
multiple usage scenarios.  For example, it may express meta-
information about the syslog message or application-specific
information such as traffic counters or IP addresses.

STRUCTURED-DATA can contain zero, one, or multiple structured data
elements, which are referred to as "SD-ELEMENT" in this document.

In case of zero structured data elements, the STRUCTURED-DATA field
MUST contain the NILVALUE.

(ref: https://tools.ietf.org/html/rfc5424#section-6.3)

In our case, the best would be to add an hyphen (that is the NILVALUE indicated by the RFC) between the HEADER and the MESSAGE.

What do you think?

Hi

Is there any way to set loggers log level ? I would like to log messages up to LOG_ERR.

Linking from: moby/moby#21613 .

Currently users of srslog (like Docker) must explicitly specify unix:// or unixgram:// when connecting to a Unix socket. Should srslog abstract this and simply retry connecting with another protocol if the first one fails? This is also the behavior of glibc (see comments in the issue above).

I noticed that the formatter.go does not generate the Log according to RFC3164 specifications. There is a space between the priority and the timestamp whereas in the RFC the format specified says that there should be no space. Please find below an example taken from the RFC:
Example 1
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8

The reason I pointed this out is because docker syslog uses this package for formatting and this is causing problems when I try to send the logs to a remote syslog (and trying to process them - gives me a parse error).

Also, if required I can open a pull request to do this change, as it seems to me as simple as removing a space. Please let me know if I am missing something here.

I use

w, err := syslog.Dial("tcp", "192.168.0.51:514", syslog.LOG_ERR, "testtag")
if err != nil {
  if n, err := w.Write([]byte("these are some bytes")); err != nil {
    log.Println("Sent %d bytes to syslog server\n", n)
  }
}

to connect to a rsyslog server, and the server is set to $InputTCPServerStreamDriverMode 1, which means it accepts TLS connection only.

The running result is that I was told

Sent 21 bytes to syslog server

but actually it's not the truth. Because the rsyslog server said,

rsyslogd: gnutls returned error on handshake: An unexpected TLS packet was received. [v8.31.0 try http://www.rsyslog.com/e/2083 ]
rsyslogd: gnutls returned error on handshake: An unexpected TLS packet was received. [v8.31.0 try http://www.rsyslog.com/e/2083 ]

The way I see it, a tag is specified in the Dial 'constructor' and used for both the tag and msgid fields for RFC3164 and RFC5424 msg formats respectively. This is fine for RFC3164 because the tag doesn't typically change from message to message. But for RFC5424, the msgid should likely change, based on the msg type.

RFC5424 detailing MSGID: https://tools.ietf.org/html/rfc5424#section-6.2.7

I'm looking for consensus that this should be considered a 'defect', then I can put my thinking cap on regarding solutions.