ssh in ssl tunnel. risks ?

Hi,
when using a ssl tunnel to get ssh through a proxy, do I create an extra risk
for a penetration from the internet ? On the client machine is a X-server
running, no others.
What if the client also had sshd running ?

--
With kind regards,
Ronald
http://ronr.nl/unix-dba

>>when using a ssl tunnel to get ssh through a proxy, do I create an
>>extra risk for a penetration from the internet ? On the client machine
>>is a X-server running, no others.
>
> Generally no, a ssh tunnel is less risk than a normal tcp socket

I'm not so sure. It's secure if the crypto software is secure. But, if the
crypto software has a vulnerability (implementation) then you might
introduce new problems, maybe even root compromise.

There has long been the debates on these newsgroups about if telnet is
really that insecure. If you do remote logins with cleartext telnet, you're
only at risk if your packets can be sniffed along the way from client to
server. OTOH, with ssh your server can be at risk even if you do nothing.
If you have an old version of OpenSSH, attackers could get root on your
server.

As with everything else it's about a balance of risks and benefits. If
there's a risk of packets being sniffed, and the consequences are severe
(if system passwords are being passed then the consequences ARE very
severe) then it's worth the added complexity and risk of SSL/SSH.

--
Jem Berkes
http://www.sysdesign.ca/

Jem Berkes <jb@users.pc9.org> writes:

[snip]
> There has long been the debates on these newsgroups about if telnet is
> really that insecure. If you do remote logins with cleartext telnet, you're
> only at risk if your packets can be sniffed along the way from client to
> server. OTOH, with ssh your server can be at risk even if you do nothing.
> If you have an old version of OpenSSH, attackers could get root on your
> server.

There is no more risk in a socket-listener being sshd than in it being
telnetd or (x)inetd. You should be well aware that a large part of worms /
exploits / nasties doing the rounds for at least the past 5 years have been
to ftp and portmapper ports, and I thought there was a hole in telnetd some
time ago too. Hence ports providing unencrypted services are just as
vulnerable to buffer-overrun attacks as any other.

There are two lines of defence that apply regardless of what the service
is: limit access to those IP#s you want, *only*, and keep it *uptodate*
every sodding day.

> As with everything else it's about a balance of risks and benefits. If
> there's a risk of packets being sniffed, and the consequences are severe
> (if system passwords are being passed then the consequences ARE very
> severe) then it's worth the added complexity and risk of SSL/SSH.

Given that I don't see any extra risk in it being ss[lh], and the
complexity leads to a more convenient way of operating with which I'm
entirely familiar, you can guess that I'm well & truly in the
DO-IT-SECURELY crowd ;)

~Tim
--
09:57:13 up 176 days, 12:16, 2 users, load average: 0.01, 0.09, 0.17
piglet@stirfried.vegetable.org.uk |Move a mountain / Fill the ground
http://spodzone.org.uk/cesspit/ |Take death on wheels / Re-create the land

> Given that I don't see any extra risk in it being ss[lh]

I just can't agree with this, myself. OpenSSL has had vulnerabilities in
the past few years. One of them resulted in the first Linux worm that could
spread using Apache (using OpenSSL). I believe script kiddies still search
for outdated OpenSSL installations to use for attacking (e.g. < 0.9.6f)

Outdated versions of OpenSSH have allowed remote root compromises more than
once. One of these remote exploits forced OpenBSD to change their slogan,
which used to brag no remote vulnerabilities in default install.

I still use OpenSSH and OpenSSL myself, because the benefits far outweigh
the risks but the point is that there are risks.

You can not just install OpenSSH and OpenSSL and forget about them; they
have to be kept up to date. Nor any service, of course. But it strikes me
as significant that with a crypto wrapped service, you have to worry about
BOTH vulnerabilities in the daemon itself, and in the crypto wrapping it.

--
Jem Berkes
http://www.sysdesign.ca/

Jem Berkes <jb@users.pc9.org> writes:

>> Given that I don't see any extra risk in it being ss[lh]
>
> I just can't agree with this, myself. OpenSSL has had vulnerabilities in
> the past few years. One of them resulted in the first Linux worm that
> could spread using Apache (using OpenSSL). I believe script kiddies still
> search for outdated OpenSSL installations to use for attacking (e.g. <
> 0.9.6f)
>
> Outdated versions of OpenSSH have allowed remote root compromises more
> than once. One of these remote exploits forced OpenBSD to change their
> slogan, which used to brag no remote vulnerabilities in default install.

Sure, I know openss[lh] have had their problems in the past, which means
that worms etc will still be banging around for some time to come. They've
had some problems in exactly the same ways as any other service, too.

[snip]
> But it strikes me as significant that with a crypto wrapped service, you
> have to worry about BOTH vulnerabilities in the daemon itself, and in the
> crypto wrapping it.

This is a feature of having any protocols in a layered / wrapped
arrangement.

