Jak zabezpieczyć publiczny serwer pulpitu zdalnego?

16

Rozglądam się za potrzebą udostępnienia mojego serwera usług pulpitu zdalnego (usług terminalowych), aby uzyskać do niego dostęp spoza naszej sieci. W tej chwili można uzyskać do niego dostęp tylko z naszej sieci.

Wiem, że łatwo jest otworzyć zaporę i przekierować port.

Jak jednak zabezpieczyć samą maszynę i jakie są najlepsze praktyki w tym zakresie? Obawiam się, że hakerzy mogą pracować przy włamaniu się do niego.

Wszelkie wytyczne / zalecenia dotyczące najlepszych praktyk będą mile widziane.


Edytować:

Pytanie o znaleziony produkt:

Filtruj przychodzące połączenia RDP według adresu IP, adresu MAC, nazwy komputera i innych

Czy ktoś może komentować bezpieczeństwo tego? Wygląda na to, że mógłbym go również użyć do ograniczenia dostępu według nazwy komputera / komputera Mac? Ktoś inny go wykorzystał?

me2011
źródło
1
Myślę, że pytasz nie tylko o to, jak zabezpieczyć to urządzenie i wszelkie połączenia RDP z nim, ale także o to, jak zmniejszyć ryzyko dla reszty sieci, gdyby zostało to zagrożone. Czy to prawda?
dunxd
Tak, poprawnie, ponieważ jesteśmy mali, istnieje tylko jeden serwer RDP i potrzebuje on pełnego dostępu do pulpitu / zasobów sieciowych dla użytkowników wewnętrznych.
me2011

Odpowiedzi:

14

Może to być coś więcej niż chcesz, ale oto jak używamy RDP dla zdalnych użytkowników, którzy nie korzystają z VPN.

Niedawno zaczęliśmy korzystać z RD Gateway Manager z usługami pulpitu zdalnego, rolą w systemie Windows 2008. Przygotowaliśmy go do przejścia przez nasz serwer TMG i bezpośrednio do komputera użytkownika. Wykorzystuje NLA, jak wspomniano powyżej. Użytkownik łączący się musi być członkiem właściwej grupy AD i członkiem właściwej grupy lokalnej, aby uzyskać dostęp. W zależności od tego, jak chcesz to skonfigurować, możesz połączyć się za pośrednictwem strony internetowej, która po prostu otwiera mstsc i wprowadza ustawienie proxy dla bramy usług pulpitu zdalnego, lub możesz ręcznie skonfigurować ustawienia na swoim komputerze, aby za każdym razem, gdy je otworzysz, spróbował przejść za pośrednictwem tego proxy. Do tej pory działał całkiem dobrze i wydaje się bezpieczny.

Don
źródło
3
+1 za to. Używam również RD Gateway z wielkim sukcesem, a do działania wystarczy tylko udostępnić port 443 w Internecie. RD Gateway nie był podatny na błąd MS12-020 sprzed kilku tygodni, który zagrażał RDP.
Ryan Ries
+1 jest również dużo mniej botów atakujących bramy RD niż bezpośrednich RDP.
Grant
8

Jak pokazała nam najnowsza historia , ujawnienie protokołu wiąże się z nieodłącznym ryzykiem. Istnieje jednak kilka kroków, które można podjąć w celu ochrony systemu:

  • Wymuszaj uwierzytelnianie na poziomie sieci.
  • Wymuszaj szyfrowanie połączenia.
  • Ogranicz użytkowników, którzy mogą logować się za pomocą usług terminalowych, do absolutnego minimum i nie zezwalaj na konta „specjalne”, takie jak domyślne Administratorkonto domeny lub idealnie na inne konta o wysokich uprawnieniach.
  • Upewnij się, że hasła są silne na kontach, które mogą się logować. Zależy od liczby użytkowników i tego, jak obecnie wyglądają Twoje zasady, ale odrzucanie skrótów i próba ich złamania, przekroczenie limitu długości hasła lub po prostu edukacja użytkowników dobre podejście.
Shane Madden
źródło
6

Zdecydowanie zalecamy skorzystanie z usługi bramy usług pulpitu zdalnego. Daje ci miejsce, w którym możesz egzekwować zasady dotyczące tego, kto może się połączyć z czym. Zapewnia dobre miejsce do rejestrowania, dzięki czemu można zobaczyć, kto próbuje się zalogować, bez sprawdzania dzienników zdarzeń poszczególnych serwerów w farmie.

Jeśli jeszcze tego nie zrobiłeś, upewnij się, że zasady blokady konta są dość silne. RDP nawet z NLA i bramą daje ludziom coś do próby brutalnego wymuszania haseł. Silna polityka blokowania znacznie utrudnia próbę sukcesu brutalnej siły.

Skonfiguruj prawidłowe certyfikaty SSL w systemach, aby klient powiadomił użytkowników końcowych, jeśli ktoś próbuje wykonać jakiś atak MITM.

Zoredache
źródło
3

Nie jest to zbyt bezpieczne, jednak istnieje kilka sposobów na zwiększenie bezpieczeństwa.

Zabroń dostępu do Internetu z tego serwera. Wiele poważniejszych szkodliwych programów próbuje komunikować się z powrotem z serwerem dowodzenia i kontroli, gdy zagraża to Twojemu systemowi. Skonfigurowanie reguły dostępu do zapory sieciowej, aby domyślnie uniemożliwiać dostęp wychodzący, oraz reguły zezwalającej na dostęp wychodzący tylko do wewnętrznych / znanych sieci i podsieci RFC 1928 może zmniejszyć ryzyko.

