Open ijaketak opened 1 year ago
I think it would be beneficial to have it set up as a service right? Especially for managing multiple servers.
I'm imagining something like this for agents:
{
services.wazuh = {
type = "agent";
manager = "10.10.13.37";
};
}
And likewise for managers:
{
services.wazuh = {
type = "manager";
settings = {
....
};
};
}
I don't have a whole lot of experience packaging stuff for nix yet, but will try and play around with it when i find the time as it a software suite i would love in my homelab. If anyone with more experience packaging stuff for nix, that would either take the lead or be a sparring partner for a newcomer it would be very appriciated.
@c3lphie
It would be interesting. Do you still intend to proceed with packaging?
I can definetly try and give it a shot. I have like zero experience as i said so help would be more than apreciated
I'm in the same boat as c3lphie. I would like to contribute, but might need some guidance on where to look for instruction.
For anyone in the NixOS wilderness who's still interested, my attempt at trying to get the agent working is here: https://github.com/V3ntus/nixpkgs/blob/wazuh-agent/pkgs/tools/security/wazuh/default.nix
I am but a beginner as well though. Main issues at hand:
install.sh
needs to be run as root: Either we eliminate install.sh
and manage the installation and build manually, or maybe there's some weird way to give it "root" accessconfigurePhase
needs to not be hardcoded and should be given service options. But this is the baseline to get install.sh
to run headlessMainly just a TODO note for me, but maybe it's possible to use buildFHSEnv
while installing?
@V3ntus I was able to take some of what you have here and I've got my own fork here: https://github.com/sjdwhiting/nixpkgs/blob/master/pkgs/tools/security/wazuh/default.nix
Couple of notes
install.sh
to run using fakeroot
but...install.sh
as is will work very well. I've tried a few times and I think it will be easier to complile everything and essentially handle it manually. make deps
which was pretty error prone and I think this is the more nix
way of doing things. (pretty new to Nix so open to feedback here!)The biggest issue I'm running into now is various times when make
or other scripts that get called in the process want to manipulate files and it is blocked from doing so. Here is the latest example
make[1]: Leaving directory '/nix/store/xb5hbjld2gpi1jf3f06mwpw85klbdagq-wazuh-agent-4.7.3/src/external/libarchive'
cp /nix/store/a3zlvnswi1p8cg7i9w4lpnvaankc7dxx-gcc-12.3.0-lib/lib/libstdc++.so.6 libstdc++.so.6
strip -x libstdc++.so.6
/nix/store/3z013mdl9cvpgvavpj19rbilihz4clvi-binutils-2.40/bin/strip: unable to copy file 'libstdc++.so.6'; reason: Permission denied
make: *** [Makefile:775: libstdc++.so.6] Error 1
error: builder for '/nix/store/ydqi49bbi2hmsnd5zhr25xfvjqah0an4-wazuh-agent-4.7.3.drv' failed with exit code 2;
last 10 log lines:
> CCLD bsdcpio
> CC cat/bsdcat-bsdcat.o
> CC cat/bsdcat-cmdline.o
> CCLD bsdcat
> make[2]: Leaving directory '/nix/store/xb5hbjld2gpi1jf3f06mwpw85klbdagq-wazuh-agent-4.7.3/src/external/libarchive'
> make[1]: Leaving directory '/nix/store/xb5hbjld2gpi1jf3f06mwpw85klbdagq-wazuh-agent-4.7.3/src/external/libarchive'
> cp /nix/store/a3zlvnswi1p8cg7i9w4lpnvaankc7dxx-gcc-12.3.0-lib/lib/libstdc++.so.6 libstdc++.so.6
> strip -x libstdc++.so.6
> /nix/store/3z013mdl9cvpgvavpj19rbilihz4clvi-binutils-2.40/bin/strip: unable to copy file 'libstdc++.so.6'; reason: Permission denied
> make: *** [Makefile:775: libstdc++.so.6] Error 1
For full logs, run 'nix-store -l /nix/store/ydqi49bbi2hmsnd5zhr25xfvjqah0an4-wazuh-agent-4.7.3.drv'.```
@sjdwhiting That's awesome! Appreciate your efforts.
Yeah I was starting to come to the conclusion that bypassing install.sh
would be more beneficial than trying to get it to work on Nix. That leaves us with reverse-engineering install.sh
and adapting its operations to the declarative Nix approach. Big respect to who gets that working.
Aside from building wazuh packages from source, I also considered utilizing the .deb
package directly (I've seen some Nix packages install with this method), but again, not sure how that would work mapping FHS to non-FHS directories, linking, etc.
I'll check out your fork, I'm excited to see someone else's approach
I'm also curious about the fakeroot
usage. wazuh, in principle, needs root access for many of it's operations, I would assume. Looking at the Debian docs, looks like fakeroot
is useful for package builds when, for example, one would need to package files with root ownership. If we're installing with fakeroot
, it sounds like the make install
call is deviating away from the Nix environment. Would this interfere with wazuh being installed incorrectly (wrong location, wrong permissions, etc.)?
I don't think there is a need to call make install. I think we can just move everything as needed to the correct directories in the nix store and setup symlinks where needed. For example. /var/ossec/ can be sym linked to the nix store entry.
Wazuh has some notes here on manual install and they make no mention of running make install https://github.com/wazuh/wazuh/blob/master/INSTALL
Update: Sorted out that error I posted, now I'm iterating through fixing similar ones as they come up. I'm just copying the files over in an earlier phase. Worst part is that it is progressing far enough in the build process that my cycle time is a couple of minutes with each fix.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/packaging-wazuh-for-nixos/43124/1
Hi @sjdwhiting @V3ntus I got this working based off your code. Please see the my comment on how to reproduce it. There's still more work to get the agent working into a service, but at least the agent is compiling and executing now.
Awesome, thanks for the work you put in! @nealfennimore
I'm assuming due to the need for sudo
while creating a new user and setting up permissions, the commands in your comment are not present in the postInstall
phase?
I'm assuming due to the need for
sudo
while creating a new user and setting up permissions, the commands in your comment are not present in thepostInstall
phase?
Those commands are just to get it working to iterate on in case anyone wants to do more work on this.
Ownership will probably come in when it's made into a service (see clamav for an example), as I do not believe the build generation has access to the other users/groups other than nixbld
(at least it errored out when I tried to modify).
Curious on opinions of how to approach translating declared options into the ossec.conf
file. ClamAV is a simplistic key value pair while Wazuh utilizes XML [1].
Aside from copying and generating the entire sample ossec.conf
within the nix expression, I'm attempting to explore other ways to go about this. I'm aware there's a toXML
built-in, but the output is way verbose, I don't think it would work. I'm not sure if it would be worth overengineering that process using something like the json2xml
Python tool. Another path to take would just be sed
and replacing the default entries (required/essentials for the agent to function and register). Thoughts?
Sample, default ossec.conf
agent config: https://github.com/wazuh/wazuh/blob/master/etc/ossec-agent.conf
I drafted a WIP module that defines a wazuh-agent service. https://github.com/V3ntus/nixpkgs/commit/9878cd4e196424fe497303d20ef68fe4bfc578e8
I'm not quite sure how to test it, I've set my repo as the only channel, yet I can't get my config to see the service or the package. Probably just my lack of nix knowledge/experience, could also be syntax issues I introduced. I pushed a commit that adds wazuh
to the top-level all-packages.nix
as well as the wazuh-agent
module to module-list.nix
, but I should've read the docs first
Another path to take would just be
sed
and replacing the default entries (required/essentials for the agent to function and register). Thoughts?Sample, default
ossec.conf
agent config: https://github.com/wazuh/wazuh/blob/master/etc/ossec-agent.conf
You might want to use pkgs.writeText and interpolate the config as a string. That should make it easier to append to later
let
ipAddr = "127.0.0.1";
ossecConf = pkgs.writeText "ossec.conf" ''
<ossec_config>
<client>
<server>
<address>${ipAddr}</address>
</server>
<config-profile>debian, debian8</config-profile>
<crypto_method>aes</crypto_method>
</client>
</ossec_config>
'';
@nealfennimore Awesome, I saw your reply on Discourse but I'm just now finding time this weekend to dig into it. @V3ntus Good stuff on getting started on the service.
Glad this is moving forward!
I debugged the service module a bit, can't figure out why it won't start with systemctl:
The env
is needed, else awk
isn't found which is required to discover available wazuh daemons. Couldn't start with /usr/bin/env
either
I got systemd to start wazuh-control
by adding busybox to the path. https://github.com/V3ntus/nixpkgs/blob/1c730ec82af54d22824077448a246916ce18a70d/nixos/modules/services/security/wazuh-agent.nix#L35-L37
systemd says wazuh-execd
did not start:
It technically did though, but I'm assuming it's timed out due to the default config pointing to localhost (?). (I'm aware the PID differs in the below snippet, but it would match the journal log)
# ps aux | grep wazuh-execd
root 1989 0.0 0.0 23812 2804 ? Sl Apr09 0:30 /var/ossec/bin/wazuh-execd
I guess all that's left is writing the configuration from the module
It did enroll itself though (starting it manually), I thought that was cool. Great progress from everyone contributing here!
Nice work @V3ntus! I wonder why that process is exiting. Can you try running the binary manually to see what's happening?
Just FYI for the config stuff there's env variables that can be used to configure the agent
That's my dilemma, running the binaries manually (wazuh-control or wazuh-agentd) returns no errors and runs fine lol. I even did a sed
in ExecPreStart
to append -ddd
extra debug options inside wazuh-control when it launches each daemon, nothing popped up in the logs. Maybe a path issue again, but calling with or without env makes no difference. I'll have to learn more about systemd to debug properly.
Thanks for the env variables lead. I suppose this is more suited to insert before the install phase, I'm just not sure how this works for configuration changes when a user, for example, changes the manager IP after the initial install.
First off great work, I'm working on playing catch up today. I need to get a manager up and running still.
As for the variables, those should ultimately be declared in the service I think and then passed in somehow. Not sure how to make that happen at the moment. But then if you wanted to change the agents configuration, you would be modifying it in your configuration.nix or flake.nix. Something like this which was posted up near the beginning of this thread:
services.wazuh = {
type = "agent";
manager = "10.10.13.37";
};
}```
Options should be pretty simple. Right now we have:
options = {
services.wazuh = {
agent = {
enable = mkEnableOption "Wazuh agent";
# TODO: mkOption -> XML for ossec.conf
};
};
};
The hurdle is interpolating the options into the XML format ossec.conf
but as Neal was saying, probably just easiest to have a copy of the sample config in the nixpkgs
repo next to the module and substitute/interpolate accordingly.
Can we just do the extraConfig
approach and allow people to write in their own and then just append that to ossec.conf during the build?
I agree, that's most likely the best/easiest way to do it. Wazuh does allow more than one <ossec_config>
tag so whatever the user places in extraConfig
should safely override.
Also FYI Wazuh currently does not support collecting logs from journald
(which seems to be nixos's primary way of system logging?), but looks planned in the immediate future https://github.com/wazuh/wazuh/issues/12862
@V3ntus Good to know, thankfully it does look like it might be here soon.
Are you doing anything beyond services.wazuh.agent.enable = true;
to get it running? I'm getting a series of errors about missing attributes going that route. I've sourced your branch in my system's flake.nix for my nixpkgs.
Still trying to get it running, lots of syntax errors (learning the Nix language at the same time 😬 )
FWIW: The way I've been testing it is doing my changes on my M1 Mac in Vscode, pushing to Github, then pulling it to a cloned repo in my UTM NixOS VM then running nixos-rebuild -I nixpkgs=$PWD switch
inside the local repo.
Probably a better idea to do all of this in a NixOS instance without the Mac.
Yea, I'm also on an M1 and I was doing similar. I took some time to setup my backup SSD on my PC as as a dedicated NixOS install.
We should probably start an issue thread on your repo so we can keep this thread saved for big updates.
Good plan, I feel bad for spamming everyone's notifications here.
Moving dev comments to here https://github.com/V3ntus/nixpkgs/issues/1
A working implementation of the wazuh-agent as a systemd service is now in a PR ready for review: #309573
Where did Wazuh Agent wind up? It does not appear in 24.05 when I make a search.
I'm willing to contribute code if there's an existing starting place?
@JackPala mainly waiting for journald support coming in 4.9.0. A beta version was released today so might be worth investigating, I just haven't found time to work on this more https://github.com/wazuh/wazuh/releases/
Project description
Wazuh is a security platform that provides unified XDR and SIEM protection for endpoints and cloud workloads.
Metadata