Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 7 subscribers
  • Views 1783 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Graylog not accepting syslog data from UTM 9 due to datetime issues

Klaus Ginzel

Hi guys,

we are using Graylog 5 / OpenSearch 2.1 and want to ingest UTM 9 logfile data. Unfortunately the transmitted datetime format is not as the syslog RFC requests (FULL-DATE "T" FULL-TIME, see https://www.rfc-editor.org/rfc/rfc5424 ) so Graylog can't handle them. I cant find any option to change this in UTM management console and changing the syslog-ng.conf doesnt help either because it get's overwritten by UTM as soon as the server or syslog service restarts.

Anyone here who had the same issue and somehow solved it, please? There is an extractor someone already built to import the data by using an Graylog extractor ( https://community.graylog.org/t/graylog-sophos-utm-9-extractors/23122 ) but I'm wondering if there is also another solution. And, if possible, this could be solved with a patch. Slight smile

Cheers,
Klaus



This thread was automatically locked due to age.

Top Replies

  • +1 verified

    Per default, the /etc/sslog-ng in the utm contains "template("<$PRI>$YEAR:$MONTH:$DAY-$HOUR:$MIN:$SEC $HOST $MSGHDR$MSG\n")" which is what you see.
    You might replace tis with "template("<$PRI>$ISODATE $HOST $MSGHDR$MSG\n")" or whatever your logging solution expects.

    However I recommend fixing it by being tolerant at the receiving side.
    We use syslog to capture messages from all sort of devices apart servers (switches, PBX, sensors, printers, tape librarys, alerting devices, cameras, WLAN APs and all other embedded stuff in use as long as they support it). Often they have their own message format (some of them may not even have a clock integrated) and capturing any message is crutial. So we use a very relaxed filtering (as long as the sender can clearly be identified it gets logged).

    Jump to answer
Parents
  • 0

    I know these are less than ideal, but my solutions have been either to:

    • Run syslog-ng agent on the Graylog server so it prepends a proper RFC5424 timestamp to the beginning of the message then redirects to localhost:1514 where the Graylog Syslog Input is listening.
    • Use the Raw Input and a pipeline rule to rewrite the timestamp during ingestion. It's pretty low resource cost in my experience.
Reply
  • 0

    I know these are less than ideal, but my solutions have been either to:

    • Run syslog-ng agent on the Graylog server so it prepends a proper RFC5424 timestamp to the beginning of the message then redirects to localhost:1514 where the Graylog Syslog Input is listening.
    • Use the Raw Input and a pipeline rule to rewrite the timestamp during ingestion. It's pretty low resource cost in my experience.
Children
No Data