Hugo's Blog

Mostly tech...mostly

What BCP38 Can and Cannot Do

We’re coming through what is seeming like a tipping point in the history of DDoS on the Internet. Rather than targeting a company or online gaming, one of the largest DDoS attacks ever targeted an individual, Brian Krebs, most likely for his work exposing a so-called “booter service”, a DDoS-for-hire outfit called vDOS, which ultimately led to the alleged proprietors being arrested. A brief history of DoS volumes Public information about DDoS attack volumes are generally sparse outside of news releases and blog posts of DDoS mitigation companies, but even as late as last year, attacks of around 400 Gbps were exceptional events and pretty much the biggest the Internet had seen.

Clarifying DDoS-related terms

I’ll be writing a bit more about DDoS attacks and security, and so I thought it would be handy to jot down some commonly used terms in one place. I’ll also look at how some of those terms are interrelated. The terms Spoofing As relates to TCP/IP, “spoofing” really just refers to forging some part of IP communications. You could, for example, spoof a source port to have response data thrown at a listening application that wasn’t expecting it, but generally we’re talking about forging the source IP address in an IP packet.

GRE Reflection?

Recently, we’re seeing an uptick in GRE traffic as part of a DDoS mix. Most prominently, GRE featured as the biggest volume contributor in the record 600+ Gbps attack on krebsonsecurity.com. (Note that the site is currently offline as it’s finding a new home, so any links to krebsonsecurity.com will reference The Internet Archive instead.)

An initial tweet from @briankrebs listed GRE in the attack traffic mix:

…and Krebs later confirmed more details in KrebsOnSecurity’s own article reporting on the attack:

Preliminary analysis of the attack traffic suggests that perhaps the biggest chunk of the attack came in the form of traffic designed to look like it was generic routing encapsulation (GRE) data packets, a communication protocol used to establish a direct, point-to-point connection between network nodes.

Now, volumetric DDoS attacks will generally use amplification vectors like open DNS resolvers, misconfigured or vulnerable NTP or SNMP servers, SSDP, etc. in order to boost the attack volume. Those amplifiers are also often vulnerable to reflection attacks, where the attacker spoofs the source address in the initial amplification trigger packets so that the amplified replies hit the target rather than the attacker. This can be pulled off because these exploited amplification vectors are stateless and UDP-based, and so a single spoofed packet from the attacker will trigger the amplified reply destined for the target. A TCP-based attack could yield a larger amplification factor (e.g. just think of pulling off an HTTP GET of a GB+ file!), but a TCP 3-way handshake would never complete successfully with a spoofed source address, and even if somehow it could, the attacker would have to keep ACK-ing somehow in order to keep the transfer going. GRE we are told, however, could not have a spoofed source address (also from the same Krebs article):

McKeay explained that the source of GRE traffic can’t be spoofed or faked the same way DDoS attackers can spoof DNS traffic.

GRE is not known to have an amplification vector, and I haven’t been able to think of one. But is it true that source IPs cannot be spoofed in GRE? *Note that this is an untested theory and still needs to be validated.*

Ubuntu Xenial and systemd network online target

So, I’m bringing a little Chromebox back into use on our home network to do some basic network services: dhcp, dns, and probably actually using it as a router (long story; tl;dr TekSavvy says they’ll give you a /56 but then the VDSL modem they sell you can’t do DHCPv6-PD properly).

Anyway…

I slapped Ubuntu 16.04 Xenial server on it and started plugging away at a couple of things. I opted to use ISC’s newer Kea DHCP server rather than isc-dhcp-server. Little did I know that Ubuntu and systemd had other ideas…

Moving to Hugo

So…I’ve moved my blog to Hugo. More info to follow, but bear with me as I clean up some bits and pieces.

BTC tips

This blog hasn’t been updated in a bit, but I’m experimenting with bitcoin tips. If you like an article or found it useful, please feel free to send me “thank you” tip via bitcoin through the BTC address at the bottom of the article. This is also a rudimentary “voting system” to let me know which content has been most beneficial to people. I’ll be adding BTC tip addresses to articles in fits and starts for existing articles as I get to them.

"Gone Google" Marketing Fail...

Google is touting their Google Apps offering for business with a new post on the official Google Blog (link). The post presents a link to a gonegoogle.com site, which runs you through a calculator of how much cash you can save by “Going Google”. The calculator seems to be based on industry averages for things like uptime, storage costs, remote access, etc., and presents a nice little summary poster at the end. An example is given from guest poster smartfurniture.com.

A nice little surprise comes up, though, when you click on the link to view the sample poster for Smart Furniture.

Wordpress Theme Updated

In case it isn’t obvious: I switched up the theme for the site. I was never really too fond of the light-green touch of the previous theme and the code styling especially bugged me, but it was a fairly clean and so I just kind of stuck with it. Anyhow; comments & feedback appreciated.

Cannot install ESET Security on Debian 4.0 Etch Virtuozzo VPS

As part of some mail filter testing, I needed to install ESET Mail Security onto a Debian 4.0 Etch VPS running on Virtuozzo. As a side-note, I found that the install package for ESET’s Gateway Filter, Mail Security, and File Server Security for Linux is all the exact same package; the functionality is basically just controlled/activated by means of licensing the appropriate component. Anyway, the download comes as an installation script called esets.