5 ms·

One significant user-visible feature of 3.13 is nftables: https://lwn.net/Articles/564095/ https://lwn.net/Articles/564095/

by dded 13y ago

sp332 13y ago
Note libnftables was just renamed to libnftnl http://www.marshut.com/imyzmp/libnftables-renamed-to-libnftnl.html http://www.marshut.com/imyzmp/libnftables-renamed-to-libnftn... A later, higher-level library will probably get the name libnftables.
esbranson 13y ago
I've been wanting to implement a dynamic ARP filter (DHCP snooping + ARP filtering) for ages now, but arptables/ebtables just didn't cut it. Hopefully this will be easier/viable now. Because I still don't think ArpON sniffs DHCP leases for its mapping (it intercepts and replays ARP requests or something) and it doesn't filter rogue DHCP servers. I'm just amazed ARP spoofing/ARP cache poisoning is still a viable attack vector on home networks in 2014.
- adekok 13y ago
  Please see the "master" branch of FreeRADIUS. https://github.com/FreeRADIUS/freeradius-server/ https://github.com/FreeRADIUS/freeradius-server/ It can accept both DHCP and ARP protocols, and will decode them into attribute-value pairs. Those can then be referenced in a policy language, and stored to / read from a database. I'm the author. :) It's no longer just a RADIUS server. I've been looking for a DHCP / ARP checker for a while, and couldn't find anything useful. Rather than writing something from scratch, I decided it was easier to just add ~2K LoC to FreeRADIUS. I could then leverage the policy language and database integration, so I didn't have to re-write all of that, either.
  - esbranson 13y ago
    Excellent. :) I will look into this. I am targeting embedded devices on OpenWRT, which means it needs to be as simple and small as possible, so I hope the code is tight. But on the other hand, I would prefer to not reinvent the wheel.
    - adekok 13y ago
      The code is tiny. It already runs on OpenWRT, so there's no issue there.
- smutticus 13y ago
  You need to implement DHCP Snooping at Layer 2 for it to really work, and these days I think all major switch vendors support it. Unless you're building a Linux L2 switch I don't see why you would want to implement DHCP Snooping.
  - esbranson 13y ago
    You need DHCP snooping for proper ARP reply filtering. It is the cleanest way of determining MAC address<->IP address mappings.
makmanalp 13y ago
> It adds a simple virtual machine to the kernel that is able to execute bytecode to inspect a network packet and make decisions on how that packet should be handled. I wonder how long it's going to take until someone figures out a way to craft a specific sequence of packets that remotely do something nasty at the kernel level :P
- diegocg 13y ago
  It's not different than the rest of the network stack, most of it consists in "inspecting packets" in one way or another, and security bugs can be (and some times are) introduced. But nftables is actually a big win from a security perspective, because it simplifies the current code (lots of duplicated code goes away) and moves other parts to userspace. Old netfilter system: 70.000 LoC in kernel + 50.000 in userspace nftables: 7.000 LoC in kernel + 50.000 in userspace (source: http://www.slideshare.net/ennael/2013-kernel-recipesnftables http://www.slideshare.net/ennael/2013-kernel-recipesnftables) Also note that it's not really a "virtual machine" comparable with java, this is how the developers actually describe it In a nutshell, nftables provides a pseudo-state machine with 4 general purpose registers of 128 bits and 1 specific purpose register to store verdicts. This pseudo-machine comes with an extensible instruction set, a.k.a. "expressions" in the nftables jargon. The expressions included in this patch provide the basic functionality, they are: * bitwise: to perform bitwise operations. * byteorder: to change from host/network endianess. * cmp: to compare data with the content of the registers. * counter: to enable counters on rules. * ct: to store conntrack keys into register. * exthdr: to match IPv6 extension headers. * immediate: to load data into registers. * limit: to limit matching based on packet rate. * log: to log packets. * meta: to match metainformation that usually comes with the skbuff. * nat: to perform Network Address Translation. * payload: to fetch data from the packet payload and store it into registers. * reject (IPv4 only): to explicitly close connection, eg. TCP RST. Using this instruction-set, the userspace utility 'nft' can transform the rules expressed in human-readable text representation (using a new syntax, inspired by tcpdump) to nftables bytecode.
- krakensden 13y ago
  I don't even think this is the first vm in the networking part of the kernel.

