[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Remote Access: Service vs. Security


On Tue, 11 Jan 2005, Ralf Gesel|ensetter wrote:

> as most of you will agree, it makes sense to have particular services of 
> your skolelinux system available remotely:
> - ssh for administration
> - ssh for sftp
> - ssh for NX

For those who need them, anyway.

> Even though, we don't use a fix IP, today we had a visitor via ssh who 
> cracked a users password by bruteforce (this pupil happened to be in 
> some weird IRC channel).

Are you sure he brute-forced it?  Might the student have been using the
same password for something elsewhere (eg his IRC nick) in clear text?

There is a very useful tool called "John The Ripper" which will read a set
of password and shadow files and attempt to crack them.  If anyone has weak
passwords (eg a word or short string) they will be cracked quickly.
However, given that all authentication in Skolelinux is done over LDAP I'm
not entirely sure how one does this.  Can an LDAP expert comment?

> As long we can't make sure all pupils' / teachers' passwords are safe, 
> we rather should not allow ssh to them (as they don't use it for now, 
> anyway). But in order to give teachers the opportunity to work from 
> home, we will need some way to assure secure access. What solutions did 
> you choose? Something like portscanblocking and hidden (unusual) port 
> could be an option.

1. TCP Wrappers.

One assumes your users generally come in from a limited set of IP ranges
(probably those of the German ISPs).  You can set a line in hosts.deny

	sshd: ALL

and then in /hosts.allow add back needed IP ranges.

	sshd: xxx.yyy.zzz.0

This is not unbreakable but it's an extra hurdle for an attacker.  OpenSSH
will not accept connections from anyone else.

2. SSH's AllowGroups/AllowUsers config

In /etc/ssh/sshd_config you can add either or both of:

	AllowGroups admins
	AllowUsers gavinm johne

The first will restrict ssh logins to those who are members of the unix
group "admins".  The second to the users gavinm and johne.  I think this
should work with LDAP.

3. Require key based authentication

As I understand it (I could be wrong), you can disable password based login
entirely with this line in /etc/ssh/sshd_config:

	PasswordAuthentication no

Now users must use key based authentication.  This is a little complicated
for the average user so may not be feasible.  It is a lot more secure
though.  Insist that the users have passphrases on their keys.

4. Refuse ssh root access

It is generally a good idea to set: 

	PermitRootLogin no

in /etc/ssh/sshd_config .  That way an outsider cannot attempt to
brute-force the root password.

> I have to add, that port 22 is forwarded by our firewall to ltsp "only", 
> hence, tjener itself is relatively secure. Our "guest" critisized 
> that /boot was readable to him (he was goodwilled).

I'm not sure I agree.  Many attacks will start with someone compromising a
single user account on a single machine somewhere.  The attacker then uses
access to the network to do all manner of other bold things and escalate
his/her privileges.  Local attacks from a minor account are much easier
than remote attacks.

One thing that you should not do is su root or log into webmin from a thin
client.  The password goes across the network in clear text which means
your above attacker could perhaps sniff it from the LTSP machine.


Reply to: