Restrict root login through telnet - SCO

This is a discussion on Restrict root login through telnet - SCO ; To imitate (more or less) in telnetd the "PermitRootLogin no" setting off sshd, it is possible to set CONSOLE=/dev/tty01 in /etc/default/login. This approach, however, effectively locks "root" out of all the other multi-screens at the console, and I guess also ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Restrict root login through telnet

  1. Restrict root login through telnet

    To imitate (more or less) in telnetd the "PermitRootLogin no" setting
    off sshd, it is possible to set CONSOLE=/dev/tty01 in /etc/default/login.

    This approach, however, effectively locks "root" out of all the other
    multi-screens at the console, and I guess also out of the serial
    ports. Given that I have, in my tests on OSR 5.0.7 with MP5, already
    managed to trash the display/console on tty01 twice, I don't feel easy
    about the risk of trashing tty01 again and totally loosing access if the
    network is down (so I couldn't telnet/ssh in and then "su" to root). So I
    don't set CONSOLE in /etc/default/login.

    I did the following trickery, which works. I'm interested on comments
    about how proper/improper it may be; and also about security gotchas,
    if any (I need to keep telnet for legacy reasons):

    1. I found out the system configured number of ttyp's, 130 in my case:

    # grep NSPTTYS /etc/conf/cf.d/config.h
    #define NSPTTYS 130

    2. In /etc/inetd.conf, I changed the telnet daemon to bind only to a
    subset of ttyp's, namely from 110 to 129:

    telnet stream tcp nowait NOLUID /etc/telnetd telnetd -r 110-129

    3. I modified the system-wide file /etc/profile, adding this at its
    very beginning:

    ## Lets check whether we are root in case we are comming from any ttyp.
    YOSOYESTE=`id | awk -F "[()]" '{print $2}'`
    TTYESESTA=`tty | awk -F "/" '{print $3}'`
    checkmeplease() {
    if [ ` w | grep $TTYESESTA | awk '{print $1}'` != $YOSOYESTE ] ; then
    DOINGSU=YES
    else
    DOINGSU=NO
    fi
    export DOINGSU # This export is just to make ~/.logout work well.
    }
    checkmeplease
    if [ "$YOSOYESTE" = "root" ] ; then
    case $TTYESESTA in
    ttyp1[12]?)
    if [ $DOINGSU != YES ] ; then
    echo "Login incorrect\n"
    exit 0
    fi
    ;;
    *)
    ;;
    esac
    fi
    ## End of the block added to system-wide /etc/profile.

    4. I forced the inetd daemon to re-read its configuration:

    # kill -HUP


    And that's it. This makes it impossible to login directly as root
    through telnet, but DOES allow to "su -" to root when logged in as a
    normal user through telnet or ssh. And it also allows to login
    directly as root at any multi-screen at the console, and through the
    serial ports.

    Is there any blatant security hole in all that?

    PS: I borrowed some code published by A.P. Lawrence in his web site.

    Regards.

  2. Re: Restrict root login through telnet

    I modified the checkmeplease() function, so that it works better when
    going single-user:

    checkmeplease() {
    TTYOWNER=`w | grep $TTYESESTA | awk '{print $1}'`
    if [ ! -z "$TTYOWNER" -a "$TTYOWNER" != "$YOSOYESTE" ] ; then
    DOINGSU=YES
    else
    DOINGSU=NO
    fi
    export DOINGSU # This export is just to make ~/.logout work well.
    }

  3. Re: Restrict root login through telnet

    In article , Pepe wrote:
    >To imitate (more or less) in telnetd the "PermitRootLogin no" setting
    >off sshd, it is possible to set CONSOLE=/dev/tty01 in /etc/default/login.
    >
    >This approach, however, effectively locks "root" out of all the other
    >multi-screens at the console, and I guess also out of the serial
    >ports. Given that I have, in my tests on OSR 5.0.7 with MP5, already
    >managed to trash the display/console on tty01 twice, I don't feel easy
    >about the risk of trashing tty01 again and totally loosing access if the
    >network is down (so I couldn't telnet/ssh in and then "su" to root). So I
    >don't set CONSOLE in /etc/default/login.
    >
    >I did the following trickery, which works. I'm interested on comments
    >about how proper/improper it may be; and also about security gotchas,
    >if any (I need to keep telnet for legacy reasons):


    I didn't look at that too closely, but note that it's possible to abort the
    processing of /etc/profile (and .profile) by hitting the interrupt key at the
    right moment, which makes anything that depends on /etc/profile being fully
    sourced fairly weak from a security perspective.

    This can be avoided by making the user's shell itself be a shell script (or
    other program), which checks conditions before exec'ing an interactive shell.

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  4. Re: Restrict root login through telnet

    On Jul 21, 2:09 pm, spce...@armory.com (John DuBois) wrote:
    > In article , Pepe wrote:
    > >To imitate (more or less) in telnetd the "PermitRootLogin no" setting
    > >off sshd, it is possible to set CONSOLE=/dev/tty01 in /etc/default/login.

    >
    > >This approach, however, effectively locks "root" out of all the other
    > >multi-screens at the console, and I guess also out of the serial
    > >ports. Given that I have, in my tests on OSR 5.0.7 with MP5, already
    > >managed to trash the display/console on tty01 twice, I don't feel easy
    > >about the risk of trashing tty01 again and totally loosing access if the
    > >network is down (so I couldn't telnet/ssh in and then "su" to root). So I
    > >don't set CONSOLE in /etc/default/login.

    >
    > >I did the following trickery, which works. I'm interested on comments
    > >about how proper/improper it may be; and also about security gotchas,
    > >if any (I need to keep telnet for legacy reasons):

    >
    > I didn't look at that too closely, but note that it's possible to abort the
    > processing of /etc/profile (and .profile) by hitting the interrupt key at the
    > right moment, which makes anything that depends on /etc/profile being fully
    > sourced fairly weak from a security perspective.
    >
    > This can be avoided by making the user's shell itself be a shell script (or
    > other program), which checks conditions before exec'ing an interactive shell.
    >
    > John
    > --
    > John DuBois spce...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/


    Ditto about not looking at it too closely.

    I've been at this business for a while and would be concerned about
    the maintainability of the solution. Down the road if somebody or
    some process optimizes the system by reducing the number of PTTYs,
    they may unaccountably discover that telnet stops working. If another
    optimization created startup scripts for daemons instead of using
    inetd, it may take a while to trace the symptom back.

    Replacing telnet with SSH is probably a better use of your time.
    Creating a staging area and trying out changes there first should cut
    back on those "Oh, oh!" moments.

    --RLR


  5. Re: Restrict root login through telnet

    ThreeStar wrote:
    > On Jul 21, 2:09 pm, spce...@armory.com (John DuBois) wrote:
    >> I didn't look at that too closely, but note that it's possible to abort the
    >> processing of /etc/profile (and .profile) by hitting the interrupt key at the
    >> right moment, which makes anything that depends on /etc/profile being fully
    >> sourced fairly weak from a security perspective.
    >>
    >> This can be avoided by making the user's shell itself be a shell script (or
    >> other program), which checks conditions before exec'ing an interactive shell.


    Thank you John, very interesting insight there!

    > I've been at this business for a while and would be concerned about
    > the maintainability of the solution. Down the road if somebody or
    > some process optimizes the system by reducing the number of PTTYs,
    > they may unaccountably discover that telnet stops working.


    Yes, very true. Right now I'm just in the process of exploring the
    possibilities. However it's true that an excess in customizations drives
    to fragility and makes a system tricky.

    > Replacing telnet with SSH is probably a better use of your time.
    > Creating a staging area and trying out changes there first should cut
    > back on those "Oh, oh!" moments.


    Yes, but sometimes you need to remotely connect from a router or
    something that only has the telnet client available. So telnet has to
    stay, at least inside the firewalled LAN.

+ Reply to Thread