Ddos

Как известно, лень двигатель прогресса. А самоизоляция двигатель DDoS'а, добавим мы по итогу осмысления былого за март-май 2020 г. Пока кто-то страдал от безвыходности (в буквальном смысле) своего положения, мамкины хакеры страдали фигней от неотвратимости онлайн-обучения и грядущих экзаменов. Деятельно страдали (эту бы энергию да в мирное русло!). По количеству DDoS-атак в сфере образования наблюдалась наибольшая динамика роста. На пике в апреле число попыток устроить отказ в обслуживании образовательным ресурсам (электронным дневникам, сайтам с проверочными работами, площадкам для онлайн-уроков и т.д.) увеличилось в 5,5 раз по отношению к марту и в 17 раз по отношению к январю 2020 г. Всё это были маломощные (и наверняка бесплатные) атаки с использованием простых легкодоступных инструментов. Разумеется, под прицел злоумышленников (правда, уже более продвинутых) попали и другие отрасли, но тут было ожидаемо: онлайн-торговля, госсектор финансовая сфера, телеком и игровой сегмент. Подробности, как всегда, под катом.



Аналитика, которую мы приводим ниже, составлена на основе данных об атаках на сетях Ростелекома с января по май 2020 года.

Как менялось количество атак

Итак. В марте-мае 2020 года количество DDoS-атак увеличилось в 5 раз в сравнении с аналогичным периодом прошлого года. В целом за первые пять месяцев 2020-го общее число подобных атак год к году выросло более чем в 4 раза.

Отчетливо видно, как киберпреступники наращивали свою активность по мере введения карантинных мер. Самый пик пришелся на апрель, когда количество атак в сравнении с январем увеличилось на 88%. Тут стоит отметить, что годом ранее динамика не была такой яркой, а количество атак из месяца в месяц оставалось плюс-минус одинаковым.



В период самоизоляции изменился и характер интернет-трафика. Многие организации, работавшие раньше только в офлайн, запустили собственные интернет-ресурсы, в том числе халявные. Добавим сюда массовую удаленку и получим новую реальность в сети: если раньше интернет-активность плавно нарастала, достигая пика к 17:00-21:00, то теперь резкий рост был отмечен примерно в 10:00 и не снижался раньше 23:00. В целом трафик за пять месяцев 2020 года вырос примерно на 20% (а где трафик там и диверсанты).

Характеристики атак

При резком росте количества DDoS-атак их сложность и мощность в целом снизились. В основном злоумышленники использовали обычную DNS- или NTP-амплификацию небольших объемов (до 3 Гб/с).

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

На кого охотились

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



Но не школой единой был жив DDoS. Увеличилось количество атак и на госучреждения в апреле более чем в 3 раза в сравнении с мартом.



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



Несмотря на то, что в целом за отчетный период мощность атак упала, в общей статистике выделились операторы связи и дата-центры: здесь чаще обычного случались атаки 150+ Гб. DDoS в этих двух сегментах позволяет вывести из строя не один конкретный сайт, а ударить оптом по клиентам оператора и ресурсам, которые обслуживает ЦОД. При этом такие компании лучше защищены, чем, например, госучреждения или образовательный сегмент. Поэтому злоумышленникам приходится применять более совершенные инструменты. В период пандемии атаки на эти два сегмента были быстрыми и мощными и осуществлялись, скорее всего, через реальные хосты, собранные в одну бот-сеть с возможностью за считанные минуты перенаправить ее на новую жертву.

В целом такое разделение по отраслям продолжает тренд, который сформировался еще в 2019 году. Например, в 2018 году на телеком-индустрию приходилось только 10% всех DDoS-атак, а в 2019 уже 31%. Мишенями хакеров становились небольшие региональные интернет-провайдеры, хостинги и дата-центры, которые обычно не располагают необходимыми для отражения атак ресурсами.

Итого

В период действия карантина на фоне распространения COVID-19 (март-май 2020 года) было зафиксировано в пять раз больше DDoS-атак, чем годом ранее.

Доля простых и маломощных атак увеличилась, что указывает на активность непрофессиональных злоумышленников.

В 5,5 раз выросло количество атак на образовательные ресурсы, а самые мощные атаки за отчетный период пришлись на операторов связи и дата-центры.



Наибольший объем атак в марте-мае пришелся на сектор онлайн-торговли (31%), который традиционно является одним из основных объектов для DDoS. Вторым по популярности стал госсектор (21% атак). Далее следуют финансовая сфера (17%), телеком (15%), образование (9%) и игровой сегмент (7%).

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

Однако, как показал минувший карантин, невозможно спрогнозировать наверняка, когда именно в компанию придет DDoS, так что соломку лучше подстелить заранее.

Пару лет назад исследовательские агентства и провайдеры услуг информационной безопасности уже начали было докладывать о снижении количества DDoS-атак. Но уже к 1-му кварталу 2019 года те же исследователи сообщили об их ошеломляющем росте на 84%. А дальше все пошло по нарастающей. Даже пандемия не поспособствовала атмосфере мира напротив, киберпреступники и спамеры посчитали это прекрасным сигналом к атаке, и объем DDoS вырос вдвое.



Мы уверены, что время простых и легко обнаруживаемых DDoS-атак (и несложных инструментов, которые могут их предотвратить) уже кончилось. Киберпреступники научились лучше скрывать эти атаки и проводить их все более изощренно. Темная индустрия перешла от brute force к атакам на уровне приложений. Она получает серьезные заказы на разрушение бизнес-процессов, включая вполне себе оффлайновые.

Врываясь в реальность

В 2017 году серия DDoS-атак, направленных на транспортные услуги Швеции, привела к длительным задержкам поездов. В 2019 году у национального железнодорожного оператора Дании Danske Statsbaner отключились системы продаж. В результате на станциях не работали автоматы по продаже билетов и автоматические ворота, и более 15 тысяч пассажиров не смогли никуда уехать. В том же 2019-ом мощная кибератака вызвала отключение электроснабжения в Венесуэле.

Последствия DDoS-атак теперь испытывают не только онлайн-пользователи, но и люди, как говорится, IRL (in real life). Хотя исторически атакующие целились только на онлайн-сервисы, теперь часто их задача нарушить любые бизнес-операции. По нашим оценкам, сегодня у более чем 60% атак есть такая цель для вымогательства или нечистоплотной конкурентной борьбы. Особенно уязвимы при этом транзакции и логистика.

Умнее и дороже

DDoS продолжает считаться одним из самых распространенных и быстрорастущих видов киберпреступности. По прогнозам экспертов, с 2020 года их количество будет только расти. Это связывают с разными причинами и с еще большим переходом бизнеса в онлайн из-за пандемии, и с развитием самой теневой отрасли киберпреступлений, и даже с распространением 5G.

Популярными DDoS-атаки стали в свое время из-за простоты развертывания и низкой стоимости: еще пару лет назад их можно было инициировать за $50 в день. Сегодня как цели, так и методы атаки изменились, что привело к увеличению их сложности и, как следствие, стоимости. Нет, цены от $5 в час по-прежнему есть в прайсах (да, у киберпреступников есть прайсы и тарифные сетки), но за сайт с защитой уже требуют от $400 в сутки, а стоимость индивидуальных заказов на крупные компании доходит до нескольких тысяч долларов.

Сейчас существует два основных типа DDoS-атак. У первого цель сделать онлайн-ресурс недоступным в течение определенного периода времени. Оплату за них злоумышленники берут за время самой атаки. В этом случае DDoS-оператор не заботится о каком-либо конкретном результате, а клиент фактически делает предоплату за начало атаки. Такие методы достаточно дешевы.

Второй тип атаки, которые оплачиваются только при достижении определенного результата. С ними уже интереснее. Они намного сложнее в исполнении и поэтому значительно дороже, поскольку атакующим приходится выбирать наиболее эффективные методы для достижения целей. В Variti мы иногда проводим целые шахматные партии с киберпреступниками, в которых они мгновенно меняют тактику и инструменты и пробуют разом прорваться в несколько уязвимостей на нескольких уровнях. Это явно командные атаки, в которых хакеры прекрасно знают, как реагировать и противодействовать действиям защитников. Бороться с ними не только непросто, но и еще и очень затратно для компаний. Например, один из наших клиентов, крупный сетевой ритейлер, почти три года держал у себя команду из 30 человек, чьей задачей было бороться с DDoS-атаками.

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


Данные от GlobalDots

Новые цели DDoS

Отчет Bad Bot Report от аналитиков из GlobalDots говорит о том, что боты сейчас генерируют 50% всего веб-трафика, причем 17,5% из них это именно вредоносные боты.

Боты умеют по-разному портить жизнь компаниям: плюс к тому, что они кладут сайты, они теперь занимаются и тем, что увеличивают расходы на рекламу, скликивания рекламные объявления, парсят цены, чтобы сделать их на копейку меньше и переманить покупателей, и крадут контент с разными нехорошими целями (например, мы недавно писали о сайтах с ворованным контентом, которые заставляют пользователей решать чужие капчи). Боты сильно искажают различную бизнес-статистику, а в итоге решения принимаются на основе неверных данных. DDoS-атака часто бывает дымовой завесой для еще более серьезных преступлений типа взлома и кражи данных. А теперь мы видим, что добавился целый новый класс киберугроз это нарушение работы определенных бизнес-процессов компании, часто оффлайновых (так как в наше время ничего не может быть совершенно вне сети). Особенно часто мы видим, что ломают логистические процессы и коммуникации с клиентами.

Не доставлено

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

Нет в наличии

Если вы работаете в сфере онлайн-коммерции, то уже наверняка знакомы с проблемой фейковых заказов. В случае атак боты перегружают логистические ресурсы и делают товары недоступными для других покупателей. Для этого они размещают огромное количество фейковых заказов, равное максимальному количеству товаров в наличии. Эти товары потом не оплачиваются и через некоторое время возвращаются на сайт. Но дело уже сделано: они были помечены как нет в наличии, и часть покупателей уже ушла к конкурентам. Эта тактика хорошо знакома в индустрии авиабилетов, где иногда боты мгновенно раскупают все билеты практически сразу после их появления. Например, один из наших клиентов крупная авиакомпания пострадал от такой атаки, организованной китайскими конкурентами. Всего за два часа их боты заказали 100% билетов на определенные направления.

Sneakers bots

Следующий популярный сценарий: боты мгновенно покупают всю линейку продуктов, а их владельцы продают их позже по завышенной цене (в среднем наценка составляет 200%). Таких ботов называют sneakers bots, потому что с этой проблемой хорошо знакомы в индустрии модных кроссовок, в особенности лимитированных коллекций. Боты практически за минуты скупали только что появившиеся новые линейки, при этом блокируя ресурс так, чтобы туда не смогли прорваться реальные пользователи. Это редкий случай, когда про ботов писали в модных глянцевых журналах. Хотя в общем-то, перепродавцы билетов на крутые мероприятия типа футбольных матчей пользуются тем же сценарием.

Другие сценарии

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

Что еще? Боты оставляют массовые фейковые плохие отзывы о товарах, забивают функцию возврат платежа, блокируя транзакции, крадут данные клиентов, спамят реальным покупателям вариантов множество. Хороший пример недавняя атака на DHL, Hermes, AldiTalk, Freenet, Snipes.com. Хакеры притворились, что они тестируют системы защиты от DDoS, а в итоге положили портал бизнес-клиентов компании и все API. В итоге случились большие перебои в доставке товаров покупателям.

Позвоните завтра

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

Как и в случаях с DDoS, цели TDoS массовых атак ботов на телефоны варьируются от розыгрышей до нечистоплотной конкурентной борьбы. Боты способны перегрузить контакт-центры и не пропустить реальных клиентов. Этот метод эффективен не только для колл-центров с живыми операторами, но и там, где используются системы AVR. Боты также могут массово нападать на другие каналы коммуникации с клиентами (чаты, emails), нарушать работу CRM-систем и даже в некоторой степени негативно влиять на управление персоналом, ведь операторы перегружены, пытаясь справиться с кризисом. Атаки также могут быть синхронизированы с традиционной DDoS-атакой на онлайн-ресурсы жертвы.

Недавно подобная атака нарушила работу службы спасения 911 в США обычные люди, остро нуждающиеся в помощи, просто не могли дозвониться. Примерно в то же время Дублинский зоопарк постигла та же участь: по меньшей мере 5000 человек получили спам в виде текстовых SMS-сообщений, побуждающих их срочно позвонить по номеру телефона зоопарка и попросить вымышленного человека.

Wi-Fi не будет

Киберпреступники также могут легко заблокировать всю корпоративную сеть. Часто блокировка IP используется в качестве борьбы с DDoS-атаками. Но это не только неэффективная, но и очень опасная практика. IP-адрес легко найти (например, с помощью мониторинга ресурсов) и легко заменить (или подделать). У наших клиентов до прихода в Variti были случаи, когда это привело к тому, что блокировка определенного IP попросту отключила Wi-Fi в их собственных офисах. Был случай, когда клиенту подсунули нужный IP, и он заблокировал доступ к своему ресурсу пользователям из целого региона, причем долго этого не замечал, потому что в остальном весь ресурс прекрасно функционировал.

Что нового?

Новые угрозы требуют новых решений для защиты. Однако эта новая ниша на рынке только начинает формироваться. Решений для эффективного отражения простых атак ботов множество, а вот со сложными все не так просто. Многие решения по-прежнему практикуют методы блокировки IP. Другим нужно время, чтобы собрать первичные данные для начала работы, и эти 10-15 минут могут стать уязвимостью. Есть решения, основанные на машинном обучении, которые позволяют определять бота по его поведению. И одновременно команды с той стороны хвастаются, что у них уже есть боты, которые могут имитировать реальные, неотличимые от человеческих паттерны. Кто кого пока непонятно.

Что делать, если приходится бороться с профессиональными командами ботоводов и сложными, многоэтапными атаками сразу на нескольких уровнях?

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

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

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

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

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

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

Что думаете вы как будет развиваться отрасль защиты от ботов и какие решения необходимы на рынке уже сейчас?

На первом в истории полностью виртуальном мероприятии РИТ++, прошедшем в конце мая, инженер Qrator Labs Георгий Тарасов, рассказал публике про веб-скрейпинг, он же парсинг, популярным языком. Мы решили предоставить вашему вниманию транскрипцию выступления.



Всем привет! Наша компания достаточно давно занимается проблематикой защиты от DDoS-атак, и в процессе этой работы мне удалось достаточно подробно познакомиться со смежными сферами изучить принципы создания ботов и способы их применения. В частности web scraping, то есть массовый сбор публичных данных с веб-ресурсов с использованием ботов.

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

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



