Benvinguts al podcast 2x01 després de força temps sense publicar cap podcast començo una nova temporada la idea d'aquesta nova temporada és fer els podcasts monotematics, per tal d'arribar on m'interessa dels temes els podcasts aniran agrupats per tematiques forman series així doncs aquest podcast és el primer d'una serie dedicada a SOCKS5, en principi formada per 3 captiols tot i q podria arribar a allargar-se 2x01 - intro i teoria de socks (concretametn parlarem de socks5) 2x02 - intro i teoria de xep0065 - socks5 i xmpp 2x03 - recull d'eines que implementen socks5 dit això comencem definint q és socks socks5 SOCKS es una abreviación de "SOCKetS SOCKS es un protocolo de Internet que permite a las aplicaciones Cliente-servidor client -> accés internet, a través d'un firewall sovint s'usa NAT no control de qui surt més enllà dels filtres tb podrien usar serveis de proxy normalment els més coneguts els HTTP però si volem fer proxy d'una connexió TCP qualsevol, proxy socks el proxy controla qui pot accedir als servidors externs a la xarxa local i qui no tb es pot usar un proxy socks de forma inversa, és a dir per accedir a un servidor local des d'internet versió actual SOCKS5 -> RFC1928 principal diferentcia amb socks4 i socks4a -> autenticació, UDP, DNS al socks i IPv6 segons OSI -> entre la capa d'aplicació i la de transport resum de com funciona 1) el client es conecta i envia una salutació amb la llista de mètodes d'autenticació suportats 2) el servidor n'escull un (o envia una resposta d'error si no en suporta cap) 3) segons el metode d'autenticació s'intercanvien uns o altres tipus de missatges amb la finalitat d'identificar el client q vol accedir al proxy 4) un cop autenticat, el client envia una petició de connexió (on vol connectar d'itnernet) 5) el servidor negocia la connexió entre ell i on vol connectar-se el client 6) el servidor connecta el socket d'internet amb el socket del client i així el client parla amb el servidor d'internet, malgrat la IP q 'ataca' sempre és la del proxy el protocol és força petit i es poden comentar els seus paquest, no es comentaré tots de forma exaustiva però si las parts més rellevants per una connexió TCP 1) client connecta al servidor i envia una llista de métodes d'autenticació suportats recordar q es medeixen els camps per octets esquema 1. +----+----------+----------+ |VER | NMETHODS | METHODS | +----+----------+----------+ | 1 | 1 | 1 to 255 | +----+----------+----------+ campo 1: número de versión socks, debe ser 0x05 para esta versión campo 2: número de métodos de autenticación soportados, 1 byte campo 3: métodos de autenticación, longitud variable, 1-byte por método soportado métodes d'autenticació 0x00 - Sin autenticación 0x01 - GSSAPI - Generic Security Services Application Program Interface (wikipedia) 0x02 - Nombre de Usuario/Password 0x03..0x7F - métodos asignados por IANA 0x80..0xFE - métodos reservados para uso privado després comentarem el métode 0x02 (user/clau) recordar q SOCKS no implementa xifrat per si mateix sinó que com a molt el pot heredar d'SSL 2) respota del servidor, aquest selecció un métode de xifrat i respon un paquet tan simple q només té dos camps: esquema 2. +----+--------+ |VER | METHOD | +----+--------+ | 1 | 1 | +----+--------+ campo 1: versión socks, 1 byte, 0x05 para esta versión campo 2: método de autenticación escogida, 1 byte, o 0xFF cuando no sean ofrecidos métodos aceptables. 3) el procés d'autenticació ja depèn del mètode escollit, especificats en els corresponents RFC, per exemple: http://tools.ietf.org/html/rfc1929 - user/clau http://tools.ietf.org/html/rfc1961 - GSS-API, no és un mètode d'autenticació en si mateix sinó una interficie comuna que usen les llibreries de diversos mètodes d'autenticació 4) la petició de connexió del client té 6 camps: esquema 3. +----+-----+-------+------+----------+----------+ |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT | +----+-----+-------+------+----------+----------+ | 1 | 1 | X'00' | 1 | Variable | 2 | +----+-----+-------+------+----------+----------+ campo 1: número de versión socks, 1 byte, debe ser 0x05 para esta versión campo 2: código de comando, 1 byte:- 0x01 = establecer una conexión stream tcp/ip 0x02 = establecer un enlazado(binding) de puerto tcp/ip 0x03 = asociar un puerto udp campo 3: reservado, debe ser 0x00 campo 4: tipo de dirección, 1 byte:- 0x01 = dirección IP V4 (el campo de direcciones tiene una longitud de 4 bytes) 0x03 = Nombre de dominio (el campo dirección es variable) 0x04 = dirección IP V6 (el campo de direcciones tiene una longitud de 16 bytes) campo 5: dirección destino, 4/16 bytes o longitud de nombre 1+dominio. Si el tipo de dirección es 0x03 entonces la dirección consiste en un byte de longitud seguido del nombre de dominio. campo 6: número de puerto en el orden de bytes de la red, 2 bytes 5) resposta del servidor, 6 camps esquema 4. +----+-----+-------+------+----------+----------+ |VER | REP | RSV | ATYP | BND.ADDR | BND.PORT | +----+-----+-------+------+----------+----------+ | 1 | 1 | X'00' | 1 | Variable | 2 | +----+-----+-------+------+----------+----------+ campo 1: versión de protocolo socks, 1 byte, 0x05 para esta versión campo 2: estado, 1 byte:- 0x00 = petición concedida, 0x01 = fallo general, 0x02 = la conexión no se permitió por el conjunto de reglas(ruleset) 0x03 = red inalcanzable 0x04 = host inalcanzable 0x05 = conexión rechazada por el host destino 0x06 = TTL expirado 0x07 = comando no soportado/ error de protocolo 0x08 = tipo de dirección no soportado campo 3: reservado, 0x00 (1 byte) campo 4: tipo de dirección, 1 byte:- 0x01 = dirección IP V4 (el campo de direcciones tiene una longitud de 4 bytes) 0x03 = Nombre de dominio (el campo dirección es variable) 0x04 = dirección IP V6 (el campo de direcciones tiene una longitud de 16 bytes) campo 5: BND.ADDR: dirección destino, 4/16 bytes o longitud de nombre 1+dominio. Si el tipo de dirección es 0x03 entonces la dirección consiste en un byte de longitud seguido del nombre de dominio. campo 6: BND.PORT: número de puerto en el orden de bytes de la red, 2 bytes valor dels camps 5 i 6 segons si el paquet és una resposta de: CONNECT, BIND, UDP ASSOCIATE si és una resposta de CONNECT: BND.ADDR i BND.PORT (camps 5 i 6) tenen el valor de la IP/hostname i el port que el proxy ha usat per fer la connexió al destí que havia demanat el client si era una resposta a BIND: BIND s'usa quan volem que un servidor es connecti a un client, és a dir el client es connecta al proxy i publica el seu socket a l'espera que un servidor (o un altre client) es connectin a ell. Quan es rep una petició de BIND s'envien dues respostes una quan: * s'ha publicat el port, llavors BND.ADDR i BND.PORT tindran el valor de la IP/hostname i Port en que el firewall esta esperant a que el peer que esta internet s'han de connectar. Aquestes dades s'han de passar per un altre canal entre el client i el servidor, sovint pel que s'anomena un port de control, per exemple, FTP control port, SIP o XMPP. * l'altre resposta la tindran quan, la connexió per part del peer d'internet amb la IP:PORT publicats es completa o falla, en aquest cas la resposta generada pel servidor conté al camp 5 i 6, la IP i PORT que ha usat el peer d'internet per connectar-se. si era una resposta d'una UDP ASSOCIATE: UDP ASSOCIATE s'usa quan volem associar el tràfic UDP entre una màquina interna i un PEER d'internet. en la petició de connexió el client intern UDP indica a DST.ADDR:DST.PORT l'acdreça i port que usarà per fer la transacció UDP. El servidor socks usarà aquesta informació per limitar el pas de paquets UDP. Si el client inern encara no sap aquesta informació deixa DST.ADDR:DST.PORT ple de zeros. L'associació UDP acabarà quan la petició TCP que demanava l'associació UDP acabi. pel que fa al paquet de resposta BND.ADDR:BND.PORT (camps 5 i 6) contenen el HOST:PORT on han d'enviar els paquets UDP el client intern perquè arribin al destí que ell vol. SOCKS5 i UDP ASSOCIATE el client intern que vol enviar paquets UDP envia els seus paquets al BND.ADDR:BND.PORT indicats en la resposta, si el procés d'autenticació que s'ha usat requereix encapsulament per motius d'autenticitat, integritat i/o confidencialitat els paquets UDP hauran de portar l'encapsulament requerit. per altre banda, els paquets UDP generats en la seva part de dades contindran una nova capçalera que serà processada pel servidor PROXY: la capçalera té 6 camps: esquema 5. +-----+----+-----+------------------------+------+ | ... | IP | UDP | SOCKS5 UDP ASSOCIATION | DATA | +-----+----+-----+------------------------+------+ esquema 6. +----+------+------+----------+----------+----------+ |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | +----+------+------+----------+----------+----------+ | 2 | 1 | 1 | Variable | 2 | Variable | +----+------+------+----------+----------+----------+ The fields in the UDP request header are: o RSV Reserved X'0000' (2 octets) o FRAG Current fragment number (1 octet) o ATYP address type of following addresses: (1 octet) o IP V4 address: X'01' o DOMAINNAME: X'03' o IP V6 address: X'04' o DST.ADDR desired destination address (4, 16octets o indefinit) o DST.PORT desired destination port (2 octets) o DATA user data (n octets) quan es re-envien paquets UDP, com és propi del protocol UDP no s'informarà d'errors en l'arribada dels mateixo, és a dir que qualsevol problema que surgeixi en l'entrega o recepció dels mateixos s'ignorarà. gràcies al info d'aquesta capçalera el servidor socks no re-enviarà els paquets UDP que no provinguin del peer d'internet que requeria el client intern. és important notar que en la forma de la capçalera afegida trobem els caps de destí real dels paquets. el camp FRAG: indica si esta o no fragmentat el paquet, si és 0x00 no ho esta, valors entre 1 i 127 indiquen la posició del fragment. fixeu-vos que de l'octet només s'usen 7bit, per això el fragment màxim és 127 el bit que queda d'usa per indicar si és l'últim fragment. el servidor socks 5 té una 'REASSEMBLY QUEUE' i un 'REASSEMBLY TIMER', la cua es reinicialitzarà si el TIMER expira o si un datagrama UDP arriba amb el camp de FRAG amb un valor inferior al seu màxim. el TIMER ha de ser d'almenys 5 segons. el suport de fragmentació és opcional i quan no s'implementa simplement el que es fa és enviar tots els paquets amb el camp FRAG amb valor 0x00. comparativa entre SOCKS i HTTP Proxy * solucionen el mateix problema * SOCKS s'usa quan volem establir una connexió bytestream * HTTP Proxy pot fer el mateix a través del métode CONNECT * en ambdós casos es crea un socket TCP cap al proxy i el client no acaba sortint mai a internet, sinó que aquesta sempre es feina del proxy * això li permet tan amb un cas com en l'altre (socks vs http proxy): permetre, denegar, filtrar, limitar les peticions i connexions. * sovint els proxies HTTP només permeten GET/POST i tenen deshabilitat el mètode CONNECT * una cosa interessant que poden fer els proxies SOCKS és permetre tràfic UDP cosa que no poden fer els HTTP. * SOCKS necessita fer un handshacke especial per cada nou socket obert * HTTP proxy no li cal, ja que la negociació la pot portar implícita en les capçaleres HTTP, per tant, el handshacke pot ser implícit