In this demo,
we're going to take our file rules to the next level and configure
them to block known malicious payloads by SHA value.
This will allow us to create a file blacklist of known malicious content.
Globomantics was happy with our ability to capture these malicious payloads,
but concerned that they were still allowed to pass through to the internal
network. They would like you to block these malicious payloads while
allowing other executable files to be transmitted.
To accomplish this,
you'll need to use the SHA values of these files to write your
detection rules, instead of just using the file type.
This will allow you to detect and block future
transmissions of the same payload without preventing
other executable files from transferring.
Globomantics would like you to test these rules to ensure
that the new transmissions are blocked.
Let's head over to our Snort VM and add the new rules. As we saw in the last
demo, our captured files were named by their SHA value.
This is exactly what we need to write a rule to block this file.
We just copy this value, and then open snort.lua and make
the change. To add a blocking rule,
we start with the same word, when, and set it equal to a set of brackets.
Within this,
we'll use the term sha256 instead of file_type_id, and set
this equal to our copied SHA value inside of quotes. We can
close this bracket and add a comma.
Now we need are use statement, and this time we'll use block for our
verdict, and we won't need to include any other options. For our
Linux executable, we use the same process, so I'll go ahead and
duplicate this rule real quick.
And then we just need to get the right SHA value,
which is this one right here, and then we make our change.
Now we'll save that, and exit.
Now we'll go ahead and start Snort again and test our blacklist.
We can try transferring the files using the same methods as the last demo,
starting with FTP. We'll open the same session, log in as user again, and
attempt to transfer the file using put. And we'll notice that our transfer
starts and then immediately stops.
All we have is the Ok to send data, and no verification that this actually
went through. Our rule worked, and interrupted the transfer.
Let's see if we can still download payload.exe on Morning Catch.
We'll go ahead and clear out the old download, and then we'll
try just hitting Enter to download it again.
And it's stuck on Starting, s this verifies that our rule successfully
blocked the payload.exe file as well. To confirm,
let's check Snort. As expected, we don't have any activity,
but we can see that Snort did catch the file transfers.
This time I'll just go ahead and view the contents of file.log.
And we have both of our block verdicts in place,
along with the corresponding SHA value of the file,
satisfying our security goals. Before we close out this course, let's
do a quick recap of what we covered in this demo.
We started out by using SHA values we obtained from
the last demo to write new rules.
We configured the verdict to block these files based on their SHA value,
creating a blacklist of specific files.
Then we tested by repeating our transfers and verified
that the files were, in fact, blocked.