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

Re: Remote Access: Service vs. Security

 --- Gavin McCullagh <lists_gmc@fiachra.ucd.ie> wrote: 

> 2. SSH's AllowGroups/AllowUsers config
> In /etc/ssh/sshd_config you can add either or both of:
> 	AllowGroups admins
> 	AllowUsers gavinm johne

I have had a Debian server connected to the Internet for over a year now. It
has still not been compromised I think (touch wood!), but that wasn't for lack
of trying. Almost daily hack attempts on ssh (and http, but that's a different
story), trying a range of machine-generated accounts like root, lpd, apache,
mysql, postgres, and a raft of others. I still have the logs. All of these
allowed unlimited number of login requests, and only rejected the attempts
because the name/password combination wasn't obvious.

As soon as I added 'AllowUsers', would-be users were thrown out even before
they could try different passwords, because they were not on the list of
allowed users. Very much a security-through-obscurity, as the list of allowed
users is not visible from outside and cannot be easily guessed.

The final level of security would be to add a user 'root@10.*' (yes, wildcards
are allowed, my own line reads 'root@192.168.1.*') to AllowUsers: No root
access unless you are already on the internal net and logged in to a skolelinux
server or workstation. No machine-generated accounts available from the outside
at all. And no access from any ltsp clients used by pupils.

> It is generally a good idea to set: 
> 	PermitRootLogin no

That would also do it. And you could set additional hurdles on 'tjener', the
main server, so that only a select group of users are allowed to do 'su root'.

My $0.02.

Lars Erlandsen.

Lars G. Erlandsen

Schapiro's Explanation: The grass is always much greener on
the other side -- but that's because they use more manure

Reply to: