On: Firewall rules: not as secure as you think

[tptacek]

This is billed as a means of selling customers on-prem stuff that you can remote-manage into with SSH despite firewall rules blocking SSH. You can do this. You can get a lot more sophisticated than the tricks outlined in this article to make it happen. It is very difficult for customers to prevent you from doing it. And, if you do it, you're going to get famous for doing it, when a customer that actually cares about your network security notices that you built a remote tunnel into their network.

I strongly advise anyone making product decisions to assume that none of these tricks work, and that there are no tricks you can use to build discreet remote management tunnels to devices (including hosts running your software) that have customer internal addresses assigned.

[spydum → tptacek]

I've seen vendors offering this technique or similar, but making it "opt-in". For example, Okta Access Gateway used to perform a reverse tunnel out to an Okta managed IP, but you had to enable the "Support VPN" option on the device. https://help.okta.com/oag/en-us/content/topics/access-gatewa... Seems like they dropped the feature, not sure if from customer backlash, or their security engineering teams finally realizing that it's risky. However, it was at least documented, and customer toggleable.

[mst → tptacek]

I think that were I to implement anything like this I would document the capability explicitly.

The situation that seems useful to me is bypassing dysfunctional processes rather than circumventing inconvenient policies.

(and if the device in question can auto-apply updates so far as I can see being able to ssh into it rather than ship it an update that Does Something is more a question of how convenient it is to Do The Thing rather than adding any additional Things that it Can Do, though it's entirely possible I'm missing something important there)