Защищаемся от DDoS-атак с помощью Tempesta FW

DDoS-атаки стали настоящим бичом современного интернета. С ними борются как организационными методами (о которых писали в журнале, и не раз), так и техническими. Последние, как правило, либо неэффективны, либо достаточно дороги. Ребята из NatSys Lab решили попробовать сделать open source средство для защиты от DDoS-атак на веб-приложения. Посмотрим, что у них получилось.

Введение

Open source средства для защиты от DDoS (IPS), такие, например, как Snort, работают на принципе DPI, то есть анализируют весь стек протоколов. Они, тем не менее, не могут контролировать установление и завершение TCP-соединений, поскольку находятся для этого на слишком высоком уровне в сетевом стеке Linux и не являются ни серверной, ни клиентской стороной. Из-за этого возможен обход данных IPS. Прокси-серверы же участвуют в установлении соединения, но защитить от крупных DDoS не могут по причинам их относительной медлительности — поскольку работают они на том же самом принципе, что и атакуемые серверы. Для них желательно если не столь же хорошее оборудование, как на бэкенде, то достаточное, чтобы выдерживать большие нагрузки.

В NatSys Lab решили пойти по пути kHTTPd и TUX — реализовать фреймворк для работы с HTTP в режиме ядра. Пока что этот фреймворк находится в стадии альфа-версии, однако к середине 2015 года обещают выпустить релиз. Тем не менее, чтобы понять принципы работы и поиграться, достаточно и прототипа, который вполне работоспособен.

Установка и настройка

Для сборки Tempesta нужно иметь исходники ядра 3.10.10 с необходимыми инструментами. Скачиваем исходники самого проекта:

$ git clone https://github.com/natsys/tempesta.git

Получение Tempesta

Копируем патч и накладываем его:

$ cp tempesta/linux-3.10.10.patch linux-3.10.10/
$ cd linux-3.10.10
$ patch -p1 < linux-3.10.10.patch

Включаем нужные возможности — так, должны быть включены опции CONFIG_SECURITY и CONFIG_SECURITY_NETWORK, отключены все прочие LSM-возможности, такие как SELinux и AppArmor, и параметр Warn for stack frames larger than в подменю kernel hacking установлен в 2048. Затем собираем/устанавливаем ядро:

$ make nconfig
$ CONCURENCY_LEVEL=5 fakeroot make-kpkg --initrd --append-to-version=-tempesta kernel_image kernel_headers
$ sudo dpkg -i ../linux-image-3.10.10-tempesta_3.10.10-tempesta-10.00.Custom_amd64.deb ../linux-headers-3.10.10-tempesta_3.10.10-tempesta-10.00.Custom_amd64.deb
$ sudo shutdown -r now

Установка размера фрейма стека в ядре

После перезагрузки уже можно собирать и сам Tempesta. Для этого переходим в каталог, куда мы клонировали его, и набираем следующую команду:

$ make

Сборка Tempesta

INFO

Аргумент NORMALIZATION=1, указанный команде make при сборке модулей Tempesta, включает возможность нормализации HTTP-трафика.

После сборки можно, конечно, уже и запускать, но сперва давай посмотрим конфигурационный файл. Пример его находится в etc/tempesta_fw.conf. Разберем, что в нем есть:

# Указываем бэкенд, куда будут направляться запросы. Допустимо указывать несколько бэкендов — каждый в отдельной строке
backend 127.0.0.1:8080;
# Порт (и при необходимости адрес), который используется самим Tempesta. Опять же допустимо использовать несколько адресов/портов
listen 80;
listen [::0]:80;
# Настройки кеширования — включено/отключено. В случае если защищаемый бэкенд находится на том же сервере, что и Tempesta, его лучше отключить
cache on;
# Каталог, где хранится кеш. Путь к нему абсолютен и не должен заканчиваться слешем. Кроме того, если в пути есть пробелы и спецсимволы, его необходимо заключать в кавычки
cache_dir /opt/tempesta/cache;
# Размер кеша. Измеряется в килобайтах и должен быть кратен 4096
cache_size 262144;

Кроме данного конфигурационного файла, в этом же каталоге есть файл tfw_sched_http.conf, в котором, собственно, и находятся правила маршрутизации HTTP и содержимое которого должно, по идее, быть включено в предыдущий — но, по всей видимости, его вынесли, чтобы в дальнейшем в модуле диспетчера добавить возможность его обработки. Посмотрим на его синтаксис:

# Обязательная строка с именем модуля
sched_http {
    # Группы бэкендов. Бэкенды должны быть заданы и в предыдущем конфиге. Внутри группы балансировка осуществляется путем алгоритма round-robin
    backend_group static_content {
        backend 192.168.1.19;
        backend 192.168.1.20:8080;
        }
    backend_group im {
        backend 192.168.1.21;
    }
    backend_group main {
        backend 192.168.1.5;
    } 

    # Правила маршрутизации. Задаются в следующем виде:
    # rule be_group field operator pattern
    # где be_group — определенная выше группа бэкендов, field — поле HTTP-заголовка, сравниваемое с pattern, используя оператор operator. Список возможных полей:
    # uri — часть uri HTTP-запроса, содержащая путь и строку запроса
    # host — имя хоста либо из uri, либо из заголовка Host. Первое приоритетнее
    # host_hdr — только заголовок Host
    # hdr_conn — поле Connection заголовка HTTP-запроса
    # hdr_raw — любое другое поле, имя которого указано в pattern
    # operator может быть либо eq — полное соответствие с pattern, либо prefix — соответствие на начало строки
    # Если запрос не удовлетворяет текущему правилу, он проверяется на соответствие следующему
    rule static_content uri prefix "/static";
    rule static_content host prefix "static.";
    rule im uri prefix "/im";
    rule im hdr_raw prefix "X-im-app: ";
    rule main uri prefix "/";
}

Как уже было сказано, эти два файла по отдельности неработоспособны — их нужно объединить в один, для чего используем команду

$ cat tempesta_fw.conf tfw_sched_http.conf > tfw_main.conf

Наконец, запускаем:

# TFW_CFG_PATH="/home/adminuser/tempesta/etc/tfw_main.conf" ./tempesta.sh start
Source:  xakep.ru