In this demo,
we're going to go over the lab setup that I'm using
for all the demos in this course.
I only used open source software, operating systems,
and free vulnerable machines to create this lab.
Links to the images and software will be available in the demo files.
For this course,
I'm running the Metasploitable2 and Morning Catch vulnerable
virtual machines and a subnet behind this Snort server
running on Ubuntu Server version 16.
VirtualBox and another virtualization software will work
as well if that's your preference.
If you watched the Getting Started course,
I used an older version of Ubuntu Server for this course to
maximize the effectiveness of the inline operation.
We'll go over the specifics of the networking configuration in a moment.
For now, let's take a closer look at that Snort VM.
My Snort VM is configured using the install guide in the demo files,
which is the same guide I used in the Getting Started course.
Again,
the only difference this time is I'm using an older version of Ubuntu Server.
If you didn't watch that course, don't worry,
I recreated a new environment without the community or
registered rules to enable anyone to watch this course without
first going through Getting Started.
The Snort virtual machine is set up to use inline mode.
I configured three NICs on this machine,
setting one to my local network to enable this machine to download updates,
install software, or for me to connect to it through SSH.
The other two act as a bridge between this router here,
which is really just another Ubuntu Server
configured to route between two networks,
and my internal network, which is running on a LAN segment.
As I mentioned, I used LAN segments and VMnets to accomplish this configuration.
I do not have any devices running external to this environment.
So if all you have is VMware Workstation or if you want to
create the same type of thing in VirtualBox,
it's entirely possible without any external devices.
This is a snapshot of the interface configuration for my Ubuntu router.
As I mentioned,
this machine is configured to act as a router between the internal
network using the 10.0.0/24 subnet and my external network which is my
local LAN configured for 192.168.178.0/24.
The internal interface is on a host‑only VMnet,
which I configured for the 10 network.
You can use VMware Network Editor to make adjustments as you see fit.
If you want to use the same network and same subnet I am,
then you would use VMnet4 and configure it to use the 10.0.0.0 subnet.
I turned off DHCP for this VMnet because I don't want any of
my hosts to use my computer as the gateway.
Instead,
I will statically configure their IPs and set this internal interface
on the Ubuntu router at 10.0.0.254 as their gateway.
To maximize the use of Snort's inline operation and
enable IPS rules and not just IDS rules,
I configured these two interfaces in a specific way to bridge between VMnet4
and the LAN segment that my internal machines are running on.
This will not require any traffic routing,
but it will require that these interfaces do not have an IP address
assigned to them and are configured in a specific way.
To configure your environment in the same way,
you'll need to modify the etc/network/interfaces file.
This interface configuration enables Snort to bridge the interfaces,
inspect the packets,
and block traffic using different actions that
we'll cover throughout this course.
Both of these are using the same options and are
configured with a quad‑zero IP address.
If you're unsure of the names of your interfaces, an ifconfig ‑a.
If there any interfaces that are not configured,
like your new VMnet interfaces that you included,
they should show up here.
In my case, the corresponding names are ens38 and ens39.
Test traffic destined for the internal network will be
sent from a VM running Kali Linux.
Tools used to send test traffic and the exploits used in this course will be
kept simple to focus on Snort's rule configuration and exploit detection rather
than on the complexities of the exploits themselves.
I created a network diagram to explain how these devices are
connected to each other within VMware Workstation.
So you can replicate the environment or change this
diagram to reflect your own network.
I have included it in the demo files.
It is helpful to have this as a reference as we write rules,
so I would recommend at least creating a quick diagram
of your environment that you can use.
For our walkthrough, these five VMs are located on my workstation,
but configured on two different virtual networks and one LAN segment.
The first is the external network,
consisting of bridged interfaces from the Kali VM and Ubuntu router.
Both are configured to a gateway that provides internet access.
The internal LAN is running on the 10.0.0.0/24 network.
The Ubuntu Server called Router is configured to route between
these networks and act as a gateway to the internal workstations
with an IP address of 10.0.0.254.
One interface on the Snort server is in VMnet4,
and the other is in the same LAN segment as the
Metasploitable and Morning Catch VMs.
Once these two interfaces are bridged by running Snort in inline mode,
the Metasploitable and Morning Catch VMs are able
to connect out to the internet, and other workstations can connect to them.
We'll be primarily writing rules to protect these
devices from this Kali Linux VM over here.