Whids service crash
xoverride opened this issue · comments
Hey @RickyXwang,
I think beta.6 still suffered from one issue, the service kills itself !
I did some changes since beta.6 regarding that issue, I'll push a new release soon so that you can try it out.
I just hope this is not MS Defender which actually killed it !
Thanks for raising that issue,
Cheers,
Just published a new beta release (https://github.com/0xrawsec/whids/releases/tag/v1.8.0-beta.7), could you please try it out and tell me if the issue is still there ?
Thank in advance,
Hi @qjerome,
I am getting this error with this new beta build when running the Linux manager.
./whids-man-v1.8.0-beta.7-amd64 -h
./whids-man-v1.8.0-beta.7-amd64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./whids-man-v1.8.0-beta.7-amd64)
I believe that my glib version is /usr/lib32/libc.so.6 -> libc-2.33.so
Hi @RickyXwang,
Maybe that is something of the latest go compiler, and maybe due to the machine I compiled it from !
Something you can try is to clone the repo and compile it on your own, it should be pretty straightforward.
# from repository directory
cd utilities/manager
make
Please let me know if that solution solved your issue.
Do you still get the agent stop issue with this new beta ?
Great if the issue you've opened the GH issue for is fixed !
whids.log
only logs agent's functional logs, neither alerts nor the events you want to filter-in.
The other thing you have to know is that a detection get logged:
- if there is at least one rule loaded in the engine to trigger a detection on that event
- if the event got a criticality above "criticality-threshold" configured in the agent configuration. Criticality of the event is defined by the sum of all the rules' criticality matching the event (bounded to 10, the maximum criticality).
In order to investigate the detections (or events filtered-in) there are two ways:
- If the agent is not connected to a manager detection logs are stored inside directory configured in agent's
config.toml
file under item forwarder->logging->dir - If the agent is connected to a manager, which seems to be your case, logs are stored on manager's side and gets deleted from the endpoint as soon as they get sent. You can query those logs, either by using the REST API https://validator.swagger.io/?url=https://raw.githubusercontent.com/0xrawsec/whids/master/doc/admin.openapi.json, or the hardcore way by looking inside the log storage directory (as configured in manager's configuration).
NB: something I did not mentioned ! In order for the agent to work properly the endpoint needs to be rebooted after agent's installation.
Hope you manage to get the logs you are looking for :)