6 ms·

Literally the most terrifying service for any security-minded operations-focused person. Wonderful tool, interesting and useful in a dizzying array of aspects -

Literally the most terrifying service for any security-minded operations-focused person. Wonderful tool, interesting and useful in a dizzying array of aspects - but dear lord, I've had some real horrific moments when users told me that they installed it to allow access to their (private) repos for testing.

ageofwant 9y ago
If your users have to resort to this they are not getting the appropriate support they need. If your users are productive, chances are so is the company that pays both your salaries. If your users have to fight their infrastructure people to get their jobs done, you company will fail to effectively compete against those companies that don't. It astounds me that so few security people understand what their purpose is: Your purpose is to assist the company you work for to keep on existing, and even make a profit. If you disempower those that are most effective in helping the company do what it does you're effectively destroying your own livelihood, and everyone else that is dependent on it.
- DonbunEf7 9y ago
  Uh, no. The purpose of a security team is to prevent data from being exfiltrated from the company's control. Passwords, PII, HIPPA/other-compliance-controlled stuff, source code, etc. are all at risk of being stolen at all times, which means that security is a game of constant vigilance. And since everybody has at least a bit of this data under their control, this means that everybody is involved with security. (At least two of my past employers have had the motto, "Everybody is on the security team.") Productivity means nothing in the face of data exfiltration. You only have to fail once at guarding a password in order to be completely compromised. If we seem tightly wound, it's because we have fully internalized and grok the stakes of our efforts and the entailment of failure. "Our infrastructure sucked, so I used an insecure tool to leak our credentials to third parties, because I couldn't be productive otherwise!" is not really a valid excuse in this light, since there's no amount of productivity which offsets data exfiltration.
  - vidarh 9y ago
    None of that matters to the company if in protecting it you tie staffs hands sufficient behind their back that the company fails. And you harm security if you're being sufficiently inflexible that staff see it as essential to circumvent your security measures to be able to do their job. Because they will almost certainly manage to do so. As such, if you hurt productivity enough, you are also going to be failing at protecting company data by making people find alternative solutions, and you're not likely to get permission to go far enough to stop it unless you're working in a field where security clearance is the norm.
  - dsr_ 9y ago
    You're both right. If the dev team needs something like ngrok, the security team has failed to provide proper tools. If the dev team goes ahead and uses ngrok without consulting the security team, the dev team has likely committed an awful security breach. The dev team and the security team need to think of each other as being on the same team, and talk to each every day about what they want and need.
    - icedchai 9y ago
      Pretty sure a lot of people using this don't even have a "security team." They likely have corporate IT that takes 2 weeks to add a DNS entry. Something complex like mapping a public IP to a dev server would take an act of $DEITY.
      - philsnow 9y ago
        so register a new domain and set it up in route53? is there some corporate law that says you can't? just don't use your company's name in the domain name, make it something obscure.
        icedchai 9y ago
        Agreed. I personally don't have this problem. I have all my externally accessible dev servers on AWS. However, others are not so lucky.
- jlg23 9y ago
  > If your users have to resort to this they are not getting the appropriate support they need. I don't see where this follows from. "private repos" and "testing" implies "local testing" for me. If that implication does not hold, the development workflow is seriously screwed. (Don't tell me there is no money for a local test setup when you have dedicated IT security.) And in my experience, more often than not, it is screwed because someone decided to use some other flashy tool without realizing the security implications. If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends.
  - fadzlan 9y ago
    > If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends. Wouldn't that still be the same, considering ngrok is just doing the tunneling. In this case, ngrok is your trusty hoster. You can park your trust into your own VM in Digital Ocean, or you can park it at ngrok.
noway421 9y ago
Surely ngrok doesn't access repo directory and only acts as port forwarding tool. Haven't used it to be sure though, but that's what i'm getting from it.
- enraged_camel 9y ago
  This is correct. You still need to have a service listening on the port you have mapped ngrok to. So simply using ngrok is not a security risk.
  - philsnow 9y ago
    well, if you've exposed your dev app running on your laptop to the internet, any exploit in your app now works against your laptop endpoint instead of a production endpoint. your laptop is a very different environment from production: there are probably different protections, firewalls, monitoring, etc in place. additionally, while your laptop (hopefully) doesn't have direct access to production databases, you probably have stuff lying around that you wouldn't want an attacker to get their hands on: sensitive work documents, your Chrome cookies just sitting in a sqlite database somewhere, source code for all the repositories you have checked out locally (not just the one app that has the exploit). I don't agree that "using ngrok is not a security risk".
    - fny 9y ago
      What's the problem with exposing port 3000 to let someone demo an app for an hour? By the time someone discovers the exposed address and port, and then figures out how to exploit the service that's running, I'll have already shut down the service.
      - philsnow 9y ago
        true, maybe there's no problem for your use case. using something like ngrok is a gamble: if the only thing on the line is low-value things like whatever is on your personal laptop (or even whatever is on a spartan vanilla ubuntu VM that your app is running in), then maybe it's not a very big gamble. if the laptop has corporate secrets on it or it can be used as by an attacker to pivot into company internal systems through the VPN you're also connected to, however, that's a completely different story.

