Linux sunucu güvenliği: ilk gün yapılacak on iş

İnternete açılan bir sunucu, ilk on dakika içinde otomatik tarayıcıların ziyaretine uğrar. Bu ziyaretlerin çoğu varsayılan parolaları ve bilinen açıkları dener. Aşağıdaki on iş, sunucuyu kullanıma açmadan önce tamamlanmalıdır; toplam süre yarım saati geçmez.

1. Sistemi güncelleyin

Kurulum imajı her zaman güncel değildir. İlk komut güncelleme olsun: AlmaLinux ve Rocky'de dnf -y update, Debian ve Ubuntu'da apt update && apt -y upgrade. Çekirdek güncellendiyse yeniden başlatın.

2. Yönetici olmayan bir kullanıcı açın

Günlük işi root ile yapmayın. Kendi kullanıcınızı oluşturup sudo yetkisi verin. AlmaLinux ve Rocky'de yetki wheel, Debian ve Ubuntu'da sudo grubundan gelir:

useradd -m -s /bin/bash ahmet
usermod -aG wheel ahmet

Böylece hem yanlışlıkla yapılan yıkıcı komutların önüne geçer, hem de kim ne yaptı sorusunu günlüklerden cevaplayabilirsiniz. Birden fazla kişi bağlanıyorsa herkese ayrı hesap açın; ortak hesap, olay incelemesini imkânsız kılar.

3. SSH anahtarına geçin, parolayı kapatın

Bu, listedeki en önemli maddedir. Kendi makinenizde anahtar üretin:

ssh-keygen -t ed25519 -C "isim@makine"

Genel anahtarı sunucuya kopyaladıktan ve yeni bir terminalde girişi doğruladıktan sonra /etc/ssh/sshd_config içinde şunları ayarlayın:

• PasswordAuthentication no
• PermitRootLogin prohibit-password
• PubkeyAuthentication yes

Servisi yeniden başlatmadan önce mevcut oturumunuzu kapatmayın. Yeni bir pencerede giriş yapabildiğinizi doğrulayın; ancak ondan sonra eski oturumu bırakın. Bu alışkanlık, kendinizi sunucudan kilitlemenin en yaygın yolunu ortadan kaldırır.

4. Güvenlik duvarını varsayılan reddet ile kurun

Doğru yaklaşım "her şey kapalı, gerekenler açık" dır. AlmaLinux'ta firewalld, Ubuntu'da ufw kullanılır. Tipik bir web sunucusunda açık kalması gerekenler: SSH (22), HTTP (80), HTTPS (443) ve posta sunucusu varsa ilgili portlar. Veritabanı portunu (3306, 5432) internete asla açmayın; uygulama aynı sunucudaysa yerel arayüzü, ayrı sunucudaysa özel ağı kullanın.

firewall-cmd --permanent --add-service={ssh,http,https}
firewall-cmd --reload

Ubuntu tarafındaki karşılığı ufw default deny incoming ile başlayıp gerekli servisleri tek tek eklemektir. Kuralları uygulamadan önce sunucunun konsol erişiminin (panel üzerinden KVM veya kurtarma modu) çalıştığını doğrulayın: güvenlik duvarını yanlış kurup kendini dışarıda bırakmak, yeni sunucularda en sık yaşanan kazadır.

5. Kaba kuvvet denemelerini otomatik engelleyin

fail2ban, günlükleri izleyip belirli sayıda başarısız denemeden sonra IP adresini geçici olarak engeller. SSH için varsayılan yapılandırma yeterlidir; web uygulamanızın giriş sayfası için de bir kural yazmak faydalıdır. Ayarlar /etc/fail2ban/jail.local dosyasına yazılır; ana yapılandırmayı düzenlemeyin, güncellemede üzerine yazılır:

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

Kurduktan sonra çalıştığını fail2ban-client status sshd ile doğrulayın; engellenen IP sayısı birkaç saat içinde artmaya başlar. Anahtar tabanlı girişe geçtiyseniz SSH tarafındaki risk zaten düşer, ama günlük gürültüsünü azaltmak da bir kazançtır.

6. Otomatik güvenlik güncellemelerini açın

AlmaLinux'ta dnf-automatic, Ubuntu'da unattended-upgrades paketi yalnız güvenlik yamalarını otomatik uygular. Uygulama sürümlerini otomatik güncellemek risklidir, ama güvenlik yamalarını elle beklemek daha risklidir. Yeniden başlatma gerektiren güncellemeler için bir bakım penceresi belirleyin.

7. Zaman eşitlemesini doğrulayın

chronyd veya systemd-timesyncd çalışıyor olmalı. Saati kaymış bir sunucuda TLS doğrulaması, iki adımlı kimlik doğrulama ve günlük ilişkilendirme bozulur. Olay incelemesinde en çok ihtiyaç duyulan şey doğru zaman damgasıdır.

8. Günlükleri okunur hale getirin

journalctl kalıcı saklamaya alınsın ve disk kotası tanımlansın. Web sunucusu ve uygulama günlükleri için logrotate kurallarını kontrol edin; sınırsız büyüyen bir günlük dosyası, diski dolduran en yaygın sebeptir.

9. İzleme ve uyarı bağlayın

Disk doluluğu, bellek, yük ortalaması ve servis durumu için eşik tabanlı uyarı kurun. Sunucunun kapandığını müşteriden öğrenmek kabul edilebilir değildir. Hangi metriklerin hangi eşikle izleneceğini ayrı bir yazıda ele aldık.

10. Yedeği kurun ve bir kez geri dönün

Sunucu üretime girmeden önce yedekleme çalışıyor olmalı ve en az bir geri dönüş denemesi yapılmış olmalı. 3-2-1 kuralı burada da geçerlidir; yedeği aynı sunucuda tutmak yedek sayılmaz.

Bitirmeden önce doğrulayın

Yapılandırma dosyasına satır yazmak işi bitirmez; servisin o satırı gerçekten okuduğunu görmek bitirir. Altı komut, listenin tamamını sınar:

Sık yapılan dört hata

• SSH portunu değiştirmeyi güvenlik sanmak. Farklı port, otomatik tarayıcıların gürültüsünü azaltır ama hedefli bir saldırganı bir dakika bile oyalamaz. Anahtar tabanlı girişin yerine geçmez.
• Tek anahtarı herkesle paylaşmak. Ekipten biri ayrıldığında tüm sunucularda anahtar değiştirmeniz gerekir. Kişi başına ayrı anahtar kullanın.
• İzinleri 777 yapıp geçmek. "Çalışmıyordu, açtım" ile başlayan her dizin, dosya yükleme açığının hedefidir. Web kullanıcısına yalnız yükleme klasöründe yazma verin.
• Kurulumla gelen örnek uygulamaları bırakmak. Panel demo sayfaları, test veritabanları ve varsayılan parolalı yönetim arayüzleri kaldırılmadıkça açık kapıdır.

Ayda bir tekrarlanacaklar

• Açık port taraması yapın; beklemediğiniz bir servis dinliyorsa sebebini bulun.
• Kullanıcı hesaplarını gözden geçirin; ayrılan kişilerin anahtarlarını kaldırın.
• Sertifika yenilemelerinin çalıştığını doğrulayın.
• Güncelleme sonrası servislerin gerçekten yeniden başlatıldığını kontrol edin.

Ayarı yazdınız ama sunucu dinlemiyor: SSH'ın gizli ayar dosyaları

SSH sertleştirmesinin en sinsi tuzağı şudur: /etc/ssh/sshd_config dosyasına PasswordAuthentication no yazarsınız, servisi yeniden yüklersiniz, her şey yolunda görünür; ama sunucu parola kabul etmeye devam eder. Ubuntu 24.04 bulut imajında bunu birebir denedik. Sebep, ana dosyanın en üstündeki şu satırdır:

Include /etc/ssh/sshd_config.d/*.conf

OpenSSH bir ayarın ilk gördüğü değerini kullanır. Bulut imajları ve kurulum araçları sshd_config.d dizinine kendi dosyalarını bırakır; bizim denediğimiz imajda 50-cloud-init.conf içinde PasswordAuthentication yes vardı. Bu dosya ana dosyadaki satırdan önce okunduğu için sizin yazdığınız değer hiç devreye girmez.

Tahmin etmek yerine sunucunun gerçekte hangi değeri kullandığını sorun:

sshd -T | grep -E '^(passwordauthentication|permitrootlogin|kbdinteractiveauthentication) '

Ana dosyayı düzenlediğimiz denemede bu komut hâlâ passwordauthentication yes döndürdü. Kalıcı çözüm, ayarları alfabetik olarak en önce okunacak bir dosyaya yazmaktır:

printf 'PasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitRootLogin prohibit-password\n' \
  > /etc/ssh/sshd_config.d/00-guvenlik.conf
sshd -t && systemctl reload ssh

sshd -t yapılandırmayı uygulamadan sınar; yazım hatası varsa satır numarasıyla söyler ve sıfırdan farklı kodla çıkar. Bu yüzden yeniden yükleme komutunu && ile ona bağlayın: hatalı yapılandırma hiç devreye girmez. Sonra sshd -T ile tekrar bakın; prohibit-password değerinin çıktıda without-password olarak görünmesi normaldir, ikisi aynı ayarın adıdır.

Son adım dışarıdan sınamaktır. Başka bir makineden yalnız parola yöntemiyle bağlanmayı deneyin; cevap Permission denied (publickey) olmalı:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no root@SUNUCU_IP

Güvenlik duvarında sırayı ters çevirmeyin

ufw'yi açmadan önce SSH izni verilmelidir; tersi, açık oturumunuzu korur ama yeni bağlantıyı keser. Doğru sıra ufw allow OpenSSH, ardından ufw enable, en son ufw status verbose çıktısında Default: deny (incoming) ve 22/tcp satırını görmektir. SSH'ı yalnız kendi IP adresinize açmak istiyorsanız önce adresinizi öğrenin: IP adresim. Kendinizi yine de dışarıda bıraktıysanız, sunucuya ağdan bağımsız erişim veren konsol kurtarma yoludur. Paketinizde konsol erişimi olup olmadığını ilk gün öğrenin; varsa bir kez giriş yapmayı deneyin, yoksa SSH ayarlarına dokunmadan önce ikinci bir oturum açık tutun.

Bu liste ne zaman yetmez?

Yukarıdaki on iş işletim sistemi katmanını korur. Gerçek dünyada ihlallerin çoğu o katmandan değil, uygulamadan gelir: güncellenmemiş bir eklenti, doğrulaması eksik bir dosya yükleme formu, yönetim paneline konmuş zayıf bir parola. Sunucuyu kusursuz sertleştirseniz de eski sürüm bir içerik yönetim sistemi sizi kaybettirir. Bu yüzden liste bittiğinde iş bitmez; uygulama güncellemeleri, yükleme klasöründe kod çalıştırmanın engellenmesi ve yönetim arayüzüne IP kısıtı aynı gün planlanmalıdır.

Sunucuda birden çok müşteri veya birbirinden bağımsız proje barındıracaksanız tek kullanıcıyla yetinmeyin; her siteyi ayrı sistem kullanıcısı ve ayrı PHP havuzu altında çalıştırın. Aksi halde bir sitenin açığı diğerlerinin dosyalarına erişim demektir.

Bu bakımı üstlenecek kaynağınız yoksa, yönetim yükünü barındırma sağlayıcısına bırakan paylaşımlı veya bayi hosting seçenekleri, sahipsiz kalan bir sunucudan çok daha güvenlidir.

Sık sorulan sorular