Univerzální proxy server. Co je to SOCKS server a proč je potřeba?

Dobrý den, drazí přátelé, známým, čtenářům, obdivovatelům a dalším jednotlivcům. V tomto článku, jak jste pochopili z názvu, budeme mluvit o tom, co je PONOŽKY server a proč je vůbec potřeba.

Tyto informace se samozřejmě budou hodit spíše zájemcům než běžnému uživateli, ale v zásadě se znalost takových věcí může hodit i jemu... protože kdo ví, jak život dopadne.

Obecný a podrobný popis SOCKS

Toto je protokol, který umožňuje síťové aplikace komunikovat přes bránu firewall, která blokuje přímé připojení. V tomto případě je použit speciální meziserver, ke kterému je povolen přístup oběma klientům.

Přenáší data přijatá od prvního klienta k druhému a zpět. Na rozdíl od, skrz PONOŽKY proxy může povolit jakýkoli provoz (řekněme ). Kromě PONOŽKY přenáší „čistá“ data, aniž by ze sebe něco přidala, takže je obtížnější jej detekovat.

V každodenní život PONOŽKY Proxy se nejčastěji používá pro přístup na stránky, které jsou zakázané. V této situaci se ukáže, že přistupujete na server, a nikoli na zakázanou internetovou adresu, takže připojení není blokováno.

Druhým důvodem, proč můžete tyto servery používat, je anonymita, konkrétně skrývání. V tomto případě to nejste vy, kdo naváže spojení se vzdáleným internetovým serverem, ale PONOŽKY proxy, takže koncový server pravděpodobně neobdrží žádné informace o vás a vašem počítači.

Doslov

Tak se věci mají. Doufám, že nyní alespoň zhruba chápete, co to obecně je a proč to může být obecně nutné.

O tom, jak konkrétně pracovat s PONOŽKY a další proxy skrýt své IP bude napsáno v samostatném článku, pokud to samozřejmě někdo nepotřebuje a nebude mít zájem.

Jako vždy, pokud máte nějaké dotazy, myšlenky, doplňky atd., uvítejte komentáře k tomuto materiálu.

Článek je věnován protokolu SOCKS5 - jeho vnitřní struktuře, praktická aplikace, stejně jako SOCKS servery a klienty dostupné pro platformu Unix

[Valentin Sinitsyn (val AT linuxcenter DOT ru)]

"Promiň, Pú," řekla SAVA. - Tigger přežvýkal všechny dráty z poštovního serveru a pošta dlouho nepřicházela...
"Dráty," pomyslel si Pú naštvaně. - Z těchto drátů upleťte ponožky.

Andrey Shcherbakov "9600 baudů a to je ono, to je ono, to je ono..."

V tomto článku budeme hovořit o protokolu SOCKS[ poznámka pod čarou: "socks" - anglicky. "ponožky", "punčochy"]. S jeho pomocí můžete vyřešit různé problémy: organizovat bezpečný přístup ke službám umístěným za nimi firewall(firewall), skryjte svou skutečnou IP adresu při práci s nepřátelskými síťovými zdroji nebo implementujte univerzální proxy server, který podporuje jakékoli protokoly aplikační úroveň(HTTP, FTP, POP3/SMTP, ICQ atd.). Bohužel, přes veškerou jednoduchost a bohatost schopností SOCKS, mnoho správci systému nejsou s tím dostatečně obeznámeni a netuší, jak by to mohlo být užitečné. Chtěl bych doufat, že po přečtení tohoto materiálu zaujme nezaslouženě zapomenutý protokol své právoplatné místo v jejich arzenálu. Udělejme rezervaci hned: všechny následující prezentace se budou týkat páté verze SOCKS, SOCKS5. Předchozí, čtvrtá verze (SOCKS4) je stále v oběhu na internetu, nicméně její možnosti jsou omezenější.

Mimochodem, název protokolu nemá nic společného s punčochovým zbožím zmíněným v epigrafu a jde o jednoduchou zkratku pro „SOCK-et-S“ - „zásuvky“, nebo ve známějším překladu do počítačového specialisty. ucho, „zásuvky“. Termín navrhli tvůrci jako pracovní možnost a ustál. Jak víte, sockety jsou základem jakéhokoli API, které implementuje síťovou komunikaci - Unix, Winsock atd. K odesílání dat přes síť je aplikace jednoduše potřebuje zapsat do soketu, podobně jako při ukládání informací do místní soubor. V obou případech se program nemusí starat o to, co se děje „v zákulisí“ – doplňování uživatelských dat o servisní informace, jejich rozdělení na segmenty s jejich následným zapouzdřením do datagramů a fyzické odeslání provádějí další části operační systém - zásobník TCP/IP a ovladače zařízení, o kterých aplikace nic neví. Toto „rozdělení práce“ vám umožňuje změnit postup doručování zpráv podle potřeby za předpokladu, že rozhraní pro programování aplikací zůstane konstantní. Právě tato vlastnost je základem ideologie SOCKS. Hlavním úkolem tohoto protokolu je zavést do „normálního“ procesu výměny dat určitého prostředníka zvaného SOCKS server nebo SOCKS proxy. Když chce klient (aplikace, která podporuje SOCKS: webový prohlížeč Mozilla, ICQ Miranda IM klient atd., viz níže) odeslat jakoukoli informaci přes síť, naváže spojení nikoli se skutečným příjemcem, ale se serverem SOCKS, která zase přeposílá data na místo určení, ale svým jménem. Z pohledu „skutečného“ serveru (například webové stránky, na které si chce uživatel prohlížet Mozilla Firefox) SOCKS proxy je nejběžnějším klientem. Identita (IP adresa) skutečného klienta je tedy skryta před serverem, který jej obsluhuje. Tato velmi výhodná okolnost je plná potenciálního nebezpečí (můžete se skrýt Vy, ale mohou od vás), proto skutečné servery SOCKS vyvinuly schémata řízení přístupu (zakazující příchozí a odchozí připojení k danému seznamu adres) a podporují autorizaci uživatelů pomocí hesla (viz níže).

Všimněte si, že protože SOCKS funguje na nižší úrovni než aplikační (jmenovitě transportní) úroveň modelu OSI, nebude jeho podpora vyžadovat žádné změny v logice klienta, tím méně serveru. Ve skutečnosti vše, co je potřeba, je upravit implementaci funkcí odpovědných za vytváření síťové připojení a odesílání dat: connect(), bind(), send() atd. V praxi se toho obvykle dosahuje zachycováním systémových volání a jejich následným nahrazením uživatelsky definovanými protějšky s podporou SOCKS. Žádné změny ve zdrojovém kódu klientské aplikace, tím méně přístup ke zdrojovým textům zpravidla není vyžadován. Tento účinný postup je známý jako „soxifikace“ a bude podrobně popsán níže.

Teď, když máme obecná myšlenka o SOCKS, můžeme přejít k podrobnější úvaze o tomto protokolu.

Specifikace SOCKS5

Protokol SOCKS5 je podrobně popsán v RFC1928. Na rozdíl od monstrózních standardů, jako je HTTP 1.1, se specifikace SOCKS vejde do 9 stránek a může být snadno analyzována kýmkoli. Zde nabízené informace jsou jejich stručným shrnutím a mají vám pomoci v této jednoduché záležitosti.

Jak bylo uvedeno dříve, SOCKS5 je protokol transportní vrstvy. Jeho „sousedé“ - TCP a UDP se přímo používají k přenosu dat přicházejících z aplikační vrstvy (z vlastní aplikace), což znamená, že proxy server SOCKS musí být schopen správně pracovat s každým z nich. Všimněte si také, že protokol ICMP používaný obslužnými programy ping a traceroute je umístěn pod transportní vrstvou, a proto jej bohužel nelze kodifikovat.[ Poznámka pod čarou: existují nestandardní rozšíření protokolu SOCKS, která umožňují pracovat s ICMP, nicméně o nich se v tomto článku nebudeme diskutovat].

Před odesláním jakýchkoli dat musí klient projít autorizační procedurou na serveru SOCKS. Za tímto účelem otevře připojení TCP k portu 1080 (výchozí hodnota) serveru SOCKS a odešle přes něj zprávu obsahující kódová čísla metod autentizace, které podporuje. Server SOCKS vybere jednu z metod podle svého uvážení a nahlásí její číslo klientovi. Seznam některých možných hodnot je uveden v tabulce 1. Jak můžete snadno vidět, autentizace může chybět (v praxi to pravděpodobně znamená, že server SOCKS rozlišuje klienty podle jejich IP adres) nebo na základě uživatelského jména a heslo. V druhém případě je to možné velký počet různé možnosti, z triviálního „Ověření uživatelského jména/hesla“ (RFC 1929) zajišťujícího přenos hesla do otevřený formulář na mnohem bezpečnější CHAP (šifrované heslo, prostá data) a GSSAPI (RFC 1961), které lze použít ke kompletní kryptografické ochraně provozu. Po úspěšné autorizaci je klient schopen odesílat požadavky (příkazy), navazovat odchozí spojení a dokonce přijímat příchozí.

Navazování odchozího TCP spojení

K navázání odchozího TCP spojení klient odešle požadavek „CONNECT“ na server SOCKS, který specifikuje adresu a doručovací port. K identifikaci uzlu příjemce slouží jak IP adresy (podporovány jsou IPv4/IPv6), tak plnohodnotné názvy domén. V druhém případě se o jejich vyřešení stará SOCKS server, takže síť, ve které klient funguje, se v zásadě obejde bez DNS serveru. Ve zprávě s odpovědí server SOCKS hlásí chybový kód (jako obvykle 0 znamená, že operace byla úspěšná), a také IP adresu (BND.ADDR) a TCP port (BND.PORT), které budou použity ke skutečnému komunikovat s požadovaným uzlem. Protože servery SOCKS mají obvykle více než jedno síťové rozhraní, danou IP adresu se může lišit od toho, se kterým bylo navázáno řídicí spojení. Klient poté otevře novou TCP relaci s BND.ADDR:BND.PORT a odešle data. Odchozí TCP spojení je ukončeno při zavření kontrolní relace. Všimněte si, že požadavek CONNECT může být odmítnut SOCKS proxy, pokud jsou zdrojové (klientské) nebo cílové (serverové) adresy zakázány [ Poznámka pod čarou: nebo není výslovně povoleno, v závislosti na konkrétní implementaci a zvolené politice] obsluhovat správce systému.

Navazování odchozího připojení UDP

Na rozdíl od streamovacího protokolu TCP, který zahrnuje vytvoření relace, protokol UDP je datagram, a proto se s ním manipuluje poněkud obtížněji. Jeho podpora se objevila až v SOCKS5.

Před odesláním UDP datagramů si klient vyžádá SOCKS server sdružení UDP pomocí příkazu "UDP ASSOCIATE". Přidružení UDP je druh virtuální relace mezi klientem a serverem SOCKS. V odchozím požadavku klient specifikuje údajnýadresu a port, který bude fungovat jako zdroj budoucích datagramů UDP. Pokud tato informace při navazování přidružení UDP ještě není známa, měl by klient použít kombinaci 0.0.0.0:0 (nebo řekněme x.x.x.x:0, pokud je neznámé pouze číslo portu). V odpovědi SOCKS server specifikuje IP adresu (BND.ADDR) a UDP port (BND.PORT), na který mají být odesílány odchozí datagramy. V tomto případě je přímo v těle uvedena adresa a port jejich skutečného příjemce (dá se říci, že probíhá zapouzdření UDP). E Vy parametry spolu s adresou odesílatele a portem se používají k rozhodnutí, zda lze datagram odeslat. Jak můžete snadno vidět, vytváří to další zatížení serveru SOCKS: na každý datagram UDP musí být aplikována pravidla filtrování, zatímco v případě připojení TCP se jeho legitimita posuzuje jednou, v okamžiku, kdy server SOCKS provede „ příkaz CONNECT“. Podle standardu musí server SOCKS zajistit, aby IP adresa odesílatele datagramu odpovídala adrese hostitele, který vytvořil asociaci UDP. Přidružení UDP je zničeno současně s uzavřením relace řízení TCP, ve které byl odeslán příkaz UDP ASSOCIATE.

U mnoha existujících serverů SOCKS dochází k vážným problémům, pokud je mezi nimi a klientem požadujícím přidružení UDP umístěn firewall NAT (Network Address Translation). Důvodem je změna zdrojové adresy a portu, ke které dochází v okamžiku, kdy UDP datagram překročí firewall. Výsledkem je, že server a nic netušící klientská aplikace začnou mluvit různé jazyky: zamýšlená zdrojová adresa a port zadané v příkazu „UDP ASSOCIATE“ již neodpovídají skutečným parametrům datagramů přijatých serverem SOCKS. V důsledku toho jsou vyřazeny, protože nepatří do asociace UDP. Problém by bylo možné vyřešit zadáním 0.0.0.0:0 jako zamýšleného zdroje (viz výše), který by měl být serverem SOCKS interpretován jako „jakýkoli datagram UDP pocházející ze stejné adresy jako příkaz k vytvoření přidružení“. Bohužel většina skutečných serverů SOCKS interpretuje standard úžeji a neumožňují současně nastavit zamýšlenou adresu i port odesílatele na nulu. Z autorem testovaných implementací umožňuje zde popsaný „trik s předáváním UDP přes NAT“ pouze jednu – Dante.

Příjem příchozích spojení

Tento stačí originální příležitost může být užitečné v případech, kdy jsou klient a "skutečný" server ve výše uvedeném schématu prohozeny, což se může stát například u protokolů jako FTP. Pro účely další diskuse budeme předpokládat, že mezi „klientem“ (stranou, která má v úmyslu přijmout příchozí spojení) a „server“ (strana iniciující příchozí spojení) již vytvořil „přímý“ komunikační kanál pomocí příkazu „CONNECT“. Pro otevření „reverzního“ kanálu musí „klient“ odeslat příkaz „BIND“ serveru SOCKS, přičemž ve svých parametrech specifikuje IP adresu a port, který bude používat pro příjem příchozího spojení. V reakci na to server SOCKS hlásí IP adresu a port, který je mu přidělen, aby udržoval „reverzní“ kanál. Očekává se, že "klient" předá tyto parametry "serveru" pomocí prostředků poskytovaných protokoly aplikační vrstvy (například příkaz FTP "PORT"). Poté, co SOCKS server přijme (nebo odmítne) příchozí spojení, znovu upozorní „klienta“ a sdělí mu IP adresu a port používaný „serverem“. Upozorňujeme, že příchozí připojení může přijímat pouze aplikace, jejíž vývojáři se postarali o podporu SOCKS ve fázi návrhu. V opačném případě (pokud aplikace pracuje se serverem SOCKS prostřednictvím programu sockets), nebude schopna poskytnout správné informace o adrese socketu, který čeká na „zpětnou vazbu“ (tj. vygeneruje nesprávný příkaz „PORT“ ve výše uvedeném příkladu FTP).

Ponožky "řetízky".

Pojď do práce. Šest pronajatých „současně“ routerů, přes které běží signál. A všechny jsou docela odolné proti hackování.

Sergej Lukjaněnko „Labyrint odrazů“

Architektura protokolu SOCKS5 umožňuje snadno kombinovat servery SOCKS do kaskád, nebo jak se jim také říká „řetězce“. Je pozoruhodné, že všechny akce potřebné k tomu lze provádět na straně klienta. Jediným požadavkem na „články“ řetězce je, že si musí navzájem „důvěřovat“ (tj. umožnit navazování příchozích a odchozích spojení). Pokud servery SOCKS, které tvoří kaskádu, nejsou anonymní (to znamená, že používají Username/Password, CHAP nebo podobná autentizační schémata), je také nutné, aby uživatel mohl úspěšně dokončit autorizační proceduru na každém z nich.

Předpokládejme, že máme sadu N serverů SOCKS s názvem socks1, socks2, ..., socksN, splňující všechny výše uvedené požadavky. Poté může klient vytvořit kaskádu takto:

V případě odchozí TCP spojení: klient se připojí k socks1, projde autorizační procedurou (je-li to nutné) a odešle příkaz „CONNECT“ s uvedením socks2 jako doručovací adresy. Provedením tohoto požadavku si socks1 vytvoří nové spojení se socks2 a všechny jím procházející informace budou pravidelně přenášet klientovi, přičemž socks2 ani neuhádnou, s kým to vlastně komunikuje. Postup se pak opakuje, dokud není vytvořeno spojení mezi ponožkami (N-1) a ponožkamiN. Poslední server v kaskádě se připojuje přímo k uzlu, který klienta zajímá. Přenos dat probíhá v normální režim: Klient odešle paket na server socks1, který jej následně odešle na server socks2, ... a tak dále, dokud není dosažen koncový uzel.

V případě odchozí připojení UDP: klient se připojí k socks1, projde autorizační procedurou a následně odešle dva příkazy: „CONNECT“ (adresa dodání - socks2) a „UDP ASSOCIATE“. Tím se vytvoří dvě nová připojení: virtuální kanál UDP mezi klientem a socks1 a relace TCP mezi socks1 a socks2.

