Telnet Script or Equivalent

chiguy1256 · 02-23-2018, 08:20 PM

I need a shell script that either reads input from a file that contains IP addresses and TCP ports or this information can be contained in the script itself. I need to telnet to the addresses and write the results to a log. This will be used to maintain ACL/firewall connectivity. Please advise. Thanks.

John VV · 02-24-2018, 12:18 AM

what have you done so far ?
and please show your work

- guessing this might be homework ?

also tellnet should NOT be used !!!
- yes there are exceptions but it is very INSECURE

John VV · 02-24-2018, 12:18 AM

what have you done so far ?
and please show your work

- guessing this might be homework ?

also tellnet should NOT be used !!!
- yes there are exceptions but it is very INSECURE

Turbocapitalist · 02-24-2018, 12:52 AM

Yes, please show your work so far.

Avoid telnet. If you are just getting started look at an SSH or SFTP client instead. They are secure and they are easier to script. If you've already done some work trying to use telnet, stop, erase it, and look at an SSH or SFTP client instead.

TB0ne · 02-24-2018, 09:24 AM

Quote:

Originally Posted by chiguy1256

I need a shell script that either reads input from a file that contains IP addresses and TCP ports or this information can be contained in the script itself. I need to telnet to the addresses and write the results to a log. This will be used to maintain ACL/firewall connectivity. Please advise. Thanks.

Read the "Question Guidelines" link in my posting signature. As others have said, we're happy to help, but you have to show your own efforts first. We aren't going to write your scripts for you, and you can find MANY examples of bash telnet scripts with the same internet search you used to find this site.

chiguy1256 · 02-25-2018, 08:24 AM

Quote:

Originally Posted by John VV

what have you done so far ?
and please show your work

- guessing this might be homework ?

also tellnet should NOT be used !!!
- yes there are exceptions but it is very INSECURE

John VV, no this is not homework. Doing some work for my employer. There is an IBM application that I support on some Red Hat Linux and IBM AIX servers we have. However, I don't work on these environments very much and do not have much scripting experience. I do know that on both systems I do not have access to nmap or netcat.

Below is a sample script I found online. This uses /dev/tcp. It works fine, but displays results to the screen. I want to log the information/results.

I am going to ask some of my UNIX/Linux counterparts at work as well.

Whatever method is used, I just need to insure that it satisfies the firewall.

Thank you in advance.

#!/bin/bash
echo "scanme.nmap.org 80
scanme.nmap.org 81
192.168.0.100 1" | (
TCP_TIMEOUT=3
while read host port; do
(CURPID=$BASHPID;
(sleep $TCP_TIMEOUT;kill $CURPID) &
exec 3<> /dev/tcp/$host/$port
) 2>/dev/null
case $? in
0)
echo $host $port is open;;
1)
echo $host $port is closed;;
143) # killed by SIGTERM
echo $host $port timeouted;;
esac
done
) 2>/dev/null # avoid bash message "Terminated ..."

TB0ne · 02-25-2018, 09:19 AM

Quote:

Originally Posted by chiguy1256

John VV, no this is not homework. Doing some work for my employer.

Ah...so since you're asking US to do your work then, how much of your paycheck do we get for doing it?

Quote:

There is an IBM application that I support on some Red Hat Linux and IBM AIX servers we have. However, I don't work on these environments very much and do not have much scripting experience. I do know that on both systems I do not have access to nmap or netcat.

This is very confusing; you say that your job is supporting an application on RHEL and AIX servers...then say you don't work on these environments very much?? How, exactly, do you support them then? And there are THOUSANDS of bash scripting tutorials you can find online to get you started. And since this is for your job, wouldn't it be a good idea if you learned to to it?

You also don't say what this 'application' is that you support. There may be other ways of doing things.

Quote:

Below is a sample script I found online. This uses /dev/tcp. It works fine, but displays results to the screen. I want to log the information/results. I am going to ask some of my UNIX/Linux counterparts at work as well. Whatever method is used, I just need to insure that it satisfies the firewall.

If you're wanting to satisfy the security requirements...you DO NOT want to use telnet. At all; ever. It is horribly insecure, and has been for decades now. Since your company is paying for RHEL and AIX (and AIX isn't cheap), your company must be large enough to take security seriously. Why do you not use SSH, and do a keyswap, making whatever you have to do MUCH easier?

Quote:

Code:

#!/bin/bash
echo "scanme.nmap.org 80
scanme.nmap.org 81
192.168.0.100 1" | (
  TCP_TIMEOUT=3
  while read host port; do
    (CURPID=$BASHPID;
    (sleep $TCP_TIMEOUT;kill $CURPID) &
    exec 3<> /dev/tcp/$host/$port
    ) 2>/dev/null
    case $? in
    0)
      echo $host $port is open;;
    1)
      echo $host $port is closed;;
    143) # killed by SIGTERM
       echo $host $port timeouted;;
     esac
  done
  ) 2>/dev/null # avoid bash message "Terminated ..."

So run the script "<script name> > /some/output/file.txt"
There you go. Script output to a file name. And using /dev/tcp isn't a good idea. If it's not your job to work with unix/Linux servers, then why aren't the unix/Linux support folks doing the scripting for their systems?

pan64 · 02-25-2018, 09:36 AM

I can't see how is this script related to "maintain ACL/firewall connectivity". By the way, what do you mean by that at all?

chiguy1256 · 02-25-2018, 01:34 PM

Quote:

Originally Posted by TB0ne

Ah...so since you're asking US to do your work then, how much of your paycheck do we get for doing it?

This is very confusing; you say that your job is supporting an application on RHEL and AIX servers...then say you don't work on these environments very much?? How, exactly, do you support them then? And there are THOUSANDS of bash scripting tutorials you can find online to get you started. And since this is for your job, wouldn't it be a good idea if you learned to to it?

You also don't say what this 'application' is that you support. There may be other ways of doing things.

If you're wanting to satisfy the security requirements...you DO NOT want to use telnet. At all; ever. It is horribly insecure, and has been for decades now. Since your company is paying for RHEL and AIX (and AIX isn't cheap), your company must be large enough to take security seriously. Why do you not use SSH, and do a keyswap, making whatever you have to do MUCH easier?

So run the script "<script name> > /some/output/file.txt"
There you go. Script output to a file name. And using /dev/tcp isn't a good idea. If it's not your job to work with unix/Linux servers, then why aren't the unix/Linux support folks doing the scripting for their systems?

I apologize for the post. Admins, if you want, you can go ahead and delete the entire thread.

TB0ne · 02-25-2018, 02:23 PM

Quote:

Originally Posted by chiguy1256

I apologize for the post. Admins, if you want, you can go ahead and delete the entire thread.

No one is saying to delete it, but you have to SHOW YOUR OWN EFFORTS here. You found a script, and you say it does what you need...and you were told to run that script followed by the ">" to redirect output to a file, which is what you asked for.

You were ALSO given advice to not use telnet, but to use SSH. You won't name the application (so we cannot offer ideas on alternative to what you're doing), explain what you mean by "maintain ACL/firewall connectivity", tell us how you administer this application on AIX/Linux without actually getting ON those systems, or how you expect to deploy these things if you're not on the Linux/Unix admin team (which, it seems, you're not).

We're happy to help you, but if you won't answer questions or take advice, there isn't much use in posting. Telnet is insecure; do not use it. Use ssh, keyswap, and you can run commands remotely through a VERY simple script. And still be secure.