Proxy Kimlik Doğrulaması Nedir? Basitçe Açıklanmış

Geonode adresinde proxy satıyoruz; dolayısıyla burada kendi ürünümüz hakkında bilgi veriyoruz. Bize hiçbir maliyeti olmayan ve çoğu kişiye yardımcı olan öneri: kaynak adresiniz sabitse, kullanıcı adı ve şifre yerine IP izin listesi kullanın. Bu, komutlarınızdan, komut dosyalarınızdan, ortam değişkenlerinizden ve yapıştırdığınız terminal çıktılarından kimlik bilgilerini tamamen ortadan kaldırır — ve gönderilecek bir şey yoksa sızacak bir şey de olmaz. Biz de dahil olmak üzere çoğu sağlayıcı bu özelliği sunar, ancak kurulum kılavuzunda ilk olarak kullanıcı adı ve şifre gösterildiği için bu özellik yeterince kullanılmamaktadır. Bu makalenin geri kalanında her iki yöntem de ele alınacak ve ayrıca SOCKS5 kimlik doğrulamasının neden genellikle gösterilenden daha fazla dikkat gerektirdiği açıklanacaktır.

Sağlayıcıların Sunduğu İki Yöntem

Kullanıcı adı ve şifre. Size kimlik bilgileri verilir ve her istekte bunları gönderirsiniz. Herhangi bir adresten çalışır; bu da adresiniz değiştiğinde — bir dizüstü bilgisayar, mobil bağlantı, dinamik adresli bir konteyner veya dağıtılmış bir işçi grubu — tek seçenek olmasını sağlar.

IP izin listesi. İsteklerinizin geleceği adresleri kaydedersiniz ve proxy, bu adreslerden gelen her şeyi kimlik bilgileri olmadan kabul eder. Yalnızca bu adreslerden çalışır; işte bu özelliği, bu yöntemi güvenli kılan unsurdur.

Çoğu ticari sağlayıcı her ikisini de destekler ve birçoğu her ikisinin aynı anda kullanılmasına izin verir. Avantaj ve dezavantajlar açıktır:

Statik adresli bir sunucuda çalışan bir veri toplayıcı için izin listesi kesinlikle daha iyidir. Mobil veya geçici herhangi bir şey için kimlik bilgileri tek uygulanabilir seçenektir. CI çalıştırıcıları için ise bu, platformunuzun size öngörülebilir bir çıkış adresi sağlayıp sağlamadığına tamamen bağlıdır ve çoğu platform bunu sağlamaz.

HTTP Proxy Kimlik Doğrulaması Nasıl Çalışır?

Bu mekanizma, RFC 9110 belgesinde tanımlanan bir “meydan okuma ve yanıt” sürecidir.

Bir istek gönderirsiniz. Proxy kimlik doğrulaması gerektiriyorsa ve siz bunu sağlamadıysanız, proxy 407 Proxy Authentication Required

yanıtını verir ve buna bir sorgu ekler. Spesifikasyon bu konuda nettir: "Bir proxy, oluşturduğu her 407 (Proxy Authentication Required) yanıtında en az bir Proxy-Authenticate başlık alanı göndermelidir."

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="proxy.example.com"

Proxy-Authorization

başlığında kimlik bilgilerini ekleyerek isteği yeniden gönderirsiniz; RFC, bunu "istemcinin, kimlik doğrulama gerektiren bir proxy'ye kendisini (veya kullanıcısını) tanıtmasına" olanak tanıyan bir özellik olarak tanımlar.

Proxy-Authorization: Basic dXNlcjpwYXNz

Bu yöntemi sıradan web kimlik doğrulamasından ayıran iki özellik vardır ve her ikisi de doğrudan spesifikasyondan kaynaklanmaktadır.

Meydan okuma, atlama (hop) özeldir. "WWW-Authenticate'ten farklı olarak, Proxy-Authenticate başlık alanı yalnızca yanıt zincirindeki bir sonraki giden istemciye uygulanır. Bunun nedeni, belirli bir proxy'yi seçen istemcinin kimlik doğrulama için gerekli kimlik bilgilerine sahip olma olasılığının daha yüksek olmasıdır."

Kimlik bilgileri iletilmez, tüketilir. "Bir zincirde birden fazla proxy kullanıldığında, Proxy-Authorization başlık alanı, kimlik bilgilerini almayı bekleyen ilk gelen proxy tarafından kullanılır." Proxy'ler bu şekilde işbirliği yaparsa, bir proxy bunları ileriye iletebilir, ancak varsayılan olarak kimlik bilgileriniz bunları isteyen ilk hopta durur.

RFC ayrıca, tek bir kuruluş içindeki zincirler için bir sonucu da belirtir: aynı yönetim etki alanındaki birkaç proxy aynı sorguyu gönderdiğinde, "her proxy aynı sorgu setini göndereceği için, Proxy-Authenticate başlığı iletiliyormuş gibi görünecektir."

407 ve 401: Önemli Olan Fark

Bu makalede, hata ayıklama yapan herkes için en yararlı olan şey.

Farklı kodlar, farklı başlıklar, farklı kimlik bilgileri, farklı çözümler.

407 kodu, hedefe asla ulaşamadığınız anlamına gelir. Proxy sizi durdurdu. Hedef kimlik bilgilerinizin bir önemi yoktur ve bunları ne kadar değiştirirseniz değiştirin bir faydası olmaz.

401 hatası, proxy'nin çalıştığı ve hedefin kimlik bilgilerini istediği anlamına gelir.

İki bağımsız kimlik bilgisi kümesi söz konusu olabileceğinden, bu hatalar tek bir kurulumda bir arada görünebilir. curl'da:

curl -x http://proxy.example.com:9000 \
     --proxy-user proxyuser:proxypass \
     -u apiuser:apipass \
     https://api.example.com/private

--proxy-user proxy için, -u hedef için. Bunları karıştırmak, tam da bu bölümün önlemek için var olduğu kafa karışıklığına yol açar.

Tahminde bulunmadan hangi aşamada reddedildiğinizi görmek için:

curl -sS -o /dev/null -x "$PROXY" \
  -w 'connect=%{http_connect} status=%{response_code}\n' \
  https://example.com

connect=407 , proxy'nin sizi reddettiği ve hedefe hiç ulaşamadığınız anlamına gelir. connect=200 status=401 , proxy'nin çalıştığı ve hedefin kimlik bilgilerini istediği anlamına gelir. İki farklı sorun, iki farklı çözüm, bunları ayırt etmek için tek bir komut.

SOCKS5 Kimlik Doğrulaması Farklı ve Daha Zayıftır

Bu fark, gerçek bir güvenlik sorunu oluşturduğu ve nadiren dile getirildiği için bilinmesi önemlidir.

SOCKS5, HTTP başlıklarını kullanmaz. Kimlik doğrulama, bağlantı kurulumu sırasında RFC 1929 tarafından tanımlanan bir alt müzakere sürecinde gerçekleşir. İstemci, sürüm baytı, kullanıcı adı uzunluğu, kullanıcı adı, şifre uzunluğu ve şifreyi içeren küçük bir ikili yapı gönderir; sunucu ise, X'00' değerinin başarıyı gösterdiği bir durum baytı ile yanıt verir. Sunucu bir hata durumu döndürürse, "bağlantıyı kapatmak ZORUNDADIR".

Söz konusu RFC’deki güvenlik notu kısadır ve dikkatle okunmalıdır:

İstek, şifreyi düz metin olarak taşıdığından, bu alt müzakere, “sniffing”in mümkün ve pratik olduğu ortamlar için önerilmez.

Düz metin, base64 değil, karma değil. HTTP Temel kimlik doğrulama en azından base64 ile kodlanmıştır — kolayca geri dönüştürülebilir, ancak paket yakalamada kelimenin tam anlamıyla okunamaz. SOCKS5 kullanıcı adı/şifre kimlik doğrulaması, şifreyi baytlar halinde ağ üzerinden iletir.

Pratik sonuçlar:

Güvenilmeyen bir ağda, TLS üzerinden bir HTTP proxy'sini veya bir izin listesini tercih edin. Kimlik bilgileri, HTTP Basic'e kıyaslSOCKS5'te daha fazla açığa çıkar ve bu fark, paylaşılan veya düşmanca ağlarda önemlidir.

SOCKS kimlik bilgilerini, HTTP kimlik bilgilerine göre daha sık değiştirin, çünkü bu bilgilerin açığa çıkma riski daha yüksektir.

Bunun yalnızca proxy'ye yapılan kimlik doğrulamayı ilgilendirdiğini unutmayın. Bir HTTPS sitesine yönelen trafiğiniz hâlâ TLS ile korunmaktadır. Korunmasız olarak iletilen, kimlik bilgilerinin kendisidir.

Kullanıcı Adındaki Parametreler: Bir Sağlayıcı Geleneği

Yeni başlayanları kafasını karıştıran ve hiçbir standardın parçası olmayan bir kalıp.

Birçok sağlayıcı, yapılandırmayı kullanıcı adı dizesi içine kodlar:

username-country-de-session-abc123:password

Bu, bir HTTP özelliği değildir. Proxy ağ geçidi kendi kullanıcı adı alanını çözümler ve fazladan bölümleri talimatlar olarak değerlendirir — bir ülke, bir oturum tanımlayıcısı, bir rotasyon ayarı. Sözdizimi, sağlayıcılar arasında tamamen farklılık gösterir.

Bundan iki sonuç çıkar.

Tahminde bulunmak yerine sağlayıcınızın belgelerini okuyun. Biçimi yanlış bir parametre genellikle hata vermez. Yanlış davranış gösteren, ancak çalışan bir istek üretir — kalıcı olmayan bir oturum ya da istemediğiniz bir ülkede bağlantı kesilmesi gibi. Bu, sessiz bir hatadır ve en uzun süre fark edilmeden kalabilen türden bir hatadır.

Bazı sağlayıcılar bunun yerine bağlantı noktalarını kullanır; bağlantı noktası aralıklarını kullanıcı adına kodlamak yerine ülkelere veya oturumlara eşler. Hiçbir yaklaşım diğerinden daha iyi değildir; sadece hangisini satın aldığınızı bilmeniz gerekir.

Kimlik Bilgilerinin Sızdığı Yerler

Dört yer; hepsi yaygın, hepsi önlenebilir.

Komut satırları. Bilgisayardaki diğer kullanıcılar tarafından işlem listesinde görülebilir ve kabuk geçmişinde süresiz olarak saklanır. curl'un kılavuzunda bu konuda net bir ifade yer alır: hassas veriler "bunun yerine bir dosyadan veya benzeri bir yerden alınmalı ve asla komut satırında açık metin olarak kullanılmamalıdır."

Ortam değişkenleri. http_proxy=http://user:pass@host:9000 standart yapılandırma biçimidir ve bu komut, şifreyi her alt işlemin ortamına, Linux'ta /proc dosyasına ve herhangi bir ortam dökümüne yerleştirir.

Ayrıntılı çıktı. curl -v komutu, Proxy-Authorization başlığını içerir ve terminal ekran görüntüleri hiç kimsenin istemediği yerlere ulaşabilir. Paylaşmadan önce gizleyin.

Kaynak kontrolü. Bir komut dosyasına sabit olarak kodlanmış ve commit edilmiş kimlik bilgileri, kaldırıldıktan sonra da depo geçmişinde kalır.

Etkinlik sırasına göre risk azaltma önlemleri: IP izin listesi kullanın ve hiçbir kimlik bilgisi saklamayın; kimlik bilgilerini ~/.netrc gibi izin kısıtlamalı bir dosyaya chmod 600 ile kaydedin; çalışma zamanında bir gizli bilgi yöneticisinden okuyun; ve en azından read -rs komutuyla bunları kabuk geçmişinden uzak tutun.

Gerçek bir kafa karışıklığına neden olan bir kodlama detayı: Şifreniz @, : veya / içeriyorsa, bir proxy URL’sine girmeden önce yüzde kodlaması yapılmalıdır; aksi takdirde ayrıştırıcı yanlış yerde bölünür ve doğru kimlik bilgilerine sahip olmanıza rağmen 407 hatası alırsınız.

Yaygın Araçlarda Yapılandırma

curl:

curl -x http://proxy.example.com:9000 --proxy-user user:pass https://example.com

wget — --proxy

bayrağı bulunmadığından, proxy ayarları ortam değişkenlerinden veya .wgetrc

adresinden alınır:

wget --proxy-user=user --proxy-password=pass https://example.com

Daha iyisi, ~/.wgetrc

adresinde chmod 600

ile:

http_proxy = http://proxy.example.com:9000/
proxy_user = user
proxy_password = pass

Python requests:

proxies = {"http": "http://user:pass@proxy.example.com:9000",
           "https": "http://user:pass@proxy.example.com:9000"}
requests.get("https://example.com", proxies=proxies)

Playwright:

const context = await browser.newContext({
  proxy: { server: 'http://proxy.example.com:9000', username: 'u', password: 'p' },
});

Playwright'ın kimlik bilgilerini URL içinde değil ayrı alanlar olarak aldığını unutmayın; bu, yüzde kodlama sorununu tamamen ortadan kaldırır.

Çevre değişkenleri, birçok araç tarafından desteklenir:

export http_proxy=http://user:pass@proxy.example.com:9000
export https_proxy=http://user:pass@proxy.example.com:9000
export no_proxy=localhost,127.0.0.1,.internal

Küçük harf kullanın. Büyük harfli HTTP_PROXY

, CGI ortamlarında belgelenmiş bir tehlike barındırır; bu ortamlarda istek başlıkları büyük harfli çevre değişkenlerine dönüşür ve bunu destekleyen bir istemci, saldırgan tarafından sağlanan Proxy:

başlığıyla yönlendirilebilir.

Sorun Giderme

Doğru olduğunu düşündüğünüz kimlik bilgileriyle 407 hatası alıyorsanız. Şifrede yüzde kodlamasına ihtiyaç duyan özel karakterler olup olmadığını kontrol edin. Süresi dolmuş bir IP izin listesinde yer alıp almadığınızı da kontrol edin. Aracın kimlik bilgilerini gönderip göndermediğini kontrol edin — curl -v ... 2>&1 | grep -i proxy-auth adresi size bunu gösterir.

Aralıklı olarak görünen 407 hatası. Genellikle, bazı işleyicilerin izin listenizdeki adreslerden farklı bir çıkış adresine sahip olduğu dağıtık bir kurulumda veya yalnızca bazı uç noktaların kimlik doğrulaması gerektirdiği dönen bir ağ geçidinde ortaya çıkar.

curl ile çalışıyor, uygulamanızda hata veriyor. Kütüphane, HTTPS için proxy kimlik doğrulamasını desteklemiyor olabilir veya proxy'yi hiç uygulamıyor olabilir. İsteklerinizin gerçekten proxy üzerinden geçip geçmediğini kontrol edin — adresinizi yankılayan bir hizmet, bunu test etmenin en hızlı yoludur.

HTTP için çalışıyor, HTTPS için hata veriyor. HTTPS için istemci önce bir CONNECT isteği gönderir ve bazı kütüphaneler tünel için proxy kimlik doğrulamasını farklı şekilde işler ya da hiç işlemez.

Kimlik doğrulama başarılı, ancak istekler yine de başarısız. O halde sorun hiçbir zaman kimlik doğrulama ile ilgili değildi. Başarılı bir CONNECT isteğinin ardından gelen 403 hatası, proxy'den değil hedef sunucudan kaynaklanmaktadır.

Bir Ekip veya Filo Çapında Kimlik Bilgilerini Yönetme

Birden fazla kişi veya makine söz konusu olduğunda, kimlik bilgilerinin yönetimi artık sadece bir kolaylık meselesi olmaktan çıkar ve operasyonel bir sorun haline gelir.

Sağlayıcınızın izin verdiği durumlarda, kişi başına ve hizmet başına ayrı kimlik bilgileri verin. Tek bir paylaşılan hesap olması, kullanım artışına kimin işinin neden olduğunu belirleyememeniz, ayrılan bir iş arkadaşınızın erişimini herkesi etkilemeden iptal edememeniz ve bir sızıntının kaynağını tespit edememeniz anlamına gelir. Alt hesaplar biraz daha pahalı olsa bile, bu konuyu araştırmaya değer.

Kimlik bilgilerini görüntülerin ve kaynak kodun dışında tutun. Bir konteyner görüntüsüne gömülmüş bir şifre, daha sonraki bir derlemede kaldırdıktan sonra bile dahil olmak üzere, görüntünün her katmanında ve her kayıt defteri kopyasında bulunur. Çalışma zamanında orkestratörün gizli mekanizması aracılığıyla enjekte edin veya başlangıçta bir gizli bilgi yöneticisinden alın.

Sabit bir çıkışa sahip her şey için izin listesini tercih edin. Sabit bir sunucu, statik adresli bir NAT ağ geçidi veya bilinen bir çıkış IP'sinin arkasındaki bir Kubernetes kümesi, hepsi bir izin listesi kullanabilir ve hiçbir kimlik bilgisi barındırmaz. Bu, kimlik bilgilerinin ne kadar dikkatli bir şekilde yönetilmesinden de kesinlikle daha iyi bir durumdur.

İhtiyacınız doğmadan önce kimlik bilgilerinin değiştirilmesini planlayın. Kimlik bilgilerini tek bir yerden okuyun — bir gizli bilgi yöneticisi tarafından doldurulan bir ortam değişkeni veya kısıtlı izinlere sahip bir yapılandırma dosyası — böylece kimlik bilgilerini değiştirmek, kod tabanında arama yapmak yerine tek bir değişiklikle halledilebilir. Kimlik bilgilerini gerçekten değiştirmeniz gereken an, grep komutuyla arama yapmak isteyeceğiniz en son andır.

Yanlışlıkla yapılan commit hatalarına dikkat edin. Commit edildikten sonra kaldırılan bir kimlik bilgisi, depo geçmişinde kalır; açık bir depo ise, commit ne kadar çabuk geri alınırsa alınsın, bu bilginin tehlikeye atıldığı anlamına gelir. Depo taraması ucuz bir önlemdir ve derhal rotasyon yapmak tek gerçek çözümdür.

Ve her bir kimlik bilgisi için kullanım izlemeyi sağlayın. Sağlayıcınız alt hesap bazında trafik raporluyorsa, ani bir değişiklik, bir kimlik bilgisinin paylaşıldığını, sızdırıldığını veya unuttuğunuz bir iş tarafından kullanıldığını gösteren en erken işarettir. Bu aynı zamanda en pahalı hatayı yakalamanın en ucuz yoludur — satın almayı planlamadığınız bant genişliğini faturalandıran kontrolsüz bir döngü.

Sık Sorulan Sorular

407 hatası nedir?

407 Proxy Authentication Required hatası, proxy sunucusunun kimlik bilgilerini istediği ancak geçerli kimlik bilgileri almadığı anlamına gelir. Bu hata web sitesinden değil, proxy sunucusundan kaynaklanır ve RFC 9110 standardı, proxy sunucusunun beklediği şemayı belirten bir Proxy-Authenticate başlığı eklemesini gerektirir. Hedeflediğiniz kimlik bilgilerinin bu durumla bir ilgisi yoktur.

401 ile 407 arasındaki fark nedir?

401 hatası hedef sunucudan gelir ve WWW-Authenticate ile Authorization başlıklarını kullanır. 407 hatası ise proxy'den gelir ve Proxy-Authenticate ile Proxy-Authorization başlıklarını kullanır. 407 hatası, hedefe hiç ulaşamadığınız anlamına gelir.

IP izin listesi, kullanıcı adı ve şifreden daha mı iyidir?

Kaynak adresiniz sabitse, evet. Sızabilecek hiçbir kimlik bilgisi yoktur, kabuk geçmişinizde görünecek hiçbir şey yoktur ve yanlışlıkla bir depoya kaydedilecek hiçbir şey yoktur. Adresiniz değiştiğinde bu yöntem başarısız olur; bu nedenle dizüstü bilgisayarlar, mobil bağlantılar ve çoğu CI ortamı için kimlik bilgileri hâlâ gereklidir.