Pomocí této TCP relace klient (v zastoupení socks1) odešle příkaz „UDP ASSOCIATE“ na server socks2 (otevře UDP kanál mezi socks1 a socks2) a „CONNECT“ na server socks3.Procedura pokračuje, dokud nejsou vytvořeny virtuální kanály UDP mezi všemi servery SOCKS v kaskádě. Pro odeslání jakýchkoli dat klient nejprve provede N-násobné zapouzdření UDP datagramu, přičemž jako doručovací adresu zadá postupně socks1, socks2, socks3, socksN a adresu skutečného příjemce a poté je odešle na server socks1. Všimněte si, že v praxi je tato kaskádová možnost extrémně vzácná. Je to proto, že servery SOCKS, stejně jako firewally NAT, mohou změnit zdrojový port datagramu, což povede k problémům podrobně popsaným v části „Navázání odchozího připojení UDP“. Pomocí řetězců SOCKS serverů, které nevyžadují autentizaci, může klient výrazně zvýšit anonymitu práce na internetu (viz epigraf). Na internetu můžete najít mnoho programů, které implementují zde popsaná schémata. Jedná se například o SocksChain ( http://www.ufasoft.com/socks/) pro Windows nebo ProxyChains ( ).

) pro Unix. Kaskádové servery SOCKS jsou také nedílnou součástí některých soxifikátorů, zejména FreeCap (

Nyní, když jsou nám principy fungování serveru SOCKS dobře známé, je čas přejít od teorie k praxi. Na světě existuje velké množství programů, které implementují protokol SOCKS5. Pokrývají všechny oblíbené operační systémy(Unix, Windows, ...) a způsoby distribuce (freeware, shareware, open-source atd.). Zde stručně zvážíme nejznámější (nebo nejzajímavější z pohledu autora) implementace.

Začněme referenční implementací SOCKS5 (http://www.socks.permeo.com/), kterou vyrobila společnost NEC a v současnosti ji vlastní Permeo. Aktuální verze má číslo 1.0r11 a pochází ze srpna 2000. Jak již z názvu snadno uhodnete, tento server je referenční implementací protokolu a obecně řečeno není určen pro průmyslové použití. Z důvodů, které mi nejsou příliš jasné, však byla zařazena do portů FreeBSD, a proto je na této platformě de facto standardem. Produkt má podporu GSSAPI a je distribuován ve zdrojovém kódu, ale pod proprietární licencí. Komerční použití tohoto serveru je zakázáno.

Dante, vyvinutý norskou společností Inferno Nettverk, je oblíbený zejména mezi příznivci Linuxu. Produkt se vyvíjí, i když ne příliš rychle (poslední verze 1.1.15 je z 31. ledna 2005) a je docela vhodný pro praktické použití. Jak již bylo zmíněno, Dante umožňuje UDP asociacím pracovat správně, i když procházejí NAT Firewallem. Program je šířen ve zdrojovém kódu pod licencí BSD. Dante obsahuje knihovnu pro transparentní koxifikaci unixových aplikací (viz níže)

Před časem jsem chtěl zkusit implementovat proxy server pro vlastní potřebu a takový, který by se dal použít i v budoucnu a také aby jeho velikost byla minimální. Přirozenou možností pro mě byla implementace pomocí assembleru. Program se ukázal jako malý, pohodlný a v budoucnu jsem ho používal velmi často. Ale nyní, po letech, bych rád ukázal nejjednodušší implementaci jednoho protokolu, SOCKS4. Tento protokol byl vytvořen tak, aby klienti nacházející se v místní síť za firewallem mohl přistupovat k vnější síti. Zároveň je v tomto případě možné kontrolovat požadavky klientů :) Úplně první věc, kterou při implementaci potřebujete, je přečíst si dokumentaci popisující tento protokol, protože chceme, aby našemu protokolu rozuměli standardní programy bez „broušení pilníkem“. Takže dokumentace:

Nyní, vyzbrojeni popisem, můžeme začít. Úkolem proxy serveru je přijmout požadavek od klienta v určitém formátu, vygenerovat soket a připojit jej na adresu požadovanou klientem a poté zajistit výměnu dat mezi dvěma sokety, dokud je server neuzavře. nebo klient. Začněme implementací.

Makra a datové struktury používané v programu

Pojďme vytvořit soubor include, include.inc. V tento soubor ty standardní umístíme na psaní Windows programy makra + struktury pro práci s SOCKS4. Zde nebudu uvádět všechna makra, uvedu pouze popis a funkčnost nezbytnou k vyřešení hlavního problému, vše ostatní najdete v přiloženém souboru s zdrojové kódy.
; SOCKS4 – Struktura použitá klientem při požadavku na připojení; na zadaný server(DSTIP)/port(DSTPORT) CONNECT_SOCK4 Struc VN Db ?

CD Db?
DSTPORT Dw?
DSTIP Dd? NULL Db? CONNECT_SOCK4 Končí ; SOCKS4 - odpověď proxy serveru o připojení. RESPONSE_SOCK4 Struc VN Db ? CD Db?
DSTPORT Dw?
DSTIP Dd? RESPONSE_SOCK4 Končí

Celkově se struktury CONNECT_SOCK4 a RESPONSE_SOCK4 neliší, protože implementujeme protokol bez oprávnění. Rozhodl jsem se je ale nechat samostatně, abych je v budoucnu mohl snadno obměnit pro vylepšení. V samotných strukturách je v proměnné VN uvedena verze protokolu v našem případě by měla být vždy 4, v případě SOCKS5 tato proměnná obsahuje 5 (protokol je v zásadě podobný). Proměnná CD se používá k vrácení výsledku požadavku proxy serveru klientovi na adresu požadovanou klientem (90 - připojení úspěšné / 91 - připojení selhalo).

; Hlavní procedura je spouštěcí procedura pro WinMain program Proc LOCAL ThreadId, hServSock:DWORD LOCAL hostname :BYTE LOCAL _wsa:WSADATA LOCAL _our:sockaddr_in ; Při spuštění knihovny pro práci se sockety využíváme funkcionalitu verze 1.1, ; vyžádejme si to jako minimum vyvolejte WSAStartup, 0101h, ADDR _wsa .if eax == 0 ; Vezmeme naši adresu, připravíme strukturu pro inicializaci serverového soketu invoke gethostname, ADDR hostname, 256 invoke gethostbyname, ADDR hostname .if eax == 0 invoke inet_addr, ADDR hostname .else mov eax, mov eax, mov eax, .endif mov _our. sin_addr, eax vyvolat inet_ntoa, eax mov _our.sin_family, AF_INET mov _our.sin_addr.S_un.S_addr, INADDR_ANY xor eax, eax ; Zadejte port, na kterém chceme poslouchat příchozí zprávy mov axe, SOCKS_PORT invoke htons, eax mov _our.sin_port, axe invoke socket, AF_INET, SOCK_STREAM, 0 .if eax != INVALID_SOCKET ; Uložte vytvořený serverový soket mov hServSock, eax ; Navážeme serverový soket na naši adresu a požadovanou vazbu vyvolání portu, hServSock, ADDR _our, SIZEOF sockaddr_in .if eax != SOCKET_ERROR @@: ; Inicializovat soket pro čekání invoke listen, hServSock, SOMAXCONN .repeat ; Přišel klient, obdržíme soket s příchozím klientem invoke accept, hServSock, NULL, NULL .until eax != INVALID_SOCKET ; Vytvořte vlákno, ve kterém bude zpracován aktuální klient xchg eax, ebx invoke CreateThread, NULL, NULL, ADDR socketThread, ebx, NULL, ADDR ThreadId ; Necháme čekat na klienty jmp @B .endif .endif invoke closesocket, hServSock .endif invoke ExitProcess, 0 WinMain Endp
Toto je náš první postup, snažil jsem se kód co nejvíce okomentovat, abyste mu rozuměli, ale pokud by vám stále nebylo něco jasné, kontaktujte mě nebo MSDN. V podstatě veškerý kód je napsán pomocí syntaxe MASM a WinAPI. Výsledkem výše uvedené funkce by měl být funkční soket na jedné ze síťových adres vašeho stroje (lokální adresa, nebo externí adresa, pokud máte skutečnou IP) + na základě klientského připojení funkce vytvoří samostatné vlákno sloužící k práci s příchozím klientem. Teď pojďme dál...

Druhá fáze, analýza požadavku klienta

Ve druhém kroku je potřeba pouze přijmout strukturu CONNECT_SOCK4, vytvořit soket, pokusit se jej připojit a odeslat klientovi odpověď. Implementace:

SocketThread Proc sock:DWORD LOCAL lpMem, _csock, ThreadId, dAmount:DWORD LOCAL Remote:sockaddr_in LOCAL wrFds, rdFds:fd_set LOCAL hResp:RESPONSE_SOCK4 ; Příprava na čtení dat ze soketu invoke FdZero, ADDR rdFds invoke FdSet, sock, ADDR rdFds invoke select, NULL, ADDR rdFds, NULL, NULL, NULL ; Získáme velikost dat čekajících na přečtení invoke ioctlsocket, sock, FIONREAD, ADDR dAmount ; Vyhrazujeme paměť pro data mov lpMem, @Result(LocalAlloc, LMEM_FIXED nebo LMEM_ZEROINIT, dAmount) ; Přečíst data požadavku ze soketu invoke recv, sock, lpMem, dAmount, 0 ; Žádost přišla lea edi, hResp mov esi, lpMem ; Esi obsahuje požadavek uživatele. Zpracováváme (zde) pouze verzi SOCKS4, ; SOCKS5 lze v zásadě zpracovat zde, ale to přijde později... Předpokládejme Esi: Ptr CONNECT_SOCK4 Předpokládejme Edi: Ptr RESPONSE_SOCK4 .if .VN == 4 ; Implementace protokolu SOX 4 .if .CD == 1 invoke socket, AF_INET, SOCK_STREAM, 0 .if eax != INVALID_SOCKET mov _csock, eax ; Bereme data vzdálený hostitel, se kterým chce klient propojit mov Remote.sin_family, AF_INET mov ax, .DSTPORT mov Remote.sin_port, ax mov eax, .DSTIP mov Remote.sin_addr, eax mov cx, .DSTPORT mov edx, .DSTIP Edi obsahuje odpověď uživateli mov .VN, 0 mov .DSTPORT, cx mov .DSTIP, edx ; Snažíme se spojit s vzdálený server invoke connect, _csock, ADDR Remote, SIZEOF Remote .if !eax ; Připravujeme odpověď, že jsme připojili mov .CD, 90 ; Klientovi zašleme odpověď obsahující výsledek pokusu o připojení invoke send, sock, ADDR hResp, SIZEOF RESPONSE_SOCK4, 0 ; Tvoříme strukturu s informacemi o serveru a; připojené klientské zásuvky; - serverem zde myslím soket připojený ke klientovi; kdo žádost odeslal; - klientem rozumím socket připojený k serveru; jehož data si klient vyžádal mov ebx, @Result(LocalAlloc, LMEM_FIXED nebo LMEM_ZEROINIT, SIZEOF THREAD_DATA) Předpokládejme, že Ebx: Ptr THREAD_DATA mov eax, _csock mov .Server, eax soClaxientsumeax Spustíme vlákno zpracování soketu (čtení z klienta a přenos do soketu serveru) zavoláme CreateThread, NULL, NULL, ADDR ClientSock, ebx, NULL, ADDR ThreadId .else ; Pokud se připojení nezdaří, zavřete klientský soket invoke closesocket, _csock ; Říkáme, že došlo k chybě připojení mov, 91; Klientovi zašleme odpověď obsahující výsledek pokusu o připojení vyvolat send, sock, ADDR hResp, SIZEOF RESPONSE_SOCK4, 0 .endif .endif .endif .endif Předpokládejme Edi: Nic Předpokládejme Esi: Nic ; Uvolnění paměti přidělené pro požadavek vyvolá LocalFree, lpMem ret socketThread Endp
Výsledkem tohoto postupu je připojený soket a také vytvořené vlákno, které implementuje výměnu dat mezi dvěma sokety. Je to jednoduché. Stačí jen objasnit, že se zde používá několik adresovacích bodů ve strukturách, které byly zavedeny do MASM, aby programátorovi usnadnili život. První bod, makro „Předpokládej“.
Řádek Assume Esi: Ptr CONNECT_SOCK4 říká kompilátoru, že tento registr (Esi) obsahuje adresu struktury CONNECT_SOCK4, což dále zjednodušuje přístup k proměnným v této struktuře. Předpokládejme, že Esi: Nic nezruší vazbu. Pro lepší pochopení může být jednodušší, když uvedu několik možností adresování:
Předpokládejme Esi:Ptr CONNECT_SOCK4 mov al, .VN ; Do AL umístíme hodnotu bytu z proměnné VN struktury mov al, .CD ; Umístěte variabilní CD mov axe do AL. .DSTPORT ; Umístěte proměnnou DSTPORT do AX Assume Esi:Nothing
nebo
mov al, ; Umístěte hodnotu bajtu z proměnné VN do AL mov al, ; Umístěte proměnnou CD mov axe, ; Umístěte proměnnou DSTPORT do AX
nebo
mov al, byte ptr ; Umístěte proměnnou VN do AL mov al, byte ptr ; Umístěte proměnnou CD do AL mov axe, slovo ptr ; Umístěte proměnnou DSTPORT do AX

Myslím, že je vám jasné, stejně jako mně, že je rychlejší, pohodlnější a přehlednější použít první možnost. I když je nutné odkazovat na jednu proměnnou struktury, druhá možnost má právo existovat. Myslím, že je lepší použít třetí možnost v případech, kdy data na adrese nejsou strukturovaná. Ale jak víte, každý tambovský vlk má svou vlastní chuť a barvu. Použijte metodu, která je pro vás nejpohodlnější.
Ještě jeden bod, který stojí za to objasnit. Výsledek makra. Toto makro bylo napsáno proto, abyste mohli volat funkci WinAPI na jednom řádku a zapisovat výsledek provedení do registru nebo paměti. Takže řádek:
mov lpMem, @Result(LocalAlloc, LMEM_FIXED nebo LMEM_ZEROINIT, dAmount)
Nejprve zavoláte takto:
vyvolat LocalAlloc, LMEM_FIXED nebo LMEM_ZEROINIT, dAmount
a po provedení tento hovor výsledek provedení (Eax) je uložen v proměnné lpMem. V tomto konkrétním případě dojde k alokaci paměti a do proměnné se zapíše adresa, na které se nám přidělená oblast nachází.

Třetí fáze, přenos dat

Dvě nejtěžší etapy jsou tedy za námi. Klient dorazil, připojili jsme ho ke vzdálenému serveru a nastal čas na nejjednodušší „opičí“ práci. Přenos dat mezi dvěma zásuvkami. Udělejme to rychle a snadno:
; Proud čtení z klientského soketu a jeho odeslání do serverového soketu.... ClientSock Proc Param:DWORD LOCAL server, sclient:DWORD LOCAL rdFds:fd_set LOCAL dAmount, lpBuf: DWORD ; V Paramu máme informace o serverových a klientských soketech; přenos do lokálních proměnných mov ebx, Param Předpokládejme Ebx: Ptr THREAD_DATA mov eax, .Server mov server, eax mov eax, .Klient mov sclient, eax Předpokládejme Ebx: Nic ; Nezapomeňte uvolnit paměť invoke LocalFree, Param @@: invoke FdZero, ADDR rdFds invoke FdSet, sserver, ADDR rdFds invoke FdSet, sclient, ADDR rdFds invoke select, NULL, ADDR rdFds, NULL, NULL, NULL; Zkontrolujte, zda existují data ke čtení.if eax == SOCKET_ERROR || eax == 0 ; Žádná data - exit jmp @F .endif ; Existují data ze serveru, která je třeba předat klientovi? vyvolat FdIsSet, server, ADDR rdFds .if eax ; Získáme velikost dat čekajících na přečtení invoke ioctlsocket, server, FIONREAD, ADDR dAmount ; Rezervovat paměť pro data mov lpBuf, @Result(LocalAlloc, LMEM_FIXED nebo LMEM_ZEROINIT, dAmount) vyvolat recv, server, lpBuf, dAmount, 0 .if eax == SOCKET_ERROR || eax == 0 jmp @F .endif invoke send, sclient, lpBuf, eax, 0 invoke LocalFree, lpBuf .endif ; Existují data od klienta k odeslání? serverový soket
?
To je ono, hurá! Pojďme sestavit a vyzkoušet. V zásadě je nejlepší volbou FireFox. V nastavení připojení uvádíme, že potřebujeme použít proxy server SOCKS4. Uvádíme jeho adresu a port, na kterém se nachází. Poté uložíme nastavení a užijeme si internet, procházíme přes náš proxy, o velikosti 3,5 kB))) Ano, vysvětlím. Pro kompilaci je nutné mít nainstalovaný balíček

