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

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

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

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

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

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

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

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.

On 2006-11-29, Ethan Trewhitt <gtg782a@mail.gatech.edu> 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

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

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