On Thu, Mar 20, 2014, Keith Keller wrote:
>On 2014-03-21, Fernando Cassia <fcassia@xxxxxxxxx> wrote:
>>
>> Interesting double negative. Implies that once the "technical barriers" are
>> removed, then it's OK to remove old features for change's sake. ;)
>
>If, as Matthew says, the codebase hasn't been maintained since 2001,
>then we should have concerns about unfound security issues, as well as
>concerns that, if others find security problems, nobody is responsible
>for fixing them. If tcpwrappers had a current maintainer this wouldn't
>be an issue.
>
>There's certainly at least one technical reason to prefer other options
>like iptables over tcpwrappers. I've had instances where an attacker
>made dozens of ssh probes per second; tcpwrappers was able to reject
>these, but sshd was so overwhelmed that it was unable to exchange host
>keys with legitimate clients. iptables would have blocked these attacks
>more effectively, letting sshd handle the legitimate client sessions
>properly.
My solution to this is to have swatch watching the tcp_wrappers ssh, imap,
and pop3 logs and blocking with iptables any IP address that has more than
N (5 by default) failed connection attempts in a minute or that is listed
in our blacklist DNSRBL. A postgresql database is used on each machine
with a history of IPs blocked which is used to automatically expire blocks
and to add them if a system is rebooted.
We maintain a couple of DNSRBLs for whitelisting and blacklisting IP
addresses and net blocks that are largely fed by the reports generated.
The /etc/hosts.allow files on all the systems we monitor use these DNSRBLs
on critical services (e.g. sshd) to ALLOW/DENY access.
The net result of this has been that it's rare when a particular IP gets
more than a few failed attempts before being blocked the first time, and
one or two if it's in our blacklist DNSRBL whether it's on the first
machine attacked or any of the other machines we monitor.
FWIW, the the majority of the attacks seem to be password guessing attempts
using IMAP, not ssh. The successful cracks on Linux machines I've seen
were done via weak user accounts on ISPs that were then accessed via php to
the user's writeable public html directory.
As somebody already pointed out, no one tool is sufficient to limit access.
Bill
--
INTERNET: bill@xxxxxxxxxxxxx Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186 Skype: jwccsllc (206) 855-5792
It takes no great insight or intelligence to see that the health
of a centralized economy built around dense concentrations of
economic power and a close business alliance with government can't
tolerate any considerable degree of intellectual schooling.
John Taylor Gatto http://www.lewrockwell.com/gatto/gatto-uhae-8.html
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
