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

[Michel 'ic' Luczak]

The ones I know do so on private VLANs (or ATM circuits on DSL) so anyway 
unrelated to any client’s address space. Also, french triple play ISPs use 
RFC1918 space for IPTV but again isolated of any customer network so doesn’t 
really matter.

> On 2 Mar 2018, at 22:18, K. Scott Helms  wrote:
> 
> I won't comment on the sanity of doing so, but _many_ service providers use
> EMTAs, ATAs, and other voice devices over RFC1918 space back to their core.
> 

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

[John Levine]

In article  you write:
>What can you do with ULA that GUA isn’t suitable for?

I have a home network with two segments, one wired and one wireless.
It has IPv6 addresses assigned by my ISP, Spectrum nee TWC, which
probably won't change but who knows, they make no promises.  I have
some servers on my network, like printers, scanners, backup disks, and a
phone TA.  Getting my own /48 would be absurd.  ULAs are just the
ticket.

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

[K. Scott Helms]

They use separate service flows and layer 3 interfaces (usually) in DOCSIS
networks but they often use the same DNS infrastructure which is why I
piped up.

Scott Helms


On Mar 2, 2018 4:46 PM, "Michel 'ic' Luczak"  wrote:

The ones I know do so on private VLANs (or ATM circuits on DSL) so anyway
unrelated to any client’s address space. Also, french triple play ISPs use
RFC1918 space for IPTV but again isolated of any customer network so
doesn’t really matter.

> On 2 Mar 2018, at 22:18, K. Scott Helms  wrote:
>
> I won't comment on the sanity of doing so, but _many_ service providers
use
> EMTAs, ATAs, and other voice devices over RFC1918 space back to their
core.
>

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

[K. Scott Helms]

I won't comment on the sanity of doing so, but _many_ service providers use
EMTAs, ATAs, and other voice devices over RFC1918 space back to their core.

On Fri, Mar 2, 2018 at 4:11 PM, Mark Andrews  wrote:

> Are you insane. ISPs should never use RFC 1918 addresses for stuff that
> talks to their customers.  They have no way of knowing which addresses the
> customers are using.
>
> Traffic from RFC 1918 addresses should be dropped by any sane border
> router which all routers connecting to a ISP are.
>
> --
> Mark Andrews
>
> > On 2 Mar 2018, at 22:49, Bjørn Mork  wrote:
> >
> > Owen DeLong  writes:
> >
> >> I don’t agree that making RFC-1918 limitations a default in any daemon
> makes any
> >> sense whatsoever.
> >
> > +1
> >
> > One of the more annoying anti-features I know of in this regard is the
> > dnsmasq rebind "protection".  It claims to protect web browsers on the
> > LAN against DNS rebind attacks.  But the implementation does not
> > consider which adresses are used on the LAN at all.  It simply blocks
> > any A record pointing to an RFC1918 address, making a few bogus
> > assumptions:
> > - IPv4 LAN addresses are selected from RFC1918
> > - RFC1918 addresses are never used on the WAN side of a CPE
> > - Noone use IPv6 on their LAN
> >
> > It's hard to know how many users have been bitten by the first
> > one. You'd have to depend on this rebind "protection" in the first
> > place, and that would be stupid.
> >
> > But the second assumption regularily bites end users when their ISP
> > provides some ISP internal service using RFC1918 addresses.  Which of
> course
> > is fine.
> >
> > The anti-feature has been enabled by default in OpenWrt for a long time,
> > ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that
> > there is a large user base having this enabled without knowing.
> >
> >> First, there are plenty of LANs out there that don’t use RFC-1918.
> >>
> >> Second, RFC-1918 doesn’t apply to IPv6 at all,
> >
> > Could you try to explain that to the OpenWrt guys?  Thanks
> >
> >
> >
> > Bjørn
>
>

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

[Mark Andrews]

Are you insane. ISPs should never use RFC 1918 addresses for stuff that talks 
to their customers.  They have no way of knowing which addresses the customers 
are using.

Traffic from RFC 1918 addresses should be dropped by any sane border router 
which all routers connecting to a ISP are. 

-- 
Mark Andrews

> On 2 Mar 2018, at 22:49, Bjørn Mork  wrote:
> 
> Owen DeLong  writes:
> 
>> I don’t agree that making RFC-1918 limitations a default in any daemon makes 
>> any
>> sense whatsoever.
> 
> +1
> 
> One of the more annoying anti-features I know of in this regard is the
> dnsmasq rebind "protection".  It claims to protect web browsers on the
> LAN against DNS rebind attacks.  But the implementation does not
> consider which adresses are used on the LAN at all.  It simply blocks
> any A record pointing to an RFC1918 address, making a few bogus
> assumptions:
> - IPv4 LAN addresses are selected from RFC1918
> - RFC1918 addresses are never used on the WAN side of a CPE
> - Noone use IPv6 on their LAN
> 
> It's hard to know how many users have been bitten by the first
> one. You'd have to depend on this rebind "protection" in the first
> place, and that would be stupid.
> 
> But the second assumption regularily bites end users when their ISP
> provides some ISP internal service using RFC1918 addresses.  Which of course
> is fine.
> 
> The anti-feature has been enabled by default in OpenWrt for a long time,
> ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that
> there is a large user base having this enabled without knowing.
> 
>> First, there are plenty of LANs out there that don’t use RFC-1918.
>> 
>> Second, RFC-1918 doesn’t apply to IPv6 at all,
> 
> Could you try to explain that to the OpenWrt guys?  Thanks
> 
> 
> 
> Bjørn

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

[Matt Erculiani]

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.

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
>

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

[Stephen Satchell]

On 03/01/2018 02:55 PM, Royce Williams wrote:

pstream, 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.


Yes, they did, in commit dbb7a8af.  Here is the commit comment:


disable UDP port by default

As reported, UDP amplification attacks have started to use insecure

internet-exposed memcached instances. UDP used to be a lot more popular as a
transport for memcached many years ago, but I'm not aware of many recent
users.

Ten years ago, the TCP connection overhead from many clients was relatively

high (dozens or hundreds per client server), but these days many clients are
batched, or user fewer processes, or simply anre't worried about it.

While changing the default to listen on localhost only would also help, the

true culprit is UDP. There are many more use cases for using memcached over
the network than there are for using the UDP protocol.

- memcached.c -
index 88a5f2e..7178666 100644


But then you look at the changes in that commit:  what makes this a 
less-than-ideal change is that they didn't modify the default 
configuration file to include "-U 0".


By defaulting their settings.udpport to zero in the C code, they 
stop-punch the astonishment factor.  By not changing the distribution 
sysconfig file, though, they open a pitfall for those people who use 
UDP.  The problem?  They could have put a warning in the default file so 
that people who add OPTIONS="U 11211" would be told to firewall that UDP 
port from the public internet at large.


(Then there is the case of people deploying memcached in the cloud, 
which would incur additional difficulties.  But that's another argument...)

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

[Stephen Satchell]

Testing on a recently-load VM of CentOS 7.3:

[root@localhost odd]# netstat -tan | grep 11211
[root@localhost odd]# netstat -uan | grep 11211
[root@localhost odd]# yum install memcached
[root@localhost odd]# systemctl start memcached.service
[root@localhost odd]# netstat -tan | grep 11211
tcp0  0 0.0.0.0:11211   0.0.0.0:*   LISTEN
tcp6   0  0 :::11211:::*LISTEN
[root@localhost odd]# netstat -uan | grep 11211
udp0  0 0.0.0.0:11211   0.0.0.0:* 

udp6   0  0 :::11211:::* 



Since CentOS is supposed to be a near bit-by-bit copy of Red Hat 
Enterprise, this shows that when one loads memcached without modifying 
the configuration, plus expose 11211/udp to the world, one is now part 
of the problem.


It also suggests that other near-clones of RHEL may also exhibit the 
problem.


So I pulled the memcached repository from GitHub, and looked through the 
commits. NOTHING about updates to prevent DDoS.


So I started looking around for the config file in the maintainer GIT 
project.  Here is what I found:



# These defaults will be used by every memcached instance, unless overridden
# by values in /etc/sysconfig/memcached.
USER="nobody"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS=""

# The PORT variable will only be used by memcached.service, not by
# memcached@x services, which will use the x
PORT="11211"


Here is what CentOS has:


PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS=""


What's missing from both of these system configuration files?

OPTIONS="-U 0"

From the memcached man page:


-U 
   Listen on UDP port , the default is port 11211, 0 is off.


So this answers the question about how anyone loading memcached fresh 
from a distribution can be a major player in the DDoS game.


Now, in a lame defense of Red Hat, when one turns on the firewalld 
daemon, that daemon implements a mostly-closed access policy. 
"memcached" is not listed in the named services.  Furthermore, looking 
at the output of 'iptables -vnL' I saw no way that a 11211/udp packet 
would make its way through the firewall.


The policy of "defense in depth" would argue that setting the default to 
disable 11211/udp is still the right thing(r) to do.

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 2, 2018, at 19:25, Bjørn Mork  wrote:
> 
> Owen DeLong  writes:
> 
>>> On Mar 2, 2018, at 3:17 AM, Bjørn Mork  wrote:
>>> 
>>> Owen DeLong  writes:
>>> 
 What can you do with ULA that GUA isn’t suitable for?
>>> 
>>> 1) get
>>> 2) keep
>>> 3) move
>> 
>> Wrong.
>> 
>> 1) get
>>Easy as going to http://tunnelbroker.net  and 
>> filling out a form. Remember to check the box for your /48.
> 
> Provided you have IPv4 connectivity and an email address you can and
> will associate with the tunnel/prefix.  You are limiting the scope here.
> 

Having an email address is a pretty low bar. You don’t need to actually set up 
the tunnel, so all you need is an ipv4 address that answers Icmp echo. Also not 
hard to come by. 


>> 2) keep
>>Admittedly, you might have to connect to your tunnel every once in a 
>> while to keep it alive, but that’s
>>hardly a high bar.
> 
> Depends.  How about preconfigured devices in storage?  There are a
> number of use cases where outside connectivity does not matter, and
> where depending on regular connections will complicate stuff.

You don’t have to connect from the devices using the addresses, you just need 
to connect. A simple laptop will do. 


> 
>> 3) move
>>If you’re not talking to the internet with it (which you can’t with ULA, 
>> theoretically), you can move that same
>>HE /48 anywhere you want, with the additional advantage that you can, if 
>> you need to, connect your tunnel
>>and actually make it work on the internet too.
> 
> Sure. There is also a long tradition in IPv4 for "borrowing" someone
> elses addresses.  It is never a good idea.  You or anyone else cannot
> make any guarantee about HE address availability at any point in time or
> space.

Meh... if you’re concerned about that, get the addresses from an RIR. Some 
people think $100/year is a barrier, so I proposed a free alternative. 
> 
> You may also want to consider https://www.tunnelbroker.net/tos.php

Last time I read it, it didn’t preclude what I’m suggesting. It may have been 
updated, but if it was, I bet there are still workarounds within the TOS. 

> 
> 
>>> Granted, many of us can do that with GUAs too.  But with ULA those
>>> features are avaible to everyone everywhere.  Which is useful for a
>> 
>> You really think that doing ULA according to the RFCs (collision
>> avoidance algorithm and all) is easier than filling out a form at HE?
>> REALLY?
> 
> Yes.
> 
> You are comparing apples and orange seeds.  If you don't want to
> construct your tunnel from the RFCs, then you cannot require ULA users
> to start there either,

I wasn’t proposing actually constructing a tunnel at all. Merely using the 
tunnel as a way to get a /48 for free. 

I wasn’t requiring the Ilan user to start from the RFCs, but specifying that 
the had to comply with them. 

The calculator is a slightly shorter form, I’ll grant you, but it doesn’t 
strike me as substantially easier. 

> 
> The ULA equivalent of the HE tunnel form is an ULA calculator. E.g
> http://www.kame.net/~suz/gen-ula.html
> 
> Which is much simpler.  At least it looks simpler to me.
> 
> But it doesn't really matter.  The main point is that ULAs are usable in
> many cases where HE (or other ISP allocated) GUAs are not. If you don't
> care about Internet connectivity, then ULAs are as good as PI GUA space.

My point is that in that case GUA is as good as ULA too. ULA offers no 
advantage. It’s just a waste of a /7. 

> 
> Believe it or not, but there are still devices and networks where
> Internet connectivity is either optional or even unwanted.  These
> devices and networks still need addresses for their internal
> communcation.

Never denied that. I have some at home. They have /64s carved out of my /48 and 
work just fine. 


> 
>>> number of applications where you care mostly about the local environment
>>> and not so much about global connectivity.
>> 
>> I hear you, but I’m not convinced about the ease.
> 
> When was the last time you saw a non RFC1918 address in a consumer
> equipment setup guide?  If we consider the distant future where IPv4 is
> long dead and buried, what is default configuration URL is going to
> replace http://192.168.1.1/ and similar?

One would home something less brain-dead like http://config.local

If your asking about what prefix should be used in examples, well, that’s what 
we have 2001:db8::/32 for. 

> 
> IoT might be a thing for a while until people start worrying about where
> they store their data.  I'm sure local sensor networks will become
> popular again once the hype is over.
> 
> Many ISPs make more money on providing network accesses which are
> isolated from the Internet than actually providing Internet access
> 
> More and more systems are made up of networked subsystems.  Take a look
> at your average core router for example. These susbsystems need
> addresses.  But you rarely want 

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

