Soket eşi mi, iletilen başlık mı: hangi adrese güvenmeli?

Uygulamanıza gelen bir istek iki tür adres kanıtı taşır: ağ bağlantısını açan eş ve daha önceki bir istemcinin adresini iddia eden bir HTTP alanı. Farklı sorulara yanıt verirler. Soket eşi gözlemlenir, başlık ise onu yazan kişi tarafından iddia edilir ve hiçbiri bir günlükte ya da erişim kuralında diğerinin yerini sessizce almamalıdır. Aşağıdaki karşılaştırma ikisini ayrı tutar ve ardından başlığın kullanılabilir hale geldiği tek düzeni gösterir.

Herhangi bir şeyi karşılaştırmadan önce yolu tanımlayın:

Client -> approved reverse proxy -> application origin

Bu düzende kaynağın soket eşi genellikle proxy'dir ve bir iletme başlığı proxy'nin istemci hakkındaki iddiasını taşıyabilir. Değeri, o proxy ile kurulan denetimli ilişkiden gelir, başlığın adından değil.

İki tür adres kanıtı

Soket eşi tek bir TCP bağlantısıyla ilgili bir olgudur: bir şey o adresten bir el sıkışma tamamladı. Bu, önemsediğiniz kişi, cihaz veya hesap olmak zorunda değildir, çünkü bir VPN veya Tor çıkışı bir hizmetin gözlemlediği kaynak olarak meşru biçimde bulunabilir. Yine de ana bilgisayarın kendisinin doğruladığı tek adres olarak kalır ve tüm değeri budur.

Bir iletme alanı zincir hakkında üst veridir. X-Forwarded-For, X-Real-IP ve standartlaştırılmış Forwarded alanı, onları yankılayan bir uç noktaya ulaşan her istemci tarafından yazılabilir, bu nedenle güvenilirlikleri tamamen bunları ayarlamaya kimin izni olduğuna bağlıdır.

İkisini de istek bağlamında farklı adlar altında tutun. Eşin üzerine başlıkla yazan bir uygulama, daha sonra bir güven hatasını yeniden kurma yeteneğini kaybeder ve tam da buna ihtiyaç duyduğunuz an odur.

Bir başlık bağlantıyı asla yeniden yönlendirmez

Bir iletme alanına adres yazmak, sunucuya gelen TCP bağlantısının kaynağını değiştirmez ve yol boyunca hiçbir yerde yönlendirmeyi değiştirmez. Olağan VPN yönlendirmesi veya kaynak NAT trafiği hiçbir HTTP başlığı olmadan iletir. Aynı şekilde, bir geçiş ağ geçidi düzgün korunan bir HTTPS alışverişini TLS uç noktasının düzenini değiştirmeden yeniden yazmaz.

Ters hata da aynı ölçüde yaygındır: HTTPS, istemcinin sağladığı bir iletme başlığını doğru yapmaz. Yanlış bir iddianın taşınmasını, doğru olanınki kadar iyi korur.

Bir iş arkadaşı yönlendirme sorununu düzeltmek için başlık değişikliği öneriyorsa, teşhis zaten yanlış gitmiştir. Yolu düzeltin veya başlığı yazan proxy yapılandırmasını düzeltin.

İddia etmeye izinli proxy'yi adlandırın

İki kural bir iletme alanını kullanılabilir kılar ve ikisi de kod değil yapılandırmadır. Kenar, dışarıdan gelen her şeyi o alanlar için kendi belgelenmiş davranışına göre normalleştirir veya atar. Ardından kaynak, adını verdiğiniz proxy yolundan bir yedek adres alır, başka hiçbir yerden almaz. İkinci kural yalnızca istemciler kaynağa başka bir yoldan ulaşamadığı sürece geçerlidir, çünkü hem doğrudan hem proxy üzerinden gelen isteklere yanıt veren bir kaynak hangisine hizmet ettiğini bilmez.

NGINX'in gerçek IP modülü ayrımı açıkça gösterir. set_real_ip_from iddiası sayılan göndericileri adlandırır ve real_ip_header hangi alanın onu taşıdığını söyler; ilki güveni uygular, ikincisi yalnızca nereye bakılacağını söyler.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Yalnızca başlık seçme yönergesi, değeri kimin gönderdiği konusunda hâlâ hiçbir şey ortaya koymaz.

Taşıma güvenliği, güvendiğiniz bileşenler arasında tüm yolu kat etmelidir. Doğru normalleştiren bir kenar, alt taraftaki korumasız bir atlama bir başkasının iddiayı yolculuk sırasında düzenlemesine izin verdiği anda o değeri kaybeder.

Çok atlamalı zincirleri bilinçli olarak yönetin

Birkaç proxy açık bir zincir modeli gerektirir. Bir blog yazısı öyle yaptı diye virgülle ayrılmış en soldaki veya en sağdaki değeri almayın; proxy'lerinizden hangisinin eklediğini, hangisinin değiştirdiğini ve hangisinin gelen alanı koruduğunu öğrenin. Örneğin NGINX, listeyi güvendiği kümesine karşı geriye doğru yürüyebilir ve sahip olmadığı ilk adreste durabilir, ve bu o ürünün kuralıdır, her çerçevenin uyduğu bir yasa değildir. Kendi proxy'nizin belgelerini aynı iki soruyla okuyun: hangi değeri seçiyor ve hangi göndericilere inanıyor?

Zinciri yazın: atlama sırası, hangi atlamanın alanı belirlediği ve hangi atlamanın gelen kopyaları kaldırdığı. Sonra bu notu yalnızca kayıt defterinde değil, proxy yapılandırmasının yanında tutun. Ardından onaylanmış doğrulama süreci üzerinden sahte başlıklı bir istek göndererek ve kaynağın onu yok saydığını doğrulayarak test edin.

Bir atlama eklediğinizde o belgeyi yeniden gözden geçirin. Güvenilen proxy'nin önüne eklenen yeni bir yük dengeleyici, kimse uygulamayı düzenlemeden hangi adresin kazandığını değiştirebilir.

İki gözlemi de günlükte tutun

Teşhise izin verilen yerlerde, bağlantının eşini ve normalleştirilmiş istemci adresini iki ayrı alan olarak günlüğe kaydedin ve yalnızca amacın gerçekten ihtiyaç duyduğu iletme üst verilerini ekleyin. Ardından dağıtımı iki istekle kanıtlayın: her iki değeri de makul biçimde kaydetmesi gereken proxy üzerinden bir istek ve reddedilmesi gereken kaynağa doğrudan bir girişim.

Bu çiftin ne anlama geldiğini unutmayın. Başlık, güvenmeyi seçtiğiniz bir bileşenin sağladığı bağlamı ekler; eş, ana bilgisayarınızın gerçekten gördüğü tek adres olarak kalır. Hiçbiri bireysel kimliğin kanıtı değildir ve herhangi birini kanıt olarak ele alan bir tasarım birisi hakkında yanılacaktır.