Linux Sunucu Güvenliği: Adım Adım Sıkılaştırma Rehberi

Linux sunucu güvenliği erişimi daraltmakla başlar: SSH'a yalnızca anahtarla izin verilir, root ve parola girişi kapatılır. Güvenlik duvarında yalnızca gerekli portlar açık bırakılır, Fail2ban veya CrowdSec ile kaba kuvvet denemeleri engellenir. Güvenlik güncellemeleri otomatikleştirilir, gereksiz servisler kapatılır, loglar izlenir ve yedekten geri dönüş düzenli test edilir.

Bu rehberdeki komutları Ubuntu/Debian ve AlmaLinux/Rocky Linux için ayrı ayrı verdik. Adımları kendiniz uygulayabilir ya da sürekli takip gerektiren kısmını, yani saldırı tespiti ve firewall yönetimi işlerini bir yönetim paketine devredebilirsiniz. Önce kısa listeyi görelim:

1. sudo yetkili, root olmayan bir kullanıcı oluşturun.
2. SSH girişini ed25519 anahtarına taşıyın.
3. Root ile doğrudan girişi ve parola ile girişi kapatın.
4. Güvenlik duvarında yalnızca gerekli portları açık bırakın.
5. Fail2ban veya CrowdSec ile kaba kuvvet denemelerini engelleyin.
6. Güvenlik güncellemelerini otomatikleştirin.
7. Kernel güncellemelerinden sonra yeniden başlatmayı planlayın.
8. Dinleyen portları denetleyin, gereksiz servisleri kapatın.
9. Web katmanında WAF ve doğru dosya izinleri kullanın.
10. Yedekten geri dönüşü test edin, sistemi CIS Benchmark ve Lynis ile denetleyin.

Sunucu sıkılaştırma (hardening) nedir?

Sıkılaştırma, bir sunucunun saldırıya açık yüzeyini daraltmak için varsayılan ayarları kapatma, kısıtlama ve izleme işlemlerinin tamamıdır. Yeni kurulan bir Linux sunucu çalışmak üzere yapılandırılmıştır, korunmak üzere değil: parola ile giriş açıktır, güvenlik duvarı çoğu zaman kapalıdır ve kimse logları okumaz.

İyi bir sıkılaştırma katmanlıdır. Ağ katmanı gereksiz trafiği dışarıda tutar, erişim katmanı kimin girebileceğini belirler, servis katmanı açık kapıları azaltır, uygulama katmanı web saldırılarını filtreler, veri katmanı ise her şey başarısız olduğunda geri dönmenizi sağlar. Tek bir önlem hiçbir zaman yeterli değildir.

1. Erişim

Sunucuya yalnızca adı belli kullanıcılar, yalnızca anahtarla ve yalnızca gerektiğinde yetki yükselterek girmelidir.

sudo kullanıcıları

sudo, normal bir kullanıcının tek tek komutları yönetici yetkisiyle çalıştırmasını sağlar ve her kullanımı loglar. Root ile doğrudan çalışmak yerine, sudo yetkili kişisel bir kullanıcı açın:

# Ubuntu / Debian
sudo adduser deploy
sudo usermod -aG sudo deploy

# AlmaLinux / Rocky
sudo useradd -m -s /bin/bash deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

Ekipte birden fazla kişi varsa her birine ayrı kullanıcı açın. Ortak bir hesap kullanıldığında logda kimin ne yaptığı görünmez ve ekipten ayrılan birinin erişimini kapatmak zorlaşır.

SSH anahtarıyla giriş

SSH anahtarı, bir özel ve bir açık anahtardan oluşan kriptografik çifttir. Açık anahtar sunucuya konur, özel anahtar yalnızca sizin bilgisayarınızda kalır. Ed25519, kısa anahtar boyutuyla güçlü güvenlik sağlayan modern bir algoritmadır. Anahtarı kendi bilgisayarınızda üretin ve bir parola (passphrase) ile koruyun:

# Kendi bilgisayarınızda (Linux / macOS)
ssh-keygen -t ed25519 -C "ad.soyad@dizustu"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@SUNUCU_IP
ssh deploy@SUNUCU_IP

Windows 10 ve 11'de OpenSSH istemcisi yerleşik gelir; ssh-copy-id olmadığı için açık anahtarı PowerShell'den şöyle kopyalayabilirsiniz:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@SUNUCU_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Root ve parola girişini kapatma

Uyarı: SSH ayarlarını değiştirmeden önce sunucuda açık ikinci bir oturum tutun ve değişiklikten sonra yeni girişi üçüncü bir terminalden deneyin. Yeni ayar sizi dışarıda bırakırsa, açık kalan oturumdan düzeltme yapabilirsiniz. Anahtarla girişin çalıştığını doğrulamadan parola girişini kapatmayın.

Modern dağıtımlarda ana sshd_config dosyası /etc/ssh/sshd_config.d/ dizinini en başta okur. sshd bir ayar için ilk karşılaştığı değeri kullandığından, dosya adını 00- ile başlatmak önemlidir; bazı bulut imajlarındaki 50-cloud-init.conf gibi dosyalar parola girişini yeniden açabilir.

sudo nano /etc/ssh/sshd_config.d/00-sertlestirme.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deploy

OpenSSH'ta PermitRootLogin ayarı varsayılan olarak prohibit-password değeriyle gelir; bu durumda root parola ile giremez ama anahtarla girebilir. no değeri root girişini tamamen kapatır ve yönetici işlerini sudo kullanıcısına taşır. Önce sözdizimini ve geçerli değerleri kontrol edin, sonra servisi yeniden yükleyin:

sudo sshd -t
sudo sshd -T | grep -Ei "permitrootlogin|passwordauthentication|kbdinteractive|pubkeyauthentication"

# Ubuntu / Debian
sudo systemctl reload ssh

# AlmaLinux / Rocky
sudo systemctl reload sshd

sshd -T çıktısında parola girişi hâlâ açık görünüyorsa, başka bir dosya sizin ayarınızdan önce okunuyordur. Ana dosyada Include satırı yoksa ayarları doğrudan /etc/ssh/sshd_config içine yazın. AllowUsers satırına sunucuya girmesi gereken herkesi ekleyin; listede olmayan kullanıcı, anahtarı doğru olsa bile giremez.

2. Ağ

Varsayılan olarak gelen tüm bağlantıları reddedin, yalnızca kullandığınız servislerin portlarını açın ve yönetim portlarını mümkünse belirli IP'lerle sınırlayın.

Güvenlik duvarı: yalnızca gerekli portlar

Ubuntu'da ufw, AlmaLinux ve Rocky'de firewalld, çekirdeğin paket filtreleme altyapısını (netfilter; güncel sürümlerde nftables) yöneten arayüzlerdir. Aşağıdaki örnek SSH, HTTP ve HTTPS dışındaki gelen bağlantıları kapatır. SSH iznini güvenlik duvarını açmadan önce ekleyin, aksi halde bağlantınız kesilir.

# Ubuntu / Debian (Debian'da önce: sudo apt install ufw)
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

# AlmaLinux / Rocky
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Ofisinizin ya da VPN'inizin sabit bir IP'si varsa SSH'ı yalnızca o adrese açmak, port değiştirmekten çok daha etkilidir. Örnekteki 203.0.113.10 yerine kendi IP'nizi yazın:

# Ubuntu / Debian
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw delete allow OpenSSH

# AlmaLinux / Rocky
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" service name="ssh" accept'
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

IP'niz değişirse sunucuya SSH ile giremezsiniz; bu kısıtlamayı uygulamadan önce sağlayıcınızın konsol erişimi gibi alternatif bir yolunuz olduğundan emin olun. Docker kullanıyorsanız, yayınlanan konteyner portlarının ufw kurallarını atlayabildiğini de hesaba katın.

SSH portunu değiştirmek gerçekten korur mu?

Hayır, korumaz; yalnızca gürültüyü azaltır. SSH'ı 22 yerine 2222 gibi bir portta çalıştırmak, internet genelinde 22 numaralı portu tarayan otomatik botların büyük kısmını loglarınızdan uzaklaştırır. Ama size özel çalışan bir saldırgan, bir port taramasıyla yeni portu kısa sürede bulur. Sunucuyu koruyan şey port numarası değil, parola girişinin kapalı olması ve anahtarın gizli kalmasıdır.

Gürültünün azalması yine de işe yarar: loglar okunabilir hale gelir ve gerçek bir denemeyi fark etmek kolaylaşır. Port değiştirmeye karar verirseniz sırayı bozmayın. Yeni portu önce güvenlik duvarında açın, AlmaLinux ve Rocky'de SELinux'a tanıtın, ardından sshd'yi yeniden yükleyin ve yeni portla bağlanmayı test etmeden 22'yi kapatmayın:

# AlmaLinux / Rocky: SELinux'a yeni portu tanıtma
sudo semanage port -a -t ssh_port_t -p tcp 2222

# Ubuntu 24.04: SSH soket etkinleştirmeli çalıştığı için
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

3. Saldırı tespiti

Loglardaki başarısız giriş örüntülerini izleyip kaynak IP'yi otomatik engelleyen bir araç kurun ve kritik olayları düzenli okuyun.

Fail2ban ve CrowdSec

Fail2ban, log dosyalarını tarayarak çok sayıda başarısız giriş deneyen IP adreslerini belirli bir süre için güvenlik duvarında engeller. Kendi dokümantasyonunun da vurguladığı gibi, başarısız deneme sayısını azaltır ama zayıf kimlik doğrulamanın riskini ortadan kaldırmaz. Yani anahtarla girişin yerine geçmez, onu tamamlar.

# Ubuntu / Debian
sudo apt install fail2ban

# AlmaLinux / Rocky (EPEL deposu gerekir)
sudo dnf install epel-release
sudo dnf install fail2ban

# Her iki dağıtımda: ayarları jail.conf yerine jail.local dosyasına yazın
sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[sshd]
enabled  = true
maxretry = 5
findtime = 10m
bantime  = 1h
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

SSH logları yalnızca systemd journal'ında tutuluyorsa, örneğin rsyslog kurulu olmayan Debian 12 sistemlerde, sshd bölümüne backend = systemd satırını ekleyin.

CrowdSec aynı işi farklı bir mimariyle yapar: logları ayrıştıran açık kaynaklı bir güvenlik motoru, engellemeyi güvenlik duvarında ya da web sunucusunda uygulayan iyileştirme bileşenleri (bouncer) ve kullanıcılarından toplanan kötü niyetli IP'lerden oluşan bir topluluk engelleme listesi. Tek bir sunucuda Fail2ban yeterlidir; birden fazla sunucuda ortak bir tehdit listesi istiyorsanız CrowdSec değerlendirilebilir.

Log izleme

Engelleme araçları bilinen örüntüleri yakalar; bilinmeyeni görmek için logları okumak gerekir. Başarılı SSH girişlerini, sudo kullanımını ve yeni kullanıcı oluşturma kayıtlarını düzenli kontrol edin:

# Ubuntu / Debian
sudo grep -E "Accepted|sudo:" /var/log/auth.log | tail -30

# AlmaLinux / Rocky
sudo grep -E "Accepted|sudo:" /var/log/secure | tail -30

Birden fazla sunucunuz varsa logları merkezi bir sunucuya göndermek, saldırganın izini silmek için logları değiştirmesini de zorlaştırır. Günlük ve haftalık log kontrollerini sunucu bakım kontrol listesi içinde ayrıntılı ele aldık.

4. Güncellemeler

Güvenlik güncellemelerini otomatik uygulayın, ana sürüm ve uygulama paketlerini test ederek elle güncelleyin.

Otomatik güvenlik güncellemeleri

Ubuntu'da unattended-upgrades varsayılan olarak kuruludur ve güvenlik güncellemelerini kendiliğinden uygular. Kurulu değilse ya da kapatıldıysa yeniden etkinleştirebilirsiniz. AlmaLinux ve Rocky 9'da aynı işi dnf-automatic yapar:

# Ubuntu / Debian
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# AlmaLinux / Rocky 9
sudo dnf install dnf-automatic
sudo sed -i 's/^upgrade_type.*/upgrade_type = security/; s/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer

Kernel güncellemeleri

