Announcement

Collapse
No announcement yet.

NFTables IPTables-Replacement Queued For Linux 3.13

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • NFTables IPTables-Replacement Queued For Linux 3.13

    Phoronix: NFTables IPTables-Replacement Queued For Linux 3.13

    NFTables is a new firewall subsystem / packet filtering engine for the Linux kernel that is poised to replace iptables. NFTables has been in development for several years by the upstream author of Netfilter. This new nftables system is set to be merged now into the Linux 3.13 kernel...

    http://www.phoronix.com/vr.php?view=MTQ5MDU

  • #2
    Wonder how that will affect Fedora FirewallD, has from the little I came to use it in the CLI, seemed much better then the old IPtables deamons.

    Comment


    • #3
      No idea what you talk about

      Originally posted by iniudan View Post
      Wonder how that will affect Fedora FirewallD, has from the little I came to use it in the CLI, seemed much better then the old IPtables deamons.
      Ip tables are kernel modules + user land commands. It doesnt use daemon anywhere. Looks like some sort of OS functionality.

      Comment


      • #4
        Originally posted by dimko View Post
        Ip tables are kernel modules + user land commands. It doesnt use daemon anywhere. Looks like some sort of OS functionality.
        Front-end then, sorry for my mistake in terminology.

        Comment


        • #5
          Originally posted by iniudan View Post
          Front-end then, sorry for my mistake in terminology.
          Yeah. The front-end here abstracts away the kernel implementation details. It doesn't matter to end users whether it is netfilter or nftables. They would at the minimum get the same functionality perhaps with better performance.

          Comment


          • #6
            It's still tables though, right? :-P

            Comment


            • #7
              Per-program rules

              Will finally be possible with nftables to block certain programs to send or receive from the net (optionally filtered by the port too)?
              :P

              Comment


              • #8
                Originally posted by tesfabpel View Post
                Will finally be possible with nftables to block certain programs to send or receive from the net (optionally filtered by the port too)?
                :P
                It's not listed at 'Main features'. If I remember correctly, firewall developers mentioned that this should be handled in userspace. I.e. some LD_PRELOAD library that catches connect() calls and matches this against a list of allowed/blocked connection characteristics. Which, in my opinion, is a sane thing to do (i.e. let userspace handle userspace).

                However, I don't think this has ever been done since it's rather ineffective. A virus could infect an .so and turn a fully legit executable binary into a virus serving thingy... . Furthermore, when I reinstall Windows on friends/relatives computer I let the Windows firewall handle things. Do you really expect everyone to check each .exe (or bin) weather it's legit or not? That is just wishful thinking. Most Linux defense mechanisms (PAX, Selinux) are geared to not get infected in the first place (or mititage it) so you won't need these kind of 'safety measures'.

                Back on topic: This looks really nice, the kernel side will be a lot smaller now that protocol specific handling will move to userspace.

                I just really hope I won't have to rewrite my rules, I spend ages on the current ones .

                Comment


                • #9
                  Rexillion, in windows or os x where you have a million services and system components dialing home, yes whitelisting can be problematic and difficult but in linux distros it wouldn't be.


                  "However, I don't think this has ever been done since it's rather ineffective. A virus could infect an .so and turn a fully legit executable binary into a virus serving thingy... . Furthermore, when I reinstall Windows on friends/relatives computer I let the Windows firewall handle things. Do you really expect everyone to check each .exe (or bin) weather it's legit or not? That is just wishful thinking. "

                  At least you would have a chance, let's say a legit service gets compromised, to see who it was dialing too.

                  I maintain that little snitch is one of the best firewalls I've seen and it allows you to define rules like app x can only dial to ip y via port z once

                  Comment


                  • #10
                    Originally posted by tesfabpel View Post
                    Will finally be possible with nftables to block certain programs to send or receive from the net (optionally filtered by the port too)?
                    :P
                    You can already do this the Android way, by running those programs as their own user. The firewall can filter by UID.

                    Comment


                    • #11
                      Originally posted by Pallidus View Post
                      Rexillion, in windows or os x where you have a million services and system components dialing home, yes whitelisting can be problematic and difficult but in linux distros it wouldn't be.
                      I beg to differ. What about renaming devices? How are updates handled? Using the argument that another OS has implies Linux needs it too is just having it because others have it too. That is not a sound argument if you ask me.

                      Besides, on Windows it fails if you only look at the .exe files. svchost.exe will load just anything that has .dll in it's name keeping svchost.exe itself legit.

                      Originally posted by Pallidus View Post
                      At least you would have a chance, let's say a legit service gets compromised, to see who it was dialing too.
                      Netfilter has logging capabilities. Furthermore, there is Selinux, PAX and all the other 'Security Subsystems' in the linux kernel dealing with that.

                      Originally posted by Pallidus View Post
                      I maintain that little snitch is one of the best firewalls I've seen and it allows you to define rules like app x can only dial to ip y via port z once
                      Why not make sure that the service does not get compromised in the first place? No need for tedious maintaining of rulesets that have the tendency to change on each update (furthermore, these rulesets have proven to be ineffective (i.e. almost every piece of malware uses port 80 or 443). If a service get's compromised you already lost.

                      I get your idea, I did this myself in Windows XP once. It was hell. Stuff just randomly broke.

                      Comment


                      • #12
                        Originally posted by Rexilion View Post
                        I just really hope I won't have to rewrite my rules, I spend ages on the current ones .
                        From http://netfilter.org/projects/nftables/ :
                        backward compatibility iptables/ip6tables user-space utility at:
                        http://git.netfilter.org/iptables-nftables/

                        Comment


                        • #13
                          Originally posted by oibaf View Post
                          Should have been more specific. I know about the backward compatibility. BUT, what I really ment was: Hopefully will simply replacing the old rules with the new syntax yield the same behaviour. I.e. no subtle changes that could imply a radical change.

                          My firewall is kind of 'complicated' (yes, I like reading docs).

                          The backward thing is kind off nice at best, but I would probably not be able to resist to rewrite once I get my hands on this. Fortunately, I'm stuck with 3.10 for the nvidia blob since nouveau causes my card to deadlock at really random moments.

                          Comment


                          • #14
                            Originally posted by tesfabpel View Post
                            Will finally be possible with nftables to block certain programs to send or receive from the net (optionally filtered by the port too)?
                            :P
                            IPTABLES(8) iptables 1.4.4 IPTABLES(8)

                            NAME
                            iptables - administration tool for IPv4 packet filtering and NAT

                            [ ....................... ]

                            owner
                            This module attempts to match various characteristics of the packet creator, for locally generated packets. This match is only valid in the OUTPUT and POSTROUTING chains. Forwarded
                            packets do not have any socket associated with them. Packets from kernel threads do have a socket, but usually no owner.

                            [!] --uid-owner username

                            [!] --uid-owner userid[-userid]
                            Matches if the packet socket's file structure (if it has one) is owned by the given user. You may also specify a numerical UID, or an UID range.

                            [!] --gid-owner groupname

                            [!] --gid-owner groupid[-groupid]
                            Matches if the packet socket's file structure is owned by the given group. You may also specify a numerical GID, or a GID range.

                            [!] --socket-exists
                            Matches if the packet is associated with a socket.

                            Comment


                            • #15
                              Originally posted by dibal View Post
                              IPTABLES(8) iptables 1.4.4 IPTABLES(8)

                              NAME
                              iptables - administration tool for IPv4 packet filtering and NAT

                              [ ....................... ]

                              owner
                              This module attempts to match various characteristics of the packet creator, for locally generated packets. This match is only valid in the OUTPUT and POSTROUTING chains. Forwarded
                              packets do not have any socket associated with them. Packets from kernel threads do have a socket, but usually no owner.

                              [!] --uid-owner username

                              [!] --uid-owner userid[-userid]
                              Matches if the packet socket's file structure (if it has one) is owned by the given user. You may also specify a numerical UID, or an UID range.

                              [!] --gid-owner groupname

                              [!] --gid-owner groupid[-groupid]
                              Matches if the packet socket's file structure is owned by the given group. You may also specify a numerical GID, or a GID range.

                              [!] --socket-exists
                              Matches if the packet is associated with a socket.
                              Well... yes. If you like creating a new user for each user/program combo then yes... .

                              Btw, this does not work for NFS and other kernel mounting protocols. Let alone incoming connections (OUTPUT and POSTROUTING) only.

                              Whatever works for you .

                              Comment

                              Working...
                              X