Advice for Forwarding Logs to Security Onion

[MACKG17]

Version

2.4.90

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Distributed

Location

airgap

Hardware Specs

Meets minimum requirements

CPU

8

RAM

500

Storage for /

1TB

Storage for /nsm

1TB

Network Traffic Collection

span port

Network Traffic Speeds

1Gbps to 10Gbps

Status

No, one or more services are failed (please provide detail below)

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

1. I have agents installed on my servers so getting logs from those but for my network devices, the Syslogs from these devices, I wanted to know if I should forward those to a Syslog Server first -AND- then have those logs pushed to Security Onion, or is it better to just forward to my Security Onion Manager Node?

2. In either case, is there some special considerations on configurations I should be aware of to configure in the SOC web interface?

3. A colleague of mine had recommended to configure different log ports for each device to differentiate between which logs are coming from what but, do you think this matters?

My Sensor Nodes are getting traffic from SPAN ports.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[reyesj2]

Depending on how many devices will be sending syslog data an option might be setting up a receiver node to specifically handle ingesting the syslog data. https://docs.securityonion.net/en/2.4/architecture.html#receiver-node

For ingesting syslog you will need to open the firewall for the node intended to receive the syslog data (receiver node if you set one up as mentioned above) https://docs.securityonion.net/en/2.4/syslog.html

For differentiating log sources data sent from syslog should include a hostname field showing device that is sending the logs.

[MACKG17]

Thanks reyesj2, I think I will just send the Syslogs to my Manager Node. My environment is not that robust to stand up a Receiver Node. Is there any special parsing considerations for Cisco firewall syslogs that you know of or is Elasticsearch in Security Onion pretty good in parsing Cisco stuff?

[reyesj2]

You might look into an elastic agent integration for the parsing. There are a few options for cisco products https://docs.securityonion.net/en/2.4/third-party-integrations.html#third-party-integrations

[MACKG17]

Does it work like this: 1) Cisco sends logs (and NetFlow if configured) to SO Manager Node, 2) Cisco Integrations is configured on Elastic Agent on the Manager Node to help parse to Cisco format ingestion into Elasticsearch? Obviously the agents are not installed on the network devices right, I assume the log data from these devices are sent to SO and it can customize it??? Sorry, I hope this makes sense.

[MACKG17]

I saw a Youtube video on Elastic Agent and they guy on their stated that one way to have Cisco logs sent to Elastic Stack is to have Cisco device send logs to an "Ingestion Server" with Elastic Agent installed. For Security Onion, I would see this as the SO Manager Node (I'm in a Distributed environment), as my "Ingestion Server," which has by default Elastic Agent installed. According to the video, all you have to do is add Cisco as an "Integration" to parse Cisco logs that come in.
https://www.youtube.com/watch?v=CkN584aH4mc. Look at this video and look at Method 3 (21:35).

Does this logic sound right to you reyesj2?? If so, in the part of the video where he changes TCP to UDP, changes the Listening Address to the Ingestion Server and changes the port to 9005. Let's say I have a Cisco device and it's forwarding Syslogs on a UDP port 514. To match what the guys says in the video, would the Listening Address be the IP address of my Manager Node and change the listening port to UDP 514?

What are your thoughts, if this makes sense to you?

[reyesj2]

The first flow you stated is correct. You add the cisco integration to for example your managers "fleet_server" policy. Then you configure your cisco device to send logs to your managers ip and to the port specified in the configuration of the cisco integration. I would recommend you change your cisco device to send logs to the manager on a different port than 514.

If you send logs to port 514 there is already a syslog integration that will be listening for those logs, but won't correctly parse them like the cisco specific integration will.

[MACKG17]

Go it! So send the Cisco Syslogs to the Manager Node but with a different port configured in the Cisco Integrations – is there this right? If so, that is GREAT, I fully understand that will bring me full circle with having a completely configured Distributed environment. Thanks guys! Y’all rock for this Tool. It makes my life so easier now using SO. From: Jorge Reyes ***@***.***> Sent: Thursday, September 19, 2024 12:24 PM To: Security-Onion-Solutions/securityonion ***@***.***> Cc: Ismail Mccowin ***@***.***>; Author ***@***.***> Subject: Re: [Security-Onion-Solutions/securityonion] Advice for Forwarding Logs to Security Onion (Discussion #13643) EXTERNAL EMAIL The first flow you stated is correct. You add the cisco integration to for example your managers "fleet_server" policy. Then you configure your cisco device to send logs to your managers ip and to the port specified in the configuration of the cisco integration. I would recommend you change your cisco device to send logs to the manager on a different port than 514. If you send logs to port 514 there is already a syslog integration that will be listening for those logs, but won't correctly parse them like the cisco specific integration will. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/Security-Onion-Solutions/securityonion/discussions/13643*discussioncomment-10695530__;Iw!!HUqgN_M!uNCX8I3QTfwrsuOwh41pP8G23dKpCauDXqB08H5W1MITZmNJryrIITzDsTG3eU0osRWd-HlF3HoKYc8VuVuN0bgXDx0$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/BJKYMZA6ZA2OTYM3F4AMFTDZXL3BDAVCNFSM6AAAAABN6VYZX2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRZGU2TGMA__;!!HUqgN_M!uNCX8I3QTfwrsuOwh41pP8G23dKpCauDXqB08H5W1MITZmNJryrIITzDsTG3eU0osRWd-HlF3HoKYc8VuVuNg7bbmWo$>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

…

---------------------------------------------------------------------- The contents of this email are intended only for the recipient(s) listed above. If you are not the intended recipient, you are directed not to read, disclose, distribute, or otherwise use this transmission. If you have received this email in error, please notify the sender immediately and delete the transmission. Delivery of this message is not intended to waive any applicable privileges.