ageofwant 9y ago

If your users have to resort to this they are not getting the appropriate support they need. If your users are productive, chances are so is the company that pays both your salaries. If your users have to fight their infrastructure people to get their jobs done, you company will fail to effectively compete against those companies that don't. It astounds me that so few security people understand what their purpose is: Your purpose is to assist the company you work for to keep on existing, and even make a profit. If you disempower those that are most effective in helping the company do what it does you're effectively destroying your own livelihood, and everyone else that is dependent on it.

DonbunEf7 9y ago
Uh, no. The purpose of a security team is to prevent data from being exfiltrated from the company's control. Passwords, PII, HIPPA/other-compliance-controlled stuff, source code, etc. are all at risk of being stolen at all times, which means that security is a game of constant vigilance. And since everybody has at least a bit of this data under their control, this means that everybody is involved with security. (At least two of my past employers have had the motto, "Everybody is on the security team.") Productivity means nothing in the face of data exfiltration. You only have to fail once at guarding a password in order to be completely compromised. If we seem tightly wound, it's because we have fully internalized and grok the stakes of our efforts and the entailment of failure. "Our infrastructure sucked, so I used an insecure tool to leak our credentials to third parties, because I couldn't be productive otherwise!" is not really a valid excuse in this light, since there's no amount of productivity which offsets data exfiltration.
- vidarh 9y ago
  None of that matters to the company if in protecting it you tie staffs hands sufficient behind their back that the company fails. And you harm security if you're being sufficiently inflexible that staff see it as essential to circumvent your security measures to be able to do their job. Because they will almost certainly manage to do so. As such, if you hurt productivity enough, you are also going to be failing at protecting company data by making people find alternative solutions, and you're not likely to get permission to go far enough to stop it unless you're working in a field where security clearance is the norm.
- dsr_ 9y ago
  You're both right. If the dev team needs something like ngrok, the security team has failed to provide proper tools. If the dev team goes ahead and uses ngrok without consulting the security team, the dev team has likely committed an awful security breach. The dev team and the security team need to think of each other as being on the same team, and talk to each every day about what they want and need.
  - icedchai 9y ago
    Pretty sure a lot of people using this don't even have a "security team." They likely have corporate IT that takes 2 weeks to add a DNS entry. Something complex like mapping a public IP to a dev server would take an act of $DEITY.
    - philsnow 9y ago
      so register a new domain and set it up in route53? is there some corporate law that says you can't? just don't use your company's name in the domain name, make it something obscure.
      - icedchai 9y ago
        Agreed. I personally don't have this problem. I have all my externally accessible dev servers on AWS. However, others are not so lucky.
jlg23 9y ago
> If your users have to resort to this they are not getting the appropriate support they need. I don't see where this follows from. "private repos" and "testing" implies "local testing" for me. If that implication does not hold, the development workflow is seriously screwed. (Don't tell me there is no money for a local test setup when you have dedicated IT security.) And in my experience, more often than not, it is screwed because someone decided to use some other flashy tool without realizing the security implications. If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends.
- fadzlan 9y ago
  > If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends. Wouldn't that still be the same, considering ngrok is just doing the tunneling. In this case, ngrok is your trusty hoster. You can park your trust into your own VM in Digital Ocean, or you can park it at ngrok.

noway421 9y ago

Surely ngrok doesn't access repo directory and only acts as port forwarding tool. Haven't used it to be sure though, but that's what i'm getting from it.

enraged_camel 9y ago
This is correct. You still need to have a service listening on the port you have mapped ngrok to. So simply using ngrok is not a security risk.
- philsnow 9y ago
  well, if you've exposed your dev app running on your laptop to the internet, any exploit in your app now works against your laptop endpoint instead of a production endpoint. your laptop is a very different environment from production: there are probably different protections, firewalls, monitoring, etc in place. additionally, while your laptop (hopefully) doesn't have direct access to production databases, you probably have stuff lying around that you wouldn't want an attacker to get their hands on: sensitive work documents, your Chrome cookies just sitting in a sqlite database somewhere, source code for all the repositories you have checked out locally (not just the one app that has the exploit). I don't agree that "using ngrok is not a security risk".
  - fny 9y ago
    What's the problem with exposing port 3000 to let someone demo an app for an hour? By the time someone discovers the exposed address and port, and then figures out how to exploit the service that's running, I'll have already shut down the service.
    - philsnow 9y ago
      true, maybe there's no problem for your use case. using something like ngrok is a gamble: if the only thing on the line is low-value things like whatever is on your personal laptop (or even whatever is on a spartan vanilla ubuntu VM that your app is running in), then maybe it's not a very big gamble. if the laptop has corporate secrets on it or it can be used as by an attacker to pivot into company internal systems through the VPN you're also connected to, however, that's a completely different story.