Understanding and preventing reverse ssh tunnels

[a bv]

Hi,

How can i prevent reverse ssh tunnels?


Regards

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate. We look at how SSL works, how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------

[Peter Thomas]

If you have open ports you cannot restrict ssh tunnels or port
forwarding within a SSH connection at the gateway as the communication
is encrypted. The gateway / firewall will only see SSH traffic.

To restrict tunnels you need to block ingress and egress traffic, and
only provide web access over a proxy that does SSL mitm and looks for
ssh over HTTP.

In most cases forcing use of proxy and blocking direct access to
external hosts will be enough.

On Fri, Jul 27, 2012 at 6:46 PM, a bv <vbavb...@gmail.com> wrote:
> Hi,
>
> How can i prevent reverse ssh tunnels?
>

--
Regards,

Peter
--------------------------------------------------
Security Scanning Tools On-line
Web: http://hackertarget.com/
--------------------------------------------------

[!s3grim]

I don't think any SSL-mitm-proxy is such a good idea. Any SSL-traffic, even it is 'secure', has to be intercepted. Thus leading to many certificate warnings annoying your users and getting them used to invalid certificates and ignoring warnings, you won't neither be able to distict malicious site from good ones, even if you wan't to, nor be able to detect all types of reverse tunnels, and theoretically there are a plenty of, some being already existent.

Btw, I don't think a proxy could ever handle this kind of problem. Any solution relaying parts of the submitted content without change can be misused for tunneling. If you are afraid, your user will be owned, what about considering something like a terminal session just presenting a browser window without copy'n'paste. Thus at least will prevent simple tunneling by changing the semantics of interaction interrupting the direct channel.

Cheers
!s3grimm

[Mustafa Qasim]

Hi,

SSH shouldn't be allowed to everyone at all.
SSH to any public host shouldn't be allowed.
SSH should only be allowed to REQUIRED external IPs from REQUIRED terminals.

--
Mustafa Qasim

m...@mustu.info
http://blog.mustu.info

[Giuseppe Longo]

Little question about reverse ssh tunneling: is it possible to bypass
proxy server?

[Peter Thomas]

Not sure what you mean by "bypass".

To bypass a proxy server with SSH will depend on network controls (firewall).

Or alternatively if you mean tunnelling SSH over a proxy server then
in this case yes it is possible. (Google for a program called
corkscrew and ssh tunnel).

On Tue, Aug 7, 2012 at 12:07 AM, Giuseppe Longo <giuse...@gmail.com> wrote:
> Little question about reverse ssh tunneling: is it possible to bypass
> proxy server?

--
Regards,

Peter
--------------------------------------------------
Security Scanning Tools On-line
Web: http://hackertarget.com/
--------------------------------------------------

[Jeffrey Walton]

On Fri, Aug 3, 2012 at 2:12 PM, !s3grim <perse...@gmx.eu> wrote:
> I don't think any SSL-mitm-proxy is such a good idea. Any SSL-traffic, even it is 'secure', has to be intercepted. Thus leading to many certificate warnings annoying your users and getting them used to invalid certificates and ignoring warnings, you won't neither be able to distict malicious site from good ones, even if you wan't to, nor be able to detect all types of reverse tunnels, and theoretically there are a plenty of, some being already existent.
>

These are sometimes referred to as Interception Proxies. Bluecoat
(http://www.bluecoat.com/), et al.

There are some Blackhat talks on the devices. Matt Green has a nice
blog entry "How do Interception Proxies fail?,"
http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html.

> Btw, I don't think a proxy could ever handle this kind of problem. Any solution relaying parts of the submitted content without change can be misused for tunneling. If you are afraid, your user will be owned, what about considering something like a terminal session just presenting a browser window without copy'n'paste. Thus at least will prevent simple tunneling by changing the semantics of interaction interrupting the direct channel.
>

Right - these devices need to see "standard" communications exchanges
(even if "standard" includes encrypted). I believe its an instance of
the halting problem (corrections, please). I imagine a spurious header
that is later discarded would be enough to evade some of the lower end
models.

Jeff

> Am 03.08.2012 um 04:49 schrieb Peter Thomas <pe...@hackertarget.com>:
>
>> If you have open ports you cannot restrict ssh tunnels or port
>> forwarding within a SSH connection at the gateway as the communication
>> is encrypted. The gateway / firewall will only see SSH traffic.
>>
>> To restrict tunnels you need to block ingress and egress traffic, and
>> only provide web access over a proxy that does SSL mitm and looks for
>> ssh over HTTP.
>>
>> In most cases forcing use of proxy and blocking direct access to
>> external hosts will be enough.
>>
>> On Fri, Jul 27, 2012 at 6:46 PM, a bv <vbavb...@gmail.com> wrote:
>>> Hi,
>>>
>>> How can i prevent reverse ssh tunnels?
>>>

[David Gillett]

The way you deploy something like BlueCoat is to tie it to your corporate CA. Users never see certificate warnings, because the certificate the proxy offers them is signed by a CA they already trust as part of their configuration on the corporate network.
(If your network is looser than that about what devices are allowed onto it, then intercepting SSL traffic may be a difficult legal/political issue even when it's not technically too difficult....)

David Gillett
CISSP CCNP

________________________________________
From: Jeffrey Walton [nolo...@gmail.com]
Sent: Tuesday, August 07, 2012 5:47 AM
To: !s3grim
Cc: Peter Thomas; a bv; securit...@securityfocus.com
Subject: Re: Understanding and preventing reverse ssh tunnels

[Jeffrey Walton]

On Tue, Aug 7, 2012 at 11:39 AM, David Gillett <gillet...@fhda.edu> wrote:
> The way you deploy something like BlueCoat is to tie it to your corporate CA. Users never see certificate warnings, because the certificate the proxy offers them is signed by a CA they already trust as part of their configuration on the corporate network.
> (If your network is looser than that about what devices are allowed onto it, then intercepting SSL traffic may be a difficult legal/political issue even when it's not technically too difficult....)
>

Agreed, but it has not stopped others in the past:
* "Trustwave revokes "MitM" certificate, vows never to issue one
again," http://www.net-security.org/secworld.php?id=12369

Sadly, "The Community" failed in the case of Trustwave/Mozilla. The
Mozilla foundation rewarded Trustwave's bad behavior and violation of
the inclusion policy by continuing Trustwave's inclusion:
* "Remove Trustwave Certificate(s) from trusted root certificates,"
https://bugzilla.mozilla.org/show_bug.cgi?id=724929

Epic fail.

Jeff