Good question Alex. However, I've never studied the scripts that 'script kiddies' use and so have no answer.
Part of what has prompted this change is the recent surge of brute-force password attacks. From the timing of the password attempts, it's clear that these are script driven.
I found a perl script that watches for failed logins. After a configurable number, the script enters the IP address into /etc/hosts.deny. After a configurable number of days, the script then removes the IP address.
What I see in /var/log/secure is a whole series of 'Invalid user' messages followed by 'Failed password for invalid user' messages. These will then, because of the script, be terminated by a 'refused connect from' message when the address is entered into hosts.deny.
My point in all this is that I only ever see *one* 'refused connect' message. So at least for this script, it gives up when it can't connect anymore.
Kirk Bocek
Alex White wrote:
Kirk Bocek wrote:
Scot L. Harris wrote:
Actually this won't reduce any bandwidth to your server. The probes still hit that address, you are just blocking those packets in iptables from begin able to get any further.
Are you saying that the single connect-and-drop that this scheme introduces is going to use the same bandwidth as a brute-force password attack on hundreds of login names?
<snipped>
Question, because I am not sure. Wouldn't the script that is being run have to be intelligent enough to move to the next machine without exhausting its attempts at guessing passwords in order for your firewalling scheme to effectively reduce bandwidth?
What I mean is, the script attempts to connect and try a password. It doesn't get a response so it assumes that the machine simply returned a login denied and tries again. It may try this several times per username (depending on the script). If that's the case, as it's not actually bothering to keep track of success of connection you're getting the same amount of connects as previously. Is that not true?
Now granted the above scenario is assuming a truly brain dead script, but they aren't all that more sophisticated than that (some of them).
Curious,
Alex _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos