On Wed, May 20, 2009 at 1:55 PM,
<bishmer@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).
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 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?