Cracked

[John]

Chris wrote:
> On Mon, 2004-10-18 at 15:20 +0800, John wrote:
> 
>>My mail service (which is not the one in my address) was cracked last week.
>>
>>I allow logins via ssh (I need access to do remote maintenance).
>>
>>One person, possibly as many as three, gained root access to the box 
>>with the ever-reliable dictionary attack.
> 
> 
> How did you figure out that is was a dictionary attack?  Lots of login
> attempts in the log?  This seems like it would be a slow attack to do
> over the network, no?

Obviously not too slow.

There was a stream of failed logins. You don't actually need a big 
dictionary to have lots of success - just a few hundreds at most. 
Include words such as god, dog, cat, pet, john, jason, footy, football.

Many are ruled out of Linux by the minimum password length (is that 
enforced? or merely advisory?), but the default is still dreadfully short.


If you're attached to the Internet, check your logs. You may see a 
stream of attempts to connect to ssh as user root, admin, test, guest 
and some others. If you log and block in iptables, you will see a stream 
of denied connexions to port 22.


>>One of the other possible countermeasures is to detect dictionary 
>>attacks and stop them cold.
> 
> 
> Have you looked at the pam_tally module for PAM?

I'd never heard of it:-) I see it's part of the pam-modules package 
(Sarge), but where's the documentation and what does it do?

There's even an executable, but no corresponding man page.




> For desktop machines I see no reason why Ubuntu couldn't take the
> Windows XP SP2 approach.  That is, iptables are turned on with the
> default set to DENY and allowing outbound by the stateful settings.
> Then the user could open the ssh port if they really want to.

Unless it's changed since I last installed U, sshd isn't enabled by default.

A user who knows of the facility and enables it is likely to undo all 
the default settings that get in the way.

As soon as the user enables the service, the problem exists.

If the default setup is secure, and the steps required to be undergone 
to enable the facility describe how to do it safely then most users, 
even unskilled ones, will do it right.

Sometimes, you need to login by password. I administer several machines 
remotely. Possibly, I could be called on to do something and only have 
access to someone else's computer, my brother's, an Internet cafe's. It 
might be that even if I use keys, I have to throw one away (as I just did).

> 
> If pam_tally or something like that was also installed then it could do
> like you suggest and block the remove host with firewall settings or it
> could just disable the account completely.  I wonder if it would be
> possible to just disable the account for remote access but still allow
> console login.

Disabling an account would destroy remote admin. I think disabling 
accounts undesirable, it makes it too easy to mount a DoS attack. Imagine
Chris runs ISP shop
John hates Chris
John tries to login as chris at isp.shop
Chris's account is disabled.


While _I_ could restrict access to Westnet client networks, that dtill 
leaves open access to hosts on Westnet client networks, and only one of 
those is me. It also means if the boss sends me to Thailand or Canada, I 
can't get in.


My prospective tool would respond to a failed login attemptand block the 
offending host. For Chris, who hates me, to mount a successful 
dictionary attack he'd need to control (or spoof) a separate host for 
each word. Going through a list of pets and common names would be a 
challenge for the ordinary cracker; most would go for easier fruit.


Actually, my proposed da-blocker would be well able to do other thingss 
too: I plan for it to match a user-supplied string against a 
user-supplied logfile to take user-specified actions.

Here, "user" means sysadmin. Since sysadmins can do bad things, I don't 
plan on bothering much with searching for shell escapes and such.

It could as easily protect email services from dictionary attacks, even 
halt the system if someone mentions it's getting too hot in here:-)