nginx 1.31.5 kontrol API'si kimlik doğrulaması olmadan worker PID'lerini ve config değişimlerini açığa çıkarıyor

dev.to üzerinde yayımlanan pratik bir yazı, nginx'in açık kaynak sürümüne 1.31.5 versiyonunda eklediği kontrol API'sine karşı sade bir curl'un ne kadar yol alabildiğini ayrıntılarıyla belgeledi. Özellik kendi başına hiçbir kimlik doğrulaması içermiyor ve dinleyici düz bir TCP portuna bağlı olduğu için, container dışından gönderilen kimlik bilgisi taşımayan bir istek her iki worker'ın da canlı process ID'lerini döndürdü. Kimlik bilgisi yine de taşımayan ikinci bir istek ise çalışan yapılandırmayı tamamen değiştirdi.

Yazı özelliğin tarihini 2 Eylül 2026 olarak veriyor ve yazım sırasında mainline sürüm olan, bu yeteneği değiştirmeden sürdüren nginx 1.31.8 üzerinde test ediyor. Özellik bir config direktifi değil komut satırı bayrağıyla açılıyor ve resmi nginx Docker imajı bu desteği derlenmiş olarak içeriyor, yani özel bir derleme gerekmiyor.

Master sürecine açılan bir HTTP kapısı

API, geleneksel kill -HUP veya nginx -s reload rutinini HTTP çağrılarıyla değiştiriyor. Endpoint ağacını art arda GET istekleriyle yoklayan yazar küçük bir yüzey haritaladı: /1/control/config canlı yapılandırma dosyasını adı ve tam içeriğiyle JSON olarak döndürüyor, /1/control/processes worker süreçlerinin durumunu bildiriyor ve gövdesiz bir PATCH, nginx'in config dosyasını diskten yeniden okuyup yeniden yüklemesini sağlıyor.

En büyük cazibe hata raporlaması. Yazar yapılandırmayı bilerek bir yazım hatasıyla bozduktan sonra iki yolla da yeniden yükleme yaptı: sinyal yolu bir çıkış kodu ve yalnızca error log içinde var olan bir satır üretirken, API HTTP 422 ile yanıt verdi ve tam ayrıştırıcı hatasını yanıt gövdesindeki bir JSON dizisinin içinde verdi. Her iki yol da hatalı config'i reddedip eskisini hizmette tuttu; yazar bunu doğruladı. Fark şu: deploy betiği artık logları kazımak ya da çıkış kodunun her şeyi anlattığını ummak yerine yapılandırılmış bir yanıt alıyor.

Ne daha hızlı, ne canlı trafiğe daha zararlı

Benchmarklar, sinyali atlamakla en azından kazanılacak hız varsayımını da çürütüyor. Her yöntemle iki geçerli config arasında dönüşümlü olarak beşer yeniden yükleme yapıldığında (böylece her çalışma gerçek bir yeniden yükleme oldu), sinyal yolu 78–100 ms, API yolu ise 90–102 ms ölçüldü. Yazar bu rakamların docker exec yükünü de içerdiği uyarısını yapıyor; yani rakamlar iki yöntemi karşılaştırıyor, gerçek yeniden yükleme gecikmesini ölçmüyor — ve bu karşılaştırmada eski yol varsa bile hafifçe daha hızlıydı.

Eşzamanlılık altında hiçbir yöntem devam eden istekleri bozmadı. Üç saniye uyuyan bir backend'e yönlendirilen bir istek, bir saniye sonra yeniden yüklemeyle kesintiye uğradı (yöntem başına üç deneme) ve her deneme yaklaşık 3,004 s ile HTTP 200 döndürerek tamamlandı; yeniden yükleme olmayan 3,012 s'lik taban çizgisinden ayırt edilemezdi. Yazar, yeniden yüklemelerin isteklerle gerçekten çakıştığını — eski worker'lar exiting görünürken yeni PID'lerin belirdiğini — isteklerden önce veya sonra gerçekleşmediğini doğruladı. Zarif worker kapanışı, yeniden yükleme hangi kapıdan gelirse gelsin aynı şekilde uygulanıyor.

Açık bir port gerçekte neyi açığa çıkarıyor

Yazıya göre nginx'in kendi sürüm notları, socketi bir ağ portuna bağlamaya şiddetle karşı çıkıyor ve API'nin kendi başına kimlik doğrulaması taşımadığını belirtiyor. Yazar sadece uyarıyı değil, bu riskin tam biçimini görmek istedi. Resmi imaj dinleyici 0.0.0.0:9000 üzerinde ve port yayınlanmış şekilde çalıştırıldığında, host'tan gönderilen iki istek — Authorization başlığı yok, API anahtarı yok, sadece bir URL — canlı süreç durumunu okudu ve servis edilen içeriği anında değiştiren bir config değişimi gerçekleştirdi. Özellikte giriş yok, token yok, IP allowlist yok; porta ulaşabilen herkes worker durumunu inceleyebilir ve tam bir yapılandırma değişimini zorlayabilir.

Belgelenen risk azaltma yolu unix sockete bağlanıp dosya sistemi izinlerine yaslanmak ve yazar bunun tuttuğunu doğruladı: varsayılan socket root sahipliğiyle srw------- olarak açıldı ve ayrıcalıksız bir kullanıcıyla yapılan bağlantı denemesi, nginx bir şey görmeden bağlantı hatasıyla başarısız oldu. Buna karşılık bir ağ arayüzü üzerinden özellik hiçbir şeyi engellemiyor.

Dinleyiciyi açık bırakmanın sürekli bir maliyeti de var. Socket açık ve boştayken master sürecinin yerleşik belleği, kapalıykenki 9.164 KB'a karşılık 9.468 KB ölçüldü — dinleyiciyi açık tutmak için kabaca 304 KB, yani yüzde 3,3. İzlemede görünmeyecek kadar küçük, ama bir operatörün bir kez açıp unutabileceği bir bayrak için gerçek ve sıfırdan farklı bir maliyet.

Neden önemli

Bu ders kitabı niteliğinde bir operasyonel tuzak: patlama yarıçapı tüm sunucu yapılandırması olan bir kolaylık API'si ve tek koruyan şey ağ erişilebilirliği. nginx dağıtımların çok büyük bir bölümünde trafiğin önünde duruyor ve bir reverse proxy üzerinde kimlik doğrulamasız bir config değişimi istekleri yeniden yönlendirebilir, upstream'leri yeniden işaretleyebilir veya config döküm endpoint'i üzerinden iç topolojiyi açığa çıkarabilir. Container kurulumları riski büyütüyor — özellik resmi imaja derlenmiş halde geliyor ve güvenli bir unix socket ile yayınlanmış bir TCP port arasındaki mesafe tek bir bayrak. Cesaret verici yarısı ise güvenli yapılandırmanın belgelenmiş, doğrulanmış ve ucuz olması: dosya sistemine bağlanın ve işi izinlere bırakın. API'nin kendisi ise elde tutmaya değer; çünkü deploy otomasyonu için log kazımak yerine ayrıştırılabilir bir 422 çok daha iyi. Çıkarılacak ders ikisini birden tutmak: özelliği koruyun, ama asla bir ağ arayüzüne yöneltmeyin.