Linux Sunucu Güvenliği için Zorunlu 10 Temel Adım

Linux sunucular neden saldırganların ilk hedefi olur?

Dış dünyaya açık bir Linux sunucu, internete bağlandığı andan itibaren taranmaya başlar. Zayıf parolalar, güncel olmayan paketler, gereksiz servisler ve geniş yetkiler aynı makinede buluştuğunda saldırganın işi kolaylaşır. Güvenlik açığının karmaşık olması gerekmiyor; yanlış bırakılmış bir SSH ayarı bile yeterli olabilir.

Üretim ortamlarında gördüğüm ortak nokta şu: Güvenlik tek bir araçla kurulmaz. Paket yönetimi, kimlik doğrulama, ağ sınırları, loglama ve geri dönüş planı birlikte çalışmalıdır. Aşağıdaki 10 adımı, her Linux sunucuya körü körüne uygulanan bir reçete değil, güvenlik taban çizgisi olarak düşünün.

Örneklerde Debian/Ubuntu ve RHEL ailesindeki güncel komutları ayrı ayrı belirtiyorum. Değişiklikleri önce test sunucusunda deneyin; canlı SSH oturumunda yapılan küçük bir hata, erişimi tamamen kaybettirebilir.

Zorunlu 10 temel adımın genel çerçevesi

İlk bakışta 10 adım çok görünebilir. Her biri farklı bir riski hedefliyor:

• Güncel olmayan paketler ve yamalar
• Yanlış yapılandırılmış SSH erişimi
• Gereğinden geniş kullanıcı ve sudo yetkileri
• Açık bırakılmış portlar ve gereksiz servisler
• Yanlış dosya izinleri ve hassas verilerin sızması
• Yetersiz loglama ve izleme
• Eksik yedekleme ve kurtarma planı
• Otomatik güvenlik kontrollerinin bulunmaması
• Yanlış yapılandırılmış firewall ve ağ sınırları
• Standartlaştırılmamış, denetlenmeyen sunucu yapılandırmaları

Şimdi her başlığı, canlı sistemlerde uygulanırken dikkat edilmesi gereken ayrıntılarla açalım.

1. Paket güncellemelerini disiplinli yönet

Güvenlik yamaları ertelendiğinde saldırganın kullanacağı pencere büyür. Paket listesini yenilemek ile paketleri yükseltmek de aynı işlem değildir; apt update yalnızca depolardaki bilgiyi günceller.

Debian ve Ubuntu tabanlı sistemlerde bakım penceresinde şu komutları kullanabilirsiniz:

sudo apt update
sudo apt full-upgrade

full-upgrade bağımlılık değişikliklerinde paket ekleyip kaldırabileceği için üretimde -y ile düşünmeden çalıştırmak yerine çıktıyı incelemeyi tercih ederim. Daha sınırlı bir yükseltme için sudo apt upgrade kullanılabilir.

RHEL, Rocky Linux, AlmaLinux ve Fedora tarafında güncel karşılığı şöyledir:

sudo dnf upgrade --refresh

Otomatik güvenlik güncellemeleri için Debian/Ubuntu’da unattended-upgrades, RHEL ailesinde ise ilgili dağıtımın otomatik güncelleme mekanizması kullanılabilir. Yine de kernel, libc, veritabanı ve web sunucusu gibi bileşenlerde yeniden başlatma veya servis kesintisi ihtimalini izleyin. Otomasyon kurduysanız, başarısız güncellemenin alarmını da kurun; sessizce duran bir görev güvenlik politikası değildir.

• Önce staging veya homelab ortamında güncellemeyi deneyin
• Bakım penceresi ve geri dönüş planı belirleyin
• Kernel güncellemesinden sonra yeniden başlatma gereksinimini kontrol edin
• Dağıtımın güvenlik duyurularını ve paket değişikliklerini izleyin

Bir kernel güncellemesinden sonra açılmayan sunucuyu rescue ortamında chroot ederek ve bootloader’ı yeniden kurarak kurtardığım oldu. O gece snapshot’ın ve konsol erişiminin değeri, bütün dokümantasyondan daha net anlaşıldı. Güncelleme kadar geri dönüş yolu da planın parçasıdır.

2. SSH güvenliği için saldırı yüzeyini küçült

SSH, sunucunun yönetim kapısıdır. Bu kapıda parola denemeleri, eski anahtarlar ve gereksiz tünel izinleri birikiyorsa diğer güvenlik katmanlarının yükü artar.

Parola yerine anahtar temelli kimlik doğrulama kullan

Her yönetici için ayrı kullanıcı ve ayrı SSH anahtarı oluşturun. Özel anahtarı sunucuya koymayın; sunucuda yalnızca public key bulunmalıdır. Yetkili anahtarları dağıtmak için parola ile geçici erişim açmak yerine konsol, mevcut yönetim bağlantısı veya Ansible gibi kontrollü bir yöntem kullanın.

/etc/ssh/sshd_config içinde temel ayarlar şu şekilde olabilir:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Dağıtımın sshd_config.d dizinindeki dosyaları da kontrol edin; sonradan okunan bir dosya beklediğiniz ayarı geçersiz kılabilir. Değişikliği uygulamadan önce yapılandırmayı doğrulayın:

sudo sshd -t
sudo systemctl reload ssh

RHEL ailesinde servis adı çoğunlukla sshd olarak geçer. Reload işleminden önce mevcut oturumu kapatmayın, ikinci bir terminalden anahtarlı girişi test edin. Ben bunu bir keresinde atlamıştım; sorun ayarda değil, bağlanmayı denediğim anahtarın istemci tarafında yanlış kullanıcıya ait çıkmasındaydı.

SSH portunu ve erişim kısıtlarını düzenle

SSH portunu 22 dışına taşımak otomatik tarama gürültüsünü azaltabilir, fakat kimlik doğrulama güvenliğinin yerine geçmez. Asıl değerli kısıtlama, SSH’yi yalnızca yönetim VPN’inden veya bilinen ofis IP aralıklarından kabul etmektir.

Gözden geçirmeniz gereken diğer ayarlar şunlardır:

• Başarısız girişleri sınırlamak için fail2ban veya eşdeğer bir mekanizma
• Uygun ortamlarda FIDO2 anahtarı ya da TOTP tabanlı MFA
• SSH port forwarding özelliklerinin yalnızca ihtiyaç halinde açık olması
• Kullanılmayan kullanıcı anahtarlarının düzenli olarak kaldırılması

Fail2ban firewall’ın yerini tutmaz ve ele geçirilmiş bir hesabı kurtarmaz. Sadece tekrarlanan başarısız denemelere karşı ek bir katmandır.

3. Kullanıcı, grup ve sudo yetkilerini sadeleştir

Her kişinin kendi hesabı olmalı; ortak yönetici hesabı kullanılmamalıdır. Böylece loglarda hangi işlemin kim tarafından yapıldığını takip edebilirsiniz.

• Servisler için giriş yapılamayan sistem kullanıcıları kullanın
• Sudo yetkisini ihtiyacı olan kullanıcı ve komutlarla sınırlayın
• Geçici erişimlere süre ve gerekçe ekleyin
• İşten ayrılan kullanıcıların hesabını, anahtarını ve grup üyeliklerini kaldırın

/etc/sudoers ve /etc/sudoers.d altındaki dosyaları düzenlerken her zaman visudo kullanın:

sudo visudo

Bu komut sözdizimini kaydetmeden önce denetler. Daha da iyisi, sudo kurallarını sürüm kontrolünde tutup değişiklikleri gözden geçirme sürecine bağlamaktır. Herkese ALL=(ALL) NOPASSWD: ALL vermek yönetim kolaylığı değil, root parolasını dosyaya yazmanın farklı bir biçimidir.

4. Firewall ile sadece gerekli portları açık bırak

Sunucunun dinlediği her port internete açık olmak zorunda değildir. Web sunucusu için 80 ve 443, yönetim için kısıtlanmış SSH ve uygulamanın gerçekten ihtiyaç duyduğu diğer portlar dışında gelen trafiği reddetmek iyi bir başlangıçtır.

