Date: Fri, 14 Feb 2020 19:04:56 -0800 (PST) From: Roger Marquis <marquis@roble.com> To: freebsd-security@freebsd.org, freebsd-current@freebsd.org Subject: Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd Message-ID: <nycvar.OFS.7.77.840.2002141841590.89032@mx.roble.com> In-Reply-To: <CAOc73CCtw2TKhfCQUcaPAri8CTgL2Vnb3UKV0y1dnrYo_iaxTA@mail.gmail.com> References: <CAPyFy2Die2tynFM3m3-5zBtWAOpHf-QHY-bE2JY7KKGiP8Tz_Q@mail.gmail.com> <4627295.A1yGqSNMk2@deborah> <CAOc73CCtw2TKhfCQUcaPAri8CTgL2Vnb3UKV0y1dnrYo_iaxTA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In the interest of good logging it may be better to filter ssh attempts with libwrap than with packet filtering. The difference being that libwrap logging, particularly when used with fail2ban, tends to be more readable and parseable. Not having libwrap in sshd is most simply and easily worked around, IMO, by running it from inetd. While less experienced sysadmins may not be familiar with inetd, and some others believe it impacts session setup time, 99.99% of sshd implementations will not see any difference between sshd linked with libwrap vs unlinked and run under inetd. Performance might be an issue is when dozens or hundreds of sessions are received per minute but then those sites are likely to already have load balancing. FreeBSD's inetd also has more instance and rate-limiting options than libwrap or packet filtering. I wouldn't be surprised if this was part of the reason why it is no longer bundled. Roger Marquis > Upstream OpenSSH-portable removed libwrap support in version 6.7, > released in October 2014. We've maintained a patch in our tree to > restore it, but it causes friction on each OpenSSH update and may > introduce security vulnerabilities not present upstream. It's (past) > time to remove it. > >> So color me ignorant, but how does this affect things like DenyHosts? Or >> is there an in-application way to block dictionary attacks? I can't go back >> to having my servers pounded on day and night (and yes, I listed on an >> alternative port).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?nycvar.OFS.7.77.840.2002141841590.89032>