Re-install libwrap in OpenSSH

[Nico Kadel-Garcia]

Please note: I am not a huge fan of libwrap, but the logic below has
some very real flaws. I'd like to ensure that it's not accepted as
complete or convincing in and of itself.

On Thu, May 21, 2015 at 4:35 AM, Malcolm <opensshdev at r.paypc.com> wrote:
> Quoting Stephan von Krawczynski <skraw at ithnet.com>:
>
>> Let alone all the useless suggestions involving
>> firewall->systemd->fail2ban schemes which do not help at all against stolen
>> passwords or keys. Risk does increase with complexity of security measures
>> so firewall per se is no real comparable option. Reasonable firewall rules
>> tend to look like spaghetti code implementing a bigger number of
>> to-be-whitelisted ips.
>
> Why would they end up that way?

Because most firewall admins make only one line changes, and are
scared spitless of breaking active services in a live environment. The
result is spaghetti code.

> Most organisations place firewalls at their network border or edge, and
> implement service access policies in a consistent and transparent manner as
> far as the servicing hosts themselves are concerned.  Log coalescing allows

At the edge, yes. Consistent and transparent? Oh, dear Lord, no. Most
network groups are quite secretive about their network configurations,
presenting a "just tell us what you need and we will do it" rather
than being willing to share backups. I've in fact offered to refine
the backup tools to strip critical SSL keys and encrypted passwords so
that the data could be shared with the operations group, and been
confronted with complete stonewalling from the network admins in
almost every place I've worked in the last 20 years. And since
checklists and guidelines often present confusing interfaces, the
backups remain the real way to review what is *actually* being
filtered.

> "bruteforce" attacks to be collected and if necessary acted upon also in a
> centralised and consistent manner.

It could, yes, if the owners of the individual hosts could or would
allow those logs to be centralized, and if resources were allocated to
manage and review that collection. But those logs often, themselves,
contain security sensitive data, such as usernames and passwords from
accidentally swapped word swapped login sessions. It gets much, much
worse if the log aggregation includes command line history, which more
and more companies are doing" "Centrify" software makes a big deal of
their modified shells that provide such logs, and I sent them some
patches for their modified SSH servers.

> The "economy" of which you speak regarding libwrap functionality sounds like
> each host you run operates like an island unto itself, rather than as a
> coordinated team of servers managed by consistent policy.

This is, in fact, normal. Also, mistakes in libwrap do not take out
the firewall for the entire company, including the access to the
firewall itself. They can be implemented on weekends and only take out
a few services on one server, with a *much* smaller risk of
repercussions.

>> In the end, every replacement for libwrap is just a risky and bad patch for
>> the real thing. So why throw away code that works since decades, is simple,
>> has simple usage pattern?
>
> The OpenSSH team has no doubt looked at the "risk profile" of linking to
> various bits of code, and libwrap is by no means the only one to see a
> potential axe here.
>
> Notice too that OpenSSL's track record has gotten to the point where the
> OpenSSH team has looked to allow system administrators to build sshd/ssh
> WITHOUT linking against any OpenSSL code at all.  Given how much cruft and
> "legacy" support that's been exploited for years by hackers and three-lettered
> US agencies alike, I think that's a sensible posture, to be honest.

Heck, yes. Others in the OpenBSD community are even working on
LibreSSL, which I applaud them for.

> I just realised that I spent a non-trivial amount of time DISABLING
> MACs/KEXs/Ciphers across my entire organisation to the point where simply
> building without any OpenSSL would have probably saved much more time to start
> with!  At some point, I think I'll make a "split patch" where the clients
> (ssh/scp) can get built one way and the server components another.

If it can be done as a ./configure option, that seems like a pretty good idea.

> Sure, I can simply build it twice and manually merge them today, but I'm a
> software engineer, not a system administrator, and I'm *LAZY*.

I'm not using hosts.allow these days: and having multiple compilation
options requires more testing and more test cases.

> Your approach is both counterproductive, and unnecessary.  If you actually
> looked through the archives, you'll find patches to re-incorporate support for
> libwrap without any difficulty whatsoever into OpenSSH.

Been there, done that., especially for chroot cages for rsync and ssh.
scp and sftp has never been sufficient for reliable content mirroring,
due to inconsistent local timezone handling in the protocols and the
inability to handle symlinks and hardlinks completely. The result has
been nasty: if I'm going to allow rsync uploads, I have to manually
fork OpenSSH for the old chroot cage patches, which have been
consistently refused by the core maintainers, and keep remerging and
manually updating that fork with every OpenSSH update. This is much
easier now with git managed code, I admit, but it's still a pain in
the keister.

These days I'm using rssh with OpenSSH instead, and even publish and
have submitted a chroot cage builder for it at
https://github.com/nkadel/rssh-chroot-tools. I'm not wildly enthused
about rssh, but it beats the heck out of maintaining my own OpenSSH
builds,a nd the 'mkchroot.sh' tool is useful for either.

> It sounds like you are wanting to have it both ways - you mention a loathing
> for "fail2ban" and similar strategies - which are entirely automated surgical
> firewalling rules put into place to reduce bruteforce attack pressure on
> hosts, versus the "labour cost differential" of hand-edited host.allow/deny
> files.
>
> Are you saying that you prefer to manually enter and retire "attacking hosts'
> IP#s" that have too many password failures against your servers?
>
> =Malcolm=

fail2ban solves different problems, and is itself often a useful tool.


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