Я буду рассказывать о следующем:

• Зачем вообще люди друг друга скрейпят;
• Какие есть виды и признаки такого скрейпинга;
• Какое влияние он оказывает на целевые веб-сайты;
• Какие средства и технические возможности используют создатели ботов, чтобы заниматься скрейпингом;
• Как разные категории ботов можно попробовать обнаружить и распознать;
• Как поступить и что делать, если скрейпер пришел в гости на ваш сайт (и нужно ли вообще что-то делать).

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

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

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

Давайте подумаем сделали ли вы кому-нибудь в процессе плохо? Ну, если только вы не парсили HTML регулярным выражением, то скорее всего никому плохо вы не сделали, а тем более сайтам, на которые вы таким образом сходили. Это однократная деятельность, ее можно назвать скромной и незаметной, и вряд ли кто-то пострадал от того, что вы пришли, быстро и незаметно схватили необходимый вам кусочек данных.

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



Потому что информация стоит денег, а вовремя собранная информация стоит еще больших денег. Именно поэтому скрейпинг является серьезной статьей заработка для большого количества людей. Это популярная тема на фрилансе: зайдите и увидите кучу заказов с просьбой собрать те или иные данные или написать скрейпинговый софт. Также есть коммерческие организации, занимающиеся скрейпингом на заказ или предоставляющие платформы для этой активности, так называемый scraping as a service. Такое многообразие и распространение возможно, в том числе и потому, что скрейпинг сам по себе чем-то нелегальным, предосудительным, не является. С правовой точки зрения к нему очень трудно придраться особенно на текущий момент, мы скоро узнаем почему.



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



С точки зрения правовых аспектов, ситуация, которую мы сейчас рассматриваем с дозволенностью скрейпинга, не всегда была такой ранее. Если мы немного посмотрим на хронологию достаточно хорошо известных судебных исков, связанных со скрейпингом, то увидим, что еще на его заре первым иском была претензия компании eBay к скрейперу, который собирал данные с аукционов, и суд запретил ему заниматься этой деятельностью. Дальнейшие 15 лет статус-кво более-менее сохранялся крупные компании выигрывали суды против скрейперов, когда обнаруживали их воздействие. Facebook и Craigslist, а также некоторые другие компании отметились исками, закончившимися в их пользу.

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

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

Посмотрим на несколько знаковых примеров.



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

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



Другой интересный случай скрейпинга это скупка товаров ограниченной доступности. Производители спортивной обуви, такие, как Nike, Puma и Reebok, периодически запускают кроссовки лимитированных и т.н. сигнатурных серий за ними охотятся коллекционеры, они находятся в продаже ограниченное время. Впереди покупателей на сайты обувных магазинов прибегают боты и сгребают весь тираж, после чего эти кроссовки всплывают на сером рынке с совершенно другим ценником. В свое время это взбесило вендоров и ритейл, который их распространяет. Уже 7 лет они борются со скрейперами и т.н. сникер-ботами с переменным успехом, как техническими, так и административными методами.



Вы наверняка слышали истории, когда при онлайн покупке требовалось лично прийти в магазин кроссовок, или про honeypot с кроссовками за $100k, которые бот скупал не глядя, после чего его владелец хватался за голову все эти истории находятся в этом тренде.



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

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



Один из примеров из нашей практики у одного из клиентов. Скрейпер пришел на локацию с параметризованным поиском, который является одной из самых тяжелых операций в бэкенде рассматриваемой структуры. Скрейперу понадобилось перебрать достаточно много поисковых запросов, и он из 200 RPS к этой локации сделал почти 700. Это серьезно нагрузило часть инфраструктуры, из-за чего пошла деградация качества сервиса для остальных легитимных пользователей, взлетело время ответа, посыпались 502-е и 503-и ошибки. В общем, скрейпера это ничуть не волновало и он сидел и делал свое дело, пока все остальные судорожно обновляли страничку браузера.

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



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



Для того чтобы понять как разные варианты скрейпинга могут с технической точки зрения повлиять на ресурс попробуем посчитать вклад отдельных факторов в эту задачу. Займемся некоторой арифметикой.



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

Понятно, что в простом кейсе одна хост-машина, студент с ноутбуком, перебирающий Washington Post, будет сделано большое количество запросов с одними и теми же признаками и параметрами. Это будет очень хорошо заметно в логах, если таких запросов будет достаточно много а значит найти и забанить, в данном случае по айпи адресу, легко.

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

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

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

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



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



И данная категория является, пожалуй, самой популярной и подробно задокументированной. Даже сложно порекомендовать, что конкретно читать, потому что, реально, материала море. Куча книжек написана по этому методу, есть масса статей и публикаций в принципе достаточно потратить 5 / 4 / 3 / 2 минуты (в зависимости от нахальства автора материала), чтобы спарсить свой первый сайт. Это логичный первый шаг для многих, кто начинает в веб-скрейпинге. Starter pack такой деятельности это чаще всего Python, плюс библиотека, которая умеет делать запросы гибко и менять их параметры, типа requests или urllib2. И какой-нибудь HTML-парсер, чаще всего это Beautiful Soup. Также есть вариант использовать либы, которые созданы специально для скрейпинга, такие, как scrapy, которая включает в себя все эти функциональности с удобным интерфейсом.

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



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

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

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

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

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



Сравнение параметров запроса, заголовков, айпи адреса друг с другом и с публично известными позволяет отлавливать самых наглых скрейперов. Простой пример к нам пришел поисковой бот, но только IP у него почему-то не из сети поисковика, а из какого-нибудь облачного провайдера. Даже сам Гугл на странице, описывающей Googlebot, рекомендует делать reverse lookup DNS-записи для того, чтобы убедиться, что данный бот реально пришел с google.com или других валидных ресурсов Гугла.

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

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



Я думаю, что некоторые слушатели узнают этот кусочек javascript'a это проверка, которая раньше была у одного из самых крупных облачных провайдеров в мире перед доступом к запрашиваемой странице, компактная и очень простая, и в то же время без ее изучения так просто на сайт не пробиться. При этом, применив чуть-чуть усилий, мы можем попросить страницу в поисках интересующих нас JS-методов, которые будут вызываться, от них, отсчитав, найти интересующие нас значения, которые должны быть вычислены, и всунуть себе в код вычисления. После не забыть несколько секунд поспать из-за задержки, и вуаля.



Мы попали на страницу и дальше можем парсить то, что нам нужно, потратив не больше ресурсов, чем на создание самого нашего скрейпера. То есть с точки зрения использования ресурсов нам ничего дополнительного для решения таких задач не нужно. Понятно, что гонка вооружений в этом ключе написание JS-челленджей и их парсинг и обход сторонними средствами ограничивается только временем, желанием и навыками автора ботов и автора проверок. Эта гонка может длиться довольно долго, но в какой-то момент большинству скрейперов это становится неинтересно, ведь есть более интересные варианты с этим справиться. Зачем сидеть и парсить JS-код у себя в Python, если можно просто взять и запустить браузер?



Да, я говорю в первую очередь о headless-браузерах, потому что этот инструмент, изначально создававшийся для тестирования и Q&A, оказался идеально подходящим для задач веб-скрейпинга на текущий момент.



