Telnet Under the Microscope: Why It's Unsafe for Modern Use
Get link
Facebook
X
Pinterest
Email
Other Apps
-
Telnet, an early protocol for remote server and device access, was once groundbreaking. However, in today’s era of cybersecurity threats, Telnet’s lack of encryption has made it obsolete and dangerous to use. This blog will demonstrate the security risks of Telnet by capturing and analysing its unencrypted communication over a network.
We Will:
Create two Ubuntu instances using Multipass.
Install and configure a Telnet server on one instance.
Create a user and password on the server.
Capture network packets while authenticating to the server.
Analyse the captured packets to show how credentials are sent in plain text.
Part 1: Introduction and Setting Up Ubuntu Instances
In Part 1, we start by setting up Ubuntu instances using Multipass. We walk through the process of creating a Telnet server and Telnet client, preparing the environment for the next steps. Watch the video here:
In Part 2, we install and configure the telnetd package on the Telnet server. This is the crucial step in setting up the server so it can accept incoming Telnet connections. Watch the video here:
In Part 3, we create a new user on the Telnet server, called demo, and set up a password for this user. This step will prepare us for the login process in the next video, where we will test the Telnet connection and observe the insecure traffic. Watch the video here:
In Part 4, we start the tcpdump packet capture on the Telnet server and initiate a Telnet login from the client. We will capture the traffic as the user logs in and executes a few commands, all while the Telnet protocol transmits sensitive data in plaintext. Watch the video here:
In Part 5, we analyze the pcap file captured with tcpdump in Wireshark. We highlight how Telnet transmits sensitive information, like usernames and passwords, without encryption. This final part concludes the demo and shows why Telnet should be replaced with secure alternatives like SSH. Watch the video here:
Through this series, we’ve demonstrated the dangers of using Telnet in modern networks. Telnet’s reliance on plaintext transmission makes it highly vulnerable to man-in-the-middle attacks and eavesdropping. By using tools like Wireshark and tcpdump, we can visualize just how easily Telnet can be exploited to intercept sensitive data.
Thank you for following along with this tutorial series! We hope you found the videos and this guide helpful in understanding the vulnerabilities of Telnet. If you have any questions or need further clarification, feel free to leave a comment below or reach out.
Prerequisites Before we dive into packet analysis, make sure you have the following set up: Two Endpoints (VMs or Containers) Wireshark tcpdump It’s also important to have a basic understanding of: TCP SSH Linux Introduction In this blog post, I'll guide you through the step-by-step process of analyzing SSH connection packets using Wireshark. Whether you're troubleshooting SSH issues or simply curious about how SSH works at the protocol level, this tutorial is for you. We'll cover both successful and failed SSH connections, examining the packet flow and explaining what’s happening in the background. I've already set up a working environment for this use case. Let’s dive right into packet capture and analysis, and uncover what happens during an SSH connection. Fig. 1: A list of servers with roles and IP addresses for quick network reference. Breaking Down Packet Capture and Analysis: A Step-by-Step Guide In this post, we'll break down the process of packet capture...
Terraform Providers: plugins that interact with cloud providers, SaaS providers, and other APIs. Each provider adds a set of resource types and/or data sources that Terraform can manage. W ithout providers, Terraform can't manage any kind of infrastructure. All Terraform configurations must declare which providers they require so that Terraform can install and use them Provider Configuration Sample Example of Provider Declaration In many Terraform setups especially in growing teams . it's common to see each module define its own provider block. It often looks like this: terraform { required_providers { incus = { source = "lxc/incus" version = "0.3.1" } } As infrastructure evolves the need of multiple modules becomes inevitable . Each of the modules if following the hardcoded approach incl...
