On Dec 23, 2009, at 1:16 AM, Richard Carter wrote:
Ah well, I suppose if you have a specific need to monitor the log file and keep it pristine then manual filtering would be best. To each their own. :)
By the way, I previously said "after a few failed attempts at logging in as root, a machine is added to the iptables block list"; this is wrong. It blocks attempts at other users too; you can configure it to block after different numbers of tries for root, non-root but restricted, normal, and nonexistent users. And it monitors /var/log/secure and then adds entries to /etc/hosts.deny, not iptables. Just thought I'd clarify for anyone else who wants to look into it; it seems effective on my dedicated server, as it's blocked 57 hosts since I first installed it a few weeks ago and it hasn't locked me out yet. You can clearly see in /var/log/secure that the hosts try to connect X number of times and then are refused.
Anyway, Daniel, one more thing to try is to look up your IP address at
arin.net
(use the search box in the top-right if you're not familiar with it). The whois entry should have a NetRange which may or may not match the mask that your router has.
One more trick that you could look into is port knocking. Essentially, you close all ports. Then, when you want access, you "knock" on (i.e. send a packet to) a specific series of ports; the computer would hear the knocks but would not respond. But as soon as the series of ports matches a specific series, then a rule is added to the firewall to allow the knocker access. I'm not sure of the options as far as daemons that implement port knocking, but I'm sure a Google search for port knocking will reveal plenty of information on the subject. It might be your ideal solution, as it doesn't require knowing IP addresses ahead of time, and you can block everyone.
> I presume you are filtering IP addresses to reduce the possibility of
> someone SSHing or brute forcing into your computer, correct?
Yes, correct.
> If this is the case, take a look at DenyHosts
> If there is some other reason you're doing this, please share with me
> because I'd really like to know if I'm doing something wrong!
I think either solution would be fine, however, there is another reason.
My auth log file had thousands of failed ssh attempts (before
implementing bruteforce protection). Using preset IP filtering will get
rid of virtually all these failed ssh attempts in the log file, whereas
the DenyHosts/Fail2ban methods will only reduce the number of failed ssh
attempts in the log file. This makes log monitoring much easier,
because the log file is far less cluttered.
--