что значит bc.googleusercontent.com в tcpdump?
когда убунту просто включена без прог, пустая. вот это выдается:
IP pc8.33314 > 177.143.198.104.bc.googleusercontent.com.http: Flags S, seq 4135551235, win 111111,
options mss 3210,sackOK,TS val 5123103219 ecr 0,nop,wscale 7, length 0
как заблокировать и повлияет ли на что то?
Talnah ★
28.01.19 23:37:17 MSK
У Вас случаем, ничего не используется из Google Cloud Platform, ну там, облака и т.п.? На *.bc.googleusercontent.com висят Google Compute Engine.
funky ★
( 29.01.19 18:08:10 MSK )
Ответ на: комментарий от funky 29.01.19 18:08:10 MSK
нету ничего такого, может какие процессы туда заходят без ведома, но как бы ничего важного не запущено.
Talnah ★
( 29.01.19 21:02:49 MSK ) автор топика
как заблокировать и повлияет ли на что то?
Смотришь через netstat или ss какой процесс юзает порт 33314
annulen ★★★★★
( 29.01.19 21:09:06 MSK )
И что, нельзя посмотреть процесс или порт который это шлет?
vertexua ★★★★★
( 29.01.19 21:10:55 MSK )
Ответ на: комментарий от annulen 29.01.19 21:09:06 MSK
они редкие запросы, даже если в реальном времени смотреть то врятли успеешь разглядеть.
вобщем обращение идет к этому сайту connectivity-check.ubuntu.com гугл выдал что что то там пингется системой к этому сайту, что интересно в обход впн. попробую заблочить hosts ом
Talnah ★
( 30.01.19 18:10:27 MSK ) автор топика
xDShot ★★★★★
( 30.01.19 18:32:05 MSK )
Ответ на: комментарий от Talnah 30.01.19 18:10:27 MSK
они редкие запросы, даже если в реальном времени смотреть то врятли успеешь разглядеть.
Если это не UDP, то приложение будет использовать порт еще некоторое время, так что можно определить. Если это, конечно, не зловред, который специально заметает следы.
annulen ★★★★★
( 30.01.19 18:37:41 MSK )
Ответ на: комментарий от annulen 30.01.19 18:37:41 MSK
Как вариант, можно попробовать пологировать все нужные /proc вхождения с помощью inotify. Были какие-то готовые решения, но но и на shell пишется не сложно, главное выбрать — что логгировать и молиться богам inotify что эту часть procfs оно умеет мониторить.
pon4ik ★★★★★
( 30.01.19 18:56:04 MSK )
А, дык ТС в гугле забанили, а я уже начала придумывать годный велосипед.
Не пойму меня гугл ддосит или кто?
Время от времени начинается куча запросов на сайт вот с таких адресов, это конечно не все, там еще много 147.231.225.35.bc.googleusercontent.com 152.238.224.35.bc.googleusercontent.com 182.165.223.35.bc.googleusercontent.com 189.207.225.35.bc.googleusercontent.com 226.39.193.35.bc.googleusercontent.com 244.241.68.34.bc.googleusercontent.com 27.252.198.104.bc.googleusercontent.com 58.238.239.35.bc.googleusercontent.com 72.172.239.35.bc.googleusercontent.com 114.220.68.34.bc.googleusercontent.com 213.174.223.35.bc.googleusercontent.com 224.57.222.35.bc.googleusercontent.com 9.184.197.104.bc.googleusercontent.com Сервер не выдерживает, виснет. Я отключил сайт, поставил заглушку, По логам на загрушку приходило порядка 150 запросов в секунду, естественно сайт не выдержал бы такого. Там шли и обращения к /index.php?do=search, а значит идут запросы на поиск в бд, а это соответственно не просто открытие статики, отсюда и нагрузка. Вопрос 1 — это Гугл хочет так быстро обойти мой сайт или кто-то другой? Вопрос 2 — почему для этих запросов определяется имя хоста и записывается в лог, тогда как для других запросов пишется только IP адрес? В апаче установлен HostnameLookups Off Вот например полные 2 строчки лога 72.172.239.35.bc.googleusercontent.com — — [18/Mar/2020:02:00:15 +0200] «GET /soft/ HTTP/1.1» 200 72487 «-» «Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2623.110 Safari/537.36» 214.42.67.34.bc.googleusercontent.com — — [18/Mar/2020:02:00:15 +0200] «GET /webmaster/ HTTP/1.1» 200 75417 «-» «Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2623.110 Safari/537.36»
На сайте с 28.02.2020
19 марта 2020, 00:08
Это не гугл. Это ddos.
На сайте с 26.09.2013
19 марта 2020, 02:10
ддос через insert photo в гугле, нужно временно заблокировать наличие рефера googleusercontent.com в вебсервере. 
эта дрянь способна быстро делать get запросы и с ней даже клавиатурой можно нагрузить сайт. Пример зажал 9 и получил 20 запросов моментальных c разных IP. 
может гугл залимитирует эту дрянь, но пока нужно блочить этот рефер. Может в вашем случае и не этот конкретный способ, есть и другой.
★Сервис идентифицирует (https://socfishing.com/?utm_source=searchengines) посетителей вашего сайта и предоставляет их профили ВКонтакте, Телефон, Почта! Цены копеечные, работаем 8 лет.
На сайте с 02.03.2011
19 марта 2020, 06:08
Скорее всего вас парсят. Это не гугл, это облачный вдс хостинг гугла, дерьма оттуда идет немерянно. Потому можно банить всех bc.googleusercontent.com смело. Если у вас фриномов нету, бот проверяльщик фринома ходит оттуда же.
SocFishing:
эта дрянь способна быстро делать get запросы и с ней даже клавиатурой можно нагрузить сайт.
Пример зажал 9 и получил 20 запросов моментальных c разных IP.
в опере в адресной строке вводя также цифры — тоже самое фигачат запросы на сервер изза какойто предзагрузки или хз чего, недавно не мог понять какого фига 100500 от меня же запросов к серверу таких идет.
Антибот, антиспам, веб файрвол, защита от накрутки поведенческих: https://antibot.cloud/ru.html + партнерка, до 40$ с продажи.
На сайте с 05.01.2012
19 марта 2020, 09:25
SocFishing:
ддос через insert photo в гугле, нужно временно заблокировать наличие рефера googleusercontent.com в вебсервере.
А подскажите как это забанить всех bc.googleusercontent.com? Это ведь не рефер, а имя хоста. Разве можно прописать в htaccess deny from bc.googleusercontent.com ? Насколько я помню уже пробовал и оно не работает. Получается нужно находить обратно IP для этого хоста, это будет адрес 35.239.172.72 и уже писать deny from 35.239.172.72 Поэтому вопрос — как заблокировать всех с хостом bc.googleusercontent.com ?
На сайте с 25.11.2006
19 марта 2020, 09:41
foxi:
в опере в адресной строке вводя также цифры — тоже самое фигачат запросы на сервер изза какойто предзагрузки или хз чего, недавно не мог понять какого фига 100500 от меня же запросов к серверу таких идет.
h3/lh4/lh5/lh6.googleusercontent.com и картинки
В ночь на 6 сентября я оформлял одну из своих статей, а делаю это в гугльдоках. Что всегда под рукой, доки лежат в облаке и кушать не просят. Быстро, удобно, надежно. Но не в этот раз. Подготовил статью, она содержала текст + 3-4 картинки. Волшебная комбинация кнопок Ctrl+A, Ctrl+C, Ctrl+V сюда и готова статья на teletype.in. Хм, а куда делись картинки? Думаю, ладно, ночь уже. Спать надо, утром разберусь. Пока сохраню в черновики.
Утро принесло массу разочарований. Картинок не было. Мало того, на teletype.in исчезли картинки в старых статьях. На гугльдоках исчезли все картинки. Что же делать, что же делать?
Взял телефон и через мобильного оператора зашел на сайты. А все на месте, все картинки нормально отображаются. Неужели мой родной Ростелеком, что-то чудит. Никогда такого не было и вот опять.
Через личный кабинет rt.ru написал вопрос в чате. При этом я знаю, что Ростелеком отличный провайдер, но только до момента когда все нормально работает. А вот когда нет, все может пойти по разному. Я пробовал, я знаю. Довольно быстро мне ответила оператор поддержки, первым вопросом спросила у меня номер лицевого счета, дату и номер договора на обслуживание, ФИО на кого оформлен договор, адрес подключения, и места наиболее значимых родинок на моем теле. Они это прям обожают, сразу поставить клиента на место. Отмел все вопросы, что я из личного кабинета пишу, неужели недостаточно информации указанной в моем кабинете.
Следом шел вопрос как я оцениваю работу интернета, считаю ли, что указанная мной проблема влияет на работоспособность сети Интернет. Да, считаю, что Интернет у меня не работает, раз картинки не грузятся.
Был задан вопрос с подвохом «Как Вы сейчас оцениваете работоспособность сайтов Российских государственных органов?» А, я начинаю понимать куда клонит оператор. Все это не просто так. Я попросил расшифровать, что значит «сайты Российских государственных органов». Мне прислали список из Яндекса, Вконтакте, Ростелеком и Госуслуги. Ладно, посмеялись и хватит.
По итогу, у меня был запрошен официальный ответ техподдержки сайта гугльдок о том что проблема не на их стороне. То, что ссылка нормально открывается на другом провайдере никак не повлияло на ситуацию. Возможно и на это требовалось официальное подтверждение.
Я все-таки добился оформления заявки по моей проблеме, стоило надеяться, что следующий специалист техподдержки будет более адекватен.
На первый сеанс общения ушло 2 часа времени.
Пока ждал звонка специалиста, начал копать вопрос:
— открыл статью на teletype.in, открыл исходник страницы, поискал по тегу «img» и нашел ссылки на сайт googleusercontent.com, подсайты разные h3/lh4/lh5/lh6.
— взял одну ссылку на картинку, попробовал открыть — неа, не открывается.
— эту же ссылку бросил в телегу, чтобы открыть ее на телефоне. Хм, а телега нормально разворачивает ссылку. Показывает картинку.
— открыл ссылку на телефоне с мобильным оператором, вижу картинку.
Давай искать информацию по сайту googleusercontent.com:
- в реестре блокировок нет.
- https://ntc.party/t/lh3-googleusercontent-com/3157/5
- https://kod.ru/google-docs-fail-files-russia
В принципе, все уже понятно. Началась очередная битва с мельницами. Кто-то что-то блокирует, не понятно по какой причине. А узнают об этом рядовые пользователи и получают массу проблем.
Позвонил оператор, я выложил всю информацию, что удалось накопать. После чего оператор попросила меня все оформить письмом и отправить им. Передадут запрос админам и возможно скажут из-за чего это все.
Пришлось написать письмо с раскладом, большую часть работы уже сделал, что уж тут. На утро 7 сентября повторного звонка еще не было. Если будет официальный ответ, покажу в комментариях.
Итоги, какие же из всей этой истории можно подвести итоги:
- гугльдок или любые облачные технологии теперь небезопасны, их отрубить могут в любой момент. И каких-либо гарантий (держать все на Российских серверах) никто никому не даст. Особенно я бы переживал за юридические лица. Сервер создать в облаке — это похоже на пороховую бочку.
- интернет превращается в хаос, что более чем печально. Место, где нет никаких законов. И мало того, никто ничего не знает и ни за что не отвечает.
- стоит задуматься о двойном-тройном резервировании всей информации, размещаемой в интернете. Это и так было понятно, но сейчас можно в минуту потерять все. Да, инстаграм здесь был первым звонком. И сейчас народ уже более лоялен. Если там готовились к отключению, сообщали за две недели. То сегодня этим никто не утруждается. Ну не открылись картинки, да и пусть, ерунда какая.
- не исключаю момент, что я сгущаю краски.
Что делать? ВПН конечно. Но, это все ладно, я с этим разберусь и настрою. Что делать обычным рядовым пользователям — только повышать свою грамотность.
Тайная жизнь вашего смартфона
В данной статье рассматривается вопрос о том, какую информацию смартфон самостоятельно собирает и передает на серверы производителей.
Тайная жизнь вашего смартфона
Введение
Сбор телеметрических данных о пользователях и их действиях в сети и приложениях — плата за пользование «бесплатными» сервисами в Интернете. Пользователи расплачиваются своим вниманием и временем, проведёнными в данных сервисах и приложениях. Поэтому производители мобильных платформ, ИТ-компании, социальные сети заинтересованы в получении максимального объёма данных с устройств. Если сбор отдельных данных телеметрии не представляет никакой угрозы, то их совокупность может предоставить очень много информации о человеке, его интересах, семье, работе. В то же время постоянная связь устройств с инфраструктурой ИТ-гигантов создаёт потенциальную угрозу утечек конфиденциальной информации или изучения окружения при помощи микрофонов и камер смартфонов. В статье рассказывается об исследовании смартфона, которое продемонстрировало, что без вашего участия устройства ведут «насыщенную жизнь» – в фоновом режиме обмениваются информацией с инфраструктурой различных вендоров и сервисов.
Начальные условия и инструментарий
Исследовался смартфон Samsung SM-A505FN (Samsung Galaxy A50), со сброшенной к заводским установкам прошивкой и установленным пакетом российского программного обеспечения, без синхронизированных учётных записей. На момент сбора трафика смартфоном не пользовались (за исключением запуска камеры, календаря, сообщений, контактов и калькулятора). Большинство запросов происходило в фоновом режиме. Для исследования трафика использовались BurpSuite и Wireshark, а при работе с архивами base64, gzip и xxd.
Исследование трафика на ресурсы, связанные с Google
Для начала были проанализированы DNS-запросы.
- time.google.com
- mtalk.google.com
- www.google.com
- youtubei.google.com
- www.googleapis.com
- android.clients.google.com
- play-lh.googleapis.com
- play-lh.googleusercontent.com
Ясно, что это далеко не все, с кем смартфон хочет пообщаться и поделиться данными, но в данной статье делается упор на *google* и немного на *samsung* c *yandex*.
Сразу хотелось бы отметить, что хоть смартфон и запрашивает столько доменов, но не со всеми он обменивается конкретными данными. Некоторые сервисы нужны для проверки интернет соединения или для синхронизации времени.
Так смартфон проверяет интернет соединение:
Или синхронизирует время с time.android.com или *.pool.ntp.org:
Первым из *google* доменов в истории запросов BurpSuite можно увидеть crashlyticsreports-pa.googleapis.com.
В теле POST-запроса видны какие-то случайные нечитаемые символы. Если посмотреть внимательнее на запрос, то в заголовке Accept-Encoding можно заметить формат gzip, значит это архив и в нём с большой вероятностью что-то лежит.
Чтобы достать данные из архива аккуратно и не повредить их, лучшим решением будет выделить всё с одиннадцатой строки до конца и закодировать в base64.
Можно заметить в начале строки характерный набор байт для закодированного в base64 архива «.gz». Из него можно извлечь JSON-файл.
Сервис firebase собрал информацию об устройстве (номер модели, установленный на устройстве чипсет, модель, название прошивки), дальше уже представлена информация об ошибках в приложениях, а если конкретнее, то перечислены методы, в которых произошел сбой и уровень его критичности.
Следующим «гугловым» запросом был этот:
Тут запрос отправляет имя приложения, его версию, версию Android и идентификатор с параметром «usage_tracking_enabled=0». Видимо, это рекламный идентификатор, чтобы показывать рекламу в youtube.
Здесь смартфон проверяет на наличие и необходимость обновления системного WebView:
А вот еще один запрос с архивом только уже на play.googleapis.com:
Чтобы достать содержимое архива, нужно проделать действия, аналогичные тем, что выше.
Тут уже данные в другом формате. Также сначала идет информация об устройстве, а затем среди ASCII символов, можно найти отчетливое упоминание о некоторых приложениях.
Кроме чётких названий пакетов, в этих данных проглядывается что-то похожее на уникальный идентификатор, скорее всего это идентификаторы остальных приложений. После этого запроса идут ещё два, таких же по смыслу, но уже с другими значениями.
А в данном запросе смартфон получает рекламный идентификатор:
Значение параметра rdid — присвоенный устройству рекламный идентификатор.
На уже известный нам play.googleapis.com, только на другой эндпоинт (/log/batch), тоже уходят архивы, но уже не gzip, на этот раз для сжатия использовался brotli, что можно заметить по заголовку Content-Type:
Как обычно сбор данных начинается с основной информации об устройстве, но дальше фигурируют приложения с версиями и токенами.
Представлена информация о другой ошибке:
Тут представлена информация об ошибке в методе во время работы приложения:
А также передается информация с некоторыми глобальными значениями:
Все это отправляется пакетом «com.google.android.gms».
Исследование трафика на ресурсы Samsung и Яндекс
При запуске стандартного приложения камеры, смартфон сразу же отправил запрос на сервер Samsung с именем приложения, которое было открыто. Видимо, устройство решило проверить наличие обновлений.
Одним из следующих запросов, отправляется архив с неизвестным содержимым:
Данные из архива больше похожи на набор параметров.
А вот загрузилась страничка Samsung Galaxy Store, хотя никто об этом не просил.
Вскоре в трафике появился запрос к Яндексу. Кроме набора параметров в запросе также присутствует и архив.
В запросе на сервер Яндекса не указано, что используется для сжатия, и по первым байтам сообщения из тела запроса непонятно, с помощью чего данные были сжаты, так что внутрь заглянуть не получится. Но в другом запросе для сжатия используется gzip. Сжатые данные можно изучить.
В этом архиве — уже стандартная «шапка» и большое количество параметров. Параметры ниже на рисунке взяты из середины для примера.
Кроме единичных сервисов неявной принадлежности, большую активность осуществляли Facebook и Microsoft. Они были одними из первых, кто «почувствовал» наличие Интернета, и посчитали своим долгом незамедлительно уведомить все возможные серверы.
Рекомендации
Существует несколько вариантов частичного решения проблемы постоянной активности устройств в сети Интернет:
- использование доверенных устройств или прошивок;
- ограничение состава установленного на устройство программного обеспечения;
- отключение неиспользуемых приложений и сервисов;
- выдача разрешений приложениям на уровне операционной системы;
- проксирование и фильтрация всего трафика устройства.
Однако, такие меры доступны либо корпоративным пользователям, либо технически подкованным специалистам. Обычные же пользователи смартфонов вынуждены принимать риски использования «бесплатных» сервисов.