Не будем вдаваться в подробности по headless-браузерам, я думаю, что большинство слушателей о них и так знает. Оркестраторы, которые автоматизируют работу headless-браузеров, претерпели довольно бодрую эволюцию за последние 10 лет. Сначала, в момент возникновения PhantomJS и первых версий Selenium 2.0 и Selenium WebDriver, работающий под автоматом headless-браузер было совсем не трудно отличить от живого пользователя. Но, с течением времени и появлением таких инструментов, как Puppeteer для headless Chrome и, сейчас, творение господ из Microsoft Playwright, которое делает то же, что и Puppeteer но не только для Хрома, а для всех версий популярных браузеров, они все больше и больше приближают безголовые браузеры к настоящим с точки зрения того, насколько их можно сделать с помощью оркестрации похожими по поведению и по разным признакам и свойствам на браузер здорового человека.



Для того чтобы заниматься распознаванием headlessов на фоне обычных браузеров, за которыми сидят люди, как правило, используются те же самые javascriptовые проверки, но более глубокие, подробные, собирающие тучу параметров. Результат этого сбора отправляют обратно либо в средство защиты, либо на сайт, с которого скрейпер хотел забрать данные. Эту технологию называют fingerprinting, потому что собирается настоящий цифровой отпечаток браузера и девайса, на котором он запущен.

Вещей, на которые смотрят JS-проверки при фингерпринтинге, довольно много их можно разделить на некоторые условные блоки, в каждом из которых копание может продолжаться до плюс бесконечности. Свойств действительно очень много, какие-то из них легко спрятать, какие-то менее легко. И здесь, как и в предыдущем примере, очень многое зависит от того, насколько дотошно скрейпер подошел к задаче сокрытия торчащих хвостов безголовости. Есть свойства объектов в браузере, которые подменяет по умолчанию оркестратор, есть та самая property (navigator.webdriver), которая выставляется в headlessах, но при этом ее нет в обычных браузерах. Ее можно спрятать, попытку спрятать можно задетектировать, проверив определенные методы то что проверяет эти проверки, тоже можно спрятать и подсовывать фальшивый output функциям, которые распечатывают методы, например, и до бесконечности это может длиться.

Другой блок проверок, как правило, отвечает за изучение параметров окна и экрана, которых у headless-браузеров по определению нет: проверка координат, проверка размеров, какой размер у битой картинки, которая не отрисовалась. Есть масса нюансов, которые человек, хорошо знающий устройство браузеров, может предусмотреть и на каждый из них подсунуть правдоподобный (но ненастоящий) вывод, который улетит в проверки fingerprintа на сервер, который будет его анализировать. Например, в случае отрисовки средствами WebGL и Canvas каких-то картинок, 2D и 3D, можно полностью весь вывод взять готовый, подделать, выдать в методе и заставить кого-то поверить в то, что что-то действительно нарисовалось.

Есть более хитрые проверки, которые происходят не одномоментно, а допустим, JS-код покрутится какое-то количество секунд на странице, или будет вообще постоянно висеть и передавать какую-то информацию на сервер с браузера. К примеру, отслеживание положения и скорости движения курсора если бот кликает только в нужные ему места и переходит по ссылкам со скоростью света, то это можно отследить по движению курсора, если автор бота не додумается в оркестраторе прописать какое-то человекоподобное, плавное, смещение.

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

Это кропотливая, достаточно сложная работа такими вещами обычно занимаются компании, которые предоставляют bot detection как услугу, и заниматься таким самостоятельно на своем ресурсе это не очень выгодное вложение времени и средств.

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

Маленькое лирическое отступление кому интересно поподробнее почитать про историю и эволюцию проверок, например на безголовость Chrome, есть забавная эпистолярная дуэль двух авторов. Про одного автора я знаю не очень много, а второго зовут Antoine Vastel это молодой человек из Франции, который ведет свой блог о ботах и об их обнаружении, об обфускации проверок и многих других занятных вещах. И вот они со своим визави на протяжении двух лет спорили о том, можно ли задетектить headless Chrome.

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



Значит, мы не будем использовать headless, а будем использовать большие настоящие браузеры, которые рисуют нам окошки и всякие визуальные элементы. Инструменты, такие как Puppeteer и Playwright позволяют вместо headlessа запускать браузеры с отрисованным экраном, считывать user input оттуда, снимать скриншоты и делать многое другое, что недоступно браузерам без визуальной составляющей.



Помимо обхода проверок на безголовость в этом случае также можно справится со следующей проблемой когда у нас какие-то элементы хитрые сайтоделы, прячут из текста в картинки, делают невидимыми без совершения дополнительных кликов или каких-то других действий и движений. Прячут какие-то элементы, которые должны быть hidden, и на которые попадаются headlessы: они-то не знают, что этот элемент сейчас не должен отображаться на экране, и попадаются на этом. Мы можем просто отрисовать в браузере эту картинку, скормить скриншот OCRу, получить на выходе текст и использовать его. Да, это сложнее, дороже с точки зрения разработки дольше и ест больше ресурсов. Но есть скрейперы, которые работают именно так, и в ущерб скорости и производительности собирают данные таким образом.



А как же CAPTCHA? спросите вы. Ведь OCRом (продвинутую) капчу не решишь без каких-то более сложных вещей. На это есть простой ответ если у нас не получается решать капчу автоматом, почему бы не задействовать человеческий труд? Зачем разделять бота и человека, если можно комбинировать их труд для достижения цели?

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

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

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



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



Поэтому сначала нужно понять, что нас скрейпят посмотреть на те значения, которые обычно аффектятся при этой деятельности. Мы говорим сейчас про технические параметры и про бизнес-метрики. Те вещи, которые можно увидеть у себя в Grafana, на протяжении времени отсматривая нагрузку и трафик, всякого рода всплески и аномалии. Это можно делать и вручную, если вы не используете средство защиты, но это более надежно делают те, кто умеет фильтровать трафик, обнаруживать разного рода инциденты и матчить их с какими-то событиями. Потому что помимо анализа логов постфактум и помимо анализа каждого отдельного запроса здесь может работать и использование какой-то накопленной средством защиты базы знаний, которая уже видела действия скрейперов на этом ресурсе или на похожих ресурсах, и можно как-то сравнить одно с другим речь о корреляционном анализе.

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



Что касается средств защиты, которые применяются против агрессивного скрейпинга, то большинство методов мы уже рассмотрели, говоря про разные категории ботов. Анализ трафика нам поможет от самых простых кейсов, поведенческий анализ поможет отследить такие вещи, как фаззинг (подмена identity) и мультиинстансинг на скриптах. Против более сложных вещей мы будем собирать цифровые отпечатки. И, конечно же, у нас есть CAPTCHA как последний довод королей если мы не смогли хитрого бота как-то поймать на предыдущих вопросах, то, наверное, он споткнется на капче, не правда ли?



Ну, здесь все немножко сложнее. Дело в том, что по мере увеличения сложности и хитрости проверок они становятся все дороже в основном для клиентской стороны. Если анализ трафика и последующее сравнение параметров с какими-то историческими значениями можно делать абсолютно неинвазивно, без влияния на время загрузки страницы и на скорость работы онлайн ресурса в принципе, то fingerprinting, если он достаточно массивный и делает сотни разных проверок на стороне браузера, может серьезно повлиять на скорость загрузки. А странички с проверками тоже мало кто любит наблюдать в процессе перехода по ссылкам.

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