Při práci s proxy je velmi důležité si vybrat správný typ proxy pro vaše úkoly, abyste se vyhnuli možným problémům a dosáhli svých cílů. Nejčastěji používané jsou HTTP proxy a Socks5 proxy. Rozdíly mezi nimi spočívají v míře anonymity, použitém protokolu, použitém způsobu přenosu dat při práci jako proxy a také v některých doplňkové funkce. Podívejme se na každý typ proxy zvlášť.

Vlastnosti HTTP proxy

Začněme s HTTP proxy. Při své práci využívají protokol HTTP, který je určen pro návštěvu stránek, stahování a přenos souborů a při práci s některými programy, které tento protokol využívají, se připojují přes proxy. Požadavky při práci s HTTP proxy servery nejsou odesílány přímo, ale používají proxy server jako prostředníka, který odesílá požadavky jeho jménem.

Také v protokolu HTTP proxy je k dispozici cachování, které urychluje načítání stránek pomocí uložených souborů, dále sledování a filtrování síťového provozu, nastavování rychlostních limitů, blokování nežádoucích zdrojů, shromažďování statistik ukládáním protokolů atd.

Proxy tohoto protokolu se liší stupněm anonymity. Vynikají následující: Typy HTTP Anonymní proxy:

Transparentní proxy, které nemaskují skutečnou IP adresu a také nezakrývají skutečnost, že pro přístup ke zdroji se používá proxy server. Takové proxy se používají zřídka, hlavně k přesměrování uživatele na jiný proxy server,

