[relax88]

“Policy made my job slightly harder so because I know better than the netsec team who clearly has or should have unlimited time and resources to help me I will do what I want anyways, and put the organization at risk.”

Also known as “how to make the netsec team hate you 101”

I agree with you about why shadow IT exists, but most IT departments are spread so thin that expecting them to be super responsive to anything but the most critical business projects is often totally unreasonable.

Then they have to waste even more time hunting down idiots setting up Tor nodes on their internal networks.

[still_grokking]

If the IT department can't do its job because of resource constraints likely the whole organization is a failure.

If you find something like that, run…

If you can't run, do whatever makes your live better. The org is doomed anyway.

[azalemeth]

A recent example from me -- one VPN client of mine suddenly refused to connect one day for no discernible reason when they made a configuration change to their cisco vpn "concentrator" without documenting it or announcing it. Cisco AnyConnect GUI clients were fine and some magic happened behind the scenes to push the configuration change and, in typical Cisco style, avoid saying what exactly it was.

I had some esoteric monitoring machine that couldn't run anyconnect (for reasons I forget but almost certainly relating to it not having a linux arm64 client at that time) and naturally couldn't connect randomly one day with openconnect (which previously had worked perfectly). I asked what the configuration change was to prevent me having to reverse-engineer it. The response was "if you want to use unsupported clients we cannot offer any assistance [...] we are currently operating two heads down and we simply do not have the resources [...]." It took me about four or five hours to work out what change they had made, change the (122 line long) configuration file for openconnect, and then, boom, everything good again. A friendly "Hey, sorry about that -- we just $FLICKED_THIS_SWITCH because $REASON" would have been massively helpful and arguably take less words than their original response. (Edit: For context, approximately 10-20k people use that specific VPN. And their team is such that losing two members of staff temporarily is a major inconvenience.)

I totally understand it from the other side. IT departments have everything from state-sponsored ransomware attacks to important people loudly going "why doesn't the printer work any more". It's a different set of skills to being a C-junkie, a programming wizard, or, in my case, a young academic with one big grant and three PhD students trying to both do work, publish work, and get money to do more work where "work" is poorly defined and highly flexible. Over time I've noticed universities get far more corporate and many academics absolutely hate this, of which I am one. The "we control the network, bug off" may be technically true but at times it does feel a bit like an imposition of some sort of academic freedom, to be honest. At the very least, it's a nice little "dog egg" to find added to the pile of administrative crap to do for that day.

[relax88]

What you’ve just described is most post secondary institutions, public utilities, government, etc.

[Aloha]

I'm working in an organization where we have one laptop from work, and another laptop to do work on. Because the one sized fits all IT policy doesn't work for our org, but it's forced on us because of the IP security needs of another parallel org.

We went from an organization moving towards BYOD, to, now the exact opposite.

[slumdev]

> because I know better than the netsec team

For anyone who's been around the block a few times, there's a good chance this is true.

Most organizations' netsec teams are too busy throwing money at vendors to keep up.

[relax88]

“Because I think I might know better I will act in a disrespectful way, and make someone else’s job harder instead of working with them to solve the problem”

You’re not the one who’s phone is going to ring at 3am on Saturday when that Tor node gets compromised. You’re not the one who has to manage the security incident. You’re not the one who has to explain why your security controls and policy did not prevent this from happening. Nor are you the one who has to clean up the damage if something goes badly.

I also think you’re vastly overestimating the average developers awareness of security issues. Perhaps you are very well versed in this topic, but many developers are utterly clueless, even when it comes to basic application security practices.

[CheBuzz]

I'm curious how you think an SSH service exposed over TOR is going to create a security issue? SSH is exposed all over the public internet.

[relax88]

It bypasses all proxies and interception, and hides all of the traffic contained in the tunnel. This means no traffic logging of the tunneled traffic, no IPS/IDS in front of the SSH service, and no visibility into the SSH traffic itself. If the box with the SSH service isn’t in a DMZ it also compromises network segmentation.

The problem isn’t SSH over TOR being insecure. It is sidestepping all of the security controls in place at your org and not talking to the netsec folks first.

Honestly I would be amazed if any competent netsec folks would even allow TOR outbound by default. I certainly wouldn’t allow it by default in an enterprise environment.

[slumdev]

The idea of allowing any kind of inbound connection into a secured network (other than to/via its DMZs) is anathema.

I don't even disagree with the logic, but the BigCorp Infosec Team heavy-handed approach to working with developers invites the developers to produce creative circumventions.