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?)

Hosted roguelikes have been using ssh for at least 15 years. It's probably time for MUD folks to consider this.

If MUDs and other games were indeed using port 23/tcp for player access, they were not only incorrect but rather dangerous.

Since 23/tcp is a well-known IANA-registered port for the Telnet service, it is an RFC violation to use it for a service that is not telnetd/remote logins via TELNET protocol.

Any port below 1024 signifies that it is a "privileged port". This is an archaic distinction that developed in high-trust R&E networks, but it did signify that the listener on the port had administrative/root access to spawn a service there, so it was kind of a signal that you could "trust" the remote server with your login credentials.

The privileged ports were also priority, because if the unprivileged ones were "first come, first served" for unprivileged users, the administrator would have the ability to enforce the uniqueness of "privileged ports", and disable or kill any process that shouldn't be using one. A MUD Wizard who finds their port in-use (bound) on start is on their own.

Typically there were no MUDs running with, or needing, root privileges. They were run under user accounts, or specific unprivileged role accounts. They had no need of a privileged port, and many were clandestine or unauthorized, and forced to use a higher port number. That's why the 4-digit ports became so popular.

Anyway, the custom has already developed of blocking port 23 to protect users from unwittingly opening a management or login interface. Most shrewd admins would choose a port that isn't routinely blocked and filtered... and port-scanned.

If your favorite MUD runs on port 23 today, such as nethack or something, then I am glad for this change, which will force the administrator to select a unique port that does not imply privilege, TELNET protocol, or shell login credentials. It is totally RFC-compliant to select an unassigned port above 1023, and MUD conventions have popularized several numbers that are still recognizable to players today.

There is some merit to the end user ISPs doing that - for example one I used before filtered SMTP traffic (and iirc some other) to the client unless you opted out from it.

Which was mildly annoying workaround for the power users (disabling it was just changing the ppp login), but stopped a lot of accidentally open open relays and a lot of other cruft

It's not a net-neutrality issue because they're not banking on any alternative.

Net-neutrality law doesn't work like that. Service providers still get to filter stuff.

What's illegal for an ISP is e.g. to give VoIP services other than their own a lower priority. That would tie in customers to use their own service and they could even charge more for it. Net neutrality means a level playing field for services on the Internet.

If you ask your ISP to do filtering, that's perfectly legal. If they filter specific traffic for the purpose of maintaining service, that's okay too.

Now if there was no alternative and they'd try to sell their product by blocking telnet, they could be sued.

Wireguard over 443/udp is also a neat trick. No need to make it look like quic although I wouldn't be surprised if someone takes the effort to make it that stealthy.

If everything was on port 443 why would we even need ports.

The ports are there for a reason, it is idiotic to serve everything over http as you would need a mechanism to distinguish the different flows of traffic anyhow.

These are the institutions I would most expect to do that.

Well, maybe not a bank.

Probably Tier 1 providers have some insight on this.

In the UK we have in fact discovered an alarming weakness in the concrete used to build schools, hospitals and other public building (in one case, the roof of a primary school collapsed without warning). The response was basically "Everybody out now".

https://en.wikipedia.org/wiki/2023_United_Kingdom_reinforced...

https://www.theconstructionindex.co.uk/news/view/raac-crisis...

https://www.theguardian.com/education/2023/aug/31/what-is-ra...

You feel it's similar because having access to port 23 is similarly life critical as having access to an hospital? Or is it because like with ports, when people can't flight to an hospital, they have 65000 other alternative options?

nah, that's like seeing an open gate to nuclear tank - a thing easily fixed within few minutes - and responding to it by removing every road in existence that can bear cars

> censorship, the suppression or removal of writing, artistic work, etc. that are considered obscene, politically unacceptable, or a threat to security

It is not the responsibility of the Tier 1 or the ISP to configure your server securely, it is their responsibility to deliver the message. Therefore it is an overreach to block it because you might be insecure. What is next. They block the traffic to your website because you run PHP?

Similar to how the mailman is obligated to deliver your letter at address 13 even though he personally might be very superstitious and believe by delivering the mail to that address bad things will happen.

