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.
> Tier 1 transit providers doing port filtering is EXTREMELY alarming.
I was admining a small ISP when blaster and its variants hit. Port filtering 139 and the rest was the easiest way to deal with it, and almost over night most of the ISPs blocked it, and we were better for it. There was a time when if you'd put a fresh XP install on the Internet you'd get 5-10 minutes until it would get restarted.
I guess if you're really an admin that needs telnet, you can move it to another port and go around it? Surely you'd tunnel that "old box that needs to stay alive" if that's the usecase? Is there anyone seriously running default telnet on 23 and is really affected by this filtering?
Lots of text games - MUDs - still play over telnet using dedicated MUD clients that implement their own telnet stack. Outright blocking the port has an outsized side efffe on them, this is simply not right.
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.
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:
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=23.
I would say that by the letter of the law, and by longstanding convention, that port 23/tcp is given to telnetd type login servers. A server listening on port 23 is expected to accept login credentials and furnish a shell or some management interface that affects the host itself. That someone would log in as a terminal user and perform computing tasks.
A MUD game could never be confused with managing the server where it runs, or a user/admin login to access that operating system. A MUD game has a specific purpose of recreation/leisure/communication.
Again, let us not conflate port 23 with telnetd with the TELNET protocol. These are all completely separate and distinct. Except that port 23/tcp implies TELNET protocol and also implies a telnetd-type server. It is sort of a one-way chain of requirement. telnetd could be run on any port (inadvisable) while TELNET protocol could be implemented by any other service (often preferable).
A MUD server is perfectly entitled to use TELNET protocol! In my server-hacking days, I often considered it a mistake and error not to support TELNET protocol! If I had known how to implement it, I would've added it to TinyMUCK myself! Honestly, it was not a priority because there was no known client supporting TELNET, either. Of course, protocol support needs to be on both ends to be effective. Without demand or capability from clients, it didn't really make sense for server programmers to add it in.
But we were perfectly content to stay on port 2283, port 4201, or port 6250, as our players and Wizards had established the games to run there, especially in those days we wished to escape notice by admins. The TELNET protocol can run on any port and support any "network virtual terminal" service. But the "telnet port" on 23 is special, unique, and as of last month, really inadvisable for everyone.
> 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.
It is a horse of a different color when user logins are handled by telnetd itself. I would imagine that access could also be provided by ssh. I know of no MUD that supports MFA, public/private keys, and host certificates!
At any rate, as of January 2026, Mooix users are gonna have a tough time connecting on port 23/tcp. I won't say they've been wrong for using it until now, but they may find themselves forced to switch to ssh, or at least a 4-digit port number. And patch that GNU telnetd ASAP, man.
EDIT: Sad to say, please do not visit the website cited in this linked article. It is, how you say, squatted by purveyors of smut. It may be the case that Mooix is abandonware.
> by longstanding convention, that port 23/tcp is given to telnetd type login servers
First thing I ever telnetted to was Melvyl, University of California's library catalogue, around 1985. This was “remote user access” (I was a remote user) to “service hosts” (running the catalogue) providing “remote terminal access”. It was not a login.
I remember using MELVYL too, and you're completely right about that.
I would suggest that MELVYL on port 23/tcp was also unnecessarily impinging on the IETF standards. MELVYL could have easily established its own well-known port with the IANA and not conflicted with the TELNET login port.
Before the WWW, there were a multiplicity of search services and indexes. Remember Archie, WAIS, and Gopher? Apparently, WAIS was assigned port 210/tcp, but Archie apparently used TELNET on 23/tcp as well.
I think some of the pioneering Internet services were perceived as not requiring a dedicated port. If MELVYL was the only service running on the mainframe and it wasn't running a Unix telnetd, then why not usurp 23/tcp? The admins there probably perceived it as a virtual "octopus cable" connecting remote "terminal labs", and for sure they had alternate methods of access for OS servicing and configuration purposes. In the beginning of MELVYL they were undecided about which protocol would prevail, and TCP/IP was competing with others, so port numbers may have been afterthoughts for the architects.
The most important thing may have been the principle of not surprising users or confusing them with parameters. "telnetting to a host" was way easier without trying to specify that they needed a port number. Just ask any Unix admin where MUD users try to bang on their telnetd port trying to play the game...
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.
Their replies are only obtuse because you fail to see that you’re being made fun of for having such a ridiculous pedantic position about this. “Terminal” does not mean shell when you read the Telnet RFC. It means TTY. A human to machine interface. MUDs implement the Telnet protocol and provide a remote TTY. What’s running on the terminal is absolutely irrelevant.
Can you show the exact line in the RFC or IANA port reservations that says it has to implement a shell login interface with the Telnet protocol if it’s on port 23? Because I can’t find it. Nothing says that anywhere.
I literally already did. And it is not merely the RFC which specifies it. The RFC defines the protocol and really leaves it open-ended for any sort of implementation.
What defines port 23/tcp is the longstanding usage and the original understanding of a "remote terminal" or NVT. In 1983 when the IETF described the NVT, it was simply understood that a terminal, or "canonical console", was a method to access a timesharing system and log in as a user. If you went to a "terminal lab" or you sat down at a desk with a "terminal" or "teletype" or any of its predecessors, you were preparing to log in and do some programming or data processing.
There were literally no terminal labs where you would sit down and begin playing Centipede, Asteroids, or PONG. Those were completely different concepts of "consoles" and "cabinets" and the IETF did not stutter when they defined an NVT.
Every Unix implementation, every router and network device, practically anything with an Internet connection implemented a "shell" login on port 23 or it did not. There were plenty of systems with /usr/games and a plethora of leisure-time activities, but surprisingly they did not default to using port 23/tcp. It has been long-standing tradition, and convention, that the TELNETD service operating on 23/tcp is what a user expects to find when they connect.
MUD admins and wizards who put their servers on 23/tcp necessarily needed another way to log in and manage their server. I am surprised that they were so easily able to usurp telnetd if this was the status quo. Was sshd already established for them or something? Did they just resort to rlogin instead? I'm genuinely clueless and curious how it was so easy to usurp 23/tcp and use it for MUDs.
Because my community often ran them clandestinely, and we always ran them unprivileged, so there would literally be no way for the server to start on port <1024 -- it never ever had root access! If your MUD ran on port 23, that's dangerous because at some point, somewhere, some time, it enjoyed root access, and hopefully dropped that UID 0 immediately after the bind()!
> I would say that by the letter of the law, and by longstanding convention,
Those are two different things, and you're confusing or conflating them.
"By the letter of the law", certainly if we're just talking about RFC 854, there's no mention of shells, or some of the other constraints you're projecting onto it.
"Remote user access to service hosts (i.e., remote terminal access)" is perfectly consistent with someone accessing a MUD.
When it comes to convention, though, which is influenced by pragmatic issues such as security constraints, you have more of a case.
> 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.
If something is running on a privileged port is not enough to trust it. Firstly you need to trust to a host, you need to know where are you connecting to. If you connect to a random host with a privileged port and pass it your credentials you are doing stupid things.
This thing with privileged ports is protecting you from users who could run arbitrary code on a server. From them and not from anyone else. So for MUD there is a lot of reasons to run on 23 port, it is a signal for users of MUD that they are connecting to a process hat was started by the owner of the machine having the root.
> 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.
If I was running a MUD, I would find some way to get around. I could use 22 for example, though it could cause me problems with logging in with ssh. But it is not an issue really, there are 1k privileged ports, I could choose one from them.
The GP's concern isn't a practical one, it's ultimately about net neutrality. It's not the ISP's job to discriminate against traffic—it's their job to deliver it.
This may seem like a good idea, and frankly is likely a net-positive thing, but it is literally the definition of "ISP decides what apps its customers can and cannot use."
I share the concern and don't really like it either.
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.
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
I run a PDP-10 during the colder parts of the year. It's for historical preservation reasons. There are others doing the same thing. We still offer telnet access because that's how it worked back then. I guess we aren't going to be doing that anymore.
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 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?
Changes like these lend even more credibility to the approach of putting everything on port 443 over TLS, and distinguishing protocols based on hostname / HTTP path.
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.
Preventing the traffic from being distinguished is the whole premise. Port 23 gets blocked because everyone uses it for telnet, and everyone expects bad actors to know that. If everything moves to 433, we'll end up with a variety of routing systems and no focal point for attack. The only alternative is to disallow port filtering in core internet infrastructure.
We can either have a standard and accept that bad actors will use it against us, or we can accept the chaos that results from abandoning it.
> The only alternative is to disallow port filtering in core internet infrastructure
I think this is an acceptable alternative. In the same way that your mail service is legally required to deliver your mail as part of their universal service obligation (without reading it).
You've got it wrong. It doesn't have to be HTTP[S] traffic.
Reverse proxies can disambiguate based on the SNI. I could run telnetd on port 23, but have port 23 firewalled off, and have my reverse proxy listening on port 443 with TLS forward anything going to telnet.mydomain.com to telnetd. Obviously, my client would need to support that, but a client-side proxy could easily handle that just as well.
Yes you can run any service on any port. But tunneling telnet over another protocol seems like you would just move the problem. I don't know too much about SNI but if "Reverse proxies can disambiguate based on the SNI" wouldn't your network service provider also be able to filter based on SNI?
You would need to agree on a protocol and you would gain all the advantages but also the disadvantages of the tunneling protocol.
> wouldn't your network service provider also be able to filter based on SNI?
Two things:
1. Only if they knew that the hostname in question is indeed being used for telnet tunneling. You can set that host name to whatever you want.
2. Encrypted SNI is a thing.
> You would need to agree on a protocol and you would gain all the advantages but also the disadvantages of the tunneling protocol.
Yeah, admittedly the entire thing is a bit contrived. If your client is capable of speaking the tunneling protocol, then likely you'd just use the tunneling protocol itself, rather than using it to tunnel telnet.
Protocol multiplexing/demultiplexing is a feature of software like sslh, nginx, and HAProxy exist, and they don't need to listen on multiple ports to speak multiple protocols or connect multiple services. Many advanced reverse proxies can do this with stream sniffing of some flavor.
People already do actually run everything through port 443 simultaneously.
Protocol multiplexing exists. But you will have to agree on a single protocol, which I view as impossible since different applications have different requirements.
If you route all your traffic through https that comes with all the upsides, for example the security layer (ssl). But also the downsides of for example overhead of headers. Currently we have an overarching (network layer) protocol, it is called IP. It divides the traffic into different ports at the host, these ports speak different protocols. If you move the multiplexing higher up the OSI stack, you are violating the principles of separation and making your stack less flexible, you are mixing OSI layers 4: transport up to 6: Presentation. Conflicting these layers can lead to big problems as this includes things like the Transport layer, for example the difference between udp/tcp is included there.
The beauty of the network stack is that there are certain layers that separate responsibility. This allows the stack to apply to wildly different scenarios. However I do agree that there should be no filtering applied on behalf of the customers.
> Protocol multiplexing exists. But you will have to agree on a single protocol
I may be misunderstanding your message here, but the requirement to agree on a single protocol isn't true when you're using multiplexing. I think you're confusing tunneling with multiplexing.
With multiplexing, you have multiple protocols listening on a single port. The multiplexer server sniffs the first few bytes of what the client sends to determine what protocol is being used, then decides which back-end to forward the connection to.
Neither the client nor the final back-end need to be aware that multiplexing is happening, and likely aren't.
Through this, you can use both HTTPS and Telnet on port 443 without the Telnet client needing to have any changes done.
I do not know what is more critical: the risk of censorship or stand by while hospitals, banking, nuclear power plants and other systems become compromised and go down with people dying because of it. These decision makers not only have powers but also have a responsibility
Have you ever seen a hospital, a bank, a power plan to expose telnetd to the public internet in the last 20 years? It should be extremely rare and should be addressed by company’s IT not by ISPs.
This feels more akin to discovering an alarming weakness in the concrete used to build those hospitals, banks and nuclear power plants – and society responding by grounding all flights to make sure people can't get to, and thus overstress, the floors of those hospitals, banks and nuclear power plants.
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".
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?
That's my question. Why is there infrastructure that has open access to port 23 on the Internet. That shouldn't be a problem that the service provider has to solve, but it should absolutely be illegal for whomever is in charge of managing the service or providing equipment to the people managing the service. That is like selling a car without seatbelts.
We are beyond the point where not putting infrastructure equipment behind a firewall should result in a fine. It's beyond the point that this is negligence.
Fixing the hospital: single place to work on, easier
Blocking all the roads/flights: everywhere, harder
Vs
Fixing all the telnet: everywhere, harder/impossible
Blocking port 23 on an infra provider: single place, easier
It makes sense to me to favor the realistic solution that actually works vs the unrealistic one which is guaranteed not fix the issue, especially when it's much easier to implement
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.
Port 23 has been filtered by most providers for decades.
This is why everything converges on using TLS over 443 or a high port number. I don't see this as a huge deal, and especially not one deserving all caps rants about censorship. Save those for things like FOSTA/SESTA.
not to mention, filtering on udp vs tcp, which makes using anything else impossible. Not that I have one, but it's just a bit in a field, why filter on it?
