Ruch botów po zgłoszonych atakach na centra danych Yandex
Jakościowa obserwacja naszych operatorów, nie pomiar. Po zgłoszonych atakach na centra danych Yandex osoby czytające logi serwerów DCXV odniosły wrażenie, że ruch z niektórych sieci farm botów osłabł: mniej zautomatyzowanych żądań, mniej prób brute force, mniej podejrzanych żądań HTTP POST. Nie publikujemy liczb, procentów, wykresów ani częstotliwości, bo nie przeprowadziliśmy kontrolowanego porównania. Artykuł pokazuje, na co patrzymy, jak te rodzaje ruchu wyglądają w logach, jak zabezpieczyć serwer niezależnie od źródła i jak samodzielnie sprawdzić tę tezę.
Co zgłoszono
Na początku października Reuters poinformował, że drony uderzyły w centra danych Yandex dwa dni z rzędu, a Yandex przekazał, że kilka modułów w jego lokalizacji w obwodzie kałuskim wyłączono i że część usług może działać z zakłóceniami (doniesienie Reutersa w The Star). Sami tych zdarzeń nie potwierdzaliśmy i nie zajmujemy stanowiska w sprawie odpowiedzialności. Artykuł dotyczy wyłącznie ruchu i higieny serwerów. O ryzyku po stronie dostawcy czytaj w hosting w Yandex i w regionach wysokiego ryzyka.
Na co patrzyliśmy
Operatorzy DCXV czytają cztery źródła: logi serwera WWW i WAF, logi uwierzytelniania SSH, trafienia w nasze ścieżki honeypot (adresy, których żaden prawdziwy odwiedzający nie otwiera) oraz dziennik błędów HTTP. Obserwują je w czasie, w zwykłej pracy. Nie było stałego okna przed i po, punktu odniesienia ani grupy kontrolnej. Poniżej jest wrażenie ludzi, którzy wiedzą, jak zwykle wyglądają te logi, nic mocniejszego.
Jak te rodzaje ruchu wyglądają w logach
Liczą się trzy wzorce. Wszystkie przykłady są poglądowe: adresy pochodzą z zakresów dokumentacyjnych, a znaczniki czasu to wypełniacze.
- Żądania automatyczne - te same ścieżki w ciasnym rytmie z ogólnym lub pustym user agentem, często szukanie paneli administracyjnych i starych skryptów.
- Próby brute force - wiele nieudanych logowań z różnymi nazwami użytkownika z jednego źródła albo jedna nazwa z wielu źródeł.
- Podejrzane żądania POST - powtarzane POST na logowanie, XML-RPC lub formularze, zwykle z odpowiedzią 200 lub 401 i bez wcześniejszego odczytu strony.
Przykładowe linie (poglądowe, nie prawdziwy ruch):
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"
Lista kontrolna zabezpieczeń działająca dla każdego źródła
Żaden krok nie zależy od tego, skąd pochodzi klient. Wykonuj je w tej kolejności i trzymaj otwartą drugą sesję SSH podczas zmian w sshd, aby literówka cię nie zablokowała. Więcej o kluczach w naszym poradniku SSH dla nowego serwera cloud.
1. SSH tylko z kluczem. Wyłącz hasła i logowanie roota hasłem, a konfigurację sprawdź przed przeładowaniem:
# /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 dla sshd. Blokuj źródło po kilku niepowodzeniach:
# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h
3. Limit żądań na endpointach logowania w nginx. Spowolnij skrypt, nie przeszkadzając człowiekowi:
# 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;
}
- Reguły WAF - blokuj znane ścieżki sond oraz zbyt duże lub wadliwe treści POST; zacznij w trybie samego logowania, potem egzekwuj.
- Ochrona endpointów POST - wymagaj tokenu CSRF, ogranicz rozmiar treści, zwracaj ten sam błąd dla złego użytkownika i złego hasła.
- CAPTCHA lub wyzwanie - pokazuj je dopiero po kilku porażkach, nie każdemu odwiedzającemu.
- Monitoring i alerty - alarmuj przy skoku nieudanych logowań lub 4xx na POST i co tydzień przeglądaj główne źródła.
Dlaczego blokada kraju sama w sobie to słaba kontrola
Geolokalizacja IP to przypuszczenie. VPN-y, proxy i wynajęte serwery przenoszą bota do dowolnego kraju, a botnet z przejętych domowych routerów jest tam, gdzie te routery. Blokada kraju zatrzymuje też prawdziwych klientów, podróżnych i partnerów. Może być tanią warstwą wśród innych, ale nie zastąpi SSH z kluczem, limitów żądań ani WAF i szybko się starzeje, gdy ruch przechodzi do innych sieci.
Jak sprawdzić tezę na własnych serwerach
Jeśli chcesz dowodów, a nie wrażeń, ustal zasady, zanim spojrzysz na dane:
- Ustal okna - wybierz równe okresy przed i po, z tymi samymi dniami tygodnia, zanim otworzysz jakikolwiek log.
- Identyczne filtry - te same pliki logów, ta sama reguła zliczania, te same blokady i limity w obu okresach.
- Zbierz punkt odniesienia - porównaj z dłuższym spokojnym okresem, bo kampanie przychodzą i znikają bez zewnętrznego zdarzenia.
- Grupuj według sieci, nie kraju - licz według sieci źródłowej i osobno notuj zakresy wynajmowane lub proxy.
- Zapisuj własne zmiany - nowa reguła zapory albo przeniesiona strona może wyglądać jak trend.
Dwa punkty wyjścia do uruchomienia w każdym oknie z tymi samymi filtrami:
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
Ograniczenia naszej obserwacji
Traktuj to jako hipotezę jednego operatora, nie ustalenie:
- Korelacja to nie przyczynowość - dwa zdarzenia blisko w czasie niekoniecznie są powiązane.
- Atrybucja jest niedoskonała - geolokalizacja IP i dane ASN mylą VPN-y, proxy, wynajętą infrastrukturę i botnety z innych krajów.
- Ruch się przesuwa - boty mogły przejść do innych sieci, więc mniej z jednego miejsca nie znaczy mniej w sumie.
- Jedna sieć to nie cały internet - widzimy tylko to, co dociera do naszych serwerów.
- To może być tymczasowe, a przyczyny mogą być inne: blokady gdzie indziej, sezonowość, zakończone kampanie albo nasze własne filtrowanie.
Kolejne kroki
Zacznij od SSH tylko z kluczem i limitu na logowanie: to minuty pracy i pomaga przeciw każdemu źródłu. Jeśli potrzebujesz czystego serwera do tej listy, zobacz nasze serwery cloud w Pradze i Covilhã, a listę kontrolną okresu próbnego pomoże dobrze go przetestować. Pytania lub własne obserwacje: sales@dcxv.com.
