Jeff, I like how you think.
However, some of us have more stringent policies than others. Either by law or by policy. Could we use the DNS return address as a code for what the host's history has been? For example, if the host has been blacklisted by 17 hosts, return an address is 127.0.0.17. If the host has been flagged for the last 3 months by 200 hosts, return 127.0.3.200. If the attacks were against root users, add a 1 to the second octet. If the attacks were against known users, add a 2. If the attacks were against unknown users, add a 4. I'm just throwing out a concept here, not a well thought out plan for a return variable. If we could get that to work, we could all have our own rule sets as to what to allow or deny. Anyone else have other ideas? -Michael >>> Jeff Dairiki <[email protected]> 4/8/2009 11:27 AM >>> Hi Phil, everyone, I thought I'd mention an idea which occurred to me last night while lying in bed, pondering what can be done about the current round of distributed SSH attacks... Have you ever thought about making the shared "Denied Hosts database" available via a DNS-based system? (http://en.wikipedia.org/wiki/DNSBL) This would enable direct querying of the database for a specific host in an efficient manner. For example, the combination of the 'aclexec' option in /etc/hosts.allow (see hosts_options(5)) with a simple script could be used to black-list all hosts in the database. This would make the "download" part of the DenyHosts synchronization code unnecessary, and make the DenyHosts generated hosts.deny smaller (enabling longer settings for PURGE_DENY.) This would also allow use of the "Denied Host database" without having DenyHosts installed. (This could be considered a good thing or a bad thing, I suppose. As a user, I consider it a good thing...) Anyhow, it's an idea. Keep up the good fight! Jeff Dairiki ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Denyhosts-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/denyhosts-user E-MAIL CONFIDENTIALITY NOTICE: This communication and any associated file(s) may contain privileged, confidential or proprietary information or be protected from disclosure under law ("Confidential Information"). Any use or disclosure of this Confidential Information, or taking any action in reliance thereon, by any individual/entity other than the intended recipient(s) is strictly prohibited. This Confidential Information is intended solely for the use of the individual(s) addressed. If you are not an intended recipient, you have received this Confidential Information in error and have an obligation to promptly inform the sender and permanently destroy, in its entirety, this Confidential Information (and all copies thereof). E-mail is handled in the strictest of confidence by Allied National, however, unless sent encrypted, it is not a secure communication method and may have been intercepted, edited or altered during transmission and therefore is not guaranteed. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Denyhosts-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/denyhosts-user
