Część 2.4 — Zabezpieczanie systemu Linux przy użyciu lokalnej zapory i zezwalanie na zdalny dostęp HTTP

Dotyczy: .NET Core 2.1, .NET Core 3.1, .NET 5

W tym artykule przedstawiono sposób konfigurowania lokalnej zapory w celu zabezpieczenia maszyny wirtualnej z systemem Linux.

Wymagania wstępne

Nie ma wymagań wstępnych do ukończenia tej części samouczka.

Cel tej części

Dowiesz się, jak zabezpieczyć maszynę wirtualną z systemem Linux, konfigurując zaporę.

Chociaż w tej części nie ma żadnych wymagań wstępnych, idealna konfiguracja będzie przestrzegać wskazówek z poprzednich części. Powinny istnieć następujące elementy:

• Serwer Nginx działa automatycznie i nasłuchuje żądań wysyłanych na porcie 80
• Serwer Nginx skonfigurowany jako zwrotny serwer proxy i kierowanie żądań przychodzących do aplikacji ASP.NET Core nasłuchującej na porcie 5000.
• Aplikacja ASP.NET Core skonfigurowana do automatycznego uruchamiania po ponownym uruchomieniu serwera lub zatrzymaniu lub awarii procesu

Konfigurowanie zapory lokalnej w celu zezwolenia na dostęp z komputerów zdalnych

Prawie wszystkie dystrybucje systemu Linux obejmują lokalną zaporę o nazwie iptables. Ten przewodnik dla początkujących jest wystarczający do szybkiego startu. Iptables to uproszczona, ale zaawansowana zapora, która używa łańcuchów zasad do zezwalania na ruch lub blokowania go.

Zgodnie ze stroną pomocy społeczności systemu Ubuntu domyślnie tabele iptable są instalowane we wszystkich oficjalnych dystrybucjach systemu Ubuntu i są skonfigurowane tak, aby zezwalać na cały ruch.

Chociaż iptables to uproszczona zapora, zarządzanie regułami trwałymi nie jest łatwe. Na szczęście istnieje kilka narzędzi konfiguracji zapory, które znacznie ułatwiają konfigurowanie reguł zapory w systemie Linux. Zgodnie z oficjalną dokumentacją zapory systemu Ubuntu domyślnym narzędziem konfiguracji zapory dla systemu Ubuntu jest ufw. To narzędzie zapewnia bardziej przyjazną dla użytkownika metodę niż iptables zapewnia tworzenie zapory opartej na hoście IPv4 lub IPv6.

Uwaga 16.

ufw początkowo jest domyślnie wyłączony. W związku z tym należy umożliwić jej używanie.

Maszyna wirtualna z systemem Linux używana w tym samouczku nie jest chroniona przez żadną regułę zapory. Jest to spowodowane tym, że chociaż tabele iptable są zainstalowane i uruchomione, nie ma zdefiniowanych reguł.

Celem jest zezwolenie tylko na ruch HTTP i SSH (Secure Shell) do maszyny wirtualnej z zewnątrz. Aby to osiągnąć, wykonaj następujące kroki:

1. Przed włączeniem ufwupewnij się, że domyślna reguła zasad jest ustawiona na zezwalanie. W przeciwnym razie ryzyko utraty połączenia SSH z maszyną wirtualną. Reguła domyślna to reguła, która jest przetwarzana, jeśli żadna inna reguła nie jest zgodna. Włączenie domyślnej reguły "zezwalaj" gwarantuje, że przychodzący ruch SSH nie jest blokowany. W tym momencie w ogóle nie ma reguły "odmowy". W związku z tym cały ruch przychodzący jest dozwolony.

2. Ważne

   Jawnie dodaj reguły SSH i HTTP "allow". Należy również zauważyć, że jeśli port SSH został skonfigurowany do innej wartości niż wartość domyślna 22, należy zezwolić na ten port. Jeśli na przykład zmieniono port SSH na 2222, uruchom następujące polecenie: sudo ufw allow 2222.

3. Ustaw regułę domyślną jako regułę "odmów". Dzięki temu upewnij się, że jeśli protokół różni się od protokołu SSH lub HTTP, domyślna reguła "odmów" będzie blokować ruch. Na przykład przychodzący ruch HTTP zostanie odrzucony.
4. Włącz element ufw.

Polecenia dla tych kroków są wymienione na poniższym zrzucie ekranu.

Dzieje się tak w każdym kroku.

1. sprawdza stan ufw, uruchamiając sudo ufw status verbose polecenie . Domyślnie wartość ufw nie jest włączona i jest nieaktywna.

2. uruchamia sudo ufw default allow polecenie . Ponieważ nie istnieje żadna inna reguła niż domyślna reguła "zezwalaj", każdy port na maszynie wirtualnej zostanie uznany za otwarty.

