Kimlik doğrulamalı SOCKS5 — gerçekte nasıl çalışıyor ve kütüphaneler neden yanlış yapıyor

SOCKS5, her şeyi kaldıran proxy protokolü olarak haklı bir ün kazanmıştır — ham TCP, UDP, her uygulama, her hedef. Ama kimlik doğrulama katmanı kendi RFC'sine, kendi kablo formatına ve istemci kütüphanelerinin bunu sessizce bozmasına dair uzun bir geçmişe sahip ayrı bir alt-protokoldür. Bir proxy sunucusunda kimlik bilgisi ayarlayın; popüler kütüphanelerin şaşırtıcı bir kısmı, bu kimlik bilgilerini gerçekten göndermeden bağlanmaya devam edecektir — çünkü bunun yerine no-auth müzakere ederler.

Özet: SOCKS5 kimlik doğrulaması RFC 1929'da tanımlanan iki turlu bir handshake'tir. Güvenli kalmak için sunucunun kimlik bilgileri yapılandırıldığında no-auth fallback'i reddetmesi gerekir — Nodetonet bunu varsayılan olarak yapar. Bu yazı, handshake'in her baytını, Nodetonet'in onu nasıl zorladığını ve kendi istemci kütüphanenizin kimlik doğrulamayı sessizce atlayıp atlamadığını nasıl doğrulayacağınızı açıklar.

SOCKS5 kimlik doğrulaması neden kendi başına bir dünyadır

Çoğu insan "kullanıcı adı ve şifreli SOCKS5" dediğinde HTTP Basic auth gibi çalıştığını hayal eder — header'da kimlik bilgisi, tamam. SOCKS5 bundan çok farklı çalışır. Protokol, yöntem müzakeresini (hangi auth türünü kullanacağınızı) kimlik bilgisi değişiminden (gerçek kullanıcı adı ve şifre) ayırır ve bunu, herhangi bir trafik akmadan önce iki farklı, sıralı handshake ile yapar. Her ikisi de bayt düzeyinde belirtilmiştir ve tek bir yanlış sekizlik bağlantıyı kapatır.

Handshake'i anlamak salt akademik değildir. En yaygın gerçek dünya arıza modu — bir scraper'ın günlerce kimlik bilgisi olmadan çalışması ve operatörün hiç fark etmemesi — doğrudan yöntem müzakeresinin yanlış gitmesinden kaynaklanır. Üst düzey bir genel bakış için SOCKS5 proxy sözlük girişine bakın, kablo detayı için burada okumaya devam edin.

İki aşamalı SOCKS5 handshake'i, bayt bayt

Aşama 1 — yöntem müzakeresi

Her SOCKS5 bağlantısı, istemciden bir selamlama ile başlar. İstemci, kullanmaya istekli olduğu kimlik doğrulama yöntemlerinin bir listesini gönderir:

05 02 00 02
^  ^  ^  ^
|  |  |  +-- yöntem 2: KULLANICI_ADI/PAROLA (0x02)
|  |  +----- yöntem 1: KIMLIK_DOGRULAMA_YOK (0x00)
|  +-------- sunulan yöntem sayısı
+----------- SOCKS versiyonu (5)

Sunucu listeyi okur, kabul ettiği tam olarak bir yöntemi seçer ve iki baytla yanıt verir:

05 02      -- "KULLANICI_ADI/PAROLA'yı seçiyorum"
05 00      -- "KIMLIK_DOGRULAMA_YOK'u seçiyorum" (tek sunduğunuz veya desteklediğim buysa)
05 FF      -- "Yöntemlerinizden hiçbiri kabul edilemez — hoşça kalın"

Sunucu FF ile yanıt verirse bağlantı hemen kapatılır. 02 ile yanıt verirse istemci kimlik bilgisi değişimine geçmek zorundadır. 00 ile yanıt verirse — ve istemci selamlayışında 00 sunduysa — bağlantı hiçbir kimlik bilgisi kontrolü olmadan devam eder. Bu, sessiz-fallback tuzağıdır.

Aşama 2 — RFC 1929 kimlik bilgisi alt-müzakeresi

Sunucu yöntem 0x02'yi seçtiğinde, istemci tamamen RFC 1929 tarafından tanımlanan ayrı bir kimlik doğrulama paketi gönderir (temel SOCKS5 RFC'si değil):

01 <ulen> <kullanici_adi_baytlari> <plen> <parola_baytlari>
^
+-- alt-müzakere versiyonu (her zaman 0x01)

Sunucu kimlik bilgilerini doğrular ve yanıt verir:

01 00      -- kimlik doğrulama başarılı
01 01      -- kimlik doğrulama başarısız (sıfır dışı herhangi bir bayt reddet anlamına gelir)

Sıfır dışı bir durum baytı, sunucunun bağlantıyı kapattığı anlamına gelir. Yalnızca 01 00 başarısından sonra istemci gerçek CONNECT, BIND veya UDP_ASSOCIATE isteğini gönderir.

Tam akış tek bir bakışta

Adım 3 ve 4, sunucu KIMLIK_DOGRULAMA_YOK'u seçtiğinde tamamen yoktur. Tehlike, bir istemci kütüphanesinin selamlayışı 05 02 00 02 olarak sunabilmesi (her iki yöntemi sunarak) ama sunucunun 00'ı seçmesidir — kimlik bilgileri hiç gönderilmez ve tünel yine de açılır.

Nodetonet kimlik doğrulamasını nasıl zorlar

Nodetonet panelinde bir SOCKS5 proxy oluşturduğunuzda, benzersiz bir kullanici_adi:parola çifti otomatik olarak oluşturulur. Atanan portu dinleyen edge node, her yeni TCP bağlantısında şu kuralları uygular:

• Edge, sunucu seçim yanıtında yalnızca yöntem 0x02'yi (KULLANICI_ADI/PAROLA) tanıtır. Kimlik bilgileri yapılandırıldığında asla 0x00 seçmez, bu nedenle fallback istemcisi sessiz bir özgür geçiş yerine 05 FF ve temiz bir bağlantı hatası alır.
• Kimlik bilgisi kontrolü, zamanlama tabanlı kullanıcı adı tespitini önlemek için sabit zamanlıdır.
• Kontrol, o tek proxy'ye kapsamlıdır — bir proxy'nin kimlik bilgileri başkasının kimliğini doğrulayamaz.
• Başarısız girişimler sayılır ve proxy denetim günlüğünüzde görünür; bu da kimlik bilgisi spreyleme saldırılarını tespit etmeyi kolaylaştırır.

Müşteri başına kimlik bilgileri (proxy istemcileri)

Tek bir tünelde proxy istemcileri yapılandırdıysanız — her müşteriye kendi kullanıcı adı/şifrelerini verebilmek için birden fazla kimlik bilgisi seti — RFC 1929 paketindeki kullanıcı adı hangi istemcinin eşleştiğini belirler. O noktadan itibaren, o istemcinin bireysel kotası, thread sınırı, IP izin listesi ve domain kısıtlamaları tüm session boyunca uygulanır. Bu, tek bir SOCKS5 uç noktasının tam olarak izole edilmiş kontrollerle düzinelerce farklı müşteriye hizmet edebileceği anlamına gelir.

SOCKS5 kimlik bilgileri kablodan düz metin olarak iletilir — bu RFC 1929 tarafından belirtilmiştir, Nodetonet'in tercihi değil. İstemcinizden edge sunucusuna giden yol güvenilmez bir ağdan geçiyorsa, bağlantıyı uygulama katmanında TLS'e sarın veya uçtan uca şifrelemeyi destekleyen HTTP/HTTPS proxy seçeneğimizi kullanın. Çoğu kullanım durumunda edge ayrılmış veya zaten şifreli bir bağlantıyla erişildiğinden, SOCKS5 kimlik doğrulamasının düz metin niteliği pratikte nadiren sorun olur.

Sessiz-fallback tuzağı — ve nasıl tespit edilir

En tehlikeli senaryo bir bağlantı hatası değil — başarılı olan ama kimlik doğrulaması olmadan çalışan bir bağlantıdır. Bu, istemci kütüphanesi selamlayışında hem KIMLIK_DOGRULAMA_YOK hem de KULLANICI_PAROLA sunduğunda, sunucu (yanlış yapılandırılmış veya çok izin verici) KIMLIK_DOGRULAMA_YOK'u seçtiğinde ve kütüphane neşeyle devam ettiğinde olur. Scraper'ınız çalışıyor gibi görünür ama hiçbir kimlik bilgisi doğrulanmamıştır.

Dile göre yaygın suçlular

• Python requests[socks] + PySocks < 1.7 — belirli hedef URL şemaları için kimlik bilgilerini sessizce düşürür. PySocks'u yükseltin ve hatayı tetikleyen bir şemayla doğrulayın.
• Node.js socks-proxy-agent — ajanı bir URL dizisi aracılığıyla oluşturursanız ve seçenekler nesnesinde userId'yi boş bir dizeye ayarlarsanız, seçenekler alanı kazanır ve etkin kullanıcı adı boş olur.
• Go golang.org/x/net/proxy — Auth struct pointer'ı nil olduğunda, sunulan auth yöntemi olmadan bağlanır ve sunucu KIMLIK_DOGRULAMA_YOK'a izin veriyorsa başarılı olur. Hiçbir uyarı verilmez.
• PHP cURL + CURLOPT_PROXYTYPE CURLPROXY_SOCKS5 — cURL'ün SOCKS5'inin (_HOSTNAMERESOLUTION varyantı olmadan) HTTPS hedefleri için kimlik doğrulamanın iletilmediği geçmiş edge case'leri vardır.

Tek satırlık kanıt

Kesin test: kasıtlı olarak yanlış kimlik bilgileriyle bir istek gönderin. Proxy sunucunuz kimlik doğrulamayı doğru şekilde zorluyorsa, bu başarısız olmalıdır:

curl --socks5 kullanici:YANLIS_PAROLA@sub42.nodetonet.com:48888 https://api.ipify.org
# Beklenen: curl: (7) Unable to receive initial SOCKS5 response
#           VEYA: SOCKS5 authentication failed

İstek yanlış kimlik bilgileriyle başarılı olursa, sunucunuz KIMLIK_DOGRULAMA_YOK'u kabul ediyor demektir. Hangi IP'nin ortaya çıktığını IP adresim nedir aracıyla doğrulayabilirsiniz.

SOCKS5 kimlik doğrulaması ile Nodetonet gelişmiş özellikleri

Sticky oturumlar

Bir rotating proxy'de her yeni bağlantıda farklı bir çıkış IP'si alırsınız. Tüm bir giriş veya ödeme akışı için aynı IP'ye ihtiyaç duyuyorsanız — bir sticky oturum — kullanıcı adına bir oturum kimliği ekleyin: u8x2-session-abc123. Proxy, o oturum etiketi olan tüm bağlantıları oturum TTL'si boyunca aynı cihaz üzerinden yönlendirir. Bu, SOCKS5 ve HTTP'de aynı şekilde çalışır.

Kullanıcı adı değiştiricileriyle coğrafi hedefleme

Kimlik bilgilerini aynı kullanıcı adı dizisinde coğrafi hedefleme değiştiricileriyle birleştirebilirsiniz — örneğin u8x2-country-tr-session-1, sabitlenmiş bir oturumla Türk mobil IP'si üzerinden yönlendirir. Uç nokta değişikliği gerekmez. Konuma özgü seçenekler için Türkiye, İstanbul ve Turkcell sayfalarına bakın.

TCP parmak izi sahteciliği için SOCKS5 kullanımı

SOCKS5 HTTP katmanını yeniden yazmak yerine ham TCP ilettiği için Nodetonet ayrıca edge'de TCP/IP parmak izi sahteciliği uygulayabilir — hedef tarafından görülen işletim sistemi düzeyindeki TCP parametrelerini değiştirerek. Bu, istemci uygulamasına görünmezdir ve IP adresinin ötesinde başka bir güven katmanı ekler.

Nodetonet'te HTTP ile SOCKS5 arasında seçim

Nodetonet her iki protokolü de aynı cihaz havuzundan sunar, dolayısıyla bu bir platform kısıtlaması değil, kullanım durumuna göre bir seçimdir. Tam karşılaştırma için HTTP vs SOCKS5 — hangisini seçmeli sayfasına bakın. Hızlı bir kılavuz olarak:

• Tarayıcılar, Playwright/Puppeteer, çoğu scraper için HTTP/HTTPS kullanın — kütüphane ekosistemi daha olgun ve URL tabanlı yapılandırma evrenseldir.
• HTTP dışı trafik için SOCKS5 kullanın (özel TCP araçları, oyun istemcileri, proxy üzerinden veritabanı bağlantıları) veya proxy'nin ham bayt iletmesini istediğinizde.
• Her ikisi de aynı formatta kullanıcı adı/şifre kimlik doğrulamasını destekler; bu yazıda açıklanan RFC 1929 handshake'i SOCKS5 için geçerlidir. HTTP proxy'lerde kimlik bilgileri Proxy-Authorization: Basic başlığında taşınır.

SOCKS5 proxy'leri tam proxy listesinin yanında görmek ve istemci kimlik bilgilerini yönetmek için SOCKS5 ve HTTP proxy'ler özellik sayfasını ziyaret edin veya ücretsiz hesap oluşturun.

Devamını oku

• HTTP vs SOCKS5 — hangisini seçmeli — her kullanım durumu için tam karşılaştırma.
• Proxy istemcileri: müşteri başına kimlik doğrulama — tek tünelde birden fazla kimlik bilgisi seti nasıl kurulur.
• Rotating mobil proxy ne zaman kullanılır — SOCKS5'i rotating cihaz havuzuyla birleştirme.
• Upstream kimlik doğrulama hatalarını debug etme — kimlik bilgileri doğru görünür ama hiçbir şey bağlanmaz.
• TCP parmak izi sahteciliği — Nodetonet'in edge'de işletim sistemi parmak izini nasıl maskelediği.
• Sticky oturumlar açıklandı — her iki protokol için geçerli olan oturum sabitleme derinlemesine.