Bug 237900 - [NEW PORT] security/wazuh-agent: Security tool to monitor and check logs and intrusions
Summary: [NEW PORT] security/wazuh-agent: Security tool to monitor and check logs and ...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Bernhard Froehlich
Keywords: feature, needs-qa
Depends on:
Reported: 2019-05-14 19:56 UTC by Michael Muenz
Modified: 2019-09-13 07:55 UTC (History)
3 users (show)

See Also:
koobs: maintainer-feedback+

shar (7.79 KB, text/plain)
2019-05-14 19:56 UTC, Michael Muenz
no flags Details
wazuh 3.9.2 (17.66 KB, text/plain)
2019-06-27 10:22 UTC, Michael Muenz
no flags Details
wazuh 3.9.2 cleanup (12.93 KB, text/plain)
2019-06-28 05:15 UTC, Michael Muenz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Muenz 2019-05-14 19:56:50 UTC
Created attachment 204379 [details]


wazuh is a fork of ossec. This is a port for the agent itself. 

I added a patch for no detecting FreeBSD as it would a startup command into rc.local. 

There is no configure style component, only an interactive install.sh script which can be automated via preloaded vars (also patched).

As this is my second maintained port better look twice if everything is ok :)

Comment 1 Bernhard Froehlich freebsd_committer 2019-05-14 19:59:17 UTC
I'll take it.
Comment 2 Michael Muenz 2019-06-27 10:22:22 UTC
Created attachment 205371 [details]
wazuh 3.9.2
Comment 3 Michael Muenz 2019-06-27 10:23:48 UTC
I updated the port to 3.9.2, removed unused patches, cleaned all critical warnings from portlint -A and also poudriere error are gone.

Tested the compiled port fine here on a FreeBSD 11.2.
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2019-06-27 12:59:09 UTC
Hi Michael,

Some review items/questions:

1) Why does this fetch dependency tarballs and build using those rather than depending on and building against port versions?

2) Is it possible to use environment variables, passed into MAKE_ENV (or otherwise, to set/configure the various build/install variables in etc/preloaded-vars.conf instead of hardcoding them?

If not, it might still be worth instead, echo'ing the appropriate lines into the file, rather than patching it. This would mean that configuration lives in the port Makefile rather than a patch, and changing those configuration directives, manually or dynamically later, much easier

3) Having all the packages files live under its own single directory in /var/ossec is not appropriate for the vast majority of ports. Ports/packages should be installed respecting hier(7) (see man7 heir)

Note: (1) and (3) are pretty important issues fundamental to the way we port things.
Comment 5 Michael Muenz 2019-06-27 13:12:26 UTC
Hi Kubilay,

Thanks for taking the time to review!

1) Wazuh sadly uses patched versions so they offer their own ones. 

2) I need a second look at this, Wazuh uses a big blob install.sh script and I took most logic out of it to don't get stage violations. Maybe the patch can also be removed completely since the guided install script isn't used.

3) Wazuh is a fork of ossec and most of the scripts uses hardcoded path's. In my first shar I tried to implement via /usr/local/wazuh but most of the scripts inside wont work. There's also a ticket at GH but progress is slow: https://github.com/wazuh/wazuh/issues/785

Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2019-06-27 13:43:17 UTC
(In reply to Michael Muenz from comment #5)

My pleasure Michael,

On balance, given ossec is in the tree with the same issues, I suppose we can give this a pass, but at least for (3) we may want to put it in /usr/local/<foo> where other ports/packages that have the same issue put their hierarchies. At least its then consistently inconsistent.

Lastly, we'll want to let upstream know in as encouraging terms as possible that it would be great to be able to easily put different things (bin files, docs, run time data, configuration) in different places, and dynamically modify the build (though we can get by with echo'ing build parameters to a file for now)
Comment 7 Michael Muenz 2019-06-28 05:15:28 UTC
Created attachment 205389 [details]
wazuh 3.9.2 cleanup
Comment 8 Michael Muenz 2019-06-28 05:23:07 UTC
Hi Kubilay,

I deleted all patches since install.sh isn't called anymore, they are not needed. In addition I added second copy job for ossec.conf.sample. Regarding 3) I'm constantly talking to the dev's via Slack Channel. I know, not the best method to share knowledge, not a fan of this thing. If you have an account there I can share you the link or send a screenshot of discussion (when needed).

Thanks for your time!

Comment 9 commit-hook freebsd_committer 2019-09-13 07:46:19 UTC
A commit references this bug:

Author: decke
Date: Fri Sep 13 07:45:38 UTC 2019
New revision: 511915
URL: https://svnweb.freebsd.org/changeset/ports/511915

  The Wazuh agent runs on the hosts that you want to monitor.
  It is multi-platform and provides the following capabilities:

  - Log and data collection
  - File integrity monitoring
  - Rootkit and malware detection
  - Security policy monitoring.
  - Configuration assessments
  - Software inventory

  In addition, it communicates with the Wazuh manager, sending data in near
  real-time through an encrypted and authenticated channel.

  WWW: https://github.com/wazuh/wazuh

  PR:		237900
  Submitted by:	Michael Muenz <m.muenz@gmail.com>

Comment 10 Bernhard Froehlich freebsd_committer 2019-09-13 07:55:36 UTC
Thanks a lot for your contribution and sorry, that it took so long to get it into the tree.

I have updated the port to the latest patch release 3.9.5 and added one patch to fix a build error on 12.0/amd64. It is more like a hack and could probably be fixed in a better way.

  LINK    libwazuh.a
    RANLIB  libwazuh.a
    CC      libwazuhext.so
/usr/bin/ld: error: can't create dynamic relocation R_X86_64_32 against local symbol in readonly segment; recompile object files with -fPIC
>>> defined in external/openssl/libssl.a(bio_ssl.o)
>>> referenced by bio_ssl.c
>>>               bio_ssl.o:(BIO_f_ssl) in archive external/openssl/libssl.a

Another build error that I noticed was with hardcoded perl paths so I added a post-patch target.