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: