There are situations where you cannot avoid giving a user full shell access through sudo. A shell with administrative privileges gives complete control over your hosts. Until recently, sudo could only log the start of the shell, not the commands executed within it. You could record sessions with sudo, but watching recordings is boring, time consuming and can still be subverted. Version 1.9.8 introduced logging of sub-commands, but that is not yet available on many systems.

Recently, I started my own blog, and as Google Analytics seems to miss a good part of visitors, I wanted to analyze my web server logs myself. I use syslog-ng to read Apache logs, process them, and store them to Elasticsearch. Along the way, I resolve the IP address using a Python parser, analyze the Agent field of the logs, and also use GeoIP to locate the user on the map.

Sudo had many features to help blue teams in their daily job even before 1.9 was released. Session recordings, plugins and others made sure that most administrative access could be controlled and problems easily detected. Version 1.9 introduced Python support, new APIs, centralized session recordings, however some blind spots still remained. Learn how some of the latest sudo features can help you to better control and log administrative access to your hosts.

What hardware to use for a syslog-ng server? It is a frequent question with no definite answer. It depends on many factors: the number and type of sources, the number of logs, the way logs are processed, and so on. My experience is that for the majority users even a Raspberry Pi would be enough. But of course, not for everyone. You can read the rest of my blog at https://www.

This year the syslog-ng project will participate in the Google Summer of Code (GSoC) as a mentor organization again. If you are a university student or otherwise eligible to participate in the GSoC program, you can choose to develop a new feature for syslog-ng. Read my blog to learn why to choose syslog-ng and how to get started: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-in-gsoc-2022 syslog-ng logo

For many years, you could use the match() filter of syslog-ng to parse log messages with regular expressions. However, the primary function of match() is filtering. Recent syslog-ng versions now have a dedicated regular expression parser, the regexp-parser(). So, you should use match() only if your primary use case is filtering. Otherwise, use the regexp-parser for parsing, as it is a lot more flexible. You can read the rest of my blog at https://www.

The latest pull request to syslog-ng adds a really useful feature: the flip-parser(): https://github.com/syslog-ng/syslog-ng/pull/3971 It allows you to flip the message text, reverse it, or both. As I also reported a couple of minor problems related to UTF-8 character handling, this PR most likely will not be merged today. However, you can compile it yourself, or if you use openSUSE Tumbleweed, use my packages from the openSUSE Build Service. You can read the rest of my blog at https://www.

Session recording has been available in sudo for many years, however not many people are aware of it. Even less well-known is that you can save not just the terminal output, but also what the user types. That way you can analyze what the user is doing within a shell session. Recordings may also include user passwords, which is not always desirable. Version 1.9.10 of sudo allows you to hide passwords in session recordings if it recognizes a password entry.

There are multiple ways in syslog-ng to limit message rate. The throttle() option of syslog-ng destinations tries to make sure that all messages are delivered without exceeding a specified message rate. The rate-limit() filter introduced in syslog-ng 3.36 drops surplus log messages, making sure that a processing pipeline or destination is not overloaded with log messages. Read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/the-difference-between-throttle-and-rate-limit-in-syslog-ng syslog-ng logo

Most of syslog-ng works perfectly well on MacOS; however, there is no native driver to collect local log messages. Due to this, in the past, the system() source did not work on MacOS, thus the default syslog-ng configuration failed to start. Version 3.36 of syslog-ng includes a workaround: it follows /var/log/system.log. You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/the-system-source-of-syslog-ng-now-also-works-on-macos syslog-ng logo