Анализатор логов ddosViewer вебсервера для поиска ддос флуда

Boris A Dolgov, благодарю за интересные замечания по существу.

Комментариев в коде много не бывает. Делать комментарии по русски некто не запрещает.

Да, это минус. Большие функции сложнее отлаживать. И в них больше вероятность ошибок. Покажите мне ваш код, я посмотрю на размер ваших функций.

Посмотрел эту функцию в коде. Она негде не вызывается и не используется. Это не доделанная до конца функция. Эта функция не была отлажена и содержит явную ошибку (использование не инициализированной переменной n). Убрал из текста программы эту не используемую функцию, что бы не смущала.

Программа переделывалась, дополнялась и отлаживалась мной около полугода. Очень много тестировалась. В ней было обнаружено и исправлено много ошибок. Были ошибки очень грубые и критические. Сейчас (после 6 месяцев активного использования) вероятность ошибок в программе не высока.

Главное что программа делает, то что заявлено в ее описании.

А именно строит отчеты и на мой взляд весьма информативные.

zexis добавил 16.01.2011 в 00:37

time tail -130000 access.log |cut -d " " -f2|uniq -c|sort -n|tail -1000

...

real    0m0.934s

user    0m0.852s

sys     0m0.080s

Тормозной Ваш парсер, вот что сударь...

Ваш скрипт лишь находит самые активные IP и выводит из отсортированные по количеству кликов.

К тому же в нем по моему 2 ошибки. (выделил их цветом)

Может вы так хотели написать?

time tail -130000 access.log |cut -d " " –f1|sort||uniq -c|sort -n|tail -1000

В моем анализаторе IP не только сортируются по количеству кликов, но еще для каждого IP рассчитывается много дополнительных данных:

Топ IP адресов

Топ IP адресов, с подсчетом интенсивности кликов

Не согласен - комментарии должны отражать идею кода и некоторые неочевидные моменты текущей реализации, а не писать, что код делает - ведь он должен быть написан так, чтобы было понятно, что он делает без комментариев :)

Чаще всего руководствуются правилом "не больше 50 строк или не больше 4-5 табов перед очередным оператором. Более-менее серьезный код, увы, сейчас показать не могу.

из какого-то плагина к billmanager

Price findPrice(int priceId)

{

    for (vector<Price>::iterator p = cnf.prices.begin(); p != cnf.prices.end(); ++p)

    {

        if (p->id == priceId) return *p;

    }

    throw logic_error("No price found");

}

string getLogin(int id)

{

    auto_ptr<ResultSet> res(msql->executeQuery("SELECT username FROM vhost WHERE pid=" + boost::lexical_cast<string>(id)));

    if (res->rowsCount() != 1) throw logic_error("Not one username");

    res->next();

    return res->getString("username");



}

void processOrder(int id, bool activate)

{

    initSql();

    int realOrder = findRealOrder(id);

    Server server = findServer(realOrder);

    Price price = activate ? findPrice(findOrdPrice(id)) : findPrice(-1);

    int realUid = findUid(realOrder), myUid = findUid(id);

    if (realUid != myUid) throw logic_error("Client doesn't have this item.");

    string login = getLogin(realOrder);



    ChangeRequest r(server, price, login);

    r.process();

}

+1

В хорошем коде - комментариев по минимуму. Для примера советую взглянуть на исходники ядра linux (прежде всего, не драйвера - а каталоги kernel/, lib/ и т.п.). Или код апача.

Кстати, взглянуть автору настоятельно рекоммендуется. Т.к. из текста ясно, что чего-то более-менее приличного он НЕ ЧИТАЛ, как тот самый чукча...

О чем вообще спор? Уже давно бенчмарки подтвердили, что грамотно написанный парсер на Perl обгоняет остальные ЯП по скорости выполнения.

Странные бенчмарки. Либо они не умеют писать на других ЯП грамотно.

Boris A Dolgov, почему бы нет для среднего кода на C и среднего же кода на PERL ?

perl компилируется в байт-код. Реализация хешей вылизана. Регулярные выражения предкомпилируемые и вылизаны в первую очередь.

Если не придираться к реализации,что действительно плохо в этой затее - запуск программы раз в минуту и анализ по моментальным счетчикам. Во-первых это означает высокую инерцию. Теоретически если атака стартует с новыми волнами ровно в первую секунду каждой минуты, она может задрючить сайт за оставшиеся 59 секунд. В идеале будет вполне достаточно N быстрых ботов для ddos продолжительностью N минут. Это совсем немного.

А во-вторых,в этом случае невозможно сформулировать четкие рамки для пользователей сайта типа "если запросов больше 10 в секунду - вас заблокируют", а только "ой, мы не знаем точно, но где то в районе 10, а может 30 запросов в секунду делать не надо".

netwind, вот потому вся эта галиматья с парсингом лога (да еще деревянного формата) - от бедности, как правило. Надо быстро костыль - он делается в момент атаки на sh/awk/sed/perl. А как штатное решение - полностью безнадежно (разве только для тупого парсинга error.log на предмет того, чтобы послать особо ретивых на файервол). Тут совершенно другие механизмы используют, уровня расширений веб-сервера.

PS: Кстати, для апача появился не так давно mod_qos - кто-то использовал это для противодействия DDoS?

myhand, ну так не ведь perl не только для костылей. Не обязательно по крону запускать.

Можно нормального демона сделать и читающего access.log и с быстрым временем реакции.

Да меня несколько другое настораживает. Зачем это решать кого блокировать на куцом уровне парсинга лог файлов, когда самое логичное и простое - делать это с точки зрения приложения, на кое и направлен DDOS. Как нормальные люди и делают.

А уж по крону костыли там или не по крону - дело десятое.

Я когда-то пытался писать систему, которая будет заниматься примерно этим, только более хитро.

После кучи бенчмарков выяснилось, что пытаться что-то постфактумно делать - намного сложнее и дороже - надо распарсивать лог (хотя формат я делал несколько более распарсиваемый), кроме того - осуществлять связь между результатами парсинга логов и вебсервером (либо файлами и ифами в конфиге нгинкса, либо постоянными релоадами, ничего из этого не является хорошим).

В результате появилось лёгкое fastcgi-приложение, которое на каком-либо основании решает, пропустить запрос или нет. Может быть, когда-нибудь оно заработает так, как этого хочется, но сейчас разбираться в нём приходится эпизодически, когда на какой-нибудь из знакомых проектов приходит ddos.

Но придумывание решения о пропускании оказалось нетривиальным, и всё равно пришлось писать парсирку некрасивых логов, чтобы загружать в неё логи нормальной работы сайта. На бусте получилось не больше 400 строк, что выдаёт классификации клиентов "SEO-грабилка/сапа , обычный пользователь, аномальный пользователь, и т.д." и некоторые критерии для определения классификации для конкретного сайта.