In this lesson,
I'm going to go into my lab environment
and show you how to configure a security information
and event management system.
Now we're going to make sure
that we get the agents on the systems in our network
configured so they can report back to that SIEM
so we can use that for later analysis.
Now in this lesson I'm going to use Security Onion,
which is an appliance that comes as a VM
and it implements things like Elastic Stack, Kibana,
and other SIEM functionalities within it.
Now the first thing we're going to do
is we're going to go and configure our sensor.
Now I've already done this for us,
but if you look on the right side of this diagram,
you're going to see the Unified Threat Management System
up at the top.
On that, we have a connection going to vLOCAL,
and vLOCAL has a sensor feeding data into my SIEM.
Now in addition to that,
I'm also going to be collecting information
from the Windows virtual machines down in the bottom,
MS1 and DC1.
Both of those have data that's being fed up into vLOCAL,
and using that sensor port,
I'm going to collect that information and send it to my SIEM.
All right, so the next thing I want to do
is go into my SIEM and we're going to open a terminal.
And from within here,
we're going to start dumping that information from the network
that we're capturing over that sensor wire.
So I'm going to type in sudo tspdump -ni eth1 ip,
and hit Enter.
Using the -n switch is going to tell us
that we don't want to use name resolution
because I'm not connected to the internet,
so I can't look up things like google.com.
I have to use IP addresses.
And by using the ip at the end,
this is going to filter out any IPv6 traffic.
So I'm just going to be focused on IPv4 traffic.
This will make sure that I see things
for traffic going to and from my host
in those two Windows machines
and to that unified threat management system.
All right, once I'm done capturing this,
I'm going to hit Ctrl + Z
and that will stop this traffic capture.
Now this traffic is going to be monitored by bro.
Bro is a passive network sensor
that we're going to use
basically as an intrusion detection system.
It's part of that unified threat manager.
Now those events have already been configured,
so it's going to write into the SIEM.
The SIEM is going to allow me to see what's in there
and we're going to use Elastic Stack to do that.
So if I go ahead and see if Elastic Stack
is running properly,
I can do this by typing in sudo so-status, and hit Enter.
This will give me the output
that shows that each service is up and okay.
If I get some kind of a warning message,
that means one of the things that I'm using to collect this,
things like Logstash,
which is part of Elastic Stack,
might not be quite ready yet.
So I would have to wait and then run that status again.
All right, from my desktop,
I'm going to go ahead and open up Kibana.
Inside of Kibana,
I'm going to log in with my username and password,
and this is going to bring me to a dashboard.
Kibana is a virtualization tool
and it's part of Elastics Stack.
It's going to be used to configure the dashboards
for different categories, showing us different information
in a graph format or a table format.
Now if I go down under Bro Hunting,
I can select Connections.
And from here, I can scroll down to verify that the host
from the 10.1.0.0/24 network
are present and accounted for.
This will make sure that I'm seeing the information
being sent to me by my intrusion detection system.
All right, now that we see that Kibana
is properly configured, I want to start doing some scans
and make sure that Kibana
is seeing this inside of there with live data.
So I'm going to go into Zenmap,
which is on my Windows machine,
and I'm going to run a scan
using a default intent scan against 10.1.0.1.
Now, Zenmap is essentially just a graphical version of Nmap,
which is a network scanner.
So it's going to go through and perform the scan for me,
and now I'm going to go back into Kibana.
If I go there under Alert Data,
I can then view the Bro Notices
and NIDS categorization for scanning activity alerts.
Now if there are no results,
you want to click on the Update button.
Now as we do this, we should be detecting that scan
that the Windows machine is doing against this network
and Kibana as the SIEM is seeing all that data
because we have that port mirroring enabled
off of that switch.
Now as you can see here, the NIDS alerts are being counted
and we can see those scans
because we have this scan being run by our Zenmap.
So this is telling me this process is working
and we're able to see it in real time.
Now the next thing we want to look at
is how to install a Beats agent
so we can capture network traffic directly from the host
instead of just capturing things off of the network switch
using port mirroring
like we are doing up to this point.
To do this, we want to capture that log information.
So we're going to install the Beats agent.
So let me go ahead and log into my DC1.
And from here, I want to configure Beats,
and I do that by going under my LABFILES
and then winlogbeat.
In here, you'll see winlogbeat.yml,
which is the configuration file,
and I'm going to right click it
and edit it with Notepad++.
Now as I edit this file,
you have to remember that YAML files
are very sensitive to white space.
So every space is actually used and counted.
So you can't just add spaces willy-nilly.
You got to make sure you count correctly.
These files use two spaces per indentation level.
So if you want to use two,
that would be the first column.
Two more, that gets you four spaces,
that's the second column
and it keeps going like that.
All right, so we're going to scroll down
and locate where it says output.logstash:.
Now in this section I'm going to find line 111,
which is the #hosts:,
and I want to change where it says localhost
to my IP address of my SIEM.
So I can send the data from this machine over to the SIEM,
and that SIEM is at 10.1.0.246.
So my line should now read host: "10.1.0.246:5044",
and that 5044 is the port
that my SIEM is configured to listen on.
Now this will allow me to get data from this,
any of the log files and send it back to that SIEM,
which gives me another way to collect data.
So I'm going to save this and close the file,
and then I'm going to copy the winlogbeat folder
to the C:\Program Files x86 directory.
Now I'm going to go into PowerShell
and run a command to be able to start this up.
So I'm going to change directories
into the 'C:\Program Files x86 \winlogbeat' directory
that I just started.
Then I'm going to run winlogbeat.
And to do this, I'm going to use the Linux style notation.
So .\winlogbeat test config -c winlogbeat.yml -e.
And what this says is I'm going to run winlogbeat,
I'm going to use it in a test and configuration mode,
and the configuration file is going to be winlogbeat.yml,
and then I'm going to execute this.
So this last part is going to say Configure OK.
Now if there is an error,
that means I messed up the configuration file,
but if not, I'm ready to keep going.
Now at this point, I'm going to run two more commands
because I need to install that agent
as a service inside Windows
so it starts up every time I reboot this computer.
To do this, I'm going to do .\install-service-winlogbeat,
and then I'm going to start the service
by doing start-service winlogbeat.
All right, now that I have that running,
I have started this up,
I have configured it as a service,
and anytime I restart this computer,
Beat is going to be running for me.
So let me go back into my SIEM now
and I want to run the command sudo so-allow-view.
Now this is going to show me the output that has the firewall
that's already been configured to allow the traffic
from beats over port 5044 into my SIEM.
Now if I go back into Kibana,
I should again see those NIDS dashboards
and those Bro notices for those scan alerts
that I saw before from those scanning alerts
that I cause by using Zenmap.
Now if I go into the Beats dashboard under Host Hunting,
I can start seeing events from DC1
where I just started that Beats agent to send data back.
Now it may take some time for that to come in,
and if yours aren't there yet,
you can click on Update or Refresh
and keep checking for those alerts.
Over time, they're going to start coming in
and you'll see those different logs from that system.
Now the next thing I'm going to do
is configure some application logging.
Now by default, Beats is going to capture
the application system and security logs
when you set it up on a Windows Server.
Now this is going to collect a lot of data
and send a lot of it back to our SIEM,
and some of it may or may not be relevant
for what you want to do.
If you're doing incident detection or threat hunting,
a lot of this just isn't something you need.
If you're doing system troubleshooting,
it's stuff you may need.
So you need to figure that out inside your organization
and determine what you want to log and how much.
So let's say we want to configure our application log.
So we're starting to send data to the SIEM.
Well, let's go over to MS1,
which was my IIS server machine.
And I want to go in there
and look at the access logs
from the event viewer
and then have Beats forward that to the SIEM.
That way I can get data about my web server.
So let me go ahead and go into MS1.
And from here, I'm going to go under Server Manager,
select Tools, and then Internet Information Services
or IIS manager.
Inside the IIS manager,
I'm going to select the server MS1,
and I'm going to double click
on the Logging app in the middle pane.
This will show me the different options I have
for log formats.
Now if you remember from our log formatting lesson,
you're going to see
that there's lots of different formats you can use,
but I'm going to use the standard of W3C,
which is really good for web application logs.
Now under the Log Event Destination,
I can select Both the log file and an ETW event,
and click Apply.
This means I'm going to log it locally to the computer
and I'm going to send it as this type of event
over through Beats.
Now if I go to Explorer,
I can copy the winlogbeat
from my domain controller that I installed it on before
to the local system here with MS1, my web server.
I'm then going to go into PowerShell as an administrator
and I need to run this big long scary command.
Now again, this is something
you don't have to memorize for the exam,
but it is what we need to run
to be able to check the name of the event log
that's capturing those IIS events.
So I'm going to do get-winevent -listlog
* | where-object { $_.logname -like "*IIS*"}
| format-list -property logname.
Whew, that was a long one.
So what is this saying?
Well, I want to get all of the Windows events
that meet these conditions.
If it's listing the logs that have a *, meaning anything,
I want to grab those
or I want to grab things where there's an object
where the log name has something like IIS in it,
or I want to get anything that's formatted as a list
with the property of logname.
So if I take all those things,
I can gather those events
and then I can figure out what I want.
This query is going to match a couple of logs.
In fact, three of them.
And then I want to copy the text,
Microsoft-IIS-Logging/Logs.
And copy the value from the prompt,
select it and press Enter.
Now I'm going to open up the Program Files directory
under winlogbeat that I just installed
and find that configuration file.
I want to go ahead into that file.
And under the winlogbeat.event_logs:,
I want to add the text
that says - name: Microsoft-IIS-Logging/Logs.
All right, now that I have this file
configured the way I want,
I'm going to close it and say yes to save it,
and then I'm going to go back into my administrator mode
and go into my PowerShell prompt.
I now want to run the command
to get into the directory for winlogbeat,
which is cd 'c:\Program Files \winlogbeat'.
And then I want to run the configuration file
and load it up.
So just like I did on the domain controller,
.\winlogbeat test config -c winlogbeat.yml -e.
Now if I got that last part right,
I'm going to see output that says Config OK.
This means I'm ready to move on.
Now I need to start it up as a service
just like I did on the domain controller,
.\install-service-winlogbeat, hit Enter,
and then start-service winlogbeat, and hit Enter.
Now we have winlogbeat or Beats
running on both the domain controller and the web server.
Now I want to be able to start generating some traffic here.
So I'm going to go over to my PC1 and my PC2,
and I'm going to do some things
like going and accessing share drives
or browsing to different websites
or using Zenmap to start scanning some things.
And when I do this, this is going to generate some traffic
for this lab environment
and it should generate both network traffic
that's captured by the SIEM based on that port mirroring,
and it's going to capture application logs
and event logs from the domain controller
and from the web server.
All right, the next thing I want to do
is install a host base intrusion detection system.
And I'm going to do this by using an agent
on one of these clients.
So with the Windows clients,
we are going to install OSSEC,
which is a HIDS agent.
Now this is going to produce
only security relevant information for us,
and again, we want to configure that
to send that data back to our SIEM.
So I'm going to go into PC1
and I'm going to go ahead and run this program called Wazuh,
which is W-A-Z-U-H.
To run it, I'm going to go into my LABFILES directory
\wazuh-agent-, the version number, .msi.
This will start my installer.
I'm going to go through this installer pretty basically,
and I'm going to accept and install it.
And when the setup is completed,
I'm going to click Run Agent configuration interface,
and then click Finish.
If I get a UAC prompt,
I'm going to go ahead and approve it and say Yes.
Now the next thing I want to do is open a Command Prompt
as the administrator and run "C:\Program Files x86
\ossec-agent\agent-auth.exe" -m 10.1.0.246.
Remember that's the IP address of my server.
So where am I sending these things?
I'm going to send 'em back to that same server.
All right, now that we've done that,
we've associated this agent with the manager
that's running on the SIEM.
That's what that -m is for.
Now this will make sure there's a connection
between the two so I can send the data there.
Now if I switch back to the Wazuh Agent Manager dialogue,
I can click the Refresh button
and I should see a key
that's loaded in the Authentication key box.
If I go to the Manager IP box,
I can type in my manager's IP address
that of the SIEM, 10.1.0.246.
Once I do that, I'm going to save it
and then select Manage, Start, and OK.
Now if I wanted to do this on the other PC of my network,
I would do the exact same thing
and configure all of them the same way,
and that way all of my devices
can go back and reach to that SIEM.
All right, now that we've done that,
let's go back into our SIEM
and start looking at some data.
We want to start extracting data
and aggregating these records to make use of our SIEM
and understand what's in there.
So inside my SIEM, I'm going to go under the OSSEC dashboard
under Host Hunting.
Here, I'm going to use the update or refresh
to check for any new alerts.
Now once I do that,
I'm going to click the Management tab
and select Index Patterns and then Create Index Pattern.
Now in the index pattern box,
I want to type logstash-ossec-*
and then click Next step.
This is the pattern I'm identifying.
Then from the time filter,
I can select I don't want to use a time filter
'cause I want everything to show up,
or I might just want to look at today's stuff
or the last three hour stuff
or a certain time period
based on what we saw from some kind of a malicious event.
Now once I've done that,
I can click the Create index pattern button
and this creates my pattern.
From here, I can click the Discovery tab.
Now from the list box,
I want to select logstash-ossec-*,
which is the index pattern that I just created.
Now under my search box,
I want to create a filter string
and then I'm going to update it.
So I'm going to do this by typing in agent.name:PC*
AND alert_level:>=5.
What this says is, anytime you found an agent
that was PC something in my network, PC1 or PC2,
and the alert_level:>=5, I want you to display it.
Now as I look at these results,
I can see some results here
and I can click the small black arrow to expand the record
and view all of the different event data around it.
And so you can see pretty quickly here
how we can start slicing and dicing data
and searching for things on a particular machine,
such as PC1 or PC2,
or if you wanted to look at all machines
by using wild card characters
and then identifying
what looks malicious across your network.
The great thing about a SIEM
is I'm not looking at everything as individual pieces.
All that data is in one place,
so I can see it across the entire network
and start looking for patterns.
Next let's configure a syslog source.
Now this is important
because a lot of hosts you're going to deal with
may not have the ability to install an agent,
but most things can be configured
for remote syslog monitoring.
So to do this,
I'm going to go ahead and do that
on my pfSense Security Appliance,
which is my unified threat management system.
So when I go into that unified threat management system,
I can click on Status and System Logs
and then click on the Settings tab.
Here if I scroll down,
I'll find the option for remote logging.
When I click that, I can enable remote logging,
then I can type in my server name, 10.1.0.246,
and I'm going to put that on port 514
because that is the port for syslog.
Now from the remote syslog contents,
I can check the system events and the firewall events
because those are the ones I want,
and then I'll click Save.
Now if I go back into my SIEM and I go back into Kibana,
I can click on the Management tab
and then select Index Patterns,
and then we can create a new index pattern.
So in this index pattern,
I'm going to call it logstash-syslog-*,
and click Next step.
For the time filter,
again, I don't want to use the time filter
and then click Create index pattern.
If I go to the Discovery tab,
here I can find logstash-syslog-*.
Now if I search for something,
for instance, syslog-sourceip:10.1.0.254
and then hit Update,
I can find all of the syslog things
that are associated with that IP address.
So at this point, we have looked at some different options
for taking information into our SIEM.
We can do it based on traffic sources by a network tap,
we can use agents like Beats,
and we can use syslog for our more generic systems
that don't have Beats installed.
Now once we've done all that,
we might have a lot of log data coming in,
so it'll be important for us to define our use cases
and tune our sensors and tune our logging
to exactly what we're looking for.
But this lab should have given you a great introduction
to Security Onion
and how to set up these different things on your network.
Again, like all the tools we've talked about in this course,
I do recommend downloading this
onto a virtual machine in your network, set up an appliance,
and then start capturing your own network traffic
and see what patterns you can identify.
Learn how to read these logs
and learn how to use these tools.
It'll make you a much better cybersecurity analyst
and it'll help you pass your job interviews,
because employers are going to want to know
that you know how to use a SIEM and how to read it.