Anonymní proxy. Přenášejí informace o použití proxy serverů, avšak vaše IP adresa je maskována a nahrazena jinou IP adresou, což poskytuje spolehlivou úroveň zabezpečení.

Elitní proxy. Skrývají použití proxy a také spolehlivě maskují IP adresu, díky čemuž jsou nejbezpečnější mezi HTTP proxy. Server, ke kterému se pokoušíte přistupovat, bude předpokládat, že vaše připojení je přímé, bez použití proxy serveru.

Měli bychom také zdůraznit HTTPS proxy, které používají protokol SSL. Jsou podtypem protokolu HTTP, který používá zabezpečené připojení. Síťový provoz přenášený těmito proxy je bezpečně šifrován, což zaručuje nejvyšší úroveň anonymita. Zpravidla se takové proxy používají k zajištění bezpečnosti bankovních sítí, v komerčních organizacích k vytvoření bezpečných podnikových sítí a v dalších spojeních vyžadujících zabezpečení. Ostatní vlastnosti jsou stejné jako u protokolu HTTP.

Vlastnosti proxy Socks5

Další mezi uživateli oblíbený protokol je Socks5. Proxy servery pracující s tímto protokolem jsou zpočátku anonymní, protože to umožňují síťový provoz ve své čisté podobě, bez odhalení HTTP hlaviček. Server, ke kterému se pokoušíte přistupovat, proto nebude vědět, že používáte proxy server, ani neobdrží vaši IP adresu.

Socks5 proxy, podporuje následující síťových protokolů: HTTP, HTTPS, FTP a jejich funkce: ukládání do mezipaměti, SSL připojení,ověření. Proxy protokolu Socks5 navíc využívají připojení UDP a TPC, což rozšiřuje rozsah jejich použití a činí z nich nejfunkčnější z moderních proxy serverů. Původně měl pracovat protokol Socks5 software. Z tohoto důvodu většina programů podporuje tento protokol pro připojení přes proxy. Proxy servery Socks5 mají také příjemnou funkci, která vám umožňuje vytvářet řetězce proxy serverů, což je užitečné pro řešení určitých problémů při práci na internetu.

Pokud porovnáte proxy HTTP a Socks5, je vhodnější použít druhé. Protože jsou anonymnější, podporují více funkcí a také pracovat se všemi weby a programy, které podporují připojení přes proxy. Naše webové stránky můžete navštívit zadáním objednávky ve svém osobním účtu.