Linux Sunucu Güvenliği: İlk 10 Sertleştirme Adımı

Yeni bir Linux sunucusu kiraladığınızda, kutudan çıktığı haliyle o makine genellikle "çalışır" durumdadır ama "güvenli" değildir. Varsayılan ayarlar erişilebilirliği önceler; oysa internete açık bir sunucu, ayakta olduğu ilk dakikadan itibaren otomatik tarama botlarının, parola deneme saldırılarının ve açık port avcılarının radarına girer. Bu botlar sizi tanımaz, hedef seçmez; halka açık her IP'yi durmadan tarar. Bu rehberde, henüz taze kurulmuş bir sunucuyu saldırı yüzeyini gözle görülür biçimde daraltacak şekilde, adım adım nasıl sertleştireceğinizi anlatıyorum.

Aşağıdaki 10 adımı Ubuntu ve Debian tabanlı sistemler üzerinden gösteriyorum; ancak arkasındaki mantık ve komutların büyük çoğunluğu, yalnızca paket yöneticisi değiştirilerek diğer dağıtımlarda da uygulanabilir. Adımları sırayla ilerletmenizi öneririm: her biri bir öncekinin üzerine oturur ve hep birlikte katmanlı bir savunma (defense in depth) oluşturur. Tek bir önlem sizi tam korumaz; asıl güç bunların üst üste binmesindedir. Sunucuyu ilk kurduğunuz anda bu listeyi bir kontrol listesi gibi baştan sona takip edin.

1. Sistemi Tamamen Güncelleyin#

Bir sunucuyu sertleştirmenin en temel, buna karşın en sık atlanan adımı, kurulu tüm paketleri güncel tutmaktır. Kullandığınız hazır imaj birkaç ay öncesine ait olabilir ve bu süre boyunca yayınlanmış onlarca güvenlik yamasını içermeyebilir. Yani daha ilk saniyeden, çoktan kapatılmış açıklarla internete çıkmış olursunuz.

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

Özellikle çekirdek (kernel) güncellemelerinden sonra sistemi yeniden başlatmanız gerekebilir. Bunun gerekip gerekmediğini şu tek satırla anlayabilirsiniz:

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

Güncellemeyi tek seferlik bir görev değil, sürekli bir alışkanlık olarak düşünün. 6. adımda bu işi otomatiğe bağlayacağız; yine de kritik yamalar için ara sıra elle kontrol etmek her zaman iyi bir refleks olarak kalsın.

2. Ayrı Bir Sudo Kullanıcısı Oluşturun#

root hesabıyla günlük iş yapmak, gaza sonuna kadar basılı bir arabayı sürmek gibidir: tek bir yanlış komut tüm sistemi geri dönüşsüz silebilir ve root üzerinden gelen bir saldırı, daha ilk anda saldırgana tam yetki teslim eder. Bunun yerine sınırlı yetkiye sahip, ihtiyaç anında sudo ile geçici olarak yükselen normal bir kullanıcı açın.

adduser cloutr
usermod -aG sudo cloutr

Yeni kullanıcının sudo yetkisinin çalıştığını doğrulamak için o hesaba geçip yetki gerektiren basit bir komut deneyin:

su - cloutr
sudo whoami   # çıktı: root

Bundan sonra sunucuya doğrudan root yerine bu kullanıcıyla bağlanacak, yönetici işlemlerini gerektiğinde sudo ile yapacaksınız. Bu yaklaşımın iki büyük kazancı var: hem yıkıcı komutları yanlışlıkla çalıştırma ihtimalinizi düşürür hem de her yetkili işlemin izini sudo günlüklerinde bırakır. Böylece sunucuda kim, ne zaman, neyi yaptı sorusunun cevabı kayıt altında olur.

3. SSH Anahtarı ile Girişe Geçin#

Parola ile SSH girişi, kaba kuvvet (brute-force) saldırılarına karşı kırılgandır: saldırgan yeterince deneme yaparsa er ya da geç zayıf bir parolayı bulabilir. SSH anahtar çifti ise bambaşka bir güvenlik seviyesindedir; özel anahtarınızı ele geçirmeden kimse içeri giremez ve iyi bir anahtar pratikte tahmin edilemez. İlk iş olarak kendi bilgisayarınızda (sunucuda değil) bir anahtar çifti üretin:

