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). -- 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.
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
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? 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 "bruteforce" attacks to be collected and if necessary acted upon also in a centralised and consistent manner. 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.> 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. 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. 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*. 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. 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=