Комментарии 29
Интересное решение :)
т.е если у меня вебсервер, который я использую еще и для выхода в интернет, к примеру на нем стоит прокси или скажем просто настроен nat, то не ваш сайт я не попаду. Снаружи вы будете видеть только открытый порт http ну и к примеру https и smtp…
Суть решения:
1) Выявить IP имеющие открытые порты наружу т.е. предположительно вэб-сервера, на которых хостятся сайты-сканеры.
2) Разобрать IP в WHOIS. В деталях у хостеров — большой диапазон выделенных IP и наличие рекламы в описании на английском аля «мы хостим, мы лучшие».
1) Выявить IP имеющие открытые порты наружу т.е. предположительно вэб-сервера, на которых хостятся сайты-сканеры.
2) Разобрать IP в WHOIS. В деталях у хостеров — большой диапазон выделенных IP и наличие рекламы в описании на английском аля «мы хостим, мы лучшие».
Но как анализировать автоматически п.2? Получается полуавтоматически :) Т.е. стоит не рубить пользователей автоматом, а раз в день просматривать некую собранную скриптами статистику и только потом рубить? Вдруг получится так, что мой домен принадлежит провайдеру, который хостит и лучший?
Хе, заход из офиса на шлюзе которого веб-сервер поднят, заход с дсл-рутера у которого забыли доступ к настройкам из веба закрыть, заход в конце концов с компа где включён скайп (у старых версий по дефолту стояла галочка использовать порты 80 и 443). Не слишком ли много ложных срабатываний?
А мне способ очень даже понравился. Это не автобан, а метод профилактики скорее…
Ну и даже по whois в поле описания у хостеров частенько фигурирует что-то типа Hosting service provider.
Очень рад, что вчера читал это в песочнице, а сегодня уже в блоге.
Ну и даже по whois в поле описания у хостеров частенько фигурирует что-то типа Hosting service provider.
Очень рад, что вчера читал это в песочнице, а сегодня уже в блоге.
По-моему, грабер отличается от человека тем, что делает просмотры быстро — это основное отличие.
Может стоит по скорости запросов с одного ip отслеживать? Хотя, конечно можно написать «медленный» грабер и воровать маленькими партиями, но воришкам это не выгодно (особенно если контента много), т.к. страдает акутальнось воруемой информации, и повышаются шансы что ваш сайт со свежим контентом поисковики переиндексируют первым.
А ваш метод, хоть и оригинален, но не запретит мне настроить грабер на домашнем компе (как с него я буду передавать награбленное на свой сайт уже другой вопрос)?
Может стоит по скорости запросов с одного ip отслеживать? Хотя, конечно можно написать «медленный» грабер и воровать маленькими партиями, но воришкам это не выгодно (особенно если контента много), т.к. страдает акутальнось воруемой информации, и повышаются шансы что ваш сайт со свежим контентом поисковики переиндексируют первым.
А ваш метод, хоть и оригинален, но не запретит мне настроить грабер на домашнем компе (как с него я буду передавать награбленное на свой сайт уже другой вопрос)?
Контента — много т.к. речь идет о доске объявлений.
Вот интересно — сколько топиков с хабра расходиться «на-лево».
Вот интересно — сколько топиков с хабра расходиться «на-лево».
К сожалению, можно делать последовательно запросы каждый раз через разные прокси. Тогда формально запросы будут «медленно» поступать с каждого ip, что фактически будет происходить «быстрая» работа парсера.
Интересная идея, теперь буду добавлять на фаервол ip сайтов которые граблю :)
Кстати вы не пробовали еще whois прикрутить провайдеров, а так же обновление списка открытых проксей, это как дополнение данной идеи. А вобще, имхо, будущее за статистикой, анализируя поведение пользователя сайта и накапливая инфу можно намного более точно выявить грабителей, что-то типо защиты цисками от ддоса :)
Кстати вы не пробовали еще whois прикрутить провайдеров, а так же обновление списка открытых проксей, это как дополнение данной идеи. А вобще, имхо, будущее за статистикой, анализируя поведение пользователя сайта и накапливая инфу можно намного более точно выявить грабителей, что-то типо защиты цисками от ддоса :)
Это пипец, до чего доходят всякие сайтостроители, чтобы защитить свой контент. Например, на сайте fenzin.org контент загружается отдельным яваскриптом (!), перехватывающим попытки выделения мышкой. Понятно, что ни о каких поисковиках речи уже не идет.
Гм, 55К текста на главной. В Opera «Копировать» работает нормально.
Например вот — fenzin.org/online/12015/1
а вам не кажется, что сайт выкладывающий полные книги их авторов (насколько я помню официально, хотя я не уверен) в праве хоть как-то, будь то от ламеров и граберов защищать контент книги?
Нет, не кажется. Я считаю такой подход к делу неуважением к посетителям. На своем сайте я не возражаю против копирования статей с указанием ссылки на источник. Как показывает практика, многие так и делают.
А если мне удобно читать книгу не с экрана, а с e-ink-книжки?
купите нужную вам книгу в нужном формате.
я не оч понимаю вообще проблемы, не нравиться не посещайте сайт.
он предоставляет то что считает нужным, гораздо лучше бы если бы доступ к книгам был по смс?
я не оч понимаю вообще проблемы, не нравиться не посещайте сайт.
он предоставляет то что считает нужным, гораздо лучше бы если бы доступ к книгам был по смс?
Кстати, по whois пробивать IP тоже не вариант, ибо очень часто применяются сервисы типа dyndns, да и бывает что у обычных людей на один айпи по 20 доменов висит. (я себе повесил 20 доменов из зоны org.ru и прочих — пригодятся)
Определяйте грабеж контента по скрости просмотра страниц.
Стандартный скрипт парсера написаный на питоне может выкачивать и обрабатывать в среднем 1 страницу в секунду.
Как вариант — затрудните полную выборку контента по регэкспам, например, расположить части контента в разных частях дерева DOM и поменяв местами. И добавить элемент случайности в генерации.
Правда после этого поисковики будут чихать и кашлять.
Определяйте грабеж контента по скрости просмотра страниц.
Стандартный скрипт парсера написаный на питоне может выкачивать и обрабатывать в среднем 1 страницу в секунду.
Как вариант — затрудните полную выборку контента по регэкспам, например, расположить части контента в разных частях дерева DOM и поменяв местами. И добавить элемент случайности в генерации.
Правда после этого поисковики будут чихать и кашлять.
У меня на рутере открыт 80-ый порт
Все, я не увижу Ваш сайт
Подойдите к проблеме проще — поисковики умеют давать пенальти за дублированный контент, тем кто его ворует. Источник они не трогают.
Все, я не увижу Ваш сайт
Подойдите к проблеме проще — поисковики умеют давать пенальти за дублированный контент, тем кто его ворует. Источник они не трогают.
поисковики не умеют определять источник
к проблеме скачивания сайта я подошел со стороны кол-ва просмотров в час abo.habrahabr.ru/blog/43768/
к проблеме скачивания сайта я подошел со стороны кол-ва просмотров в час abo.habrahabr.ru/blog/43768/
Сама идея — неплохая, но конкретная реализация мне не очень понравилась.
И вот почему:
1. Запрос происходит в on-line'е сразу после генерации страницы? Если на той стороне firewall, который «глотает» ваши попытки подключения (т.е. не отвечает, что на порту ничего нет), то достаточно «дорогой» (по памяти) процесс (или поток) web сервера будет каждый раз «подвисать» на лишние 3-4 секунды.
На сайтах с более менее высокой посещаемостью — расточительно слишком.
2. Наличие чего-либо прослушиваемого на портах — далеко не показатель чего-либо (у меня, к примеру, роутер тоже всех на 80й и 443й порты пустит)
3. Робот может игнорировать установку куки и тогда его никогда не поймаешь.
Я бы предложил немного другую модификацию:
1. Анализ поведения посетителей, по логам web-сервера.
Робот-сканнер скорее всего ходит каждый день (а то и много раз в день), подобные слишком частые посетители заносятся в серый список.
2. По серому списку и проводятся проверки (причём отдельным демоном, который по своему расписанию проверяет) на порты и т.д.
3. Тем, у кого открыты порты — в каждый пост добавляется какой-нибудь безобидный UID (типа ID новости: <тут уникальная строка для IP адреса>)
4. Через какое-то время — ищешь в поисковиках выдаваемые уникальные строки.
Если что-то нашлось — значит вот он, дубликатор-автомат.
p.s. В общем-то основная идея — проверки желательно делать в off-line'е и на основе статистики, а не проверять всех подряд с поводом и без повода.
И вот почему:
1. Запрос происходит в on-line'е сразу после генерации страницы? Если на той стороне firewall, который «глотает» ваши попытки подключения (т.е. не отвечает, что на порту ничего нет), то достаточно «дорогой» (по памяти) процесс (или поток) web сервера будет каждый раз «подвисать» на лишние 3-4 секунды.
На сайтах с более менее высокой посещаемостью — расточительно слишком.
2. Наличие чего-либо прослушиваемого на портах — далеко не показатель чего-либо (у меня, к примеру, роутер тоже всех на 80й и 443й порты пустит)
3. Робот может игнорировать установку куки и тогда его никогда не поймаешь.
Я бы предложил немного другую модификацию:
1. Анализ поведения посетителей, по логам web-сервера.
Робот-сканнер скорее всего ходит каждый день (а то и много раз в день), подобные слишком частые посетители заносятся в серый список.
2. По серому списку и проводятся проверки (причём отдельным демоном, который по своему расписанию проверяет) на порты и т.д.
3. Тем, у кого открыты порты — в каждый пост добавляется какой-нибудь безобидный UID (типа ID новости: <тут уникальная строка для IP адреса>)
4. Через какое-то время — ищешь в поисковиках выдаваемые уникальные строки.
Если что-то нашлось — значит вот он, дубликатор-автомат.
p.s. В общем-то основная идея — проверки желательно делать в off-line'е и на основе статистики, а не проверять всех подряд с поводом и без повода.
связка iptables + patch-o-matic + TARPIT target способна здорово напрячь ваш апач.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматический отстрел граберов или как избежать автоматического сграбления сайта