Linux sunucu sertleştirme kontrol listesi, yeni kurulan her sunucuda ilk saatte uygulanması gereken adımların toplamıdır. Çünkü internete açılan bir sunucu, DNS kaydı bile yokken dakikalar içinde otomatik taramalarla karşılaşır: varsayılan SSH portuna şifre denemeleri, bilinen açıklara yönelik istekler, açık bırakılmış veritabanı portlarını arayan botlar. Bu saldırıların büyük bölümü hedefli değildir; herkese yapılır. İyi haber şu: aşağıdaki adımlar bu genel gürültünün neredeyse tamamını eler ve hedefli bir saldırının maliyetini ciddi biçimde artırır. Liste, kendi sunucularımızda ve müşterilerimize kurduğumuz sunucularda uyguladığımız sırayla. Sertleştirme her sunucuda aynı sırayla uygulanırsa unutulan adım kalmaz; bu yüzden listeyi kurulum şablonunun parçası yapın.
Başlamadan önce: envanter ve erişim planı
Sertleştirmeye başlamadan önce üç şeyi yazılı hâle getirin: sunucuda hangi servisler çalışacak ve hangi portlar dışarıya açık olacak; sunucuya kimler, hangi yöntemle erişecek; acil durumda (SSH kilitlenirse) konsola nasıl ulaşılacak. Üçüncü madde atlanırsa, güvenlik duvarını yanlış kuran bir komut sizi kendi sunucunuzun dışında bırakır. Sağlayıcı panelinden konsol erişiminin çalıştığını ilk iş olarak doğrulayın. Yönetimsiz bir VPS, VDS veya dedicated sunucu kiraladıysanız bu iş tamamen sizindir; VPS ve VDS yazısında değindiğimiz gibi kök erişimiyle teslim edilen makine, güvenliği kurulmamış bir makinedir. Bu planı bir metin dosyasına yazıp sunucu dışında saklamak, aylar sonra "bu port neden açıktı" sorusunun cevabını verir.
SSH: en çok saldırılan kapı
SSH, sunucuya giden ana kapıdır ve otomatik saldırıların büyük çoğunluğu buraya gelir. Yapılacaklar sırayla:
- Şifreyle girişi kapatın, yalnızca anahtarla girişe izin verin (PasswordAuthentication no). Güçlü bir şifre bile kaba kuvvet trafiğini durdurmaz; anahtar durdurur.
- Root ile doğrudan girişi kapatın (PermitRootLogin no); normal kullanıcıyla girip sudo ile yükselin. Böylece hangi işlemi kimin yaptığı kayıtta görünür.
- Mümkünse SSH’ye yalnızca belirli IP adreslerinden veya bir VPN üzerinden izin verin. Ofis IP’niz sabitse bu tek adım kaba kuvvet denemelerini sıfıra indirir.
- Portu değiştirmek bir güvenlik önlemi değil, gürültü azaltma önlemidir; yapabilirsiniz ama anahtar girişi ve IP kısıtlamasının yerine geçmez.
- Kullanılmayan kimlik doğrulama yöntemlerini, X11 yönlendirmesini ve boşta kalan oturum süresini sınırlayın.
- İki faktörlü doğrulama (TOTP) ekleyerek anahtar çalınsa bile tek başına yeterli olmamasını sağlayın; yönetici erişimi olan sunucularda bu ek katman ucuzdur.
Yapılandırmayı değiştirdikten sonra mevcut oturumu kapatmadan ikinci bir pencereden giriş yapıp test edin; kilitli kalmanın en sık nedeni budur.
Güncellemeler: en ucuz ve en çok ihmal edilen önlem
Bilinen açıklara yönelik saldırılar, yaması aylar önce yayınlanmış zafiyetleri hedefler. Güvenlik güncellemelerini otomatik uygulayan bir düzen kurun (Debian ve Ubuntu’da unattended-upgrades, RHEL türevlerinde dnf-automatic). Çekirdek güncellemesi sonrası yeniden başlatma gerektiğinde bunu bildirecek bir kontrol ekleyin; aksi halde sunucu yamalı görünür ama eski çekirdekle çalışmaya devam eder. Uygulama katmanı da bu kapsama girer: PHP, veritabanı, web sunucusu ve kullandığınız kütüphaneler. Yalnızca işletim sistemini güncelleyip eski bir uygulama sürümünü yıllarca çalıştırmak, sahada en sık gördüğümüz açıklardan biridir. Güncelleme sonrası uygulamanın bozulmasından korkuluyorsa çözüm güncellememek değil, önce test ortamında denemek ve geri alınabilir bir anlık görüntü almaktır.
Güvenlik duvarı ve servis azaltma
Varsayılan kural "her şey kapalı, yalnızca gerekenler açık" olmalıdır. nftables veya ufw ile gelen trafiği varsayılan olarak reddedin; yalnızca web (80 ve 443), SSH ve uygulamanızın ihtiyaç duyduğu portları açın. Veritabanı, Redis, panel ve izleme portları dışarıya hiçbir zaman açık olmamalı; bunlara yalnızca yerel ağdan veya VPN’den erişilmeli. Ardından sunucuda çalışan servislerin listesini çıkarın ve kullanılmayanları kaldırın: posta sunucusu, yazıcı servisi, kullanılmayan paneller. Çalışmayan bir servis, güncellenmesi gereken bir servis değildir. Çıkış (outbound) trafiğini de değerlendirin; ele geçirilen sunucuların ilk yaptığı şey dışarıya bağlanmaktır ve gereksiz çıkış portlarını kapatmak bunu zorlaştırır. Birden fazla sunucunuz varsa aralarındaki trafiği de özel ağ üzerinden geçirin; veritabanı sunucusunun genel internete hiç çıkmaması en temiz yapıdır.
fail2ban ve oturum koruması
Anahtar girişi ve IP kısıtlaması yapılamayan durumlarda (ya da ek katman olarak) fail2ban, başarısız girişimleri izleyip kaynak IP’yi geçici olarak engeller. Yalnızca SSH için değil; web uygulamanızın giriş sayfası, panel girişleri ve posta servisleri için de kural yazılabilir. Burada iki pratik not var. Birincisi, kendi IP adreslerinizi beyaz listeye ekleyin; yoksa bir gün şifreyi üç kez yanlış yazıp kendinizi engellersiniz. İkincisi, fail2ban log dosyalarına dayanır; log biçimi değiştiğinde kurallar sessizce çalışmayı bırakır, bu yüzden ara sıra engellenen IP listesine bakıp çalıştığını doğrulayın. Ayrıca sudo kullanımını kayıt altına alın ve paylaşılan hesap kullanmayın; her yöneticinin kendi hesabı olsun. Kalıcı engel yerine artan süreli geçici engel kullanın; aynı IP tekrar tekrar geldiğinde süre uzasın. Böylece dinamik IP alan masum bir kullanıcı sonsuza kadar kilitli kalmaz.
İzleme ve kayıt: fark etmediğiniz saldırı, savunamadığınız saldırıdır
Sertleştirmenin son ve sürekli adımı izlemektir. Üç katman öneriyoruz. Birincisi kaynak izleme: işlemci, bellek, disk doluluğu ve ağ trafiğinde anormal artış; ani işlemci yükü çoğu zaman kripto madencisi, ani çıkış trafiği ise veri sızıntısı demektir. İkincisi kayıt (log) toplama: kimlik doğrulama kayıtları, sudo kullanımı, web sunucusu erişim kayıtları ve güvenlik duvarı düşürmeleri sunucu dışında bir yerde de tutulmalı; saldırgan sunucuyu ele geçirdiğinde ilk sildiği şey yerel kayıtlardır. Üçüncüsü bütünlük kontrolü: kritik sistem dosyalarının değişip değişmediğini izleyen bir araç (AIDE veya benzeri), rootkit taraması ve açık port listesinin düzenli karşılaştırılması. Bunların hepsi alarm üretmeli ve alarmın gittiği bir kişi olmalı; kimsenin bakmadığı bir izleme paneli, izleme değildir. Alarm eşiklerini ilk haftada gerçek değerlere göre ayarlayın; sürekli çalan alarm, kimsenin bakmadığı alarmdır.
Kontrol listesi
- Konsol erişimi doğrulandı, servis ve port envanteri yazıldı
- SSH: anahtar girişi, root girişi kapalı, IP veya VPN kısıtlaması
- Otomatik güvenlik güncellemeleri açık, yeniden başlatma bildirimi var
- Uygulama katmanı (PHP, veritabanı, web sunucusu) güncel
- Güvenlik duvarı varsayılan reddet; yalnızca gereken portlar açık
- Veritabanı, Redis ve panel portları dışarıya kapalı
- Kullanılmayan servisler kaldırıldı
- fail2ban kuruldu, kendi IP’leriniz beyaz listede
- Her yöneticinin kendi hesabı var, sudo kaydı tutuluyor
- Kayıtlar sunucu dışına kopyalanıyor; kaynak ve bütünlük alarmları tanımlı
- Yedekleme kuruldu ve geri yükleme test edildi
Bu listeyi uygulamak ortalama bir sunucuda birkaç saat alır ve sonraki yıllarda yaşanacak sorunların büyük bölümünü baştan engeller. Mevcut sunucularınızın bu listeye göre denetlenmesini veya sertleştirme işinin tamamen üstlenilmesini istiyorsanız firewall ve güvenlik hizmetlerimize göz atabilirsiniz.
