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@xxxxxxxxxxx> wrote: > 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? 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@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