Proxy kimlik bilgileri şifrelenir mi?

HTTP Basic proxy kimlik doğrulaması, kimlik bilgilerini base64 ile kodlar; bu kodlama geri dönüştürülebilir ancak düz metin olarak okunamaz. SOCKS5 kullanıcı adı/şifre kimlik doğrulaması ise bunları düz metin olarak gönderir — RFC 1929 bunu açıkça belirtir ve "sniffing'in mümkün ve pratik olduğu durumlarda" bundan kaçınılmasını tavsiye eder. Şifreleme de bir koruma sağlamaz; sizi koruyan şey aktarımdır.

Özel karakter içeren proxy şifrem neden reddediliyor?

Çünkü @, : ve / gibi karakterler bir URL içinde anlam taşır. http://user:p@ss@host:9000 adresi, sizin amaçladığınız şekilde yorumlanmaz. Bu karakterleri yüzde kodlamaya tabi tutun veya kullanıcı adı ile şifreyi URL’ye gömmek yerine ayrı alanlar olarak kabul eden bir istemci kullanın.

Proxy kullanıcı adımdaki fazladan metin ne anlama geliyor?

Bu, kodlama seçeneklerini (bir ülke, oturum tanımlayıcısı, rotasyon ayarı gibi) kullanıcı adı alanına eklemek için sağlayıcıların kullandığı bir uygulamadır. Herhangi bir standardın parçası değildir; sözdizimi sağlayıcıya göre farklılık gösterir ve bir hata genellikle hata mesajı yerine, yanlış davranış sergileyen ancak işlevsel bir istekle sonuçlanır.

Hem kimlik bilgilerini hem de izin listesini kullanabilir miyim?

Birçok sağlayıcıda evet, bu mantıklı bir düzenlemedir: İzin listesi, kimlik bilgisi gerektirmeyen sabit sunucularınızı kapsarken, kimlik bilgileri geliştirici makinelerini ve adresi değişen her şeyi kapsar.

Proxy ve web sitesi için ayrı kimlik bilgileri gerekir mi?

Her ikisi de kimlik doğrulama gerektiriyorsa, evet — bunlar ayrı başlıklara sahip tamamen ayrı mekanizmalardır. Curl’da bu, proxy için --proxy-user ve hedef için -u şeklindedir; bunları karıştırmak, 401 beklerken 407 hatası veya tersi bir durumla sonuçlanır.

Sonuç

Proxy kimlik doğrulaması, web sitesi kimlik doğrulamasından ayrı bir katmandır ve protokol, bunu açıkça ortaya koymak üzere tasarlanmıştır. Farklı durum kodu, farklı başlıklar, farklı kimlik bilgileri. 407 kodunu "proxy beni durdurdu" ve 401 kodunu "hedef kimlik bilgilerini istiyor" olarak yorumladığınızda, kafa karıştırıcı hataların büyük bir kısmı kendiliğinden çözülür.

Mekanizmanın kendisi basittir: Proxy-Authenticate adresinde bir sorgu, Proxy-Authorization adresinde bir yanıt, bunu soran ilk hop tarafından işlenir. Unutulmaması gereken bir ayrıntı ise SOCKS5 adresidir; burada spesifikasyon, kimlik bilgilerinin düz metin olarak iletildiğini açıkça belirtir — bu, kontrolünüz altında olmayan herhangi bir ağda HTTP proxy'sini veya izin listesini tercih etmeniz için bir nedendir.

Ve bir satıcıya hiçbir maliyeti olmayan bir öneri: İstekleriniz sabit bir adresten geliyorsa, bir IP izin listesi kullanın. Burada açıklanan her sızıntı — kabuk geçmişi, işlem listeleri, ortam dökümleri, kaydedilmiş kaynak kodu, yapıştırılmış terminal çıktısı — sızacak bir kimlik bilgisinin varlığına bağlıdır. Kimlik bilgisini ortadan kaldırırsanız, bu sızıntı türünü de ortadan kaldırmış olursunuz.