What’s new in sudo and syslog-ng?
Czanik, Peter
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.
 Hi, I'm Peter Arzhamit, open source evangelist at 1&Entity. Today I will talk about what is new in sudo and syslogangy and provide you with a BSD specific view. I started to use free BSD in 1994. Today I will spend most of my time with sudo and syslogangy. So I will introduce you to what is new with this 2 software and also show you how to install it on free BSD either from binary packages with pkj or combining it yourself from ORDS. Finally I will also show you how to use syslogangy in BSD. So let's start with sudo. What is sudo? I asked this question from thousands of people over the past few years and the typical answer depended on the experience of the person and went into three main categories. For most people sudo is a tool to complicate life. Why do you sudo if you can log in as root or use the su command to change the root? But even seasoned administrators told me that well sudo is just a prefix for administrative commands and only a few people told me that they know some of the advanced features of sudo. So what is sudo? sudo allows a seasoned administrator to delegate authority by giving certain users the ability to run some commands as root or another user by providing an audit trail of the commands and their arguments. So as you can see it's a lot more than just a prefix. If we can believe to xkcd it can even get you a sandwich. Just make sure that when you make a request for a sandwich then you use the sudo prefix. Back to more series topics. sudo comes with a huge set of useful defaults but if some of these do not fit your use case you can change these defaults using the default statement in your configuration. Here are a couple of examples like changing what path is considered secure by sudo, which is environment variables to keep from the user's settings and disabling insults for the user's. You can also make defaults user or host specific. For example the last line of the screen shows how to enable insults for members of the wheel tube. So what are insults? Insults are fun but not always politically correct error messages when someone mistypes a password. It's kind of sysadmin humor. As you can see it's nothing harmful but still some people find it offensive so it's disabled now by default. Another lesser known feature of sudo is digest verification. You can store the digest of applications in this sudoers file and this way sudo always compares the digest with the application before running it. The downside is that it's quite difficult to maintain this database in your sudoers file. On the other hand this way you can prevent modified binaries from running and it provides you with an additional layer of protection if you don't trust your users. Another feature is session recording. Sudo can record everything what is happening on your terminal which is especially useful when you have users which need shell access instead of just some specific commands. The recordings can be played back just like a movie. They are quite difficult to modify as they are not clear text. On the other hand these files are saved locally therefore they are easy to delete with unlimited access. The good news is that starting with sudo 1.9 which was released last year session recordings can be collected centrally which means that anything what a user does is streamed in real time to another location so they cannot modify or delete the recordings. Once you have more than just a handful of machines you want to manage your configurations centrally. Most configuration management systems support sudo but sudo itself has support for centrals. You can store your configuration in eldop which has the advantage that settings propagate in real time and they cannot be modified by users locally. On the other hand there are quite a few limitations as for example you cannot use aliases and if your network is down you might not be able to run sudo. Another feature which was added to sudo 1.9 is python support. Previously you can extend sudo through C based plugins but now you can write your own extensions to sudo using python using the very same APIs. The advantage of python is that there is no need for a dedicated development environment or compiling your code and you can even distribute your python code using a config management system. One of the most interesting APIs to sudo is the iolox API. Using this API you can access input and output from user sessions. And for example you can use python to break connections if a given text appears on screen so it's a kind of data lake prevention or you can analyze the command line what users are trying to run and break the session if someone tries to use error mines fr on the command line. Here is a short python example it's fully functional but of course it doesn't cover any corner cases so it's just to show that it how it works. In this case anytime my secret appears on the screen the session is broken. On the following screen I will show you how it works. I created a file called mysecret in a directory and before it could be shown on screen the session is terminated. Here is the screenshot the user starts sudo with minus s so it starts as shell changes to the root directory lists the directory and can see that oh there is that directory called do not enter it must be something very interesting let's check it out the user changes to this directory and types the ls command but before my secret could appear on screen the session is terminated. Now let's change the syslogangy. First of all what is logging? Logging is a recording of events happening on a computer such as an ssh login message and most people are only aware of this that you can see what happened on your system in text files in the var log directory. So what is syslogangy? It's an enhanced logging domain with a strong focus on portability and high performance in central collection. Originally it was developed in C but now you can extend it in python or java as well. And it has many more features than just simple saving log messages to text files. Let's see the four major roles of syslogangy. The first role is collecting data. We can collect system and application logs together providing quite useful contextual data for either side. It can collect log messages from a wide variety of platform specific sources like devlog, jorma, sun streams and so on. As a central log collector it can collect log messages over the network using the legacy or the new syslog protocol over UDP, TCP and encrypted connections. And it can also collect logs or any kind of text data from applications through files, sockets, pipes and even application output. If none of these fits your needs you can extend syslogangy using python and for example add HTTP server to syslogangy to collect log messages like the HTTP event collector in sprunk. The next role is log processing. You can classify normalizing structure logs with built-in parsers. For example the CSV parser can parse any kind of columnar data like Apache access logs, or can parse freeform log messages like the SSH login message. And there are parsers for JSON format messages, key value pairs or even for XML. And these parsers can also be combined together so we have also parsers for cscool log messages and for many more. You can also rewrite log messages using syslogangy and you don't have to think about falsifying log messages here but for example an animation is required by different compliance regulations. For example finding and overwriting credit card numbers in log messages. You can also enrich log messages at additional fields based on the message content or use the gip parser to add geolocation to IP addresses. Or you can reformat log messages using templates like the elastic search destination needs JSON format field messages, some scene system needs the ISO date format and so on. And if you want you can extend, you can parse your log messages using Python, you can implement any of the above features in Python as well or you can enrich your log messages from databases and also do filtering from Python which brings us to our next topic, filtering data. It has two main uses, discarding source plus log messages like you don't want to store debug level messages as storage is expensive and these messages are rarely used. Another use for filtering is message routing like making sure that all of your authentication related events reach your scene system. There are many possibilities for filtering, it can be based on message content, different message parameters, you can use comparisons, white cards, many different filtering functions and best of all you can combine any of these with boolean operators to make really quite complex filters within syslogang. Finally, you have to store your log messages somewhere, most people are only aware that they can store log messages to text files either locally or at the central syslogang server. But there are many more possibilities, you can store log messages to databases, to different scene systems, to big data like Hadoop, Erasticsearch, MongoDB, to message queuing like Kafka or AMQP, so there are many possibilities and if none of these fits your needs you can use Python or Java to extend syslogang with a new destination. Here you can see a heat map of IP addresses as found by the GIP parser in syslogang. This is real data, it's from my home router sitting in a quiet suburb of Budapest but as you can see the network itself is nothing quiet, everyone from around the world tries to connect but fortunately kicked out by my firewall. Here I combine sudo and syslogang and send alerts from sudo to Slack in real time. Sudo logs are parsed automatically by syslogang so all I had to do is add a filter to filter on my username and whenever I do something through sudo syslogang sends a message in real time to Slack. Of course alerting on myself is not much use but you can do the same on your hosts with multiple engineers using sudo. So here comes a tricky question, what is common between the BMW i3 and the Kindle ebook reader? The answer is syslogang. Both of them are running syslogang. And most people are not aware of it that hundreds of millions of devices run syslogang. What else syslogang and sudo used? Sudo is installed on almost all bsd linux, unix and macOS systems so many devices. And syslogang is available on most linux distributions and bsd variants. It's running by default on most bsd based appliances like Freenas or OpenSense. It's also on Synology and QNAP network attached storage systems and on tourism near firewalls. I wouldn't be surprised to learn if I learned that it's also running somewhere in space. So let's see how you can install this software on FreeBSD. sudo is available in the FreeBSD ports under the security group. This port is kept pretty much up to date, it follows the 1.9 line of sudo. If you install the binary package using pkj, it only has the very basic functionality. But don't worry, most people don't use anymore. But if you need any of the advanced functionality I mentioned earlier, then you need to compile sudo yourself from ports. For example, if you want to enable inserts, you need to compile sudo yourself. But also if you want held up support, Python or Kerberos support within sudo. Cisco GenG is also in FreeBSD ports in the sysutils group. I'm a commentator for this port, so it's also kept up to date. If you use the pre-built binary package, Cisco GenG provides only basic functionalities. But define basic, previously we tried to keep the extra dependencies low, so we only enabled features we didn't need any external dependencies. But over the years, some extra features were enabled, like DRS, so encryption support is enabled by default for years. Last year, two years ago, we enabled JSON support by default, and last year, HTTP support was enabled by default as well. This means that without recompiling syslog.ng, you can store log messages to Elasticsearch port to many different cloud-based login-assess service providers, like SumoLogic or Logly. For example. But you still need to compile syslog.ng from ports yourself if you want to enable support for language pytings like Python or Java. If you want to store your log messages to databases like different SQL databases or MongoDB, if you need message queuing like AMQP, Kafka, and to support many other technologies like SMTP, SNMP, GIP, and more. Finally I want to show you how to run syslog.ng in Bastille. But first of all, what is Bastille? Bastille is an open-source system for automating deployment and management of containerized applications on 3DSD. It doesn't have any hard dependencies on any other applications. The only exception is JIT if you want to use the templates. And you want us to use a template for syslog.ng as well. On the next slides I will show you how to install Bastille and get to your first syslog.ng jail. First you need to install Bastille from ports. It's also in the sysutils group. Then set up Bastille, configure your firewall. And then create a new jail. Install syslog.ng using template. And finally also configure your firewall. On my slides I will show you only a very basic setup, but there are many more possibilities like you can use CFS, VNET, and other advanced 3DSD technologies. So, the latest version of Bastille you can install from ports, freshly updated ports as it was just released last week. Just change to the directory, make install clean and enable it. The simplest setup which works everywhere is to use a cloned interface and use private IP addresses for your jails and redirect external ports to your internal network using the PF firewall. So, the next slide shows you PFConf. Using this you can protect your host and forward connections to your jails without editing your firewall configuration anymore. So Bastille can maintain your firewall settings. And finally I will show you how to get started with Bastille commands. As a first step you need to bootstrap a release of 3DSD you want to use. I used 12.2 and I also bootstraped the CISL GenG template. Next I created a jail using this release on a private IP address. Then applied the template to this jail and as a final step I redirected an external port to the internal network. Now you are ready to send log messages from your other hosts to CISL GenG running in Bastille. And now it's time for questions. Thank you for your attention. Okay, we're going to switch to live now. You hear me? Yes, I can hear you. Okay, excellent. So thanks Peter for this great presentation. Now it's time for questions. I saw you start answering some of them on the chat. Maybe if we have other questions. Someone was asking if using the slack destination is documented somewhere. Of course it's part of the official documentation but I also have a blog about it and I sent the URL to the chat. You can find this blog and many others about how to use CISL GenG on CISL GenG.com under the community many point and not just slack but many other use cases are described including the steps how to install CISL GenG on FreeBSD and other operating systems. So please forward if you have someone who is probably taking questions. No. So I think that's probably all. Thank you very much for your presentation. Thank you for welcoming me here. And if you still have any questions, I will stay here for a while and can answer anything. Okay. And I hope you will see you next year with another great presentation and probably answering the questions. Thank you very much. And I think this is the end for the BSD Devroom. Thank you all for being here. All the presentations and videos will be available on the FOSDEM website. I think probably today, maybe tomorrow. And I think that's all. I hope I will see you next year probably in Brussels so we can share some waffles and some cup of beers together and enjoy the rest of the day. Thank you very much. Goodbye. Thank you. Thank you. Thank you.
 Hi, I'm Peter Arzhamit, open source evangelist at 1&Entity.  Today I will talk about what is new in sudo and syslogangy and provide you with a BSD  specific view.  I started to use free BSD in 1994.  Today I will spend most of my time with sudo and syslogangy.  So I will introduce you to what is new with this 2 software and also show you how to install  it on free BSD either from binary packages with pkj or combining it yourself from ORDS.  Finally I will also show you how to use syslogangy in BSD.  So let's start with sudo.  What is sudo?  I asked this question from thousands of people over the past few years and the typical answer  depended on the experience of the person and went into three main categories.  For most people sudo is a tool to complicate life.  Why do you sudo if you can log in as root or use the su command to change the root?  But even seasoned administrators told me that well sudo is just a prefix for administrative  commands and only a few people told me that they know some of the advanced features of  sudo.  So what is sudo?  sudo allows a seasoned administrator to delegate authority by giving certain users the ability  to run some commands as root or another user by providing an audit trail of the commands  and their arguments.  So as you can see it's a lot more than just a prefix.  If we can believe to xkcd it can even get you a sandwich.  Just make sure that when you make a request for a sandwich then you use the sudo prefix.  Back to more series topics.  sudo comes with a huge set of useful defaults but if some of these do not fit your use case  you can change these defaults using the default statement in your configuration.  Here are a couple of examples like changing what path is considered secure by sudo, which  is environment variables to keep from the user's settings and disabling insults for  the user's.  You can also make defaults user or host specific.  For example the last line of the screen shows how to enable insults for members of the wheel  tube.  So what are insults?  Insults are fun but not always politically correct error messages when someone mistypes  a password.  It's kind of sysadmin humor.  As you can see it's nothing harmful but still some people find it offensive so it's disabled  now by default.  Another lesser known feature of sudo is digest verification.  You can store the digest of applications in this sudoers file and this way sudo always  compares the digest with the application before running it.  The downside is that it's quite difficult to maintain this database in your sudoers  file.  On the other hand this way you can prevent modified binaries from running and it provides  you with an additional layer of protection if you don't trust your users.  Another feature is session recording.  Sudo can record everything what is happening on your terminal which is especially useful  when you have users which need shell access instead of just some specific commands.  The recordings can be played back just like a movie.  They are quite difficult to modify as they are not clear text.  On the other hand these files are saved locally therefore they are easy to delete with unlimited  access.  The good news is that starting with sudo 1.9 which was released last year session recordings  can be collected centrally which means that anything what a user does is streamed in real  time to another location so they cannot modify or delete the recordings.  Once you have more than just a handful of machines you want to manage your configurations  centrally.  Most configuration management systems support sudo but sudo itself has support for centrals.  You can store your configuration in eldop which has the advantage that settings propagate  in real time and they cannot be modified by users locally.  On the other hand there are quite a few limitations as for example you cannot use aliases and  if your network is down you might not be able to run sudo.  Another feature which was added to sudo 1.9 is python support.  Previously you can extend sudo through C based plugins but now you can write your own extensions  to sudo using python using the very same APIs.  The advantage of python is that there is no need for a dedicated development environment  or compiling your code and you can even distribute your python code using a config management  system.  One of the most interesting APIs to sudo is the iolox API.  Using this API you can access input and output from user sessions.  And for example you can use python to break connections if a given text appears on screen  so it's a kind of data lake prevention or you can analyze the command line what users  are trying to run and break the session if someone tries to use error mines fr on the  command line.  Here is a short python example it's fully functional but of course it doesn't cover any corner cases  so it's just to show that it how it works.  In this case anytime my secret appears on the screen the session is broken.  On the following screen I will show you how it works.  I created a file called mysecret in a directory and before it could be shown on screen the  session is terminated.  Here is the screenshot the user starts sudo with minus s so it starts as shell changes  to the root directory lists the directory and can see that oh there is that directory  called do not enter it must be something very interesting let's check it out the user changes  to this directory and types the ls command but before my secret could appear on screen  the session is terminated.  Now let's change the syslogangy.  First of all what is logging?  Logging is a recording of events happening on a computer such as an ssh login message  and most people are only aware of this that you can see what happened on your system in  text files in the var log directory.  So what is syslogangy?  It's an enhanced logging domain with a strong focus on portability and high performance  in central collection.  Originally it was developed in C but now you can extend it in python or java as well.  And it has many more features than just simple saving log messages to text files.  Let's see the four major roles of syslogangy.  The first role is collecting data.  We can collect system and application logs together providing quite useful contextual  data for either side.  It can collect log messages from a wide variety of platform specific sources like devlog,  jorma, sun streams and so on.  As a central log collector it can collect log messages over the network using the legacy  or the new syslog protocol over UDP, TCP and encrypted connections.  And it can also collect logs or any kind of text data from applications through files,  sockets, pipes and even application output.  If none of these fits your needs you can extend syslogangy using python and for example add  HTTP server to syslogangy to collect log messages like the HTTP event collector in sprunk.  The next role is log processing.  You can classify normalizing structure logs with built-in parsers.  For example the CSV parser can parse any kind of columnar data like Apache access logs,  or can parse freeform log messages like the SSH login message.  And there are parsers for JSON format messages, key value pairs or even for XML.  And these parsers can also be combined together so we have also parsers for cscool log messages  and for many more.  You can also rewrite log messages using syslogangy and you don't have to think about falsifying  log messages here but for example an animation is required by different compliance regulations.  For example finding and overwriting credit card numbers in log messages.  You can also enrich log messages at additional fields based on the message content or use  the gip parser to add geolocation to IP addresses.  Or you can reformat log messages using templates like the elastic search destination needs JSON  format field messages, some scene system needs the ISO date format and so on.  And if you want you can extend, you can parse your log messages using Python, you can implement  any of the above features in Python as well or you can enrich your log messages from databases  and also do filtering from Python which brings us to our next topic, filtering data.  It has two main uses, discarding source plus log messages like you don't want to store  debug level messages as storage is expensive and these messages are rarely used.  Another use for filtering is message routing like making sure that all of your authentication  related events reach your scene system.  There are many possibilities for filtering, it can be based on message content, different  message parameters, you can use comparisons, white cards, many different filtering functions  and best of all you can combine any of these with boolean operators to make really quite  complex filters within syslogang.  Finally, you have to store your log messages somewhere, most people are only aware that  they can store log messages to text files either locally or at the central syslogang server.  But there are many more possibilities, you can store log messages to databases, to different  scene systems, to big data like Hadoop, Erasticsearch, MongoDB, to message queuing like Kafka or  AMQP, so there are many possibilities and if none of these fits your needs you can use  Python or Java to extend syslogang with a new destination.  Here you can see a heat map of IP addresses as found by the GIP parser in syslogang.  This is real data, it's from my home router sitting in a quiet suburb of Budapest but as  you can see the network itself is nothing quiet, everyone from around the world tries  to connect but fortunately kicked out by my firewall.  Here I combine sudo and syslogang and send alerts from sudo to Slack in real time.  Sudo logs are parsed automatically by syslogang so all I had to do is add a filter to filter  on my username and whenever I do something through sudo syslogang sends a message in  real time to Slack.  Of course alerting on myself is not much use but you can do the same on your hosts with  multiple engineers using sudo.  So here comes a tricky question, what is common between the BMW i3 and the Kindle ebook reader?  The answer is syslogang.  Both of them are running syslogang.  And most people are not aware of it that hundreds of millions of devices run syslogang.  What else syslogang and sudo used?  Sudo is installed on almost all bsd linux, unix and macOS systems so many devices.  And syslogang is available on most linux distributions and bsd variants.  It's running by default on most bsd based appliances like Freenas or OpenSense.  It's also on Synology and QNAP network attached storage systems and on tourism near firewalls.  I wouldn't be surprised to learn if I learned that it's also running somewhere in space.  So let's see how you can install this software on FreeBSD.  sudo is available in the FreeBSD ports under the security group.  This port is kept pretty much up to date, it follows the 1.9 line of sudo.  If you install the binary package using pkj, it only has the very basic functionality.  But don't worry, most people don't use anymore.  But if you need any of the advanced functionality I mentioned earlier, then you need to compile  sudo yourself from ports.  For example, if you want to enable inserts, you need to compile sudo yourself.  But also if you want held up support, Python or Kerberos support within sudo.  Cisco GenG is also in FreeBSD ports in the sysutils group.  I'm a commentator for this port, so it's also kept up to date.  If you use the pre-built binary package, Cisco GenG provides only basic functionalities.  But define basic, previously we tried to keep the extra dependencies low, so we only enabled  features we didn't need any external dependencies.  But over the years, some extra features were enabled, like DRS, so encryption support is  enabled by default for years.  Last year, two years ago, we enabled JSON support by default, and last year, HTTP support  was enabled by default as well.  This means that without recompiling syslog.ng, you can store log messages to Elasticsearch  port to many different cloud-based login-assess service providers, like SumoLogic or Logly.  For example.  But you still need to compile syslog.ng from ports yourself if you want to enable support  for language pytings like Python or Java.  If you want to store your log messages to databases like different SQL databases or MongoDB,  if you need message queuing like AMQP, Kafka, and to support many other technologies like  SMTP, SNMP, GIP, and more.  Finally I want to show you how to run syslog.ng in Bastille.  But first of all, what is Bastille?  Bastille is an open-source system for automating deployment and management of containerized  applications on 3DSD.  It doesn't have any hard dependencies on any other applications.  The only exception is JIT if you want to use the templates.  And you want us to use a template for syslog.ng as well.  On the next slides I will show you how to install Bastille and get to your first syslog.ng  jail.  First you need to install Bastille from ports.  It's also in the sysutils group.  Then set up Bastille, configure your firewall.  And then create a new jail.  Install syslog.ng using template.  And finally also configure your firewall.  On my slides I will show you only a very basic setup, but there are many more possibilities  like you can use CFS, VNET, and other advanced 3DSD technologies.  So, the latest version of Bastille you can install from ports, freshly updated ports  as it was just released last week.  Just change to the directory, make install clean and enable it.  The simplest setup which works everywhere is to use a cloned interface and use private  IP addresses for your jails and redirect external ports to your internal network using the  PF firewall.  So, the next slide shows you PFConf.  Using this you can protect your host and forward connections to your jails without editing your  firewall configuration anymore.  So Bastille can maintain your firewall settings.  And finally I will show you how to get started with Bastille commands.  As a first step you need to bootstrap a release of 3DSD you want to use.  I used 12.2 and I also bootstraped the CISL GenG template.  Next I created a jail using this release on a private IP address.  Then applied the template to this jail and as a final step I redirected an external port  to the internal network.  Now you are ready to send log messages from your other hosts to CISL GenG running in Bastille.  And now it's time for questions.  Thank you for your attention.  Okay, we're going to switch to live now.  You hear me?  Yes, I can hear you.  Okay, excellent.  So thanks Peter for this great presentation.  Now it's time for questions.  I saw you start answering some of them on the chat.  Maybe if we have other questions.  Someone was asking if using the slack destination is documented somewhere.  Of course it's part of the official documentation but I also have a blog about it and I sent  the URL to the chat.  You can find this blog and many others about how to use CISL GenG on CISL GenG.com under  the community many point and not just slack but many other use cases are described including  the steps how to install CISL GenG on FreeBSD and other operating systems.  So please forward if you have someone who is probably taking questions.  No.  So I think that's probably all.  Thank you very much for your presentation.  Thank you for welcoming me here.  And if you still have any questions, I will stay here for a while and can answer anything.  Okay.  And I hope you will see you next year with another great presentation and probably answering  the questions.  Thank you very much.  And I think this is the end for the BSD Devroom.  Thank you all for being here.  All the presentations and videos will be available on the FOSDEM website.  I think probably today, maybe tomorrow.  And I think that's all.  I hope I will see you next year probably in Brussels so we can share some waffles and  some cup of beers together and enjoy the rest of the day.  Thank you very much.  Goodbye.  Thank you.  Thank you.  Thank you.
