While Zabbix and Netdata and other similar applications focus on devices, networking uptimes, bandwidth and other things, Wazuh focus on protecting your network from attacks by keeping malware databases updated and scanning for attack vectors, protecting endpoints, malware hunting, XDR … a lot more. Wazuh may also need agents installed on your devices to function properly.
WAZUH contributes to Open Source Security extending capabilities and functionality through the integration of new modules, resulting an extremely powerful host IDS. Find how OSSEC helps with PCI DSS compliance, protect your cloud environment or just secure your system
Some may say that Zabbix (?) or Nagios can also be security solutions, by implementing reverse proxy and other protective tech, but as far as I have seen it is still not really the same. IPFire can also have an IDS running, in fact I think most do, and you can do many things with the Firewall to detect and prevent intrusions, but it is not an “AntiMalware” app.
Alternatives to Wazuh could be Comodo EDR also branded as Xcitium I think.
I had Wazuh installed a few days, but I was mistaken in considering it a Monitoring system, so I threw it out, will give it another shot if someone is willing to brainstorm it with me bit… looking at you @ummeegge , and others.
Questions that may be relevant:
Is this a good security complement to IPFire?
Can it be installed on the IPFire device itself?
Is it even what it says?
Can you install it easily?
So, over the next couple of weeks perhaps we may find out, or maybe someone already has these answers and more…?
Installed Wazuh on Ubuntu 22.04.3 LTS.
No docker or anything, just the wget straight on, it does an excellent job at that.
I find the Docker setup rather complex for my experience with docker, so for now skipping it. Available at 192.168.1.12:443
Registered an agent, my desktop, from the Agent interface. Wazuh does not seem to have support for Android or IOS, so that is a bit of a bummer.
Run as Administrator (this is a custom script per agent):
PowerShell 7.4.0
PS C:\Windows\System32> Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.0-1.msi -OutFile ${env.tmp}\wazuh-agent; msiexec.exe /i ${env.tmp}\wazuh-agent /q WAZUH_MANAGER='192.168.1.12' WAZUH_AGENT_NAME='WRM' WAZUH_REGISTRATION_SERVER='192.168.1.12'
PS C:\Windows\System32> net start WazuhSvc
The Wazuh service is starting.
The Wazuh service was started successfully.
and I will just leave it a bit to see what happens
You listed pretty much of the possibilities of Wazuh whereby some features like e.g. System Auditing (relays on Auditd) or OpenSCAP does not work since it is not available on IPFire. The Security Events, Integrity Monitoring, SCA, MITRE ATT&CK and FIM, are working out of the box but Auditing and Policy Monitoring works partly (no CIS-CAT, OpenSCAP since as mentioned not available on IPFire).
In “Regulatory Compliance” section PCI DSS, GDPR, HIPPA, NIST 800-53 and TSC are working.
There is a ROOTKIT detection, Active-Response which can triggers other processes like e.g. FW rules if specifics are happening and this for specific time, IPs, etc. and can be configured via XML and is also disabled per default. Email alerts, reports own visualizations and Dashboards (via ELK-Stack), Snapshot Management, Notifications, …, are of course possible.
Wazuh works with a so called "Rule Classification " so a granularity from 0 to 16 gives a better overview of what kind of event are happening and how to deal with them.
Writing your own decoders and rules might be a working aspect to understand how it works but should also be fairly easy after a little time to understand (XML).
Did i forgot something, for sure so there is more but for the first…
I would say non of them are really comparable since we speak mainly about a SIEM so candidates like “AlienVault”, “Sagan”, “OSSEC” are more familiar with this kind of information and event processing.
Is this a good security complement to IPFire? →
I like it but would like to bring on some IPFire specs into the rules and decoder world of Wazuh. Wazuh hosts also some OPNsense, pfsense and e.g. OpenWRT specific rulesets and decoders on Github so it might be an idea to find some for IPFire but not only …
Can it be installed on the IPFire device itself? →
As @tphz pointed it above out (but deleted it) an “Agentless” integration is possible but i made an IPFire package via IPFire development environment as Adolf pointed it out.
Is it even what it says? →
Until now YES.
Can you install it easily? →
Meanwhile yes but if the IPFire package is in usage, it is not for productive systems. LFS, PAKS, ROOTFILE, CONF files are available to build it by your own if wanted…
So for the first a little overview after the first look into from my side.
Best,
Erik
EDIT: The Wazuh agent is also not that resource expensive →
The biggest problem I see when these types of packages are highlighted is that no one ever comes forward and says that they will be the owner of that package in IPFire and make sure that it is kept updated, deal with any backwards compatibility issues and any bugs that are identified.
An example of what we don’t want to happen is icinga. It is curently on version 1.11.4 which was released in 2014.
The version 1.x branch is no longer supported by icinga and 1.14.2 was the last version in 2017. The 1.x branch went EOL at the end of 2018.
There is no reference to the version 1 series on the icinga website and it is archived on the github site.
The version 2.x branch was released in 2014 and is a complete re-write. There have been the occasional request on the forum to upgrade icinga to the 2.x branch but no one who is an interested user has been willing to come forward and pick it up as the owner.
The other aspect that the devs will not be keen on is having another addon package that is only configured from the command line and not the WUI.
So if someone wants to have wazuh as an IPFire package by all means go ahead but make sure that you commit to maintaining and supporting it and also to defining a WUI page for configuring it on IPFire.
Having it as PakFire is probably only relevant after IPFire version 3 and implementation of SystemD. (Weird words from me, I don’t really know what I am talking about, but you mentioned it )
So, for now, I am only using it as some kind of additional protection layer, that will not scan the IPFire machine, but the rest of Linux/Windows devices on my Network.
With scores like this I do have a lot to check up, and I doubt half is relevant outside of a corporate environment.
Hello @bonnietwin,
as you may have read, there is an agentless configuration possible so no need for additional packages also, there is no package distributed in here but an offer to build it by your own to test it so the maintaining, update and WUI problem does appear by whom who wants to build it by itself.
Spoken about the WUI for an Wazuh agent, except configuring an Manager IP address and importing the key nothing needs to be done on agent side since all configuration can be handled via Wazuh manager which does have a WUI.
Since Wazuh provides agent package generation possibility for all widely know OS´s it might be an idea to check them, i currently do so too.
Some false positives appears surely but if some positives are hiding behind it, it might be worth it.
Best,
Erik
P.S.: Pakfire is the package manager for IPFire which already delivers all installed addons as an *.ipfire package.
P.S.1: Nothing in here is Systemd or IPFire-3.x related, so it is purely OT!
From what I read, the agentless configuration requires you to give it ssh access to the IPFire system so it can run the commands that it requires to collect the data.
I think it is important to know which commands will be run and to understand what those commands will do and then to adjust the ssh config to only allow those commands to be run.
I did not read enough of the link to understand what level of ssh access the agentless approach will use/require.
Yes this is true the agentless access needs SSH. For myself it is not crucial since i do not use the agentless configuration but my self compiled agent package and there is a lot to check too. I think it might be crucial for those who wants to use it and the documentation lines them out and you can check them via Wazuh manager since the scripts are also located in there.
In general, all should be checked and executed on testing environments but understanding all of it might be a same complex task like understanding all commands in Zabbix, Observium or Nagios whereby it seems that understanding only the configuration itself does also needs a lot of time for some users and spoken about WUI´s i think the first two lacks there also with CGIs doesn´t they ?
According to Icinga, i think Michael build it long time ago for what purpose i really do not remember but may the maintaining is EOL so why it should be kept i don´t know but you can ask may Michael ?
…
)