| > A lot of machines are not open to the public internet, so this probably doesn't apply there. An internal audit is enough to trigger it. "Port scan crashes machine" is not exactly "reliable software". > You can also use some cgroup managing tool (like systemd) to restrict memory usage to the process and configure the OOM killer behavior, so that would also prevent DoS attacks. But that means that the default is bad, and unsuitable for resource constrained machines. Which circles back to "neat, but no actual use case". > Actually no, this is wrong, at least for me when I tried the version of netstat that ships with debian. It only shows if something has the port open -- that thing could be an fd holding service So you agree that it's a bad idea? > So you're right that this complicates the system but this isn't really systemd's fault It is, because it's needless complication. At least inetd was a model to make things simpler. It's the cgi-bin of network services. But you'll notice that people don't write inetd-based services anymore. In fact my Ubuntu default install doesn't even have inetd installed. > The only way to know for sure is to use a different tool that prints information about the owning process netstat has supported this for (maybe) decades on Linux. It's the -p option. But aside from systemd's poor choices if you see port 22 open, then you can actually be very sure that there is an sshd running, that successfully started (not too broken config). You could still be wrong. Someone could have started netcat there, or just a honeypot, or whatever, but you can't tell me it's not useful information. > Well now you got me confused, this seems to be directly conflicting with when you said this: "It will show you if you have an SSH server running" … unless systemd broke this functionality. I'm making the point why it's a bad idea to break this. Clients connecting will also not get useful error messages. Port is closed means service not running. Timed out waiting for SSH banner means something else. Pre systemd it was essentially never anything other than inetd that held ports for others. And for about the last 20 years even it would only do things like echo,chargen,time service that people would run. And having those open by default is from a more naive time, where people thought "sure, why not run tftpd and time service, would could possibly go wrong?". Nowadays they're off by default, because we're more experienced that any attack surface is still an attack surface, no matter how small. Probably it helped that OpenBSD kept bragging about how many remote holes in the default install. It's not actually because OpenBSD had better code, it was just that a default OpenBSD only had OpenSSH open to the world. |
I'm not sure I understand where you're coming from here? I explained how it could be made suitable, it could be done in a way that was crash resistant. I don't know if it's a bad idea or not, it depends on what you're trying to accomplish. The default here is configured by the distro, so you could expect to see a different default on an embedded distro.
>In fact my Ubuntu default install doesn't even have inetd installed.
I believe this is mostly because systemd has replaced its functionality.
>netstat has supported this for (maybe) decades on Linux. It's the -p option.
Good call, I forgot about that, I always use lsof. But that's exactly what I mean, it will show you which pid has the port open, so it will make it obvious if it's systemd or sshd. You won't be sure if there is actually an sshd running unless you check that. This really seems like a non-issue, you have all the tools you need to troubleshoot it.
>systemd broke this functionality. [...] Port is closed means service not running. [...] Pre systemd it was essentially never anything other than inetd that held ports for others.
I don't really want to discuss this anymore if I have to repeat myself, but this is not correct. There are multiple other reasons why you would have another service holding the fd open, such as load balancers, filtering proxies, userspace firewalls, etc, etc. The ability to pass an fd to a child process is an intentional feature of every Unix-like operating system that I've used. Systemd is only using the feature as the OS intended it, which is also supported on OpenBSD.