Opowiemy 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 rozpaczliwie potrzebuje czasu na rozwiązanie pilnych i ważnych spraw.
Jeden z partnerów, który trzyma w naszej chmurze kilka maszyn wirtualnych obsługiwanych przez siebie klientów, poinformował, że w godzinach od 9:10 do 9:20 kilka serwerów Windows działających na naszej ukraińskiej stronie nie akceptowało połączeń z usługą zdalnego dostępu, użytkownicy nie mogli zalogować się na swoje komputery, ale po kilku minutach wydawało się, że problem sam się rozwiązał.
Podnieśliśmy statystyki pracy kanałów komunikacyjnych, ale nie stwierdziliśmy żadnych wzrostów ani awarii ruchu. Przyjrzeliśmy się statystykom obciążenia zasobów obliczeniowych – żadnych anomalii. I co to było?
Potem inny partner, który hostuje w naszej chmurze około stu serwerów więcej, zgłosił te same problemy, które zauważyła część ich klientów i okazało się, że ogólnie serwery były dostępne (poprawnie odpowiadały na test ping i inne żądania), ale usługa zdalnego dostępu na tych serwerach albo akceptuje nowe połączenia, albo je odrzuca, a my mówiliśmy o serwerach w różnych lokalizacjach, do których ruch pochodzi z różnych kanałów transmisji danych.
Przyjrzyjmy się temu ruchowi. Na serwer dociera pakiet z żądaniem połączenia:
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 odbiera 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 wyraźnie nie są jakiekolwiek problemy w działaniu infrastruktury, ale coś innego. Może wszyscy użytkownicy mają problemy z licencjonowaniem zdalnego pulpitu? Być może do ich systemów przedostało się jakieś złośliwe oprogramowanie, które dzisiaj zostało aktywowane, podobnie jak kilka lat temu XData и Pietia?
Kiedy to porządkowaliśmy, otrzymaliśmy podobne prośby od kilku kolejnych klientów i partnerów.
Co właściwie dzieje się na tych maszynach?
W dziennikach zdarzeń pełno jest komunikatów o próbach odgadnięcia hasła:
Zazwyczaj takie próby są rejestrowane na wszystkich serwerach, na których standardowy port (3389) jest używany do usługi zdalnego dostępu i dostęp jest dozwolony z dowolnego miejsca. W Internecie pełno jest botów, które stale skanują wszystkie dostępne punkty połączenia i próbują odgadnąć hasło (dlatego zdecydowanie zalecamy stosowanie skomplikowanych haseł zamiast „123”). Intensywność tych prób tego dnia była jednak zbyt duża.
Co powinienem zrobić?
Zalecasz, aby klienci spędzali dużo czasu na zmianie ustawień, aby ogromna liczba użytkowników końcowych przełączyła się na inny port? To nie jest dobry pomysł, klienci nie będą zadowoleni. Czy zalecasz zezwolenie na dostęp tylko przez VPN? W pośpiechu i panice podnoszenie połączeń IPSec tym, którzy ich nie podnieśli - być może takie szczęście też nie uśmiecha się do klientów. Chociaż, muszę powiedzieć, w każdym razie jest to boska rzecz, zawsze zalecamy ukrycie serwera w sieci prywatnej i jesteśmy gotowi pomóc w ustawieniach, a dla tych, którzy lubią to rozgryźć samodzielnie, udostępniamy instrukcje do ustawienia IPSec/L2TP w naszej chmurze w trybie site-to-site lub road -warrior, a jeśli ktoś chce skonfigurować usługę VPN na własnym serwerze Windows, zawsze chętnie podzieli się wskazówkami, jak skonfigurować standardowy RAS lub OpenVPN. Ale niezależnie od tego, jak fajni byliśmy, nie był to najlepszy czas na prowadzenie prac edukacyjnych wśród klientów, ponieważ musieliśmy rozwiązać problem tak szybko, jak to możliwe, przy minimalnym stresie dla użytkowników.
Rozwiązanie, które wdrożyliśmy, było następujące. Przeprowadziliśmy analizę ruchu przechodzącego w taki sposób, aby monitorować wszystkie próby nawiązania połączenia TCP na porcie 3389 i wybierać z niego adresy, które w ciągu 150 sekund będą próbowały nawiązać połączenie z ponad 16 różnymi serwerami w naszej sieci - to są źródła ataku (Oczywiście, jeśli któryś z klientów lub partnerów ma realną potrzebę nawiązania połączeń z tyloma serwerami z tego samego źródła, zawsze można takie źródła dodać na „białą listę”. Co więcej, jeżeli w jednej sieci klasy C przez te 150 sekund zostaną zidentyfikowane więcej niż 32 adresy, to warto zablokować całą sieć.Blokada ustawiana jest na 3 dni i jeśli w tym czasie nie zostały przeprowadzone żadne ataki z danego źródła, źródło to jest automatycznie usuwane z „czarnej listy”. Lista zablokowanych źródeł jest aktualizowana co 300 sekund.
Lista ta dostępna jest pod tym adresem: , możesz na tej podstawie zbudować swoje listy ACL.
Jesteśmy gotowi udostępnić kod źródłowy takiego systemu, nie ma w nim nic przesadnie skomplikowanego (jest to kilka prostych skryptów skompilowanych w dosłownie kilka godzin na kolanie), a jednocześnie można go adaptować i wykorzystywać nie tylko w celu ochrony przed takim atakiem, ale także w celu wykrycia i zablokowania wszelkich prób skanowania sieci:
Dodatkowo dokonaliśmy zmian w ustawieniach systemu monitorowania, który teraz dokładniej monitoruje reakcję kontrolnej grupy serwerów wirtualnych w naszej chmurze na próbę nawiązania połączenia RDP: jeżeli reakcja nie nastąpi w ciągu po drugie, jest to powód, aby zwrócić na to uwagę.
Rozwiązanie okazało się całkiem skuteczne: nie ma już żadnych skarg zarówno ze strony klientów, partnerów, jak i systemu monitoringu. Do czarnej listy regularnie dodawane są nowe adresy i całe sieci, co oznacza, że atak trwa, ale nie wpływa już na pracę naszych klientów.
W liczbach jest bezpieczeństwo
Dzisiaj dowiedzieliśmy się, że inni operatorzy napotkali podobny problem. Ktoś nadal wierzy, że Microsoft dokonał pewnych zmian w kodzie usługi zdalnego dostępu (jeśli pamiętacie, pierwszego dnia podejrzewaliśmy to samo, ale bardzo szybko odrzuciliśmy tę wersję) i obiecuje zrobić wszystko, co w naszej mocy, aby szybko znaleźć rozwiązanie . Niektórzy po prostu ignorują problem i doradzają klientom, aby samodzielnie się zabezpieczyli (zmiana portu połączenia, ukrycie serwera w sieci prywatnej itp.). Już pierwszego dnia nie tylko rozwiązaliśmy ten problem, ale także stworzyliśmy podstawy pod bardziej globalny system wykrywania zagrożeń, który planujemy opracować.
Szczególne podziękowania należą się klientom i partnerom, którzy nie milczeli i nie siedzieli na brzegu rzeki, czekając, aż pewnego dnia spłyną po niej zwłoki wroga, ale od razu zwrócili naszą uwagę na problem, co dało nam możliwość wyeliminowania to tego samego dnia.
Źródło: www.habr.com