One significant user-visible feature of 3.13 is nftables: https://lwn.net/Articles/564095/ https://lwn.net/Articles/564095/

by dded 13y ago

One significant user-visible feature of 3.13 is nftables: https://lwn.net/Articles/564095/ https://lwn.net/Articles/564095/

sp332 13y ago

Note libnftables was just renamed to libnftnl http://www.marshut.com/imyzmp/libnftables-renamed-to-libnftnl.html http://www.marshut.com/imyzmp/libnftables-renamed-to-libnftn... A later, higher-level library will probably get the name libnftables.

esbranson 13y ago

I've been wanting to implement a dynamic ARP filter (DHCP snooping + ARP filtering) for ages now, but arptables/ebtables just didn't cut it. Hopefully this will be easier/viable now. Because I still don't think ArpON sniffs DHCP leases for its mapping (it intercepts and replays ARP requests or something) and it doesn't filter rogue DHCP servers. I'm just amazed ARP spoofing/ARP cache poisoning is still a viable attack vector on home networks in 2014.

adekok 13y ago
Please see the "master" branch of FreeRADIUS. https://github.com/FreeRADIUS/freeradius-server/ https://github.com/FreeRADIUS/freeradius-server/ It can accept both DHCP and ARP protocols, and will decode them into attribute-value pairs. Those can then be referenced in a policy language, and stored to / read from a database. I'm the author. :) It's no longer just a RADIUS server. I've been looking for a DHCP / ARP checker for a while, and couldn't find anything useful. Rather than writing something from scratch, I decided it was easier to just add ~2K LoC to FreeRADIUS. I could then leverage the policy language and database integration, so I didn't have to re-write all of that, either.
- esbranson 13y ago
  Excellent. :) I will look into this. I am targeting embedded devices on OpenWRT, which means it needs to be as simple and small as possible, so I hope the code is tight. But on the other hand, I would prefer to not reinvent the wheel.
  - adekok 13y ago
    The code is tiny. It already runs on OpenWRT, so there's no issue there.
smutticus 13y ago
You need to implement DHCP Snooping at Layer 2 for it to really work, and these days I think all major switch vendors support it. Unless you're building a Linux L2 switch I don't see why you would want to implement DHCP Snooping.
- esbranson 13y ago
  You need DHCP snooping for proper ARP reply filtering. It is the cleanest way of determining MAC address<->IP address mappings.

makmanalp 13y ago

> It adds a simple virtual machine to the kernel that is able to execute bytecode to inspect a network packet and make decisions on how that packet should be handled. I wonder how long it's going to take until someone figures out a way to craft a specific sequence of packets that remotely do something nasty at the kernel level :P

diegocg 13y ago
It's not different than the rest of the network stack, most of it consists in "inspecting packets" in one way or another, and security bugs can be (and some times are) introduced. But nftables is actually a big win from a security perspective, because it simplifies the current code (lots of duplicated code goes away) and moves other parts to userspace. Old netfilter system: 70.000 LoC in kernel + 50.000 in userspace nftables: 7.000 LoC in kernel + 50.000 in userspace (source: http://www.slideshare.net/ennael/2013-kernel-recipesnftables http://www.slideshare.net/ennael/2013-kernel-recipesnftables) Also note that it's not really a "virtual machine" comparable with java, this is how the developers actually describe it In a nutshell, nftables provides a pseudo-state machine with 4 general purpose registers of 128 bits and 1 specific purpose register to store verdicts. This pseudo-machine comes with an extensible instruction set, a.k.a. "expressions" in the nftables jargon. The expressions included in this patch provide the basic functionality, they are: * bitwise: to perform bitwise operations. * byteorder: to change from host/network endianess. * cmp: to compare data with the content of the registers. * counter: to enable counters on rules. * ct: to store conntrack keys into register. * exthdr: to match IPv6 extension headers. * immediate: to load data into registers. * limit: to limit matching based on packet rate. * log: to log packets. * meta: to match metainformation that usually comes with the skbuff. * nat: to perform Network Address Translation. * payload: to fetch data from the packet payload and store it into registers. * reject (IPv4 only): to explicitly close connection, eg. TCP RST. Using this instruction-set, the userspace utility 'nft' can transform the rules expressed in human-readable text representation (using a new syntax, inspired by tcpdump) to nftables bytecode.
krakensden 13y ago
I don't even think this is the first vm in the networking part of the kernel.