Для нормальной работы сайта необходимо разрешить JavaScript, включая скрипты с доменов googlesyndication.com и doubleclick.net для отображения системы поиска по сайту и прочих сервисов Google.

Google занимается взломом веб-серверов?

google-hacker.jpg Просматривая лог-файлы одного веб-сервера Apache я обнаружил многочисленные записи о запрете доступа к многочисленным не существующим файлам и директориям сервера.

Все запросы имеющие явные признаки сканирования шли с ИП-адреса 35.192.177.169, которому назначен AS36903 (Autonomous System Numbers), и, который принадлежит компании Google:

35.192.177.169 [21/Dec/2017:17:42:15 +0200] "GET /wp-login.php HTTP/1.0" 403 "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" "Referer: -"
35.192.177.169 [21/Dec/2017:17:42:15 +0200] "GET /admin.php HTTP/1.0" 403 "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" "Referer: -"
35.192.177.169 [21/Dec/2017:17:42:16 +0200] "GET /bitrix/admin/index.php?lang=en HTTP/1.0" 403 "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" "Referer: -"
35.192.177.169 [21/Dec/2017:17:42:16 +0200] "GET /admin/login.php HTTP/1.0" 403 "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" "Referer: -"
35.192.177.169 [21/Dec/2017:17:42:16 +0200] "GET /admin/ HTTP/1.0" 403 "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" "Referer: -"
35.192.177.169 [21/Dec/2017:17:42:17 +0200] "GET /user/ HTTP/1.0" 403 "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" "Referer: -"

Видим, что в одно и то же время, например "21/Dec/2017:17:42:16 +0200", за одну секунду с ИП-адреса 35.192.177.169 приходит по два-три GET запроса по разным не существующим адресам.

PTR запись ИП-адреса 35.192.177.169 указывала на домен "169.177.192.35.bc.googleusercontent.com", что также подтвердил и ДНС сервант самой гугли:

nslookup 35.192.177.169 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
 
Non-authoritative answer:
169.177.192.35.in-addr.arpa name = 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" ему не присущи!

Откуда растут ноги?

Не проводя дополнительных исследований первыми напрашиваются два варианта:

  1. Какой-то из сотрудников Google, без ведома компании разумеется, использует вычислительные мощности Google, и, одновременно прикрываясь компанией, использует ПО для поиска и взлома веб-серверов для дальнейшего их использования с цель разумеется наживы;
  2. Аналог варианта №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.16

Hello 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-пакете, например как-то так:

iptables -A INPUT -m string --algo bm --string "blocked.domain" -j DROP

Этот фокус не проверен, а потому не факт, что будет работать и приведён лишь в качестве примера возможного решения, да и с точки зрения производительности строковый поиск в пакете является ущербным. Справку по модулю "string" можно получить командой "iptables -m string":

iptables -m string --help
...
string match options:
--from Offset to start searching from
--to Offset to stop searching
--algo Algorithm
--icase Ignore case (default: 0)
[!] --string string Match a string in a packet
[!] --hex-string string Match a hex string in a packet

Боле эффективным будет использование списка/набора (sets) блокируемых ИП-диапазонов (ip) загружаемых на уровень ядра с помощью проги "ipset". Опять же, что такое "ipset" и как его употреблять здесь мы расписывать не будемибо есть то отдельная песня.

Где нарыть список ИП-диапазонов принадлежащих "Google Cloud Platform"?

Спросим, "тыхто 35.196.247.60":

whois 35.196.247.60
...
NetRange: 35.192.0.0 - 35.207.255.255
CIDR: 35.192.0.0/12
NetName: GOOGL-2
NetHandle: NET-35-192-0-0-1
Parent: NET35 (NET-35-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Google LLC (GOOGL-2)
RegDate: 2017-03-21
Updated: 2017-03-21
Ref: https://whois.arin.net/rest/net/NET-35-192-0-0-1

В ответе находим строку "Ref: ..." и переходим по ссылке, где находим поле "Organization Google LLC (GOOGL-2)" и тыкаем по ссыле (GOOGL-2) перейдя по которой находим и тыкаем по See Also Related networks. - здесь и будут перечислены все IP-диапазоны и CIDR маски выделенные под GOOGLE-CLOUD

Собираем список, заливаем ipset-ом в ядро, - Аллилуйя, путь к серванту врагам отрезан, откидываемся на спинку кресла и тычем дули в монитор :))

Внешние ссыли схожей тематики

Рекомендуемый контент



Комментарии   

afotof
0 #3 afotof 16.10.2018 22:21
я вот анализирую ссылки на свой сайт и замечаю что некоторые говносайты плодят ссылки тоже на "не существующих на веб-сервере адресов админ разделов"
Цитировать
Олег Головский
0 #2 Олег Головский 18.02.2018 15:53
Цитирую Геннадий:
... статья родной речью...

тут бешенно плюсую! :bayan:
Цитирую Геннадий:
...Хотел спросить, а есть ли у такого метода с блокировкой диапазонов IP побочный эффект?
Например, допускаю, что из того же диапазона может какой-то из поисковых ботов Гугла заходить, или какое-то обращение от одного из сервисов для веб-мастеров.
Не повлияет ли такая блокировка потом пагубно на ранжирование или ещё что-то?

Нет боков у метода, читать выше "Откуда растут ноги?" - там всё сказано! "Google Compute Engine VM" диапазоны типа Код:*.bc.googleusercontent.com выделяются исключительно под потреБляАцкие нужды юзверей и "гуглоботы" (включая сервисы для мастеров) оттуда никак не ходят. :trepanat:
Цитировать
Геннадий
0 #1 Геннадий 18.02.2018 14:47
Спасибо! Кстати, в такой последовательно сти и шёл :) Сначала статья в Группах Гугл, затем Ваша статья родной речью.
Хотел спросить, а есть ли у такого метода с блокировкой диапазонов IP побочный эффект?
Например, допускаю, что из того же диапазона может какой-то из поисковых ботов Гугла заходить, или какое-то обращение от одного из сервисов для веб-мастеров.
Не повлияет ли такая блокировка потом пагубно на ранжирование или ещё что-то?
Цитировать

Добавить комментарий


Защитный код
Обновить

Рейтинг@Mail.ru 2 megabytes