Prevent SSH tunneling through port 80

Hi all,

I'm interested in stopping SSH connections from traveling through port 80. I'm not interested in doing this because I want to prevent my users from enjoying SSH connections. I have no users. Rather, I'm imagining a scenario where a rootkitted host is attempting to covertly connect to the outside world.

Of course SSH or even other traffic could be tunneled through various protocols. This is a huge problem and SSH though port 80 is one small portion of it. If anyone has ideas of how to stop the aforementioned, please share them here. Many tools and guides exist on tunneling SSH through port 80, even through HTTP proxies.

Apparently SSL connections can be decrypted and inspected by the proxy combination Squid+SslBump. I'm not familiar with Squid - yet. It would be cool if somehow decrypted traffic could be identified as either legitimate HTTPS traffic or malicious.

Link to Squid+SslBump Page Here:
http://wiki.squid-cache.org/Features/SslBump

Also, this is a mirror of the topic on Daemonforums / OpenBSD Security:
http://www.daemonforums.org/showthread.php?t=8003

ejr2122 said:

Rather, I'm imagining a scenario where a rootkitted host is attempting to covertly connect to the outside world.

Click to expand...

If that happens all gloves are off anyway.

Of course SSH or even other traffic could be tunneled through various protocols. This is a huge problem and SSH though port 80 is one small portion of it. If anyone has ideas of how to stop the aforementioned, please share them here. Many tools and guides exist on tunneling SSH through port 80, even through HTTP proxies.

Click to expand...

If your server is owned there's nothing stopping an attacker from changing any configuration on that box. They can only install a rootkit if they have root access. Since root can change just about anything there isn't anything stopping them from enabling everything you disabled.

The only way to prevent such a machine from reaching the outside world is by using an external firewall.

SirDice said:

The only way to prevent such a machine from reaching the outside world is by using an external firewall.

Click to expand...

Indeed. The Squid+SslDump combination can act as a layer 7 / application firewall. Since Squid is an HTTP proxy server, at the very least it can apply it's HTTP validation rules to GET/POST traffic the decrypted traffic. Maliciously tunneled SSH traffic would presumably be invalid. If an SSH tunneling implementation were somehow cleverly wrapping SSH traffic in valid HTTP headers, then perhaps Squid could identify other traits in the malicious traffic.

Probably you can achieve your goal by using an intrusion detection / intrusion prevention system.

There is, for example, Suricata, which can recognize protocols. Probably you can create some blocking rules out of the recognition.

Markus

storvi_net said:

Probably you can create some blocking rules out of the recognition.

Click to expand...

HIDS/IDS/IPS are all great. One of these tools could be made to detect what looks like suspicious SSL connection initiations. When the detection occurs, perhaps it could start a MITM attack to inspect it first. It would i.e. be an SSL gateway/proxy.

If this is a web server just block all access to the outside world. The firewall should only allow incoming connections to port 80. The responses are allowed if you have a proper stateful firewall. So there shouldn't be a need for the server to initiate connections on its own.

That all assumes we're talking about a web server. Depending on the type of server you may need to allow some traffic.

SirDice said:

If that happens all gloves are off anyway.


If your server is owned there's nothing stopping an attacker from changing any configuration on that box. They can only install a rootkit if they have root access. Since root can change just about anything there isn't anything stopping them from enabling everything you disabled.

The only way to prevent such a machine from reaching the outside world is by using an external firewall.

Click to expand...

Pretty much that.

What you really want is a DMZ network for exposed machines (behind an edge firewall) and another internal firewall between these machines and your internal network so that if one of the DMZ hosts is compromised you're not screwed internally - your internal firewall being very specific with what it will allow back in to your internal network.

If you can make your edge firewall, internal firewall and internal/DMZ hosts different platforms (so one exploit can't be used to compromise all of them), even better.

For example, on my corporate network I have:

• Inbound Cisco IOS ACLs on my edge router -> DMZ network. All that is passed is DNS, SMTP and IPsec / L2TP over IPsec. My outside DNS and MX (FreeBSD hosts) and HTTP proxy live in the DMZ. Any traffic is allowed "out" from the DMZ.
• Between the DMZ and inside, I have a Cisco ASA. This allows only specific ports from inside to the DMZ (from specific hosts only) and specific ports (that can't be proxied) to the outside (to specific destinations).
• My internal hosts (mailbox server for example) are mostly Windows (corporate network).

The only remote access permitted is via IPsec/L2TP and the edge/DMZ devices can only be managed via a specific set of IPs on the internal network.

There is still stuff I need to/am working on tightening - e.g., tighter control of where the DMZ machines are allowed to connect out to, more use of certificates (recently installed an enterprise CA), etc.

ejr2122 said:

Apparently SSL connections can be decrypted and inspected by the proxy combination Squid+SslBump. I'm not familiar with Squid - yet. It would be cool if somehow decrypted traffic could be identified as either legitimate HTTPS traffic or malicious.

Click to expand...

This is impossible in a general case but if the client program is willing to trust any server certificate it is presented then it becomes possible. It certainly will not work with web browsers and when the user is security conscious enough not to trust any unknown certificate the browser presents him/her.

You may remember the Dutch security company that was fooled into issuing an SSL certificate for Google mail and it turned out that the Iranian government was behind the attempt in some way. A proxy that could decrypt SSL connections transparently would need a same kind of bogus certificate (many certificates in fact) that is signed by a trusted third party so that alarm bells won't go off when the user tries to connect to an SSL site.

Regarding the original question, use of SSL encryption is probably the worst idea if you want to contact a remote site covertly. This is because it implies a stateful TCP connection that is very easy to pick out. I would use some kind of ICMP morse code protocol if I were to design such system myself

Also just to clarify - there's no way for your firewall to determine if HTTP is being tunnelled over SSH, as SSH is encrypted against eavesdropping, which will also impact your ability to do protocol inspection. Short version: you can't inspect SSH payloads.

The protocol is designed to prevent man in the middle. You can tell that the protocol is SSH easily enough by network inspection, but not that it is being used to tunnel something else.