Web Sunucusu Yapılandırmasını Sertleştirme

Aktif olarak kullanmadığınız her etkin modül veya servis, saldırganlar için potansiyel bir giriş noktasıdır. Apache ve Nginx'in varsayılan kurulumları çoğu zaman WebDAV, durum sayfaları, otomatik dizin listeleme ve gerekli olmayabilecek sunucu taraflı betik motorları için modüller içerir. Tüm modülleri denetleyin ve temel olmayanları kaldırın.

• Etkin modüllerin listesini alın: apache2ctl -M (Apache) komutunu çalıştırın veya nginx.conf derlenmiş modüllerini inceleyin.
• Uygulamanız açıkça gerektirmiyorsa WebDAV modüllerini (mod_dav, mod_dav_fs) devre dışı bırakın.
• Sunucu durumu ve bilgi uç noktalarını (mod_status, mod_info) devre dışı bırakın ya da yalnızca localhost erişimine kısıtlayın.
• Gerekli değilse otomatik dizin listeleme modüllerini kaldırın (tam dizin listeleme sertleştirmesi için Adım 04'e bakın).
• Kullanılmayan betik dil işleyicilerini (ör. Perl, CGI) sunucu düzeyinde devre dışı bırakın.
• Web sunucusunun gerektirmediği OS düzeyindeki servisleri (FTP, Telnet, kullanılmayan veritabanları) durdurun ve devre dışı bırakın.
• Devre dışı bıraktıktan sonra sunucuyu yeniden başlatın ve işlevselliğin etkilenmediğini doğrulayın.

İçeriği şifrelenmemiş HTTP üzerinden sunmak, kullanıcıları dinleme ve ortadaki adam saldırılarına karşı savunmasız bırakır. HTTPS'yi zorunlu kılmak ve TLS'yi doğru yapılandırmak, yapabileceğiniz en yüksek etkili sertleştirme adımlarından biridir. Sensagraph, TLS yapılandırmanızı ve sertifika geçerliliğinizi otomatik olarak kontrol eder.

• Güvenilir bir CA'dan geçerli bir TLS sertifikası edinin (Let's Encrypt ücretsiz ve yaygın olarak desteklenir).
• Sunucu düzeyinde tüm HTTP trafiğinden HTTPS'ye kalıcı yönlendirme (HTTP 301) yapılandırın.
• TLS 1.0 ve TLS 1.1'i devre dışı bırakın — yalnızca TLS 1.2 ve TLS 1.3'ü destekleyin.
• Güçlü şifre takımları kullanın; Nginx için önerilen başlangıç noktası: ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
• Şifre tercihini uygulamak için ssl_prefer_server_ciphers on; (Nginx) veya SSLHonorCipherOrder On (Apache) ayarını yapın.
• Sertifika doğrulamasını hızlandırmak için OCSP Zımbalama'yı etkinleştirin: ssl_stapling on; ssl_stapling_verify on; (Nginx).
• Güvenli bir Diffie-Hellman parametresi belirleyin: openssl dhparam -out /etc/ssl/dhparam.pem 4096 ile oluşturun ve yapılandırmanızda referans verin.
• Her değişiklikten sonra bağımsız bir tarayıcı kullanarak TLS yapılandırmanızı doğrulayın.

HTTP güvenlik başlıkları, tarayıcılara içeriğinizi nasıl işlemesi gerektiğini bildirir; kullanıcıları tıklama hırsızlığı, siteler arası betik çalıştırma, MIME koklama ve diğer saldırılardan korur. Eksik veya yanlış yapılandırılmış başlıklar, web güvenlik değerlendirmelerinde en sık karşılaşılan bulgular arasındadır. Sensagraph bu başlıkların varlığını ve doğruluğunu otomatik olarak kontrol eder.

• Strict-Transport-Security (HSTS): En az bir yıl boyunca HTTPS'yi zorunlu kılmak için Strict-Transport-Security: max-age=31536000; includeSubDomains; preload ekleyin.
• Content-Security-Policy (CSP): Betik, stil ve kaynak kaynaklarını kısıtlayan bir politika tanımlayın. Kısıtlayıcı başlayın ve yalnızca gerektiğinde genişletin; örneğin default-src 'self';.
• X-Frame-Options: Tıklama hırsızlığını önlemek için DENY veya SAMEORIGIN olarak ayarlayın.
• X-Content-Type-Options: MIME türü koklamayı önlemek için nosniff olarak ayarlayın.
• Referrer-Policy: Referans bilgisi sızdırmayı sınırlamak için strict-origin-when-cross-origin veya daha kısıtlayıcı bir değere ayarlayın.
• Permissions-Policy: Uygulamanızın kullanmadığı tarayıcı özelliklerine (kamera, mikrofon, coğrafi konum) erişimi kısıtlayın.
• X-Powered-By başlığını tamamen kaldırın (teknoloji yığınını açığa çıkarır).
• Dağıtımdan sonra tüm başlıkları tarayıcınızın geliştirici araçları veya otomatik bir tarama ile test edin.

Dizin listeleme, herkesin sunucunuzun dosya yapısına göz atmasına izin verir; bu durum kaynak kod, yedek dosyalar ve yapılandırma dosyalarını açığa çıkarabilir. Web kök dizinine yanlışlıkla yerleştirilen hassas dosyalar bu riski büyük ölçüde artırır.

• Apache'de dizin listelemeyi global olarak devre dışı bırakın: ana yapılandırmanızda veya .htaccess dosyanızda Options -Indexes ayarlayın.
• Nginx'te autoindex'i devre dışı bırakın: autoindex off; ayarlandığından emin olun (varsayılan değer budur, ancak açıkça onaylayın).
• Gizli dosya ve dizinlere (noktalı dosyalar) doğrudan erişimi engelleyin: Nginx'te location ~ /\. { deny all; } ekleyin; Apache'de RedirectMatch 404 /\..*$ kullanın.
• Yaygın hassas dosya uzantılarına erişimi engelleyin: .env, .bak, .sql, .log, .conf, .git dizinleri.
• Mümkünse tüm yapılandırma ve gizli dosyaları web kök dizininin dışına taşıyın.
• /.git/, /.env, /wp-config.php.bak ve benzeri yolların 403 veya 404 döndürdüğünü doğrulayın — asla 200 olmamalıdır.
• Web kök dizinini kamuya açık olmaması gereken dosyalar açısından düzenli olarak denetleyin.

Web sunucuları varsayılan olarak yazılım adı ve sürümünü yanıt başlıklarında ve hata sayfalarında yayımlar. Saldırganlar bu bilgileri güvenlik açığı bulunan sunucu sürümlerini hızla tespit etmek ve bilinen CVE'leri hedef almak için kullanır. Bu bilgileri gizleyerek keşif maliyetini artırın.

• Nginx: nginx.conf dosyasındaki http bloğunda server_tokens off; ayarlayın.
• Apache: httpd.conf veya apache2.conf dosyasında ServerTokens Prod ve ServerSignature Off ayarlayın.
• Daha fazla gizleme gerekiyorsa bir başlık işleme modülü kullanarak Server yanıt başlığını kaldırın veya yeniden yazın.
• X-Powered-By başlığını kaldırın (PHP, Express ve diğerleri bunu varsayılan olarak ekler); PHP'de php.ini dosyasında expose_php = Off ayarlayın.
• Varsayılan hata sayfalarını (404, 403, 500) yığın izleri, yazılım sürümleri veya dosya yolları göstermeyecek şekilde özelleştirin.
• Tarayıcınızda veya otomatik tarama ile yanıt başlıklarını inceleyerek gizlemenin başarılı olduğunu onaylayın — Sensagraph açıkta kalan sunucu banner'larını kontrol eder.

Web sunucuları çoğu zaman çoğu uygulama tarafından gerektirilmeyen — TRACE, PUT, DELETE ve OPTIONS gibi — HTTP metodlarını kabul eder. Bu metodların etkin bırakılması saldırganlara, TRACE aracılığıyla siteler arası izleme (XST) saldırıları dahil ek vektörler sağlar.

• Uygulamanızın gerçekten kullandığı HTTP metodlarını belirleyin (genellikle GET, POST ve muhtemelen CORS ön uçuşu için OPTIONS).
• Nginx: Metodları şu blokla kısıtlayın: if ($request_method !~ ^(GET|POST|HEAD)$) { return 405; }
• Apache: Yalnızca açıkça gerekli metodlara izin vermek için <LimitExcept> yönergesini kullanın.
• TRACE metodunu her zaman devre dışı bırakın — nadiren ihtiyaç duyulur ve siteler arası izleme saldırılarına olanak tanır.
• İzin verilmeyen metodların 200 OK yerine 405 Method Not Allowed veya 403 Forbidden döndürdüğünü test edin.

Hız sınırlaması olmadan sunucunuz kaba kuvvet oturum açma denemeleri, kimlik bilgisi doldurma ve hacimsel hizmet reddi saldırılarına karşı savunmasızdır. İstek hızlarını ve yük boyutlarını kontrol etmek maruziyetinizi önemli ölçüde azaltır.

• Nginx hız sınırlaması: IP başına istekleri sınırlamak için limit_req_zone ve limit_req yönergelerini kullanın; örneğin saniyede 10 istek ve bir burst payı belirleyin.
• Apache: Bağlantı hızlarını sınırlamak ve kötüye kullanım yapan IP'leri engellemek için mod_ratelimit veya mod_evasive kullanın.
• Uygulamanıza uygun maksimum istek gövde boyutu belirleyin: client_max_body_size 10m; (Nginx) veya LimitRequestBody 10485760 (Apache).
• Yavaş istemciler için zaman aşımı ayarlayın: client_body_timeout, client_header_timeout ve keepalive_timeout (Nginx) veya Apache eşdeğerlerini yapılandırın.
• Kimlik doğrulama uç noktalarına (/login, /api/auth) ve şifre sıfırlama akışlarına özellikle daha sıkı hız sınırlamaları uygulayın.
• Daha derin istek incelemesi için sunucunuzun önüne bir Web Uygulama Güvenlik Duvarı (WAF) entegrasyonu düşünün.
• Aktif saldırıları tespit etmek için tekrarlayan 429 (Too Many Requests) veya 403 yanıtlarını kaydedin ve uyarı oluşturun.

Aşırı izin verilen dosya ve dizin izinleri, saldırganların — veya paylaşılan bir sistemdeki diğer kullanıcıların — yapılandırma dosyalarını okumasına, uygulama kodunu değiştirmesine ya da kötü amaçlı dosyalar yazmasına olanak tanır. En az ayrıcalık ilkesini titizlikle uygulayın.

• Web sunucusu sürecini özel, ayrıcalıksız bir kullanıcı olarak çalıştırın (Debian/Ubuntu'da www-data, RHEL/CentOS'ta nginx) — asla root olarak çalıştırmayın.
• Web kök dizin izinlerini 755 olarak ayarlayın (sahip okuma/yazma/çalıştırma, grup ve diğerleri okuma/çalıştırma).
• Statik dosya izinlerini 644 olarak ayarlayın (sahip okuma/yazma, grup ve diğerleri yalnızca okuma).
• Yapılandırma dosyası izinlerini 640 veya 600 olarak ayarlayın, böylece yalnızca sahip (ve isteğe bağlı olarak web sunucu grubu) bunları okuyabilir.
• .env ve gizli dosyaların 600 izinli ve yalnızca uygulama kullanıcısına ait olduğundan emin olun.
• Belirlenen yükleme klasörleri dışındaki tüm dizinlerde web sunucusu sürecine yazma erişimini reddedin.
• Yükleme dizinlerini betik çalıştırmadan kısıtlayın: yükleme yolları için php_admin_value engine Off veya eşdeğerini yapılandırın.
• İzinleri özyinelemeli olarak denetleyin: dünya tarafından yazılabilir dosyaları tespit etmek için find /var/www -type f -perm /o+w komutunu çalıştırın.

Sertleştirme tek seferlik bir görev değildir. Web sunucusu yazılımı, TLS kütüphaneleri ve sunucu taraflı çerçevelerdeki yeni güvenlik açıkları düzenli olarak keşfedilmektedir. Sağlam bir güncelleme ve izleme süreci, sertleştirmenizin zamanla etkin kalmasını sağlar. Sensagraph, web sunucusu yapılandırmanızı sürekli tarar ve yeni sorunlar tespit ettiğinde sizi uyarır.

• Web sunucusu yazılımınız (Apache, Nginx) ve işletim sistemi dağıtımınız için güvenlik duyurularına abone olun.
• Kritik güvenlik açıkları için yamaları yayımlanmadan sonra 72 saat içinde, daha düşük ciddiyettekiler için ise 30 gün içinde uygulayın.
• İşletim sistemi düzeyindeki yamalar için işletim sistemi paket yöneticisinin otomatik güvenlik güncellemesi özelliğini kullanın (Debian/Ubuntu'da unattended-upgrades, RHEL/CentOS'ta dnf-automatic).
• TLS kütüphanelerini (OpenSSL, LibreSSL) güncel tutun — birçok kritik TLS güvenlik açığı temel kütüphanededir.
• Sunucu erişim ve hata günlüklerini etkinleştirin ve inceleyin; bunları merkezi bir log yönetim sistemine gönderin.
• Anormal desenler için uyarı kurun: yüksek 4xx/5xx oranları, hassas yollarda beklenmedik 200 yanıtları, trafik artışları.
• Yapılandırma kaymasını ve yeni açıkları tespit etmek için web sunucunuzun düzenli otomatik güvenlik taramalarını planlayın.
• Önemli bir yapılandırma değişikliği veya yazılım yükseltmesinden sonra tam sertleştirme kontrol listesini yeniden çalıştırın.