 Hi, I'm Peter Erzonic, open source evangelist at One Identity, and today I will talk about working with BSD parts. First, I would like to share a few things about me. I started to use free BSD in 1994, so almost 27 years ago. Right now I'm working at One Identity, which is an upstream for Syslogangy and Sulu. And for the past more than 10 years, I was working on packaging Syslogangy on Linux and free BSD, and recently also Sulu with. And this year I gave a try to tag on free BSD, net BSD and open BSD, and tried to update Syslogangy to the most recent version in these BSDs. So, let me give you a quick overview of what I will be talking about today. First, I try to define what is part, then introduce you to Sulu and Syslogangy, the two software I work with, and then I will talk about free BSD, try one, free BSD, net BSD and open BSD parts. My experiences with them, what I see as most important differences, and my experiences with Sulu and Syslogangy in these parts. So, what is parts? In free BSD and the other BSDs, the kernel and the complete base system is developed together. They are a complete base system. And if you want to use third-party applications, you need to use ports to install these third-party applications. I can describe most easily ports as a kind of database which describes how to compile and install these third-party packages. Of course, nowadays, compiling applications from source code is not so popular anymore. Rather, most people use binary packages, and all of these projects provide binary packages from ports for multiple architectures. Ports might provide some additional features compared to these binary packages, and some ports might even replace some base system functionality. Just think about Syslogangy. If you want to use Syslogangy to call local log messages, first you need to disable Syslogy on the base system, and then you can start Syslogangy. It doesn't mean that Syslogangy is overwriting anything in the base system. It just means that functionality is turned off in the base system and replaced by something in the ports. Let me talk a few words about Linux just for contrast. Linux itself is just a kernel, so it's not a complete system like any of the BSDs, but only a kernel. And what most people refer to as Linux are actual Linux distributions, the Linux kernel, and some collected applications. And the kernel and even the very most basic applications are developed independently from each other. Now, let's take a look at sudo. What is it? I guess most of you use it, but if in case you do not use, here is the definition from the sudo website. Sudo allows a system administrator to delegate authority by giving certain users the ability to run some commands as root or another user, while providing an audit trail of the commands and their arguments. So it's a lot more than just a prefix, even if many people consider sudo as a prefix for administrative commands. Here we see a very basic sudoers file, the configuration for sudo. By default sudo enables the members of the real group to run any commands on all hosts or as any user. Yes, it's lots of permissions, but it's still useful as this way you can see who is doing what on your system. Without sudo just giving out the root password, you do not know who does what on your system. Sudo has a huge number of defaults, and you can change those using the default statement in the sudoers file. Here there are a couple of examples on the screen, like you can overwrite which path is considered to be secure, which environment variables to keep from the user, or if you want to enable insults for your users. You can make these defaults user and host specific as well, like in this case defaults are enabled only for members of the real group. So what are insults? These are fun but not always politically correct error messages when a user mistypes a password. It's cisadmin humor and I love it, but some people feel offended by this and now it is disabled by default. One of the lesser known features of sudo is session recording. Anything happening on the terminal you can save and play back just like a movie. These recordings are difficult to modify as they are not clear text. However, by default these recordings are saved locally, which means that if you give too much permissions to a user, then they can easily delay these recordings. And obviously this feature is most useful when you give shell access to your users and they have all the possibility to delay these files. The good news is that sudo 1.9 introduces central session recording, which means that sessions are streamed in real time, so the users cannot delay or modify these recordings. Once you have more than just a single host, then you want to do some central configuration management. One of the possibilities is using LDOP, which has the advantage that settings are propagated in real time and they cannot be modified locally. On the other hand, there are quite a few limitations. You cannot use some of the advanced functionalities of sudo, so it's up to you if you use LDOP or other configuration management systems like Ansible. Python support was also added in sudo 1.9, which means that you can extend sudo using Python scripts. It's using the very same API as the C-based plugins for sudo. However, you do not need a dedicated development environment to develop Python plugins or to compile anything, and they are much easier to distribute as well. One of the sudo APIs is the IOLOX API, which can also be used from Python and access any input and output from user sessions. Some Python examples are breaking a session if a given text appears on screen, so it's kind of data leak prevention, or you can try to analyze what is happening on the command line and prevent RM-FR from running. So users cannot delay recursively and do too much damage. Here is a very simple Python example. All it does is checking what is happening on the screen, and it checks everything before it's actually printed on screen, which means that in this case the Python script checks if my secret appears in a buffer, and if it's there, then it terminates the sudo session. Here is a screenshot of this. The user starts share session using sudo, and there is a file called mysecret in the directory called do not enter. So the user changes to the directory of root, lists it. Oh, do not enter. That must be something interesting. Ties to list it, but kicked out before any sensitive information would be displayed on the terminal. Let's talk a few words about syslog-ng. First of all, what is syslog-ng? It's an enhanced login daemon with a strong focus on portability and high performance central log collection. It was originally developed in C, but you can now also extend it in Python and Java as well. What is logging? It's a recording of events like an SSH login message. Syslog-ng has four major roles. The first one is collecting data. Syslog-ng can collect system and application logs together, which can provide quite useful contextual data for either side. It can collect log messages from a wide variety of platform-specific sources, like Devlog, Journal, Sunstreams. As a central log collector, it speaks more than the new syslog protocols over UDP, TCP and encrypted connections. It can collect any kind of text data from applications. You can also use Python to extend syslog-ng, so you can create yourself an HTTP source, a Kafka source, whatever you need, and not yet implemented in syslog-ng itself. The next role is processing. You can crossify, normalize and structure data with built-in parsers. You can also rewrite log messages, and you don't have to think about falsifying log messages here, but for example do an elimination as required by compliance regulations. You can also enrich log messages using, for example, GIP or reformat log messages as needed by the destinations like Erasticsearch, Knits, JSON formatting. And you can also use Python for block processing, and you can implement any of the above possibilities, or enrich log messages from databases, or even do filtering from Python, which brings us to our next topic, its filtering data. It has two main uses. First of all, you don't want to keep all of your log messages, but for example, throw away debug-level log messages. And those are only necessary when you try to trace a problem. And also it's used for message routing, like you want to make sure that any out-indication related log messages reach your SIEM system. Finally, you want to store your log messages somewhere. Traditional syslog ng saved all log messages to text files, either locally or at the central syslog server. Nowadays, there are a lot more possibilities. You can store log messages to databases, message queuing, even to Hadoop. And if none of these fit your needs, you can extend syslog ng using Python and Java as well. Here is a tricky question before we are going on to discussing BSDs. What is common between the BMW i3 and a Kindle? There aren't many common things, but there is an interesting one. Both of them are running syslog ng. Now, let's talk about free BSD ports. You can find the source files for ports in the user ports directory, and binaries are installed under the user locale hierarchy. There are two sets of packages built from ports. Latest is always following what is happening in ports. All of the latest updates are available there. But not all people want to change package versions almost every day, so there is also a branch called Quarterly. So every three months, there is a new branch from Latest, and packages built from this branch. And here there are no version updates, but for three months you can stay on the same versions, and if there are any security problems, those are fixed in the Quarterly branch. When it comes to packages, in free BSD ports, packages often have only the basic functionality of an application, or the most used features are only enabled. Ports often have a lot more functionality, which provides you with a lot more flexibility if you want to use some lesser known features, or you can even disable some of the features. So if you are targeting an embedded device, you can disable most of the features and go with the bare minimum. You can find sudo under the security directory in free BSD ports, and it's pretty much up to date, it follows the 1.9 line of sudo releases. The package has only basic functionality, but most people are okay with this, as only advanced features are missing. And ports have practically everything. If you want to use inserts or held up or Python, then you need to compile sudo for yourself, otherwise you will be okay with buying real packages. Syslogang can be found in the Sysutilus directory, where I'm a maintainer for this port. Here the package only has basic functionalities, but let's define what is basic. It's always a tricky question. We try to define it in a way that features we do not need extra dependencies. But as you see, we made some exceptions. DRS support is enabled by default. JSON parsing and formatting is also there. And last year we also enabled HTTP support, which means that you can send log messages to Elasticsearch or Splunk without comparing Syslogang yourself. Of course there are still plenty of features, which are only available in ports, like language bindings, database support, message queuing, SMTP support or GIP as well. Dragonfly BSD is a fork of the FreeBSD codebase and they still have a close connection. The source of ports on Dragonfly is found under user dports and ports are synced from FreeBSD regularly, usually once in the middle of each month. Of course, they do not use FreeBSD directly, but they also have some modifications to FreeBSD ports and also some additions. When I first tested Dragonfly, Syslogang didn't work out of box and I posted a fix in my blog, which was quickly taken over by Dragonfly developers. However, a few months later, when I checked it again, I found that this fix was gone. So you can see the URL to my blog on screen, which contains information on how to use Syslogang on Dragonfly. One more thing to note about Dragonfly that security fixes are slow. I mean, my example here is Sudo, which had a serious problem at the beginning of the year, which was fixed in FreeBSD on the day when the problem became public. On the other hand, the fix reached DragonflyBSD only three weeks later on the next regular port sync. NetBSD calls ports as package source and the source for this can be found under the user package source directory. And the binaries are installed under the user package directory. Just like FreeBSD, there are two variants of packages. There is a quarter lip branch and the current, meaning the very same as latest on FreeBSD. And here the NetBSD package source is not only used on NetBSD, but can be also used on Solaris, on some of the Linux distributions, and also on macOS. When I first checked NetBSD, then all of the official documentation mentioned only the legacy tools to work with packages, which was a kind of annoying, knowing that I discovered on my own that there is also a tool called packaging, which is a much more up to date and easy to use tool for package management. When I checked back a few months later, the legacy tools are still mentioned in the documentation. The focus is finally on the new tool, so users who start to work with NetBSD now can find up to date the latest documentation. Sudu is in package source at the very same usual location, and it's up to date. However, some of the features of Sudu are missing. Only the basic functionality is available in package source. And these are also missing on the source side, not just from the packages. Cisco Gen.G is also available in package source, but right now it has quite an old version, 3.17. The good news is that an update is underway, and updating the port was quite easy even as a NetBSD newbie. It's thanks to the excellent documentation for package source. The new port is not yet submitted to package source, as there were a couple of bugs which needed to be fixed in Cisco Gen.G. The TCP source doesn't work, and it is fixed now in upstream, and I also pushed the system source patch from package source to upstream. Right now, I'm waiting for the next Cisco Gen.G release, and once it's there, then I will go on pushing the changes to package source. Finally, let's talk about OpenBSD ports. Both source and bindings are at the very same location as on FreeBSD. However, there is a huge difference here. Ports in this case are not intended to be used by end users, but the use of binary packages is strongly encouraged by OpenBSD developers. And they are probably right, as there are some rough edges. Like when I tried to compile Cisco Gen.G myself from ports, it turned out that build dependencies were not always well included in the ports. Unlike the other distos where there is a quarterly release of packages, OpenBSD releases packages together with the base system, and they receive security updates on most supported architectures for the lifetime of the release. SUDU is in OpenBSD ports, and it's maintained by SUDU author Tod Miller, so it's always up to date, and it has all the major features enabled. Cisco Gen.G was stuck at quite an old version for a very long time. And there were many OpenBSD specific patches in the ports. I tried to update Cisco Gen.G myself, but both Cisco Gen.G and OpenBSD changed quite a lot in the past few years. So my attempt failed, and I asked for help from Tod Miller, who updated the patches and upstreamed them as well. So Cisco Gen.G is now up to date in OpenBSD ports, and it has all of the often used features enabled. Let me summarize my talk. I checked SUDU and Cisco Gen.G for different BSDs, and I found that security in ports is mostly good, except probably for Dragonfly BSD, which was lagging a bit behind. SUDU is well maintained in all of the BSDs, and Cisco Gen.G is up to date now in 3 out of 4 BSDs, and NetBSD update is working progress. So hopefully in the coming weeks or months, it will be up to date as well. BSD ports seem to have different priorities, similarly to their base systems. FreeBSD and Dragonfly BSD has a strong focus on flexibility, what you can do in ports and with packages. NetBSD has a strong focus on portability, and OpenBSD has a focus on stability and security. Thank you for your attention, and it's time for questions.