Как стать автором
Обновить

Комментарии 59

Т.е. получается что таки каждую минуту может происходить nginx -s reload?
Мне кажется можно делегировать половину действий самому nginx и обойтись без частых reload.
Потенциально, может. На практике с таким не сталкивались пока. Да, и решение не претендует на универсальность. Для конкретного проекта хорошо подошло,
у паразитного трафика имеются определенные паттерны поведения и свойства

Проблема в том что вы обнаруживаете свойства, заранее вам известные. Попробуйте положить в свои страницы код проверки на наличие пользователя (типа рекапчи от гугля, только не капча а именно проверка на наличие действий пользователя — метание курсора, выделение текста) — и удивитесь сколько вас  фантомом парсят, и при этом в озвученные выше фильтры не попадают.
А проверка капчей — честно, спорно. Что бы отсечь посещения которые мешают только вам, вы создаете неудобства своим пользователям. За что?
Можно написать webdriver-бота (хотя бы и через selenium), он и мышкой будет дёргать и выделять текст и вообще.
(зато будут забанены пользователи, которые жабаскрипт отключили)
можно. Но тут уже для качественной имитации надо иметь хорошую стату что бы выделить паттерны поведения пользователей и имитировать их деятельность. не скажу что нет таких в природе, но это уже игроки другого эшелона.
Да и в общем то моя реплика больше была не о том что авторы делают что то неправильно а скорее о том что этого вообще делать то и не надо (на мой взгляд, допускаю что он может быть ошибочным).
В общем цена получения данных или содания нагрузки противостоит цене защиты от них с сохранением прибыли.
Авторы в любом случае выделили один паттерн из миллиона и используют его.
Тут вопрос в том, сколько %% ботов они отсекают этим паттерном.
У меня джаваскрипт отключён, а когда включён, я ни мышкой не метаюсь, ни текст не выделяю, т.к. Vimperator.

UPD: И да, писал парсеры, ни один под приведённый в статье список поведения не попадает, кроме пустого referer'а. Это просто, чтобы подтвердить первую половину Вашей точки зрения.: )

UPD2: А *большинство* запросов к разделу товаров скорее всего у вообще всех посетителей сайта, если это магазин.
У меня такое ощущения сложилось, что задачи "отшить всех ботов" вообще не ставилось.

Об этом ещё из преамбулы видно: ну стащат что-то боты и стащат, не в этом дело. Хотелось, как я понял, "пришибить" ботов создающих повышенную нагрузку и при этом не дающих ничего взамен (поисковики, понятно, дают и понятно что).

А CAPTCHA — это, как я понял, от ложных срабатываний: если человека вдруг записали в боты — он разгадает картинку и его пропустят, а для ботоводов есть более простые решения — просто переписать их так, чтобы они не создавали излишней нагрузки...
В точку! :)
А для создателей интернетов тогда нужно разработать стандарт файлов, в котором будет лежать вся информация для парсящих. Разрабатывал и парсеры, и системы, которые определяют ботов. Защищаться от ботов себе дороже. Проще переформировывать файл с каталогом товаров (прайс лист).
Я тоже подумал об этом: ну господи, грузят они, нужна им эта информация, ну так дайте им её простым способом, чтобы им не приходилось парсить. Или даже продайте занедорого.

Проблема в том, что многие магазины по разным причинам очень не хотят сравнений с конкурентами, а если выдать свой прайс, да ещё в стандартном машиночитаемом формате — сравнения будут на каждом шагу. Поэтому они не захотят делать свои прайсы в таком формате, и парсинг запрещают.
для ботоводов с бот-сеткой — фигня вопрос… скажем есть у него в наличии 500 уникальных IP, при сотне запросов в сутки с каждого, ежедневно у него в наличии актуальный прайс лист на 50.000 артиклей… и у конкурентов цена на пару процентов ниже.
При том, что свои зоопарки ботоводы часто разводят на компах "домохозяек" и т.п. — все эти ip ещё и динамические в добавок… т.е. завтра другие как правило...
А для создателей интернетов тогда нужно разработать стандарт файлов,
А чем вам RSS не угодил?
И это все компания делает во время развития семантической концепции интернета.
Возможно нужно развивать просто защиту информации как-то подписывать контент.
Или регистрировать себя как первоисточник в тех же поисковых системах.
Вы получили временную передышку? Или смогли отвадить "парсеры" совсем?
От данного клиента отстали. Больше нигде не пробовали применять.
НЛО прилетело и опубликовало эту надпись здесь
У них теперь даже есть подробная инструкция по обходу защиты :)
Нужно только знать, что за клиент ) Из более, чем полутора сотен — сложно угадать.
Если автор парсера читает хабр, ему угадывать не надо :)
Очень российский подход — не знаем, кто и зачем к нам ходит, но давайте на всякий случай запретим. Наверняка это злодеи. Картинка к посту это эпично подтверждает.

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

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

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

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

Ну и с архитектурной точки зрения решения просто ужасно. Хотя бы по причине постоянной перезагрузки настроек nginx. Когда вы запускаете какой-то процесс сервера (в особенности веб сервер или СУБД), то ожидаете, что он будет работать с изначальными настройками всё время до ручной перезагрузки или ребута. А выходит, что если некий администратор правил настройки — например, хотел подключить SSL — и не доделал их, сохранив в уверенности что вернётся к этому чуть позже, то неверные настройки будут автоматически использованы.

Если уж заказчик захотел такой функционал, то было правильно использовать подходящие для него средства — например, fail2ban. По айпи адерсам и юзерагентам он отлично умеет определять ботов. Можно было бы так же дописать некие свои проверки — например, сделанную вам проверку по PTR… Хотя кажется, fail2ban умеет и это. Нет, сделали какой-то ужасный костыль и довольны.
Тут именно по настоянию заказчика занимались реализацией этой задачи. Согласен, что это костыль. fail2ban не помог. Возможно, стоило просто стать под защиту специализированных сервисов. Однако, заказчик настоял именно на таком вот решении. Поверьте, пытались переубедить :)
А что не срослось с fail2ban? Верю, что могли быть какие-то интересные грабли, интересно узнать, какие. Сам я fail2ban использовал для защиты ftp/smtp и ещё нескольких сервисов, с http пока не было потребности — но интернет говорит, что используют успешно.
fail2ban не помог

Ну как бы в мире ИТ не существует подобных словосочетаний — "не работает", "не помогло" (без конкретики).

А как разработчик fail2ban пока поверю только в то, что установив его (из коробки), вы не получили требуемого результата. Имхо, вполне ожидаемо и закономерно (ибо нужно его "готовить", в принципе как и любой инструмент).

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

В результате (вероятно просто не разобравшись) вы сделали велосипед, плохой-хороший не суть важно, ибо все-равно велик. Потому что, если я правильно разобрал, что вы "создали", то как минимум половину работы (если не 2/3) можно было переложить на f2b...
А вы пытались хотя бы намекнуть клиенту, что, возможно, стоит вместо того, чтобы бороться — возглавить? Сделать api, чтобы желающие мгли получить данные не грузя сайт, без всякого парсинга?
вот-вот. нас просто блокировали без объяснений и попытки связаться.
Вы совсем читать не умеете? Вам про Фому, а вы — про Ерёму.
Если у проекта есть парсинг — он делается не просто так и делаться от ваших действий он не перестанет, просто примет другие формы.
или можно было бы поднять нормальный API на отдельном серваке.
даже за деньги многие не готовы к этому — владельцы сайтов я имею в виду
Всё очень правильно написано. Я занимаюсь парсингом более трёх лет. И за 3 года я видел только один сайт, который нельзя было спарсить. Точнее, в заданном промежутке времени я не нашёл решения. Для каждого сайта можно сделать парсер. И он будет эммулировать всё то, что Вы описали в статье и даже больше.
Наиболее рациональная защита — это ограничение по количеству запросов с 1 ip в единицу времени. Большинство живых людей не будут сидеть и листать Ваш сайт час страницу за страницей. Либо же отдача какой-то части материала. Например, если человек ищет какую-то услугу в каком-то регионе, то ему отдаются не все 40000 результатов поиска, а 3000 первых записей. Для живого человека этого более, чем достаточно (именно так работает таже manta.com).
Большинство живых людей не будут сидеть и листать Ваш сайт час страницу за страницей.
Зато за одним proxy-IP может оказаться вдруг несколько тысяч (если не миллионов) живых людей.
Сколько эти парсеры давали нагрузки, что "LA значительно рос на серверах". 100 запросов в секунду? 1000? Может проще было оптимизировать код, пересмотреть какие-то подходы, чтобы просто не замечать эту избыточную нагрузку? Ну а если с одного адреса проходит запредельное кол-во запросов на бэкенд мимо кешей, то можно поместить этот адрес в некий список, которому показываю только капчу. (У вас что-то подобное уже реализовано)
Удивительно, я конечно не знаю всех деталей, но столько вложить сил в латание… по факту костылей.
В кои-то веки нормальная техническая статья про конфигурирование, а все комментарии про надо / не надо и не одного про конфиги. На хабре админы остались, вообще?
Чуть выше автор признаёт, что это специфический костыль, обусловленный требованиями заказчика. Ну и не совсем понятно, какие комментарии про конфиги вы хотите услышать.
В статье описан жуткий костыль и она скорее является примером как делать не надо, потому и реакция соответствующая.
Статья и тематика спорная, но прочитал с интересом. Не хватает цифр — доля паразитного трафика до и после, какие меры из реализованных больше всего повлияли на итоговую фильтрацию.
PTR-записи у многих хостеров ставятся автоматом любые и никто не мешает им поставить ptr-записи google или яндекс и т.п. Поисковики рекомендуют потом еще обратное преобразование проверять.

Еще может иметь смысл проверять IP-адреса по whois, тогда если whois правильный и соответствует яндексу/гуглу и т.п. — можно в белый список сразу всю их сеть внести и данные в whois подделать сложнее, чем PTR.
geo $whitelist {
default 0;

77.88.0.0/18 1;
93.158.128.0/18 1;
95.108.128.0/17 1;
178.154.128.0/17 1;
199.36.240.0/22 1;

Не доверяйте просто так подсетям ПС. Они далеко не безгрешны. Парсинг 2-х летней давности с серверов Яндекса:

178.154.243.106 -       5011415253      1419741951.254  [GET]   [/servis-centr/texet?ah62]      200     15241     -       [Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5409 Safari/536.5]       m*****.ru       XXX.XXX.217.215:80    28/Dec/2014:07:45:51 +0300      RU      w:1     []
178.154.243.105 -       5011428078      1419741951.345  [GET]   [/servis-centr/texet?ah141]     200     241     -       [Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5409 Safari/536.5]       m*****.ru       XXX.XXX.217.215:80    28/Dec/2014:07:45:51 +0300      RU      w:1     []
178.154.243.104 -       5011415952      1419741951.354  [GET]   [/servis-centr/texet?ah88]      200     19249     -       [Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5409 Safari/536.5]       m*****.ru       XXX.XXX.217.215:80    28/Dec/2014:07:45:51 +0300      RU      w:1     []
95.108.158.134  -       5011424897      1419741951.430  [GET]   [/servis-centr/texet?ah69]      200     52415     -       [Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5409 Safari/536.5]       m*****.ru       XXX.XXX.217.215:80    28/Dec/2014:07:45:51 +0300      RU      w:1     []
178.154.243.107 -       5011410458      1419741951.574  [GET]   [/remont-chasov/royal-london18ao]       200     8029    -       [Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5409 Safari/536.5]       m*****.ru       XXX.XXX.217.215:80     28/Dec/2014:07:45:51 +0300      RU      w:1     []
5.255.253.3     -       5011428792      1419741951.586  [GET]   [/remont-chasov/royal-london19au]       200     8030    -       [Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5409 Safari/536.5]       m*****.ru       XXX.XXX.217.215:80     28/Dec/2014:07:45:51 +0300      RU      w:1     []
95.108.128.241  -       5011423471      1419741951.593  [GET]   [/remont-chasov/royal-london22a]        200     8028    -       [Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5409 Safari/536.5]       m*****.ru       XXX.XXX.217.215:80     28/Dec/2014:07:45:51 +0300      RU      w:1     []
95.108.128.242  -       5011427425      1419741951.617  [GET]   [/servis-centr/texet?ah73]      200     15245     -       [Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5409 Safari/536.5]       m*****.ru       XXX.XXX.217.215:80    28/Dec/2014:07:45:51 +0300      RU      w:1     []

Около 3'000'000 запросов за сутки. Разумеется никакими Яндекс-ботами здесь и не пахнет
А что мешало реализовать динамическую роботоловилку с прослойкой перед внутри nginx на lua? Так делает, например, Wallarm.
По временным затратам вышло бы примерно тоже самое, но скорость и качество работы ни в сравнение.

Не критики для, а вопроса ради. Решение, как я понимаю, уже протестировано и работает в рамках ТЗ заказчика. Интересует, почему вы пришли именно к такому решению.

P.S. Соглашусь с комментарием jehy, что можно было не банить, а попытаться связаться с владельцами ботов. Отдавая хотя бы стандартную страницу "call me maybe"
Мешало отсутствие знаний lua и времени на его изучение. А так да, такая идея была.
Стоило хотя бы попытаться. В него на удивление просто вникнуть.
А мы боремся с теми, кто борется с нашими парсерами… Пока получается. Но мы не такие плохие (даже хорошие я бы сказал) — мы стараемся раскидывать нагрузку (запросы к сайту) в течение дня, а не разово пытаться скачать "весь Интернет".
Я иногда пишу парсеры как хобби. Даже у меня есть небольшие наработки по проходу сайтов и ваша защита так себе )
Лучше сделайте API, если вам кому-то нужны ваши продукты то пускай на них смотрят.

Если большой пик с одних адресов, то скорее всего идет «синхронизация», т.е. если бот не работал нужно добрать. А так инкремент как правило идет довольно быстро.

Когда парсерщим это надоесть они купят симку и модем и будут ходить на мобильную версию сайта с сети МТС и тд.
Мобильная версия накладывает ограничения на всякие капчи, а если забаните ip большой тройки сами плакать будете )
Мне кажется странным, что интернет-магазин решил ограничить распространение данных из своего раздела Товаров (читай каталогов и прайс-листов). Обычно поступают наоборот. Может лучше было организовать API, а при детектировании бота выдавать ему подсказку с адресом этого API, чтобы облегчить жизнь админу этого бота?
Я, чесно, не пойму, какую такую ужасную нагрузку несет nginx динамике c, хотя бы, 30 минутным кешем каталога товаров.
Ну ей богу, не пойму. При правильной настройке ключей (с cookies и без cookies) у вас отдельные кеши для всех и для зарегистрированных клиентов/редакторов.

И в таком случае, как правильно заметили выше, роляет рейт запросов на IP. Если динамика тупая и кривая и работает на калькуяторе.\

Подходит только под: не хочу делиться, хочу быть уникальным! Глупости это все и трата времени. Кто хочет — спарсит. Что не может — попросит того, что может. Я сам, когда парсил нужные мне ресурсы представлялся или хромом, или гуглом, всегда отправлял реферера и еще пачку заголовков, иногда и кукисы поддерживал, и все в 5-6 потоков. Иногда часть через прокси. Мде.
Потому что современные интернет магазины не кешируют ничего даже для анонимов/гостей. Необходим анализ переходов пользователя для отображения спец предложений, похожих или возможно заинтересующих товаров. Маркетологи на крупных проектах сейчас пытаются каждые вероятные 0,5 процента выжать.

Подходит только под: не хочу делиться, хочу быть уникальным! Глупости это все и трата времени. Кто хочет — спарсит. Что не может — попросит того, что может. Я сам, когда парсил нужные мне ресурсы представлялся или хромом, или гуглом, всегда отправлял реферера и еще пачку заголовков, иногда и кукисы поддерживал, и все в 5-6 потоков. Иногда часть через прокси. Мде.
Вас можно вычислить. На раз — два. Приходилось использовать вебдрайвер (selenium, PhantomJS), правильно водить мышкой, изучать поведенческие шаблоны и пр. Покупать распознавание капчи наконец. А с учетом стоимости таких услуг иногда только 80$ в день улетало на распознавание капчи.
>> Потому что современные интернет магазины не кешируют ничего даже для анонимов/гостей. Необходим анализ переходов пользователя для отображения спец предложений, похожих или возможно заинтересующих товаров. Маркетологи на крупных проектах сейчас пытаются каждые вероятные 0,5 процента выжать.

Это все можно на джаваскрипте асинхронно сделать.
Не на раз-два. Стоимость обнаружения качественного парсера сравнима со стоимостью разработки такого парсера. Короче, тут типичная борьба оружия и брони.

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

Вы их на мух и котлет разделяете при помощи cookies? 10 секундный кеш по ключу с кукисами решит вашу проблему. Просто добавить $cookiename к ключу.
Даже для тех, кто не слушает советов, 1 секундный кеш и рейты в каждом случаю 100% решают задачу и коллосально снижают нагрузки. А всю обработку нужно повесить на javascript, как писали ниже. Ну или покупать железо мощнее.

Вас можно вычислить. На раз — два.

У вас есть такой сайт (или вы с ним сталкивались), который вычисляет таких парсеров на раз-два? Дайте ссылку в личку, я хочу посмотреть.
Ой, ладно, какая нагрузка? Хотите с ней бороться — помогите парсерам, сделайте api. Или кешируйте данные. Или… Средств борьбы с нагрузкой куча!
Мне кажется, что вы просто боитесь за данные.
На что только не пойдут люди, лиж бы не сделать файлик с каталогом, в котором все будет лежать в удобоваримой форме.
Это какая-то борьба с ветряными мельницами, тем более что боты просто парсили контент.
Впрочем, типично российский подход к решению проблем, все запретить, никого не пускать, пускай клиенты монитор разобьют из-за капчей.
Ну да, вместо того чтобы сделать удобный АПИ, давайте объявим потребителей злоумышленниками! Совковый маразм!
Сказ о потраченных человекочасах.
Как владелец СП-сайта (и тот, кто писал парсеры сайтов поставщиков для своих организаторов закупок) хотелось бы заметить, что если бы компании, подобные вашим клиентам, не были бы упоротыми и предоставляли бы прайс-листы в машиночитаемом виде и со ссылками на картинки (для выкачивания), а не кучей разовых соплей и пони какающих радугой, то количество подобныъ парсеров устремилось бы к нулю.
С одной стороны, понимаю Вас, и в чем-то согласен, так было бы всем проще жить. С другой, понимаю и таких клиентов: они тратят ресурс на наполнение контентом своих проектов, а это потом все пытаются бесплатно утащить.
Так о том и речь: если бы они «нормально» вели себя с контрагентами и затруднились бы задуматься о специфике работы (более того, машиночитаемые прайслисты требуют намного меньше работы для наполнения, чем эта радужная каша, которую они присылают), то мало кому нужно было бы бесплатно таскать у них.

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