Użyj kart inteligentnych lub innego rodzaju uwierzytelniania dwuskładnikowego. Jest to zwykle drogie i występuje głównie w dużych organizacjach, jednak opcje się poprawiają (przychodzi na myśl PhoneFactor). Należy pamiętać, że wymaganie kart inteligentnych można wykonać na serwer, jako opcję konfiguracji na poziomie konta.

Skonfiguruj sieć obwodową, umieść serwer zdalny na obwodzie i skorzystaj z niedrogiego VPN, aby zapewnić dostęp. Przykładem może być Hamachi. Pamiętaj, że zabronienie dostępu do Internetu z sieci obwodowej jest również dobrą praktyką.

Jeśli to możliwe, nie udostępniaj pełnego pulpitu, ale publikuj potrzebne aplikacje. Jeśli ktoś potrzebuje tylko dostępu do jednej aplikacji, można również skonfigurować „program początkowy”, który może być prostą powłoką opakowania, która może wymusić wylogowanie po zamknięciu aplikacji.

Greg Askew
źródło
1

Sugerowałbym następujące środki:

  1. Zmień port używany do połączenia z pulpitem zdalnym
  2. Nie używaj ogólnych nazw użytkowników, ale bardziej skomplikowane zasady nazewnictwa
  3. Wymagania dotyczące wysokich haseł
  4. Zamknij każdy inny nieużywany port z zewnątrz (przychodzący)

Opcjonalny

  1. Użyj VPN (CISCO, Open VPN itp.), A następnie połącz się z serwerem za pomocą wewnętrznego adresu IP.
  2. Użyj logowania kartą inteligentną, jeśli to możliwe
Alex H.
źródło
Zwykle zmieniam port w zaporze, a nie na serwerze (robienie tego na serwerze wymaga zmian w rejestrze). Zwykle łatwiej jest skonfigurować port do przekazywania dalej na routerze i bezpieczniej (bez dotykania rejestru).
JohnThePro
Tak :) właśnie to powiedziałem, ponieważ niektóre osoby nie mają dostępu ani wiedzy na temat przekierowania portów użytkownika. Mimo że zaleca się, aby nie zmieniać rejestru, chyba że jest to konieczne, nigdy nie miałem żadnych problemów. Jedynym problemem, jaki możesz napotkać, jest zmiana go na już używany port.
Alex H
Tak, mam na myśli, że nie jest to największa oferta na świecie, a każdy, kto zna regedit, jest prawdopodobnie wystarczająco inteligentny, aby być ostrożnym ... ale nie możesz tego wiedzieć. :)
JohnThePro
1

Możesz uruchomić WinSSHD na porcie 22, a następnie użyć klienta Tunnelier, aby utworzyć tunel dla Ciebie i automatycznie otworzyć sesję usług terminalowych przez tunel JEDNYM kliknięciem. Daje to również bardzo miłą, bezpieczną opcję FTP do przesyłania plików.

djangofan
źródło
1

Do tych rzeczy używam przekierowania portów ssh i zezwalam tylko na uwierzytelnianie na poziomie użytkownika, oparte na kluczu publicznym. Klucze prywatne wszystkich użytkowników również powinny być szyfrowane. W systemie Windows Putty robi to dobrze, a widowisko ułatwia użytkownikom ładowanie klucza. Jeśli nie uruchamiasz żadnych serwerów Linux / BSD, które domyślnie mają ssh, możesz użyć OpenSSH w Cygwin, aby to zrobić.

Polecam dedykowany zdalny serwer powłoki z lokalną zaporą ogniową blokującą rzeczy, do których nie chcesz, aby ludzie się dalej przesiedlali, ponieważ umożliwienie przekierowania portów w SSH zasadniczo otwiera dowolny wewnętrzny serwer / port dla pożądanych użytkowników.

Jon Zobrist
źródło
1

Bitvise SSH to dobry darmowy SSH dla systemu Windows.

Wybrałbym tanie zakończenie SSL VPN od klienta do obwodu bramy internetowej dla czegoś więcej niż codziennego użytku (na przykład komercyjna poufność).

Powyższe posty dotyczące zabezpieczania RDP są również dobrą praktyką i zawsze powinny być wykonywane, jeśli nie chcesz udostępniać swoich komputerów freeloaderom.

Wola
źródło
0

nie najlepsza praktyka, ale kilka przypadkowych myśli:

  • aktualizuj system - zezwalaj na automatyczne aktualizacje, nie używaj produktów, które są wycofane z eksploatacji,
  • używaj długich / skomplikowanych haseł dla wszystkich kont systemowych
  • zostanę tu skarcony za sugerowanie „bezpieczeństwa przez zaciemnienie”, ale nie wyrządzi ci to żadnej szkody, jeśli:
    • zmień domyślny port 3389 / tcp na inny, np. 26438 / tcp
    • dodaj port-knocking [jeśli to możliwe] na poziomie zapory ogniowej, aby potencjalny użytkownik rdp musiał najpierw odwiedzić jakąś stronę internetową, a dopiero potem mógł rdp na twój serwer.
pQd
źródło