ГлавнаяБитриксБитрикс защита от ddos

Особенности использования машинного обучения при защите от DDoS-атак. Битрикс защита от ddos


Базовая защита "Битрикс виртуальная машина" от DDoS атак.

Данный способ защиты не панацея, и скорее всего не спасет от профессиональной DDoS атаки, когда ваш сервер на CentOS подвергается запросам от множества IP адресов. Однако способ бесплатный и убережет, хотя бы, от начинающих DDoS-еров

PS Добавлено после написания заметки. Не учел, один момент. Битрикс виртуальная машина получает запросы на nginx, а не на apache. Чуть позже дополню заметку

Защищаем сайт от DDoS

Суть заключается в установке модуля mod_evasive для Apache. Который будет блокировать IP адреса, с которых идет большое количество запросов к серверу. То есть, защита ставится сразу на весь сервер и под ее правила попадают все сайты на сервере

Устанавливаем сам модуль, командой

yum install mod_evasive

Устанавливаем редактор nano (На виртуальной машине Битрикс его нет, по умолчанию)

yum install nano

Открываем конфиг Apache

nano /etc/httpd/conf/httpd.conf

И добавляем в него строчку, для загрузки модуля при старте

LoadModule evasive20_module modules/mod_evasive20.so

И перезагружаем Apache

service httpd restart

Все теперь ваш сервер защищен от простой, топорной DDoS атаке. Если вас не устраивают правила срабатывания защиты, которые применяются по умолчанию, вы можете сконфигурировать модуль под себя

Для этого открываем файл конфигруции mod_evasive

nano /etc/httpd/conf.d/mod_evasive.conf

И правим на свой вкус. 

camouf.ru

современные подходы к защите / Блог компании 1С-Битрикс / Хабр

В маркетинговых материалах по защите от DDoS-атак, публикуемых всевозможными компаниями, раз за разом встречаются ошибки одного и того же плана. А именно, приводятся взятые из чьих-либо отчётов данные о зафиксированных атаках объёмом, например, 400 Гбит/с, делается вывод, что всё плохо и нужно срочно что-то делать, но при этом в характеристиках предлагаемых услуг указан верхний предел объёма фильтруемых атак в 10 Гбит/с. И такие несоответствия возникают довольно часто.

Происходит это потому, что специалисты, которые создают саму услугу, не очень верят в то, что столь мощные атаки вообще реальны. Потому что ни сами эти специалисты, ни кто-либо, кого они знают, с такими атаками не сталкивались. И потому возникает актуальный для e-commerce вопрос: какие угрозы действительно сейчас актуальны, а какие маловероятны? Как оценивать риски? Обо всём этом и многом другом рассказывается в докладе Артёма Гавриченкова на конференции Bitrix Summer Fest.

Классификация атак

Давайте для начала поговорим о том, какие вообще бывают атаки. В качестве критерия для классификации возьмём объект атаки, то есть что именно выводится из строя. В этом случае можно выделить четыре основных класса атак, осуществляемых на разных уровнях согласно модели OSI.

Первый класс (L2) — «забивание» канала. Это атаки, которые направлены на лишение доступа к внешней сети вследствие исчерпания канальной ёмкости. Абсолютно неважно, каким именно образом. Как правило, для этой цели используются массированные, с точки зрения трафика, атаки типа «что-нибудь»-Amplification (NTP-, DNS-, RIP-… Amplification может быть любой, не имеет смысла перечислять). Вообще, к данному классу атак относятся всевозможные flood’ы, в том числе ICMP Flood и пр. Основная задача состоит в том, чтобы в канал размером, скажем, 1 гигабит/с залить хотя бы 1,1 гигабит/с. Этого будет достаточно для прекращения доступа.

Второй класс (L3) — нарушение функционирования сетевой инфраструктуры. К этому классу относятся, в числе прочего, атаки, приводящие к проблемам с маршрутизацией в рамках протокола BGP, с анонсами сетей (Hijacking) — или атаки, следствием которых становятся проблемы на транзитном сетевом оборудовании: например, переполнение таблицы отслеживания соединений. Атаки данного класса отличаются большим разнообразием.

Третий класс (L4) — эксплуатация слабых мест TCP-стека, то есть атаки на транспортном уровне. Этот транспортный протокол, лежащий в основе HTTP и ряда других протоколов, довольно сложно устроен. Например, в нём используется большая таблица открытых соединений, каждое из которых является, фактически, конечным автоматом. И именно атаки на этот автомат составляют третий класс DDoS-нападений. К третьему классу можно отнести и атаку типа SYN Flood в том случае, если она не нанесла урона на двух предыдущих уровнях, дошла до самого сервера и вследствие этого априори является атакой на TCP-стек. Также сюда можно отнести открытие большого числа соединений (TCP Connection Flood), что приводит к переполнению таблицы протокола. К третьему классу, как правило, относится также использование таких инструментов, как SlowLoris и Slow POST.

Четвёртый класс (L7) — деградация Web-приложения. Сюда относятся всевозможные «кастомные» атаки, начиная от типичного GET/POST/HTTP Flood до нападений, нацеленных на многократно повторяющиеся поиск и извлечение конкретной информации из БД, памяти или с диска, пока у сервера просто не закончатся ресурсы.

Обратите внимание, что оценивать атаку в гигабитах имеет смысл, в основном, на самом низком уровне (L2). Потому что для вывода из строя, к примеру, MySQL с помощью расширенного поиска по всем товарам много гигабит не надо, как и ума. Достаточно использовать от 5000 ботов, которые активно запрашивают поиск и обновляют страницу, возможно даже, одну и ту же (зависит от настроек кэширования на сервере жертвы). При таких атаках проблемы возникнут у многих. Кто-то «просядет» при атаке 50 000 ботов, самые устойчивые системы выдержат атаку вплоть до 100 000 ботов. При этом в прошлом году максимальное зарегистрированное количество одновременно атакующих ботов достигло 419 000.

Защита от атак

Давайте посмотрим, что можно противопоставить на каждом из вышеперечисленных уровней.

L2. Против лома нет приема, окромя другого лома. Если полоса атаки превышает 100 гигабит/с, то эти гигабиты нужно где-то обрабатывать, например, на стороне провайдера или датацентра, и проблема всегда будет в «последней миле». С помощью технологии BGP Flow Spec можно фильтровать часть атак по сигнатурам пакетов — скажем, Amplification легко отсекается по порту источника. Однако подобный способ довольно дорог и не от всего способен защитить.

L3. На L3 необходимо анализировать сетевую инфраструктуру, причём не только свою. Классический пример — в 2008 году Пакистан из-за собственной ошибки перехватывал префиксы у YouTube посредством BGP Hijacking. То есть значительная часть трафика этого видеохостинга перенаправлялась в Пакистан. К сожалению, автоматически с подобной напастью бороться невозможно, всё придётся делать вручную. Но до того, как начнётся борьба, ещё нужно будет определить, что данная проблема (кража префикса) вообще возникла. Если это произошло, то необходимо обратиться к сетевому оператору, к администрации датацентра, к хостеру и т.д. Они помогут в решении проблемы. Но для этого нужна продвинутая аналитика сетевой инфраструктуры, потому что признаком Hijacking служит, в общем случае, только то, что, начиная с какого-то момента, анонсы данной сети в интернете пошли «нетипичные», не такие, как были в течение длительного времени до этого. Соответственно, для своевременного обнаружения необходимо иметь, как минимум, историю анонсов.

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

L4. Для защиты от атак на четвёртом уровне необходимо проводить анализ поведения TCP-клиентов, TCP-пакетов на сервере, эвристический анализ.

L7. На L7 необходимо проводить поведенческий, корреляционный анализ, заниматься мониторингом. Не имея в наличии инструментов для аналитики и мониторинга, взять и настроить тот же Nginx так хорошо, чтобы он отбил любые атаки, невозможно, борьба с атаками всё равно превратится в ручную работу.

Оценка рисков

Итак, где мы принимаем и обрабатываем входящие HTTP-запросы: Для оценки рисков можно применять такой полезный инструмент, как матрица вероятности и воздействия (Probability & Impact Matrix).

По горизонтальной оси откладывается серьёзность последствий того или иного события, а по вертикальной оси — его вероятность. Белой рамкой в данном случае обозначен текущий уровень риска для DDoS-атак.

От чего зависит вероятность проведения атаки? В первую очередь, атаки — это инструмент конкурентной борьбы. Если в вашем сегменте рынка более-менее спокойно, то, скорее всего, атак долгое время не будет. Но если конкуренция возрастает, то нужно готовиться к защите, и белую рамку нужно перемещать вниз по оси.

Но самое страшное в DDoS-атаке — impact, воздействие. Допустим, нападение осуществляется на вашего хостера. Даже если в этот момент обратиться к поставщику anti-DDoS-решений, то не факт, что он сможет помочь. Проблема в том, что ваш IP-адрес, на котором находится «ваше всё» — от Web-сервера до БД и прочих важнейших компонентов — уже известен атакующим. И даже если вы укажете в DNS какой-то другой адрес, с определённой вероятностью это не сыграет никакой роли и атака будет продолжена напрямую. В лучшем случае, вам придётся съехать с этого хостинга. И в этом случае ваши проблемы можно оценить как «очень серьёзные», потому что трудно придумать что-то хуже для IT-проекта, чем переезд на неподготовленную площадку в рабочее время, при лежащем сервере. Ну вот, разве что, патч Бармина — тот да, точно хуже :)

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

Давайте попробуем оценить, насколько тот или иной сетевой ресурс подвержен атакам того или иного сетевого уровня.

