You could use a drop-in unit to wrap sshd in tcpd, as suggested by theThis would require to switch to socket activation of sshd, which is not
Fedora wiki page? This would avoid exposing sshd's process space to
libwrap and all the stuff it links to by default.
On Wed, 03 Apr 2024 14:10:37 +0100, "Jonathan Dowland"
<jmtd@debian.org> wrote:
For you and fellow greybeards, perhaps: I'd be surprised if many people >younger than us have even heard of tcp wrappers. I don't think the
muscle memory of a diminishing set of users is a strong argument, >especially given it's a preference rather than a requirement, and >alternatives do exist.
It is possible to have that alternative not present without being
noticed (for example, a firewall build script failing, but sshd start
nof failing), whilea security measure built into the very daemon is
way harder to be accidentally disabled while keeping the daemon
running.
I personally moved to nftables which is nearly as simple once you get
your muscle memory set.
These times have long gone and tcp wrapper as a security mechanism has
lost its reliability, this is why people started moving away from tcp
wrapper (which i think is a shame)
I personally moved to nftables which is nearly as simple once you get
your muscle memory set. If ssh is your only candidate of network service
you could also use match statements in /etc/ssh/sshd_config.d/.
* add dependency-only packages called something like
openssh-client-gsskex and openssh-server-gsskex, depending on their
non-gsskex alternatives
* add NEWS.Debian entry saying that people need to install these
packages if they want to retain GSS-API key exchange support
* add release note saying the same
* for Debian trixie+1 (or maybe after the next Ubuntu LTS, depending on
exact timings):
* add separate openssh-gsskex source package, carrying gssapi.patch
in addition to whatever's in openssh, and whose binary packages
Conflicts/Replaces/Provides the corresponding ones from openssh
* add some kind of regular CI to warn about openssh-gsskex being out
of date relative to openssh
* drop gssapi.patch from openssh, except for small patches to
configuration file handling to accept the relevant options with
some kind of informative warning (compare
https://bugs.debian.org/152657)
We carry a patch to restore support for TCP wrappers, which was dropped
in OpenSSH 6.7 (October 2014); see >https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html >and thread. That wasn't long before the Debian 8 (jessie) freeze, and
so I patched it back in "temporarily", but then I dropped the ball on >organizing a proper transition.
All the same, I'm aware that some people now depend on having this
facility in Debian's main openssh package: I get enough occasional
bug
reports to convince me that it's still in use.
On Apr 02, Colin Watson <cjwatson@debian.org> wrote:
At the time, denyhosts was popular, but it was removed from DebianYes, people. I object to removing TCP wrappers support since the patch
several years ago. I remember that, when I dealt with that on my own
systems, fail2ban seemed like the obvious replacement, and my impression
is that it's pretty widely used nowadays; it's very pluggable but it
normally works by adding firewall rules. Are there any similar popular
systems left that rely on editing /etc/hosts.deny?
is tiny and it supports use cases like DNS-based ACLs which cannot be supported by L3 firewalls.
If libwrap is bringing in complex libs, maybe we could reduce the
attack surface on libwrap itself? It would be nice to have a variant
that only links to the libc and that's it...
Another thing we're considering in OpenSSH is changing how we integrate
with PAM. PAM's API demands loading modules into the authenticating
process' address space, but obviously we've just been reminded that this
is risky.
I think that I would prefer to move to a model where there PAM auth and account modules run in a helper process, and only the session module
runs in the unprivileged post-auth sshd process.
This means that PAM auth/account modules and their transitive library dependencies cannot affect the sshd address space. They would still
likely need to run with privilege, could still fail permissively in
unwanted situations and might still be able to cause problems directly
(e.g. opening a reverse shell from the PAM module itself), but they
would no longer have direct access to the contents of sshd network
traffic, signatures, etc that are extremely useful in building NOBUS (https://en.wikipedia.org/wiki/NOBUS) backdoors like the xv one.
Where this gets challenging is that some PAM modules make assumptions
that the auth, account and session modules all run in the same address
space. These would break until re-architected to pass things explicitly,
e.g. via environment variables, temp files, etc.
On Tue Apr 2, 2024 at 12:30 PM BST, Marc Haber wrote:
Please don't drop the mechanism that saved my¹ unstable installations
from being vulnerable to the current xz-based attack. Just having to
dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to
maintain a packet filter.
For you and fellow greybeards, perhaps: I'd be surprised if many people >younger than us have even heard of tcp wrappers. I don't think the
muscle memory of a diminishing set of users is a strong argument,
especially given it's a preference rather than a requirement, and >alternatives do exist.
from being vulnerable to the current xz-based attack. Just having to
dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to >maintain a packet filter.
TCP wrappers
============
SELinux
=======
For the time being my inclination is to leave this be, but I've seen the suggestion that pam_selinux is basically all you need (https://infosec.exchange/@alwayscurious/112192949171400643), so maybe
it would be an option to drop --with-selinux in favour of that? I've
never used SELinux, so I'd need an expert to weigh on here.
To speed things up for those who really want it, perhaps make openssh-client/server dependency-only packages on openssh-client/server-nogss? People can choose the less-compatible version for this release if they want to, and the default can change next release. Pushing back the ability to install the unpatched version for a few more years seems suboptimal.
Am Di, Apr 02, 2024 at 13:30:43 +0200 schrieb Marc Haber:
from being vulnerable to the current xz-based attack. Just having to
dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to >>maintain a packet filter.
Stupid question, but if you put „ALL: ALL” into hosts.deny, couldn’t you >stop the ssh daemon instead? ALL: ALL will block your ssh access, so it >doesn’t matter if the daemon is running or not.
GSS-API key exchange
====================
However, OpenSSH upstream has long rejected it
All the same, I'm aware that some people now depend on having this
facility in Debian's main openssh package
How does this rough plan sound?
* for Debian trixie (current testing):
* add dependency-only packages called something like
openssh-client-gsskex and openssh-server-gsskex, depending on their
non-gsskex alternatives
* add NEWS.Debian entry saying that people need to install these
packages if they want to retain GSS-API key exchange support
* add release note saying the same
[I've CCed openssh-unix-dev for awareness, but set Mail-Followup-To to
just debian-devel and debian-ssh to avoid potentially spamming them
with a long discussion. If you choose to override this then that's
your call, but please be mindful of upstream's time.]
On Tue, 2 Apr 2024 01:30:10 +0100, Colin Watson <cjwatson@debian.org>
wrote:
We carry a patch to restore support for TCP wrappers, which was dropped
in OpenSSH 6.7 (October 2014); see >https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html >and thread. That wasn't long before the Debian 8 (jessie) freeze, and
so I patched it back in "temporarily", but then I dropped the ball on >organizing a proper transition.
Please don't drop the mechanism that saved my¹ unstable installations
from being vulnerable to the current xz-based attack. Just having to
dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to maintain a packet filter.
Greetings
Marc
¹ and probably thousands others
There are more than enough ways to keep the entries based on dnsNot for the form *.domain.tld.
records in your l3 firewalls uptodate, I can't see how this should
warrant to keep yet another patch Jan^WMarco.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 24:56:00 |
| Calls: | 6,707 |
| Calls today: | 1 |
| Files: | 12,239 |
| Messages: | 5,352,379 |