Faye Gibbins wrote:
> Hi,
> 
>  I take a slightly different approach. A three strikes and your out rule.
> 
>  I tail my log file looking for failed SSH logins. After three bad 
> attempts that IP address is DROP'd (not rejected) for two weeks by 
> iptables. Dropping slows down the scan, whereas rejecting would 
> immediatly tell the attacker what's up. nowadays a hacker might quickely 
> move one but I like to think it helps.

You're looking after the event. Even a few seconds is enough for a 
script to do its harm.

Limiting in netfilter as I do also allows a small window, but I don't 
rely on failed attempts. If the attack is basically this:
cat ~/.ssh/id_dsa.pub | ssh -t example.com tee -a .ssh/authorized_keys
with some magic to type a password at the critical moment, then the very 
next ssh connexion will succeed without a password (assuming you allow 
passwordless logins with a good key, as you should) and might be one 
that allows free entry on another port for the report cracker to talk to 
a shell. Or it might just install a bunch of tools to send spam, or 
attack other systems etc etc.

To breach my system, the cracker needs a distributed attack or to be 
lucky. Since google doesn't know the sequence of symbols that is my 
password, it's probably not in any dictionary.

Blocking on failed passwords, and not resetting for a long time might 
lose your access from that location for a time. If you recognise that 
and are comfortable with it, fine.

DROP vs REJECT
I DROP too, but I don't really think it makes a difference to the 
cracker. I reckon I could program around it (think multithreading and 
multiple processes), and if I get (maybe a couple of consecutive) 
timeouts I decide that IP address is too hard.

In perl, it's trivial to start some number of processes, and having done 
so, do something like this:
while (1)
   {
     wait(); # waits for a single process
     StartAnother();
}


What might be useful, but I don't have enough public IP addresses that 
I've bothered with it, is to have network-wide monitoring where an 
intrusion attempt at one site results in the cracker's being blocked at 
all firewalls.

> 
>  Similar to greet_pause in sendmail.
> 
>  Thus this not only reduces the amount of attacks against my machine but 
> legitimate users with good typing or keys can always get in.

If you can predict that your users will only connect from small sections 
of the public Internet, then you can have special rules for those 
sections, and more stringent rules for the rest.

If you have some that wander the world, laptops in hand, then a VPN 
might be useful.

You should not assume that a possessor of your laptop is a user, but you 
could require the user to authenticate via the VPN before trusting the 
laptop. Of course, you do not want the user to use a stored password (so 
http/https is out) or for ~/.bash_history to contain useful clues.


> 
>  The block list is held ni a view in postgres so it's always easy to 
> edit if needed.
> 
>  John's idea is good but too often I find myself needing more than 5 
> connectinos per hour, especially to gateway machines.

It seems I neglected to mention some earlier rules. Zones I inhabit or 
may inhabit have earlier ACCEPT rules. And then there's my VPN.

I'm more vulnerable from Australian IP addresses, but in practice that's 
not a problem, and law enforcement is relatively simple (one 
jurisdiction) and sanctions include a term in one of HM's fine 
establishments.

> 
>  For a few machines only I connect to I have thought of use a RNG to 
> decide upon a port number for sshd using redirection in iptables and 
> having a simular programmed shell function wrapping the ssh CMD. Perhaps 
> changing it every day. Then adding a port knocker to stop port scans 
> finding it out.
tcpwrappers probably does what you really want, but iptables can provide 
  similar protection. It's a matter of taste as to which one uses; ssh 
(and most TCP/IP programs) use tcpwrappers and can be configured in 
/etc/hosts.{allow,deny}




>  Either that or have another phone line put in and using a modem, so 
> that I have to dial in and use SSH over Eth over PPP (PPP over modem is 
> sooo easy, joy) or something. Then opening up the ssh port for my IP.

Don't make it too fanciful. If my fairly simple procedures are 
inadequate, probably your assets are valuable enough you should hire a 
specialist:-)



-- 

Cheers
John

-- spambait
[log in to unmask]  [log in to unmask]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)