[Bjørn Mork]

Owen DeLong  writes:

>> On Mar 2, 2018, at 3:17 AM, Bjørn Mork  wrote:
>> 
>> Owen DeLong  writes:
>> 
>>> What can you do with ULA that GUA isn’t suitable for?
>> 
>> 1) get
>> 2) keep
>> 3) move
>
> Wrong.
>
> 1) get
>   Easy as going to http://tunnelbroker.net  and 
> filling out a form. Remember to check the box for your /48.

Provided you have IPv4 connectivity and an email address you can and
will associate with the tunnel/prefix.  You are limiting the scope here.

> 2) keep
>   Admittedly, you might have to connect to your tunnel every once in a 
> while to keep it alive, but that’s
>   hardly a high bar.

Depends.  How about preconfigured devices in storage?  There are a
number of use cases where outside connectivity does not matter, and
where depending on regular connections will complicate stuff.

> 3) move
>   If you’re not talking to the internet with it (which you can’t with 
> ULA, theoretically), you can move that same
>   HE /48 anywhere you want, with the additional advantage that you can, 
> if you need to, connect your tunnel
>   and actually make it work on the internet too.

Sure. There is also a long tradition in IPv4 for "borrowing" someone
elses addresses.  It is never a good idea.  You or anyone else cannot
make any guarantee about HE address availability at any point in time or
space.

You may also want to consider https://www.tunnelbroker.net/tos.php


>> Granted, many of us can do that with GUAs too.  But with ULA those
>> features are avaible to everyone everywhere.  Which is useful for a
>
> You really think that doing ULA according to the RFCs (collision
> avoidance algorithm and all) is easier than filling out a form at HE?
> REALLY?

Yes.

You are comparing apples and orange seeds.  If you don't want to
construct your tunnel from the RFCs, then you cannot require ULA users
to start there either,

The ULA equivalent of the HE tunnel form is an ULA calculator. E.g
http://www.kame.net/~suz/gen-ula.html

Which is much simpler.  At least it looks simpler to me.

But it doesn't really matter.  The main point is that ULAs are usable in
many cases where HE (or other ISP allocated) GUAs are not. If you don't
care about Internet connectivity, then ULAs are as good as PI GUA space.

Believe it or not, but there are still devices and networks where
Internet connectivity is either optional or even unwanted.  These
devices and networks still need addresses for their internal
communcation.

>> number of applications where you care mostly about the local environment
>> and not so much about global connectivity.
>
> I hear you, but I’m not convinced about the ease.

When was the last time you saw a non RFC1918 address in a consumer
equipment setup guide?  If we consider the distant future where IPv4 is
long dead and buried, what is default configuration URL is going to
replace http://192.168.1.1/ and similar?

IoT might be a thing for a while until people start worrying about where
they store their data.  I'm sure local sensor networks will become
popular again once the hype is over.

Many ISPs make more money on providing network accesses which are
isolated from the Internet than actually providing Internet access

More and more systems are made up of networked subsystems.  Take a look
at your average core router for example. These susbsystems need
addresses.  But you rarely want them to connect to the Internet.

One can easily imagine future PC or handheld systems where internal
buses like I2C and USB (when used to connect *internal* lowspeed
components like fingerprint readers etc) have been replaced by IP over
ethernet.

Just to name a few applications I can think of here and now.  There are
many many more.

I'm not claiming that ULAs are the answers to all these.  There are
certainly reasons why you might want GUAs instead.  But these are cases
where the main disadvantage of the ULAs - The lack of Internet
connectivity - does not matter, or is even turned into an advantage.




Bjørn

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 2, 2018, at 3:17 AM, Bjørn Mork  wrote:
> 
> Owen DeLong  writes:
> 
>> What can you do with ULA that GUA isn’t suitable for?
> 
> 1) get
> 2) keep
> 3) move

Wrong.

1) get
Easy as going to http://tunnelbroker.net  and 
filling out a form. Remember to check the box for your /48.

2) keep
Admittedly, you might have to connect to your tunnel every once in a 
while to keep it alive, but that’s
hardly a high bar.

3) move
If you’re not talking to the internet with it (which you can’t with 
ULA, theoretically), you can move that same
HE /48 anywhere you want, with the additional advantage that you can, 
if you need to, connect your tunnel
and actually make it work on the internet too.

> Granted, many of us can do that with GUAs too.  But with ULA those
> features are avaible to everyone everywhere.  Which is useful for a

You really think that doing ULA according to the RFCs (collision avoidance 
algorithm and all) is easier
than filling out a form at HE? REALLY?

> number of applications where you care mostly about the local environment
> and not so much about global connectivity.

I hear you, but I’m not convinced about the ease.

Owen

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

[Owen DeLong]

For that matter, if we can kill IPv4, we have plenty of headroom for a LOT of 
IPv6 PI space.

Owen

> On Mar 1, 2018, at 4:48 PM, 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.
> 
> 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
>> 

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 5:30 PM, Mark Andrews  wrote:
> 
> 
>> 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.

Meh.

ISP assigned addresses _CAN_ be used to talk to the rest of the world. PI 
addresses are also
perfectly fine for this where supported.

> With IPv6 you use ULA along side ISP assigned addresses.

With IPv6 you _CAN_ use ULA along PA.
or you can use PI.
or you can use PI along side PA.

IMHO, either of the latter two are better than the former.

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

My home router doesn’t have web pages since I turned off J-web.
It also doesn’t run DHCP as a server. (It does run a DHCP client to talk to 
Comcast).

I do, however, have some static DHCP entries in my dhcpd.conf file on my dhcp 
server.

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

Nope… But there’s _NO_ reason that can’t do that equally well with a PI block
(or a free /48 from HE that they just don’t bother to really connect to a 
tunnel)
instead of ULA.

So… I stand by my point… ULA offers no… ZERO advantages over GUA.

All the defense of ULA makes strange assumptions about the nature of GUA.
I did not. Any form of GUA that suits the purpose is fine with me. If you’re
comfortable with PA, great. If you prefer PI, great. If you need something
free, get a /48 from HE, they hand them out on a simple web form. If you’re
using it locally, nothing says you _HAVE_ to actually turn on the tunnel.
OTOH, if you want, you’re certainly free to do so and it will solve certain 
address
selection oddities that happen with some systems when ULA is used and
greatly simplify your DNS life.

Owen

>> 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: 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 6:30 PM, Harald Koch  wrote:
> 
> 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.

I object to NAT more strongly than ULA, but IMHO, even if you aren’t going to 
route it, a block of GUA PI makes more sense than ULA for virtually any 
installation I can imagine.

Owen

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

[Bjørn Mork]

Owen DeLong  writes:

> I don’t agree that making RFC-1918 limitations a default in any daemon makes 
> any
> sense whatsoever.

+1

