Mailing List Archive

On 23/06/2021 15:54, Saint Michael wrote:
> I compiled the latest version, 8.1,
Current version is 8.6p1


> inside Centos 7.9, and to my dismay,
> there was no support for libwrap

It was removed in version 6.7p1, in 2014.

https://serverfault.com/questions/869431/openssh-removed-support-for-tcp-wrappers-now-what-no-hosts-allow-for-ssh-acce

https://github.com/openssh/openssh-portable/commit/f2719b7c2b8a3b14d778d8a6d8dc729b5174b054


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I suggest that we turn it into a ./configure option.
I found the patch but I am unable to adapt it to the current version.
Any volunteers? Also, we need the service definition files for Systemd.
For example, Ubuntu 20.10 supports libwrap
strings $(which sshd)| grep libwrap
libwrap.so.0
libwrap refuse returns
why do we need to ruin the lives of millions of security officers?
I got hacked in 72 servers this week, they installed Bitcoin miners.



On Wed, Jun 23, 2021 at 11:11 AM Brian Candler <b.candler@pobox.com> wrote:

> On 23/06/2021 15:54, Saint Michael wrote:
>
> I compiled the latest version, 8.1,
>
> Current version is 8.6p1
>
>
> inside Centos 7.9, and to my dismay,
> there was no support for libwrap
>
> It was removed in version 6.7p1, in 2014.
>
>
> https://serverfault.com/questions/869431/openssh-removed-support-for-tcp-wrappers-now-what-no-hosts-allow-for-ssh-acce
>
>
> https://github.com/openssh/openssh-portable/commit/f2719b7c2b8a3b14d778d8a6d8dc729b5174b054
>
>
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

There used to someone who was maintaining patches to add TCP wrapper support
to OpenSSH.? The patches are at http://sf.net/projects/mancha/files/misc/
The last version of the patch is for 7.8.

--
Jeff Wieland, UNIX Systems Administrator
Purdue University IT Infrastructure Services UNIX Platforms

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Ubuntu publishes version 8.3 with libwrap support. But for us who
inherited old Centos or RHEL 7 it becomes impossible to update open-ssh.
Any helping hand?
cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.10
ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /usr/lib/x86_64-linux-gnu/libwrap.so.0
(0x00007fc62ad4c000)
root@mexico:~# ssh -V
OpenSSH_8.3p1 Ubuntu-1ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020

On Wed, Jun 23, 2021 at 12:03 PM Saint Michael <venefax@gmail.com> wrote:

> I suggest that we turn it into a ./configure option.
> I found the patch but I am unable to adapt it to the current version.
> Any volunteers? Also, we need the service definition files for Systemd.
> For example, Ubuntu 20.10 supports libwrap
> strings $(which sshd)| grep libwrap
> libwrap.so.0
> libwrap refuse returns
> why do we need to ruin the lives of millions of security officers?
> I got hacked in 72 servers this week, they installed Bitcoin miners.
>
>
>
> On Wed, Jun 23, 2021 at 11:11 AM Brian Candler <b.candler@pobox.com>
> wrote:
>
>> On 23/06/2021 15:54, Saint Michael wrote:
>>
>> I compiled the latest version, 8.1,
>>
>> Current version is 8.6p1
>>
>>
>> inside Centos 7.9, and to my dismay,
>> there was no support for libwrap
>>
>> It was removed in version 6.7p1, in 2014.
>>
>>
>> https://serverfault.com/questions/869431/openssh-removed-support-for-tcp-wrappers-now-what-no-hosts-allow-for-ssh-acce
>>
>>
>> https://github.com/openssh/openssh-portable/commit/f2719b7c2b8a3b14d778d8a6d8dc729b5174b054
>>
>>
>>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, 23 Jun 2021, Saint Michael wrote:

> why do we need to ruin the lives of millions of security officers?
> I got hacked in 72 servers this week, they installed Bitcoin miners.