It was 1996 for me. I forget where the original SSH (SSH1 protocol) came from, but I do remember compiling it on a Slackware box around that time.

> /etc/hosts.equiv

Ah, the memories.

cat '+ +' >> /etc/hosts.equiv

Because for a long time, on most computers, the telnet client was the closest thing to an "open a tcp socket to this ip/port and connect the i/o from it to stdin/stdout" application you can get without installing something or coding it up yourself.

These days we have netcat/socat and others, but they're not reliably installed, while telnet used to be generally available because telnetting to another machine was more common.

These days, the answer would be to use a netcat variant. In the past, telnet was the best we could be confident would be there.

The telnet protocol with escapes, etc. is only used by the telnet client if you’re connecting to the telnet port. If you’re connecting to HTTP, SMTP or something else, the telnet protocol is not enabled.

Same reason that people use vi. It's always there.

Because it's there.

In the days of yore, Windows had telnet installed. Most hackers used telnet in the 90's and early 2000's.

You can program without tools? I want to see that. Do you still have switches to alter RAM content, or do you use the butterfly method?

who's hand rolling code anymore these days though?

SMTP has and is almost blocked everywhere to dissuade spam.

It's... not super clear from the article whether this is a port block or a stateful protocol thing. But yes, you're probably right and SMTP spoofing is probably safe for now.

It might be the telnet filtering in action. The host responds to ping but I get nothing back on TCP/23, not even a reset.

I connected a few times today to the IPv4 one. Have had no problems myself.

The manufacturer should at least supply certificates, and it could be up to you to ignore or use. It's not much but it's something.