For `vulnerability in the ... crypto wrapping it', substitute `cross-site
scripting attack', and for daemon, read `apache'. That's an example of
apache providing a protocol (HTTP) on top of which is layered something
else (dynamically generated HTML), in which you have plenty enough scope
for nasties to thrive. However, I don't think you'd suggest that people
stop using dynamic websites, rather the emphasis should be on keeping the
providers of dynamism (can you say `phpBB'?) uptodate.
Ditto with openss[lh].

IMHO the risk of sending passwords and other normal shell traffic in the
clear being intercepted over so much as 1 routing hop outweighs any "but
there's more to go wrong" argument - if only because I ssh into boxes all
day every day repeatedly but openss[lh] have their vulnerabilities once,
maybe twice, a year.

~Tim
--
23:48:41 up 177 days, 2:08, 2 users, load average: 0.48, 0.77, 0.48
piglet@stirfried.vegetable.org.uk |Windows 98 is year 2000-ready
http://spodzone.org.uk/cesspit/ |(seen during a recent, >y2000, installation)

> [snip]
>> But it strikes me as significant that with a crypto wrapped service,
>> you have to worry about BOTH vulnerabilities in the daemon itself,
>> and in the crypto wrapping it.
>
> This is a feature of having any protocols in a layered / wrapped
> arrangement.
>
> For `vulnerability in the ... crypto wrapping it', substitute
> `cross-site scripting attack', and for daemon, read `apache'. That's
> an example of apache providing a protocol (HTTP) on top of which is
> layered something else (dynamically generated HTML), in which you have
> plenty enough scope for nasties to thrive. However, I don't think
> you'd suggest that people stop using dynamic websites, rather the
> emphasis should be on keeping the providers of dynamism (can you say
> `phpBB'?) uptodate. Ditto with openss[lh].

Good point here, definitely.

> IMHO the risk of sending passwords and other normal shell traffic in
> the clear being intercepted over so much as 1 routing hop outweighs
> any "but there's more to go wrong" argument - if only because I ssh
> into boxes all day every day repeatedly but openss[lh] have their
> vulnerabilities once, maybe twice, a year.

Yup, for anything like logins I would not have it any other way. Maybe
another way to state my point is that not everything deserved crypto. Let's
say you have an entirely secure daemon, like one that just outputs the
current uptime. For something like that, there's no reason to put it over
OpenSSL (adds risk without any gain).

--
Jem Berkes
http://www.sysdesign.ca/

Jem Berkes <jb@users.pc9.org> writes:

[snip]
>> This is a feature of having any protocols in a layered / wrapped
>> arrangement.
>>
>> For `vulnerability in the ... crypto wrapping it', substitute
>> `cross-site scripting attack', and for daemon, read `apache'. That's
>> an example of apache providing a protocol (HTTP) on top of which is
>> layered something else (dynamically generated HTML), in which you have
>> plenty enough scope for nasties to thrive. However, I don't think
>> you'd suggest that people stop using dynamic websites, rather the
>> emphasis should be on keeping the providers of dynamism (can you say
>> `phpBB'?) uptodate. Ditto with openss[lh].
>
> Good point here, definitely.

Ta. It's one that worries me occasionally.

I'm thinking, fine, so PHP and a multiplicity of scripting languages make
it nigh-on impossible to have a buffer-overrun problem. But so what? All
they do is push the security concerns a level higher in the pecking order,
into the application-logic-space rather than low-level stuff. I expect
we'll see a rise in this sort of thing over time - XML/RPC and SOAP
firewalls, maybe?

>> IMHO the risk of sending passwords and other normal shell traffic in the
>> clear being intercepted over so much as 1 routing hop outweighs any "but
>> there's more to go wrong" argument - if only because I ssh into boxes
>> all day every day repeatedly but openss[lh] have their vulnerabilities
>> once, maybe twice, a year.
>
> Yup, for anything like logins I would not have it any other way. Maybe
> another way to state my point is that not everything deserved crypto.
> Let's say you have an entirely secure daemon, like one that just outputs
> the current uptime. For something like that, there's no reason to put it
> over OpenSSL (adds risk without any gain).

Oh OK. Yeah, there's no demand - and in some ways, if it draws the crackers
away from the secure ports... hmmmm, false security through multiplicity is
of similar value to false security through obscurity, I guess.

~Tim
--
13:06:34 up 177 days, 15:26, 2 users, load average: 0.20, 0.14, 0.10
piglet@stirfried.vegetable.org.uk |There's peat smoke rising
http://spodzone.org.uk/cesspit/ |From the village chimneys

Is that possible?
As far as I remember, SSH uses 2 channels (i.e. 2 ports) for its
communication, typically 22 and something dynamically assigned below 1024.
How can you tunnel that, 2 tunnels or what?
Cheers,

--
Mike

Jem Berkes <jb@users.pc9.org> wrote in
news:Xns94F6EC021EFCFjbuserspc9org@130.179.16.24:

>> IMHO the risk of sending passwords and other normal shell traffic in
>> the clear being intercepted over so much as 1 routing hop outweighs
>> any "but there's more to go wrong" argument - if only because I ssh
>> into boxes all day every day repeatedly but openss[lh] have their
>> vulnerabilities once, maybe twice, a year.
>
> Yup, for anything like logins I would not have it any other way. Maybe
> another way to state my point is that not everything deserved crypto.
> Let's say you have an entirely secure daemon, like one that just
> outputs the current uptime. For something like that, there's no reason
> to put it over OpenSSL (adds risk without any gain).

I agree. I understand the open sending vs crypto argument. The logic is
indisputable. But the computer forensics and honeypots I do has tended to
have ssh showup far more in the reports than any open-send protocol. Not
just exploits but in general knowledge and useage. What's really funny is
a honeypot with old protocols running and available and getting daily
use. For over a year now the skiddies that get in seem to be at a total
loss how to continue because the newer things like ssh arent available.

MUDs are also reporting the change. It used to be that a MUD game running
on port 23 would see alot of confused "breakins" from apparently sniffed
passwords. (MUDs are games that run using telnet). That seems to have
fallen to nothing in the past 4-5 years.

Of course I would never RECOMMEND an open protocol to anyone who was new
enough to ask what they should use. :) Just asking the question makes
some answers automaticly a good idea.

Gandalf Parker
-- Saying that there is NO security thru obscurity is like saying the
army should give up wearing camoufaged clothing.