Sunucu Güvenliği için Yapılması Gereken 15 Temel Ayar

Yazar:komut.io ekibi
0 Yorum

Yeni bir sunucu teslim aldığınızda, o temiz kurulumun üzerindeki sorumluluk hissiyle ne yapacağınıza karar vermeniz gerekiyor. Üretim ortamına almadan önce mutlaka uygulamanız gereken bir kontrol listeniz yoksa, zamanla biriken güvenlik açıkları sizi ciddi şekilde zorlayabilir. Bu yazıda yıllarca farklı ortamlarda edindiğim deneyimleri 15 temel başlık altında topladım. Hem Linux hem Windows tarafını ele alacağız, ama ağırlık Linux’ta olacak.

1. SSH Yapılandırmasını Sıkılaştırın

SSH, sunucunuzun ön kapısı. Ve çoğu saldırı bu kapıya yöneliyor. Varsayılan 22. portu değiştirmek tek başına yeterli değil, ama dikkati azaltıyor. Asıl mesele anahtar tabanlı kimlik doğrulamaya geçmek ve parola girişini tamamen kapatmak.

# /etc/ssh/sshd_config dosyasında yapılması gereken değişiklikler
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers sysadmin deploy
X11Forwarding no

Değişiklikleri uygulamadan önce mevcut bağlantınızı kesmemenizi öneririm. Yeni bir terminal açın, değişiklikleri test edin, sonra eski bağlantıyı kapatın. Kaç kez kendi kendimi sunucudan kilitlediğimi saymakla uğraşmıyorum artık.

# Servisi yeniden başlatmadan önce yapılandırmayı test edin
sshd -t
# Hata yoksa yeniden başlatın
systemctl restart sshd

2. Root Girişini Tamamen Devre Dışı Bırakın

Bu, birinci maddede kısmen değindim ama ayrıca vurgulamak gerekiyor. PermitRootLogin no demeniz yetmez; sisteminizde root kullanıcısına doğrudan erişim sağlayan başka vektörler de olabilir. Su, cron, PAM modülleri bunların başında geliyor.

Bunun yerine sudo yetkisine sahip bir yönetici kullanıcı oluşturun ve o kullanıcıyla giriş yapın.

# Yeni yönetici kullanıcı oluşturma
useradd -m -s /bin/bash sysadmin
usermod -aG sudo sysadmin

# Sudo yetkilerini kısıtlı tutmak isterseniz
visudo
# Şu satırı ekleyin:
# sysadmin ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx

Tüm sudo erişimini NOPASSWD vermek yerine, gerçekten neye ihtiyaç duyulduğunu düşünün. Parola sormadan restart atabilmek mantıklı, ama rm -rf / için değil.

3. Güvenlik Duvarı Kurallarını Doğru Yapılandırın

“Sonra ayarlarım” diyerek açık bırakılan port sayısı düşünülemez. Varsayılan politika her şeyi reddet, sadece ihtiyaç duyulan servislere izin ver. Bu basit kural, onlarca potansiyel saldırı vektörünü kapatır.

# UFW ile temel güvenlik duvarı kuralları (Ubuntu/Debian)
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp comment "SSH custom port"
ufw allow 80/tcp comment "HTTP"
ufw allow 443/tcp comment "HTTPS"
ufw enable
ufw status verbose

firewalld kullananlar için:

# CentOS/RHEL sistemlerde firewalld
firewall-cmd --set-default-zone=drop
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

Hangi portların açık olduğunu düzenli kontrol edin. Bir servis kaldırdığınızda güvenlik duvarı kuralını da kaldırmanız gerekir, ama çoğu zaman unutulur.

4. Fail2Ban ile Brute Force Saldırılarına Karşı Koyun

Sunucularınıza bakıyorsanız, auth.log veya secure dosyanız binlerce başarısız giriş denemesiyle dolu olabilir. Bu normal. Ama bunu otomatik olarak engellemeyeceksek, neden log tutuyoruz ki?

# Fail2Ban kurulumu ve temel jail.local yapılandırması
apt install fail2ban

cat > /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5
backend = systemd

[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s

[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
EOF

systemctl enable fail2ban
systemctl restart fail2ban
fail2ban-client status

Bantime değerini iş gereksinimlerinize göre ayarlayın. Kendi ofis IP’nizi ignoreip listesine eklemeyi unutmayın, yoksa bir gün kendinizi dışarıda bulursunuz. Bunu birden fazla kez yaşadım.

5. Gereksiz Servisleri Durdurun ve Devre Dışı Bırakın

Kurulum sırasında gelen ve hiç kullanmayacağınız servisler, saldırı yüzeyinizi gereksiz yere genişletir. Bluetooth daemon, CUPS (yazıcı servisi), avahi-daemon sunucularda ne arıyor?

# Çalışan servisleri listeleyin
systemctl list-units --type=service --state=running

# Gereksiz servisleri durdurun ve devre dışı bırakın
systemctl stop bluetooth
systemctl disable bluetooth

systemctl stop avahi-daemon
systemctl disable avahi-daemon

systemctl stop cups
systemctl disable cups

# Bir servisin neden çalıştığını anlamak için
systemctl status avahi-daemon

Önce ne çalıştığını anlayın, sonra kapatın. Özellikle veritabanı sunucularında, uygulama bağımlılıkları bazen beklenmedik servisleri gerektirebilir. Kapatmadan önce systemctl show --property=WantedBy,RequiredBy ile bağımlılıkları kontrol edin.

6. Otomatik Güvenlik Güncellemelerini Etkinleştirin

“Ben manuel güncelleme yapıyorum” diyenler için bir soru: Son ne zaman güncelleme yaptınız? Özellikle kritik güvenlik yamalarının çıktığı günlerde, otomatik güncelleme hayat kurtarıcı olabiliyor.

# Debian/Ubuntu için unattended-upgrades
apt install unattended-upgrades apt-listchanges

# Yapılandırma dosyasını düzenleyin
cat > /etc/apt/apt.conf.d/50unattended-upgrades << 'EOF'
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Mail "[email protected]";
EOF

# Otomatik güncellemeyi etkinleştirin
dpkg-reconfigure -plow unattended-upgrades

Otomatik yeniden başlatmayı (Automatic-Reboot) üretim ortamında kapalı tutmanızı öneririm. Kernel güncellemesi sonrası beklenmedik reboot, hizmet kesintisine yol açabilir. Bunun yerine güncellemeleri uygulayın, yeniden başlatmayı bakım penceresine alın.

7. Disk Şifrelemesi ve Hassas Dosya İzinleri

Sunucuya fiziksel erişim olan biri için şifrelenmemiş disk bir davet niteliğinde. Veri merkezi ortamında bile LUKS şifrelemesi ciddi bir güvenlik katmanı ekler. Ama en az bunun kadar önemli olan, çalışan sistemdeki dosya izinleri.

# Kritik sistem dosyalarının izinlerini kontrol edin
ls -la /etc/passwd /etc/shadow /etc/sudoers

# shadow dosyası sadece root tarafından okunabilmeli
chmod 640 /etc/shadow
chown root:shadow /etc/shadow

# SSH anahtarlarının izinleri
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_rsa

# SUID/SGID bitli dosyaları bulun ve gözden geçirin
find / -perm /4000 -o -perm /2000 2>/dev/null | grep -v proc

SUID bitli dosyalar listesi sizi şaşırtabilir. passwd, sudo, ping gibi meşru araçlar burada olacak, ama tanımadığınız bir şey görürseniz araştırın. Gereksiz SUID bitleri potansiyel privilege escalation vektörleridir.

8. Sistem Loglarını Merkezi Bir Yerde Toplayın

Bir şeyler ters gittiğinde log olmadan hiçbir şey anlayamazsınız. Üstelik saldırganlar genellikle logları silmeye ya da değiştirmeye çalışır. Merkezi log sunucusu bu riski azaltır.

# rsyslog ile uzak log gönderimi
cat >> /etc/rsyslog.conf << 'EOF'
# Merkezi log sunucusuna gönder
*.* action(type="omfwd" target="log-server.sirketiniz.com" port="514" protocol="tcp")
EOF

systemctl restart rsyslog

# Log dosyalarının değişmediğini doğrulamak için aide kullanabilirsiniz
apt install aide
aideinit
# Günlük kontrol için cron'a ekleyin
echo "0 3 * * * root /usr/bin/aide --check" >> /etc/crontab

Logları düzenli olarak okuyun. journalctl -p err -b komutu son açılıştan bu yana tüm hataları gösterir. Haftalık rutin olarak bu çıktıya bakmak, sorunları erken tespit etmenizi sağlar.

9. İki Faktörlü Kimlik Doğrulama Ekleyin

Parola sızdı, SSH anahtarı çalındı, ne olacak? İkinci bir doğrulama katmanı bu senaryoda hayat kurtarır. Google Authenticator PAM modülü kurulumu çok basit.

# Google Authenticator PAM modülü
apt install libpam-google-authenticator

# Her kullanıcı için ayrı ayrı çalıştırın
google-authenticator

# PAM yapılandırması
echo "auth required pam_google_authenticator.so" >> /etc/pam.d/sshd

# sshd_config'e ekleyin
cat >> /etc/ssh/sshd_config << 'EOF'
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
EOF

systemctl restart sshd

SSH anahtarı artık tek başına yeterli olmayacak, ayrıca TOTP kodu da gerekecek. Bu yapılandırma özellikle kritik altyapı erişimlerinde standart olmalı. Ancak CI/CD pipeline’larınız varsa, bu hesaplar için ayrı servis hesapları kullanın ve 2FA’yı bunlara uygulamayın.

10. Kernel Parametrelerini Güvenlik Odaklı Ayarlayın

sysctl ayarları genellikle ihmal edilir. Oysa ağ tabanlı saldırılara karşı kernel seviyesinde birçok önlem alınabilir.

# /etc/sysctl.d/99-security.conf dosyası oluşturun
cat > /etc/sysctl.d/99-security.conf << 'EOF'
# IP spoofing koruması
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# ICMP redirect kabul etme
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Source routing
net.ipv4.conf.all.accept_source_route = 0

# SYN flood koruması
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2

# ICMP broadcast
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Ptrace kısıtlaması
kernel.yama.ptrace_scope = 1

# Core dump kısıtla
fs.suid_dumpable = 0
EOF

sysctl -p /etc/sysctl.d/99-security.conf

Bu ayarlar router veya ağ cihazı olarak kullanılan sistemlerde farklı olabilir. IP forwarding gibi ayarları amacınıza göre düzenleyin.

11. AppArmor veya SELinux ile Mandatory Access Control

Discretionary access control (DAC), yani standart Unix izinleri, tek başına yeterli değil. Bir servis ele geçirildiğinde o servisin yetkisiyle ne yapılabileceğini sınırlamak için MAC kullanın.

# Ubuntu'da AppArmor durumunu kontrol edin
aa-status

# Profilleri enforce moduna alın
aa-enforce /etc/apparmor.d/*

# Nginx için örnek AppArmor profili durumu
aa-status | grep nginx

# Eğer bir uygulama AppArmor'u engelliyorsa logları inceleyin
grep "apparmor" /var/log/syslog | tail -20

SELinux tercih eden RHEL/CentOS kullanıcıları için:

# SELinux durumunu kontrol edin
sestatus
getenforce

# Permissive moddan Enforcing moda geçiş
setenforce 1

# Kalıcı yapın
sed -i 's/SELINUX=permissive/SELINUX=enforcing/' /etc/selinux/config

# SELinux loglarını izleyin
ausearch -m avc -ts recent

“SELinux her şeyi kırıyor” şikayetini çok duydum. Evet, permissive moddan enforcing moda geçince uygulamalar problem çıkarabilir. Ama bu SELinux’un sorunu değil, uygulamanın beklenen dışı davranmasının işareti. Logları okuyun, politikayı ayarlayın.

12. Ağ Bağlantılarını ve Açık Portları Düzenli Denetleyin

Sunucunuzun dışarıya ne açık olduğunu bilmiyorsanız, güvenliği kontrol ettiğinizi söyleyemezsiniz. Hem yerel hem dış perspektiften düzenli tarama yapın.

# Yerel perspektiften açık portlar
ss -tlnp
netstat -tlnp  # eski sistemlerde

# Hangi process hangi portu dinliyor
ss -tlnp | grep LISTEN

# Dışarıdan port taraması (başka bir sunucudan)
nmap -sV -p- hedef-ip

# Aktif ağ bağlantılarını izleyin
watch -n 5 'ss -tnp | grep ESTABLISHED'

Beklenmedik bir bağlantı görürseniz, hemen process ID’sini alın ve ne olduğunu anlayın. Bunu otomatize etmek için basit bir script yazabilirsiniz:

#!/bin/bash
# Şüpheli dış bağlantıları tespit et
KNOWN_PORTS="22 80 443 3306"
ss -tnp | grep ESTABLISHED | while read line; do
    REMOTE_PORT=$(echo $line | awk '{print $5}' | cut -d: -f2)
    if ! echo $KNOWN_PORTS | grep -q $REMOTE_PORT; then
        echo "$(date): Şüpheli bağlantı: $line" >> /var/log/suspicious_connections.log
    fi
done

13. Parola Politikalarını Güçlendirin

Anahtar tabanlı SSH kullandığınızda bile, sistem üzerindeki diğer servisler, veritabanları ve yerel hesaplar parola kullanıyor olabilir. Zayıf parola politikası tüm diğer önlemleri geçersiz kılabilir.

# PAM ile parola politikası
apt install libpam-pwquality

# /etc/security/pwquality.conf düzenleme
cat > /etc/security/pwquality.conf << 'EOF'
minlen = 14
dcredit = -1
ucredit = -1
ocredit = -1
lcredit = -1
maxrepeat = 3
gecoscheck = 1
dictcheck = 1
EOF

# /etc/pam.d/common-password içinde pwquality'nin etkin olduğunu doğrulayın
grep pam_pwquality /etc/pam.d/common-password

# Parola geçerlilik süresi
chage -M 90 -m 7 -W 14 kullanici_adi
# Tüm kullanıcılara uygulamak için
awk -F: '$3 >= 1000 {print $1}' /etc/passwd | while read user; do
    chage -M 90 -m 7 -W 14 $user
done

14. Dosya Sistemi Bütünlüğünü İzleyin

Rootkit veya backdoor kurulumu genellikle sistem dosyalarında değişiklik gerektirir. Bu değişiklikleri tespit etmek için dosya bütünlüğü izleme şart.

# AIDE (Advanced Intrusion Detection Environment)
apt install aide

# İlk baseline veritabanını oluşturun
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Günlük kontrol için cron görevi
cat > /etc/cron.daily/aide-check << 'EOF'
#!/bin/bash
AIDE_LOG=/var/log/aide/aide-$(date +%Y%m%d).log
/usr/bin/aide --check > $AIDE_LOG 2>&1
if [ -s $AIDE_LOG ]; then
    mail -s "AIDE Alert: $(hostname)" [email protected] < $AIDE_LOG
fi
EOF
chmod +x /etc/cron.daily/aide-check

AIDE veritabanını oluşturduktan sonra, o veritabanını güvenli bir yerde (salt okunur medya veya farklı bir sistem) saklayın. Saldırgan sisteme erişirse AIDE veritabanını da değiştirebilir.

15. Güvenlik Denetimi ve Uyumluluk Taraması

Yukarıdaki 14 maddeyi uyguladınız, peki her şey doğru mu? Manuel kontrol yerine otomatik denetim araçları kullanın.

# Lynis ile güvenlik denetimi
apt install lynis
lynis audit system

# Daha ayrıntılı rapor için
lynis audit system --verbose 2>&1 | tee /var/log/lynis-audit.log

# Sadece kritik bulguları görmek için
grep "WARNING|SUGGESTION" /var/log/lynis-audit.log | head -30

Lynis her çalıştırmada bir hardening index skoru verir. 60 ile başlayan bir sunucuyu 85’e çıkarmak makul bir hedef. 100’e ulaşmaya çalışmak ise çoğu zaman pratik değil, çünkü bazı öneriler belirli kullanım senaryolarında uygulanamaz.

CIS Benchmarks da bu aşamada çok değerli. Red Hat, Ubuntu ve diğer dağıtımlar için yayınlanan bu belgeler, endüstri standartlarında güvenlik yapılandırmasının ne olduğunu çok net açıklıyor.

# OpenSCAP ile CIS benchmark kontrolü
apt install libopenscap8 scap-security-guide
oscap xccdf eval 
  --profile xccdf_org.ssgproject.content_profile_cis 
  --results /tmp/scap-results.xml 
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2004-xccdf.xml

Sonuç

Bu 15 maddeyi tam anlamıyla uygulamak birkaç saatinizi alabilir, ama bu birkaç saatlik yatırım, olası bir ihlalden sonra harcayacağınız günler ve haftalarca süren kriz yönetimiyle kıyaslanamaz.

Önemli olan nokta şu: güvenlik bir kez yapılan bir şey değil. Sunucu ömrü boyunca devam eden bir süreç. Lynis denetimini aylık çalıştırın, log dosyalarını düzenli okuyun, yeni açıklıkları takip edin. Türkiye CERT ve NVD gibi kaynakları beslemenize dahil edin.

Bazı maddeler ortamınıza göre uyarlanabilir. Container ortamında çalışıyorsanız SELinux yerine seccomp profilleri daha uygun olabilir. Kubernetes kullanıyorsanız pod security policies devreye giriyor. Ama temel prensipler değişmiyor: en az ayrıcalık, derinlemesine savunma, izlenebilirlik.

Bu listeyi bir başlangıç noktası olarak görün. Kendi ortamınıza özgü risklerinizi belirleyin, tehdit modelinizi oluşturun ve buna göre öncelik verin. Tüm bunları bir Ansible playbook veya Chef recipe olarak kodlayıp her yeni sunucuya otomatik uyguluyorsanız, çok daha iyi bir noktadasınız demektir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir