Jak zahartować serwer SSH?


128

Jakie środki mogę / powinienem podjąć, aby upewnić się, że bezpieczeństwo wokół mojego serwera SSH jest absolutnie nieprzepuszczalne?

To będzie wiki społeczności od samego początku, więc zobaczmy, co ludzie robią, aby zabezpieczyć swoje serwery.


44
Absolutna nieprzepuszczalność wymaga wyłączenia pudełka.
Thorbjørn Ravn Andersen

Co jeśli masz Wake-on-LAN?
rebus

Problemem będzie część LAN ... Pakiety Wake-on-LAN nie są kierowane, więc musisz mieć dostęp do komputera w sieci LAN, aby wysłać pakiet WOL ...
LassePoulsen

W celu uwierzytelnienia klucza możesz ograniczyć Szyfry do szyfrów, których naprawdę potrzebujesz.

Odpowiedzi:


108

Do uwierzytelniania używaj par kluczy publiczny / prywatny zamiast haseł.

  1. Wygeneruj klucz SSH chroniony hasłem dla każdego komputera, który musi uzyskać dostęp do serwera:

    ssh-keygen

  2. Zezwól na dostęp SSH z kluczem publicznym z dozwolonych komputerów:

    Skopiuj zawartość ~/.ssh/id_rsa.pubz każdego komputera do poszczególnych wierszy ~/.ssh/authorized_keysna serwerze lub uruchom ssh-copy-id [server IP address]na każdym komputerze, do którego udzielasz dostępu (musisz podać hasło serwera w odpowiedzi na monit).

  3. Wyłącz dostęp SSH do hasła:

    Otwórz /etc/ssh/sshd_config, znajdź wiersz, który mówi #PasswordAuthentication yes, i zmień go na PasswordAuthentication no. Uruchom ponownie demona serwera SSH, aby zastosować zmianę ( sudo service ssh restart).

Teraz jedynym możliwym sposobem na SSH do serwera jest użycie klucza pasującego do linii w ~/.ssh/authorized_keys. Stosując tę metodę, ja nie dbam o atak brute force, ponieważ nawet jeśli odgadnąć hasło, zostanie ona odrzucona. Brutalne wymuszanie pary kluczy publiczny / prywatny jest niemożliwe w dzisiejszej technologii.


5
-1: Zasadniczo dostęp jest przyznawany indywidualnym, a nie komputerom, tworzenie klucza dla każdego potencjalnego komputera klienckiego łączącego się z serwerem jest nieuzasadnione. Twoje ostatnie stwierdzenie jest niepoprawne, zgodnie z twoją sugestią, a ponieważ nie sugerujesz, aby ustawić hasło dla kluczy prywatnych, które mają dostęp / naruszenie bezpieczeństwa dowolnego systemu klienckiego automatycznie przyznają dostęp do serwera SSH. Zalecane jest uwierzytelnianie za pomocą klucza SSH, ale klucze prywatne muszą być odpowiednio chronione i powinny być używane indywidualnie, a nie w sposób rozproszony, jak opisano.
João Pinto

7
„Zasadniczo dostęp jest przyznawany poszczególnym komputerom, a nie komputerom, tworzenie klucza dla każdego potencjalnego komputera klienckiego łączącego się z serwerem jest nieuzasadnione” Istnieje wiele opcji i myślę, że opisanie, jak bezpiecznie przenieść klucz prywatny do każdego klienta wydaje się być poza zakresem tego pytania . Nie przedstawiam wszystkich opcji, tylko tę prostą, którą ludzie mogą zrozumieć. „... należy stosować indywidualnie, a nie w sposób rozproszony, jak opisano” Wydaje się to przeczyć twojemu wcześniejszemu stwierdzeniu, a ja nie opisałem niczego jako rozpowszechnionego.
Asa Ayers,

5
„niemożliwe” może być nieco przesadzone.
Thorbjørn Ravn Andersen

9
Dlatego mówię „niemożliwe”. Nikt nie ma tak szybkich komputerów przez tak długi czas. „Wyobraź sobie komputer wielkości ziarenka piasku, który może testować klucze w odniesieniu do niektórych zaszyfrowanych danych. Wyobraź sobie również, że może przetestować klucz w czasie potrzebnym do jego przejścia. Następnie rozważ klaster tych komputerów, tak wielu, że jeśli pokryjesz je ziemią, pokryją całą planetę do wysokości 1 metra. Gromada komputerów złamałaby 128-bitowy klucz średnio za 1000 lat. ”
Asa Ayers,

@ ThorbjørnRavnAndersen „Impossible” tak naprawdę nie przesadza, o ile używasz silnego klucza. Nie mogę teraz znaleźć cytatu, ale przy obecnych długościach kluczy ataki brutalnej siły są niemożliwe „dopóki komputery nie złożą się z czegoś innego niż materia i nie zajmą czegoś innego niż przestrzeń”.
Maximillian Laumeister,

72

Sugerowałbym:

  • Korzystanie z fail2ban w celu zapobiegania próbom logowania z użyciem siły brutalnej.

  • Wyłączanie logowania jako root za pośrednictwem SSH. Oznacza to, że atakujący musiał poznać zarówno nazwę użytkownika, jak i hasło, co utrudnia atak.

    Dodaj PermitRootLogin nodo swojego /etc/ssh/sshd_config.

  • Ograniczanie użytkowników, którzy mogą SSH do serwera. Albo według grupy, albo tylko konkretnych użytkowników.

    Dodaj AllowGroups group1 group2lub AllowUsers user1 user2ogranicz, kto może SSH na serwerze.


2
W AllowUsers i AllowGroups nie akceptuje przecinek , jako ogranicznik. Upewnij się, że nie próbujesz tego zdalnie. Wciąż blokuje się mój serwer NAS, robiąc to niepoprawnie.
bezgłośny hałas

4
Zawsze potwierdzić swoją sshdconfig jest poprawna przed ponownym uruchomieniem sshd, aby uniknąć blokowania się z urządzenia. Zobacz ten blog, aby uzyskać szczegółowe informacje - po prostu uruchom sshd -Tpo zmianie konfiguracji przed ponownym uruchomieniem głównego sshd. Również mieć otwartą sesję SSH na maszynie podczas dokonywania zmian konfiguracyjnych i nie zamykaj tego dopóki nie zatwierdzone config jak wspomniano, a może zrobili logowanie Test SSH.
RichVel,

24

Inne odpowiedzi zapewniają bezpieczeństwo, ale możesz zrobić jedną rzecz, która sprawi, że twoje dzienniki będą ciszej i mniej prawdopodobne, że zostaniesz zablokowany z konta:

Przenieś serwer z portu 22 na inny. Albo w twojej bramie, albo na serwerze.

Nie zwiększa bezpieczeństwa, ale oznacza, że ​​wszystkie przypadkowe skanery internetowe nie będą zaśmiecać plików dziennika.


1
Dla tych, którzy wierzą w bezpieczeństwo przez zaciemnienie ( en.wikipedia.org/wiki/Security_through_obscurity ) sensowne jest użycie innego portu. Nie sądzę ..
LassePoulsen

32
Tu nie chodzi o bezpieczeństwo poprzez zaciemnienie (chociaż niejasność może mieć marginalny pozytywny efekt). Chodzi o zmniejszenie hałasu tła podczas niekończących się prób brutalnej siły. Nie można z powodzeniem kontrolować dzienników błędów dostępu, jeśli są one pełne automatycznych ataków; fail2ban nie zmniejsza wystarczająco głośności, biorąc pod uwagę liczbę atakujących oraz częstość ataków rozproszonych (botnet) i dławionych. Z ssh na nietypowym porcie wiesz , że ataki, które widzisz w logach, pochodzą od prawdziwych atakujących zainteresowanych twoim urządzeniem. Zdecydowanie polecam.
bobince

Ponieważ możesz wyszukiwać w usługach internetowych, takich jak shodan, w przypadku serwerów SSH skierowanych do sieci lub używając nmap i przechwytywania banerów, zmiana domyślnego portu jest prawie bezcelowa. odradzałbym to.
SLow Loris,

Shodan nie pobiera wszystkich portów 65k, więc zmiana na wysoki port prawdopodobnie usunie go ze swoich skanów. Ponadto, jeśli przejdziesz do losowo wysokiego portu, atakujący prawdopodobnie będzie musiał wykonać skanowanie 65K TCP (bardzo głośne), aby znaleźć twoją usługę, aby zacząć go atakować. Oba są wygrane z punktu widzenia bezpieczeństwa, więc przejście do wysokiego portu jest ogólnie dobrym planem. Kolejnym jest to, że przenosząc się do wysokiego portu, możesz mieć lepszy pomysł, że ktoś, kto cię atakuje, atakuje twoje systemy specjalnie w przeciwieństwie do zwykłego szumu internetowego w tle
Rоry McCune,

23

Włącz uwierzytelnianie dwuskładnikowe za pomocą HOTP lub TOTP . Jest to dostępne od 13.10.

Obejmuje to używanie uwierzytelniania za pomocą klucza publicznego zamiast uwierzytelniania za pomocą hasła, tak jak w innej odpowiedzi tutaj, ale wymaga również od użytkownika udowodnienia, że ​​oprócz swojego klucza prywatnego posiada swoje urządzenie drugiego czynnika.

Podsumowanie:

  1. sudo apt-get install libpam-google-authenticator

  2. Poproś każdego użytkownika, aby uruchomił google-authenticatorpolecenie, które generuje ~/.google-authenticatori pomaga im skonfigurować urządzenia dwuskładnikowe (np. Aplikację Google Authenticator na Androida).

  3. Edytuj /etc/ssh/sshd_configi ustaw:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Uruchom, sudo service ssh reloadaby odebrać zmiany w /etc/ssh/sshd_config.

  5. Edytuj /etc/pam.d/sshdi zamień wiersz:

    @include common-auth
    

    z:

    auth required pam_google_authenticator.so
    

Więcej szczegółów na temat różnych opcji konfiguracji znajduje się w moim blogu z zeszłego roku: Lepsze uwierzytelnianie ssh w dwóch aspektach na Ubuntu .


21

Spraw, aby sshd blokował adresy IP klientów, którzy nie podali prawidłowych danych logowania „ DenyHØsts ”, może wykonać to zadanie dość skutecznie. Mam to zainstalowane na wszystkich moich urządzeniach Linux, które są w jakiś sposób dostępne z zewnątrz.

Zapewni to, że ataki siłowe na SSHD nie będą skuteczne, ale pamiętaj (!), Że w ten sposób możesz się zablokować, jeśli zapomnisz hasła. Może to stanowić problem na zdalnym serwerze, do którego nie masz dostępu.


2
Czy istnieje jakaś opcja, na przykład 10 nieudanych prób logowania przed zablokowaniem adresu IP?
sayantankhan

20

Oto jedna łatwa rzecz: zainstaluj ufw („nieskomplikowana zapora ogniowa”) i użyj jej, aby ograniczyć liczbę połączeń przychodzących.

W wierszu polecenia wpisz:

$ sudo ufw limit OpenSSH 

Jeśli ufw nie jest zainstalowany, zrób to i spróbuj ponownie:

$ sudo aptitude install ufw 

Wielu atakujących będzie próbowało użyć twojego serwera SSH do haseł typu brute-force. Umożliwi to tylko 6 połączeń co 30 sekund z tego samego adresu IP.


+1 Korzystanie z limitu może być dobre. Należy jednak zauważyć, że napotkałem problemy podczas korzystania z wbudowanego serwera sftp, ponieważ ogranicza to również połączenia.
Mark Davidson,

2
@ Mark - dobry punkt, ale czy to nie brzmi jak źle napisany klient SFTP? Dlaczego mieliby łączyć się ponownie z portem SSH, skoro mogliby po prostu otworzyć więcej kanałów SSH?
mpontillo

12

Jeśli chcę mieć dodatkowe zabezpieczenia lub muszę uzyskać dostęp do serwerów SSH głęboko w sieci firmowej, konfiguruję usługę ukrytą za pomocą oprogramowania anonimizującego Tor .

  1. Zainstaluj Tor i skonfiguruj sam serwer SSH.
  2. Upewnij się, że sshd nasłuchuje tylko w localhost.
  3. Otwarte /etc/tor/torrc. Ustaw HiddenServiceDir /var/lib/tor/sshi HiddenServicePort 22 127.0.0.1:22.
  4. Patrzeć var/lib/tor/ssh/hostname. Jest taka nazwa d6frsudqtx123vxf.onion. To jest adres ukrytej usługi.
  5. Otwórz $HOME/.ssh/configi dodaj kilka wierszy:

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
    

Ponadto potrzebuję Tora na moim lokalnym serwerze. Jeśli jest zainstalowany, mogę wejść, ssh myhosta SSH otworzy połączenie przez Tora. Serwer SSH po drugiej stronie otwiera swój port tylko na localhost. Więc nikt nie może połączyć go przez „normalny internet”.


10
Bezpieczeństwo dzięki zaawansowanemu zaciemnieniu, ale bardzo interesujące.
Johannes,

8

Artykuł na temat administracji Debiana na ten temat. Obejmuje podstawową konfigurację serwera SSH, a także reguły zapory. Może to być również interesujące dla zaostrzenia serwera SSH.

Zobacz tam artykuł: Zabezpieczanie dostępu do SSH .


3
Trochę za późno, ale proszę, odpowiadając na pytania, skopiuj ważne części z linku, aby w przypadku zaniku linku informacje nadal były dostępne.
umop aplsdn

1
Dobry pomysł. Chociaż przeżyłem okres, w którym udział jest znacznie krótszy. Moja odpowiedź to „wiki społeczności”, więc jeśli masz czas, dodaj informacje o linku.
Huygens,

6

Moje podejście do hartowania SSH jest ... złożone. Poniższe elementy dotyczą sposobu, w jaki to robię, od najbardziej skrajnych granic mojej sieci (sieci) do samych serwerów.

  1. Filtrowanie ruchu na granicy przez IDS / IPS za pomocą znanych skanerów usług i podpisów na liście bloków. Osiągam to dzięki Snortowi za pośrednictwem mojej firewalli granicznej (takie jest moje podejście, urządzenie pfSense). Czasami nie mogę tego zrobić, na przykład za pomocą moich VPS.

  2. Filtrowanie zapory / sieci portów SSH. Wyraźnie zezwalam tylko niektórym systemom na dostęp do moich serwerów SSH. Odbywa się to albo za pośrednictwem zapory ogniowej pfSense na granicy mojej sieci, albo zapory ogniowe na każdym serwerze jawnie konfigurowane. Są jednak przypadki, w których nie mogę tego zrobić (co prawie nigdy tak nie jest, z wyjątkiem prywatnych środowisk testowania piórem lub laboratorium testowego bezpieczeństwa, w których zapory ogniowe nie pomagają w testowaniu).

  3. W połączeniu z moim pfSense, lub firewallem granicznym NAT, łączącym sieć wewnętrzną i oddzielającym od Internetu i systemów, dostęp tylko do VPN z serwerami . Muszę VPN do moich sieci, aby dostać się na serwery, ponieważ jako takie nie ma portów podłączonych do Internetu. To zdecydowanie nie działa dla wszystkich moich VPS, ale w połączeniu z # 2 mogę mieć jeden VPS jako „bramę” przez VPNing do tego serwera, a następnie zezwolić na jego adresy IP do innych urządzeń. W ten sposób wiem dokładnie, co może, a czego nie może SSH - moje jedno urządzenie, którym jest VPN. (Lub w mojej sieci domowej za pfSense, moim połączeniem VPN, a ja jestem jedynym z dostępem VPN).

  4. Tam, gdzie # 3 nie jest wykonalne, fail2ban, skonfigurowany do blokowania po 4 nieudanych próbach i blokowania adresów IP przez godzinę lub dłużej, stanowi przyzwoitą ochronę przed ludźmi stale atakującymi z brutalnym atakiem - po prostu zablokuj je w zaporze ogniowej za pomocą fail2ban i meh. Konfiguracja fail2ban jest jednak trudna ...

  5. Ukrywanie portów przez zmianę portu SSH. Jednak NIE jest to dobry pomysł, aby obejść się również bez żadnych dodatkowych środków bezpieczeństwa - mantra „Bezpieczeństwo przez zaciemnienie” została już obalona i zakwestionowana w wielu przypadkach. Zrobiłem to w połączeniu z IDS / IPS i filtrowaniem sieci, ale nadal jest to BARDZO kiepska rzecz do zrobienia sama.

  6. OBOWIĄZKOWE uwierzytelnianie dwuskładnikowe za pośrednictwem rozwiązań uwierzytelniania dwuskładnikowego Duo Security . Na każdym moim serwerze SSH skonfigurowano Duo, tak aby aby się nawet dostać, pojawiają się monity 2FA i muszę potwierdzić każdy dostęp. (Jest to najbardziej przydatna funkcja - ponieważ nawet jeśli ktoś ma moje hasło lub włamuje się, nie może przejść obok wtyczek Duo PAM). Jest to jedna z największych zabezpieczeń na moich serwerach SSH przed nieautoryzowanym dostępem - każdy login MUSI powiązać się ze skonfigurowanym użytkownikiem w Duo, a ponieważ mam restrykcyjny zestaw, nie można zarejestrować nowych użytkowników w systemie.

Moje dwa centy za zabezpieczenie SSH. A przynajmniej moje myśli o zbliżaniu się.


1

Możesz skorzystać z aplikacji FreeOTP z RedHat zamiast z Google Authenticator. Czasami podczas aktualizacji aplikacji blokują Cię! ;-)

Jeśli chcesz używać innych tokenów sprzętowych, takich jak Yubikey lub eToken PASS lub NG, lub jeśli masz wielu użytkowników lub wiele serwerów, możesz skorzystać z zaplecza uwierzytelniania dwuskładnikowego.

Ostatnio napisałem o tym howto .


0

Niedawno napisałem mały samouczek. Zasadniczo musisz używać PKI, a mój samouczek pokazuje również, jak korzystać z uwierzytelniania dwuskładnikowego, aby uzyskać jeszcze większe bezpieczeństwo. Nawet jeśli nie użyjesz żadnej z tych rzeczy, jest też kilka ciekawostek na temat zabezpieczania serwera poprzez usunięcie słabych pakietów szyfrów i innych podstawowych informacji. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/


0

W przypadku dużej liczby użytkowników / certyfikatów rozważ integrację z LDAP. Duże organizacje używają LDAP jako repozytorium poświadczeń użytkownika i certyfikatów przechowywanych na identyfikatorach lub brelokach, niezależnie od tego, czy certyfikaty są używane do uwierzytelniania czy podpisywania wiadomości e-mail. Przykłady obejmują openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ...

Komputerami i grupami można również zarządzać w LDAP, zapewniając centralne zarządzanie danymi uwierzytelniającymi. W ten sposób działy pomocy mogą mieć punkt kompleksowej obsługi, aby radzić sobie z dużymi populacjami.

Oto link do integracji centOS: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html


0

Możesz także blokować na podstawie kraju pochodzenia, korzystając z bazy danych geoIP.

Zasadniczo, jeśli mieszkasz w USA, nie ma powodu, aby ktoś w Rosji łączył się z Twoim SSH, więc zostaną one automatycznie zablokowane.

Skrypt można znaleźć tutaj: https://www.axllent.org/docs/view/ssh-geoip/

Możesz także dodać do niego polecenia iptables (zrobiłem to dla moich kropelek), aby automatycznie usuwać cały ruch do / z tych adresów IP.


1
Czasami bazy danych GeoIP mogą się mylić - zostałem zapytany, czy byłem wczoraj w Moskwie ... eh nie! :)
Sean
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.