Config kontrollerini geçen ve üretimi sessizce bozan dört nginx yanlış yapılandırması

OCSP stapling asla staple etmiyor

ssl_stapling açmak, nginx sertifika otoritesinin OCSP responder'ını çözümleyebilmedikçe hiçbir işe yaramıyor. Yazıda açıklandığı üzere, nginx çalışma zamanı sorgularında sistem çözümleyicisini kullanmıyor; bu sorguları yalnızca kapsamda bir resolver yönergesi varsa gerçekleştiriyor. Resolver yapılandırılmadığında iptal durumu sorgusu hiç gerçekleşmiyor ve stapling basitçe olmuyor; istemciler kendi OCSP sorgularını kendileri yürütmek zorunda kalıyor — oysa stapling'in amacı bu işi onlardı almak idi.

Çözüm, yerel veya bulut içi DNS'e işaret eden bir resolver yönergesi; yazar, 8.8.8.8 gibi herkese açık bir resolver'ın her iç sorguyu şifresiz olarak ağınızın dışına gönderdiği konusunda uyarıyor. openssl s_client ve -status bayrağıyla başarılı bir OCSP yanıtı olup olmadığını doğrulayabilirsiniz — ve kontrolü iki kez yapın, çünkü reload sonrası ilk el sıkışma çoğu zaman staple edilmemiş giderken arka planda sorgu sürmektedir. Modern bir detay: yazıya göre Let's Encrypt Ağustos 2025'te OCSP sunmayı bıraktı, bu yüzden sertifikaları için doğru hamle resolver eklemek değil, ssl_stapling'i tamamen kaldırmaktır.

Herkesi içeri alan erişim kuralları

ngx_http_access_module kuralları sırayla değerlendirir ve ilk eşleşmede durur — hiçbir kural eşleşmezse erişim izni verir. Sonda deny all; bulunmayan bir allow listesi bu nedenle hiçbir kurala eşleşmeyen her adrese hizmet verir, oysa niyet bir insana gayet açık görünür.

Daha sinsi tuzak kalıtımdır. Erişim kuralları dış bağlamdan yalnızca iç bağlam kendi kuralını tanımlamadığında aktarılır; dolayısıyla bir location içindeki tek bir allow, sunucu düzeyindeki tüm kural setini — deny all dahil — çöpe atar. Yazının örneği, /metrics/ location'ına tek bir allow ekleyerek istemeden endpoint'i herkese açık hale getiriyor — erişimi sıkılaştırmak işleri gevşetti.

Erişim kontrollerinden önce çalışan return

Dosyadaki konum yürütme sırasını belirlemez. Farklı modüllerin yönergeleri farklı istek fazlarında çalışır: return rewrite fazına, allow ve deny ise access fazına aittir. Bir location içindeki return 200, istekte erişim kurallarına hiç danışılmadan sona erdirir; dolayısıyla bir health endpoint'ini koruyan eksiksiz ve doğru allow listesi fiilen ölü koddur.

Çare, hazır yanıtı bir iç yönlendirme üzerinden ulaştırmak — return içeren adlandırılmış bir location'a try_files ile — çünkü try_files, erişim değerlendirmesinden sonraki content fazında çalışır. Yazar bunu open_file_cache ayarlarıyla eşleştiriyor; böylece yönlendirme her istekte her aday için bir dosya sistemi sorgusu ödemez ve bir bulguyu düzeltirken başka bir tuzak yaratma tuzağından kaçınılır.

Her reload'da düşen QUIC bağlantıları

Son durum, tek başına zararsız üç ayarı birleştiriyor: quic_bpf on, bir QUIC listener üzerinde reuseport ve birden fazla worker. quic_bpf'in eklediği eBPF programı paketleri QUIC bağlantı kimliğine göre doğru worker'a yönlendirir; ama reload'da BPF socket map, kapanmakta olan worker'lara ait girdileri korur. Sonuç, yazarın ifadesiyle, canlı QUIC bağlantılarının kabaca yarısı loglarda ya da sayaçlarda hiçbir şey görünmeden düşüyor — istemciler zaman aşımına uğruyor ve TCP üzerindeki HTTP/2'ye geri kayıyor. Yazı bunu mainline'da hâlâ açık olan bilinen bir upstream sorunu (nginx/nginx#425) olarak tanımlıyor ve neredeyse her dağıtımın kabul etmesi gereken ödün olarak quic_bpf off öneriyor. Yenilenen 90 günlük sertifikaları almak için reload yapan herkes bu hataya birkaç ayda bir yakalanıyor.

Bunları taramak

gixy-ng pip ile kurulur. Yazar, o anda düzenlediğiniz dosyayı değil nginx -T çıktısını taramanızı önerir; çünkü bu döküm her include'ı çözümler ve yalnızca parçalar birleştiğinde ortaya çıkan sorunları açığa çıkarır. Faydalı bayraklar arasında orta ve üzeri önem derecesindeki bulgular için -l 2, CI pipeline'ları için -f ve sürüme özel CVE kontrollerini etkinleştiren --nginx-version yer alır — araç yalnızca config'e bakar ve binary'niz hakkında bilgisi yoktur, bu yüzden hangi sürümün çalıştığı söylenmedikçe CVE kontrolü sessiz kalır.

Neden önemli

nginx'in hızlı doğrulama döngüsü yazım hatalarını yakalar, semantiği değil. Bu dört örüntü, ölçekte tehlikeli kılan ortak bir özelliğe sahip: başlangıçta hata yok, log satırı yok, metrik yok — yalnızca güvenlik açığı (herkese açık admin yolları, atlanan iptal kontrolleri) ya da sessiz gerilemeler (rutin reload'lardan sonra sarkan HTTP/3 trafiği). Şimdilik, config odaklı statik analizi CI'a katmak, bunları üretim trafiğinden önce yakalamanın tek pratik yolu.