Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd
On 2/21/20 11:49 AM, Ed Maste wrote: > It seems starting sshd from inetd via tcpd is a reasonable approach > for folks who want to use it; also, have folks using libwrap looked at > sshd's Match blocks to see if they provide the desired functionality? While match blocks can disallow a login from anything other than an approved source address, they apparently permit the configured number of failed attempts before throwing the prospective intruder out. With the wrappers, it's an immediate disconnect. They also have no mechanism to recognize a DNS mismatch (forward versus reverse map). imb ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
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-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: machine hangs on occasion - correlated with ssh break-in attempts
I do something related to this with fwlogwatch although it can probably
be adapted to any similar tool; when I hit the 'block' threshold, I
execute something like:
#!/bin/sh
HR=`date +%-k`
/sbin/ipfw table 0 add $3 ${HR}
.. so each entry has a tag indicating the hour at which the block was
initiated.
At 5 to the hour, I run a simple cron job which does this to clean out
everything older than 24 hours ..
#!/bin/sh
HR=`date -v+1H +%-k`
/sbin/ipfw table 0 list /tmp/xx.$$
cat /tmp/xx.$$ |
while read LINE
do
set $LINE
case $2 in
${HR})
/sbin/ipfw table 0 delete $1
echo -n `date +%H:%M:%S` /var/log/fwlw_clean_log
echo fwlw_clean: removed $1 from table 0
/var/log/fwlw_clean_log
esac
done
rm /tmp/xx.$$
I also have a script in /usr/local/etc/rc.d which saves the current
state in the event of an orderly shutdown and restores it on boot:
#!/bin/sh
case $1 in
start)
cat /var/db/ipfw/cache0 | while read LINE
do
set $LINE
/sbin/ipfw table 0 add $1 $2
done
;;
stop)
/sbin/ipfw table 0 list /var/db/ipfw/cache0
;;
restart)
$0 $DEBUG stop
$0 $DEBUG start
exit $?
;;
*)
echo Usage: $0 {start|stop|restart}
exit 1
;;
esac
exit 0
Of course, this only works for ipv4 because of the restriction on the
ipfw table data but it's just an example,
Michael
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