CA compromise is very rare and difficult. There are much easier attacks on TLS than that (notably, attacking insecure validation methods; the problem isn't that CAs aren't secure, it's that validation methods and their dependencies are insecure). Besides, the CAs for TLS only covers transport security; authentication+authorization would be handled securely through OIDC, using temporary sessions and not exposing the true credential, often combined with 2FA. Even you successfully attack a TLS server, two factors, and an active session, it only works once; you have to keep pulling it off to remain inside.

Compare that to malware that just copies a developer's ssh private key off the disk (again, almost nobody ever password protects theirs). This just happened recently on a massive scale with the npm attacks. Or intercepts the first connection from a client host and, again, because nobody ever validates keys, injects a false host key, and now they're pwnd indefinitely. Or, again, companies that do not strictly validate host keys, meaning immediate MitM. There's like a dozen ways to compromise SSH. It doesn't have to be that way, but it is that way, because of how people use it.

SSH certs aren't TLS certs. Totally different format. All SSH CAs are private, you run your own CA to issue certs to devices you want to allow to connect to your server.

>>Nobody verifies host keys,

>The known_hosts file is verification of host keys

I think the point was that those devices typically generate host keys dynamically and therefore the host key verification is usually turned off, leaving you just with encryption (which is still better than telnet - at least you're safe against passive adversaries). At least that's what I've seen in practice.

TIL that IPsec can be used without encryption. That should work pretty well.

Telnet is mostly used for auth and straightforward terminal/BBS access in my experience. There are some other alternatives like HamSSH but I don’t think it’s that common.

In general, this is pretty true in practice.

Just dont mess with: GPS, Airline radio, cell phones, broadcast infra, emergency services

If you're blowing double the power for ISM, nobody cares. Your PEP using a yagi is 4x what is legal? Unless you piss off a ham, nobody cares.

And even if you are a ham, and are using 150KHz bandwidth with low power in, say 50MHz (regulation says 40KHz max), again, nobody cares.

And also if above 6GHz (common SDR top end), nobody will notice. The equipment up there is $$$$$.

But damn, you want to piss off hams? Mention bitrate maximums or encryption. You'll never hear the end from the old gatekeeping idiots.

For a few weeks I ran a MUD over AX.25 for a couple of my friends.

Because on their own, MUDs aren't nerdy enough, amateur radio isn't nerdy enough, and indeed packet radio isn't nerdy enough.

Eventually we decided we'd had our fun and now I needed to the TNC for something else.

TBH, I don’t care if someone drop all my inventory and delete my account. If I would care about it then I would obviously not use telnet.

Ah, not really. We are on a non-standard port (9000). I just meant some folks use the telnet client to connect, and we do negotiate some telnet options. I use tintin++ these days but I think most of our players are still using decades old zMUD versions to connect!

Or with telnet (the client)

Yes, perhaps we should define “MUD” and your incomplete experience of “most”.

As a MUD enthusiast for 37 years, I learned to program in C and Unix through TinyMUD, MUCK, and MUSH derived servers. From the beginning, none of these codebases implemted Telnet. There was nothing but a raw transparent TCP connection. In fact, I facilitated the introduction of a grand innovation: the "port concentrator" system which multiplexed TCP connections. Unix processes had a hard rlimit of 64 file descriptors, which crimped our style as an emerging MMORPG. The multiplexer increased this to 4096, for the biggest games of the era.

You mention MUSHclient, and I do not know about later revisions of the TinyMUSH server, but I can assure you that every MUSH I found from Larry Foard on, was not implementing Telnet. (I was privileged to help Larry "test" new features as I red-teamed his server with bizarre edge cases!)

Likewise, after I handed off TinyMUCK 2.3 to the furries, it was not doing the Telnet protocol. When we backported stuff to MUCK 1.x, it was not doing Telnet. I wrote a bonkers Perl program to read MUCK databases and sort of implement the game. No Telnet there. I've got to wonder whether the Ubermud or MOO guys had folded it in; they were close collaborators with us, back in the day.

Now as for the Diku, LP, and other “combat” type games, I’ve no idea. Perhaps they did. We never cared. I was aware that some of them had a pesky “prompt” that violated the line-mode assumptions of conventional clients and needed workarounds.

telnet(1), the program, was historically the only program that implemented the protocol. If you use Tinyfugue or Tinywar or tinymud.el, they are not, and no, I am not confused, because I was giving an example of why the Telnet-implementation, the program, the client, was so inadequate for playing on MUD servers.

It wouldn’t have been difficult to retrofit the Telnet RFC 854 into any MUD server, but none of us wizards had any use for it, seeing that our clients were mature and capable of much more processing without it.

If modern MUD servers have mostly implemented Telnet, then that is cool, but what surprises me is that it is mandatory, and your clients don’t seem to interoperate without it? That is a strange reversal!

I have a hard time thinking it’s popular enough these days that attacks, attempts at attacks, or just command and control couldn’t be the main use.

Culture has changed a lot since the 20th century and older projects can have antiquated norms around things like testing. I was just listening to a recent podcast talking about how worrisome it is that OpenSSL has a casual culture about testing[1] and was reminded about how normal that used to be. I think in the case of telnetd you also have the problem that it’s been deprecated for multiple decades so I’d bet that they struggle even more than average to find maintainer time.

1. https://securitycryptographywhatever.com/2026/02/01/python-c...

Even with automated tests you'd need to think of this exploit right? Perhaps fuzzing would have got it. The mailing lists says they proved it successful on

- OpenIndiana

- FreeBSD

- Debian GNU/Linux

So not complete YOLO.

See https://lists.gnu.org/archive/html/bug-inetutils/2015-03/msg...

FWIW, a well known LLM agent, when I asked for a review of the patch, did suggest it was dodgy but didn't pick up the severity of how dodgy it was.

If you think you can do better you're welcome to do better. I say this without a hint of sarcasm. This is how open source works. It's a do–ocracy, not a democracy. Whoever makes a telnet server gets to decide how the telnet server works and how much testing it gets before release.

Any business that has a telnet daemon able to be reached by an unauthenticated user is negligent. Just the fact that everything is in the clear is reason enough to never use it outside of protected networks.

Most 90’s era software had zero tests. Nobody gave it a second thought.

There's a famous XKCD about this: https://xkcd.com/2347/

In this case the hero's name is apparently Simon Josefsson (maintainer).

https://xkcd.com/2347/

Ah, someone beat me to it!

It can't be critical business software if the business to which it is critical isn't paying anything for it.

/s

It is wrong. The author is known, was acting in good faith, and simply fucked up really badly.

I don't know what 11 years ago has to do with anything, besides the awful lifespan of such a severe bug.

> GNU organization

> giant security flaw

Checks out.

Or Notepad, for a change!

The rest of it seems to be substantially edited by an LLM too, or at least it's composed much like LLM outputs often are these days: “not a gradual decline, not scanner attrition, not a data pipeline problem, but a step function.”

"Not X, not Y, not Z" is a common LLM tic, and there's a few more like it in there.

It's a joke and a poke that macOS isn't certified UNIX as shipped.

There are many things I want to say in reply to this. So I’ll bullet point them:

* yes, do not buy equipment that has acquired so much tech debt that it still requires telnet.

* there are a million telnet clients out in the world. And ones far better than the default OS one. Apple not shipping one standard is not the end of the world or really anything more than a mild inconvenience for the small handful of people who need actual “Telnet” as opposed to Netcat or socat, both of which are far better than base Telnet.

You can have it, it’s not on the base install.

99% of Mac users never use it, directly or indirectly. Asking that they have it anyway is a self centric view.

Ubuntu and derivates removing telnet from the default install, along with other basic tools like traceroute etc, was one of the driving factors toward me creating my own distro. I'm sick of basic stuff being omitted because somebody just decided it's not needed anymore.

Using netcat results in showing Unicode replacement symbols, instead of answering to telnet options. I doubt it implements telnet at all, because this is just not its job.

How does SSH become an arbitrary user without effective root?

You are thinking 20 years ahead. In 1995 most servers were still pets, not cattle.

That still needs a way to change users, and OpenSSH already has privilege separation. That hardens the process somewhat to reduce the amount of code running in the process which can change the uid for a session but fundamentally something needs permission to call setuid() or the equivalent.

Congratulations, you've created a server that lets people have shells running as the user running telnetd.

You presumably want them to run as any (non root) user. The capability you need for that, to impersonate arbitrary (non-root) users on the system, is pretty damn close to being root.

You still need to have privileges to become the userid of the user logging in. Openssh does do privsep, but you still need a privileged daemon.

I'm not sure that you need root because of the port - I think login itself needs to run as root, otherwise it cant login to anything other than the account its running under.

Those are already unprivileged operations, but how does it start the initial process in that terminal with the correct privileges for a different user?

Any breach of the daemon will still give access to a system that can approve/deny user logins. Breaching the daemon therefore allows permission escalation, because you can simply jump to an account. Chain with any local vuln of your choice to completely own the box.

It doesn't matter what user it is running as.

If this was so easy to deal with, someone would have done it. Instead, we get endless HN comments about people that act like they can do better but never submit a PR.

Also, one of the authors is "Orbie", which looks like an AI name, and if you go and read through some of the recent posts, all of the posts with that author feel very LLM-y and bland, and the posts without that author are much more normal.

GGP has a good eye.

Good call-out! Yes, while the router labels it as "DOS Attack" it is probably a simple port-scan!

However, anyone who knows the nature of CHARGEN would recognize that a singular successful connection could immediately blossom into a somewhat lackluster DDOS, as the chargen service risked consuming CPU and network resources unnecessarily.

chargen has been also aggressively deprecated, far more than telnetd, since it was a non-essential service. I'd like to know how many servers are voluntarily running chargen on the public Internet today.

A port-scan for chargen is more likely a comprehensive port-scan that is just attempting to identify and fingerprint anything that may have been established on that port. It would be less surprising to find, like, ssh or a web server occupying that space today.

You comment reads very AI generated. From the, it's not X it's y, to the overdramatization of completely normal events (i.e. key infrastructure providers are notified of CVEs before they are disclosed so impact is minimized)

because it reads like claude output?

and also the pattern:

> The most interesting thing here isn't the CVE… This is what mature security…

> The most interesting finding isn't that hyperbolic growth… This is Kuhnian paradigm…

both comments in the last 24h