In this demo,
we're going to leverage the active response and Appid modules
to block access to Globomantics internal web app and enforce an
internal acceptable use policy.
We'll need to address the following security goals.
Globomantics discovered multiple vulnerabilities in their internal web
application and accessed to prevent access from external users.
They would like for us to send a page informing the
external user of their unauthorized access.
Globomantics would also like us to prevent their internal users from
accessing social media sites using company devices.
To prove that Snort can accomplish this,
they would like you to write a rule that blocks access to Twitter and sends the
same block page you configured in the last rule. As usual,
you'll need to test your rules to ensure they function as expected.
Let's head over to our Snort VM and write these rules.
We will need to use React to accomplish these security goals,
which requires a little configuration before we can use it in a rule.
First, let's create that block page that we want to send to users.
I created this extremely simple HTML page included in
the demo files for this module.
I saved it as blockpage.html in my home directory.
Feel free to modify it with whatever information you want.
The next thing we need to do is modify Snort.lua to activate
react and specify this as the response page.
To do this,
we just need to access snort.lua and scroll down to Section 5,
Configure Detection. To configure react, you just need to remove these
two dashes that are commenting it out and add a page = followed by the
path to your blockpage.html file.
Once we have these configurations in place,
we're ready to leverage the react option in our rules.
Our first security goal in this demo is to send a block
page whenever an external user attempts to access the web
app for our Metasploitable VM.
Our rule will use react as an action followed by http as the protocol
and a source of EXTERNAL_NET any. Our destination will be the
Metasploitable IP and the app is running on Port 80.
The message will be unauthorized web access.
We now need an additional option called http_method.
This is a modification of the content option that allows us to
focus on the method from an HTTP request.
Our content for this rule will be GET,
which is the initial request a client will send to
obtain a page from the server.
Our sid is 1,000,010 and the revision value is 1.
Our next security goal is to send the same block
page for internal use of Twitter.
We can use react again as the rule action, TCP for a protocol, but
this time our source's HOME_NET any and a destination of any any
because we're focused on internal usage. We'll use a message of
acceptable use policy violation.
Next, we need to specify the appid as Twitter.
Our sid is 1,000,011 and the revision value again is 1.
Now that we have a rule set up, we just need to test them.
Let's go ahead and save this file and fire up Snort.
And now we can head over to Kali Linux for the first test.
For this test, we use the web browser and navigate to 10.0.0.100 using HTTP.
And there is our block page verifying that the first rule is successful.
For our second test, we need an internal device.
We can use the Morning Catch VM since it has a full GUI interface
and a web browser. You can log in as either Richard Bourne or boy
genius using a password of password.
Whichever one you choose,
you just need to open a web browser and try to get to Twitter.
And again we have our block page verifying the second rule.
Let's check back in on Snort and see what alerts we generated.
In addition to receiving the block page as we expected verifying
that are react rules worked, we can see here that Snort also
dropped all of our traffic. Before moving on, let's do a quick
recap of what we covered in this demo.
We started out by configuring react with a simple block page,
and then we activated it in snort.lua.
Next,
we wrote two Snort rules leveraging react to send our block
page to targets that matched our rules.
The second rule leveraged appid to identify internal attempts to use Twitter.
Once the rules were written,
we tested them by attempting to access the destinations,
and instead, we received the block page that we configured.