Хостинг. Большинство хостингов не смогут отфильтровать мощные атаки, чей трафик существенно превышает 100 Гбит/с. В том числе и на последней миле до вашего сервера. Поэтому вам придётся самостоятельно обрабатывать весь, или почти весь, флуд, который к вам придёт. И на седьмом уровне вам придётся самостоятельно проводить аналитику, потому что это ваш сервер и ваши проблемы.

На L3 опасность не очень высока, потому что, скорее всего, ради вашего ресурса не будут, скажем, воровать префикс у всего хостинга. Это очень трудоёмко и дорого для злоумышленника. Это можно сделать, но нужно очень веское основание. Хотя, конечно, из всякого жизненного правила бывают исключения, особенно если в сетевой инфраструктуре хостинга есть проблемы с производительностью.

Есть важный момент: очень многие вендоры предлагают для защиты дорогостоящее оборудование, которое ставится в вашу стойку и в него включается uplink и downlink, ведущий к вашему серверу. Проблема здесь вот в чём: сеть не более устойчива, чем устойчива «последняя миля», включая используемое вами оборудование. И у вас в любом случае должен быть запас производительности, чтобы в час пик загрузка процессора не была близка к 100%. В противном случае любой незначительный скачок может привести к отказу. Если атакующие неопытны, и вы можете справиться своими силами, то всё равно вам нужен запас прочности, пока вы изучаете запросы, пишете скрипты для автобана, настраиваете fail2ban и т.д.

Также нужно отметить, что если вы физически располагаетесь на ресурсах, которые не защищены, то смена DNS с вероятностью до 30% вам не поможет. Об этом говорит опыт недавних атак на американские финансовые компании. Так что с большой долей уверенности можно сказать, что вам придётся быстро переезжать с незащищённого хостинга.

Облако. У облака обязательно должна быть Anycast-сеть, то есть один и тот же префикс должен быть анонсирован из многих мест в мире. Потому что в одном месте атаку на сотни гигабит не переварить, а через год можно ожидать уже терабитные атаки. Благодаря распределённой структуре опасность атак на канал сильно снижается. Но даже в условиях Anycast-сети атака в 400-500 гигабит/с — это очень много. К этому нужно готовиться, но не все это делают.

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

И наконец, самое «забавное» заключается в том, что облако способно переварить очень много пользовательского трафика, но вам придется его оплатить. Когда счёт достигнет десятков тысяч долларов за прошедший месяц, то вам начнут обрывать телефон, а то и просто отключат по причине вашей неплатёжеспособности. Так что пребывание в облаке всё равно не решает целиком проблему защиты от атак. Оно лишь повышает устойчивость до того, как вы встали под защиту.

CDN. CDN рассчитан на обработку больших объемов трафика, так что со «статикой» (изображения, CSS и пр.) он справится легко. С канальной ёмкостью тут всё то же самое, что и у облака. Но на уровне инфраструктуры гораздо интереснее. У CDN всегда есть DNS-сервер, на который завязаны все услуги ресурса. Если в случае облака инфраструктура сети может быть скрыта за простым Anycast’ом, то у CDN в 99,9% случаев вы будете видеть DNS-маршрутизатор, который перенаправляет пользователя на ближайшую точку CDN. Кроме того, у CDN будут точки, вынесенные из Anycast и из своей сети и расположенные в чужих сетях, поближе к пользователю. Соответственно, они не будут защищены по умолчанию. Их просто невозможно защитить. И здесь всё зависит от того, насколько у CDN защищен его DNS, насколько тот готов к экстренному выключению из сети атакованных нод. Но такое встречается нечасто. DNS-сервер, который занимается раскидыванием пользователей по регионам, должен быть защищён, устойчив и продуман.

Общие советы по сетевой архитектуре

На сегодняшний день средний уровень угроз достиг такого уровня, что самостоятельно с ними справляться очень сложно. Атакующему гораздо легче организовать нападение, чем жертве — защититься. А после двух суток без сна, абсолютно любой системный администратор больше ничего не в состоянии противопоставить атакующему. Поэтому мы запустили новую услугу для клиентов 1С-Битрикс: десять дней в год работы бесплатно. Под атакой, не под атакой — неважно. Так что если у вас случается беда, то в панели управления вашего сайта последней версии «1С-Битрикс: Управление сайтом» есть заветная кнопка, пожалуйста, нажимайте на неё, не стесняйтесь.

habr.com

Особенности использования машинного обучения при защите от DDoS-атак

Этот пост подготовлен по материалам выступления Константина Игнатова, Qrator Labs, на партнёрской конференции «1С-Битрикс».

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

Как правило, владелец ресурса узнает об атаке только в тот момент, когда ему начинают звонить недовольные пользователи. Эту ситуацию большинство компаний встречают неподготовленными. В момент пожара разрабатывать план спасения поздно, и все бросаются на поиски универсального средства, которое окажется под рукой. Но «волшебной пилюли» против DDoS, которая мгновенно бы устранила проблему, нет. Готовиться необходимо заранее. Защита от DDoS — это процесс. Начинать его необходимо не тогда, когда случилась атака, а сильно заранее. Очевидно, что этот процесс относится к сфере информационной безопасности.

Что означает термин «информационная безопасность»? В данном контексте мы говорим о противодействии двух сторон. Злоумышленники (конкуренты, вымогатели, недовольные пользователи) хотят, чтобы ваш сайт хотя бы на время перестал работать (ушёл в даунтайм). Владелец ресурса хочет стопроцентной доступности без перерыва.

Есть два основных принципа информационной безопасности:

Процесс защиты от DDoS

DDoS-атака направлена на исчерпание ограниченных ресурсов. Это могут быть любые ресурсы: Полностью переложить проблему противодействия DDoS на поставщика соответствующей услуги не получится. Необходимо задуматься об этом еще на стадии проектирования системы. Над проблемой защиты должна работать большая команда людей: Рассмотрим, как работают системы противодействия DDoS-атакам на примере Qrator Labs — компании-партнёра «1С-Битрикс», предоставляющей сервис фильтрации трафика. Узнать её защищенный IP-адрес можно в личном кабинете в «1С-Битрикс». После чего можно перевести на этот адрес свой DNS. Старый IP-адрес продолжит работать. Одна из задач внешнего сервиса защиты состоит в том, чтобы никто не знал этот старый IP-адрес. Потому что как только он начинает «светиться», злоумышленники могут атаковать интернет-ресурс в обход защиты Qrator. Для таких случаев тоже есть решения, но их стоимость выше.

Помимо того, что защита от нападений должна быть разработана заблаговременно, сам процесс защиты целесообразно автоматизировать. Злоумышленники, как правило, редко сфокусированы на конкретном сайте. У них всё поставлено на поток, написаны универсальные скрипты. Они автоматически просканировали множество сайтов, обнаружили какую-то уязвимость на вашем и решили атаковать. Запустили скрипт, ушли спать — атака не представляет никакой сложности. А вот на разработку тактики защиты может уйти несколько часов, даже если у вас очень сильная команда специалистов. Вы вносите изменения в свой сайт, атака отражена. Злоумышленник просыпается через несколько часов, меняет пару строчек в своем скрипте, и вам наверняка придётся снова придумывать, как защититься. И так по кругу. Вряд ли ваши спецы выдержат больше 48 часов в таком режиме. После этого приходится прибегать к дорогим средствам защиты, потому что подключение под атакой всегда стоит больше. Нейтрализовать атаку, когда она уже в разгаре, вполне возможно, но это гораздо сложнее, и даунтайма уже не избежать. Внешние поставщики таких услуг, как правило, используют автоматизацию, т.к. «ручные» средства практически никогда не спасают.

Машинное обучение для автоматизации

Когда мы говорим об автоматизации в современных системах противодействия DDoS-атакам, практически всегда подразумевается использование технологий машинного обучения. Применение machine learning необходимо для нейтрализации атак уровня приложений (L7). Большинство других типов атак можно нейтрализовать методом «грубой силы». Во время атаки типа Amplification в канал поступает много одинаковых пакетов. Не нужно применять искусственный интеллект, чтобы понять, где пакет от легитимного пользователя, а где мусор. Достаточно иметь большую канальную емкость, чтобы пропустить и отфильтровать весь плохой трафик. Если емкости не хватает, может пригодиться сторонняя геораспределенная сеть, такая как Qrator, которая примет на себя излишний трафик, отфильтрует мусор и отдаст «чистые» пакеты от легитимных пользователей.

Атака на приложения происходит по другой схеме. В приложение может поступать множество самых разных запросов с большим количеством параметров. Если их достаточно много, этот поток выводит из строя базу данных. Чтобы решить проблему, необходимо уметь распознавать, где запросы от реальных пользователей, а где от ботов. Эта задача неординарная, потому что на первый взгляд они неразличимы. В её решении наиболее эффективно использовать машинное обучение.

Что такое машинное обучение? В первую очередь, это просто набор алгоритмов, который имеет две фазы:

Алгоритмы бывают трёх типов: В качестве примера задачи для машинного обучения я взял статистику по уровню входного трафика одного из наших клиентов (верхний график). А на нижнем графике представлен прогноз, построенный на основании тестовых данных (выделенный синим участок в начале кривой).

Сверху приведены суточные изменения объемов трафика На второй картинке смотрим график начала нагрузки, алгоритм предсказывает каким будет дальше трафик. Это пример регрессии.

Влияние злоумышленников на процесс обучения

При помощи алгоритмов машинного обучения рассчитывается оценка математического ожидания, дисперсии или других числовых характеристик распределения той или иной случайной величины.

Чтобы соответствовать принципам информационной безопасности, алгоритм должен работать в соответствии с двумя основными требованиями:

