Re: allowing root logins via the network, was Fix for Linux/AIX login hole

[proff () suburbia apana org au (Julian Assange)]

> It depends on where you want to draw the line between security and flexibility
> (ie. do you want to be able to login as root from home and fix things up or
> are you willing to have to come in an be physically at the console for those
> - very rare - times when something has gone very wrong).  Sure, I can think
> of a number of scenarios when it is nice to be able to login as root via a
> telnet session - but they are all times when there is a problem.  We made the
> decision a long time ago that we would bite the bullet in such situations and
> give up the ease of logging in as root via a telnet session for the security
> of only allowing root logins on the console - in our case the extra security
> warrants it we feel.  On certain machines (ie. a kerberos or other
> authentication key server) I'd even recommend disabling the regular vendor
> telnetd, rlogind, rshd, rexecd, rexd, etc.  daemons in /etc/inetd.conf so that
> your trusted security server machine doesn't become the first victim!
>
> If being able to get to the console and login as root at remote locations 
> (ie., you have isolated Unix boxes running a turnkey vertical application
> out at branch offices or franchises where there are no sys admin staff)
> is a real necessity I wouldn't recommend doing it via a public TCP/IP network -
> I'd put the console (or auxiliary remote console) on a modem with several
> levels of challenge on it - perhaps even a callback unit).
>
> As for the issue of allow root rlogin-without-a-password access via the /.rhosts
> file so that your root passwords are not captured - there are two ways to
> fix this problem.  The first - as you say - is to use Kerberos or a similar
> authentication system.  The second is to build a more secure physical local
> area network and enterprise (as much of it as you administer) network.  This
> can be done by getting rid of the shared LANs (primarily coax ethernet but
> also a few other technologies/topologies) as much as possible and replaced
> them with hubs providing private, bridged, switched connections (one machine
> per port).  Expensive but getting cheaper every day.  These two steps
> (and I would also recommend a firewall for most organizations connected to
> the Internet) can make a network much more secure.

Or you could just use encrypted telnet or my challenge responce system "Chalace".

- Proff