Zabezpiecz połączenie SSH systemu Linux, aby chronić system i dane. Administratorzy systemów i użytkownicy domowi muszą wzmocnić i zabezpieczyć komputery połączone z Internetem, ale SSH może być skomplikowane. Oto dziesięć łatwych i szybkich korzyści, które pomogą chronić Twój serwer SSH.
Podstawy bezpieczeństwa SSH
SSH oznacza Secure Shell . Nazwa „SSH” jest używana zamiennie i oznacza sam protokół SSH lub narzędzia programowe, które umożliwiają administratorom systemu i użytkownikom nawiązywanie bezpiecznych połączeń z komputerami zdalnymi przy użyciu tego protokołu.
Protokół SSH jest szyfrowanym protokołem zaprojektowanym w celu zapewnienia bezpiecznego połączenia w niezabezpieczonej sieci, takiej jak Internet. SSH w Linuksie jest zbudowany na przenośnej wersji OpenSSH projekt. Jest zaimplementowany w klasyczny model klient-serwer , z serwerem SSH akceptującym połączenia od klientów SSH. Klient jest używany do łączenia się z serwerem i do pokaz sesja z użytkownikiem zdalnym. Serwer akceptuje połączenie i wykonuje sesja.
W swojej domyślnej konfiguracji serwer SSH nasłuchuje połączeń przychodzących na protokole kontroli transmisji ( TCP ) port 22. Ponieważ jest to ustandaryzowany, dobrze znany port , jest celem aktorzy zagrożeń i złośliwe boty .
Podmioty zagrażające uruchamiają boty, które skanują zakres adresów IP w poszukiwaniu otwartych portów. Porty są następnie badane, aby sprawdzić, czy istnieją luki, które można wykorzystać. Myślenie: „Jestem bezpieczny, są większe i lepsze cele niż ja, do których złoczyńcy mogą wycelować” to fałszywe rozumowanie. Boty nie wybierają celów na podstawie jakichkolwiek zalet; metodycznie szukają systemów, które mogą złamać.
Nominujesz siebie jako ofiarę, jeśli nie zabezpieczyłeś swojego systemu.
Tarcie bezpieczeństwa
Tarcie związane z bezpieczeństwem to irytacja - w jakimkolwiek stopniu - której użytkownicy i inne osoby mogą doświadczyć podczas wdrażania środków bezpieczeństwa. Mamy długie wspomnienia i pamiętamy, jak wprowadzaliśmy nowych użytkowników do systemu komputerowego i słyszeliśmy, jak pytają przerażonym głosem, czy naprawdę musiał wprowadzić hasło każdego razu zalogowali się do komputera mainframe. To - dla nich - było tarciem o bezpieczeństwo.
(Nawiasem mówiąc, przypisuje się wynalazek hasła Fernando J. Corbató , kolejna postać z panteonu informatyków, których wspólna praca przyczyniła się do powstania okoliczności, które doprowadziły do narodzin Unix .)
Wprowadzenie środków bezpieczeństwa zwykle wiąże się z jakąś formą tarć. Właściciele firm muszą za to zapłacić. Użytkownicy komputerów mogą być zmuszeni do zmiany swoich znanych praktyk, zapamiętania innego zestawu szczegółów uwierzytelniania lub dodania dodatkowych kroków, aby nawiązać połączenie. Administratorzy systemu będą musieli wykonać dodatkową pracę w celu wdrożenia i utrzymania nowych środków bezpieczeństwa.
Utwardzanie i blokowanie systemu operacyjnego Linux lub uniksopodobnego może bardzo szybko się zaangażować. Przedstawiamy tutaj zestaw łatwych do wdrożenia kroków, które poprawią bezpieczeństwo Twojego komputera bez konieczności korzystania z aplikacji innych firm i bez przekopywania się przez zaporę.
Te kroki nie są ostatnim słowem w kwestii bezpieczeństwa SSH, ale pozwolą Ci przejść daleko w przód od ustawień domyślnych i bez zbytniego tarcia.
Użyj protokołu SSH w wersji 2
W 2006 roku protokół SSH został zaktualizowany z wersji 1 do wersja 2 . To było znaczące ulepszenie. Wprowadzono tak wiele zmian i ulepszeń, zwłaszcza dotyczących szyfrowania i zabezpieczeń, że wersja 2 nie jest wstecznie kompatybilna z wersją 1. Aby uniemożliwić połączenia z klientami w wersji 1, można określić, że komputer będzie akceptował połączenia tylko od klientów w wersji 2.
Aby to zrobić, edytuj plik
/ etc / ssh / sshd_config
plik. Będziemy to często robić w tym artykule. Zawsze, gdy chcesz edytować ten plik, użyj polecenia:
sudo gedit / etc / ssh / sshd_config
Dodaj linię:
Protokół 2
I zapisz plik. Zrestartujemy proces demona SSH. Ponownie, będziemy to często robić w tym artykule. To jest polecenie, którego należy użyć w każdym przypadku:
sudo systemctl zrestartuj sshd
Sprawdźmy, czy obowiązuje nasze nowe ustawienie. Przeskoczymy na inną maszynę i spróbujemy nawiązać połączenie SSH na naszej maszynie testowej. I użyjemy
-1
(protokół 1) opcja wymuszenia
ssh
polecenie użycia protokołu w wersji 1.
ssh -1 [email protected]
Świetnie, nasze żądanie połączenia zostało odrzucone. Upewnijmy się, że nadal możemy łączyć się z protokołem 2. Użyjemy
-2
(protokół 2) możliwość udowodnienia faktu.
ssh -2 [email protected]
Fakt, że serwer SSH żąda naszego hasła, jest pozytywną wskazówką, że połączenie zostało nawiązane, a Ty korzystasz z serwera. W rzeczywistości, ponieważ nowi klienci SSH będą domyślnie używać protokołu 2, nie musimy określać protokołu 2, o ile nasz klient jest aktualny.
ssh [email protected]
Nasze połączenie jest akceptowane. Dlatego odrzucane są tylko słabsze i mniej bezpieczne połączenia protokołu 1.
Unikaj portu 22
Port 22 to standardowy port dla połączeń SSH. Jeśli używasz innego portu, dodaje to trochę bezpieczeństwa poprzez zaciemnienie do twojego systemu. Bezpieczeństwo dzięki niejasności nigdy nie jest uważane za prawdziwy środek bezpieczeństwa i skarżyłem się na to w innych artykułach. W rzeczywistości niektóre z inteligentniejszych botów atakujących sondują wszystkie otwarte porty i określają, które usługi oferują, zamiast polegać na prostej liście wyszukiwań portów i zakładać, że zapewniają zwykłe usługi. Jednak użycie niestandardowego portu może pomóc w zmniejszeniu hałasu i złego ruchu na porcie 22.
Aby skonfigurować niestandardowy port, edytuj plik konfiguracyjny SSH:
sudo gedit / etc / ssh / sshd_config
Usuń hash # z początku wiersza „Port” i zastąp „22” wybranym numerem portu. Zapisz plik konfiguracyjny i zrestartuj demona SSH:
sudo systemctl zrestartuj sshd
Zobaczmy, jaki to miało wpływ. Na drugim komputerze użyjemy rozszerzenia
ssh
polecenie, aby połączyć się z naszym serwerem. Plik
ssh
polecenie domyślnie używa portu 22:
ssh [email protected]
Odmówiono nam połączenia. Spróbujmy ponownie i określ port 470, używając opcji -p (port):
ssh -p 479 [email protected]
Nasze połączenie jest akceptowane.
Filtruj połączenia za pomocą opakowań TCP
TCP Wrappers jest łatwy do zrozumienia lista kontroli dostępu . Umożliwia wykluczanie i zezwalanie na połączenia w oparciu o cechy żądania połączenia, takie jak adres IP lub nazwa hosta. Opakowania TCP powinny być używane w połączeniu z prawidłowo skonfigurowaną zaporą ogniową, a nie zamiast niej. W naszym konkretnym scenariuszu możemy znacznie uprościć sprawę, używając opakowań TCP.
Opakowania TCP były już zainstalowane na maszynie Ubuntu 18.04 LTS używanej do badania tego artykułu. Musiał być zainstalowany na Manjaro 18.10 i Fedorze 30.
Aby zainstalować w Fedorze, użyj tego polecenia:
sudo yum zainstaluj tcp_wrappers
Aby zainstalować na Manjaro, użyj tego polecenia:
sudo pacman -Syu tcp-wrappers
W grę wchodzą dwa pliki. Jeden zawiera listę dozwolonych, a drugi listę zabronionych. Edytuj listę odmów za pomocą:
sudo gedit /etc/hosts.deny
Spowoduje to otwarcie
gedit
edytor z załadowanym plikiem odmowy.
Musisz dodać linię:
WSZYSTKO WSZYSTKO
I zapisz plik. To blokuje cały dostęp, który nie został autoryzowany. Teraz musimy autoryzować połączenia, które chcesz zaakceptować. Aby to zrobić, musisz edytować plik zezwolenia:
sudo gedit /etc/hosts.allow
Spowoduje to otwarcie
gedit
edytor z załadowanym plikiem zezwolenia.
Dodaliśmy w nazwie demona SSH,
SSHD
Oraz adres IP komputera, któremu pozwolimy na połączenie. Zapisz plik i zobaczmy, czy ograniczenia i uprawnienia obowiązują.
Najpierw spróbujemy połączyć się z komputera, którego nie ma w
hosts.allow
plik:
Odmowa połączenia. Spróbujemy teraz połączyć się z komputera pod adresem IP 192.168.4.23:
Nasze połączenie jest akceptowane.
Nasz przykład jest nieco brutalny - może się połączyć tylko jeden komputer. Opakowania TCP są dość wszechstronne i bardziej elastyczne niż to. To wspiera nazwy hostów, symbole wieloznaczne i maski podsieci akceptować połączenia z zakresów adresów IP. Jesteś do tego zachęcany sprawdź stronę podręcznika .
Odrzuć żądania połączenia bez haseł
Chociaż jest to zła praktyka, administrator systemu Linux może utworzyć konto użytkownika bez hasła. Oznacza to, że żądania zdalnego połączenia z tego konta nie będą miały hasła do sprawdzenia. Te połączenia będą akceptowane, ale nieuwierzytelnione.
Domyślne ustawienia protokołu SSH akceptują żądania połączenia bez haseł. Możemy to bardzo łatwo zmienić i upewnić się, że wszystkie połączenia są uwierzytelnione.
Musimy edytować Twój plik konfiguracyjny SSH:
sudo gedit / etc / ssh / sshd_config
Przewiń plik, aż zobaczysz wiersz o treści „#PermitEmptyPasswords no”. Usuń hash
#
od początku wiersza i zapisz plik. Zrestartuj demona SSH:
sudo systemctl zrestartuj sshd
Użyj kluczy SSH zamiast haseł
Klucze SSH zapewniają bezpieczny sposób logowania się do serwera SSH. Hasła można odgadnąć, złamać lub brutalnie wymuszony . Klucze SSH nie są otwarte na tego typu ataki.
Podczas generowania kluczy SSH tworzysz parę kluczy. Jeden to klucz publiczny, a drugi to klucz prywatny. Klucz publiczny jest zainstalowany na serwerach, z którymi chcesz się połączyć. Klucz prywatny, jak sugeruje nazwa, jest bezpieczny na Twoim komputerze.
Klucze SSH umożliwiają nawiązywanie połączeń bez hasła, które są - wbrew intuicji - bezpieczniejsze niż połączenia korzystające z uwierzytelniania hasłem.
Kiedy wysyłasz żądanie połączenia, komputer zdalny używa swojej kopii klucza publicznego do tworzenia zaszyfrowanej wiadomości, która jest odsyłana z powrotem do Twojego komputera. Ponieważ został zaszyfrowany za pomocą klucza publicznego, komputer może go odszyfrować za pomocą klucza prywatnego.
Następnie komputer wyodrębnia z wiadomości pewne informacje, zwłaszcza identyfikator sesji, szyfruje je i wysyła z powrotem na serwer. Jeśli serwer może go odszyfrować za pomocą swojej kopii klucza publicznego i jeśli informacje w wiadomości są zgodne z tym, co wysłał serwer, zostanie potwierdzone, że połączenie pochodzi od Ciebie.
Tutaj połączenie z serwerem pod adresem 192.168.4.11 jest nawiązywane przez użytkownika z kluczami SSH. Zauważ, że nie są proszeni o podanie hasła.
ssh [email protected]
Klucze SSH zasługują na osobny artykuł. Mamy dla Ciebie jeden. Oto jak tworzyć i instalować klucze SSH .
ZWIĄZANE Z: Jak tworzyć i instalować klucze SSH z powłoki systemu Linux
Całkowicie wyłącz uwierzytelnianie hasłem
Oczywiście logicznym rozszerzeniem korzystania z kluczy SSH jest to, że jeśli wszyscy zdalni użytkownicy są zmuszeni do ich przyjęcia, można całkowicie wyłączyć uwierzytelnianie hasłem.
Musimy edytować Twój plik konfiguracyjny SSH:
sudo gedit / etc / ssh / sshd_config
Przewiń plik, aż zobaczysz wiersz zaczynający się od „#PasswordAuthentication tak”. Usuń hash
#
od początku wiersza zmień „tak” na „nie” i zapisz plik. Zrestartuj demona SSH:
sudo systemctl zrestartuj sshd
Wyłącz przekazywanie X11
Przekazywanie X11 umożliwia zdalnym użytkownikom uruchamianie aplikacji graficznych z serwera w ramach sesji SSH. W rękach agenta lub złośliwego użytkownika interfejs GUI może ułatwić ich złośliwe cele.
Standardową mantrą w cyberbezpieczeństwie jest to, że jeśli nie masz prawdziwego powodu, aby ją włączać, wyłącz ją. Zrobimy to, edytując plik konfiguracyjny SSH:
sudo gedit / etc / ssh / sshd_config
Przewiń plik, aż zobaczysz wiersz zaczynający się od „# X11Forwarding no”. Usuń hash
#
od początku wiersza i zapisz plik. Zrestartuj demona SSH:
sudo systemctl zrestartuj sshd
Ustaw wartość limitu czasu bezczynności
Jeśli istnieje połączenie SSH z komputerem i przez pewien czas nie było na nim żadnej aktywności, może to stanowić zagrożenie dla bezpieczeństwa. Istnieje szansa, że użytkownik opuścił biurko i jest zajęty gdzie indziej. Każdy, kto przechodzi obok ich biurka, może usiąść i zacząć korzystać z komputera, a przez SSH - z komputera.
O wiele bezpieczniej jest ustalić limit czasu. Połączenie SSH zostanie zerwane, jeśli nieaktywny okres będzie zgodny z limitem czasu. Jeszcze raz edytujemy Twój plik konfiguracyjny SSH:
sudo gedit / etc / ssh / sshd_config
Przewiń plik, aż zobaczysz wiersz zaczynający się od „#ClientAliveInterval 0” Usuń hash
#
od początku wiersza zmień cyfrę 0 na żądaną wartość. Wykorzystaliśmy 300 sekund, czyli 5 minut. Zapisz plik i zrestartuj demona SSH:
sudo systemctl zrestartuj sshd
Ustaw limit prób podania hasła
Określenie limitu liczby prób uwierzytelnienia może pomóc w zapobieganiu zgadywaniu hasła i atakom siłowym. Po wyznaczonej liczbie żądań uwierzytelnienia użytkownik zostanie odłączony od serwera SSH. Domyślnie nie ma limitu. Ale to jest szybko naprawiane.
Ponownie musimy edytować Twój plik konfiguracyjny SSH:
sudo gedit / etc / ssh / sshd_config
Przewiń plik, aż zobaczysz wiersz zaczynający się od „#MaxAuthTries 0”. Usuń hash
#
od początku wiersza zmień cyfrę 0 na żądaną wartość. Użyliśmy tutaj 3. Zapisz plik po wprowadzeniu zmian i zrestartuj demona SSH:
sudo systemctl zrestartuj sshd
Możemy to sprawdzić, próbując się połączyć i celowo wprowadzając nieprawidłowe hasło.
Należy zauważyć, że liczba MaxAuthTries wydawała się być o jeden większa niż liczba prób, na które zezwolono użytkownikowi. Po dwóch nieudanych próbach nasz użytkownik testowy zostaje rozłączony. To było z MaxAuthTries ustawionym na trzy.
Wyłącz główne dane logowania
Logowanie się jako root na komputerze z systemem Linux jest złą praktyką. Powinieneś zalogować się jako zwykły użytkownik i używać
sudo
do wykonywania czynności wymagających uprawnień roota. Co więcej, nie powinieneś zezwalać rootowi na logowanie się do Twojego serwera SSH. Tylko zwykli użytkownicy powinni mieć możliwość łączenia się. Jeśli chcą wykonać zadanie administracyjne, powinni użyć
sudo
też. Jeśli musisz zezwolić użytkownikowi root na logowanie, możesz przynajmniej zmusić go do używania kluczy SSH.
Po raz ostatni będziemy musieli edytować Twój plik konfiguracyjny SSH:
sudo gedit / etc / ssh / sshd_config
Przewiń plik, aż zobaczysz wiersz zaczynający się od „#PermitRootLogin prohibit-password” Usuń hash
#
od początku linii.
- Jeśli chcesz w ogóle uniemożliwić rootowi logowanie, zamień „zabronione-hasło” na „nie”.
- Jeśli chcesz zezwolić rootowi na zalogowanie się, ale zmusisz go do używania kluczy SSH, pozostaw „zakaz-hasło” na miejscu.
Zapisz zmiany i zrestartuj demona SSH:
sudo systemctl zrestartuj sshd
Ostateczny krok
Oczywiście, jeśli w ogóle nie potrzebujesz SSH uruchomionego na komputerze, upewnij się, że jest wyłączone.
sudo systemctl zatrzymaj sshd
sudo systemctl wyłącz sshd
Jeśli nie otworzysz okna, nikt nie może wejść.