В нашем случае данные для обучения — это информация об активности пользователей. Это значит, что злоумышленники могут оказать влияние как минимум на часть данных, на которых мы собираемся учиться. А что если им придёт в голову отличная идея: так повлиять на общую статистику, чтобы наши алгоритмы научились именно тому, что хотят злоумышленники? Это вполне может произойти, а значит необходимо заранее предотвратить такую возможность.

Вот пример из нашего внутреннего отчёта о странной активности у одного из наших клиентов.

Каждый вечер, в одно и то же время количество пакетов увеличивалось. Не смертельно, сайт продолжал открываться, нагрузка была на грани допустимого (на графике логарифмический масштаб). Причиной этого могло быть всё, что угодно: cкорее всего, сисадмин что-то напутал, записал в cron операцию ежедневного сохранения бэкапов на определенное время. Но может быть кто-то пытается научить наши алгоритмы пропускать нелегитимный трафик.

Уметь так делать и уметь защищаться от этого — непростые задачи, над их решением трудятся лучшие умы, в Сети есть уже немало научных статей на эту тему. Наши алгоритмы пока никто не смог научить «плохому» и мы готову к тому, что кто-то попытается. Сейчас расскажу, почему у злоумышленников ничего не выйдет.

Как с этим бороться? На первом этапе (обучение) важными становятся такие понятия, как робастность и breaking point.

Робастность — мера того, насколько легко можно повлиять на прогнозируемую оценку. Breaking point — количество образцов в обучающей выборке, достаточное для искажения оценки. Хотя оба термина очень близки друг к другу, нам ближе второй из них. Он означает количество искаженных, неправильных элементов в обучающей выборке — тех исходных данных, на которых мы учимся,— позволяющее повлиять на результаты прогнозирования.

Если breaking point равен нулю, то алгоритм может сломаться сам по себе. Если breaking point равен единице, то достаточно вбросить один-единственный неправильный запрос, и система будет предсказывать не то, что должна.

Чем выше значение breaking point, тем сложнее — а значит дороже для злоумышленника — повлиять на обучение алгоритмов. Если мы так обучили нашу систему, что breaking point высокий, вопрос противодействия перемещается в экономическую плоскость. Выигрывает тот, кто потратил меньше денег.

В идеале защита должна стоить очень мало, а ее преодоление – очень много.

На втором этапе (отработка алгоритма) нужно помнить о том, что всё может пойти не так, как планировалось. Иногда приходится анализировать постфактум, а что же всё-таки произошло. Поэтому неплохо бы иметь возможность заставить алгоритмы «рассказать», как они отработали и почему. Объяснимость действий алгоритма помогает «приглядывать» за автоматизированным процессом, а также облегчает задачи тестирования, отладки и расследования инцидентов.

Сбор данных

Алгоритмам машинного обучения нужны данные. Где их взять? В принципе, здесь у нас всё под рукой…

Какие именно данные нужно собирать? В первую очередь, необходимо наблюдать за всеми исчерпаемыми ресурсами:

Собирать и хранить такие данные легко — существует множество инструментов для этого. Объём таких данных предсказуем. Если вы каждую минуту записывали один мегабайт данных телеметрии, то даже после начала DDoS-атаки вы всё равно будете записывать один мегабайт. Если вы ещё этого не делаете, то самое время начать.

Второй тип данных для анализа – поведение пользователей, которое отражено в логах (в основном это access.log и\или лог, хранящий запросы к базе данных). Они должны быть в удобном для машины формате.

В отличие от телеметрии, объем логов растёт как минимум линейно с количеством запросов. Особенно чувствительно это может быть во время DDoS-атаки, когда ресурсов катастрофически не хватает. У вас ЦПУ загружен на 100%, а тут еще система пытается сохранить 2Гб логов. Нужно сделать так, чтобы эта задача в критических ситуациях либо не запускалась, либо прерывалась. Но неплохо всё-таки, чтобы хотя бы какие-то логи сохранялись даже под атакой.

Можно хранить не все логи, а только часть. Но нужно подойти к этому с умом. Не имеет смысла записывать каждый десятый запрос, нужно сохранять сессиями. Например, вы можете вычислять некриптографический хэш от IP-адреса и сохранять только определённый диапазон этих хэшей: пусть некриптографический хэш принимает значения в диапазоне от 1 до 100. Начинаем с сохранения всех запросов. Если не успеваем, сохраняем запросы только от тех IP-адресов, хэш которых находится в диапазоне 1-90. Уменьшаем интервал, пока не сможем справиться с потоком.

Также всегда нужен хотя бы небольшой образец логов «чистого поведения» системы (то есть не под атакой). Даже если вы их не храните, периодически можно записывать небольшой дамп, чтобы иметь представление о том, как себя ведут пользователи, когда на вас нет DDoS-атаки.