3. Ważne

   Dodaj protokół SSH do listy dozwolonych, uruchamiając sudo ufw allow ssh polecenie . Protocol.ssh jest znanym protokołem i jest zdefiniowany w pliku /etc/services . W związku z tym można użyć ciągu "ssh" zamiast "22". Pamiętaj, że jeśli skonfigurujesz usługę SSH do nasłuchiwania na porcie innym niż domyślny port 22, należy jawnie dodać drugi port. Jeśli na przykład skonfigurujesz protokół SSH do nasłuchiwania portu 2222, uruchom następujące polecenie: sudo ufw allow 2222.

4. Zezwalaj na protokół HTTP, uruchamiając polecenie sudo ufw allow http. HTTP to znany protokół zdefiniowany w pliku /etc/services. W związku z tym można użyć nazwy protokołu i sudo ufw allow http można uruchomić polecenie. Bieganie sudo ufw allow 80 jest również doskonale prawidłowe.

   Uwaga 16.

   Po zezwól zarówno na protokoły SSH, jak i HTTP, należy dodać wszystkie pozostałe protokoły do listy "odmów".

5. Można to zrobić, zmieniając regułę domyślną na odmowę sudo ufw default deny , uruchamiając polecenie . Dozwolone będą tylko protokoły SSH i HTTP. Pozostałe protokoły zostaną odrzucone.

6. Włącz funkcję ufw.

Poniżej przedstawiono dane wyjściowe po wykonaniu sudo ufw status verbose tej procedury.

Po skonfigurowaniu zapory przetestuj, czy działa.

Testowanie zapory lokalnej

Testowanie zapory jest łatwe: utwórz regułę "odmów" dla protokołu HTTP, a następnie spróbuj uzyskać dostęp do lokacji z innego komputera. Żądanie powinno zostać zablokowane.

Przed utworzeniem tej reguły "odmów" upewnij się, że aplikacja jest dostępna dla przeglądarki w bieżącej konfiguracji. W tym celu zmodyfikuj plik C:\Windows\System32\drivers\etc\hosts na komputerze klienckim, dodając nazwę hosta buggyamb i używając publicznego adresu IP maszyny wirtualnej z systemem Linux. Nazwa hosta buggyamb rozpoznaje adres IP maszyny wirtualnej z systemem Linux. Możesz dodać dowolną nazwę hosta do pliku hostów lub spróbować połączyć się bezpośrednio z publicznym adresem IP maszyny wirtualnej z systemem Linux.

Po sprawdzeniu, czy żądania HTTP mogą dotrzeć do maszyny wirtualnej, spróbuj włączyć regułę blokującą ruch HTTP. Upewnij się, że zapora działa. W tym celu dodaj regułę "odmów" dla protokołu HTTP, uruchamiając polecenie sudo ufw deny http. Spowoduje to dodanie dwóch reguł odmowy dla protokołu HTTP (na porcie 80). Jeden jest dla IPv4, drugi jest dla IPv6.

Otwórz ponownie przeglądarkę, a następnie spróbuj uzyskać dostęp do aplikacji ASP.NET Core działającej w systemie Linux.

Ten zrzut ekranu przedstawia oczekiwany wynik.

Podobny test można uruchomić bezpośrednio na maszynie wirtualnej z systemem Linux przy użyciu wget polecenia . Poniższy zrzut ekranu przedstawia wymagane kroki dla tego samego testu, uruchamiając polecenie wget.

Dzieje się tak w każdym kroku.

1. Dodano regułę "odmów" protokołu HTTP.

2. Polecenie wget buggyamb-external zostało uruchomione. Jak można się domyślać, nazwa hosta "buggyamb-external" rozpoznaje publiczny adres IP maszyny wirtualnej z systemem Linux. W tym celu zmodyfikuj /etc/hosts plik przy użyciu narzędzia vi. Jak pokazano, wget próbował nawiązać z nim połączenie, ale nigdy nie powiodło się. Aby przerwać operację, trzeba było nacisnąć CTRL+C.

3. Dodano regułę "zezwalaj" dla protokołu HTTP.

4. wget buggyamb-external Ponowne uruchomienie polecenia wywołało różne wyniki. Tym razem udało się nawiązać połączenie, wget ponieważ protokół HTTP był dozwolony. Jak pokazano, wget pobiera plik Index.html do bieżącego katalogu.

Teraz jesteś o krok bliżej ukończenia wymaganej konfiguracji w celu debugowania aplikacji ASP.NET Core. Przed przejściem do następnej części upewnij się, że protokół SSH i HTTP są dozwolone w zaporze lokalnej.

Następne kroki

Część 2.5 — kopiowanie plików ze środowiska deweloperskiego do maszyny wirtualnej z systemem Linux, a następnie wyodrębnianie plików w systemie Linux.