Ubuntu’da basit bir UFW örneği:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Örnek IP dokümantasyon bloğundandır; kendi VPN veya ofis ağınızla değiştirin. RHEL tabanlı sistemlerde firewalld, daha düşük seviyede ise nftables kullanılabilir. Hangi aracı seçtiğinizden çok kuralların kaynağının, amacının ve değişiklik sahibinin belli olması önemlidir.

Firewall değişikliğinden önce ikinci bir SSH oturumu açın. Kendi erişiminizi yanlışlıkla keserseniz mevcut oturum sizi kurtarabilir, fakat bu bir geri dönüş planı sayılmaz. Konsol erişimini de hazır tutun.

5. Gereksiz servisleri ve portları kapat

Firewall ile gizlenen bir servis hâlâ sistemde çalışıyor olabilir. Önce makinenin ne dinlediğini görün, sonra her portun sahibini ve gerekliliğini sorgulayın.

sudo ss -tulpen

Buradaki -p seçeneği dinleyen soketin arkasındaki işlemi görmeye yardımcı olur; yetki olmadan tüm süreç bilgilerini göremeyebilirsiniz. Servis durumunu da ayrıca kontrol edin:

systemctl --type=service --state=running
systemctl list-unit-files --state=enabled

Eski bir test veritabanı, açık bir yönetim paneli veya artık kullanılmayan RPC servisi, sunucunun saldırı yüzeyini gereksiz yere büyütür. Kullanılmayan paketi kaldırın; yalnızca durdurmak yetmiyorsa otomatik başlatma kaydını da temizleyin. Üretimde “belki lazım olur” diye çalışan servis bırakmamaya çalışıyorum.

6. Dosya izinlerini ve kritik dizinleri gözden geçir

Bir uygulama hesabının okuyabildiği dosya sayısı arttıkça, uygulamadaki bir açığın etkisi de büyür. Web kökü, uygulama yapılandırmaları, loglar, yedekler ve SSH anahtarları ayrı ayrı incelenmelidir.

• Uygulama kodunun sahibi ile web servisinin yazma ihtiyacını birbirinden ayırın
• /var/www altında tüm ağa yazma izni vermeyin
• Veritabanı parolalarını kaynak koduna veya herkese okunabilir dosyalara koymayın
• Yedek dizinlerini web kökünün dışında tutun
• SSH anahtarlarının sahibi ve izinlerini kontrol edin

Kullanıcı SSH dizini için tipik izinler şöyledir:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

İzinleri düzeltirken dosyanın sahibini değiştirmeyi unutmayın:

chown -R kullanici:kullanici ~/.ssh

chmod -R 777 bir onarım yöntemi değildir; yalnızca asıl izin problemini daha geniş bir güvenlik problemine çevirir. Hangi hesabın hangi dosyaya neden yazması gerektiğini belirleyin, sonra en dar izni uygulayın.

7. Loglama, izleme ve uyarı mekanizmasını kur

Bir sunucuyu korumak kadar, ne olduğunu anlayabilmek de gerekir. SSH girişleri, sudo kullanımı, servis yeniden başlatmaları, firewall olayları ve kritik dosya değişiklikleri izlenebilir durumda olmalıdır.

En azından şu sinyaller için alarm kurun:

• Başarısız ve başarılı SSH girişleri
• Beklenmeyen sudo kullanımı veya yeni kullanıcı oluşturulması
• Disk doluluğu, bellek baskısı ve anormal load
• Servis çökmesi ve tekrarlanan yeniden başlatmalar
• Beklenmeyen dinleyen port veya yapılandırma değişikliği

systemd kullanan sistemlerde temel log incelemesi için:

sudo journalctl -u ssh --since "1 hour ago"
sudo journalctl -p warning..alert -b

Dağıtımınıza göre SSH günlükleri /var/log/auth.log veya /var/log/secure altında da bulunabilir. Logları aynı sunucuda tutmak tek başına yeterli değildir; saldırgan makineye eriştiğinde kanıtları da silebilir. Birden fazla sunucuda merkezi log toplama, zaman eşitlemesi ve erişim kontrollü saklama kullanın.

Evdeki Proxmox laboratuvarımda Uptime Kuma, Prometheus ve Grafana birlikte çalışıyor. Bu araçlar saldırıyı kendiliğinden çözmez, fakat disk doluluğu veya servis düşüşünü sessizce beklemek yerine bana erken sinyal verir.

8. Yedekleme ve felaket kurtarma planı oluştur

Güvenlik önlemleri her olayı engelleyemez. Yanlış bir rm, bozuk bir güncelleme, disk arızası veya fidye yazılımı sonrasında geri dönebileceğiniz doğrulanmış bir kopya gerekir.

• Verinin değişim hızına göre yedekleme sıklığını belirleyin
• En az bir kopyayı farklı bir sistemde ve farklı lokasyonda tutun
• Dış ortama çıkan yedekleri şifreleyin
• Silinmeye ve değiştirilmeye karşı korumalı veya immutable kopyalar kullanın
• Geri dönüş süresini ve kabul edilebilir veri kaybını yazılı hale getirin

3-2-1 yaklaşımı hâlâ pratik bir başlangıçtır: en az üç kopya, iki farklı ortam ve bir kopya farklı lokasyonda. Ben dosya senkronizasyonu için rsync, sürümlü ve şifreli yedekler için borgbackup kullanıyorum; fakat kullanılan araçtan daha önemli olan düzenli geri dönüş provasıdır.

Test edilmemiş yedek yalnızca umut verir. Ayda bir örnek bir dosyayı, mümkünse izole bir ortama tam servis geri dönüşünü deneyin. Yedekleme işinin başarılı göründüğünü söyleyen log ile gerçekten açılan bir uygulama aynı şey değildir.

9. Otomatik güvenlik taramaları ve hardening araçları kullan

Elle kontrol gerekir, fakat her sunucuda aynı listeyi tekrar tekrar elle uygulamak hata üretir. CIS benchmark kontrolleri, Lynis gibi denetim araçları, paket güvenlik raporları ve dosya bütünlüğü izleme çözümleri bu noktada yardımcı olabilir.

Bir aracın önerdiği her ayarı doğrudan canlıya uygulamayın. Örneğin bir tarayıcı, çalışan bir uygulamanın gerektirdiği çekirdek parametresini veya servis özelliğini riskli işaretleyebilir. Önce önerinin neyi değiştirdiğini, hangi bileşeni etkilediğini ve geri dönüşünü okuyun.

Otomatik kontrolleri şu şekilde değerlendirin:

• İmaj veya kurulum sonrasında başlangıç taraması yapın
• Periyodik taramaları raporlayıp değişiklikleri karşılaştırın
• Yüksek riskli bulgular için sorumlu ve son tarih belirleyin
• Yanlış pozitifleri gerekçesiyle kayda alın

Güvenlik aracını kurup raporlarını hiç okumamak, alarmı kapatılmış bir duman dedektöründen farksızdır.

10. Konfigürasyon yönetimi ve altyapı standardizasyonu sağla

Elle kurulmuş ve zaman içinde farklılaşmış sunucuların güvenlik seviyesini bilmek zordur. Bir makinede kapatılan parola erişimi diğerinde açık kalabilir; birinde uygulanan firewall kuralı başka birinde unutulabilir.

Sağlam bir çalışma düzeni için:

• Sunucu rollerini web, veritabanı, cache ve worker gibi profillere ayırın
• Kurulum ve sertleştirme adımlarını Ansible gibi araçlarla tekrarlanabilir hale getirin
• Konfigürasyonları sürüm kontrolünde tutun ve gizli değerleri depoya yazmayın
• Değişiklikleri önce test ortamında uygulayın
• Sunucu envanterini, sahipliğini ve yaşam döngüsünü kayıt altında tutun

Elle iki kez yaptığım işi üçüncüde playbook’a dönüştürmeye çalışıyorum; tek satırlık bir iş için YAML açmak bazen gereksiz, ama aynı güvenlik ayarını on sunucuda tutarlı uygulamak için ciddi zaman kazandırıyor. Standart bir temel imaj ve düzenli yapılandırma denetimi, tek seferlik hardening işleminden daha değerlidir.

Süreklilik, denetim ve insan faktörü

Güvenlik ayarları bir kez yapılıp bırakılmaz. Yeni kullanıcılar, yeni servisler, paket güncellemeleri ve mimari değişiklikler ilk durumu kısa sürede değiştirebilir.

