Бот-трафік після повідомлених ударів по дата-центрах Yandex
Якісне спостереження наших операторів, а не вимірювання. Після повідомлених ударів по дата-центрах Yandex ті, хто читає логи серверів DCXV, відчули, що трафік із деяких мереж ботоферм зменшився: менше автоматичних запитів, менше спроб підбору паролів, менше підозрілих HTTP POST-запитів. Ми не публікуємо кількостей, відсотків, графіків чи частоти запитів, бо не проводили контрольного порівняння. У статті: на що ми дивимося, як ці типи трафіку виглядають у логах, як захистити сервер незалежно від джерела та як перевірити твердження самостійно.
Що повідомлялося
На початку жовтня Reuters повідомило, що дрони вражали дата-центри Yandex два дні поспіль, а Yandex заявив, що на майданчику в Калузькій області вимкнено кілька модулів і частина сервісів може працювати з перебоями (повідомлення Reuters на The Star). Ми самі ці події не підтверджували й не маємо позиції щодо відповідальності. Стаття лише про трафік і гігієну серверів. Про ризики провайдера читайте в матеріалі хостинг у Yandex і в регіонах високого ризику.
На що ми дивилися
Оператори DCXV читають чотири джерела: логи вебсервера й WAF, логи автентифікації SSH, звернення до наших honeypot-шляхів (адрес, які реальний відвідувач не відкриває) та журнал HTTP-помилок. Вони стежать за цим у звичайній роботі, протягом часу. Не було фіксованого вікна до і після, базової лінії чи контрольної групи. Нижче лише враження людей, які знають, як ці логи виглядають зазвичай, і нічого сильнішого.
Як ці типи трафіку виглядають у логах
Важливі три шаблони. Усі приклади нижче ілюстративні: адреси взято з документаційних діапазонів, мітки часу умовні.
- Автоматичні запити - одні й ті самі шляхи в чіткому ритмі із загальним або порожнім user agent, часто пошук адмінок і старих скриптів.
- Підбір паролів - багато невдалих входів з різними іменами з одного джерела або одне ім'я з багатьох джерел.
- Підозрілі POST-запити - повторні POST на вхід, XML-RPC чи форми, зазвичай відповідь 200 або 401 без попереднього перегляду сторінки.
Приклади рядків (ілюстративні, не реальний трафік):
sshd[1234]: Failed password for invalid user admin from 203.0.113.7 port 51234 ssh2
sshd[1235]: Failed password for invalid user test from 203.0.113.7 port 51240 ssh2
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /wp-login.php HTTP/1.1" 200 5120 "-" "Mozilla/5.0"
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /xmlrpc.php HTTP/1.1" 200 420 "-" "Mozilla/5.0"
Чекліст захисту для будь-якого джерела
Жоден крок не залежить від того, звідки прийшов клієнт. Робіть їх у такому порядку й тримайте другий SSH-сеанс відкритим, поки змінюєте sshd, щоб помилка не відрізала вас від сервера. Більше про ключі в посібнику з SSH для нового хмарного сервера.
1. SSH лише за ключем. Вимкніть паролі та вхід root за паролем, а перед перезавантаженням перевірте конфігурацію:
# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3
LoginGraceTime 20
sudo sshd -t && sudo systemctl reload ssh
2. fail2ban для sshd. Баньте джерело після кількох помилок:
# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h
3. Ліміт запитів на входи в nginx. Сповільніть скрипт, не заважаючи людині:
# http {} context
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# server {} context
location = /login {
limit_req zone=login burst=5 nodelay;
limit_req_status 429;
proxy_pass http://127.0.0.1:3000;
}
- Правила WAF - блокуйте відомі шляхи-проби та завеликі чи некоректні тіла POST; почніть із режиму лише журналу, потім вмикайте блокування.
- Захист POST-ендпоїнтів - вимагайте CSRF-токен, обмежте розмір тіла, повертайте однакову помилку для хибного імені й хибного пароля.
- CAPTCHA або перевірка - показуйте її лише після кількох невдач, а не кожному відвідувачу.
- Моніторинг і сповіщення - сповіщайте про стрибок невдалих входів або 4xx на POST і щотижня переглядайте топ джерел.
Чому блокування країни саме по собі слабкий контроль
Геолокація IP - це припущення. VPN, проксі й орендовані сервери переносять бота в будь-яку країну, а ботнет із зламаних домашніх роутерів перебуває там, де ці роутери. Блок за країною також зупиняє реальних клієнтів, мандрівників і партнерів. Це може бути одним дешевим шаром серед інших, але він не замінить SSH за ключем, ліміти запитів і WAF, і швидко старіє, коли трафік переходить в інші мережі.
Як перевірити твердження на своїх серверах
Якщо вам потрібні докази, а не враження, задайте правила до того, як дивитеся на дані:
- Зафіксуйте вікна - оберіть однакові періоди до і після, з тими самими днями тижня, ще до відкриття логів.
- Однакові фільтри - ті самі файли логів, те саме правило підрахунку, ті самі бани й ліміти в обох періодах.
- Візьміть базову лінію - порівняйте з довшим спокійним періодом, бо кампанії приходять і зникають без зовнішніх подій.
- Групуйте за мережею, не за країною - рахуйте за мережею джерела й окремо відзначайте орендовані та проксі-діапазони.
- Записуйте власні зміни - нове правило фаєрвола чи перенесений сайт можуть виглядати як тренд.
Дві відправні команди, які слід виконати за кожне вікно з однаковими фільтрами:
sudo journalctl -u ssh --since "24 hours ago" --no-pager | \
grep "Failed password" | \
awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head
awk '$6 == "\"POST"' /var/log/nginx/access.log | \
awk '{print $7}' | sort | uniq -c | sort -rn | head
Обмеження нашого спостереження
Читайте це як гіпотезу одного оператора, а не як висновок:
- Кореляція не є причиною - дві події поруч у часі ще не пов'язані.
- Атрибуція недосконала - геолокація IP і дані ASN хибно позначають VPN, проксі, орендовану інфраструктуру та ботнети з інших країн.
- Трафік переміщується - боти могли перейти в інші мережі, тож менше з одного місця не означає менше загалом.
- Одна мережа - не весь інтернет - ми бачимо лише те, що доходить до наших серверів.
- Це може бути тимчасово, а причини можуть бути іншими: блокування деінде, сезонність, завершені кампанії чи наша власна фільтрація.
Наступні кроки
Почніть із SSH за ключем і ліміту на вхід: це кілька хвилин і допомагає проти будь-якого джерела. Якщо потрібен чистий сервер для цього чекліста, дивіться наші хмарні сервери у Празі та Ковільяні, а чекліст пробного періоду допоможе протестувати сервер як слід. Питання чи власні спостереження: sales@dcxv.com.
