Jak zahartować serwer SSH?

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.

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.

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.

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.

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 .

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.

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.

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”.

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 .

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ę.

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 .

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/

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

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.