One of the more annoying anti-features I know of in this regard is the
dnsmasq rebind "protection".  It claims to protect web browsers on the
LAN against DNS rebind attacks.  But the implementation does not
consider which adresses are used on the LAN at all.  It simply blocks
any A record pointing to an RFC1918 address, making a few bogus
assumptions:
- IPv4 LAN addresses are selected from RFC1918
- RFC1918 addresses are never used on the WAN side of a CPE
- Noone use IPv6 on their LAN

It's hard to know how many users have been bitten by the first
one. You'd have to depend on this rebind "protection" in the first
place, and that would be stupid.

But the second assumption regularily bites end users when their ISP
provides some ISP internal service using RFC1918 addresses.  Which of course
is fine.

The anti-feature has been enabled by default in OpenWrt for a long time,
ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that
there is a large user base having this enabled without knowing.

> First, there are plenty of LANs out there that don’t use RFC-1918.
>
> Second, RFC-1918 doesn’t apply to IPv6 at all,

Could you try to explain that to the OpenWrt guys?  Thanks



Bjørn

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 2, 2018, at 1:50 AM, Saku Ytti  wrote:
> 
> Enno et al ULA fans
> 
> I could not agree more.
> 
> Either you provide your enterprise customers transportable address or
> ULA. If you assign and promote them to use your 'PA' address, they
> will take your PA address with them when they change operator 10 years
> from now, and if you reuse it, these two customers cannot reach each
> other. Why? Because anyone who has worked at non-trivial size
> enterprise knows that even just finding out what needs to be done, to
> renumber internal networks is massively long, expensive and error
> prone proposal, there will be tons of documents and scripts in
> non-standard locations containing IP addresses punched in.

This, right here, is inherently the a very good reason NOT to use ULA IMHO.

See, no matter how widely you deploy ULA, those same scripts are still going to 
use
the provider assigned public addresses that work for all the things they care 
about and
not just local connectivity.  Instead, you adopted a false sense of security 
and made
it more confusing when things do get renumbered.

I completely agree that PI is the way to go and that PA was a silly idea whose 
time
is long past. For home users, perhaps PA is OK for a little while longer 
(wouldn’t
make me happy in my home, but I’ve got PI, so whatever other folks want to do
isn’t my problem here).

> No matter how well you do your job, you cannot impact how others do,
> and you must expect them to continue working as they have in the past,
> and you must realise when that poses risk to yourself and protect
> yourself from that.

Which won’t happen with ULA.

> ULA at inside and 1:1 to operator address in the edge is what I've
> been recommending to my enterprise customers since we started to offer
> IPv6 commercially. Fits their existing processes and protects me from
> creating tainted unusable addresses.

Oh, please. NAT all over again? That’s another inherently very good reason
NOT to use ULA.

Owen

> 
> 
> On 2 March 2018 at 11:39, Enno Rey  wrote:
>> Hi,
>> 
>> On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote:
>>> 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.
>> 
>> as is proper (source|destination) address selection in a sufficiently 
>> complex environment.
>> for interest: for a system which must be both globally and internally 
>> reachable, which address do you put into which DNS?
>> 
>> 
>>> 
>>> All of the objections I've seen to ULA are actually objections to (IPv6)
>>> NAT, which is why I was confused.
>> 
>> the main objection against ULAs is avoidance of complexity in environments 
>> where at least some systems need global reach(ability), which applies to 
>> pretty much all environments nowadays.
>> 
>> best
>> 
>> Enno
>> 
>> 
>> 
>> 
>> 
>> 
>>> 
>>> (As it turns out my ISP prefix has been static for years, but I'm too lazy
>>> to undo all of the work...)
>>> 
>>> --
>>> Harald
>> 
>> --
>> Enno Rey
>> 
>> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>> 
>> Handelsregister Mannheim: HRB 337135
>> Geschaeftsfuehrer: Matthias Luft, Enno Rey
>> 
>> ===
>> Blog: www.insinuator.net || Conference: www.troopers.de
>> Twitter: @Enno_Insinuator
>> ===
> 
> 
> 
> -- 
>  ++ytti

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

[Bjørn Mork]

Owen DeLong  writes:

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

1) get
2) keep
3) move

Granted, many of us can do that with GUAs too.  But with ULA those
features are avaible to everyone everywhere.  Which is useful for a
number of applications where you care mostly about the local environment
and not so much about global connectivity.


Bjørn

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

[Saku Ytti]

Enno et al ULA fans

I could not agree more.

Either you provide your enterprise customers transportable address or
ULA. If you assign and promote them to use your 'PA' address, they
will take your PA address with them when they change operator 10 years
from now, and if you reuse it, these two customers cannot reach each
other. Why? Because anyone who has worked at non-trivial size
enterprise knows that even just finding out what needs to be done, to
renumber internal networks is massively long, expensive and error
prone proposal, there will be tons of documents and scripts in
non-standard locations containing IP addresses punched in.

No matter how well you do your job, you cannot impact how others do,
and you must expect them to continue working as they have in the past,
and you must realise when that poses risk to yourself and protect
yourself from that.

ULA at inside and 1:1 to operator address in the edge is what I've
been recommending to my enterprise customers since we started to offer
IPv6 commercially. Fits their existing processes and protects me from
creating tainted unusable addresses.


On 2 March 2018 at 11:39, Enno Rey  wrote:
> Hi,
>
> On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote:
>> 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.
>
> as is proper (source|destination) address selection in a sufficiently complex 
> environment.
> for interest: for a system which must be both globally and internally 
> reachable, which address do you put into which DNS?
>
>
>>
>> All of the objections I've seen to ULA are actually objections to (IPv6)
>> NAT, which is why I was confused.
>
> the main objection against ULAs is avoidance of complexity in environments 
> where at least some systems need global reach(ability), which applies to 
> pretty much all environments nowadays.
>
> best
>
> Enno
>
>
>
>
>
>
>>
>> (As it turns out my ISP prefix has been static for years, but I'm too lazy
>> to undo all of the work...)
>>
>> --
>> Harald
>
> --
> Enno Rey
>
> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Matthias Luft, Enno Rey
>
> ===
> Blog: www.insinuator.net || Conference: www.troopers.de
> Twitter: @Enno_Insinuator
> ===



-- 
  ++ytti

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

[Enno Rey]

Hi,

On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote:
> 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.

as is proper (source|destination) address selection in a sufficiently complex 
environment.
for interest: for a system which must be both globally and internally 
reachable, which address do you put into which DNS?


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

the main objection against ULAs is avoidance of complexity in environments 
where at least some systems need global reach(ability), which applies to pretty 
much all environments nowadays.

best

Enno






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

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Matthias Luft, Enno Rey

===
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
===

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
>

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" <ra...@psg.com> 
To: "Christopher Morrow" <morrowc.li...@gmail.com> 
Cc: "North American Network Operators' Group" <nanog@nanog.org> 
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! :-)
>> 

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

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