Учитывая все эти факторы что же нам в итоге делать, если скрейпинг пришел к нам, мы на него посмотрели и смогли как-то оценить его влияние на наши бизнес- и технические показатели? С одной стороны, бороться со скрейпингом по определению как со сбором публичных данных, машинами или людьми смысла не имеет вы сами согласились с тем, что эти данные доступны любому пользователю пришедшему из интернета. И решать задачу по ограничению скрейпинга из принципа то есть из-за того что к вам приходят продвинутые и талантливые ботоводы, вы стараетесь их всех забанить значит потратить очень много ресурсов на защиту, либо собственных, либо использовать дорогостоящее и очень сложное решение, self-hosted или облачное в режиме максимальной защищенности и в погоне за каждым отдельным ботом рисковать отпугнуть долю валидных пользователей такими вещами, как тяжелые javascript-проверки, как капча, которая выскакивает на каждом третьем переходе. Все это может ваш сайт до неузнаваемости изменить не в пользу ваших посетителей.

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

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

Большое спасибо за внимание!

Киберпреступники захватывают маршрутизаторы, а затем используют их для продажи сервисов анонимизации, проксирования, организации DDoS-атак. Причём за владение зомби-устройствами сражаются сразу несколько ботнетов. О том, как проходит эта война, рассказывает новое исследование Trend Micro, и в этом посте мы поделимся наиболее важными деталями.



По оценкам экспертов в 2020 году количество подключенных к интернету IoT-устройств превысит 31 млрд штук. Каждое такое устройство содержит операционную систему с сетевым стеком и набор программ для выполнения основных задач. Наиболее функциональные IoT-устройства это роутеры. Обычно их прошивка представляет собой облегчённую и довольно редко обновляемую владельцами устройств версию Linux. На многих устройствах остаётся заданный производителем пароль, что в сочетании с неисправленными уязвимостями старого Linux превращает роутеры в идеальную цель для захвата и подключения к ботнету.

Зачем нужны ботнеты
Армию из десятков тысяч устройств можно использовать с разными целями. Самые распространённые это анонимные прокси и организация DDoS-атак. Эти два направления позволяют получить серьёзный доход при грамотной монетизации. Чем больше устройств в сети, тем больше в ней потенциальной мощности и тем больше денег она приносит своим владельцам. Поэтому киберпреступники соревнуются за то, чтобы захватить как можно больше маршрутизаторов.

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


Количество брутфорс-атак на маршрутизаторы в 2019-2020 году. Источник (здесь и далее, если не указано иное): Trend Micro

По данным телеметрии Trend Micro, в 2019 г. количество попыток входа на маршрутизаторы с применением брутфорса постоянно увеличивалось. Сначала рост был постепенным, а начиная с октября цифры резко выросли.
Второе по популярности средство расширения сферы действия IoT-ботнетов это взлом протокола telnet. Хотя сегодня telnet используется не так широко, как в прошлом и даже не рекомендуется к применению, многие устройства IoT всё ещё используют его для обеспечения удалённого доступа. Telnet-сеансы не шифруются, что позволяет злоумышленнику или бот-сети легко перехватывать учётные данные пользователя и другую информацию. В результате бот-сети могут использовать полученные из протокола telnet данных для дальнейшего расширения.
Попытка открыть telnet-сессию с другими устройствами не является нормальным поведением маршрутизатора и может служить признаком попытки заражения. В нашем исследовании мы использовали эту метрику как индикатор количества заражённых маршрутизаторов.


Данные телеметрии Trend Micro с июля 2019 по апрель 2020 года. Чёрные столбцы количество попыток telnet-подключений, синий график источники этих попыток

На пике источниками вредоносного трафика были до 16 тыс. устройств в неделю, после чего это количество снизилось, что совпало с частичным отключением одного из наиболее мощных ботнетов DoubleGuns.
Мы обнаружили, что существует три основные кодовые базы бот-сетей, которые чаще всего используются кибергруппировками и скрипт-киддис: Mirai, Kaiten и QBot. Их коды общедоступны, поэтому любой технически подкованный мошенник может легко загрузить код, скорректировать и перекомпилировать его под себя, чтобы захватывать маршрутизаторы для создания бот-сети. Таким образом, коды этих трёх ботнетов основное кибероружие в продолжающейся войне за маршрутизаторы.

Mirai
Это самый распространённый код, на базе которого создаются ботнеты. Mirai появился в конце 2016 года, и это сразу изменило ландшафт IoT-угроз. Mirai создавался как инструмент для DDoS-атак.
Первой атакой Mirai стало нападение на игровые серверы Minecraft, размещённые у интернет-провайдера OVH. Мощность атаки, которая началась 19 сентября 2016 года, составила 799 Гбит/с. Ботнет состоял из 145 тыс. устройств.
Ещё одной демонстрацией возможностей ботнета стала DDoS-атака на сайт Krebs on Security 20 сентября 2016 года мощностью 665 Гбит/с. CDN-провайдер Akamai, не справившись с атакой, просто отключил сайт, который в итоге лежал четыре дня. Сама атака продолжалась 77 часов, в ней участвовали 24 тыс. захваченных роутеров.
Самой крупной кампанией Mirai стала атака 12 октября 2016 года на DNS-провайдера Dyn, который предоставлял услуги Netflix, Reddit, Twitter и другим компаниям. По заявлению специалистов, мощность атаки превосходила возможности всех имеющихся защитных решений. В составе Mirai на тот момент насчитывалось более 11 млн устройств.
Публикация исходных кодов Mirai навсегда изменила мир. Возможность создать себе DDoS-дубину для расправы с конкурентами и сдачи в аренду оказалась настолько привлекательной, что сразу появилось множество форков Mirai с дополнительными возможностями в виде использования дополнительных эксплойтов для взлома маршрутизаторов, а также кода для очистки взломанных устройств от конкурентов.



Фрагменты кода Mirai для уничтожения малвари-конкурента Anime. Здесь Mirai использует системную функцию Linux kill() для передачи сигнала SIG_KILL (9) процессам-конкурентам

Kaiten / Tsunami
Этот ботнет не так известен, как Mirai, хотя его можно считать одним из самых старых. Его исходники находятся в общем доступе с 2001 года. Взаимодействие с управляющими серверами происходит по протоколу IRC (Internet Relay Chat). Адреса серверов прописаны в исходном коде Kaiten, который можно собрать под архитектуры SH4, PowerPC, MIPSel, MIPS и ARM.
Поиск и заражение устройств происходит с помощью Python-скрипта, который ищет открытые telnet-порты и затем пытается подключиться с ним, брутфорся пароли. Перебор начинается с самых распространённых паролей, которые содержатся в теле скрипта:


Список самых небезопасных и распространённых паролей в теле скрипта Kaiten

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


Авторы форков Kaiten хвастаются функцией ботоубийства на форумах

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


Фрагмент кода QBot, содержащий строки-идентификаторы конкурирующих вредоносов

Qbot также нетерпимо относится к конкурентам. Один из его форков содержит 438 названий процессов-конкурентов, включая Mirai и Kaiten.

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

