Given firewall
Problem
Question
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.
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.
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/
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.
