5 ms·

Is this the result of the no-ops movement? Did people forget how to deploy software? I find it hard to believe somebody would run a database on publicly accessi

Is this the result of the no-ops movement? Did people forget how to deploy software? I find it hard to believe somebody would run a database on publicly accessible ip/port.

SCHiM 10y ago
For some reason redis thinks it's a good idea to listen on all interfaces by DEFAULT so you can perhaps understand why this happens. But I mean come on, what year is this. How often do we need to repeat that you need to use SECURE DEFAULTS! Short of that I find redis an nice piece of software, I only wish it was somewhat more sane in its default configuration.
- an_d_rew 10y ago
  In theory I totally agree with the concept of using secure defaults. In practice, however, I have seen far too many developers spend hour after hour trying to unwind a byzantine labyrinth of iptables and strange network configurations, weird firewall rules and corporate policies, never mind mangled DNS, to think that the correct solution is merely "secure defaults". At the end of the day, developers get paid to "make it work" and unfortunately that strongly incentivizes the "open by default" configuration mindset.
  - mtgx 10y ago
    Maybe developers should get paid "not to put us in the headlines with 1 billion accounts breached".
    - user5994461 10y ago
      Maybe developers should care about not having their companies in the headlines instead of just pushing things out as quickly as possible.
  - cookiecaper 10y ago
    Most developers past a certain seniority level know better than to run on a production database on a public interface without at least setting up good authentication. I think in many cases, it's just an issue of something slipping through the cracks. A few example scenarios where this can happen: one may open a port temporarily in testing before something goes live and forget to close it back up. Legacy applications may be dependent on certain services at certain ports and it may not be trivial to change those, or even add authentication to them. The whitelist rules allowing communication can get mangled or misconfigured, especially if the legacy application's IP jumps around; in frustration, an admin may set the rules too wide to try to encompass all potential IPs, assuming that no one in the same /16 is going to try to break in soon and they'll come back and fix this in like a week or something. One may spin up a test instance into a wide-open security group and assume that someone else is going to come through and sweep it up, and before you know it that test instance is hosting real data and no one has tried to clamp it down, or that firewall rules for that port are not necessary because the authentication/whitelisting will occur on the software side, and then fail to set that up correctly, or run an insecure version of the software. There's that old saying: "A person isn't stupid; people are". The constraints of the business often make it so that compromises have to be made and what we'd consider a "good solution" is politically intractable. No one likes that, but it's the environment many of us have to work in, like it or not. All we can do is scream at the wall until at least one exec goes through a traumatic security event. It usually takes a significant breach to scare the exec team straight.
- gselva 10y ago
  redis used to listen to all interfaces. The current stable release has fixed that. http://download.redis.io/redis-stable/redis.conf http://download.redis.io/redis-stable/redis.conf
- cookiecaper 10y ago
  Redis's "Protected Mode" was introduced a couple of years back iirc. It refuses to listen on anything besides localhost if you haven't configured authentication, unless you explicitly disable the protected mode flag. If you're using the version of redis packaged in trusty/universe, it is extremely old and doesn't contain this. It also contains a handful of critical security vulns that are being openly exploited in the wild. Update manually TODAY.
- deleted 10y ago
  [deleted]
- stevekemp 10y ago
  The default in Redis changed, as a result of active exploitation: https://kevinchen.co/blog/postmortem-server-compromised/ https://kevinchen.co/blog/postmortem-server-compromised/
mcs_ 10y ago
this is (maybe) because deployment is done by front-end engineers. don't get me wrong here, "lazy devops" is great and combined with cloud is just amazing (proc files, package files, ci files etc) i don't think people want run the database or the cache system or any other critical service as public, but probably the background is not enough to solve issues on production when they pops up so: 1. you deploy a service over cloud 2. everything works 3. but if something must be solved at infrastructure level 4. apply('old style solution') open everything and debug from home attached to production
rrdharan 10y ago
I think it's unfair to blame this on no-ops. People have found unsecured MySQL ports on the open internet for years dating back to the first LAMP stack deployments. And things like iSCSI targets, SMB shares, etc.
- mdekkers 10y ago
  bad-ops is of course also a thing, and mostly comes from the same mindset ("how hard can it be?", and "why do I pay so much for this stuff?"), but I personally believe that the concept of no-ops is hilarious. Treating infrastructure as code is fantastic, but developers and ops people have different priorities, skillsets and approaches. Neither are dispensable in any kind of serious environment.
  - uniclaude 10y ago
    Well, no ops is not really no ops, but more "Google/Amazon is paying ops people for me".
- stevekemp 10y ago
  Two years ago I was looking at rsync shares - still thousands of them out there, unsecured: https://blog.steve.fi/Secure_your_rsync_shares__please_.html https://blog.steve.fi/Secure_your_rsync_shares__please_.html
  - achillean 10y ago
    There's still a lot of rsync out there (~160,000): https://www.shodan.io/search?query=rsyncd https://www.shodan.io/search?query=rsyncd
