Now, let's look at our external IP look‑up rule and see it in action.
When running suricata‑update,
it will use Suricata's configuration file to know where to write the rules to.
We can look at the configuration file by opening up
etc/suricata/suricata.yaml with a text editor.
And then, you can type a forward slash and that will allow you to search.
Let's search for the value default‑rule‑path.
And here you can see that the default path will be var/lib/suricata/rules.
Okay, now that we confirmed that, let's go ahead and exit out of our editor.
If you run suricata‑update,
you will also see an informational message indicating
where rules will be written to.
So there are really a few ways in which you can get this
information to know where the rules file will be located.
Something that I also want to point out,
if you look at the contents of var/lib/suricata/rules,
you'll notice that there's only a single .rules file.
Rule managers such as suricata‑update will condense all of the sources and
write one single rules file with all of your rules in them.
Next, let's use grep to find the external IP lookup rule by SID.
That SID was 2021997.
Okay, quick refresher now.
This will alert on an HTTP GET request going from HOME_NET to
EXTERNAL_NET when the HTTP URI length is one,
and the http.host isapi.ipify.org.
Next,
let's run a PCAP using the NGS script that will contain
traffic that will generate this alert.
If you remember when we looked at this script after it's done executing,
it will use jq in order to look at the temporary logs that were
generated the eve.json to print the alerts for us.
So once the script is done, we'll see what alerts are generated.
And there they are.
We can confirm our alert matches by viewing the signature ID,
as well as the message.
If we want to get a little bit more information,
we can use jq to query the eve.json file that was generated.
In doing so,
we can see not only alert information but also information about
event data that was generated because of the alert.
So in this case, information about the http request.
Let's compare this content with the rule to see how it matches up.
The length of the URL is indeed one.
The http_method is GET, the http host is api.ipify.org.
And finally, the src_ip is an internal address, and the dest_ip, external.
Another way to look at this would be with Wireshark,
and I'll use the command line in order to launch Wireshark and provide it as
an argument the path of the PCAP that I want it to open.
Once open, we can filter by HTTP protocol in the display filter box.
Right‑click now on the first packet and select Follow, HTTP Stream.
Here is the HTTP request response.
There is a URI length of one, just a /, the request method is GET,
and the hostname is api.ipfi.org.
When writing rules, or even looking to modify an existing rule,
it is common to begin by looking at sample traffic via PCAPs
and to use tools like Wireshark to look for unique patterns to
create your rule's content matches.
While this may look straightforward, there is actually a lot to consider.
Often how you can measure the success of your rule is in how well it
detects variations in the activity you're monitoring while also having
very little to no false positive matches.
If you open the links‑helpful‑info.html file on your desktop,
you will see a link to EveBox under Local tools.
It's possible that you don't see any alerts right now.
And why is that?
Well, EveBox is pointing to the service mode logs at var/log/suricata,
and not the temp logs we created from the PCAP that we just ran.
There is a way to run EveBox in what is called oneshot mode
and point it to a temporary log location.
But for right now, we're going to focus on service mode operations.
Going back to a terminal, let's run the suri‑replay script with the demo PCAP.
Since this script is replaying the PCAP to our dummy interface,
Suricata will be processing the traffic in real time.
Part of the script's behavior is also to clear service mode logs for Suricata.
So every time we run this,
it will clear any previous data that was generated to include alerts,
so that it will only see data from the PCAP that we just replayed.
And this will help us to stay focused on just the traffic in
the PCAP that we're currently analyzing.
Going back to EveBox, we can see our external IP lookup alerts.
Alerts that are generated via the replay script will also have
a timestamp from when we replayed the PCAP.
Basic information is also shown such as the message,
source and destination, as well as the relevant protocol.
Clicking on an alert will allow you to see all of the same details
we were just exploring directly from the e‑file,
just now everything is a simple click away.
Let's say we wanted to investigate this alert further,
let's take a step back by clicking on the Flow ID.
Okay, with this flow there isn't anything that really helps us build that
additional context right now. We already looked at the content from the HTTP
request that generated the alert in the first place.
So let's remove the flow_id as a search filter and look at other HTTP
requests. To do this, we'll delete the value in the filter box,
click on the Events menu, and then select HTTP. Okay,
now it's getting a little more interesting, in that we have
not only our IP lookup, but after that, we have a POST
request to a .ru top‑level domain.
This is definitely starting to look a little more suspicious.
A quick check on abuse.ch's ThreatFox shows it is an IOC
related to Hancitor. Well, if this was real, our day would
have just taken a turn for the worse.
I would encourage you to spend some time with EveBox at this point, as it
has an easy and intuitive interface. From the Inbox,
you can archive alerts, which is essentially saying you do not
need to take any further action on them.
You can also escalate them, which would indicate an investigation is warranted.
There could be a number of reasons that you'd want to do this.
Maybe you're seeing a rule generate a lot of false
positives, or perhaps there is an alert indicating a
misconfiguration in your environment.
It's important to realize that alerts are not just for malicious traffic,
they can be used to draw your attention to a wide variety of
events in your network. From the Events page,
you can explore all of the metadata that Suricata generates by protocol.
Event records will be listed and just like we did with alerts,
you can click into them,
explore the content, and quickly pivot off of data that is of interest to you.
There is also a time filter.
This will always keep the data you're seeing limited to the time span
selected here. In a training instance like this,
it is usually fine to select All, as it's easy to forget this filter exists and
you think you're missing data, when in fact, it was just filtered out. And
finally, there is the search or filter box. To get an idea of the syntax, I
think the easiest way is to just click on properties on the data and see how it
is populated in the filter box.
We did this when we dug deeper into the alert through the flow ID, but any
field that provides a hyperlink will also behave the same.
So let's recap.
Now you know two ways to investigate Suricata data directly
from the eve.json file or with EveBox.
I'll be using both as we progress through the course.
You also have a better idea of how rules work,
how to investigate them, and this helps set the stage for our next discussion,
which will be how to begin to fine tune what data Suricata generates.