What's the problem that SSH tunneling is trying to solve?
12 comments
You could ask similar questions about all the layers. Why is any of this needed at all?
Direct SSH connections from Internet-based clients to target hosts could be secured in principle if you believe in your SSH key management (perhaps even using some MFA strategy). An SSH tunnel is pretty analogous to an authenticated web or SOCKS proxy. You usually use such a thing to selectively work around firewall or routing obstacles, or to inject yet another layer of authn+authz+audit for different traffic classes.
So, working bottom-up, you can probably interpret your company's layer cake as:
- Presumably you are using SSH because it is the native protocol for your actual target systems' OS.
- Having a proxy tunnel for SSH helps when target hosts are in otherwise non-routed subnets.
- They believe in a virtual desktop strategy as a way to avoid trust in end-user client systems.
- They use RDP over VPN because they don't trust RDP over the Internet.
Different schools of thought will see some or all of these layers as necessary best practice or as delusional cargo culting.
As native user of SSH for almost 30 years, I think the whole virtual desktop approach is a travesty. I would not want to have any SSH credentials being stored in a virtual PC outside my physical control. But I know I am not going to convince a typical CIO of that.
Direct SSH connections from Internet-based clients to target hosts could be secured in principle if you believe in your SSH key management (perhaps even using some MFA strategy). An SSH tunnel is pretty analogous to an authenticated web or SOCKS proxy. You usually use such a thing to selectively work around firewall or routing obstacles, or to inject yet another layer of authn+authz+audit for different traffic classes.
So, working bottom-up, you can probably interpret your company's layer cake as:
- Presumably you are using SSH because it is the native protocol for your actual target systems' OS.
- Having a proxy tunnel for SSH helps when target hosts are in otherwise non-routed subnets.
- They believe in a virtual desktop strategy as a way to avoid trust in end-user client systems.
- They use RDP over VPN because they don't trust RDP over the Internet.
Different schools of thought will see some or all of these layers as necessary best practice or as delusional cargo culting.
As native user of SSH for almost 30 years, I think the whole virtual desktop approach is a travesty. I would not want to have any SSH credentials being stored in a virtual PC outside my physical control. But I know I am not going to convince a typical CIO of that.
Filtering by IP is not generally safe enough: any node on the network can broadcast IP packets with any IP in the headers. While it might not be easy for any node to pick up traffic destined for a particular IP (depending on the network topology), adding encryption can certainly stop it completely.
A tunnel is a simple way to forward any TCP/IP traffic securely between two nodes. If you've got secure entry into a network, tunnel between nodes on that network ensures no eavesdropping or impersonation from another node on that network.
Also note that SSH came before VPNs :) You can also bridge two networks over ssh with things like sshuttle.
A tunnel is a simple way to forward any TCP/IP traffic securely between two nodes. If you've got secure entry into a network, tunnel between nodes on that network ensures no eavesdropping or impersonation from another node on that network.
Also note that SSH came before VPNs :) You can also bridge two networks over ssh with things like sshuttle.
Not enough information here, but I think it falls into roughly these possibilities:
1. The tunnels are required by IT. For certain machines, they wanted an extra layer of security.
2. The tunnels are rogue. By "we need to do tunneling" it means "without knowledge/approval of IT, we hacked access to something via SSH tunnels".
Either way:
> Can't anyone who knows the server IP and has company VPN; tunnel and get access to that server?
Not necessarily! Internal IP addresses can be divided into subnets with firewalls between them, such that the only way to get through is SSH tunnels (or other chosen means).
Even if you're physically inside the company, on the LAN, and not coming in via a VPN, you may have to use a tunnel to get to certain resources.
You can set up something like that at your own desk! Put a router on the LAN, where behind your router you have your 192.168.0/* network. On your router, you can have an sshd server, and then so from outside of your little desktop network, you can SSH to your company-LAN-facing machine (say 10.x.y.z) and set up a tunnel targeting some 192.168.0.n:nnnn address in your desktop network.
The point of doing this would be that you cannot just route between the company LAN and your 192.168 subnet. You could do port forwarding. But ssh tunnels give you more flexibility than a fixed port forwarding configuration. The ssh client can specify tunnels. And ssh keeps out unauthorized users. Nobody can access anything in your 196.168.0/* without ssh access to the 10.x.y.z router. And ssh can help get around blocked ports.
1. The tunnels are required by IT. For certain machines, they wanted an extra layer of security.
2. The tunnels are rogue. By "we need to do tunneling" it means "without knowledge/approval of IT, we hacked access to something via SSH tunnels".
Either way:
> Can't anyone who knows the server IP and has company VPN; tunnel and get access to that server?
Not necessarily! Internal IP addresses can be divided into subnets with firewalls between them, such that the only way to get through is SSH tunnels (or other chosen means).
Even if you're physically inside the company, on the LAN, and not coming in via a VPN, you may have to use a tunnel to get to certain resources.
You can set up something like that at your own desk! Put a router on the LAN, where behind your router you have your 192.168.0/* network. On your router, you can have an sshd server, and then so from outside of your little desktop network, you can SSH to your company-LAN-facing machine (say 10.x.y.z) and set up a tunnel targeting some 192.168.0.n:nnnn address in your desktop network.
The point of doing this would be that you cannot just route between the company LAN and your 192.168 subnet. You could do port forwarding. But ssh tunnels give you more flexibility than a fixed port forwarding configuration. The ssh client can specify tunnels. And ssh keeps out unauthorized users. Nobody can access anything in your 196.168.0/* without ssh access to the 10.x.y.z router. And ssh can help get around blocked ports.
> Can't anyone who knows the server IP and has company VPN; tunnel and get access to that server?
I'm not sure I've understood quite how your chain of VPN, RDP and Tunnels is set up so I'm making some assumptions (Hopefully it'll still be helpful). I'm going to assume that you create a tunnel from the RDP machine to a port on the target machine's localhost interface.
First of all the process of creating the tunnel will involve authentication, which makes it easier to lock down access to individuals. Also the authentication process will leave entries in logs that a specific user connected to the tunnel which is generally more useful that someone with an IP of x.x.x.x connected (especially if multiple users could be connecting from the RDP machine).
Secondly making an application only listen on the localhost interface reduces the chance that in the future a miss-configuration of the firewall will open up access to the world.
Thirdly the tunnel will be encrypted which can add an extra layer of security if the underlying protocol being used transmits in the clear.
I'm not sure I've understood quite how your chain of VPN, RDP and Tunnels is set up so I'm making some assumptions (Hopefully it'll still be helpful). I'm going to assume that you create a tunnel from the RDP machine to a port on the target machine's localhost interface.
First of all the process of creating the tunnel will involve authentication, which makes it easier to lock down access to individuals. Also the authentication process will leave entries in logs that a specific user connected to the tunnel which is generally more useful that someone with an IP of x.x.x.x connected (especially if multiple users could be connecting from the RDP machine).
Secondly making an application only listen on the localhost interface reduces the chance that in the future a miss-configuration of the firewall will open up access to the world.
Thirdly the tunnel will be encrypted which can add an extra layer of security if the underlying protocol being used transmits in the clear.
Filtering by IP is not enough for security.
Imagine, Rostelecom, largest Russian ISP, few times misconfigured their network equipment, so ~90% of European traffic went throw Russian channels.
So they seen all unencrypted files, logins/passwords, emails, phones, bank accounts, etc.
They always said, "this is just mistake", but we cannot be sure, if all these information was not sold on black market.
You have not suffer from scammers? This is just question of how strong your encryption and how much time passed.
SSH tunneling, if properly configured, is strong enough, so nobody could decrypt your data in nearest years.
To be strict, considering current state of cryptography science/tech, one need hundreds years of CPU time to decrypt data, but we cannot be sure, nearest years will not uncover mistakes or will not appear some new equipment, like quantum computers, so hundreds years could shrink to few weeks of medium size DC.
Imagine, Rostelecom, largest Russian ISP, few times misconfigured their network equipment, so ~90% of European traffic went throw Russian channels.
So they seen all unencrypted files, logins/passwords, emails, phones, bank accounts, etc.
They always said, "this is just mistake", but we cannot be sure, if all these information was not sold on black market.
You have not suffer from scammers? This is just question of how strong your encryption and how much time passed.
SSH tunneling, if properly configured, is strong enough, so nobody could decrypt your data in nearest years.
To be strict, considering current state of cryptography science/tech, one need hundreds years of CPU time to decrypt data, but we cannot be sure, nearest years will not uncover mistakes or will not appear some new equipment, like quantum computers, so hundreds years could shrink to few weeks of medium size DC.
> While some servers are directly accessible, some are not. We need to do tunneling for it.
BTW, you can set tunneling in your ~/.ssh/config, so that you do `ssh <server>` and it connects automagically.
(I know this is not what you asked, but I hope it helps)
BTW, you can set tunneling in your ~/.ssh/config, so that you do `ssh <server>` and it connects automagically.
(I know this is not what you asked, but I hope it helps)
So, at TCP level routing should allow ssh client to reach server. The session is secure (encrypted, authenticated) and logically allows multiple data pipes to be multiplexed of over the connection.
By default, one pipe is used to connect client terminal to a remote shell at the server, but it's possible to do something useful with the other pipes. For instance, user local forwarding, as port or IP address only locally visible to the server can be tunneled through a pipe and mapped to a port on the client machine.
So, in case of RDP: never expose port 3389 on a public IP. Instead use an SSH tunnel to route the RDP traffic through a tunnel over port 22 (or some random SSH port) and have it egress on the client's machine. Your RDP client can then transparently use the local port.
By default, one pipe is used to connect client terminal to a remote shell at the server, but it's possible to do something useful with the other pipes. For instance, user local forwarding, as port or IP address only locally visible to the server can be tunneled through a pipe and mapped to a port on the client machine.
So, in case of RDP: never expose port 3389 on a public IP. Instead use an SSH tunnel to route the RDP traffic through a tunnel over port 22 (or some random SSH port) and have it egress on the client's machine. Your RDP client can then transparently use the local port.
I think tunnelling is pretty common on networks divided into zones. It allows you to cross a zone but requires authentication. Effectively the same as a VPN but you don't need 1 VPN per zone.
A zone is basically just a logical boundary like "DMZ" for systems directly exposed to the internet, semi-trusted for machines accessible from the internet by other machines (like through a proxy or load balancer), and trusted/private for machines not accessible from the internet.
There's newer stuff like Tailscale that makes some of these obsolete and can introduce software routing rules so you could access arbitrary things through a single connection regardless of where they live from a network perspective.
A zone is basically just a logical boundary like "DMZ" for systems directly exposed to the internet, semi-trusted for machines accessible from the internet by other machines (like through a proxy or load balancer), and trusted/private for machines not accessible from the internet.
There's newer stuff like Tailscale that makes some of these obsolete and can introduce software routing rules so you could access arbitrary things through a single connection regardless of where they live from a network perspective.
The point of that tunnel may be to prevent entities that are inside the VPN from sniffing cleartext RDP traffic. If an attacker gets VPN access you want to limit their ability to do damage inside the VPN.
Could be. I think these days RDP has support for TLS 1.2 though.
I can't say I know what problem it's solving in your particular situation, but I've found SSH tunnelling useful for redirecting cloud VPS traffic to my local box to pinpoint and debug issues in an IDE - though these days it's all k8s and it's much easier to drop your machine in as a particular node.
You're probably tunneling through a bastion/jump host. This is a security design so that the ssh host you tunnel through is the only host allowed to interact with the destination hosts and some security checks/auditing is done on the ssh server/bastion host.
remote control of an ethernet cable
What's the problem that tunneling is trying to solve