Check if individual systemd services are down (like firewalld)?

Hi All,

This is my first post! The security team is wondering if I can set an alert to see if the firewalld service is started or stopped on a RHEL server. They want to be able to tell if the local firewall is stopped on any of the Linux servers. Is this possible (I wasn’t able to find a similar thread in the forum)?

Thank you!

1 Like

Hi @davevad and welcome to the checkmk community.

For this purpose you can use the process monitoring. There are several rules you can come around with depending on your needs. I suppose you want to ensure that on any linux host the service or process is running so i would recommend a manual check instead of an inventorized.
Depending on your checkmk version the configuration is sligthely different but in general you need the rule State and count of processes.
To ensure that a process is running your rule parameters would look similar like the following picture. Your thresholds need to be set to exactly one process or more, if it’s possible that your process is active more than once.

1 Like

IMHO systemd single services are better suited to check if a systemd service unit is still active.

But for the firewall case I would check against a known list of rules if the current firewall rules are still the same. Firewalld may be running but the rules may be wide open nevertheless.

There is a (rudimentary) agent plugin mk_iptables available that does this for iptables IPv4 rules.

1 Like

Thank you both for your swift replies! I will test these out and get back to you with how it went.

Note that firewalld is an abstraction, and while it was originally based around iptables, on newer hosts it will use nftables, but the idea is that you’re not really supposed to know/care.

1 Like

Yes, I know. But the concept is still the same.

If it is important to you that the firewall does what it should do you need to check the current ruleset against a known good one. And not only check if a firewalld service is running.

If you care about the security of the system you should know what firewalld is doing. Or not use firewalld at all IMHO.

Trying to correctly interpret iptables/nftable rules would be very very very difficult. Like, parsing natural language difficult (well, maybe not that hard, but sufficiently hard and time consuming and likely highly error prone). Do not assume that the chains presented are the same (because they are not) between any given platform. With that said, if you are using a “tool” to produce the rules, that tool could ensure restrictions that might lead to something that could be evaluated, but the assumption would be that the “tool” produces a clear uniform restricted ordered subset of firewall rules so that they could be parsed and made sense of. Even then, there’s so many other variables that means (even) what appears to be the same set of rules could perform differently based on the underlying device configurations. In short, it’s a good idea, but just not practical.

When you have a known good ruleset you save it with nft list ruleset. After that you can compare the stored ruleset against the current working ruleset every time the agent is called. No need to interpret anything.

Write the check for us.

Hi All,

First off, thank you to everyone who responded and offered suggestions. I am VERY new to checkmk. I think I have things working properly. I also forgot to state that I am using checkmk Raw. I first navigated to Setup > Services > Service monitoring rules > Systemd Services Summary where I configured the rule like so:

Screen Shot 2021-11-15 at 13.27.47

Which gave me the alert that I needed. However, will this affect alerting/notification for other systemd issues?

Thank you!
David

No, this way you ignore every other service.

Go to the Service Discovery Rules and the to the ruleset Single Systemd Service Discovery.

With this you create a new service check that monitors a specific systemd unit.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.