[Server-devel] XS testing (Tony Anderson)

[Greg Smith]

Hi Tony,

I don't fully understand all the vagaries of access to root, but I do 
want to warn you about having any open ports or users with password 
authentication only.

Be really careful about dictionary style attacks. I have seen an XS 
broken in to via dictionary attack, even when the password was extremely 
secure (e.g. caps and on-caps, special characters and long password).

If there's anything not protected by SSH, use denyhosts to prevent rapid 
fire guessing of your password. http://denyhosts.sourceforge.net/

You may want that tool on your server anyway.

ClamAV is also handy, especially if you have Web, PHP, SQL ports visible 
on the Internet. Even slightly out of date versions of those tools can 
be subject to buffer overflow attacks and other ways to add unwanted 
code to you box. ClamAV may help scrub them off before they do damage.

Just FYI. Sounds like OTP and/or your strategy already cover the main 
points.

Thanks,

Greg S

> Date: Thu, 09 Oct 2008 22:14:06 +0545
> From: Tony Anderson <tony_anderson at usa.net>
> Subject: Re: [Server-devel] XS testing
> To: timmoody at sympatico.ca
> Cc: server-devel at lists.laptop.org
> Message-ID: <48EE3152.6040001 at usa.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> At the moment, I am enabling password authentication for SSH. However, 
> root login via SSH will not be possible. So this test would require the 
> installer to log in as admin, for example. He would then su to root with 
> the root password set by the install script, as needed.
> 
> 
> As far as I know, we don't have a clear plan on how to implement key 
> pairs. For example, the installer is likely to use the nearest available 
> XO to administer the system. I suppose we could use the usb drive to set 
> up .ssh on that XO. However, we wouldn't want the student with that XO 
> to be the server administrator later on. If we shut down password 
> authentication after the install, there is still the question of how a 
> technician would access the server at the school in case of a subsequent 
> problem.
> 
> Tony
> 
>