Re-install libwrap in OpenSSH

[Stephan von Krawczynski]

On Thu, 21 May 2015 09:28:05 +1000
Darren Tucker <dtucker at zip.com.au> wrote:

> On Thu, May 21, 2015 at 1:05 AM, Michael Stone <mstone at mathom.us> wrote:
> 
> > On Wed, May 20, 2015 at 03:58:22PM +0200, Stephan von Krawczynski wrote:
> >
> >> Show me this as an example of your firewall skills and replace this
> >> hosts.allow entry:
> >>
> >> sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected
> >> me |
> >> /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW
> >>
> >>
> >> This is only an example code, of course.
> >>
> >
> > It's an example of something really horrible. It might have seemed like a
> > good idea in the 90s, but in a modern system that sort of alerting should
> > be integrated into log monitoring (and should be much more comprehensive
> > than a couple of services linked against wrappers).
> >
> 
> Note that you can still do that by starting sshd under tcpd+inetd,
> something like:
> 
> ssh stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sshd -i
> 
> or the equivalent in your inetd-alike.  For SSHv2 connections it should be
> about the same speed (it'll be slower for Protocol 1 connections because
> each connection will need to generate a new ephemeral host key, but that's
> probably a plus from a security standpoint).

Thanks for your suggestion, one of the very few constructive postings
regarding the issue. But if you compare the work loaded on admins all around
the world produced by removing such a small piece of code to its benefits,
don't you think the whole story looks more like a weird political issue. The
maintainers cannot be that braindead to think they can tilt libwrap
alltogether, there is wide use of it, probably more than OpenSSH. So the users
and admins end up in a system where the majority of code is quite happy with
libwrap and openSSH refusing it - without true replacement.
If you do a risk-analysis, you have to admit that simply by using two binaries
(inet+sshd) instead of one with an immanent security feature (sshd+libwrap)
things have gotten worse. 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.
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? If you cut off one of your legs, you cannot expect
to run as fast and easy as one who doesn't even if you own a wheel chair.
 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.


-- 
Regards,
Stephan