Bootstrap your Network Security Monitoring with Security Onion

there's a lot of options out there when it comes to security monitoring of systems and networks and the reality is that a whole suite of different capabilities are required to provide good coverage across a variety of threats configuring these from scratch can be a very steep learning curve and especially challenging for small businesses or students who don't have access to a lot of resources or deep technical expertise if only there was some sort of linux distribution that came pre-configured out of the box with a comprehensive package of monitoring tools hey there i'm andy and in this video we'll be looking at how to bootstrap a simple network security monitoring capability with security onion [Music] security onion is a linux distribution that comprises multiple open source projects designed for network and system security monitoring so whilst you can absolutely configure each of these tools individually security onion does all that hard work for you the main components are af packet which is a means of capturing network traffic stenographer to store those packet captures to disk for detailed analysis surrey carter and ids to analyze network traffic against signatures of known threats zeke to record netflows analyze application protocols and extract files strelka to then analyze those files in detail and an elk stack to ingest store and analyze the logs from the above network security systems along with any host-based logs that you might want to throw at it a selection of other host security and incident management tools are also baked into the distro including os query wazoo the hive cortex cyber chef and several more now i'm certainly not going to go into detail on all of those in this video but do get yourself subscribed as i will be dedicating a video going deeper on each of these in the future for now we'll take a look at the setup of a simple security onion instance to monitor this sample network note that the sensor requires at least two network interfaces one to act as the management interface to allow access to the user and administration interfaces and a second to act as the sensor port it's this latter which monitors network traffic for signs of badness and in most real environments you'll have multiple sensor interfaces covering different network segments an important point to note for network traffic capture is the need to see packets flowing across a given segment physical networks are nowadays almost always connected via a switch which if it sees a packet from workstation 1 destined for workstation 3 will only transmit on the physical port for workstation 3 meaning our network sensor is blind if it's connected to a normal switch port for it to see this traffic either a hardware tap must be placed in line to take a copy of all packets flowing over a particular link although a separate tab and sensor port is needed for each monitored link or a span port is configured on the switch to take a copy of all traffic flowing in and out of specific ports this allows for multiple links to be monitored from a single sensor connection and doesn't require the need of a separate hardware tap however it's important to be aware of bandwidth limitations if multiple ports are transferring data at close to their maximum speeds the span interface can quickly become saturated and the switch has no choice but to drop some traffic leaving gaps in the sensor's visibility a third option for a fully virtualized test lab network like the one i'm using is to configure the security settings of the virtual switch to permit interfaces to run in promiscuous mode so that they receive a copy of all traffic as if it were operating in an unswitched network producing a result similar to a span port architecting the positioning of network sensors is no small feat in a larger network let me know in the comments if this is a topic you'd like to see more detail on in the future installation of security onion is a largely automated process after specifying an administrator username and password the base system is installed one reboot later and the configuration process runs this collects a bunch of information about the deployment model networking config patching policy and credentials to access the web user interfaces once all the necessary details have been provided config files are generated and an elaborate web of docker containers created which run the various services which make up the security onion platform one final reboot and we're all up and running we can get a preview of some of the main detection capabilities in action by simulating some malicious activity here a windows workstation has opened efficient link which downloads a malicious word document the user foolishly clicks through the security warnings and triggers the payload which silently establishes a reverse shell back to the attacker let's see what our out-of-the-box security onion sensor detected by logging into the web interface from here we can explore the main capabilities including the alerts section which summarizes the number of alerts which have yet to be acknowledged by an analyst the hunt interface allowing for individual events to be examined in more detail and the pcap interface where packet captures can be retrieved and analyzed a couple of items are listed on the alerts page both of which are generated from this suricata ids service one relates to an office document with embedded vba code the other relates to possible metasploit related communications we can investigate each by clicking on one and then selecting the drill down option this gives more details about each instance of an alert although for us there's just a single instance of each this view exposes the source and destination ip addresses and ports of the connection where the threat was discovered for the first alert the macro-enabled office document came from 10.2.0.143 on port 8080 and for the second alert the possible metasploit command came from the same address although this time on port 1690 but surakarta doesn't provide the whole picture on its own it says the suspicious office dock was transferred via a web client but it doesn't show us the user agent string so we can't know whether it was sourced from a user's browser or some other method such as a powershell invoke web request and there's nothing here indicating the url or file name of the document meaning we'd struggle to search for other instances of this same dock on other machines zeke events can help improve our visibility of what happened so let's pivot off this attacker ip address that means going into the hunt interface and searching for the ip several events are shown the earliest are a couple of zeke events summarizing two tcp connections from the victim user to the attacker on port 8080 including the number of bytes transferred the duration of the connection and the protocol http the first of these was very short-lived but the second transferred more data zeke has generated another entry for that second connection this time at the http protocol layer here we can see details of the request method and uri the browser user agent and details of the response and openxml word processing file another event provides further details of the file including file hashes this is handy to pivot off to see where else a particular file has been spotted or as a means to search for the presence of no and bad hashes provided by a threat intelligence feed the file uid is a useful identifier here we can pivot off of it to see the information which strelka has managed to glean by pulling apart the file into its constituent parts each part is individually hashed allowing for correlation with other occurrences of parts of a file the next event is the suricata event we were examining earlier these events give a good picture of the first stage of the attack where the victim downloaded the malicious file all extracted from a single network communication sniffed off the network it's worth noting that we can review the network traffic which led to these events by selecting an event and choosing the pcap option this retrieves the relevant packets from stenographer's packet archive a simple browser interface is provided and also a button to download the pcap file for examination in a dedicated tool such as wireshark the last couple of events from our attacker-based search occur around 35 seconds after the malicious file download and consist of a zeke event showing a connection from the victim to the attacker this time on port 1690 and last in 73 seconds and an associated suricata alert that the connection matches a meta sprite signature this was the reverse shell connection established by the vba payload on our brief tour of the main alerts hunt and peak app sections of the web interface we've seen the value of multiple different security tools working together to provide a far more comprehensive detection alerting and investigation capability than any one tool can on its own although we've really only just scratched the surface here more advanced threat hunting and dashboarding can be performed by the kibana interface and our ability to detect and investigate events can be improved by adding further data feeds such as host-based logs we'll be exploring this further in future videos along with a bunch of other great defensive tools and techniques so do make sure you get subscribed and if you found this video useful please do click that like button but that's all for now let me know in the comments if you think there's anything i've missed in this introduction to security onion or if there's any particular topic you think i should cover next i'll see you next time [Music] you

Channel: Attack Detect Defend

Views: 11,256

Keywords:

Id: ubQxWUCtzpw

Length: 10min 54sec (654 seconds)

Published: Tue Jul 13 2021