ssh-keygen -t ed25519 -C "cloutr-sunucu"

ed25519 günümüzde hem hızlı hem de güçlü kabul edilen bir algoritmadır; eski rsa yerine bunu tercih edin. Ürettiğiniz açık anahtarı sunucuya kopyalayın:

ssh-copy-id cloutr@SUNUCU_IP

Sisteminizde ssh-copy-id yoksa, açık anahtar dosyasının (~/.ssh/id_ed25519.pub) içeriğini sunucudaki ~/.ssh/authorized_keys dosyasına elle ekleyebilirsiniz. Bu durumda dizin ve dosya izinlerinin doğru olması kritik önemdedir; aksi halde SSH güvenlik gereği anahtarı yok sayar:

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

Anahtarla giriş yapabildiğinizi mutlaka test edin. Bir sonraki adımda parola girişini tümüyle kapatacağımız için, aktif oturumdan çıkmadan önce anahtarınızın gerçekten çalıştığından kesinlikle emin olun; aksi halde kendinizi sunucudan dışarıda bırakabilirsiniz. SSH'ın tüm ayrıntılarını ve ek sertleştirme seçeneklerini SSH bağlantısı ve güvenliği rehberimizde bulabilirsiniz.

4. Parola Girişini ve Root SSH'ını Kapatın#

Anahtarınızın sorunsuz çalıştığından emin olduktan sonra SSH sunucu yapılandırmasını sertleştirebiliriz. /etc/ssh/sshd_config dosyasını düzenleyin:

sudo nano /etc/ssh/sshd_config

Aşağıdaki ayarların şu değerlerde olduğundan emin olun. İlgili satırlar dosyada # ile yorum satırı olarak duruyorsa, başındaki # işaretini kaldırıp değeri güncelleyin:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

KbdInteractiveAuthentication, eski OpenSSH sürümlerinde ChallengeResponseAuthentication olarak geçen ayarın güncel adıdır; sisteminizde hangisi tanımlıysa onu no yapın. Bu blok, hem doğrudan root girişini hem de parola/klavye tabanlı doğrulamayı kapatarak yalnızca anahtarla girişe izin verir.

İsteğe bağlı ama önerdiğim bir ek önlem, varsayılan 22 portunu değiştirmektir (örneğin Port 2222). Bunu net bir çerçeveye oturtalım: bu "güvenlik" değil, "gürültü azaltma" önlemidir. Kararlı bir saldırgan tüm portları tarayarak SSH'ı yine bulur; ancak internetteki otomatik botların ezici çoğunluğu yalnızca 22'ye vurduğu için, port değişikliği günlüklerinizdeki başarısız deneme selini ciddi biçimde azaltır. Portu değiştirdiyseniz güvenlik duvarında yeni portu açmayı unutmayın, aksi halde kendinizi kilitlersiniz. Değişiklikleri kaydettikten sonra SSH servisini yeniden başlatın:

sudo systemctl restart ssh

Bazı Ubuntu sürümlerinde servis adı ssh yerine sshd olabilir; komut hata verirse sudo systemctl restart sshd deneyin. Yakın Ubuntu sürümlerinde SSH soket etkinleştirmeyle çalıştığından, port değişikliğinin tam oturması için sudo systemctl restart ssh.socket de gerekebilir.

Mevcut oturumunuzu kapatmadan, ayrı bir terminalde yeni port ve kullanıcıyla bağlanabildiğinizi test edin. İlk oturumu açık tutmak, bir hata durumunda kilitli kalmanızın önündeki tek güvencedir.

5. UFW Güvenlik Duvarını Yapılandırın#

Güvenlik duvarı, sunucunuza dışarıdan hangi portlar üzerinden erişilebileceğini belirleyerek saldırı yüzeyini doğrudan daraltır. ufw (Uncomplicated Firewall), arka planda çalışan iptables/nftables altyapısına sade bir arayüz sunar. En güvenli başlangıç, gelen tüm bağlantıları varsayılan olarak reddetmek ve yalnızca gerçekten ihtiyaç duyduğunuz portları tek tek açmaktır:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH        # SSH portunu değiştirdiyseniz: sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp         # HTTP
sudo ufw allow 443/tcp        # HTTPS
sudo ufw enable

Kuralların doğru işlediğini görmek için durumu kontrol edin:

sudo ufw status verbose

Sunucuda bir web servisi çalıştırmıyorsanız 80 ve 443'ü açmanıza hiç gerek yoktur. Kural şudur: yalnızca fiilen kullandığınız portları açık bırakın, çünkü açtığınız her port aynı zamanda potansiyel bir giriş noktasıdır. Uygulamanız TLS trafiğini güvenli servis etsin diye ayrıca bir SSL sertifikası kurmayı da planlamalısınız; SSL'in tam olarak ne işe yaradığını merak ediyorsanız SSL sertifikası nedir yazımıza göz atın.

6. Otomatik Güvenlik Güncellemelerini Açın#

Kritik güvenlik yamalarını her gün elle takip etmek zordur ve bir gün mutlaka atlanır. unattended-upgrades paketi tam bu boşluğu kapatır; güvenlik güncellemelerini sizin müdahaleniz olmadan otomatik uygular:

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

Davranışın ince ayarını /etc/apt/apt.conf.d/50unattended-upgrades dosyasından yapabilirsiniz. Örneğin yalnızca güvenlik deposundan gelen güncellemelerin etkin olduğundan emin olun ve otomatik yeniden başlatmayı, kimseyi rahatsız etmeyecek bir gece saatine sabitleyin:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Kritik üretim sunucularında otomatik yeniden başlatmayı önceden belirlenmiş bir bakım penceresine çekmek, plansız kesintilerin önüne geçer. Ayarları devreye almadan önce kuru bir test (dry-run) çalıştırarak sistemin ne yapacağını görebilirsiniz:

sudo unattended-upgrade --dry-run --debug

7. Fail2ban ile Kaba Kuvvet Saldırılarını Engelleyin#

SSH anahtarına geçmiş olsanız bile sunucunuz aralıksız giriş denemeleriyle dövülmeye devam eder; botlar parola kapalı olsa da denemekten vazgeçmez. fail2ban, kimlik doğrulama günlüklerini izler ve kısa sürede belirli sayıda başarısız denemede bulunan bir IP'yi belirli bir süre için engeller. Kurmak için:

sudo apt install fail2ban -y

Ana yapılandırma dosyası jail.conf'u doğrudan düzenlemeyin; onun yerine ayarlarınızı bir jail.local dosyasında toplayın. Paket güncellendiğinde jail.conf yenilenir ama jail.local korunur, yani ayarlarınız ezilmez:

sudo nano /etc/fail2ban/jail.local

Bu dosyaya yalnızca değiştirmek istediğiniz ayarları yazmanız yeterlidir. [sshd] bölümünü etkinleştirip makul bir eşik belirleyin:

[sshd]
enabled = true
maxretry = 4
bantime = 3600
findtime = 600

Ardından servisi başlatın ve durumunu kontrol edin:

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

Buradaki üç değer davranışı belirler: findtime (kaç saniyelik pencerede sayılacağı), maxretry (o pencerede izin verilen başarısız deneme sayısı) ve bantime (yasak süresi, saniye). Bunları kendi iş yükünüze göre ayarlayın. Uzun bir bantime daha güvenlidir ama parolasını hatırlamayan meşru bir kullanıcıyı da geçici olarak dışarıda bırakabilir; bu dengeyi gözetin.

8. Gereksiz Servisleri Kapatın#

Arka planda çalışan her servis, dışarıya bakan bir kapı ve dolayısıyla ek bir saldırı yüzeyidir. İlk olarak sunucunuzda hangi portların dinlendiğini ve bunları hangi süreçlerin açtığını görün:

sudo ss -tulpn

İhtiyaç duymadığınız her servisi durdurup açılışta başlamasını da engelleyin. Örneğin sade bir web sunucusunda çalışmasına hiç gerek olmayan bir yazdırma servisi (CUPS) varsa:

sudo systemctl disable --now cups

Kurulu ama kullanmadığınız paketleri de tamamen kaldırın; çünkü sistemde olmayan bir yazılım, gelecekte yamalanması gereken bir açık daha az demektir:

sudo apt purge PAKET_ADI -y
sudo apt autoremove -y

Buradaki genel ilke tek bir cümlede özetlenir: Bir servisin neden çalıştığını açıklayamıyorsanız, muhtemelen kapatmalısınız. En az ayrıcalık (least privilege) mantığıyla, yalnızca uygulamanızın gerçekten ihtiyaç duyduğu en küçük servis kümesini açık bırakın.

9. Güçlü Parolalar ve İki Faktörlü Doğrulama (2FA)#

SSH'ı artık anahtarla korumuş olsanız da, sudo parolanız, veritabanı kullanıcılarınız ve yönetim panel hesaplarınız hâlâ parola tabanlıdır. Veri ihlallerinin büyük kısmının kökeninde zayıf ya da farklı yerlerde tekrar kullanılan parolalar yatar; bu yüzden her hesap için uzun, benzersiz ve rastgele parolalar kullanın. Böyle parolalar üretmek için şifre üretici aracımızı kullanabilirsiniz.

Kritik hesaplara mümkün olan her yerde iki faktörlü doğrulama (2FA) ekleyin; parola çalınsa bile ikinci faktör olmadan giriş yapılamaz. Dilerseniz SSH'a bile TOTP tabanlı bir 2FA katmanı ekleyebilirsiniz:

sudo apt install libpam-google-authenticator -y
google-authenticator

Kurulum sırasında ekrana gelen QR kodunu Google Authenticator, Authy ya da benzeri bir uygulamayla tarayın ve size verilen yedek kodları güvenli bir yere kaydedin. Bu yedek kodlar hayat kurtarıcıdır: telefonunuzu kaybettiğinizde tek geçiş yolunuz onlar olur. Onları kaybederseniz aynı 2FA sizi de sunucudan kilitleyebilir, bu yüzden mutlaka çevrimdışı ve güvenli bir yerde saklayın.

10. Yedekleme ve İzleme Kurun#

En titiz sertleştirme bile bir ihlali ya da donanım arızasını yüzde yüz önleyemez; güvenlik olasılıkları düşürmekle ilgilidir, sıfırlamakla değil. Bu nedenle düzenli, otomatik ve sunucudan bağımsız bir konumda tutulan yedekler pazarlık konusu olamaz. Yedeği yalnızca aynı diskte tutmak, disk çöktüğünde hem asıl veriyi hem de yedeği aynı anda kaybetmek demektir; yani hiç yedek almamış gibi olursunuz.

Basit bir dosya yedeğini rsync ile alıp cron ile otomatikleştirebilirsiniz:

rsync -avz --delete /var/www/ /yedek/www/

Bu komutu her gece çalışacak bir cron görevine bağlamak için crontab -e çalıştırıp şu satırı ekleyin:

0 3 * * * rsync -avz --delete /var/www/ /yedek/www/ >> /var/log/yedek.log 2>&1

Yalnızca dosyalar yetmez; veritabanlarınızı da düzenli olarak dışa aktarmayı unutmayın, çünkü dinamik içeriğin gerçek değeri çoğu zaman oradadır:

mysqldump -u root -p --all-databases | gzip > /yedek/db_$(date +%F).sql.gz

İzleme tarafında ise sunucu kaynaklarını (CPU, RAM, disk kullanımı), açık oturumları (last, who) ve kimlik doğrulama günlüklerini (/var/log/auth.log) düzenli aralıklarla gözden geçirin. Beklenmedik disk dolulukları, açılmaması gereken portlar ya da art arda gelen başarısız giriş denemeleri, çoğu zaman bir sorunun ilk sessiz işaretleridir; erken fark etmek, olayı büyümeden çözmenin anahtarıdır. Yedekleme stratejinizi elle uğraşmaktan kurtarıp profesyonel bir altyapıya taşımak isterseniz, yedekleme çözümlerimiz tam otomatik ve sunucu dışı depolama sunar.

Sertleştirme Kontrol Listesi Özeti#

Aşağıdaki tablo, uyguladığınız her adımın hangi tehdide karşı koruma sağladığını bir bakışta özetler:

Sıkça Sorulan Sorular#

SSH portunu değiştirmek gerçekten güvenlik sağlar mı?#

Tek başına bir güvenlik önlemi değildir; kararlı bir saldırgan tüm portları tarayarak SSH'ı yine bulur. Buna karşın varsayılan 22 portundaki otomatik bot gürültüsünü belirgin biçimde azaltır ve günlüklerinizi okunabilir tutar. Bu yüzden port değiştirmeyi asıl önlemlerin (anahtarla giriş, Fail2ban, güvenlik duvarı) yerine değil, üzerine ince bir katman olarak ekleyin.

Fail2ban kullanırken kendimi yanlışlıkla kilitleyebilir miyim?#

Evet; kısa sürede art arda birkaç kez yanlış parola ya da yanlış anahtar denerseniz kendi IP'niz de yasaklanabilir. Bunu önlemek için sabit IP adresinizi jail.local içindeki ignoreip satırına ekleyebilirsiniz. Yine de kilitli kalırsanız, sunucu sağlayıcınızın web tabanlı konsolundan (VNC ya da kurtarma modu) bağlanıp yasağı sudo fail2ban-client unban IP_ADRESI komutuyla kaldırabilirsiniz.

Otomatik güncellemeler sunucumu bozar mı?#

unattended-upgrades varsayılan olarak yalnızca güvenlik deposundan gelen yamaları uygular; bu yüzden bir şeyi bozma riski oldukça düşüktür. Yine de kritik üretim sistemlerinde otomatik yeniden başlatmayı bir gece bakım penceresine ayarlamak ve büyük değişiklikleri önce bir test sunucusunda denemek en temkinli yaklaşımdır.

Yönetilen (managed) bir hosting kullanıyorsam bu adımları yapmam gerekir mi?#

Paylaşımlı hosting ya da tam yönetilen sunucularda çekirdek güncellemeleri, güvenlik duvarı ve yamalar çoğunlukla sağlayıcı tarafından üstlenilir; bu durumda çoğu adım sizin sorumluluğunuzda olmaz. Ancak root erişimine sahip kendi VDS veya sanal sunucunuzda işletim sistemi seviyesindeki güvenlik tümüyle size aittir ve bu rehberdeki her adım sizin için geçerlidir.

Anahtarla giriş varken 2FA yine de gerekli mi?#

SSH anahtarı zaten çok güçlü bir kimlik doğrulama yöntemidir, ama 2FA sizi farklı bir riske karşı korur: özel anahtarınızın bulunduğu bilgisayarın çalınması ya da ele geçirilmesi. Böyle bir durumda tek başına anahtar yeterli olurken, ikinci faktör devrede olduğunda saldırgan yine de içeri giremez. Özellikle birden fazla kişinin bağlandığı ya da yüksek değerli sunucularda 2FA'yı bir üst katman olarak eklemeye değer.

Tüm bu adımları uygulamak ne kadar sürer?#

Daha önce benzer işler yapmış bir kullanıcı için ilk 8 adım aşağı yukarı 20-30 dakika sürer. Buna karşın acele etmeyin: özellikle 3. ve 4. adımlarda, parola girişini kapatmadan önce anahtarla bağlanabildiğinizi ayrı bir oturumda mutlaka doğrulayın. Bu tek kontrol, kendinizi sunucudan kilitlemenizle sorunsuz devam etmeniz arasındaki farkı belirler.

Yeni bir sunucunun ilk saati, çoğu zaman tüm ömrü boyunca taşıyacağı güvenlik seviyesini belirleyen en kritik andır. Bu on adımı bir alışkanlık hâline getirdiğinizde, sunucunuz internetteki otomatik saldırıların büyük çoğunluğuna karşı belirgin biçimde dayanıklı olur. Güçlü, kararlı ve tam denetiminizde bir altyapı üzerinde çalışmak isterseniz, root erişimi sunan VDS sunucularımızı veya esnek sanal sunucu paketlerimizi inceleyebilir; bu sertleştirme adımlarını daha ilk günden kendi sunucunuza uygulamaya başlayabilirsiniz.