SSH is the recommended protocol for remote configurations. Still, telnet is being used in many devices. Are there any advantages of telnet over SSH?
Hmm, let's see:
Telnet is simpler (as others have noted already);
Telnet is obviously faster, as the protocol is much more trivial and there is no key exchange and no encryption involved;
Telnet is less vulnerable
Wait, stop, WHAT !?
Well, yes, telnet protocol is plain-text, so you can just sniff the connection and now you know the password and everything else.
And that is a well known fact indeed.
How hard would it be to actually sniff the particular telnet session,
depends on the network setup and a bunch of other things, and might range from being completely trivial to extremely hard to do.
But aside the (obvious) lack of encryption, when it comes to protocol and the service implementation(s) itself, which one is less vulnerable in overall ?
Let's take a look in the CVE database:
Telnet: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=telnet
There were 5 vulnerabilities, registered in 2016,
3 of them are just "hardcoded credentials", which is more of a vendor error than a real service implementation or protocol flaw.
Now, SSH: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ssh
25 (!) vulnerabilities (year 2016), ranging from the "hard-coded" credentials to allowing the selection of low-security encryption algorithms, issues which allow for denial-of-service attacks or reading the private keys from the remote process memory and so on.
So there were obviously many more SSH related vulnerabilities than Telnet vulnerabilities detected in 2016, and Telnet is a winner here.
That is actually pretty logical, taking that SSH is a much more complex protocol, and a typical SSH implementation will have many more features, like X11 forwarding, file transfer, tunnels e.t.c.,requiring a more complex code, and making a much wider "attack surface"
Please take the above with a grain of salt, Telnet is still plain-text
and it is widely regarded as an outdated protocol, so you definitely have to use a decent SSH implementation instead.
Just make sure that it is configured properly (e.g. switch off features you are not going to use), and keep it up to date at all times.
At the same time, you have to remember that sometimes "obvious things" are not always that "obvious", when you look at them at a bit different angle,
and that is the point of this post.
Probably telnet is simpler but it might be historical reasons as well.
Related
These days, I'm really into webRTC technology, and I've been studying webRTC. But, I'm faced with a problem.
I understand that webRTC is using the ICE framework, which has TURN, STUN sever for relay and signaling. But as this article said, webRTC doesn't need a TURN server.
So I'm really curious whether it is possible to connect successfully every time without a TURN sever?
If it is, please tell me the way, and if it isn't, how often are peers using the TURN server in average?
Thank you.
(PS, Azar (one of the biggest apps using webRTC) also said they don't use the TURN sever on their website)
Yes it's possible to connect without a TURN server. Every time? Yes. Everyone? No. Because firewalls.
The Holy Grail of WebRTC is a direct client-to-client network connection without going through an intermediary server (a relay).
TURN is an intermediary server. It's used as a fallback when peers are behind symmetric NATs.
Negotiating this, is the purpose of ICE. There are articles written on how, but in short, "ICE agents" (browsers) collaborate on both ends, communicating through your JS signaling channel, to poke holes from inside the firewall on each end to connect up.
This related answer suggests TURN usage is ~20%.
STUN is not a relay, but merely a mirror server for agents to learn their own external IPs.
WebRTC signalling is driving me crazy. My use-case is quite simple: a bidirectional audio intercom between a kiosk and to a control room webapp. Both computers are on the same network. Neither has internet access, all machines have known static IPs.
Everything I read wants me to use STUN/TURN/ICE servers. The acronyms for this is endless, contributing to my migraine but if this were a standard application, I'd just open a port, tell the other client about it (I can do this via the webapp if I need to) and have the other connect.
Can I do this with WebRTC? Without running a dozen signalling servers?
For the sake of examples, how would you connect a browser running on 192.168.0.101 to one running on 192.168.0.102?
STUN/TURN is different from signaling.
STUN/TURN in WebRTC are used to gather ICE candidates. Signaling is used to transmit between these two PCs the session description (offer and answer).
You can use free STUN server (like stun.l.google.com or stun.services.mozilla.org). There are also free TURN servers, but not too many (these are resource expensive). One is numb.vigenie.ca.
Now there's no signaling server, because these are custom and can be done in many ways. Here's an article that I wrote. I ended up using Stomp now on client side and Spring on server side.
I guess you can tamper with SDP and inject the ICE candidates statically, but you'll still need to exchange SDP (and that's dinamycally generated each session) between these two PCs somehow. Even though, taking into account that the configuration will not change, I guess you can exchange it once (through the means of copy-paste :) ), stored it somewhere and use it every time.
If your end-points have static IPs then you can ignore STUN, TURN and ICE, which are just power-tools to drill holes in firewalls. Most people aren't that lucky.
Due to how WebRTC is structured, end-points do need a way to exchange call setup information (SDP) like media ports and key information ahead of time. How you get that information from A to B and back to A, is entirely up to you ("signaling server" is just a fancy word for this), but most people use something like a web socket server, the tic-tac-toe of client-initiated communication.
I think the simplest way to make this work on a private network without an internet connection is to install a basic web socket server on one of the machines.
As an example I recommend the very simple https://github.com/emannion/webrtc-web-socket which worked on my private network without an internet connection.
Follow the instructions to install the web socket server on e.g. 192.168.1.101, then have both end-points connect to 192.168.0.101:1337 with Chrome or Firefox. Share camera on both ends in the basic demo web UI, and hit Connect and you should be good to go.
If you need to do this entirely without any server, then this answer to a related question at least highlights the information you'd need to send across (in a cut'n'paste demo).
I'm not trying to setup a VPN. I want to secure tcp sessions between services that might be implemented in either user-mode or as kernel daemons. If it weren't for the kernel requirement, TLS would probably suffice.
First target would be Linux; pointers to any example code in user or kernel mode would be dandy if there are any.
All the existing examples I've found are about creating VPNs and use a bunch of static configuration in protected directories, all of which I'd like to avoid. I imagine I'd looking at setsockopt things to define keys before listening and connecting, but have so far found nothing.
VPN will just offer you secure tunnel for your communication also this comes with price of slow connection or overhead. IF you are looking for Ipsec be ware that programatically trying to get a secure and chaning IP itself comes with the same price of large overhead for communication.
It is important to know that what is your specific need. Like if you are not bothered about overhead or extra cost, you can definitely go ahead do IPSec at Network layer. But if you are worried about the performance issues or you want less overhead in your communication SSL/TLS is better for offering you desired security.
I normally use MOBAXterm to SSH into my work pc, but when I use my gf's internet connection, it works for only a little while before giving me the above error message.
It also happens when I ssh into other external machines and it also happens when I use putty. I already implemented all the in-build steps MOBAXterm offers that could potentially fix this problem.
My suspicion is that it's related to the internet connection cutting out temporarily, but I don't see why that should be such an issue.
Any advice would be appreciated.
Two possibilities here, the nefarious and the irritating. If you know how to sniff traffic, a pcap dump of the session dying would be extremely useful. Grab it using the stable version of Wireshark.
The nefarious possibility
Traffic shaping. SSH can be used to tunnel VPN traffic. If the ISP is difficult about it (more likely if they're a big ISP) they could happily send RSTs to long-lived sessions.
The irritating possibility
Sketchy home router. If the NAT table is too full, the router's memory is overloaded, or there's a bug in the firmware, the NAT table could drop sessions which would cause what you describe.
Solutions
Try mosh. It uses SSH for session setup, then its own protocol over UDP for the actual session. It's UDP-based so there's no TCP connection to RST, and mosh is designed to survive a nuclear strike. It doesn't even care if your IP address changes mid session.
The problem is likely to be solved using mosh - even if it's the home router, mosh's session continuity will mask the NAT table resetting.
If you want to replace the home router (for example if the same thing is happening to other protocols), and you can get the authentication details for the Internet connection, try swapping it out for another one - preferably a recent high-end SOHO model.
If the connection presents as Ethernet (for example a cable modem, like Virgin) then my standard known-good is the TP-Link Archer C7.
If the connection is DSL-based (copper phone line, or BT fibre), you'll also want a 1-port VDSL (for fibre) or ADSL/ADSL2+ (for copper) modem capable of bridge mode. You'll need this in addition to the Ethernet router.
For VDSL, I'd probably recommend the ZyXEL VMG1312-B. For ADSL/ADSL2+ I'd suggest the ZyXEL P660-R.
For bypassing filtering in my country, I've rented an abroad server (CentOS 5) with 256 MB of RAM. Client is Ubuntu 12.04. I run this command in client to set up the tunnel:
ssh -CNfD 1080 <user>#<server-ip>
In Firefox settings, I defined a socks proxy server:
localhost:1080
By using this method, everything works properly and I can bypass the limitations. But, the speed degrades reasonably. I don't know why. I guess some reasons and I want to share them with you and have your opinions:
If I use direct connection, most sites use http, but when I use proxy, all sites have to use the secure connection prepared by ssh. My provider may have decreased the speed of secure connections. (I think this may be the matter, but it seems that https sites not using the proxy still open faster.)
Such tunnelling essentially causes the internet speed to decrease. Maybe because of overhead which applies to secure packets or some other reason. If so, what can I replace? I have a working dedicated server.
PS. The server internet connection speed is much higher than the speed (bandwidth) between client and server.
PPS. May I set up an http tunnel? Or use some software instead of ssh to be faster and has less overhead or not to use https?
Please help me figure out what is really happening, since I'm not so familiar with these concepts.
I am afraid there is not much you can do...
Indeed it is to be expected that speed, latency and throughput decrease when you tunnel your payload data through an encryption tunnel. Reason mainly is the overhead of encryption and also, depending on the connection at hand, the modified (longer) routing. You have to take into account that most of the encryption has to be done by your tunnel endpoint, so your server in this case. If that system lacks computation power, then the result will be reduced throughput, obviously. Things like CDN also won't work the same any more.
It might very well be that your service provider throttles different types of connection. Especially in areas with high control and censorship over communication content it clearly makes sense for the authorities to prefer not encrypted payload, so payload that can be controlled and filtered. Everything that keeps people from using encryption is in their interest. So throttling encrypted communication only makes sense from their point of view. Sad, but true nevertheless.
The only thing that could have an impact is some details about your tunnel endpoint, so your server in this case. Increased computation power could reduce an bottle neck if that system shows high load cause by the encryption.
Also it's network connection is of interest, just as your local connection: the encrypted tunnel requires much more control data on the upload side compared to not encrypted traffic. Since typically the upload bandwidth is much lower than for download this could also be an issue.