Mało która firma ma dzisiaj dostęp do wszystkich swoich zasobów za pomocą własnych kabli sieciowych w swojej siedzibie. Skoro serwery stoją „gdzieś”, to jak łączyć się z nimi bezpiecznie? Oto propozycja jednego z możliwych rozwiązań.
Korzystanie z chmury to wygoda – zasoby obliczeniowe, aplikacyjne czy przestrzeń dyskowa jest dla nas zawsze dostępna, prosta w uruchomieniu i na wyciągnięcie ręki w ciągu paru minut. Dostawca usługi jest odpowiedzialny za zapewnienie jej dostępności oraz obszar tzw. security of the cloud. Prostota wdrożenia i łatwość konfiguracji niesie ze sobą pewne ryzyko co do bezpieczeństwa tego, co znajduje się ,,wewnątrz chmury”. To my jako klient końcowy odpowiadamy za samo wdrożenie naszych instancji czy rozwiązań sieciowych – a jeżeli coś jest proste we wdrożeniu i konfiguracji, to jest łatwiej dostępne dla mniej doświadczonych użytkowników. Przykłady związane z naruszeniem bezpieczeństwa można by wymieniać bez końca – począwszy od publicznie dostępnych danych osobowych w bucketach Amazon S3, przez korzystanie z podatnych wersji usług, aż po nader często popełniane typowe błędy konfiguracyjne. W dzisiejszym artykule skupimy się na zabezpieczeniu dostępu do zasobów w chmurze poprzez wdrożenie bezpiecznego tunelu IPSec VPN. Oczywiście sama tematyka bezpieczeństwa w chmurze jest bardzo rozległa (chętnych do jej zgłębienia odsyłamy do naszego poprzedniego cyklu artykułów), ale zazwyczaj pierwszy krok będzie stanowić właśnie skonfigurowanie dostępu do naszych zasobów.
Zapewnienie bezpiecznego dostępu
Istnieje wiele możliwości rozwiązania kwestii dostępu do zasobów i są one zależne od typu platformy chmurowej (IaaS/Paas/SaaS) i technologii wdrożonych po stronie zasobów on-premises. W przypadku instancji systemów operacyjnych dostawca chmury zazwyczaj w samym procesie wdrażania (przez interfejs WEB lub z wykorzystaniem dedykowanej powłoki / API) pozwala na skonfigurowanie tunelowanego połączenia wspieranego przez system operacyjny. Dla systemów Windows najczęściej będzie to usługa pulpitu zdalnego (RDP), a dla platform Linux wykorzystany zostanie protokół SSH. W przypadku Aruba Cloud w zależności od poziomu zakupionej usługi możemy zdefiniować użytkownika oraz hasło / klucz SSH dla naszej maszyny wirtualnej. Dla poziomu usługi Aruba Private Cloud już na etapie wdrożenia mamy możliwość dowolnego skonfigurowania naszych maszyn wirtualnych, ponadto dzięki technologii VMware NSX możemy automatycznie utworzyć bezpieczny tunel IPSec VPN.
Dla najbardziej wymagających klientów dostawcy chmury tacy jak Amazon, Microsoft czy Google zapewniają bezpośrednie połączenie z zasobami obliczeniowymi realizowane na poziomie operatora łącza WAN. Taka usługa jest dość kosztowna i dostępna wyłącznie tam, gdzie infrastrukturę posiadają współpracujący operatorzy. Co jeśli nie mamy możliwości uruchomienia bezpośredniego połączenia do chmury? W takim wypadku możemy wykupić funkcjonalność tzw. VPN gateway’a, na którym będziemy terminować połączenie VPN. Rozwiązanie to jest dodatkowo płatne, dlatego wielu klientów decyduje się na wdrożenie własnego rozwiązania w postaci tzw. virtual appliance’u. Jest to najczęściej gotowy produkt typu cloud firewall / UTM (dostępne w sklepie dostawcy chmury lub importowane jako obraz wspieranego systemu) obsługujące takie mechanizmy jak SSL, IPSec lub nawet tunele VPN działające w oparciu o autorską technologię.
W naszym dzisiejszym artykule chcemy zaprezentować rozwiązanie bardziej uniwersalne – serwer VPN działający w oparciu o rozwiązanie open source o nazwie StrongSwan. Po stronie zasobów chmurowych będzie ono wymagać uruchomienia instancji z systemem Linux. Po drugiej stronie, reprezentującej naszą sieć lokalną, wykorzystamy rozwiązanie MikroTik CHR. Jeżeli posiadacie jakiekolwiek inne rozwiązanie typu router / firewall, które wspiera protokół IPSec w standardowej implementacji, to ono również może być wykorzystane do takiego scenariusza. Zatem zaczynajmy! Cały proces konfiguracji możecie zobaczyć na poniższym filmie lub przeczytać w formie tekstowej pod nim.
StrongSwan
Po stronie zasobów w Aruba Cloud będziemy potrzebowali instancji, na której zainstalujemy i skonfigurujemy pakiet StrongSwan. Możemy wybrać nawet najbardziej podstawową instancję Cloud VPS (Server Smart). Jeżeli macie określone oczekiwania co do niezawodności i przede wszystkim gwarantowanej wydajności, to warto rozważyć instancje typu Cloud PRO, które zapewniają łącza o przepustowości 1000 Mbps oraz umownie gwarantowane wartości przepustowości minimalnych.
Miejcie też na uwadze, że w przypadku Private Cloud nie ma potrzeby uruchomienia żadnej dedykowanej instancji, ponieważ sam Gateway Edge pozwala na bezpośrednie terminowanie do niego tuneli IPSec VPN.
Jako platformę VPN Gateway’a w przypadku naszego scenariusza wykorzystamy gotowy obraz systemu CentOS 7 utworzony w ramach najbardziej podstawowej instancji z oferty Cloud PRO. Wybór tego produktu nie jest przypadkowy – to w ramach Cloud PRO mamy możliwość tworzenia wirtualnych sieci wewnętrznych, a więc nasza instancja jednym interfejsem będzie podłączona do sieci Internet, a drugim obsłuży sieć wewnętrzną. Dla potrzeb utworzenia tylko i wyłącznie bramki IPSec VPN wystarczające będą najbardziej podstawowe parametry wspomnianej instancji:
Sam proces wdrożenia bramki VPN wyglądać będzie dokładnie tak samo, jak w naszym poprzednim artykule poświęconym budowie klastra. Po uruchomieniu instancji i zalogowaniu przez SSH w pierwszej kolejności aktualizujemy system operacyjny, a następnie instalujemy pakiet StrongSwan:
yum -y install epel-release yum -y update && yum -y upgrade yum -y install strongswan
Nasza instancja będzie stanowić punkt łączący lokalną infrastrukturę z zasobami w chmurze. Warto zadbać o przeprowadzenie właściwego hardeningu systemu operacyjnego – przydatny opis zestawu dobrych praktyk znajdziecie w innym naszym artykule.
Po zainstalowaniu pakietu StrongSwan całą konfigurację przeprowadzimy w oparciu o dwa pliki: /etc/ipsec.conf oraz /etc/ipsec.secrets. Abyśmy mogli skonfigurować połączenie IPSec w wersji IKEv2 i z uwierzytelnianiem w oparciu o certyfikaty X.509, musimy najpierw przeprowadzić wstępną konfigurację urządzenia na drugim końcu tunelu.
Wdrożenie MikroTik CHR
W naszym przykładowym środowisku wykorzystamy rozwiązanie MikroTik Cloud Hosted Router. Będzie ono służyć do zestawienia bezpiecznego tunelu VPN pomiędzy serwerem w chmurze a jedną lokalną siecią LAN. Architekturę takiego środowiska można w uproszeniu przedstawić w następujący sposób:
Oczywiście jeżeli posiadacie sprzętowe rozwiązanie MikroTik, to również może być ono tutaj wykorzystane. Zapewnia ten sam poziom funkcjonalny co wersja wirtualna, od strony zarządzania czy konfiguracji różnice są związane w zasadzie z liczbą interfejsów sieciowych i ich typem. Ważne jest to, abyśmy wykorzystali w swojej konfiguracji najnowszą, stabilną wersję firmware’u. W chwili powstawania niniejszego artykułu bazowaliśmy na wersji 6.44.5 (wersja ze wsparciem typu long-term).
UWAGA: MikroTik zarówno w formie sprzętu, jak i wersji chmurowej, to rozwiązanie komercyjne i wymaga posiadania odpowiedniej licencji. W przypadku platformy CHR dostępna jest darmowa licencja free, która zapewnia wszystkie te same funkcje, co i firmware routerów sprzętowych, niemniej jednak maksymalna przepustowość jest ograniczona do wartości 1 Mbps per jeden interfejs sieciowy.
Obraz systemu wirtualnego MikroTik CHR możemy pobrać bezpośrednio ze strony producenta. Same obrazy zostały przygotowane pod różne platformy wirtualizacji, takie jak np. Hyper-V, Virtual Box czy VMware (vSphere/ESXi/Workstation). W naszym przykładzie skorzystamy z gotowego szablonu w formacie OVA (Open Virtual Appliance), dzięki czemu nie będzie konieczne ręczne tworzenie samej maszyny wirtualnej i podłączanie do niej dysku.
Obraz OVA może być zaimportowany na różne platformy. Jeżeli nie dysponujesz żadnym dedykowanym rozwiązaniem w postaci sprzętowego hypervisora i chcesz jedynie przetestować opisane przez nas rozwiązanie, możesz skorzystać z oprogramowania do wirtualizacji. W przypadku pracy z platformami open source może to być Oracle VirtualBox. Dobrą alternatywą jest również dostępny w zestawie z systemami Windows 10 (Enterprise, Edu i Pro) Microsoft Hyper-V.
W zależności od wybranej platformy wirtualizacji procedura importu i pierwszego uruchomienia maszyny może się w pewnym stopniu różnić, niemniej jednak już sam proces konfiguracji MiktoTika ,,od środka” będzie wyglądać tak samo.
Poniżej opisujemy Wam proces importu i uruchomienia MikroTik CHR na platformie VMware Hypervisor 6.7 (ESXi). Pozostałe instrukcje Quick Start Guide dla innych platform wirtualizacji czy chmury publicznej znajdziecie w tym miejscu: https://wiki.mikrotik.com/wiki/Manual:CHR#Steps_to_install_CHR
Po pobraniu obrazu MikroTik CHR zaczynamy od jego zaimportowania. Bezpośrednio po zalogowaniu do konsoli VMware ESXi klikamy na opcję Create/Register VM:
Zostanie wyświetlone nowe okno kreatora tworzenia maszyny wirtualnej. Wybieramy w nim drugą opcję o nazwie Deploy a virtual machine from an OVF or OVA file:
W kolejnym oknie z wykorzystaniem metody przeciągnij-upuść wskazujemy plik obrazu OVA MikroTik CHR:
W kolejnym etapie nadajemy nazwę dla naszego wirtualnego routera i przechodzimy dalej:
Następnie wskazujemy nazwę tzw. datastore, na którym zostaną stworzone wszystkie pliki maszyny wirtualnej:
Potem wskazujemy nazwę tzw. portgrupy podłączonej do wirtualnego interfejsu sieciowego:
Na koniec procesu importu zostają wyświetlone wszystkie wcześniej wybrane ustawienia. W celu zakończenia klikamy na przycisk Finish:
Następnie musimy poczekać, aż import się zakończy:
Przed pierwszym uruchomieniem konfigurację naszego witalnego routera musimy poddać odpowiedniej edycji, aby właściwie podłączyć go do istniejącej infrastruktury:
Nasz wirtualny router będzie wyposażony w dwa interfejsy – dla sieci LAN (10.10.10.0/24) oraz WAN (188.147.34.216/29). Jako drugi dodajemy interfejs sieci LAN:
Zapisujemy ustawienia klikając na Save i uruchamiamy maszynę wirtualną:
Po uruchomieniu maszyny klikamy na nią. Wyświetlone zostanie okno zarządzania – przechodzimy w nim do uruchomienia okna wirtualnej konsoli maszyny wirtualnej:
Zarządzanie urządzeniem będziemy realizować wyłącznie z sieci LAN, stąd też podczas startowej konfiguracji w konsoli sieć tę zdefiniujemy jako pierwszą. Aby przejść do konfiguracji, należy zalogować się do konsoli – login to admin, hasła natomiast nie podajemy – domyślnie nie jest ono zdefiniowane:
W zależności od tego w jaki sposób nasze urządzenie wirtualne zostanie podłączone do sieci, mamy dwie możliwości jego skonfigurowania:
1. Poprzez CLI, korzystając z konsoli hypervisora – w przypadku gdy nie mamy fizycznej możliwości bezpośredniego podłączenia się naszym komputerem do sieci LAN, dla której Mikrotik ma stanowić bramę domyślną:
– logujemy się poprzez podanie nazwy użytkownika admin i pustego hasła,
– w celu nadania adresu IP dla sieci LAN musimy przejść do odpowiedniego sub-menu poprzez wydanie komendy: /ip address
– następnie wydajemy polecenie definiujące adres IP na właściwym interfejsie (ether1):
add address=10.10.10.254/24 interface=ether1
– następnie celem weryfikacji poprawności wprowadzonej konfiguracji wydajemy polecenie:
Wynik działania tych poleceń powinien przedstawiać się w następujący sposób:
2. Inna możliwość to skorzystanie z dedykowanej aplikacji WinBox, o ile jesteśmy podłączeni w ramach tej samej podsieci co interfejs LAN urządzenia (istotna jest widoczność w ramach drugiej warstwy sieci w modelu ISO/OSI).
– WinBox jest aplikacją typu portable i można go pobrać bezpośrednio ze strony producenta:
– po jej uruchomieniu od razu wyszukane zostają dostępne routery MikroTik (widoczne w zakładce Neighbours); w przypadku widoczności naszego routera wystarczy kliknąć na niego i bez podawania hasła dla użytkownika admin zalogować się poprzez kliknięcie na przycisk Connect:
– po podłączeniu do urządzenia możemy od razu przystąpić do skonfigurowania adresu IP, aby dalsze połączenie i logowanie było możliwe już z wykorzystaniem warstwy trzeciej ISO/OSI; w tym celu z menu po lewej stronie wybieramy opcję IP -> Addresses:
– konfigurujemy adres IP, jaki będziemy wykorzystywać do zarządzania urządzeniem; jest to też adres IP stanowiący bramę domyślną dla naszej sieci LAN 10.10.10.0/24:
– po poprawnym skonfigurowaniu adresu IP – w celu weryfikacji, czy konfiguracja jest poprawna – możemy uruchomić ponownie aplikację WinBox i połączyć się do urządzenia z wykorzystaniem nadanego mu adresu IP:
Dalszą część naszej instrukcji będziemy realizować w oparciu o pracę z interfejsem aplikacji WinBox. Oczywiście przeprowadzenie wszystkich czynności jest możliwe również z poziomu wiersza poleceń – producent dostarcza dla niego bardzo rozbudowaną dokumentację: https://wiki.mikrotik.com/wiki/Manual:TOC
Po wykonaniu wstępnej konfiguracji po stronie sieci LAN przechodzimy do ustawienia adresacji dla interfejsu WAN. W tym celu ponownie wybieramy opcję IP -> Addresses i definiujemy adres IP (188.147.34.218) przydzielony przez naszego operatora – w tym wypadku na interfejsie ether2:
Kolejny krok stanowić będzie zdefiniowanie bramy domyślnej operatora o adresie IP 188.147.34.217:
Po dodaniu trasy RouterOS ustawi ją jako aktywną, tylko jeśli brama będzie dostępna, co można zweryfikować w zakładce Nexthops:
Dodatkowo możemy wykonać weryfikację poprzez przetestowanie, czy komunikacja z naszą instancją w Aruba Cloud jest już poprawnie realizowana. W tym celu możemy po prostu uruchomić terminal systemowy i skorzystać z polecenia ping:
Przed przystąpieniem do finalnej konfiguracji tunelu VPN warto jeszcze zdefiniować reguły firewalla oraz skonfigurować NAT-owanie. Platforma MikroTik domyślnie nie posiada żadnego zestawu reguł, a cała komunikacja przechodząca przez urządzenie nie zostanie zablokowana. Należy o tym pamiętać, ponieważ jeśli nie zdefiniujemy odpowiednich reguł blokujących niedozwoloną komunikację, to będzie ona dopuszczona.
Reguły firewalla edytujemy w sekcji IP -> Firewall. Cały zestaw jest przetwarzany zgodnie z określoną kolejnością – jako pierwsze stosowane są reguły znajdujące się na samej górze, a jako ostatnie te będące na samym dole. Zdefiniujmy zatem następującą politykę:
- Hosty z sieci LAN mające adresy IP z zakresu 10.10.10.100-200 będą mogły inicjować połączenia do wszystkich sieci i dla wszystkich protokołów.
- Wszystkie hosty z sieci LAN 10.10.10.0/24 będą miały dostęp do sieci wewnętrznej w Aruba Cloud (10.10.20.0/24) dla wszystkich protokołów.
- Wszystkie hosty z sieci wewnętrznej Aruba Cloud (10.10.20.0/24) będą miały dostęp tylko do hosta 10.10.10.50 i tylko dla protokołu SSH.
- Cała pozostała komunikacja ma zostać zablokowana.
Zestaw reguł odpowiadający powyższym założeniom będzie przedstawiać się w poniższy sposób:
Dla zapewnienia komunikacji pomiędzy hostami z sieci LAN a siecią Internet niezbędne jest również zdefiniowanie reguły NAT, która wygląda następująco:
Konfiguracja tunelu IPSec
Skonfigurowanie tunelu VPN zaczynamy od wygenerowania certyfikatu urzędu certyfikacji (CA) oraz certyfikatów przez niego podpisanych. Całość wygenerujemy z poziomu RouterOS i z wykorzystaniem CLI. Zaczynamy od zdefiniowania serwerów czasu i właściwej strefy czasowej, aby okres ważności certyfikatów mogła być zawsze poprawnie zweryfikowany:
/system ntp client set enabled=yes
/system ntp client set primary-ntp=159.253.242.123
/system ntp client set secondary-ntp=193.70.94.126
/system clock set time-zone-name=Europe/WarsawKolejno przechodzimy do utworzenia CA i wygenerowania certyfikatów dla obydwu serwerów VPN:
/certificate add common-name="z3s.pl Root CA" name=ca
/certificate sign ca ca-crl-host=10.10.10.254
/certificate add common-name=vpn.z3s.pl subject-alt-name=IP:vpn.z3s.pl key-usage=tls-server name=server1
/certificate sign server1 ca=ca
/certificate add common-name=aruba.z3s.pl key-usage=tls-server name=server2
/certificate sign server2 ca=caWynik powyżej wykonanych poleceń powinien wyglądać tak jak na poniższym zrzucie:
Następnie eksportujemy certyfikaty do postaci plikowej:
/certificate export-certificate ca
/certificate export-certificate server2 export-passphrase=supertajnehasloPliki certyfikatów pobieramy, korzystając z modułu Files:
Następnie, korzystając z dowolnego klienta SCP czy SFTP (np. WinSCP), kopiujemy pliki na instancję serwera w Aruba Cloud:
W dalszej części możemy przejść do skonfigurowania parametrów tunelu po obu jego stronach. Zaczynamy od MikroTika, ponownie wracając do wiersza poleceń. Tunel IPSec skonfigurujemy poprzez wydanie następującej sekwencji poleceń:
/ip pool
add name=ARUBA ranges=10.10.20.0/24
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048
/ip ipsec mode-config
add address-pool=ARUBA address-prefix-length=32 name=aruba
/ip ipsec peer
add address=89.38.144.210 name=aruba exchange-mode=ike2 profile=default passive=yes
/ip ipsec identity
add auth-method=rsa-signature certificate=server1 generate-policy=port-strict peer=aruba mode-config=aruba
/ip ipsec policy
set 0 dst-address=10.10.20.0/24 src-address=10.10.10.0/24Mając już gotowe wszystkie elementy po stronie routera MikroTik, przechodzimy do powłoki CentOS-a i finalizujemy konfigurację StrongSwana. Zaczynamy od przeniesienia plików certyfikatów we właściwe miejsce:
mv /root/cert_export_ca.crt /etc/strongswan/ipsec.d/cacerts/cert_export_ca.pem
mv /root/cert_export_server2.crt /etc/strongswan/ipsec.d/certs/cert_export_server2.pem
mv /root/cert_export_server2.key /etc/strongswan/ipsec.d/private/cert_export_server2.pemKolejno przechodzimy do edycji pliku /etc/strongswan/ipsec.conf. Nasz będzie miał następującą zawartość:
conn vpn.z3s.pl
keyexchange=ikev2
ike=aes256-sha256-modp2048
esp=aes256-sha256-modp2048
ikelifetime = 24h
lifetime = 30m
dpddelay = 120s
left=%defaultroute
leftsourceip=%config
leftcert=cert_export_server2.pem
leftid=aruba.z3s.pl
leftfirewall=yes
right=188.147.34.218
rightsubnet=10.10.10.0/24
rightid="CN=vpn.z3s.pl"
auto=addNa ostatnim etapie konfiguracji usługi StrongSwan przechodzimy do edycji pliku /etc/strongswan/ipsec.secrets, dodając w nim tylko jeden wpis wskazujący nazwę oraz hasło do pliku zawierającego klucz prywatny:
: RSA cert_export_server2.pem "supertajnehaslo"Włączamy usługę StrongSwan:
systemctl enable strongswan
systemctl start strongwanPrzed uruchomieniem połączenia weryfikujemy, czy wszystkie certyfikaty zostały załadowane prawidłowo:
strongswan listcerts
Na powyższym zrzucie zaznaczony na czerwono wiersz jest dość istotny – dzięki informacji has private key wiemy, że poza kluczem publicznym poprawnie załadowany został również klucz prywatny naszego certyfikatu.
Domyślnie certyfikaty generowane przez RouterOS mają roczny termin ważności – musimy zatem pamiętać, aby je wznowić lub wygenerować nowe przed upływem tego okresu. W przeciwnym razie nasz tunel VPN nieoczekiwanie przestanie działać. W celu zainicjowania tunelu VPN po stronie instancji CentOS wydajemy następujące polecenie:
strongswan up vpn.z3s.pl
Zarówno z poziomu CentOS-a, jak i na routerze MikroTik, weryfikujemy, czy tunel jest zestawiony prawidłowo:
Samo zestawienie tunelu nie oznacza jeszcze, że hosty po obu stronach będą się ze sobą poprawnie komunikowały. Jako prosty test możemy wysłać pakiety ICMP Echo Request na adres IP interfejsu MikroTik CHR w sieci LAN (w tym scenariuszu jest to adres 10.10.10.254):
Tak skonfigurowany tunel nie będzie uruchamiany automatycznie w przypadku restartu instancji chmurowej (MikroTik jest stroną pasywną tunelu, co oznacza że nie reinicjuje go w przypadku przerwania). Aby tunel był zestawiany automatycznie, wystarczy, że w pliku konfiguracyjnym /etc/ipsec.conf zmienimy ostatni wiersz:
auto=add
na
auto=start
Podsumowanie
Zapewnienie bezpiecznego kanału komunikacji pomiędzy zasobami w chmurze a infrastrukturą lokalną ma ogromne znaczenie w kontekście bezpieczeństwa danych. Nie można również zapominać o potrzebie zapewnienia wysokiej dostępności. W przypadku bardzo dużych organizacji poza dedykowanymi przyłączami do chmury (np. DirectConnect dla AWS czy DirectAccess w Azure) tworzone są również zapasowe tunele VPN w oparciu o typowe łącza operatorskie. To właśnie z wykorzystaniem takiego połączenia nasze systemy brzegowe, dostępne publicznie dla całego świata, mogą komunikować się z wewnętrznymi systemami i aplikacjami, jakich na co dzień używają pracownicy w biurze. Nie należy jednak zapominać, że usługi, jakie udostępniamy publicznie, również należy zabezpieczyć we właściwy sposób – dostawca chmury nie będzie bowiem odpowiedzialny za tę część zabezpieczenia dzierżawionych zasobów. Dlatego poza routerami czy bramkami VPN będziemy potrzebować kolejnych komponentów w postaci load balancerów czy firewalli aplikacyjnych (WAF).
