OpenSSH Güvenlik Sertleştirme Rehberi

Yazar:komut.io ekibi
0 Yorum

Bir sunucuyu internete açtığınız anda, birkaç dakika içinde SSH portuna brute-force denemeleri gelmeye başlar. Bu gerçek. Shodan’da açık SSH portlarına baktığınızda milyonlarca sonuç görürsünüz ve bu portların büyük çoğunluğu varsayılan ayarlarla çalışıyor. Peki ya sizin sunucunuz? OpenSSH güçlü bir araç, ama varsayılan konfigürasyonu “yeterince güvenli” değil, sadece “çalışıyor.” Bu yazıda OpenSSH’i gerçekten sertleştirmek için adım adım yapmanız gerekenleri ele alacağız.

Neden Varsayılan SSH Konfigürasyonu Yetmez?

Bir Ubuntu 22.04 sunucusu kurduğunuzda gelen SSH konfigürasyonu temel işlevi yerine getirir ama güvenlik açısından pek çok kapıyı açık bırakır. Root girişine izin verir, eski şifreleme algoritmalarını destekler, boş şifreli hesapların girişine göz yumabilir ve herhangi bir IP’den bağlantı kabul eder. Bunların hepsi birer risk faktörü.

Gerçek dünya senaryosu şu: Bir müşterimin VPS’ini audit ettiğimde auth.log dosyasında günlük 50.000’i aşkın başarısız giriş denemesi görüyorum. Çoğu root, admin, ubuntu, test kullanıcı adlarıyla geliyor. Eğer zayıf bir şifre varsa, bu saldırıların başarıya ulaşması an meselesi.

SSH Konfigürasyon Dosyasına Giriş

Tüm ayarlar /etc/ssh/sshd_config dosyasında tutulur. Değişiklik yapmadan önce her zaman yedek alın:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
sudo chmod 600 /etc/ssh/sshd_config.backup

Değişikliklerinizi uygulamadan önce konfigürasyonu test etmek için şu komutu kullanın. Bu alışkanlığı edinirseniz kendinizi pek çok dertten kurtarırsınız:

sudo sshd -t

Hiçbir çıktı vermezse konfigürasyon geçerli demektir. Hata varsa satır numarasıyla birlikte gösterir.

Temel Güvenlik Ayarları

Port Değişikliği

Varsayılan 22 numaralı port, her otomatik tarayıcının ilk baktığı yerdir. Portu değiştirmek saldırıları tamamen engellemez ama otomatik tarama trafiğini dramatik biçimde düşürür. 1024 ile 65535 arasında kullanılmayan bir port seçin:

# /etc/ssh/sshd_config
Port 2299

Firewall kurallarını da güncellemeyi unutmayın:

sudo ufw allow 2299/tcp
sudo ufw delete allow 22/tcp
# ya da iptables kullanıyorsanız:
sudo iptables -A INPUT -p tcp --dport 2299 -j ACCEPT
sudo iptables -D INPUT -p tcp --dport 22 -j ACCEPT

Önemli not: Port değiştirdikten sonra mevcut bağlantınızı kapatmadan önce yeni porttan bağlandığınızı doğrulayın. Aksi takdirde kendinizi kilitleyebilirsiniz.

Root Girişini Devre Dışı Bırakma

Bu, yapabileceğiniz en kritik değişikliklerden biridir. Root olarak doğrudan SSH girişine izin vermek, saldırganlara kullanıcı adını tahmin etme yükünü ortadan kaldırır. Önce sudo yetkili bir kullanıcı oluşturun, ardından root girişini kapatın:

# Önce yönetici kullanıcı oluştur
sudo adduser sysadmin
sudo usermod -aG sudo sysadmin

# /etc/ssh/sshd_config içinde
PermitRootLogin no

Eğer bazı otomasyon araçları için root erişimi zorunluysa PermitRootLogin prohibit-password seçeneğini kullanabilirsiniz. Bu şifre girişini engellerken key tabanlı kimlik doğrulamaya izin verir.

Şifre Kimlik Doğrulamasını Kapatma

SSH key tabanlı kimlik doğrulama kullanıyorsanız, şifre ile girişi tamamen kapatın. Bu, brute-force saldırılarını neredeyse imkansız kılar:

PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no

Key tabanlı kimlik doğrulamayı etkinleştirmek için önce client tarafında key çifti oluşturun:

# Client makinede
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519

# Public key'i sunucuya kopyala
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2299 sysadmin@sunucu_ip

Ed25519 algoritmasını tercih edin. RSA’ya göre hem daha güvenli hem de daha hızlı. RSA kullanmak zorundaysanız minimum 4096 bit anahtar uzunluğu belirleyin.

Şifreleme Algoritmalarını Sıkılaştırma

Modern OpenSSH birçok algoritmayı destekler, ama hepsine ihtiyacınız yok. Zayıf ve eski algoritmalar saldırı yüzeyi oluşturur. Sunucunuzun hangi algoritmaları kullandığını görmek için:

ssh -vvv -p 2299 kullanici@sunucu_ip 2>&1 | grep -E "kex|cipher|mac"

Konfigürasyona ekleyeceğiniz sıkılaştırılmış algoritma listesi:

# /etc/ssh/sshd_config

# Anahtar değişim algoritmaları - sadece güçlü olanlar
KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# Şifreleme algoritmaları
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

# MAC algoritmaları
MACs [email protected],[email protected],[email protected]

# Host key algoritmaları
HostKeyAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

Bu ayarları uyguladıktan sonra eski istemcilerle bağlantı sorunu yaşayabilirsiniz. Eğer organizasyonunuzda eski sistemler varsa algoritmalar listesini buna göre genişletmeniz gerekebilir. Test ortamında deneyin, production’a öyle alın.

Oturum ve Bağlantı Yönetimi

Idle Bağlantıları Sonlandırma

Açık kalan ama kullanılmayan SSH oturumları güvenlik riski oluşturur. Birisi ekranı kilitlemeden uzaklaşmış olabilir, ya da zombie oturumlar sistem kaynaklarını tüketiyor olabilir:

# /etc/ssh/sshd_config
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 30

Bu ayarlar şunu yapar: Her 300 saniyede bir client’a sinyal gönderilir. İki kez yanıt gelmezse bağlantı kesilir. Yani maksimum 10 dakika idle bağlantı açık kalabilir. LoginGraceTime 30 ise kimlik doğrulamanın 30 saniye içinde tamamlanmasını zorunlu kılar, bu da yavaş brute-force denemelerini yavaşlatır.

Maksimum Deneme Sayısı

MaxAuthTries 3
MaxSessions 5
MaxStartups 10:30:60

MaxAuthTries 3: Her bağlantıda maksimum 3 kimlik doğrulama denemesi. Üçüncüden sonra bağlantı düşer.

MaxSessions 5: Tek bir bağlantı üzerinden açılabilecek maksimum kanal sayısı.

MaxStartups 10:30:60: Bu biraz karmaşık ama önemli. 10 kimlik doğrulanmamış bağlantı varken yeni bağlantıların %30’u rastgele reddedilir. 60 kimlik doğrulanmamış bağlantıya ulaşıldığında tüm yeni bağlantılar reddedilir. Bu ayar bağlantı flood saldırılarına karşı koruma sağlar.

Kullanıcı ve Grup Kısıtlamaları

Her kullanıcının SSH’e erişmesine gerek yoktur. Whitelist yaklaşımı benimseyin:

# /etc/ssh/sshd_config
AllowUsers sysadmin deploy monitoring
# ya da grup bazlı
AllowGroups sshusers admins

# Belirli kullanıcıları kesinlikle engelle
DenyUsers guest ftp backup

Grup bazlı yaklaşım çok daha yönetilebilir. Yeni bir admin eklediğinizde SSH konfigürasyonuna dokunmadan sadece sshusers grubuna eklersiniz:

sudo groupadd sshusers
sudo usermod -aG sshusers sysadmin
sudo usermod -aG sshusers deploy

IP Bazlı Erişim Kısıtlaması

Eğer sadece belirli IP adreslerinden yönetim yapıyorsanız, Match bloğuyla kısıtlama yapabilirsiniz:

# /etc/ssh/sshd_config - dosyanın sonuna ekle

# Ofis IP'sinden tam erişim
Match Address 203.0.113.0/24
    PermitRootLogin no
    PasswordAuthentication no

# VPN subnet'inden erişim
Match Address 10.8.0.0/24
    PasswordAuthentication no
    AllowUsers sysadmin deploy

# Diğer tüm IP'lerden sadece monitoring kullanıcısı
Match User monitoring Address !10.8.0.0/24,!203.0.113.0/24
    ForceCommand /usr/local/bin/monitoring-check.sh
    PermitTTY no

Diğer Kritik Parametreler

# /etc/ssh/sshd_config

# X11 yönlendirmeyi kapat (GUI uygulamaları yönlendirmiyorsanız)
X11Forwarding no

# TCP yönlendirmeyi kısıtla
AllowTcpForwarding no
# Eğer port forwarding gerekiyorsa sadece local
# AllowTcpForwarding local

# Agent yönlendirmeyi kapat
AllowAgentForwarding no

# Tünel desteğini kapat
PermitTunnel no

# Geçersiz ortam değişkenlerini engelle
PermitUserEnvironment no

# Banner ekle (caydırıcı + yasal uyarı için)
Banner /etc/ssh/banner.txt

# Sıkıştırmayı kapat (kimlik doğrulaması öncesi)
Compression no

# Yalnızca SSH protokol 2 kullan (modern dağıtımlarda zaten varsayılan)
# Protocol 2  # Bu satır modern OpenSSH'te gerekli değil

Banner dosyasını oluşturmak için:

cat > /etc/ssh/banner.txt << 'EOF'
*******************************************************************
* Bu sistem yalnızca yetkili kullanıcıların erişimine açıktır.   *
* Tüm aktiviteler kayıt altına alınmaktadır.                     *
* Yetkisiz erişim girişimleri yasal işleme tabi tutulacaktır.   *
*******************************************************************
EOF

Fail2Ban ile SSH Koruması

Konfigürasyon ayarları tek başına yetmez. Fail2Ban, başarısız giriş denemelerini izleyerek tekrarlayan saldırganları otomatik olarak engeller:

sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

SSH için özel konfigürasyon oluşturun:

cat > /etc/fail2ban/jail.d/sshd.conf << 'EOF'
[sshd]
enabled = true
port = 2299
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600
ignoreip = 127.0.0.1/8 10.8.0.0/24 203.0.113.0/24
EOF

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

Bu konfigürasyonla 600 saniye içinde 3 başarısız deneme yapan IP, 1 saat boyunca engellenir. ignoreip kısmına kendi IP aralıklarınızı ekleyerek kendinizi yanlışlıkla kilitlemekten korunun.

Fail2Ban durumunu kontrol etmek için:

sudo fail2ban-client status sshd
sudo fail2ban-client status sshd | grep "Banned IP"

# Bir IP'yi manuel engelle
sudo fail2ban-client set sshd banip 192.168.1.100

# Bir IP'nin engelini kaldır
sudo fail2ban-client set sshd unbanip 192.168.1.100

SSH Sertifika Tabanlı Kimlik Doğrulama

Büyük ortamlarda onlarca sunucu ve onlarca kullanıcı varsa, her kullanıcının public key’ini her sunucuya dağıtmak bir kabus haline gelir. SSH sertifikaları bu problemi çözer. Bir CA (Certificate Authority) kurarak merkezi yönetim sağlayabilirsiniz:

# CA key çifti oluştur (güvenli bir makinede sakla)
ssh-keygen -t ed25519 -f /etc/ssh/ssh_ca -C "SSH CA - Sirket Adi"

# Kullanıcı key'ini imzala
ssh-keygen -s /etc/ssh/ssh_ca 
    -I "[email protected]" 
    -n sysadmin,deploy 
    -V +52w 
    ~/.ssh/id_ed25519.pub

Sunucu tarafında CA’yı tanıt:

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ssh_ca.pub

Artık CA tarafından imzalanmış herhangi bir sertifika bu sunucuya girebilir. Bir çalışan ayrıldığında tek yapmanız gereken sertifikasını iptal etmek, her sunucudan tek tek key silmek değil.

Tüm Konfigürasyonu Bir Arada Görme

Tüm değişiklikleri uyguladıktan sonra konfigürasyon şöyle görünmeli:

# Konfigürasyonu gözden geçir
sudo sshd -T | grep -E "port|permitroot|passwordauth|maxauthtries|allowusers"

# Servisi yeniden başlat
sudo systemctl restart sshd

# Servis durumunu kontrol et
sudo systemctl status sshd

Yeni bir terminal açıp bağlantıyı test etmeden mevcut oturumu kapatmayın. Bu kural hayat kurtarır.

Güvenlik Denetimi ve İzleme

Konfigürasyonu yaptıktan sonra işimiz bitmedi. Düzenli izleme şart:

# Başarısız giriş denemelerini görüntüle
sudo grep "Failed password|Invalid user|authentication failure" /var/log/auth.log | tail -50

# Başarılı girişleri izle
sudo grep "Accepted " /var/log/auth.log | tail -20

# Hangi IP'ler en çok deneme yapıyor?
sudo grep "Invalid user" /var/log/auth.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# SSH bağlantı istatistikleri
sudo ss -tnp | grep sshd

Basit bir monitoring scripti:

#!/bin/bash
# /usr/local/bin/ssh-audit.sh

LOGFILE="/var/log/auth.log"
REPORT="/tmp/ssh-report-$(date +%Y%m%d).txt"
THRESHOLD=100

echo "SSH Guvenlik Raporu - $(date)" > $REPORT
echo "================================" >> $REPORT

FAILED=$(grep "$(date '+%b %d')" $LOGFILE | grep -c "Failed password")
echo "Bugun basarisiz giris: $FAILED" >> $REPORT

if [ $FAILED -gt $THRESHOLD ]; then
    echo "UYARI: Basarisiz giris sayisi esigi asti!" >> $REPORT
    # Mail gonder
    mail -s "SSH Uyarisi - $(hostname)" [email protected] < $REPORT
fi

TOP_ATTACKERS=$(grep "$(date '+%b %d')" $LOGFILE | grep "Invalid user" | 
    awk '{print $NF}' | sort | uniq -c | sort -rn | head -5)
echo -e "nEn cok deneme yapan IP'ler:n$TOP_ATTACKERS" >> $REPORT

cat $REPORT

Bu scripti crontab’a ekleyerek günlük rapor alabilirsiniz:

chmod +x /usr/local/bin/ssh-audit.sh
echo "0 8 * * * root /usr/local/bin/ssh-audit.sh" >> /etc/cron.d/ssh-audit

Sonuç

SSH sertleştirme bir kez yapıp unutulan bir iş değil, sürekli bakım gerektiren bir süreç. Temel adımları özetleyecek olursam: Varsayılan portu değiştirin, root girişini kapatın, şifre kimlik doğrulamasını devre dışı bırakın, güçlü algoritmaları zorunlu kılın, gereksiz özellikleri (X11, tünel, yönlendirme) kapatın, kullanıcı ve IP kısıtlamaları uygulayın, Fail2Ban kurun ve düzenli olarak logları izleyin.

Bu adımların hepsini uygulayan bir sunucuya otomatik saldırıların neredeyse hiçbiri geçemez. Geriye kalan risk ise hedefli saldırılar, bu da ayrı bir yazının konusu. Ama şunu söyleyeyim: Auth.log dosyanızda saatte binlerce başarısız deneme görüyorsanız, bu yazıdaki adımları uyguladıktan sonra o sayının dramatik biçimde düştüğünü göreceksiniz. Ben bu sertleştirmeleri yaptıktan sonra bir müşteri sunucusunda günlük 50.000 olan başarısız deneme sayısının 200’ün altına düştüğünü gördüm. Geri kalanları da Fail2Ban halletti.

OpenSSH güvenilir ve olgun bir yazılım. Onu zayıf yapan çoğunlukla biz sistem yöneticilerinin konfigürasyon tembelliği oluyor. Birkaç saatlik emek, potansiyel bir ihlali önlemek için fazlasıyla değer.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir