Peter Czanik

Sudo is used by millions to control and log administrator access to systems, but using only the default configuration, there are plenty of blind spots. Using the latest features in sudo lets you watch some functions that previously were blind spots and you can also control access to them. There were several minor and major changes since the 1.9.0 release that I discussed in my previous FOSDEM talks. Here are the four major new features allowing you see your blind spots:

• instead of giving full shell access, you can fine-tune the working directory and chroot settings

• JSON-formatted logs give you more details on events and are easier to act on

• relays in sudo_logsrvd make session recording collection more secure and reliable

• you can log and control sub-commands executed by the command that is run through sudo

Previously, there were quite a few situations where you had to give users full shell access through sudo. Typical examples are when you run a command from a given directory, or run commands in a chroot environment. You can now configure the working directory or the chroot directory and give access only to the command the user really needs.

Logging is one of the main roles of sudo, to see who did what on the system. Using JSON-formatted log messages gives you even more information about events. Also, structured logs are easier to act on. Setting up alerting for suspicious events is much easier when you have a single parser to configure for any kind of sudo logs. You can collect sudo logs not only by local syslog, but also by using sudo_logsrvd, the same application used to collect session recordings.

Speaking of session recordings: instead of using a single central server, you can now have multiple levels of sudo_logsrvd relays between the client and the final destination. This allows session collection even if the central server is unavailable, providing you with additional security. It also makes your network configuration simpler.

Finally, you can log sub-commands executed from the command issued through sudo. You can see commands started from a shell. No more unnoticed shell access from text editors. And, best of all: you can also intercept sub-commands.

A desktop thermometer that displays relative humidity is useful, but it does not provide continuous monitoring. In comes the Raspberry Pi: it is small, inexpensive, and has many sensor options, including temperature and relative humidity. It can collect data around the clock, do some alerting, and forward data for analysis.

Originally it was a project to practice Python and learn Elasticsearch, but ended up with using syslog-ng between the two. Along the way, I also learned how to regulate humidity in my room. In my talk, I plan to cover the following topics:

• collecting environmental data on the Rasbperry Pi using Python

• configuring Elasticsearch to work around a syslog-ng limitation

• configuring syslog-ng to forward the collected data to Elasticsearch / OpenSearch

• take a look at the graphs in Kibana and learn how to keep humidity low in your room

Most people consider sudo and syslog-ng as old, small and stable utilities. Yes, they are from the ‘90s, but both are constantly evolving, gaining many interesting new features along the way. Peter, who is an evangelist for these two applications, shows you some of the most interesting new developments in both projects. By default, only basic functionality is enabled in FreeBSD ports, so we will also take a look at some of the extra features you can enable if you compile the packages yourself.

On the syslog-ng side most people know that it can save incoming log messages to text files, and few are aware of the complete set of features this tool has. Syslog-ng has four major roles: collecting log messages, processing, filtering and storing them. There are many supported log sources and you can write your own in Python. Or another example: it can find credit card numbers in logs and remove them to comply with PCI-DSS. And syslog-ng can store logs not just to text files, but to databases, big data destinations, like Hadoop, or to Splunk or Elasticsearch as well. Sudo is mostly known as a prefix for administrative commands. Did you know that you can also record sessions, extend sudo with Python scripts and even analyze what is happening on the screen? Learn which of the above mentioned features are supported in FreeBSD ports (hint: all of them), which are enabled by default, and which features require you to recompile sudo or syslog-ng.

Everybody knows sudo, right? Sudo allows a system administrator to give certain users the ability to run some commands as root, while logging the executed commands and their arguments. It is installed by default on almost all Linux systems, and is available for most commercial UNIX systems. Still, even system administrators often only know it is the “prefix” to use before entering a command requiring root privileges. Learn how much more this simple looking tool can do!

Everybody knows sudo, right? Sudo allows a system administrator to give certain users the ability to run some commands as root, while logging the executed commands and their arguments. It is installed by default on almost all Linux systems, and is available for most commercial UNIX systems. Still, even system administrators often only know it is the “prefix” to use before entering a command requiring root privileges. Learn how much more this simple looking tool can do! Most of the times the default configuration allows a group of users to run any commands: %wheel ALL=(ALL) ALL It’s a good first step, better than using the root account directly. This way you can trace who ran what commands on the system. But there are a lot more possibilities when configuring sudo, making your system more secure. Life is simple when when you have to give access a single user to a single command. But as soon as you have multiple users with the same access rights, it is not just shorter but also easier to maintain, if you use aliases. For added security, you can add a hash of binaries to sudo. This way if the binary changes for any reasons, like modifying it through a successful exploit, you can prevent it from being used.

Using sudo does not make much sense without proper logging and alerting. There are three major possibilities: - syslog: all events are logged to syslog. For additional security, collect sudo logs centrally, so a malicious user cannot delete them easily. - e-mail: sudo can send e-mail alerts on different kinds of failures - debug: in depth logging of subsystems, mostly useful for developers Session recording is a fourth possibility. The terminal output can be saved in a local file and played back. You can play back what happened, even if the user started up an interactive shell.

Instead of maintaining the sudoers file on each of your systems, you can use LDAP to configure sudo. It has some differences compared to a sudoers file, but also many advantages: - local users cannot manipulate the rules, - is easier to maintain, - goes live immediately.

Starting with version 1.8, sudo has a plugin-based architecture. You can replace or extend sudo functionality using plugins. This way users can keep starting applications the usual way using sudo, but have a different configuration or policy engine behind the sudo command. There are both open source and commercial plugins available. For example the sudo_pair plugin – developed in Rust – enables monitoring and makes it possible to require interactive approval of sessions.

As you can see, sudo has several lesser-known features that can make monitoring and access management easier for large organizations.

From my talk you will learn about some lesser-known features of sudo, and how you can make your security more flexible by extending sudo using Python.

Everybody knows sudo, right? Sudo allows a system administrator to give certain users the ability to run some commands as root, while logging the executed commands and their arguments. It is installed by default on almost all Linux systems, and is available for most commercial UNIX systems. Sudo allows you to fine-tune access policies, record sessions, and do extensive logging. Still, even system administrators often only know it is the “prefix” to use before entering a command requiring root privileges, and don’t realize its true powers.

Did you know that with version 1.8 sudo changed to a plugin-based architecture? You can extend or even replace basic functionality through plugins. While plugins provide the ultimate flexibility – and there are both open source and commercial plugins for sudo available – it is not easy to extend sudo. This is why the Python plugin is under way to sudo (and will be released before FOSDEM).

Sudo has a number of well defined APIs for plugins (https://www.sudo.ws/man/sudo_plugin.man.html). The Python plugin builds on these APIs. For example, you can set your own policies using the policy API, or access what is happening on the screen using the I/O API (used by session recording).

Using Python for extending sudo makes development not just easier (no development environment necessary), but opens up many new possibilities. For example, you can develop a plugin which analyzes on-screen activity in real-time, and breaks the session if the infamous “rm -fr /” command appears on screen. As multiple I/O plugins can work in parallel, you do not have to give up session recording to analyze sessions in real-time from Python.

From my talk you will learn about some lesser-known features of sudo, and how you can make your security more flexible by extending sudo using Python.

The syslog-ng application collects logs from many different sources, performs real-time log analysis by processing and filtering them, and finally it stores the logs, or forwards them for further analysis. It was originally developed in C due to its low footprint and high performance. Recently Python language bindings were added, so you can collect, process, and store log messages using embedded Python code.

Learn how to customize your log processing infrastructure in Python using syslog-ng, integrate your logs to local and cloud services, and the implementation details and benefits of such solutions.

The syslog-ng application collects logs from many different sources, performs real-time log analysis by processing and filtering them, and finally it stores the logs, or forwards them for further analysis. It was originally developed in C due to its low footprint and high performance. Recently Python language bindings were added, so you can collect, process and store log messages using embedded Python code.

Python bindings always have two parts: a configuration part – where you configure a source, parser, or destination – and the actual Python code part. You can store the code in-line in the syslog-ng configuration file, or in external files, if you have a larger project.

The first Python binding added to syslog-ng was the Python destination. Many databases and cloud services have an easy to use Python API, while a C implementation of the API is either missing or difficult to implement. The syslog-ng application handles log messages and parsed data as name-value pairs. You can pass name-values to the Python destination code in mulitple ways: an object which contains all of the name-value pairs, or as a dict, which contains only name-value pairs configured in syslog-ng.conf. Recent releases also support the use of templates.

Next the Python parser was implemented. Originally it was intended as an easy-to-code parser for messages not supported by the built-in parsers, like PatternDB or csv-parser. But you can also use it to enrich log messages from external databases. For example, you can use it to resolve host names from IP addresses.

Recently support for Python source was added. You can use it to fetch data or implement a server in Python, for example, to collect messages over HTTP or Kafka protocols.

Obviously the Python code is slower than native C code. On the other hand, extending syslog-ng in Python offers a lot more flexibility than development in C. You do not need a development environment other than a text editor and the Python module installed. Neither do you need you to compile the code. Just write it and use it.

It is easy to get started, as there is no need for extra setup. You can get proof-of-concept minimal setup working with a single method quickly. You can extend it later to have proper initialization and connection control for added robustness.

Learn how to customize your log processing infrastructure in Python using syslog-ng, integrate your logs to local and cloud services, and the implementation details and benefits of such solutions.

Logging events is important for every device connected to the Internet or a network. The syslog-ng application is an enhanced logging daemon, with a focus on portability and central log collection. It collects logs from many different sources, processes and filters them, and finally it stores them or routes them for further analysis. IoT developers can get started with it quickly, as its configuration language is similar to programming languages.

Logging events is important for every device connected to the Internet or a network. The syslog-ng application is an enhanced logging daemon, with a focus on portability and central log collection. It collects logs from many different sources, processes and filters them, and finally it stores them or routes them for further analysis. IoT developers can get started with it quickly, as its configuration language is similar to programming languages.

From this session you will learn how to use logging for collecting usage statistics, monitoring, security, or debugging running applications, using examples from syslog-ng. We will discuss some interesting use cases from a wide range IoT devices: consumer devices, like the Amazon Kindle or the BMW i3 electric car IT appliances, like NAS and network devices industrial uses, like National Instruments devices

In addition to acting as a logging agent, syslog-ng can be your logserver and collect data from IoT devices. The syslog-ng application can parse incoming data for interesting information, anonymize it if required by compliance, and route results to the proper destination. Other than saving logs locally, you have many possibilities, including visualizing logs using Graphite, creating alerts using Riemann, analyzing them in Kibana, or saving them to Hadoop HDFS for long term storage.

Event logging is a central source of information for IT security. The syslog-ng application collects logs from many different sources, performs real-time log analysis by processing and filtering them, and finally it stores the logs or routes them for further analysis. This session focuses on how syslog-ng parses important information from incoming messages, enriches them with additional contextual information, and concludes with demonstrating how all of this can be used for alerting or for dashboards.

Event logging is a central source of information for IT security. The syslog-ng application collects logs from many different sources, performs real-time log analysis by processing and filtering them, and finally it stores the logs or routes them for further analysis. In an ideal world, all log messages come in a structured format, ready to be used for log analysis, alerting or dashboards. But in a real world only part of the logs belong to this category. Traditionally, most of the log messages come as free format text messages. These are easy to be read by humans, which was the original use of log messages. However, today logs are rarely processed by the human eye. Fortunately syslog-ng has several tools to turn unstructured and many of the structured message formats into name-value pairs, and thus delivers the benefits of structured log messages. Once you have name-value pairs, log messages can be further enriched with additional information in real-time, which helps responding to security events faster. One way is adding geo-location based on IP addresses. Another way is adding contextual data from external files, like the role of a server based on the IP address or the role of the user based on the name. Data from external files can also be used to filter messages, for example to check firewall logs to determine whether certain IP addresses are contained in various black lists for malware command centers, spammers, and so on. Logging is subject to an increasing number of compliance regulations. PCI-DSS or many European privacy laws require removing sensitive data from log messages. I will demonstrate how logs can be anonymized in a way that they are still useful for security analitics. At the end I would like to introduce you to the basics of syslog-ng configuration, and demonstrate how the collected logs can be used for alerting or visualized on a dashboard.

Event logging is important not only for IT security and operations, but also for business decisions. The syslog-ng application is an enhanced logging daemon, with a focus on central log collection. It collects logs from many different sources, processes and filters them and finally it stores them or routes them for further analysis. From this session you will learn (using examples from syslog-ng) why and how to parse important information from incoming messages, and how to route logs, feeding downstream systems using arbitrary formats. We will also discuss how the client – relay – server architecture can solve scalability problems. Also, I will present some of the recently introduced “Big Data” destinations of syslog-ng, which can help to scale your infrastructure even further.

Outline:

• what is syslog-ng
• log collection
• introduction to log processing
• filtering
• Big Data destinations
• log formats - the importance of name-value pairs
• message parsing (both unstructured and some structured message formats)
• formatting (templates, anonymization)
• log routing (optimizing analytics infrastructure)
• client (collection) - relay (processing) - server (storing, routing)
• summary

Most people still think of syslog-ng as a logging system with a flexible configuration language. It is now databases, message parsing, mongodb, JSON, message queuing and a lot more.

Over the years, syslog-ng has evolved from a flexible and reliable logging system into a feature-rich log-processing tool. It's not just store and forward anymore, for example, with syslog-ng you can: * Process and parse the body of messages to find important information and send e-mail alerts for specific events * Receive structured JSON messages from your applications and store-them in a schema-free MongoDB NoSQL database * Publish your messages to different message-queuing systems, for example, STOMP or AMQP * Collect real-time statistics from your hosts and applications using the redis or riemann destinations All of these illustrated with short real life examples, how they can be used during development or operating your servers.

For many years, syslog-ng was part of many distributions but stuck at ancient software versions. My task was to help distributions to update their syslog-ng packages and now to keep them updated. This is a two way process, as while distros receive many help, we also get a lot of useful feedback and ideas, which influence the development of syslog-ng. Using syslog-ng as an example, I'll try to show how upstream can work with distributions for the benefit of both sides.

For many years, syslog-ng was part of many distributions but stuck at ancient software versions. My task was to help distributions to update their syslog-ng packages and now to keep them updated. This is a two way process, as while distros receive many help, we also get a lot of useful feedback and ideas, which influence the development of syslog-ng. Using syslog-ng as an example, I'll try to show how upstream can work with distributions for the benefit of both sides.