Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Harald Koch]

On 1 March 2018 at 18:48, Mark Andrews  wrote:

> ULA provide stable internal addresses which survive changing ISP
> for the average home user.


Yeah this is pretty much what I'm doing. ULA for stable, internal addresses
that I can put into the (internal) DNS: ISP prefixes for global routing.
Renumbering is hard.

All of the objections I've seen to ULA are actually objections to (IPv6)
NAT, which is why I was confused.

(As it turns out my ISP prefix has been static for years, but I'm too lazy
to undo all of the work...)

-- 
Harald

Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Mark Andrews]

> On 2 Mar 2018, at 11:48 am, Matt Erculiani  wrote:
> 
> Not sure if this is the common thought, but if anyone has a network
> which requires static IP assignments, they can probably justify a
> request for a /48 from an RIR.  After all, ARIN's requirement for an
> end-user IPv6 block is, at minimum: "Justify why IPv6 addresses from
> an ISP or other LIR are unsuitable". I would think that ISP
> portability would satisfy this requirement, but If I'm wrong, I'm
> absolutely open to being corrected on this. But most home users have
> no need for static IPs, so the dynamic ISP assignment is perfectly
> fine.

ISP assigned addresses are perfectly fine for TALKING TO THE REST OF THE WORLD.
ISP assigned addresses are not perfectly fine for internal communication.

With IPv6 you use ULA along side ISP assigned addresses.

With IPv4 RFC 1918 address + NAT the home user has STATIC local addresses
for devices that need them.  Go look at your home router’s web pages.  You
will be able to assign static addresses to your internal machines via DHCP.

Are YOU going to tell everyone that sets values there that they no longer
can do the same thing for IPv6.  That they need to fully renumber all their
devices just because the ISP gave them a different prefix this morning?

> I think the tech will advance fast enough that keeping up with an IPv6
> route table will be a non-issue. IPv6 adoption is, unfortunately, slow
> enough that there will be no issues keeping up, even assuming a "slow"
> hardware refresh cycle.
> 
> -M
> 
> On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews  wrote:
>> 
>>> On 2 Mar 2018, at 9:28 am, Owen DeLong  wrote:
>>> 
>>> 
 On Mar 1, 2018, at 1:20 PM, Harald Koch  wrote:
 
 On 1 March 2018 at 15:18, Owen DeLong > wrote:
 Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly 
 anyone
 uses ULA (the IPv6 analogue to RFC-1918).
 
 Wait. What's the objection to ULA? Is it just that NAT is bad, or is there 
 something new?
>>> 
>>> No particular objection, but I don’t see the point.
>>> 
>>> What can you do with ULA that GUA isn’t suitable for?
>>> 
>>> Owen
>> 
>> ULA provide stable internal addresses which survive changing ISP
>> for the average home user. Now, I know you can do the same thing
>> by going to a RIR and getting a prefix but the RIR’s aren’t setup
>> to supply prefixes like that to 10 billion of us.
>> 
>> They are also in a specific range which makes setting filtering
>> rules easier for everyone else.
>> 
>> Now I would love it if we could support 100 billion routes in the
>> DFZ but we aren’t anywhere near being able to do that which would
>> be a requirement for abandoning ULA.  Until them they have there
>> place.
>> 
>> Mark
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Randy Bush]

hyperbole.  sad and embarrassing to say, but it’s just another damned 
day of the internet security rolling disaster.  there will be more.  
there will be worse.  and screaming wolf will only make folk inured 
(excuse the american idiom).


randy

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Jippen]

The problem here is that you're not being shot in the foot, you're moving a
semi full of ammo and parking it in front of my building. Collateral damage
from other people being lazy with their servers is a pain.

Oh, and this was used to set a new high water mark for 'Biggest DDoS'
against github. 1.5 Tbps. So, its a pretty big deal. And that ignoring the
additional vulnurability from just getting everything useful out of the
memcached server, or continuously clearing the server to damage performance
of the app relying on it.

If your gun's default aiming position is at your foot, then there's a good
argument to change the default. It doesn't solve the problem, but it helps.

On Thu, Mar 1, 2018 at 3:51 PM, Randy Bush  wrote:

