18

Given firewall

  • inbound: all are blocked
  • outbound: allow port 80, 443

Problem

  • colleagues are still able to ssh to home device by port 80/443, and establish a reverse ssh tunnel from company to home, and further from home to company.

Question

  • Besides asking HR to add a penalty rule in company policy handbook, is it able for network admin to block reverse ssh in a technical way?
developer.cyrus
  • 317
  • 1
  • 2
  • 5
  • 10
    I guess you must be happy, employees are smart enough to break through the firewall. I'd say set additional restrictions like proxy, then raise salary of people that can pass through it. Then you can add layer 7 filtering, etc. – akostadinov Oct 13 '15 at 08:31
  • 1
    what about setting iptables rules to block ALL incoming SSH traffic to related machines within your company? –  Oct 13 '15 at 08:44
  • @Begueradj: It's not about incoming SSH traffic, it's about outgoing SSH traffic, (that's being disguised as HTTPS) that enables a tunnel in the reverse direction. – Guntram Blohm Oct 13 '15 at 14:17
  • 2
    You don't. Cell phone internet will defeat you in the end anyway. – Joshua Oct 13 '15 at 15:39
  • @akostadinov, Layer 7 filtering??? – Pacerier Mar 20 '17 at 22:01
  • @Pacerier, maybe layer 7 firewall or application layer firewall is a better term. Search it and you'll get a lot of results. – akostadinov Mar 20 '17 at 22:06
  • @developer.cyrus, If you only allow port 80 and 443, does it mean that employees cannot visit site like `http://example.com:8080/`? – Pacerier Mar 20 '17 at 22:07
  • @akostadinov, Wow, just think about the processing overhead for implementing layer 7 filtering... – Pacerier Mar 20 '17 at 22:09

6 Answers6

26

SSH traffic looks different from HTTP and HTTPS. SSH traffic simply tunneled through port 80 or 443 (i.e. ssh -p80...) can be detected by looking at the first response packet already which contains the SSH version and not the HTTP version or the TLS ServerHello. But you could also simply enforce the use of a HTTP proxy inside the network which makes the use of plain SSH impossible.

This leaves the possibility to tunnel SSH inside some other protocol, like simply creating a tunnel through the proxy using a CONNECT request or even hiding the SSH connection within a full TLS connection, using plain HTTP, using WebSockets, with DNS or similar. This is much harder to detect although some statistical analysis might help because SSH shows a different behavior than normal HTTP traffic. But such analysis might be easily confused with today's common WebSockets traffic.

At the end it is a race and you should ask yourself why you focus on SSH tunnels anyway. These tunnels are nothing but a tool to transport data between inside and outside. Such data transports can also be done using normal HTTP/HTTPS, can be done with USB sticks etc. Thus focusing on a single vector do prevent data leakage or to prevent the attacker entering the network is IMHO the wrong way. And for having a policy: it is more secure to have a white list on what is allowed than to have a black list on what is not allowed.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 4
    Blocking one protocol is pointless - if there's a way in/out of the network, someone can find a way around it anyway. A friend of mine built a simple HTTPS web API to send simple request/response from his browser, then used that to send SSH commands and receive the response... probably pointless, but the fact is that it was indistinguishable from general HTTPS traffic – Jon Story Oct 13 '15 at 10:11
  • 5
    For HTTPS, use any TLS-intercepting proxy to make sure the cleartext is really HTTP. – user253751 Oct 13 '15 at 10:46
  • 6
    There's even [software that tunnels tcp through DNS requests](http://dnstunnel.de/). There's no technical solution to the problem. The key is that whoever is clever enough to build/use this kind of tunnel is *probably* clever enough to avoid the threads an open internet connection poses to the company. – Guntram Blohm Oct 13 '15 at 14:22
  • 2
    @GuntramBlohm I have found that those Clever enough to bypass constraints who also posses the hubris to carry out that bypass, will seldom apply that cleverness to protecting the interests of anyone but themselves. – tjd Oct 13 '15 at 18:37
  • 1
    @tjd, What's that supposed to mean? – Pacerier Mar 21 '17 at 02:51
  • Can you explain for me why using HTTP Proxy makes plain SSH impossible ? Thanks. – hqt Sep 03 '19 at 19:51
  • @hqt: if all traffic going out of the network must use the HTTP proxy instead of connecting directly to the server port 80 or 443, then SSH would need to tunnel over the HTTP proxy too. While one might setup something like this it would no longer be **plain** SSH (which connects directly to the server). – Steffen Ullrich Sep 03 '19 at 20:43
6

A way to make it a bit harder could be to have an HTTP proxy in place so that connections can't be made directly over 80/443 anymore unless it's a valid HTTP connection, but even that can be bypassed though using something like Proxytunnel. Another way to bypass this would be to just run a web console and access it normally over 80/443.

Making it harder for them will probably not stop them, but in the end if you have it in your policy that it is not allowed and you monitor the network then warnings can be given to people who people who break this rule.

alxjsn
  • 79
  • 2
  • 2
    either you MITM attack TLS, or they can still use the proxy to just open a connection on port 443 – Josef Oct 13 '15 at 08:08
4

Here, they have blocked SSH through 443 port by blocking CONNECT method of the HTTP Proxy.

A second solution is to use a false 'login' page. Using proxy can ask for password, this is normaly asked by the browser, or entered in authentication fields in apps that can use a proxy. But you can bypass this on the proxy server by using a false login page that ask for login / password.

This method is horrible, as only application that display this page can go through the proxy. Putty for example, can't display this page, and so can't authenticate itself to the proxy.

iXô
  • 141
  • 2
2

The first question should be why are users / admins using reverse ssh tunnels. I worked at a company that had a really poorly implemented VPN for remote management, that only allowed connectivity to a citrix server with poor tools, so we used SSH remote tunnels to adequately manager our servers remotely. The tunnels where only allowed out from a bastion host. The host was setup with Disabled password authentication, Disabled root login, and Enabled key-based authentication. The reverse tunnel allowed ssh connections backthrough to the DMZ, then from the bastion host users could only get to a handful of other bastion hosts. Instead of going down the rabbit hole to block ssh tunneling with MITM intercepting proxies, IDS, blocking access to admins home IPs, and DPI firewalls. Provide a better solution to the users / admins, satisfying their requirements, then implement an HR policy and enforce it.

Jerry
  • 21
  • 2
2

Luajit via Suricata IDPS provides some advanced mechanisms for controlling SSH as well as SSL/TLS tunnels to prevent proxy subversion, reverse shells, et al.

Check out this rather thorough, albeit not-fully complete, guide to find self-signed certs using Suricata and luajit -- https://www.stamus-networks.com/2015/07/24/finding-self-signed-tls-certificates-suricata-and-luajit-scripting/

atdre
  • 18,885
  • 6
  • 58
  • 107
1

Asking how to secure ssh opens a can of worms, here are those worms.

Some will be mad when I say this, but it's something fairly simple that can be accomplished and "should have been built this way" a long time ago.

This can be done, most who disagree are neighsayers, and likely responsible for the vulnerabilities we currently face in the world...I digress.

The above suggestion of forcing all traffic through proxies that require visibility into the traffic before handing off is a strong start and should be a concept deployed on top of and aligned with your network and physical security policies and methodologies, sometimes down to the security guard's laptop/mobile doing hall duty.

Control your client workstations. Wire them appropriately. Segregate from wireless. Have constant stat monitoring on client "dumb terminals." Usb turned off. Provide power hubs for the individuals needing power. Have all exports leave through a approval process, which includes IT admin procedures.

Software on these workstations can be a simple platform with minimal ability that provides a web interface or client application that will securely guide them to accessible resources that are only appropriate to their role.

Wireless should be avoided unless on a completely different trunk altogether.

Services like "social media platforms" should be "overscrutinized" as they're should be more false alerts than actual alerts, so that the company can benefit from the information going in and out of a social media network being "utilized."

All of this is from a low level support agent with way too much time on their hands. However, if you have a network with these methodologies deployed, you will attest it is valuable to know the comings and goings of your employees, not an invasion of privacy, but an asset. At your place of secure data, the only thing anyone should have to hide is the company and its data, including who handles it and how.

In this day and age, if you have a reason for information assurance, you need assurance in those people assuring to provide secure information.

No need for employees to be moving company data around as freely as they do these days.

This can all be greatly mitigated at the minimum, let alone enforced with physical security protocols as well to limit the photography and video aspects of data exfil methods in addition to usual pen and paper, "killer usb drives," etc.

Jeremy Ruhnke
  • 11
  • 1
  • Oh, and let us not forget ssh through a browser, spice, etc. – Jeremy Ruhnke Sep 06 '17 at 23:02
  • This is certainly a justifiable approach in an environment where you need to keep your technology safe from your staff, so +1 for these caes. In most cases, it is more necessary to protect technology from technology than from people. – rackandboneman Nov 24 '17 at 20:21