Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd
On 2/14/20 6:37 PM, Ben Woods wrote: > On Sat, 15 Feb 2020 at 4:27 am, Joey Kelly wrote: > >> On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote: >>> 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). > > > DenyHosts can be configured to use PF firewall tables directly, rather than > using TCP wrappers: > https://github.com/denyhosts/denyhosts/blob/master/denyhosts.conf#L261 > Requiring the addition of a firewall where there was none before is a significant and potentially error-prone change. I am not about to add this degree of complexity to every machine which only has a single port exposed via NAT. To maintain equivalent functionality, the port version (security/openssh-portable) has the requisite patch as an option or, perhaps better, the base SSHD can be run from INETD and, consequently, TCP-wrapped as it was before, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd
On Sat, 15 Feb 2020 at 4:27 am, Joey Kelly wrote: > On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote: > > 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). DenyHosts can be configured to use PF firewall tables directly, rather than using TCP wrappers: https://github.com/denyhosts/denyhosts/blob/master/denyhosts.conf#L261 ### # # On FreeBSD/OpenBSD/TrueOS/PC-BSD/NetBSD/OS X we may want to block incoming # traffic using the PF firewall instead of the hosts.deny file # (aka tcp_wrapper). # The admin can set up a PF table that is persistent # and DenyHost can add new addresses to be blocked to that table. # The TrueOS operating system enables this by default, blocking # all addresses in the "blacklist" table. # # To have DenyHost update the blocking PF table in real time, uncomment # these next two options. Make sure the table name specificed # is one created in the pf.conf file of your operating system. # The PFCTL_PATH variable must point to the pfctl extectuable on your OS. # PFCTL_PATH = /sbin/pfctl # PF_TABLE = blacklist # Note, a good rule to have in your pf.conf file to enable the # blacklist table is: # # table persist file "/etc/blacklist" # block in quick from to any # # Warning: If you are using PF, please make sure to disable the # IPTABLES rule above as these two packet filters should not be # run together on the same operating system. # Note: Even if you decide to run DenyHost with PF filtering # only and no hosts.deny support, please still create an empty # file called /etc/hosts.deny for backward compatibility. # Also, please make sure PF is enabled prior to launching # DenyHosts. To do this run "pfctl -e". # # To write all blocked hosts to a PF table file enable this next option. # This will make hosts added to the PF table persistent across reboots. # PF_TABLE_FILE = /etc/blacklist # ### Regards, Ben > -- -- From: Benjamin Woods woods...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd
On Fri, 14 Feb 2020 at 15:27, Joey Kelly wrote: > > On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote: > > 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? It's independent of denyhosts, fail2ban, blacklistd and similar. TCP wrappers is configured using /etc/hosts.allow and /etc/hosts.deny. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Early heads-up: plan to remove local patches for TCP Wrappers support in sshd
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. Although the specific deprecation steps aren't yet fleshed out I'm sending this as an early notice that I plan to disable libwrap support from the base system sshd and that FreeBSD 13 will not support it. We'll probably keep the patch in the tree for some time, to support MFCs to stable branches; the patch will be removed entirely later on. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r357907 seems to have broken sys/kern/vfs_default.c
I already fixed that in r357909, sorry. On 2/14/20, David Wolfskill wrote: > ... > Building > /common/S4/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zfs/vdev_file.o > --- vfs_default.o --- > /usr/src/sys/kern/vfs_default.c:576:10: error: implicit declaration of > function 'lockmgr_lock_fast_path' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > return (lockmgr_lock_fast_path(>v_lock, flags, > ^ > Building /common/S4/obj/usr/src/amd64.amd64/sys/GENERIC/vfs_hash.o > /usr/src/sys/kern/vfs_default.c:576:10: note: did you mean > 'lockmgr_lock_flags'? > /usr/src/sys/sys/lockmgr.h:73:6: note: 'lockmgr_lock_flags' declared here > int lockmgr_lock_flags(struct lock *lk, u_int flags, > ^ > 1 error generated. > *** [vfs_default.o] Error code 1 > > make[2]: stopped in /common/S4/obj/usr/src/amd64.amd64/sys/GENERIC > .ERROR_TARGET='vfs_default.o' > .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC/vfs_default.o.meta' > > > > Running: > FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #820 > r357854M/357854: Thu Feb 13 04:52:51 PST 2020 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > > and updating with sources at r357908. > > Peace, > david > -- > David H. Wolfskillda...@catwhisker.org > What if McConnell had voted to convict Trump in the impeachment "trial?" > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r357907 seems to have broken sys/kern/vfs_default.c
... Building /common/S4/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zfs/vdev_file.o --- vfs_default.o --- /usr/src/sys/kern/vfs_default.c:576:10: error: implicit declaration of function 'lockmgr_lock_fast_path' is invalid in C99 [-Werror,-Wimplicit-function-declaration] return (lockmgr_lock_fast_path(>v_lock, flags, ^ Building /common/S4/obj/usr/src/amd64.amd64/sys/GENERIC/vfs_hash.o /usr/src/sys/kern/vfs_default.c:576:10: note: did you mean 'lockmgr_lock_flags'? /usr/src/sys/sys/lockmgr.h:73:6: note: 'lockmgr_lock_flags' declared here int lockmgr_lock_flags(struct lock *lk, u_int flags, ^ 1 error generated. *** [vfs_default.o] Error code 1 make[2]: stopped in /common/S4/obj/usr/src/amd64.amd64/sys/GENERIC .ERROR_TARGET='vfs_default.o' .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC/vfs_default.o.meta' Running: FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #820 r357854M/357854: Thu Feb 13 04:52:51 PST 2020 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 and updating with sources at r357908. Peace, david -- David H. Wolfskill da...@catwhisker.org What if McConnell had voted to convict Trump in the impeachment "trial?" See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: r351900 broke UEFI boot on VMware VMs
> On 14. Feb 2020, at 13:43, Yuri Pankov wrote: > > Hi Toomas, > > I was finally able to find the revision that has broken UEFI boot on VMware > VMs, that is ESXi 6.7 and Workstation 15.x, for me at least -- VM simply > powers off (sometimes with uninformative message about runtime exception) > after loader messages and before displaying any kernel messages. > > commit 9b4871ee590632c8f983fbc82fea6a95a01e8c76 (HEAD) > Author: tsoome > Date: Thu Sep 5 22:15:50 2019 + > >loader: use teken teminal emulator for x86 and uefi > >Replace mini cons25 emulator with teken, this does enable us proper console >terminal for loader and will make it possible to implement different >back end callbacks to draw to screen. > >At this time we still only "draw" in text mode. > > Notes: >svn path=/head/; revision=351900 > > Done by bisecting, building full ISO for every step, so it's likely correct. > Any ideas? I am currently working with that code, so hopefully will be able to find the root cause soon enough. I am able to replicate the issue on fusion, for time being, I have found that if you esc out from menu and enter ls command, the crash wont happen:) sorry, toomas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
