SOCKS Proxy Nedir ve Nasıl Çalışır? Detaylı Analiz
Bu yazıda SOCKS proxy (vekil) türünün nasıl çalıştığını detaylı olarak ve örneklendirerek açıklamaya çalıştım. SOCKS proxy türünün tam olarak nasıl çalıştığını merak edenler için faydalı bir yazı olduğunu düşünüyorum.
Teknik detaların daha iyi anlaşılabilmesi için aşağıdaki kavramların bilinmesinde fayda var:
- Temel seviyede OSI standardı ve katmanları
- TCP tabanlı bağlantılardaki üçlü el sıkışma (three-way handshake) olayı
- FQDN, IP4, IP6
Bu proxy yapısında 3 aktör mevcuttur;
- Client: Bağlantıyı başlatan kaynak nokta,
- SOCKS Sunucusu: Bağlantıya aracılık eden sunucu,
- Hedef: SOCK sunucusu aracılığıyla bağlanılmak istenen uç nokta (Bir PC ya da sunucu olabilir)
Giriş
Client: ile Hedef arasındaki iletişime aracılık eden ve OSI standartına göre 5. katmanda bulunan bir protokoldür. Kurumsal ortamlarda kullanıcıların network trafiğini kontrol etmek için, bireysel kullanımda gizlilik için, (kimi zaman karanlık amaçlar için) tercih edilen bir vekil sunucu türüdür.
Kullnımı oldukça basittir. SOCKS proxy desteği olan herhangi bir uygulamaya (tarayıcı vb) bir SOCKS4 veya SOCKS5 hizmeti veren bir IP adresi ve port numarasını girdinizde Hedef ile olan iletişime SOCKS Sunucusu aracılık edecektir. Böylece karşı taraf yani Hedef sizin IP adresinizi değil SOCKS Sunucusunun IP adresini görecektir.
Hatırlatma:
SOCKS proxy ile VPN birbirine karıştırılmamalıdır. Kullanım amaçları bakımından benzer gibi görünseler de yapıları bakımından birbirlerinden farklıdır.
Proxy Türleri ve Farkları
SOCKS proxy türünün SOCKS4, SOCK4a ve SOCKS5 olarak versiyonları mevcuttur. SOCKS5’de IP6 ve UDP protokolleri desteklenmekte ve SOCKS4’e göre daha fazla yetkilendirme mekanizması mevcuttur.
HTTP Proxy sadece uygulama (7. katman) seviyesinde çalışırken SOCKS Proxy 5. katman ve üstünde bulunan tüm protokolleri destekler. Yani HTTP proxy sadece HTTP bağlantılarına aracılık edebilrken, SOCKS protokolü 5. katmanın üzerindeki tüm protokolleri (HTTP, FTP, SSH, SSL) destekler.
Önce SOCKS bağlantı akışını inceleyelim. Sonrasında bir örnek yapacağız;
3 adet bağlantı süreci mevcut;
- Client‘in SOCKS Sunucusuna bağlanması
- SOCKS Sunucusunun Hedefe bağlanması
- Client‘ın Hedef arasındaki (Proxy aracılığıyla olan) iletişim (FTP, SSH, HTTP vb.)
Bağlantı Akışı
Bir SOCKS Sunucusunun aracılık ettiği kaynak-Hedef arasındaki bağlantı sırasında özet olarak aşağıdaki işlemler gerçekleşir.
Client ile SOCKS Sunucusu arasında TCP handshake gerçekleşir.
Client, SOCKS Sunucusuna ne tür yetkilendirme metodlarını tercih ettiğini belirten bir mesaj gönderir. Bu mesajın içeriği şöyledir;
- SOCKS versiyon numarası [1 byte]
- SOCKS metod adedi [1 byte]
- Tercih edilen SOCKS metodları (Her bir metod 1 byte ile ifade edilir) [1-255 bytes],
SOCKS Sunucusu, Client tarafından teklif edilen yetkilendirme metodlarından birini seçer ve cevap olarak bu seçime dair bir mesaj gönderir. Mesajın içeriği şöyledir;
- SOCKS versiyon numarası [1 byte]
- Seçilen yetkilendirme metodu ifade eden kod, [1 byte]
Eğer seçilen kodun değeri;- 0xFF ise SOCKS Sunucusu Client‘ın teklif ettiği hiçbir metodu uygun bulmamış demektir. Bu mesajdan sonra Client ile SOCKS Sunucusu arasındaki bağlantı sonlanır.
- 0x02 ise Client ile SOCKS Sunucusu arasında kullanıcı/parola ile yetkilendirme olacaktır.
- 0x00 ise Client ile SOCKS Sunucusu arasında yetkilendirme olmasızın bağlantı kurulacak demektir.
- Birçok yetkilendirme metodu mevcut. Diğer metodlar için kaynak: RFC 1928
Not: Bundan sonraki adımlar yukarıda anlatıldığı üzere seçilen yetkilendirme metoduna göre değişkenlik gösterecektir.
- Bu adımda SOCKS Sunucusu ile Hedef arasında nasıl bir bağlantı olacağı belirlenir. Bağlantı 3 şekilde olabilir;
- SOCKS Sunucusundan Hedefe TCP/IP bağlantısı (CONNECT metodu),
- Hedeften SOCKS Sunucusuna bağlantı için TCP/IP port binding (BIND metodu) (**),
- UDP bağlantısı
En yaygın olan bağlantı türü bizim de anlatacağımız 1. bağlantı türüdür. Yani SOCKS Sunucusundan Hedefe bağlanmasını isteyeceğiz. Böylece bizim SOCKS Sunucusuna göndereceğimiz paketleri SOCKS Sunucusu bu bağlantı aracılığıyla Hedefe gönderecek.
Client SOCKS Sunucusuna bağlantı kurması için aşağıdaki mesajı gönderir. Mesajın içeriği şöyledir;
- SOCKS versiyon numarası [1 byte]
- Bağlantı komutu [1 byte] (Connect: 0x01), (Port binding: 0x02), (UDP: 0x03)
- Rezerve: 0x00 [1 byte]
- Hedef adres türü [1 byte] (IP4: 0x01) (FQDN: 0x03) (IP6:0x04)
- Hedef adres [Boyutu adres türüne göre farklılık gösterir]
- Hedef port (network byte düzenine göre) [2 byte]
Bu adımda SOCKS Sunucusundan Hedef hosta bağlanmasını istiyoruz. Hedef hostun adresi bir FQDN türünde olabilir (altdomain.domain.com) ya da sıklıkla tercih edilen IP4 türünde bir adres olabilir. (Örn: 178.234.23.12)
Not: Bundan sonraki adım Client‘ın Bağlantı Kodu ile belirttiği bağlantı talebine göre değişkenlik gösterir. Biz yine yaygın olarak kullanılan CONNECT metoduna göre anlatacağız.
Eğer bağlantı kodu CONNECT ise SOCKS Sunucusu mesajda hedef adres olarak belirtilen Hedef hostun hedef port una TCP bağlantısı kurar.
Bağlantının durumu (başarılı/başarısız) Client‘a mesaj olarak iletilir. Bu mesajın içeriği şöyledir; (X ile başlayan değerler hexadecimal değerlerdir.)
- SOCKS versiyon numarası [1 byte]
- Bağlantı durumu [1 byte]
- X’00’ Başarılı
- X’01’ SOCKS Suncusundan kaynaklı bir hata
- X’02’ Kuralseti tarafından bağlantı reddedildi
- X’03’ Network erişilebilir değil
- X’04’ Host erişilebilir değil
- X’05’ Bağlantı reddedildi
- X’06’ TTL zaman aşımına uğradı
- X’07’ Komut desteklenmiyor
- X’08’ Adres türü desteklenmiyor
- X’09’ ile ‘FF’ arası boşta
- Rezerve: 0x00 [1 byte]
- SOCKS Sunucusunun bağlantı adres türü [1 byte]
- IP4 address: X’01’
- FQDN: X’03’
- IP6: X’04’
- SOCKS Sunucusunun bağlantı IP’si (***)
- SOCKS Sunucusunun bağlantı portu
Gelen mesajda bağlantının başarılı olduğunu belirtiliyor ise herşey hazır demektir. 1. adımda Client ile SOCKS Sunucusu arasında bağlantı kurulumuştu. Şimdi de SOCKS ile Hedef host arasında bağlantı kuruldu. Artık esas bağlantı için herşey hazır. Bundan sonra Client ile Hedef host arasında nasıl bir iletişim tercih edilmişse (FTP, SSH, HTTP vb) bu iletişim TCP paketleri halinde önce SOCKS Sunucusuna oradan da Hedef sunucuya iletilecektir.
NOT: Buraya kadar olan adımlar tüm TCP tabanlı bağlantılarda ortaktır.
Bu adımdan sonraki süreç standart bir TCP bağlantısındaki ile tamamen aynıdır. Yani Client hangi protokol ile Hedefe bağlanacaksa (Örn: HTTP) paketleri SOCKS Sunucusuna görderir. SOCKS Sunucusu da gelen paketleri Hedefe gönderir. Hedef de yanıtları aynen bu yol ile geri gönderir. Client ile Hedef birbirinden haberdar olmaksızın haberleşmiş olur.
İletişim tamamlandığında Client bağlantıyı sonlandırır. SOCKS ve Hedef host arasındaki bağlantılar da kapanır.
Şimdi SOCKS proxy kullanarak HTTPS bağlantısının nasıl kurulduğunu yukarıdaki adım adım anlattığımız gibi anlatalım. (Bu bağlantı SOCKS proxy desteği olan herhangi bir uygulama ile gerçekleştirilebilir.)
Örnek Bağlantı Akışı
Genel akış aşağıdaki resimde olduğu gibi olacaktır.
İlk olarak Client ile SOCKS Sunucusu arasında TCP bağlantısı (üçlü el sıkışma) gerçekleşecek.
Resim 2: handshake
TCP bağlantısı kuruldu. Şimdi sıra veri iletimi için SOCKS Sunucusu ile Client arasındaki yetkilendirme mekanizmasına karar verilecek. 2. maddede anlattığımız üzere Client tercih ettiği yetkilendirme metodlarını SOCKS Sunucusuna gönderiyor.
Resim 3: Metot Önerme
Görüntüden anlayacağınız üzere Client tarafı iki tür yetkilendirme metodu önermektedir:
* No authentication
* Username/password
SOCKS Sunucusu, Client tarafından önerilen metodlardan birini seçecek. Eğer parola ile yetkilendirme mekanizması varsa SOCKS sunucumuz Client tan kullanıcı adı ve parola istecektir. Eğer böyle bir mekanizması yoksa yetkilendirme olmadan (anonim) bağlantı kurulacaktır.
Şimdi 3. adımda anlattığımız gibi SOCKS Sunucusu tercih ettiği metodu ve birtakım bilgileri Client‘a gönderecek.
Resim 4: Sunucunun kabul ettiği metot
Resimde SOCKS Sunucusunun tercih ettiği metodu görüyorsunuz. Herhangi bir yetkilendirme olmayacak diyor.
Hatırlatma: Client‘ın amacı SOCKS proxy vasıtasıyla example.com sitesine bağlanmak olduğundan; SOCKS Sunucusu, Client adına bu bağlantıyı gerçekleştirecek
Client madem yetkilendirme yok o halde benim adıma example.com’a git bağlan diyecek. Bunu bir mesaj ile SOCKS Sunucusuna bildirecek. 4. adımda anlattığımız gibi mesajın içeriği şöyle olacak;
Resim 5: Bağlantı
Resimde gördüğümüz üzere Client, SOCKS suncusuna “Connect” emri gönderiyor. Bağlanmasını istediği yer ise example.com sitesinin sunulduğu 192.64.118.106’si ve tabiki HTTPS portu 443’tür. SOCKS Sunucusu aldığı bu talimatla example.com’a bağlanmış olacak. Sonra bağlantının durumu ile ilgili Client‘e mesaj gönderecek.
Resim 6: Bağlantı durumu
Sunucudan gelen cevabın içerisinde gördüğümüz Results(s): Succeeded SOCKS Sunucusunun example.com’a başarılı olarak bağlandığını ifade ediyor. Mesajdaki diğer alanların anlamını 5. adımda anlatmıştık. Mesaj içerisindeki remote adres alanı example.com’a bağlanan SOCKS Sunucusunun IP ve local port numarasıdır.
Buraya kadar herşey tamam. Bu adımdan sonrası her yerde aynıdır. Yani her zaman olduğu gibi Client-server arası HTTPS iletişimi nasıl oluyorsa burada da aynısı olacak. Tek farkı Client‘ımız sanki example.com ile konuşuyormuş gibi paketlerini SOCKS Sunucusuna gönderecek. SOCKS Sunucusu da sanki bağlanmak isteyen kendisiymiş gibi example.com ile konuşacak ama Client‘ın gönderdiği paketleri iletecek sadece. Kendisi ilave olarak birşey yapmayacak. Hedef kendisiyle konuşmak isteyenin SOCKS Sunucusu olduğu zannedecek. Bu işin arkasında Client‘ın olduğunu bilmeyecek.
Şimdi bu iletişim nasıl olduğu görelim;
Resim 7: TCP Flow
Resimde görüldüğü üzere HTTPS iletişimi başlıyor. Bağlanılan yer bir web sitesi olduğundan bağlantı protokolü HTTP/HTTPS olacak. HTTPS bağlantılarında ilk olarak TLS protokolü devreye giriyor. Hedef example.com web sayfasının içeriğini (HTML+CSS+Javascript vs.) şifreli TCP paketleri halinde gönderir.
Not: Bu iletişim sırasında SOCKS sunucu aldığı paketi işlemeden Hedefe gönderir. HTTP proxyden farklı olarak SOCKS Sunucusu trafiği kesme (intercept) yapmaz, doğrudan iletir (relay).
Hedef example.com web sayfasının tüm içeriğini (HTML+CSS+Javascript vs.) gönderdikten sonra gönderecek başka birşey kalmadığını ifade eden TCP FIN-ACK mesajını gönderir.
TCP FIN-ACK mesajını alan Client benzer bir şekilde SOCKS Sunucusuna benim sana ileteceğim birşey kalmadı anlamında TCP FIN-ACK mesajı gönderir. Bu mesaj alındıktan sonra SOCKS Sunucusunun hem Cliet ile hem de Hedef ile bağlantısı olağan bir (TCP bağlantısında olduğu gibi) sonlandırılır.
Client sonuç olarak example.com‘a bir SOCKS Sunucusu aracılığla bağlanmış oldu. example.com site admini erişim loglarına baktığında SOCKS Sunucusunun IP adresini görecek, Client‘a dair herhangi bir şey göremeyecektir. Böylelikle Client anonim olmuş oldu.
Peki HTTP/HTTPS bağlantısı yerine başka ne tür protokoller kullanılabilirdi?
Sorunun cevabı basit. SOCKS proxyler OSI standardının 5. katmanda bulunduğundan 5. katman üzerindeki hemen hemen tüm protokolleri destekler. Bu örnek bir HTTPS örneği idi. HTTPS yerine SSH, FTP, SMTP ya da TELNET protokolü kullanılabilirdi. Bağlantı süreci 7. adıma kadar aynı olacaktı, 7. adımdan sonra ilgili protokole ait paketler gidip gelecekti.
Anlacaklarımız bu kadardı. İlerleyen zamanda daha fazla örnek yapacağım. Şimdilik bu kadar.
**: Bu BIND denen bağlantı metodunun amacı nedir diye aklımıza bir soru gelebilir. Bazı protokollerde ilkinin yanında ikinci bir bağlantıya ihtiyaç duyulabiliyor. Örneğin FTP protokolünde veri gönderimi için ek olarak bir bağlantı daha gerekiyor. Bu bağlantı sadece veri gönderimi için kullanılıyor. İlk bağlantı ise sadece FTP komutunun iletimi için kullanılıyor. Daha fazla detay için: FTP Basic
***: Buradaki IP adresi bize aracılık eden SOCKS Sunucusuna ait IP adresi olmak zorunda değildir. Çünkü SOCKS Sunucusunun network yapısından kaynaklı olarak Hedefe bağlandığı IP adresi farklı olabilir. Şuan bizim için çok önemli değil ancak bilmekte fayda var.