The best thing to do for security is to make su only executable by root.
Then get the "sudo" package and install it, giving only a few users the
ability to run "sudo su" and thus change to root.
This makes the telnet server more acceptable, and limits your exposure.
Also, with inetd/xinetd, telnetd can be limited to serving people only
on specific networks by changing hosts.deny, hosts.allow ("man
hosts.allow") in the /etc directory.
the basic rule for hosts.deny that all systems should follow is
ALL: ALL
this denys everyone access to all services. In hosts.allow, assuming
your local network is 192.168.1.x, you could put
ALL: 192.168.1.
This overrides hosts.deny and allows all servers that use inetd to
service anyone coming in over the 192.168.1.x network.
bug
On Fri, 5 Jan 2001, Bill Kenworthy wrote:
> Never been able to figure out the logic for that! Invariably the first
> thing one does when telnetting into a box to do some work as root is to
> su - whats the difference? The password still goes in clear etc - just
> seems anoying. Can see the sense in not installing telnetd in some
> cases, but telnet is a standard unix service - one only has to look at
> the number of queries to the list over the problems this causes, and the
> fact that the first thing that person does is install the package, one
> has to question whether this approach is worthwhile - in my opinion
> would be better to install, but leave disabled, or perhaps make it an
> install question that comes up with the package list "Do you want telnet
> services - Warning ...".
>
> BillK
>
>
> > The feature you are referring to as twisty is not twisty at all. It is very
> > important that you not be able to telnet in as root. The only way to make
> > things absolutely tight on unix machines is to disallow telnet sessions for
> > accounts that are system standard on *nix systems.
> >
>
