SOCKS es un sistema Proxy equipado con seguridad, auditoria, administración, tolerancia a fallas y notificación de alarmas.

Establece un canal de datos seguro entre dos computadoras dentro de un entorno Cliente-Servidor.

Basándonos en la terminología utilizada para sistemas Proxy podríamos decir que SOCKS es del tipo Proxy de Circuito por lo cual requiere para el cliente Custom Client Software. Estas características hacen de SOCKS un producto general, capaz de proporcionar servicios a múltiples protocolos.

SOCKS es un producto comercial, desarrollado inicialmente David y Michelle Koblas en 1991 y puede obtenerse en forma gratuita.

SOCKS fue diseñado para comunicar aplicaciones Cliente-Servidor basadas en TCP. La aplicación cliente realiza un request a SOCKS para poder comunicarse con el servidor. Este request incluye la dirección del servidor, el tipo de conexión y la identidad del usuario.

Una vez establecido el circuito entre cliente y servidor, SOCKS transmite los datos de la aplicación entre ambos.

Como todos los datos pasan a través de SOCKS, este producto brinda la posibilidad de poder filtrarlos, monitorearlos, auditarlos, etc. Por este motivo, se dice que SOCKS no es simplemente un FIREWALL sino que esta en condiciones de efectuar tareas administrativas en la red.

El siguiente esquema muestra la forma en que se llevan a cabo estas tareas

SOCKS realiza 4 funciones básicas

SOCKS v5 agrega a la versión anterior otras funcionalidades como la de autenticar una conexión, negociar entre el cliente y el servidor el método elegido para realizar dicha autenticación, proveer integridad y privacidad a los mensajes, etc.

Todas estas funciones se llevan a cabo en la etapa en que se establece el circuito de conexión entre un cliente y el servidor. El diagrama de la Figura 2 muestra todas las operaciones realizadas durante una conexión a través de SOCKS.

Figura 2 Operaciones de SOCKS

El software necesario para trabajar con SOCKS contiene

La siguiente figura ilustra la ubicación de estos componentes en la estructura dada por el modelo OSI.

Figura 3 SOCKS en el modelo OSI

En la figura anterior puede verse que un servidor SOCKS actúa en la capa de aplicación y la SOCKS Client Library esta entre la capa de aplicación y transporte del cliente.

Con SOCKS es posible reutilizar el software cliente de manera que se pueda llamar a un servidor de este tipo y utilizar sus servicios. Para lograr esto, se debe recompilar el programa junto con la SOCKS Client Library reemplazando todas las llamadas a la red standard con llamadas de la versión de SOCKS. La siguiente tabla indica los cambios que deben realizarse:

SOCKS v5 soporta dos métodos de autenticación

Además de especificar los métodos de autenticación para una conexión, SOCKS v5 permite negociar entre cliente y servidor la elección del método a utilizar. Para proveer este tipo de negociación SOCKS v5 agrega 2 mensajes. El cliente envía el primer mensaje a SOCKS diciéndole que método de autenticación soporta y este le contesta con el mensaje que el cliente debe usar.

SOCKS determina el método de autenticación en basa a la política de seguridad definida en la configuración del servidor SOCKS.

Si los métodos declarados por el cliente no cumplen los requerimientos de seguridad, SOCKS baja la conexión.

Bajo Kerberos 5, SOCKS v5 puede chequear todos los mensajes, incluyendo los pedidos de conexión de los clientes, las respuestas de SOCKS v5 y los datos de la aplicación.

SOCKS es un producto muy usado y quizás esta popularidad sea una de sus ventajas. Los componentes de SOCKS pueden obtenerse fácilmente.

La generación de logs durante una conexión no es lo suficientemente detallada.