 Je suis Mathieu Herb, je ne parle pas d'un développeur d'OpenBSD, mais d'un peu plus d'utilisateurs d'OpenBSD dans mon travail régulier. C'est pourquoi les logos ne sont pas les logos de l'OpenBSD, comme pour l'autre parler. Dans mon travail régulier, je travaille dans la recherche d'ingénieurs de la classe de CNRS. CNRS est une agence de recherche publique en français. Ils couvrent beaucoup de domaines différents, d'histoires, de sciences humaines, de mathématiques, de robotiques, de sciences fondamentales, etc. Dans mon lab, on travaille avec des sciences d'ingénieurs, d'automation, de sciences computers, de robotiques et d'électroniques. Je travaille deux choses dans mon travail. J'ai fait un PhD dans les robotiques longues, et je travaille avec les teams de robotiques pour leur soutien avec des systèmes d'embodée. C'est la base de Linux, et le reste du temps, je travaille pour l'administration générale de la lab, plus spécifiquement en charge de sécurité. J'ai fait aussi quelques autres choses, comme je l'ai dit. Mais ici, ce qui est intéressant, c'est le lab, donc mon lab network, et ce que nous faisons, en utilisant les firewalls d'OpenBSD, là-bas. Donc le lab, c'est un lab avec 650 personnes permanentes, plus un nombre de PhD étudiants, il y a environ 100 PhD défenses chaque année, et aussi beaucoup d'interne global, il y a presque 300 personnes arrivent et 300 personnes vivant le lab chaque année. C'est donc beaucoup de turnover. Comme je l'ai dit, nous avons 6 départements de recherche, nous avons plusieurs secteurs de recherche. C'est tout pour moi, un set de machines que l'on hoste dans notre own machine room. Nous avons des services de storage, plusieurs clusters de virtualisation, ralentir either VMware ou Proxmox. Nous avons des clusters de computer délicatés, des servers backup, etc. Et globalement, pour toutes les personnes, nous avons environ 2000 end-devices connectées à la network, c'est-à-dire la station, les laptops, les tablettes mobiles et plusieurs équipements de recherche. Dans notre lab, nous avons des projets de sécurité sensibles qui ont des nécessaires spécifiques en termes de sécurité, pas seulement sur la computer et le point de vue network, mais aussi sur la sécurité physique, etc. Nous avons été utilisés par les BSD Firewalls depuis presque 15 ans, depuis 2009. Je l'ai présenté à la première fois en français en 2011. Si vous avez les slides, c'est un lien à la présentation que j'ai faite en 2011. Une autre chose intéressante, c'est que même si nous avons des labs de l'air avec beaucoup d'IPv4 en espace, c'est-à-dire 16, nous avons aussi décidé de déployer l'IPv6 depuis longtemps, nous avons commencé en 2004. Toutes les choses que je vais présenter ici ont besoin de travailler avec l'IPv4 et l'IPv6. Il y a été des choses intéressantes dans le passé, mais aujourd'hui, c'est presque complètement transparent. Nous avons aussi utilisé l'IPv4 pour d'autres choses, afin d'essayer d'avoir une masse critique, et je vais revenir à cela dans la conclusion, mais pour moi, c'est important que je ne sois pas le seul, le seul l'IPv4 qui sait comment ce système fonctionne, c'est important d'enseigner à d'autres personnes dans la team de sisi, comment installer, comment dégrader, comment fixer les choses dans l'IPv4. Donc, une de les moyens pour atteindre cela est d'avoir beaucoup de services différents, selon l'IPv4, pour que beaucoup de personnes soient intéressées en utilisant, installant, upgradeant l'IPv4. Nous avons réunit nos services d'INS, les services autoritatifs et les services de caching sur les machines virtuelles de l'OPENBSD. Nous avons réunit nos services SMTP sous l'OPENBSD, nos services NTP en utilisant l'OPEN NTPD, notre service DHCP, le service de l'OPENBSD DHCP. Je ne parle pas de ces détails dans ces slides, mais le lien entre le service d'OPENBSD DHCP et l'IPv4, c'est ce que l'on est capable de publier la liste dans le table de PF pour que vous puissiez bloquer toutes les IPs non allocées en utilisant le PF, c'est bien. Nous avons une web proxy, et des profs d'artwatch, aussi, tout en utilisant l'OPENBSD. Les architectures d'architecture de notre réseau ressemblent à ça. Nous sommes connectés à l'Internet avec Renataire, une éducation de la France et une étude de recherche, le bunch français de géants. Nous avons des zones DMZ, les zones militaires, même si nous ne sommes pas un lab de recherche militaire, mais tentant de trouver un autre nom n'a pas travaillé trop bien. J'ai tenté de dire une zone d'opening, je n'ai pas travaillé. Nous avons quelque chose d'internant, et ces zones circulèrent dans la confusion pour bacteria de pain carpe, open bsd. qui est un Linux pour raison d'au-delà de mon scope. Donc, dans ce cas, je suis fait presque avec la présentation générale de l'AS. Maintenant, je vais se concentrer sur quelques remises en PDF et en Carp, et ensuite vous montrer comment nous configurons les choses en utilisant les domaines routiers, qui sont assez intéressantes. Ensuite, je vais donner des réponses sur nos expériences currentes avec ces systèmes. Et la dernière partie, je vais vous montrer un moyen d'expérimenter avec ça, avec un setup que vous pouvez utiliser sous un VMM, pour expérimenter sur un laptop OpenBSD avec 3 VMs, pour tester des choses dans un setup qui est assez près de la production setup. Donc, quand vous êtes en train d'utiliser une partie de l'appareil sur Carp, il y a une grande issue que nous avons faite pendant un nombre de années, c'est que l'inactif de l'appareil, qui est en state de backup, à un niveau donné, n'a pas d'accès à l'accès de l'appareil. C'est parce que l'interface de l'appareil et l'interface de l'appareil sont en state de backup, et pour l'interface de l'interface de l'appareil, vous pouvez aller autour par allocer un adresse spécifique à cet appareil, mais sur l'outside, ce n'est pas possible. Le renataire ne nous permet pas d'avoir plusieurs adresses publics sur l'extrême porte, donc il n'y a que l'adresse public Carp. Nous verrons que dans cette organisation, c'est encore plus compliqué pour l'interface de l'appareil, car depuis que nous avons beaucoup d'interfaces, le management de l'appareil et l'interface de l'appareil sont très difficiles. C'est ce que je dis dans ce slide. Et pour tout cela, la notion de l'interface de l'appareil est une bonne approche pour fixer cet issue. La idée de l'interface de l'interface de l'appareil dans OpenBSD, pour ceux qui ne le connaissent pas, c'est un moyen de séparer complètement un set d'interfaces de l'interface, pour isoler l'interface de l'appareil. Donc, chaque procès dans le système est lié à un domaine d'interfaces, et un nombre de tables d'interfaces, mais généralement, vous avez juste un domaine d'interfaces par domaine d'interfaces. Et donc, ici, pour exemple, c'est quelque chose qui s'occupe de ce que nous faisons. Nous avons un domaine d'interfaces dedicé à l'interfaces d'interfaces. Donc, nous avons deux interfaces dans cet domaine et les procédures qui sont nécessaires ne voient que ces deux interfaces. Et un autre domaine d'interfaces dedicé à l'administration avec d'autres procédures qui ne voient que ces deux interfaces et pas les deux autres. Et si vous voulez utiliser des domaine d'interfaces, quelques remandements, vous specifiez ce que l'interface soit attachée à un interface ou plus correctement, à laquelle l'interface est attachée à l'interface d'interfaces dans le file hostname.ef par ajouter le nombre d'interfaces n, que vous voulez attaquer à ce domaine. Vous pouvez voir quel est l'interface de la procédure pour votre chelon de current en utilisant id minus air et route-tn-exec vous permet de lancer un nouveau procès attaché à un domaine d'interfaces spécifié par l'interface n. Vous pouvez aussi lister toutes les procédures avec le table d'interfaces d'interfaces px-o air et pour le start-up général des démons, vous pouvez spécifier le domaine d'interfaces qui va filer par spécifiant la option d'interfaces d'interfaces px-o air et cela va faire les procédures à la procédure de l'interfaces d'interfaces px-o air avec les correctes options. Si vous avez besoin de repler les procédures entre les domaines routés qui est normalement forbidé, vous pouvez utiliser le procès px-o air Donc, si nous voulons utiliser ceci pour résoudre le problème de la fierté, nous pouvons juste couper le design des roues larges des roues du Muzumi Percisco ou de quoi que ce soit, par créer un plan de route spécifique, ou un domaine de route spécifique, ou un domaine d'administration spécifique, ou un domaine de route spécifique, pour le contrôle et l'administration. Le contrôle plan va toujours avoir une route spécifique accessible. Le plan de route spécifique va être actif ou inactive, et il peut perdre ses accessoires, mais nous ne sommes pas obligés. Et l'idée c'est d'utiliser le domaine de route spécifique 0, donc le domaine de route spécifique pour l'administration, pour que ce soit le plus transparent possible pour l'utilisateur. Quand vous serrez dans votre route, en fait vous ne verrez pas le plan de route spécifique, mais vous pouvez voir le processus de route spécifique dans la partie d'administration, et vous pouvez faire normalement ce type d'administration, appliquer des patches, etc. Donc, en pratique, cela donne un schéma avec deux routers. Dans Violet, nous avons le plan de route spécifique, et dans Red, nous avons le domaine de route spécifique. Je vais montrer cette figure un peu plus tard, mais nous avons les interfaces PFC, nous avons les interfaces externes, créant un groupement de groupes de route spécifique 0, avec les adresses IPv4 et IPv6, les adresses internelles de route spécifique 1, avec des adresses IPv4 et des adresses IPv6, et un plan d'administration et un autre plan d'administration. Quand vous voulez installer cette configuration, ce n'est pas très difficile, vous commencez par connecter la interface utilisée pour l'administration, puis vous installez OpenBSD, USB Key, CD-ROM, image, ou quelque chose, normalement, et vous configurez seulement cette interface. Donc, dans mon cas, la figure que j'ai montée avant, c'est Violet 3, la interface, et quand vous avez installé les machines, vous pouvez configurer le reste, la route domaine 1, l'interface, la pf-sync, etc. Vous pouvez aussi préparer un nouveau firewall complètement offline, vous avez besoin de configurer la route domaine 0, vous pouvez pré-configurer tout dans la route domaine 1, ce n'est pas connecté, mais il n'y a pas de problème, il n'y a pas de paquets pour l'administration, donc vous pouvez écrire toute la carte de la pf-sync, les interfaces, les règles de pf-sync, et tout, et quand tout est déjà connecté, on va commencer les paquets de route. Donc, pour essayer d'être utile, j'ai démontré toute la configuration, je ne vais pas aller dans les détails, d'abord, c'est CTL.conf pour enlever la carte, les interfaces physiques de la route 0 et de la route 1 sont passées, avec ces deux lines, la route 2, qui est utilisée pour pf-sync, on va mettre l'adresse non routable pour pf-sync, pf-sync transport currently only works with pf-sync, donc, oui, c'est une bonne chose. Donc, ici, et nous ne sommes pas très carets, puisque c'est un short, c'est un lien local, ça pourrait même se passer avec quelque chose comme un IP, ça ira aussi travailler. Ensuite, nous pouvons installer les interfaces de pf-sync sur les routers, donc pf-sync 0, pf-sync 1. Ici, j'ai pris des exemples d'adresses pour pf-sync interfaces, pf-sync 4, pf-sync 6. Et la seule chose qui est un peu spécifique et que vous devez savoir, c'est que le vrai routier en utilisant votre provider de pf-sync, vous ne pouvez pas utiliser ATC MyGate pour spécifier cela, parce que ça va être utilisé par les routiers de pf-sync 0. Donc, vous devez ajouter les commandes chibons pour installer la route pour pf-sync 4 et pf-sync 6. Dans les interfaces internaux, il n'y a pas de route pour pf-sync 4, c'est plus facile. La deuxième route est exactement la même que pour l'adv.sq parameter, pour que la deuxième route reste inactive comme possible, mais le reste est exactement la même. Si ce n'est pas un erreur pour pf-sync, c'est la même file sur les routiers. Vous devez juste dire que c'est dans le domaine 1 et que c'est utilisé pour l'interface. Ensuite, j'ai ajouté un simple pf-dontcon file, mais c'est vraiment très simple et simple. Si vous voulez avoir plus d'insights dans les rôles de pf-sync, c'était un bon tutoriel un peu plus tard. Je ne vais pas dans ces détails. Et c'est Peter's Book. Vous devez faire des services sur le plan de data. Par exemple, si vous voulez utiliser ça pour un simple pf-dontcon ou un pf-dontcon ou un pf-dontcon, vous devez faire le pf-dontcon pour l'IPv6 et vous devez prendre un ds-servers et peut-être un tp pour avoir quelques ds-servers pour votre plan. D'ici, la seule nouvelle est que vous devez penser à les routiers en domaine 1, pour que ces services soient visibles par vos machines internes. Oui, En OpenBSD, il y a aussi des features de redundancy qui vous permettent de vous dire quel est le master, quel est le slave, le service de l'HCP. Donc, ce sont ces options minus Y. Juste le doc. Donc, après ce que nous avons fait, nous avons quelque chose qui marche à la fin en utilisant ces types de set-ups. Des feedbacks sur ce que nous faisons. Les machines externes sont des machines physiques. Aujourd'hui, elles sont de l'air 340. Ces machines sont trop grandes pour ce qu'elles font. Mais, selon la structure du marché public, quand vous travaillez dans une recherche publique dans l'institut, c'est difficile de acheter des machines plus petites. Donc, c'est ce qu'on a. Nous utilisons l'Intel X710 GB en utilisant les ports SFP Plus pour la paquette pour l'arrivée. Donc, l'internel et la connexion pour notre MZ. Et l'Intel X500 50 cars avec des interfaces copper pour le PFC, et le management. Et notre PFC rule set est de 320 règles. Ce n'est pas beaucoup. Mais, il y a encore de nombreuses stations utilisant ces portes SFP. Il y a environ 40 000 états dans les portes SFP chaque fois durant le jour. Les portes SFP sont un peu plus intéressantes parce qu'on a décidé, il y a quelques années, de les virtualiser complètement. Donc, ils sont en train d'utiliser l'infrastructure de la VMW en utilisant beaucoup de portes SFP pour séparer toutes les portes SFP. En pratique, nous avons 26 villes currently in our land connected to those two virtual machines. So this provides an impressive level of redundancy because when a virtual machine crashes VMW is able to either move it to another supervisor or to restart it. Then we have redundancy with carp. So it's really hard to have something completely broken there. The rules and the internal firewalls are a bit smaller, but not much. And also they run about the same number of states in general production. And currently we are running OpenBSD 703 stable, so the latest stable version on all those four machines. Our PFR set basically blocks everything in bound which allows only allow some specific traffic to web servers, SSH servers, some specific services open to only to some of our partners and so on. And lets most of the egress traffic going out. We are doing something about people doing brute force attacks on passwords by using the max con rate down by moving them to a specific table where they are blocked for one hour and that works pretty well. We also have some custom fail to ban rules when a fail to ban server running on a Linux machines figure out someone who is doing too much traffic it can ask PF to block this address rather than using a local IP filter rule. And we are using PF log also to log some of the traffic that our upper management asks us to log on outbound traffic. I wrote a small script that is completely trivial to check the syntax of PF rules and to copy the pf.conf rule to the secondary firewall if everything is okay. It's just something that everyone needs so I decided to put it on a slide so that it can be reused. With IPv6 our rulesets get a bit bigger because we have to duplicate the rules for both IPv4 and IPv6 address for each service that is allowed or banned. I hope that sometimes we will be able to unplug IPv4 but it's not coming very fast so I don't know. There is one thing that I didn't investigate too much but basically the Karp KIPA live packets are running both in IPv4 and IPv6 and this is a bit redundant I don't know if it would be possible to only run one of the two protocols but well it's not that much traffic it's not really a problem pf.sync is IPv4 only and the other thing that used to be a problem but works better now is that RID doesn't like to listen on an interface that is down and so I needed at some point but I think it's not the case anymore but I forgot to recheck I needed some IFCID rules to start RID on the secondary firewall whenever it becomes the main one because otherwise the RID demand so the router advertisement demand for IPv6 dies when the firewall is inactive somewhere about the use of Karp you want redundancy but what exactly do we need redundancy for? in fact the hardware is so much reliable that the redundancy to prevent hardware failure is not really an issue in 15 years we have almost never experienced any kind of hardware failure where Karp could have helped in fact Karp is just something very very comfortable to be able to upgrade firewalls without interrupting the traffic to be able to do some tests on a machine or at the beginning at least 15 years ago we still had a number of bugs in OpenBSD and from time to time the main router would just freeze but it's not a problem the second one would take over and just need someone to notice that we switch to the backup router to actually reset the main one so that it start again but in the recent years I've never saw such kind of freeze and it's not needed anymore it may come back at some point given all the hard work OpenBSD is doing to unlock the network stack to allow it to run on several CPUs maybe there will be some bugs in the future again but really thinking about Karp for our hardware failure first it's much more harder than you think because there are a lot of other typical setups with switches and so on and in practice it's not really the issue we had one strange bug where our upstream provider router stopped to answer IRP requests and so it lost IPv4 connectivity but IPv6 was still ok and the Karp packet would still work because of the rate where they are exchanging the ARP address for those who would never expire and well Karp was not useful in this case we really needed to have the operator reboot so that ARP would start again during our 15 years we went from a single attachment configuration to a double attachment so we have also a bit more on the upstream links we are using 2 different paths for the fibres because this was at Toulouse one of our main source of stress is that this link here goes through a bridge that was under heavy constructions for several years and almost every morning we were fearing that someone would cut the fibres in the bridge so now another pass they can cut the fibres in the bridge we don't care anymore but still the Karp packets are not going this way they are just going this way so we don't really test the availability of the upstream routers and to conclude I just want to present some setup that you can run on an openBSD machine with 2 virtual machines for the 2 routers plus 1 extra virtual machine to emulate a client in the LAN that allows you to run this on your laptop I have an almost working setup on my laptop that I re-did yesterday evening but I probably don't have time to try to show it so it's again the same that the one I presented earlier with 2 virtual machines this is why earlier I used the VIO as the interface names and basically you just need to setup vm.cons that will define the 3 switches we are using the new virtual interface bridge written by but it also works with regular bridges I think that the VEB is just a bit lighter than regular bridges for this so I just use VEB so I have the external switch the internal switch and the PFC switch with VEB012 then the vm.configuration for the first router nothing fancy here we have 3 interfaces connected to the 3 bridges that we defined earlier and one local interface which is going to be the LAN interface for management and I am the owner of this vm so I don't need to run Duas or anything to start them I can just start vm.ctl as Matthew on the machines exactly the same file router B with just the name of the image that changes and the name of the machine and basically that's it I showed you the configuration files that you need on both routers earlier and you can start the VMs and you have some working setup and so to conclude running OpenBSD firewalls in my lab has been quite successful for now we see no reason to change this we are now on 10 gigabits uplink but for us performance is not really an issue the current state of the traffic is that we are around 1 gigabit average on a day sometimes we go up to 2 or 3 gigabits but not much more our OpenBSD firewalls running on the Dell machines or the internal ones on our VMWare infrastructure are perfect we cannot see anything where we could say ok this is where it's pf limiting our performance if that should happen we know that there are solutions we can try to run active-active firewalls or we can switch to I know I don't want to but we have a few DDoS attacks that were successfully blocked that means that we saw the huge amount of incoming traffic but nothing on outgoing traffic it was still going fine I really like all the the tools bound to pf to look at the traffic to look at the states and so on figuring out what are the data flux the flows that are going in and out for debugging purposes and so on it's nice, it's text-based but it makes things easier to pass by to write some tools, some scripts to do some statistics and so on and as I said one of the main concern for the sustainability of this kind of setup is to create stuff that knows about OpenBSD and is able to how to say it to do some things when I'm not here or since I'm coming closer and closer to the retirement when I won't be there anymore I hope that I will not just do expensive stuff that they can still continue running this and also when we need to replace the machines it's always a bit difficult to make sure that the new hardware is going to be compatible with OpenBSD for example the current one the Intel 700 something cards when we set up we needed to run OpenBSD current the stable version but that time didn't support those cards so for some a few numbers of months we were running current and upgrading every week until the release that supported it came out and I don't know for the next generation of 10 or 20 giga cards that we that we need to to buy and basically that's it if you have questions yes Henning so I'm I'm a bit surprised about the hardware issue because I have not run into a single piece of server hardware in like a decade that cause problems so at worst you may be forced to run current for a couple of months I have also for the mail server we have a physical machine and the latest one that we bought in the always with the constraints of our public markets as some Broadcom cards that are not supported at all so I needed to buy another Intel based PCI card to replace the Broadcom one and I know that whenever I'm going to call the support they will say well but there is a non supported card in this machine it's normal that it's broke so I need to think to remove the Intel cards to run the DAGs I find that use of running as you say that basically gets you to a state like the really really really big routers that separate control and administrator packet flow so that's actually really interesting really good you can usually get around reachability issue by assigning more IP addresses if you have done, which is a limitation and you're totally right you gotta look at the entire setup because very often I very often see setups for the open beast the machines are redundant but the switches are not guess what dies any other question do you use anything for version management of your firewall configs and stuff like that for change tracking or yes for this we use Git but not in a very clever way we just commit things locally to Git and push it to a remote repository to archive them but then all the commits are done by root which is not optimal but do you use anything but conventions and processes to keep the redundant firewalls and same configuration wise well mostly the script that I show you that is used to upgrade the rules we never edit anything on the secondary firewall we just edit them on the main one and push to the one using my script knowing that the script is available on both machines so if for some excellent period of time we need to use the backups switch it will try to push it to the master switch but this is also not perfect if one of the firewall is done for too long then you will need to synchronize them manually when it comes back but well since it's something that almost never happened in 15 years thanks Matt for the talk just a quick question you know when you're thinking between the A and the B firewall how do you deal with different interface name configs or different IP addresses you know on the individual well since we bought both machines at the same time so the interface names are the same what I meant was like different IPs you know the real IPs and the systems being totally different well this doesn't appear anywhere in our rules so our rules just have the car addresses or IP addresses from the different services so do you make use of pf anchors to keep even parts of a ruleset organized ? not in those cases I'm using anchors on the visitors firewall because we have some constraint to shut up this network outside workshours so there is an anchor there that is used to shut down there is a use of anchors that almost nobody makes use of but that I absolutely love the anchor statement you can put all kinds of statements on there like anchor foo from or anchor foo to port 80 that one is actually pretty good for performance because you only enter that anchor for let's say you have an anchor for your web servers so you only enter the anchor for port 80 and 4.3 and inside the anchor you just list the appearance of stuff like that almost nobody does that but it's super convenient the most convenient one is a very very early anchor anchor quick catching all the packets to the local machine I prefer to use one anchor per routing domain or per address family that's something to try for our next talk