Pierwsza godzina: mniejsza powierzchnia ataku.

Zweryfikuj i zachowaj dostęp

Potwierdź tożsamość serwera przez zaufany kanał i dodaj swój klucz publiczny SSH. Utwórz nazwanego użytkownika administracyjnego. Pozostaw oryginalną sesję otwartą podczas testowania nowej i zapisz metodę odzyskiwania przed zmianą uwierzytelniania.

Łataj i ograniczaj ekspozycję

Zainstaluj obsługiwane aktualizacje bezpieczeństwa i w razie potrzeby uruchom ponownie. Przejrzyj nasłuchujące usługi i zezwól w zaporze tylko na niezbędne porty, w tym IPv6. Usuń nieużywane demony i nie otwieraj bazy danych publicznie tylko po to, by ułatwić konfigurację.

Oddziel użytkowników i sekrety

Uruchamiaj aplikacje na ich własnych kontach. Umieść prywatną konfigurację poza publicznym katalogiem sieciowym i wyklucz ją z kontroli wersji. Stosuj wąskie uprawnienia bazy danych i oddzielne dane uwierzytelniające dla produkcji i eksperymentów.

Zostaw działającą ścieżkę odzyskiwania

Ustaw rotację logów, alerty dyskowe i osobną kopię zapasową. Uruchom ponownie raz, aby sprawdzić, czy aplikacja startuje poprawnie. Zapisz, co zostało zmienione, aby konfigurację można było odtworzyć na czystym obrazie.

Sprawdź przed zamknięciem sesji

Otwórz drugie połączenie przy użyciu nowego konta, zweryfikuj podniesienie uprawnień administracyjnych i przetestuj zaporę z innego klienta. Potwierdź, że usługa wraca po ponownym uruchomieniu. Udokumentuj trasę odzyskiwania u dostawcy, aby błędna reguła sieciowa nie wymagała improwizowanego odzyskiwania.

Lista weryfikacyjna na pierwszy dzień

Sprawdź otwarte gniazda, ostatnie zdarzenia uwierzytelniania, stan aktualizacji, wiek kopii zapasowej i użycie dysku. Upewnij się, że prywatna konfiguracja i metadane kontroli wersji nie mogą zostać pobrane przez HTTP. Używaj najmniejszego zestawu zainstalowanych narzędzi, który obsługuje rzeczywiste obciążenie.

ss -lntup
df -h
free -h
systemctl --failed

Wprowadzaj zmiany dostępu w odwracalnej kolejności

Najpierw potwierdź konsolę lub trasę ratunkową i zweryfikuj klucz hosta SSH przez zaufany kanał dostawcy. Zainstaluj klucz publiczny dla nazwanego administratora, następnie otwórz drugie połączenie i przetestuj podniesienie uprawnień. Zweryfikuj składnię konfiguracji SSH przed ponownym załadowaniem usługi. Zastosuj zmiany zapory dopiero po dozwoleniu zamierzonej trasy SSH. Wyłącz starą metodę uwierzytelniania po tym, jak zamiennik zadziała z nowej sesji, z uwzględnieniem wymaganego przepływu drugiego czynnika.

• Sprawdź obowiązującą konfigurację i dołączone fragmenty; ustawienie w jednym pliku może nie być ostateczną polityką.
• Sprawdź zarówno uwierzytelnianie hasłem, jak i politykę uwierzytelniania interaktywnego z klawiaturą podczas przeglądu projektu logowania opartego na kluczach.
• Niestandardowy port SSH może ograniczyć szum w tle, ale nie zastępuje zweryfikowanych kluczy, limitów dostępu ani aktualizacji.
• Użyj nazwy usługi i procedury przeładowania dla swojej dystrybucji. Pozostaw oryginalną sesję, dopóki nowa polityka nie zostanie sprawdzona.

# Validate before applying a changed SSH configuration.
sudo /usr/sbin/sshd -t
# Read effective settings; adapt user, host and client address to the test.
sudo /usr/sbin/sshd -T -C user=admin,host=server.example,addr=198.51.100.10

Oficjalna dokumentacja: OpenSSH: podręcznik konfiguracji serwera

Udowodnij działanie zapory ogniowej spoza hosta

Traktuj zaporę sieciową dostawcy i zaporę gościa jako osobne mechanizmy kontroli. Przetestuj zamierzoną usługę przez IPv4 i IPv6 z innej autoryzowanej maszyny. Połączenie lokalne dowodzi tylko, że proces nasłuchuje. Nie odrzucaj bezmyślnie każdego pakietu ICMP: normalne działanie sieci wymaga też odpowiedniego ruchu kontrolnego. Sprawdź porty publikowane przez kontener względem rzeczywistych reguł, ponieważ ekspozycja aplikacji może nie odpowiadać polityce, którą według Ciebie zastosował front zapory.

• Jeśli SSH zawiedzie, sprawdź ograniczenia adresu źródłowego, interfejs nasłuchujący i zaporę dostawcy, zanim wielokrotnie zmienisz klucze.
• Jeśli HTTPS zawiedzie, sprawdź kolejno DNS, nasłuchujący proces i lokalną/zaporę proxy.
• Przed pierwszym produkcyjnym zestawem danych sprawdź status aktualizacji, czysty restart, alerty dyskowe i niezależnie odtwarzalną kopię zapasową.
• Ustaw udokumentowaną strefę czasową i zweryfikuj synchronizację czasu. Nie dodawaj dowolnych ustawień swap ani logowania bez sprawdzenia potrzeb pamięci i retencji obciążenia.

Oficjalna dokumentacja: Ubuntu Server: administracja zaporą sieciową