Dlaczego warto korzystać z SSH i VPN w połączeniu?

Mój pracodawca wymaga ode mnie pierwszego zalogowania się do VPN, a dopiero potem mogę SSH na serwerach. Ale biorąc pod uwagę bezpieczeństwo SSH, czy VPN jest nadmiernie obciążony?

Jakie jest wykorzystanie VPN w zakresie bezpieczeństwa, jeśli już korzystam z SSH ?

Przyczyną twojego obecnego ustawienia jest prawdopodobnie kombinacja trzech następujących powodów.

VPN to rozwiązanie bezpieczeństwa dla sieci zewnętrznej firmy (patrz nr 1 poniżej) . SSH może jednak stanowić drugą warstwę bezpieczeństwa poza siecią Twojej firmy ... ale jego głównym celem jest zabezpieczenie ruchu w sieci Twojej firmy (patrz # 2 poniżej) . VPN jest również konieczne, jeśli urządzenie, do którego próbujesz połączyć się z siecią SSH, korzysta z prywatnego adresu w sieci twojej firmy (patrz punkt 3 poniżej) .

1. VPN tworzy tunel do sieci firmowej, przez który przepychasz dane. Dlatego nikt, kto widzi ruch między tobą a siecią Twojej firmy, nie może zobaczyć, co wysyłasz. Widzą tylko tunel. Zapobiega to przechwytywaniu ruchu przez osoby spoza sieci firmowej w użyteczny sposób.

2. SSH to szyfrowany sposób łączenia się z urządzeniami w sieci (w przeciwieństwie do Telnet, który jest zwykłym tekstem). Firmy ze względów bezpieczeństwa często wymagają połączeń SSH nawet w sieci firmowej. Jeśli zainstalowałem złośliwe oprogramowanie na urządzeniu sieciowym i telnet na to urządzenie (nawet jeśli przechodzisz przez tunel VPN - ponieważ tunel VPN zwykle kończy się na obwodzie sieci firmowej), widzę twoją nazwę użytkownika i hasło. Jeśli używasz SSH, nie mogę.

3. Jeśli Twoja firma korzysta z prywatnego adresu dla sieci wewnętrznej, urządzenie, z którym się łączysz, może nie być routowalne przez Internet. Łączenie się przez tunel VPN byłoby jak bezpośrednie połączenie w biurze, dlatego użyłbyś wewnętrznego routingu sieci firmowej, który byłby nieosiągalny poza siecią firmową.

SSH jest niezwykle popularnym celem prób brutalnego wymuszania. Jeśli masz serwer SSH bezpośrednio w Internecie, w ciągu kilku minut zobaczysz próby logowania przy użyciu wszelkiego rodzaju nazw użytkowników (i haseł) - często tysiące dziennie, nawet na małych, nieznacznych serwerach.

Teraz możliwe jest zahartowanie serwerów SSH (główne trzy mechanizmy wymagają klucza SSH, odmawiając dostępu root do SSH i, jeśli to możliwe, ograniczając adresy IP, które mogą się nawet łączyć). Mimo to najlepszym sposobem na zahartowanie serwera SSH jest w ogóle jego brak w Internecie.

Dlaczego to ma znaczenie? W końcu SSH jest zasadniczo bezpieczny, prawda? Cóż, tak, ale jest to tylko tak bezpieczne, jak to robią użytkownicy - a twój pracodawca może martwić się słabymi hasłami i kradzieżą kluczy SSH.

Dodanie VPN dodaje dodatkową warstwę obrony, która jest kontrolowana na poziomie korporacyjnym, a nie na poziomie pojedynczego serwera, jak SSH.

W sumie pochwaliłbym twojego pracodawcę za wdrożenie tutaj dobrych praktyk bezpieczeństwa. Oczywiście kosztem wygody (bezpieczeństwo zwykle odbywa się kosztem wygody).

VPN pozwala połączyć się z prywatną siecią pracodawcy i uzyskać adres IP tej prywatnej sieci. Po nawiązaniu połączenia z VPN wygląda to tak, jakbyś korzystał z jednego z komputerów w firmie - nawet jeśli fizycznie znajdujesz się po drugiej stronie świata.

Najprawdopodobniej twój pracodawca wymaga najpierw połączenia przez VPN, ponieważ serwery nie są dostępne z Internetu (tj. Nie mają publicznego adresu IP), co jest dobrym pomysłem. VPN dodaje kolejną warstwę bezpieczeństwa, ponieważ gdyby serwery były publicznie dostępne za pośrednictwem SSH, byłyby narażone na szereg ataków.

SSH to protokół szyfrowania używany do kilku rzeczy. Jednym z nich jest szyfrowanie ruchu w tunelu VPN. Twój ruch jest szyfrowany za pomocą SSH, ale musi być zawinięty w prawidłowe pakiety IP (tunel), aby przejść przez sieć taką jak Internet. Ten tunel to VPN.

Zasadniczo twój pracodawca blokuje ruch sieciowy dla bezpieczeństwa, chyba że ten ruch przychodzi przez VPN kontrolowany przez pracodawcę. VPN może, ale nie musi, szyfrować zawartość tunelu. Korzystanie z SSH szyfruje ruch przenoszony w tunelu VPN.

Potrzebujesz VPN, aby uzyskać dostęp do sieci lokalnej.

Nie musisz wtedy zabezpieczać swojego połączenia z poszczególnymi serwerami, ponieważ będzie ono już szyfrowane przez łącze VPN.

Ale jak inaczej byś się z nimi połączyć? SSH to de facto protokół dostępu do konsoli zdalnych serwerów; instalowanie i konfigurowanie niezabezpieczonego byłoby dodatkowym obciążeniem zarządzania i zmniejszyłoby bezpieczeństwo w sieci lokalnej (co może, ale nie musi stanowić problemu).

Nie zapominaj, że nie wszyscy w firmie będą mieli pełny dostęp do każdego serwera, a możliwość korzystania z szyfrowania opartego na kluczach nawet w sieci lokalnej pozwala administratorowi sieci łatwo i bezpiecznie zapewnić, że tylko ludzie, którzy pozornie wiedzą, co robią, nawet wewnątrz firmy, mogą dotykać serwera.

Możesz także prowadzić dodatkowe warstwy bezpieczeństwa przez VPN. Takie jak sprawdzanie kryteriów urządzenia, uwierzytelnianie 2-czynnikowe itp.

Typowe rozumowanie polega na tym, że chcesz maksymalnie ograniczyć ekspozycję i możliwe wektory ataku.

Jeśli zaczniesz od założenia, że ​​zarówno SSH, jak i VPN są wymagane (do ich własnych celów), wtedy oba mają do czynienia z zewnętrznymi, co oznacza, że ​​atakujący mają dwie potencjalne drogi do twojego środowiska. Jeśli uczynisz SSH tylko lokalnym, doda to dodatkową warstwę do bezpieczeństwa serwera. Rozważ następujące scenariusze:

1. SSH + VPN zewnętrznie. Atakujący potrzebuje tylko kompromisu SSH, aby skompromitować serwer.

2. SSH zewnętrzny. Funkcjonalnie taki sam jak w poprzednim scenariuszu.

3. VPN zewnętrzny (wewnętrzny SSH). Podwaja bezpieczeństwo. Atakujący musi przebić się przez oba, zanim będzie mógł cokolwiek zrobić na serwerze.

Weź pod uwagę, że oprócz tego, że VPN byłby niezbędny dla innych funkcji i może być lepiej skonfigurowany do dostępu zewnętrznego i jest to oczywiste.

Zaryzykowałbym, że odpowiedź brzmi po prostu, że NAT jest zaangażowany i (jak wielu innych stwierdziło) ujawnienie ostatecznego serwera docelowego światu zaprasza na kolejny punkt ataku. O ile nie wykonujesz dużych masowych transferów danych z dużymi kluczami, SSH zazwyczaj nie przeszkadza. Wąskim gardłem prawie zawsze będzie sieć. (Prawie! = Zawsze).

Jeśli masz szczęście, że masz IPv6, prawdopodobnie nie będzie to stanowić większego problemu, ale w przypadku IPv4 i ograniczonej dostępnej przestrzeni adresowej NAT (IMO) ostatecznie, jak sądzę, stoi za tą „polityką” bardziej niż jakakolwiek inna „przypadkowe” lub „celowe” bezpieczeństwo.

Z mojego obecnego zrozumienia, SSH - ponieważ po prostu używa wymiany kluczy tcp do sprawdzenia, czy użytkownik klienta ma prawidłowe dane uwierzytelniające, aby uzyskać dostęp do identyfikatora użytkownika na serwerze, jest podatny na ataki typu man at the middle, gdzie dostawca usług internetowych lub przejęty router może przechwytuje żądanie uzgadniania i działa jako ten, który wysyła uwierzytelnienie, w efekcie przejmując połączenie. Pozwala to na wstrzykiwanie poleceń do strumienia, a następnie odfiltrowuje dane wyjściowe, zanim dotrze do początkowego autentycznego klienta, ukrywając w ten sposób człowieka w środkowym wstrzyknięciu dowolnych poleceń do powłoki ssh serwera.

Jednak przez tunel VPN pozwala coś, czego ssh nie robi. Dodatkowy uzgodniony klucz szyfrowania symetrycznego. Oznacza to, że ruch między dwiema maszynami nie jest podatny na atak człowieka w środku, ponieważ ruch, jeśli zostanie przechwycony i przekazany w imieniu autentycznego klienta w celu kontroli warstwy szyfrowania ssl, nie będzie w stanie przekazać klucza szyfrowania VPN wymagania, ponieważ strona trzecia nie miałaby możliwości sfałszowania kluczy VPN w taki sam sposób, w jaki byłaby w stanie kontrolować pośredniego przekazywania połączenia ssh tcp ssl.

Tak więc, ssh nie jest wystarczający, aby powstrzymać człowieka w środku od dostawcy usług internetowych lub routera, który musi przejść klient, aby połączyć się z serwerem.