Google занимается взломом веб-серверов?
Просматривая лог-файлы одного веб-сервера Apache я обнаружил многочисленные записи о запрете доступа к многочисленным не существующим файлам и директориям сервера.
Все запросы имеющие явные признаки сканирования шли с ИП-адреса 35.192.177.169, которому назначен AS36903 (Autonomous System Numbers), и, который принадлежит компании Google:
Видим, что в одно и то же время, например «21/Dec/2017:17:42:16 +0200», за одну секунду с ИП-адреса 35.192.177.169 приходит по два-три GET запроса по разным не существующим адресам.
PTR запись ИП-адреса 35.192.177.169 указывала на домен «169.177.192.35.bc.googleusercontent.com», что также подтвердил и ДНС сервант самой гугли:
Прощупывание не существующих на веб-сервере адресов админ разделов:
- /wp-login.php
- /admin.php
- /bitrix/admin/index.php
- /admin/login.php
- /admin/
- /user/
Иначе как тупым и не санкционированным сканированием назвать нельзя ИМХО ссылок на них нет, а ни в файле robot.txt , а ни в одной из карт сайта (HTML/XML), и, физически их нет и никогда не было на веб-сервере.
К тому же, это явно не Googlebot, ИМХО реферер » Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 » и ИП-адрес » 35.192.177.169 » ему не присущи!
Откуда растут ноги?
Не проводя дополнительных исследований первыми напрашиваются два варианта:
- Какой-то из сотрудников Google, без ведома компании разумеется, использует вычислительные мощности Google, и, одновременно прикрываясь компанией, использует ПО для поиска и взлома веб-серверов для дальнейшего их использования с цель разумеется наживы;
- Аналог варианта №1, но уже с одобрения руководства Google, что мало вероятно, но может быть негласной политикой Google, например по заказу спец. служб и т.д. и т.п.
Однако, не будем спешить с выводами и копнём глубже дабы наковырять больше инфы об этом googleusercontent.com.
Поанонировав по разным поисковым системам с запросом «googleusercontent.com what is it» наткнулся на ветку в «Группы Google»: About bc.googleusercontent.com domain – Группы Google
Где, как и мы здесь, некий «Ken Walker» сетовал на получение своим сервером множественных запросов с адресов типа упомянутого выше *.bc.googleusercontent.com , на что ему «Faizan (Cloud Platform Support)» ответил дословно следующее:
Faizan (Cloud Platform Support)
09.08.16Hello Ken,
Each Google Compute Engine VM can have 1 external IP assigned. This IP can be static or ephemeral. As such, if you are receiving requests with different IPs (i.e. x.x.x.x.bc.googleusercontent.com) they will be from different users/location.
You can refer to this link [1] which has more information on networking of GCE instance.
I hope that helps.
[1] https://cloud.google.com/compute/docs/networking
Аллилуйя! Начала текста «Each Google Compute Engine VM . » было достаточно, чтобы понять, что на адресах *.bc.googleusercontent.com висят виртуальные машины выдающиеся клиентам в рамках «Google Compute Engine (GCE) is the Infrastructure as a Service (IaaS)»:
Google Compute Engine — Wikipedia
Google Compute Engine (GCE) is the Infrastructure as a Service (IaaS) component of Google Cloud Platform which is built on the global infrastructure that runs Google’s search engine, Gmail, YouTube and other services. Google Compute Engine enables users to launch virtual machines (VMs) on demand.
Всё ясно. Подробнее о том, что такое «Google Compute Engine» (IaaS) мы здесь жевать не будем, об этом можно почитать по приведённым выше ссылям (правда только на «вражеском»):
Теперь возникает вопрос: Что с этим *.bc.googleusercontent.com делать?
Если на своём сервере мы не предоставляем никакого API и т.п., то решение с проблемой скана идущего с *.bc.googleusercontent.com очевидно — однозначно в вечный БАН! Сделать это можно с помощью iptables .
Как заблокировать поддомены *.bc.googleusercontent.com с помощью iptables?
При помощи iptables заблокировать домен или все его поддомены можно попробовать используя модуль » string » выполнив строковый поиск в IP-пакете, например как-то так:
Этот фокус не проверен, а потому не факт, что будет работать и приведён лишь в качестве примера возможного решения, да и с точки зрения производительности строковый поиск в пакете является ущербным. Справку по модулю » string » можно получить командой » iptables -m string «:
Боле эффективным будет использование списка/набора (sets) блокируемых ИП-диапазонов (ip) загружаемых на уровень ядра с помощью проги » ipset «. Опять же, что такое » ipset » и как его употреблять здесь мы расписывать не будемибо есть то отдельная песня.
Где нарыть список ИП-диапазонов принадлежащих «Google Cloud Platform»?
Спросим, «тыхто 35.196.247.60»:
В ответе находим строку » Ref: . » и переходим по ссылке, где находим поле «Organization Google LLC (GOOGL-2)» и тыкаем по ссыле (GOOGL-2) перейдя по которой находим и тыкаем по See Also Related networks. — здесь и будут перечислены все IP-диапазоны и CIDR маски выделенные под GOOGLE-CLOUD.
Собираем список, заливаем ipset -ом в ядро, — Аллилуйя, путь к серванту врагам отрезан, откидываемся на спинку кресла и тычем дули в монитор :))
What is Googleusercontent?
For those who don’t know, googleusercontent is Google’s domain for serving user-supplied content without affecting the safety of Google’s own pages.
How do I clear Gmail image cache?
To use the Chrome menu, select the three-dot icon and choose Settings. Scroll down, select Privacy and Security, then choose Clear browsing data. Check the box for Cached images and files and then click the Clear data button.
How do I bypass Google proxy images?
Entering Image URL patterns To maintain a whitelist of internal URLs that’ll bypass proxy protection, enter the image URL patterns in the Image URL proxy whitelist setting. Matching URLs will bypass the image proxy. A pattern can contain the scheme, the domain, and a path.
Where is Googleusercontent stored?
That’s because all files that you upload to your Kerika pages are stored in your own Google account, so when you are viewing a Kerika project page, some of that content is coming from your Google Docs account. Recently, Google has started storing images in a new domain, called googleusercontent.com.
What is Googleusercontent COM proxy?
The Google Image Proxy is a caching proxy server. Every time an image link is included in email the request will go to the Google Image Proxy first to see if it has been cached, if so it should serve it up from the proxy or it will go fetch it and cache it there after.
Why won’t my email let me send pictures?
Answer: The most likely reason you can’t send the file is because it’s larger than the disk quota your ISP allows you to have. If you are attempting to send just a picture, and it won’t go through, that means the image file is probably very high-resolution and un-compressed. …
What happens if I clear data from Gmail?
Clearing data erases all the downloaded messages (but only from the phone). That is why I warned about the amount of data that would be downloaded again when you sync after clearing data. It will not affect any settings or other products or messages stored in your account.
Googleusercontent com что это
когда убунту просто включена без прог, пустая. вот это выдается:
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
как заблокировать и повлияет ли на что то?
У Вас случаем, ничего не используется из Google Cloud Platform, ну там, облака и т.п.? На *.bc.googleusercontent.com висят Google Compute Engine.
нету ничего такого, может какие процессы туда заходят без ведома, но как бы ничего важного не запущено.
как заблокировать и повлияет ли на что то?
Смотришь через netstat или ss какой процесс юзает порт 33314
И что, нельзя посмотреть процесс или порт который это шлет?
они редкие запросы, даже если в реальном времени смотреть то врятли успеешь разглядеть.
вобщем обращение идет к этому сайту connectivity-check.ubuntu.com гугл выдал что что то там пингется системой к этому сайту, что интересно в обход впн. попробую заблочить hosts ом
они редкие запросы, даже если в реальном времени смотреть то врятли успеешь разглядеть.
Если это не UDP, то приложение будет использовать порт еще некоторое время, так что можно определить. Если это, конечно, не зловред, который специально заметает следы.
Как вариант, можно попробовать пологировать все нужные /proc вхождения с помощью inotify. Были какие-то готовые решения, но но и на shell пишется не сложно, главное выбрать — что логгировать и молиться богам inotify что эту часть procfs оно умеет мониторить.
Google занимается взломом веб-серверов?
Просматривая лог-файлы одного веб-сервера Apache я обнаружил многочисленные записи о запрете доступа к многочисленным не существующим файлам и директориям сервера.
Все запросы имеющие явные признаки сканирования шли с ИП-адреса 35.192.177.169, которому назначен AS36903 (Autonomous System Numbers), и, который принадлежит компании Google:
Видим, что в одно и то же время, например «21/Dec/2017:17:42:16 +0200», за одну секунду с ИП-адреса 35.192.177.169 приходит по два-три GET запроса по разным не существующим адресам.
PTR запись ИП-адреса 35.192.177.169 указывала на домен «169.177.192.35.bc.googleusercontent.com», что также подтвердил и ДНС сервант самой гугли:
Прощупывание не существующих на веб-сервере адресов админ разделов:
- /wp-login.php
- /admin.php
- /bitrix/admin/index.php
- /admin/login.php
- /admin/
- /user/
Иначе как тупым и не санкционированным сканированием назвать нельзя ИМХО ссылок на них нет, а ни в файле robot.txt , а ни в одной из карт сайта (HTML/XML), и, физически их нет и никогда не было на веб-сервере.
К тому же, это явно не Googlebot, ИМХО реферер » Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 » и ИП-адрес » 35.192.177.169 » ему не присущи!
Откуда растут ноги?
Не проводя дополнительных исследований первыми напрашиваются два варианта:
- Какой-то из сотрудников Google, без ведома компании разумеется, использует вычислительные мощности Google, и, одновременно прикрываясь компанией, использует ПО для поиска и взлома веб-серверов для дальнейшего их использования с цель разумеется наживы;
- Аналог варианта №1, но уже с одобрения руководства Google, что мало вероятно, но может быть негласной политикой Google, например по заказу спец. служб и т.д. и т.п.
Однако, не будем спешить с выводами и копнём глубже дабы наковырять больше инфы об этом googleusercontent.com.
Поанонировав по разным поисковым системам с запросом «googleusercontent.com what is it» наткнулся на ветку в «Группы Google»: About bc.googleusercontent.com domain – Группы Google
Где, как и мы здесь, некий «Ken Walker» сетовал на получение своим сервером множественных запросов с адресов типа упомянутого выше *.bc.googleusercontent.com , на что ему «Faizan (Cloud Platform Support)» ответил дословно следующее:
Faizan (Cloud Platform Support)
09.08.16Hello Ken,
Each Google Compute Engine VM can have 1 external IP assigned. This IP can be static or ephemeral. As such, if you are receiving requests with different IPs (i.e. x.x.x.x.bc.googleusercontent.com) they will be from different users/location.
You can refer to this link [1] which has more information on networking of GCE instance.
I hope that helps.
[1] https://cloud.google.com/compute/docs/networking
Аллилуйя! Начала текста «Each Google Compute Engine VM . » было достаточно, чтобы понять, что на адресах *.bc.googleusercontent.com висят виртуальные машины выдающиеся клиентам в рамках «Google Compute Engine (GCE) is the Infrastructure as a Service (IaaS)»:
Google Compute Engine — Wikipedia
Google Compute Engine (GCE) is the Infrastructure as a Service (IaaS) component of Google Cloud Platform which is built on the global infrastructure that runs Google’s search engine, Gmail, YouTube and other services. Google Compute Engine enables users to launch virtual machines (VMs) on demand.
Всё ясно. Подробнее о том, что такое «Google Compute Engine» (IaaS) мы здесь жевать не будем, об этом можно почитать по приведённым выше ссылям (правда только на «вражеском»):
Теперь возникает вопрос: Что с этим *.bc.googleusercontent.com делать?
Если на своём сервере мы не предоставляем никакого API и т.п., то решение с проблемой скана идущего с *.bc.googleusercontent.com очевидно — однозначно в вечный БАН! Сделать это можно с помощью iptables .
Как заблокировать поддомены *.bc.googleusercontent.com с помощью iptables?
При помощи iptables заблокировать домен или все его поддомены можно попробовать используя модуль » string » выполнив строковый поиск в IP-пакете, например как-то так:
Этот фокус не проверен, а потому не факт, что будет работать и приведён лишь в качестве примера возможного решения, да и с точки зрения производительности строковый поиск в пакете является ущербным. Справку по модулю » string » можно получить командой » iptables -m string «:
Боле эффективным будет использование списка/набора (sets) блокируемых ИП-диапазонов (ip) загружаемых на уровень ядра с помощью проги » ipset «. Опять же, что такое » ipset » и как его употреблять здесь мы расписывать не будемибо есть то отдельная песня.
Где нарыть список ИП-диапазонов принадлежащих «Google Cloud Platform»?
Спросим, «тыхто 35.196.247.60»:
В ответе находим строку » Ref: . » и переходим по ссылке, где находим поле «Organization Google LLC (GOOGL-2)» и тыкаем по ссыле (GOOGL-2) перейдя по которой находим и тыкаем по See Also Related networks. — здесь и будут перечислены все IP-диапазоны и CIDR маски выделенные под GOOGLE-CLOUD.
Собираем список, заливаем ipset -ом в ядро, — Аллилуйя, путь к серванту врагам отрезан, откидываемся на спинку кресла и тычем дули в монитор :))
Как искать информацию в веб-кэше Google (Инструкция)
У самого значимого в мире поисковика «все ходы записаны» – информация, попавшая в поле зрения поисковых роботов Google, раз и навсегда сохраняется в виде сохранённой копии. Эта копия иногда очень нужна веб-журналистам – чтобы получить важные, но уже удалённые сведения. Но как получить к ним доступ? Как осуществлять поиск по кэшу Google?
Сохраненная копия
Если вы ищете что-то через Google, то найти сохраненную копию можно и через обычный интерфейс поисковика. Нажмите на зелёный треугольничек справа от ссылки на сайт, затем – на надпись «Сохраненная копия». Нажмите на неё – и посмотрите резервную копию имеющейся информации, которая попала в цепкие лапы “гугла”.
Поиск через адресную строку
Есть два способа:
Способ №1
Введите в адресную строку своего веб-браузера (Ghrome, Safari, Mozilla, Internet Explorer, Opera и т.д.) следующую информацию:
http://webcache.googleusercontent.com/search?q=cache:http://polezner.ru Вместо polezner.ru подставьте нужный вам сайт.
При желании можно посмотреть версию страницы без графики (только текст, своего рода режим Readability). Для этого достаточно нажать на «Текстовая версия» в правом верхнем углу экрана.
Способ №2
В браузере перед адресом страницы допишите слово «cache: ». В результате вместо самой страницы откроется её копия в кэше Google. Например:
Важно: Google в вашем браузере должен быть поиском по умолчанию. Если у вас не так – вводите «cache: » и адрес страницы в поисковой строке на google.com.
Вот и всё! Теперь вы можете искать в веб-кэше Google всё, что захотите – и когда захотите.
что значит 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
как заблокировать и повлияет ли на что то?
У Вас случаем, ничего не используется из Google Cloud Platform, ну там, облака и т.п.? На *.bc.googleusercontent.com висят Google Compute Engine.
нету ничего такого, может какие процессы туда заходят без ведома, но как бы ничего важного не запущено.
как заблокировать и повлияет ли на что то?
Смотришь через netstat или ss какой процесс юзает порт 33314
И что, нельзя посмотреть процесс или порт который это шлет?
они редкие запросы, даже если в реальном времени смотреть то врятли успеешь разглядеть.
вобщем обращение идет к этому сайту connectivity-check.ubuntu.com гугл выдал что что то там пингется системой к этому сайту, что интересно в обход впн. попробую заблочить hosts ом
они редкие запросы, даже если в реальном времени смотреть то врятли успеешь разглядеть.
Если это не UDP, то приложение будет использовать порт еще некоторое время, так что можно определить. Если это, конечно, не зловред, который специально заметает следы.
Как вариант, можно попробовать пологировать все нужные /proc вхождения с помощью inotify. Были какие-то готовые решения, но но и на shell пишется не сложно, главное выбрать — что логгировать и молиться богам inotify что эту часть procfs оно умеет мониторить.