Vekil Arkasında Gerçek İstemci IP'si
Günlüklerinizde tüm istekler aynı adresten geliyor gibi görünüyor. Hız sınırlaması çalışmıyor çünkü herkes tek bir kaynak sayılıyor. Coğrafi analiz anlamsız. Sunucunuzun önüne bir vekil koyduğunuz andan itibaren, istemci adresi artık doğrudan görünmez.
Bu yazı, gerçek ziyaretçi adresini doğru okumayı ele alıyor.
Adres Neden Kayboluyor
- İstemci vekile bağlanır.
- Vekil sunucuya yeni bağlantı açar.
- Sunucu vekilin adresini görür.
Üçüncü adım kaçınılmazdır: uygulama sunucusu bağlantıyı kimin açtığını görür ve bu, vekilin kendisidir — gerçek ziyaretçinin adresi ancak vekil onu bir başlıkta ilettiyse bilinebilir.
Bu yapı yük dengeleyici, içerik ağı ve ters vekil kullanımında geçerlidir.
Konteyner ağlarında da aynı durum yaşanır.
Çözüm, başlıkları doğru yapılandırmaktan geçer.
İletilen Başlıklar
| Başlık | İçerik |
|---|---|
| İletilen adres listesi | Zincirdeki tüm adresler |
| Gerçek istemci başlığı | Tek adres |
| Standart iletim başlığı | Protokol ve ana bilgisayar da dahil |
Birinci satırın bir listesi olması önemlidir: iletilen adres başlığı virgülle ayrılmış birden fazla adres içerebilir çünkü zincirdeki her vekil kendi gördüğü adresi sona ekler — hangi adresin gerçek istemci olduğunu bilmek yapılandırma gerektirir.
Listenin başındaki adres istemci gibi görünür.
Ama bu adres istemci tarafından uydurulmuş olabilir.
Bir sonraki bölüm bu riski açıklıyor.
Başlıklara Körü Körüne Güvenmek
- Başlıklar istemci tarafından gönderilebilir.
- Vekil bunları eklemeyebilir, üzerine yazmalıdır.
- Doğrulanmadan kullanılmamalıdır.
Birinci madde ciddi bir güvenlik açığıdır: bir saldırgan isteğine sahte bir iletilen adres başlığı ekleyebilir — uygulamanız bunu doğrulamadan kullanıyorsa hız sınırlaması, engelleme listesi ve denetim kayıtları tamamen atlatılabilir.
Bu, en sık istismar edilen yanlış yapılandırmalardan biridir.
Vekil, gelen başlığı silip kendi değerini yazmalıdır.
Uygulama ise yalnızca güvenilen vekilden gelen değeri kabul etmelidir.
Güvenilen Vekil Listesi
- Vekilin adresi tanımlanır.
- Yalnızca ondan gelen başlık kabul edilir.
- Başka kaynaktan gelen yok sayılır.
İkinci madde doğru modeli kurar: bağlantıyı açan adres güvenilen vekiller listesinde değilse iletilen adres başlığı tamamen yok sayılmalıdır — bu tek kural, sahte başlık saldırılarını etkisiz kılar.
Liste, vekil ağının adreslerini içermelidir.
İçerik ağı kullanıyorsanız sağlayıcı bu aralıkları yayımlar.
Bu aralıklar zaman zaman güncellenir.
Zincirde Kaç Vekil Var
| Yapı | Alınacak adres |
|---|---|
| Tek vekil | Listedeki tek adres |
| İçerik ağı ve yük dengeleyici | Sondan ikinci |
| Bilinmeyen sayıda | Güvenilir değil |
Üçüncü satır önemli bir uyarıdır: zincirdeki vekil sayısını bilmiyorsanız hangi adresin gerçek istemci olduğunu da bilemezsiniz — yapılandırma, mimarinizdeki kesin vekil sayısına göre yapılmalıdır.
Mimari değiştiğinde bu ayar da güncellenmelidir.
İçerik ağı eklemek, zinciri bir uzatır.
Bu değişiklik atlanırsa adresler yanlış okunur.
Yanlış Adresin Sonuçları
- Hız sınırlaması çalışmaz.
- Engelleme listesi işlevsizdir.
- Denetim kayıtları değersizdir.
- Coğrafi analiz yanlıştır.
İkinci madde en tehlikelisidir: saldırgan bir adresi engellediğinizi sanarken aslında kendi vekilinizin adresini engelliyor olabilirsiniz — bu, tüm trafiği kesme riskini de beraberinde getirir.
Böyle bir engelleme siteyi tamamen kapatabilir.
Birinci madde ise koruma mekanizmasını sessizce devre dışı bırakır.
Sınır çalışıyor görünür ama kimseyi durdurmaz.
Her Katmanda Ayrı Ayar
- Web sunucusu yapılandırılır.
- Uygulama çerçevesi yapılandırılır.
- Günlük biçimi güncellenir.
Üçüncü madde sıkça unutulur: uygulama gerçek adresi doğru okusa bile web sunucusunun erişim günlüğü hâlâ vekil adresini yazıyor olabilir — günlük biçimi ayrıca güncellenmelidir.
Bu, sonradan yapılan analizleri bozar.
İkinci madde ise çerçeveye özgü bir ayardır.
Çoğu çerçeve güvenilen vekil listesi tanımlamayı destekler.
Doğrulama
- Adresi ekrana yazan test sayfası kurun.
- Dışarıdan erişin.
- Sahte başlıkla deneyin.
Üçüncü madde güvenliği kanıtlar: isteğinize elle sahte bir iletilen adres başlığı ekleyip gönderdiğinizde uygulamanız o sahte değeri gösteriyorsa, yapılandırmanız güvensizdir ve saldırgan da aynısını yapabilir.
Doğru yapılandırmada sahte değer yok sayılır.
Bu test dakikalar sürer.
Her mimari değişikliğinden sonra tekrarlanmalıdır.
Vekil ve uygulama katmanlarını birlikte yapılandırabilmek tam sunucu erişimi gerektirir; sanal sunucu altyapı çözümleri ile tüm katmanları kendiniz denetleyebilirsiniz.
Sonuç
Vekil arkasında istemci adresi kaybolur; başlıklardan okunur ama körü körüne güvenilemez. Bir saldırgan isteğine sahte bir iletilen adres başlığı ekleyebilir ve hız sınırlaması, engelleme ile denetim kayıtları atlatılabilir. Doğru model tek kuralla kurulur: bağlantıyı açan adres güvenilen vekiller listesinde değilse başlık tamamen yok sayılmalıdır. Günlük biçimini güncellemeyi de unutmayın.
Sıkça Sorulan Sorular (SSS)
Tüm istekler neden aynı adresten görünüyor?
Sunucunuz bağlantıyı kimin açtığını görür ve bu, önündeki vekildir. Gerçek ziyaretçinin adresi ancak vekil onu bir başlıkta ilettiyse bilinebilir. Yük dengeleyici, içerik ağı ve konteyner ağlarında aynı durum yaşanır.
Başlığa doğrudan güvenebilir miyim?
Hayır. Bir saldırgan isteğine sahte bir iletilen adres başlığı ekleyebilir; doğrulamadan kullanırsanız hız sınırlaması, engelleme listesi ve denetim kayıtları atlatılabilir. Yalnızca güvenilen vekilden gelen değeri kabul edin.
Listedeki hangi adres gerçek istemci?
Mimarinizdeki vekil sayısına bağlı. Tek vekilde listedeki tek adres, içerik ağı ve yük dengeleyici birlikteyse genellikle sondan ikinci adres. Vekil sayısını bilmiyorsanız hangi adresin gerçek olduğunu da bilemezsiniz.
Uygulamam doğru okuyor ama günlükler yanlış?
Web sunucusunun erişim günlüğü biçimi ayrıca güncellenmelidir; uygulama gerçek adresi doğru okusa bile günlük hâlâ vekil adresini yazıyor olabilir. Bu, sonradan yapılan tüm analizleri bozar.
