Securing telnet - Security

This is a discussion on Securing telnet - Security ; I'm competing in a hacking competition for a network security class in which we must secure a linux machine as well as attempt to hack others. We must offer telnet as a service, and there is a TA who will ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 31

Thread: Securing telnet

  1. Securing telnet

    I'm competing in a hacking competition for a network security class in
    which we must secure a linux machine as well as attempt to hack others.
    We must offer telnet as a service, and there is a TA who will
    occasionally connect and log in to see that it's working.

    Since this password is in the clear, most IT folks would simply say
    "tough cookies" and not offer telnet, but obviously we don't have this
    option. Thus, I assume that people will be able to see the TA's logins
    without much effort, and I would like to use a long, rotating list of
    passwords so that each password is only valid once. We would share this
    list with the TA beforehand. Is this possible with any existing tools in
    Linux? He's ruled out secure tunneling methods, so is there a better way
    to make telnet's login secure?

    --
    eth'nT
    http://www.hydrous.net
    aim: courtarro

  2. Re: Securing telnet

    P.S. Any similarity between this question and the previous one is just a
    coincidence

    --
    eth'nT
    http://www.hydrous.net
    aim: courtarro

  3. Re: Securing telnet

    On 2006-11-28, Ethan Trewhitt wrote:
    > Linux? He's ruled out secure tunneling methods, so is there a better way
    > to make telnet's login secure?

    One time passwords?

    --
    Damian Szuberski

  4. Re: Securing telnet

    Damian 'legion' Szuberski wrote:
    > One time passwords?


    That's what I'm going for, but how do I accomplish that?

    --
    eth'nT
    http://www.hydrous.net
    aim: courtarro

  5. Re: Securing telnet


    Ethan Trewhitt wrote:
    > Damian 'legion' Szuberski wrote:
    > > One time passwords?

    >
    > That's what I'm going for, but how do I accomplish that?


    How about forcing the user to change his password on a daily basis?

    See the passwd(1) documentation, specifically with respect to the -x,
    -n, and -w options

    HTH
    --
    Lew


  6. Re: Securing telnet

    Lew Pitcher wrote:
    > How about forcing the user to change his password on a daily basis?
    >
    > See the passwd(1) documentation, specifically with respect to the -x,
    > -n, and -w options


    Unfortunately, the competition consists only of two one-hour sessions
    separated by 3 days. I plan to change the password between the two
    sessions, but I'm primarily worried about users accessing his account
    after only a few minutes of him leaking his password.

    I've found a lot of information about OPIE and OTPW (both one-time
    password systems), but they seem pretty complicated. They're pretty much
    exactly what I wanted, but the process of implementing their use seems
    pretty complicated.

    --
    eth'nT
    http://www.hydrous.net
    aim: courtarro

  7. Re: Securing telnet

    On Wed, 29 Nov 2006 10:43:51 -0500, Ethan Trewhitt wrote:
    > Lew Pitcher wrote:
    >> How about forcing the user to change his password on a daily basis?
    >>
    >> See the passwd(1) documentation, specifically with respect to the -x,
    >> -n, and -w options

    >
    > Unfortunately, the competition consists only of two one-hour sessions
    > separated by 3 days. I plan to change the password between the two
    > sessions, but I'm primarily worried about users accessing his account
    > after only a few minutes of him leaking his password.
    >
    > I've found a lot of information about OPIE and OTPW (both one-time
    > password systems), but they seem pretty complicated. They're pretty much
    > exactly what I wanted, but the process of implementing their use seems
    > pretty complicated.


    Here are some vague memories that may be applicable. I believe
    the system was called S/Key.

    You start with a secret passphrase, hash it (e.g., SHA-1)
    100 times, and store the result, with the number 100, in the
    host to be secured. When the user asks to log in, the host
    presents him with the number 100-1 = 99. The user hashes
    the secret passphrase 99 times, and sends the result as the
    password. The host checks the password by hashing it once
    and comparing it with the 100th hash. If the two match,
    the host allows the login, decrements its counter from 100
    to 99, and replaces the stored 100th hash with the 99th
    hash. After 100 logins, a new secret passphrase must be
    used.

    Was this intelligible?

    --
    To email me, substitute nowhere->spamcop, invalid->net.

  8. Re: Securing telnet

    On 2006-11-29, Ethan Trewhitt wrote:
    > Lew Pitcher wrote:
    >> How about forcing the user to change his password on a daily basis?
    >>
    >> See the passwd(1) documentation, specifically with respect to the -x,
    >> -n, and -w options

    >
    > Unfortunately, the competition consists only of two one-hour sessions
    > separated by 3 days. I plan to change the password between the two
    > sessions, but I'm primarily worried about users accessing his account
    > after only a few minutes of him leaking his password.
    >
    > I've found a lot of information about OPIE and OTPW (both one-time
    > password systems), but they seem pretty complicated. They're pretty much
    > exactly what I wanted, but the process of implementing their use seems
    > pretty complicated.


    You could write a PAM module (or rather, rip one off) that implemented
    a simple challenge/response system, say based on the time of day ... ? So
    the password changes every minute or somesuch - a simpler version of
    SecureID without the token.


    --
    "Other people are not your property."
    [email me at huge [at] huge [dot] org [dot] uk]

  9. Re: Securing telnet

    On 2006-11-29, Ethan Trewhitt wrote:
    > I've found a lot of information about OPIE and OTPW (both one-time
    > password systems), but they seem pretty complicated. They're pretty much
    > exactly what I wanted, but the process of implementing their use seems
    > pretty complicated.
    >

    OPIE is pretty simple, actually. This link:
    http://awesom-o.hpmc.net/opie_fluor.html
    Was very helpful to me. You should be able to implement it without too
    much stress.

    The document mentions debian and installing packages with apt, but it's
    really not all that debian-specific.

    --
    Ian Kilgore
    echo "pfxz@pfxz.trw" | tr pzfwxt ikagno

  10. Re: Securing telnet

    Ian Kilgore wrote:
    > OPIE is pretty simple, actually. This link:
    > http://awesom-o.hpmc.net/opie_fluor.html
    > Was very helpful to me. You should be able to implement it without too
    > much stress.


    That looks good, but it doesn't describe how to force telnet to use
    opie. I played around with opie a bit last night, but I couldn't see how
    to instruct telnet to use a specific PAM module since there is no
    "telnet" file in /etc/pam.d like there is for sshd. Any idea? I don't
    know enough about the syntax of these pam.d files to understand what
    they're doing.

    --
    eth'nT
    http://www.hydrous.net
    aim: courtarro

  11. Re: Securing telnet


    Ethan Trewhitt wrote:
    > I'm competing in a hacking competition for a network security class in
    > which we must secure a linux machine as well as attempt to hack others.
    > We must offer telnet as a service, and there is a TA who will
    > occasionally connect and log in to see that it's working.


    OK, how about taking this approach

    Enable telnet in a chroot jail (or a virtual machine), and disable root
    logins through the telnet session. Your TA gets his telnet, and your
    system remains secure.

    HTH
    --
    Lew


  12. Re: Securing telnet

    * Ethan Trewhitt wrote:
    > I'm competing in a hacking competition for a network security class in
    > which we must secure a linux machine as well as attempt to hack others.
    > We must offer telnet as a service, and there is a TA who will
    > occasionally connect and log in to see that it's working.
    >
    > Since this password is in the clear, most IT folks would simply say
    > "tough cookies" and not offer telnet, but obviously we don't have this
    > option. Thus, I assume that people will be able to see the TA's logins
    > without much effort, and I would like to use a long, rotating list of
    > passwords so that each password is only valid once. We would share this
    > list with the TA beforehand. Is this possible with any existing tools in
    > Linux? He's ruled out secure tunneling methods, so is there a better way
    > to make telnet's login secure?


    How about running telnet on a port other than the standard one?
    eg 2300

    I do that with my ssh server - I've gone from 100's of attempted
    breakins to zero. It appears the baddies mainly try standard
    ports, and are too lazy to try others.

    --
    Troy Piggins ,-O (o- O
    O ) //\ O
    If you're into bondage, make sure "More" `-O V_/_ OOO
    isn't your safety word. RLU#415538

  13. Re: Securing telnet

    On 2006-11-29, Troy Piggins wrote:
    >
    > How about running telnet on a port other than the standard one?
    > eg 2300


    That won't help if all the machines are on the same physical
    network--the connections to port 2300 will be sniffed just as easily as
    those to 23 (assuming that his classmates are reasonably skilled).

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  14. Re: Securing telnet

    On 2006-11-29, Troy Piggins wrote:
    > How about running telnet on a port other than the standard one?
    > eg 2300

    Security by obscurity? Plz, spare me...

    > I do that with my ssh server - I've gone from 100's of attempted
    > breakins to zero. It appears the baddies mainly try standard
    > ports, and are too lazy to try others.

    Those buddies are l33t h4x0rs with "logbot" I guess therefore level of
    danger is really low. You are extactly as vulnerable for attacks as you
    were before moving telnet.

    --
    Damian Szuberski

  15. Re: Securing telnet

    * Damian 'legion' Szuberski wrote:
    > On 2006-11-29, Troy Piggins wrote:
    >> How about running telnet on a port other than the standard one?
    >> eg 2300

    >
    > Security by obscurity? Plz, spare me...


    Securing telnet? Plz, spare me. Right back at ya.

    It's not a production system he's talking about, it's a class
    project. I would've thought every little bit you can do to make
    it more difficult to find your server the better. Of course it's
    not going to make it secure.

    >> I do that with my ssh server - I've gone from 100's of attempted
    >> breakins to zero. It appears the baddies mainly try standard
    >> ports, and are too lazy to try others.

    >
    > Those buddies are l33t h4x0rs with "logbot" I guess therefore level of
    > danger is really low. You are extactly as vulnerable for attacks as you
    > were before moving telnet.


    I disagree, although we may be talking semantics or definitions
    of 'security'.

    I'm saying you get a little more security because you are just
    that little harder to find running on a non-standard port, and
    hence reduce the number of attempted breakins.

    You're saying that they'll find you anyway, and once they find
    your telnet/ssh port, they can just try the same attacks as if
    you were on the standard port. Of course. But the number of
    attacks are reduced.

    --
    Troy Piggins ,-O (o- O
    O ) //\ O
    If you're into bondage, make sure "More" `-O V_/_ OOO
    isn't your safety word. RLU#415538

  16. Re: Securing telnet

    On Thu, 30 Nov 2006 09:14:13 +1000, Troy Piggins wrote:
    > * Damian 'legion' Szuberski wrote:
    >> On 2006-11-29, Troy Piggins wrote:
    >>> How about running telnet on a port other than the standard one?
    >>> eg 2300

    >>
    >> Security by obscurity? Plz, spare me...

    >
    > Securing telnet? Plz, spare me. Right back at ya.
    >
    > It's not a production system he's talking about, it's a class
    > project. I would've thought every little bit you can do to make
    > it more difficult to find your server the better. Of course it's
    > not going to make it secure.


    By now it seems obvious that the point of the 'exercise' is to drive
    home the fact that TELNET IS UNSECURE AND DANGEROUS.

    See the futility of it in a 'learning environmet' -- before venturing
    out into The Real World (tm).


  17. Re: Securing telnet

    Lew Pitcher wrote:
    > Enable telnet in a chroot jail (or a virtual machine), and disable root
    > logins through the telnet session. Your TA gets his telnet, and your
    > system remains secure.


    That's exactly what I'm doing at the moment. Telnet sessions start in a
    chroot dir with a barebones set of bin/ and lib/ files. Thus, telnet
    sessions are relatively benign to the server, but I'd still like to
    prevent users from gaining access in the first place. That access is
    worth points to other teams. Thanks though!

    --
    eth'nT
    http://www.hydrous.net
    aim: courtarro

  18. Re: Securing telnet

    Troy Piggins wrote:
    > It's not a production system he's talking about, it's a class
    > project. I would've thought every little bit you can do to make
    > it more difficult to find your server the better. Of course it's
    > not going to make it secure.


    You're right that it doesn't matter in the long term since this is just
    a demo box, but in the short term we're talking about giving points to
    other teams

    > I'm saying you get a little more security because you are just
    > that little harder to find running on a non-standard port, and
    > hence reduce the number of attempted breakins.


    Damian is right that security through obscurity can be deceptively
    insecure, but I agree with you that it helps. On my servers I'll put the
    private services (like SSHd) on nonstandard ports as a small piece of
    security against automated attacks. That way, if some worm using a
    zero-day exploit spreads infecting SSHd, I'll be a bit more secure.

    --
    eth'nT
    http://www.hydrous.net
    aim: courtarro

  19. Re: Securing telnet

    Ethan Trewhitt (06-11-28 17:14:30):

    > I'm competing in a hacking competition for a network security class in
    > which we must secure a linux machine as well as attempt to hack
    > others. We must offer telnet as a service, and there is a TA who will
    > occasionally connect and log in to see that it's working.
    >
    > Since this password is in the clear, most IT folks would simply say
    > "tough cookies" and not offer telnet, but obviously we don't have this
    > option. Thus, I assume that people will be able to see the TA's logins
    > without much effort, and I would like to use a long, rotating list of
    > passwords so that each password is only valid once. We would share
    > this list with the TA beforehand. Is this possible with any existing
    > tools in Linux? He's ruled out secure tunneling methods, so is there a
    > better way to make telnet's login secure?


    Peter Pearson pointed you in the right direction. Use S/Key
    authentication. It's a very simple, though very secure one-time
    password system, which gets its security from the difficulty of finding
    collisions in a hash function (MD5 by default, but I use SHA1).

    Otherwise you could write your own login program, which requires the
    user to do some math locally, before they can login. Your telnetd
    should allow you to choose an alternative login program. Require the
    user to find some square root of a number in a finite non-field (only
    those, who know the prime factorization of the cardinality of the ring,
    can do that). Or something like that.


    Regards,
    E.S.

  20. Re: Securing telnet

    On 2006-11-29, Troy Piggins wrote:
    >>> How about running telnet on a port other than the standard one?
    >>> eg 2300

    >> Security by obscurity? Plz, spare me...

    > Securing telnet? Plz, spare me. Right back at ya.

    I've commented only miserable try that will (not) make system more
    secure.

    >>> I do that with my ssh server - I've gone from 100's of attempted
    >>> breakins to zero. It appears the baddies mainly try standard
    >>> ports, and are too lazy to try others.

    >> Those buddies are l33t h4x0rs with "logbot" I guess therefore level of
    >> danger is really low. You are extactly as vulnerable for attacks as you
    >> were before moving telnet.

    > I disagree, although we may be talking semantics or definitions
    > of 'security'.
    >
    > I'm saying you get a little more security because you are just
    > that little harder to find running on a non-standard port, and
    > hence reduce the number of attempted breakins.

    Do you see big problem in design dedicated/use existed port scanner?

    > You're saying that they'll find you anyway, and once they find
    > your telnet/ssh port, they can just try the same attacks as if
    > you were on the standard port. Of course. But the number of
    > attacks are reduced.

    True. NumberOfAllAttacks -= ThoseMadeByKids. Security improvement or
    psychical comfort improvment?

    --
    Damian Szuberski

+ Reply to Thread
Page 1 of 2 1 2 LastLast