Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

Post reply on HN
Print view View original

291–300 of 414 posts

Re: The Day the Telnet Died

#291

Post by prmoustache »

1718627440 wrote: post #287
prmoustache wrote: post #278

Earlier quoted context omitted.

Many companies have been preventing its execution or removing the package by default for a number of years. Also most linux containers do not ships with such binaries to save on img size and reduce vuln management overhead.

> to save on img size $ ls --human --size --dereference $(which telnet) 144K /usr/bin/telnet

The point is not that this particular binary is huge, the point is that we tend to strip images of anything that is not useful for the actual application shipped. So we strip everything. Also: small things adds up. On AI prompt can be handled reasonably by a single machine, millions of concurrent ones involve huge datacenters and whole energy plants being restarted/built.

The point of reducing the amount of binaries shipped with the image is also to reduce the amount of CVEs/vulns in your reports that wouldn't be relevant for your app but woulld still be raised by their presence.

Re: The Day the Telnet Died

#292

Post by mystraline »

ErroneousBosh wrote: post #260
iamnothere wrote: post #57

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.

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.

Re: The Day the Telnet Died

#293

Post by RupertSalt »

its_magic wrote: post #204
jmb99 wrote: post #180

Earlier quoted context omitted.

How on god’s green earth is `sudo apt install telnet` sufficiently challenging to be a driving factor to creating your own distro??

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 debt and a support burden for the upstreams and distros which carry them. You have unnecessarily assumed a burden in this way.

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.

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.

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.

Re: The Day the Telnet Died

#294

Post by trashb »

7bit wrote: post #220
oaiey wrote: post #213

Earlier quoted context omitted.

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

Censorship is one of these words that get slapped on anything. Filtering one port is not censorship. Not even close.

> 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.

Re: The Day the Telnet Died

#295

Post by RupertSalt »

da_chicken wrote: post #289
RupertSalt wrote: post #285

Earlier quoted context omitted.

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=…

Boy, wait until I tell you what happened with http!

[flagged]

Re: The Day the Telnet Died

#296

Post by simlevesque »

RupertSalt wrote: post #285
Kim_Bruning wrote: post #280

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=…

I don't understand how playing a MUD doesn't fit the definition of "remote user access to service hosts".

Re: The Day the Telnet Died

#297

Post by PunchyHamster »

RulerOf wrote: post #218
NitpickLawyer wrote: post #216

Earlier quoted context omitted.

> 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…

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.

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

Re: The Day the Telnet Died

#298

Post by VladVladikoff »

josteink wrote: post #222
VladVladikoff wrote: post #161

On the bright side that CVE seems like pretty great news for the hardware hacking community hoping to get root on embedded devices which have open telnetd.

I just tried on a Zyxel Wifi AP I have. It seems to use a different telnetd (busybox?), because from what I can tell it's not prone to this error.

Damn :(

Re: The Day the Telnet Died

#299

Post by PunchyHamster »

gspr wrote: post #217
oaiey wrote: post #213

Earlier quoted context omitted.

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

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.

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

Re: The Day the Telnet Died

#300

Post by RupertSalt »

Quarrel wrote: post #288
RupertSalt wrote: post #279

Earlier quoted context omitted.

I worked for an ISP in the mid-90s and had been on the Internet since 1989 or so. I recall the progression for me was something like this: We used telnet in college no problem. It was a fairly well-accepted method of remote access. The heterogeneous network had many different modes, but a major dialup point was the Annex box, which supported telnet into the Unix or VMS machines. Between Unix machines, we would often…

> /etc/hosts.equiv Ah, the memories. cat '+ +' >> /etc/hosts.equiv

Ah, I have no memory of such a command, so I must be getting old!
Post reply on HN