Quoting Stephan von Krawczynski <skraw@xxxxxxxxxx>: > 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= _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
