Linux Sunucu Güvenliği Bölüm 1: SSH Hardening

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.

1. Linux Sunucu Güvenliği Bölüm 1: SSH Hardening
2. 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_config

Kullandığı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/null

Ardı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/moduli

Veya 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-2048

SSH 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 2

Ardı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 56677

Ayrı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 packets

Ayarladığı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_key

Aynı 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 no

Bağ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.com

HostKeyAlgorithms 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.com

Kullanı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 mertcangokgoz

Unutmayı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 no

SSH 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 no

Bütün bu işleri yaptıktan sonra ssh-audit aracıyla test etmeyi unutmuyoruz.

pip install ssh-audit

ve çı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-authenticator

SSH 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) y

Artı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.