[Ca By]

On Wed, Feb 28, 2018 at 5:54 PM Job Snijders  wrote:

> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
> > On 2018-02-27, Ca By  sent:
> > > Please do take a look at the cloudflare blog specifically as they
> > > name and shame OVH and Digital Ocean for being the primary sources
> > > of mega crap traffic
> > >
> > >
> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
> > >
> > > Also, policer all UDP all the time... UDP is unsafe at any speed.
> >
> > Hi, DigitalOcean here. We've taken steps to mitigate this attack on
> > our network.
>
> NTT too has deployed rate limiters on all external facing interfaces on
> the GIN backbone - for UDP/11211 traffic - to dampen the negative impact
> of open memcached instances on peers and customers.
>
> The toxic combination of 'one spoofed packet can yield multiple reponse
> packets' and 'one small packet can yield a very big response' makes the
> memcached UDP protocol a fine example of double trouble with potential
> for severe operational impact.
>
> Kind regards,
>
> Job


Thanks Job. NTT is a very good internet steward, making common sense calls
 not just sling bits by the kilo for $


>

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

[Job Snijders]

On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
> On 2018-02-27, Ca By  sent:
> > Please do take a look at the cloudflare blog specifically as they
> > name and shame OVH and Digital Ocean for being the primary sources
> > of mega crap traffic
> > 
> > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
> > 
> > Also, policer all UDP all the time... UDP is unsafe at any speed.
> 
> Hi, DigitalOcean here. We've taken steps to mitigate this attack on
> our network.

NTT too has deployed rate limiters on all external facing interfaces on
the GIN backbone - for UDP/11211 traffic - to dampen the negative impact
of open memcached instances on peers and customers. 

The toxic combination of 'one spoofed packet can yield multiple reponse
packets' and 'one small packet can yield a very big response' makes the
memcached UDP protocol a fine example of double trouble with potential
for severe operational impact.

Kind regards,

Job

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

[Mike Hammett]

They ship it by default firewalled from the Internet. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Denys Fedoryshchenko" <de...@visp.net.lb> 
To: nanog@nanog.org 
Sent: Wednesday, February 28, 2018 6:42:37 AM 
Subject: Re: New Active Exploit: memcached on port 11211 UDP & TCP being 
exploited for reflection attacks 

I want to add one software vendor, who is major contributor to ddos 
attacks. 
Mikrotik till now shipping their quite popular routers, with wide open 
DNS recursor, 
that don't have even mechanism for ACL in it. Significant part of DNS 
amplification attacks 
are such Mikrotik recursors. 
They don't care till now. 

On 2018-02-28 14:31, 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

[Grzegorz Janoszka]

On 2018-02-28 13:42, Denys Fedoryshchenko wrote:
I want to add one software vendor, who is major contributor to ddos 
attacks.
Mikrotik till now shipping their quite popular routers, with wide open 
DNS recursor,
that don't have even mechanism for ACL in it. Significant part of DNS 
amplification attacks

are such Mikrotik recursors.
They don't care till now.


I have mixed experiences with Mikrotik, but I don't think they would do 
such a stupid thing. A friend of my has three offices and each one has 
mikrotik to form tunnels and one domain for all the company.


He is not too IP savvy, so he copy-pasted the VPN config from internet 
and left the rest as it was. His routers are not open DNS resolvers.


When I asked them I got no reply and their logs showed:

_drop input: in:ether1 out:(unknown 0), src-mac 00:AB:CD:81:c2:71, proto 
UDP, AAA.47.138.134:9082->BBB.146.251.103:53, len 51


His settings showed the DNS server ON with all the queries for the local 
network and he actually had a toggle "allow remote queries" on, but his 
routers were not open resolvers.


--
Grzegorz Janoszka

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

[Denys Fedoryshchenko]

I want to add one software vendor, who is major contributor to ddos 
attacks.
Mikrotik till now shipping their quite popular routers, with wide open 
DNS recursor,
that don't have even mechanism for ACL in it. Significant part of DNS 
amplification attacks

are such Mikrotik recursors.
They don't care till now.

On 2018-02-28 14:31, 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

[Job Snijders]

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: Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Brian Kantor]

It seems to me that since peer pressure hasn't worked, it's time
to resort to legal means.  Have a talk with your own organization's
lawyers, explain to them how much time and money those folks are
costing your organization, and see if there isn't something you can
do in the way of billing for the time, small claims court, stern
letters from your lawyers to their legal department, criminal
illegal-computer-access complaints, etc.
- Brian

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

[Jean | ddostest.me via NANOG]

I ran a full scan of the internet with zmap to find vulnerable memcached 
servers from an AWS server. AWS received an abuse report and forwarded 
it to me.


I deleted the VM and the case was close...

LOL

OVH Is not dumb. Do you know how easy it is to deploy a VM today with 
all the automated frameworks?


Jean


On 02/28/2018 06:51 AM, Rich Kulawiec wrote:

On Wed, Feb 28, 2018 at 12:29:54AM +, Filip Hruska wrote:

OVH is one of the largest server providers in the world - of course they will 
be at the top of that list.

Of course not.  The larger an operation, the greater its responsibility
to the rest of the Internet -- because the more damage it can and will do
if it's not professionally operated.  Moreover, the larger the operation
the easier abuse control is and the less tolerance any of us should have
for failure.  I don't want to hear any clueless whining from ignorant
newbies about how-oh-so-terribly-hard-it-is-with-a-billion-users.  If you
don't know how run it, or you're too lazy, cheap, and stupid to run it,
you should never have built it: you're simply not good enough.

---rsk

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

[Rich Kulawiec]

On Wed, Feb 28, 2018 at 12:29:54AM +, Filip Hruska wrote:
> OVH is one of the largest server providers in the world - of course they will 
> be at the top of that list.   

Of course not.  The larger an operation, the greater its responsibility
to the rest of the Internet -- because the more damage it can and will do
if it's not professionally operated.  Moreover, the larger the operation
the easier abuse control is and the less tolerance any of us should have
for failure.  I don't want to hear any clueless whining from ignorant
newbies about how-oh-so-terribly-hard-it-is-with-a-billion-users.  If you
don't know how run it, or you're too lazy, cheap, and stupid to run it,
you should never have built it: you're simply not good enough.

---rsk

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

[Rich Kulawiec]

On Tue, Feb 27, 2018 at 04:13:23PM -0800, Dan Hollis wrote:
> OVH does not suprise me in the least.
> 
> Maybe this is finally what it will take to get people to de-peer them.

Let's hope so.  There are two, and only two possibilities.

1. They know what's going on in their operation.  In that case, they're
fully aware of all the spam, phishing, attacks, abuse, etc., and are
choosing to actively support and encourage them because it's profitable.

2. They don't know what's going on in their operation.  In that case,
they're amazingly ignorant and stunningly incompetent -- because we
all know what's going on in it and we're not even there.

But in either case, the operational impact on us is exactly the same
and so is the solution.

---rsk

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

[Dan Hollis]

On Wed, 28 Feb 2018, Filip Hruska wrote:

What exactly should they do, according to you?


read and act on abuse reports.


Why should people de-peer them?


because they ignore abuse reports.

-Dan

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

[Ca By]

On Tue, Feb 27, 2018 at 4:29 PM Filip Hruska  wrote:

> This is just stupid.
>
> OVH is one of the largest server providers in the world - of course they
> will be at the top of that list.
> What exactly should they do, according to you?
>

They should have rough norms enforced on their traffic behavior ,
especially around udp. If they do 1tbs of udp, they should police to 3tbs
or something similar.

Why should people de-peer them?
>

Abuse.  But abuse happens, failure to fix chronic is a reason to depeer...
not one off. Personally, i do not peer with ovh because i need my upstream
to rtbh their traffic.



> Regards,
> Filip Hruska
>
> On 28 Feb 2018 at 1:13 am, > wrote:
>
> OVH does not suprise me in the least.
>
> Maybe this is finally what it will take to get people to de-peer them.
>
> -Dan
>
> On Tue, 27 Feb 2018, Ca By wrote:
>
> > Please do take a look at the cloudflare blog specifically as they name and
> > shame OVH and Digital Ocean for being the primary sources of mega crap
> > traffic
> >
> > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
> >
> > Also, policer all UDP all the time... UDP is unsafe at any speed.
> >
> >
> > On Tue, Feb 27, 2018 at 12:28 PM Barry Greene  wrote:
> >
> >> Hello Fellow NANOGer,
> >>
> >> If you have not already seen it, experiences it, or read about it, working
> >> to head off another reflection DOS vector. This time it is memcached on
> >> port 11211 UDP & TCP. There are active exploits using these ports.
> >> Reflection attacks and the memcached is not new. We know how reflection
> >> attacks work (send a spoofed packet to a device and have it reflected  back
> >> (yes please deploy source address validation and BCP 38).
> >>
> >> Operators are asked to review their networks and consider updating their
> >> Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP
> >> port 11211 for all ingress and egress traffic. If you do not know about
> >> iACLs or Explorable port filters, you can use this white paper details and
> >> examples from peers on Exploitable Port Filters:
> >> http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/
>
> >>
> >> Enterprises are also asked to update their iACLs, Exploitable Port
> >> Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress
> >> and egress traffic.
> >>
> >> Deploying these filters will help protect your network, your organization,
> >> your customers, and the Internet.
> >>
> >> Ping me 1:1 if you have questions.
> >>
> >> Sincerely,
> >>
> >> --
> >> Barry Raveendran Greene
> >> Security Geek helping with OPSEC Trust
> >> Mobile: +1 408 218 4669
> >> E-mail: bgre...@senki.org
> >>
> >> 
> >> Resources on memcached Exploit (to evaluate your risk):
> >>
> >> More information about this attack vector can be found at the following:
> >>
> >> • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009)
> >> http://www.jpcert.or.jp/at/2018/at180009.html
> >> • Qrator Labs: The memcached amplification attacks reaching 500
> >> Gbps
> >>
> >> https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98
> >> • Arbor Networks: memcached Reflection/Amplification Description
> >> and DDoS Attack Mitigation Recommendations
> >>
> >> https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/
> >> • Cloudflare: Memcrashed – Major amplification attacks from UDP
> >> port 11211
> >>
> >> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
> >> • Link11: New High-Volume Vector: Memcached Reflection
> >> Amplification Attacks
> >>
> >> https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/
> >> • Blackhat Talk: The New Page of Injections Book: Memcached
> >> Injections by Ivan Novikov
> >>
> >> https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf
> >> • Memcache Exploit
> >> http://niiconsulting.com/checkmate/2013/05/memcache-exploit/
> >>
> >
>
>
>

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

[Steve Atkins]

> On Feb 27, 2018, at 4:29 PM, Filip Hruska  wrote:
> 
> 
> 
> This is just stupid.   
> 
> 
> 
> OVH is one of the largest server providers in the world - of course they will 
> be at the top of that list.   
> 
> What exactly should they do, according to you?

Read their abuse@ alias. Shut down those customers who are being abusive.
Currently they do neither. Every so often they'll privately admit that they've 
been
doing an unconscionably bad job of mitigating abuse from their networks and
promise to do better, then don't.

Given some of their customers have been consistently abusive for years from the 
same
domain and the same IP address the problem isn't "Oh, the bad people keep
signing up with new credit cards! Oh, poor us!" or any other reasoning based on
being a large, inexpensive provider.

> Why should people de-peer them?   

If the overall cost of the bad traffic exceeds the benefit of the good traffic. 
I'm
sure it doesn't, but that people are even suggesting it is telling.

Cheers,
  Steve

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

[Filip Hruska]

  
  
This is just stupid.   
  

  
OVH is one of the largest server providers in the world - of course they will 
be at the top of that list.   
  
What exactly should they do, according to you?
  
Why should people de-peer them?   
  

  
Regards,   
  
