On Thu, Mar 1, 2018 at 3:18 PM, Owen DeLong <o...@delong.com> wrote: > I don’t agree that making RFC-1918 limitations a default in any daemon > makes any > sense whatsoever. > > First, there are plenty of LANs out there that don’t use RFC-1918. > > Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly > anyone > uses ULA (the IPv6 analogue to RFC-1918). > > I do agree that listening on all addresses might not be the best default, > but > building assumptions about RFC-1918 into anything (other than the > assumption > that they’re generally a pretty bogus way to do IP) makes little sense to > me. > > this is sort of why openbsd listens only on 127.0.0.1/::1 by default, right? it's the only sane choice for 'fresh out of the box' network daemons: "Yes, it's running, yes I can healthcheck it locally to prove it's running"
> Owen > > > On Mar 1, 2018, at 10:32 AM, Eric Kuhnke <eric.kuh...@gmail.com> wrote: > > > > On the other side: VM/VPS providers have a template based image that they > > use for every type and subtype of operating system it's possible to > > auto-provision. For example Ubuntu Server Xenial AMD64 or Debian Jessie > or > > Stretch AMD64. > > > > It's important that VM/VPS providers don't push fresh images that have > > anything vulnerable, abusable or exploitable enabled by default. Not all > > VM/VPS providers do this. Standard sane configuration choices apply such > as > > bind9 not being a recursive resolver by default. > > > > If individual Debian, CentOS, Ubuntu or whatever other distro packages > for > > memcached or any other daemon have "listen on all interfaces = yes" or > > "listen on non-RFC1918 IP ranges = yes" turned on in their respective > > configurations, that would be an issue to take up with the package > > maintainers for the daemons. > > > > > > > > On Wed, Feb 28, 2018 at 4:31 AM, Job Snijders <j...@ntt.net> wrote: > > > >> Dear all, > >> > >> Before the group takes on the pitchforks and torches and travels down to > >> the hosting providers' headquarters - let's take a step back and look at > >> the root of this issue: the memcached software has failed both the > >> Internet community and its own memcached users. > >> > >> It is INSANE that memcached is/was[1] shipping with default settings > >> that make the daemon listen and respond on UDP on INADDR_ANY. Did nobody > >> take notes during the protocol wars where we were fodder for all the > >> CHARGEN & NTP ordnance? > >> > >> The memcached software shipped with a crazy default that required no > >> authentication - allowing everyone to interact with the daemon. This is > >> an incredibly risky proposition for memcached users from a > >> confidentiality perspective; and on top of that the amplification factor > >> is up to 15,000x. WHAT?! > >> > >> And this isn't even new information, open key/value stores have been a > >> security research topic for a number of years, these folks reported that > >> in the 2015/2016 time frame they observed more than 100,000 open > >> memcached instances: https://aperture-labs.org/pdf/safeconf16.pdf > >> > >> Vendors need to ensure that a default installation of their software > >> does not pose an immediate liability to the user itself and those around > >> them. No software is deployed in a vacuum. > >> > >> A great example of how to approach things is the behavior of the > >> PowerDNS DNS recursor: this recursor - out of the box - binds to only > >> 127.0.0.1, and blocks queries from RFC 1918 space. An operator has to > >> consciously perform multiple steps to make it into the danger zone. > >> This is how things should be. > >> > >> Kind regards, > >> > >> Job > >> > >> [1]: https://github.com/memcached/memcached/commit/ > >> dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 > >> > >> ps. promiscuous defaults are bad, mmkay? > >> Ask your BGP vendor for RFC 8212 support today! :-) > >> > >
