Bir SSH sunucusunu nasıl sertleştirebilirim?


128

SSH sunucumun etrafındaki güvenliğin kesinlikle sızdırmaz olduğundan emin olmak için ne gibi önlemler almalıyım?

Bu başlangıçtan itibaren topluluk wiki'si olacak, bu yüzden insanların sunucularını güvende tutmak için ne yaptığını görelim.


44
Mutlak geçirimsizlik, kutunun kapatılmasını gerektirir.
Thorbjørn Ravn Andersen

Yerel Ağda Uyanma varsa?
rebus

Sorun LAN kısmı olacaktır ... Wake-on-LAN paketleri yönlendirilmez, bu yüzden WOL paketini göndermek için LAN içindeki bir makineye erişiminiz olması
gerekirdi

Anahtar kimlik doğrulaması için, Şifreleri gerçekten ihtiyacınız olan şifrelerle sınırlayabilirsiniz.

Yanıtlar:


108

Kimlik doğrulama için şifreler yerine genel / özel anahtar çiftleri kullanın.

  1. Sunucuya erişmesi gereken her bilgisayar için parola korumalı bir SSH anahtarı oluşturun:

    ssh-keygen

  2. İzin verilen bilgisayarlardan ortak anahtar SSH erişimine izin verin:

    ~/.ssh/id_rsa.pubHer bilgisayardan içeriğini ~/.ssh/authorized_keyssunucunun tek tek satırlarına kopyalayın veya ssh-copy-id [server IP address]erişim verdiğiniz her bilgisayarda çalıştırın (istemde sunucu şifresini girmeniz gerekir).

  3. Şifre SSH erişimini devre dışı bırak:

    /etc/ssh/sshd_config, yazan satırı bul #PasswordAuthentication yesve değiştir PasswordAuthentication no. Değişikliği uygulamak için SSH sunucusu arka planını yeniden başlatın ( sudo service ssh restart).

Şimdi, SSH'yi sunucuya girmenin tek yolu hat içinde eşleşen bir anahtar kullanmaktır ~/.ssh/authorized_keys. Bu yöntemi kullanarak, ben onlar benim şifresini tahmin bile, reddedilecektir çünkü kaba kuvvet saldırılarına umurumda değil. Kamuya açık / özel bir anahtar çiftinin kaba şekilde kullanılması bugünün teknolojisi ile mümkün değildir .


5
-1: Genel olarak bilgisayarlara değil, tek tek erişime izin verilir, sunucuya bağlanan her potansiyel istemci bilgisayar için bir anahtar oluşturmak mantıksızdır. Son ifadeniz, önerinize göre doğru değil ve müşteri sistemlerinden herhangi birine erişimi olan / erişimi olan özel anahtarlar için bir parola ayarlamanızı önermediğiniz için, otomatik olarak SSH sunucusuna erişim izni verir. SSH anahtar doğrulaması önerilir, ancak özel anahtarlar uygun şekilde korunmalı ve tarif edildiği gibi dağıtılmış şekilde değil, bireysel olarak kullanılmalıdır.
João Pinto

7
"Genellikle bilgisayarlara değil, tek tek erişim sağlanır, sunucuya bağlanan her potansiyel istemci bilgisayar için bir anahtar oluşturmak mantıksızdır" Birçok seçenek var ve bence her müşteriye özel bir anahtarın nasıl güvenli bir şekilde aktarılacağını açıklamak bu sorunun kapsamı dışında görünüyor . Tüm seçenekleri sunmuyorum, insanların anlayabildiğini düşündüğüm basit bir seçenek. “... bireysel olarak kullanılmalı, açıklandığı gibi dağıtılmış bir şekilde kullanılmamalıdır” Bu önceki ifadenize aykırı görünüyor ve dağıtılmış olarak hiçbir şey tarif etmedim.
Asa Ayers,

5
"imkansız" belki de biraz abartıyor.
Thorbjørn Ravn Andersen

9
Bu yüzden "imkansız" diyorum. Kimse bilgisayarları bu kadar hızlı bu kadar küçük ya da bu kadar zaman harcayamaz. "Anahtarları şifreli bazı verilere karşı test edebilen bir kum taneciğinin büyüklüğünde bir bilgisayar hayal edin. Ayrıca bir anahtarı geçmesi için gereken süreyi ölçen bir anahtarı test edebileceğini hayal edin. Sonra bu bilgisayarların bir kümesini göz önünde bulundurun. o kadar ki, dünyayı onlarla kaplarsan, tüm gezegeni 1 metre yüksekliğe kadar kaplarlardı. Bilgisayar kümesi, ortalama olarak 1000 yılda 128 bitlik bir anahtarı kırar. ”
Asa Ayers,

@ ThorbjørnRavnAndersen "İmkansız", güçlü bir anahtar kullandığınız sürece gerçekten abartmıyor. Şu anda bir teklif bulamıyorum, ancak mevcut anahtar uzunluklarında kaba kuvvet saldırıları "bilgisayarlar maddeden başka bir şey yapıp uzaydan başka bir şeyi işgal edinceye kadar" mümkün değil.
Maximillian Laumeister,

72

Öneririm:

  • Kaba kuvvet oturum açma girişimlerini önlemek için fail2ban kullanmak .

  • SSH üzerinden root olarak giriş yapmayı devre dışı bırakın. Bu, bir saldırganın hem kullanıcı adını hem de şifreyi bir saldırıyı daha zor hale getirdiğini bulması gerektiği anlamına gelir.

    Ekle PermitRootLogin noBlogunuza /etc/ssh/sshd_config.

  • Sunucuya SSH yapabilen kullanıcıları sınırlama. Ya grup tarafından ya da sadece belirli kullanıcılar tarafından.

    Ekle AllowGroups group1 group2veya AllowUsers user1 user2sunucuya SSH kişileri sınırlamak için.


2
AllowUsers ve AllowGroups virgül kabul etmez , ayırıcı olarak. Bunu uzaktan denemediğinizden emin olun. Bunu yanlış yaparak NAS cihazımdan kilitlenmeye devam ediyorum.
sanatsız gürültü

4
Her zaman doğrulamak sizin sshdmakinenin kendinizi kilitleme önlemek için, sshd yeniden başlatmadan önce yapılandırma doğrudur. Ayrıntılar için bu blogu inceleyin - sshd -Tana bilgisayarı yeniden başlatmadan önce yalnızca yapılandırma değişikliğinden sonra çalıştırın sshd. Ayrıca, config değişikliğini yaparken makinede bir SSH oturumunun açık olmasını sağlayın ve config'i belirtilen şekilde doğrulayana ve belki de bir test SSH girişi yapmış olana kadar kapatmayın.
RichVel

24

Diğer yanıtlar güvenlik sağlar, ancak günlüklerinizi daha sessiz hale getirecek ve hesabınızdan kilitlenmemenizin daha az muhtemel olmasını sağlayacak bir şey yapabilirsiniz.

Sunucuyu 22 numaralı bağlantı noktasından diğerine taşıyın. Ya ağ geçidinizde ya da sunucuda.

Güvenliği artırmaz, ancak tüm rasgele internet tarayıcılarının günlük dosyalarınızı karıştırmayacağı anlamına gelir.


1
Gizliliğe güvenerek güvenenler için ( en.wikipedia.org/wiki/Security_through_obscurity ) başka bir limanı kullanmak çok mantıklıdır. Ben sanmıyorum ..
LassePoulsen

32
Bu, Müstehcenlik Üzerinden Güvenlik ile ilgili değildir (muğlaklığın marjinal bir olumlu etkisi olmasına rağmen). Sonsuz kaba kuvvet girişimi girişimlerinin arka plan gürültüsünü azaltmakla ilgili. Otomatik saldırılarla doluysa, erişim hatası günlüklerinizi yararlı bir şekilde denetleyemezsiniz; fail2ban, saldırganların sayısı ve dağıtılmış (botnet) ve atılan saldırıların yaygınlığı göz önüne alındığında, sesi yeterince azaltmıyor. Sıradışı bir limanda ssh ile , kayıtlarda gördüğünüz saldırıların kutunuzla ilgilenen gerçek bir saldırgandan geldiğini biliyorsunuz . Kesinlikle tavsiye ederim.
bobince

Web'e bakan web siteleri için shodan veya nmap ile banner yakalama gibi internet hizmetlerini sorgulayabildiğiniz için varsayılan portu değiştirmeyi çok anlamsız hale getirir. Buna karşı tavsiye ediyorum.
SLow Loris

Shodan, 65k portların hepsini kapmadığından yüksek bir porta geçmek muhtemelen taramalarından çıkarır. Ayrıca, rastgele bir yüksek bağlantı noktasına geçerseniz, saldırganın saldırmaya başlamak için hizmetinizi bulmak için büyük olasılıkla 65K TCP taraması yapması gerekir (çok gürültülü). Bunların her ikisi de güvenlik açısından kazanır, bu yüzden yüksek limana taşınmak genellikle iyi bir plandır. Bir diğeri yüksek noktasına taşıyarak sizi saldırıyor birileri özellikle aksine sistemlerinizi hedeflemekte olduğuna ilişkin daha iyi bir fikir olabilir sadece genel arka plan İnternet gürültüsünü için
Rоry McCune

23

HOTP veya TOTP ile iki faktörlü kimlik doğrulamayı etkinleştirin . Bu, 13: 10'dan itibaren kullanılabilir.

Bu, burada başka bir cevapta olduğu gibi, şifre kimlik doğrulaması üzerinden genel anahtar kimlik doğrulamasının kullanılmasını da içerir, ancak kullanıcının özel anahtarına ek olarak ikinci faktör cihazını tuttuğunu kanıtlamasını gerektirir.

Özet:

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

  2. Her kullanıcının , iki faktörlü aygıtlarını (ör. Google Authenticator Android uygulaması) google-authenticatoroluşturup ~/.google-authenticatoryapılandırmalarına yardımcı olan komutu çalıştırmasını isteyin.

  3. Düzenle /etc/ssh/sshd_configve ayarla:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. sudo service ssh reloadDeğişikliklerinizi almak için çalıştırın /etc/ssh/sshd_config.

  5. Düzenleyin /etc/pam.d/sshdve çizgiyi değiştirin:

    @include common-auth
    

    ile:

    auth required pam_google_authenticator.so
    

Farklı yapılandırma seçenekleriyle ilgili daha fazla ayrıntı, geçen yılki blog gönderim: Ubuntu'da daha iyi iki faktörlü ssh kimlik doğrulaması .


21

Doğru oturum açma bilgisi sağlamayan sshd bloğu istemci IP'lerini yapın " DenyHØsts " bu işi oldukça etkin bir şekilde yapabilir. Bunu, bir şekilde dışardan erişilebilen tüm Linux kutularıma kurdum.

Bu, SSHD'ye yapılan zorla saldırıların etkili olmayacağından emin olacaktır, ancak hatırlayın (!) Bu şekilde, şifrenizi unutursanız kendinizi kilitlemeyi bırakabileceğinizi unutmayın. Bu, erişiminiz olmayan uzaktaki bir sunucuda bir sorun olabilir.


2
IP adresini yasaklamadan önce 10 başarısız giriş denemesi gibi bir seçenek var mı?
sayantankhan

20

İşte yapılacak kolay bir şey: ufw'yi ("karmaşık olmayan güvenlik duvarı") yükleyin ve gelen bağlantıları sınırlamak için kullanın.

Komut isteminde şunu yazın:

$ sudo ufw limit OpenSSH 

Eğer ufw kurulu değilse, bunu yapın ve tekrar deneyin:

$ sudo aptitude install ufw 

Birçok saldırgan SSH sunucunuzu kaba kuvvetli şifreler için kullanmaya çalışacaktır. Bu, aynı IP adresinden sadece her 30 saniyede bir 6 bağlantıya izin verecektir.


+1 Sınırı kullanmak iyi olabilir. Bununla birlikte, yerleşik sftp sunucusunu kullanırken, bunun için de bağlantıları sınırladığı için sorunlarla karşılaştığımı da belirtmeliyim.
Mark Davidson,

2
@Mark - iyi nokta, ama kötü yazılmış bir SFTP istemcisi gibi gelmiyor mu? Neden daha fazla SSH kanalı açabiliyorlarsa, neden SSH portuna tekrar bağlanmaya devam ediyorlar?
mpontillo

12

Daha fazla güvenlik sağlamak veya bazı şirket ağlarının derinliklerinde SSH sunucularına erişmek istediğimde anonimleştirme yazılımı Tor kullanarak gizli bir servis kurarım .

  1. Tor'u kurun ve SSH sunucusunu kendiniz ayarlayın.
  2. Sshd'nin yalnızca dinlediğinden emin olun localhost.
  3. /etc/tor/torrc. Set HiddenServiceDir /var/lib/tor/sshve HiddenServicePort 22 127.0.0.1:22.
  4. Bak var/lib/tor/ssh/hostname. Gibi bir isim var d6frsudqtx123vxf.onion. Bu gizli servisin adresi.
  5. $HOME/.ssh/configve birkaç satır ekle:

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

Ayrıca yerel ev sahibime de Tor lazım. Eğer ssh myhostkurulursa girebilirim ve SSH Tor ile bir bağlantı açar. Diğer taraftaki SSH sunucusu portunu sadece localhost'ta açar. Böylece kimse "normal internet" üzerinden bağlanamaz.


10
Gelişmiş gizlilik ile Güvenlik, ama çok ilginç.
Johannes,

8

Bu konuda bir Debian İdaresi makalesi var. Temel SSH sunucusu yapılandırmasını ve ayrıca güvenlik duvarı kurallarını kapsar. Bu, bir SSH sunucusunu sertleştirmek için de ilgi çekici olabilir.

Bkz. Makale: SSH erişimini güvende tutmak .


3
Biraz geç, ancak lütfen soruları yanıtlarken, önemli kısımları bir linkten kopyalayın, böylece link bilgileri hala burada kalır.
umop aplsdn

1
İyi bir fikir. Buna rağmen katılmak için daha az zaman harcadığım bir dönemden geçiyorum. Cevabım bir "topluluk wiki" dir, bu nedenle zamanınız varsa bağlantı bilgilerini eklemekten çekinmeyin.
Huygens

6

SSH sertleşmesine yaklaşımım ... karmaşık. Aşağıdaki öğeler, ağlarımın en uç sınırlarından sunucuların kendilerine kadar nasıl yaptığım konusundadır.

  1. Blokaj listesindeki bilinen servis tarayıcıları ve imzalarıyla IDS / IPS üzerinden trafiğin sınır düzeyinde filtrelenmesi. Bunu Snort ile sınır güvenlik duvarım üzerinden gerçekleştiriyorum (bu benim yaklaşımım, bir pfSense aracı). Bazen, VPS'lerimde olduğu gibi bunu yapamam.

  2. Güvenlik duvarı / SSH bağlantı noktalarının ağ filtrelemesi. Açıkça, yalnızca belirli sistemlerin SSH sunucularıma erişmesine izin veriyorum. Bu, ağımın sınırındaki bir pfSense güvenlik duvarı veya açıkça yapılandırılmış her sunucudaki güvenlik duvarları aracılığıyla yapılır. Buna rağmen, bunu yapamayacağım durumlar var (ki bu, güvenlik duvarlarının olayları test etmesine yardımcı olmayacağı özel kalem testi veya güvenlik testi laboratuarı ortamları hariç, neredeyse asla durum böyle değildir).

  3. PfSense'imle veya bir iç güvenlik ağını DOĞRAYAN ve İnternet ve sistemlerden ayırma ile sınırlayıcı bir güvenlik duvarıyla birlikte, Sunuculara Yalnızca VPN Erişimi . Sunuculara ulaşmak için ağlarıma VPN girmeliyim, çünkü internete bakan bağlantı noktaları yok. Bu kesinlikle tüm VPS'lerim için işe yaramaz, ancak # 2 ile birlikte, VPN tarafından bu sunucuya 'ağ geçidi' olarak bir VPS'ye sahip olabilirim ve IP'lerinin diğer kutulara IP'lerine izin verebilirim. Bu şekilde, SSH'nin ne yapabileceğini ya da yapamayacağını tam olarak biliyorum - VPN olan tek kutum. (Veya, ev ağımda pfSense’in arkasındaki VPN bağlantım ve VPN erişimi olan tek kişi benim).

  4. # 3 uygun olmayan durumlarda, fail2, 4 başarısız denemeden sonra engellemek ve IP'leri bir saat veya daha fazla süreyle engellemek üzere yapılandırılmış olarak yapılandırılır . Fail2ban'ı yapılandırmak acı verici olsa da ...

  5. SSH portunu değiştirerek port gizleme. Bununla birlikte, bu, herhangi bir ek güvenlik önlemi olmadan da yapılması iyi bir fikir DEĞİLDİR - “Müstehcenlikle Güvenlik” mantığı birçok durumda çürütülmüş ve tartışmalıdır. Bunu IDS / IPS ve ağ filtreleme ile birlikte yaptım, ancak yine de kendi başına yapmak için ÇOK zayıf bir şey.

  6. ZORUNLU İki Faktörlü Kimlik Doğrulama, Duo Security'nin İki Faktörlü Kimlik Doğrulama çözümleri ile . SSH sunucularımın her biri Duo'da yapılandırılmış durumda, öyle ki, içeri girmek için bile 2FA istemeleri gerçekleşiyor ve her erişimi onaylamam gerekiyor. (Bu nihai faydalı özelliktir - çünkü birisi benim parolamı girse veya girse bile Duo PAM eklentilerini geçemez). Bu, SSH sunucularımdaki yetkisiz erişime karşı en büyük korumalardan biridir - her kullanıcı girişi, Duo'da yapılandırılmış bir kullanıcıya bağlanmalıdır ve kısıtlayıcı bir sete sahip olduğum için sisteme yeni kullanıcılar giremez.

SSH’yi güvenceye almak için iki kuruş. Ya da en azından yaklaşım hakkındaki düşüncelerim.


1

FreeOTP uygulamasını Google Authenticator kullanmak yerine RedHat'tan teslim almak isteyebilirsiniz. Bazen uygulamayı güncellerken, sizi kilitler! ;-)

Bir Yubikey veya eToken PASS veya NG gibi başka donanım belirteçleri kullanmak istiyorsanız veya çok fazla kullanıcı veya çok sayıda sunucunuz varsa, açık kaynaklı iki faktörlü bir kimlik doğrulama arka ucu kullanmak isteyebilirsiniz.

Son zamanlarda bunun hakkında bir şeyler yazdım .


0

Son zamanlarda bunu yapmak için küçük bir öğretici yazdım. Temel olarak, PKI kullanıyor olmanız gerekir ve benim öğreticim ayrıca daha fazla güvenlik için Two-Factor Authentication'ın nasıl kullanılacağını gösterir. Bunlardan hiçbirini kullanmasanız bile, zayıf şifreleme takımlarını ve diğer temel bilgileri kaldırarak sunucuyu güvence altına almakla ilgili bazı bilgiler de var. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/


0

Çok sayıda kullanıcı / sertifika için LDAP entegrasyonunu düşünün. Büyük kuruluşlar, sertifikaların kimlik doğrulaması için veya e-postaları imzalamak için kullanılıp kullanılmadıklarında, rozetlerde veya foblarda depolanan kullanıcı kimlik bilgileri ve sertifikaları için bir depo olarak LDAP'yi kullanır. Örnekler arasında openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ... bulunur.

Bilgisayarlar ve gruplar LDAP'ta yönetilebilir ve merkezi kimlik bilgisi yönetimi sağlanır. Bu şekilde, yardım masalarının büyük nüfuslarla başa çıkabilmek için tek bir yerden olması mümkündür.

İşte centOS entegrasyonuna bir link: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html


0

Ayrıca, coğrafi veritabanını kullanarak menşei ülkeye göre engelleyebilirsiniz.

Temel olarak ABD’de yaşıyorsanız, Rusya’daki bir kişinin SSH’nize bağlanması için hiçbir sebep yoktur, bu nedenle otomatik olarak engellenir.

Komut dosyasını burada bulabilirsiniz: https://www.axllent.org/docs/view/ssh-geoip/

Ayrıca bu IP'lere giden tüm trafiği otomatik olarak bırakmak için iptables komutlarını (damlacıklarım için yaptım) ekleyebilirsiniz.


1
Bazen GeoIP veritabanları yanlış olabilir - Bana dün Moskova'da olduğumu sordum ... ha hayır! :)
Sean
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.