Telnet is a protocol that allows us to connect to and control a remote device. The telnet program can be used to test whether ports on a remote server are open, closed, or filtered. This makes it a useful tool for testing port connectivity before deploying applications and services.

In this comprehensive guide, we will cover:

  • An overview of the telnet protocol
  • Using telnet to test specific ports
  • Examples testing open, closed, and filtered ports
  • Automating tests with a telnet shell script
  • Checking ports for potential vulnerabilities with nmap

Understanding the Telnet Protocol

Telnet is an unencrypted text-based protocol that allows connecting to and controlling a remote device. By default, telnet uses TCP port 23.

When you connect to a remote host with telnet, you get a terminal session where you can execute commands as if you were logged into the device locally. This allows for testing and administration.

However, telnet has some major downsides:

  • Communication is in plaintext and unencrypted. Any data sent over a telnet session could be intercepted and read by an attacker on the same network. Usernames, passwords, and other sensitive data are transmitted insecurely.

  • There is no authentication. An attacker could establish their own telnet session and execute malicious commands.

Because of these deficiencies, telnet has largely been superseded by the Secure Shell (SSH) protocol for remote access. SSH uses strong encryption to secure communication channels, and supports several methods for authenticating users and preventing unauthorized access.

While SSH is preferred for most administration and connectivity, telnet still has some useful testing applications which we will explore in this guide.

Using Telnet to Test Specific Ports

While telnet has security weaknesses as a remote access protocol, the telnet program can still be useful for checking port status. By attempting to establish a manual telnet session on a specific port, we can quickly test whether that port is open, closed, filtered, or if a service is listening on that port.

Some key terms:

Open port: A port that is actively listening for and accepting new connections. Establishing a telnet session will connect successfully.

Closed port: A port has been purposely shutdown or blocked. Telnet will display "Connection refused."

Filtered port: A firewall or other security device is blocking access to that port. Telnet will timeout with no response.

Checking Port Status with Nmap First

Before diving into manual telnet tests, it‘s always a good idea to start by scanning the target with nmap to discover open ports and running services.

For example, let‘s scan a server at 192.0.2.1:

nmap 192.0.2.1

This performs a basic TCP scan on 1000 common ports. The output will highlight ports that nmap finds open or closed:

Starting Nmap 7.91 ( https://nmap.org ) at 2023-02-20 16:34 EST
Nmap scan report for 192.0.2.1
Host is up (0.0014s latency).  
Not shown: 998 closed ports
PORT   STATE SERVICE
22/tcp open  ssh    
80/tcp open  http

This shows that ports 22 (SSH) and 80 (HTTP for a web server) are open.

Now that we know some available ports, we can test connectivity manually with telnet.

Telnet Session to an Open Port

Let‘s try connecting to port 22 which nmap reported as open:

$ telnet 192.0.2.1 22
Trying 192.0.2.1...
Connected to 192.0.2.1.
Escape character is ‘^]‘.
SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1

This allowed us to establish a connection successfully. The "Escape character" message indicates the session is active, and then we see the remote server immediately returns data, showing SSH is listening and identifiable on that port.

So port 22 is actively open and accepting TCP connections as expected.

Telnet to a Closed Port

Now let‘s try connecting to a closed port that is not listening for connections:

$ telnet 192.0.2.1 81
Trying 192.0.2.1...
telnet: connect to address 192.0.2.1: Connection refused

We immediately see "Connection refused," indicating the remote host has purposefully closed port 81. Our TCP connection attempt is rejected.

Testing a Filtered Port with Telnet

Finally, let‘s see what happens when a port is filtered by a firewall:

$ telnet 192.0.2.1 123
Trying 192.0.2.1...

The connection hangs indefinitely until eventually failing with timeout. There is no "Connection refused" because incoming packets are blocked before ever reaching the host service. So filtered ports simply appear unresponsive to telnet session attempts.

Automated Telnet Testing with Bash

Rather than manually running telnet each time, we can automate connectivity testing in a bash script.

