Can I Use Telnet to Verify What Kind of Service a Port on a Different Host Is Running?

Using Ubuntu 22.04 on my laptop, and I have the socket address 192.168.38.201:8080 of a different machine. When I log in via telnet on my terminal, it does seem to work, as in a screen appears saying this

$ telnet 192.168.38.201 8080
Trying 192.168.38.201...
Connected to 192.168.38.201.
Escape character is '^]'.
^]
telnet> display

But what kind of conclusion can I draw from this? That I have firewall access to that specific port, and some service (which may be http, SSH, redis etc.) is running on that port? Once I connect, can I query anything more, like what kind of service is running, what protocol it supports etc.?

If the telnet-ing fails, can I conclude either no service is running or I do not have firewall access?

All that telnet does is that it opens a connection to that port and tries to establish an "interactive session" - in the way that everything that you type will be sent the remote host and that everything the remote host replies will be echo'ed back to you.

It is primarily intended as a convenience tool for bi-directional communication with a text-based remote service - and NOT a security tool.

You pretty much want to use a tool such as nmap (that should be availabe as a package in any major GNU / Linux distribution) for any kind of "inquisitative" questions.

It has quite a lot of options, but you can find several decent guides on how to use it online - for instance https://phoenixnap.com/kb/nmap-commands or https://www.stationx.net/nmap-cheat-sheet/

To answer your "If the telnet-ing fails" - this leads to the issue of "how did it fail?".

Because there might be several different ways how it might "fail" that may not be obvious:

• telnet uses the TCP protocol - so it tells you nothing about UDP / ICMP or other protocols.
• Your firewall may only allow traffic in one direction. And while this would normally cause telnet to "fail" - your firewall could possibly misconfigured so badly that it would allow all of those control packets that are required for a TCP connection to be established - but still not allow any data being sent.
• The service that you connected to may not support any input and/or output

To give you a little bit more background: TCP is just one of the many protocols that are implemented on top of IP - or "the internet" as it's generally perceived.

TCP is a stateful, connection-based protocol.

UDP is stateless and connection-less. Several core services use UDP, such as for instance DNS.

Security oriented tools such as nmap have been designed to do their best to figure out what exactly is going on. But there are many things that could cause telnet to "fail".

Historically, telnet was used prior to the wide-spread adoption of encrypted shells such as ssh; you'd use telnet to get an interactive command prompt at a remote computer. But oftentimes, it already failed miserably when the two couldn't agree on a common character set.

It was never meant to handle any binary data either.

So basically, if telnet succeeds, then a bi-directional text-based communication channel could be established. If it doesn't succeed, nothing else can reliably be assumed.

Since you're using a private IP address in your question - please be aware that you should really run a tool such as nmap against your public IP address - and from a machine outside your network.

You could, for instance use the Free Tier of a Cloud Provider such as Amazon AWS to deploy a very basic image of something like Debian or Alpine to run the nmap against your public IP from the "outside".