sudo_and_syslog_ng_0_179.png sudo_and_syslog_ng_180_527.png sudo_and_syslog_ng_528_1379.png sudo_and_syslog_ng_1380_5219.png sudo_and_syslog_ng_5220_5915.png sudo_and_syslog_ng_5916_8771.png sudo_and_syslog_ng_8772_9971.png sudo_and_syslog_ng_9972_12263.png sudo_and_syslog_ng_12264_13715.png sudo_and_syslog_ng_13716_16175.png sudo_and_syslog_ng_16176_17915.png sudo_and_syslog_ng_17916_22499.png sudo_and_syslog_ng_22500_23855.png sudo_and_syslog_ng_23856_26111.png sudo_and_syslog_ng_26112_28139.png sudo_and_syslog_ng_28140_29159.png sudo_and_syslog_ng_29160_29831.png sudo_and_syslog_ng_29832_31091.png sudo_and_syslog_ng_31092_37163.png sudo_and_syslog_ng_37164_39815.png sudo_and_syslog_ng_39816_40211.png sudo_and_syslog_ng_40212_40487.png sudo_and_syslog_ng_40488_40547.png sudo_and_syslog_ng_40548_40871.png sudo_and_syslog_ng_40872_41075.png sudo_and_syslog_ng_41076_41531.png sudo_and_syslog_ng_41532_41603.png sudo_and_syslog_ng_41604_41795.png sudo_and_syslog_ng_41796_42275.png sudo_and_syslog_ng_42276_43475.png sudo_and_syslog_ng_43476_44255.png sudo_and_syslog_ng_44256_44519.png sudo_and_syslog_ng_44520_45263.png sudo_and_syslog_ng_45264_45311.png sudo_and_syslog_ng_45312_46031.png sudo_and_syslog_ng_46032_46151.png
Hi, I'm Peter Arzhamit, open source evangelist at 1&Entity. Today I will talk about what is new in sudo and syslogangy and provide you with a BSD specific view. I started to use free BSD in 1994. Today I will spend most of my time with sudo and syslogangy. So I will introduce you to what is new with this 2 software and also show you how to install it on free BSD either from binary packages with pkj or combining it yourself from ORDS. Finally I will also show you how to use syslogangy in BSD. So let's start with sudo. What is sudo? I asked this question from thousands of people over the past few years and the typical answer depended on the experience of the person and went into three main categories. For most people sudo is a tool to complicate life. Why do you sudo if you can log in as root or use the su command to change the root? But even seasoned administrators told me that well sudo is just a prefix for administrative commands and only a few people told me that they know some of the advanced features of sudo. So what is sudo? sudo allows a seasoned administrator to delegate authority by giving certain users the ability to run some commands as root or another user by providing an audit trail of the commands and their arguments. So as you can see it's a lot more than just a prefix. If we can believe to xkcd it can even get you a sandwich. Just make sure that when you make a request for a sandwich then you use the sudo prefix. Back to more series topics. sudo comes with a huge set of useful defaults but if some of these do not fit your use case you can change these defaults using the default statement in your configuration. Here are a couple of examples like changing what path is considered secure by sudo, which is environment variables to keep from the user's settings and disabling insults for the user's. You can also make defaults user or host specific. For example the last line of the screen shows how to enable insults for members of the wheel tube. So what are insults? Insults are fun but not always politically correct error messages when someone mistypes a password. It's kind of sysadmin humor. As you can see it's nothing harmful but still some people find it offensive so it's disabled now by default. Another lesser known feature of sudo is digest verification. You can store the digest of applications in this sudoers file and this way sudo always compares the digest with the application before running it. The downside is that it's quite difficult to maintain this database in your sudoers file. On the other hand this way you can prevent modified binaries from running and it provides you with an additional layer of protection if you don't trust your users. Another feature is session recording. Sudo can record everything what is happening on your terminal which is especially useful when you have users which need shell access instead of just some specific commands. The recordings can be played back just like a movie. They are quite difficult to modify as they are not clear text. On the other hand these files are saved locally therefore they are easy to delete with unlimited access. The good news is that starting with sudo 1.9 which was released last year session recordings can be collected centrally which means that anything what a user does is streamed in real time to another location so they cannot modify or delete the recordings. Once you have more than just a handful of machines you want to manage your configurations centrally. Most configuration management systems support sudo but sudo itself has support for centrals. You can store your configuration in eldop which has the advantage that settings propagate in real time and they cannot be modified by users locally. On the other hand there are quite a few limitations as for example you cannot use aliases and if your network is down you might not be able to run sudo. Another feature which was added to sudo 1.9 is python support. Previously you can extend sudo through C based plugins but now you can write your own extensions to sudo using python using the very same APIs. The advantage of python is that there is no need for a dedicated development environment or compiling your code and you can even distribute your python code using a config management system. One of the most interesting APIs to sudo is the iolox API. Using this API you can access input and output from user sessions. And for example you can use python to break connections if a given text appears on screen so it's a kind of data lake prevention or you can analyze the command line what users are trying to run and break the session if someone tries to use error mines fr on the command line. Here is a short python example it's fully functional but of course it doesn't cover any corner cases so it's just to show that it how it works. In this case anytime my secret appears on the screen the session is broken. On the following screen I will show you how it works. I created a file called mysecret in a directory and before it could be shown on screen the session is terminated. Here is the screenshot the user starts sudo with minus s so it starts as shell changes to the root directory lists the directory and can see that oh there is that directory called do not enter it must be something very interesting let's check it out the user changes to this directory and types the ls command but before my secret could appear on screen the session is terminated. Now let's change the syslogangy. First of all what is logging? Logging is a recording of events happening on a computer such as an ssh login message and most people are only aware of this that you can see what happened on your system in text files in the var log directory. So what is syslogangy? It's an enhanced logging domain with a strong focus on portability and high performance in central collection. Originally it was developed in C but now you can extend it in python or java as well. And it has many more features than just simple saving log messages to text files. Let's see the four major roles of syslogangy. The first role is collecting data. We can collect system and application logs together providing quite useful contextual data for either side. It can collect log messages from a wide variety of platform specific sources like devlog, jorma, sun streams and so on. As a central log collector it can collect log messages over the network using the legacy or the new syslog protocol over UDP, TCP and encrypted connections. And it can also collect logs or any kind of text data from applications through files, sockets, pipes and even application output. If none of these fits your needs you can extend syslogangy using python and for example add HTTP server to syslogangy to collect log messages like the HTTP event collector in sprunk. The next role is log processing. You can classify normalizing structure logs with built-in parsers. For example the CSV parser can parse any kind of columnar data like Apache access logs, or can parse freeform log messages like the SSH login message. And there are parsers for JSON format messages, key value pairs or even for XML. And these parsers can also be combined together so we have also parsers for cscool log messages and for many more. You can also rewrite log messages using syslogangy and you don't have to think about falsifying log messages here but for example an animation is required by different compliance regulations. For example finding and overwriting credit card numbers in log messages. You can also enrich log messages at additional fields based on the message content or use the gip parser to add geolocation to IP addresses. Or you can reformat log messages using templates like the elastic search destination needs JSON format field messages, some scene system needs the ISO date format and so on. And if you want you can extend, you can parse your log messages using Python, you can implement any of the above features in Python as well or you can enrich your log messages from databases and also do filtering from Python which brings us to our next topic, filtering data. It has two main uses, discarding source plus log messages like you don't want to store debug level messages as storage is expensive and these messages are rarely used. Another use for filtering is message routing like making sure that all of your authentication related events reach your scene system. There are many possibilities for filtering, it can be based on message content, different message parameters, you can use comparisons, white cards, many different filtering functions and best of all you can combine any of these with boolean operators to make really quite complex filters within syslogang. Finally, you have to store your log messages somewhere, most people are only aware that they can store log messages to text files either locally or at the central syslogang server. But there are many more possibilities, you can store log messages to databases, to different scene systems, to big data like Hadoop, Erasticsearch, MongoDB, to message queuing like Kafka or AMQP, so there are many possibilities and if none of these fits your needs you can use Python or Java to extend syslogang with a new destination. Here you can see a heat map of IP addresses as found by the GIP parser in syslogang. This is real data, it's from my home router sitting in a quiet suburb of Budapest but as you can see the network itself is nothing quiet, everyone from around the world tries to connect but fortunately kicked out by my firewall. Here I combine sudo and syslogang and send alerts from sudo to Slack in real time. Sudo logs are parsed automatically by syslogang so all I had to do is add a filter to filter on my username and whenever I do something through sudo syslogang sends a message in real time to Slack. Of course alerting on myself is not much use but you can do the same on your hosts with multiple engineers using sudo. So here comes a tricky question, what is common between the BMW i3 and the Kindle ebook reader? The answer is syslogang. Both of them are running syslogang. And most people are not aware of it that hundreds of millions of devices run syslogang. What else syslogang and sudo used? Sudo is installed on almost all bsd linux, unix and macOS systems so many devices. And syslogang is available on most linux distributions and bsd variants. It's running by default on most bsd based appliances like Freenas or OpenSense. It's also on Synology and QNAP network attached storage systems and on tourism near firewalls. I wouldn't be surprised to learn if I learned that it's also running somewhere in space. So let's see how you can install this software on FreeBSD. sudo is available in the FreeBSD ports under the security group. This port is kept pretty much up to date, it follows the 1.9 line of sudo. If you install the binary package using pkj, it only has the very basic functionality. But don't worry, most people don't use anymore. But if you need any of the advanced functionality I mentioned earlier, then you need to compile sudo yourself from ports. For example, if you want to enable inserts, you need to compile sudo yourself. But also if you want held up support, Python or Kerberos support within sudo. Cisco GenG is also in FreeBSD ports in the sysutils group. I'm a commentator for this port, so it's also kept up to date. If you use the pre-built binary package, Cisco GenG provides only basic functionalities. But define basic, previously we tried to keep the extra dependencies low, so we only enabled features we didn't need any external dependencies. But over the years, some extra features were enabled, like DRS, so encryption support is enabled by default for years. Last year, two years ago, we enabled JSON support by default, and last year, HTTP support was enabled by default as well. This means that without recompiling syslog.ng, you can store log messages to Elasticsearch port to many different cloud-based login-assess service providers, like SumoLogic or Logly. For example. But you still need to compile syslog.ng from ports yourself if you want to enable support for language pytings like Python or Java. If you want to store your log messages to databases like different SQL databases or MongoDB, if you need message queuing like AMQP, Kafka, and to support many other technologies like SMTP, SNMP, GIP, and more. Finally I want to show you how to run syslog.ng in Bastille. But first of all, what is Bastille? Bastille is an open-source system for automating deployment and management of containerized applications on 3DSD. It doesn't have any hard dependencies on any other applications. The only exception is JIT if you want to use the templates. And you want us to use a template for syslog.ng as well. On the next slides I will show you how to install Bastille and get to your first syslog.ng jail. First you need to install Bastille from ports. It's also in the sysutils group. Then set up Bastille, configure your firewall. And then create a new jail. Install syslog.ng using template. And finally also configure your firewall. On my slides I will show you only a very basic setup, but there are many more possibilities like you can use CFS, VNET, and other advanced 3DSD technologies. So, the latest version of Bastille you can install from ports, freshly updated ports as it was just released last week. Just change to the directory, make install clean and enable it. The simplest setup which works everywhere is to use a cloned interface and use private IP addresses for your jails and redirect external ports to your internal network using the PF firewall. So, the next slide shows you PFConf. Using this you can protect your host and forward connections to your jails without editing your firewall configuration anymore. So Bastille can maintain your firewall settings. And finally I will show you how to get started with Bastille commands. As a first step you need to bootstrap a release of 3DSD you want to use. I used 12.2 and I also bootstraped the CISL GenG template. Next I created a jail using this release on a private IP address. Then applied the template to this jail and as a final step I redirected an external port to the internal network. Now you are ready to send log messages from your other hosts to CISL GenG running in Bastille. And now it's time for questions. Thank you for your attention. Okay, we're going to switch to live now. You hear me? Yes, I can hear you. Okay, excellent. So thanks Peter for this great presentation. Now it's time for questions. I saw you start answering some of them on the chat. Maybe if we have other questions. Someone was asking if using the slack destination is documented somewhere. Of course it's part of the official documentation but I also have a blog about it and I sent the URL to the chat. You can find this blog and many others about how to use CISL GenG on CISL GenG.com under the community many point and not just slack but many other use cases are described including the steps how to install CISL GenG on FreeBSD and other operating systems. So please forward if you have someone who is probably taking questions. No. So I think that's probably all. Thank you very much for your presentation. Thank you for welcoming me here. And if you still have any questions, I will stay here for a while and can answer anything. Okay. And I hope you will see you next year with another great presentation and probably answering the questions. Thank you very much. And I think this is the end for the BSD Devroom. Thank you all for being here. All the presentations and videos will be available on the FOSDEM website. I think probably today, maybe tomorrow. And I think that's all. I hope I will see you next year probably in Brussels so we can share some waffles and some cup of beers together and enjoy the rest of the day. Thank you very much. Goodbye. Thank you. Thank you. Thank you.
Hi, I'm Peter Arzhamit, open source evangelist at packages with pkj or combining it yourself from prefix for administrative commands and only a few people told me that they know some of the the last line of the screen shows how to enable can record everything what is happening on your management system. One of the most interesting message and most people are only aware of this text files. Let's see the four major roles of falsifying log messages here but for example an credit card numbers in log messages. You can also format and so on. And if you want you can extend, can implement any of the above features in Python databases and also do filtering from Python which reach your scene system. There are many that they can store log messages to text files you can store log messages to databases, to different scene systems, to big data like Hadoop, logs are parsed automatically by syslogang so all Both of them are running syslogang. And most syslogang and sudo used? Sudo is installed on very basic functionality. But don't worry, most in FreeBSD ports in the sysutils group. I'm a extra dependencies low, so we only enabled support is enabled by default for years. Last syslog.ng as well. On the next slides I will show the community many point and not just slack but