Linux Sunucu Güvenliği: Temel Sertleştirme Adımları

Yeni bir VPS açıp üzerine siteyi kurduğunuz anda, sunucunuz internetteki otomatik tarayıcıların listesine girer. Birkaç saat içinde /var/log/auth.log ya da journalctl çıktısında, "root", "admin", "test" gibi kullanıcı adlarıyla yapılan yüzlerce başarısız SSH denemesi görürsünüz. Bunlar size özel saldırılar değil; zayıf bırakılmış her sunucuyu arayan robotlar. Temel sertleştirme, bu robotların işini imkânsız hâle getiren bir dizi basit ayardır: parola yerine SSH anahtarı, kapalı root girişi, yalnızca gereken portların açık olduğu bir güvenlik duvarı, fail2ban, otomatik güvenlik güncellemeleri, korunan bir kontrol paneli ve her işin en az yetkiyle yapılması. Aşağıdaki kontrol listesini katmanlara göre grupladık; komut örnekleri Debian/Ubuntu tabanlı sistemler içindir.

Önce Önceliklendirin: İlk 30 Dakika ve İlk Hafta

Her şeyi aynı gün yapmak zorunda değilsiniz, ama bazı adımlar sunucu internete açıldığı anda tamamlanmalı.

1. Hesaplar ve SSH Erişimi

• Sistemi güncelleyerek başlayın. Sağlayıcıların hazır imajları çoğu zaman haftalar önce hazırlanmıştır. İlk iş sudo apt update && sudo apt full-upgrade ve gerekiyorsa yeniden başlatma.
• Kendi kullanıcınızı oluşturun, root'u günlük işlerde kullanmayın. adduser onur ve usermod -aG sudo onur ile yönetici yetkisini sudo üzerinden verin (kullanıcı adı örnektir). Böylece her yönetici işlemi kayıt altına girer ve kimin ne yaptığı izlenebilir.
• Parola yerine SSH anahtarı kullanın. Kendi bilgisayarınızda ssh-keygen -t ed25519 ile anahtar çifti üretin, açık anahtarı ssh-copy-id onur@sunucu-ip ile sunucuya kopyalayın. Ubuntu'nun OpenSSH dokümantasyonu da ed25519 anahtar kullanımını ve authorized_keys izinlerinin doğru olmasını öneriyor. Özel anahtarı bir parola ile koruyun; dizüstü bilgisayarın çalınması sunucunun da çalınması anlamına gelmesin.
• Root girişini ve parola doğrulamasını kapatın. OpenSSH'nin varsayılanında PasswordAuthentication yes'tir, yani parola ile giriş açıktır. Ayarı ana dosya yerine /etc/ssh/sshd_config.d/ altındaki bir dosyada yapmak, paket güncellemelerinde çakışmayı önler. Örnek /etc/ssh/sshd_config.d/10-sertlestirme.conf içeriği: PermitRootLogin no, PasswordAuthentication no, KbdInteractiveAuthentication no, MaxAuthTries 3, AllowUsers onur. Bazı imajlar bu klasöre parola girişini açan kendi dosyalarını koyar; klasördeki diğer dosyaları da kontrol edin.
• Değişikliği güvenli uygulayın. sudo sshd -t ile yapılandırmayı test edin, ardından SSH servisini yeniden yükleyin. Mevcut oturumu kapatmadan ikinci bir terminalden anahtarla giriş yapabildiğinizi doğrulayın. Kendinizi kilitlerseniz sağlayıcının web konsolu tek çıkış yolunuzdur; bu konsolun nerede olduğunu baştan öğrenin.
• Port değiştirmek mi? SSH'yi 22 dışında bir porta almak günlüklerdeki gürültüyü azaltır ama gerçek bir güvenlik katmanı değildir; hedefli bir tarama yeni portu kısa sürede bulur. Asıl korumayı anahtar doğrulama ve IP kısıtı sağlar. Port değiştirirseniz güvenlik duvarı kuralını önce açmayı unutmayın.
• Mümkünse SSH'yi IP ile sınırlayın. Ofisinizin sabit IP'si ya da bir VPN varsa, SSH'ye yalnızca oradan izin vermek en etkili önlemdir. Ofis ağı ve VPN kurulumu için küçük ofis ağ kurulumu yazımıza bakabilirsiniz.

2. Ağ ve Güvenlik Duvarı

• Varsayılan politika: gelen her şeyi reddet. Ubuntu'da UFW ile: sudo ufw default deny incoming, sudo ufw default allow outgoing, ardından yalnızca gerekenler: sudo ufw allow OpenSSH, sudo ufw allow 80/tcp, sudo ufw allow 443/tcp. SSH kuralını eklemeden sudo ufw enable çalıştırmak, kendinizi dışarıda bırakmanın en hızlı yoludur.
• IP kısıtlı kurallar yazın. SSH ve panel gibi yönetim portları için: sudo ufw allow from 203.0.113.25 to any port 22 proto tcp (IP örnektir). Herkese açık olması gerekenler yalnızca web portlarıdır.
• Dinleyen servisleri listeleyin. sudo ss -tulpn çıktısında beklemediğiniz her satır bir soru işaretidir. Veritabanı (3306, 5432), Redis (6379) ya da Elasticsearch gibi servisler yalnızca 127.0.0.1 üzerinde dinlemeli; uygulama aynı sunucudaysa dış dünyaya açılmalarına gerek yoktur.
• Docker kullanıyorsanız dikkat. Docker, yayınlanan portlar için kendi iptables kurallarını ekler ve bu kurallar UFW'yu atlayabilir. Konteyner portlarını yalnızca 127.0.0.1:8080:80 gibi yerel adrese bağlayın ve dışarıya ters vekil (reverse proxy) üzerinden açın.
• Sağlayıcı güvenlik duvarını ikinci katman olarak kullanın. Çoğu bulut ve VPS sağlayıcısı, sunucunun önünde çalışan bir ağ güvenlik duvarı sunar. Sunucu içindeki kurallarla birlikte kullanıldığında, bir yapılandırma hatası tek başına sunucuyu açıkta bırakmaz.
• Web trafiğini bir koruma katmanının arkasına alın. Cloudflare gibi bir hizmet kullanıyorsanız, 80/443 portlarını yalnızca o hizmetin IP aralıklarına açmak doğrudan sunucuya yapılan saldırıları keser. Ayrıntılar için Cloudflare rehberimize göz atın.

3. Saldırı Denemelerine Karşı: fail2ban

• Kurun ve yerel yapılandırma dosyası oluşturun. fail2ban, günlüklerde tekrarlayan başarısız girişleri tespit edip kaynağı belirli bir süre engelleyen bir servistir. sudo apt install fail2ban sonrası ayarları paketle gelen dosyaya değil, /etc/fail2ban/jail.local dosyasına yazın; güncellemeler bu dosyayı ezmez.
• SSH hapsini (jail) etkinleştirin. Örnek değerler: [sshd] bölümünde enabled = true, maxretry = 5, findtime = 10m, bantime = 1h. Kendi IP'nizi ignoreip satırına eklemek, yanlışlıkla kendinizi engellemenizi önler.
• Günlük kaynağını kontrol edin. Bazı güncel dağıtımlar varsayılan olarak auth.log dosyası tutmaz, kayıtlar yalnızca systemd günlüğündedir. Bu durumda fail2ban "günlük dosyası bulunamadı" hatası verir ya da hiçbir şey yakalamaz; backend = systemd ayarı gerekir. Kurulumdan sonra sudo fail2ban-client status sshd ile hapsin gerçekten çalıştığını görün.
• Diğer servisler için de hapis tanımlayın. Nginx kimlik doğrulama hataları, panel girişleri, posta sunucusu ve CMS yönetici sayfası için hazır ya da özel filtreler kullanılabilir. Tekrar eden saldırganlar için recidive hapsi, kısa yasakları atlatıp dönenlere daha uzun yasak uygular.
• Anahtar doğrulamayla birlikte düşünün. Parola girişi kapalıysa SSH kaba kuvvet saldırıları zaten başarısız olur; fail2ban burada günlük gürültüsünü ve kaynak tüketimini azaltır. Asıl değeri, parola ile korunan web panelleri ve uygulama girişlerinde ortaya çıkar.

4. Güncellemeler ve Yama Yönetimi

• Otomatik güvenlik güncellemelerini açın. Ubuntu dokümantasyonuna göre unattended-upgrades paketi varsayılan olarak kuruludur ve güvenlik güncellemelerini günlük uygular; ayar /etc/apt/apt.conf.d/20auto-upgrades dosyasındadır. Debian'da ve hazır imajlarda paketin kurulu ve etkin olduğunu mutlaka kontrol edin.
• Yeniden başlatma gereksinimini takip edin. Çekirdek ve temel kütüphane güncellemeleri, yeniden başlatma ya da servislerin yeniden yüklenmesi olmadan etkili olmaz. /var/run/reboot-required dosyasının varlığı bunun işaretidir; needrestart aracı hangi servislerin eski kütüphaneyle çalıştığını gösterir. Bakım penceresi belirleyin.
• Sistem dışı yazılımları unutmayın. İşletim sistemi güncellemeleri; WordPress çekirdeğini, eklentileri, Composer ya da npm bağımlılıklarını, Docker imajlarını kapsamaz. Bunlar için ayrı bir kontrol takvimi gerekir. Saldırıların önemli bir kısmı işletim sistemi yerine güncellenmemiş uygulama katmanından gelir; bu durumda yapılacaklar site hacklendiğinde ilk 24 saat yazımızda.
• Destek süresi biten sürümlerden çıkın. Desteği sona ermiş bir dağıtım sürümü artık güvenlik yaması almaz. Sunucuyu kurarken uzun süreli destek (LTS) sürümü seçin ve destek bitiş tarihini takvime yazın.

5. Kontrol Paneli Güvenliği

cPanel, Plesk, aaPanel, Webmin gibi paneller sunucu yönetimini kolaylaştırır, ama aynı zamanda internete açık, yüksek yetkili bir giriş kapısıdır. Panel ele geçirilirse SSH sertleştirmesinin hiçbir anlamı kalmaz.

• Panel portunu herkese açmayın. Yönetim arayüzüne yalnızca belirli IP'lerden ya da VPN üzerinden erişilsin. IP kısıtı mümkün değilse en azından panelin sunduğu özel giriş yolu, iki adımlı doğrulama ve giriş denemesi sınırı açık olmalı.
• İki adımlı doğrulamayı zorunlu kılın. Panel ve panelin bağlı olduğu e-posta hesabı için.
• Paneli güncel tutun. Panel yazılımlarındaki açıklar, saldırganların en sevdiği hedeflerdendir. Otomatik güncelleme seçeneğini açın ve sürüm notlarındaki güvenlik duyurularını takip edin.
• Kullanılmayan eklenti ve uygulamaları kaldırın. Tek tıkla kurulan dosya yöneticisi, veritabanı arayüzü (phpMyAdmin gibi) ve terminal eklentileri ek saldırı yüzeyidir. Kullanmıyorsanız kaldırın; kullanıyorsanız ek kimlik doğrulamanın arkasına alın.
• Panel ile manuel yapılandırmayı karıştırmayın. Panelin yönettiği bir dosyayı elle düzenlemek, bir sonraki panel güncellemesinde ayarlarınızın sessizce geri alınmasına yol açabilir.

Paylaşımlı hosting, VPS ve bulut arasında bu sorumlulukların nasıl dağıldığını hosting türleri karşılaştırmamızda anlattık.

6. En Az Yetki: Hasarı Sınırlamak

• Her site ya da uygulama için ayrı sistem kullanıcısı. Bir sitedeki açık, aynı sunucudaki diğer siteleri etkilememeli. PHP-FPM havuzlarını ve uygulama süreçlerini ayrı kullanıcılarla çalıştırın; web sunucusu süreçleri root olarak çalışmamalı.
• Dosya izinlerini daraltın. Dizinler için genellikle 755, dosyalar için 644; yapılandırma dosyaları (.env, wp-config.php) için daha kısıtlı izinler. "Çalışmıyordu, 777 yaptık" çözümü, herkesin dosya yazabileceği anlamına gelir; asla kalıcı çözüm olmamalı.
• Veritabanı kullanıcılarını uygulamaya özel açın. Her uygulamaya yalnızca kendi veritabanında ve yalnızca ihtiyaç duyduğu yetkilerle bir kullanıcı. Uygulamaya veritabanı root hesabını vermeyin.
• sudo yetkisini kısıtlayın. Yalnızca belirli komutları çalıştırması gereken bir dağıtım (deploy) kullanıcısına tam sudo vermek yerine sudoers içinde bu komutları tanımlayın.
• Erişimleri düzenli gözden geçirin. Ayrılan çalışanların, eski ajansların, tek seferlik destek için eklenen anahtarların authorized_keys dosyasında kalması çok yaygın. Üç ayda bir bu listeyi temizleyin.
• Gizli bilgileri kodda tutmayın. API anahtarları ve veritabanı şifreleri depoya (Git) değil, ortam değişkenlerine ya da gizli bilgi yönetim aracına konmalı; depoya yanlışlıkla gönderilmiş bir anahtar, silinse bile geçmişte kalır ve derhâl yenilenmelidir.

7. Şifreleme, Yedekleme ve İzleme

• Tüm web trafiği HTTPS olsun. Otomatik yenilenen sertifika, HTTP'den HTTPS'e yönlendirme ve eski TLS sürümlerinin kapatılması. Ayrıntılar SSL sertifikası rehberimizde.
• Yedeği sunucunun dışına alın. Aynı sunucuda duran yedek, sunucu ele geçirildiğinde ya da silindiğinde işe yaramaz. Şifreli, sunucu dışı ve düzenli test edilen yedek planı için 3-2-1 yedekleme rehberimize bakın.
• Günlükleri okuyun ya da okutun. Başarısız girişler, sudo kullanımı, yeni kullanıcı oluşturma ve beklenmedik süreçler için basit bir günlük özeti ya da merkezi günlük toplama çözümü kurun.
• Kaynak ve erişilebilirlik izlemesi. Ani işlemci artışı, disk doluluğu ya da beklenmedik giden trafik, sunucunun kripto madenciliği veya spam için kullanıldığının ilk işaretleri olabilir. Uyarıların gittiği adresin gerçekten takip edildiğinden emin olun.
• Kıyaslama için bir referans kullanın. CIS Benchmark'ları, yaygın dağıtımlar için ayrıntılı sertleştirme önerilerini madde madde listeler. Hepsini uygulamak gerekmez; bu kontrol listesini tamamladıktan sonra eksiklerinizi görmek için iyi bir ölçüttür.

Hızlı Kontrol Komutları

Servis adı dağıtıma göre ssh ya da sshd olabilir. Bu komutları ayda bir çalıştırıp sonuçları bir önceki ayla karşılaştırmak, gözden kaçan değişiklikleri yakalamanın basit bir yoludur. Sunucu tarafının ötesindeki güvenlik başlıkları için KOBİ siber güvenlik kontrol listemize göz atabilirsiniz.

Sık Sorulan Sorular

SSH portunu değiştirmek yeterli bir önlem mi?

Hayır. Günlüklerdeki otomatik deneme sayısını azaltır ama hedefli bir saldırganı durdurmaz. Gerçek koruma, anahtar tabanlı doğrulama, kapalı parola girişi ve mümkünse IP kısıtıdır.

fail2ban ile güvenlik duvarı aynı şey mi?

Hayır, birbirini tamamlarlar. Güvenlik duvarı hangi portların kime açık olduğunu belirleyen sabit kurallardır. fail2ban ise günlüklere bakarak kötü davranan IP'leri geçici olarak bu kurallara ekler.

Otomatik güncellemeler siteyi bozar mı?

Yalnızca güvenlik güncellemeleriyle sınırlı otomatik güncelleme nadiren sorun çıkarır. Büyük sürüm yükseltmeleri ve uygulama bağımlılıkları ise test ortamında denenip planlı yapılmalıdır. Güncellemesiz kalmanın riski, çoğu durumda nadir bir uyumsuzluk riskinden çok daha büyüktür.

Kontrol paneli kullanmak sunucuyu daha güvensiz yapar mı?

Panel ek bir saldırı yüzeyidir ama doğru yapılandırıldığında, yönetimi kolaylaştırıp hata payını azaltarak güvenliğe katkı da sağlar. Kritik olan; paneli IP ile kısıtlamak, iki adımlı doğrulamayı açmak ve güncel tutmaktır.

Sunucumun ele geçirildiğinden nasıl şüphelenirim?

Tanımadığınız kullanıcılar ya da SSH anahtarları, yeni zamanlanmış görevler, açıklanamayan işlemci kullanımı, beklenmedik giden bağlantılar ve sağlayıcıdan gelen kötüye kullanım bildirimleri en sık işaretlerdir. Böyle bir durumda sunucuyu izole edip kanıtları koruyarak ilerleyin.

Bu adımları bir kez yapmak yeterli mi?

Hayır. Sertleştirme bir başlangıçtır; güncellemeler, erişim gözden geçirmeleri, yedek testleri ve günlük takibi düzenli tekrarlanmalıdır. Aylık kısa bir kontrol ve üç ayda bir kapsamlı gözden geçirme çoğu küçük ölçekli sunucu için makul bir ritimdir.

Özetle

Bir Linux sunucusunu güvenli hâle getirmek için gelişmiş araçlara değil, temel adımların eksiksiz uygulanmasına ihtiyaç vardır: anahtarla SSH, kapalı root ve parola girişi, varsayılanı "reddet" olan bir güvenlik duvarı, fail2ban, otomatik güvenlik güncellemeleri, kısıtlanmış bir kontrol paneli ve her işin en az yetkiyle yapılması. Bu katmanlar birbirini tamamlar; biri atlanırsa diğerlerinin değeri düşer. Sunucunuzun kurulumunu, sertleştirmesini ve düzenli bakımını üstlenmemizi isterseniz IT hizmetlerimize göz atın; sunucuda çalışan uygulamanın güvenli bir mimariyle geliştirilmesi gerekiyorsa özel yazılım ekibimiz destek olabilir. Mevcut sunucunuz için bir güvenlik gözden geçirmesi planlamak için bize yazın.

Kaynaklar

• Ubuntu Server Documentation – OpenSSH server
• Ubuntu Server Documentation – Firewall
• Ubuntu Server Documentation – Automatic updates
• OpenBSD Manual – sshd_config(5)
• CIS Benchmarks