Web Sunucu Güvenlik Checklist’i: Linux ve Windows İçin Temel Rehber

Web sitesi, otel ve B2B gelirinin “dijital resepsiyonu” gibidir; sunucu tarafındaki küçük açıklar bile hem kesinti (uptime kaybı) hem de veri riski olarak geri döner. Bu rehber, komut ezberi yerine konsept düzeyinde ama uygulanabilir bir baseline güvenlik modeli sunar: önce işletim sistemi ve yamalar, sonra erişim, ardından firewall/port yönetimi, en son yedekleme-izleme ile işi kapatırsınız. Böylece ajans/BT ekibi, go-live öncesi veya sezon pikinde (özellikle turizmde) güvenlik kontrolünü hızlıca standardize eder.

Web sunucu güvenliğini pratikte “tek ayar” çözmez; güvenlik bir katmanlar sistemidir. Bu yazıda 4 ana katmanı kullanacağız: 1. OS Hardening (işletim sistemi + paketler) 2. Erişim katmanı (SSH/RDP + kullanıcı/rol) 3. Ağ katmanı (firewall + port/servis azaltma + WAF) 4. Dayanıklılık katmanı (yedekleme + izleme + loglama)

Veri noktası (yumuşatılmış): Basit hardening önlemleri (güncelleme, erişim sınırı, port azaltma) uygulanmayan sunucuların, otomatik tarama/bot saldırılarına daha sık maruz kaldığı çoğu ortamda gözlenir. Yani “baseline” yoksa saldırı gürültüsü ve risk artar.

Web sunucu güvenlik checklist’i nasıl olmalı?

İyi bir checklist katmanlı olmalı ve “bir kez yap–bitti” değil, rutin olarak yürütülmelidir. Önce OS ve güncellemeler, sonra erişim kontrolü, ardından firewall/port yönetimi, en son yedekleme ve izleme ile tamamlanır. Bu sırayı bozmak genelde “kapıyı kilitlemeden alarm takmak” gibi verimsiz olur.

Web sunucum güvenli mi, nereden başlamalıyım?

Başlangıç için 4 adım: (1) Patch durumu (kritik güncellemeler), (2) root/admin erişimi (kısıtlı mı?), (3) açık portlar (gereksiz var mı?), (4) yedek + geri dönüş testi (son 30 günde yapıldı mı?). Bu dört kontrol “en hızlı risk azaltma” setidir.

“Konsept Düzeyinde” Baseline Neden Önemli?

Çoğu içerik komut listesine gömülür; fakat ekipler değişir, vendor güncellenir, ortamlar (on-prem/cloud) farklılaşır. Bu yüzden bu rehberin ana hedefi: • Prensip bazlı (kalıcı) • İş uyumlu (BT + yönetim dili) • Uygulanabilir (go-live checklist’i gibi) bir çerçeve kurmaktır.

Sunucu güvenliğinin en temel bileşeni patch yönetimidir. Linux ya da Windows fark etmez: zafiyetler (CVE’ler) “bilinip unutulmaz”; saldırganlar otomatik tarama ile açıkları aktif olarak arar. Bu nedenle hedef; “güncelleme yapıyorum” demek değil, güncellemeyi yönetilebilir bir rutine oturtmaktır.

Linux/Windows Update ve Patch Politikaları

Patch yönetimi pratikte 3 parçadır: • Sıklık: Kritik güvenlik yamaları için hızlı pencere (ör. 24–72 saat hedef), diğerleri için haftalık/aylık bakım penceresi • Kapsam: OS + web server + runtime (PHP/Node/Java) + bağımlılıklar • Doğrulama: Güncelleme sonrası servis health-check ve log kontrolü Linux tarafında paket yöneticisi (apt/yum/dnf) ve repo politikaları; Windows tarafında Windows Update, WSUS/Intune gibi mekanizmalar devreye girer. Otel/B2B tarafında kritik nokta: sezon/pik trafik dönemlerinde plansız restart riskini kontrol etmektir.

OS Hardening: Baseline Ayar Mantığı

“Hardening”i tek bir ayar listesi olarak değil, şu hedeflerle düşünün: • Minimum yetki: Servisler sadece ihtiyaç duyduğu izinlerle çalışır • Gereksiz bileşeni çıkar: Kullanılmayan paket/servis/role kapatılır • Görünürlük: Güvenlik olayları loglanır ve izlenir

Patch Sürecini İşe Uyumlu Hale Getirmek

Otel ve ajans tarafında en çok kaçırılan nokta şudur: Güncelleme işi, sadece BT’nin değil, iş sürekliliği sorunudur. Bu yüzden: • Bakım penceresini yönetimle netleştirin (ör. gece düşük trafik) • Rollback planı belirleyin (geri dönüş yolu) • “Önce staging, sonra prod” disiplinini mümkün oldukça kurun

Sunucuya erişim, güvenlikte en yüksek etkili noktalardan biridir. Çünkü saldırıların büyük kısmı ya zayıf kimlik doğrulama ya da fazla yetkili hesap üzerinden büyür. Buradaki hedef: erişimi kapatmak değil, erişimi doğru kimlikle, doğru yetkiyle, izlenebilir hale getirmektir.

Root/Admin Hesaplarının Sınırlandırılması

Root/admin hesabını “gerekli ama tehlikeli” olarak düşünün. Yapılması gereken: • Root/admin ile direkt login’i minimize etmek • Günlük iş için ayrı kullanıcılar + role-based yetki • “Yükseltme (sudo/privileged)” akışını kontrol etmek • Erişimleri kişiye özel ve geri alınabilir yapmak (shared account anti-pattern)

SSH Key Yönetimi, RDP Güvenliği

SSH (Linux): • Parola yerine key temelli erişim • Key’lerin yaşam döngüsü: oluşturma, saklama, rotasyon, iptal • Mümkünse MFA / bastion yaklaşımı • Fail2Ban gibi brute-force önleyici katman RDP (Windows): • İnternete açık RDP’den kaçınma (VPN, jump host, allowlist) • MFA ve güçlü politika • Oturum zaman aşımı, cihaz/konum kısıtları • Deneme/başarısız giriş alarmları

Root/admin erişimini nasıl sınırlandırırım?

Önce “shared admin” kullanımını bitirin: herkesin kendi hesabı olsun. Sonra admin yetkisini sadece gerektiğinde yükseltin (sudo/privileged) ve bu yükseltmeyi loglayın. Son olarak erişim yollarını daraltın: SSH/RDP’yi allowlist/VPN/jump host üzerinden çalıştırın ve başarısız girişleri otomatik olarak engelleyin.

Ağ katmanı çoğu zaman “firewall açık mı?” seviyesinde ele alınır; oysa asıl kazanım “gereksiz yüzeyi kapatmak”tır. Bir web sunucusu için ideal yaklaşım: az port, az servis, net kurallar. Burada kritik hedef; saldırı yüzeyini küçültmek ve trafik akışını anlaşılır hale getirmektir.

Gereksiz Servis ve Port’ların Kapatılması

Web sunucusunda sık yapılan hata: “kurduk kaldı” diye gereksiz servisleri açık bırakmak. Örnek yaklaşım: • Sadece gereken portları açık tut (örn. 80/443; yönetim portları kontrollü) • Yönetim portlarını public bırakma (VPN/allowlist/jump host) • Kullanılmayan servisleri kapat/disable et • “Default açık gelen” bileşenleri gözden geçir

Linux/Windows web sunucusunda hangi port ve servisleri kapatmalıyım?

Kural basit: iş değeri üretmeyen ve zorunlu olmayan her servis adaydır. Public tarafta genellikle yalnız 80/443 kalmalı; yönetim erişimi (SSH/RDP) mümkünse public olmaz, allowlist/VPN/jump host üzerinden yürür. Ayrıca kullanılmayan admin panelleri, test servisleri ve default servisler kapatılmalıdır.

Fail2Ban / WAF Gibi Ek Katmanlar

Bu katmanları “sihirli kalkan” değil, gürültü azaltıcı olarak düşünün: • Fail2Ban: brute-force denemelerini otomatik bloke eder (özellikle SSH) • WAF: bilinen saldırı örüntülerini filtreler (SQLi, XSS, bot trafikleri) • Allowlist/Rate limit: özellikle yönetim uçlarını korur • CDN/edge güvenliği: L7 saldırıları ve bot trafiği kontrolünde yardımcı olur

“Uptime + CWV + Güvenlik” Birlikte Düşünülmeli

Sunucu güvenliği, performans ve süreklilik bir aradadır. Örneğin WAF/CDN doğru kurgulanırsa bot trafiği azalır, sunucu yükü düşer; bu da uptime ve dolaylı olarak kullanıcı deneyimine katkı verir. Bu noktada teknik SEO tarafındaki süreklilik beklentisiyle birlikte düşünmek gerekir (Internal Link Targets: /tr/seo/teknik-seo).

Güvenlik; sadece “saldırıyı engelleme” değildir. Olay olduğunda toparlanma hızınız (RTO/RPO) ve görünürlüğünüz (log/alert) en az firewall kadar kritiktir. Otel ve B2B sitelerinde tipik risk: “yedek var sanıyoruz ama geri dönmüyor” senaryosudur.

Yedekleme Senaryoları ve Testler

Yedekleme stratejisini 3 soruyla netleştirin: • Neyi yedekliyorum? (dosyalar, DB, config, sertifikalar) • Ne sıklıkla? (RPO hedefi) • Ne kadar sürede geri döner? (RTO hedefi) En kritik kural: Yedek, test edilmediyse yedek değildir. Düzenli geri dönüş testleri, “felaket anında sürpriz” riskini keser.

İzleme, Alert ve Loglama (KVKK Bağlamı)

İzleme iki parçadır: • Servis sağlığı: CPU/RAM/Disk, web server health, response time, error oranları • Güvenlik sinyalleri: başarısız girişler, anormal trafik, WAF block’ları, beklenmeyen servis start/stop Loglama tarafında KVKK uyumu açısından; “gereksiz kişisel veri” toplamadan, güvenlik ve olay analizi için yeterli kayıt tutulmalıdır (Internal Link Targets: /tr/raporlama/kvkk-veri-guvenligi).

“Go-Live Öncesi Sunucu Güvenlik Kontrol Listesi”

Bu rehberin fark yaratan (competitor gap) noktası burada: Komut ezberi yerine, go-live’a girmeden önce herkesin anlayacağı iş uyumlu bir QA akışı. Aşağıdaki tabloyu (BÖLÜM 4.4’te) bir “release gate” gibi kullanın.

Bu checklist ile Linux/Windows fark etmeksizin web sunucusunu prensip bazlı bir güvenlik modeline oturtursunuz. Böylece BT ekibi “nereden başlayacağını” netleştirir, yönetim tarafı ise risk azaltma planını somut deliverable’larla görür. Ayrıca teknik SEO ve süreklilik (uptime) beklentileriyle uyumlu bir altyapı standardı oluşur.