 I have the pleasure to present to you Sebastian Provost. He is a Linux system engineer with interest in cybersecurity. He also enjoys, in his free time, travel, photography, soccer, reading, history, and gaming. Please give a warm welcome and round of applause to Sebastian Provost. Hello, everyone. Today I would like to talk about tor and configuration management. So first, let me introduce myself a little bit. I'm Sebastian Provost. I work as a Linux system engineer at the company. And we manage around 2,000 to 500 servers with configuration management. Most of them are done by Puppet. It's one of the systems, a few by Chef, and a few manually, which, of course, nobody wants, actually. There are also a few of my contact details on screen, like my Twitter, my pjpiki. So first, let me ask you one or two questions. You don't have to answer. Which one of you actually does some sort of system administrating in his job or daily? So I see that's around almost 50% of the audience. Now, my second question, also again, you don't really have to answer, is which one of you runs a Torrelay hidden service or anything else Torrelated on one of their servers, actually? So that's more than around 25%. It's actually my goal to move people to install a Torrelay if they don't or install more Torrelays if they have only one or two, by showing them that it's easily done in an easy way, in a manageable way, in a way that's easy to configure as well. Also, the reason why I'm standing here in front of you today is because in the past few years, I've learned a lot of new nice people, and they learned to me a lot about technology, and I want to give something back to the community. So let's start. So I will be talking about how we can expand the Tor network in four different stages. So first, how can we do this? I will be explaining this at the hand of configuration management and the advantages of that. Then the advantages of the way we could expand the Tor network, of course. I will also be talking about disadvantages of this, and I will be talking about a module I created for Puppets specifically for this talk, and about features that will be added in the future as well. So let's start. First, we'll be talking about how configuration management with Puppets, why we could do this or should do this, of course. We'll be talking about some specific feature about from Puppets called export resources. I will be talking about some statistics, and I will show you a quick example on screen of how easy it is to do this, of course. So let me give you a quick introduction about configuration management. Configuration management is a general term of a way that you can actually easily deploy configuration or update configuration on different kind of servers or workstations in a network. There are a few different languages or systems for that, like we have Puppets, we have Ansible, we have Chef, Salt, and a few others. I will be going a little bit deeper into Puppets because that's the system or language I'm most familiar with. I've been using it for the last three or four years in my job, beside a little bit of Chef. And Puppets is also, in my opinion, the most easy to use because it's quite clear how you can use it, actually. Some of the advantages of covariance management are reliability, infrastructure installation, rollout of updates, and testing of configuration easier before you rollout. So first, why the reliability? So some people who manage the servers manually and they have managed dozens of servers, they do a lot of things manually, of course. They log in and server, install updates, then do the next all the time, or they create a script for it. But then it's easy to forget to install updates for a piece of software so the server might be left in available states. With the covariance management, it's easier to actually manage all the servers because you can do it from a strength point or from a standalone point. And you can be sure that if you keep the demon of one of the languages running in the background, that the configuration stays as you want it. Because, for example, if someone tries to break in your server and chase a configuration item, the demon of your configuration management system, like from Puppet, can actually revert the change every half hour or 15 minutes or every minute. It's how you chose it, of course. So it makes sure that you can keep your servers up to date with a decent configuration. It's also easy to install new infrastructure, of course. For example, let's say you want to install 20 servers and you have one master server. If you boot up all the servers with a bare agent for one of the configuration items or for Puppet, the central server will recognize the agent. And it will say, OK, I have this agent. It needs some code. I will give you the code that is needed for that agent. And within half an hour, we can have all 20 servers installed without you needing to touch any of the servers again to do some manual configuration. It's also very handy for updates, the rollout of updates. Because, for example, if there's a piece of software to use on all servers and it has a vulnerability, like Shells a few years ago, the availability in Bash, you can actually roll out the updates to fix that vulnerability in, let's say, less than an hour. It takes you not much time to roll out updates because you can just say, on your central server, OK, I want all my servers to install this update from that piece of software, for example, a new version of Tor. And then all servers will see at the central points that they need to install new updates. And if all servers connected to the master server, they see, OK, I need to install update to install it. And within the hour, you can have all the servers running that new piece of software, the new update, of course. And one of the other advantages, specifically for Puppet, in this part, is the testing of the configuration. That's easier before you roll out new configuration. It's actually possible with Puppet to manage different environments. Let's say you have a production environment, testing, QA, and depth environment. And you have a piece of configuration you want to test on a few depth servers before you actually roll out it to production. You can actually tell Puppet, OK, these servers can only use code from the depth environments so we can break them whenever we want or we can play with them. So then if you want to install new piece of software or a new Tor array, for example, you can first put the code in a depth environment, tell Puppet, OK, these servers execute only depth environment. If it works, you can change that code to the production environment. And then roll out all the rest of your production servers, of course. So now we'll talk a little bit about why we should use configuration management to expand the Tor network. I will be talking about the easy deployment of Tor arrays, quick change to the configuration. It's easy to add Sabix, Shinga, or other monitoring to configurations as well. It's easy to install from a central point or standalone. And Puppet has an advantage called export resources. So first, I will be talking about the easy deployment of Tor arrays. Nowadays, you have to manually change configuration from Tor to install a relay. You have to manually change with Nano or VI or some else editor, then reload the service of Tor, for example. With Puppet or any other configuration management system, it's actually easy to make a definition for your Tor array, for any Tor array at all, and say, OK, I want all my servers in a new Tor array. If the definition is upload to the central server or to a standalone server, then the servers will actually see, OK, I have a new definition that I need to install. And within an hour or any amount of period of time that you choose yourself, the Tor array will actually be installed on a server that's asked to code on a master server. This enables us to easily deploy the servers without actually having to change the configuration manually, because Puppet or Chef will, in the end, generate the configuration file for you, for yourself. And you don't have to change the ending manually anymore. For example, if you want to add a Sox proxy in any of your servers for Tor, but you want to add another one with an isolation flag, for instance, it's easy to actually change the configuration item. All servers will recognize it, of course, and change the configuration and generate a new one configuration for your Tor instance, and you have a new Sox proxy with an isolation flag. It's easy to change and easy to manage, of course. Because of the way Puppet works, you can easily say, OK, the Tor module, I want also to be able to monitor with Cybex or Shinga that my Sox proxy works decently or my relay is still running. You can actually generate Cybex or Shinga configuration files with Puppet as well, with some modules that are online available. And then you can push them with a Cybex or Shinga agent to your monitoring server. So you can actually make sure that you monitor all your Tor-related services perfectly. Now, Puppet has two ways of installing systems. You have central points, way of installing system, or standalone. The central point allows us to install everything from a master, one master, a more multiple master servers. And you have a lot of slaves, actually, that have a Puppet agent installed. Those slaves will connect to the master and ask for a code based on the host name they have, or the role, or the location, or anything related that can say to the master, I need this part of the code. And then the master will actually see, OK, I need to give them this part of code. For example, I want to install an exit note on one server, and I give one role an exit note role, or one server an exit note role. Then the master will see, OK, he has an exit note role. I need to give him the configuration items for an exit note. This allows us to easily manage our Tor-related services from a central point of view. You have also a standalone version. That is just, actually, how do I say it? Create a Puppet file with all the definitions you want on the server. For example, in the Ingenix instance, for a hidden service definition, and the packages for Tor and Ingenix, you don't also all the modules. And you can actually install all from one single line, one single comment line on the server with a standalone instance. So I will also talk a little bit about one Puppet advantage called export resources. So Puppet has this thing called export resources. You're able to use this if you use it with Puppet master and slaves, or from a central point of managing all your servers. Export resources is a feature in Puppet that allows you to export resources from slaves to a master. For this, you need to install Puppet database on the master. And for example, if I enslave, that's a Tor-related. And I want to export my family fingerprint from Tor-related to the master. I can do it with export resources. The first line shows the line you use in Puppet code to actually get the fingerprints from the Puppet master back on the slave. And this allows you to actually generate my family configuration item in the Tor configuration file without having to change that manual all the time. This allows you to, for example, install 10 Tor relays. And you don't have to worry about them connecting to each other because Puppet can automatically generate my family fingerprints in a single line in a configuration item. This allows for a little bit more security, of course, and less headaches because you forgot to change the configuration file. And you don't have to worry about that anymore. This is a small example. I don't know if it's readable to people. I'm just an example that I'm used to show you how easy to install Tor Relay, actually. So the first line actually just installs basic default Apache software web server. And the second block, the class Tor block, is just five lines of code. This installs actually a fully featured Tor Relay. But Tor Relay, if you don't configure this exit policy, it can also be seen as an exit node. So at the next block, just actually, again, four lines of code. This installed exit policy that converts our relay into a working relay because you can't get out. You just use it as a relay. Then you also see that we can install Tor Hidden Service. Again, not much lines of code. It will listen to port 80. And it will connect back to a local host port 80, which in this case is our default Apache installation or web server. This allows us to install in the service very quickly. And the last block is actually an example I want to show you as well. Because in the Tor configuration files, you can actually add isolation flags to your SOX proxies. But in a basic configuration file, you don't see it's quite a little bit hidden on the Tor site itself. But this feature is all built in in a module. This adds another SOX proxy on port 9052. And that's two isolation flags as well. Just to show you how easy it is to configure any Tor Relay service with the module I created for this specifically. I have a few statistics to show you how fast it is. With Puppet just changing the message of the day, it takes 0.03 seconds. It's not much. It's quite fast. Installing the Tor package with a SOX proxy in port 9051 plus the message of the day takes less than four seconds. I keep in mind that this is based also on how fast your internet connection is. If it's not very fast, it takes a little bit more time to actually install it, of course. This statistic is actually based on 80 megabit per second connection at my home. Just installing a Tor Relay without a SOX proxy and without the message of the day takes 3.45 seconds. An example I showed you on the slide earlier takes less than eight seconds. Installing Apache, the service, the relay, and a few other parts. So now I will talk a little bit about the advantages of why we could use actually a configuration management to install Tor Relay services and to expand the network. I will talk about diversity, easier management, and less over it during installation and configuration. So let's first talk about diversity. But the diversity, this module allows us to actually, if this module is finished, it will be support multiple operating system distributions. For example, Red Hat-based, Linux distributions, Debian-based, Windows, for example, FreeBSD, It's possible, and other operating systems. This allows us to have a wide variety of different servers or systems that run any Tor Relay service in the end. Because of the easiness of the code and the module, I want to reach a bigger audience. With a bigger audience, then we can also have wider diversity of Tor Relays around the world. Instead of only a few people having a few months of Tor Relays, so it will make the network stronger. I'm talking about more system administrators installing Tor Relay services, maybe small administrators from small, large organizations, maybe some hobbyists that just do some system administration at home. I'm talking about DevOps engineers who also are in contact with configuration management or continuous integration that they can integrate Tor Relay on any of their pipelines. Most of them are home map owners. Maybe people who are in the lab at home to do some research, maybe they can install also a small server with a Tor Relay or a service or anything else, that allows us to make the network stronger and grow more resilient against being weakened. I will also talk about ease management. Puppet code is easily manageable from heat repositories or just one repository, local file systems, or database systems. For example, about the heat repository, if you have a central point of your code, central point master server, it's actually possible to pull the code from heat repository and download it to central master server every few minutes. This makes sure that your code is also the date on the master server. And you just have to push it to a hit and you don't have to worry about putting on the server anymore because the master server will pull it every few minutes with a ground job or anything else. It's also possible from local file systems and database systems. Database systems, it's possible to manage a few configurations from a Mongo database from JSON files included in any sort of database. It's also with configuration management, with Puppet, it's easier to deploy changes and or additions in configuration. We see with statistics that it's quite fast, actually, to deploy changes. And it's without much hassle. So if you, for example, want to change your contact details on all your relays, you can just push a configuration to a hit, central point will take the code from heat and deploy to all your servers, you would have to worry. Within an hour, you can say, OK, all my contact details are updated. It's also easier to manage your family keys. And I've been talking with a few people. And some communities possibly use configuration management already for the management of their tour-related services. For example, if they view exit nodes of a certain amount of tour relays, it's easier to manage them with some configuration management systems. There's less overhead for installing and configuring your relays and your tour-related services because the first step isn't very big. It's a small first step. You just need a few lines of code, install Puppet on one of your servers, execute the code, and you're done. If you use Puppet, you don't actually have to manually configure your tour-related services anymore. You have to configure, you do a few lines of Puppets, and Puppet takes care of the rest. There's easy configuration of SOC policies, exit policies, execution and services, exit nodes, or relays, actually anything you want. There are two disadvantages I've been thinking about as well. One of them is easy coding control of hundreds of relays and centralization. So the first item is the control. The downside or more than one downside of the easy installation procedure is that easy coding controls of hundreds of new relays, exit nodes, hidden services, or anything else. This might result in a possibility of one or more civil attacks or some other attacks because if you control a lot of nodes, that might be quite dangerous actually. One of the other disadvantages is that system administration can install more relays, exit nodes, or hidden services fastier, easier, and with less hassle so they might be convinced to do it a lot more. This might result in actually more single point of fails, maybe, because, for example, if you have a city administrator who decides to add thousands relays at one point, of course, if the relays integrate the network and they're fully used, the network grows stronger, but what if it disappears and all these relays disappear with him as well? The network will grow weaker again because his thousands relays are disappearing. So that's one of the downsides of the easy way of installing torus related services because he has management because it's easy to add quickly another amount of relays or exit nodes and we need to be more mature about this and know what the impact is if you install too much at one point, what impact might be on the network. So I will also be talking about the puppet module I've created for this. I've been looking into all the puppet modules for Tor, there are a few, but they're also basic. They do a basic installation of an exit node or a hidden service or a Tor relay or anything else related, but they don't necessarily implement like extra features or the hidden features like the isolation flags. So at the roadmap, there are a few things like export resources that feature will be used quite fast in the future. I'm actually working that right now. It will be released as soon as possible. At this point, the redhead-based distributions and Debian-based distributions are actually supported mostly but my goal to actually support this module are as much different operating systems as possible in the future, which include also Windows, but I don't know who to install relays on Windows anymore. I will also take care of single-comment execution scripts that download all necessary tools to install an integrated service with this module. I will also prepare some guides and examples so people are more convinced to follow the guides and to install everything and to start experimenting with different features. This module will also be available on Puppet Forge. It's the central site where you can upload modules that all the people can use in the future as well. And at the bottom, you can see the link of the hit-and-pull story where it's stated, of course. And this allows us in here, you can actually see, I will create a sort of Kanban board or something related to that with different steps or different feature plans where you can see the progress of the features. Well, I'm also inviting you to look at the code and to pull some issues or some feature requests if you want some, of course. I'm also giving tomorrow a small workshop about this. I will give a quick introduction in the specifics of Puppet, the basic specifics. And after that, I will work with you to install a hidden service or a relay, anything you want on a workshop. To show you, it's actually quite easy. Very easy and you're all invited. I'll prepare some virtual machines that you can use so you can experiment so you don't have to install anything on your laptop so you don't have to mess around with any settings. This was my talk. I thank you all for listening and if you have any questions, feel free to ask them. Thank you very much, Sebastian. Oh, questions. No questions. Nobody understood anything. That's always my fear when the audience never asks, is like. Or everything was perfectly clear. Of course, you have a community of hackers trying to learn. So, first question. Are you taking into account that running hidden service on a relay is potential bad practice? Do you have several roles in account for running separate nodes for only hidden services? I didn't understand the last part of the sentence. Can you repeat, please? Do you take into account that you make a separate role just for only using a tour as a providing a hidden service? Yes, of course. It's actually easy to make sure that to create separate roles based on certain configuration items in Puppets so you don't mess around with hidden services that combine with relays. You can change it all the way you want. Okay, thank you very much. No problem. Any more questions? No. Questions, please. Perfect. I have one question on the configuration manager and it's the fact to say it can recognize changes and then it resets you back to the whatever you have chosen. Does it notify you that it was changed without your authorization or something? Normally it doesn't, but I assume that it shouldn't be too hard to actually create an extension of Puppets that nullifies you of changes without you knowing it. Also, in general Puppets, if it changes something, it will save the logs from the Puppet execution in the syslog. So if you monitor your syslog, you actually see what happens with Puppets if you're not around and see if it changed anything. So essentially you could already see it, but it's not that hard, I think, to create an extension that enables you to be notified of changes in the configuration without you knowing it. Thank you. More questions, anyone else? Well, if there are no more questions, then we can thank the speaker again. Please give him a round of applause.