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

41–50 of 414 posts

Re: The Day the Telnet Died

#41

Post by acdha »

ieie3366 wrote: post #23
greyface- wrote: post #17

Earlier quoted context omitted.

https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...

That's crazy. This is core business critical software but they just YOLO critical changes without any automated tests? this PR would be insta-rejected in the small SAAS shop I work at.

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

Re: The Day the Telnet Died

#42

Post by direwolf20 »

RupertSalt wrote: post #20
adolph wrote: post #2

The pattern points toward one or more North American Tier 1 transit providers implementing port 23 filtering

Someone attempted to compromise my home router last week using CHARGEN. Can you imagine!

Attempted to compromise, or just port scanned?

Re: The Day the Telnet Died

#43

Post by dragonfax »

direwolf20 wrote: post #39
charcircuit wrote: post #36

The design of telnet and ssh where you have a daemon running as root is bad security that as shown here is a liability, a ticking time bomb ready to give attackers root.

Literally how else is a remote login daemon supposed to work though?

1. Start with root to bind the port below 1024.

2. give up root because you don't need it any further.

3. Only accept non-root logins

4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.

Re: The Day the Telnet Died

#44

Post by mmooss »

jaredsohn wrote: post #30
trebligdivad wrote: post #24

Why are people still using telnet across the internet in this century? Was this _all_ attack traffic? (OK, I know one ancient talker that uses it - but on a very non-standard port so a port 23 block wouldn't be relevant)

To watch Star Wars in ASCII. telnet towel.blinkenlights.nl https://www.youtube.com/watch?v=Mhcf6tc2jeQ (Remember hearing about this a long time ago (from some searching I think it was in 1999 via Slashdot) and verified some instance of it still exists/works.)

  Connection failed
Maybe we should give the kind person who hosts it a break. Try it out tomorrow. (Yes, I should have thought of that before I tried.)

Re: The Day the Telnet Died

#46

Post by [deleted] »

dragonfax wrote: post #43
direwolf20 wrote: post #39

Earlier quoted context omitted.

Literally how else is a remote login daemon supposed to work though?

1. Start with root to bind the port below 1024. 2. give up root because you don't need it any further. 3. Only accept non-root logins 4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.

[deleted]

Re: The Day the Telnet Died

#47

Post by nine_k »

charcircuit wrote: post #36

The design of telnet and ssh where you have a daemon running as root is bad security that as shown here is a liability, a ticking time bomb ready to give attackers root.

What do you think proper architecture would be, given that ssh needs a capability to let root logins?

I suppose it could be via a proper PAM module, which is widely supported.

Too bad the first PAM RFC was published about the same time the first be version of ssh was released.

Re: The Day the Telnet Died

#48

Post by [deleted] »

dragonfax wrote: post #43
direwolf20 wrote: post #39

Earlier quoted context omitted.

Literally how else is a remote login daemon supposed to work though?

1. Start with root to bind the port below 1024. 2. give up root because you don't need it any further. 3. Only accept non-root logins 4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.

[deleted]

Re: The Day the Telnet Died

#49

Post by saulpw »

jopython wrote: post #45

This is about Telnetd. Not telnet itself.

...except that port 23 seems to now be filtered across the internet at large, leading to a huge drop-off in telnet traffic over the course of days if not hours. I think it's safe to say that even if you patch telnetd, being able to use telnet over the internet is not possible in many places (including Canada, according to the data).

Re: The Day the Telnet Died

#50

Post by acdha »

dragonfax wrote: post #43
direwolf20 wrote: post #39

Earlier quoted context omitted.

Literally how else is a remote login daemon supposed to work though?

1. Start with root to bind the port below 1024. 2. give up root because you don't need it any further. 3. Only accept non-root logins 4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.

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.
Post reply on HN