Ахтунг! Google отслеживает низкоуровневые протоколы?

Вчера неожиданно возникла мысль, как Google может отслеживать дорвейные сети:

Все мы знаем (ну ладно, некоторые из нас), что прежде чем попасть на компьютер пользователя, любой HTTP-пакет инкапсулируется в следующие протоколы:

TCP
IP
Ethernet (или другие альтернативные протоколы)

Любое HTTP-сообщение таким образом выглядит так
<ethernet><ip><tcp><http></tcp></ip></ethernet>
В каждом протоколе содержится некая служебная информация, необходимая для его функционирования. В каком-то из этих протоколов содержится MAC-адрес сетевой карты сервера, с которого пришел документ.

А теперь вопрос: Что мешает Google отслеживать разворачиваемые сети дорвеев по этомй признаку? Получается так, что даже после смены IP и доменов, если в железяке под названием сервер ничего неменять, то Google будет знать "Ага, это тот самый сервер, где были замечены вот такие проблемы", или "Ага, эта септь доменов расположена на одном сервере".

Есть у кого-то каменты на эту тему?

Последний раз редактировалось: kit (24/03/06 в 19:00), всего редактировалось 1 раз

Зачем так сложно? ) А гугль не может предположить вариант, что дедик перепродали уже в "белые" руки? Получается что изначально белый сайт уже будет пенальтизирован. А гугль и так очень осторожничает с этим. Иначе б все фрихосты были б забанены давно-давно

Тем более дорвейщик легко меняет серваки. Проще поменять сервак, чем переносить его в другую подсетку.

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

kit, доброе утро. Это все импользуется. Может не в той форме что ты сказал, но используется. Совершенно ни к чему возиться с именно мак адресами если есть имена на кого регистрировали домены, диапазон сети где стоит сервер, имена ДНСов и т.п. Я знаю имя зарегестрировав на которое домен ты никогда не получишь на него от гугля трафа (ну может лет через 60....)
Отслеживается ли физически та ли машина это - фиг знает. Просто я никогда не переносил машину с места на место. А вот то что не надо складывать все яйца в одну корзину и "избегайте неблагополучных соседей" - это уже в раздел наскальной живописи скоро перейдет по возрасту и крепости написания.
То есть я исхожу из того что даже если сегодня что-то не используется, но хрен его знает что эти паразиты там пишут и когда у них дойдут руки это проанализировать. Так что я предпочитаю превентивно не наступать туда где в любой момент выяснится что там еще вчера грабли положили.

Немного не так...
Допустим у нас следующая связь между гуглем и дедиком:
Дедик(1)<-->промежуточный_хост(2)<-->промежуточный_хост(3)<-->гугл(4)
Такая связь существует в 99,999999999999999% случаев, ибо вряд ли у кого-то есть дедик со шнурком, напрямую воткнутым в сервер гугла..
В скобочках для краткого обозначения указаны хосты.
Далее запрос от гугла к дедику выглядит так:
У гугла формируется пакет <http>, пердается на уровень tcp:
<tcp><http></tcp>
Далее передается на уровень ip:
<ip><tcp><http></tcp></ip>
Далее передается на уровень ethernet:
<ethernet4-3><ip><tcp><http></tcp></ip></ethernet4-3>
Я обозначил <ethernet4-3>, потому что в пакетах на уровне ethernet'а содержится информация о MAC-адресах хостов 4 и 3

Далее на хосте 3 этот пакет раскрывается и получается:
<ip><tcp><http></tcp></ip>
Затем обратно заворачивается в пакет ethernet, но уже немного другой:
<ethernet3-2><ip><tcp><http></tcp></ip></ethernet3-2>
Разворачивается на хосте 2 и снова заворачивается в ethernet:
<ethernet2-1><ip><tcp><http></tcp></ip></ethernet2-1>
Попадает на хост 1 (наш дедик) и мы видим, что дедик ни как не получает информации о мак-адресе гугла.
Далее ответ выглядит совершенно также в сторону гугля и гугл не может определить MAC-адрес дедика.

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

PS: Есть подозрения, что гугл сниффит траффик на уровне http, а это совсем другая интересная история

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

bog писал:

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

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

A d u l t писал:

Немного не так... Допустим у нас следующая связь между гуглем и дедиком: Дедик(1)<-->промежуточный_хост(2)<-->промежуточный_хост(3)<-->гугл(4) Такая связь существует в 99,999999999999999% случаев, ибо вряд ли у кого-то есть дедик со шнурком, напрямую воткнутым в сервер гугла.. В скобочках для краткого обозначения указаны хосты. Далее запрос от гугла к дедику выглядит так: У гугла формируется пакет <http>, пердается на уровень tcp: <tcp><http></tcp> Далее передается на уровень ip: <ip><tcp><http></tcp></ip> Далее передается на уровень ethernet: <ethernet4-3><ip><tcp><http></tcp></ip></ethernet4-3> Я обозначил <ethernet4-3>, потому что в пакетах на уровне ethernet'а содержится информация о MAC-адресах хостов 4 и 3 Далее на хосте 3 этот пакет раскрывается и получается: <ip><tcp><http></tcp></ip> Затем обратно заворачивается в пакет ethernet, но уже немного другой: <ethernet3-2><ip><tcp><http></tcp></ip></ethernet3-2> Разворачивается на хосте 2 и снова заворачивается в ethernet: <ethernet2-1><ip><tcp><http></tcp></ip></ethernet2-1> Попадает на хост 1 (наш дедик) и мы видим, что дедик ни как не получает информации о мак-адресе гугла. Далее ответ выглядит совершенно также в сторону гугля и гугл не может определить MAC-адрес дедика.

Всё правильно, на транспортном уровне не передаётся МАС.

Кит не пугай людей ;)

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

Gatos+ писал:

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

Ну зачем тогда мучиться? Можно сразу половину сайтов из индекса выкинуть, а потом убить себя ап стену

A d u l t писал:

Ну зачем тогда мучиться? Можно сразу половину сайтов из индекса выкинуть, а потом убить себя ап стену

Технически вполне реально, почему бы им не использовать такую возможность? Хостеры задумаются с какими клиентами иметь дело, а с какими нет.. Это как альтернативный метод, есть здесь и своё НО:
трейсроуте использует ИЦМП протокол, который можно всегда запретить ;)

Кит, ситуация иная.
Если предположить что ты прав, получим такую ситуацию, послав ping на google мы узнаем его Mac-адрес. А теперь проделаем это все на практике:
1. Посылаем несколько пакетов
ping google.com

Код:

Pinging google.com [64.233.167.99] with 32 bytes of data: Reply from 64.233.167.99: bytes=32 time=281ms TTL=240 Reply from 64.233.167.99: bytes=32 time=454ms TTL=240 Reply from 64.233.167.99: bytes=32 time=421ms TTL=240 Reply from 64.233.167.99: bytes=32 time=321ms TTL=240 Ping statistics for 64.233.167.99:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 281ms, Maximum = 454ms, Average = 369ms

после набираем комманду
arp -a ( Displays current ARP entries)
получаем

Код:

Interface: 192.168.YYY.101 --- 0x10003   Internet Address      Physical Address      Type   192.168.YYY.11          Mac-адрес     dynamic   192.168.YYY.22          Mac-адрес     dynamic

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

З.Ы. Кит, эни комент?

Я раздавлен вашими аргументами господа ;-).
Подвело не очень хорошее знание работы протоколов.
Выходит Мас-адрес источника данных не такая уж и легкодоступная штука.

Но в целом, идей остаётся: Гугл может анализировать не только HTTP протоколы, но и любые другие сопутствующие им, и на основе их строить какие-то дополнительные предположения.

kit писал:

Я раздавлен вашими аргументами господа ;-). Подвело не очень хорошее знание работы протоколов. Выходит Мас-адрес источника данных не такая уж и легкодоступная штука. Но в целом, идей остаётся: Гугл может анализировать не только HTTP протоколы, но и любые другие сопутствующие им, и на основе их строить какие-то дополнительные предположения.

они могут хоть до усрачки анализировать это внутри своей сети, но это ровным счетом не даст никакой информации о нас =)

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

мало того, с запуском персонализированного поиска они начали передавать намного больше информации в самом поисковом запросе. Это наверное все видели.

Mauser писал:

но хрен его знает что эти паразиты там пишут и когда у них дойдут руки это проанализировать

хаха, ... гуглевые паразиты не дают траф отбирать ...

jAPAN писал:

они могут хоть до усрачки анализировать это внутри своей сети, но это ровным счетом не даст никакой информации о нас =)

Да прям!
Привожу примеры:
1) Гуглебар - это целая армия пользователей, своим поведением они очень много рассказывают Гуглу.
2) Персонализированный поиск
3) Анализ данных системы DNS
4) Анализ статистики обращения к DNS

Не так уж и мало они об интернете знают.

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

причина сих мыслей - бай виагра. из 10 - штук 6-7 доров.

гугл много чего анализирует... еще б он это с успехом применял и внедрял.... (хотя лучше б внедрял как сейчас)

А куда должен вести "бай виагра", на статью о виагре, или на сайта фирмы Pfizer - разработчика виагры?
Лично мне не кажется этот пример удачно демонстрирующим плохое качество выдачи Гугля. Был бы так плох его поиск, не захватил бы он практически 50% поискового рынка, откусив у всех остальных поисковиков.

Есть такой старый анекдот.
Как-то раз пошли чукча с геологом охотится на зверька пушного зимой. Ну постреляли, патроны закончились, идут домой, вдруг бац! Прваливаются в берлогу, выскакивают оттуда с поломаными лыжами, а оттуда медведь за ними. Но пока медведь в себя приходил они припустили. Медведь сориентировался и за ними. Бегут и геолог говорит: - Это бесполезно, мы не можем бежать быстрее медведя. Чукча: - а мне не надо бежать быстрее медведя, мне достаточно бежать быстрее тебя.

Вот и тут также...

Во первых немного теории:

1. Прикладной уровень - HTTP и другие
2. Транспортный уровень: TCP/UDP
3. Сетевой уровень - IP
4. Канальный уровень: Ethernet/modem и т. п.

Принцип в том, что любой вышестоящий уровень о нижнем не может знать ничего...HTTP о TCP, TCP о IP, IP о Ethernet....

MAC адрес - дело канального уровня.

Так сложилось, что маршрутизаторы предлагают только IP маршрутизацию, тоесть, только первый, второй и третий пункт - IP[TCP[HTTP]].

Так что все окей

Кто хочет подучить теорию: http://www.zeiss.net.ru/docs/technol/tcpip/tcp00.htm[/img]

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

CKA3KA, а ты посмотри статистику, какой процент пользователей пользуется фаерфоксом в половину которых бар вставлен по умолчанию. А дальше начинается статистика. Что бы узнать предочтения миллионнного города с точностью в 2% с 95% достоверностью тебе достаточно опросить чуть больше 1000 человек...

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

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

Вот про адсенс роскошный пример: картинка. Видите рекламу по drug tests? Казалось бы - ну чего тут общего? А если я добавлю что показывают это именно мне, активно работающему с этим и этим? Там, правда и сам сайт не очень обычный и я отметился, но тенденция видна, думаю, более чем отчетливо.

Последний раз редактировалось: Mauser (28/03/06 в 22:21), всего редактировалось 1 раз