Sophos XG syslog based elastic integration not working...

[dohabandit]

I dumped my fully functional SO 2.3 based setup and took the plunge with a fresh start using SO 2.4.30.
I have several other threat intelligence based integrations working (AlienVault OTX, AbuseCH, etc.), and now I am trying to get my Sophos XG firewall logs to be ingested using the Sophos v3.4.0 integration. I don't see any sophos logs being ingested and wondering if someone else knows what I am missing.

I have a standalone configuration but have one IDH host that I added.
I enabled the integration and created one policy, and set the hostname and serial number (confirmed to match the XG's device_id from raw syslog messages.)
I set the policy to only allow Sophos XG logs using UDP and port 9005. I took all the defaults other than turning off UTM logs, TCP logs, and setting the hostname and device serial# which were listed in the example settings dialog.
I assigned the policy to the standalone node and the integration policy shows the standalone node as having it assigned.
I noticed when I did a netstat that UDP port 9005 was now bound to the 0.0.0.0. Okay, that's a good sign! Something is listening on that port now.

netstat -a -n | grep 9005
udp        0      0 127.0.0.1:9005          0.0.0.0:*

I however noticed that in IPTables, I found nothing listed in any chains for port 9005.

iptables --list | grep udp
ACCEPT     udp  --  172.17.1.0/24        anywhere             udp
ACCEPT     udp  --  securityonion        anywhere             udp
ACCEPT     udp  --  securityonion        anywhere             udp dpt:syslog
ACCEPT     udp  --  192.168.0.0/16       anywhere             udp dpt:syslog
ACCEPT     udp  --  securityonion        anywhere             udp

Hrmm. Let's check for drops.

Dec 17 00:35:31 securityonion kernel: IPTables-dropped: IN=ens160 OUT= MAC=00:50:56:a1:72:28:00:50:56:a1:bb:53:08:00 SRC=192.168.1.1 DST=192.168.1.21 LEN=925 TOS=0x00 PREC=0x00 TTL=64 ID=29558 DF PROTO=UDP SPT=43018 DPT=9005 LEN=905

Yep, so the host firewall is killing the syslog traffic on UDP 9005. Fixing this using the old method was to use SO-ALLOW, but I am going with the new 2.4 SOC configuration steps as much as possible here to learn the new methods.

So I went into the SO configuration settings via SOC, enabled advanced config under options, and then under Firewall->Portgroups->Syslog->udp, I added port 9005 to the default and deployed config to the standalone node.
After doing this I can see via IPTables that there is now a rule to allow my sophos XG subnet on udp 9005. Okay, so it should all be plumbed in through the network layer, so we should be good. NOPE.

iptables --list | grep 9005
ACCEPT     udp  --  securityonion        anywhere             udp dpt:9005
ACCEPT     udp  --  192.168.0.0/16       anywhere             udp dpt:9005

I still see nothing in the elastic logs. I also don't see an easy way to see what is being received on port 9005, or why the sophos integration is not matching/triggering a pipeline to process the logs. I know the logs are flowing though, and I sent them to another host to capture some raw logs to ensure the device_id in the log matches the ID I used for "serial_number" in the integration. Should this field name match the raw log?
Do I need to also enable rsyslog processing?

I ran a wireshark capture and the XG is firehosing the SO node on UDP 9005 with log data. Something is clearly wrong with my configuration or I missed a step somewhere. I searched sophos related integration issues and all the posts I am finding are old, or for earlier versions of SO.

What am I missing?

[dougburks]

What is the output of the following?

sudo iptables -nvL |grep 9005

Also, if you run the following command and look for each of your 9005 entries, what Chain are they in?

sudo iptables -nvL |more

[dohabandit]

I think the IPTables are good:

sudo iptables -nvL |grep 9005
    0     0 ACCEPT     udp  --  *      *       192.168.1.12         0.0.0.0/0            udp dpt:9005
    3  1971 ACCEPT     udp  --  *      *       192.168.0.0/16       0.0.0.0/0            udp dpt:9005

They are both in the INPUT chain:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  *      *       192.168.1.12         0.0.0.0/0            udp dpt:9005
    7  3901 ACCEPT     udp  --  *      *       192.168.0.0/16       0.0.0.0/0            udp dpt:9005

[dougburks]

The INPUT chain should be correct and the numbers on the left indicate that some traffic is making it through iptables:

    7  3901 ACCEPT     udp  --  *      *       192.168.0.0/16       0.0.0.0/0            udp dpt:9005

However, 7 packets seems like a small number for an active firewall especially when you say "the XG is firehosing the SO node".

Does that number seem correct to you?

[dohabandit]

I think it had just rolled over is why the number was low.
Here are some new numbers, I repeated the cmd a couple times to show the rate of increase.

   29 28571 ACCEPT     udp  --  *      *       192.168.0.0/16       0.0.0.0/0            udp dpt:9005
   32 31914 ACCEPT     udp  --  *      *       192.168.0.0/16       0.0.0.0/0            udp dpt:9005
 1221 1110K ACCEPT     udp  --  *      *       192.168.0.0/16       0.0.0.0/0            udp dpt:9005

I forgot to mention that I am using Sophos XG version SFOS 19.5.3 MR-3-Build652.

I am thinking I might just install a fresh SO 2.4 node and only apply the Sophos integration settings to see if something else I did broke something. When I created the IDH node, I cloned the agent rules and the original rules are on the IDH node and the new rules that also include the threat intel ingestion and sophos syslogs are on the cloned set.

Is there a way to see the elastic agent on the standalone node processing the traffic received on udp 9005?

[dohabandit]

Ha, okay. So I did a fresh install, ran all the steps I did last time and it still didn't work at first.
Even though the IPtables chain looks good, I think I might have discovered the issue. I'll know shortly if this is the case and will update for sure if this was cause.

What I did different was with the sophos integration, by default it said it would listen on "localhost". I changed this to 0.0.0.0.

Okay, this appears to be the issue. I guess I should have seen this issue sooner, however it doesn't make sense to have the sophos integration bind to localhost only and only receive syslog data from the securityonion node itself since the SO node is not an XG firewall. Also, the netstat output showed that udp 9005 was bound to the dotted quad and not bound to 127.0.0.1.

Anyway, hope this helps others. The only other issue I have now is the nicely built dashboards for sophos are all geared towards the UTM which has different field labels, etc.

[dougburks]

I guess I should have seen this issue sooner, however it doesn't make sense to have the sophos integration bind to localhost only and only receive syslog data from the securityonion node itself since the SO node is not an XG firewall.

Elastic defaults to localhost most likely for security reasons.

I've added the following to https://docs.securityonion.net/en/2.4/elastic-fleet.html#adding-an-integration:
If the integration is designed to listen on a port to receive data, it will most likely default to listening on localhost only. Depending on how you are sending data to the integration, you may need to change that to 0.0.0.0.

[dohabandit]

Doug, thanks for taking the time to respond. Slight revision might make it more understandable to some. *If the integration is designed to listen on a port to receive data, it will most likely default to listening on localhost only. Depending on how you are sending data to the integration, you may need to change that to 0.0.0.0 because a process bound to the loopback address can't receive events from other network hosts.*

…

On Tue, Dec 19, 2023, 9:43 AM Doug Burks ***@***.***> wrote: I guess I should have seen this issue sooner, however it doesn't make sense to have the sophos integration bind to localhost only and only receive syslog data from the securityonion node itself since the SO node is not an XG firewall. Elastic defaults to localhost most likely for security reasons. I've added the following to https://docs.securityonion.net/en/2.4/elastic-fleet.html#adding-an-integration : *If the integration is designed to listen on a port to receive data, it will most likely default to listening on localhost only. Depending on how you are sending data to the integration, you may need to change that to 0.0.0.0.* — Reply to this email directly, view it on GitHub <#12032 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5H3BOA2G3MNOKEIM2UUBLDYKGR2JAVCNFSM6AAAAABAYOK4I2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQOJYGI2TG> . You are receiving this because you authored the thread.Message ID: <Security-Onion-Solutions/securityonion/repo-discussions/12032/comments/7898253 @github.com>

[dougburks]

Updated to:
If the integration is designed to listen on a port to receive data, it will most likely default to listening on localhost only. Depending on how you are sending data to the integration, you may need to change that to 0.0.0.0 so that it can receive data from other hosts.