No messages despite all is looking good?

Graylog Central (peer support)
, ,
1

Followed instructions here: https://go2docs.graylog.org/5-0/getting_in_log_data/graylog_sidecar.html

Running:

  • Graylog 4.2 and as of what is documented I installed Sidecar 1.2
  • Windows Server 2016 w/Exchange Server.

Challenge:
I can’t seem to receive any messages, trying to forward Exchange transport- and connector-logs.
I’ve followed a few tutorials on this, and they all seem quite the same. But I have a feeling that I’ve completely miss out on something vital in here somewhere. Something tells me it might need some input regarding how to parse these log files. But dunno. Any help are appreciated.

Since I am not allowed to include more than one embedding and had already made the whole post, I chose to just dump it in a PDF and share it through Google drive.
Screen shots/configs : https://drive.google.com/file/d/1UNvSKjw1MK-erexTjC4HVqjJIQHSbPr6/view?usp=sharing

  • Collector status (looks all good).
  • Mapped ports on container works.
  • Service running healthy on node (Windows Server 2016)
  • No firewall activated on docker host running Graylog server.
  • Created a GELF UDP input for testing, and it listens on UDP port. But seems it dont, on UDP port 5044.
  • Both nodes on same subnet/fw-zone and fw-interface/nettwork L2.
  • No errors in Sidecar logs.

What am I missing out?

Please see the PDF with all the info/screen shots.

2

Hey @buksa && Welcome

Setting look good, Check Timezone/Timestamp. Some times this does ahve affect when you can see the logs. Only other thing I can think of is try TCPDUMP on graylog see if Windows Logs are reaching Graylog.I’m not sure if you check Graylog-Sidecar logs

3

Thanks for helping out @gsmith :slight_smile:

You make a good point on the matter of time sync, I have forgot to configure ntp properly on this test server (Ubuntu 22.04 LTS vm), I only did that on the production one! So I will get right to it now.

EDIT: No it is actually done, because I cloned the VM running the production instance of Graylog server. It syncs towards the DC which is correct. It has only gotten it’s own IP and additionally mapped the port winlogbeat is running on/the input is running on.

  1. Would you mind to elaborate on the TCPDUMP you are referring to here?

–>> 1b. Would it be better/higher chance of them arriving, if I change to TCP? Or would it “explode” the network with TCP traffic by doing this? If I can still use UDP I think it will be the best for our network and CPU loads…

  1. I can see some files in the same directory, as the log for the Sidecar service file. These are named “winlogbeat.x”, where x represents a number.
    I opened one of these files in notedpad, and yes, they’re full of parsed logs. :slight_smile:

  2. How come that when I am probing the UDP port with powershell as showed in the PDF, why is it saying that it is NOT listening on that UDP port? I cannot be a network thing. Same network, and no active fw on either the Ubuntu-server nor the Windows server. Where in the Sidecar config can I see which port and proto it actually is configured to use? These are configs that I haven’t actually comed across anywhere. Just the tutorial that says it will be using UDP port 5044.

Thanks again! :slight_smile:

4

hello @buksa

Something like this, pretty similar to wireshark.

sudo tcpdump -n host 192.168.1.185

Either one is good, TCP connects have a tendency to show connection issues in the log file.

5

@gsmith Thanks for helping me.

I am still not sure though: What protocol and port are logs by default sent as, from the Sidecar service?
I have only forwarded 5044 UDP into the container, not TCP. Maybe this is the issue?

Do you have any other advice for me here?

We had an earlier setup that we created using a concept called “LME” or “Logging Made Easy”. It is a combined configuration consisting of Logstash, Elasticsearch, and Kibana. The setup works like this: Sysmon sends logs from Events and Applications to a centralized Winlogbeat-server, which runs it through some parsing scripts in Java before forwarding it to the Logstash server with Elasticsearch and Kibana.

Unfortunately, the Logstash server is no longer running due to a crash, and we had to scrap it. I want to switch to Graylog instead since I have prior knowledge of it, and we also have network devices logging to this server.

The reason for mentioning all this is to ask if I can set up a similar input and direct the existing installation of Winlogbeat to the Graylog server?

This is the current config in the winlogbeat.yml:

winlogbeat.event_logs:
  - name: ForwardedEvents
    tags: [forwarded]
    processors:
      - script:
          when.equals.winlog.channel: Security
          lang: javascript
          id: security
          file: ${path.home}/module/security/config/winlogbeat-security.js
      - script:
          when.equals.winlog.channel: Microsoft-Windows-Sysmon/Operational
          lang: javascript
          id: sysmon
          file: ${path.home}/module/sysmon/config/winlogbeat-sysmon.js

output.logstash:
  hosts: ["host.ourdomain.local:5044"]
  ssl.certificate_authorities: ["C:\\Program Files\\lme\\root-ca.crt"]
  ssl.certificate: "C:\\Program Files\\lme\\wlbclient.crt"
  ssl.key: "C:\\Program Files\\lme\\wlbclient.key"

I asked ChatGPT on how to change the outout so that it sends logs to Graylog server instead of the Logstash server, and it gave me this:

output.graylog:
  hosts: ["x.x.x.x:514"]
  tcp:
    enabled: true
    tls:
      enabled: false
    ssl:
      enabled: false

or

output.graylog:
  hosts: ["graylog-server:5044"]
  path: "/api/beats"
  bulk_max_size: 1024
  timeout: 60
  username: "beats-sidecar"
  password: "your-sidecar-token"

But the service just crashes when restarting it. And I cannot find any logs from the service itself. So it is hard so check what’s wrong.

6

@gsmith

I solved the issue by opening up forwarding for TCP-port 5044 instead of/in addition to the UDP-port.
This was into the container, so just had to modify the docker-compose to include this port.

Thanks for helping out!

1 Like
7

awesome-yes-will-ferrell (1)

Glad you resolved it :+1:

8

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