Here is an example script called testports.sh that reads a list of target IPs and port numbers from a text file, iterates through attempting telnet connections, and logs any successes or failures:

#!/bin/bash

targets=$1

while read -r target port; do
  echo "Testing $target on port $port" >> testlog.txt

  if telnet "$target" "$port">/dev/null 2>&1; then  
    echo "[OK] Connected to $target on port $port" >> testlog.txt
  else
    echo "[FAIL] Failed to connect $target on port $port" >> testlog.txt
  fi

done < "$targets"  

The telnet command is sent to /dev/null to suppress any output. We use the exit code to record pass/fail rather than inspecting connection banners.

An example target file would look like:

192.0.2.1 22
192.0.2.1 80 
192.0.2.2 80
192.0.2.3 443
...

This allows conveniently running:

testports.sh targets.txt

And efficiently testing connectivity to all entries in that target file.

So with some simple scripting, telnet can support automated connectivity testing across environments.

Checking for Vulnerabilities with Nmap

While telnet is handy for quickly checking port status, tools like nmap provide deeper inspection capabilities and vulnerability scanning functions. Some examples:

Banner Grabbing for Service Identification

Whereas telnet displays the raw connection banner returned, nmap can map banners to known services:

nmap -sV 192.0.2.1

Starting Nmap 7.91 ( https://nmap.org ) at 2023-02-21 10:23 EST
Nmap scan report for 192.0.2.1
Host is up (0.0048s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))

This fingerprints the running SSH and HTTP server versions, rather than just showing the raw connection text.

Targeted Vulnerability Scanning

Nmap supports detailed vulnerability scans to check services for known security issues:

nmap --script vuln 192.0.2.1 

Starting Nmap 7.91 ( https://nmap.org ) at 2023-02-21 10:25 EST
Nmap scan report for 192.0.2.1
Host is up (0.0062s latency).

PORT   STATE SERVICE
22/tcp open  ssh
| vulners:  
|   cpe:/a:openbsd:openssh:7.6p1:
|       CVE-2019-6111   7.5 https://vulners.com/cve/CVE-2019-6111
|       CVE-2019-6110   7.8 https://vulners.com/cve/CVE-2019-6110
|       CVE-2018-20685  7.5 https://vulners.com/cve/CVE-2018-20685
|       CVE-2018-15473  7.8 https://vulners.com/cve/CVE-2018-15473 
|_      ...

80/tcp open  http  
| http-vuln-cve2011-3192: 
|   VULNERABLE:
|   Apache byterange filter DoS
|     State: VULNERABLE
|     IDs:  CVE:CVE-2011-3192  BID:49303
|       The Apache web server is vulnerable to a denial of service attack when numerous
|       overlapping byte ranges are requested.
|     Disclosure date: 2011-08-19
|     References:
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
|       https://seclists.org/fulldisclosure/2011/Aug/175
|_      https://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3192
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-stored-xss: Couldn‘t find any stored XSS vulnerabilities.
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)
...

This scans the running services against known vulnerabilities, identifies several issues with the OpenSSH version, and detects that the Apache server is vulnerable to a specific denial of service (DoS) attack.

Nmap has extensive vulnerability checking capabilities, rather than just testing if a port happens to connect. This allows identifying services needing upgrades or reconfiguration to resolve security gaps.

Conclusion

While telnet is not generally recommended as a remote access tool, the telnet client can still be useful for basic port testing and availability checks during troubleshooting or service deployment. The manual interactive connections give quick visual port status, easily confirming open, closed, and filtered behavior.

Nmap builds on these basic tests with detailed service identification, vulnerability scanning, and more advanced TCP/IP interrogation options. Together they provide both simple connectivity checking and deeper inspection capabilities.

There are many techniques for mapping network topology and validating vulnerabilities ranging from elementary telnet sessions to sophisticated enterprise scanning tools. Understanding the basics helps determine the right approach for hardening environments against threats. Hopefully this overview gives a solid foundation for strategically applying these technologies!

Similar Posts