Hey Ben. Nice to see a package for that :-)
On Tue, 2024-06-25 at 00:46 +0200, Ben Hutchings wrote: > > net.ipv4.conf.all.rp_filter=1 > > This is (effectively) set to 2 by the new configuration. Just wondered why not using 1? AFAIU, the RFC would recommend strict mode (1). Does that break anything that is widely used? I've used 1 on workstations and servers for over a decade now and never really noticed any issues. > > net.ipv4.conf.all.accept_redirects = 0 > > This is not set by the new configuration. The kernel default for > this > is the inverse of net.ipv4.conf.all.forwarding, so it will be set on > routers but not hosts. Sure about that? The kernel docs seem to say it will be enabled on hosts, and disabled on routers. Or did you simply mean "will be set (to 0)"? Still, question is... what for are ICMP redirects needed on normal hosts? The old procps sysctl.conf documented it as preventing some spoofing attacks... and as above, I've had these set on both desktops and larger server clusters doing quite some networking for at least over a decade and never saw any need for enabling it. > > net.ipv6.conf.all.accept_redirects = 0 > > This is not set and the kernel default is still 1. Well, basically same as above. Is there any real world thing that needs ICMP redirects to be to be accpeded? > > net.ipv4.conf.all.send_redirects = 0 > > This is not set and the kernel default is still 1. It's documented > to > only affect routers but I'm not sure if that's true. Not an ICMP expert, but I'd guess it's okay to leave it enabled. At least it sounds as if could not affect the local security, since the respective host would be the evil guy that sends a redirect to do nasty things. I mainly had it set because procps' sysctl.conf contained it. > > > net.ipv6.conf.all.accept_source_route = 0 > > That has always been the kernel default value. btw: Seems that 0 doesn't actually disable it completely for v6,... that would require a negative value (at least according to docs). > > 1) The vast majority of Debian installations are NOT used as rooter > > I think this is longer true: anything hosting VMs or containers that > have networking acts a router. Hmm, even with that I'd rather tend to say it's not the majority, or is it?! Well I don't have any representative numbers either,... but at least that's what's my experience from our supercomputing centre here, and the clusters we run there. Typically we have some servers which are dedicated for virtualisation/containers and others which are not. Even if the latter do run containers, that's usually just a local thing (and typically in the same namespace as the host). Desktops/workstations may run containers but still... does it happen often that real routing is done there? In my experience it's rather some bridging or NAT, and that seem to work with all the restricted settings (or they simply enable whichever feature they need once started - which is IMO the proper thing to do). > I think it can be acceptable to break really unusual configurations > if > we provide appropriate notification in NEWS and release notes. > > But like I said, I don't think routers are that rare now. > > Which of the above would be a problem for routers? Cannot really tell,... I've never run Linux as a dedicated router but only did some minor works in netfilter PREROUTING and POSTROUTING (like for NAT or redirecting ports). And there I at least don't recall any case where my current systctl.conf settings, which are: net.ipv4.conf.default.rp_filter=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.ip_forward=0 net.ipv6.conf.all.forwarding=0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 net.ipv4.conf.all.log_martians = 1 caused troubles. For local VMs on the desktop I use libvirt+QEMU with NAT as mode, and that seems to work, too (though it may just set whatever it needs when started, haven't really checked). btw: Does anyone know why fs.protected_fifos isn't set to the stricter `2`? I guess you just took that from systemd, which set it (to 1) in https://github.com/systemd/systemd/commit/2732587540035227fe59e4b64b60127352611b35 but no real explanation whether there are any use cases which would be broken by `2`. Anyway... apart from the above points/questions I'd say we can mark my original issue as done? Cheers, Chris.
