Given firewall

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


  • 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.


  • 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?
  • 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. Commented Oct 13, 2015 at 8:31
  • 1
    what about setting iptables rules to block ALL incoming SSH traffic to related machines within your company?
    – user45139
    Commented Oct 13, 2015 at 8: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. Commented Oct 13, 2015 at 14:17
  • 2
    You don't. Cell phone internet will defeat you in the end anyway.
    – Joshua
    Commented Oct 13, 2015 at 15:39
  • @akostadinov, Layer 7 filtering???
    – Pacerier
    Commented Mar 20, 2017 at 22:01

6 Answers 6


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.

  • 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
    Commented Oct 13, 2015 at 10:11
  • 5
    For HTTPS, use any TLS-intercepting proxy to make sure the cleartext is really HTTP. Commented Oct 13, 2015 at 10:46
  • 6
    There's even software that tunnels tcp through DNS requests. 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. Commented Oct 13, 2015 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
    Commented Oct 13, 2015 at 18:37
  • 1
    @tjd, What's that supposed to mean?
    – Pacerier
    Commented Mar 21, 2017 at 2:51

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.

  • 2
    either you MITM attack TLS, or they can still use the proxy to just open a connection on port 443
    – Josef
    Commented Oct 13, 2015 at 8:08

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.


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.


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/

  • I like your profile pic.
    – Pacerier
    Commented Mar 21, 2017 at 2:55

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.

  • Oh, and let us not forget ssh through a browser, spice, etc. Commented Sep 6, 2017 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. Commented Nov 24, 2017 at 20:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .