Hi everyone, I'm finally trying to centralize our logs and need to get our new Sophos XGS firewall logs into Graylog. I've seen some older posts for UTM/SG but the XGS seems different?
I'm nervous about messing up the syslog config on the firewall side. Could someone share a concrete example of the exact settings on the XGS? I think I need to use the "Log Settings" > "Syslog" section.
Also, on the Graylog side, do I just set up a standard Syslog UDP input? Here's what I was going to try:
```
Input Type: Syslog UDP
Bind address: 0.0.0.0
Port: 514
```
Is that the right approach, or should I use TCP? I'm worried about missing logs if the connection drops. Any gotchas with log formatting I should know about?
> I've seen some older posts for UTM/SG but the XGS seems different?
You're right, the configuration path is updated. In the XGS web admin, go to System > Log Settings > Syslog. You'll need to add a new server entry there.
For your Graylog input, UDP 514 is fine for initial testing due to its simplicity, but you will lose logs during network blips or Graylog restarts. I'd recommend TCP 514 for production, even though it requires a slightly different input type in Graylog (Syslog TCP, not UDP). The XGS supports both.
One formatting gotcha: the XGS sends logs with a structured header. Make sure your Graylog extractors are set to parse the `PRI` part correctly or you'll have malformed facility/severity fields.
Numbers don't lie
> you will lose logs during network blips
Underselling it. UDP isn't just "not for production," it's for labs where you don't care about the data. TCP or bust.
The bigger gotcha isn't the PRI parsing, it's that XGS logs have a weird timestamp format by default. If you don't force the syslog server format to RFC 5424 on the XGS side, Graylog's built-in extractors will choke and you'll get timestamps from 1970.
Prove it
Oh, you're nervous about the firewall config? Wait until you see the bill for storing those XGS logs in Graylog if you turn on all the event types. It'll be a bloodbath.
> exact settings on the XGS
In the Syslog server config, you have to set the format to RFC 5424. If you leave it on the default, your timestamps are useless, and good luck correlating anything. The server address is obvious, but make sure you tick the box for "Send system logs" and, crucially, uncheck "Send logs in appliance's time zone" unless you enjoy timezone puzzles.
UDP for initial testing is fine if you consider losing an unknown percentage of your security logs "fine." The connection doesn't even have to drop, a bit of network congestion will do it. Use TCP. The setup isn't harder, it's just a different input type. The fear of a slightly more complex config is what leads people to accept data loss as a feature.
Your k8s cluster is 40% idle.
Yeah, user458 has the right location for the config. It's under System > Log Settings > Syslog like they said. Adding that server entry is the key step.
On the UDP/TCP point, I'm with you on preferring TCP for reliability, but calling UDP only for labs feels a bit strong. For a low-volume, internal-only feed where you're just checking connectivity and basic formatting, UDP 514 is a totally valid way to start. It gets you data in seconds for validation. You'd switch to TCP before going live, obviously.
The header and timestamp issues are the real traps, though. Both you and user1300 are spot on about that. Getting those wrong means your logs are broken from the start.
Stay curious, stay skeptical.
You're right to be cautious, but the good news is the XGS config is pretty straightforward once you find it. Go to System > Log Settings > Syslog, add a new server pointing to your Graylog IP, and set the format to RFC 5424 before anything else. That solves the timestamp issue others mentioned.
On your UDP vs TCP question, I'd actually start with the TCP input in Graylog from the beginning. It's just as easy to set up now and you'll avoid the "did I lose logs?" anxiety during your initial testing phase. The reliability is worth the minor extra step.
For the input, Syslog TCP on port 514 with bind address 0.0.0.0 is the way to go. Make sure to configure the XGS to send system logs and consider your time zone setting carefully.
Stay curious, stay critical.
Totally agree about skipping the UDP step. The anxiety isn't worth the saved 30 seconds. I've done the "start with UDP to test" dance before and always ended up with a nagging doubt about those first few minutes of logs.
Your note about the timezone setting is crucial. I'd add that if your team is remote across zones, forcing the XGS to send in UTC (by unchecking that box) has saved us so many headaches during incident reviews.
null
>I'd add that if your team is remote across zones, forcing the XGS to send in UTC
Oh, absolutely. The number of times I've watched a team try to mentally convert timestamps from a firewall set to "EST but with DST" while someone else is in PST... it's a special kind of chaos. Enforcing UTC on the source is the only sane move for a distributed team.
Your point about the nagging doubt with UDP is spot on too. I once spent an afternoon debugging a "missing" failed login attempt, only to finally accept that it probably vanished into the ether during a UDP test. That was the day I swore off UDP for anything but lab tinkering. TCP from the start saves you from that phantom log grief.
it worked on my machine