> > The defaults for Zimbra seem to be to listen everywhere all the time.
> > amidst all the hysterical pontification, i am having trouble finding any
> > release which has, by default, a port 11211 listener on any interface.
>
> sorry, i should have said "any operating system release"
>
> yes, you can install memcached
>
> yes, you can install some j random container which has memcached
>
> yes, you can shoot yourself in the foot; welcome to the internet
>
> my point was merely that the hysteria and grandstanding can cost a lot
> of ops a bunch of time.  and folk should be aware that normal, simple,
> vanilla environments will not be a source of reflection.
>
> of course, they might be a target :)
>
> randy
>

dnswl.org contact

[Randy Bush]

anyone have contact with the dnswl.org folk?

my calendar says that it is the time of year i owe them some money, and
i can not seem to pay them.

randy

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Randy Bush]

> The defaults for Zimbra seem to be to listen everywhere all the time. 
> amidst all the hysterical pontification, i am having trouble finding any 
> release which has, by default, a port 11211 listener on any interface. 

sorry, i should have said "any operating system release"

yes, you can install memcached

yes, you can install some j random container which has memcached

yes, you can shoot yourself in the foot; welcome to the internet

my point was merely that the hysteria and grandstanding can cost a lot
of ops a bunch of time.  and folk should be aware that normal, simple,
vanilla environments will not be a source of reflection.

of course, they might be a target :)

randy

Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Mark Andrews]

> On 2 Mar 2018, at 9:28 am, Owen DeLong  wrote:
> 
> 
>> On Mar 1, 2018, at 1:20 PM, Harald Koch  wrote:
>> 
>> On 1 March 2018 at 15:18, Owen DeLong > > wrote:
>> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly 
>> anyone
>> uses ULA (the IPv6 analogue to RFC-1918).
>> 
>> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there 
>> something new?
> 
> No particular objection, but I don’t see the point.
> 
> What can you do with ULA that GUA isn’t suitable for?
> 
> Owen

ULA provide stable internal addresses which survive changing ISP
for the average home user. Now, I know you can do the same thing
by going to a RIR and getting a prefix but the RIR’s aren’t setup
to supply prefixes like that to 10 billion of us.

They are also in a specific range which makes setting filtering
rules easier for everyone else.

Now I would love it if we could support 100 billion routes in the
DFZ but we aren’t anywhere near being able to do that which would
be a requirement for abandoning ULA.  Until them they have there
place.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Royce Williams]

On Thu, Mar 1, 2018 at 1:38 PM, Randy Bush  wrote:
>
> > 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"
>
> amidst all the hysterical pontification, i am having trouble finding any
> release which has, by default, a port 11211 listener on any interface.


... for people using the OS package, and not compiling from source.

Upstream, until two days ago, the default was to listen on all interfaces.

https://github.com/memcached/memcached/wiki/ReleaseNotes156

The package maintainers were (thankfully) injecting additional sanity.

Royce

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Mike Hammett]

The defaults for Zimbra seem to be to listen everywhere all the time. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Randy Bush"  
To: "Christopher Morrow"  
Cc: "North American Network Operators' Group"  
Sent: Thursday, March 1, 2018 4:38:05 PM 
Subject: Re: New Active Exploit: memcached on port 11211 UDP & TCP being 
exploited for reflection attacks 

> 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" 

amidst all the hysterical pontification, i am having trouble finding any 
release which has, by default, a port 11211 listener on any interface. 

randy 

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Christopher Morrow]

On Thu, Mar 1, 2018 at 5:50 PM, Christopher Morrow 
wrote:

> pre install of memcache on a (debianXXX)
>

$ cat /etc/debian_version
9.3

(cut/paste fail before click-submit)


> Abort.
> morrowc@build:~$ netstat -anA inet | grep LIST
> tcp0  0 192.110.255.61:53   0.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:530.0.0.0:*
>  LISTEN
> tcp0  0 0.0.0.0:22  0.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:5432  0.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:953   0.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:250.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:5433  0.0.0.0:*
>  LISTEN
>
>
> run:
> apt-get install memcached
>
> now:
> morrowc@build:~$ netstat -anA inet | grep LIST
> tcp0  0 192.110.255.61:53   0.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:530.0.0.0:*
>  LISTEN
> tcp0  0 0.0.0.0:22  0.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:5432  0.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:953   0.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:250.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:5433  0.0.0.0:*
>  LISTEN
> tcp0  0 127.0.0.1:11211 0.0.0.0:*
>  LISTEN
>
>
> fargh.
>
> On Thu, Mar 1, 2018 at 5:38 PM, Randy Bush  wrote:
>
>> > 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"
>>
>> amidst all the hysterical pontification, i am having trouble finding any
>> release which has, by default, a port 11211 listener on any interface.
>>
>> randy
>>
>
>

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Christopher Morrow]

