Twitter üzerinden bahsettiğim gibi Blue Team makalelerinin ilki olan SSH Hardening ile karşınızdayım. Paketinden yeni çıkmış bir sunucuyu kurarken ilk öncelikli olarak eriştiğimiz yer önemlidir, yollar eninde olmasa bile sonunda OpenSSH kardeşimizden geçer.
- Linux Sunucu Güvenliği Bölüm 1: SSH Hardening
- Linux Sunucu Güvenliği Bölüm 2: Kernel Hardening
Bir gün işleri büyüyen ve kullandığı hostingin yetmediğini gören engin(aşağıdaki çizgili)
Bir bilişim işlerinden anlayan arkadaşına danışmış ve ufak çaplı bir sanal sunucu almış. Ancak güvenlik konusunda hiç bir bilgisi olmadığı ve arkadaşıda söylemediği için otomatik ssh brute-force saldırısı yapan botlar tarafından hacklenmiş.
Peki ne yapması gerekiyordu?
Host Anahtarlarının Değiştirilmesi
Ön tanımlı olarak SSH zaten güvenli başka bir şey yapılmasına gerek yok diye düşünmeyin sonuçta bu bir yazılım ve bu yazılımında kendince açıkları ve zayıf olduğu düşünülen yerler bulunuyor. Bunlardan ilki güncel kriptolojik teknikler kullanarak anahtarların yenilenmesi ve güncel teknolojinin kullanılmasıdır.
Yapacaklarımızın hemen öncesinde mevcut kullandığınız sshd_config dosyasının yedeğini almayı unutmayın. Yapacağınız yanlış bir hamle sunucu ile olan bağlantınızı kesebilir.
cp /etc/ssh/sshd_config /etc/ssh/backup.sshd_configKullandığınız eski anahtarları kaldırmalısınız, merak etmeyin bir sıkıntı yaşamazsınız.
cd /etc/ssh/
rm /etc/ssh/ssh_host_*Hemen ardından yeni standartlara uygun anahtarları üretelim.
ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N "" < /dev/null
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "" < /dev/nullArdından kriptografik açıdan zayıf olduğu düşünülen moduli.safe dosyası içerisinde gereken değişiklikleri yapıyoruz, zaten herhangi bir audit aracı ile kontrol ettiğiniz anda size Diffie Hellman hakkında gereken bilgiyi verecek ve güvensiz diyecektir çünkü bu değerlerin benzersiz yani uniq olması gerekmektedir ancak genelde bu ön tanımlı olarak gelir.
awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.safe
mv /etc/ssh/moduli.safe /etc/ssh/moduliVeya direk olarak aşağıdaki işlemleri yaparak sıfırdan oluşturabilirsiniz.
ssh-keygen -G moduli-2048.safe-b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.safe
cp moduli-2048 /etc/ssh/moduli
rm moduli-2048SSH Yapılandırmasının İyileştirilmesi
Şimdi bu değişikliklerin ikinci aşamasına geçiş yapıyoruz ve sshd_config dosyasını başlıyoruz düzenliyoruz böylelikle bir takım saldırılardan otomatik olarak kurtulmuş olacağız.
Önce SSH protokolümüzü değiştiriyoruz, ön tanımlı olarak 2 kullanılıyor ancak siz genede benim gibi sağlamcı olup düzenlemeyi yapın.
Protocol 2Ardından SSH servisimizin kullandığı portu en çok kullanılan portların aralığından çıkıyoruz yani 1024 ile 65535 arasından bir seçim yapıyoruz.
port 56677Ayrıca aşağıdaki portlardan herhangi birisinide kullanmayın, çünkü en fazla port taraması yapılan portların listesidir kendileri,
[+] Top 20 scanned ports:
tcp 23 2760 packets
tcp 3389 2561 packets
tcp 8080 351 packets
tcp 5555 331 packets
tcp 81 253 packets
tcp 8291 223 packets
tcp 8545 217 packets
tcp 8089 216 packets
tcp 2323 212 packets
tcp 1433 211 packets
tcp 8443 178 packets
tcp 8088 170 packets
tcp 6379 110 packets
tcp 5900 107 packets
tcp 5038 104 packets
tcp 9200 104 packets
tcp 2375 103 packets
udp 5060 599 packets
udp 123 168 packets
udp 1900 124 packets
udp 161 102 packets
udp 389 92 packets
udp 5683 46 packets
udp 1194 45 packets
udp 11211 43 packets
udp 111 42 packets
udp 5632 41 packets
udp 5353 40 packets
udp 19 32 packets
udp 1434 32 packets
udp 3702 31 packets
udp 3283 31 packets
udp 623 29 packets
udp 47808 27 packets
udp 6881 27 packets
udp 17 25 packetsAyarladığımız host anahtalarını tanımlama sırası geldi, geriye kalan diğerlerini yapılandırma dosyanızdan lütfen çıkartın zaten artık aşağıdaki ikisini kullanacağız.
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_keyAynı anda kaç kişinin ssh üzerinden bağlanacağını ve bağlantılarda kaç kez giriş isteği yapabileceklerini belirliyoruz, yüksek bir değer vermenize gerek yok. Ayrıca bağlanan bu kişilerin sistemde ne kadar zaman geçireceğinide belirleyeceğiz ki hiç bir işlem yapılmadığında otomatik çıkış yapılsın.
MaxAuthTries 3
MaxSessions 1
ClientAliveInterval 300
Parola ile girişi kapatacağız ve klavye ile etkileşimli olan protokolü devre dışı bırakacağız, bunun temel sebeplerinden bir tanesi artık public key kullanacak ve ssh anahtarımız ile sisteme giriş yapacak olmamızdır. Key oluşturmak için SSH Key Oluşturma İşlemi makalesinden faydalanabilirsiniz.
PasswordAuthentication no
ChallengeResponseAuthentication noBağlantı başına anahtarlar oluşturmak için kullanılan anahtar değişim yöntemini, bağlantıdan sonra kullanılacak kriptografik anahtarı ve bir SSH sunucusunun bir SSH istemcisine kendi kimliğini doğrulaması için kabul edilen genel anahtar algoritmalarını tanımlıyoruz.
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.comHostKeyAlgorithms belirleme aşamasında ssh -Q key dan faydalanılır, destekleyen keyler bu şekilde bulunur ve eklenir.
root@ankara:/etc/ssh# ssh -Q key
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.comKullanıcı Kısıtlamaları
Ön tanımlı olarak sisteme her kullanıcı girebilir, buna root yani kök kullanıcıda dahil bu istediğimiz bir şey değil ve değiştirmemiz gerekiyor ki işleri biraz daha zorlaştıralım, SSH üzerinden direk olarak root kullanıcı adıyla bağlantı yapılmasına izin vermiyoruz bundan böyle sudo kullanacağız ve kullanıcı tanımlamasınıda ayrıca yapıyoruz ki her kullanıcı bağlanmasın.
PermitRootLogin no
AllowUsers mertcangokgozUnutmayın bağlanmasını istediğiniz her kullanıcıyı tek tek tanımlamanız gerekiyor.
X11Forwarding ve AllowAgentForwarding Devre Dışı Bırakmak
CLI ile bağlantı kurduğumuz bir sistemde kullanıcı arayüzüne gerek yok bu sebeple yönlendirmesinede gerek yok, ayrıca güvenlik sebebiyle agentinde yönlendirmeyi kabul etmesine gerek yok tünelleme işlemi yapılmayacak sonuçta
X11Forwarding no
AllowAgentForwarding noSSH Banner Devre Dışı Bırakmak
Ben bütün işleri debian üzerinde yaptığım için sistemdeki hiç bir ön tanımlı yazının sızmaması ve bağlantı sağlandığında hiç bir şey yazmasını istemiyorum ve bu yüzden kapatmayı tercih ediyorum.
Banner none
DebianBanner noBütün bu işleri yaptıktan sonra ssh-audit aracıyla test etmeyi unutmuyoruz.
pip install ssh-auditve çıkan sonuç misler gibi
Unutmayın bu test sonucu sadece dışarıdan ssh bağlantılarındaki güvenliği test etmek amaçlıdır.
SSH Bağlantıları İçin 2FA Nasıl Aktif Edilir?
Google Authenticator PAM, uygulaması ve kullanımı diğer kimlik doğrulama modüllerinden daha kolay olduğu için bu kütüphane üzerinden yürüyeceğiz ve 2FA aktif edeceğiz. Pek fazla bilginiz yoksa aşağıdaki adımları yapmayınız. Yoksa sunucuya erişiminiz doğrudan kesilecektir.
Gerekli olan kütüphaneyi sistemimize dahil edelim
apt install libpam-google-authenticatorSSH yapılandırmanıza nano /etc/pam.d/sshd aşağıdaki değişiklikleri uygulayın.
auth required pam_google_authenticator.so nullok
auth required pam_permit.so
Ardından ana SSH yapılandırmanız da nano /etc/ssh/sshd_config içerisinde yer alan ChallengeResponseAuthentication değerini “yes” olarak değiştirin. Bu, SSH kardeşimize, biri sistemde oturum açmaya çalıştığında kimlik doğrulama kodu istemesini söyleyecek böylece 2FA girebileceğiz.
Kayıt edip çıkın ve ssh servisini systemctl restart sshd.service aracılığı ile yeniden başlatın. Yapılandırmamız SSH tarafında tamamlanıyor. Şimdi sırada google servisini yapılandırmak var. Bunun için terminalde google-authenticator komutunu çalıştırın ve adımları uygulayın. Kare kodu telefonunuzdan okutmayı unutmayın.
Do you want authentication tokens to be time-based (y/n) y
Do you want me to update your "/root/.google_authenticator" file? (y/n) y
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) n
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) yArtık işlem tamamlandı her SSH bağlantısı yaptığınız sırada karşınıza 2FA isteyen bir ekran gelecek. Google Authenticator veya Authy kullanabilirsiniz.
Dipnot: SSH Key ile auth olunan sunucularda yukarıdaki işlemlerin çalışmayacağını şimdiden hatırlatayım.