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

231–240 of 414 posts

Re: The Day the Telnet Died

#231

Post by da_chicken »

gspr wrote: post #228
forty wrote: post #223

Earlier quoted context omitted.

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?

All I'm saying is that the only right place to fix this is at the hospital. Not at the roads leading to it.

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.

Re: The Day the Telnet Died

#232

Post by hibbelig »

prmoustache wrote: post #225
degamad wrote: post #194

Earlier quoted context omitted.

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…

You don't even need netcat or socat for that, probing /dev/tcp/ / from the shell is enough.

Telnet was available in the 90s. I reckon /dev/tcp is way more recent. GP did say a long time ago.

Re: The Day the Telnet Died

#233

Post by _ink_ »

citrin_ru wrote: post #230
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

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.

Probably Tier 1 providers have some insight on this.

Re: The Day the Telnet Died

#234

Post by [deleted] »

NitpickLawyer wrote: post #216
virgulino wrote: post #169

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…

[deleted]

Re: The Day the Telnet Died

#235

Post by anthk »

paulddraper wrote: post #118
tokyobreakfast wrote: post #109

An RCE in GNU's telnetd has no relationship to the sunsetting of telnet. Something could equally likely happen with SSH (but not really because the OpenBSD folks are paranoid by nature). Apple removing the telnet client from OS X was a stupid move. How can you call yourself UNIX and not have a telnet client? It's like removing grep or ed.

There's no UNIX requirement for telnet. Ubuntu does not include it by default (starting 16.04?). Most most distros don't.

Netcat works as a telnet client. GAWK can do that too with a dumb loop. So can con(1) under 9front.

Re: The Day the Telnet Died

#236

Post by tosti »

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.

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.

Re: The Day the Telnet Died

#237

Post by sznio »

citrin_ru wrote: post #230
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

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.

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

Well, maybe not a bank.

Re: The Day the Telnet Died

#238

Post by forty »

gspr wrote: post #228
forty wrote: post #223

Earlier quoted context omitted.

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?

All I'm saying is that the only right place to fix this is at the hospital. Not at the roads leading to it.

There again, I think the comparison fails.

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

Re: The Day the Telnet Died

#240

Post by PhilipRoman »

ajross wrote: post #135
0xbadcafebee wrote: post #88

Earlier quoted context omitted.

Telnet is used in legacy, IoT, embedded, and low-level industrial hardware. It's also intentionally enabled on devices where automation was written for telnet and it wasn't easy to switch to ssh. If you investigate most commercial uses of ssh, the security is disabled or ignored. Nobody verifies host keys, and with automation where hosts cycle, you basically have to disable verification as there's no easy way around…

> Nobody verifies host keys, The known_hosts file is verification of host keys. It's not verification of a host cert, which is a different thing. Most sshd instances are running on ad hoc hardware without the ability to associate them with someone a cert authority would be willing to authenticate. Basically people running services that need cert-based authentication are already using TLS (or if they're using sshd the…

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

Post reply on HN