Bits and pieces.

High performance DDoS statistics

Recently, I’m dealing with Redis/Hiredis C library in order to implement flow statistics into our flowShield DDoS-Mitigation application.

First, I’ve thought about using MySQL, as we already heavily use the MySQL C Library. However, MySQL has some serious performance issues and could (seriously) not cope with 4.000 Insert Queries per second.

Therefore, I’ve looked into in-memory key value storage, such as Memcached and Redis. At combahton, we’re already using both for our customer area – memcached as session store, redis as key value store for temporary objects.

Personally, I felt like Redis would be a deeper look worth.

Hiredis C Libary

Hiredis is pretty good documented. The library can be found on https://github.com/redis/hiredis. Debian development packages are also available, which include hiredis header files already.

A pretty simple hiredis implementation would look like that:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <hiredis/hiredis.h>

int main() {

  redisContext *c = redisConnect("redis.host.de", 6379);
  if (c == NULL || c->err) {
    if (c) {
        printf("Error: %s\n", c->errstr);
        // handle error
    } else {
        printf("Can't allocate redis context\n");
    }
  }

  redisCommand(c, "SET foo %u", 123);

}

Using Redis for DDoS Statistics

In our scenario, hiredis runs as seperate thread, pushing flows (such as Source/Dest IP, Protocol, Source/Dest Port, TCP Flags, etc.) as json to our Analyzer Redis Instance. Later on, the Analyzer can use those information do create custom flowspec rules, create granular attack logs or present these details to customers.

Prototyping

As first prototype, our flowShield application now includes a seperate pthread which crawls flows from a hasharray and exports them to redis.

Why another thread? It’s simple, flowShield often deals with multiple million packets per second. Without threading, we would need to wait for redis whenever a packet gets handled.

That would spike our packet handlers latency and cause the NIC buffer to overrun in zero time.

I’ve also played a bit with phpredis, which allowed me to build the following web frontend in basically no time:

Leave a Reply

Your email address will not be published. Required fields are marked *