Технически, навскидку 4 варианта развития событий (может быть и больше):
Хост-машине, с которой стримится видео+аудиопоток, забивает канал связи. Если стрим идет не через сервис, а зрители коннектятся непосредственно к источнику -- то исчерпать провайдерскую емкость можно легко безо всяких атак.
Стрим может идти через сервис/платформу, но ip+порт источника контента торчат в Сеть без ACL и других ограничений в файрволе. Они обнаруживаются аттакером, после чего туда наливается мусорный трафик, для домашнего или офисного канала много его не потребуется.
DDoS шатает саму платформу для стриминга. Если это Twitch, например, то в случае удачи атака однозначно будет значимой, уровня "заголовки в новостях". При этом outage будет и других стримеров и зрителей.
Эм, там все-таки в пустыне существенная часть происходит. С таким же успехом можно Сахару (все вариации), 1го и 3го Индиану Джонса, 4-е Звездные Войны, Присциллу и ряд других популярных кино прогнать через такой анализ.
Хотя, справедливости ради, пустыня (и, в частности, Сахара) богата красками и многообразием видов, которое мало кому удалось в полной мере передать на киноэкране.
основной бизнес-задачей рассматриваемых в рамках доклада веб-ресурсов является не продажа публичных данных скрейперам, с которыми вы предлагаете «прийти к взаимовыгодному решению»;
оценка действий скрейпера с позиции логики не всегда соотносится с реальностью. Как и договороспособность.
Приведу 2 примера из практики, которые иллюстрируют это:
Скрейпер приходит на страницу сайта с авиабилетами и собирает перелеты, делая несколько млн запросов за час. При этом он собирает столько же уникальных данных, сколько бы он получил, делая порядка 20000 запросов за тот же час: частота обновления на ресурсе заведомо ниже частоты запросов к одной и той же позиции, и большинство ответов ему просто не нужны. Зачем он это делает? «Держать лишние инстансы, деньги на них тратить? Я что, идиот?» Нет, ему просто наплевать, пока не возникло защиты в этом месте, создание такой нагрузки была для него столь же дешевым.
Сайт открыл свой API для поиска и листинга цен, там появился трафик, но нагрузка от скрейперов не снизилась. Причины: 1) скрейперам забыли позвонить и сообщить :) 2) в API пришла часть тех, кто раньше покупал у скрейперов собранные данные, сузив рынок сбыта, но не ликвидировав его 3) снова, скрейпить без защиты просто и дешево, поэтому отказываться от него ради API нелогично, наоборот, можно совместить одно с другим.
Оверхед на скрейпинг с веб-страниц, о котором вы говорите, существует в основном из-за наличия уже внедренных мер защиты. И на него согласны тратиться лишь оттого, что других вариантов собрать данные с такой же скоростью не предоставлено. API скорее помогает не скрейперам, а тем, кто от них больше всего страдает — юзерам, аффилиатам или партнерам, которым нужна интеграция функций одного сервиса в другой.
то-то я этого параграфа не понял — сдаётся мне, Вы слишком витиевато изъяснились.
Постараюсь проще. Расходы на продвинутый скрейпинг могут быть совсем не копеечными, если данные нужно собирать помногу и регулярно, а не один раз из одного места для исследования или развлечения. Внезапно, миллион капч оборачивается порядка $700, аренда residential proxy — от $100/m и выше сообразно качеству. А это те инструменты, на которые скрейпера заставляет тратиться защита. А вы этого не учитываете.
Здесь совершенно тупое взаимодействие двух акторов: владельца данных и скрейпера, далее чистая теория игр
Не могу согласиться насчет «тупое». Есть масса факторов, которые находятся за пределами вашей платежной матрицы и могут заставить (и в реальной жизни заставляют) скрейпера не ходить в API или ходить не только в него:
интерфейсы коммерческих ресурсов, что платные, что бесплатные (как Walmart Open API) имеют либо рейтлимит, либо лимит на общее число запросов с одного токена, и собрать датасет нужного размера не выходит. При этом такого рода ограничения на вебсайте (особенно рейтлимит) вводить опасно, его же еще и люди смотрят.
В API может не оказаться данных нужного типа. Или они преобразовываются как надо на фронте, и под них нужно писать аналогичную трансформацию, что дольше, чем лишний раз бахнуть по сайту.
Открыли API? А я собираю с десятков подобных сайтов, где API нет, у меня уже потрачено на инфраструктуру и техстек, теперь я могу скрейпить ваш сайт из обоих мест параллельно! :).
Банальная лень и нежелание трогать то, что уже работает.
и будет иметь то, что «надо», за копейки так или иначе
Такое обобщение не берет в расчет бизнес-модель коммерческих скрейперов. А она работает, когда в асимптотическом приближении (инструмент уже написан/куплен, стоимость модификации околонулевая, а кол-во заказов большое и растет) стоимость данных с одной обработанной странички в продаваемом датасете выше, чем накладные расходы: виртуалки, трафик, стоимость решения капчи, стоимость ручного труда + еще ряд менее очевидных параметров.
ибо нафига? Обращались бы к API.
Идея public API благородна, я бы хотел жить в мире, где у каждого ресурса с полезными данными было бы оно. К сожалению, что с коммерческим, что с бесплатным роботоориентированным интерфейсом бывает так, что ресурс начинают скрейпить и со страничек, и с API — каких-то данных не хватает, медиа и тд. Из того, что вы уважаете потребности своих юзеров, не следует, что они станут уважать ваши.
А до тех пор — «кто не успел, тот опоздал»
Здесь согласен. Однако пока не у всех ритейлеров работает такая модель, эти сценарии как были, так и продолжатся.
Ещё раз повторю вопрос про специальность вашего гипотетического студента :)
Пусть будет — сугубо гипотетически — 051311, математическое и программное обеспечение вычислительных машин, комплексов, и компьютерных сетей. Но с тем же успехом может быть и 010107, вычислительная математика, и какая-нибудь другая, где студентами ведется научная работа, и решаются задачи с использованием компьютера :)
На курсовых технических специальностей нет слов «prior art/prior works, событий, упоминаний в медиапространстве».
Это очень строгое отрицание, и оно, как мне кажется, неверно. Понятие prior art в контексте алгоритмов и исходного кода общеупотребимо. Поэтому, если вы, например, делаете работу об алгоритме собственной разработки, который решает какую-то задачу, без изучения prior art по своей тематике, упоминания релевантных разработок в обзорной части доклада и анализа их преимуществ/недостатков относительно этой задачи вряд ли ее воспримут всерьез. Я не берусь говорить, что «везде так» или «везде не так», однако вот выписка из одного из вузовских пособий по оформлению учебно-научных текстов: «Назначение этой главы – дать более детальное и систематическое представление о существующих решениях рассматриваемой проблемы, чем это сделано во введении. <...> В идеале в обзорной главе должен быть дан сравнительный анализ известных подходов и вариантов решения проблемы...»
На моем опыте, учитывая, что первая курсовая у студента чаще не несет больших и важных научных инноваций, научное руководство повышенное внимание обращало на то, насколько тщательно студент изучил свою тему и собрал данные для обзорной части, особенно если он планировал в этой теме работать и дальше.
При том, что специальность не программирование?
А почему бы и да? Студенты фундаментальных научных дисциплин тоже изучают по программе ЯП и используют их в качестве инструмента, да и не только они. К тому же, как я говорил в докладе, гайдов и готовых сниппетов вокруг столько, что яблоку упасть негде.
Научный руководитель у простой курсовой? Это где так?
Как минимум, в МГТУ, МФТИ, МГУ это так, наверняка во многих других ВУЗах тоже, но я не берусь безоговорочно судить.
Не очень понимаю, отчего вы решили, что речь идет о «тупой копипасте». Любая исследовательская работа, включая студенческие, требует поиска и изучения prior art/prior works, событий, упоминаний в медиапространстве и их значимости для выбранной сферы.
Так, если человек делает исследование эволюции систем предупреждения столкновений воздушных судов и уже успел изучить их устройство, ключевые параметры и сделать нужные выводы, этого будет недостаточно без информации о самих инцидентах столкновений и их последствий, т.е. контекста, в котором работа по этому направлению ведется последние 50-60 лет. Как минимум, стоило бы раздобыть описание всех инцидентов за этот срок, категоризировать их и показать, какие из них были ключевыми для внедрения изучаемых технологий (как катастрофа в Гранд-Каньоне в 1956). Без такого анализа работа на эту тему будет, вероятно, воспринята в лучшем случае как проведенная небрежно, а в худшем — как откровенная халтура.
Это всего лишь пример, притом скромный по масштабу, т.к. крупных столкновений-катастроф с участием гражданской авиации всего меньше 100, и они уже заботливо разложены по табличках в вики-статьях и на профильных ресурсах. Но даже в его контексте вытащить, скажем, газетные заголовки из онлайн-архивов печатных изданий вручную достаточно долго и муторно.
Что касается оценок — по моему опыту, если кафедра принимала решение устраивать именно защиту курсовых работ (а не как обычно, сдача текста -> письмо на кафедру от н/р с рекомендованной оценкой -> проставление оценки), то оценки оглашались в тот же день.
есть «бюджетный» вариант — делать headless-браузером скриншоты (они умеют это делать уже достаточно давно) и распознавать нужное на них. Если это телефон/цена картинкой прямо на странице — можно справиться и так. Однако если элемент, к примеру, скрыт и требует интерактива (hover, click, drag etc), халява не прокатит, придется работать в окне headful-браузера. А headful-браузер тащит за собой еще и много лишних для этой задачи компонентов, которые тоже едят ресурсы.
Про js fingerprinting у BIG-IP ASM мне известно, но так получилось, что ни один ресурс с полностью настроенной защитой от F5 пока не прошел через очумелые ручки. Попадётся — с интересом загляну под капот.
Это интересная игра, в которую можно играть очень долго. Проблема в том, что анализ собранных данных позволяет достаточно точно определить, как и когда сайт выдает неверные данные в сравнении с имеющимися настоящими. Дальше можно вычислить, какое поведение триггерит выдачу фейковых данных, и скорректировать его. Развитие событий будет вынуждать защитника отдавать фейк на все большее количество обращений, что неизбежно повышает риск ложных срабатываний — для нормального юзера получить фейковые данные (он может не знать, что они таковые) еще опаснее, чем просто 403-ю ошибку или редирект.
В примитивном варианте это поможет от скрейперов «запустил и забыл», которые, видимо, не собираются продавать свою работу, и на ее качество им плевать.
Метрики из Google Analytics могут помочь обнаружить скрейпинг, если он производится топорно, без попыток мимикрировать под человека. Во-первых, надо почистить метрики фильтрами (Exclude all hits from known bots and spiders), а затем можно искать аномалии в репортах: например, юзеры, которые открывают ровно 1 URL (не корень) и уходят, высокая скорость переходов и т.д. — по совокупности факторов неладное заметить можно невооружённым глазом.
Так что предотвратить — нет, обнаружить — чаще да, чем нет.
Эксплуатировать WebRTC leak это ходовой вариант, но и защититься от него несложно.
А вот обфускация и динамические перестановки действительно заставят повозиться тех, кто глазами и парсером смотрит JS и крафтит ответы. Однако динамика встречается нечасто по моим наблюдениям.
Если там REST API, в которое можно сходить чем угодно помимо браузера по задумке, то речь об обычной js инъекции не идет. Однако если там доступ токенизирован с ограничением предметной области — например, конкретное моб.приложение и браузеры — то все веселее. Для браузера уже понятно, как токен сгенерировать, а вот в моб.приложении модифицируется клиентская часть, для этого антиботчики дают свои SDK. У одного из решений можно вообще так капчу себе встроить в клиент (звучит дико, как по мне)
Я кстати скайрим и на плойку купил два раза )) ванильный под PS3 и ремастеред (уже чисто онлайн) на PS4, потом в стиме у меня есть, купил по случаю. Плюс один на Нинтендо свич. Толку мне от той DVD 2009-го?
А, значит, Вы — тот самый человек, которому Todd Howard продал Skyrim четыре раза!
Пока такая бизнес-модель работает, носители, компьютеры и ключи вряд ли куда-нибудь денутся. С облачной арендой так просто не предоставишь человеку одну и ту же IP N раз по полной стоимости.
Совершенно верно. Вариант «как минимум» это действие исключит, если стараться этот IP не светить.
Однако есть и другие способы узнать реальный IP-адрес ресурса, их достаточно много. Они, во-первых, совершенно бесплатны, а во-вторых, не намного сложнее самого банального, и их описание есть в открытых источниках. Соответственно, их применение не увеличивает стоимость атаки сколько-нибудь заметно.
С чего бы ему снижаться на порядок, если сложность организации атаки возрастает незначительно?
Как минимум, если ничего больше не делать, кроме прятанья реальных IP за CF — будет то, что в статье сказано (атакующему достаточно обратиться к DNS history своей цели).
Как не минимум (если менять адреса и т.д.), существуют сервисы, которые резолвят в адреса позади CF — снова один дополнительный запрос для обитателя «серой зоны» Интернета. Дальше история повторяется.
Это больше похоже на проблемы с маршрутизацией, чем на блокировку. Тут TCP-трасса ответила бы точно на этот вопрос.
Во всех ответах, отдаваемых самим защищаемым сайтом, будет такое значение. Наоборот, при блокировке никакого HTTP-ответа заблокированный не получит.
В конце поста есть мои контакты — можно мне туда написать.
Так они научили. Если есть проблемы с доступом куда-то в подобном сценарии, напишите в ЛС, выясним причину. Обратная связь -- царица полей.
Технически, навскидку 4 варианта развития событий (может быть и больше):
Хост-машине, с которой стримится видео+аудиопоток, забивает канал связи. Если стрим идет не через сервис, а зрители коннектятся непосредственно к источнику -- то исчерпать провайдерскую емкость можно легко безо всяких атак.
Стрим может идти через сервис/платформу, но ip+порт источника контента торчат в Сеть без ACL и других ограничений в файрволе. Они обнаруживаются аттакером, после чего туда наливается мусорный трафик, для домашнего или офисного канала много его не потребуется.
DDoS шатает саму платформу для стриминга. Если это Twitch, например, то в случае удачи атака однозначно будет значимой, уровня "заголовки в новостях". При этом outage будет и других стримеров и зрителей.
Одна из черепашек лжет.
Эм, там все-таки в пустыне существенная часть происходит. С таким же успехом можно Сахару (все вариации), 1го и 3го Индиану Джонса, 4-е Звездные Войны, Присциллу и ряд других популярных кино прогнать через такой анализ.
Хотя, справедливости ради, пустыня (и, в частности, Сахара) богата красками и многообразием видов, которое мало кому удалось в полной мере передать на киноэкране.
Приведу 2 примера из практики, которые иллюстрируют это:
Оверхед на скрейпинг с веб-страниц, о котором вы говорите, существует в основном из-за наличия уже внедренных мер защиты. И на него согласны тратиться лишь оттого, что других вариантов собрать данные с такой же скоростью не предоставлено. API скорее помогает не скрейперам, а тем, кто от них больше всего страдает — юзерам, аффилиатам или партнерам, которым нужна интеграция функций одного сервиса в другой.
Постараюсь проще. Расходы на продвинутый скрейпинг могут быть совсем не копеечными, если данные нужно собирать помногу и регулярно, а не один раз из одного места для исследования или развлечения. Внезапно, миллион капч оборачивается порядка $700, аренда residential proxy — от $100/m и выше сообразно качеству. А это те инструменты, на которые скрейпера заставляет тратиться защита. А вы этого не учитываете.
Не могу согласиться насчет «тупое». Есть масса факторов, которые находятся за пределами вашей платежной матрицы и могут заставить (и в реальной жизни заставляют) скрейпера не ходить в API или ходить не только в него:
Этот список можно продолжить.
Такое обобщение не берет в расчет бизнес-модель коммерческих скрейперов. А она работает, когда в асимптотическом приближении (инструмент уже написан/куплен, стоимость модификации околонулевая, а кол-во заказов большое и растет) стоимость данных с одной обработанной странички в продаваемом датасете выше, чем накладные расходы: виртуалки, трафик, стоимость решения капчи, стоимость ручного труда + еще ряд менее очевидных параметров.
Идея public API благородна, я бы хотел жить в мире, где у каждого ресурса с полезными данными было бы оно. К сожалению, что с коммерческим, что с бесплатным роботоориентированным интерфейсом бывает так, что ресурс начинают скрейпить и со страничек, и с API — каких-то данных не хватает, медиа и тд. Из того, что вы уважаете потребности своих юзеров, не следует, что они станут уважать ваши.
Здесь согласен. Однако пока не у всех ритейлеров работает такая модель, эти сценарии как были, так и продолжатся.
Сорри за проволочку — линк на видео как раз доехал в статью.
Пусть будет — сугубо гипотетически — 051311, математическое и программное обеспечение вычислительных машин, комплексов, и компьютерных сетей. Но с тем же успехом может быть и 010107, вычислительная математика, и какая-нибудь другая, где студентами ведется научная работа, и решаются задачи с использованием компьютера :)
Это очень строгое отрицание, и оно, как мне кажется, неверно. Понятие prior art в контексте алгоритмов и исходного кода общеупотребимо. Поэтому, если вы, например, делаете работу об алгоритме собственной разработки, который решает какую-то задачу, без изучения prior art по своей тематике, упоминания релевантных разработок в обзорной части доклада и анализа их преимуществ/недостатков относительно этой задачи вряд ли ее воспримут всерьез. Я не берусь говорить, что «везде так» или «везде не так», однако вот выписка из одного из вузовских пособий по оформлению учебно-научных текстов:
«Назначение этой главы – дать более детальное и систематическое представление о существующих решениях рассматриваемой проблемы, чем это сделано во введении. <...> В идеале в обзорной главе должен быть дан сравнительный анализ известных подходов и вариантов решения проблемы...»
На моем опыте, учитывая, что первая курсовая у студента чаще не несет больших и важных научных инноваций, научное руководство повышенное внимание обращало на то, насколько тщательно студент изучил свою тему и собрал данные для обзорной части, особенно если он планировал в этой теме работать и дальше.
А почему бы и да? Студенты фундаментальных научных дисциплин тоже изучают по программе ЯП и используют их в качестве инструмента, да и не только они. К тому же, как я говорил в докладе, гайдов и готовых сниппетов вокруг столько, что яблоку упасть негде.
Как минимум, в МГТУ, МФТИ, МГУ это так, наверняка во многих других ВУЗах тоже, но я не берусь безоговорочно судить.
Так, если человек делает исследование эволюции систем предупреждения столкновений воздушных судов и уже успел изучить их устройство, ключевые параметры и сделать нужные выводы, этого будет недостаточно без информации о самих инцидентах столкновений и их последствий, т.е. контекста, в котором работа по этому направлению ведется последние 50-60 лет. Как минимум, стоило бы раздобыть описание всех инцидентов за этот срок, категоризировать их и показать, какие из них были ключевыми для внедрения изучаемых технологий (как катастрофа в Гранд-Каньоне в 1956). Без такого анализа работа на эту тему будет, вероятно, воспринята в лучшем случае как проведенная небрежно, а в худшем — как откровенная халтура.
Это всего лишь пример, притом скромный по масштабу, т.к. крупных столкновений-катастроф с участием гражданской авиации всего меньше 100, и они уже заботливо разложены по табличках в вики-статьях и на профильных ресурсах. Но даже в его контексте вытащить, скажем, газетные заголовки из онлайн-архивов печатных изданий вручную достаточно долго и муторно.
Что касается оценок — по моему опыту, если кафедра принимала решение устраивать именно защиту курсовых работ (а не как обычно, сдача текста -> письмо на кафедру от н/р с рекомендованной оценкой -> проставление оценки), то оценки оглашались в тот же день.
Про js fingerprinting у BIG-IP ASM мне известно, но так получилось, что ни один ресурс с полностью настроенной защитой от F5 пока не прошел через очумелые ручки. Попадётся — с интересом загляну под капот.
В примитивном варианте это поможет от скрейперов «запустил и забыл», которые, видимо, не собираются продавать свою работу, и на ее качество им плевать.
Метрики из Google Analytics могут помочь обнаружить скрейпинг, если он производится топорно, без попыток мимикрировать под человека. Во-первых, надо почистить метрики фильтрами (Exclude all hits from known bots and spiders), а затем можно искать аномалии в репортах: например, юзеры, которые открывают ровно 1 URL (не корень) и уходят, высокая скорость переходов и т.д. — по совокупности факторов неладное заметить можно невооружённым глазом.
Так что предотвратить — нет, обнаружить — чаще да, чем нет.
Эксплуатировать WebRTC leak это ходовой вариант, но и защититься от него несложно.
А вот обфускация и динамические перестановки действительно заставят повозиться тех, кто глазами и парсером смотрит JS и крафтит ответы. Однако динамика встречается нечасто по моим наблюдениям.
Если там REST API, в которое можно сходить чем угодно помимо браузера по задумке, то речь об обычной js инъекции не идет. Однако если там доступ токенизирован с ограничением предметной области — например, конкретное моб.приложение и браузеры — то все веселее. Для браузера уже понятно, как токен сгенерировать, а вот в моб.приложении модифицируется клиентская часть, для этого антиботчики дают свои SDK. У одного из решений можно вообще так капчу себе встроить в клиент (звучит дико, как по мне)
А, значит, Вы — тот самый человек, которому Todd Howard продал Skyrim четыре раза!
Пока такая бизнес-модель работает, носители, компьютеры и ключи вряд ли куда-нибудь денутся. С облачной арендой так просто не предоставишь человеку одну и ту же IP N раз по полной стоимости.
Золотые слова!
Совершенно верно. Вариант «как минимум» это действие исключит, если стараться этот IP не светить.
Однако есть и другие способы узнать реальный IP-адрес ресурса, их достаточно много. Они, во-первых, совершенно бесплатны, а во-вторых, не намного сложнее самого банального, и их описание есть в открытых источниках. Соответственно, их применение не увеличивает стоимость атаки сколько-нибудь заметно.
Как минимум, если ничего больше не делать, кроме прятанья реальных IP за CF — будет то, что в статье сказано (атакующему достаточно обратиться к DNS history своей цели).
Как не минимум (если менять адреса и т.д.), существуют сервисы, которые резолвят в адреса позади CF — снова один дополнительный запрос для обитателя «серой зоны» Интернета. Дальше история повторяется.