Uhm… just use a firewall? For example pf can easily handle
permitting access to SSH by host via tables.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 23/06/2021 17:03, Saint Michael wrote:
> I got hacked in 72 servers this week, they installed Bitcoin miners.

Are you saying this happened through opensshd?

What specifically was the cause: do you allow password authentication
for example?

You can control this by IP address with "Match" clauses in sshd_config. 
For example:

PasswordAuthentication no

Match Address 10.0.0.0/8,fc00::/7
PasswordAuthentication yes

This will allow passwords only from the 10.0.0.0/8 and fc00::/7
networks, forcing connections from the Internet to use a proper
authentication mechanism (e.g. keys)

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I use iptables, but all my servers have public IPs, for we do
telecommunications. If my firewall is down for any reason and I don't catch
it, they will hack me. I don't know how they do it, for I have password
authentication disabled, but they hack me and it's always via Centos 7
machines. But Openssh in Centos 7 is so old that cannot communicate with
newer machines, they cannot agree on protocols and ciphers, etc. So I am
trying to compile openssh latest in Centos 7, but no libwrap support. The
perfect storm.
They have been installing Bitcoin miners right and left. I think that they
penetrate a single box that is left with password authentication =yes, and
do a lateral infection. The only failsafe solution is to use hosts.allow.
They can take down a powerplant with this technique. To remove libwrap was
a completely irresponsible move.

On Wed, Jun 23, 2021 at 12:19 PM Brian Candler <b.candler@pobox.com> wrote:

> On 23/06/2021 17:03, Saint Michael wrote:
> > I got hacked in 72 servers this week, they installed Bitcoin miners.
>
> Are you saying this happened through opensshd?
>
> What specifically was the cause: do you allow password authentication
> for example?
>
> You can control this by IP address with "Match" clauses in sshd_config.
> For example:
>
> PasswordAuthentication no
>
> Match Address 10.0.0.0/8,fc00::/7
> PasswordAuthentication yes
>
> This will allow passwords only from the 10.0.0.0/8 and fc00::/7
> networks, forcing connections from the Internet to use a proper
> authentication mechanism (e.g. keys)
>
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Can somebody add a general patch for a ./configure option? Off by default.

<openssh-unix-dev@mindrot.org>

On Wed, Jun 23, 2021 at 12:18 PM Jeff Wieland <wieland@purdue.edu> wrote:

> There used to someone who was maintaining patches to add TCP wrapper
> support
> to OpenSSH. The patches are at http://sf.net/projects/mancha/files/misc/
> The last version of the patch is for 7.8.
>
> --
> Jeff Wieland, UNIX Systems Administrator
> Purdue University IT Infrastructure Services UNIX Platforms
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 6/23/21 5:54 PM, Saint Michael wrote:
> I compiled the latest version, 8.1, inside Centos 7.9, and
[snip]

What use-case would there be there for tcpwrappers that cannot be better
solved with a packet filter? In the case of CentOS 7 you have nftables
and iptables.

/Lars

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi,

On Wed, Jun 23, 2021 at 12:03:58PM -0400, Saint Michael wrote:
> I got hacked in 72 servers this week, they installed Bitcoin miners.

Libwrap is not the right answer for this.

Disable password authentication and/or require 2FA is.

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

The point is: this decision should not have been taken. In any case, it
should have been converted to an option, maybe an option in
/etc/ssh/sshd_config.
Can we fix it?

On Wed, Jun 23, 2021 at 12:36 PM Gert Doering <gert@greenie.muc.de> wrote:

