Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

361–370 of 414 posts

Re: The Day the Telnet Died

#361
post #335

Earlier quoted context omitted.

If you can get it on IPv6, maybe via a gateway, port 23 filtering doesn't seem to be applied to IPv6 yet! (I assume because the v6 address space is too large to mass scan?)

If I am rewriting the network stack or making other substantial changes, that defeats the purpose of historical preservation.

If moving it to another port from the OS is beyond the pale for you, your router should implement PAT (port translation) or forwarding, so that from the outside, users could connect on, say, 443 or 2323, and the router rewrites the segments to connect to your immutable port 23/tcp.

It makes no sense that IPv6 is treated differently than IPv4. If GNU telnetd is vulnerable and it's running on port 23/tcp, it will be found on IPv6. I would definitely not bind anything to listen on port 23 on any protocol, because I would expect it to become filtered shortly. Port 23 is permanently burned everywhere.

Conversely, a vintage PDP-10 telnetd is not affected by the CVE for GNU.

It is a classic rookie mistake to treat the two protocols differently, so if Tier-1 providers have done this, they must be overly optimistic, or foolish, or met with some technical obstacles, or perhaps OSI Layer 8?

Re: The Day the Telnet Died

#362

Never mind telnetd. Tier 1 transit providers doing port filtering is EXTREMELY alarming. They have partitioned the Internet, and in a way that automatic routing (BGP) can't get around.

I can connect with the GNU telnet client via the Spectrum ISP to servers in both Seattle and the Netherlands.

It doesn’t matter what client you use.

Is it on port 23/tcp, and what are the ASNs?

The report specifically says that cloud networks like VPS, AWS seemed exempt.

Re: The Day the Telnet Died

#363

Earlier quoted context omitted.

Hams use it over packet radio sometimes since encryption is forbidden on the amateur bands. IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.

Most people don't care about FCC rules. I'm breaking a tonne of FCC rules right now.

Yes but in many ways it's riskier to do that when you have a license from them.

Re: The Day the Telnet Died

#364

Earlier quoted context omitted.

If I am rewriting the network stack or making other substantial changes, that defeats the purpose of historical preservation.

If moving it to another port from the OS is beyond the pale for you, your router should implement PAT (port translation) or forwarding, so that from the outside, users could connect on, say, 443 or 2323, and the router rewrites the segments to connect to your immutable port 23/tcp. It makes no sense that IPv6 is treated differently than IPv4. If GNU telnetd is vulnerable and it's running on port 23/tcp, it will be fo…

I meant rewriting it for IPv6 instead of IPv4.

Re: The Day the Telnet Died

#365

Earlier quoted context omitted.

There are many ways from passkeys to SAML. Though for complex methods we may want a dedicated services outside the kernel.

How does that service get launched with the privilege to switch to any user?

The kernel can start a process with any user it wants. The user doesn't have to switch during the process's life.

Re: The Day the Telnet Died

#366
post #182

Earlier quoted context omitted.

I'll admit it is still problematic. But at least there is only 1 gatekeeper instead of 2.

How is that better?

You can focus all of your energy into strengthening and testing a single point of the system instead of having to do it for many.

Re: The Day the Telnet Died

#367

Earlier quoted context omitted.

They're remote terminal applications? Remote interactive text sessions. Over TELetype NETworking? You're saying that connecting my tty (emulator), to a remote host is not the purpose of telnet? Though ... I suppose by now a switch to port 22 could make sense.

No. MUDs should never have adopted port 23 or port 22 or any pre-assigned ports. There is no "well-known port assignment" from IANA for MUD-type games or servers. The end of RFC854, the very last paragraph, states: https://datatracker.ietf.org/doc/html/rfc854 Port Assignment When used for remote user access to service hosts (i.e., remote terminal access) this protocol is assigned server port 23 (27 octal). That is L=…

> A MUD game could never be confused with managing the server where it runs

What do you think of [], highlights: It is extremely tightly integrated with the system. Connections are handled by telnetd, and the interface is basically considered a shell by the system. MUD characters are treated as actual users by the system, with a UNIX username consisting of "m-" followed by the first 5 characters of their selected character name. The database is stored as directories and files, with occasional symlinks.

Any programming or scripting language which is capable of manipulating Mooix's data files can be used to write custom commands, in a similar idea to, say, CGI. Libraries have been created to aid in this for several languages, including Perl, C, Ruby, and bash.

When a character is enabled as a programmer, they basically get the amount of power normally associated with a shell account. They can create and execute files, evaluate perl scripts, and can access a simplified version of a standard UNIX shell, among other benefits. Facilities are provided to edit Mooix scripts or programs (using your favorite editor) from within the MUD, then set them up to be executed when a user types a certain command.

[]https://everything2.com/title/Mooix

Re: The Day the Telnet Died

#368

Earlier quoted context omitted.

They're remote terminal applications? Remote interactive text sessions. Over TELetype NETworking? You're saying that connecting my tty (emulator), to a remote host is not the purpose of telnet? Though ... I suppose by now a switch to port 22 could make sense.

