Opowiemy Wam ciekawą historię o tym, jak „osoby trzecie” próbowały ingerować w pracę naszych klientów i jak rozwiązano ten problem.
Jak to się wszystko zaczęło
Wszystko zaczęło się rankiem 31 października, ostatniego dnia miesiąca, kiedy wiele osób desperacko potrzebuje załatwić pilne i ważne sprawy.
Jeden z naszych partnerów, który hostuje kilka maszyn wirtualnych dla obsługiwanych przez siebie klientów w naszej chmurze, poinformował, że w godzinach 9:10-9:20 kilka WindowsSerwery działające w naszej ukraińskiej witrynie nie akceptowały połączeń z usługą zdalnego dostępu, a użytkownicy nie mogli uzyskać dostępu do swoich pulpitów. Jednak po kilku minutach problem zdawał się sam rozwiązać.
Przyjrzeliśmy się statystykom kanałów komunikacji, lecz nie stwierdziliśmy żadnych wzrostów ani spadków ruchu. Przyjrzeliśmy się statystykom obciążenia zasobów obliczeniowych – nie zaobserwowano żadnych anomalii. A co to było?
Następnie inny partner, który hostuje około stu serwerów w naszej chmurze, zgłosił te same problemy, które zauważyli niektórzy jego klienci i okazało się, że serwery były ogólnie dostępne (poprawnie odpowiadały na testy ping i inne żądania), ale usługa zdalnego dostępu na tych serwerach czasami akceptowała nowe połączenia, czasami je odrzucała, a dotyczyło to serwerów w różnych lokalizacjach, z ruchem przychodzącym z różnych kanałów transmisji danych.
Przyjrzyjmy się temu ruchowi. Pakiet z żądaniem 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
Oznacza to, że przyczyną problemu ewidentnie nie są żadne problemy z infrastrukturą, ale coś innego. Być może wszyscy użytkownicy mają problemy z licencjonowaniem pulpitu zdalnego? Być może jakieś złośliwe oprogramowanie zdążyło już przeniknąć do ich systemów i dziś zostało aktywowane, jak to miało miejsce kilka lat temu XData и Pietia?
Podczas gdy prowadziliśmy dochodzenie, otrzymaliśmy podobne prośby od kilku innych klientów i partnerów.
Co się w ogóle dzieje z tymi maszynami?
Dzienniki zdarzeń są pełne komunikatów o próbach odgadnięcia hasła:
Zazwyczaj takie próby są rejestrowane na wszystkich serwerach, na których używany jest standardowy port (3389) dla usługi zdalnego dostępu, a dostęp jest dozwolony z dowolnego miejsca. Internet jest pełen botów, które nieustannie skanują wszystkie dostępne punkty połączeń i próbują odgadnąć hasło (dlatego też zdecydowanie zalecamy używanie skomplikowanych haseł zamiast „123”). Jednak intensywność tych prób była tego dnia zbyt duża.
Co powinienem zrobić?
Zalecanie klientom poświęcania mnóstwa czasu na zmianę ustawień dla ogromnej liczby użytkowników końcowych tylko po to, by przełączyć się na inny port? To nie jest dobry pomysł; klienci nie będą zadowoleni. Zalecanie zezwalania na dostęp tylko przez VPN? Pośpiech w konfigurowaniu połączeń IPSec w panice, gdy nie mają ich uruchomionych – prawdopodobnie również nie byłby satysfakcjonujący dla klientów. Chociaż, trzeba przyznać, to i tak dobra rzecz. Zawsze zalecamy ukrycie serwera w sieci prywatnej i jesteśmy gotowi pomóc w konfiguracji. Dla tych, którzy wolą sami rozwiązywać problemy, udostępniamy instrukcje dotyczące konfiguracji IPSec/L2TP w naszej chmurze w trybie site-to-site lub w trybie „road-warrior”. A jeśli ktoś chce samodzielnie skonfigurować usługę VPN, Windows-serwer – zawsze gotowy podzielić się wskazówkami dotyczącymi podniesienia standardu RAS lub OpenVPNAle bez względu na to, jak bardzo byliśmy w dobrej formie, nie był to najlepszy moment na edukowanie klientów, ponieważ musieliśmy rozwiązać problem tak szybko, jak to możliwe, przy jak najmniejszym zakłóceniu pracy użytkowników.
Rozwiązanie, które wdrożyliśmy, wyglądało następująco. Przygotowaliśmy analizę ruchu przechodzącego w taki sposób, aby śledzić wszystkie próby nawiązania połączenia TCP na porcie 3389 i wybierać z niej adresy, które próbują nawiązać połączenia z więcej niż 150 różnymi serwerami w naszej sieci w ciągu 16 sekund - są to źródła ataku (oczywiście, jeśli któryś z klientów lub partnerów ma realną potrzebę nawiązania połączeń z taką liczbą serwerów z tego samego źródła, zawsze można dodać takie źródła do „białej listy”. Jednocześnie, jeśli w ciągu tych 150 sekund w jednej sieci klasy C zostanie wykrytych więcej niż 32 adresy, ma sens zablokować całą sieć. Blokada jest ustawiona na 3 dni, a jeśli w tym czasie nie było ataków z tego źródła, to źródło to jest automatycznie usuwane z „czarnej listy”. Lista zablokowanych źródeł jest aktualizowana co 300 sekund.
Lista ta jest dostępna pod następującym adresem: , możesz na jego podstawie zbudować swoje listy kontroli dostępu.
Jesteśmy gotowi udostępnić kod źródłowy takiego systemu, nie ma w nim nic super skomplikowanego (to kilka prostych skryptów, skompilowanych dosłownie w parę godzin „na kolanie”), a jednocześnie można go dostosować i wykorzystać 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 monitorującego, który teraz dokładniej monitoruje reakcję grupy kontrolnej serwerów wirtualnych w naszej chmurze na próbę nawiązania połączenia RDP: jeśli reakcja nie następuje w ciągu sekundy, należy zwrócić na to uwagę.
Rozwiązanie okazało się bardzo skuteczne: nie mamy już skarg od klientów i partnerów, a także od systemu monitorującego. Do czarnej listy regularnie dodawane są nowe adresy i całe sieci. Oznacza to, że atak nadal trwa, ale nie ma już wpływu na działalność naszych klientów.
W liczbach jest bezpieczeństwo
Dziś dowiedzieliśmy się, że inni operatorzy napotkali podobny problem. Niektórzy nadal sądzą, że Microsoft wprowadził pewne zmiany w kodzie usługi dostępu zdalnego (jeśli pamiętacie, podejrzewaliśmy to samo pierwszego dnia, ale bardzo szybko odrzuciliśmy tę wersję) i obiecują zrobić wszystko, co możliwe, aby znaleźć rozwiązanie tak szybko, jak to możliwe. Niektórzy po prostu ignorują problem i radzą klientom, aby się zabezpieczyli (zmienili port połączenia, ukryli serwer w prywatnej sieci itp.). Już pierwszego dnia nie tylko rozwiązaliśmy ten problem, ale także stworzyliśmy podstawy bardziej globalnego systemu wykrywania zagrożeń, który planujemy opracować w przyszłości.
Szczególne podziękowania należą się naszym klientom i partnerom, którzy nie milczeli i nie siedzieli na brzegu rzeki, czekając, aż pewnego dnia spłynie po niej ciało wroga, lecz natychmiast zwrócili naszą uwagę na problem, co dało nam możliwość jego rozwiązania jeszcze tego samego dnia.
Źródło: www.habr.com