Что полезного мы можем извлечь из сохраненной телеметрии и логов? На основе телеметрии мы можем научить алгоритмы определять, когда ресурсы сервера близки к исчерпанию. Если есть логи, можем проанализировать, чем отличается поведение злоумышленников от обычных пользователей. Можем группировать пользователей по разным признакам, например, выбирать тех, кто оказывает большую нагрузку, но при этом не приносит дохода. Зачем это может понадобиться? Если сервер совсем не справляется с нормальной нагрузкой (когда нет атаки), то, к сожалению, придётся банить кого-то из легитимных пользователей. Кого? Явно не тех, кто сейчас нажимает «купить».

Примеры задач

На практике обычно алгоритмы не используются по отдельности, а складываются в цепочку задач (pipeline): то, что получается на выходе из одного алгоритма, используется как входные данные для другого. Или результаты работы одного алгоритма используются, как параметры для настройки другого.

Рассмотрим примеры задач, которые раскладываются на цепочки.

Задача №1. Оценить будущую плановую нагрузку на сайт

Задача раскладывается на следующие шаги:

Задача №2. Принять решение, нужно ли кого-нибудь банить, если мы видим признаки атаки На текущий момент мы точно знаем, что есть атака. Возможно, следует заблокировать часть IP-адресов, которые участвуют в нападении. Но агрессивная блокировка приводит к тому, что будет забанена и часть легитимных пользователей. Эта ситуация называется False Positive, и нужно стремиться, чтобы таких случаев было как можно меньше (алгоритм ошибочно — False — относит пользователя к группе тех, кто причиняет вред — Positive). Если сервер способен «переварить» атаку (то есть обработать все запросы) без последствий для пользователей, то и делать ничего не надо. Следовательно, необходимо оценить способность сервера выдержать атаку без даунтайма. Задача раскладывается на следующие шаги: Очевидно, что данная задача — это часть цепочки, которая ведёт к достижению главной цели — доступности сервера. На следующем этапе, например, необходимо решить, какие именно запросы нужно блокировать.

Задача №3. Запросы от каких реальных пользователей можно отфильтровать с меньшими потерями для бизнеса, если сервер не справляется с легитимной нагрузкой В этой задаче мы рассматриваем ситуацию, когда легитимная нагрузка на сервер больше, чем он способен выдержать (даже без учета зловредного трафика). Такие ситуации, к сожалению, случаются. Чтобы решить эту задачу, нужно пройти два первых шага из Задачи №2. То есть данная задача — это тоже часть некоторой цепочки.

Затем идём по следующим шагам:

В идеале хорошо бы рассчитать вероятную прибыль от каждой сессии из текущих, чтобы банить только тех, кто наименее важен. Но на практике обычно применяют эвристики и упрощают задачу — блокируют тех пользователей, чьи сессии имеют признаки менее важных.

Остановимся подробнее на Задаче №1 Помните график, на котором отображена входная нагрузка на одного нашего клиента? На самом деле, ради красоты он очищен. Реальный график выглядит так:

Видим много огромных всплесков, на несколько порядков превышающих обычный уровень нагрузки. Также видно, что нагрузка непостоянна, дни бывают очень разные. То есть задача построения робастной модели на основе таких данных нетривиальна.

На эту тему написаны горы статей и проведено множество исследований. Но общепринятого идеального решения здесь нет.

Могут использоваться следующие подходы:

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

Сверху — исходные данные. Второй график — результат робастной нормализации с её помощью мы уменьшаем влияние аномалий. Последний график — результат нелинейного обратимого преобразования. То, что у нас есть аномалия, мы поняли уже на втором графике, после этого ее абсолютная величина нас уже не очень интересует. Мы её «обрезаем» при помощи нелинейного преобразования. Получаем данные, с которыми гораздо проще работать.

Этот же самый график можно визуализировать в виде цветной картинки.

Читается эта картинка построчно слева направо, сверху вниз. По горизонтали – секунды с начала дня, по вертикали – даты. Желтый и красный (например, в правом верхнем углу) показывают высокую нагрузку.

После применения вышеописанных подходов, мы можем сгруппировать разные дни по уровню нагрузки и кластеризовать их.

Мы можем увидеть три разных типа нагрузки, которые более явно отражены на следующих иллюстрациях.

Справа – ожидаемая нагрузка в разные типы дней. Слева — робастный аналог стандартного отклонения (разброс квантилей).

Применим это к реальной ситуации. Фиолетовая линия отражает нагрузку в течение некоторого периода времени. Она ближе всего к синей пунктирной кривой. То есть это тот тип, на который нужно ориентироваться при прогнозе нагрузки.

Поиск групп признаков

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

В первом случае анализируем каждый запрос в отдельности, ищем, например, признаки нелегитимных ботов… Во втором случае анализируем, по сути, поведение пользователей.

Примеры признаков запросов:

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