No. MUDs should never have adopted port 23 or port 22 or any pre-assigned ports. There is no "well-known port assignment" from IANA for MUD-type games or servers. The end of RFC854, the very last paragraph, states: https://datatracker.ietf.org/doc/html/rfc854 Port Assignment When used for remote user access to service hosts (i.e., remote terminal access) this protocol is assigned server port 23 (27 octal). That is L=…

The vast majority of MUDs don't even implement the full TELNET protocol, just a small subset. In typical MUD fashion, fundamental TELNET parts like option negotiation were either hacked together -badly- or altogether ignored.

For the longest time in the 90s TELNET AYT would crash tons of custom implementations.

Re: The Day the Telnet Died

#369
post #182

Earlier quoted context omitted.

How is that better?

You can focus all of your energy into strengthening and testing a single point of the system instead of having to do it for many.

You're grasping for straws a bit here. This is already done for ssh as the defacto remote access mechanism for a very long time.

Re: The Day the Telnet Died

#370

Earlier quoted context omitted.

Because I go long periods of time without internet access, and I don't want to have to "sudo apt install" a fucking thing, ever. Especially not a tiny utility that is all of 172k in size, that I might need for something. Understand? I want EVERYTHING that I might use installed AT ALL TIMES, FROM DAY ONE, so that I can IMMEDIATELY USE IT when required. This is only one of many reasons why I abandoned the giant dumpste…

I would never ever install your distro for this reason alone. Someone has already pointed out that old/deprecated/obsolete software like a telnet client represent tech debt. Removing the telnet client was, in part, a recognition that its complementary server was deprecated and unsafe. If everyone was transitioned to ssh and nc, [and custom MUD clients], why keep telnet around? Any software like this represents tech d…

> I would never ever install your distro for this reason alone.

And you are? Completely mystified as to why you'd think I would care. I built this distro for me and my people, not you. That's the whole point. We're getting off this ride.

> Someone has already pointed out that old/deprecated/obsolete software like a telnet client represent tech debt.

Not a subscriber to this religion. There is nothing about new software that inherently makes it safe, and nothing about old software that inherently makes it vulnerable.

New flaws are introduced all the time, and old bugs do get found and fixed.

I can patch old code. I can't guarantee that new code doesn't contain bugs.

The ONLY way to ensure code is flawless is through validation--mathematical proof. When you have devised a proof framework that I can use across my distro, get back to me. At this time you're nowhere near that level, and are therefore unqualified to lecture anyone about security.

> Removing the telnet client was, in part, a recognition that its complementary server was deprecated and unsafe.

Unsafe? On my personal LAN? I think not.

You don't get to just 'deprecate' things that I might need, or want to use for perfectly valid reasons.

That's the entire point of my distro: computing the way I WANT IT, not the way Ubuntu wants it.

> If everyone was transitioned to ssh and nc, [and custom MUD clients], why keep telnet around?

Because it's 172 kilobytes. Contrast with the giant bloated carcass of everything else they shove in there that's oh-so-needed by the herd.

> Any software like this represents tech debt and a support burden for the upstreams and distros which carry them. You have unnecessarily assumed a burden in this way.

I'm a distro maintainer. Hello? Telnet represents ZERO maintenance burden for me. There are no operators standing by on hotlines to "support" any of this. It's a 172 kilobyte utility.

> Furthermore, ask the maintainers of OpenBSD or any hardened OS about attack surfaces. The more software that you cram into the default distribution, the more bundled features an OS or system has, you are multiplying your potential vulnerabilities, your zero-days, and your future CVE/patch updates.

Nobody can magically teleport themselves inside my computer and compromise my telnet client. Nobody is injecting packets into my LAN.

> Especially in the face of growing supply-chain attacks and LLM-automated vulnerability disclosure. Your focus should be on limiting attack surface in every regard.

You're concerned about supply chain attacks, so your mitigation is...doubling down on getting the Latest Updates to everything? Because new code is inherently good.

Telnet has to go--way too risky to keep that around--but KDE/Gnome/systemd/dbus/etc stays?

'traceroute' is useless and dangerous, but let's keep the giant QT framework with its vendored copy of Chromium? (That's QT5 and QT6, each with a vendored Chromium, mind you.)

Chromium, by the way, itself represents tens of gigabytes of code/data now inside its repository, with 'third party' directories vendored three or even four levels deep. But a 72k traceroute utility is likely to be packed with security flaws and should be avoided.

> It is good practice for everyone to uninstall unnecessary apps and software. Whether you use Android, iOS, Mac, Linux, BeOS or Plan9 or Inferno. Do not install and maintain software that you do not use or need. It will come back to bite you.

Completely wrong and misleading theory of security you are proposing here.

I devised this new distro exactly because I was tired of my computing experience being shaped and controlled by clueless kids with intellectually bankrupt arguments and/or wolves in sheeps' clothing.

Post reply on HN