So today, I really wanted to focus on kind of an introductory level explanation of, you know,
some of the stuff that we see in the cloud and, you know, of course, how a lot of things are moving
to the cloud these days, just security onion in general, and how we might be able to leverage
security in the cloud to monitor our cloud infrastructure. And then also, maybe a couple
ways that, you know, through a stance of academia or standing up a POC proof of concept or whatnot,
how we can automate that and automate our testing and maybe automate the deployment
of security in the cloud. So most of this will be focused on AWS, since it is one of the largest
cloud providers. Although we will have some resources to share for other cloud providers,
and we'll be going through some of that stuff there. So without further ado, I will go ahead
and get started. A little bit about me. I have four kids, married, of course, and definitely love
every minute of it. I, as I mentioned, work for Security Onion Solutions, where we develop and
maintain Security Onion. And we also provide professional services and training for Security
Onion. And it's really all about that open source platform and getting folks better visibility into
their network. So let me go ahead and get started. Talking about the agenda today, we're going to go
through the cloud in general, some of the stuff that we find all over the place in different
clouds, whether it be AWS, Azure, GCP, Google Cloud Platform. And then also, again, introducing
Security Onion, what it is, how it can help us, and then introducing, again, Security Onion in the cloud,
and then automating that deployment. So when we talk about the cloud, and we talk about all the
assets and all the data that we really house there, and that potentials or other folks could
potentially access, some of those are as follows. For AWS, it's going to be things like S3 buckets,
which we might have seen in the news recently. A lot of leaky buckets, a lot of unsecured S3
buckets having public read or maybe even write access to them. So there's definitely some
attack surface there with that kind of stuff, as well as DynamoDB and some other production data
storage in AWS. Again, with Azure, it's blob storage, or maybe even event hubs, where our data might be
stored, or logs, or whatnot. So that's another thing to keep a look for in Azure. And then in Google
Cloud Platform, obviously, like S3, we have storage buckets, cloud data stores and file stores that we
want to keep an eye on, and lots of juicy stuff for attackers that they may be trying to find this
stuff, publicly accessible from the internet, or they're able to get past, slip past our initial
defenses and easily get to the stuff, or maybe even not easily get this stuff, we definitely want to
know. And then of course, we have the application or the network traffic itself, right? So we have
all this this traffic and this data flowing across from these different instances, from these
different segments in the cloud. And we definitely would love to know what's going on. And it
definitely can help others to know what's going on, such as an attacker. So we just want to be mindful
of these things whenever we're doing business in the cloud, running all these critical operations
and whatnot, just being aware of that. Now, an example of that stuff being abused in the case of
AWS, there are various tools that, you know, attackers or just security researchers use in
general to try to find these items. It might be S3 scanner to scan for open S3 buckets, or maybe AWS
bucket dump to try to get the stuff where we could enumerate buckets, look for interesting, juicy
tidbits of data. So there are lots, there are no shortage. And, you know, every day, again, there
are more leaks and more tools being released to try to find this type of stuff. So it's becoming
easier and easier for the attacker to get in and get this data if we're not careful about our
environments. Similarly with Azure, there's microburst, right? So we could look for different
services in Azure that might be enabled, weak configuration, or maybe even try to identify
post-exploitation actions, right? So, again, these tools, there's no shortage. Definitely have to
keep an eye on this stuff. And then, again, with GCP. So GCP, there's a mechanism, GCP bucket
brute, similar to the others, where we can enumerate Google Cloud storage buckets. We can
determine access levels, privileges, see if we can get privask, privilege escalation there.
Lots of ways that we can do that there. And then also the cloud credentials. It's really
going to be another thing where it's not even the data itself, but something that brokers access to
the data, right? If account passwords, IM, or root account credentials are able to be phished
from people, of course, that's no good. And, again, it's the weakest link, which is,
you know, very commonly the human in this case. And, you know, with these access keys or these
credentials, that means that attackers could control access to AWS servers without a username
and password, right? So access keys, if they have those, they can just go straight in.
And then, again, those are obtained usually by a phish or some similar method, right?
And then, again, with the privilege escalation with regard to cloud credentials,
folks can create new policy versions, right? They can create new keys off of those keys. So even if
you delete the old keys that were compromised, if you're not deleting new keys that were created by
them, or you're not monitoring that, it's very difficult to get, you know, those attackers out
of your network, or it just poses yet another concern and another question, right? Even adding
malicious Lambda layers to existing Lambda functions, it's one thing that attackers can do,
and Rhino Security Labs actually demonstrated it's pretty cool, actually, basically modifying
existing Lambda functions to act as you would not expect, and it's a great way to hide stuff like
that without being super obvious. So we've talked about that stuff, and I've gone through that
rather quickly, but I think as far as a cloud village, I think some of us are aware of these
threats, of course. So now I want to talk a little bit about monitoring challenges, right? So monitoring
in the cloud. Now with NSM, or network security monitoring, which is really a core component of
security engine, where we're monitoring that network data, we're monitoring that traffic that goes from
endpoint to endpoint, there can be some challenges in the cloud, and there are ways to get around
them, but to talk about a couple, VXLAN encapsulation. So even if we are able to capture the traffic
in the cloud, typically if we don't have the right applications, if we can't decapsulate that,
or understand what it means, or alert on it, then it's not as much value to us. So it makes it more
difficult, you know, to interpret that data, or to use that data in analytics, or reporting,
or alerting, and that can be difficult. That can be a challenge. Another one would be segmentation.
Maybe you have certain segmentation in your clouds where you're not able to easily tie together a
monitoring solution. I'm not saying security engine is it, and they'll be all for that, or
anything else, but that's just a general challenge overall that sometimes it's just difficult to
overcome. Then again, ephemerality. So we talk about instances spinning up and down a lot of times in
cloud environments. You may have a variable number of instances. They may be there one minute, they
may be gone another minute, and one of the challenges with monitoring that is how do you
tell something, right, to monitor this host, or to monitor the activity of this host when it spins up,
and then it just goes away? How do we tell, you know, to monitor the next host and the next host?
How can we group these together and create an effective solution? And in some cases, there really
is no native or no great mechanism for monitoring in the cloud, and it just, again, makes it even
more difficult. But there are ways around it. Sometimes they don't scale that well. Well, a lot
of times they don't scale that well. So it's always best if there is a native solution. And again,
there are commercial solutions available for monitoring. A lot of times these are highly
specialized, highly integrated with specific feature sets and specific products, so they can
be very expensive. And a lot of folks may not be able to afford something like that, especially
small to medium-sized businesses that are trying to run their workloads in the cloud. So
enter the onion. Just making sure that wasn't from you guys. Enter the onion, right? Security
onion. We're going to talk a little bit about here. So what is security in general? A little
introduction. It was created by Doug Burks in 2008. Doug was really scratching the need or the
itch to create an all-in-one solution, a click, click, or a click, click, finish solution as far
as rolling your own IDS and doing all this alerting and this analyst activity. Back during
2007, 2008, there really weren't a lot of great solutions tied together to enable somebody to
have this effective monitoring platform and not have to know all these ins and outs, not having
to compile ZEKE, not having to compile Cercata, PFRing, NetSniffNG and all this stuff. You had to
know a lot of stuff, a lot of that core technology to be able to even get in the game. And it takes
a lot of time to spin up. So a lot of the reasoning behind this is that we want this platform that's
easy to install, easy to set up, and we're getting folks monitoring in minutes. And it's free. It's
open source. Again, those small businesses, those medium-sized businesses can easily adopt this and
be able to tip the scale in favor of the blue team maybe, just a little bit more to that side
and be able to identify what's going on in the network. So security in itself can be installed
from an ISO image. We provide one on our site. And then also it can be installed from packages
on top of Ubuntu 16.04. And again, all this takes a very little amount of time. Obviously,
the ISO image is going to be faster, but you can install it on your Ubuntu flavor of choice.
So like many IDSs and network security monitoring platforms, Security Engine is traditionally fed
data from a TAP or a SPAN port. We have had folks use ERSPAN, GRE tunnels, that sort of thing.
It's not recommended, and it's not really supported, but there are other methods of
getting that traffic to it. And now we do integrate with the Elastic Stack for the
data enrichment, indexing, and visualization components. So it gives you all that rich,
being able to create data tables and be able to create visualizations and really get an
idea of what's going on in your network. It makes it really, really easy.
And here's just a quick screenshot. It's not the most exciting screenshot, but it does give you an
overview into the overview dashboard itself in Security Engine. And this is inside of Kibana.
So we can see the overall number of logs here and some different log types that we've recorded.
Some sensors that we've got connected right now, in this case just one. And then the number of
devices connected, which would be the management node and the sensor itself. Let me just click here.
And again, just some more, you know, just kind of scrolling down that overview dashboard. And
I'm going to go through this more in just a little bit, but we can see some other data types.
And again, just grouping on those sensors and those protocols. And then you also see some NIDS
alerts down here. So talking about some of that data that we get, a lot of folks traditionally,
when they've been exposed to an IDS or a network-based intrusion detection system,
they're going to be aware of this type of alert data that we see here on the screen.
So this right here is an alert, right?
Let me see if I can do it without clicking. Oh, let me go back. Sorry about that. So the
panmunix right here, this is just a Wazoo alert for the user W. Lambert that occurred locally
on a system. So Wazoo is a host-based intrusion detection system that we include in Security
Engine that can generate that alert data. And not even just alerts, but other types of activity
generated on the host itself. And then we have down below alert data, similar to what you would
find from Suricata, going to be generated down here. So we've got both of those types of alert
data there, the host and the network-based intrusion detection system alerts. And it gives
us the ability to kind of correlate back and forth and tie things together better, right?
The other types of data that Security Engine provides is going to be that of network metadata.
And this data is going to be recorded by Zeek, formerly known as Bro. You might have some Bro
fans in here. And this metadata is going to give us a lot of detail around specific protocols and
transport mechanisms that we see in our environment. For example, DNS, HTTP, SSL,
there's tons of different protocol parsers for Zeek. And it gives us just a lot of great detail
about those, right? Like URIs, user agents, queries, the query codes, whatnot. Just tons and
tons of different stuff that you might have associated with each different type of transaction.
And then the full content data is another thing that Security Engine provides. And this is going
to be commonly known as PCAP. So we can render an ASCII transcript of that PCAP based on whatever
items that you're looking at in Security Engine. So if you want to go from an event in Kibana to
the PCAP and see the actual raw communication, typically if it's not encrypted or whatnot,
or if it's not some unsupported protocol, then you should be able to see that activity.
And it helps to really verify what you think is going on and the other things that you're
seeing in the environment. So again, it offers that complete picture or that complete transcript
of what is going on. Now, you can feed supplementary data to Security Engine. So we have
the HIDS data, the NIDS data, we have all of this network metadata and stuff generated by Zeek,
we have PCAP, and then we have other stuff like Beats, right? So using FileBeat, we could pick up
DNS debug logs, we could pick up specific application logs and send those off to
Security Engine. We could pick up Windows event logs and send those off with Sysmon and whatnot.
We could even use PacketBeat and send that stuff. So if we have a segment where we're monitoring
hosts, and some people do this in the cloud, but whenever you can avoid it, I would probably
recommend it, you can use PacketBeat to have it on those isolated hosts. If you have a host that's
on its own dedicated network and you're not allowed to monitor that segment traditionally,
maybe if you have that pinhole in the firewall or whatnot, to install PacketBeat and send that
data back, you at least have some better visibility into what's going on in the box,
as well as a host-based agent and whatnot. And then there's stuff like S3 and Azure event hubs
that Logstash affords us, and even FileBeat these days, that we can send data from those
storage facilities and even Syslog. And that's great and all, right? It's great that Security
Engine offers that stuff, and I haven't really gone into a lot of detail so far,
but how can it help us when we're in a cloud environment, and how might we set that up?
Or what might that look like? What does the infrastructure look like?
You know, maybe with AWS or something similar. So that brings me to traffic mirroring. When we
talk about traffic mirroring, I'm talking mainly here with regard to AWS, because that is the
actual naming of their mirroring facility in AWS. And we can take advantage of that with Security
Engine. We can basically use this architecture to collect this traffic from these hosts and then
forward it off to our Security Engine instance. So we can set up a mirror target, which is going
to be our Security Engine instance or a sniffing interface, and we can set up our mirror filter,
which is going to filter any traffic that we want to go to that target. For example,
if we don't want certain traffic, if we don't want DHCP or some other type of traffic to be sent
to our Security Engine instance, we can filter that out with our mirror filter. And then we'll
set up our sources, which will feed through that mirror filter into that mirror target.
And all of this encompasses a mirror session, really. So that's what a mirror session is
comprised of. And that is really the pretty basic concepts of the AWS Traffic Mirroring.
Again, that traffic mirror target is going to be where we define the target interface,
our Security Engine instance in this case, where we want to send our mirrored traffic
that we're collecting from our hosts. And then we have that filter, which is going to filter out
any unwanted stuff that we don't want or allow us just to specify what we do want.
And then we have that overarching mirror session comprised of each of those.
Let's check this real quick. Okay, no questions. All right. So let me get back to this. All right.
So the mirror session, then. You can see here we've got a screenshot right here. The name is
just Security Engine demo session. And then, again, the source and the target, which is our
Security Engine instance. And there's another way we could approach this. So maybe instead of
just setting up a standalone instance of Security Engine, if we just want to have our Security
Engine forward node, which is going to be our sensor only and our distributed deployment,
we can have just that in AWS. So typically, I don't think I went through this, but our
architecture would suggest in a distributed fashion that you have a master or manager node,
and then you have this forward node. And then you have a storage node, which is going to store most
of your elastic data. So what's going to happen in this case is you're going to send your forward
node, or you're going to have it in AWS. It's going to be collecting that traffic from the
mirror session. And then your master server is going to be connected up to that. So you could
have an on-premise master server. You don't necessarily have to deploy all of Security
Engine in the cloud. You could have another on-premises forward node, right? You can have
all of these different types of devices on your local network and have maybe open VPN or direct
VPN access to the cloud and having that one security in an instance if you need it.
So it's very flexible how we can architect these deployments. And I think it makes it
very powerful overall for us to be able to have that comprehensive view for both our local and
our cloud networks. And this right here is just an example of some of the VXLAN traffic that would
come across during a typical mirror session. So all of this mirror traffic is going to be
encapsulated, as I mentioned, in that VXLAN tunnel. So this basically, for applications
that can't read it, of course, as I mentioned, creates a little bit of a challenge. But in our
case, Zeek and Suricata can both decapsulate this data. So this is what this looks like
just coming across the wire on a box right here in AWS.
Again, just a shot of some cloud node stuff. If we were going to set up security as a cloud node
and have the rest of it on premise. And as I mentioned before, Suricata 4.1.5 and up, which
of course now we distribute a version higher. I can't remember the exact version off the top of my
head, but we can decapsulate VXLAN now. And VPC mirroring is capable with only these Nitro-based
instances. And I've got some documentation down there at the bottom with regard to those EC2
Nitro instances. So you'll want to make sure if you're monitoring stuff or if you've not even
deployed yet, and if it's feasible cost-wise, that you're deploying on these supported instances so
that we can take advantage of that. And then again, there are other considerations as far as
mirror sources and destinations. There are overall limits to the number of sources, so
please do check out that link down there if you do plan on standing this up in production.
Just testing in a lab environment, you're never going to really exceed the limits here. But
architecturally, there are some considerations that you'll want to have, maybe using a
NLB or a network load balancer versus individual hosts and whatnot. So that's just something to
think about there when you're going through and planning your deployment.
All right, and before we get started here, I also want to talk about TMNIDS real quick. So
TMNIDS is an open source project written by Tiago Faria and ThreeCorsec. So they've been
doing a bunch of great work with NSM lately, specifically NSM in the cloud.
And what this is, TMNIDS is an open source script that will allow you to, if you're familiar with
NIDS, testing your IDS using TestMyIDS. So it's a very... folks like me that have been doing it
for a little while, there's a site called TestMyIDS, and you would curl that and you would
get the UID root, and that would send you a little IDS alert as long as that rule was enabled and
make sure that your IDS is A-OK and that it's working as intended. And this serves a similar
purpose. This is a little bit more modern day, I think, and of course you could extend it if you
wanted to, but you can see here the different choices of alerts that you would like to trigger.
So you have a few different options here to try and see, generate some data, generate some alerts,
to see if that IDS is working, and to really just generate some interesting lab data. Now,
all of this traffic right here is not actually malicious, just simulating the maliciousness,
so please don't be afraid to run it. I know Tiago very well, and he would not... I don't think he
would do anything like that, so... All right. So now, I know we've been talking a lot. I've been
speaking to the joy of security and how it might help us. And now, I want to go through just
setting it up from scratch in AWS, and hopefully you guys can follow along if you have an AWS
account and you've seen the resources that we have here. Let me just get out of here,
out of presentation mode. So we do have these resources here that should have been in the talk
description or the workshop description. And if you scroll down here to follow along, I not long
ago posted a document. And this will really be just a text-based version of the instruction here.
And if you can, if you would like to, please do follow along. It is not the most verbose,
but hopefully it captures everything that we need to do here, and I myself will likely be referring
to it as we go through, just to make sure I don't miss anything. So please do let me know if you
have any questions or something seems amiss, and we can definitely get that taken care of.
So without further ado, I will begin to go into AWS here. Let me just go ahead and refresh.
And what we're going to do here is we're going to stand up a security and an instance from our
community AMI here. And we're also going to stand up another instance that we're going to be
monitoring with the VPC, sorry, or the traffic mirroring. So we're going to get through from
scratch, set this all up, and then I'm going to show you a way to make this a little bit easier.
But I do want to get started from scratch, just getting you guys used to all of these mechanisms,
all these different concepts, and maybe nailing them down a little bit more easily.
Okay, so I'm in AWS here. I want to launch the security and an instance from the AMI.
So a quick note, real quick too, if you guys do have trouble, I know this might be a deal
breaker for some of you guys, there are images. So if you're looking and you don't see the image,
there are images in EU Central 1, EU West 2, US East 2, and US West 1. I won't be able to
update that on the fly right now, but if you do still want to try it and you're in another region,
please feel free to reach out after the workshop and I can definitely help you out there.
So we've got these four in these four regions. Right now I'm going to be using US East 2.
So if I go, obviously you can see I have zero running instances right now.
I'm going to launch an instance here.
And come on, click launch instance. And I'm going to search for security onion.
Right now, don't be fooled, you may see one in the marketplace here. We don't actually charge
for our image here, and I don't believe we plan on doing that in the future. You'll see one here,
it's by BL King Consulting. Do not use this one. Do not. This one, first of all, is based on 1404,
which is several iterations behind what we're on now, and it is not supported nor endorsed by us,
so please do not use that one. The one we will be using is this security onion 1604 right here.
The official AMI provided by Security Onion Solutions. So we're going to select this,
and the smallest you probably want to go on this is going to be a T3 medium.
Now, this is going to be a little bit of a charge. I mentioned this in the documentation.
It's not really much at all. It's a few cents an hour to run this box itself, so it's not much,
but just a heads up there that it's not completely free.
And again, this is not really for Security Onion itself. This is just really the infrastructure
that's running Security Onion. So we're going to choose T3 medium for Security Onion,
and we're going to configure instance details. Oh, you know what? I skipped a step.
All right, so let's go back. See, I should have been reading my own documentation. All right,
we'll get a VPC because first of all, we need a VPC to put all this together, right? So we're
going to launch the VPC wizard, and for the sake of ease for this workshop, we're going to choose
a VPC with a single public subnet. Now, if you're doing this in production, you probably don't want
to do this. You'll probably want something behind a VPN using OpenVPN or Direct Connect or something
like that. But for purposes of our testing and whatnot, and because we're whitelisting by IP,
it'll be just fine using this. So what we're going to do here, we're going to specify the
CIDR block for the VPC and then for the public subnet. Now, if we go to the docs here,
we're going to choose the default 10 WACC for the entire VPC. But in case you wanted to add
something later, we're just going to specify the 10 110 for the public subnet. So that's what I'm
going to do here. 10 110. So if you want to go play with it, you could add other subnets later.
We just want to narrow the scope on this one a bit. All right, so we're just keeping the name
public subnet. Sorry. There we go. So we'll keep it like this. And then we'll go with the default
public subnet name right here. And then we'll click create VPC. And I forget to name it.
Okay. So let's go to my VPCs. And I'm just going to give it a name here because I failed
to do that. Because once again, not following my own directions. So I'm going to call this VPC
security onion demo. And right here we can see that one VPC is available. Now if we go into EC2,
we can go to running instances. We'll go back and we'll launch an instance.
We'll launch that security onion instance I mentioned before. That AMI.
Like that. And we'll grab the T3 medium here and we'll go to configure instance details.
And we'll make sure it's in our VPC that we defined and of course in our public subnet,
which it should be since those are the only ones that we have available right now.
Now what we're going to do here is we're going to go ahead and add the secondary device
for the sniffing interface by clicking add device right here. And what this is going to do,
it's going to make it so that AWS will not be able to publicly assign an IP address if you have,
you can see it here, if you have more than one interface. So we're going to go back and
fix that in just a minute. But we're going to go ahead and click next, add storage here.
And everything looks good here. We don't need to modify anything here.
Let's click next, add tags. And unless you really wanted to, we don't necessarily need
to add any tags here. I just really want to get to this configure security group right here.
And so what this one is called, it's called right now launch wizard one. We just want to call this
maybe, actually we'll select a default security group here. All right. And we'll click review
and launch. So this will have our default security group attached to it once we launch it.
All right. Now, what we can do here is it's going to ask you for a key pair to authenticate to your
host. Now, if you don't already have a key pair uploaded to AWS, you can create a new one and
then use that key pair to connect with this instance. You could proceed without a key pair,
which I don't recommend because you won't be able to get into it. So we're going to do
create a new key pair. And go to onion demo. All right.
And download this key pair. Okay. So I've got it saved locally now. And if I want to launch it
from my terminal, I can do that. I'm going to go ahead and launch this instance now that I've got
the key pair downloaded. And we get this nice little screen and we can go view our instances
here. And we can see that it's starting up here. All right. So it's going to flip back over here.
So once we launch that instance, what we're going to want to do is we're going to want to go to that
network interface and we're going to want to allocate an Elastic IP. So this makes it available
publicly so that we can access it from our box across the internet. All right. So let me go
ahead. Go to actions. Well, I'm sorry. Go to the network interface, eth0, which is the one we want
to connect to. It's going to bring up this hyperlinked interface ID. I'm going to click on that.
All right. So we brought up the interface and it's selected. And then we want to manage the
IP addresses for this interface. Once we get there, we can allocate an Elastic IP for it,
the one I mentioned previously. It's going to give us a new tab here. And it's going to ask if we want
to, you know, how we want to allocate it, what kind of settings. Just leave the defaults here and
click allocate. And then you can actually see that I've got some various ones that I didn't clean up
before allocated. But here you would have one here. So let me just go ahead and delete these
just so I'm not confusing you guys. Okay. I'm just going to release those real quick
so I'm not confusing anybody. All right. So we've got our Elastic interface. And now that
that's allocated, we can go back. Go ahead and hit cancel. Go back to actions and go to associate
address, which will allow us to associate that IP address. And we want to click allow reassociation
just in case that we want to change it later. We probably won't be doing that here, but
might be a good habit to get into if you want to be able to reassign them.
And then we're going to click associate address.
Okay. So now that we see that the... if we go back to the instances, see the instances running,
then we see our public IP right here. So if we want to go ahead and verify that that is up,
we can do that from here. So I downloaded that PIM file right there. You see right here,
securityunion1.pim. And you can do this with sudo or you can change the permissions on the file.
I'll just use sudo in this case to elevate my privileges to be able to execute this.
But I'll just do... I'm not in the downloads. Let me change to that.
And real quick before I continue. So when you're SSHing here, if you're on Mac or you're on Linux
and you already have a native SSH client, you should be able to do this natively. But if you're
using PuTTY, you will need to do something like the following in this link to convert the PIM file
for use with PuTTY. And it's going to be using PuTTYgen so that you can basically have PuTTY
source that that's a public key and then be able to go off and authenticate to that host.
So do look at those links there if you need to do that.
But then down here, we also have the command that you'll run. And then again,
if you don't change the permissions on the file, you will probably have to add sudo to that
to execute it with higher or elevated privileges.
So I'm going to do an SSHI PIM and then the default user for the security in an image
that's going to be onion. So we'll use onion at and then the public IP right here of the host.
Okay, so we'll paste that in here. And we'll just hit enter. And this is my local password
so that I can sudo. Remember it. Let's see if I fat fingered it again.
Oh, you know what? Okay, so what we're going to do here. One more thing. I'm sorry.
We'll need to change the security groups assigned for this interface.
Okay, so we'll go into security groups, go back to our default security group.
Okay, and we'll edit the inbound rules because we really only want to allow SSH
for our IP. And so I'm just going to allow it for my external IP here.
And then also for HTTPS when we want to access the web interface of a security ending. So
just modify the inbound rules here for the default security group. And we'll just save that.
Okay, so now anything that's part of that default security group will respect those
firewall rules. So now we only have SSH and HTTPS from that external IP.
And you'll want to do the same when you're standing ears up. So we'll do that real quick.
And let me just do this real quick.
And right now that we've modified that, we can just hit yes to accept here. And now we are into
our security box. Now we we do have the security in an image and most of the stuff is installed
already, but we still have to run setup on here. So what that means is the actual process of
configuring all the stuff and you know, and all the packages installed on the OS. So what we'll
do here, just some kind of administration stuff. We'll just change the host name real quick to
something like security and in demo. And I'm just going to reflect that in Etsy host real quick.
So we'll change Etsy host name and Etsy host. I'm going to just give the box a quick reboot.
Let's check for any questions or anything. Okay. All right, so it's probably rebooted by now.
Because these AWS instances are pretty fast. So SSH back in to security and in demo.
And now what we'll do is we'll run the first phase of setup for security. And what I'm doing here
is I'm running SS setup minimal. Now, because we're running on a box with four gigs of RAM,
yeah, four gigs of RAM and two cores, we run the minimal setup of security in it so that we can
still operate efficiently. You could run the full fledged version, you would have to size up probably
to a T3 large, or maybe even a little more comfortably a T3 extra large. But SS setup
minimal will be more than enough for our lab. And usually is more than enough for many folks as well.
So we'll run that. It's going to ask us if we would like to proceed. We'll hit yes.
Yes. And we're going to configure the network interfaces. And we'll just select ENS5 for our
management interface. And we'll hit okay. And we'll want to make sure to select DHCP and let AWS
handle all of the IP addressing and that sort of stuff. And then we'll like to configure our
sniffing interfaces. So we'll just hit yes whenever it asks us to do so. And then we'll
select ENS6, which is really the only other interface available at this moment. So we'll hit
okay. And so it's just going to ask us if we're really ready. And yes, we're ready. So we'll click
yes. But we are not ready to reboot. So hopefully you haven't gone through and hit reboot just yet.
But if you did, then it shouldn't be too far until you're rebooted. So we'll go and edit.
Since the network interfaces have been configured for the most part,
an important distinction for cloud monitoring and monitoring in AWS is going to be the VXLAN
encapsulation. And what that does is going to add 54 bytes to the MTU or to the size of the packet
in general. So we want to accommodate for that. We want to plan for that. So we'll want to manually
adjust our MTU of our sniffing interface. And we can do that simply by adding this MTU 1575 line
right here. And then we'll just hit control Z to save. And then so now that we've got our MTU set
right there, I'm just going to reboot real quick. It's on. And then once it comes back up, we should
be able to configure our run through the next phase of setup. And I'm just going to refer to
these instructions here to make sure that I didn't miss anything. Okay. All right. So we've SSH'd
back into the security in an instance. And now we're ready to run the next phase of setup.
And we'll run ss setup minimal again. And just hit yes. And yes. And it's going to ask if we
would like to skip the network configuration. And we're going to click yes because we've already
configured it as we want to. And we're going to go through the main configuration, selecting the
production mode option. And then we're going to click the option for a new deployment. And hit
okay. I'm just going to specify a username here. And what this will be is my application level user
account for logging into things like Squirt or Kibana. And basically it's not going to be the
same as the OS level account but a separate account that you would use for those purposes.
Now we're going to roll with best practices here because they are the best practices. So we use
them. I'm going to hit okay. And we're going to use the default ET open rule set here. We're going to
click okay. And because Suricata does offer that VXLAN DCAP, we're going to select Suricata
versus Snort right now. And we're going to hit okay. And we're going to enable the network
sensor services because that's what we're looking for. And we're just going to go with the defaults
here from there. Logs. Okay. And continue. And so what's going to happen, that's going to roll
through setup. And while that's rolling through setup, we can go ahead and start prepping our
other node that we want to monitor. So I'm just going to minimize that. And go to instances. And
let me flip back real quick. All right. So we're going to create an instance, a Linux 2 AMI
instance. We're going to launch right here. And another thing to remember, and what I mentioned
earlier, is you'll want to make sure that for the traffic mirroring that you're using supported
instances for those Nitro instances. I'm sorry, Nitro-based instances. And the T3 line of images
is one of those, as well as I believe the T3A. So what we're going to do here, we don't have to
select a giant image. We can still use a very, very small image. So I'm going to use a T3 micro
right here. And then I'm going to select configure instance details. And sure, all of this good
stuff, the network and the subnet looks okay. Everything else looks okay. And what we can do
is we can actually just auto-assign a public IP. So if we select that, then it'll automatically
assign an IP, since we only have a single interface. And then we'll click next add storage.
Don't need anything else here. Add tags. And then we'll make sure that we're using the security
group that we want to use. In this case, we can again use that default security group because
we'll want that SSH access. While we really don't need HTTP access, in this case,
as far as a demo, there's really no need to create another security group because there's
not really anything running on this host as far as HTTPS. So we're just going to click review and launch.
Okay, all right, and launch. And it's going to give us the same question about the key pair.
So what I'm going to do here and what we can do is select the the key pair that we created
previously. So the one that we just created was security in demo one. We're going to select that
and click I acknowledge. And then we're going to launch instances here and go to view instances.
Okay, so now we see it's creating it automatically assigned that public IP
that we can then access here in just a minute. So we'll flip back over here.
Security is still downloading a few things, still configuring a few things.
And then you go ahead and double check here.
Yep, okay. So while that's still going, what we can do is create our security group that's going
to be used for the sniffing interface of security. So what we want to do is be able to allow access
or allow traffic to be forwarded to that interface, but we don't want that interface to be able really
to or anybody else to that interface. So we'll create a security group right here.
Just click create security group and we'll call it security and sniffing group.
And this is the group that dictates who can talk to security and sniffing interface.
All right, and what we're going to do here, instead of all traffic, well I guess we can do all traffic, but
in fact you'll want to. So you'll want to limit it to the subnet that we defined earlier, right?
So we will only really want to accept traffic from those hosts that are forwarding that traffic.
Only accept from internal, so that's outbound. I'm sorry, I'm not... well that'll be the same case.
So we really only want outbound connectivity to those as well, if there's any at all. So we'll do that.
All right, so we've created that group now and what we can do is we can associate that
with that sniffing interface. So if we go over here to our instances again, we will... let me go ahead
and label these so they're a little bit easier to see. Okay, all right, so this one's the security anyone?
All right, so we'll go to eth1 and we'll go to interface id and we'll go ahead and we'll change the security groups.
I'm going to change it to this security and sniffing security group. All right, so it no longer has
anything that can access it from external. It needs to. It's only doing its deed as a sniffing interface.
All right, so what we do next... let's go ahead and check. Okay, so run through the first set
and there's just a little bit of post-configuration that it automatically runs through here for the
security inbox. All right, so we'll let that go and then what we'll do here is open up a new terminal
and we're going to go ahead and ssh to our Amazon Linux host while the security inbox is finishing up.
Okay, I'm going to do the sudo ssh i
1 and the default user for the AZ Linux box or the Amazon Linux box is going to be ec2-user
and we'll just paste this in here and again
prompt it locally because my sudo and if i could type oh my goodness okay all right there we go
all right so we're in the Amazon Linux node right now over here on this screen
okay so we got that ssh session going there
all right so it's not quite finished here
Okay, so we've got those two SSH connections up now. Now what we'll do is really, I guess
what you guys have been waiting for, not the boring AWS setup, but the actual mirror traffic
configuration. Okay, so what we'll do now is go ahead and create our mirror filter,
our mirror target, and our mirror session. So, go over here to VPC, and traffic mirror
filters. We'll just go ahead and create the filter first, and we're just going to name
it security.demo, and let's call it security.demo. Alright, now we want everything in this filter,
we want all the traffic, all the things. So we'll do a quad zero here, here, the inbound
and the outbound, we'll do a quad zero for the source and destination, because it will
actually filter out the inbound and outbound from the traffic it's mirroring if you're
not careful, so that's why we're doing that here. Okay, and we'll hit close. So we've
created our traffic mirror filter, what defines what will be forwarded to the mirror target.
Now we'll go ahead and create that mirror target. Alright, and this is going to be the
security.onion.sniffing demo. And what we'll do here is we'll choose the target ENI, or
network interface. And right here, as you can see, these primary network interfaces
aren't going to be it, those are going to be management interfaces. So we know that
it's this one right here, otherwise we might have to go check. Alright, so we'll hit create.
So we've created our traffic mirror filter and our traffic mirror target, so now we just
need to associate all this with a source inside of a mirror session. And that's what we'll
do here is our security.onion.demo.mirror.session. And our mirror source, again, is going to
be one of these primary network interfaces. However, we don't know just yet, so we'll
need to go over here to instances, and we'll need to go to the instance where we want to
mirror and find that source network interface. And here it is, eth0. So we're going to click
that, we're going to grab this interface ID and copy it so that we know for certain which
one we want to monitor. And it's this primary network interface. And we know here our target,
so we'll select that. And one thing that always gets me is that you'll have to enter in here,
even though it's prepended, or pre-populated with a 1, it's not really filled out, you
have to enter a 1 there for the session number. And then we'll hit create... I didn't add
my filter. So we'll need to add filter here, and that's going to apply that filter, right?
So let's create that. So we've now got our security.onion.demo.mirror.session, our traffic
mirror session, created. So from a networking standpoint, security.onion, or at least the
box, should be able to see all this traffic on the network interface. So let's go back
to our SSH session. Okay. So setup is now complete. I'm just going to check the status
and make sure everything looks good. Okay. And real quick, before we dive into any of
the other stuff, I'm just going to check real quick with the tcpdump command to check and
see if that traffic is coming by. I don't see anything just yet. But if we type here...
and let's see if I can break this out into a different one. We can see now that our traffic
is being mirrored. Right? So that's it. It's that simple to create the mirror sessions,
right? It's a little bit of work to get the infrastructure set up. And to... I guess
once you go through it a couple of times, it's a little bit easier to grasp, I guess.
But it's fairly straightforward to get that set up. And now once we have that, since we're
using security engine, and we want to see that traffic, we can actually use something
like... where is it? Test my nids, which I was referring to earlier. And so what this
does is it's going to execute a series of tests, callouts to this actual website, testmynids.org.
It's going to simulate that bad activity. So if we just do this here, and there's several
options right here, we're going to enable pure chaos and run them all, as always. And
it looks like maybe on Amazon Linux, Netcat is not installed by default, which is fine.
So maybe that one didn't go through, but that's fine. We can just do yum.install.netcat if
we want. Install-y netcat. I'll just run it one more time. And just let it run through
there. So it's just going to simulate some nice traffic for us to be able to see in security
engine. All right, still going there. All right, I think that's probably more than enough
for us to take a look at. So I'm going to get off of this TCB dump here, and I'm going
to allow access locally, because even though we've run or allowed the port in the firewall
for AWS, we have not allowed it for the local firewall. So we'll want to allow that for
the analyst, the port 443. It's going to give us 22443 and 7734 in case you wanted to run
the SQL client, which is... I honestly didn't mention it previously. I didn't mention all
of the tools in security engine. But if some of you have used SQL before, you can use that
SQL client to connect up there and view that alert data. So I'm just going to do... before
I do this, I'm going to do who real quick. Grab this business. Okay. And you can do the
same thing. Run who to get that IP. Just paste that in there. All right. And we'll just hit
enter, and it's going to refresh and throw that rule in there. And then we're going to
access the web interface of that external IP. So let's go back and get our... where
am I going? Okay. EC2 instances. And we're going to grab the public IP of the security
in an instance. And we're going to go over here. That's not it. If I can copy... copy
pasta. Come on, people. All right. Copy and paste is not being happy with me today. I'll
just copy it from over here. Copy. There we go. Okay. Okay.
So we get here, of course, it's a self-signed certificate. Obviously, you would want to
change this if you deploy it in your environment. But for us, it's just fine. For Catalina,
it's annoying. So we type this is unsafe. And then here we are on the just kind of splash
page for security. And there's some links here for Cyber Chef, which we include for
data transformation. And, you know, if you've got things like encoded bits of text, compressed
stuff, performing other types of data analysis and whatnot, it's really good for that. And
then also Squirt, which is going to be the web equivalent of Squeal, where you view that
IDS alert data. So I can pop in there real quick if I want to. And I'll specify that
username and password that I created earlier. And let's see. So okay. So we don't get much
here. But let me pivot back over to Kibana. Okay. And let's see what kind of NIDS alerts
we got here. Hmm. Okay. So we got the return to root one. But we didn't get many others.
I think I know why. I think it's because we didn't enable EVX and decapsulation for Cercata.
So this is something important to note, that we do not enable this by default, just because of the
potential overhead of having to run it and not the percentage of folks who actually don't run
VXLAN traffic compared to on prem. So we'll want to enable that real quick in Cercata.yaml. And I
feel like it's good for folks to be comfortable with that and know where that exists. So right
here we see VXLAN. I'm just searching for it in here. And then we see a VXLAN enabled.
Stanza right here. I'm just going to change this to true.
And yes, I really want to edit it. And just to make sure that it's still there.
Okay. So we've got VXLAN decap enabled for Cercata.
Let's do an asonids restart, which will restart Cercata and pull in that change.
And we're going to replay that traffic one more time and then see what we get.
And this is kind of what I alluded to previously, is no matter if you're watching the traffic or
recording the traffic with seeing that VXLAN traffic, it's very important to be able to have
an IDS or a mechanism to be able to decapsulate that or unwrap that so you can actually see and
alert on what's going on underneath. So if we run this command again,
let it run through. And I'm going to give it a minute before we refresh.
But we should see some more data in there. Hopefully, you know, several more NIDS alerts
and then, you know, something that we can have a little meat towards.
All right. So I'll give that a minute there. Okay. So it looks like it's done.
And if we go back, it will take... it does take about 30 seconds for Elasticsearch to
refresh its indexes. So we'll just do this. And by refresh, I mean basically making it
available for search, even though the data is in there. And so now that we've enabled that
VXLAN decapsulation, we're seeing a lot more. As I mentioned, it's very important that that's
enabled when you're doing this in the cloud. So we can see all sorts of types of alerts here.
And then if we go down here, we can see that stuff here as well. Let me see if I can put
it down just a little bit. Right. We get an ET policy PDF with an embedded file. That's
interesting, right? We could go investigate that. We could see what other activity was
associated with this. So if I wanted to search for this particular IP, this destination IP,
or how about the source IP here? This is strange, right? So maybe where it came from.
I can click that, and what it's going to do is take me to an indicator dashboard.
And this indicator dashboard is basically doing a search for any time this IP address was seen.
So it's going to give me other snort alerts. So these are the Suricata alerts. To clarify,
we just called the data type snort, just for our parsing purposes. It's just what we've done so far
that will change in the future. And then we can see the Ebro connection records,
or ZEKE connection records, and then the ZEKE files records. Again, we've kept the
older naming convention for now. And then the HTTP records, right? So we also see different
stuff that this destination IP address was associated with. And then we can see some
other, if there were any other source destination IPs that communicated, right? And then, let's see,
get some different MIME types here. And you can really, at least from here,
go off in each type of these, right? If you want to filter down for, say, HTTP,
you can scroll down here, look at these HTTP logs that we've indicated via the indicator dashboard,
drill into those. And then, now this is important as well. In fact, I don't know many,
even commercial solutions that can do this off the shelf is VXLAN decapsulated PCAP.
So I will say that typically in the on-premise version, you can pivot to PCAP from here and
see the full conversation, as I mentioned. One limitation currently with the current platform
is that you can't necessarily pivot to PCAP, but you can enable stuff like Suricata,
EJSON logging, and still log that packet. Or you can do other stuff with that PCAP,
which I'll talk about in just a little bit. But again, you can see the breadth of data
that we have here. As far as HTTP, we have MIME types, the file IDs that were basically
Zykl pull-out identifiers for the files that it rips out of the network stream. So we can
pivot based off of those into different types of data, and it can be very powerful.
All right, so if we go back here again, if we just want to even get a summary of the
connection data, so we can see all of the stuff that was even VXLAN. So if you want
to separate out nodes that are maybe cloud nodes and maybe on-prem nodes, then you can
kind of filter out maybe based on the VXLAN, because all of these are VXLAN encapsulated.
So if I filter on those, well, let me actually do this.
Let's take those out then. It's really going to be the categorized con logs and whatnot.
So again, I mean, you can group by service. You can then, if you want to drill into,
maybe you've got some weird SSL stuff, you know, you've got a high count here,
then you can drill into the SSL data over here.
All right, and then we can see the different server names that we have here, common names
associated with the SSL, the validation status, if you want to track validation of certs,
and maybe, you know, you see some certs that aren't valid or track expiration, stuff like that.
There's a lot more here than, you know, just detection-oriented stuff. And, you know,
a lot of that, even that stuff can lend its way to being detection-oriented.
So, as you can see here on this Zeek hunting panel, there's tons and tons of data that we
could pore over if we wanted to. We could see these query types and these response codes for DNS,
obviously what server we reached out to, the actual queries, right? So, you know,
hey, that's a weird query, right? So, it's pretty easy to stack this data and to see
it and represent it in an easy-to-digest fashion. And then, again, with the HIDS alerts,
if we had any host-based agents deployed, we would see those logs here, and we could,
you know, drill into different details there. You can see the TCP dump that we ran locally
earlier, and you can also see where we modified suricata.yaml. So, Suricata, I'm sorry,
security in itself will run a local Wazoo or OSEC agent here on the box and watch everything
that's going on its own box as well as any other agents or any other endpoints to which we deploy
it. So, again, you know, being able to tie in, and we don't have any just at the moment,
you can tie in autoruns data, beats data, and all that other good stuff to help augment this data.
And, again, you know, there are things like CloudWatch, and there are these host-based
events, but being able to have the network security monitoring component and being able
to bridge the gap from the host to host and being able to see what's going on is super powerful,
and in many cases can be very cost-effective compared to other solutions. So, let me just
go back here to... let me make sure, see if I missed anything here. Okay. All right. So,
we walked through that. Let me see. So, again, that's how you, you know, from scratch go and set
up security in that environment in AWS, promote that traffic mirroring and whatnot. And I know
I didn't go into a whole lot of the investigation, but I really just want to try to leave you guys
wanting for more and exploratory there and being able to delve into a lot of that on your own
and in your testing. But I will continue here, and what we're going to do is I'm just going to
go ahead and terminate these real quick. Yes, terminate. I'm going to clean up the VPC here
and then show you guys something else, which if you do have that Ubuntu host and you're able to
have internet access, you should be able to follow along with. Let's see. Okay. So, it's
going to take a second for those to get the story there. So, I'll go back here with the PowerPoint
and I'll follow up on some more stuff while that's happening. So, we'll move on. I mentioned
that supplementary data. So, if we want to bring in Azure logs, stuff from Azure Event Hubs,
we can absolutely do that. Logstash has an Event Hubs plugin that we can use. So, we can pull all
that telemetry, all of that data into Security Engine. If you've got multiple clouds, that can
be a very effective solution. And what that looks like in summary is, you know, the instructions
are here. I'm not going to go over these too much right now. I'll leave this as an exercise
to the reader if they want to go and do that. But there is plenty of guidance on being able to do
that and just ingest that data into Security Engine. This is kind of what it looks like,
the configuration there. Again, once you configure that, you can pull those logs from
Azure Event Hubs into Security Engine and then correlate that data across all of your other data
and have, again, your cloud data and your on-prem data and whatnot all in one place
through that single pane of glass. And this is kind of what it might look like here. So,
we've got some stuff from Event Hub. We're just tracking administrative actions here.
Different... looks like somebody listed some keys here in Azure. So, that might be an interesting
event to go after. And there's tons and tons of stuff that you can glean there
and throw in there to make that context even greater. And the same case with Google Cloud,
which I'm not going to go over with too much right here. But you could also have things like
VPC flow logs or audit logs sent to the cloud logging functionality, the export sync in Google
Cloud. You could pick that up with something like PubSubBeat and have that transmitted to
Logstash if you like. That is one option. And, again, I'm not going to go through that too much
just right this second. It's kind of what the configuration looks like there. Fairly
straightforward as far as PubSubBeat itself. And then once that data is in there, again,
if you've got VPC flow logs from Google Cloud and you're not performing any other type of monitoring,
then we can pull that stuff in. And the same thing with AWS, right? So,
aside from traffic mirroring, we can still pull in CloudTrail, we can still pull in CloudWatch
and throw them into S3 and have Logstash read from S3 and have those in security
and in for that greater context. And I'm just going to skip through this.
And so, before continuing any further, again, just again kind of harping on the idea that
you can pretty much take any of this cloud data that you want to augment your current
monitoring strategy with and send it to security, whether it be in the cloud or on-prem,
and really have a powerful solution without having to buy into a bunch of commercial stuff,
basically. So, to move along from that, I want to talk about 3CoreSec AutoMirror real quick.
And what it is, is it's another open source tool by 3CoreSec, Tiago Faria and his folks,
and it really allows for that quick and easy facilitation of NSM. Now, we talked about the
mirror config, and obviously going and adding stuff to a mirror session can, if you have a ton
of hosts and they spin up and spin down, it can be a chore and it can be difficult to manage.
So, one of the solutions here is to use 3CoreSec AutoMirror in AWS. And what this means is that
if we have instances tagged with mirror equals true, a mirror tag that equals true, then we can
do that upon creation. That can be a default and a template, and then these will be added to a VPC
mirror session for a mirror target. And what that means is that we can spin up one host, we can
spin up another host, we can spin up another host, and these will all be added to the mirror session,
and security on end can be watching these without having to do any additional configuration.
It's pretty powerful and pretty awesome to be able to do something like this.
Now, it sits as a Lambda function. Tiago has released a serverless app. The way I use it,
I upload a Lambda function with everything required, which is the way that he used to do it.
If you're not using security on end, you can still use that, obviously, to facilitate that.
Another thing I want to talk about, automating the deployment is one of the things that I
mentioned at the beginning, and something that really doesn't take too much time.
This is where we can automate the deployment of security on end and 3CS AutoMirror so that
we're deploying a security on end node, we're deploying maybe a Ubuntu instance
for a lab environment or for POC. Ultimately, you could do this with a production environment.
Although the templates here aren't necessarily suited for a production environment, you could
tweak them to do so. Again, that's kind of what I want to walk through here and get into the
next demo here. I will hop out of this and check on our instances. Let's go ahead and do this.
Ta-da! Refresh. Okay, so those are gone. Now I'm just going to clean up this VPC. I really don't
want this thing anymore. You know, it's just we want to try to automate this thing, so let's just
delete this whole VPC. I don't need this stinking thing. All right. All right, we blew it with
smithereens. Okay, so now we've got a fresh account, right? No VPC, nothing. Now we want
to automate this. How do we do that? So we're going to pop over. I've got any Ubuntu 18.04
box right here. Let me get out of this. This thing is in my way. Sorry, let me
clear that up. Okay, so now what we're going to be utilizing here is going to be, let me go back
real quick, this security onion cloud right here. So this page, it's in the link here in the
document for this automated deployment. Let me go ahead and paste that in there just in case.
And we're going to be doing it for AWS.
So I didn't put it in there. All right, so you can go there to take a look at that,
and you can follow along. The steps I use are going to be a little bit different. It's not
going to be as manual. So I'll just go from there. But let me go back to my host here,
and what I've done is I've already get cloned security onion cloud. So I would just do...
probably should have done this from fresh. All right, so we're going to do a get clone
security and solutions security onion cloud right here. And then once that's cloned,
we're going to cd into it. I'm going to cd into the Terraform AWS directory.
So we can see all this good stuff in here. And what we're going to want to do is there are a few
variables that we need to populate. First of all, when you're first installing it, you need to run
obviously the prep. It's going to be the prep so script. So if you just clone that,
it's going to be prep so right here. Just do a sudo prep so and super secret password. All right,
it's going to run through. It's going to install Terraform. It's going to install AWS CLI. It's
going to install jq. Just because we like things pretty. It's going to install...
know what? What else is it going to install? It's going to basically get everything prepped for the
Terraform thing that we're going to do here. And then it's going to prompt you to configure AWS CLI.
Now, when you configure it for the first time, you're going to get this. It's configuring AWS CLI
and then the access key ID right here. So it's not going to show secret right here. It's going to
just be blank and you're going to have to enter in. Let me see if I can get it right here real
quick. You're going to have to go here to my security credentials and access keys. Expand
that and if you don't already have an access key, you're going to create one. And there's going to
be an access key ID, right? So once you have that access key ID, you'll paste that into the first
prompt. Then there'll be a secret key that's included with that. You'll paste that into the
second prompt. So this access key ID isn't necessarily like your secret key. You may still
want to protect it, but obviously you're not going to be able to do anything without the secret key
as well. So we'll just press enter here to keep the secret access key. And then in the region,
you're going to want to specify one of those regions that has access to that AMI. So in our
case, that's going to be that US-East-2. It's going to be the US-West-2, the EU-Central-1,
and EU-West-2, I think. Sorry, I've got terrible memory. EU-West-2, yep. Let me go back. Alright,
so I've already got this configured, so it's just going to keep the defaults. And default output
format is none, that's fine. Okay, and I've already... it's already generated a public-private
key pair. It's going to prompt you on your first install, and you can just hit enter for the time
being unless you want to protect it with a password, which obviously in a production case,
you would want to take more secure measures, but for the purposes of testing, you should be fine.
So we're not going to overwrite this. Alright, we're just going to... it's going to prompt us
from this stance if we would like to have any Ubuntu host also stood up that we want to monitor.
Now, there's an option in the actual terraform.tfvars file that you can modify if you want
this enabled or not, but this just helps you do it. So this is just less manual going in and doing
stuff. So I'm just going to select yes, and then what it's going to do is it's going to populate
this... terraform.tfvars. It's going to populate it with the path of the credential files, which
should be the default that you're going to be using. It's going to already have the default
path of the security and then key pair, and then it's going to have... where is it? The Ubuntu
host right here. Now, this instance type and... I'm sorry, the AMI will get configured here in
a minute. Don't worry about that just yet because that may be an old AMI that you're looking at.
But thankfully, what we have here is a launch SO script, and what this is going to do,
this is actually going to grab the latest AMI. It's going to substitute that in for that AMI
in that file, and then it's also going to try to determine your public IP address,
and if it can determine your public IP address, it's going to populate that in there as well.
So you don't really have to touch it a whole lot. Otherwise, you can go inside of that file,
that TFR's file, and modify it yourself. So we're going to go ahead and click sudo launch so,
and what it's going to do, it's going to run behind the scenes a Terraform init
to initialize Terraform in this directory. It's going to also do the things I mentioned a second
ago, and then also a Terraform apply auto approve so that it goes ahead and runs that action.
And now what it's doing is creating that entire VPC, it's creating the subnets, it's creating the
security groups, it's creating the instances, the mirror config, and auto mirror lambda function,
and it's doing all of that behind the scenes. It may take a few minutes, so you know, if you
see it sit there for just a couple minutes, that's normal. Wes, we do have a question that came up.
It's one dumb question. Is it possible to make it work like a host intrusion prevention system?
If not, are there any open source projects that can do that? Yeah, yeah, so I mean you can also
not use the nids, the sensor components at all, right? You can send up security engine and only
enable Wazoo, or you know, if you want to point just stuff to Elastic Stack, you can do that.
Yeah, I mean, you can absolutely do that and only use the host-based monitoring components.
Absolutely. Okay, so let me go ahead and copy that. So now you see that we now already,
instead of spending the time, you know, going and configuring this manually, we now already have
these ready to go, right? And what did I do? Exit it? Hmm, what did I... I did something wrong. Let's see.
Hmm.
Dee dee dee dee. What am I doing?
Let's just get that out of there. Typos. Typos galore.
WLAM root. Hmm, okay, well that's strange. I tested this. No, all right, so let me go back here.
Just do a...
SSHI security. Do I have a typo?
Okay, that's why. Okay.
Okay, so I've actually... I must have the same public IP in here and then host. Let's see.
Listen and host. Okay, let me take a step back real quick.
And do a SSHI.
Okay, so let's try this one. See if this one works.
Okay, so something with the permission of the key. Let me...
All right, so I think what might have happened is the script modified the permissions on the key.
Let me see.
Members.
Apologies for that.
There we go. All right, so basically, that's how it works there. And let me go ahead and get back into that Onion instance.
Okay, so you want to make sure, apparently, that's something that wasn't as well tested with that script.
But just ensure the permissions are correct on that key and you should be able to SSH accordingly.
That is my bad.
Yeah, I was trying to help folks and automate it just a little bit, but apparently it bit me just a little bit.
All right, so onion at security, onion zero. That's going to be the security and then host, right?
So we could go ahead, if we wanted to, just get the interface up. We really don't have to do anything else here.
Let's do an ifconfig.
See, all right, so ens6 is not up yet.
So what we can do, if we just want to run setup minimal real quick, or if we just want to do, really, an ifup ens6.
ifconfig
validate. Okay, all right, so we'll just run through the setup minimal real quick, if I can type.
And what we're going to do here is we're not going to go all the way through the configuration.
We're just going to, really, just illustrating you how the auto mirror and everything else works, since we've already gone through the actual security and install.
So I'm just going to do that here.
Yep, we're just going to reboot real quick.
And again, this is really just about illustrating how quickly and easily that you can stand this stuff up, right?
So it's much quicker than the prior route that we took.
Again, I wanted you to get the feel and get the understanding of how to build that manually,
but it's definitely easier when we're using something like this.
And we can see that security and zero and that Ubuntu zero instance are running.
And then if we want to go over real quick, just to view it while we wait for the reboot,
we can go and see that mirror session that's already created right here.
So it's pretty neat to be able to have that kind of stuff automated.
And you can, again, add another host and it would pop back onto that.
It would also be mirrored as well.
So let's modify that real quick.
And wrong one.
We'll SSH back in.
And it's fine.
Okay, so now if we do a ccpdump, you know, six.
That will also do...
Oops, new terminal here.
Let's see.
Let's do a history grep ssh.org.
Nope, it's not the right one.
All right, let me go back and grab that IP of the Ubuntu instance.
All right, got that right here.
It's this one.
Pop back over here and do an ssh i.
And Ubuntu is the default user for Ubuntu.
All right, and we see that traffic's...
And once again, you know, obviously, if we run something like testmyniz and generate a bunch of
traffic, then we can see all that flowing as well.
So again, I'm not going to go through really the whole investigationary component or illustration.
But again, you can kind of see how easy it is to sand this stuff up and have it automatically
mirrored.
So I would definitely recommend that you check out the Terraform stuff and AutoMirror in general,
you know, aside from even if you're not using the security engine.
So let me go back here.
All right, and so we're not going to do it right this second.
But feel free, if you have some time and you want to experiment, and please do offer any
feedback if you do try it.
But we can also do this with Google Cloud.
So we have on the GitHub as well, we have some usage information for Google GCP over here.
So you can do pretty much the same thing.
And because they use mirroring groups, you can just add a host to the group to be mirrored.
And it's very much so like AutoMirror.
Very nice being able to do something like that.
So it's yet another way to quickly and easily spin up security in Google Cloud and do a very
similar thing.
And then last but not least, there is a tool that we have.
I mentioned that the PCAP is not, you know, we're not able to...
we write the PCAPs to disk, they are VXLAN encapsulated, but we just don't have the
technology in the current platform to actually render that ASCII transcript.
But if you would like to take the PCAP and be able to import it into other tools that
also don't understand VXLAN encapsulation, you can use VXLAN to PCAP.
And I'm sorry, I should play from the current slide and make that a little bit bigger for
you guys.
And what you can do is just run the PCAP through there and it will decapsulate it.
It will take off that VXLAN wrapper, and then you're left with the PCAP that you would
normally see on the wire if it was not transported by VXLAN.
So that's another pretty cool tool to be able to use if you've got VXLAN encapsulated PCAP
and you have tools that need to be able to parse that and pull that in.
And then, of course, all of this stuff you can miter, miter, miter, right?
You can absolutely use a miter attack cloud matrix with some of this stuff when you're
pulling this stuff in, right?
And when you're pulling in cloud trail data, when you're pulling in NSM data, you can create
detections with Elastic Alert rules.
You can use Sigmac from the Sigma authors to convert this to Elastic Alert rules and
base those on those techniques and tactics, right?
And then you can test those detections using something like Atomic Red Team, right, if
you want to do that.
And we've got some really exciting stuff coming up in the next release of Security
Onion 2.0, which is in plans to be released hopefully soon.
Right now we have an RC1 release, Candidate 1 release, of Security Onion 2.0 that you
can go check out by following that link at the bottom.
And it does include that Sigma stuff and Playbook.
Playbook is going to be basically taking the Sigma rules and converting them to Elastic
Alert rules.
It includes OS Query.
I know you mentioned host-based monitoring.
That's going to be another addition to the host-based monitoring that we have.
And also the Hive and Cortex, right?
Being able to go in there and have those events fire from the Sigma rules and then have them
in an investigationary stance.
Have them ready to go in the Hive and creating cases and working those observables and whatnot.
It's just going to be really good stuff.
So please do check that out.
I would have loved to have demoed that for you today.
Unfortunately, we don't have a public 2.0 AMI out just yet.
But definitely do keep in touch and keep looking and we will have something ready for you soon.
And then if you want to download, obviously, the current platform on Security On-End,
you can download it from securityonend.net.
And, you know, absolutely free, open source.
We have a great community, great mailing list on there.
And, you know, hopefully some decent documentation.
And then if you're already using Security On-End or you really want more help figuring out how
to set it up in the cloud or you want training or support, then we have professional services
available for that as well if you need that.
But anything else, if you have any other questions or feedback, anything else,
just feel free to reach out to me at the real W. Lambert on Twitter.
Or feel free to hit securityonend on there and just let us know what you're thinking.
And we'd be glad to help out.
And hopefully you got something useful today.