Some questions about ssh tunnelling and security

Lisa Kachold lisakachold at obnosis.com
Wed May 20 17:03:58 MST 2009


On Wed, May 20, 2009 at 1:55 PM, <bishmer at sekaran.net> wrote:

> I'm looking for some answers to my questions from more paranoid
> security-minded people (hi Lisa!). Networking isn't really something I'm
> particularly good at, and I'm always looking to learn more about it.
>
> Assume a host somewhere on the internet with sshd running ("Egress").
> Let's say someone else, from a different geographical location, then
> creates an ssh tunnel to Egress and sets up a SOCKS proxy.
> Our user then uses his SOCKS proxy to send and receive various sorts of
> TCP traffic (let's say SMTP, IMAP, telnet and HTTP).
>

Basically explained simply here:
http://en.wikipedia.org/wiki/Tunneling_protocol


> Questions:
> 1) Of the various points for attacks on the traffic, are Egress' local
> network and the client's local network particularly risky, less risky, or
> safe compared to the bounces along the backbone?


Nothing short of the server itself is "risky", since the traffic is end to
end encrypted on two levels.  With access to the server, the key can be
obtained via escalated access exploits.  With patched entropy using current
SSH and new clean keys, it should be extremely difficult to get both the
SOCKS proxy encryption from within the SSH session.  Essentially all
services running on the server must be secure also, for instance if you are
running a http with a perl form that does not input/output checking or an
Apache that allows a WebDav write outside of DocumentRoot, or a Php with
File escalation holes, well, it's not going to be too secure, since they
essentially would have shell access, and hense be able to trivially buffer
overflow to escalated privs, edit your binaries via selective rootkits or
just change pam.d and add their own backend anacron doorways home, etc.

Also the Socks 5 would be paranoid and needed more in a IPv6 environment,
although 4 is going to be sufficient for most proxy use (see:)

http://en.wikipedia.org/wiki/SOCKS

2) In securing the ssh tunnel itself, what is a reasonable amount of
> paranoia to result in reasonable security? Portnumber changing? Port
> knocking? Can you layer more encryption on top of ssh?


SSH itself would need to be setup:

1) From secure source.
2) Accessing aged passwords of secure length and randomness, or updated
protected keys.  (No users access who can not be trusted to exploit a shell
buffer and take the keys for instance).
3) With a wrapper and/or IP source/destination allow/deny process, or a
something like like SPA

S P A via fwknop

Single port authentication systems provide another key based exchange for
access on any port.  Conventional woodpecker style port knocking is open to
sniffing and brute force knocking attacks.  Sending an encrypted packet with
an access request to the server is safer and more modern, handled via
Firewall Knock Operator.  fwknop stands for "Firewall Knock Operator" and is
a piece of software that was released at the DEFCON
12<http://www.defcon.org/html/defcon-12/dc-12-index.html>conference in
July, 2004 in Las Vegas.

http://www.cipherdyne.org/fwknop/download/

http://www.net-security.org/secworld.php?id=7481   1.9.11 just released.

4) Ensure your server keys are protected, and sufficient.

3) What sort of sensitive information should never be sent through this
> tunnel due to inherent risk, no matter how much effort has gone into
> securing the connection?


I suppose if you are insanely paranoid, you would never send your server
keys; passwords.

But if encryption is good enough for Credit Cards and PCI compliance, it's
good enough for me?


> Thanks in advance for answers!


But of course, a VPN is perhaps a better solution?

Anyone have any corrections or input here?

>
>
>


-- 
www.obnosis.com (503)754-4452
"Contradictions do not exist." A. Rand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20090520/633010b4/attachment.htm 


More information about the PLUG-discuss mailing list