Kernel güncellemesi paket olarak kurulsa da yeni çekirdek ancak yeniden başlatmadan sonra çalışır. Ubuntu'da /var/run/reboot-required dosyasının varlığı, AlmaLinux ve Rocky'de sudo dnf needs-restarting -r çıktısı yeniden başlatma gerektiğini gösterir. Ubuntu'da /etc/apt/apt.conf.d/50unattended-upgrades dosyasındaki Unattended-Upgrade::Automatic-Reboot seçeneğiyle otomatik yeniden başlatmayı belirli bir saate bağlayabilirsiniz. Yeniden başlatmanın kabul edilemediği sistemlerde Canonical Livepatch ya da Red Hat ailesinde kpatch gibi canlı yama çözümleri araştırılabilir.

5. Servis yüzeyi

Çalışmayan bir servis saldırıya uğramaz. Kullanmadığınız her servisi kapatın, kullandıklarınızı yalnızca gereken arayüzde dinletin.

Gereksiz servisler

systemctl list-unit-files --type=service --state=enabled
sudo systemctl disable --now SERVIS_ADI

Bir servisi kapatmadan önce ne işe yaradığını öğrenin; ağ, SSH ya da zaman senkronizasyonu servislerini kapatmak sunucuyu erişilemez hale getirebilir.

Dinleyen portların denetimi (ss -tulpn)

sudo ss -tulpn

Bu komut TCP ve UDP üzerinden dinleyen tüm portları ve bunları açan süreçleri gösterir. Yerel adres sütununda 127.0.0.1 görüyorsanız servis yalnızca sunucunun içinden erişilebilir. 0.0.0.0 veya IPv6'daki karşılığını görüyorsanız tüm arayüzlerden erişilebilir. Aynı sunucudaki uygulamanın kullandığı MySQL, MariaDB veya Redis tüm arayüzlerde dinliyorsa, yapılandırmasında bind-address değerini 127.0.0.1 yapın. Güvenlik duvarı yanlışlıkla açılsa bile servis dışarıya kapalı kalır.

6. Web uygulaması katmanı

Saldırıların önemli bir kısmı işletim sistemini değil, web uygulamasını hedefler; bu katmanda WAF ve en az yetki ilkesi gerekir.

WAF

WAF (Web Application Firewall), HTTP isteklerini inceleyerek SQL enjeksiyonu, XSS ve dosya dahil etme gibi saldırı kalıplarını engelleyen filtredir. Sunucu üzerinde yaygın açık kaynak seçenek ModSecurity ve OWASP Core Rule Set'tir. WAF kurallarını önce yalnızca kayıt tutan modda çalıştırın; doğrudan engelleme modu, meşru istekleri de engelleyerek siteyi bozabilir. Kural setleri uygulamanıza göre ayarlanmadıkça ya çok gevşek ya da çok katı kalır.

Dosya izinleri

Web sunucusu kullanıcısının yazabildiği her dosya, bir uygulama açığı durumunda değiştirilebilir. Dosyaların sahibi dağıtım kullanıcısı, grubu web sunucusu olsun; yazma izni yalnızca yükleme ve önbellek dizinlerinde kalsın. Ubuntu/Debian için bir WordPress örneği:

sudo chown -R deploy:www-data /var/www/ornek.com
sudo find /var/www/ornek.com -type d -exec chmod 750 {} +
sudo find /var/www/ornek.com -type f -exec chmod 640 {} +
sudo chmod -R g+w /var/www/ornek.com/wp-content/uploads

AlmaLinux ve Rocky'de grup adı web sunucusu ve PHP-FPM yapılandırmanıza göre nginx ya da apache olur. SELinux açıkken yazılabilir dizinlerin bağlamını da tanımlamanız gerekir:

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/ornek.com/wp-content/uploads(/.*)?"
sudo restorecon -Rv /var/www/ornek.com

Bir izin sorununu 777 ile çözmeyin; bu, dizini sunucudaki herkese yazılabilir yapar.

7. Yedek ve geri dönüş

Sıkılaştırma saldırı olasılığını düşürür ama sıfırlamaz. Fidye yazılımı, silinen bir veritabanı ya da hatalı bir güncelleme karşısında son savunma hattı yedektir. Yedeğin sunucudan ayrı bir yerde durması, sunucuyu ele geçiren birinin onu silememesi ve geri yüklemenin düzenli test edilmesi gerekir. Sunucuya root yetkisiyle giren bir saldırgan, aynı sunucuda duran ya da sunucudan silinebilen yedekleri de yok edebilir.