Filip Hruska
  

  
  
  
  
  
>   
> On 28 Feb 2018 at 1:13 am,wrote:
>   
>   
>  OVH does not suprise me in the least. Maybe this is finally what it will 
> take to get people to de-peer them. -Dan On Tue, 27 Feb 2018, Ca By wrote:  > 
>  Please do take a look at the cloudflare blog specifically as they name and  
> >  shame OVH and Digital Ocean for being the primary sources of mega crap  >  
> traffic  >   >  
> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
>   >   >  Also, policer all UDP all the time... UDP is unsafe at any speed.  > 
>   >   >  On Tue, Feb 27, 2018 at 12:28 PM Barry Greene wrote:  >   >>  Hello 
> Fellow NANOGer,  >>   >>  If you have not already seen it, experiences it, or 
> read about it, working  >>  to head off another reflection DOS vector. This 
> time it is memcached on  >>  port 11211 UDP  &  TCP. There are active 
> exploits using these ports.  >>  Reflection attacks and the memcached is not 
> new. We know how reflection  >>  attacks work (send a spoofed packet to a 
> device and have it reflected back  >>  (yes please deploy source address 
> validation and BCP 38).  >>   >>  Operators are asked to review their 
> networks and consider updating their  >>  Exploitable Port Filters 
> (Infrastructure ACLs) to track or block UDP/TCP  >>  port 11211 for all 
> ingress and egress traffic. If you do not know about  >>  iACLs or Explorable 
> port filters, you can use this white paper details and  >>  examples from 
> peers on Exploitable Port Filters:  >>  
> http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/
>   >>   >>  Enterprises are also asked to update their iACLs, Exploitable Port 
>  >>  Filters, and Firewalls to track or block UDP/TCP port 11211 for all 
> ingress  >>  and egress traffic.  >>   >>  Deploying these filters will help 
> protect your network, your organization,  >>  your customers, and the 
> Internet.  >>   >>  Ping me 1:1 if you have questions.  >>   >>  Sincerely,  
> >>   >>  --  >>  Barry Raveendran Greene  >>  Security Geek helping with 
> OPSEC Trust  >>  Mobile: +1 408 218 4669  >>  E-mail: bgre...@senki.org  >>   
> >>    >>  Resources on memcached Exploit (to 
> evaluate your risk):  >>   >>  More information about this attack vector can 
> be found at the following:  >>   >>  • JPCERT – memcached のアクセス制御に関する注意喚起 
> (JPCERT-AT-2018-0009)  >>  http://www.jpcert.or.jp/at/2018/at180009.html  >>  
> • Qrator Labs: The memcached amplification attacks reaching 500  >>  Gbps  >> 
>   >>  
> https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98
>   >>  • Arbor Networks: memcached Reflection/Amplification Description  >>  
> and DDoS Attack Mitigation Recommendations  >>   >>  
> https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/
>   >>  • Cloudflare: Memcrashed – Major amplification attacks from UDP  >>  
> port 11211  >>   >>  
> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
>   >>  • Link11: New High-Volume Vector: Memcached Reflection  >>  
> Amplification Attacks  >>   >>  
> https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/
>   >>  • Blackhat Talk: The New Page of Injections Book: Memcached  >>  
> Injections by Ivan Novikov  >>   >>  
> https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf
>   >>  • Memcache Exploit  >>  
> http://niiconsulting.com/checkmate/2013/05/memcache-exploit/  >>   >   
>   

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

[Dan Hollis]

OVH does not suprise me in the least.

Maybe this is finally what it will take to get people to de-peer them.

-Dan

On Tue, 27 Feb 2018, Ca By wrote:


Please do take a look at the cloudflare blog specifically as they name and
shame OVH and Digital Ocean for being the primary sources of mega crap
traffic

https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/

Also, policer all UDP all the time... UDP is unsafe at any speed.


On Tue, Feb 27, 2018 at 12:28 PM Barry Greene  wrote:


Hello Fellow NANOGer,

If you have not already seen it, experiences it, or read about it, working
to head off another reflection DOS vector. This time it is memcached on
port 11211 UDP & TCP. There are active exploits using these ports.
Reflection attacks and the memcached is not new. We know how reflection
attacks work (send a spoofed packet to a device and have it reflected  back
(yes please deploy source address validation and BCP 38).

Operators are asked to review their networks and consider updating their
Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP
port 11211 for all ingress and egress traffic. If you do not know about
iACLs or Explorable port filters, you can use this white paper details and
examples from peers on Exploitable Port Filters:
http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/

Enterprises are also asked to update their iACLs, Exploitable Port
Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress
and egress traffic.

Deploying these filters will help protect your network, your organization,
your customers, and the Internet.

Ping me 1:1 if you have questions.

Sincerely,

--
Barry Raveendran Greene
Security Geek helping with OPSEC Trust
Mobile: +1 408 218 4669
E-mail: bgre...@senki.org


Resources on memcached Exploit (to evaluate your risk):

More information about this attack vector can be found at the following:

• JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009)
http://www.jpcert.or.jp/at/2018/at180009.html
• Qrator Labs: The memcached amplification attacks reaching 500
Gbps

https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98
• Arbor Networks: memcached Reflection/Amplification Description
and DDoS Attack Mitigation Recommendations

https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/
• Cloudflare: Memcrashed – Major amplification attacks from UDP
port 11211

https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
• Link11: New High-Volume Vector: Memcached Reflection
Amplification Attacks

https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/
• Blackhat Talk: The New Page of Injections Book: Memcached
Injections by Ivan Novikov

https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf
• Memcache Exploit
http://niiconsulting.com/checkmate/2013/05/memcache-exploit/

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

[Roland Dobbins]

On 28 Feb 2018, at 5:26, Ca By wrote:


Just udp.


This Arbor Threat Summary discusses the TCP issue, as well, FWIW:



'It should also be noted that memcached priming queries can also be 
directed towards TCP/11211 on abusable memcached servers. TCP is not 
currently considered a high-risk memcached reflection/amplification 
transport as TCP queries cannot be reliably spoofed.'


We also recommend implementing situationally-appropriate network access 
policies at the IDC edge which disallow unwanted UDP/11211 as well as 
TCP/11211 from reaching abusable memcached deployments.


---
Roland Dobbins 

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

[Justin Paine via NANOG]

Thanks Chip!


Justin Paine
Head of Trust & Safety
Cloudflare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Tue, Feb 27, 2018 at 1:52 PM, Chip Marshall  wrote:
> On 2018-02-27, Ca By  sent:
>> Please do take a look at the cloudflare blog specifically as they name and
>> shame OVH and Digital Ocean for being the primary sources of mega crap
>> traffic
>>
>> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
>>
>> Also, policer all UDP all the time... UDP is unsafe at any speed.
>
> Hi, DigitalOcean here. We've taken steps to mitigate this attack on our 
> network.
>
> Also, we've only seen udp/11211 being a problem. I'd be interested to
> hear of anyone seeing tcp/11211 attacks.
>
> --
> Chip Marshall 
> http://2bithacker.net/

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

[Ca By]

On Tue, Feb 27, 2018 at 1:54 PM Chip Marshall  wrote:

> On 2018-02-27, Ca By  sent:
> > Please do take a look at the cloudflare blog specifically as they name
> and
> > shame OVH and Digital Ocean for being the primary sources of mega crap
> > traffic
> >
> >
> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
> >
> > Also, policer all UDP all the time... UDP is unsafe at any speed.
>
> Hi, DigitalOcean here. We've taken steps to mitigate this attack on our
> network.
>
> Also, we've only seen udp/11211 being a problem. I'd be interested to
> hear of anyone seeing tcp/11211 attacks.
>

Thanks DO!

Just udp.



> --
> Chip Marshall 
> http://2bithacker.net/
>

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

[Chip Marshall]

On 2018-02-27, Ca By  sent:
> Please do take a look at the cloudflare blog specifically as they name and
> shame OVH and Digital Ocean for being the primary sources of mega crap
> traffic
> 
> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
> 
> Also, policer all UDP all the time... UDP is unsafe at any speed.

Hi, DigitalOcean here. We've taken steps to mitigate this attack on our network.

Also, we've only seen udp/11211 being a problem. I'd be interested to
hear of anyone seeing tcp/11211 attacks.

-- 
Chip Marshall 
http://2bithacker.net/

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

[Steve Atkins]

> On Feb 27, 2018, at 1:16 PM, Eric Kuhnke  wrote:
> 
> I question whether there is *any* high volume hoster out there that has a
> reputation for successfully addressing abuse issues coming from their
> customer base, and cuts off services...  By high volume hoster I define it
> as companies where anybody with a credit card can buy a $2 to $15/month
> VPS/VM in a fully automated process.
> 
> OVH just happens to be one of the largest and probably ranks in the top 10
> worldwide by number of hypervisors and VPS. I doubt whether any of their
> 30-40 competitors that are smaller than them do much better, considering
> the ratio of clued and attentive staff to VMs.

OVH are worse than that. Floods of the same spam coming from the
*same IP addresses* for years at a time. Continuous probes. A total refusal
to police their network or even respond to reports of issues.

They're not a major source of abuse because of their size, it's because
they've chosen to be.

Cheers,
  Steve

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

[Eric Kuhnke]

I question whether there is *any* high volume hoster out there that has a
reputation for successfully addressing abuse issues coming from their
customer base, and cuts off services...  By high volume hoster I define it
as companies where anybody with a credit card can buy a $2 to $15/month
VPS/VM in a fully automated process.

OVH just happens to be one of the largest and probably ranks in the top 10
worldwide by number of hypervisors and VPS. I doubt whether any of their
30-40 competitors that are smaller than them do much better, considering
the ratio of clued and attentive staff to VMs.




On Tue, Feb 27, 2018 at 12:47 PM, Ca By  wrote:

> Please do take a look at the cloudflare blog specifically as they name and
> shame OVH and Digital Ocean for being the primary sources of mega crap
> traffic
>
> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-
> port-11211/
>
> Also, policer all UDP all the time... UDP is unsafe at any speed.
>
>
> On Tue, Feb 27, 2018 at 12:28 PM Barry Greene  wrote:
>
> > Hello Fellow NANOGer,
> >
> > If you have not already seen it, experiences it, or read about it,
> working
> > to head off another reflection DOS vector. This time it is memcached on
> > port 11211 UDP & TCP. There are active exploits using these ports.
> > Reflection attacks and the memcached is not new. We know how reflection
> > attacks work (send a spoofed packet to a device and have it reflected
> back
> > (yes please deploy source address validation and BCP 38).
> >
> > Operators are asked to review their networks and consider updating their
> > Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP
> > port 11211 for all ingress and egress traffic. If you do not know about
> > iACLs or Explorable port filters, you can use this white paper details
> and
> > examples from peers on Exploitable Port Filters:
> > http://www.senki.org/operators-security-toolkit/
> filtering-exploitable-ports-and-minimizing-risk-to-and-
> from-your-customers/
> >
> > Enterprises are also asked to update their iACLs, Exploitable Port
> > Filters, and Firewalls to track or block UDP/TCP port 11211 for all
> ingress
> > and egress traffic.
> >
> > Deploying these filters will help protect your network, your
> organization,
> > your customers, and the Internet.
> >
> > Ping me 1:1 if you have questions.
> >
> > Sincerely,
> >
> > --
> > Barry Raveendran Greene
> > Security Geek helping with OPSEC Trust
> > Mobile: +1 408 218 4669
> > E-mail: bgre...@senki.org
> >
> > 
> > Resources on memcached Exploit (to evaluate your risk):
> >
> > More information about this attack vector can be found at the following:
> >
> > • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009)
> > http://www.jpcert.or.jp/at/2018/at180009.html
> > • Qrator Labs: The memcached amplification attacks reaching 500
> > Gbps
> >
> > https://medium.com/@qratorlabs/the-memcached-
> amplification-attack-reaching-500-gbps-b439a7b83c98
> > • Arbor Networks: memcached Reflection/Amplification Description
> > and DDoS Attack Mitigation Recommendations
> >
> > https://www.arbornetworks.com/blog/asert/memcached-
> reflection-amplification-description-ddos-attack-
> mitigation-recommendations/
> > • Cloudflare: Memcrashed – Major amplification attacks from UDP
> > port 11211
> >
> > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-
> port-11211/
> > • Link11: New High-Volume Vector: Memcached Reflection
> > Amplification Attacks
> >
> > https://www.link11.com/en/blog/new-high-volume-vector-
> memcached-reflection-amplification-attacks/
> > • Blackhat Talk: The New Page of Injections Book: Memcached
> > Injections by Ivan Novikov
> >
> > https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-
> The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf
> > • Memcache Exploit
> > http://niiconsulting.com/checkmate/2013/05/memcache-exploit/
> >
>

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

[Ca By]

Please do take a look at the cloudflare blog specifically as they name and
shame OVH and Digital Ocean for being the primary sources of mega crap
traffic

https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/

Also, policer all UDP all the time... UDP is unsafe at any speed.


On Tue, Feb 27, 2018 at 12:28 PM Barry Greene  wrote:

> Hello Fellow NANOGer,
>
> If you have not already seen it, experiences it, or read about it, working
> to head off another reflection DOS vector. This time it is memcached on
> port 11211 UDP & TCP. There are active exploits using these ports.
> Reflection attacks and the memcached is not new. We know how reflection
> attacks work (send a spoofed packet to a device and have it reflected  back
> (yes please deploy source address validation and BCP 38).
>
> Operators are asked to review their networks and consider updating their
> Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP
> port 11211 for all ingress and egress traffic. If you do not know about
> iACLs or Explorable port filters, you can use this white paper details and
> examples from peers on Exploitable Port Filters:
> http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/
>
> Enterprises are also asked to update their iACLs, Exploitable Port
> Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress
> and egress traffic.
>
> Deploying these filters will help protect your network, your organization,
> your customers, and the Internet.
>
> Ping me 1:1 if you have questions.
>
> Sincerely,
>
> --
> Barry Raveendran Greene
> Security Geek helping with OPSEC Trust
> Mobile: +1 408 218 4669
> E-mail: bgre...@senki.org
>
> 
> Resources on memcached Exploit (to evaluate your risk):
>
> More information about this attack vector can be found at the following:
>
> • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009)
> http://www.jpcert.or.jp/at/2018/at180009.html
> • Qrator Labs: The memcached amplification attacks reaching 500
> Gbps
>
> https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98
> • Arbor Networks: memcached Reflection/Amplification Description
> and DDoS Attack Mitigation Recommendations
>
> https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification-description-ddos-attack-mitigation-recommendations/
> • Cloudflare: Memcrashed – Major amplification attacks from UDP
> port 11211
>
> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
> • Link11: New High-Volume Vector: Memcached Reflection
> Amplification Attacks
>
> https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-amplification-attacks/
> • Blackhat Talk: The New Page of Injections Book: Memcached
> Injections by Ivan Novikov
>
> https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of-Injections-Book-Memcached-Injections-WP.pdf
> • Memcache Exploit
> http://niiconsulting.com/checkmate/2013/05/memcache-exploit/
>