Рекомендации по защите
Мы рекомендуем IT-специалистам проверять состояние подведомственных маршрутизаторов не реже одного раза в квартал по этому чек-листу:
проверьте журналы роутера на предмет необычного поведения, странных учётных записей и других аномалий;
убедитесь, что на маршрутизаторе установлена последняя прошивка;
используйте надёжный пароль и время от времени меняйте его;
ограничьте число попыток неправильного ввода пароля, если прошивка позволяет сделать это;
отключите возможность telnet-подключения к маршрутизатору, и разрешите входы только из локальной сети.
Мы также призываем ИТ-персонал помогать работающим дистанционно сотрудникам в обеспечении безопасности их домашних маршрутизаторов.
Среди решений Trend Micro есть устройство, ориентированное на защиту домашних сетей Trend Micro Home Network Security. Оно проверяет интернет-трафик между маршрутизатором и домашней сетью, а также помогает пользователям оценить уязвимости в подключённых к сети устройствах. Использование этого решения позволяет предотвратить захват устройств ботнетами в ходе войны, где маршрутизаторы являются полем боя и призовым фондом для выигрыша.

CrowdSec

Инструмент Fail2Ban хорошо известен админам. Программа анализирует логи на сервере и подсчитывает количество попыток доступа с конкретных IP-адресов по указанным протоколам. В случае нарушения правила данный IP-адрес блокируется на заданный отрезок времени. Например, джейл для авторизации по SSH включён с дефолтными настройками 5 попыток авторизации за 10 минут, после чего происходит бан IP-адреса на 10 минут. Отличный способ отфильтровать мусорный трафик от разных сканеров и защита от DDoS.

Fail2Ban и SSHGuard лучшие инструменты в своей области. Однако новый опенсорсный проект CrowdSec представляется интересной альтернативой. Это локальная замена Fail2Ban, а потенциально нечто большее глобальная база репутации IP-адресов типа иммунной системы интернета.

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



Разработчики CrowdSec называют следующие ключевые особенности:

• обнаружение атак и реагирование на всех уровнях (логи могут лежать в любом месте);
  
• простота в установке и обслуживании (установка с визардом в консоли);
  
  

  git clone https://github.com/crowdsecurity/crowdsec/releases/latest
  

  
  

  sudo ./wizard.sh -i
  

  
  
  Установка CrowdSec. Визард в консоли помогает выбрать и предлагает, какие демоны/логи нужно мониторить, хотя возможна и последующая настройка через обычные конфиги
  
• интеграция с другими компонентами (чтение логов и автоматическая блокировка нарушителей на уровне CDN);
  
• общий доступ (опционально): метаданные можно отправлять в центральный API, так что данные о вредоносных IP-адресах получат все пользователи. Нужно подчеркнуть, что это опциональная фича, и никто не заставляет передавать метаданные в общий доступ;
  
• лёгкий вес: автономная работа, минимум оперативной памяти и CPU;
  
• возможность обработки холодных логов (из архива) для своеобразной симуляции;
  
• предустановленные панели мониторинга.

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

Ещё один интересный момент инструмент написан на языке программирования Go.

С архитектурной точки зрения система состоит из трёх основных компонентов:

• постоянно работающая служба CrowdSec, которая отслеживает логи, атаки и т. д.;
  
• инструмент командной строки, интерфейс для взаимодействия со службой;
  
• модули интеграции (bouncers) с другими инструментами типа Cloudflare для реального обеспечения блокировки.

Вот как выглядит архитектура программы из документации:



На данный момент разработано пять модулей интеграции (bouncers):
cs-cloudflare-blocker, cs-custom-blocker (пользовательские сценарии), cs-netfilter-blocker, cs-nginx-blocker и cs-wordpress-blocker. Например, модуль для Nginx сверяет каждый неизвестный IP-адрес с базой данных, прежде чем веб-сервер ответит на запрос или выдаст ошибку 403. Модуль Netfilter просто добавляет вредоносные IP-адреса в чёрный список nftables/ipset.

Для простоты настройки на сайте собраны коллекции и конфигурации.