Denetim: CIS Benchmark ve Lynis

Sıkılaştırmanın eksik kalıp kalmadığını, kabul görmüş bir standarda ve otomatik bir tarayıcıya karşı ölçün.

CIS Benchmark, Center for Internet Security'nin uzman konsensüsüyle hazırladığı yapılandırma rehberleridir. Ubuntu, Debian, AlmaLinux ve Rocky Linux dahil birçok dağıtım için ücretsiz PDF olarak indirilebilir. Level 1 profili çoğu sunucuya sorunsuz uygulanabilen temel ayarları, Level 2 daha katı ve işlevselliği etkileyebilecek ayarları içerir. Red Hat ailesinde OpenSCAP araçları CIS profillerini otomatik denetlemek için de kullanılabilir.

Lynis, Linux ve Unix sistemlerde güvenlik taraması yapan açık kaynaklı bir araçtır. Sistemi değiştirmez, yalnızca raporlar:

# Ubuntu / Debian
sudo apt install lynis

# AlmaLinux / Rocky (EPEL)
sudo dnf install lynis

sudo lynis audit system

Raporun sonunda uyarılar ve öneriler listelenir. Her öneriyi körü körüne uygulamayın; bazıları sizin kullanım senaryonuzla çelişebilir. Ama uyarı olarak işaretlenen maddeleri tek tek kapatın ve taramayı birkaç ayda bir tekrarlayın.

Sağlayıcı ne yapar, siz ne yaparsınız?

Sağlayıcı fiziksel altyapıyı ve ağı korur; işletim sisteminin içindeki her şey, bir yönetim sözleşmesiyle devretmedikçe sizindir.

Sunucu yönetimi sayfasında yönetim ekibinin yaptığı işler arasında açık tespiti, IDS/IPS ile saldırı tespiti ve müdahale, malware taraması, WAF ve özel kural setleri de listeleniyor. Hangi işin hangi pakete girdiğini sipariş öncesinde sayfadan kontrol edin. Sağlayıcı ile müşteri arasındaki genel sorumluluk sınırlarını managed ve unmanaged sunucu farkı yazısında matrisle anlattık.

Sık sorulan sorular

Fail2ban yeterli mi?

Tek başına yeterli değildir. Fail2ban kaba kuvvet denemelerinin hızını düşürür, ama parola girişi açık ve parola zayıfsa riski ortadan kaldırmaz. Anahtarla giriş, kapalı parola girişi ve güncel yazılımla birlikte kullanıldığında anlamlı bir katman oluşturur.

Otomatik güncelleme güvenli mi?

Güvenlik güncellemeleri için evet; bu paketler mevcut sürümdeki açıkları kapatmak üzere hazırlanır ve davranışı nadiren değiştirir. Bilinen bir açığın yamasız kalması, nadir bir uyumsuzluk riskinden genellikle daha tehlikelidir. Ana sürüm yükseltmelerini ve veritabanı, PHP gibi uygulamanın bağlı olduğu paketleri ise test ortamında deneyip elle güncelleyin.

SELinux veya AppArmor'u kapatmalı mıyım?

Hayır. Birçok kurulum rehberi bir izin hatasını aşmak için SELinux'u kapatmayı önerir; bu, bir uygulama açığında saldırganın hareket alanını sınırlayan katmanı devre dışı bırakır. Hata alıyorsanız sudo ausearch -m avc -ts recent ile reddedilen işlemi bulun ve doğru bağlamı ya da boolean değerini tanımlayın.

Bu adımların bir kısmı bir kez yapılır, bir kısmı ise sürekli takip ister: logların okunması, saldırı tespiti ve firewall kurallarının güncel tutulması gibi. Sıkılaştırmayı ve sürekli güvenlik takibini SLA-3 ile devretmek isterseniz sunucu yönetimi paketlerini inceleyin.

Kaynaklar

• OpenSSH: sshd_config(5)
• Fail2ban (GitHub)
• CrowdSec documentation
• Ubuntu Server documentation: Automatic updates
• Rocky Linux documentation: Patching servers with dnf-automatic
• CIS Benchmarks
• Lynis (CISOfy)