> Hi,
>
> On Wed, Jun 23, 2021 at 12:03:58PM -0400, Saint Michael wrote:
> > I got hacked in 72 servers this week, they installed Bitcoin miners.
>
> Libwrap is not the right answer for this.
>
> Disable password authentication and/or require 2FA is.
>
> gert
> --
> "If was one thing all people took for granted, was conviction that if you
> feed honest figures into a computer, honest figures come out. Never
> doubted
> it myself till I met a computer with a sense of humor."
> Robert A. Heinlein, The Moon is a Harsh
> Mistress
>
> Gert Doering - Munich, Germany
> gert@greenie.muc.de
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> On Jun 23, 2021, at 12:19 PM, Brian Candler <b.candler@pobox.com> wrote:
>
> On 23/06/2021 17:03, Saint Michael wrote:
>> I got hacked in 72 servers this week, they installed Bitcoin miners.
>
> Are you saying this happened through opensshd?
>
> What specifically was the cause: do you allow password authentication for example?
>
> You can control this by IP address with "Match" clauses in sshd_config. For example:
>
> PasswordAuthentication no
>
> Match Address 10.0.0.0/8,fc00::/7
> PasswordAuthentication yes
>
> This will allow passwords only from the 10.0.0.0/8 and fc00::/7 networks, forcing connections from the Internet to use a proper authentication mechanism (e.g. keys)
>
>


Another option would be to setup 2FA through a third party service with OpenSSH. I’ve got duo setup for OpenSSH connections on critical MidnightBSD systems for this reason.




Lucas Holt
Luke@FoolishGames.com
________________________________________________________
MidnightBSD.org (Free OS)
JustJournal.com (Free blogging)




_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

OpenSSH has built-in support for per-user and host restrictions via
the "AllowUsers" and "DenyUsers" settings in /etc/ssh/sshd_config.

Relying on host-based security is not really a good idea but you
can do it with stock OpenSSH if you really need to.

- todd
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

any external app can be down at any time, while openssh remains active and
exposed, BUT libwrap is baked into openssh, so the protection will hold.
Libwrap is the last line of defense. Why remove it?

On Wed, Jun 23, 2021 at 1:01 PM Lars Noodén <lars.nooden@gmx.com> wrote:

> On 6/23/21 5:54 PM, Saint Michael wrote:
> > I compiled the latest version, 8.1, inside Centos 7.9, and
> [snip]
>
> What use-case would there be there for tcpwrappers that cannot be better
> solved with a packet filter? In the case of CentOS 7 you have nftables
> and iptables.
>
> /Lars
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Libwrap has never been part of OpenSSH (or if it was it was removed when
OpenBSD team forked the original SSHv1 source back in 1999).  This has
always been a 3rd party patchset.

Ben

Saint Michael wrote on 6/23/21 12:31 PM:
> any external app can be down at any time, while openssh remains active and
> exposed, BUT libwrap is baked into openssh, so the protection will hold.
> Libwrap is the last line of defense. Why remove it?
>
> On Wed, Jun 23, 2021 at 1:01 PM Lars Noodén <lars.nooden@gmx.com> wrote:
>
>> On 6/23/21 5:54 PM, Saint Michael wrote:
>>> I compiled the latest version, 8.1, inside Centos 7.9, and
>> [snip]
>>
>> What use-case would there be there for tcpwrappers that cannot be better
>> solved with a packet filter? In the case of CentOS 7 you have nftables
>> and iptables.
>>
>> /Lars
>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev@mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 23.06.21 18:27, Saint Michael wrote:
> I use iptables, but all my servers have public IPs, for we do
> telecommunications. If my firewall is down for any reason and I don't catch
> it, they will hack me.

1. You want to start doing that thing called "monitoring".

2. If by "firewall", you mean a unit *other* than the target machines,
from the moment it is "down", it should *NOT* allow any through traffic
to the targets (unless necessary to let an admin remote in to fix the
firewall problem).

3. Otherwise, i.e., all you have is the iptables on the target machines
themselves, you IMHO want to
-- have the sshd listen on a nonstandard port,
-- make the iptables, *if they are up and working*, NAT connection
attempts to port 22 to the real port, and
-- hand a "port cheat sheet" to the admins so that *they* can remote
into some machine to fix the iptables being "down".

I shall stop here with the details, though, because if you don't know
how you get (re)hacked, you don't know whether it's done *through SSH*
in the first place, either (and, if so, whether it's by weak passwords,
an authorized key hidden someplace during the first hack, etc. etc.).

