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)
(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)
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
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 the host keys constantly changing. Without host key verification, there's kinda no point to the rest.
Even assuming the host keys were verified, the popular ssh conventions are to use either long-lived static keys (and almost nobody puts a password on theirs), or a password. Very few people use SSH with 2FA, and almost no-one uses ephemeral keys (OIDC) or certificates (which many people screw up).
So in terms of how people actually use it, SSH is one of the least secure transport methods. You'd be much more secure by using telnet over an HTTPS websocket with OAuth for login.
The problem with IoT and embedded secrets isn't really a solved problem, from what I can tell. I'm not sure that OAuth exactly solves the problem here. Though all your comments about SSH (especially host verification) holds true.
Just honestly trying to understand the possible solution space to the IoT problem and automated (non-human) authorization.
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 they've locked it down appropriately). SSH is for your workstation and your RPi and whatnot.
The point is that a "private" cert is not a "cert" as commonly understood. The important part to a certification authority is the AUTHORITY part, not the data format. Either there is a trusted third party that will promise you are who you say you are, or there is not. With SSH, there is not, nor can there be as it is commonly deployed.
So applications that want that have used other protocols and other schemes, very productively.
>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.
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168...
PCI DSS, HIPAA, and ISO 27001 each either highly recommend or enforce this.
I wouldn't use a jumphost without it.
I'd say that HTTPS (or TLS in general) is more problematic, since you need to trust numerous root CAs in machine/browser store. Sure, you can use certificate pinning, but that has the same issues as SSH host key verification.
Compare that to malware that just copies a developer's ssh private key off the disk (again, almost nobody ever password protects theirs). This just happened recently on a massive scale with the npm attacks. Or intercepts the first connection from a client host and, again, because nobody ever validates keys, injects a false host key, and now they're pwnd indefinitely. Or, again, companies that do not strictly validate host keys, meaning immediate MitM. There's like a dozen ways to compromise SSH. It doesn't have to be that way, but it is that way, because of how people use it.
IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.
I know from bitter experience that IPsec is a “now you have two problems” kind of solution, but the Authentication Header is a thing and is supported by most (all?) implementations. Ham radio operators probably don’t have much use for the actual features of telnet compared to plain netcat, do they? (It’s mostly terminal feature negotiation and such.)
Telnet is mostly used for auth and straightforward terminal/BBS access in my experience. There are some other alternatives like HamSSH but I don’t think it’s that common.
Telnet, on the other hand, is quite a bit fancier than that and has a fairly involved feature negotiation mechanism for terminal connections that is not entirely in line with the prevalent DEC tradition. As admittedly one of the funkiest examples of what you can do with it, there is for instance a mode[1] where the client is asked to emulate a terminal of the IBM 3270 lineage. (To a practicioner of the aforementioned DEC tradition, those feel like the marsupials of terminals: everything is functionally there, but primitive and derived are occasionally flipped and some features are oddly weak or misdesigned due to a lack of competition.) So if you do actually use Telnet the protocol, by all means, I’ll be delighted to learn what you do with it (partly why I asked in the first place). But if you just need a pipe, then TCP is enough, and netcat or socat make fine ad-hoc clients.
I'm breaking a tonne of FCC rules right now.
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.
So much gatekeeping.
Incidentally, I have it Word From On High within Ofcom here in the UK that you literally cannot pay them to take an interest in what happens on the amateur bands.
There's "breaking the law" and there's "being a bit rude", the latter of which might be things like "hey let's do fastscan TV on 70cm and use about half the allocation!" You do have to watch with 70cm in the UK though because amateur radio is a secondary user, with primary users being the armed forces. But it's 10MHz wide and there's space for everyone to play.
Putting the 70cm packet BBS channel 5kHz above where all the car alarm keyfobs work was a bit silly though.
As regards microwave stuff, I've got some scrap 26GHz stuff at work that can apparently be tuned to 24GHz by swapping the cavity tuning screw for one of the slightly longer ODU outer cover screws, and tweaking a setting in the EEPROM in Factory Never Touch This Shit mode. Want to bet they had radio amateurs working for them?
I really should update it to allow more secure options
Not anymore ;)
Seriously though: did you notice any spikes up or down?
If you'd run it on a non-standard port, anyone can still connect with netcat, socat, etc etc.
How can I get access?
Pretty slow these days, hack 'n slash style game
All of that was foundational for my career and I still look back fondly on the technology of the time, which tended to be fairly "open" to exploration by curious-minded teenagers.
Because on their own, MUDs aren't nerdy enough, amateur radio isn't nerdy enough, and indeed packet radio isn't nerdy enough.
Eventually we decided we'd had our fun and now I needed to the TNC for something else.
The problem is the auth is plain text too and you're open to having your credentials stolen.
telnet doom.w-graj.net 666