5 ms·

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 ye

by 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/

by SCHiM 10y ago

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/