Announcement

Collapse
No announcement yet.

BPF-Based Linux Firewall "bpfilter" Shows Impressive Performance Potential

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

  • #11
    Originally posted by Danny3 View Post

    For somebody used to simplewall and GlassWire on Windows and AFWall+ on Android, seeing the available firewalls for Linux surely gets a big disappointment and frustration.

    Great that at least somebody tries to fix this with OpenSnitch.
    Too bad that the Linux foundation or EFF doesn't want to help out this user friendly firewall project.
    I remember back in the days of Linux 2.2 and 2.4 where Linux had iptables which was amazing compared to what was available on Windows 95 and 98. I used to be very impressed with the firewall on Linux.
    Canonical created ufw which is a nicer way to interact with iptables, its too bad they don't seem to be maintain ufw anymore.

    Then with Windows 7 I think (or maybe it was available in Windows Vista or even earlier?) they had this application firewall that lets you allow/deny access to applications, and that was really amazing, it is another paradigm of firewall, but its very good for the desktop. So yeah it is disappointing that Linux does not have an application firewall.

    Now with Flatpak and Snap we're getting some sandboxes with permissions (like Android), which is good, but still most software runs unconfined and are neither Flatpaks or Snaps.

    I really wish that the GNOME Project (or even the KDE Project) would make an application firewall, similar to that one in Windows.

    Comment


    • #12
      Originally posted by uid313 View Post

      I remember back in the days of Linux 2.2 and 2.4 where Linux had iptables which was amazing compared to what was available on Windows 95 and 98. I used to be very impressed with the firewall on Linux.
      Canonical created ufw which is a nicer way to interact with iptables, its too bad they don't seem to be maintain ufw anymore.

      Then with Windows 7 I think (or maybe it was available in Windows Vista or even earlier?) they had this application firewall that lets you allow/deny access to applications, and that was really amazing, it is another paradigm of firewall, but its very good for the desktop. So yeah it is disappointing that Linux does not have an application firewall.

      Now with Flatpak and Snap we're getting some sandboxes with permissions (like Android), which is good, but still most software runs unconfined and are neither Flatpaks or Snaps.

      I really wish that the GNOME Project (or even the KDE Project) would make an application firewall, similar to that one in Windows.
      This is a hard problem, needs actual work and innovation (as opposed to writing an umpteenth music app or reshuffling buttons on the toolbars), and nobody pays for it. So, ain't gonna happen.

      Comment


      • #13
        Originally posted by sinepgib View Post

        No? AFAIR it was invented for more efficient packet sniffing. Not dropping packets from the system, but before copying them to a raw packet buffer in userspace. The packets would still go through the usual channels, just not to that particular socket.
        If I recall correctly the original point was to make iptables faster. The kernel gained the ability to compile iptable rules into BPF programs that would then run in-kernel much faster. And then all that other stuff came later.

        Comment


        • #14
          iptables and firewalld are already confusing enough.

          Comment


          • #15
            Originally posted by Developer12 View Post

            If I recall correctly the original point was to make iptables faster. The kernel gained the ability to compile iptable rules into BPF programs that would then run in-kernel much faster. And then all that other stuff came later.
            It wasn't invented for Linux, so that's unlikely. Plus, Wikipedia backs me up: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
            Done for FreeBSD (that's why it's called Berkeley Packet Filter) and for packet capture.

            Regarding compiling to BPF, IIUC bpfilter is all about compiling with the same iptables syntax. You can perfectly make a firewall with current BPF AFAICT, just it wouldn't really be practical.

            EDIT: sorry, the part about FreeBSD was me failing to read properly. Still, the foundational paper both proves it's not originally from Linux and it's meant for more efficient packet capture, and all other stuff came later: https://www.tcpdump.org/papers/bpf-usenix93.pdf
            Last edited by sinepgib; 24 September 2021, 01:58 PM.

            Comment


            • #16
              Originally posted by q2dg View Post
              Nft performs worse than Iptables?? WTF???
              I asked Dmitrii Banshchikov about this and here is his reply:

              Basically the reason is that nft's virtual machine requires more
              indirect calls than iptables. This gives flexibility but this
              flexibility comes by the cost of indirect calls. Post spectrum
              epoch needs retpolines for indirect calls and retpolines
              introduce even more performance penalties. This means that the
              cost of indirect calls is even larger then before.

              For a basic rule that matches only by source or/and destination
              L3 address iptables doesn't need any indirect calls while nft
              does. This means that even for basic matches nft requires
              indirect calls. There was a discussion in [email protected] mailing list
              where Alexei Starovoitov mentioned that for a basic rule nft
              needs something like 10 indirect calls. This dramatically kills
              performance.

              BPF programs generated by bpfilter don't have any indirect calls
              except map access and hence the performance is more optimal. And
              I'm not even mentioning optimisations that are possible with
              bpfilter and aren't possible with iptables of nft due to a more
              precise context.

              Hopefully this clarifies things a bit.

              Comment


              • #17
                Originally posted by piotr.dobrogost View Post

                I asked Dmitrii Banshchikov about this and here is his reply:
                Thanks a lot!

                Comment


                • #18
                  Originally posted by tildearrow View Post

                  Yeah, what happened here.
                  I guess I will stick to iptables now that the is realy no point on learning something thatis slowr...
                  See answer by Dmitrii Banshchikov here
                  https://www.phoronix.com/forums/foru...44#post1283544

                  Comment


                  • #19
                    Originally posted by sinepgib View Post
                    I wouldn't use the slower one cause my rules are most likely to be simple (I wouldn't know yet, I haven't configured one by hand), but wasn't the point of nftables to win on flexibility rather than performance?
                    Answer given by Dmitrii Banshchikov at https://www.phoronix.com/forums/foru...44#post1283544 seems to agree with you.

                    Comment

                    Working...
                    X