Hello everyone,
since we have been confronted with the topic of audit logging more and more recently, I wanted to ask you how you approach this topic with your customers and your systems.
The components and services used in UCS all differ slightly in terms of their logging objectives and scope.
A few examples:
Samba: Authorization, authentication, DSDB, and much more via the specification of debug classes using the log level directive
Samba: (File) operations at share level using vfs_full_audit
slapd: BINDs via debug level > 256 and filtering using rsyslog
slapd: Directory transactions via univention-directory-logger
UDM: Administrative changes via the admin-diary (or the point before that)
UDM: (Failed) logins via management-console-server.log or auth.log
I could expand on this extensively, and these were just rough examples.
How do you deal with this requirement?
Do you throw everything possible into an ELK stack (or similar)?
What are your experiences?
My question directly to Univention:
Are you planning to meet these requirements in the future?
I’ve been wondering this myself.
I’m checking health of the network and systems like UCS with zabbix. That’s enough for quite detailed insight of the machine, and other parts of the system.
For the past few months we were testing Wazuh which is quite handy thread and compliance checker. Yes, some additional tuning and log monitoring has to be implemented but it does the job.
The only problem I’ve got with testing Wazuh is how bad UCS 5.0 looks when checked for vulnerabilities Tend to just ignore this page when talking about risk
Univention will consolidate the logging in its own software (e.g., UDM, not Samba). Structured logging will make it much easier in the future to parse log files, extract relevant information, and correlate events.
I cannot provide a definitive timeframe yet, but you can expect improvements to the logging of the UDM REST API, for example.
We’re also looking into making metrics available that’ll help you observe the state of services and databases.
I’m sorry, I have no timeframe, so you’ll have to cope with what’s available at the moment. But I wanted to at least give you a heads-up that we’re working on that topic.
For monitoring aspects, we already have many parts of core components of UCS as separate services inside Checkmk and are quite happy. But IMHO thats a different topic than auditing and logging.
We are looking forward into this. At the moment, the gathering of log files and also the analysis of those are different from (sub-) service to service, even when all those services are made by Univention.
Do you extend the current univention-monitoring-* packages (UCS Dashboard) you’ve implemented with 5.0-2 or will this be a separate component?
Tend to just ignore this page when talking about risk