 Alright, good afternoon everyone. My name is Eric Garver. I am the current Firewall D maintainer. This talk is about Firewall D and what's been going on for about the past 18 months. It also covers some future plans and potential features. So, I'm going to discuss a lot of features and I hope this doesn't make the deaf people mad, but I'm okay with since we're going to discuss a lot of features, if you have a simple question in the middle, I'm okay with it. But otherwise, if it's a long question, complex question, please wait till the end. Okay. Alright, so a quick information here about Firewall D, just to make sure that it's on the same page. Firewall D is a zone based firewall abstraction for NF tables and IP tables. It provides some parameters like services and ports and also adds some more network level things like port forwarding and masquerading. It also contains a simple language for custom rules for more advanced use cases. There are two main interfaces, a CLI and a GTK GUI. It also has a D-Bus interface for more programmatic interface. Interestingly enough, both user interfaces use the D-Bus interface. It is the default firewall for REL, Fedora and SUSA and it's available in many, many other distributions. So as I said, a very busy 18 months. Here's some random statistics I pulled. Most of these come from the Git log. So over 18 months, we've had 40 unique contributors upstream. A lot of those, yeah, so these are actual pull requests upstream. Interestingly enough, 17 of these are repeat contributors, which I thought was really cool. So some diffs there if you're really interested. A bunch of 65 pull requests and a bunch of 89 plus issues have been closed in that 18 months. And lots and lots of new service definitions. So that's things like your one line command to add MD&S SSH, so a lot of new services. The main reason we're here is to talk about features. So 18 months, all these are probably more notable things that have been added in 18 months. All of these will be in 0.7 which will be released someday. I'm not sure when. They'll also be in REL 8 and Fedora 31. These first two are very large features. They have their own slides, so I'll only briefly mention them right now. Those are NF tables back end and rich rule priorities. So I'm actually going to jump down to the third bullet. So there was quite a bit of improvements with network integration. Arguably these could be called bug fixes but they're significant enough I add them here. There were some scenarios or certain for example interaction with Docker. You know, if you add a Docker interface sometimes you can resupply RLD and it wouldn't be re-added to the Xenon property. So features, bugs like that have been improved. Next bullet here is a 64 address filtering. So this is a feature that actually existed in network scripts. It had been there for at least a decade and as you may have heard through other talks, network scripts are kind of on the out right now. So this was a feature we decided it would be nice to have in firewall D. So this has been added. This is basically a specific set of IPv6 address, destination address where we filtered. Next bullet point is the CLI command or CLI option check config. This is basically config validation. In the past users have done manual changes to XML configuration and they restart and find out it's not valid. All in all that's not a bad thing but the bad thing was that's hard to figure out. Basically they had to go dig through logs to find that. So one feature that was added is a check config option. So basically you can make all your changes, do a firewall config, check config and find out not only XML schema issues but some semantic changes like you're trying to use a service that just simply doesn't exist. So a good use case for this is you had a config they used on one box or a different version of firewall D you can bring that over, run a check config and make sure it validates against a different version. The last line here is a new global config called flush all on reload. This mostly affects users of direct rules and people that like to do run time only changes for interface to zone bindings. There was actually a mostly undocumented behavior where direct rules, run time direct rules and interface bindings would actually be retained on a reload. So a lot of times I was surprised so basically if you can't fix it feature so the new behavior is everything flushes as you most people, many people would expect. So all those direct rules, interface bindings that are run time only will fully flush but if you like the old behavior you can change this to know and get it back. So moving on to the big ones here let's talk about the end of tables back so this is going into the 0.6 release which is a little over 6 months old, maybe 8 months old. The big question is why? There are many reasons I highlighted some here. A big benefit is we can do combined processing for both IBV4 and IBV6 I don't know how familiar everybody is with the back end but previously you would have to add if you were to enable allow SSH through you would have to add that for there would be an entry for IBV4 and IBV6, both IB tables and IB6 tables. With NF tables we can handle both in the same rule. Another reason is NF tables has built in sets so don't need IB set We can use the NFT binary to manage all our rules, all our sets, IBV6 and IBV4 with single interface, we don't have to deal with multiple tools. Another nice thing about NF tables is with IB tables there was basically global tables and it didn't cooperate well with multiple users so if there's firewall D and somebody else trying to use IB tables a lot of times how you dealt with that is you flush and apply everything. With the NF tables back end, NF tables actually has what NF tables calls tables as more like a namespace so we can actually create a firewall D table and not touch any other rules that exist in NF tables. When firewall D comes up it doesn't care if there's other rules there so in essence what this allows is you can use firewall D and in combination you can use your own custom table and firewall D won't touch it. When it does kind of upgrade for you, anybody users, this upgrade should be seamless. What I mean by this is we still support all the features pre-NF tables support. That includes all the primitives, all direct rules direct rules are still supported so you can still have, use your NF tables back end with your IPv4 direct rules. So last line, again, don't panic. IP tables back end is still supported, fully supported upstream if you want to use it, it's still there. Just got to change it. If you would like to know more information about this I do post regular blogs for major features so there's a link here at the bottom there's more specifics in there if you really want to get into the details or further questions or email me, that's fine or IRC. So if I have any quick question there it's a stop point. Alright next major feature would be rich rule priorities. So as I mentioned at the start firewall D has custom syntax for rules for more advanced users that's what we call rich rules. In the past, based on what type of rule you had, if the rule was allowing traffic or denying traffic it would automatically be sorted into a position in the rule set. Basically an allow to allow it would, yeah, you had no control of where the rule got placed within the firewall D's rule set. So that's what this feature is all about is adding a priority field allowing user to arbitrarily order these custom rules. And one consequence is that is it allows you to freely mix your log rules, your deny rules, and your accept rules. Previously those were sorted by firewall D and had no control over which order those were running. This also allows you to place rituals before and after firewall D's other primitives. So in the past if you were to add a service and a rich rule that allowed certain traffic those were treated equally. Which everyone got added first that's going to get executed first. With priorities we can actually control that order. And of course we're backwards compatible. If you don't specify priority you still get the old behavior. This feature also has its own blog post that goes into more low level details. What it looks like actually looks like in an F table. So if you're curious please go look at it. So here's some examples of that. These are fairly small ones because it's hard to fit on a slide. But here's the syntax so you'll see this is what's all been added and this is again the ritual syntax. And it's basically just another field like how you would specify the family. In this first example it's basically a catch all rule that you would basically right before the policy would have happened you would put this there if you wanted to catch unexpected traffic. Basically you want to see anything that comes through that wasn't caught by any of your services you're allowing. That's a way to just kind of flag unexpected traffic. On the second example it's allowing the service for a specific range by the addresses. And then for everybody else we're going to log and reject it. So allow somebody but scream loudly for everyone else. So there was a handful of features that were not necessarily user facing but I think they're important The biggest one and I put this on this slide because it's not user facing but heavily benefits user is there was a lot of work rewriting the test suite and adding lots and lots and lots of new tests. As you can see the third bullet says we're going from 6 test groups to well over 120. Also as part of this effort we added CI for every commit, every pull request. So let's try to CI up on GitHub. Every time somebody makes a PR we'll know how good it is. This last bullet here is source code checking that again runs part of CI. So if anybody wants to fix Flake 8 source code contact me after this talk. For this set of work there was also another blog post talking about the test suite. This is useful for anybody that wants to contribute or just curious about how to use the test suite. But this is also useful for anybody that's interested in packaging and wants to run this as part of your packaging. It's also useful for anybody that works on other projects that use auto tools. So it's a fairly useful internal. So let's talk about some future features. Again these are possible features. I'll emphasize that. A big one so the first one I have listed here is policy objects. This is a concept that I've been thinking about for a while that would allow you to place a policy let me back up for a minute. So right now Firewall D attaches rules to a zone, right? This will allow you to attach rules to a policy that exists between two zones. So it's more about when a traffic flows from zone A to zone B apply a policy there. And the reason that's interesting is because it allows us to implement features that have been lacking and requested for a long time. Namely the output and forward filtering. The second one I have listed here is live NF tables. So right now the NF tables back end for Firewall D is simply calling out to the NFT binary. Recently Upstream got a brand new library to live NF tables. Firewall D using that would allow us to do a lot of big batch updates and have a more structured interface to NF tables. Third item here is DOS protection. I call it DOS protection but really this is rate limiting. The idea would be to rate limit connections per second or rate limit bandwidth data coming through. Exposing that via rituals means you could rate limit a certain user, you could rate limit a certain service, anything of that sort. This fourth one here, rituals inside of service definition. This is actually one of those other fairly frequently requested items. So right now services can have ports, you can have all kinds of things but one thing they can't have inside of them is a ritual. So adding a ritual would allow you to do some other interesting things like that. So we could almost implement major features via a service definition. So like earlier I mentioned the 6-4 filtering if we had this rituals inside of a service session we can implement that entire feature simply by having rituals to a service definition. So it would be very flexible. It would be a way for users to add a lot of arbitrary features like that. So it's kind of building on the basics and adding very powerful features. So I listed a couple of crazy ideas. One of the things on the previous slide was we did a lot of work refactoring to enable separate backends to add a NF table support. As a consequence of that that means we can support new backends fairly easily. So if there ever comes a time where EVPF and XEP make sense for Farwelde we're ready for it. Lastly, if anybody's interested in protruding the codes all on GitHub, it's written in Python. It's very easy to get involved. Whether you're adding services, reporting issues and translations are a big one. So if anybody speaks any language that's where we get all our translations so it's beneficial to all the users. Translations are very appreciated. As far as community, there's the channel on FreeNode. I'm always there but due to time zones I may not always reply right away but the users are actually very friendly and very hopeful. I've been surprised how many users help each other. And news and blog. Every new feature gets a blog. Every release gets a blog so please check it, read it. That's the best way to be informed about new things. And with that stop for questions. So the question is I mentioned rate limiting as a possible future future. He's asking about shaping. The answer is I haven't thought about it. File of future request. Anybody else? Interactive. Interactive what? Okay so I think you're asking for like a I think they call it little snitch or that's one of those features. It's basically so the question is I think the question is is there any plan to add outputs? Okay. So the question is is there any plan to support dynamically detecting new traffic and then allowing it. No, there's a it's been requested to add something similar like that to the output side. Meaning if there's some program that's sending traffic that we haven't expected and I determined they used this little snitch. I'm not familiar with that software but it's been requested. It'd be nice to see but yeah. It'd be a cool feature I will say. Any other questions? We've got a few minutes, Dan. Yeah so in one of the first slides you had like 8,000 lines added and 11,000 some removed. Added a couple of cool new features. So the question is is about the diff stats here. These ones how we added a bunch of features but ended up with less lines of code. You're right. A lot of that had to do with the code refactoring. There was quite a bit of redundant code removed but then we also removed a alternative CLI that was basically unknown and not used much. That removing that CLI was probably 6,000 less maintenance. I think we got time for like one or two more. I guess we're good. Thanks everybody.