user5994461 10y ago
> Did people forget how to deploy software? People never knew how to deploy software. Are there even guides to learn that? Seems not.

Is this the result of the no-ops movement? Did people forget how to deploy software? I find it hard to believe somebody would run a database on publicly accessible ip/port.

SCHiM 10y ago

For some reason redis thinks it's a good idea to listen on all interfaces by DEFAULT so you can perhaps understand why this happens. But I mean come on, what year is this. How often do we need to repeat that you need to use SECURE DEFAULTS! Short of that I find redis an nice piece of software, I only wish it was somewhat more sane in its default configuration.

an_d_rew 10y ago
In theory I totally agree with the concept of using secure defaults. In practice, however, I have seen far too many developers spend hour after hour trying to unwind a byzantine labyrinth of iptables and strange network configurations, weird firewall rules and corporate policies, never mind mangled DNS, to think that the correct solution is merely "secure defaults". At the end of the day, developers get paid to "make it work" and unfortunately that strongly incentivizes the "open by default" configuration mindset.
- mtgx 10y ago
  Maybe developers should get paid "not to put us in the headlines with 1 billion accounts breached".
  - user5994461 10y ago
    Maybe developers should care about not having their companies in the headlines instead of just pushing things out as quickly as possible.
- cookiecaper 10y ago
  Most developers past a certain seniority level know better than to run on a production database on a public interface without at least setting up good authentication. I think in many cases, it's just an issue of something slipping through the cracks. A few example scenarios where this can happen: one may open a port temporarily in testing before something goes live and forget to close it back up. Legacy applications may be dependent on certain services at certain ports and it may not be trivial to change those, or even add authentication to them. The whitelist rules allowing communication can get mangled or misconfigured, especially if the legacy application's IP jumps around; in frustration, an admin may set the rules too wide to try to encompass all potential IPs, assuming that no one in the same /16 is going to try to break in soon and they'll come back and fix this in like a week or something. One may spin up a test instance into a wide-open security group and assume that someone else is going to come through and sweep it up, and before you know it that test instance is hosting real data and no one has tried to clamp it down, or that firewall rules for that port are not necessary because the authentication/whitelisting will occur on the software side, and then fail to set that up correctly, or run an insecure version of the software. There's that old saying: "A person isn't stupid; people are". The constraints of the business often make it so that compromises have to be made and what we'd consider a "good solution" is politically intractable. No one likes that, but it's the environment many of us have to work in, like it or not. All we can do is scream at the wall until at least one exec goes through a traumatic security event. It usually takes a significant breach to scare the exec team straight.
gselva 10y ago
redis used to listen to all interfaces. The current stable release has fixed that. http://download.redis.io/redis-stable/redis.conf http://download.redis.io/redis-stable/redis.conf
cookiecaper 10y ago
Redis's "Protected Mode" was introduced a couple of years back iirc. It refuses to listen on anything besides localhost if you haven't configured authentication, unless you explicitly disable the protected mode flag. If you're using the version of redis packaged in trusty/universe, it is extremely old and doesn't contain this. It also contains a handful of critical security vulns that are being openly exploited in the wild. Update manually TODAY.
deleted 10y ago
[deleted]
stevekemp 10y ago
The default in Redis changed, as a result of active exploitation: https://kevinchen.co/blog/postmortem-server-compromised/ https://kevinchen.co/blog/postmortem-server-compromised/

mcs_ 10y ago

this is (maybe) because deployment is done by front-end engineers. don't get me wrong here, "lazy devops" is great and combined with cloud is just amazing (proc files, package files, ci files etc) i don't think people want run the database or the cache system or any other critical service as public, but probably the background is not enough to solve issues on production when they pops up so: 1. you deploy a service over cloud 2. everything works 3. but if something must be solved at infrastructure level 4. apply('old style solution') open everything and debug from home attached to production

rrdharan 10y ago

I think it's unfair to blame this on no-ops. People have found unsecured MySQL ports on the open internet for years dating back to the first LAMP stack deployments. And things like iSCSI targets, SMB shares, etc.

mdekkers 10y ago
bad-ops is of course also a thing, and mostly comes from the same mindset ("how hard can it be?", and "why do I pay so much for this stuff?"), but I personally believe that the concept of no-ops is hilarious. Treating infrastructure as code is fantastic, but developers and ops people have different priorities, skillsets and approaches. Neither are dispensable in any kind of serious environment.
- uniclaude 10y ago
  Well, no ops is not really no ops, but more "Google/Amazon is paying ops people for me".
stevekemp 10y ago
Two years ago I was looking at rsync shares - still thousands of them out there, unsecured: https://blog.steve.fi/Secure_your_rsync_shares__please_.html https://blog.steve.fi/Secure_your_rsync_shares__please_.html
- achillean 10y ago
  There's still a lot of rsync out there (~160,000): https://www.shodan.io/search?query=rsyncd https://www.shodan.io/search?query=rsyncd

user5994461 10y ago

> Did people forget how to deploy software? People never knew how to deploy software. Are there even guides to learn that? Seems not.