Universidad Nacional de Luján Departamento de Ciencias Básicas División Estadística y Sistemas Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5 Gabriel Tolosa Fernando Bordignon Abril – 2001 La presente obra es propiedad intelectual del autor. Prohibida su reproducción parcial o total por cualquier medio, sin permiso por escrito de su editor.
36
Embed
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5 · 2003-08-28 · Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5 Primera Sección Firewalls
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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:
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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.
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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).
Estructura del mensaje
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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).
Estructura del mensaje
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.
Estructura del mensaje
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 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:
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
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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.
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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í:
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.
@ IN SOA bariloche.tyr.unlu.edu.ar.ght.bariloche.tyr.unlu.edu.ar. (
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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.
@ 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: 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:
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.
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.
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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.
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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)
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
Cantidad de segmentos en fase inicio 3Cantidad de segmentos en fase de fin 2Cantidad de segmentos en transferencia 10(7 con datos de aplicación y 3 sin datos de aplicación)
Conexión 4 - SS 129.50.4.1:1046 - SA 129.50.4.2:80
Cantidad de segmentos en fase inicio 3Cantidad de segmentos en fase de fin 4Cantidad de segmentos en transferencia 6(3 con datos de aplicación y 3 sin datos de aplicación)
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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).
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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).
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5
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
Descripción y Análisis Funcional del Protocolo SOCKS, Versión 5