[featurerequest] send events logs to remote syslog/journald/http...

[juju4]

It would be great if kunai had the option to send logs to a remote system, be it through classical syslog, journald, http or else.
Benefits

• logs consolidation
• avoid to write any local disk and possibly alter evidence during investigation
  Thanks! Great work!

[qjerome]

Hey @juju4,

This is my ToDo since a while but I kept postponing it as nobody asked for it ...
Now you did it might be the good timing to implement it.

My idea was to implement a minimal kunai server talking websocket with agents to:

• send config/rules
• receive logs

Would that be acceptable for you or you'd need something more standard such as syslog ?

Other question: if you'd have this would you still need feature #177 ?

[juju4]

On management side, that was definitely a coming question :)
On logs, I would prefer to stay agnostic and allow a central management server and/or a logging/SIEM system. Most of them can receive logs through HTTP but not websocket AFAIK.
Examples:

• https://www.elastic.co/guide/en/integrations/current/http_endpoint.html
• https://openobserve.ai/docs/api/ingestion/logs/json/
• https://docs.cribl.io/stream/sources-cribl-http/
• https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/

If I take osquery case, there is a config and a logging plugin with an endpoint for each (--config_plugin/config_tls_endpoint/config_tls_refresh and --logger_plugin/logger_tls_endpoint/logger_tls_period). It's also possible to have multiple logger output like local and remote. Management server can be the one getting logs or not.

As for #177, yes, this one is a good workaround.

[qjerome]

My idea was more implementing a light kunai server to communicate with agents. I tend to think it is very risky to expose log storage platforms to every agent (potentially host) in the network. Maybe I am too much paranoid ...

So my idea was more something like the following:

graph LR;
    A[Kunai Agent] -->|Websocket| B[Kunai Server];
    B -->|Forward Logs| C[OpenSearch];
    B -->|Forward Logs| D[Elastic];
    B -->|Forward Logs| E[Splunk];
    B -->|Forward Logs| F[...];
    B -->|Websocket| A;

Loading

If that is something that would fit your needs I can prioritize implementation

[juju4]

In the full paranoid mode, I like kunai not doing any networking and leave logs shipping to another tool :)
Behavior seems more like a proxy and a single point of failure if not supporting multi-targets.
If I look to other tools

• Commercial all have their own central management server doing logging
• Osquery have multiple management servers (fleet, zentral...) that can manage logs or not
• Velociraptor have its management server but can ship artefacts to a variety of targets like amazon s3 or azure storage
• In my xp, logging collector are set per environment and exposed to those, like often web proxy, dns server, vulnerability scanner, monitoring server and else. Adding another one won't necessarily change much but is also another server to manage.
  In the end, that's your call.

[qjerome]

Ok, so if I understand correctly, if I resolve #177 it would actually solve your problem with log collection.

Another option which hasn't been mentioned, what about setting kunai output to stdout so that the logs ends-up in journald ? I don't have the same knowledge as you in log collection but wouldn't it be an easy way to forward logs to a remote server thanks to whatever tool supporting journald uploads ?