descripción y análisis funcional del protocolo socks...

Universidad Nacional de LujánDepartamento de Ciencias Básicas

División Estadística y Sistemas

Descripción y Análisis Funcionaldel Protocolo SOCKS, Versión 5

Gabriel TolosaFernando Bordignon

Abril – 2001 La presente obra es propiedad intelectual del autor. Prohibida sureproducción parcial o total por cualquier medio, sin permiso por

escrito de su editor.

Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5

Indice

Primera Sección

Firewalls

Firewalls a nivel de red

Firewalls a nivel de aplicación

SOCKS versión 5

Operación bajo protocolo TCP

Servicio de retransmisión basados en UDP

Demonio y cliente

Bibliografía

Segunda Sección

Configuración de la red TCP/IP

Comandos de configuración de red

Configuración de Servicios de Aplicación

Conexión a Internet

Tercera Sección

Configuración de SOCKS5 sobre la red TCP/IP

Cuarta Sección

Análisis del intercambio de mensajes de losDistintos protocolos

Anexo I - Configuración de hosts y ruteadores

Anexo II - Detalle de las capturas realizadas


Primera Sección

Firewalls

Un firewall es un sistema que permite establecer una política decontrol de acceso entre dos redes, donde todo el tráfico desde elexterior al interior, y viceversa, debe necesariamente pasar por elsistema. El tráfico autorizado, que está definido en la política deseguridad de la organización, solamente pasará de una red a otra.

INTERNET

RED INTERNA

FIREWALL

��

Según un ejemplo presentado por Tanenbaum, un firewall funcionaanálogamente al viejo sistema de seguridad medieval consistentede un foso profundo alrededor de un castillo. Esto obligaba acualquiera que entrara o saliera del castillo a pasar por un solopuente levadizo, donde podría ser inspeccionado. En las redes, elcastillo representa la red interna de la organización (bien aproteger) mientras que el puente levadizo se corresponde alenlace con otras redes donde se implementan las políticas decontrol.

Funcionalmente un firewall actúa como elemento separador deredes (determina claramente la frontera entre la red de unaorganización y el mundo). Estructuralmente se lo puede ver comoun conjunto de componentes (ruteadores, computadoras ysoftware apropiado), donde las configuraciones posibles variarándependiendo de las políticas de seguridad, del presupuesto y delas características de la red a proteger.

Firewalls a nivel de red

Este tipo de firewalls se basan en el filtrado de paquetes. Estatécnica consiste en el análisis de los valores de ciertos campos decabecera de protocolo, a los efectos de confrontar con reglaspredeterminadas que dictan la validez o no de dicho paquete. Losfiltros de paquetes generalmente son manejados por tablasconfiguradas por el administrador de la red. En dichas tablas selistan los orígenes y destinos aceptables, los orígenes y destinosbloqueados (entiéndase cualquier combinación de dirección yservicio), protocolos permitidos o denegados, y las reglaspredeterminadas a tomar con paquetes que llegan, de, o salen aotras máquinas. En definitiva estas tablas y reglas son laimplementación directa de las políticas de seguridad de todaorganización.

A continuación se muestra un ejemplo de una posible tabla dereglas de filtrado:

Regla Direcciónorigen

DirecciónDestino

Protocolo PuertoFuente

PuertoDestino

Acción

A Cualquiera Cualquiera Cualquiera Cualquiera Cualquiera ProhibirB Externa w.x.y.z TCP >1023 80 PermitirC w.x.y.z Cualquiera TCP 80 >1023 PermitirD Cualquiera Cualquiera ICMP Permitir

La regla A define una postura de negación preestablecida, dondelo que no está permitido expresamente (por las reglas siguientes)se considera prohibido. La regla B deja pasar cualquier solicitud deservicio proveniente del exterior, dirigida al host cuya dirección esw.x.y.z en el puerto 80 (típicamente HTTP). La regla C habilitaque las respuestas del servidor HTTP puedan llegar a destino(complementa a la regla B). La regla D permite mensajes ICMP(de cualquier tipo) circular en ambos sentidos.

Firewalls a nivel de aplicación

Las pasarelas de aplicación operan sobre el contenido de cadamensaje entrante ó saliente. Para cada uno, la pasarela decide (enbase a reglas predeterminadas) si debe transmitirlo o descartarlo,basándose en datos propios del protocolo de aplicación.

Estos funcionan como sistemas intermediarios entre un cliente dela organización y un servidor externo a la misma. El cliente entablauna comunicación con el sistema intermedio, éste evalúa lasolicitud y, de ser pertinente, establece una segunda comunicación


con el servidor externo. De ahí en más el equipo intermediariotransmite las solicitudes del cliente al servidor y las respuestas deéste al cliente. Funcionalidades extras pueden agregarse a estemodelo, como ser: comunicaciones encriptadas entre el cliente y elequipo intermediario, autenticación de clientes, permisos deacceso basados en horarios, lugares, contenidos, etc.

Otro aspecto importante de este tipo servicios es la posibilidad deesconder totalmente una red, dado que para el exterior solamenteexiste el equipo que actúa como intermediario de lascomunicaciones, por lo cual la red interna podría operar con unesquema de direcciones privadas.

Este tipo de servicios son efectivos solo cuando se emplean juntocon un mecanismo que restringe las comunicaciones directasentre equipos internos y externos.

SOCKS versión 5

SOCKS provee un mecanismo de proxy, creando un circuito entreel cliente y el servidor de aplicación, sin interpretar el protocolosuperior. Este sistema es una categoría de firewall, dado quepermite implementar medidas de protección de redes. El protocoloestá descripto en el documento RFC 1928, fechado en marzo de1996.

SOCKS brinda un marco en aplicaciones cliente/servidor parautilizar servicios de una red de manera conveniente y segura endominios de protocolos de transporte UDP y TCP. Habilita opermite que hosts de un lado del servidor SOCKS tengan acceso ahosts del otro lado del servidor, sin requerir alcance a nivel IP enforma directa. Esto trabaja redireccionando pedidos de conexiónde hosts de uno de los lados a hosts situados del otro lado delservidor SOCKS, el cual autentifica y autoriza los requerimientos,establece una conexión proxy y pasa los datos en ambos sentidos.

Servidor deAplicación

Cliente deAplicación/SOCKS

TCP

Conexión TCP

Conexión SOCKS

ServidorSOCKS

Borde de la red

Arquitectura SOCKS

Su antecesor SOCKS versión 4 provee conexiones inseguras paraaplicaciones cliente servidor basadas en TCP (telnet, FTP, HTTP,etc.). SOCKS versión 5 incorpora fuertes esquemas deautenticación, incluye soporte para protocolo UDP y extiende elesquema de direccionamiento para abarcar nombres de dominio ydirecciones IP versión 6.

El siguiente esquema muestra el modelo de control de flujo enSOCKS, quedando claramente detallada la funcionalidad agregadapor la versión 5 sobre la 4.


Cliente deAplicación

Envio de métodosde autenticación

Verif. métodoautenticación

Proceso deautenticación

Requerimiento dereenvio

Chequeo de estadodel requerimiento

Protocolo deaplicación

Servidor SOCKS

Chequeo depolíticas

Selección y envíode método elegido

Proceso deautenticación

Procesamiento desolicitud

Establecimiento deconexión

Envío de estado

Reenvío de datos

Conexión aceptada

Protocolo deaplicación

Servidor deAplicación

SOCKSV4

SOCKSV5

Operación bajo protocolo TCP

Cuando un cliente TCP quiere establecer una conexión con unaaplicación que solamente es alcanzable a través del firewall, debeabrir una conexión con el servidor SOCKS (típicamente utiliza elpuerto bien conocido 1080). Si el pedido de conexión es exitoso senegocia un método de autenticación a utilizar. A continuación, seautentifica con el método seleccionado y en caso de validarse elcliente, éste envía una solicitud de relay (mensaje request). Porotro lado el servidor SOCKS evalúa la petición y procede o no. Apartir de este punto el servidor SOCKS se conecta al servidor deaplicación en representación del cliente, procediendo a mantenerdos conexiones por medio de la técnica de relevamiento,interceptando cada segmento de datos provenientes del cliente ydel servidor, y reenviándolos a la otra conexión. (Para el servidorde aplicación el cliente es el servidor SOCKS, lo que demuestra elgrado de enmascaramiento alcanzado con esta técnica).

Etapas de una conexión SOCKS

a) Etapa de autenticación

Solicitud de método: El cliente envía un mensajeanunciando su versión de protocolo y una lista de métodosde autenticación soportados.

Estructura del mensaje

Versión SOCKS(1 byte)

Nro. de métodos(1 byte)

Códigos de métodos(de 1 a 255 bytes)

Códigos de métodos

00 Sin autenticación requerida01 Autenticación GSSAPI (RFC 1961)02 Username/Password (RFC 1929)03-7F Asignados a IANA80-FE ReservadosFF Ningún método aceptado.

Respuesta a solicitud: El servidor selecciona uno de losmétodos ofrecidos y envía un mensaje informándole.

Ejemplo

05 01 00

Utilizando la versión 5 de SOCKS (05), el clienteinforma al servidor que tiene un solo método (01)de autenticación, y corresponde a “ sinautenticación requerida” (00).


Versión SOCKS(1 byte)

Código de método(1 byte)

El código de método seleccionado secorresponde a la tabla de solicitud de método

Ejemplo

05 00


El servidor utilizando la versión 5 SOCKS (05)informa al cliente el método elegido (00).

A partir de aquí se requiere una subnegociación deautenticación específica del método anteriormenteseleccionado. Finalizada la misma de manera exitosa elcliente procede con la etapa siguiente.

b) Etapa de solicitud (request/reply)

Solicitud (request): El cliente envía un mensajesolicitando comunicación con un servidor de aplicación (Siel método seleccionado en la etapa anterior incluyeencapsulamiento por cuestiones de seguridad, estasolicitud será encapsulada según especificaciones).


VersiónSOCKS(1 byte)

Comando(1 byte)

Reser-vado(1 byte)

Tipo deDirección(1 byte)

DirecciónDestino(variable)

PuertoDestino(2 bytes)

Códigos de comandos

01 connect02 bind03 UDP associate

Código de tipo de dirección

01 IPV402 Nombre de dominio

(mnemónico)03 IPV6

Ejemplo

05 01 00 01 81 32 04 02 00 50

Utilizando la versión de protocolo 5 (05) se envíaun mensaje de connect (01) (el siguiente campocon valor 00 está reservado), con un formato dedireccionamiento IPV4 (01) al host 129.50.4.2 (8132 04 02) al puerto 80 (00 50)

Respuesta (reply): Luego que el servidor SOCKS intentaestablecer una conexión con el servidor de aplicación,

indicado por el cliente en el mensaje de solicitud, ybasándose en su éxito o fracaso, retorna al cliente unmensaje de respuesta.


VersiónSOCKS(1 byte)

Respuesta(1 byte)

Reser-vado(1 byte)

Tipo deDirección(1 byte)

Direcciónde salidadel servidorSOCKS(variable)

Puertode salidadel servidorSOCKS(2 bytes)

Códigos de respuesta

00 Éxito01 Falla general del servidor SOCKS02 Conexión no permitida por reglas03 Red no alcanzable04 Host no alcanzable05 Conexión rechazada06 TTL expirado07 Comando no soportado08 Tipo de dirección no soportada09-FF No asignado

Ejemplo

05 00 00 01 81 32 04 01 04 0E

El servidor SOCKS, operando con versión 5 (05),informa del éxito (00) de la solicitud de aperturade conexión con el servidor de aplicación. Luegosigue el campo reservado (00). A continuacióninforma que se ha conectado a la dirección tipoIPV4 (01) 129.50.4.1 (81 32 04 01), puerto 1038(04 0E).

Nota: A partir de este momento el servidor SOCKS tomará lossegmentos provenientes del cliente ó del servidor de aplicación ylos reenviará según corresponda, sin agregar informaciónadicional. No existe etapa de cierre a nivel de protocolo SOCKS.La finalización de las conexiones SOCKS ocurre a demanda de lasentidades intervinientes en la aplicación.

El comando bind en un mensaje de solicitud de servicio, se usapara protocolos que requieren que el cliente acepte conexiones


entrantes desde el servidor de aplicación. FTP es un ejemplo,dado que de forma normal, el cliente debe abrir una conexión enmodo pasivo cuando requiere una transferencia de datos.

Si la interacción entre cliente y servidor de aplicación requiere queel cliente acepte conexiones entrantes, se lo indicará al servidorSOCKS a través una conexión secundaria mediante un comandobind (en dicho mensaje informa la dirección y número de puertodonde espera en modo pasivo). El servidor SOCKS deberáhabilitar una conexión en modo pasivo para atender al servidor deaplicación. En caso de éxito informará al cliente la dirección ypuerto que habilitó para dicha tarea (si fracasó también informará).El cliente, a través de la conexión primaria, indicará al servidor deaplicación la dirección y número de puerto donde aceptará laconexión entrante (que en realidad corresponde al servidorSOCKS). Cuando el servidor SOCKS detecte que el servidor deaplicación se conectó, enviará al cliente de aplicación un segundomensaje (por la conexión secundaria) informando esta situación. Apartir de este momento por la técnica de relevamiento (relay) elservidor SOCKS manejará el intercambio de datos de la conexiónentrante.

Nota: Cuando un mensaje de respuesta indica una condición deerror (código distinto de 00), el servidor SOCKS debe terminar laconexión luego de enviar dicha respuesta.

Servicios de retransmisión basados en UDP

Un cliente basado en UDP envía sus datagramas de transporte alservidor SOCKS. El cliente UDP utiliza una conexión TCP con elservidor SOCKS, que es iniciada cuando una aplicación realiza laprimera llamada a la función sendto(). Por dicha conexión seenviará un comando solicitando servicio de retransmisión eindicando dirección de respuestas. El servidor SOCKS informaráal cliente donde debe dirigirle dichos mensajes. A medida quelleguen serán retransmitidos al servidor de aplicación. En caso deque el servidor SOCKS reciba respuestas del servidor deaplicación, las retransmitirá al cliente al puerto indicado en elmensaje de solicitud de servicio.

Una sesión de requerimiento de transporte UDP puedeejemplificarse de la siguiente forma:

Un cliente C necesita enviar un mensaje UDP a unservidor de aplicación SA, a través de un servidor SOCKSS.

A establece una conexión TCP (puerto del servidorSOCKS) con S, enviando un mensaje tipoUDP_ASSOCIATE. Como se ve en el siguiente ejemplo

05 03 00 01 00 00 00 00 04 63

Utilizando la versión 5 del protocolo SOCKS (05),C solicita un servicio de transporte UDP (03,UDP_ASSOCIATE). El siguiente campo (00) esreservado. A continuación informa que ladirección de respuesta (para UDP replies) en C estipo IPV4 (01), no especificada (00 00 00 00),puerto 1123 (04 63).

El servidor S contesta al mensaje anterior de la siguienteforma:

05 00 00 01 81 32 03 01 04 02

Utilizando la versión 5 del protocolo SOCKS (05),S informa que la petición ha sido exitosa (00). Elsiguiente campo (00) es reservado. La dirección ala cual C debe remitir su mensaje UDP es tipoIPV4 (01), IP 129.50.3.1 (81 32 03 01), puerto1026 (04 02).

C envía un mensaje UDP a S al puerto 1026 con lasiguiente conformación:

00 00 00 01 81 32 04 02 00 25 Datos_Aplicación

Los primeros dos bytes (00 00) están reservados.El byte siguiente indica número de fragmento(00). La dirección a la cual S debe retransmitir elmensaje UDP (Datos_Aplicación) es tipo IPV4(01), IP 129.50.4.2 (81 32 04 02), puerto 37 (0025).

S retransmite en un nuevo mensaje UDP los datos deaplicación y esperará por respuesta (si la hubiera) en unpuerto UDP que habilitará para tal fin. En caso de que lahubiera retransmitirá el mensaje UDP a C, según la


información proporcionada con el comandoUDP_ASSOCIATE.

Demonio y Cliente

En la sección 3 de este documento se desarrolla laimplementación SOCKS de la empresa NEC, describiendocaracterísticas y configuración de un servidor y cliente SOCKSversión 5.

Bibliografía de la primera sección

Tanenbaum, A. “Redes de Computadoras” . 3ra edición. PrenticeHall. 1997.

Chapman, D & Zwicky E. “Construya Firewalls para Internet” . 1raedición. Mc Graw Hill & O´Reilly. 1997.

RFC 1928. SOCKS Versión 5

Pagina de NEC www. SOCKS.nec.com

RFC 1929. Username/Password Authentication for SOCKS V5

RFC 1961. GSS-API Authentication Method for SOCKS Version-5


Segunda Sección

Configuración de la Red TCP/IP

En esta sección se describe la configuración de una interredbasada en la pila de protocolos TCP/IP. A nivel de enlace setrabajará con dos tecnologías, a saber: vínculos seriales (sobredos redes) bajo protocolo SLIP y protocolo Ethernet en 5 redes.Seis de las redes poseen hosts conectados, mientras que laséptima funciona como una red de interconexión (tipo backbone, ala que podría asociarse una tecnología tipo Fast Ethernet).

El direccionamiento del nivel de red se realiza a través de ladivisión de la dirección clase B 129.50.0.0 mediante la técnica desubnetting, resultando:

NúmeroDe Red

Nombre Direcciónde Red

Máscarade Red

1 Bsas 129.50.1.0 255.255.255.02 Argentina 129.50.2.0 255.255.255.03 Lapampa 129.50.3.0 255.255.255.04 Rionegro 129.50.4.0 255.255.255.05 Corboba 129.50.5.0 255.255.255.06 Neuquen 129.50.6.64 255.255.255.2527 mendoza 129.50.6.128 255.255.255.252

La siguiente tabla muestra los ruteadores (implementados comoPC-routers, bajo Sistema Operativo Linux, distribución Slackware,Kernel 2.2.15) y las redes que vinculan físicamente

Nombre 1er. Interfaz 2da. interfazrouter21 eth0:129.50.1.5 eth1:129.50.2.5router25 eth0:129.50.2.4 eth1:129.50.5.4router26 eth0:129.50.2.1 sl0:129.50.6.65router27 eth0:129.50.2.2 sl0:129.50.6.130router32 eth0:129.50.2.6 eth1:129.50.3.6router34 eth0:129.50.3.1 eth1:129.50.4.1router42 eth0:129.50.2.3 eth1:129.50.4.3

De forma mnemónica, a los nombres de ruteadores se leagregaron las redes que vinculan. Con respecto a la asignación

de direcciones a las interfaces de enlace, se siguió la norma deasociar a la primera interfaz la dirección de red menor. Finalmentese hizo coincidir el número de host en cada interfaz del ruteador.

La asignación de nombres, direcciones y máscaras de red en loshosts se indican en el siguiente plano de la red.

rout

er21

eth

1 1

29.5

0.2

.5

cord

oba

129.5

0.5

.0 /

255.2

55.2

55.0

rioiii

129.5

0.5

.1

argentina129.50.2.0 / 255.255.255.0

lapampa129.50.3.0 / 255.255.255.0

pico

129.5

0.3

.2

ro

ute

r34

eth

1 1

29.5

0.4

.1

rione

gro

129.5

0.4

.0 /

255.2

55.2

55.0

baril

oche

129.5

0.4

.2ro

uter

42eth

0 1

29.5

0.2

.3

rout

er25

eth

0 1

29.5

0.2

.4

eth

1 1

29.5

0.5

.4

rout

er27

eth

0 1

29.5

0.2

.2

men

doza

129.5

0.6

.128

255.2

55.2

55.2

52

sanr

afae

l129.5

0.6

.129

sl0 1

29.5

0.6

.130

rout

er26

eth

0 1

29.5

0.2

.1

neuq

uen

129.5

0.6

.64

255.

255.

255.

252

cutr

alc

o129.5

0.6

.66

sl0 1

29.5

0.6

.65

eth

0 1

29.5

0.1

.5

lu

jan

129.5

0.1

.2 la

pla

ta 129.5

0.1

.3 c

hiv

ilcoy

129.5

0.1

.4bs

as129.5

0.1

.0 /

255.2

55.2

55.0

rout

er32

eth

0 1

29.5

0.2

.6

eth

1 1

29.5

0.3

.6

eth

0 1

29.5

0.3

.1

eth

1 1

29.5

0.4

.3

Pla

no d

e T

opol

ogía

de

Red

Red 1

29.5

0.0

.0


Comandos de configuración de red

El siguiente procedimiento está ajustado para el sistema operativoLinux, distribución Slackware, con permisos de usuarioadministrador (root).

Establecimiento del nombre del host

Edición del archivo /etc/HOSTNAME e insercióndel nombre y dominio asociado (FQDN).

Edición del archivo de registro de redes

Debe editarse el archivo /etc/networks y añadirselos registros necesarios, bajo la siguiente sintaxis:número IP de red (tabulador) nombre de la red.

Edición del archivo de registro de hosts

Debe editarse el archivo /etc/hosts y añadirse losregistros necesarios, bajo la siguiente sintaxis:número IP de host (tabulador) nombre de host ydominio asociado (tabulador) nombre de host sindominio asociado.

Configuración de la interfaz

Con el comando ifconfig, para cada interfaz denivel de enlace, debe configurarse la interfaz dered bajo la siguiente sintaxis: ifconfig (nombre dela interfaz) (número IP de host) netmask (máscarade red) broadcast (dirección de difusión de la red).En el caso de ser interfaces Ethernet la primeraserá eth0, la segunda eth1 y así sucesivamente;para interfaces seriales tipo SLIP la primera serásl0, la segunda sl1 y así sucesivamente.

Configuración de rutas de red

Con el comando route deben ingresarse alsistema operativo cada una de las rutasdesprendidas de la política de ruteo diseñada. Lasintaxis asociada es la siguiente: route add –net(número de red) gw (dirección Ip del gatewayasociado) metric (valor decimal de peso de la

métrica) (nombre de la interfaz de nivel de enlacepor la cual deben entregarse los datagramas)

Configuración de la política de resolución de nombres

En este punto hay que definir el orden deevaluación de los mecanismos de resolución denombres (mediante tabla estática /etc/hosts omediante DNS). A tales efectos se debe editar elarchivo /etc/host.conf. Ejemplo para este caso:

order hosts, bind

Además, es necesario configurar la dirección delDNS para cada hosts. Esto se especifica en elarchivo /etc/resolv.conf, por ejemplo:

search tyr.unlu.edu.arnameserver 129.50.4.2

Comandos de configuración de la interfaz slip

La configuración de las interfaces slip requieren del comandoslattach, cuya sintaxis es la siguiente:

slattach -s <velocidad del enlace> -p <protocolo> tty

Por ejemplo:

slattach -s 57600 -p slip /dev/cua0 &(Esto se debe hacer en ambos extremos del enlace)

Luego, es necesario configurar (“ levantar” ) la interfaz (usandoifconfig):

ifconfig sl0 129.50.6.65 pointopoint 129.50.6.66 up

En nuestro modelo de red existen dos enlaces seriales. Uno en lared neuquen (129.50.6.64) y otro en la red mendoza(129.50.6.128). Para lo cual en cada interfaz serial (generalmentesl0) deben configurarse el enlace y la definición de interfaz de redcomo muestra el ejemplo.

Ejemplo de tabla de rutas


Se instaló una porción de la red enunciada, que consta de unruteador (router34) y dos hosts (pico y bariloche). En router34, unavez configurado, se ejecutó el comando route –n y se obtuvo lasiguiente salida:

Kernel IP routing tableDestination Gateway Genmask Flags Metric RefUse Iface129.50.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1129.50.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0127.0.0.00.0.0.0 255.0.0.0U 0 0 0 lo

La columna destination indica la red a alcanzar. Gateway es ladirección de la interfaz de ruteo, donde 0.0.0.0 indica el propioequipo. Genmask hace referencia a la máscara de la red dedestino. Flags indicadores, donde U significa ruta habilitada, H eldestino es un hosts, G se especifica cuando la ruta no se alcanzadirectamente, D ruta aprendida dinámicamente, M ruta modificadadinámicamente y ¡ ruta rechazada. Metric es el peso decimal quese le asigna a la ruta como parámetro de selección en caso dealternativas. Ref no utilizado en Linux. Use cantidad de veces quese uso la ruta. Iface es la asociación con la interfaz de nivel deenlace.

En nuestro ejemplo, la primer línea indica que a la red 129.50.4.0se la accede directamente por la interfaz eth1.

Ejemplo de tabla ARP

Del ruteador router34 se extrajo una instancia de su tabla ARPcomo se muestra a continuación:

? (129.50.4.1) at 00:80:AD:40:4E:63 [ether] on eth1? (129.50.3.1) at 00:00:B4:5B:A4:2E [ether] on eth0

La primer entrada hace referencia a que la dirección de interfaz dered 129.50.4.1 le corresponde la dirección MAC00:80:AD:40:4E:63 y pertenece al dominio de broadcast de nivelde enlace de la interfaz eth1.

Ejemplo de tabla servicios bien conocidos

Esta tabla describe los servicios disponibles para un sistemaTCP/IP, asociándolo a un puerto bien conocido donde se ofrecen.A efectos demostrativos solo se muestran algunas líneas. Seencuentra en /etc/services.

# servicesecho 7/tcpecho 7/udp

ftp-data 0/tcpftp 21/tcptelnet 23/tcpsmtp 25/tcptime 37/tcptime 37/udp

La primer columna denota el nombre del servicio, seguido delnúmero de puerto y protocolo de transporte asociado.

Ejemplo de tabla de protocolos

Este archivo describe los protocolos y sus códigos asociados queestán disponibles para un sistema TCP/IP. Se encuentra en/etc/protocols.

# protocols

ip 0 IP # internet protocol,pseudo protocol numbericmp 1 ICMP # internet control message protocoligmp 2 IGMP # internet group multicast protocolggp 3 GGP # gateway-gateway protocoltcp 6 TCP # transmission control protocolpup 12 PUP # PARC universal packet protocoludp 17 UDP # user datagram protocolidp 22 IDP # WhatsThis?raw 255 RAW # RAW IP interfaz

# End of protocols.

Esta tabla como la anterior son consultadas por las aplicaciones ala hora de la generar mensajes, dado que necesitan asociar unmnemónico con su correspondiente numérico.

Configuración de Servicios de Aplicación

En la red presentada se instalaron y configuraron los siguientesservicios de aplicación:

Bajo sistema operativo Linux, en el host bariloche (129.50.4.2)servidor HTTP (Apache versión 1.3.6) y servidor DNS (Bindversión 4).

Bajo sistema operativo Microsoft Windows 95, en el host pico(129.50.3.2) se instaló un cliente HTTP (Netscape Navigatorversión 4.61) y el software de interfaz SOCKS versión 5(SocksCaps versión 1.03 ,de la empresa NEC)

Bajo sistema operativo Linux, se instaló en el ruteador router34 unservidor SOCKS versión 5, de la empresa NEC.

Configuración del servidor HTTP


Se instaló, con la utilidad pkgtool, la versión de servidor Apachedistribuida en el curso. La misma generó una estructura dedirectorios a partir del camino /var/lib/apache. Se editó el archivode configuración (/var/lib/apache/conf/httpd.conf) a los efectos dedefinir el nombre de servidor (directiva ServidorName). El resto delas opciones se dejaron con sus valores por defectos, ya que no serequerían cambios para la realización del presente trabajo.Además se incorporó la script de arranque como parte de losservicios a iniciar durante el booteo.

Configuración del servidor de nombres

Se definió una única zona para toda la red propuesta bajo eldominio tyr.unlu.edu.ar. Se instaló, con la utilidad pkgtool, laversión de servidor Bind distribuida en el curso. Se incorporó unascript de arranque como parte de los servicios a iniciar durante elbooteo. La configuración de los distintos archivos que componen labase de datos se describe en el siguiente instructivo deconfiguración:

En nuestra instalación, el directorio /var/named contiene losarchivos de configuración. El archivo named.boot define eldirectorio (directory) en el cual residen el resto de los archivos deconfiguración de zonas. Además indica los dominios sobre loscuales el servidor de nombres tiene autoridad (primary) ó esréplica (secondary). También se hace referencia a la lista depunteros a los root-servers, mediante la directiva cache. Cadaentrada está ligada a un archivo que se denota en la tercercolumna. En nuestra instalación named.boot se ve así:

directory /var/namedcache . named.caprimary tyr.unlu.edu.ar named.hostsprimary 0.0.127.IN-ADDR.ARPA named.localprimary 50.129.IN-ADDR.ARPA named.rev

El archivo named.ca contiene una lista de asociaciones nombre-dirección correspondiente a los servidores de nombre raíz paravinculaciones con dominios de alto nivel, a los efectos de podercomenzar la resolución de nombres no pertenecientes a nuestrodominio.

;. 99999999 IN NS NS.NIC.DDN.MIL;NS.NIC.DDN.MIL 99999999 IN A 26.3.0.103;. 99999999 IN NS NS.NASA.GOV;NS.NASA.GOV 99999999 IN A 128.102.16.10

Nota: Debido a que nuestra red no tiene vinculación con Internet,no se requiere acceso a root-servers, por lo cual se hancomentado todas las entradas.

Named.host es un archivo que indica quien tiene autoridad sobreel dominio tyr.unlu.edu.ar (en nuestro caso bariloche), definiendouna serie de parámetros para el control de las replicas y contactoadministrativo. Luego, mediante registros tipo A se vinculan losnombres de hosts con su dirección de red. CNAME permite definirun alias sobre entradas tipo A. En nuestro caso el host barilochetiene asociado dos alias que son www y dns.

@ IN SOA bariloche.tyr.unlu.edu.ar.ght.bariloche.tyr.unlu.edu.ar. (

20000708001 ;serial86400 ;refresh:

;1 vez x dia3600 ;retry: 1 x hora3600000 ;expire: 42 dias604800 ) ;minimum:1semana

IN NS barilochelocalhost. IN A 127.0.0.1

;Descripción de los distintos registros para

bariloche IN A 129.50.4.2pico IN A 129.50.3.2dns IN CNAME barilochewww IN CNAME barilochelujan IN A 129.50.1.2laplata IN A 129.50.1.3chivilcoy IN A 129.50.1.4rioiii IN A 129.50.5.1cutralco IN A 129.50.6.66sanrafael IN A 129.50.6.129

Nota: Si se agrega un host a la red deberá agregarse lacorrespondiente entrada tipo A en este archivo, como también susalias (CNAME) si hubiera. En caso de definir servidor de mail eltipo de registro es MX y una entrada posible sería

lujan IN MX 10 lujan

Aquí se definió que el host lujan maneja mail para el dominiotyr.unlu.edu.ar.

Named.local. Este archivo indica que la resolución inversa para ellocalhost corresponde a un determinado servidor de nombres (esél mismo) y se define un puntero.


1 ;serial360000 ;refresh: 100 hs3600 ;retry: 1 x hora3600000 ;expire: 42 dias604800 ) ;minimum: 1 semana


IN NS bariloche1 IN PTR localhost.

Named.rev. Este archivo contiene el mapeo inverso de direccionesIP, indicando que el host bariloche da respuestas con autoridad.En el registro tipo SOA se adjuntan datos de contactoadministrativo y control de réplicas. Los registro tipo PTR definenpunteros que vinculan direcciones de red con mnemónicos.


20000708001 ;serial86400 ;refresh: 1 vez x dia3600 ;retry: 1 x hora3600000 ;expire: 42 dias604800 ) ;minimum: 1 semanaIN NS bariloche

2.4 IN PTR bariloche2.3 IN PTR pico2.1 IN PTR lujan4.1 IN PTR chivilcoy3.1 IN PTR laplata1.5 IN PTR rioiii66.6 IN PTR cutralco129.6 IN PTR sanrafael

La instrucción de arranque del servidor de nombres es:

named –b /var/named/named.boot

Por cualquier modificación a los datos, el demonio debe serrelanzado a los efectos de que lea nuevamente los archivos deconfiguración. Por lo cual es común utilizar el siguiente comando:

Kill –HUP (pid del proceso named)

En nuestro caso, si se decidiera implementar en la red 129.50.0.0una estrategia de réplica del servidor de nombres, se definiría enun host (por ejemplo lujan) un servidor secundario cuyo archivonamed.boot con el siguiente contenido:

directory /var/namedcache . named.casecondary tyr.unlu.edu.ar named.hosts.rprimary 0.0.127.IN-ADDR.ARPA named.local.rsecondary50.129. IN-ADDR.ARPA named.rev.r

Configuración del cliente

Al host pico (estación de trabajo con sistema operativo MicrosoftWindows 95) se le asignó (por panel de control/red) la dirección IP129.50.3.2. Se asignó un gateway por defecto correspondiente al

router34 en 129.50.3.1. y finalmente se instanció el servidor denombres (129.50.4.2) y dominio asociado (tyr.unlu.edu.ar).

Nota: En este hosts se instaló la aplicación Nestcape Navigatorcomo parte de los requerimientos para resolución del trabajopráctico e instrumento de prueba de los servicios instalados(servidor HTTP y servidor de nombres).

Conexión a Internet

En el supuesto caso de querer vincular la red 129.50.0.0 conInternet, en un host ó ruteador de la misma deberá instalarse unenlace vinculante. Por ejemplo en el host bariloche a través de lainterfaz sl0 IP 100.100.100.65 (netmask 255.255.255.252). Esimportante denotar que la capacidad IP-FORWARDING debehabilitarse en bariloche (pasando de ser multihomed host aruteador). En los hosts internos debe agregarse una ruta pordefecto (default gateway) de manera tal que si un datagrama nopertenece a una de las redes internas, debe enviarse a través debariloche a Internet.

route add default gw 129.50.4.2 netmask 0.0.0.0 metric 1

Nota: Debe considerarse que en el nuevo ruteador bariloche existela necesidad de implementar algún mecanismo de filtrado (tipoipchains en Linux) de manera que no rutee al exterior los posiblesdatagramas pertenecientes a la red interna. Además, este softwarepodría ser utilizado como un firewall elemental de filtrado depaquetes (por dirección, protocolo y servicios) debido a que lasdirecciones internas de la red pasan a ser públicas para Internet.


Tercera Sección

Configuración de SOCKS Versión 5 sobre la RedTCP/IP

SERVIDOR SOCKSrouter34 - multihomed host

eth0 129.50.3.1

SERVIDOR HTTP y DNSbariloche

129.50.4.2

CLIENTE HTTPpico

129.50.3.2

eth1 129.50.4.1

Diagrama de la subred implementada

