 Hello, my name is John Holly. I'm an open-source developer at VMware and today I'm going to be doing an introduction to NF tables This is this was originally intended as a workshop I'm basically Due to everything not going to be able to do that. So what I'm going to be doing today is talking about a bit of the history a bit of How NF tables came about what how it works how IP tables works How IP six tables works how basically x tables works and kind of go into a couple of brief examples that you should be able to copy once you've got the slides so Without too much further ado Let's kind of change this up a little bit again. I'm John Holly. I'm an open-source developer at VMware If you're interested in getting ahold of me The you know the easiest way track me down on IRC and Warthog 9 if you need to tweet at me at wordy 9 Or Warthog 9 will get to me, but I'll respond on out wordy 9 Should be pretty easy to track down my email is Pretty easily found. So if you've got any questions comments go ahead and toss them out there um Quick aside The content in that this particular talk is CC by SA 4.0 If you're interested in recycling it using it, please by all means go ahead. Just follow the CC by SA so without Digging in too far. We're basically talking about packet filtering today. So there's a lot of really good ways to try and protect your computer and The easiest way is obviously to take your computer Incase it in cement and drop it into the Mariana's trench Now the downside to this particular security methodology is that you can't actually use the computer And you're also dumping a lot of things into the Mariana's trench. It's very secure though at least until we can you know bring things up from the Mariana's trench and then you're kind of Kind of doomed at that point, but obviously, you know, we want to hook computers up to the internet We want to be able to do things with our computers On a network scale. So the obvious thing is is we hook them up and well as much as we would like to believe that the internet is a Wonderful and glorious and happy place to be connected to it's not it's actually, you know, full of script kiddies It's full of all kinds of Entities that are attempting to gain control over Computers for their own needs their own wants their own nefarious purposes potentially so This is something that we need at least a first line of defense in trying to secure things and the obvious way We can go about doing this is to use a network packet Filter system and this is built into the operating system. This is actually in most cases Built right into the the network stack itself Because it needs to kind of be that close to to the rest of the network stack and You know, this allows you to at least try and stop the vast majority of the basic Situations you're going to run into it's not going to be perfect. It's not going to be a Penicea for everything But at least it will give you that first line of defense that you can use to to protect yourself And Specifically what this is going to do is it's going to mostly just drop traffic that it has a rule defined that it shouldn't be accepting It is really nothing more complicated than that there's a series of rules it Decides against the rules whether it should accept something or drop something There's also when we kind of get down into this a little bit more their stateless fire of filtering systems And their stateful filtering systems will get into this a little bit later but it's kind of the difference between You know blindly just reading whatever is there or trying to do a bit more intelligent Taking a look at what's going on. So there we are packet filters so Packets have a lot of pieces of information stuffed into them outside of the piece of data And when a lot of us think about, you know, when we open up HTTP colon slash slash linux-foundation.org Really what we we tend to think about is that this does some sort of a DNS query It looks up an IP address and it just sends the entire packet out and gets a bunch of data back Conceptually this is the way it works because HTTP uses TCP so we can kind of you know at least from the application perspective treat this entire connection as a one in one out and Everything's done except that's not actually the way that packets Transmit on the wire. In fact, they get broken up into logical chunks of about Most of the time on the public internet, it's about 1500 And using an MTU of about 1500 a little bit hand-wavy because of a variety of things not going to necessarily get into it, but The data packet is not the data portion of that is not the only thing that that gets transmitted on each one of these Chunks of data. In fact, there's an entire header section that has a bunch of useful pieces particularly for our purposes for doing filtering There's an IP address whether that's IPv4 or IPv6. There's a protocol Defined in the header to give you an idea of what type of packet this is whether it's TCP UDP You know great many other Things that it could be TCP and UDP obviously being the most common these days the type of service Most the time you don't need to worry about that, but you know, it's in the header The hardware interface that it came from Or that it's going to the direction that the packets going Etc. These are you know, there's a number of pieces of Information that's encapsulated in that header Although for the most part the IP addresses both the source and destination The port that's being used and a few other bits and pieces of information there are Really what we care about from a filtering perspective and in a stateless system again stateless nothing's being recorded on or tracked on the firewall side So that it can actually do more logical things It's really just looking at each individual packet as an entity unto itself and making all of its decisions Based on that specific packet a state full firewall will however Build a much larger piece of the puzzle a much larger piece of the picture to actually make its determination on what's going on with the specific stream Now from a stateless perspective you have little visibility into the packet payload and in fact even from a stateful perspective You really don't have a lot of information on what's going on in the data section of the header This is intentional because deep packet inspection trying to actually Unwind what's going on in that data packet requires a lot of processing and that's because you basically have to reassemble the entire piece that was requested and then analyze what's going on with it and this is this really is just expensive both from a memory perspective a CPU perspective and From a latency perspective because this clogs things up a lot There are really useful things you can do from a deep packet inspection perspective though However, it is just very costly and it's not Probably what you're going to want to do when you do a firewall I'm in reason why you may or may not care about that. I'm not going to get into that here beyond that but Packet filters can also look into the TCP headers that what what we're talking about right now is just the packet So that I had mentioned the port the port's not actually included in the packet header because the packet doesn't need to care about A port that's a TCP or UDP problem. That's something specific to a Different layer of the protocol, but the packet filters can look into TCP headers For for additional pieces of information that may or may not be useful So now that I've kind of mentioned ports. Let's talk briefly about ports ports are used in TCP and UDP to define where a Where a network socket is coming from and where a network socket is going to So again using the example of opening up any a website basically your computer has About 65,535 ports associated to it. This is basically defined from TCP and UDP and There's two ways you can use these sockets most the time you're going to want to use these when you bind you bind to a specific socket or a specific port so that you can listen on it now This this is great for listening when you're talking out a lot of the time You also want to listen so you end up also kind of associating yourself to that port when you talk out and When you're binding to a port and you're listening you usually bind to a very specific port you're very well It's usually a well-known port That others know how to talk to so case in point FTP uses port 20 and 21 NTP Uses 1 1 9 SMTP uses port 25 tell that 23 Our example of HTTP uses port 80 for HTTPS. It uses 4 4 3 These are these are ports that should be relatively Well known to you if they're not it's worth taking a look at what ports are actually running on your system You can do this with you know things like net stat or even just taking a look at a TCP dump Of what's going on in your system or you know Only doing this against systems you control or that you have permission to do this against nMap is a really great way to also Double-check what ports are open what ports are listening on your system. It's not going to tell you what's going out Net stat will tell you both incoming and outgoing, but nMap will be able to to tell you what's going on What's listening on your on your system? and Some ports have very specific meaning so you know things like FTP port 20 and 21 these Port 20 and 21 have been Kind of assigned to FTP everybody probably knows that FTP is running on those You don't necessarily have to have FTP running on those, but most people are going to expect FTP to be running on those same things with something like a HTTP Everybody expects it to be running on port 80. However, if you've got an IOT device or something around in your house or You know you've been doing some web development a lot of people will for development purposes run a certain port 8,000 or 8080 Or something like that that they can still get to the port is just a it's If you want to think about it as an apartment complex you have a full address That's what the IP address is the port is just what apartment in that address You would like to to communicate with so There are also some very specific ports that require special permissions so on a lot of operating systems port 1 through 10 23 are considered service ports or Super user require permissions required to use that port so things like port 80 you actually have to be a super user to use This is both good and bad. Obviously you don't necessarily want You know a random user to be able to attach to these ports because lots of important things do run on these ports On the flip side, you also don't want a web server running his route. This is a bad idea So what a lot of the these? Service daemons that do attach to the these lower level ports What they do is they they open the port as a root or as a super user Privilege root whatnot and then once they've acquired the address a listening space. They actually switch to a different user To actually do the rest of their their running so That's kind of how some of these things work. Unfortunately. Some of these things do just straight up run as root This is not a great idea. Some of these things need to be fixed a Lot of this is open source. Obviously patches welcome Um But obviously I've said there's sixty five thousand five hundred thirty five. I've only talked about about a thousand of these What are the rest of these ports used for? Well a lot of things? Generally speaking there are ports 1024 through about 50,000 It's four thousand forty nine thousand one hundred and fifty one on most operating systems are reserved for Services that run not as a super user So, you know things like NFS or NF SVN or open VPN They don't necessarily need to be in that this you know hyper privileged Run level, but they do need a port to be able to communicate with so most operating systems generally reserve That space for those ports so things like you know eight port eight thousand. I as a normal user I don't need to be a super user. I can oh I can bind to port eight thousand and do things with it Well again, we're only up to about fifty thousand out of the sixty five thousand ports So what are the last a few ports generally used for? Well the last? Range of ports forty about forty nine thousand one hundred and fifty two to about sixty five thousand five hundred thirty five Are used for the outgoing connections from your system? So when you open that socket you want to talk to a server that that is on port 80 on the remote side But you need a port on your side to for the communication to actually work And so what your operating system will do is when you go to open that socket it will actually assign you a Port that you are communicating on and that comes out of the forty nine thousand one hundred fifty two to sixty five thousand five hundred thirty five range Most Linux kernels actually limit this a little bit differently. They're down into the thirty two thousand seven hundred sixty eight up to sixty one Thousand for those sockets. There's rhyme and reason why why this is broken up a little bit differently But they're still ephemeral ports They're not intended for you to bind a service to that you will then connect to Although in some cases you can generally it's still not a great idea because the operating system Doesn't like having those ports kind of taken away from it so These are ports Now We can get into some interesting problems with just port blocking and port blocking is very very useful. Don't get Let this slide Determine you from using port blocking. It is very very powerful and in most cases It's probably what you're actually going to want to be doing either explicitly opening up ports or specifically closing ports That are that have access to your system However, sometimes this gets weird. Let's take FTP for example FTP is An older legacy protocol. If you've never played with it It's been out there for a long time But it has a really odd way of communicating in fact the way it communicates is it actually uses two ports When you connect to FTP the client sends arbitrary commands to port 21 On the server now the server sends all of its responses on port 20 to the client on a dynamically allocated port So this gets really weird in some very odd ways because one of the first things in the FTP transaction You're going to do is you're going to say I am you know, I'm a client I am talking to you obviously at port 21. Please respond to me from your port 20 to this Other allocated port Well, this is really weird and this is very odd and obviously a stateless Firewall can't handle this because it's going to see a packet going out to port 20 and that's probably going to be allowed But when it sees the packet come back from port 20 on port 20 It's not going to know that this is the same transaction unless you blindly open up all Anybody sending you data from port 20 to any port obviously that's a bad idea. So, you know, this gets into a really odd situation where you do actually need a state full piece of the firewall usually this is built in as a module into the The the packet filtering system itself so that it actually keeps track of oh, you wanted to talk to that FTP server Back on this port. Let me go ahead and do the appropriate magic to allow that to come through without necessarily Everything opening up in a very odd way This is pretty cool um, and so Let's kind of dig into packet filtering rules since this is where we're kind of going with all of this anyway So really it comes down to you got a policy that you want to implement and how the firewall is going to be able to do this So from a policy perspective you want no outside web access Let's say that I'm on a Guest network and for whatever reason I want nobody to have access to the the web although I'm okay with them having access to The the git protocol over it. It's native port You on the firewall side you would drop all outgoing packets to any IP address using port 80 That's pretty straightforward And this kind of you can kind of build these rules into more and more complicated Rule sets as you go, you know, so things like prevent your network from being used in a denial of service attack, you know Drop all ICMP packets going to a broadcast address i.e. something in the 222.22 space specifically in this case 2525 Would actually stop, you know a broadcast a denial of service attack Is it a good idea it's going to depend on your situation, but it may or may not be something worth taking a look at So and in fact you can while I've talked about TCP and UDP ICMP is something you can filter on as well. In fact, you can prevent your your entire network from being trace routed There's rhyme and reason and a lot of argument over whether this is a good thing or a bad thing Even be even if you look at Windows 10, and I think some of the other more recent Versions of Windows they don't even allow you to paint them Which is a really interesting problem when you want to figure out if the system's up kind of hard to tell sometimes so These firewalls can be can be very powerful can be very interesting and when you get into some things like IPv6 particularly from the ICMP perspective you can actually break I see you can actually break IPv6 by limiting Certain ICMP pieces of information from being transmitted because IPv6 actually requires certain pieces of ICMP to be able to flow back and forth between the systems particularly particularly to determine an Intermediate NTU that they can both use to communicate more effectively so packet rule definitions rules are processed from top to bottom in almost all packet processing systems. It doesn't matter whether it's Linux or Windows or Mac or most operating systems even you know the big commercial Hardware vendors for For firewalls they all pretty much go the same way. They all process from top to bottom Until they hit a match and unless the match specifically says to continue for whatever reason sometimes they're Marking a packet for for later investigation or usage or routing or what not You know once you find a rule that matches That's the end of the story. So if you take a look at the The example we've got here, which my head is unfortunately cutting off slightly You've got a deny rule so anything outside of the 222.22 slash 16 space That has a source port greater than 1023 and has a destination port of port 80 all gets denied So anybody trying to access a web an HTTP website on this network Obviously just gets dropped. However, if you're on the network If you're you're on the the 222.22 since it's not explicitly denied. You're allowed To access that that port The the next rule allow outside of 222 go ahead and if you have a source port of Port 80 and you're trying to to get to a destination port of greater than 1023 You should be fine Either basically assuming that a remote web server wants to talk to you on something that's not on a privileged port This could be for any number of reasons, you know Let's say that a web service is attempting to talk to port 8,000 i.e. your own Portion of a web service and that's what they're trying to do And basically like I said you run through top to bottom chunk chunk chunk and this last line that not that you can read All of it, but it has a deny and all In all of the ports across the bottom and basically what happens is you chunk chunk chunk chunk chunk You figure out of any anything was denied or allowed and if you fall through all the way to the bottom in this case Everything gets denied. So if for whatever reason there was not an explicit rule that allowed or denied you already your packet was denied and Not and that is just how this particular one is set up. You don't necessarily have to deny everything As a policy a policy level decision a lot of the times This is just the fall through default of oh my god. I don't want to trust anything So stateless filters pros and cons stateless is actually going to be a little bit faster for the most part just because it doesn't have to look at much as much of the the stream that's going on but You know, and it's going to be effective against worms and Trojan horses sort of All you know pretty much anything that's a pro or a con is always going to be sort of because there's always different There's always no ones is there that are hard to to describe or really get into sometimes It can be very fast at filtering rules that are not too complex particularly since it's you know top-to-bottom It's built into the Lenox kernel obvious disadvantages It's not going to stop malformed packets because it's not going to see the entire data stream and it's not going to look Too much further into things like the TCP or UDP Information it's not going to protect against protocol Based attacks buffer overflows what not it doesn't protect against you know email viruses and it's not going to enforce user privileges or Are the pieces along those lines? That's because this is really just a basic, you know first line of defense It's taking a look and doing some really high level attempts to to Take a look at things So now, you know, so let's talk about some state full filters You know, I've kind of mentioned things like FTP needs a stateful process to take a look at things But but the the advantage of state full is it actually remembers the state of the communication session Taking a look at like the TCP headers and whatnot. So if let's say I open a TCP connection This is a long lived Connection and it's going to you know once it's established. It's not a new connection every time So you can actually It write a firewall that if you have an already established connection Um, then you don't need to do any then this is permitted or if you have an already established connection You know immediately start denying things because we we've decided that that IP address is bad for whatever reason um And you know, there's a few extra pieces that you can start taking a look at As you deep you dive into some of this So a state full is actually just keeping track of more information more about what's going on With the connection itself Obviously, this takes up more ram that this takes up a little bit more processing time because it's going to look deeper into the packet to do things um And uh, uh, there's some interesting ways of keeping track of what's going on on your system from A perspective from just from any perspective. Um, I've mentioned things like net staff. There's obviously Things like IPT state if you're using IP tables Um, but basically this just gives you a rundown of what's running on your system both listening and talking Um, particularly from a you um tcp perspective Obviously on udp you can only listen or you can only list what's being Listened on because a udp packet doesn't keep a a session. So you wouldn't necessarily know where You know who's sending a udp packet to you if you're just monitoring it kind of this way um, and you know one of the things that Uh, I you know just mentioned the the established state Well, you know the the system is actually keeping track of whether a packet is new established related and valid You know, uh, uh, what's going on with that that packet with that stream Um, particularly from a tcp perspective. So, you know, if it's a new connection It hasn't quite completed its handshake. Um, it's still connecting if it's been established that the handshake is complete And that it is flowing If it's related, um things like that ftp, um example, you would you would see related packets Um, or even an invalid packet if some but if something's just spewing garbage at At it at some point the system will recognize that it is invalid and drop it on the floor Certain types of spoofing or certain attacks on on ip blocks Sometimes you use that attempt to to break things And linux uses the contract mechanism to maintain this connection table. So this is all like I said This is all inside the linux kernel already whether you're using ib tables or um nf tables and stateful filters pros and cons advantages relatively easy to implement from the the The user perspective not that they're a bit more complicated inside the kernel. Obviously, um They they tend to be they also can be fast, but there's a they are looking at a lot more pieces So it kind of depends on what's going on um, it does protect against a few additional pieces of um potential attacks So, you know bad packets invalid packets These are things that a stateful firewall can actually pay attention to and keep track of um as opposed to a stateless firewall that can't And does not protect against attacks with you know malformed packets It still doesn't you know protect against email viruses or buffer overflows. That's all left to Layers much higher up the stack Um, then what we're talking about here. So you're still going to need to run You know, you know good code fix bugs, you know patch cvs And you know run things like spam assassin if you're dealing with the email or clam av if you're dealing with email um so And to touch briefly on this um There are bridges if you're not familiar with bridges. This is this is something that's that's worth Taking a look at because these these are used particularly heavily with with virtual machines and um containers because These are basically a software switch inside the system that allows you to attach more things to an interface And and just like plugging cables into a physical switch The really interesting thing particularly on linux is that you can actually filter Packets going across this switch So you can actually set up firewalling rules directly across these bridges um, you know in and out and doing things there to to be able to um To have a more comprehensive firewall. In fact nat actually kind of works this way that um when Behind the scenes it's not it doesn't like use bridging tools or anything But nat basically sets up this kind of a setup inside the kernel to be able to Filter these things around You can also use the the the sprout table where some other pieces of information are stored, but i'm not going to get too far further down that that Down that rabbit hole, but it's worth being aware that you can filter Traffic across a bridge in particularly in linux and it can be very very useful um quick overview of net on the net filter architecture, which is kind of what we've got I want to say now, but this is actually in in the process of changing because nf tables is becoming more and more widely used Um, it uses a bunch of different separate tables to to keep track of things eb tables arp tables ip tables ip6 tables And contract Now the real gotcha With all of this is that each one of the these table implementations they they recycle a lot of um Similar ideas. They all kind of do very similar things in slightly different ways And it does end up with a a you know, very complicated very interwoven system Um to to get things through The packet filter now This has obviously all worked for a long time, but there's um Some really interesting and very obnoxious problems with x tables in general, um Even though it has been used since the the the two four curl Defining about the stateless and stateful firewall rule can be tedious due to the number of rules that need to be written You basically end up having to write a bunch of different rules across a bunch of different pieces To actually make a stateless and stateful piece of a firewall work Um, and it's you can't necessarily keep them all in like one file or keep track of them It's basically keeping track of a bunch of little pieces all completely independently and separately Um, the order of the rules is important. Although like I said top to bottom Has always been the way a lot of the firewalls still process everything, but it's even more important in the way Um, these interactions across Um these tables and these systems all work So, um And when you're building a multi-tenant multi-user multi-tenant server and creating and searching these rules can get really really complicated really really fast. Um, just because You know, all of these systems they all go top to bottom. Um, trying to to figure things out and Basically as the number of rules explodes the search path the search path to do everything um, similarly explodes and Probably the most obnoxious thing particularly nowadays since ipv6 is finally Um starting to become more and more common. Um, ipv4 and ipv6 work are completely separate firewalls Effectively inside the system. They're not linked in any Useful way, so you're actually maintaining effectively maintaining Two firewalls if you've got a dual stack system Um There's uh, uh, obviously this is an example of dropping malformed packets The number of things you need to do to actually figure out that a packet is bad Is um, there's about six commands you have to enter to get to the point where you've actually Determined uh inside the the filter rule that a packet is invalid kind of obnoxious um, the other thing that uh x tables doesn't handle very well By itself is long lists. Like I said, it's kind of long lists of things. So if you've got um A block list that you want to to implement directly inside of x tables You literally have a you know an individual rule for each Block that you want what you want to do. So let's say you have 15,000 IPs that you want to block for whatever reason you would need to have 15,000 lines of entry And every packet that comes in is going to be processed against that 15,000 lines each time Obviously, this is obnoxious. This is not a good thing Um, there was a tool that that that that came out to kind of help solve that but let let's get into nf tables because this is Kind of where nf tables Starts coming in so in 2009 the nf tables uh, uh project was created by patrick mccarty Um to address a lot of the problems from from ax tables Obviously getting um all of these pieces all of these networking layers all kind of cohesively put into a single place So you're processing things in one location with one concept with effectively with only one firewall It is super super powerful and obviously something that needed to happen because You know trying to do this any other way is just silly and kind of obnoxious and um This uh, uh, this got some really early on traction Because it did solve a lot of problems and it um had some really serious advantages versus Um, uh ip tables or x tables now what happened was was the ip set command So I talked about you know, if you've got a block list you've got 15,000 items Well, the ip set came out our command came out was built bundled into the linux kernel itself and this gave you a way to do um a much more efficient much more um Or a much faster You know set of ip addresses or rule sets that are all basically identical inside the linux kernel and so That 15,000 linear you know ip linear search now got turned into something that you could you know Quick sort or quick search Based on because that the the data structures inside the linux kernel were dramatically better um As a result of this particular Uh feature to address a problem a really obvious problem In um ip tables nf tables ended up getting put on the back burner and um, kind of Languished for about four years It was um picked back up in 2013 by pablo um and the kernel and the code finally made it into the linux kernel around 313 so um Obviously, this is a good thing and with the explosion of vms and containers I mean, you know, I'm sure you can take a look at all the other talks Probably about half of them if I had to guess our our deal with containers or virtual machines in some way But you know having being able to to make the the firewall rules much more straightforward Put everything in one place actually makes dealing with this explosion of additional ip connectivity on your system a lot easier to manage so um The end of tables architecture it it more or less just takes a lot of the ideas of x tables and crams them all into a Single location where everything all gets processed as a single bit Now, what are the really neat things that they're doing with this is they actually take the berkeley packet a filter virtual machine concept In fact, it is the a berkeley packet filter Uh a virtual machine and this is what actually does a lot of the filtering So there's a full virtual machine if you think about um, you know, these byte compiled languages out there things And how you can compile to the the virtual machine Well, that's basically what you're doing with your firewall now And what your your firewall actually is is this um byte compiled code running very quickly inside the linux kernel on top of everything else Which is really really neat. Um, so But by also combining all of this you no longer need a separate ip tables a separate ip6 tables arp tables Ev tables, etc It's all in one place So you don't need to worry as much About trying to figure out how all of these separate pieces all interact. They're already all there. So you don't need um No predefined tables Like input or output or forward. These are already all kind of just built into nf tables Um nf table still uses the the hooks for for contract. Um, that hasn't gone away The system the the the linux kernel still obviously needs to to track connections. This is all hooked in nicely And one another thing that nf tables really brings to the table is arithmetic bitwise comparison operators so you can actually do fairly complicated firewall rules to do certain types of matching and um, but Um, just like x tables nf tables more or less still uses the same table chain rule So, you know, it should all still look basically familiar even if the back end has changed rather dramatically and You know, like I said, this is normally done as a hands-on tutorial. Um, not going to do that here But if you want to follow Some of the things that we've got In the slides here, um, please by all means do Um, I would recommend if you're going to kind of follow some of this go ahead and do it in a virtual machine That way you don't screw up your main system. Um, I will not be held responsible for for screwed up firewalls everywhere by doing any of this But um, obviously there's a way to to verify nf tables is in your kernel You can check for the the module being loaded or even if the nft command is even present if it's not obviously You know dnf install yum install apt get install nf tables will get you the commands and then you can kind of run through and play with some of these Um, and i'm going to try and make sure that The slides are up somewhere where you can download these because uh in a in a couple of slides There's going to be some really big examples. Um, they're as short as I could possibly make them But they're still completely um in uh illegible for the most part and with the the video box I've got here I actually end up unfortunately Covering some of that so um, you know, even if you're you're squinting and reading the the screen in a pause mode It's not going to work very well, but um The the commands you're really going to do want to pay attention to if you're going to start playing with nft tables is nft Um, that's the main command line interface into nft tables Um, you can also grab the ip tables to nft tables translators and their libraries I really don't recommend trying to translate ip tables to nft tables Um, there's a there's so many concepts In ip tables that don't match or that don't map very well To nft tables directly and things that you have to work around at ip tables that you don't have to work around in nft tables That a lot of the translators particularly for more complicated firewalls do not handle well um and um Unsurprisingly with anything on from a firewall perspective on linux the firewall that's running in the kernel right now Is transient when you reboot the system It goes away. You have to fully reload the firewall Once you reboot the system now most users are are are Aren't going to realize this because there's um back end processes particularly on shutdown That will save the fire your current firewall configure even pre save it before you shut down Um to the the current state and then restore it on the next boot You know if you go and you start playing with this directly be aware that your changes will not Will not cross a reboot unless you specifically save and restore it um And there there's um almost every command that you can do with ip tables you can do with nft tables in fact Excuse me. Um in more recent kernels most of ip tables is secretly behind the hood using um bpf as its Packet filtering system. So ip tables is actually using the exact same packet filtering system in the back end as nft tables With the the obvious with the gotcha that you can express things in ip tables and you can express things in ip tables And you can express things in eb tables that do not translate back and forth So even the translator sometimes will will translate things to bpf and since bpf can be um forward and move Reverse will try and translate it back to nft tables and it doesn't work very well at that point um And the coexistence of eq tables x tables and nft tables they hypothetically can It's just going to confuse you greatly at some point If you want to start playing with nft tables just turn ip tables and ip6 tables and basically add tables off You will have a much better experience and it you just won't be tracking down Weird and wacky problems as a result and those are the pieces of information on how to do that um And the sequence of tasks in nft tables is to create a table then a chain then a rule Exactly the same way you would do this with ip tables or ip6 tables um And the address families you're going to want to worry about our ip which is ipv4 ip6 ipv6 um inet both arp bridge and net up All relatively straightforward the the shouldn't be Too weird on what what uh, you would expect from a firewalling perspective um, and another really nice thing that nft tables brings to to the table is the idea that um, you can not only use the command line interface, which is which is really nice But you can also save all of this information into a file and then replay that back into nft tables in fact the um if you go to do nft list rule set nft space list space rule set um or rules I don't it's built into my fingers. I check the man page if I've got it wrong um You can literally just copy and paste what it outputs there put it in a file and then um on your next the next time It would you load your system you can actually just reload that straight in it's literally giving you the config file That it will accept And the the config files the files that it can read in are actually really really powerful. Um There as long as you don't flush the rule set somewhere in your in your file It will actually keep adding whatever is in the file into your existing Firewall, so if you've got a basic firewall and you just need to be able to add Some additional piece you write up a quick file and then you can import it directly in Um, it doesn't wipe out your entire existing configuration That's actually really cool. Um the other thing that the nft Are the nftables Configuration files can do is they can actually have their own includes So you can actually just have you know include include include include include To get to a full firewall setup So these are really worth pointing out. They're really nice to use I've been using the the includes and the separate files for a lot of different things particularly To just separate um just protocols. So if I want to have a well-known well-documented firewall rule for let's say ssh I just put that all into its own configuration file and then I just include that Um has something into the main can uh into the main Uh a configuration file that the system loads and that's super duper useful um So let's get on to a basic um Firewall setup here There we go. Um, this is a simple ipv4 ipv6 command a combined firewall um, this is exactly the entire um A rule set that you need to have a very basic very just You know drop everything on the floor if it's incoming or you're it's attempting to forward or if you're on the Um, or if you're trying to go out just accept everything. So this is um Really really basic and this does both ipv4 and ipv6 in the same configuration So you don't even need to think too hard about what's going on here It all just works Again, I'm going to have the slides up um somewhere So you can go ahead and copy and paste and play with this and if you can't find it Hang me online. I will get you copies of this. Nothing here is too weird um For for for being able to set stuff up But at least this gives you a starting point to start taking a look at what do do these kinds of firewalls actually take a look like Um, so that's a that's a really that was a really simple firewall um You know something that you would use on like your laptop or an individual machine Obviously, most of us have a home connection that we would like to NAT This gives you a really simple really straightforward NAT configuration with the ability to forward a port around inside Inside of the the NAT. So if you wanted to have let's say port 1922 actually forward to another SSH enabled server inside your own network This has all of the information to do that um This is I mean you this looks like a lot To take in this is actually really really short and most of this is basic boilerplate Around what's trying or what's all happening here? So nothing here is super duper complicated And in fact, this is this is an example where it actually doesn't include if um, I don't know if any of you Will be able to actually notice it but the first line in this Um on the left hand side is an include statement for another file that file is the one that's on the right um Really simple really straightforward. Um I don't want to get too far into this because I'm going to start running out of time And there's a couple of other things I want to touch on before I really run out of time but um NAT is something I really want to um That I have a a brief chat about just because ipv4 and ipv6 are actually rather different beasts for most of us so In the ipv4 world particularly like let's just take your your typical home network um You have a single ip address that your isp gives to you and all of your machines behind it all go through a network address translation This all works great. It means that um, the isp only has to give you one ip address and nat I won't I don't want to say that gives you an extra layer of protection because nat is not a firewall It is not protection. There are ways of reversing across an ad But it does um mean that your systems generally are not directly connected to the internet now That works all well in grade and obviously we all have uh firewalls for a variety of reasons from that as well But with respect to ipv6, there is no nat And before anybody goes uh, uh, uh, screaming around on on stuff and tells me that ipv6 nat Does exist it does don't use it. It's a bad idea it Unless you really really understand it. It's don't touch it Um and pretend that and absolutely just pretend it doesn't exist But it does mean that the ip address for your your system is actually publicly routable across the entire internet Now this is going to conceptually be a very big change To how people want to to deal with their firewalls how they want to secure things Um, I mean just think about it. You know right now if you're on a nat of network You have this semi insulation that nobody can ping your ip address directly Except on an ipv6 network Anybody on ipv6 can hypothetically ping your ip address Assuming it's on the the actual publicly routable site Again, there are private ip ranges for ipv6 that aren't that are explicitly not routable Still don't use those for now Um, those are for very private network kind of things that you don't want to to get around it But it does mean that you like you know in the the case of your iot device as I've got illustrated here The the big bad internet does if you've got ipv6 may actually have direct access to your iot device and Because we all know that iot devices are totally and absolutely and miraculously perfectly secure You know Nothing will ever bad or nothing bad will ever happen to to that poor little iot device, right? um This does mean that you have to be a bit more diligent and a bit more careful on how you write your firewall rules But it also means that you can actually think about your devices In a much more uniform way In fact because we have nat a lot of devices on your even on your own home network probably Do weird and wacky things to specifically plow holes Through the the firewall through the network address translation to be able to to get Different connections going out This makes it very hard to write some firewall rules For things that may be really complicated. Maybe really obnoxious. So um ipv6 actually makes a lot of this simpler But obviously, you know while ipv6 is still rolling out not everybody has it yet. It's not everywhere yet We're still working on it. So um I obviously mentioned ip set earlier and how that actually delayed Some things in uh with nf tables coming out. Let's back up a little bit and let's talk about nf tables in the ip set With nf tables you actually don't need ip set anymore because nf tables actually has the same basic functionality already baked into it and in fact it goes a couple of steps further beyond um Beyond that in just the types of dictionaries and the types of um Mappings that it can do inside of it. So ip ip set is very specific on how it can do things It's basically an ip address sometimes with an expiration and a long list and it's um To make it very efficient nf tables actually gives you you know full maps full full Dictionaries that you can use to actually build these complicated like ip lists For doing things with and they're already built into nf tables. So this is all there Everything's already taken care of you don't have to treat this as a separate piece To the rest of your firewall the way you would have to do this with ip set um And quick example of this, um, I've got a block list here of ip addresses I do not want the um accessing Anything on my network. We go ahead and set up a block list We give it that anything that gets added to that block list is uh times out after three hours and 45 seconds so um Basically what that means is once an ip address is put in there. There's a timestamp and once that timestamp Once that timer exhausts Um, it is actually removed from the list automatically The ip set has a very similar mechanism But uh, uh, nf tables already obviously has this built in really really well um On top of that the the the rule set off to the right here Is really the the the next piece that that would matter that um, and and how you would actually reference that so um, and uh, uh, basically That's just a dump. That's nft list rule set. That's exactly what the the rest of the the firewall was seeing So, um, again, I talked very briefly about ip uh translating ip tables to nft tables. Don't do it just if you want to do it as a um, just to figure out how things work how maybe some of this might actually work out You can try it It's probably not going to work the way you expect it and one of the really You know simple examples of this a bridged firewall An example bridge set up from ip tables um Defines a bunch of pieces and then after the translation Basically a lot of the pieces of that Um bridge were explicitly commented out because there was no good way for nft or the translator To translate that back into something useful for nft tables because the concept doesn't exist the same way so um, and obviously This is intended as a tutorial class. This is an intended as Something that beginners can do one of the things that people are going to ask for is obviously a gooey firewall builder There are some that exist. They aren't you know, there's not a lot and sometimes these firewalls can get very complicated um There's things like fire fw builder and um, in fact firewall d at this point and a lot of cases is using um nft tables in the back end itself So if you're using firewall d, you might actually already have a decent Uh, uh, a gooey Uh, a system to to build your firewall or at least get a starting point for a firewall So And last but not least Obviously, where do you find more documentation because um end of tables unfortunately has some really kind of terrible Places to find documentation Um, this is my my my best suggestion on where to go. Look take a look at the end of tables wiki Um, which is listed there arch linux has a very good nftables page on their wiki. There is a book um That was published in 2015. It's not too bad. Um, go ahead and take a look at that and obviously there's always the nft manual page um, again, so i'm running out of time at this point and Uh, I don't want to run over too far here. Um, again, my name is john holly Uh, I I work at vmware as one of the ripenshorse engineers. I can be found online. Um, usually as worthog nine Pretty much if you google for worthog nine, you'll you're almost certainly fine to me If you need to get ahold of me on twitter at worty nine If you need to email me worthog nine at eaglescrag.net or you can use my work email jholly at vmware.com um Take your pick. Please go ahead and reach out to me and Um, I I hope this was uh, beneficial. I hope this was useful And I really do hope that uh, at some point we can go back to Doing this in person and actually being able to work through some of these things more individually and in a better setting than Recording a webcast. So anyway, thank you very much