-
Version2.4.160 Installation MethodSecurity Onion ISO image Descriptionconfiguration Installation TypeDistributed Locationon-prem with Internet access Hardware SpecsExceeds minimum requirements CPUvaries for each grid member RAMvaries for each grid member Storage for /varies for each grid member Storage for /nsmvaries for each grid member Network Traffic Collectiontap Network Traffic Speeds1Gbps to 10Gbps StatusYes, all services on all nodes are running OK Salt StatusNo, there are no failures LogsNo, there are no additional clues DetailWe currently have a distributed Security Onion (SO) grid which monitors network traffic and a separate Elasticsearch cluster that receives all our host/device log data. We are considering merging the two to allow analysis workflows to have a single pane of glass. In our Elasticsearch cluster, we have three Elasticsearch nodes. On the three Elasticsearch nodes, in addition to the main interface which the Elastic agents send their logs to, they each have an additional interface in what Elasticsearch calls a transport network that is meant only for inter-node communication. In our SO grid we have only one search node which only has a single interface. When merging, I assume I would need to add two additional search nodes to match the required resources used in the Elasticsearch cluster. When I do this, how is the transport network handled in the SO architecture or is it not used? Our idea is to apply our Elasticsearch enterprise license to the SO grid once merged. If anyone has already gone through this process, would you be able to share any lessons learned or gotchas that we should look at? TIA Guidelines
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
Are asking about Cross Cluster Replication or Cross Cluster Searching? |
Beta Was this translation helpful? Give feedback.
-
|
TBH, I don't know. I just know that our 3 Elasticsearch nodes have an interface that Elastic refers to as a transport interface and it's meant only for inter-node communication (i.e. not for Kibana/Elastic agent/Fleet > Elasticsearch communication). For us, this interface is in a vlan that only contains the other Elasticsearch nodes' transport interfaces. My current Security Onion (SO) grid (completely separate from our Elastic cluster) has one search node and that search node only has one interface. My question is, does the SO architecture use this transport network? If not, cool but it seems like a fundamental part of Elastic so I have questions. If so, when additional search nodes are added to a SO grid does an additional interface need to be added or is inter-node communication handled using the one interface? Hopefully that makes things a little clearer. |
Beta Was this translation helpful? Give feedback.
-
|
I think I may have answered my own question. It looks like our Elasticsearch nodes are listening on port 9300 on the IP of the transport network interface for inter-node communication. The SO search node is listening on port 9300 on 0.0.0.0 and since it has only one interface that would mean inter-node communication isn't handled on a different network. It uses the same network as everything else. I'm assuming it could be setup as a separate network but would take some customizing and I don't know if this could negatively impact the SO grid in some way. |
Beta Was this translation helpful? Give feedback.
-
|
It would, you would need the TLS setttings in place for the communication to happen and depending on whether you are doing CCR or CCS additional configurations would be needed. |
Beta Was this translation helpful? Give feedback.
It would, you would need the TLS setttings in place for the communication to happen and depending on whether you are doing CCR or CCS additional configurations would be needed.