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.
Sshd blok istemcisinin doğru oturum açma bilgisi sağlamayan IP'lerini yapın " DenyHØsts " bu işi oldukça etkili bir şekilde yapabilir. Bunu, bir şekilde dışardan erişilebilen tüm Linux kutularıma yükledim.
Bu, SSHD'ye yapılan zorla saldırıların etkili olmayacağından emin olacaktır, ancak parolanızı unutursanız (!) Bu şekilde kendinizi kilitlemeyi başarabileceğinizi unutmayın. Bu, erişiminiz olmayan uzaktaki bir sunucuda bir sorun olabilir.
Kimlik doğrulama için şifreler yerine genel/özel anahtar çiftleri kullanın.
Sunucuya erişmesi gereken her bilgisayar için parola korumalı bir SSH anahtarı oluşturun:
ssh-keygen
İzin verilen bilgisayarlardan ortak anahtar SSH erişimine izin verin:
Her bilgisayardan
~/.ssh/id_rsa.pub içeriğini sunucudaki
~/.ssh/authorized_keys satırına tek tek kopyalayın veya erişim verdiğiniz her bilgisayarda
ssh-copy-id [server IP address] komutunu çalıştırın (sunucuya girmeniz gerekir) İstemi'nde parola).
Şifre SSH erişimini devre dışı bırak:
/etc/ssh/sshd_config öğesini açın,
#PasswordAuthentication yes yazan satırı bulun ve
PasswordAuthentication no olarak değiştirin. Değişikliği uygulamak için SSH sunucusu arka plan programını yeniden başlatın (
Sudo service ssh restart).
Şimdi, SSH'yi sunucuya girmenin tek yolu
~/.ssh/authorized_keys içindeki bir satıra uyan bir anahtar kullanmaktır. Bu yöntemi kullanarak, I kaba kuvvet saldırılarına aldırış etmiyor çünkü şifremi tahmin etseler bile reddedilecek. Açık/özel anahtar çiftlerinin kaba şekilde kullanılması imkansızdır bugünün teknolojisi ile.
Öneririm:
Kaba kuvvet oturum açma girişimlerini önlemek için fail2ban kullanın.
SSH üzerinden root olarak giriş yapmayı devre dışı bırakma. Bu, bir saldırganın hem kullanıcı adını hem de şifreyi bir saldırıyı zorlaştırmak zorunda kalması gerektiği anlamına gelir.
PermitRootLogin no içine
/etc/ssh/sshd_config ekleyin.
Sunucuya SSH yapabilen kullanıcıları sınırlama. Ya grup tarafından ya da sadece belirli kullanıcılar tarafından.
Sunucuya kimin SSH atayabileceğini sınırlamak için
AllowGroups group1 group2 veya
AllowUsers user1 user2 ekleyin.
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.
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:
Sudo apt-get install libpam-google-authenticator
Her kullanıcının
google-authenticator üreten ve iki faktör cihazını yapılandırmalarına yardımcı olan
~/.google-authenticator komutunu çalıştırmasını sağlayın (örneğin, Google Kimlik Doğrulayıcı Android uygulaması).
/etc/ssh/sshd_config öğesini düzenleyin ve ayarlayın:
ChallengeResponseAuthentication yes PasswordAuthentication no AuthenticationMethods publickey,keyboard-interactive
Değişikliklerinizi
Sudo service ssh reload olarak almak için
/etc/ssh/sshd_config komutunu çalıştırın.
/etc/pam.d/sshd öğesini düzenleyin ve satırı 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: buntu'da daha iyi iki faktör ssh kimlik doğrulaması .
İşte yapılacak kolay bir şey: install fw ("karmaşık güvenlik duvarı") ve gelen bağlantıları sınırlamak için kullanın.
Komut İsteminde, şunu yazın:
$ Sudo ufw limit OpenSSH
fw yüklü 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.
localhostkonumunda dinlendiğinden emin olun.
/etc/tor/torrcöğesini açın.
HiddenServiceDir /var/lib/tor/sshve
HiddenServicePort 22 127.0.0.1:22olarak ayarlayın.
var/lib/tor/ssh/hostnamebölümüne bakın.
d6frsudqtx123vxf.oniongibi bir isim var. Bu gizli servisin adresi.
$HOME/.ssh/config açın ve birkaç satır ekleyin:
Host myhost HostName d6frsudqtx123vxf.onion ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
Ayrıca yerel Host cihazımda Tor'a ihtiyacım var. Eğer kurulursa,
ssh myhost girebilirim ve SSH Tor ile bir bağlantı açar. Diğer taraftaki SSH sunucusu, portunu yalnızca localhost'ta açar. Böylece kimse "normal internet" üzerinden bağlanamaz.
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 .
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.
Bilinen servis tarayıcıları ve engelleme listesindeki imzalarla IDS/IPS üzerinden trafiğin sınır düzeyinde filtrelemesi. Bunu Snort ile sınır güvenlik duvarım üzerinden yapıyorum (bu benim yaklaşımım, bir pfSense aracı). Bazen, VPS'lerimde olduğu gibi bunu yapamam.
SSH bağlantı noktalarının Güvenlik Duvarı/Ağ filtrelemesi. Açıkça yalnızca belirli sistemlerin SSH sunucularına 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).
PfSense veya bir sınır güvenlik duvarı ile birlikte, dahili ağa DOĞALTMAK ve İnternetten ve sistemlerden ayrılmak, 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 veya yapamayacağını 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).
# 3 mümkün olmadığında, fail2ban, 4 başarısız denemeden sonra engellemek ve IP'leri bir saat veya daha fazla süreyle engellemek için yapılandırılmış insanlara karşı sürekli olarak iyi bir korumadır bruteforcing ile saldırmak - onları güvenlik duvarında otomatik olarak fail2ban ve meh ile bloke etmek. Fail2ban'ı yapılandırmak acı verici olsa da ...
SSH portunu değiştirerek liman gizliliği. Ancak, bu, herhangi bir ek güvenlik önlemi olmadan da yapılması iyi bir fikir değildir. - "Müstehcenlik Üzerinden 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.
ZORUNLU İki Faktörlü Kimlik Doğrulama, Duo Security'nin İki Faktörlü Kimlik Doğrulama çözümleri . SSH sunucularımın her birinde Duo yapılandırılmış Bunun üzerine, içine girmek için bile, 2FA istemleri olur ve her erişimi onaylamam gerekir. (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.
FreeOTP uygulamasını Google Authenticator kullanmak yerine RedHat'tan teslim almak isteyebilirsiniz. Bazen uygulamayı güncellerken, sizi kilitler! ;-)
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, bir açık kaynaklı iki faktörlü kimlik doğrulama arka uç kullanmak isteyebilirsiniz.
Son zamanlarda bir bu konuda nasıl yazdım.
Ç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
GeoIP veritabanını kullanarak Menşe Ülkesine göre de engelleyebilirsiniz.
Temel olarak ABD’de yaşıyorsanız, Rusya’da birisinin SSH’nize bağlanması için hiçbir sebep yoktur, bu yüzden otomatik olarak engellenirler.
Betik burada bulunabilir: 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.
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/