Linux Sunucu Güvenliği: SSH, fail2ban ve Log İzleme

Bir sunucuyu internete açtığınız andan itibaren tarama botları onu bulur; /var/log/auth.log dosyasını ilk kez açan biri genelde dakikada onlarca başarısız SSH denemesiyle karşılaşıp şaşırır. Güvenlik duvarı tek başına yetmez, çünkü açık kalması gereken portlar (SSH, web) zaten saldırının hedefidir. Bu yazıda Linux sunucu güvenliğini SSH sertleştirmeden fail2bane, otomatik güncellemelerden log izlemeye kadar katmanlı bir savunma olarak ele alıyorum.

SSH erişimini şifreyle değil anahtarla korumak neden şart?

Parola tabanlı SSH girişi, brute-force saldırılarına karşı sistemin en zayıf noktasıdır. Güçlü bir parola bile otomatik deneme botlarına karşı süresiz dayanmaz. SSH anahtar çifti oluşturmak birkaç saniyelik bir işlemdir:

ssh-keygen -t ed25519 -C "celil@sunucu"

ed25519 algoritması, RSA'ya kıyasla daha kısa bir anahtarla aynı güvenlik düzeyini sağlar ve işlemi daha hızlı yapar; bu yüzden yeni kurulumlarda tercih edilir. Eski bir sistemle uyumluluk gerekiyorsa -t rsa -b 4096 seçeneği de hâlâ güvenlidir. Anahtarı sunucuya kopyalamak için şu komut kullanılır:

ssh-copy-id -i ~/.ssh/id_ed25519.pub kullanici@sunucu-ip

Anahtarla giriş doğrulandıktan sonra parola girişini tamamen kapatın. /etc/ssh/sshd_config dosyasında şu iki satırı düzenleyin:

PasswordAuthentication no
PermitRootLogin no

PermitRootLogin no satırı, root kullanıcısının doğrudan SSH ile giriş yapmasını engeller. Saldırganların en sık denediği kullanıcı adı root olduğu için bu tek ayar saldırı yüzeyini büyük ölçüde daraltır. sudo systemctl restart sshd komutunu çalıştırmadan önce mevcut oturumunuzu kapatmayın; yeni ayarla giriş yapabildiğinizi doğrulamadan eski oturumdan çıkarsanız kendinizi sunucudan kilitleme riski doğar.

Varsayılan 22 portunu değiştirmek tek başına güvenlik önlemi sayılmaz, ama otomatik tarama botlarının büyük bölümünü eler ve log dosyalarındaki gürültüyü azaltır. sshd_config içine Port 2222 gibi bir satır eklemek yeterlidir. Port değişikliği güvenlik duvarı kuralıyla eşleşmezse SSH erişimi kesilir; bu yüzden önce ufw/iptables kuralını güncelleyin, sonra sshd servisini yeniden başlatın.

fail2ban tekrarlayan saldırıları nasıl otomatik engeller?

fail2ban, log dosyalarını sürekli izleyen ve belirlenen eşiği aşan başarısız girişleri iptables seviyesinde otomatik olarak engelleyen bir araçtır. Aracın yapılandırma seçeneklerini fail2ban'ın resmi sitesinden öğrenebilirsiniz.

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

Varsayılan jail.conf dosyasını doğrudan düzenlemeyin; paket güncellemesi geldiğinde bu dosyanın üzerine yazılır. SSH koruması için temel ayarları jail.local içine yazın:

[sshd]
enabled = true
maxretry = 5
bantime = 3600
findtime = 600

Bu ayar, 10 dakikalık bir sürede (findtime) 5 başarısız denemeden (maxretry) sonra ilgili IP'yi bir saatliğine (bantime) engeller. Servisi başlatıp durumunu kontrol edin:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Bu komut, o an engellenmiş IP'lerin listesini ve toplam engelleme sayısını gösterir. Kendinizi yanlışlıkla engellerseniz sudo fail2ban-client set sshd unbanip IP_ADRESI komutuyla engeli kaldırabilirsiniz.

fail2ban yalnızca SSH için çalışmaz; Nginx, Apache, Postfix gibi birçok servis için hazır filtre şablonları içerir. Bir web sunucusunda tekrarlayan 404 hatası üreten tarama botlarını engellemek için şu ayar kullanılır:

[nginx-botsearch]
enabled = true
maxretry = 3
bantime = 86400

Bu filtreler, /etc/fail2ban/filter.d/ klasöründeki hazır tanımlara dayanır; kendi log formatınız farklıysa buraya yeni bir filtre dosyası ekleyebilirsiniz. Yeni bir jail eklerken filtreyi önce fail2ban-regex aracıyla gerçek log satırlarına karşı test edin; üretim ortamında yanlış eşleşen bir kural meşru kullanıcıları da engelleyebilir.

Otomatik güvenlik güncellemeleri neden risk almadan kurulmalı?

Bilinen bir güvenlik açığı yamalandıktan sonra o yamayı geciktirmek, saldırı yüzeyini gereksiz yere açık tutar. Debian/Ubuntu'da unattended-upgrades paketi güvenlik yamalarını otomatik olarak uygular:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Bu paket yalnızca güvenlik havuzundan gelen güncellemeleri kurar; büyük sürüm yükseltmelerine dokunmaz, bu yüzden beklenmedik bir uygulama kırılması riski düşüktür. /etc/apt/apt.conf.d/50unattended-upgrades dosyasından hangi paket kaynaklarının dahil olduğunu görebilir ve ayarı ince ayarlayabilirsiniz.

Otomatik güncellemeler bazen yeniden başlatma gerektirir. Sunucunun beklenmedik bir anda yeniden başlamasını istemiyorsanız şu ayarı ekleyin:

Unattended-Upgrade::Automatic-Reboot "false";

Bu ayarı false yaptığınızda, yeniden başlatma gereken durumları elle takip etmeniz gerekir; /var/run/reboot-required dosyasının varlığı size bunu hatırlatır.

RHEL/CentOS ailesinde aynı işi dnf-automatic üstlenir:

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer

/etc/dnf/automatic.conf dosyasındaki upgrade_type = security ayarı, yalnızca güvenlik yamalarının otomatik kurulmasını sağlar; tüm paketleri kapsamaz. Kritik üretim sunucularında bu ayrım önemlidir; beklenmedik bir işlevsellik değişikliği riskini azaltır. Otomatik güncellemeye rağmen kritik bir CVE duyurusu geldiğinde apt list --upgradable ya da dnf check-update komutuyla bekleyen yamaları elle de kontrol edin.

Açık portları düzenli denetlemek neden tek seferlik bir iş değil?

Bir sunucu zamanla katman biriktirir: test için açılıp kapatılması unutulan bir port, artık kullanılmayan ama hâlâ çalışan bir servis. ss komutuyla dinleyen tüm portları listeleyin:

sudo ss -tulnp

Beklemediğiniz bir portun dinlediğini görürseniz, o portu hangi paketin tuttuğunu dpkg -S veya systemctl status ile bulun ve gerçekten gerekli olup olmadığını sorgulayın. ss çıktısındaki PID sütunu, portu tutan süreci doğrudan gösterir; ps -p PID -o comm= komutuyla süreç adını netleştirebilirsiniz. Dışarıdan görünürlüğü de ayrıca kontrol edin:

nmap -Pn sunucu-ip

Bu iki kontrolü aylık bir alışkanlığa çevirmek, sızan bir test servisini ya da unutulan bir geliştirme aracını saldırganlardan önce fark etmenizi sağlar. Docker kullanıyorsanız ayrı bir tuzağa dikkat edin: bir konteyner -p 0.0.0.0:5432:5432 ile başlatıldıysa, güvenlik duvarı kuralınız olsa bile Docker'ın kendi iptables zinciri bu portu dışarıya açık bırakabilir. Konteyner portlarını 127.0.0.1:5432:5432 gibi yerel arabirime bağlamak, kazara dışarı açık bir port bırakma riskini büyük ölçüde azaltır.

Log dosyalarını izlemek saldırıyı erken fark etmenin en ucuz yolu mu?

/var/log/auth.log (Debian/Ubuntu) ya da /var/log/secure (RHEL/CentOS), tüm kimlik doğrulama denemelerini kaydeder. Şüpheli etkinliği hızlıca taramak için:

sudo grep "Failed password" /var/log/auth.log | tail -30
sudo grep "Accepted password" /var/log/auth.log

İkinci komut ayrı bir önem taşır. Parola girişini kapattıysanız ve yine de "Accepted password" satırları görüyorsanız, sshd_config değişikliğiniz uygulanmamış demektir; bunu hemen araştırın. Başarılı anahtar girişlerini görmek için:

sudo grep "Accepted publickey" /var/log/auth.log | tail -10

Beklemediğiniz bir saatte ya da tanımadığınız bir IP'den gelen başarılı bir giriş, fail2ban gibi araçların yakalayamadığı bir olaydır; çünkü o giriş başarısız değil, başarılıdır. Bu yüzden yalnızca başarısız denemelere değil, başarılı girişlere de düzenli göz atmak gerekir.

Bu taramayı elle yapmak yorucudur. logwatch aracı, günlük özet raporunu e-postanıza otomatik gönderir:

sudo apt install logwatch
sudo logwatch --detail high --mailto [email protected] --range today

Bu komut, o günün önemli log olaylarını (başarısız girişler, sistem hataları, disk uyarıları) tek bir özet e-postada toplar; sabahları göz atmak, ham log dosyalarını taramaktan çok daha sürdürülebilir bir alışkanlıktır. Birden fazla sunucunuz varsa merkezi bir log toplama sistemi (örneğin rsyslog ile tek bir log sunucusuna yönlendirme) uzun vadede daha ölçeklenebilir bir çözümdür.

Katmanlı savunma pratikte neye benzer?

Tek bir önlem yeterli değildir; her katman, diğerinin kaçırdığı bir tehdidi yakalar. Aşağıdaki tablo, bu yazıda anlatılan katmanları özetler.

Bu katmanların hiçbiri tek başına yeterli değildir. fail2ban, yavaş ve dağıtık bir saldırıyı (her IP'den birkaç deneme) yakalamayabilir; otomatik güncellemeler sıfır gün (zero-day) açıklarına karşı işe yaramaz. Katmanları birlikte çalıştırmak, birinin başarısız olduğu yerde diğerinin devreye girmesini sağlar; bu yaklaşıma "ayrıntılı savunma" denir.

Öncelik sırası da önemlidir. Kısıtlı zamanınız varsa önce SSH anahtar girişini kapatın, ardından güvenlik duvarını sıkılaştırın, sonra fail2ban ve otomatik güncellemeleri ekleyin. Log izleme en son eklenecek katmandır; diğer katmanlar oturmadan log izlemeyi başa alırsanız, henüz temizlenmemiş gürültülü kayıtlarda gerçek sinyali kaçırırsınız.

Güvenlik kontrol listesini ne sıklıkla gözden geçirmelisiniz?

Bir güvenlik yapılandırması kurulduğu anda sabit kalmaz; yeni servisler eklendikçe, kullanıcılar değiştikçe kontrol listesinin de güncellenmesi gerekir. Aylık bir rutin işe yarar: ss -tulnp ile açık portları, sudo fail2ban-client status ile engelleme istatistiklerini, sudo apt list --upgradable ile bekleyen güncellemeleri gözden geçirin.

sudo apt list --upgradable

Bu üç kontrolü takvime bağlı bir alışkanlığa dönüştürmek, güvenliği tek seferlik bir kurulum değil sürekli bir süreç olarak ele almak demektir.

Kullanıcı hesaplarını da bu rutine dahil edin. Artık kullanılmayan bir hesabı bulmak için lastlog komutu işinize yarar:

lastlog | grep -v "Never logged in"

Aylarca giriş yapmamış ama hâlâ SSH erişimi olan bir hesap, gereksiz bir saldırı yüzeyidir. İşten ayrılan bir ekip üyesinin hesabını devre dışı bırakmayı es geçmek, sık karşılaşılan ama kolayca önlenebilir bir açıktır. sudo usermod -L kullanici-adi komutu hesabı kilitler ama silmez; gerektiğinde geri açmak mümkün kalır. Hesabı tamamen silmeden önce bu ara adımı tercih etmek, dosya sahipliğiyle ilgili sürpriz sorunları önler.

Yazan Celil Uyanikoglu

Bilgisayar mühendisiyim; 25 yılı aşkın süredir bilgi işlem sektörünün içindeyim. Bu blogu 2020'de, işimde her gün karşılaştığım sorunların çözümlerini bir yere yazmak için açtım: Linux, güvenlik, tarayıcılar, yapay zeka araçları. Yazdığım her rehberi önce kendi bilgisayarımda ya da sunucumda deniyorum; çalıştığını görmediğim adımı yayınlamam. Hatalı ya da eskimiş bir şey görürsen iletişim sayfasından yaz — düzeltirim.