So far, we've discussed Suricata basics and core functions.
This has given you a solid understanding of what Suricata does,
along with the data it generates.
Now it's time to discuss deploying Suricata into your networks.
Let's start with a quick review.
Capabilities that are important to keep in mind as you're
planning to deploy Suricata into your networks.
First, Suricata uses a YAML file for configuration,
which aligns with many popular projects.
This makes it easy to change how Suricata behaves.
It also produces output in JSON format,
which makes for integrations such as with an Elastic Stack much easier.
Suricata is multithreaded to help with performance.
In high traffic networks, you can also look into hardware acceleration.
There is native IPv6 support and auto‑protocol detection,
which makes identifying traffic easier.
For example, Suricata can detect a TLS session,
regardless of what port it is over.
As you've seen with Suricata output, as well as in the rule syntax,
it has advanced support for application layer protocols,
such as HTTP, HTTP/2, DNS, SMTP, TLS, and many more.
Suricata can perform file extraction on live network traffic
over a variety of supported protocols, such as HTTP and SMB.
This is in addition to Suricata's ability to identify
and produce file information events,
which includes such information as file magic and the file hash.
Netflow output is also available, although it is disabled by default.
To continue our capabilities review,
Suricata is extensible through Lua scripting,
which provides you with the ability to add more complex
logic to your network inspection.
Suricata can utilize IP lists for blocking, based on reputation or geolocation.
Bypass rules are also available.
These deal with large flows, also known as elephant flows,
such as streaming services.
Why waste precious compute time on the latest episode of the Mandalorian?
Community ID is an emerging industry standard for
correlating data between different tools,
such as Suricata and Zeek logs.
JA3/JA3S hashes can be produced to provide a fingerprint from TLS sessions.
This can allow you to apply rules based on these hashes,
as well as hunt in your network traffic.
Suricata is continuously expanding SCADA protocol support and provides the
ability to record your network traffic via full packet capture.
And those are the main features.
There is more detailed than the online documentation.
Let's now turn our attention to modes of operation.
Network security monitoring is an approach to collecting network
traffic to provide immediate alerting and long‑term analysis
through visualizations and other tools that can provide insight
into the data generated.
Even with the growing use of TLS,
monitoring your network is key to understand what is happening on your systems.
Suricata plays a key role in developing an effective
approach to network security monitoring.
While this can be accomplished with a single Suricata sensor,
due to how your network is laid out,
it often requires multiple sensors to get the coverage you need.
You also have to consider what to do with the logs.
Do you leave them on the sensor and analyze them there or ship them to a
central server for aggregation and later analysis?
We'll touch on common deployment scenarios in this module to include
how to integrate Suricata within Elastic Stack.
Hopefully by now, you can finish these next few rules before I do.
Suricata will generate for you logs that contain events,
metadata and protocol information, and alerts.
Keep in mind that exactly what data is generated is ultimately up to.
Don't need alerts?
You can disable those entirely.
You can look at network security monitoring from two perspectives.
The first is proactive.
The data you are collecting allows you to perform threat hunting to
periodically go looking for potential malicious activity in your
network or even try to identify misconfigurations or other issues
that could cause performance issues.
You can also look at it as a reactive capability.
Let's say you get an alert from your antivirus on an endpoint.
Being able to look back into your network activity can help
you identify key aspects of the attack and generate
valuable indicators of compromise.
So what do you need for a complete NSM solution?
Well, first up, you'll need full packet capture.
This gives you historical perspective.
Usually,
the main limit with implementing full packet
capture is how much storage you have.
If you have a busy network,
you can generate gigabytes or even terabytes of network traffic daily,
and this requires some serious storage.
You can calculate how much traffic you generate on average and use
that as a guide to determine your storage needs,
based on how far back you want to be able to see.
Of course, there's network monitoring, which is done with Suricata,
and while Suricata has you covered on the network,
what about what is happening on the host?
For example, process activity can reveal a lot,
but just like network traffic, if you don't capture it,
then you have no way of knowing exactly what occurred.
Endpoint detection and response, or EDR,
gives you an ability to not only capture this
information but then to query systems live,
to isolate systems, pull system information on demand,
and interact with them from a central vantage point in
your security operations center.
Gathering all of this data is the next major concern.
As an open source project,
the Elastic Stack provides pretty much everything you need to accomplish this.
Elasticsearch for data storage and analysis,
Kibana for visualizations and dashboards,
Logstash and various Beats for data normalization and shipping.
Of course, there are also commercial alternatives,
such as Splunk, and a wide variety of other projects to consider.
If you're not sure, we suggest starting with the Elastic Stack.
And finally, there are many,
many tools available to further help you wrangle your network traffic,
such as EveBox and Arkime.
While we use EveBox in this course, we won't touch on Arkime.
It's definitely worth taking a look at it though,
as it's another amazing open source project.
So now that we've covered some deployment considerations,
and throughout this course you've had time to give thought to
what data you want to generate and collect,
we can now focus on specific modes of operation for Suricata.
Intrusion detection mode, or IDS,
is one of the most common ways to deploy Suricata.
It is completely passive.
That means there's almost no impact to your network
traffic or systems on your network.
Suricata is fed network traffic from a span or tap and is then
only limited by the hardware it is running on.
If your Suricata sensor runs out of resources,
it will begin to slow down, possibly even dropping packets.
However, traffic on your network will continue to flow as it would normally.
The primary drawback to this mode of operation is that
it provides no direct protection.
It can generate alerts, but it won't block any traffic.
Have a malicious office document, downloading a Trojan from a compromised server?
Sure, Suricata may generate alerts,
but the payload won't be stopped from being downloaded.
While our focus has been on the technical elements of deploying Suricata,
there is also an organizational impact.
Mainly, you have to have processes developed to monitor alerts.
Process the alert to determine severity of the potential
incident and then respond accordingly.
If no one is watching your data, how will you know what is going on?
There is also a learning curve when deploying Suricata for the first time.
It will generate a lot of data.
Knowing how to begin to process and fine tune your
setup is key to turning it into a lean, mean network monitoring machine.
Some other benefits with IDS mode is that it helps to
determine how exposed you are as an organization.
It will improve your visibility into your network,
which will increase your knowledge and help you to better
understand where you may have weaknesses or exposures.
It can also help detect attacks, in progress, failed, and previously undetected.
From an adversarial perspective,
it can be very difficult to detect an IDS on the network.
In a passive mode,
it provides less opportunity for them to be able to probe the
sensor directly or through the traffic that they're
intentionally generating on your network.
Intrusion prevention system mode, or IPS,
is very similar to IDS mode, with one key distinction.
Suricata can be instructed to block certain network traffic.
This is primarily done by changing rules from alert to drop or reject.
One other key distinction is in how Suricata is deployed.
It has to be in line with the traffic, not passively on the side.
This means that all network traffic will have to pass through
Suricata on its way around your network,
and Suricata can become a bottleneck if not given proper resources.
IPS mode still provides an ability to detect attacks.
It just goes one step further and blocks traffic.
And similar to IDS mode, this can result in an increase in your reaction time.
You will have the same visibility into your network,
which can help increase your knowledge.
Everything you are used to Suricata generating is still there.
Attack detection is also similar,
just that there is an increased chance that Suricata prevented the
attack instead of listening and alerting in passive mode.
And while this may sound appealing, IPS mode does come with its challenges.
It is much harder to set up.
Since you are now blocking traffic,
it's possible that you can disrupt legitimate communication on your network.
IPS mode requires a thorough and complete understanding of your network,
at least to the extent that that can be attained.
If you're working on a new deployment,
IDS mode is usually the best place to start,
as you learn not only how Suricata works but also your own networks.
Once you are ready to attempt IPS mode,
it's common to validate before moving to production.
This could be done with a QA instance of Suricata and a pcap from your network.
This would have no direct impact to your production network
but still allow you to test your exact configuration and
setup on your network traffic.
Hybrid modes are also available.
This allows you to get some of the benefits of both of
the previous modes we discussed.
You can deploy Suricata as an IDS,
and since it has the ability to reset connections by sending reset packets,
it can block certain connection attempts.
As with IPS mode, Suricata has to be deployed in line,
so ensuring high throughput in your network will be vital.
For this mode to be engaged, you have to change alert rules to reject rules.
This can be done through rural management tools such as suricata‑update.
There really are many ways to deploy Suricata.
For example, as an IDS with NSM capabilities.
This would give you alerts plus metadata.
You can deploy Suricata as an IPS, along with NSM capabilities,
or you could just deploy it in IDS or IPS mode without NSM capabilities.
And don't forget, once the traffic is gone,
it's gone,
so consider full packet capture to have full fidelity
of what occurs on your network.
You can mix and match.
It's up to you to ultimately decide what you need.
Let's now take a look at a possible deployment scenario using the Elastic Stack.
You first have to determine what mode of operation you want Suricata to run in.
This will determine how you get your network traffic.
You also have to identify, based on your network layout,
what part of your network you want to monitor.
Once Suricata has the network traffic,
it uses rules to generate alerts or bypass elephant flows.
These will come from external or internal rules sources.
Suricata then generates output in JSON format,
which can be picked up by a log shipper, such as Filebeat from Elastic.
Filebeats can ship data to Logstash for further normalization and/or
enrichment or directly to Elasticsearch. Finally,
Kibana can be used to search and visualize your data,
along with other tools, such as EveBox, helping you to operationalize it,
monitor your environment, and react when issues arise.
Here's a similar example, except we'll replace the Elastic Stack with Splunk.
You'll see it's very similar to what we previously discussed.
The main difference is that Splunk is utilized for data storage,
searchability, and, ultimately, visualizations.
We've discussed mode of operations.
Now, let's look at network placement and capture methods.