Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
On Sat, Mar 3, 2018 at 7:55 PM, Walter Dnes wrote: > On Wed, Feb 28, 2018 at 04:40:37PM -0700, Grant Taylor wrote >> On 02/28/2018 02:15 PM, Walter Dnes wrote: >>> >>> Is there something besides iptables? >> >> nftables > > Assuming I just want filtering, could I emerge nftables and unmerge > iptables and have a functional firewall? nftables is a replacement of iptables. It's not less featureful. https://wiki.nftables.org/wiki-nftables/index.php/Why_nftables%3F [ You'll have to learn a new runtime and config-file syntax ]
Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
On 03/03/2018 05:55 PM, Walter Dnes wrote: Assuming I just want filtering, could I emerge nftables and unmerge iptables and have a functional firewall? Simplistically, yes. It's my understanding that iptables and nftables are two completely different firewalling technologies. So you will need to either write or find something to manage nftables for you. Is there a reason not to stick with simple iptables without anything fancy to manage it? -- Grant. . . . unix || die
Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
On Thu, Mar 1, 2018 at 8:48 PM, Walter Dnes wrote: > On Thu, Mar 01, 2018 at 12:58:44PM -0500, Tom H wrote >> On Wed, Feb 28, 2018 at 4:15 PM, Walter Dnes wrote: >>> >>> Is there something besides iptables? It seems to be like >>> systemd/perl/python, continuously expanding its scope. And no, I'm not >>> looking for an "easy-peasy front-end gui" that'll probably pull in 90% >>> of QT as dependancies. I fondly remember IPCHAINS. >> >> iptables doesn't depend on systemd, perl, or python. > > It has become an all-in-one router/packet-mangler/firewall/QOS/etc > when I simply want a firewall. The required kernel entries have > increased simply for the firewall functionality. Why should you care that iptables has many features that you might not use? There's at most one program on your system for which you use every single feature.
Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
On Wed, Feb 28, 2018 at 04:40:37PM -0700, Grant Taylor wrote > On 02/28/2018 02:15 PM, Walter Dnes wrote: > > Is there something besides iptables? > > nftables Assuming I just want filtering, could I emerge nftables and unmerge iptables and have a functional firewall? -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
On Fri, Mar 2, 2018 at 6:34 PM, Grant Taylor wrote: > On 03/02/2018 05:08 AM, Rich Freeman wrote: >> >> On the other hand, if netfilter were implemented in userspace such as via >> a microkernel, then if it contained a bug the remote attacker would be able >> to MITM all network traffic on the machine, but that would be the extent of >> the access they have. > > > I don't know that it would be the extent of the access the attacker would > have. It might also be a beachhead that could be used as a starting point > for future attacks. How? You'd need a local priv escalation vulnerability to do anything further. If the same bug existed in kernel space you'd already have kernel privs and own the machine. It would be the exact same code whether it is running in userspace or kernelspace. It isn't like code is magically immune to bugs if it is in the kernel. It would probably be maintained by the exact same people either way. > >> The process running the netfilter code doesn't need anything other than a >> pipe back to the kernel to receive packets and send packets back, so it can >> run with minimal privs otherwise. > > > I think that more than a simple pipe (as in unix socket) is needed. > Currently, any program that uses IP is expecting a socket to behave like it > currently behaves. I don't think a simple pipe can provide that. There would be no change to regular software. They would use the same system calls to open sockets. They would send their packets to the kernel. The kernel would send them to the userspace netfilter process. The userspace netfilter process would send them back to the kernel. The kernel would then send them to the physical layer for transport. That is how microkernels work. The kernel is still the central point of contact and the system calls basically work the same way as they do today. However, the kernel offloads as much processing to userspace as possible. With filesystems it is no different with a microkernel. You use the same system calls to write to a file. The data to be written goes to the kernel. However, instead of the kernel calling the filesystem layer in kernel space it instead sends the data via IPC of some sort to a filesystem driver running in userspace. It then sends the raw block device instructions back to the kernel, which then passes it to the device driver for the disk. >> a lot of the boot-time mounting logic and devfs/etc logic has gone away in >> favor of initramfs and udev. > > > Please provide examples of this "…boot-time mounting logic and devfs/etc > logic…" that used to be in kernel. > > I'll argue that devfs is now in kernel when it used to be files on a file > system or dynamically created by a user space process. As far as I know, > mounting (more than root as RO) has always been driven from user space via > init scripts. I'm talking about mounting root. Capabilities such as identifying devices by UUID have not been added to the kernel, with this being done in an initramfs instead. The trends has been in that direction with assembling RAID arrays and such as well. They haven't removed much code that is working, but they haven't been enhancing it either. If you use an initramfs the kernel automatically disables most of the RAID handling. I believe there was a period of time after devfs came along but before udev came along that the complexity of hotplug/etc seemed to be growing on the kernel side. This was quickly recognized as a losing battle which is why we have udev today (or its alternate implementations - one of the benefits of moving this stuff out of the kernel is that it makes it easier to use alternate implementations). Obviously mounting filesystems other than root have never been in the kernel. > Sure, there's a LOT of changes going on in that space, particularly around > (anti)systemd. Well, unless you're referring to udev (which got absorbed by systemd though it is more-or-less still separate), I don't think there is actually a great deal that systemd does that would otherwise be done in kernel space. Maybe some of the maintenance of CGROUPS, but that was all done in userspace from the start, as this trend is fairly established now and it was never done in kernel space. >> And of course if this is done it is done correctly, and not as some kind >> of userspace hack on top of an OS to add features that it lacks. > > ??? > I said that because I think your view might be a bit tainted by previous experiences in Windows/etc. There is a difference between designing a kernel subsystem to provide a capability but to offload some of the work to userspace, and trying to layer some kind of capability into an OS that otherwise lacks it. All this stuff is designed into linux so that it is robust. There are pros and cons to microkernels, and of course linux will probably never turn into a proper microkernel, and I'm not really even saying it should. However, the fact that stuff is done in userspace doesn't mean th
Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
On 03/02/2018 05:08 AM, Rich Freeman wrote: On the other hand, if netfilter were implemented in userspace such as via a microkernel, then if it contained a bug the remote attacker would be able to MITM all network traffic on the machine, but that would be the extent of the access they have. I don't know that it would be the extent of the access the attacker would have. It might also be a beachhead that could be used as a starting point for future attacks. The process running the netfilter code doesn't need anything other than a pipe back to the kernel to receive packets and send packets back, so it can run with minimal privs otherwise. I think that more than a simple pipe (as in unix socket) is needed. Currently, any program that uses IP is expecting a socket to behave like it currently behaves. I don't think a simple pipe can provide that. I can see a way now, using existing technology, to have an isolated firewall that runs in user space. Remove all IP processing from eth0 in the main kernel. Connect eth0 to a User Mode Linux kernel which does the filtering (in user space) and routes the traffic back over another connection to the host kernel, i.e. uml0. +-+ | Host| | +--+ | | | UML Firewall | | -+ eth0eth1 +---uml0 | | +--+ | +-+ Processes running on the host can use the uml0 interface just like they formerly used the eth0 interface. All the firewalling / filtering / routing happens in user space (possibly a container) and independent of the host kernel. a lot of the boot-time mounting logic and devfs/etc logic has gone away in favor of initramfs and udev. Please provide examples of this "…boot-time mounting logic and devfs/etc logic…" that used to be in kernel. I'll argue that devfs is now in kernel when it used to be files on a file system or dynamically created by a user space process. As far as I know, mounting (more than root as RO) has always been driven from user space via init scripts. Sure, there's a LOT of changes going on in that space, particularly around (anti)systemd. But IMHO this has been user space for as long as I have known. Please provide examples where I'm wrong. I'd like to learn. And of course if this is done it is done correctly, and not as some kind of userspace hack on top of an OS to add features that it lacks. ??? -- Grant. . . . unix || die
Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
On Fri, Mar 2, 2018 at 6:42 AM, Heiko Baums wrote: > Am Thu, 1 Mar 2018 21:45:46 -0500 > schrieb Rich Freeman : > >> If they did move netfilter to userspace, then it would > > most likely be more insecure because a userspace process can be easier > bypassed, killed, hacked or whatever. That's a lot harder with the > kernel if not impossible. It is actually the opposite. The whole appeal of microkernels is that they can potentially be a lot more robust. Consider something like netfilter. The code in netfilter is exposed to unfiltered network traffic. If it contains a bug then a remote attacker might be able to run arbitrary code in kernel space, where there is no separation of privs. That code can access everything on the machine. On the other hand, if netfilter were implemented in userspace such as via a microkernel, then if it contained a bug the remote attacker would be able to MITM all network traffic on the machine, but that would be the extent of the access they have. Granted, it still wouldn't be ideal because it probably would include local traffic that might not be encrypted (think localhost traffic and socket connections/etc). Then again, depending on the implementation different interfaces or connections might run in separate processes in which case a remote attacker might only be able to MITM his own connection. The process running the netfilter code doesn't need anything other than a pipe back to the kernel to receive packets and send packets back, so it can run with minimal privs otherwise. The fact that there are convenient command-line utilities to kill a process does not mean that they are less secure/robust than kernel modules. Generally you have to be running as root to kill a process with a different UID, and bugs that allow this to be exploited are treated as severe by the kernel team (and in a microkernel they would be very severe since it is one of the few things the kernel actually does, and since the kernel doesn't do much the things it does do get more attention). If you are root, then you can also mess with the kernel if you want to. You might not know how to do it, but messing with kernel processes certainly isn't impossible, as is crashing your machine. This is why the Linux maintainers actually prefer to move stuff to userspace when it makes sense. They're not looking to transition to a microkernel, but a lot of the boot-time mounting logic and devfs/etc logic has gone away in favor of initramfs and udev. This allows for alternate implementations, and it helps cut down on the complexity of kernel code. And of course if this is done it is done correctly, and not as some kind of userspace hack on top of an OS to add features that it lacks. -- Rich
Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
Am Thu, 1 Mar 2018 21:45:46 -0500 schrieb Rich Freeman : > If they did move netfilter to userspace, then it would most likely be more insecure because a userspace process can be easier bypassed, killed, hacked or whatever. That's a lot harder with the kernel if not impossible. See all those personal firewalls for Windows like Kerio Personal Firewall, Zone Alarm or whatever when Windows didn't have its own firewall. I hope netfilter will never move to userspace. And I'm pretty sure it won't.
Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
On Thu, Mar 1, 2018 at 8:48 PM, Walter Dnes wrote: > On Thu, Mar 01, 2018 at 12:58:44PM -0500, Tom H wrote >> On Wed, Feb 28, 2018 at 4:15 PM, Walter Dnes wrote: >> > >> > Is there something besides iptables? It seems to be like >> > systemd/perl/python, continuously expanding its scope. And no, I'm not >> > looking for an "easy-peasy front-end gui" that'll probably pull in 90% >> > of QT as dependancies. I fondly remember IPCHAINS. >> >> iptables doesn't depend on systemd, perl, or python. > > It has become an all-in-one router/packet-mangler/firewall/QOS/etc > when I simply want a firewall. The required kernel entries have > increased simply for the firewall functionality. > Has it really changed that much for the same requirements? Google suggests that blocking a port is still a one-liner. They've certainly added a lot of functionality, but as far as I'm aware you don't have to use most of it to just filter packets. In any case, netfilter is entirely in the kernel, so you're going to be using it one way or another if you want to use linux. Using a front-end is the easiest way to go with it. I don't really see that Linus has much choice but to accept more scope unless he wants to move netfilter out into userspace, since I'm sure some people need those features and he hasn't really given them any other way to have them. If they did move netfilter to userspace, then it would probably end up working a lot more like dbus, I'm sure that would make you happier... It would enable you to use an alternative implementation, though. Not that anybody will bother to write one because it is easier to let RedHat do all the work. That is generally how most of these things go. Nobody really kills off the ability for a simple tool to work. However, what does happen is that somebody comes up with a fancier tool that covers more edge cases, then all the distros adopt it, because they're shipping it all preconfigured so it isn't that big a deal if the new solution requires 35 configuration files since it isn't like their end-users are editing those files directly. Then more software ends up taking advantage of some of the features offered by this tool, and it becomes harder to avoid using it. If anything netfilter staying in the kernel and picking up all those other features is probably going to be more to your taste than the alternatives... -- Rich
[gentoo-user] [OT] Best *SIMPLE* firewall?
On Thu, Mar 01, 2018 at 12:58:44PM -0500, Tom H wrote > On Wed, Feb 28, 2018 at 4:15 PM, Walter Dnes wrote: > > > > Is there something besides iptables? It seems to be like > > systemd/perl/python, continuously expanding its scope. And no, I'm not > > looking for an "easy-peasy front-end gui" that'll probably pull in 90% > > of QT as dependancies. I fondly remember IPCHAINS. > > iptables doesn't depend on systemd, perl, or python. It has become an all-in-one router/packet-mangler/firewall/QOS/etc when I simply want a firewall. The required kernel entries have increased simply for the firewall functionality. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
On 02/28/2018 02:15 PM, Walter Dnes wrote: Is there something besides iptables? nftables I think BPF may come into context here, but I've mostly ignored it, so I'm not sure. It seems to be like systemd/perl/python, continuously expanding its scope. What do you mean? I've seen newer match extensions and targets over the years. But those are simply additional optional bits. I.e. you need to have the module loaded or compiled into your kernel. I fondly remember IPCHAINS. I vaguely remember ipchains. I don't remember what was before it, ipfwadm(?). Maybe it was my ignorance at the time, but I wouldn't use the word "fondly" to describe my experience with ipchains. I am fond of iptables / ebtables / arptables. I've looked at nftables a few times in the last 18 months and have decided not to take that plunge yet. Usually it's because I feel like I don't have feature parity between iptables and nftables for the iptables features that I use. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
