Securing telnet - Security

This is a discussion on Securing telnet - Security ; On 2006-11-29, Ethan Trewhitt wrote: >> 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: Securing telnet

  1. Re: Securing telnet

    On 2006-11-29, Ethan Trewhitt wrote:
    >> 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.

    If somebody can discover and exploit vulnerability, he (she?) can add to
    exploit scanner (stupid telnet to port and check for 'SSH-1.99-OpenSSH_4.3'
    is enough, right?).

    --
    Damian Szuberski

  2. 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?
    >


    You may try kerberos. Kerberos would encrypt the password...

  3. Re: Securing telnet

    Ethan Trewhitt wrote:

    > 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!


    Suggestion (hypothetical): use layers. I cannot suggest exact software or
    configuration, but it's your assignment, not mine. Do exactly what was
    suggested above (and elsewhere about using non-standard ports, rotating
    passphrase lists, etc.) which you said you were doing. Allow only one
    login from the TA.

    Immediately after successful login, disable that password for normal
    login, but keep it open for a honeypot.

    Any second or subsequent login attempts with that passphrase, put them
    into a honeypot, and get whatever info on them you can. If you can get
    info to "back-crack" them from the honeypot, those are points for you.

    Require a second layer, challenge response authentication.

    Immediately after login and second layer authentication, require a
    password change via (at least) Diffie-Hellman key negotiation to prevent
    sniffing(, or rely on a pre-established long list of one-time
    passphrases). Perhaps your TA doesn't have appropriate encryption software
    installed, in which case there could be more difficult but still possible
    solutions to achieve the same anti-sniffing purpose. Require strong
    passphrases. If your other classmates are sniffing the TA's login and it
    remains valid, they will be on you like fleas on a dog.

    This all presupposes there is no MITM attack possible, in which case all
    bets are off. If it is possible in your lab LAN environment for a student
    to run a MITM attack (think carefully) then set a bot, do that and crack
    everyone else's logins and get an A+. You'll either land a great job or
    get put on "Homeland Security's" watchlist and never be heard from again.
    ;/ HSA probably doesn't like people to use the same tactics they might
    think they are permitted to use. But it's just a class assignment on a
    lab LAN, right? And you can also keep screaming that it was just your
    contribution to "The War On Terror", as they fly you off to some secret
    prison in (...Romania...?).

    Obviously, if someone can sniff and read your clear text logins they can
    log right into your systems, unless other layers are in place. (*_Don't_
    leave telnet open to the world.*)

    HTH.


  4. Re: Securing telnet

    * Ethan Trewhitt wrote:
    > 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


    Not sure if you can use it for telnet, but have you looked into
    port knocking?

    http://www.portknocking.org/

    >> 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.


    Exactly.

    --
    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

  5. Re: Securing telnet

    Troy Piggins wrote:

    > Not sure if you can use it for telnet, but have you looked into
    > port knocking?
    >
    > http://www.portknocking.org/


    You can use port knocking to secure any port you want, including the telnet
    port.

  6. Re: Securing telnet

    As well as changing the address he could use a form of port knocking.

    Allodoxaphobia wrote:
    > 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).
    >


    --
    ----------------
    Barton L. Phillips
    Applied Technology Resources, Inc.
    Tel: (818)652-9850
    Web: http://www.applitec.com

  7. Re: Securing telnet

    You can also implement a form of port knocking. This will make it a lot
    harder for a bot to break in.

    Ethan Trewhitt wrote:
    > 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.
    >


    --
    ----------------
    Barton L. Phillips
    Applied Technology Resources, Inc.
    Tel: (818)652-9850
    Web: http://www.applitec.com

  8. Re: Securing telnet

    On 2006-11-29, Ethan Trewhitt wrote:
    >
    > 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.


    After this huge thread, I hope you will post with the results of your
    sessions! I am especially curious about the work you'll do to
    secure your sessions, how successful your classmates were at cracking
    your box, and if you got cracked how they did it.

    --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


  9. Re: Securing telnet

    On 2006-11-30, Barton L. Phillips wrote:
    > You can also implement a form of port knocking. This will make it a lot
    > harder for a bot to break in.
    >

    From the sound of it, I think OP's challenge is securing telnet on a
    sniffed network. port knocking, while cool in other situations,
    probably wouldn't be very effective here. One time passwords seem like
    the way to go.

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

  10. Re: Securing telnet

    Ian Kilgore wrote:

    > From the sound of it, I think OP's challenge is securing telnet on a
    > sniffed network. *port knocking, while cool in other situations,
    > probably wouldn't be very effective here. *One time passwords seem like
    > the way to go.


    You can do the same with port knocking by having a one time knock sequence.
    No, it does not stop from sniffing the data, but it does make it close to
    impossible for someone to try buffer overflow attacks on an open telnet
    port. Kerberos could be used to encrypt the password. If it is allowed, the
    use of a VPN between computers could allow for an encrypted telnet session
    that nobody could sniff and read the data without breaking the encryption.

  11. Re: Securing telnet

    An update for everyone, since I figure I owe it to the group...

    I ended up implementing a chroot jail on my machine using a bit of code
    called chrootshell. It performs the chroot after login on any interface
    (telnet or ssh in our case), then uses the chroot's etc/passwd to set
    the user up with a real shell. I had to build a miniature filesystem for
    the chroot jail, but it worked quite well.

    We didn't implement one-time passwords or Kerberos simply due to time.
    Of the 8 teams, 5 of them (including my team) were able to sniff most of
    the telnet passwords and gain user access to the other teams' boxes. The
    teams that got into our box weren't able to do anything but create a
    text file as evidence, so I consider it a success. I know for future
    reference that I will be trying out one-time passwords and creating my
    own PAM library, whenever I have some free time. Thanks again for all
    the help!

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

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2