Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 8 subscribers
  • Views 2587 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.
Parents
  • +1

    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).

Reply
  • +1

    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).

Children
  • 0 in reply to Alan Brand

    The issue with changing the template is that after a reboot / change in the UI for syslog the template gets resetted to the original value so there would be more work needed.. also changes done by root will void the support. So I'll stick to the workaround, but thanks a lot for the explanation. Slight smile

  • 0 in reply to Klaus Ginzel

    You could make a simple cronjob to run a one-liner replacement for this format string every reboot. Just add this line to `/etc/crontab-static`:

    @reboot root sed -i 's/<$PRI>$YEAR:$MONTH:$DAY-$HOUR:$MIN:$SEC/<$PRI>$ISODATE/g' /etc/syslog-ng.conf

    Then make an arbitrary config change in the UI (e.g. go to Management > Up2Date, then configuration tab, and change one of the intervals to 'Manual', click Apply, switch back to previous interval, click Apply again) to make the system write /etc/crontab-static to /etc/crontab so it will take effect.

Unfiltered HTML