Pull to refresh
450
0
Алексей @SaveTheRbtz

SRE

Send message
Hardware очередей на igb сейчас 8. Это значит будь у вас хоть 1024 ядра до RPS/RFS дело не дойдёт, если сетевуха не сможет переварить столько пакетов.
У нас igbшная сетевуха выдерживает без тюнинга 275к пакетов. С тюнингом и бондом на 2 гигабита до 1кк. Ядер много не надо, я вообще не видел дров которые нормально распараллеливаются на больше чем 8 потоков.

Вообще интересно узнать подробнее про специфику этого ддоса:
1) TCP/UDP.
2) Медиана размера пакета
3) Примерный размер вектора аттаки

А то в нас последнее время тож зачастили пуляцца.
Вот что получилось, если вдруг кому интересно:

Очень вовремя, как раз хотел с помощью Gephi нарисовать граф взаимодействий наших поисковых серверов. Спасибо!
/* На случай, если кто-то, всё же, до сюда дочитал */


avrelian Натолкнул меня на интересную мысль: Как можно использовать Нейронную Сеть для кластеризации данных?

После прочтения нескольких десятков pdf'ок по Clusterization using Neural Networks стали выделятся некоторые алгоритмы для unsupervised обучения нейронных сетей. Особо можно выделить SOTA (Self Organising Tree Algorithm — Развитие идеи SOM — Self-Organized Maps) и семейство алгоритмов ART*. Остановлюсь подробнее на последних, ибо они более напоминают устройство нашего мозга: алгоритм устроен на сравнении ожиданий с данными от сенсоров. Если посмотреть на матчасть, то видно, как алгоритм умудряется балансировать между обучением и запоминанием. Так же, довольно интересной для новичков в ML будет являться структура нейронной сети используемой в ART*/SOTA алгоритмах.

В общем будет с чем поиграться на досуге.
Я в вашем примере не могу понять одну вещь: откуда в тестовой выборке появится Надым, ведь он не «хороший»?
1) Она может начать расти только если в тестовом наборе есть «плохие» примеры, иначе ошибка будет 0% и там и там.
2) Вот это уже интересно. То есть «плохие» примеры всё же есть, но они генерируются из «хороших». Правда похоже это возможно делать только имея на руках единовременно все «хорошие», иначе сложно ответить на вопрос: не встречался/встретится ли только что сгенерированный «плохой» пример в «хорошем» наборе. Также, пока не очень понимаю как генерировать словарь для создания feature vector'ов и рассчитывать размер input layer без наличия на руках всех запросов единовременно. Впрочем, некоторыи идеи на этот счёт есть.
3) С этим согласен.
Хммм, всё равно не могу понять: как без «плохих» примеров, даже при наличии test set'а, запрретить сети отвечать на всё запросы «хороший». Ведь именно такой подход обеспечит ей 0% ошибок на Training set и Test set.

Все потому, что она «запомнила» исходные данные.

Ммм… Для того чтобы она действительно смогла «запомнить» все feature vector'а нужно очень большое количество нейронов (= кол-во features * кол-во запросов). Так же скорее всего придётся вводить какие-то ограничения на количество одновременно активных нейронов (sparsity), иначе сеть опять сойдётся на «всё хорошо». Ещё к этому нужно добавить, что я не очень хорошо понимаю как поощрять сеть за удачные «запоминания» и наказывать за неудавшиеся. Хотя, логично предположить, что обучить нейронную сеть запоминать возможно — яркий тому пример наш мозг.

ПС. Так же я не понял разницу между вашими 1) и 2).
«Но на тестовом множестве с определенного момента она(ошибка) начнет расти.»

Моё утверждение было таково: Нейронная сеть обученая только хорошими запросами сойдётся к тому, что будет выдавать «хорошо» на любой ввод. Теперь вопрос: как сеть которая выдаёт на любые входные данные «хорошо» может хоть раз ошибится на тестовом множестве?

ПС. Ещё вопрос: а вы пробовали сами проделать вышеописаный вами эксперимент? Можно и без эксперимента, просто расписав формулы на листочке.
Нет, я имел в виду именно то, что написал.

Давайте поясню:
Давайте отбросим всю математику за процессом обучения и представим нейронную сеть как чёрный ящик. Вы в него кидаете данные, а он выдаёт класс этих данных. При обучении только «хорошими» запросами вы научите нейронную сеть говорить, что запрос хороший, на ЛЮБЫЕ входные данные, ведь именно такое поведение будет выдавать наименьшие ошибки на training и test set'ах.
Если давление во времмя DDoS'а мешает программировать, то конечно нужно блокировать старыми добрыми методами, однако потом ничто не мешает собрать логи и уже в спокойной обстановке попробовать написать что-нибудь интересное.
К сожалению такая нейронная сеть скорее всего сойдётся на том, что будет любой запрос классифицировать как хороший, поэтому такой метод недееспособен.
Я тоже думал по началу это сделать на определении аномалий, но там есть нюанс: нужно вводить дополнительные features являющиеся комбинацией существующих, чтобы ловить запросы с OS Windows ME и referer'ом fc-zenit.ru, а это очень сильно увеличивает их кол-во. Например, из 100 признаков мы получим 5050, если захотим ловить по комбинации двух признаков, а если по трём, то все 171700.
У меня обучение занимало от секунд (1000 экземпляров, ~300 признаков) до дней (1,000,000 экземпляров, ~10000 признаков). Но, ещё раз замечу, что это ни о чём не говорит — всё слишком сильно зависит от алгоритма.
Производительность очень сильно зависит от реализации. Цифры я не озвучивал специально, ибо это всего лишь набросок, темболее на питоне. Любые числа названные мной будут на порядки отличаться от продакш системы.
Насчёт байесовского фильтра — интересная идея на подумать, спасибо.
Ой, промахнулся — коммент ниже приедназначен вам.
Не поверите, но нейронную сеть начал писать только после того как не смог сходу «нагрепать» запросы от ботов, вот, например, угадайте какой из запросов тут от бота:
0.0.0.0 - - [20/Dec/2011:18:13:08 +0400] "GET /forum/index.php HTTP/1.1" 200 25364 "-" "Opera/9.80 (Windows NT 5.1; U; ru) Presto/2.9.168 Version/11.52"

0.0.0.0 - - [20/Dec/2011:15:56:40 +0400] "GET /forum/index.php HTTP/1.1" 200 25364 "-" "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.10.229 Version/11.60"

Так что с заголовками было всё ок.

Как я понимаю, нейронная сеть мне хорошо помогла «поймать» продвинутый, но всё же ограниченный генератор User-agent'ов аттакующего.
Да, я по началу тоже думал принимать решения базируясь не на конкретном запросе, а на блоках, сгруппированных по IP или лучше session_id. Но потом пришла ещё пара мыслей:
1) Строить некий call-graph для каждой сессии и анализировать его.
2) Использовать js для записи и анализировать поведение пользователей.

Но это уже тема для отдельного поста или даже полноценного ПО.
Если я правильно понял — с пунктами 1) и 2) должен справиться PCA.
А вот про третий пункт (и дерево решений, кстати) нужно будет поискать в интернетах, спасибо!

Information

Rating
Does not participate
Location
Mountain View, California, США
Works in
Registered
Activity