I got an answer ready for this but I had a crisis of morality.

If you can explain a good reason to have something like this, I'll answer. Until then, this is a bad attempt at getting someone to help you thwart security.

Please, no one answer until we are sure we are not helping someone make life harder on someone else.

Update:

I can only see one reason for this:

You are in a college or a library, and you see a common computer.

You decide to log in and check your email through telnet on a
college server.  You go to the computer, run 'telnet', and wait
for the "username" and "Password" prompts.  When they arrive,
you type in your username "naiveboy", and you type in your 
password "drowssap".  You get an "incorrect password" message.

You try again, you get the same error.  You try another computer 
and you get connected.  

Unbeknownst to you, your password and username were just grabbed
by the unimaginative yutz who can write enough perl to create
a fake telnet client like the one above.

Let's not help the yutz above ruin someone's life.

J. J. Horner
Linux, Perl, Apache, Stronghold, Unix
jhorner@knoxlug.org http://www.knoxlug.org/

However there is no need to use Perl to get that. Instead investigate /etc/syslog.conf and you will find that login errors are already logged for you. If you are an authorized administrator (and not a moronic script kiddie) you should be able to figure out what you need to legimately do from the messages you can log from there.

Easy, easy! Witch hunts have rarely done any good. :-))

What I mean by this is there are probably legitimate uses even if we don't see them right away. I remember that I wanted to write my own telnet client when I started learning Perl a few years ago to add some extra functionality for my personal use (didnīt succeed, though, cause I used a all-but-clever approach :-/, and I never resumed the project). Or I might be interested to write one so I understand the inner workings. There is no reason why I shouldnīt write my own clients, servers and wrappers.

The example jjhorner stated is, of course, a real scenario, but I'd like to add that the first stone should be thrown at the sysadmin of that box that allows anonymous users to install executables (even in their local directory). The minimum he/she should do is to give them a restricted shell.

Another point is that security by obscurity alone will not work. There are also no such thing as a good or a evil tool. It always depends on how you use them. E.g. while I use SAINT to check my boxes for security holes every once in a while another guy uses them to find the holes and break into a computer.

It is my personal believe that publishing security exploits enhances security on the long run as it doesnīt give cracker circles an advantage of knowledge. I remember a post some days ago when a monk pointed out that you should never accept unchecked input from a user (e.g. path names) and was prompted by the original author "any security exploits?"! You see, the holes are out there, the bad boys know them, so spread the word on how itīs done and how to prevent it.

Just my two cents. Feel free to comment on this in public or private (see my home node for the email address).

Andreas

There are certainly legitimate uses for a telnet client, server, or wrapper. However, that's not what this person asked for. They want a "fake telnet client" that will take the username and password, then give a false error message and log the username and password.

I have yet to hear of a single legitimate use for such a program. I can think of only one purpose; to log usernames and passwords without user knowledge. A legitimate administrator has no need for such tools; in *nix, this information can be logged, while in Windows, the administrator can determine the user passwords with ease.

So, then - under what circumstances does this become a legitimate use?

- email Ozymandias

A legitimate use is hard to find here, I admit. The only one I can think of is to actually write this fake client so you can demonstrate the people they have a problem. But that sounds a bit far fetched, even to me.

By now, I thought our friend GoRN would have found time to post a reasonable explanation himself, which he/she didn't, so I am more willing to follow your interpretation of his/her intents. What makes me wonder is, should the intent really be to create a password stealing telnet, why not cloak this request with something harmless like "I want to write a new MUD client ..." or something like that? Would have gone through easily ...

Well, you never know. Letīs hope the admins close the security hole in the first place, 'cause our young friend is certainly not alone out there.

Andreas

This is probably a stretch, but it could be used as a honeypot that not only keeps a script kiddie busy, but also gives the administrator some idea of what kind of attack is being attempted (raw brute force, dictionary attack, etc). That being said, I also feel uneasy about the original question. Just my thoughts...

Do not use perl for bad! Perl is good, not evil. Go somewhere else and with another language.

mt2k:

This is not meant as a personal attack or criticism.

But. You are assisting someone in breaching security. I am an experienced systems administrator, so are several of the people here, including jjhorner. If ANYONE, including one of my admins, tried to do something like this, they would be fired so fast they wouldn't even notice the gunshot wounds. There is NO legitimate reason for doing what this person describes. It has nothing to do with their username, as evidenced by the fact that I can't remember what it is right now. It has everything to do with their description of what they are attempting to do. If they have a legitimate reason for doing this, I challenge THEM to provide one, and if they do provide one that I feel is acceptable, THEN I will help them. Not before.

- email Ozymandias

i think the issue is that he says he wants to "replace" telnet with a telnet-like client that always fails and stores the login/password entered.

correction: i see now that he doesn't mention logging anything but the error. my mistake. however, it seems to be saying that it would intentionally generate an error in a non-error situation and then log it, which makes no sense.

This is a very bad idea.

The problem is that you're getting overly complex. The only reason for creating a box with intentional security vulnerabilities is to create a honey pot system for intrustion detection/cracker investigation, and that's not something you want to be playing with. Honey pots and honey nets are widely known by both real crackers and script kiddies, and as such running on is a good way to become a frequent target. If that's what you want, then don't go to all this trouble; just run wu-ftpd and straight telnet.

If you want a secure box, on the other hand, then you do NOT want to play The Shell Game. That's been done, over and over again, and every time the person running it thinks it's a reall cool idea guar-an-teed to make their system into a castle.

The problem is that you're letting them in in order to trap them. Think of the castle analogy; the root account is the castle keep, the throne room, along with all your critical files. IPCHAINS and other firewalling software are the outer walls. Every open port is a separate gatehouse into the castle; you might put passwords and access control lists in place to restrict it, like drawbridges and guards, but it's still a gateway into the castle.

What you're trying to do here is to create a blind alley gatehouse, a way into the castle that doesn't lead anywhere. You want to let your enemy in, then observe what they do once they're there.

That sounds good for the castle, but it's where the analogy breaks down. Castles have thick granite walls and iron gates and guards with real, thinking brains and pointy things to annoy the intruder. Your computer is an unthinking automation, which will do exactly what you say but won't think about what it's doing, and it will work for the intruder as well as it does for you. Once you let them into that blind pocket, they're inside your wall. If you do that, EVERYTHING has to be perfect, and EVERYTHING has to work exactly right, or you can kiss your system good-bye. It never, ever will be perfect. Don't even pretend for an instant that you can make it that way. Nothing is perfect, nothing is absolutely secure if it's on the Internet. The most you can do is create a strong, simple security model. And that's already been done. Bastille Linux is a good place to start if you are willing to use a RedHat derivative. (Don't try to impress me with your Slackware bigotry; the only thing Slackware does better than RedHat is allow you to shoot yourself in the foot with compiled source rather than packages. It still hurts.) Another good place is LinuxSecurity.com. The Linux Security HOW-TO is another good place to start. You'll notice none of them advocate things like your fake Telnet server.

- email Ozymandias

Not to reply to everything you write today, but seconded and agreed. In addition using ftp for administration is a bad idea. It doesn't matter whether nobody knows what ftpd you have, you are still sending your passwords in the clear to your box where anyone can pick them up!

Rather than trying to think up cool security tricks, spend some time learning what people who have been doing this for some time think. I might have given a different list than Ozymandias did, but I don't disagree with anything he listed and he gave you enough reading material for a bit.

I would suspect a proper answer might be found in the Unix Socket FAQ. Yes, I know it's Unix. Yes, I know the examples are given in C. The important thing is that sockets in Perl are remarkably similar.

Question 4.13 appears to give an applicable answer.

thats a cool faq, I wanna learn C++ ( i know different but structed the same) and I'm using Linux... Thanks for the link, reading now Dunt Dunt Duh...
GoRN To The Rescue,
Yet Again...
zGoRNz@Yahoo.com
- GoRN Out -
^D
EOF
Check out GBNBot, /the/ Battle.Net Bot for *nix.

#!/usr/bin/perl
use IO::Socket;
#use Net::hostent;
$port = 9539;
$0 = "Telmet \*Running\*";
$serv = IO::Socket::INET->new (
Proto => 'tcp',
LocalPort => $port,
Listen => 10,
Reuse => 1)
|| die "Can't create server: $!";

while ($client = $serv->accept()) {
eval {
$client->autoflush(1); # Always remember to flush!
$who = $client->peerhost;
print STDERR "Telmet2: Connection from $who\n";
print $client " Zincix 12.76\n";
print $client "The /ONLY/ Secure *Nix \n";
print $client "\n\n";
print $client "Nixel Login: ";
$usr = <$client>;
chomp $usr;
$usr =~ s/\W//g;
print STDERR "Telmet2: $who: User $usr\n";
die unless (length $usr < 20 && length $usr > 1);
print $client "Passwd: ";
$pass = <$client>;
chomp $pass;
die unless (length $pass < 20 && length $pass > 1);
print STDERR "Telmet2: $who: Pass $pass\n";
print $client "Incorrect Username or passwd!\n";
print $client "Remember it's case sensitive!\n";
};
close $client;
}

I remember when I originally read this thread that I definitely agreed with those who felt you were trying to develop a cracking tool. They felt, on that basis, that it would be improper to answer your question.

I can see from what you have written that you have stated a somewhat legitimate reason for your qustion, but I still feel that it would be improper to answer your question (to be fair, I haven't used IO::Sockets, so I couldn't answer the question even if I wanted to).

Basically, what you are asking is for help creating security by obscurity. This is arguably the worst method of creating security. If, for some reason, a cracker wanted to take a run at your box, do you really believe that sending out signals suggesting your box is 3 different OSs is really going to fool anyone? If you have a moderately secure box, it might fool the casual user, but that's about it.

Learn how to tighten down your box properly and you won't have to worry about useless tricks like this.

Cheers,
Ovid

> I still feel that it would be improper to answer your question

Personally, I think that at least in this case it would be much better to answer with an alternate solution to the problem rather than just not answering it because you feel that the questioner is asking the wrong question. Sometimes I spend ages figuring a particular problem out, only to find out later that what I've spent the last 4 hours scratching my head over is not what I'm looking for at all. That doesn't mean I've wasted the last hour; I'm still learning and every problem I solve is something learnt.