Например, если в логе есть часть запросов, URL которых заканчивается на /login, то мы можем выделить это как признак и разметить каждый запрос по этому признаку (пометить единицей или нулём — заканчивается URL запроса на /login или нет). Или мы можем пометить запросы, которые пришли с сайта example.com, единицами, а все остальные — нулями. Или можем выделить признак по длительности обработки запроса: длительные, быстрые и средние. То есть по сути мы смотрим на данные и пытаемся понять, какие признаки нам могут понадобиться. В этом суть процесса так называемого feature extraction. Потенциальных признаков бесконечно много. При этом любая группа или множество признаков также формирует новый признак. Это усложняет задачу.

Итак, задача разбивается на две подзадачи:

В реальности это может выглядеть вот так:

На картинке выше запросы превращены в признаки. На следующей картинке мы сгруппировали признаки, выделили новые и посчитали, как часто они встречаются. В этой задаче мы анализировали около 60 000 запросов (что не так уж и много, но это просто пример).

В правом столбике указано сколько запросов соответствует данной группе признаков. Видно, что количество разное, и что один запрос может попасть в несколько групп. То есть есть запросы, которые не попали в некоторые группы. Мы помечаем каждый запрос массивом из десяти нулей или единиц. Единица означает, что запрос соответствует группе, ноль — что не попадает в неё. Таким образом, у нас получается массив в виде матрицы 60 000х10. С этой числовой информацией можно работать также, как описано выше.

Чтобы выделить такие признаки, используются специальные алгоритмы. Описывать их здесь подробно не буду.

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

Другой тип базы данных работает не с множествами, а с последовательностями. Это нужно для анализа сессий, потому что сессия, по сути, — последовательность запросов. Такая БД умеет выделять все подпоследовательности определённого типа. Например, запрос к ней: найти в логе среди всех подпоследовательностей во всех сессиях такие, которые удовлетворяют определённому критерию, и отсортировать эти подпоследовательности по количеству сессий, в которых они встретились.

Третий тип баз данных позволяет работать с переходами из одной части сайта в другую в рамках одной сессии. То есть каждая сессия теперь — граф. БД должна уметь находить все подграфы, удовлетворяющие определенному критерию, и сортировать их по количеству сессий, в которых они встретились.

Этот процесс называется pattern discovery. В качестве паттернов выступают множества, последовательности или графы.

С помощью такого анализа можно найти интересующие нас группы пользователей. Результат такого анализа можно изучать даже вручную. Нужно ко всему этому готовиться заранее

Ещё раз подчеркну, что на всё это понадобится время. Защиту от DDoS нельзя просто взять и включить (в момент атаки) — её нужно готовить заранее. Нужно найти подходящих людей и обучить их. Нужно собрать данные, которые можно будет использовать для обучения. Возможно, потребуется что-то изучить, посмотреть вручную, найти узкие места. Алгоритмы системы защиты нужно обучить. Необходимо проверить, что сервер или, напрмер, почтовый демон не «светит» незащищённый IP.

Всё это — часть большого процесса и не может произойти моментально.

С другой стороны, хочу заметить, что, результаты работы системы защиты от DDOS можно использовать для бизнес-аналитики. Например, отдать в работу маркетинговому отделу данные группы пользователей, которых мы решили не банить, потому что они приносят доход.

habr.com

A/B тестирование, триггерные рассылки и защита от DDoS

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.detail/.default/template.php

27 Мая 2015 Компания «1С-Битрикс» представила новую версию основного продукта — платформы «1С-Битрикс: Управление сайтом 15.5». Впервые в продукте появились уникальные инструменты для измерения и анализа конверсии, проведения A/B тестирования, осуществления триггерных рассылок и защиты от DDoS-атак. Также, в соответствии с требованиями Google к сайтам, в рамках платформы реализован набор решений и новые инструменты SEO для сохранения и повышения позиций сайтов в поисковой выдаче.

Теперь владельцам интернет-ресурсов не нужно заказывать дополнительную разработку необходимых для сайта инструментов, весь необходимый комплекс реализован в рамках платформы.

Пульс конверсии. Конверсия — основной показатель качества работы интернет-проекта. Увидеть конверсию сайта теперь можно в режиме реального времени. В новой версии появился инструмент, который показывает конверсию сайта за выбранный период времени и аналитику по каждому из каналов привлечения клиентов: контекстной рекламы, SEO, триггерных рассылок и мобильного трафика. Конверсию также можно оценить для пользователей в зависимости от типа устройств — компьютера, планшета или смартфона. Результат отображается в «пульсе конверсии» — индикаторе изменения конверсии сайта.

A/B тестирование. Один из самых эффективных маркетинговых инструментов, который используется для оценки и управления конверсией сайта. Инструмент облегчит работу маркетолога — он встроен в продукт и не требует дополнительных настроек. Пользователю доступно шесть готовых сценариев A/B тестирования — новый дизайн, главная страница, детальная карточка товара, страницы корзины, страница оформления заказа и произвольно выбранная страница. На основании тестирования будет выбран наиболее эффективный вариант для показа.

