Embed Size (px)
Citation preview
whoami
Александр Головко
CTO в Wallarm
Что такое Wallarm
● Решение для защиты от взлома● Защищает QIWI, Юлмарт, и многие другие интернет-
компанииMail.ru — НЕТ!, можете ломать
● У клиентов — большие нагрузки, частые выкатки кода, большая инфраструктура, много атак
● За прошлый мы обработали 500+ млр. запросов ● И задектировали 150 миллионов вредоносных
запросов
Как все начиналось
● Мы умели ломать сайты (проводить аудиты информационой безопасности)
● Мы умели обходить WAF’ы● Поняли, что исправить WAF’ы нельзя● Нам стало больно, обидно и холодно :)● Мы решили делать что-то, отличное от WAF
Задача
● Непрерывный мониторинг безопасности ● Анализировать трафик локально● Выявлять уязвимости локально и из облака● Хранить в облаке статистику и атаки
Непростые требования
● Не мешать нормальной работе приложения (минимум оверхедов)
● Не требовать абсолютного доверия (не отдавать нам трафик)
● Не портить приложение (не инжектить HTML/JS)● Автоматически подстраиваться под защищамое
приложение● Бесконечно масштабироваться● Ставиться легко и просто без своих железок
Зоны ответственности
● Клиентские ноды видят весь трафик(установлены в инфраструктуре клиента как reverse-proxy)
● Облако видит только зловредов и статистику
Nginx
Плюсы:
● Мы знаем команду Nginx, а они нас :)● Стандарт де-факто● Сам по себе он быстр и стабилен
Минусы:
● Хардкор
Дилемма
● Надо гарантированно проверять все запросы● При нехватке ресурсов жертвовать некритичным
функционалом● Быть устойчивым к сбоям● А при чем тут Тарантул-то? Есть же nginx-lua (прямо
как у CloudFlare)
Мудрость жизни
● Если хочешь успевать больше:○ не тупи
○ не отвлекайся
● Надо разделить процесс на две части○ первичная обработка (синхронная, nginx!)
○ постобработка (асинхронная, tarantool?!)
А еще...
● Атаки бывают не только Input Validation● Поведенческие атаки
○ Bruteforce/Dirbusting
○ Fuzzers
○ Fraud
● Хотим то не знаю что, тогда не знаю когда○ обучение — сбор статистики
○ обучалка в любой момент может захотеть собрать что-то, что
раньше даже не планировалось собирать (кол-во запросов с
пустым HOST в полнолуние)
Первичная обработка
● Блокировка до получения проблем● IV может создать проблемы с одного запроса● По сутиподсчет метрик о каждом запросе
Постобработка
● Ошибки выгрузки данных в облако● Bruteforce и другие поведенческие атаки можно
выявить только постфактум● Какой еще будет анализ поведения — неизвестно● По сути — сбор статистики● Вывод — нам надо какую-то БД
Выбор БД
Выбор БД
● Надо быть способным записать все, что проходит через Nginx
● В худшем случае - еще и все успеть выгрузить● Надо вести различную статистику запросов● Возможность делать произвольную аналитику● Память дешева, так что in-memory БД
Варианты
● Писать что-то свое специфиное● Взять какую-то встраиваемую БД● Взять какую-то из обычных БД
Подводящие мысли
● Идеал, если нам подходит что-то готовое● Популяция in-memory баз в 2013 невелика● Больше хранимок, меньше денормализации● OpenSource решение на C в почете
В итоге
● MySQL● Redis● Tarantool
Redis vs Tarantool
● Оба однопоточны● Оба можно скриптовать на LUA● По бенчмаркам индексы Tarantool быстрее● LuaJIT добавили в Redis только в 2014● Мы знаем команду Tarantool, а они наc. Прямо как
Nginx :)● Нам нравилась идея Application-сервера для LUA.● Secondary index облегчают денормализацию данных
Tarantool!
Как мы используем Tarantool
● nginx готовит сериализованный запрос● nginx вызывает tarantool-функцию для записи
запроса● в tarantool в этот момент считаются и сохраняются
дополнительные метрики● если tarantool не хватает свободной памяти, то
удаляется что-то из старых данных● внешние скрипты выгружают из tarantool часть
данных и что-то с ними делают.
Сейчас
● Статистика для брутов● Маркировка запросов по хидерам● Выгрузка вредоносных запросов● Сбор информации о структуре приложения
Tarantool 1.5 - раздражало
● Отвратительный вывод на экран в консоли● Необходимость набирать lua перед каждой командой● Обращение к спэйсам и индексам по номерам
Tarantool 1.5 - боль
● Ужасная статистика потребления памяти● Expirationd - отстой● Однопоточность
Tarantool 1.6 - боль
● Смена протокола● Нет триггера на нехватку памяти● Пришлось везде вставлять pcall()● Память иногда не очищалась после удаления данных● Последний такой баг закрыли только в 1.6.7
Tarantool 1.6 - косяки
● Были сегфолты● Смешной сегфолт в lua-yaml● Мы не дочитали доки на протокол и минорный апдейт
принес нам проблемы коннекта.
Tarantool 1.6 - плюшки
● Для нас стало заметно быстрее○ вместо 25к/сек записей стало 30к/сек
● Появились hash-функции (md5 и прочие) в стандартной поставке
● msgpack● Написание функций на C это огонь!● Sophia - можно теперь подумать на тему вынесения
части данных на диск
Итого
● Несмотря на все описанные сложности, Tarantool нам понравился
● Он позволил нам сэкономить значительное время при выходе на рынок
● Сейчас ноды с тарантлом работают в очень нагруженных проектах.○ Qrator - через них проходит порядка 500мбит трафика
○ Qiwi - несолько сотен инсталляций○ Обработано более 400 млрд запросов за 2015 год.
● Триггер на нехватку памяти● Ускориться за счет сишных хранимок● Начать использовать их nginx-коннектор● Поиграться с вынесением части данных в sophia
Будущее
