Linux Sunucu Sertleştirme (Hardening) Kontrol Listesi

Yeni kurulan bir Linux sunucusu, kutudan çıktığı haliyle çalışır ama güvenli değildir. Varsayılan yapılandırma her zaman erişilebilirliği önceler: parola ile SSH açıktır, root doğrudan bağlanabilir, güvenlik duvarı çoğu zaman kapalıdır ve kimse izlemez. Oysa sunucunuz internete çıktığı ilk saniyeden itibaren, hedef seçmeden çalışan tarama botlarının, sözlük saldırılarının ve açık port avcılarının menziline girer. Bu botlar sizi tanımaz; halka açık her IP'yi durmadan yoklar. Bir sistem yöneticisi olarak yıllardır gördüğüm en yaygın olay, "henüz kimse bilmiyor, sonra hallederim" diyerek çıplak bırakılan bir sunucunun daha ilk gecesinde ele geçirilmesidir.

İşte bu yüzden sertleştirmeyi (hardening) bir sonraki işe değil, ilk işe koymak gerekir. Bu rehberi bir kontrol listesi gibi kullanın: sunucuyu üretime almadan, üzerinde web sitesi ya da uygulama yayınlamadan önce baştan sona uygulayın. Her adımı Ubuntu/Debian üzerinden gösteriyorum; komutların büyük bölümü yalnızca paket yöneticisini değiştirerek AlmaLinux, Rocky veya diğer dağıtımlarda da geçerlidir. Adımları sırayla ilerletin; her biri bir öncekinin üzerine oturur ve hepsi birlikte "katmanlı savunma" (defense in depth) oluşturur. Tek bir önlem sizi kurtarmaz, asıl güç bu önlemlerin üst üste binmesindedir. Temel kavramlarda eksiğiniz varsa bu listeye başlamadan önce sunucu güvenliğinin temelleri yazısına göz atmanızı öneririm.

Başlamadan Önce: Kontrol Listesinin Özeti#

Aşağıdaki tablo, bu rehberde işleyeceğimiz dokuz temel adımın özetidir; her satır bir maddeyi ve o maddenin tek cümlelik gerekçesini içerir. Sunucunuzun kaç tanesini karşıladığını hızlıca işaretleyerek nereden başlayacağınızı görebilirsiniz.

Başlamadan önce iki pratik hatırlatma: İlk olarak, mümkünse sunucunun bir anlık görüntüsünü (snapshot) alın; SSH ayarlarını yanlış yaptığınızda geri dönebileceğiniz bir güvenlik ağı oluşur. İkincisi, SSH oturumunuzu kapatmadan her değişikliği ikinci bir terminalden test edin — kendinizi sunucudan kilitlemenin en sık yolu, çalışan oturumu kapatıp yeni bağlanamamaktır.

1. Sistemi Güncelleyin ve Otomatik Güncellemeyi Açın#

Bir sunucuyu sertleştirmenin en temel ama en sık atlanan adımı, kurulu tüm paketleri güncel tutmaktır; çünkü kullandığınız hazır imaj aylar öncesine ait olabilir ve o sürede yayımlanmış onlarca güvenlik yamasını içermez. İlk iş, her şeyi güncellemek olmalı:

sudo apt update && sudo apt upgrade -y
sudo apt dist-upgrade -y
sudo apt autoremove --purge -y

Çekirdek güncellemesinden sonra yeniden başlatma gerekip gerekmediğini tek satırla kontrol edebilirsiniz:

[ -f /var/run/reboot-required ] && echo "Yeniden baslatma gerekli" || echo "Gerek yok"

Güncellemeyi elle takip etmek zamanla aksar; kritik güvenlik yamalarının otomatik kurulması için unattended-upgrades paketini kurun. Bu sayede siz uyurken bile açıklar kapanır:

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

/etc/apt/apt.conf.d/50unattended-upgrades dosyasında yalnızca güvenlik deposunun etkin olduğundan emin olun; tüm paketleri otomatik yükseltmek istemeyebilirsiniz, ancak güvenlik yamalarını mutlaka açık tutun. AlmaLinux/Rocky tarafında aynı işi dnf-automatic görür.

2. SSH'ı Anahtar Tabanlı Girişe Geçirin ve Root'u Kapatın#

Parola ile SSH girişi kaba kuvvet saldırılarına açıktır; anahtar tabanlı giriş ise özel anahtarınız çalınmadan aşılamaz, bu yüzden ilk sertleştirme önceliğiniz burasıdır. Önce kendi bilgisayarınızda (sunucuda değil) bir anahtar çifti üretin ve sunucuya kopyalayın:

# Yerel makinenizde
ssh-keygen -t ed25519 -C "cloutr-sunucu"
ssh-copy-id cloutr@sunucu-ip-adresi

Anahtarla giriş yapabildiğinizi doğruladıktan sonra, /etc/ssh/sshd_config dosyasında şu satırları düzenleyin:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
MaxAuthTries 3
AllowUsers cloutr

Ardından yapılandırmayı sınayıp servisi yeniden başlatın:

sudo sshd -t          # sözdizimi hatası varsa burada uyarır
sudo systemctl restart ssh

root girişini kapatmak, botların en çok denediği kullanıcı adını hedef olmaktan çıkarır; parola girişini kapatmak ise sözlük saldırılarını tamamen anlamsız hale getirir. SSH tarafını daha derinlemesine sertleştirmek (port değiştirme, AllowGroups, idle timeout, anahtar yönetimi) için SSH bağlantısı ve güvenliği rehberini ayrıca okuyun. Değişiklikten sonra mevcut oturumu kapatmadan yeni bir terminalden bağlanabildiğinizi test etmeyi unutmayın.

3. Güvenlik Duvarını "Varsayılan Reddet" ile Kurun#

Güvenlik duvarı, hangi portların dışarıya açık olacağına karar veren kapıdır; doğru strateji "önce her şeyi reddet, sonra yalnızca gerekeni aç" olduğu için saldırı yüzeyi en aza iner. Ubuntu/Debian üzerinde en pratik araç UFW'dir:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Buradaki kritik nokta sıralamadır: enable komutundan önce SSH portunu (ya da OpenSSH profilini) mutlaka izin listesine ekleyin, yoksa güvenlik duvarını açar açmaz kendinizi dışarıda bırakırsınız. Web sunucusu çalıştırmıyorsanız 80/443 kurallarını eklemeyin — açık olmayan bir port taranamaz.

Daha ince kontrol isteyenler için iptables veya nftables da aynı işi yapar; hatta belirli bir IP bloğunu tamamen engellemek gibi durumlarda daha esnektir:

# Yalnızca ofis IP'nizden SSH'a izin ver (örnek)
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Uygulama katmanında HTTP saldırılarına karşı ek koruma istiyorsanız, sunucu güvenlik duvarını bir Web Application Firewall (WAF) ve DDoS koruması ile tamamlamak mantıklı olur; ağ katmanı güvenlik duvarı 7. katman saldırılarını (SQL injection, bot seli) filtrelemez.

4. Fail2ban ile Tekrarlayan Saldırıları Otomatik Engelleyin#

Güvenlik duvarı portu açık tutsa bile, o porta durmadan parola deneyen botları elle engellemek imkânsızdır; Fail2ban tam da bunu otomatikleştirir ve belirli sayıda başarısız denemeden sonra saldırganın IP'sini geçici olarak yasaklar. Kurulumu basittir:

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

jail.local dosyasında SSH için mantıklı bir eşik tanımlayın (varsayılanı doğrudan jail.conf üzerinde düzenlemeyin, güncellemede kaybolur):

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 4
ignoreip = 127.0.0.1/8 203.0.113.10

[sshd]
enabled = true
port    = ssh
maxretry = 3

Servisi başlatıp durumunu kontrol edin:

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

ignoreip satırına kendi sabit IP'nizi eklemeyi unutmayın; aksi halde kendi yanlış parola denemeleriniz sizi de yasaklayabilir. Fail2ban yalnızca SSH ile sınırlı değildir — Nginx, Postfix, WordPress giriş sayfası gibi log üreten her servis için "jail" tanımlayabilirsiniz.

5. Gereksiz Servisleri ve Açık Portları Kapatın#

Çalışan her servis potansiyel bir saldırı kapısıdır; kullanmadığınız bir veritabanı, mail sunucusu ya da eski bir yönetim aracı sunucuda dinlemeye devam ediyorsa, onu kapatmak saldırı yüzeyini doğrudan daraltır. Önce neyin dinlediğini görün:

sudo ss -tulpn

Çıktıda tanımadığınız ya da ihtiyaç duymadığınız bir servis varsa devre dışı bırakın. Örneğin web sunucusunda çalışan bir yazıcı servisi (CUPS) ya da kullanılmayan bir RPC servisi tipik adaylardır:

sudo systemctl disable --now cups.service
sudo systemctl disable --now rpcbind.service

Kurulu ama gereksiz paketleri tamamen kaldırmak, hem yüzeyi daraltır hem de bakım yükünü azaltır:

sudo apt purge -y telnetd rsh-server
sudo apt autoremove --purge -y

Kural basit: bir servisin ne işe yaradığını bilmiyorsanız ve bir şey onu talep etmiyorsa, kapatın. Bir şeyin bozulup bozulmadığını kapattıktan sonra test edersiniz; hâlâ ihtiyaç varsa geri açmak, açık bir kapıyı fark etmemekten çok daha ucuzdur.

6. Güçlü Parola Politikası ve İki Faktörlü Doğrulama#

SSH'ta parola girişini kapatsanız bile sunucuda hâlâ parolalar vardır — sudo, veritabanı, panel, uygulama hesapları; bu yüzden güçlü bir parola politikası ele geçirilen tek bir parolanın domino etkisi yaratmasını engeller. Parola karmaşıklığını sistem düzeyinde zorlamak için libpam-pwquality kurun:

sudo apt install -y libpam-pwquality

/etc/security/pwquality.conf dosyasında minimum uzunluk ve karakter çeşitliliği belirleyin:

minlen = 14
minclass = 3
maxrepeat = 3
dictcheck = 1

Kritik hesaplar için tek başına güçlü parola bile yetmez; SSH'a ikinci bir faktör (2FA) eklemek, anahtar dosyası çalınsa bile ikinci bir engel koyar:

sudo apt install -y libpam-google-authenticator
google-authenticator   # QR kodu üretir, uygulamayla taratın

Kurcalanmasını istemediğiniz sunucular için 2FA'yı SSH'ın PAM yapılandırmasına ekleyerek anahtar + tek kullanımlık kodu birlikte zorunlu kılabilirsiniz. Yönetim panellerinizde ise 2FA'yı mutlaka açık tutun — Clou.TR müşteri panelinde hesabınız için TOTP tabanlı iki faktörlü doğrulamayı Güvenlik bölümünden etkinleştirebilirsiniz.

7. Loglama, İzleme ve Denetim#

Bir güvenlik olayı yaşandığında "ne oldu, ne zaman oldu, nereden geldi" sorularının tek cevabı loglardır; bu yüzden loglamayı düzgün kurmak, saldırıyı önlemek kadar önemlidir çünkü olaydan sonra izi ancak kayıtlar taşır. systemd tabanlı sistemlerde temel logları journalctl ile inceleyebilirsiniz:

sudo journalctl -u ssh --since "1 hour ago"
sudo journalctl -p err -b        # bu açılıştaki hatalar
sudo lastb | head                # başarısız giriş denemeleri

Logların disk dolduğunda kaybolmaması için logrotate zaten çoğu dağıtımda kuruludur; kritik servisleriniz için döndürme (rotation) ayarlarının makul olduğunu doğrulayın. Bir adım öteye geçmek isterseniz, dosya bütünlüğü izleme aracı kurarak sistem dosyalarındaki beklenmeyen değişiklikleri yakalayabilirsiniz:

sudo apt install -y aide
sudo aideinit
# Sonraki kontrollerde:
sudo aide --check

Merkezî izleme ve uyarı için, sunucularınızın erişilebilirliğini dışarıdan sürekli kontrol eden bir sistem de kurmanızı öneririm; Clou.TR panelindeki uptime uyarıları, bir servis düştüğünde size e-posta, webhook veya Telegram üzerinden anında haber verir. İşin sürekli yönetimini kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmeti izleme ve güncelleme yükünü sizden alır.

8. Düzenli ve Test Edilmiş Yedekler Alın#

Tüm önlemlere rağmen kötü bir gün gelebilir — bir fidye yazılımı, silinen bir veritabanı ya da bozulan bir disk; bu yüzden düzenli yedek, sertleştirmenin değil kabul etmenin bir ürünüdür ve son savunma hattınızdır. En kötü senaryoya hazırlıklı olmayan bir sunucu asla tam sertleştirilmiş sayılmaz. Basit bir yedek betiğiyle başlayabilirsiniz:

#!/usr/bin/env bash
# /usr/local/bin/yedek.sh
set -euo pipefail
TARIH=$(date +%F)
HEDEF="/yedek/$TARIH"
mkdir -p "$HEDEF"
tar czf "$HEDEF/etc.tar.gz" /etc
mysqldump --all-databases | gzip > "$HEDEF/mysql.sql.gz"
# Uzak konuma kopyala (3-2-1 kuralı)
rsync -a "$HEDEF" yedek-sunucu:/depo/

Betiği bir cron görevine bağlayarak her gece otomatik çalıştırın:

# crontab -e
0 3 * * * /usr/local/bin/yedek.sh >> /var/log/yedek.log 2>&1

Buradaki en önemli kural şudur: test edilmemiş yedek, yedek değildir. Düzenli aralıklarla bir yedeği boş bir ortama geri yükleyip gerçekten açılıp açılmadığını doğrulayın; yıllardır süren felaketlerin çoğu, "yedeğimiz var" sanılırken geri yüklenemeyen dosyalardan çıkar. 3-2-1 kuralını hedefleyin: en az üç kopya, iki farklı ortam, biri sunucu dışında. Yedekleme altyapısını kendiniz kurmak istemiyorsanız otomatik yedekleme hizmeti bu yükü üstlenir.

9. Düzenli Denetim ve Bakımla Sertleştirmeyi Sürdürün#

Sertleştirme tek seferlik bir proje değil, süreklilik isteyen bir alışkanlıktır; çünkü yeni açıklar her hafta ortaya çıkar, kurallar zamanla eskir ve dünkü güvenli yapılandırma yarın yetersiz kalabilir. Aylık bir bakım ritmi oluşturun: güncellemeleri kontrol edin, açık portları yeniden tarayın, Fail2ban ve giriş loglarını gözden geçirin, kullanılmayan hesapları kapatın.

Hızlı bir öz-denetim için birkaç komut her zaman işe yarar:

sudo ss -tulpn                  # hâlâ ne dinliyor?
sudo lastlog | grep -v "Hiç"    # kim ne zaman girdi?
sudo apt list --upgradable      # bekleyen güncelleme var mı?
who -a                          # aktif oturumlar

Sunucu sayınız arttıkça bu denetimleri elle yapmak zorlaşır; Ansible gibi bir otomasyon aracıyla tüm filoyu tek komutta güncellemek ve yapılandırmayı standart tutmak ölçeklenmenin tek sağlıklı yoludur. Yeni bir sunucu kurarken bu kontrol listesini her defasında baştan uygulamak yerine, adımları bir betiğe ya da Ansible playbook'una dökerek tekrarlanabilir hale getirin. Böylece ister tek bir VDS sunucu ister onlarca makineden oluşan bir filo olsun, güvenlik seviyeniz her yerde aynı kalır.

Sıkça Sorulan Sorular#

Sunucu sertleştirme (hardening) tam olarak nedir?#

Sunucu sertleştirme, bir sistemin varsayılan yapılandırmasındaki gereksiz açıklıkları kapatarak saldırı yüzeyini bilinçli biçimde daraltma sürecidir. Pratikte bu; kullanılmayan servisleri kapatmak, güçlü kimlik doğrulama zorunlu kılmak, güvenlik duvarı kurmak ve sistemi güncel tutmak gibi katmanlı önlemlerin tümünü kapsar. Amaç, sunucuyu "aşılamaz" yapmak değil — böyle bir şey yoktur — saldırganın işini olabildiğince zorlaştırıp otomatik saldırıların çoğunu daha ilk adımda etkisiz bırakmaktır.

Bu adımları hangi sırayla uygulamalıyım?#

Rehberdeki sırayı takip etmenizi öneririm çünkü her adım bir öncekinin üzerine oturur. Önce sistemi güncelleyin, hemen ardından SSH erişimini anahtara geçirip root'u kapatın; bu ikisi en kritik ve en çok saldırı alan noktalardır. Sonra güvenlik duvarı, Fail2ban ve gereksiz servislerle saldırı yüzeyini daraltır, en sonda loglama ve yedekle olası bir olaya hazırlık yaparsınız. Her değişikliğin ardından SSH oturumunuzu kapatmadan test etmeyi ihmal etmeyin.

root girişini kapatırsam sunucuyu nasıl yöneteceğim?#

Root girişini kapatmak, yönetici yetkisinden vazgeçmek anlamına gelmez; sadece o yetkiye sudo üzerinden, kimliği belli bir kullanıcıyla erişirsiniz. Önce sudo yetkisine sahip normal bir kullanıcı oluşturur, o kullanıcının anahtarla girip sudo çalıştırabildiğini doğrular, ancak ondan sonra PermitRootLogin no ayarını uygularsınız. Bu yaklaşım hem yıkıcı komutları yanlışlıkla çalıştırma riskini azaltır hem de her yetkili işlemin sudo loglarında iz bırakmasını sağlar.

Anahtar tabanlı SSH varken Fail2ban'a gerçekten gerek var mı?#

Evet, çünkü Fail2ban yalnızca SSH parola denemelerini değil, sunucudaki diğer log üreten servisleri de koruyabilir. Parola girişini tamamen kapatmış olsanız bile botlar denemeye devam eder ve bu denemeler loglarınızı doldurup CPU harcar; Fail2ban bu gürültüyü otomatik olarak keser. Ayrıca web uygulaması giriş sayfası, mail sunucusu ya da FTP gibi parola gerektiren servisleriniz varsa Fail2ban orada birinci savunma hattı olur.

Sertleştirmeyi ne sıklıkla gözden geçirmeliyim?#

En az ayda bir kez düzenli bir denetim yapmanızı, kritik bir güvenlik açığı duyurulduğunda ise beklemeden müdahale etmenizi öneririm. Aylık kontrolde güncellemeleri uygular, açık portları yeniden tarar, giriş loglarını ve Fail2ban kayıtlarını inceler, kullanılmayan hesapları kapatırsınız. Sertleştirme bir kez yapılıp unutulacak bir iş değildir; yeni açıklar sürekli çıktığı için güvenlik, ancak düzenli bakımla korunan bir durumdur.

Paylaşımlı hosting kullanıyorum, bu adımları uygulamam gerekir mi?#

Hayır; paylaşımlı hostingte sunucunun işletim sistemi, güvenlik duvarı ve güncellemeleri sağlayıcı tarafından yönetilir, dolayısıyla bu kontrol listesi sizin sorumluluğunuzda değildir. Bu adımlar VDS, VPS veya dedicated gibi sizin root erişimine sahip olduğunuz sunucular için geçerlidir. Paylaşımlı hostingte sizin göreviniz kendi uygulamanızı güncel tutmak, güçlü parola ve 2FA kullanmak ve düzenli yedek almaktır; alt yapı sertleştirmesi sağlayıcının işidir.

Kapanış#

Bir sunucuyu sertleştirmek, tek bir sihirli komutla değil, üst üste binen küçük ve disiplinli adımlarla olur. Sistemi güncel tutmak, SSH'ı anahtara taşıyıp root'u kapatmak, "varsayılan reddet" bir güvenlik duvarı kurmak, Fail2ban ile saldırıları otomatik engellemek, gereksiz servisleri kapatmak, güçlü parola ve 2FA zorunlu kılmak, loglamayı düzgün yapmak ve test edilmiş yedekler almak — bunların her biri tek başına küçük bir engel, hepsi birlikte ise ciddi bir savunma duvarıdır. Bu listeyi her yeni sunucuda baştan uygulayın ve zamanla bir betiğe dökerek tekrarlanabilir hale getirin.

Kendi root erişiminizin olduğu, üzerinde bu adımları özgürce uygulayabileceğiniz güçlü bir altyapı arıyorsanız Clou.TR'nin sanal ve VDS sunucu çözümlerine göz atabilirsiniz; kurulumdan itibaren yanınızda bir ekip olmasını isterseniz yönetilen sunucu hizmeti güncelleme, izleme ve sertleştirme yükünü sizin adınıza üstlenir. Güvenli bir sunucu, üzerine kurduğunuz her şeyin sağlam temelidir — o temeli en baştan doğru atın.