Hacker News Reader

Comment by kavanutz | Hacker News Reader

It's definitely not for everyone. Inbound/outbound SSH is usually blocked on corp networks. One of the reasons is you can tunnel/forward ports and expose the internal network. HTTPS takes that away. Plus you can't copy files off the server and the idea is you can audit what is being done. Depends on what the threat is in IMHO.

View on HN

Corp networks are almost never a shining example of network design or security. Most people that work doing that sort of thing are the checkbox type and will block SSH (and other protocols) because it gives them some sense of warm and fuzzies.

The reality is this is stupid and just leads to people working around the problem. Take for example corkscrew, which allows you to tunnel SSH over HTTPS proxies, without losing any of it's port forwarding or other juicy features.

If you feel like you really need to embarass them you can ofcourse run something like sshuttle over the top providing automatic VPN routing over this rogue SSH tunnel.

Worse yet they might install KeyBox on their AWS deployment because they don't have SSH outbound, which then promptly gets pwned because it's a relatively unproven Java web application rather than a battle-hardened unix staple (i.e sshd).

Corp networks and infosec departments are a joke.

In terms of auditing all you need to do is make proper use of *nix permission model and then enable sudo input/output logging and control access to sudo via LDAP groups. Send all of your sudo logs to centralized logging system like Splunk/ELK/fluentd/Flume etc.

I'm all for your contempt of corporate network security policies honestly, but I think they're typically trying to stop most users that are not particularly sophisticated and basically assume that anyone with half a brain will get around eventually. That's why audit policies are much more rigorously enforced than network tunneling restrictions, for example.

I regularly defeat most policies if I really have to get work done but the real deterrent, sadly, is for employees to be fearful of getting caught and having to deal with the immense mountain of bullshit paperwork and training that is likely to follow. Completely meaningless paperwork filling is a form of disciplinary action in my opinion.

For example, at the US Air Force, the following policies are in place:

* Use of SSH is discouraged, because the traffic is encrypted, and the Air Force wants to be able to read all the traffic in and out of boxes.

* If you do get a waiver for SSH, the system admins require you to hand over all your SSH private keys, so that they can decrypt the traffic, read it, and re-encrypt it.

Yup! Make administration less confidential, but try and keep it as secure as possible. Inside attacks are a big problem in the financial industry too. I like the idea of controlling it through a hardened web-app, but may need a little help getting there.

Why? You can protect against insider threat by auditing the target system itself and streaming said audit logs to write only media.

Building a single point of compromise has no advantages over this and many disadvantages beyond just security.

Auditing can be a deterrent to an attack, but won't necessarily protect you against it. It's a good way of letting you know what has happened after the fact.

Think if you had a DB with financials (credit cards and such) in a isolated DMZ with SSH inbound/outbound blocked

How can you dump the DB and copy it off if all the traffic was "proxied" through this?? It's not like you can scp a tarball anywhere.

You can't forward ports and expose the DB outside of the DMZ either.

And it doesn't take admins to setup auditing or disable forwarding, you have physically disabled it.

I got to say I don't understand the single point of compromise thing. A single point of failure is a bad, but the less points of compromise the better. You identify your critical systems, you protect your critical systems. Spreading things out doesn't make you more secure.

Here is an old white paper on some things to think about SSH in your infrastructure.

http://www.sans.org/reading-room/whitepapers/vpns/security-i...

Your right in saying this is an unproven application!

You can tunnel through HTTPS too, given a client/server pair that supports HTTP CONNECT. Conversely it's possible to disable the SSH port forwarding function. From the firewall's point of view, they ought to be equally risky.

Reply on news.ycombinator.com