Бизнес-модель интернет-магазина. В платформе включен аналитический инструментарий, который позволяет оценить эффективность работы интернет-магазина: его прибыльность, какова цена перехода и средний чек. Владелец сайта может, изменяя ключевые параметры проекта, прогнозировать прибыль, таким образом определяя наиболее оптимальные показатели.

Триггерные рассылки. Для любого интернет-проекта важно не просто привлечь новых покупателей, но и удержать существующих. В новом «1С-Битрикс: управление сайтом 15.5» появился удобный инструмент взаимодействия с посетителями сайта — автоматизированная система триггерных рассылок, увеличивающая количество возвратов и повторных покупок в магазине. В продукте реализовано семь готовых сценариев триггерных рассылок: брошенная корзина, отмененный заказ, повторные заказы и 4 вида рассылок для клиентов, не заходивших в магазин в течение 90, 111, 180 и 365 дней. Для каждого сценария можно один раз настроить шаблон письма, и письма будут отправляться автоматически каждому пользователю, если он попадает в одну из категорий. Эффективность каждой рассылки может быть проанализирована.

АвтоБюджет контекста. Контекстная реклама становится основным источником привлечение клиентов на сайт, но часто расход бюджета бывает неэффективным. 

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

«1С-Битрикс» предлагает инструмент для управления контекстными рекламными кампаниями прямо из административной панели сайта. Инструмент позволяет автоматически прекращать или возобновлять рекламные кампании в зависимости от наличия товаров на складе, автоматически приостанавливать рекламные кампании, если стоимость перехода выше, чем стоимость товара.

Встречаем мобильных клиентов. Современные поисковые системы ранжируют сайты в зависимости от наличия адаптивной или мобильной версии. И сайты с адаптивной версией имеют более высокие позиции в поисковой выдаче. В продукте представлен комплекс решений для выполнения требований Google к сайтам — используется современная технология адаптивной верстки с использованием Bootstrat 3, объединение и сжатие javascript и CSS-файлов, ускорение сайта 2.0, оптимизация изображений и перенос javascript вниз страницы. 

Все эти изменения позволят клиентам не только сохранить, но и повысить позиции своих сайтов в поисковой выдаче.

Защита от DDoS. Самое важное для каждого интернет-бизнеса — непрерывность его работы. От DDoS никто не застрахован, и чаще всего атака начинается неожиданно. «1С-Битрикс» совместно с компанией Qrator — лидером рынка защиты от DDoS — обеспечивает владельцам сайтов 10 дней защиты от DDoS-атак бесплатно. А в случае продолжающейся атаки заключить долгосрочный договор, обеспечив тем самым непрерывность работы бизнеса. Для клиентов «1С-Битрикс» на сайте представлена инструкция для активации услуги.

Веб-акселератор. Программный продукт, разработанный для редакции «1С-Битрикс: Энтерпрайз». Предназначен для создания точек присутствия компании, построения распределенных систем и ускорения доставки контента по стране и миру. Обеспечивает максимально быстрое отображение страниц сайта.

Другие, но не менее важные новинки:

BigData с прогнозированием интереса. Для сервиса BigData:Персонализация разработана новая технология InterestID, которая увеличила силу рекомендаций в 3 раза, а также улучшила рекомендации для первичных посетителей сайта. На основании собранной за полгода работы сервиса статистики, персональные рекомендации дают клиентам «1С-Битрикс» увеличение числа новых заказов от 9% до 37%.

Новые возможности для SEO-оптимизации. Выпущен набор решений, чтобы сделать сайты более дружественными для поисковых систем. Появились: ЧПУ 2.0, канонические ссылки, ЧПУ в умном фильтре, хлебные крошки и др.

Новая интеграция с 1С. Представлен новый интерфейс, реализован модуль обмена с 1С:ERP 2.0, а также поддерживается обмен скидок между 1С и интернет-магазином.

Новый визуальный редактор. Позволяет вставлять текстовые файлы с исходным форматированием, сохраняя их структуру.

Обработка изображений. В продукте появляется возможность обрабатывать изображения перед загрузкой на сайт. Отлично решит задачу быстрой загрузки большого числа фотографий.

«Интернет-рынок меняется очень быстро, конкуренция возрастает, и в современных условиях уже не достаточно просто привлекать много посетителей на сайт. Их нужно успешно превращать в покупателей. Комплекс реализованных в новой версии продукта инструментов идеально выполнит задачу повышения конверсии сайта и продаж для вашего бизнеса», — отметил генеральный директор компании «1С-Битрикс» Сергей Рыжиков.

Источник:  HTTP://www.1c-bitrix.ru/about/life/news/1360489/

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.list/list/template.php

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.list/list/template.php

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.list/list/template.php

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.list/list/template.php

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.list/list/template.php

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.list/list/template.php

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.list/list/template.php

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.list/list/template.php

08:25:04 - 07.08.2018 /bitrix/templates/.default/components/bitrix/news/mpo_news/bitrix/news.list/list/template.php

mpo.kz

Prostoy-Site | Все права защищены © 2018 | Карта сайта