New reflection attacks using Memcached, Learning with Google AI, and the introduction of vgo.

Memcrashed

After the fun we had last year with DDoS attacks coming from IoT devices, this year has brought us a new entry. Reflection attacks through Memcached.

As a small reminder, reflection attacks happen when an attacker uses a spoofed origin to send a message to a 3rd-party, traditionally a DNS server, which then sends its reply to the victim. These attacks are dangerous as the payload that comes in the reply is far larger than what the attacker sends, which automatically scales up the volume of the attack.

Cloudflare described on their blog¹ that these attacks started to happen, complete with their usual deep technical analysis. Based on the data it seems like a massive amplification is possible by using open UDP ports on memcached to return large amounts of data to a victim.

Later in the week, this came to a head when GitHub was attacked by a 1.3 Tbps DDoS attack using this method. While GitHub had some initial trouble, with the help of Akamai they eventually stayed up during the attack.

Learn with Google AI

Google has posted a new learning section on their site called Learn with Google AI. If you’re interested in AI/ML, this seems like a very good starting place. It’s becoming a more important part of software development all the time, and these courses are aimed at learning the basics. It also includes a course that is used by Google to train its own staff, so I recommend checking it out.

vgo

If you read my writing on this site, you’ll be aware that I enjoy writing in Go. It’s a great compact language that is perfect for certain use cases. However, one of the things it hasn’t managed to get right so far is dependency management. It has gotten better recently with the introduction of dep, which allows you to more easily vendor your dependencies and lock them to a certain version.

However, Dep is not the end result². It is meant as a way to bring things together and to learn what is required for the final command that will be integrated into Go. The first attempt at figuring out this final command is the recently announced vgo. Vgo is not even a full proposal at this point, but the proposal is coming, for inclusion in Go 1.11³.

Vgo is focused on versioning of packages. This includes the expectation of backwards compatibility that currently exists, but it will also extend this by defaulting to the lowest allowed version number of the defined dependencies. Vgo will also introduce the concept of modules, which is a group of packages that are versioned as a single unit, and attempt to integrate this all into the tool chain.

The original post was followed by a lot more, and so far vgo seems well thought out but as it has only been public for a couple of weeks there are likely limitations that still need to be addressed. The goal is to replace even go get and it will be interesting to see how this will happen. A big change like this will likely take several releases before its fully worked out, so I’m sure we’ll see a lot of discussion about it.