16 вересня 2026 року я помітила у власній аналітиці ICanUp незвичний сигнал: звичайні перегляди різко зросли, а дедупліковані перегляди не повторили цей стрибок.
Спочатку це могло виглядати як раптовий приріст трафіку. Але така різниця між двома метриками більше схожа на великий обсяг повторюваних автоматизованих запитів.
Перевірка журналів доступу Nginx привела до конкретного джерела. Один IP за день зробив приблизно 3300 HTTP-запитів, називав себе Googlebot і масово шукав .env, облікові дані, ключі хмарних сервісів, конфігурації WordPress та інші потенційні секрети.
Перший сигнал був у власній аналітиці
У розподілі ботів найбільшу частку займав Other bot. При цьому кількість дедуплікованих переглядів була набагато меншою за загальну кількість.
Географічний розподіл теж різко змістився в одну країну. Це ще не доводило проблему, але добре підсилювало сигнал, що трафік нетиповий.
Ці числа не повинні збігатися з кількістю запитів у Nginx. Журнал доступу бачить кожен HTTP-запит, включно з перевірками неіснуючих шляхів і перенаправленнями, тоді як аналітика рахує лише перегляди, які проходять її власний контракт обліку.
Сигнал | Значення |
|---|---|
Other bot | 831 перегляд, близько 98% трафіку ботів |
AI crawler | 9 переглядів |
Googlebot | 6 переглядів |
Germany | 809 переглядів, близько 96% визначеного географічного трафіку |
Дедупліковані Other bot | приблизно 90 переглядів |
Я почала з User-Agent і частоти запитів
Першим кроком я подивилася, які IP та User-Agent повторювалися у журналі Nginx за цей день.
sudo grep '16/Sep/2026' /var/log/nginx/access.log \ | awk -F'"' '{print $1 " | " $6}' \ | sort \ | uniq -c \ | sort -nr \ | head -30600 ... | Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)584 ... | Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)550 ... | Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)439 ... | Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)352 ... | Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)У журналі повторювався IP 94.154.46.243 з User-Agent, який представлявся Googlebot.
Сам по собі User-Agent нічого не доводить. Це звичайний текстовий заголовок, який HTTP-клієнт може встановити самостійно.
Далі я перевірила найактивніші IP
sudo grep '16/Sep/2026' /var/log/nginx/access.log \ | awk '{print $1}' \ | sort \ | uniq -c \ | sort -nr \ | head -203300 94.154.46.2432473 34.125.80.252431 91.196.55.136277 34.18.23.254277 34.17.35.131228 213.209.159.175218 213.209.159.133Один IP дав приблизно 3300 запитів за день. Частина з них ішла дуже щільними пачками, тому це вже було схоже не на звичайний пошуковий обхід, а на автоматизоване перебирання шляхів.
Що саме шукав цей клієнт
sudo grep '16/Sep/2026' /var/log/nginx/access.log \ | grep '^94\.154\.46\.243 ' \ | awk -F'"' '{print $2}' \ | sort \ | uniq -c \ | sort -nr \ | head -50GET /.env HTTP/1.1GET /~/.composer/auth.json HTTP/1.1GET /zipkin/.env HTTP/1.1GET /zabbix/.env HTTP/1.1GET /www/.env.production HTTP/1.1GET /www/.env.local HTTP/1.1GET /wp/wp-config.php HTTP/1.1GET /wp-config.php HTTP/1.1GET /wp-config.php.bak HTTP/1.1GET /wp-debug.log HTTP/1.1GET /wp-content/uploads/.env HTTP/1.1GET /web/laravel/.env HTTP/1.1GET /.env.aws HTTP/1.1GET /.env.redis HTTP/1.1GET /.env.stripe HTTP/1.1GET /.env.paypal HTTP/1.1Найважливіше було перевірити коди HTTP-відповідей
sudo grep '16/Sep/2026' /var/log/nginx/access.log \ | grep '^94\.154\.46\.243 ' \ | awk -F'"' '{print $3}' \ | awk '{print $1}' \ | sort \ | uniq -c \ | sort -nr3286 30114 400Цей результат був принципово важливим. 301 не означає, що сканер отримав файл.
Запити потрапляли на HTTP-адресу, а Nginx перенаправляв їх на HTTPS. Тому наступним кроком було перевірити саме перенаправлення і поведінку вже на HTTPS.
Я перевірила перенаправлення і HTTPS-серверні блоки у Nginx
sudo nginx -T 2>/dev/null \ | grep -nE 'server_name|listen .*443|access_log|return 30[1278]|rewrite'Конфігурація підтвердила окремі HTTP-серверні блоки, перенаправлення HTTP на HTTPS і окремі HTTPS-віртуальні хости для production та dev.
return 301 https://icanup.com.ua$request_uri; # devreturn 301 https://$host$request_uri;Потім я перевірила всі доступні журнали доступу Nginx
sudo grep -H '94\.154\.46\.243' /var/log/nginx/*access*.log \ | tail -100У доступних журналах я бачила ті самі HTTP-запити з 301, наприклад до /.env.stripe, /.env.paypal, /.env.aws, /.env.redis і /credentials.txt.
Ознак 200 OK для цих секретних шляхів у дослідженому трафіку не було.
Фінальна перевірка: що реально повертає HTTPS
curl -I https://icanup.com.ua/.envcurl -I https://dev.icanup.com.ua/.envcurl -I https://icanup.com.ua/wp-config.php.bakcurl -I https://icanup.com.ua/.git/configcurl -I https://icanup.com.ua/composer.jsonШлях | Відповідь |
|---|---|
https://icanup.com.ua/.env |
|
https://dev.icanup.com.ua/.env |
|
/wp-config.php.bak |
|
/.git/config |
|
/composer.json |
|
Отриманий запит і успішний злам - не одне й те саме
Публічні сервери постійно сканують. Сам факт запиту до /.env ще не означає успішний злам.
Правильне питання інше: що сервер реально повернув у відповідь?
Для мене розслідування не завершилося на фразі "хтось шукав .env". Я перевірила коди відповідей, перенаправлення, HTTPS, правила Nginx і конкретні критичні шляхи.
Спостереження | Що воно означає |
|---|---|
Запит до | Спроба отримати файл |
| Перенаправлення, а не вміст файла |
| Доступ заборонений |
| Ресурс не доступний за цим шляхом |
| Потребує негайного розслідування |
Мій практичний алгоритм перевірки підозрілого трафіку ботів
- Порівняти звичайні та дедупліковані перегляди, якщо власна аналітика вже показує аномалію.
- Знайти найактивніші IP у журналі Nginx.
- Перевірити User-Agent, але не вважати його доказом справжності клієнта.
- Подивитися конкретні запитані шляхи для підозрілого IP.
- Порахувати коди HTTP-відповідей.
- Перевірити перенаправлення і HTTPS-серверні блоки.
- Переглянути всі доступні журнали доступу Nginx.
- Перевірити критичні файли напряму через HTTPS.
- Шукати
200на небезпечних шляхах, а не робити висновок лише з кількості запитів. - Окремо перевірити, що dotfiles, службові файли Git та конфігураційні файли недоступні публічно.
Цей випадок також пояснив різницю між звичайними та дедуплікованими переглядами
Саме графік привів мене до журналів Nginx.
Звичайні перегляди різко зросли, але дедупліковані залишилися значно нижчими. Це природний сигнал для великого обсягу повторюваного автоматизованого трафіку.
Тому для технічного сайту мені корисно бачити не одну загальну цифру, а окремо людей, відомих пошукових роботів, AI crawler, невідомих ботів, звичайні перегляди та дедупліковані перегляди.
Метрика | Що вона допомогла побачити |
|---|---|
Звичайні перегляди | Реальний обсяг усіх зарахованих переглядів |
Дедупліковані перегляди | Наскільки цей обсяг складається з повторів |
Категорія бота | Хто створює автоматизований трафік |
Країна | Чи є різка географічна концентрація |
server_tokens off - це посилення захисту, а не виправлення інциденту
Під час перевірки я також побачила, що сервер віддає точну версію Nginx у заголовках відповіді:
server: nginx/*.**.* (Ubuntu)
Це не причина сканування і не доказ уразливості. Але точну версію можна не показувати без потреби.
server_tokens off;sudo nginx -tsudo systemctl reload nginxЯких висновків я не роблю з цього інциденту
- Не називаю цей випадок успішним зламом.
- Не вважаю Googlebot User-Agent доказом, що запит справді прийшов від Google.
- Не вважаю
301доказом доступу до файла. - Не роблю висновок про витік лише через тисячі запитів до
.env. - Не трактую
server_tokens offяк виправлення вразливості для трафіку сканерів. - Не блокую весь трафік із країни лише через один підозрілий IP.
- Не покладаюся тільки на одну метрику аналітики без перевірки журналів сервера.
Публічне сканування сервера є звичайним явищем. Важливо не те, що сканер спробував запросити, а те, чи зміг він отримати щось корисне.
Висновок
16 вересня різкий розрив між звичайними та дедуплікованими переглядами в ICanUp виявився першим сигналом великого обсягу автоматизованого сканування.
Журнали Nginx показали клієнта, який називав себе Googlebot, зробив приблизно 3300 запитів за день і масово перебрав шляхи до .env, облікових даних, ключів хмарних сервісів та конфігурацій.
Але самі запити не були доказом успішного зламу. Переважна відповідь була 301 на HTTP, а перевірені критичні HTTPS-шляхи повертали 403 або 404. У дослідженому трафіку я не знайшла ознак успішного отримання секретних файлів.
Для мене головний урок простий: при підозрілому трафіку ботів треба йти від графіка до журналів, від User-Agent до поведінки, а від запитаного шляху до фактичної HTTP-відповіді.