El objetivo de la implementación, presentada en el diagramaanterior, es brindar un acceso seguro a otras redes por parte deequipos pertenecientes a la red 129.50.3.0. Para lo cual al equipodenominado router34 se le deshabilitó la función del IP-Forwarding, convirtiéndolo en un multihomed host. Además, seinstaló el software con capacidad de servidor SOCKS versión 5desarrollado por la firma NEC (accesible en la URLhttp://www.SOCKS.nec.com). La instalación se realizósiguiendo las instrucciones adjuntas al software, dondebásicamente se configuró la distribución fuente, se compiló, sedistribuyó en los directorios predeterminados y finalmente seconfiguró el software de acuerdo a las necesidades propias. Laconfiguración del servidor se realiza sobre el archivo/etc/socks5.conf, en nuestro caso se utilizó la siguiente:

auth - - - # Permite cualquier tipo# de autenticación# inclusive ninguna.

permit - - 129.50.3. - - - # Permite que todos los hosts# de la red 129.50.3 puedan tener# servicio de proxy,# negando acceso a servicios# proxy a cualquier hosts# de otra red

set SOCKS5_V4SUPPORT # Brinda servicios de SOCKS# versión 4 a clientes que lo# soliciten.

El servidor SOCKS se ejecutó bajo línea de comando con lasiguiente orden:

<dir.de instalación>#./socks5 –b 1080 –d 2 –s

Donde –b 1080 le indica que atienda en el puerto 1080 y –d 2determina el nivel de información provista por el módulo dedebugger en archivos de logs y –s indica que las líneas de debugdeben ser redirigidas a la salida estándar de errores (monitor ennuestro caso).

En el equipo pico, operando sobre sistema operativo MicrosoftWindows 95, se instaló el software cliente HTTP denominadoNavigator, de la empresa Netscape. Dado que la versión instalada(4.61) solo soporta el protocolo SOCKS versión 4 fue necesarioincluir un agente residente que capture las peticiones del Navigatory las traduzca a peticiones SOCKS 5. Este software es provistopor la empresa NEC (accesible en la URLhttp://www.SOCKS.nec.com) y se denomina SocksCaps. Luegode instalado, se lo configuró indicando los siguientes parámetros:dirección IP y número de puerto del servidor SOCKS, indicación dequien resuelve la conversión de nombres (si es local o a través delservidor SOCKS), si se lleva un registro de logs sobre peticionesrealizadas, aplicaciones sobre las cuales va a actuar. En definitiva,bajo Windows, SocksCaps a través de librerías dinámicas (DLL)provee un servicio transparente (para la aplicación cliente) deacceso a servidores de aplicación a través de un servidor SOCKS.Esta tarea se denomina Socksification.

http://www.socks.nec.com/

http://www.socks.nec.com/


Cuarta Sección

Análisis del intercambio de mensajes de losdistintos protocolos

Captura Nro. 1

En base a la configuración enunciada en la sección anterior seprocedió a realizar una captura de protocolo HTTP que incluyó unapágina HTML y un objeto gráfico asociado. para lo cual, en elequipo router34 se corrió el software de captura tcpdump con laopción de almacenamiento en archivo. En una segunda terminal,del mismo equipo se ejecutó el programa netstat con refrescodinámico, a los efectos de monitorear el estado de los serviciosactivos y determinar cuando se establece y cierra una conexión.En el equipo pico, cliente Microsoft Windows 95, ejecutando elsoftware Navigator en modo Socksfied se procedió a tipear lasiguiente URL http://www.tyr.unlu.edu.ar. Como resultadose obtuvo la página requerida con su gráfico asociado. Además sesolicitó una página no existente del mismo servidor, obteniéndoseel correspondiente mensaje de error. Finalmente se detuvo lacaptura

Analizada la captura obtenida, a continuación se realiza un somerorelato de los principales hechos sucedidos (Referirse al anexo 2,sección captura 1, por un mayor grado de detalle). En primer lugarel cliente de aplicación (CA) solicita una apertura de conexión TCPcon el servidor SOCKS (SS), e intercambian mensajes deprotocolo SOCKS a los efectos de acordar el método deautenticación. Luego CA envía una solicitud de servicio contra unservidor de aplicación (SA). SS consulta al servidor DNS acerca dela dirección IP de SA, para luego establecer una conexión TCPcon SA y poder avisar acerca del éxito a CA. Este envía a SS unpedido de servicio de aplicación (GET /), el cual es reenviado porSS a SA. A partir de aquí en más SS funciona como agente dereenvío en ambos sentidos. Debido a que la página HTMLrecuperada contenía una referencia a un objeto externo, CA debeabrir una segunda conexión con SS para recuperarlo (siguiendo elmecanismo descripto anteriormente). Finalizadas ambastransferencias, se procedió a tipear desde CA una URL queapuntaba a un recurso inexistente en SA. Cabe notar aquí queesta nueva solicitud se canalizó por la primer conexión entre CA ySS, dado que a nivel protocolo HTTP mediante la directiva keep-alive el canal quedo abierto. Finalmente, por iniciativa del SA secerraron ambas conexiones con SS, y por ende este con CA.

Resumen

Cantidad de PDUs intercambiadas 71Cantidad de mensajes ARP 3(1 request y 2 replies)Cantidad de mensajes UDP DNS 4Cantidad de conexiones TCP 4

Conexión 1 - CA 129..50.3.2:1056 - SS 129.50.4.1:1080

Cantidad de segmentos en fase inicio 3Cantidad de segmentos en fase de fin 4Cantidad de segmentos en fase de transferencia 14(9 con datos de aplicación y 5 sin datos de aplicación)

Overhead (Bytes totales en aplicación/bytes totalesconexión) : 2854/4168 = 0,68 = 68%

Conexión 2 - SS 129.50.4.1:1045 - SA 129.50.4.2:80

Cantidad de segmentos en fase inicio 3Cantidad de segmentos en fase de fin 4Cantidad de segmentos en transferencia 5(5 con datos de aplicación y 4 sin datos de aplicación)

Conexión 3 - CA 129.50.3.2:1057 - SS 129.50.3.1:1080


Overhead (Bytes totales en aplicación / bytes totalesconexión) : 2921/3863 = 0,75 = 75%

Conexión 4 - SS 129.50.4.1:1046 - SA 129.50.4.2:80


Overhead total ( total bytes aplicación / (mensajes ARP +bytes conexión 1 + bytes conexión 3) ) = (2854+2921) /(128 + 4168 + 3863) = 0,78 = 78% de overhead

http://www.tyr.unlu.edu.ar/


El gráfico de tiempos de la página siguiente muestra los mensajesintercambiados durante el procesamiento de la primer solicitud,donde se ve claramente la interacción entre las tres partes delmodelo SOCKS.

Captura Nro. 2

Bajo las condiciones de la captura número 1 se procedió amodificar el archivo de configuración /etc/socks5.confdeterminando que el CA no tiene autorización para obtenerservicios de relay. la línea agregada al archivo de configuración esla siguiente:

deny - - 129.50.3.2 - - -

Debido a que la línea de permit se mantuvo, el resto de losequipos en esta red mantenían la autorización. En el equipo pico,cliente Microsoft Windows 95, ejecutando el software Navigator enmodo Socksfied se procedió a tipear nuevamente la solicitud de laURL http://www.tyr.unlu.edu.ar, obteniéndose comoresultado un mensaje de no autorización a prestación de servicio.

Analizada la captura se nota que luego de emitida la solicitud deservicio por parte de CA a SS, éste consulta al servidor DNS paraobtener la dirección IP de SA. Luego envía una respuesta negativaa la solicitud de servicio dado que por regla CA carece deautorización. Es de notar que la consulta al servidor DNS fuetotalmente innecesaria por parte de SS. Inmediatamente SSsolicita a CA cierre de conexión. (Referirse al anexo 2, seccióncaptura 2, por un mayor grado de detalle).

Captura Nro. 3

Bajo las condiciones de la captura número 1 se procedió a cerrarel servicio HTTP en el servidor de aplicación.

En el equipo pico, cliente Microsoft Windows 95, ejecutando elsoftware Navigator en modo Socksfied se procedió a tipearnuevamente la solicitud de la URLhttp://www.tyr.unlu.edu.ar, obteniéndose como resultadoun mensaje de error por parte del servidor SOCKS ya que no pudoestablecer conexión con el servidor de aplicación.

Analizada la captura se nota que luego de emitida la solicitud deservicio por parte de CA a SS, éste consulta al servidor DNS paraobtener la dirección IP de SA. A continuación SS envía unasolicitud de conexión a SA, obteniendo un mensaje de rechazo porno existir un demonio atendiendo peticiones de aplicación. Luegoenvía una respuesta negativa a la solicitud de servicio de CA ysolicita el cierre de la conexión. (Referirse al anexo 2, seccióncaptura 3, por un mayor grado de detalle).




129.50.3.2 CASS

129.50.3.1129.50.4.1

129.50.4.2 SA

1056 a 1080 - SYN (s927) mss1460-w8192

1080 a 1056 - SYN ACK(s6218-a9272)-mss1460-w32120

1056 a 1080 - ACK (s:1)-w8760

1056 a 1080 - P ACK (s:1:4-a1)-w8760

1080 a 1056 - ACK(a4)-w32120

1080 a 1056 - P ACK(s1:3-a4)-w32120

1056 a 1080 - P ACK (s4:30-a3)-w8758

DNS 1027 a 53 - query

DNS 53 a 1027 - response

1080 a 1056 - ACK(a30)-w32120

1045 a 80 - SYN (s820) - mss1460-w3212080 a 1045- SYN ACK - (s4837:a821)

mss1460-w321201045 a 80 - ACK (a1) - w321220

1080 a 1056 - P ACK(s3:13-a30)-w32120

1056 a 1080 - P ACK (s30:298-a13)-w8748

1045 a 80 - P ACK (s1:269-a1) - w32120

80 a 1045- ACK - (a269) w32120

1080 a 1056 - ACK (a298)-w32120 80 a 1045- P ACK - (s1:1449-a269) w32120

80 a 1045- P ACK - (s1449:1898-a269) w32120

1045 a 80 - P ACK (a1449) - w31856

1080 a 1056 - P ACK (s13:1473-a298)-w32120

1045 a 80 - ACK (a1898) - w31856

1056 a 1080 - ACK -(a1473)-w1898

1080 a 1056 - P ACK (s1473:1910-a298)-w32120

1056 a 1080 - ACK -(a1910)-w8323

La captura continua con la recuperación de un segundo objeto, por una nueva conexión,y a continuación se muestra la secuencia de cierre de la primer conexión

80 a 1045- FIN ACK - (s2314-a542) w32120

1045 a 80 - ACK (a2315) - w31856

1045 a 80 - FIN ACK (s542-a2315) - w31856

80 a 1045- ACK - (a543) w32120

1080 a 1056 - FIN ACK (s2326-a571)-w32120

1056 a 1080 - ACK -(a2327)-w7907

1056 a 1080 - FIN ACK -(s571-a2327)-w7907

1080 a 1056 - ACK (a572)-w32120

Captura Nro. 4

Bajo las condiciones de la captura número 1, en el equipo pico,cliente Microsoft Windows 95, ejecutando el software Navigator enmodo Socksfied se procedió a tipear la solicitud de la URLinexistente http://www.unlu.edu.ar, obteniéndose comoresultado un mensaje de error por parte del servidor SOCKS yaque no pudo obtener la dirección IP correspondiente.

Analizada la captura se nota que luego de emitida la solicitud deservicio por parte de CA a SS, éste consulta al servidor DNS paraobtener la dirección IP de SA. El servidor DNS contesta indicandoque no puede resolver lo pedido. A continuación SS envía unanueva solicitud al servidor DNS, agregando su dominio a la URL,obteniendo la misma respuesta negativa. SS envía un mensaje deimposibilidad de brindar servicio a la solicitud de CA y solicita elcierre de la conexión. (Referirse al anexo 2, sección captura 4, porun mayor grado de detalle).

Captura Nro. 5

Bajo las condiciones de la captura número 1 se procedió a cerrarel servicio SOCKS. Luego, en el cliente Microsoft Windows 95,ejecutando el software Navigator en modo Socksfied se procedió atipear la solicitud de la URL inexistentehttp://www.tyr.unlu.edu.ar, obteniéndose como resultadoun mensaje de error por parte del cliente HTTP.

Analizada la captura se nota que cuando CA intenta establecerconexión con SS, recibe rechazos sistemáticos en todos susintentos, dado que no existe demonio brindando servicio SOCKS.(Referirse al anexo 2, sección captura 5, por un mayor grado dedetalle).




ANEXO 1 – Configuración de hosts y ruteadores

*** TABLA DE HOSTS

-Archivo /etc/hosts

129.50.1.2 lujan.tyr.unlu.edu.ar lujan129.50.1.3 laplata.tyr.unlu.edu.ar laplata129.50.1.4 chivilcoy.tyr.unlu.edu.ar chivilcoy129.50.3.2 pico.tyr.unlu.edu.ar pico129.50.4.2 bariloche.tyr.unlu.edu.ar bariloche129.50.5.1 rioiii.tyr.unlu.edu.ar rioiii129.50.6.66 cutralco.tyr.unlu.edu.ar cutralco129.50.6.129 sanrafael.tyr.unlu.edu.ar sanrafael

*** DEFINICION DE RUTEADORES

Nombre de host: router21

-Dominio: tyr.unlu.edu.ar

-Archivo /etc/networks

129.50.1.0 bsas129.50.2.0 argentina129.50.3.0 lapampa129.50.4.0 rionegro129.50.5.0 cordoba129.50.6.64 neuquen129.50.1.128 mendoza

-Interfaces

--Eth0:ifconfig eth0 129.50.1.5 netmask 255.255.255.0 broadcast 129.50.1.255


-Rutas

route add -net 129.50.1.0 netmask 255.255.255.0 eth0route add -net 129.50.2.0 netmask 255.255.255.0 eth1route add -net 129.50.3.0 gw 129.50.2.6 netmask 255.255.255.0 metric 1 eth1route add -net 129.50.3.0 gw 129.50.2.3 netmask 255.255.255.0 metric 2 eth1route add -net 129.50.4.0 gw 129.50.2.3 netmask 255.255.255.0 metric 1 eth1route add -net 129.50.4.0 gw 129.50.2.6 netmask 255.255.255.0 metric 2 eth1route add -net 129.50.5.0 gw 129.50.2.4 netmask 255.255.255.0 metric 1 eth1route add -net 129.50.5.0 gw 129.50.2.6 netmask 255.255.255.0 metric 4 eth1route add -net 129.50.6.64 gw 129.50.2.1 netmask 255.255.255.252 metric 1 eth1route add -net 129.50.6.64 gw 129.50.2.6 netmask 255.255.255.252 metric 4 eth1route add -net 129.50.6.128 gw 129.50.2.2 netmask 255.255.255.252 metric 1 eth1route add -net 129.50.6.128 gw 129.50.2.6 netmask 255.255.255.252 metric 4 eth1

* Nombre de host: router32



129.50.1.0 bsas129.50.2.0 argentina129.50.3.0 lapampa129.50.4.0 rionegro129.50.5.0 cordoba129.50.6.64 neuquen

129.50.1.128 mendoza

-Interfaces



-Rutas






-Interfaces



-Rutas





129.50.1.0 bsas129.50.2.0 argentina129.50.3.0 lapampa


129.50.4.0 rionegro129.50.5.0 cordoba129.50.6.64 neuquen129.50.1.128 mendoza

-Interfaces



-Rutas






-Interfaces



-Rutas






-Interfaces


--Sl0:ifconfig sl0 129.50.6.65 netmask 255.255.255.252 broadcast 129.50.6.67

-Rutas

route add -net 129.50.2.0 netmask 255.255.255.0 eth0route add -net 129.50.6.64 netmask 255.255.255.252 sl0route add -net 129.50.1.0 gw 129.50.2.5 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.1.0 gw 129.50.2.3 netmask 255.255.255.0 metric 4 eth0route add -net 129.50.3.0 gw 129.50.2.6 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.3.0 gw 129.50.2.3 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.4.0 gw 129.50.2.3 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.4.0 gw 129.50.2.6 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.6.64 gw 129.50.2.1 netmask 255.255.255.252 metric 1 eth0route add -net 129.50.6.64 gw 129.50.2.6 netmask 255.255.255.252 metric 4 eth0route add -net 129.50.6.128 gw 129.50.2.2 netmask 255.255.255.252 metric 1 eth0route add -net 129.50.6.128 gw 129.50.2.6 netmask 255.255.255.252 metric 4 eth0





-Interfaces



-Rutas

route add -net 129.50.2.0 netmask 255.255.255.0 eth0route add -net 129.50.6.128 netmask 255.255.255.252 sl0route add -net 129.50.1.0 gw 129.50.2.5 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.1.0 gw 129.50.2.3 netmask 255.255.255.0 metric 4 eth0route add -net 129.50.3.0 gw 129.50.2.6 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.3.0 gw 129.50.2.3 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.4.0 gw 129.50.2.3 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.4.0 gw 129.50.2.6 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.6.64 gw 129.50.2.1 netmask 255.255.255.252 metric 1 eth0route add -net 129.50.6.64 gw 129.50.2.6 netmask 255.255.255.252 metric 4 eth0route add -net 129.50.6.128 gw 129.50.2.2 netmask 255.255.255.252 metric 1 eth0route add -net 129.50.6.128 gw 129.50.2.6 netmask 255.255.255.252 metric 4 eth0

*** DEFINICION DE HOSTS


* Hosts en red 129.50.1.0 (red bsas)

* Nombre de host: lujan




-Interfaces


-Rutas

route add -net 129.50.1.0 netmask 255.255.255.0 eth0route add -net 129.50.2.0 gw 129.50.1.5 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.3.0 gw 129.50.1.5 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.4.0 gw 129.50.1.5 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.5.0 gw 129.50.1.5 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.6.64 gw 129.50.1.5 netmask 255.255.255.252 metric 1 eth0route add -net 129.50.6.128 gw 129.50.1.5 netmask 255.255.255.252 metric 1 eth0

* Nombre de host: laplata




-Interfaces


-Rutas


* Nombre de host: chivilcoy




-Interfaces


-Rutas


* Hosts en red 129.50.3.0 (red lapampa)

* Nombre de host: pico




-Interfaces


-Rutas

route add -net 129.50.3.0 netmask 255.255.255.0 eth0route add -net 129.50.1.0 gw 129.50.3.6 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.1.0 gw 129.50.3.1 netmask 255.255.255.0 metric 3 eth0route add -net 129.50.2.0 gw 129.50.3.6 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.2.0 gw 129.50.3.1 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.4.0 gw 129.50.3.1 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.4.0 gw 129.50.3.6 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.5.0 gw 129.50.3.6 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.5.0 gw 129.50.3.1 netmask 255.255.255.0 metric 3 eth0route add -net 129.50.6.64 gw 129.50.3.6 netmask 255.255.255.252 metric 2 eth0route add -net 129.50.6.64 gw 129.50.3.1 netmask 255.255.255.252 metric 3 eth0route add -net 129.50.6.128 gw 129.50.3.6 netmask 255.255.255.252 metric 2 eth0route add -net 129.50.6.128 gw 129.50.3.1 netmask 255.255.255.252 metric 3 eth0

* Hosts en red 129.50.4.0 (red rionegro)

* Nombre de host: bariloche





-Interfaces


-Rutas

route add -net 129.50.4.0 netmask 255.255.255.0 eth0route add -net 129.50.1.0 gw 129.50.4.1 netmask 255.255.255.0 metric 3 eth0route add -net 129.50.1.0 gw 129.50.4.3 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.2.0 gw 129.50.4.3 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.2.0 gw 129.50.4.1 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.3.0 gw 129.50.4.1 netmask 255.255.255.0 metric 1 eth0route add -net 129.50.3.0 gw 129.50.4.3 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.5.0 gw 129.50.4.3 netmask 255.255.255.0 metric 2 eth0route add -net 129.50.5.0 gw 129.50.4.1 netmask 255.255.255.0 metric 3 eth0route add -net 129.50.6.64 gw 129.50.4.3 netmask 255.255.255.252 metric 2 eth0route add -net 129.50.6.64 gw 129.50.4.1 netmask 255.255.255.252 metric 3 eth0route add -net 129.50.6.128 gw 129.50.4.3 netmask 255.255.255.252 metric 2 eth0route add -net 129.50.6.128 gw 129.50.4.1 netmask 255.255.255.252 metric 3 eth0

* Hosts en red 129.50.5.0 (red cordoba)

* Nombre de host: rioiii




-Interfaces


-Rutas


* Hosts en red 129.50.6.64 (red neuquen)

* Nombre de host: cutralco




-Interfaces


-Rutas

route add -net 129.50.6.64 netmask 255.255.255.252 sl0route add -net 129.50.1.0 gw 129.50.6.65 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.2.0 gw 129.50.6.65 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.3.0 gw 129.50.6.65 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.4.0 gw 129.50.6.65 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.5.0 gw 129.50.6.65 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.6.128 gw 129.50.6.65 netmask 255.255.255.252 metric 1 sl0

* Hosts en red 129.50.6.64 (red mendoza)

* Nombre de host: sanrafael




-Interfaces


-Rutas

route add -net 129.50.6.128 netmask 255.255.255.252 sl0route add -net 129.50.1.0 gw 129.50.6.130 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.2.0 gw 129.50.6.130 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.3.0 gw 129.50.6.130 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.4.0 gw 129.50.6.130 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.5.0 gw 129.50.6.130 netmask 255.255.255.0 metric 1 sl0route add -net 129.50.6.64 gw 129.50.6.130 netmask 255.255.255.252 metric 1 sl0


ANEXO 2 - Detalle de las capturas realizadas

Códigos de fases TCP:

I inicioT transferenciaC cierre

Códigos de hosts:

CA cliente de aplicaciónSS servidor SOCKSSA servidor de aplicación

Códigos de protocolos y fases:

ROJO ARPVERDE DNSAZUL OSCURO Inicio de conexión TCPAZUL MEDIO Transferencia en conexión TCPCELESTE Cierre de conexión TCPNEGRO Mensajes de protocolo SOCK


Captura Nro. 1

ID CARGA FASETCP

VOLCADO TCPDUMP COMENTARIOS

1 01:38:03.803728 arp who-has 129.50.3.1 tell pico.50.129.IN-ADDR.ARPA

CA solicita MAC de 129.50.3.1 (SS)

2 01:38:03.803955 arp reply 129.50.3.1 is-at 0:0:b4:5b:a4:2e SS por eth0 responde a CA su MAC

3 01:38:03.804331 arp reply 129.50.3.1 is-at 0:80:ad:40:4e:63 SS por eth1 responde a CA su MAC

4 I 01:38:04.017314 pico.50.129.IN-ADDR.ARPA.1056 >129.50.3.1.1080: S 6349271:6349271(0) win 8192 <mss 1460> (DF)

CA solicita apertura de conexión TCP con SS (SYN)

5 I 01:38:04.017634 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1056: S 402776218:402776218(0) ack 6349272 win 32120<mss 1460> (DF)

SS acepta (SYN ACK)

6 I 01:38:04.018872 pico.50.129.IN-ADDR.ARPA.1056 >129.50.3.1.1080: . ack 1 win 8760 (DF)

CA acepta (ACK)

7 3 T 01:38:04.037217 pico.50.129.IN-ADDR.ARPA.1056 >129.50.3.1.1080: P 1:4(3) ack 1 win 8760 (DF)

CA solicita apertura de conexión SOCKS sin autenticación

8 T 01:38:04.037524 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1056: . ack 4 win 32120 (DF)

ACK de transporte

9 2 T 01:38:04.042215 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1056: P 1:3(2) ack 4 win 32120 (DF)

SS indica a CA que la forma de autenticación seleccionada (sinautentificación)



CA solicita requerimiento de conexión con SA, enviando dirección ypuerto

11 37 01:38:04.165407 129.50.4.1.1027 > bariloche.50.129.IN-ADDR.ARPA.domain: 26868+ A? www.tyr.unlu.edu.ar. (37)

SS solicita a DNS la dirección IP del SA

12 122 01:38:04.168303 bariloche.50.129.IN-ADDR.ARPA.domain >129.50.4.1.1027: 26868* 2/1/1 CNAME bariloche.tyr.unlu.edu.ar.,A bariloche.50.129

DNS contesta indicando la dirección IP solicitada


ACK de transporte

14 I-2 01:38:04.174433 129.50.4.1.1045 > bariloche.50.129.IN-ADDR.ARPA.www: S 402970820:402970820(0) win 32120 <mss1460,sackOK,timestamp 584664

SS solicita apertura de conexión TCP con SA (SYN)

15 I-2 01:38:04.178812 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1045: S 4252404837:4252404837(0) ack 402970821 win32120 <mss 1460,sackOK,

SA acepta (SYN ACK)

16 I-2 01:38:04.179257 129.50.4.1.1045 > bariloche.50.129.IN-ADDR.ARPA.www: . ack 1 win 32120 <nop,nop,timestamp 584664637480> (DF)

SS acepta (ACK)


SS conesta a CA el ésito de la fase de apertura de conexión con SA


A nivel de aplicación, CA solicita a SA un recurso (SS actua como relay)

19 268 T-2 01:38:04.306773 129.50.4.1.1045 > bariloche.50.129.IN-ADDR.ARPA.www: P 1:269(268) ack 1 win 32120 <nop,nop,timestamp584677 637480> (DF)

SS reenvia el mensaje #17 a SA

20 T-2 01:38:04.308303 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1045: . ack 269 win 32120 <nop,nop,timestamp 637493584677> (DF)

ACK de transporte



ACK de transporte

22 1448 T-2 01:38:04.326407 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1045: P 1:1449(1448) ack 269 win 32120<nop,nop,timestamp 637495 584677> (

SA contesta el mensaje #18, enviando a SS el recurso (parte 1)solicitado

23 449 T-2 01:38:04.326770 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1045: P 1449:1898(449) ack 269 win 32120<nop,nop,timestamp 637495 584677>


24 T-2 01:38:04.327288 129.50.4.1.1045 > bariloche.50.129.IN-ADDR.ARPA.www: . ack 1449 win 31856 <nop,nop,timestamp 584679637495> (DF)

ACK de transporte


SS reenvia la respuesta recibida de SA a CA (parte 1)


ACK de transporte

27 T 01:38:04.542198 pico.50.129.IN-ADDR.ARPA.1056 >129.50.3.1.1080: . ack 1473 win 8760 (DF)

ACK de transporte



29 T 01:38:04.752688 pico.50.129.IN-ADDR.ARPA.1056 >129.50.3.1.1080: . ack 1910 win 8323 (DF)

ACK de transporte

30 I-3 01:38:04.784674 pico.50.129.IN-ADDR.ARPA.1057 >129.50.3.1.1080: S 6350038:6350038(0) win 8192 <mss 1460> (DF)


31 I-3 01:38:04.784934 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1057: S 406060411:406060411(0) ack 6350039 win 32120<mss 1460> (DF)

SS acepta (SYN ACK)

32 I-3 01:38:04.786185 pico.50.129.IN-ADDR.ARPA.1057 >129.50.3.1.1080: . ack 1 win 8760 (DF)

CA acepta (ACK)


33 3 T-3 01:38:04.823102 pico.50.129.IN-ADDR.ARPA.1057 >129.50.3.1.1080: P 1:4(3) ack 1 win 8760 (DF)


34 T-3 01:38:04.823393 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1057: . ack 4 win 32120 (DF)

ACK de transporte

35 2 T-3 01:38:04.824091 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1057: P 1:3(2) ack 4 win 32120 (DF)

SS indica a CA que la forma de autenticación seleccionada (sinautentificación)


CA solicita requerimiento de conexión con SA, enviando dirección ypuerto

37 37 01:38:04.960560 129.50.4.1.1027 > bariloche.50.129.IN-ADDR.ARPA.domain: 35353+ A? www.tyr.unlu.edu.ar. (37)


38 122 01:38:04.964089 bariloche.50.129.IN-ADDR.ARPA.domain >129.50.4.1.1027: 35353* 2/1/1 CNAME bariloche.tyr.unlu.edu.ar.,A bariloche.50.129

DNS contesta indicando la dirección IP solicitada

39 I-4 01:38:04.966619 129.50.4.1.1046 > bariloche.50.129.IN-ADDR.ARPA.www: S 390064459:390064459(0) win 32120 <mss1460,sackOK,timestamp 584743


40 I-4 01:38:04.967769 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1046: S 4252586142:4252586142(0) ack 390064460 win32120 <mss 1460,sackOK,

SA acepta (SYN ACK)

41 I-4 01:38:04.968222 129.50.4.1.1046 > bariloche.50.129.IN-ADDR.ARPA.www: . ack 1 win 32120 <nop,nop,timestamp 584743637559> (DF)

SS acepta (ACK)


SS conesta a CA el ésito de la fase de apertura de conexión con SA


A nivel de aplicación, CA solicita a SA un recurso (SS actua como relay)

44 311 T-4 01:38:05.097861 129.50.4.1.1046 > bariloche.50.129.IN-ADDR.ARPA.www: P 1:312(311) ack 1 win 32120 <nop,nop,timestamp584756 637559> (DF)



45 T-4 01:38:05.099181 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1046: . ack 312 win 32120 <nop,nop,timestamp 637572584756> (DF)

ACK de transporte

46 T-3 01:38:05.111774 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1057: . ack 341 win 32120 (DF)

ACK de transporte

47 1448 T-4 01:38:05.111450 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1046: P 1:1449(1448) ack 312 win 32120<nop,nop,timestamp 637573 584756> (


48 1162 T-4 01:38:05.112483 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1046: P 1449:2611(1162) ack 312 win 32120<nop,nop,timestamp 637573 584756



ACK de transporte





52 T-3 01:38:05.118589 pico.50.129.IN-ADDR.ARPA.1057 >129.50.3.1.1080: . ack 2623 win 8760 (DF)

ACK de transporte


ACK de transporte


A nivel de aplicación, CA solicita a SA un recurso (SS actua como relay)usando una conexi{on existente

55 273 T-2 01:38:09.477232 129.50.4.1.1045 > bariloche.50.129.IN-ADDR.ARPA.www: P 269:542(273) ack 1898 win 31856<nop,nop,timestamp 585194 637495>



56 416 T-2 01:38:09.489311 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1045: P 1898:2314(416) ack 542 win 32120<nop,nop,timestamp 638011 585194>

SA responde al SS con un mensaje de error por no existir el recurso


SS reenvia la respuesta (mensjaje 56) al CA

58 F-2 01:38:09.491094 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1045: F 2314:2314(0) ack 542 win 32120<nop,nop,timestamp 638011 585194> (

SA solicita a SS cierre de conexión (FIN)

59 F-2 01:38:09.491519 129.50.4.1.1045 > bariloche.50.129.IN-ADDR.ARPA.www: . ack 2315 win 31856 <nop,nop,timestamp 585196638011> (DF)

SS confirma cierre (ACK)

60 F-2 01:38:09.494726 129.50.4.1.1045 > bariloche.50.129.IN-ADDR.ARPA.www: F 542:542(0) ack 2315 win 31856<nop,nop,timestamp 585196 638011> (D

SS solicita a SA cierre de conexión (FIN)

61 F-2 01:38:09.494852 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1056: F 2326:2326(0) ack 571 win 32120 (DF)

SS solicita a CA cierre de conexión (FIN)

62 F 01:38:09.495457 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1045: . ack 543 win 32120 <nop,nop,timestamp 638012585196> (DF)


63 F 01:38:09.496104 pico.50.129.IN-ADDR.ARPA.1056 >129.50.3.1.1080: . ack 2327 win 7907 (DF)


64 F 01:38:10.408902 pico.50.129.IN-ADDR.ARPA.1056 >129.50.3.1.1080: F 571:571(0) ack 2327 win 7907 (DF)

CA solicita a SS cierre de conexión (FIN)

65 F 01:38:10.409166 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1056: . ack 572 win 32120 (DF)


66 F-4 01:38:21.213993 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1046: F 2611:2611(0) ack 312 win 32120<nop,nop,timestamp 639184 584759> (

SA solicita a SS cierre de conexión (FIN)


67 F-4 01:38:21.214473 129.50.4.1.1046 > bariloche.50.129.IN-ADDR.ARPA.www: . ack 2612 win 31856 <nop,nop,timestamp 586368639184> (DF)


68 F-4 01:38:21.216367 129.50.4.1.1046 > bariloche.50.129.IN-ADDR.ARPA.www: F 312:312(0) ack 2612 win 31856<nop,nop,timestamp 586368 639184> (D

SS solicita a SA cierre de conexión (FIN)

69 F-3 01:38:21.216492 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1057: F 2623:2623(0) ack 341 win 32120 (DF)


70 F-4 01:38:21.217179 bariloche.50.129.IN-ADDR.ARPA.www >129.50.4.1.1046: . ack 313 win 32120 <nop,nop,timestamp 639184586368> (DF)

SA confirma cierre (ACK)

71 F-3 01:38:21.218125 pico.50.129.IN-ADDR.ARPA.1057 >129.50.3.1.1080: . ack 2624 win 8760 (DF)

CA confirma cierre (ACK)


Captura 2

ID CARGA FASETCP


1 01:34:43.963645 arp who-has 129.50.3.1 tell pico.50.129.IN-ADDR.ARPA CA solicita MAC de 129.50.3.1 (SS)



4 I 01:34:44.156024 pico.50.129.IN-ADDR.ARPA.1055 > 129.50.3.1.1080: S6149360:6149360(0) win 8192 <mss 1460> (DF)


5 I 01:34:44.157227 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1055: S200050781:200050781(0) ack 6149361 win 32120 <mss 1460> (DF)

SS acepta (SYN ACK)

6 I 01:34:44.158660 pico.50.129.IN-ADDR.ARPA.1055 > 129.50.3.1.1080: . ack 1 win 8760(DF)

CA acepta (ACK)

7 3 T 01:34:44.167447 pico.50.129.IN-ADDR.ARPA.1055 > 129.50.3.1.1080: P 1:4(3) ack 1 win8760 (DF)


8 T 01:34:44.167764 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1055: . ack 4 win 32120(DF)

ACK de transporte

9 2 T 01:34:44.172400 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1055: P 1:3(2) ack 4 win32120 (DF)

SS indica a CA que la forma de autenticación seleccionada (sin autentificación)


10 26 T 01:34:44.290320 pico.50.129.IN-ADDR.ARPA.1055 > 129.50.3.1.1080: P 4:30(26) ack 3win 8758 (DF)

CA solicita requerimiento de conexión con SA, enviando dirección y puerto

11 01:34:44.299005 arp who-has bariloche.50.129.IN-ADDR.ARPA tell 129.50.4.1 SS solicita MAC de 129.50.4.2 (SA)

12 01:34:44.300234 arp reply bariloche.50.129.IN-ADDR.ARPA is-at 0:40:33:90:20:a5 SA responde a SS su MAC

13 37 01:34:44.300572 129.50.4.1.1027 > bariloche.50.129.IN-ADDR.ARPA.domain: 38020+ A?www.tyr.unlu.edu.ar. (37)



ACK de transporte

15 122 01:34:44.305752 bariloche.50.129.IN-ADDR.ARPA.domain > 129.50.4.1.1027: 38020* 2/1/1CNAME bariloche.tyr.unlu.edu.ar., A bariloche.50.129.IN-ADDR.ARPA (122)

DNS responde a SS acerca de la dirección IP de SA

10 T 01:34:44.321436 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1055: P 3:13(10) ack 30win 32120 (DF)

SS responde a CA que la conexión con SA no está permitida por reglas (DENY)

17 F 01:34:44.324676 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1055: F 13:13(0) ack 30win 32120 (DF)


18 F 01:34:44.325643 pico.50.129.IN-ADDR.ARPA.1055 > 129.50.3.1.1080: . ack 14 win 8748(DF)


19 F 01:34:44.475049 pico.50.129.IN-ADDR.ARPA.1055 > 129.50.3.1.1080: F 30:30(0) ack 14win 8748 (DF)


20 F 01:34:44.475319 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1055: . ack 31 win 32120(DF)



Captura 3

ID CARGA FASETCP







5 I 01:47:49.415747 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1059: S1026063239:1026063239(0) ack 6934813 win 32120 <mss 1460>

SS acepta (SYN ACK)


CA acepta (ACK)




ACK de transporte






11 37 01:47:49.567701 129.50.4.1.1027 > bariloche.50.129.IN-ADDR.ARPA.domain: 46870+ A?www.tyr.unlu.edu.ar. (37)



ACK de transporte

13 122 01:47:49.572325 bariloche.50.129.IN-ADDR.ARPA.domain > 129.50.4.1.1027: 46870* 2/1/1CNAME bariloche.tyr.unlu.edu.ar., A bar

El DNS contesta al SS sobre la dirección IP del SA

14 I-2 01:47:49.587773 129.50.4.1.1048 > bariloche.50.129.IN-ADDR.ARPA.www: S1039819463:1039819463(0) win 32120 <mss 1460,sackOK,t


15 I-2 01:47:49.589189 bariloche.50.129.IN-ADDR.ARPA.www > 129.50.4.1.1048: R 0:0(0) ack1039819464 win 0

SA rechaza la solicitud por no estar disponible el servicio (RST)

16 10 T 01:47:49.593307 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1059: P 3:13(10) ack 30win 32120 (DF)

SS avisa a CA del rechazo de solicitud de conexión con SA

17 F 01:47:49.596717 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1059: F 13:13(0) ack 30win 32120 (DF)




19 F 01:47:49.739810 pico.50.129.IN-ADDR.ARPA.1059 > 129.50.3.1.1080: F 30:30(0) ack 14win 8748 (DF)


20 F 01:47:49.740084 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1059: . ack 31 win 32120(DF)



Captura 4

ID CARGA FASETCP




2 I 01:38:41.143976 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1058: S430197664:430197664(0) ack 6386407 win 32120 <mss 1460> (DF)

SS acepta (SYN ACK)


CA acepta (ACK)




ACK de transporte





8 33 01:38:41.277537 129.50.4.1.1027 > bariloche.50.129.IN-ADDR.ARPA.domain: 9757+ A?www.unlu.edu.ar. (33)


9 33 01:38:41.279907 bariloche.50.129.IN-ADDR.ARPA.domain > 129.50.4.1.1027: 9757ServFail 0/0/0 (33)

DNS contesta indicando que no puede resolver la petición (dado que está aislado)


10 49 01:38:41.280946 129.50.4.1.1027 > bariloche.50.129.IN-ADDR.ARPA.domain: 9758+ A?www.unlu.edu.ar.tyr.unlu.edu.ar. (49)

SS solicita a DNS que resuelva la consulta original agregándoles dominio propio

11 114 01:38:41.282956 bariloche.50.129.IN-ADDR.ARPA.domain > 129.50.4.1.1027: 9758NXDomain* 0/1/0 (114)

DNS contesta indicando que no puede resolver la petición (dado que está aislado)

12 22 T 01:38:41.286746 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1058: P 3:25(22) ack 26win 32120 (DF)

SS informa a CA que no puede realizar una conexión con SA (conexión rechazada)

F 01:38:41.287840 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1058: F 25:25(0) ack 26win 32120 (DF)




15 F 01:38:41.464203 pico.50.129.IN-ADDR.ARPA.1058 > 129.50.3.1.1080: R6386432:6386432(0) win 0 (DF)

CA envía un reset de la conexión (RST)


Captura 5

ID CARGA FASETCP






CA solicita conexión SOCKS con SS (SYN)

5 I 01:50:28.289846 129.50.3.1.1080 > pico.50.129.IN-ADDR.ARPA.1061: R 0:0(0) ack7093725 win 0

SS rechaza la conexión por servicio inexistente (RST)

descripción y análisis funcional del protocolo socks...

Documents