pre install of memcache on a (debianXXX)
Abort.
morrowc@build:~$ netstat -anA inet | grep LIST
tcp0  0 192.110.255.61:53   0.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN

tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:5432  0.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:953   0.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:250.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:5433  0.0.0.0:*   LISTEN



run:
apt-get install memcached

now:
morrowc@build:~$ netstat -anA inet | grep LIST
tcp0  0 192.110.255.61:53   0.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN

tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:5432  0.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:953   0.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:250.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:5433  0.0.0.0:*   LISTEN

tcp0  0 127.0.0.1:11211 0.0.0.0:*   LISTEN



fargh.

On Thu, Mar 1, 2018 at 5:38 PM, Randy Bush  wrote:

> > 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"
>
> amidst all the hysterical pontification, i am having trouble finding any
> release which has, by default, a port 11211 listener on any interface.
>
> randy
>

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Randy Bush]

> 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"

amidst all the hysterical pontification, i am having trouble finding any
release which has, by default, a port 11211 listener on any interface.

randy

Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Owen DeLong]

> On Mar 1, 2018, at 1:20 PM, Harald Koch  wrote:
> 
> On 1 March 2018 at 15:18, Owen DeLong  > wrote:
> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly anyone
> uses ULA (the IPv6 analogue to RFC-1918).
> 
> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there 
> something new?

No particular objection, but I don’t see the point.

What can you do with ULA that GUA isn’t suitable for?

Owen

IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Harald Koch]

On 1 March 2018 at 15:18, Owen DeLong  wrote:

> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly
> anyone
> uses ULA (the IPv6 analogue to RFC-1918).
>

Wait. What's the objection to ULA? Is it just that NAT is bad, or is there
something new?

-- 
Harald

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Christopher Morrow]

On Thu, Mar 1, 2018 at 3:18 PM, Owen DeLong  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  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  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! :-)
> >>
>
>

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Owen DeLong]

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.

Owen

> On Mar 1, 2018, at 10:32 AM, Eric Kuhnke  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  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! :-)
>> 

[NANOG-announce] Program Committee appointments

[Ryan Donnelly]

*Greetings, fellow NANOG enthusiasts,I’m pleased to announce that the board
has appointed 11 individuals to the Program Committee. As always, making
these appointments is an exercise in difficult choices; and these
appointments were made especially challenging by this cycle’s 18
highly-qualified applicants.We are, at our core, a volunteer organization.
It is through the interest and commitment of volunteers like these that we
are able to deliver the exceptional program quality expected by our
members, attendees and sponsors. We’d like to thank each of the 18
individuals that applied, and for those not selected, we would be delighted
to entertain your candidacy during the next appointment cycle.The 11
members appointed to the Program Committee are:Vincent Celindro, Michaela
Clifford, Michael Costello, Philippe Couture, Tom Kacprzynski, Ognian
Mitev, Chris Pennisi, Steven Schechter, Benson Schliesser, Edward Winstead,
Chris WoodfieldPlease join me in congratulating them.We’d also like to
thank and recognize the contributions of Kevin Blumberg, Anna Claiborne,
Allison Feese-Strickland, Steve Plote, Dani Roisman, Michael K. Smith, and
Jesse Sowell for their service on the Program Committee.In the coming
weeks, the new Program Committee will hold its first meeting and select a
chair and a vice chair.I know I speak for the rest of the board when I say
that we can’t wait to experience the output of our new PC in Denver for
NANOG 73.See you in June!Best Regards,--ryan(for the NANOG Board of
Directors)*
___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Eric Kuhnke]

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  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! :-)
>

ALTDB maintainer creation

[Jacob Slater]

Hello all,

Any chance anyone has a contact for any of the ALTDB admins? I put in
a maintainer creation request several months ago and haven't heard
back.

Working with an upstream who will only take ALTDB or LOAs and would
like to avoid having to due LOAs in the future.

Thanks all,
Jacob Slater