Where you place your sensor is of vital importance,
as it will determine what traffic you're actually monitoring.
Let's now discuss placement and capture methods.
Knowing where to place your sensors begins with knowing your network,
Who are you protecting?
What activity should you expect from your users?
When are they most active?
How is your network segmented?
This also extends to the type of systems they use.
Is it all Windows, or is there a mixture of Linux and Apple?
What type of data do your users typically handle?
Is it something sensitive like healthcare information, or something more benign?
In any case, it is your goal to protect not only your users,
but any customers you may have.
What are you defending?
This expands upon what user activity you should expect and
includes what are the actual servers?
What services do they provide?
You should take note of what is most critical in your environment.
It's possible that you can't defend everything,
at least to start, but can prioritize on critical systems and users.
Where do all of your users and infrastructure reside?
Do users VPN in?
If so, do you want to monitor their traffic?
What about the use of cloud‑based services such as AWS?
Those change your ability to see all of your traffic,
and in fact, really require a completely different conversation.
What about network segments?
If you place a sensor in one segment,
it may not be able to see traffic in another.
When is everything used?
This ties back to user activity.
When you can expect certain behaviors and when you see
maybe someone accessing a server at 3 a.m.
in the morning versus 3 p.m.
in the afternoon, you can begin to identify abnormal patterns.
Finally, how is everything used?
From user activity to customer data,
it all needs to come together to see the full picture of your network,
and from there, determine how to place sensors to get maximum coverage.
As you might have guessed,
there is a balance that you're trying to strike between the
resources that you are trying to protect,
and your ability to handle the deployment of these sensors,
as well as the ability of your security team to properly handle
the volume of alert and other data generated,
to ensure the efficacy of your defensive efforts.
The last thing you want is for there to be too much data generated,
or an ineffective process for handling it that leads to
indicators of a compromise that get ignored.
Sensors are commonly placed on the internet link,
watching traffic coming in and out, or north and south,
as it is commonly referred to, on the path from servers to other networks,
with the idea that the servers are critical infrastructure and
should have a high priority in terms of monitoring.
This is part of monitoring your internal traffic or east/west.
This is also very important and should not be overlooked.
On the path from clients to the internet,
users are one of the most common vectors that are attacked
as a way to get malware inside a network,
so monitoring their activity is a very common task.
Suricata has two main modes of operation, IDS and IPS mode.
Each of these modes can provide you different types of capture methods,
which can be determined by your operating system,
and in the case of IPS mode, the type of deployment being done.
On Linux, you'll primarily be using AF_Packet for IDS mode.
However, PF_Ring, NETMAP, and Libpcap are other options.
In IPS mode on Linux, you will need to use either Netfilter or AF_Packet,
as capture methods like Libpcap do not support IPS mode.
Another operating system such as FreeBSD,
you'll probably be looking at NETMAP or Libpcap for IDS mode,
and IPFW or NETMAP for IPS mode.
For special requirements, typically high performance,
there are some vendors that provide specialized capture cards.
These may or may not provide IPS mode,
but you'll have to talk to the vendor about your requirements.
We haven't discussed physical versus virtual sensor deployments yet,
and yet again, there are tradeoffs as to which one you would choose.
With virtual,
it provides a lot of flexibility, in that you don't need to
hassle with physically racking a server.
Virtual deployments are often easier to manage, back up, and restore.
The main drawbacks are that you may not have full control over the VM host,
and that virtualization settings can interfere with capturing sniffing traffic.
Since there are a wide variety of virtualization options,
it can be difficult to provide a list of best practices,
which can add to the complication of a virtual‑based deployment.
Hardware deployments have some significant pros.
First, you typically have full control over the server you are setting up.
The servers are typically dedicated for the deployment,
whereas a virtual host may be providing virtual machines for other purposes,
and physical deployments provide the best performance and should
certainly be considered if you're managing a busy network.
The drawbacks are what you might expect.
There is more overhead in having to deal with physical hardware,
going on site to set up, possibly even needing physical access.
Hardware resources are more difficult to adjust on the fly.
Need more memory?
Well, you may have to order more RAM, then go on site to install.
Now you may be asking yourself, what operating system is best?
Surprise!
It depends.
Suricata is natively developed on Linux and mostly tested on Linux,
so starting with a Linux OS is usually a good choice.
Suricata does run on Windows,
but there is less support for that mode of deployment overall. I said it
depends. Well, what OS can depend on, corporate policy.
Perhaps your organization only allows certain Linux
distributions. You may also choose a Linux OS based on what
you or your team is most comfortable with.
So there isn't a best OS that we can recommend,
but rather provide these general guidelines to help you make that
determination yourself. Monitoring encrypted traffic will require special
attention as well. Encryption is becoming more and more prevalent, not only
for inbound/outbound traffic, but for systems communicating internally on
the network. With encrypted traffic, the entire idea is to keep the contents
of the conversation private,
which means that by default, Suricata has no special
ability to peek into this data.
There are many vendors that provide solutions for inspecting encrypted traffic.
The idea behind these solutions is that endpoints establish a secure
connection to these devices, which then provide the decrypted traffic to a
monitoring device, like Suricata, before establishing a new secure
connection with the other device the client wants to communicate with.
When the need to monitor encrypted traffic is present, where you place
Suricata is key, as it must see the decrypted traffic from the device
performing this task.
However,
Suricata can still monitor encrypted sessions and provide
information about those sessions such as flow data,
information about the TLS session, as well as
information from the TLS certificate.
This still provides an opportunity to generate alerts, as well as
monitor secure connections for abnormalities.
Keeping Suricata up to date is also an important aspect
of managing your Suricata deployments.
Suricata is updated regularly for feature and
performance enhancements, bug fixes, and yes,
on occasion, even security issues. With most operating systems,
you'll be able to use the native package manager such as apt or yum.
Running an update upgrade is usually all that is required.
If you've made modifications to your configuration file,
the upgrade will usually ask if you want to keep it or use the new version.
It is best to use the latest version and apply any changes you made from the
previous YAML. As we've discussed throughout the course, keeping your system
and Suricata up to date is a good idea, but it can bring with it changes to
drivers and other aspects of the OS, so it's best to test these upgrades
before rolling them out to production systems, as it could lead to downtime
due to unexpected upgrade issues. And in line with that previous warning, it
is really best to maintain test or QA systems for these purposes.
Don't forget though,
you may also want to ensure that the OS is still performing as
expected, Suricata is operational, and all of your log management
and handling is still functioning.
You will also want to ensure that any dashboards,
visualizations that you use, have not broken.
So there is a lot to consider, and we recommend having a
checklist or playbook for handling the upgrade process, as
well as verifying that it was a success.
Now that we've considered how to deploy Suricata,
let's turn our attention back to rules and get into more detail
about managing rules in your environment.