Коллекции это, по сути, просто наборы парсеров и сценариев для разных ситуаций. Например, в коллекцию Nginx входит парсер логов nginx-logs и базовые http-сценарии для определения типичных вредоносных ботов (агрессивный краулинг, сканирование/пробирование портов, чёрный список user-agent'ов, а также определение попыток проведения атаки path traversal).

Полный список коллекций:

• apache2
  
• base-http-scenarios
  
• iptables
  
• linux
  
• modsecurity
  
• mysql
  
• naxsi
  
• nginx
  
• postfix
  
• sshd

Один из вариантов работы с CrowdSec через консольную программу cscli:

cscli metrics

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

Следующая команда выводит список хостов с указанием причин, почему их забанили, кодом страны, идентификатором автономной сети (AS), количеством нарушений и другой информацией.

cscli ban list

Консольная утилита cscli поддерживает большой список команд и параметров для подключения/удаления конфигураций, добавления новых правил блокировки и др.

Но кроме cscli, конфигурацию можно изменить и традиционным способом, путём редактирования текстового файла в формате YAML:

vi /etc/crowdsec/config/profiles.yaml

Естественно, кастомные сценарии тоже поддерживаются.

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

Сейчас компания пытается предложить пользователям платный доступ к облачному API и базе данных с репутацией IP-адресов, которая составляется совместными усилиями. При этом поставщики информации в эту базу освобождаются от оплаты, а платят только чистые потребители, которые не хотят делиться информацией из своих логов. Планируется два тарифных плана: premium и enterprise с услугами по поддержке, специальными служебными инструментами (типа развёртывания системы на несколько локаций из одного центрального места), применением дата-майнинга и машинного обучения (обнаружение тенденций в глобальных данных), более продвинутом анализе холодных логов (форензика, криминалистика, расследования хотя данное направление бизнеса в Европе затруднено из-за закона GDPR).

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



Разработчики обращают внимание, что программа пока в бета-версии, но никаких проблем на продакшне ни у кого не возникало. Они также говорят, что программа на Go элементарно портируется на другие платформы вроде Windows и Mac.

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

---

На правах рекламы

Виртуальные серверы с защитой от DDoS-атак и новейшим железом, серверы размещены в одном из лучших российских дата-центров DataPro. Всё это про наши эпичные серверы. Максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe! Поспешите заказать.

Четыре года назад Twitter, Slack, Pinterest и другие популярные интернет-сервисы вышли из строя на один день из-за масштабной DDoS-атаки на DNS-серверы провайдера Dyn. Недавно группа исследователей решила проверить, какие уроки были вынесены жертвами. Спойлер: никакие.

DDoS от электрочайника

Четыре года назад, 21 октября 2016-го, провайдер Dyn стал жертвой массированной DDos-атаки. Она продолжалась в течение почти всего дня и в результате значительная часть популярных мировых интернет-сервисов была недоступна. Среди них Amazon, Airbnb, CNN, Netflix, PayPal, Spotify, Visa и многие другие. Все они использовали в качестве провайдера DNS только решение от Dyn и не имели никакого резервного варианта на случай неполадок.

Считается, что атака была организована достаточно хитроумно, через ботнет MIrai, который включал в себя множество устройств интернета вещей чайников, кофеварок, телевизоров и так далее. Доступ к ним удалось получить по причине того, что большинство пользователей не изменили стандартные пароли к ним. Нагрузка в 1,2 терабита в секунду позволяет оценивать атаку, как одну из самых масштабных в истории. Эта атака фактически уничтожила Dyn и буквально через месяц, в ноябре, она была куплена компанией Oracle.

Вынесены ли уроки

Чтобы выяснить это, группа ученых из университета КарнегиМеллона исследовала 100 000 самых популярных мировых веб-сайтов из рейтинга Alexa. Их интересовало, какой процент сайтов до сих пор зависит от одного поставщика DNS.

Итоги они озвучили на недавней конференции Internet Measurement Conference. По их данным, в 2020-м, 89,2 % всех проанализированных ими веб-ресурсов пользуются услугами DNS-провайдера, а не разворачивают собственный сервер. А 84,8 % сайтов работают с одним DNS-провайдером, у них нет никакого запасного варианта на случай сбоя или атаки.

Число зависимых от одного DNS-поставщика ресурсов за четыре года выросло на 4,7%. Похоже, что никаких выводов после атаки сделано не было. Одна из самых характерных цифр с 2006 года только два сайта из Топ-100 Alexa добавили резервные DNS-серверы. Что касается небольших сайтов, они продолжают использовать одного провайдера, и в целом, большинство ресурсов пользуется услугами известного вендора. То есть, ситуация сегодня очень похожа на ту, которая была перед атакой в октябре 2016 года.

Зависимость от трех сервисов

По результатам исследования выяснилось три самых популярных провайдера среди Топ-100 000 сайтов из рейтинга Alexa. Это Cloudflare (24%), Amazon Web Services (12%) и GoDaddy (4%). Причем 38% этих сайтов используют только один из них, без какой-либо подстраховки.

Любые неполадки, как злонамеренные, так и случайные, могут положить значительную часть глобальной сети. И похоже, что именно это регулярно происходит. Например, атаки время от времени выводят из строя сервисы AWS.

Также исследователи проанализировали сайты, использующие CDN (сети доставки контента) и CA (центры сертификации). Результаты получились похожими многие ресурсы пользуются единственным сервисом, без какого-либо резервирования.

Что делать

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

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

---

Блог ITGLOBAL.COM Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:

• Почему этичным хакерам следует взламывать корпорации сообща. Интервью с баг-хантером Алексом Чапманом
• Страх перед автоматизацией работы и другие тренды в мировой и российской кибербезопасности
• Как мы нашли уязвимость в почтовом сервере банка и чем она грозила
• Главные тенденции ИТ-индустрии в 2021 году по версии Gartner

---

Глобальный сбой работоспособности интернета произошел по вине американского провайдера CenturyLink. Из-за некорректной настройки межсетевого экрана, у пользователей по всему миру наблюдались проблемы с доступом к Google, службам Microsoft, облачным сервисам Amazon, сервису микроблогов Twitter, Discord, сервисам Electronic Arts, Blizzard, Steam, веб-сайту Reddit и многим другим.



Причиной сбоя стало то, что CenturyLink, являясь Level3-провайдером, некорректно сформулировал правило BGP Flowspec в протоколе безопасности. BGP Flowspec используется для перенаправления трафика, так что эта ошибка привела к серьезным проблемам с маршрутизацией внутри сети провайдера, что сказалось и на стабильности глобального интернета. Конечно, сильнее всего пострадали пользователи в США, но отголоски проблем ощущались по всему миру.

Важно отметить, что CenturyLink является третьей про размерам телекоммуникационной компанией Америки, сразу после AT&T и Verizon.

BGP Flowspec по IETF имеет код спецификации RFC 5575 и описан как многопротокольное расширение BGP MP-BGP, которое содержит информацию о доступности сетевого уровня Network Layer Reachability Information (NLRI). BGP FlowSpec это альтернативный метод сброса атакующего DDoS-трафика с маршрута, который считается более тонким способом уклониться от атаки, нежели RTBH (Remote Triggered Black Hole Filtering), когда блокируется весь трафик с адреса атаки, либо трафик до адреса назначения. Вообще, RTBH, по сути оружие судного дня и является крайним средством для прекращения атаки, так как его применение зачастую позволяет атакующему добиться желаемого, то есть изоляции одного из адресов.

BGP FlowSpec действует более тонко и по сути, является фильтром межсетевого экрана, который который вводится в BGP для фильтрации определенных портов и протоколов и определяет, какой трафик по какому маршруту пропускать. Таким образом, белый трафик проходит до адреса назначения, а определенный, как DDoS сбрасывается с маршрута. Трафик анализируется минимум по 12 параметрам NLRI:

1. Destination Prefix. Определяет префикс назначения для соответствия.
2. Source Prefix. Определяет исходный префикс.
3. Протокол IP. Содержит набор пар {оператор, значение}, которые используются для сопоставления байта значения протокола IP в IP-пакетах.
4. Порт. Определяет, будут ли пакеты обрабатываться TCP, UDP или оба.
5. Порт назначения. Определяет порт назначения, на который будет влиять FlowSpec.
6. Исходный порт. Определяет исходный порт, на который будет влиять FlowSpec.
7. Тип ICMP.
8. Код ICMP.
9. Флаги TCP.
10. Длина пакета. Соответствие общей длине IP-пакета (исключая уровень 2, но включая IP-заголовок).
11. DSCP. Соответствие по параметру Class Of Service flag.
12. Fragment Encoding

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

Согласно отчету CloudFlare о произошедшем сбое, все началось с резкого роста 522 ошибки в 10:03 по Гринвичу, 30 августа.



Так, автоматической системе ре-машрутизации на случай сбоев удалось сократить количество ошибок и снизить их до 25% от пикового значения, но проблемы со связностью сети и доступностью ресурсов все еще сохранялись и имели глобальный характер. Все это было сделано в окне между 10:03 на начало сбоя и до 10:11 по UTC. За эти восемь минут автоматика и инженеры отключили свою инфраструктуру в 48 (!) городах Северной Америки от CenturyLink и перебросили трафик на резервные каналы других провайдеров.

Очевидно, что так поступали не только в CloudFlare. Однако это не позволило полностью решить проблему. Для наглядности, какое влияние проблемный провайдер имеет на телеком-рынок США и Канады, инженеры компании привели официальную карту доступности услуг CenturyLink:



В США провайдером пользуется 49 миллионов человек, а это означает, что для некоторых клиентов, если говорить об отчете CloudFlare, и даже целых дата-центров, CenturyLink является единственным доступным провайдером.

В итоге, из-за почти полного падения CenturyLink, специалисты CloudFlare зафиксировали сокращение мирового интернет-трафика на 3,5%. Вот как это выглядело на графике по шести основным провайдерам, с которыми работает компания. CenturyLink на нем красный.



О том, что сбой был глобальный, а не просто проблемы в дата-центре под Онтарио, как заявил сам провайдер, свидетельствует и размер обновлений правил Flowspec. Обычно размер обновления конфигураций BGP Flowspec составляет около 2 мегабайт, но специалисты CloudFlare зафиксировали обновления конфигураций BGP размером до 26 Мб (!).



Эти обновления, которые распространяются раз в 15 минут, делятся с узлами сети информацией об изменениях в работоспособности маршрутов. Это позволяет гибко реагировать на какие-то локальные проблемы. Обновления размером в 10-15 раз выше обычных говорят о том, что практически вся сеть провайдера легла или наблюдались крайне серьезные проблемы со связностью.

В CloudFlare считают, что причиной сбоя стало некорректное глобальное правило BGP Flowspec, которое получило подавляющее большинство маршрутизаторов, которые потом ушли в реверсивную перезагрузку в попытках восстановить соединение. Это укладывается в картину сбоя, который продолжался более 4 часов. Именно при перегрузке памяти и ЦП маршрутизаторов инженеры могли потерять удаленный доступ к ряду узлов и управляющих интерфейсов.

К слову, подобная история далеко не уникальна. Чуть более года назад интернет по всему миру прилег по вине самих CloudFlare и сбоя в работе их DNS, плюс эта же компания честно упоминает о похожих проблемах с Flowspec еще семь лет назад, после которых они отказались от его использования.

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

Атаки 7 уровня на сайты включают атаки на уровень веб-сервера (nginx, apache и т.д.) и атаки на уровень сервера приложений (php-fpm, nodejs и т.д.), который, как правило, расположен за проксирующим сервером (nginx, apache и т.д.). С точки зрения сетевых протоколов, оба варианта являются атакой на уровень приложения. Но нам, с практической точки зрения, нужно разделить эти два случая. Веб-сервер (nginx, apache и т.д.), как правило, самостоятельно отдает статические файлы (картинки, стили, скрипты), а запросы на получение динамического контента проксирует на сервер приложений (php-fpm, nodejs и т.д.). Именно эти запросы становятся мишенью для атак, так как в отличие от запросов статики, серверы приложений при генерировании динамического контента требуют на несколько порядков больше ограниченных системных ресурсов, чем и пользуются атакующие.

Как ни банально звучит, чтобы защититься от атаки, ее нужно сначала выявить. На самом деле, к отказу сайта могут привести не только DDoS атаки, но и другие причины, связанные с ошибками разработчиков и системных администраторов. Для удобства анализа, необходимо добавить в формат логов nginx (сорри, варианта с apache у меня нет) параметр $request_time, и логировать запросы к серверу приложений отдельный файл:

      log_format timed '$remote_addr - $remote_user [$time_local] '            '$host:$server_port "$request" $status $body_bytes_sent '            '"$http_referer" "$http_user_agent" ($request_time s.)';      location /api/ {           proxy_pass http://127.0.0.1:3000;           proxy_http_version 1.1;           proxy_set_header Upgrade $http_upgrade;           proxy_set_header Connection 'upgrade';           proxy_set_header Host $host;           proxy_cache_bypass $http_upgrade;           proxy_set_header X-Real-IP $remote_addr;           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;           proxy_set_header X-NginX-Proxy true;           access_log /var/log/ngunx/application_access.log timed;       }

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

Выявив атаку можно, приступать к защите.

Очень часто, системные администраторы пытаются защитить сайт, ограничив количество запросов с одного IP-адреса. Для этого используют 1) Директиву limit_req_zone nginx (см. документацию), 2) fail2ban и 3) iptables. Безусловно, эти способы нужно использовать. Однако, такой способ защиты уже как 10-15 лет является малоэффективным. На это есть две причины:

