что значит 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 оно умеет мониторить.
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
Б локировка началась в минувшую пятницу, 6 апреля, следует из материалов реестра запрещенных сайтов, который ведет организация «Роскомсвобода». В реестре найдено более 10 тысяч заблокированных страниц с техническим доменом Google. При этом в официальном реестре запрещенных сайтов, который ведет Роскомнадзор, информация о блокировке googleusercontent.com отсутствует.
Google использует указанный домен для разных целей, в том числе для загрузки контента c Google CDN и хранения кешированных копий сайтов.
Роскомнадзор заблокировал технический домен Google из-за ограничения доступа к приложению Zello, сообщили «Интерфаксу» в пресс-службе Роскомнадзора. В ведомстве отметили, что включение сайта в «черный список» не повлияет на работу других сервисов.
В апреле 2017 года Роскомнадзор заблокировал Zello в России из-за того, что разработчик приложения отказался регистрироваться в реестре организаторов распространения информации.
Zello — это бесплатная программа, позволяющая использовать смартфон или планшет в качестве рации и выходить на связь в реальном времени.
Не пойму меня гугл ддосит или кто?
По логам на загрушку приходило порядка 150 запросов в секунду, естественно сайт не выдержал бы такого.
Там шли и обращения к /index.php?do=search, а значит идут запросы на поиск в бд, а это соответственно не просто открытие статики, отсюда и нагрузка.
Вопрос 1 — это Гугл хочет так быстро обойти мой сайт или кто-то другой?
Вопрос 2 — почему для этих запросов определяется имя хоста и записывается в лог, тогда как для других запросов пишется только IP адрес?