Opowiemy wam interesującą historię o tym, jak "trzecie strony" próbowały zakłócić pracę naszych klientów i jak ten problem został rozwiązany.
Jak to wszystko się zaczęło
Wszystko zaczęło się w poranek 31 października, ostatniego dnia miesiąca, kiedy wielu pilnie musiało załatwić pilne i ważne sprawy.
Jeden z partnerów, który w naszym chmurze ma kilka maszyn wirtualnych swoich klientów, zgłosił, że od 9:10 do 9:20 kilka Windows-serwerów działających na naszej ukraińskiej platformie nie odbierało połączeń z usługą zdalnego dostępu, a użytkownicy nie mogli zalogować się na swoje pulpity, ale po kilku minutach problem wydawał się sam zniknąć.
Zebraliśmy statystyki pracy kanałów komunikacyjnych, ale nie znaleźliśmy ani wzrostów ruchu, ani spadków. Sprawdziliśmy statystyki obciążenia zasobów obliczeniowych – żadnych anomalii. I co to było?
Następnie inny partner, który hostuje w naszej chmurze jeszcze około setki serwerów, zgłosił takie same problemy, które zauważyli niektórzy z ich klientów. Okazało się, że serwery są ogólnie dostępne (prawidłowo odpowiadają na testy ping i inne zapytania), ale usługa zdalnego dostępu na tych serwerach to akceptuje nowe połączenia, to je odrzuca, przy czym mowa była o serwerach w różnych lokalizacjach, a ruch do nich pochodził z różnych kanałów transmisji danych.
A sprawdźmy ten ruch. Pakiet z żądaniem na ustanowienie połączenia dociera do serwera:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
Serwer otrzymuje ten pakiet, ale odrzuca połączenie:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
To oznacza, że problem z pewnością nie jest spowodowany żadnymi awariami w infrastrukturze, ale czymś innym. Może wszyscy użytkownicy mieli problemy z licencjonowaniem zdalnych pulpitów? Może do ich systemów wkradło się jakieś złośliwe oprogramowanie, które dziś się aktywowało, tak jak kilka lat temu było z XData i Petya?
Podczas gdy badaliśmy sprawę, otrzymaliśmy podobne zgłoszenia od kilku innych klientów i partnerów.
A co w ogóle dzieje się na tych maszynach?
W dziennikach rejestracji zdarzeń jest pełno wiadomości o próbach złamania hasła:
Zwykle takie próby są rejestrowane na wszystkich serwerach, gdzie dla usługi zdalnego dostępu używany jest standardowy port (3389) i gdzie dostęp jest dozwolony z wszędzie. W sieci Internet jest mnóstwo botów, które nieustannie skanują wszystkie dostępne punkty podłączenia i próbują odgadnąć hasło (dlatego zdecydowanie zalecamy używanie skomplikowanych haseł zamiast „123”). Niemniej jednak, intensywność tych prób tego dnia była nadmiernie wysoka.
Co robić?
Zalecać klientom poświęcenie ogromnej ilości czasu na zmianę ustawień u wielu końcowych użytkowników, aby przestawili się na inny port? To niezbyt dobry pomysł, klienci nie będą zadowoleni. Zalecać zezwolenie na dostęp tylko przez VPN? W pośpiechu i panice uruchamiać połączenia IPSec tam, gdzie nie zostały nawiązane – najprawdopodobniej i to nie uśmiecha się klientom. Chociaż trzeba przyznać, że to w każdym razie posługa boża, zawsze zalecamy ukrywanie serwera w prywatnej sieci i jesteśmy gotowi pomóc w konfiguracji, a dla tych, którzy wolą zajmować się tym samodzielnie, dzielimy się instrukcjami dotyczącymi konfiguracji IPSec/L2TP w naszej chmurze w trybie site-to-site lub road-warrior, a jeśli ktoś chce uruchomić usługę VPN na własnym serwerze Windows – zawsze chętnie dzielimy się wskazówkami na temat uruchomienia standardowego RAS lub OpenVPN. Ale, jakkolwiek byśmy nie byli świetni, to nie był najlepszy czas na prowadzenie działań edukacyjnych wśród klientów, bo trzeba było jak najszybciej rozwiązać problem z minimalnym wysiłkiem dla użytkowników.
Wdrożone przez nas rozwiązanie polegało na tym, że zorganizowaliśmy analizę ruchu, aby śledzić wszystkie próby nawiązania połączenia TCP na porcie 3389, wybierając adresy, które w ciągu 150 sekund próbują nawiązać połączenia z więcej niż 16 różnymi serwerami w naszej sieci – to są źródła ataku (oczywiście, jeśli któryś z naszych klientów lub partnerów ma rzeczywistą potrzebę nawiązywania połączeń z taką liczbą serwerów z jednego źródła, można zawsze dodać takie adresy do „białej listy”. W przypadku, gdy w jednej sieci klasy C w ciągu tych 150 sekund zidentyfikowano więcej niż 32 adresy, sensowne jest zablokowanie całej sieci. Blokada jest ustalana na 3 dni, a jeśli nie były prowadzone ataki z tego źródła w tym czasie, jest ono automatycznie usuwane z „czarnej listy”. Lista zablokowanych źródeł jest aktualizowana co 300 sekund.
Lista ta jest dostępna pod tym adresem: , możesz na jej podstawie budować własne ACL.
Jesteśmy gotowi podzielić się kodem źródłowym tego systemu, w którym nie ma nic skomplikowanego (to kilka prostych skryptów stworzonych dosłownie w kilka godzin „na kolanie”), a także może być dostosowywany i używany nie tylko do ochrony przed takim atakiem, ale także do wykrywania i blokowania wszelkich prób skanowania sieci:
Dodatkowo wprowadziliśmy pewne zmiany w ustawieniach systemu monitorowania, które teraz uważniej obserwuje reakcję kontrolnej grupy wirtualnych serwerów w naszej chmurze na próbę nawiązania połączenia RDP: jeśli reakcja nie nastąpi w ciągu sekundy – to sygnał, aby zwrócić uwagę.
Rozwiązanie okazało się wystarczająco skuteczne: nie ma już skarg ani ze strony klientów, ani partnerów, ani systemu monitorowania. Nowe adresy i całe sieci regularnie trafiają na „czarną listę”, co wskazuje, że atak trwa, ale już nie wpływa na działanie naszych klientów.
Jeden w polu to nie wojownik
Dziś dowiedzieliśmy się, że inni operatorzy również napotkali podobny problem. Niektórzy wciąż uważają, że to Microsoft wprowadził zmiany w kodzie usługi zdalnego dostępu (jeśli pamiętacie, w pierwszy dzień podejrzewaliśmy to samo, ale szybko odrzuciliśmy tę wersję) i zapewniają, że zrobią wszystko, aby jak najszybciej znaleźć rozwiązanie. Inni po prostu ignorują problem i radzą klientom, aby zabezpieczali się sami (zmieniając port połączenia, ukrywając serwer w prywatnej sieci itd.). A my już w pierwszy dzień nie tylko rozwiązaliśmy ten problem, ale także stworzyliśmy podstawy dla bardziej globalnego systemu wykrywania zagrożeń, który planujemy rozwijać.
Szczególne podziękowania dla klientów i partnerów, którzy nie milczeli i nie czekali na to, aż trup wroga przepłynie rzeką, lecz od razu zwrócili naszą uwagę na problem, co pozwoliło nam na jego rozwiązanie jeszcze tego samego dnia.
Źródło: habr.com