1) Трафик, который генерирует сеть ботов при атаке на 7 уровень, по своему объему может быть меньше чем трафик обычного посетителя сайта, так как у обычного посетителя сайта на один тяжелый запрос к серверу приложений (php-fpm, nodejs и т.д.) приходится примерно 100 легких запросов на загрузку статических файлов, которые отдаются веб-сервером (nginx, apache и т.д.). От таких запросов iptables не защищает, так как может ограничивать трафик только по количественным показателям, и не учитывает разделение запросов на статику и динамику.

2) Вторая причина распределённость сети ботов (первая буква D в аббревиатуре DDoS). В атаке обычно принимает участие сеть из нескольких тысяч ботов. Они в состоянии делать запросы реже, чем обычный пользователь. Как правило, атакуя сайт, злоумышленник опытным путем вычисляет параметры limit_req_zone и fail2ban. И настраивает сеть ботов так, чтобы эта защита не срабатывала. Часто, системные администраторы начинают занижать эти параметры, отключая таким образом реальных клиентов, при этом без особого результата с точки зрения защиты от ботов.

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

Кроме этого необходимо построить защиту, основанную на выявлении ботов. Все, что нужно для понимания механики выявления ботов, было подробно описано в исторической статье на Хабре Модуль nginx для борьбы с DDoS автора kyprizel, и реализована в библиотеке этого же автора testcookie-nginx-module

Это библиотека на С, и она продолжает развиваться небольшим сообществом авторов. Наверное, не все системные администраторы готовы на продакшин сервере прикомпилировать незнакомую библиотеку. Если же потребуется дополнительно внести изменения в работу библиотеки то это и вовсе выходит за рамки рядового системного администратора или разработчика. К счастью, в настоящее время появились новые возможности: скриптовый язык Lua, который может работать на сервере nginx. Есть две популярные сборки nginx со встроенным скриптовым движком Lua: openresty, разработка которого изначально споснировалась Taobao, затем Cloudfare, и nginx-extras, который включен в состав некоторых дистирибутивов Linux, например Ubuntu. Оба варианта используют одни и те же библиотеки, поэтому не имеет большой разницы, который из них использовать.

Защита от ботов может быть основана на определении способности веб-клиента: 1) выполнять код JavaScript, 2) делать редиректы и 3) устанавливать cookie. Из всех этих способов, выполнение кода JavaScript оказалось наименее перспективным, и от него я отказался, так как код JavaScript не выполняется, если контент загружается фоновыми (ajax) запросами, а повторная загрузка страницы средствами JavaScript искажает статистику переходов на сайт (так как теряется загловок Referer). Таким образом, остаются редиректы которые устанавливают cookie, значения котрых подчиняются логике, которая не может быть воспроизведена на клиенте, и не допускают на сайт клиентов без этих cookie.

В своей работе я основывался на библиотеке leeyiw/ngx_lua_anticc, которая в настоящее время не развивается, и я продолжил доработки в своем форке apapacy/ngx_lua_anticc, так как работа оригинальной библиотеки не во всем устраивала.

Для работы счетчиков запросов в библиотеке используются таблицы памяти, которые поддерживают удобные для наращивания значения счетчиков методы incr, и установку значений с TTL. Например, в приведенном ниже фрагменте кода наращивается значение счетчика запросов с одного IP-адреса, если у клиента не установлены cookie с определенным именем. Если счетчик еще не был инициализирован, он инициализируется значением 1 с TTL 60 секунд. После превышения количества запросов 256 (за 60 секунд), клиент на сайт не допускается:

local anticc = ngx.shared.nla_anticclocal remote_id = ngx.var.remote_addrif not cookies[config.cookie_name] then  local count, err = anticc:incr(remote_id, 1)  if not count then    anticc:set(remote_id, 1, 60)    count = 1   end   if count >= 256 then     if count == 256 then       ngx.log(ngx.WARN, "client banned by remote address")     end     ngx.exit(444)     return  endend

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

local whitelist = ngx.shared.nla_whitelistin_whitelist = whitelist:get(ngx.var.remote_addr)if in_whitelist then    returnend

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

local exec = require 'resty.exec'if ngx.re.find(headers["User-Agent"],config.google_bots , "ioj") then    local prog = exec.new('/tmp/exec.sock')    prog.argv = { 'host', ngx.var.remote_addr }    local res, err = prog()    if res and ngx.re.find(res.stdout, "google") thenngx.log(ngx.WARN, "ip " .. ngx.var.remote_addr .. " from " .. res.stdout .. " added to whitelist")whitelist:add(ngx.var.remote_addr, true)        return    end    if res then        ngx.log(ngx.WARN, "ip " .. ngx.var.remote_addr .. " from " .. res.stdout .. "not added to whitelist")    else        ngx.log(ngx.WARN, "lua-resty-exec error: " .. err)    endend

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

apapacy@gmail.com
9 мая 2021 года