Security Basics
Understanding and preventing reverse ssh tunnels Jul 27 2012 08:46AM
a bv (vbavbalist gmail com) (1 replies)
Re: Understanding and preventing reverse ssh tunnels Aug 03 2012 02:49AM
Peter Thomas (peter hackertarget com) (2 replies)
Re: Understanding and preventing reverse ssh tunnels Aug 06 2012 05:42AM
Mustafa Qasim (alajal gmail com) (1 replies)
Re: Understanding and preventing reverse ssh tunnels Aug 06 2012 02:07PM
Giuseppe Longo (giuseppelng gmail com) (1 replies)
Re: Understanding and preventing reverse ssh tunnels Aug 07 2012 04:34AM
Peter Thomas (peter hackertarget com)
Re: Understanding and preventing reverse ssh tunnels Aug 03 2012 06:12PM
!s3grim (persephane gmx eu) (1 replies)
Re: Understanding and preventing reverse ssh tunnels Aug 07 2012 12:47PM
Jeffrey Walton (noloader gmail com) (1 replies)
RE: Understanding and preventing reverse ssh tunnels Aug 07 2012 03:39PM
David Gillett (gillettdavid fhda edu) (1 replies)
Re: Understanding and preventing reverse ssh tunnels Aug 07 2012 04:06PM
Jeffrey Walton (noloader gmail com)
On Tue, Aug 7, 2012 at 11:39 AM, David Gillett <gillettdavid (at) fhda (dot) edu [email concealed]> 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

> ________________________________________
> From: Jeffrey Walton [noloader (at) gmail (dot) com [email concealed]]
> Sent: Tuesday, August 07, 2012 5:47 AM
> To: !s3grim
> Cc: Peter Thomas; a bv; security-basics (at) securityfocus (dot) com [email concealed]
> Subject: Re: Understanding and preventing reverse ssh tunnels
>
> On Fri, Aug 3, 2012 at 2:12 PM, !s3grim <persephane (at) gmx (dot) eu [email concealed]> 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-prox
ies-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 <peter (at) hackertarget (dot) com [email concealed]>:
>>
>>> 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 <vbavbalist (at) gmail (dot) com [email concealed]> wrote:
>>>> Hi,
>>>>
>>>> How can i prevent reverse ssh tunnels?

------------------------------------------------------------------------

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;e13b6be442
f727d1
------------------------------------------------------------------------

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus