All right. Now that we've covered the monitoring and analysis tools, let's take a look at how they interact with each other and with a discussion on the architecture. For that, we will jump over to the Security Onion documentation site as their graphics are much nicer than anything that I could put together. So this is the girl that will get you to their documentation site. I haven't already pulled up, so we won't have to worry about anything loading. So says security. Onion don't read the docks dot io etcetera. So this is a very high level architecture diagram of security onion starting at the top. Here we have our analyst machine interacting with various things on the Internet and various processes. We have python team slack things like that and interacting with the security onion interface Here were directly hitting Cabana. Just the query and visualization engine tens.
Cabana is sitting on top of the elastic search which ingests and indexes are logs. And based on this data, we can have several scripts running how it can have domain stats which give statistics on domain. So the D. N s traffic. We have frequency server, which is looking for anomalous uh, de ns queries so big, randomly generated domains, things like that. Then we have a last alert which can alert based on any of these are alert to any of these Service is up here that we have curator which is helping us to manage our indices and then log Stashes where our data is parsed and logged. But it's in the name log stash, and then everything that is sending data in tow log Stashes down here. So we have snort, sir Kata o s sec, bro and Sis Log. And then underneath os sac. We have sis mon and auto runs, so just at a very high level.
This is how everything in security on you it works. If you have a distributed architecture, this is more or less how it works. Um, Cabana will be sitting up at the top and it'll query anything at the manager or it'll go down to, ah, storage note and query, and on ah analyst machine or, ah, standalone server. Everything will be going on in the same server. So little works out there to come down here. We have ah, much more detailed diagram. I already have a pulled up here just to look through really quick. You have our analyst machine here, like we did on the high level architecture diagram. And on here it is a bit more granular. Exactly what we're hitting. So squeal is hitting. The Squeal Service browser is hitting the web proxy on the management server, which is hitting squirt to cap me. Uh, we follow this over, it should take us to Cabana, and then we have course have RS S H clients where we can ss agents. The manager and I do admit administrative tasks to, um, choir the data directly.
Things like that. So if we want to look at our child's node that is actually sniffing the traffic, this would be in an enterprise deployment. We have sniffing traffic right here. It's coming down hitting PF ring, which is splitting the traffic between snorts terra cotta and bro. And then we half the traffic oingo were 10 net sniff n G, which is from doing a full packet capture and storing all the logs as P caps actually think they're as snort then the snort format. They should be think we have all of our alerts being written. Two disc ear. Then we have our transport layer here. Soapy cap agent Barnyard says Log envy. If we are using a forward, knowed everything will be sent through sis log N G to log stash on the manager. If we are using a heavy note architecture, then it'll send it to lug stash on the sensor. Note itself on the heavy note itself, so we'll talk a bit about this later on. But the heavy note has all service is running, while ah Ford Note does not have the elasticsearch components running. It forwards the Excuse me, it forwards the ah, like the bro logs, the snort logs things like that to the manager, where it stores it in the local log stash. And then from there it can be stored either on the manager or on a storage node.
So after the data is stored on here, it can be sent over to squeal, so the idea slugs will be sent over to squeal, and it's stored on the security onion database. Any of the scripts that we discussed earlier would be running here in our doctor containers. So this review that we're giving right now isn't meant to be comprehensive by any means. I I'd recommend coming in here taking a look through the flow diagrams and really gained familiarity. What? What exactly what exactly is going on in your network on your build? If you're ever trying to figure out what has broken our how things fit together, then knowing how everything is put together in the first place is pretty important. So I That's one thing that I very much appreciated about the security onion projects, the people that security onion solutions is they have very good documentation for this project. Um, I I I found things in here that I didn't even know I needed to worry about, so I'd recommend coming in here and reading through this and see what you can learn.