[Twisol]

> Someone upstream of a significant chunk of the internet’s transit infrastructure apparently decided telnet traffic isn’t worth carrying anymore. That’s probably the right call.

Does this impact traffic for MUDs at all? I know several MUDs operate on nonstandard Telnet ports, but many still allow connection on port 23. Does this block end-to-end Telnet traffic, or does it only block attempts to access Telnet services on the backbone relays themselves?

[RupertSalt]

Most MUDs do not use Telnet.

MUDs use plaintext TCP protocols that are accessible to a wide range of clients.

The Telnet protocol is well-defined and not completely plaintext. There are in-band signaling methods and negotiations. Telnet is defined to live on 23/tcp as an IANA well-known, privileged, reserved port.

MUDs do none of this. You can usually connect to a MUD using a Telnet client, but most players hate the experience and often deride this method in favor of a dedicated, programmable client.

The fact that MUDs inhabit higher 4-digit ports is an artifact from their beginnings as unprivileged, user-run servers without a standardized protocol or an assigned “well-known port” presence. If you want your MUD to be particularly inaccessible, you could certainly run on port 23 now!

[Twisol]

As a MUD enthusiast of two decades, this is not accurate. Where are you getting this information?

Most MUDs implement RFC 854, and a number of non-standard Telnet option subnegotiation protocols have been adopted for compression (MCCP2), transmission of unrendered data (ATCP, GMCP, ZMP), and even a mechanism for enabling marking up the normal content using XML-style tags (MXP). These telopts build on the subnegotiation facility in standard Telnet, whose designers knew that the base protocol would be insufficient for many needs; there are a great number of IANA-controlled and standardized telopt codes that demonstrate this, and the MUD community has developed extensions using that same mechanism.

> You can usually connect to a MUD using a Telnet client, but most players hate the experience and often deride this method in favor of a dedicated, programmable client.

I think you are confusing "telnet" the program with "telnet" the protocol. I am speaking here of the protocol, defined at base in RFC 854, for which "telnet" the program is but one particularly common implementation. You look at any of those "dedicated, programmable clients" and they will contain an implementation of RFC 854, probably also an implementation of RFC 1143 (which nails down the rules of subnegotiation in order to prevent negotiation loops), and an implementation of the RFCs for several standard telopts as well as non-standardized MUD community telopts. I can speak for the behavior of MUSHclient in especial regard here, though I am also familiar with the underlying Telnet nature of Mudlet, ZMud, and CMUD, not to mention my very own custom-made prototype client for which I very much needed to implement Telnet as described above.

[breve]

> MUDs do none of this.

MOOs do.

[MBCook]

It wasn’t clear from the article but I assumed they were filtering for the attack specifically.

Since Telnet is totally plain text that would absolutely be easy to do right?

[Mixtape]

Wouldn't that imply that >80% of all monitored telnet sessions were exploit attempts for the specific CVE in question? Even with the scale of modern botnets, that seems unrealistic for a single vuln that was undisclosed at the time.

[wbl]

Not at interconnect speeds

[Laforet]

It seems like they are doing a port based block similar to how residential lines often have their SMTP ports shut off.

That said in this day and age, servers on the public network really ought to use SSH.