• Aylık veya üç aylık periyotlarla kullanıcı, anahtar ve sudo listelerini gözden geçirin
• Dinleyen portları ve firewall kurallarını envanterle karşılaştırın
• Yılda en az bir kez güvenlik değerlendirmesi veya sızma testi planlayın
• Yeni servis devreye alınırken güvenlik kontrol listesini zorunlu tutun
• Yedek geri dönüşü ve olay müdahalesi için tatbikat yapın

Paylaşılan hesaplar, aceleyle onaylanan erişim talepleri ve log okumadan yapılan yeniden başlatmalar teknik ayarlar kadar risklidir. Benim production shell’lerimde kırmızı prompt kullanmamın nedeni de bu: komut çalıştırmadan önce hostname’i tekrar görmeye ihtiyacım var. Küçük bir alışkanlık, pahalı bir hatayı engelleyebilir.

Güvenlik seviyenizi bugün yükseltin

Bu 10 adımı aynı gün tamamlamak zorunda değilsiniz. Önce güncelleme durumunu, SSH ayarlarını, açık portları ve yedeklerin gerçekten geri dönüp dönmediğini kontrol edin. Ardından bulguları bir listeye yazıp sorumlusu ve tamamlanma tarihi belli işler haline getirin.

Linux tabanlı altyapınızı çalıştırmak için kaynakları kolayca ölçekleyebileceğiniz sanal sunucu çözümleri işinizi kolaylaştırabilir. Türkiye lokasyonunda VPS arıyorsanız VPS.TC Linux VPS sunucuları veya daha ayrıntılı kaynak kontrolü için VPS.TC VDS çözümleri ile güvenlik kontrollerini kendiniz uygulayabileceğiniz bir temel oluşturabilirsiniz.

Kısa bir kontrol listesi hazırlayın, her değişikliği önce test edin ve uyguladığınız ayarın geri dönüşünü de yazın. Güvenlikte en sevdiğim kayıt, çalışmayan bir ayarı nasıl geri aldığımı anlatan kayıttır.

Sunucu güvenliğini temel seviyede sağladıktan sonra, uygulamanın kullandığı veritabanını da aynı ciddiyetle yapılandırmak gerekiyor. Bunun için VPS’te MySQL kurulumu ve güvenli yapılandırma adımlarını anlattığım rehbere göz atabilirsiniz.

Linux sunucu güvenliğinde temel adımları uyguladıktan sonra, yoğun ve kötü niyetli trafik karşısında ne yapacağınızı da bilmeniz gerekir. Bu nedenle DDoS Saldırısı Nedir? VPS Koruma Rehberi yazımda, saldırıyı erken fark etmek ve VPS’inizi korumak için izleyebileceğiniz pratik adımları anlattım.

Sık Sorulan Sorular

Linux sunucu güvenliği için ilk hangi kontrol yapılmalı?

Önce erişimi kaybetmeden mevcut durumu çıkarın: işletim sistemi sürümünü, bekleyen güvenlik güncellemelerini, SSH ayarlarını, kullanıcıları ve dinleyen portları kontrol edin. Ardından değişiklikleri test ortamında uygulayın.

SSH portunu değiştirmek güvenliği sağlar mı?

Tek başına sağlamaz. Port değiştirmek otomatik tarama gürültüsünü azaltabilir; anahtar tabanlı giriş, root erişiminin kapatılması, MFA ve firewall ile kaynak IP kısıtlaması asıl güvenlik katmanlarıdır.

fail2ban kullanmak firewall ihtiyacını ortadan kaldırır mı?

Hayır. fail2ban tekrarlanan başarısız giriş denemelerine karşı geçici engel koyar. Gereksiz portları kapatmak ve yönetim erişimini güvenilir ağlarla sınırlamak için ayrıca firewall gerekir.

Yedekleme güvenlik planının parçası sayılır mı?

Evet. Bir ihlali her zaman önleyemezsiniz; fakat şifreli, farklı lokasyonda tutulan ve düzenli olarak geri dönüşü test edilen yedekler olayın etkisini ciddi biçimde azaltır.