> But Openssh in Centos 7 is so old that cannot communicate with
> newer machines, they cannot agree on protocols and ciphers, etc.

... out of interest, what's your reference standard there, since it
apparently surpasses even hardening guides like
https://www.ssh-audit.com/hardening_guides.html#rhel7 ... ?

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH

I use a non-standard port and they apparently broke a server in an
external datacenter, analyzed history, used the same ssh command with
ad-hoc port number. The box was connected paswordlessly to all my important
boxes and Zas!, Bitcoin miners all over the company.

On Wed, Jun 23, 2021 at 2:02 PM Jochen Bern <Jochen.Bern@binect.de> wrote:

> On 23.06.21 18:27, Saint Michael wrote:
> > I use iptables, but all my servers have public IPs, for we do
> > telecommunications. If my firewall is down for any reason and I don't
> catch
> > it, they will hack me.
>
> 1. You want to start doing that thing called "monitoring".
>
> 2. If by "firewall", you mean a unit *other* than the target machines,
> from the moment it is "down", it should *NOT* allow any through traffic
> to the targets (unless necessary to let an admin remote in to fix the
> firewall problem).
>
> 3. Otherwise, i.e., all you have is the iptables on the target machines
> themselves, you IMHO want to
> -- have the sshd listen on a nonstandard port,
> -- make the iptables, *if they are up and working*, NAT connection
> attempts to port 22 to the real port, and
> -- hand a "port cheat sheet" to the admins so that *they* can remote
> into some machine to fix the iptables being "down".
>
> I shall stop here with the details, though, because if you don't know
> how you get (re)hacked, you don't know whether it's done *through SSH*
> in the first place, either (and, if so, whether it's by weak passwords,
> an authorized key hidden someplace during the first hack, etc. etc.).
>
> > But Openssh in Centos 7 is so old that cannot communicate with
> > newer machines, they cannot agree on protocols and ciphers, etc.
>
> ... out of interest, what's your reference standard there, since it
> apparently surpasses even hardening guides like
> https://www.ssh-audit.com/hardening_guides.html#rhel7 ... ?
>
> Regards,
> --
> Jochen Bern
> Systemingenieur
>
> Binect GmbH
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 23.06.21 20:12, Saint Michael wrote:
> I use a non-standard port and they apparently broke a server in an
> external datacenter, analyzed history, used the same ssh command with
> ad-hoc port number. The box was connected paswordlessly to all my important
> boxes and Zas!, Bitcoin miners all over the company.

Well, if you got hacked through some legitimately *trusted* external
machine that is *required* to be able to do unattended logins, I don't
quite see how TCP Wrappers could have prevented that ...

(In the meantime, I remembered that there's a "traditional" way to put
some service under TCP Wrappers, as long as it can run under an inetd;
CentOS 7's repos offer a package tcp_wrappers that contains the required
/usr/sbin/tcpd . But I suppose that OpenSSH sshd doesn't have inetd mode
support, either, even if someone were willing to sacrifice the builtin
rate limiting etc. in favor of TCP Wrappers ... ?)

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH

iptables is not an external app. It's never "down" any more than
/etc/hosts.deny is down. What can tcpwrappers do that iptables cannot do
even better?


Tom.III


On Wed, Jun 23, 2021 at 10:32 AM Saint Michael <venefax@gmail.com> wrote:

> any external app can be down at any time, while openssh remains active and
> exposed, BUT libwrap is baked into openssh, so the protection will hold.
> Libwrap is the last line of defense. Why remove it?
>
> On Wed, Jun 23, 2021 at 1:01 PM Lars Noodén <lars.nooden@gmx.com> wrote:
>
> > On 6/23/21 5:54 PM, Saint Michael wrote:
> > > I compiled the latest version, 8.1, inside Centos 7.9, and
> > [snip]
> >
> > What use-case would there be there for tcpwrappers that cannot be better
> > solved with a packet filter? In the case of CentOS 7 you have nftables
> > and iptables.
> >
> > /Lars
> >
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev@mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Saint Michael wrote:
> I compiled the latest version, 8.1, inside Centos 7.9, and to my dismay,
> there was no support for libwrap

Be aware that many Linux distributions make changes to the upstream
release as part of their packages.

It's wise to consider whether that's actually in ones interest on a
case-by-case basis.

If "recent" distribution OpenSSH packages support libwrap then that's
such a modification, made by the distribution.


> I didn’t find service definitions for Systemd. ¿where can I find them?

systemd integration in OpenSSH, which Red Hat (the company) distributes
plenty of, is another such modification by the distribution.

If you look closer into this you'll find that few distributions actually
make independent, informed decisions - herd mentality is strong.

Upstream OpenSSH doesn't support systemd at all at the moment, and thus
also doesn't distribute unit files.

Running upstream sshd under systemd works anyway, but you can run
into problems if you expect everything that systemd provides to work
according to the systemd model - it will not, potentially leaving the
system without a running sshd.


> How do I overcome these obstacles?

As far as I know there exists no sensible sshd+systemd integration.

Red Hat (the company) distributes an sshd that depends on libsystemd.so,
which I find a horrible idea. I think debian (thus also Ubuntu) have
followed along and use the same patches.

I've written and proposed a small standalone sd_notify() implementation
to be used instead of libsystemd.so, but I don't think anyone uses it.

Personally I wouldn't mind upstream OpenSSH supporting systemd Type=notify
but I expect nothing.


> we should keep libwrap baked into openssh, even as optional.

I don't think upstream OpenSSH will support it. Like others I
recommend you to place useful firewall rules on every system and
to monitor that they are in effect.

Oh, and don't assume that the visible Bitcoin miner is the only thing
that was installed on your compromised servers; boot from CD and take
a closer look.


Kind regards

//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

TCP wrappers? The 1990s just called, and they want their O'Reilly network security book back.

Seriously, I hear phone and power networks, and TCP wrappers are the best defense-in-depth that can be done? We're doomed as a species.

At the very least, you can use https://cr.yp.to/ucspi-tcp.html and https://cr.yp.to/daemontools.html for reliable alternatives to TCP wrappers and systems, respectively.

At best, you should be using on-host iptables, public-key or certificate authentication, and other modern methods to secure your systems....

--
jmk

> On Jun 23, 2021, at 11:52, Thomas Dwyer III <tomiii@tomiii.com> wrote:
>
> ?iptables is not an external app. It's never "down" any more than
> /etc/hosts.deny is down. What can tcpwrappers do that iptables cannot do
> even better?
>
>
> Tom.III
>
>
>> On Wed, Jun 23, 2021 at 10:32 AM Saint Michael <venefax@gmail.com> wrote:
>>
>> any external app can be down at any time, while openssh remains active and
>> exposed, BUT libwrap is baked into openssh, so the protection will hold.
>> Libwrap is the last line of defense. Why remove it?
>>
>>> On Wed, Jun 23, 2021 at 1:01 PM Lars Noodén <lars.nooden@gmx.com> wrote:
>>>
>>> On 6/23/21 5:54 PM, Saint Michael wrote:
>>>> I compiled the latest version, 8.1, inside Centos 7.9, and
>>> [snip]
>>>
>>> What use-case would there be there for tcpwrappers that cannot be better
>>> solved with a packet filter? In the case of CentOS 7 you have nftables
>>> and iptables.
>>>
>>> /Lars
>>>
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev@mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev@mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

The problem is that the people who invented security audits never remove anything from the list of things they will ding you with… If you are getting paid to pass all of these benchmarks, you have keep everything around forever.

From: openssh-unix-dev <openssh-unix-dev-bounces+herbie.robinson=stratus.com@mindrot.org> On Behalf Of Jim Knoble
Sent: Wednesday, June 23, 2021 7:25 PM
To: Thomas Dwyer III <tomiii@tomiii.com>
Cc: Saint Michael <venefax@gmail.com>; Lars Noodén <lars.nooden@gmx.com>; openssh-unix-dev@mindrot.org
Subject: [EXTERNAL] Re: Bringing back tcp wrappers

[.EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.]

TCP wrappers? The 1990s just called, and they want their O'Reilly network security book back.

Seriously, I hear phone and power networks, and TCP wrappers are the best defense-in-depth that can be done? We're doomed as a species.

At the very least, you can use https://cr.yp.to/ucspi-tcp.html<https://cr.yp.to/ucspi-tcp.html> and https://cr.yp.to/daemontools.html<https://cr.yp.to/daemontools.html> for reliable alternatives to TCP wrappers and systems, respectively.

At best, you should be using on-host iptables, public-key or certificate authentication, and other modern methods to secure your systems....

--
jmk

> On Jun 23, 2021, at 11:52, Thomas Dwyer III <tomiii@tomiii.com<mailto:tomiii@tomiii.com>> wrote:
>
> ?iptables is not an external app. It's never "down" any more than
> /etc/hosts.deny is down. What can tcpwrappers do that iptables cannot do
> even better?
>
>
> Tom.III
>
>
>> On Wed, Jun 23, 2021 at 10:32 AM Saint Michael <venefax@gmail.com<mailto:venefax@gmail.com>> wrote:
>>
>> any external app can be down at any time, while openssh remains active and
>> exposed, BUT libwrap is baked into openssh, so the protection will hold.
>> Libwrap is the last line of defense. Why remove it?
>>
>>> On Wed, Jun 23, 2021 at 1:01 PM Lars Noodén <lars.nooden@gmx.com<mailto:lars.nooden@gmx.com>> wrote:
>>>
>>> On 6/23/21 5:54 PM, Saint Michael wrote:
>>>> I compiled the latest version, 8.1, inside Centos 7.9, and
>>> [snip]
>>>
>>> What use-case would there be there for tcpwrappers that cannot be better
>>> solved with a packet filter? In the case of CentOS 7 you have nftables
>>> and iptables.
>>>
>>> /Lars
>>>
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev@mindrot.org<mailto:openssh-unix-dev@mindrot.org>
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
>>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev@mindrot.org<mailto:openssh-unix-dev@mindrot.org>
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
>>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org<mailto:openssh-unix-dev@mindrot.org>
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org<mailto:openssh-unix-dev@mindrot.org>
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, Jun 23, 2021 at 06:15:12PM +0200, Thorsten Glaser <t.glaser@tarent.de> wrote:

> On Wed, 23 Jun 2021, Saint Michael wrote:
>
> > why do we need to ruin the lives of millions of security officers?
> > I got hacked in 72 servers this week, they installed Bitcoin miners.
>
> Uhm… just use a firewall? For example pf can easily handle
> permitting access to SSH by host via tables.
>
> bye,
> //mirabilos

You can even have a little script that parses /etc/hosts.allow
(even if sshd itself doesn't consult it), and creates firewall
rules based on its contents. That way, it doesn't matter if the
firewall is briefly down. Debian's sshd uses libwrap but I do
this anyway because it's an easy way to manage the firewall,
and because it dramatically reduces the sshd logs.

cheers,
raf

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, Jun 23, 2021 at 12:48:15PM -0500, Ben Lindstrom wrote:
> Libwrap has never been part of OpenSSH (or if it was it was removed when
> OpenBSD team forked the original SSHv1 source back in 1999).  This has
> always been a 3rd party patchset.

This is incorrect: the supporting code was in upstream OpenSSH (provided
you compiled with -DLIBWRAP, or used the portable configure script)
until
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd.c.diff?r1=1.420&r2=1.421,
and https://www.openssh.com/txt/release-6.7 logs the removal of the
feature.

--
Colin Watson (he/him) [cjwatson@debian.org]
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev