Просматривая лог-файлы одного веб-сервера 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" ему не присущи!
Откуда растут ноги?
Не проводя дополнительных исследований первыми напрашиваются два варианта:
- Какой-то из сотрудников 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-пакете, например как-то так:
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-ом в ядро, - Аллилуйя, путь к серванту врагам отрезан, откидываемся на спинку кресла и тычем дули в монитор :))
Внешние ссыли схожей тематики
- Compute Engine - IaaS | Google Cloud Platform
- What does it mean when you get a referral from googleusercontent.com?
- How To Use Google As Proxy Server In 2 Different Ways
- Packet Capturing with TCPDUMP command in linux
