Durante las primeras décadas de su existencia, las redes de computadoras fueron usadas principalmente por investigadores universitarios para el envío de correo electrónico, y por funcionarios corporativos para compartir impresoras. En estas condiciones, la seguridad no recibió mucha atención. Pero ahora, cuando millones de ciudadanos comunes usan redes para sus transacciones bancarias, compras y declaraciones de impuestos, la seguridad de las redes surge en el horizonte como un asunto potencial de masivos proporciones. En las próximos secciones estudiaremos la seguridad de las redes desde varios ángulos, señalaremos muchos peligros y estudiaremos varios algoritmos y protocolos para realizar más seguras las redes. La seguridad es un asunto amplio que cubre una multitud de pecados. En su manera más sencilla, la seguridad se ocupa de garantizar que los curiosos no puedan leer, o peor aún, adaptar mensajes dirigidos a otros destinatarios. Tiene que ver con la gente que intenta alcanzar a servicios remotos no autorizados. También se ocupa de mecanismos para comprobar que el mensaje supuestamente enviado por la autoridad fiscal que indica: ?Pague el viernes o aténgase a las consecuencias? realmente venga de ella y no de la mafia. La seguridad también se ocupa del asunto de la captura y reproducción de mensajes legítimos, y de la gente que intenta negar el envío de mensajes. Los dificultades de seguridad de las redes pueden partirse en términos globales en cuatro áreas interrelacionadas: confidencialidad, autenticación, no repudio y control de integridad. La confidencialidad consiste en mantener la información afuesera de las manos de usuarios no autorizados. Esto es lo que usualmente viene a la mente cuando la gente pensad en la seguridad de las redes. La autenticación se encarga de decidir con quién se está hablando antes de descubrir información delicada o realizar un trato de negocios. El no repudio se encarga de las firmas: ¿cómo verificar que su cliente realmente hizo un pedido electrónico por 10 millones de utensilios para zurdos a 89 centavos cada uno cuando él despues aduce que el precio era de 69 centavos? O tal vez argumente que él jamás elaboró ningún pedido. Por último, ¿cómo puede asegurarse de que un mensaje recibido realmente fuese enviado, y no algo que un adversario malicioso modificó en el sendero o cocinó por su particular cuenta? 7.1  Redes Seguras y Políticas de Seguridad En un ámbito de red debe asegurarse la privacidad de los datos sensibles. No sólo es significativo asegurar la información sensible, sino también, proteger las operaciones de la red de daños no intencionados o deliberados. El mantenimiento de la seguridad de la red necesita un equilibrio entre facilitar un entrada sencillo a los datos por fracción de los usuarios autorizados y restringir el entrada a los datos por fracción de los no autorizados. Es responsabilidad del administrador crear este equilibrio. Incluso en redes que controlan datos sensibles y financieros, la seguridad a veces se estima medida tardía. Las cuatro amenazas principales que afectan a la seguridad de los datos en una red son: Acceso no autorizado. Soborno electrónico p dir="ltr Robo. Daño intencionado o no intencionado. La seguridad de los datos no siempre se implementa de manera apropiada, precisamente por la seriedad de estas amenazas. La tarea del administrador es asegurar que la red se mantenga fiable y segura. En definitiva, abierta de estas amenazas. La magnitud y nivel requerido de seguridad en un sistema de red depende del tipo de ámbito en el que labora la red. Una red que almacena datos para un banco importante, necesita una gran seguridad que una LAN que enlaza equipos en una pequeña organización de voluntarios. Permisos de entrada La seguridad basada en autenticación de usuario es la más usada, nos faculta administrar y asignar derechos a los usuarios de la red. Permitiendo o denegando los entradas a los recursos a través de una fundamento de datos en el servidor. El esfuerzo del administrador deberá incluir la administración de usuarios. Otra forma de administrar usuarios es mediante el uso de grupos de usuarios, el cual nos da la facilidad de aplicar las políticas de seguridad a grupos particulares los cuales heredarán estas a los miembros de dicho grupo. Medidas Adicionales Se debe beber en cuenta el uso de cortafuegos que permita administrar el entrada de usuarios de otras redes así como el monitorear las actividades de los usuarios de la red, permitiendo el tener una bitácora de sucesos de red. Las bitácoras son de mayor utilidad para aplicar auditorias a la red. La revisión de los registros de eventos dentro de la red faculta ver las actividades de los usuarios dentro de la red, esto faculta al administrador darse cuenta de los entradas no autorizados por fracción de los usuarios y beber las medidas que faciliten incrementar la seguridad. La auditoria faculta monitorear determinadas de las próximos actividades o funciones Intentos de acceso. Conexiones y desconexiones de los recursos designados. Terminación de la conexión. Desactivación de cuentas. Apertura y cierre de archivos. Modificaciones realizadas en los archivos. Creación o borrado de directorios. Modificación de directorios. Eventos y transformaciónes del servidor. Modificaciones de las contraseñas. Modificaciones de los parámetros de entrada. Prevención Se debe tener políticas de prevención contra estas amenazas que ponen en riesgo la integridad de la red. Esto se puede evitando abrir correos sospechosos, entrar en paginas de Internet con contenidos pornográficos, de juegos y páginas sospechosas. Instalar proyectos antivirus. Actualmente hay una mayor variedad de proveedores de estos servicios, hay que escoger el que más se adapte a nuestras necesidades. Algunos cuentan con detectores de spyware, robots, antispam, entre otras amenazas potenciales. La seguridad en redes WLAN Por la misma naturaleza de las redes inalámbricas que emplean como recurso físico de transmisión el aire el agente de seguridad es crítico. La seguridad de este tipo de redes se ha basado en la implantación de la autenticación del punto de entrada y los clientes con fichas inalámbricas permitiendo o denegando los entradas a los recursos de la red. Políticas de Seguridad en Redes Las decisiones en cuanto a medidas de seguridad para un sitio determinan, obviamente, que tan segura será la red y, además, qué nivel de funcionalidad ofrecerá y qué tan sencillo será de usar. Estas decisiones deben ser antecedidas por la determinación de los metas de seguridad, que permitirán resolver la selección de las dispositivos que harán efectivos tales metas. Estos metas serán distintos para cada organización porque dependen de sus necesidades. Están muy relacionados con algunos puntos de equilibrio claves tales como: Servicios ofrecidos vs. La seguridad provista: cada servicio ofrecido a un usuario tiene su propio riesgo de seguridad. Facilidad de uso vs. Seguridad: un sistema muy sencillo de usar permitirá el entrada a casi todos los usuarios y por lo tanto serán menos seguro. Costo de la seguridad vs. Riesgo de pérdida: tienen lugar muchos costos de seguridad: monetarios, de desempeño y facilidad de uso. Los riesgos de pérdida pueden ser de privacidad, de datos, y servicios. Cada tipo de costo debe ser balanceado con respecto a cada tipo de pérdida. Una vez definidos los objetivos, deben ser comunicados a todos los usuarios de la red de la organización e implementados a través de un conjunto de normas de seguridad, llamadas ?política de seguridad?. ?Una política de seguridad es un pronunciado formal de las normas que los usuarios que acceden a los recursos de la red de una organización deben cumplir? [RFC-2196]. El meta principal del uso de una política de seguridad es: Informar a los usuarios de la red sus obligaciones para proteger a los recursos de la red. Especificar los mecanismos a través de los cuales estos requerimientos pueden ser logrados. Proveer una guía que permitirá implementar, configurar y controlar los sistemas de la red para decidir su conformidad con la política. Una política de seguridad debe asegurar cuatro apariencias fundamentales en una solución de seguridad: autenticación, control de acceso, integridad y confidencialidad. A dividir de estos, aparecen los principales componentes de una política de seguridad: Una política de privacidad: determina expectativas de privacidad con respecto a funciones como monitoreo, registro de actividades y entrada a recursos de la red. Una política de entrada: que faculta definir derechos de entrada y privilegios para proteger los metas clave de una pérdida o exposición mediante la especificación de guías de uso aceptables para los usuarios con respecto a conexiones externas, comunicación de datos, conexión de herramientas a la red, inclusión de nuevo software a la red, etc. Una política de autenticación: que constituye un servicio de confiabilidad mediante cierta política de contraseñas o mecanismos de firmas digitales, estableciendo guías para la autenticación remota y el uso de herramientas de autenticación. Un sistema de IT (tecnología de la información) y una política de administración de la red: detalla cómo pueden manipular la tecnologías los encargados de la administración interna y externa. De aquí aparece la consideración de si la administración externa será soportada y, en tal caso, cómo será controlada. 7.2  Herramientas de empleo de red (NIS, NFS NIS:Network Information Service (conocido por su acrónimo NIS, que en español implica Sistema de Información de Red), es el nombre de un protocolo de servicios de directorios cliente-servidor extendido por Sun Microsystems para el envío de datos de configuración en sistemas distribuidos tales como nombres de usuarios y hosts entre computadoras sobre una red. NIS está basado en ONC RPC, y consta de un servidor, una biblioteca de la fracción cliente, y algúnas dispositivos de administración. Originalmente NIS se llamaba Páginas Amarillas (Yellow Pages), o YP, que todavía se emplea para mencionarse a él. Desafortunadamente, ese nombre es una marca registrada de British Telecom, que exigió a Sun dejar ese nombre. Sin embargo YP permanece como prefijo en los nombres de la mayoría de las órdenes vinculadas con NIS, como ypserv e ypbind. DNS sirve un rango limitado de información, siendo la más significativo la correspondencia entre el nombre de nodo y la dirección IP. Para otros tipos de información, no tiene lugar un servicio especializado así. Por otra parte, si sólo se administra una pequeña LAN sin conectividad a Internet, no parece que merezca la pena configurar DNS. Ésta es la razón por la que Sun desarrolló el Sistema de Información de Red (NIS). NIS ofrece prestaciones de entrada a fundamentos de datos genéricas que pueden utilizarse para distribuir, por ejemplo, la información contenida en los archivos passwd y groups a todos los nodos de su red. Esto hace que la red parezca un sistema individual, con las mismas cuentas en todos los nodos. De forma similar, se puede usar NIS para distribuir la información de nombres de nodo contenida en /etc/hosts a todas las máquinas de la red NFSEl Network File System [](Sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un ámbito de red de computadoras de área local. Permite que diferentes sistemas conectados a una misma red accedan a archivos remotos como si se tratara de locales. Originalmente fuesese extendido en 1984 por Sun Microsystems, con el meta de que sea independiente de la máquina, el sistema operativo y el protocolo de transporte, esto fuesese probable gracias a que está implementado sobre los protocolos XDR (presentación) y ONC RPC (sesión).1 El protocolo NFS está incluido por defecto en los Sistemas Operativos UNIX y la mayoría de distribuciones Linux. Los servicios de NIS y NFS son fracción de los servicios llamados RPC y son complementarios. NFS es un protocolo que data de los años 80. En esas fechas los dificultades de seguridad eran menores. Todavia podian construirse protocolos basados en la confianza, tanto el servidor como el cliente confiando en la información que intercambian. Internet convierte este comienzo en algo absurdo y este es sin duda uno de los mayores dificultades de NFS. La version 2 del protocolo es la primera version publicada y Seguid la siendo la mas extendida en vuestros dias. Existen implementaciones sobre algúnas plataformas distintos y se han descrito escasos dificultades de compatibilidad. La versión 3 del protocolo data de 1992 y muestra algúnas mejoras: Mejora del rendimiento debido a la reescritura del código de la red, y al     uso de paquetes de datos mayores. Mejora en la seguridad: Listas de ACL (Listas de control de entrada) que facultan difinir entrada a los recursos por UID y fichero a fichero. Implementación de un sistema de autentificación basado en contraseña. Por desgracia, la versión 3 de NFS para Linux esta todavia en pañales. NFS para GNU/Linux es intrínsecamente inseguro y peligroso si se administra mal. Debemos hablar de los servicios RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) el cual es un protocolo que faculta a un proyecto de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un mayor avance sobre los sockets usados hasta el momento. De esta forma el proyectodor no tenía que estar zarcillo de las comunicaciones, estando éstas encapsuladas dentro de las RPC. Es indispensable conocer esto, ya que la implementación de un protocolo NFS es por lo común sobre un RPC. Los servicios de RPC tienen en comun masivos agujeros de seguridad. Estos servicios son ya viejos, y en su epoca las redes eran mucho mas cerradas. Los fallos de los servicios de RPC son altamente conocidos y explotados sobre Internet. Una de las normas escenciales cuando utilizamos un servicio RPC es restringir el entrada a la red local y no hacer exports de manera descontrolada. Incluso en una red local, hay que saber que las contraseñas circulan sin encriptar sobre la red. Cualquier máquina puede ?escuchar? los intercambios entre un cliente NIS y el servidor y encontrar un buen número de contraseñas. Por defecto no se emplea ningún algoritmo de cifrado. Para colocar en servicio un cliente de NFS, hay que asegurarse de que el kernel de Linux que estamos usando tiene compilado el soporte para NFS. Para montar una partición hay que conocer algunos parámetros: el nombre del servidor el nombre de la partición a la que se quiere alcanzar el nombre del directorio donde vamos a montar la partición NFS. La sintaxis del comando mount es la siguiente: mount -t nfs maquina:/particion/a/montar /punto/de/montaje Nota : Se puede facilitar el montaje de una partición si la incluimos en el /etc/fstab para que se monte al iniciarse el sistema. Podríamos usar determinadas alternativas de montaje para dotar de gran seguridad el sistema. La alternativa -o nosuid quita el bit SUID sobre los ejecutables montados por NFS. Esto puede resultar molesto si estamos montando /usr pero tiene sentido si estamos montando particiones de datos. La alternativa -o noexec es todavía más radical, ya que imposibilita la ejecución de proyectos desde la partición montada por NFS. Si poseemos usuarios que redactan scripts esta alternativa puede ser muy molesta 7.3  Seguridad en aplicaciones cliente / servidor La tecnología Cliente/Servidor es el procesamiento cooperativo de la información por recurso de un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan requerimientos a uno o más servidores centrales. Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que faculta a los usuarios finales conseguir entrada a la inmaneración de manera transparente aún en ámbitos multiplatamanera. Se trata pues, de la arquitectura más extendida en la realización de Sistemas Distribuidos. Un sistema Cliente/Servidor es un Sistema de Información distribuido basado en las próximos características: Servicio: unidad escencial de diseño. El servidor los ofrece y el cliente los utiliza. Recursos compartidos: Muchos clientes emplean los mismos servidores y, a través de ellos, comparten tanto recursos lógicos como físicos. Protocolos asimétricos: Los clientes inician ?conversaciones?. Los servidores aguardan su establecimiento pasivamente. Transparencia de localización física de los servidores y clientes: El cliente no tiene porqué saber dónde se descubre ubicado el medio que quiere utilizar. Independencia de la plataforma HW y SW que se emplee. Sistemas débilmente acoplados. Interacción basada en envío de mensajes. Encapsulamiento de servicios. Los detalles de la implementación de un servicio son transparentes al cliente. Escalabilidad horizontal (añadir clientes) y vertical (ampliar potencia de los servidores). Integridad: Datos y proyectos centralizados en servidores facilitan su integridad y mantenimiento. En el modelo normal Cliente/Servidor, un servidor, (daemon en la terminología sajona basada en sistemas UNIX/LINUX, traducido como ?demonio?) se activa y aguarda las solicitudes de los clientes. Habitualmente, proyectos cliente múltiples comfracciónn los servicios de un proyecto servidor común. Tanto los proyectos cliente como los servidores son con frecuencia fracción de un proyecto o aplicación mayores. El Esquema de funcionamiento de un Sistema Cliente/Servidor sería: El cliente solicita una información al servidor. El servidor recibe la petición del cliente. El servidor procesa felicidad solicitud. El servidor envía el fruto obtenido al cliente. El cliente recibe el fruto y lo procesa. MIDDLEWARE El middleware es un módulo intermedio que actúa como conductor entre sistemas permitiendo a cualquier usuario de sistemas de información comunicarse con algúnas fuentes de información que se encuentran conectadas por una red. En el caso que nos concierne, es el intermediario entre el cliente y el servidor y se ejecuta en ambas partes. La utilización del middleware faculta construir aplicaciones en arquitectura Cliente/Servidor independizando los servidores y clientes, facilitando la interrelación entre ellos y evitando dependencias de tecnologías propietarias. El concepto de middleware no es un concepto nuevo. Los primeros * monitores de teleproceso* de los masivos sistemas basados en tecnología Cliente/Servidor ya se basaban en él, pero es con el nacimiento de la tecnología basada en sistemas abiertos cuando el concepto de middleware coge su máxima importancia. El middleware se articula en tres niveles: Protocolo de transporte. Network Operating System (NOS). Protocolo particular del servicio. Las principales características de un middleware son: Simplifica el proceso de desarrollo de aplicaciones al independizar los ámbitos propietarios. Permite la interconectividad de los Sistemas de Información del Organismo. Ofrece gran control del negocio al poder contar con información procedente de diferentes plataformas sobre el mismo soporte. Facilita el desarrollo de sistemas complejos con distintos tecnologías y arquitecturas. Dentro de los inconvenientes más significativos destacan la gran carga de máquina necesaria para que puedan funcionar. Seguridad Cliente-Servidor Seguridad Punto a Punto Dentro de la seguridad punto a punto, las alternativas más recomendadas al momento de aplicarla son SSL y TSL. SSL actualmente se descubre en su versión 3.0 y constituye una mejor comunicación entre un cliente y el servidor utilizando algoritmos avanzados de encriptación.Con SSL, se constituye una comunicación dedicada entre el servidor y el cliente donde se construye un canal destinado y encriptado para la comunicación. Las sesiones de seguridad SSL en servidores son muy comunes para aplicaciones de comercio electrónico. Los usuarios pueden revisar su conexión SSL directamente desde sus navegadores, y así conseguir información del tipo de algoritmo que está siendo usado en la negociación. Si el proveedor del certificado no es confiable, ya sea porque el certificado expiró o ha sido removido, el usuario recibe una advertencia. Seguridad End-to-End Las transacciones en línea, en determinadas ocasiones pueden involucrar más de dos entes. La seguridad End-to-End es de crucial relevancia para las interacciones de los servicios web, en donde se realizan operaciones que demandan altos niveles de seguridad por recurso de controles que el propio nivel de seguridad exija, tales como claves cifradas, algúnas formas de autenticación, etc. Autenticación y Autorización Autenticación La autenticación se refiere a comprobar la identidad del usuario, es decir, a someterlo a un proceso de validación de su identidad para afirmar que elusuario es quien dice ser. El mecanismo más utilizado para este objetivo es de login/password. El usuario provee su nombre y contraseña para autenticarse. Se recomienda no transmitir la inmaneración de origen de sesión en texto plano, sino más bien utilizar conexiones SSL.Otra manera de autenticar a los usuarios es utilizando certificados digitales, pero este método ya no es ampliamente usado en aplicaciones B2C y ha tenido un repunte en aplicaciones B2B o en la autenticación de usuarios en una intranet corporativa. Autorización Las políticas de autorización, por su parte, especifican lo que los usuarios autenticados son capaces de hacer. Uno de los métodos de control para este fin es el DAC (Discretionary Access Control),que labora de acuerdoa los privilegios o prohibiciones asignadas a los usuarios. Las listas de control de entrada son el mejor ejemplo de un sistema DAC; faculta o restringe el entrada a recursos, información, tanto a un usuario como a un grupo de usuarios. Si el número de usuarios de una aplicación web tiende potencialmente a aumentar en masivos cantidades, la mejor opción es utilizar un sistema de control de entrada basado en roles o RBAC para mejorar la escalabilidad y reducir el trabajo de administración de la aplicación web. Los derechos o prohibiciones son asignados a los roles que cumple cada usuario en espacio de a los recursos e información Problemas en la seguridad de los clientes Si la información personal es intercambiada mientras operaciones en línea,los usuarios deben estar seguros que los respectivos proveedores del servicio les garanticen que sus datos son manejados de una forma confiable. La privacidad de los datos de los usuarios no puede ser unicamente intervenida mientras el proceso de transferencia de la misma con el proveedor, sino que también ha tenido un mayor crecimiento las nuevas técnicas como phishing y web Spoofing, que son tratadas en un artículo más adelante. Resguardando la información Cuando se emplean sesiones SSL, los usuarios tienen la tranquilidad de una transferencia segura de su información, pero no pueden decidir cómo esta información es manejada despues de que se completa la transferencia. De esta manera, los proveedores deben establecervínculos de relación confiable con los usuarios antes de que éstosempiecen a transferir información.La plataforma para preferencias privadas o P3P, propuesta por el W3C 27 ,brinda un estándar para la declaración de políticas de protección deinformación en un formato XML legible para las máquinas, y que se puedemostrar a los usuarios finales como políticas de seguridad. Los clientes igualmente pueden declarar sus preferencias de privacidad empleando factores de P3P que vienen incorporados en la mayoría de los navegadores que utilizamos hoy en día. Si no se detectan conflictos de privacidad, la aplicación web es mostrada al usuario, caso contrario, se obtienen datos del asunto detectado y se presenta un mensaje en formato legible para el usuario, dando una aclaración del por qué del 27 W3C, disponible en: Phishing and Web Spoofing El término Phishing es una abreviación para el proceso de captura de información privada. Estos ataques son efectuados con la intención clara de conseguir información personal como números de seguro social,números de fichas de crédito que pueden ser usadas para suplantación de identidad o fraudes comerciales. Este tipo de ataque afecta especialmente a clientes de organizaciones financieras. El método más usado es enviar correos electrónicos suplantando la identidad de un representante de la organización, pidiendo información al usuario para distintos actualizaciones de servicios; de esta forma, el usuario ingresa su información y se efectúa el daño.En cambio, el término Web Spoofing se refiere a un conjunto de técnicas que procuran simular la presencia de una web en una organización con la finalidad de engañar a los clientes a través de sitios web convincentes,proveedores de correo semejantes y URLs reales. Tanto los ataques de Phishing como de Web Spoofing no sólo causan daños a los usuarios finales sino que también implican un perjuicio para los proveedores de servicios. Esfuerzos administrativos y financieros están siendo dedicados día a día para contrarrestar los efectos de estos ataques y informar al usuario tan pronto como sea posible. Actualmente la transferencia se está realizando mediante el uso de fichas inteligentes en espacio de mecanismos PIN/TAN que emplean las fichas de crédito hoy en día Seguridad de escritorio Otros agentes que influyen en la seguridad son las amenazas causadas por virus y gusanos. Es responsabilidad de cada usuario el contrarrestar estas amenazas, mantenimiento sus sistemas actualizados, navegando por sitios seguros, utilizando antivirus o firewalls, etc. 7.4 Consideraciones para WWW CONSIDERACIONES  PARA WWW Seguridad WEB Web es el espacio donde la mayoría de las Trudies vagan en la actualidad y tratan de hacer esfuerzo sucio. Analizaremos algunos de los dificultades y cuestiones que se realizan con la seguridad en WEB. La seguridad en WEB se puede partir en tres partes. La primera, ¿Cómo se nombran de forma segura los objetos y los recursos? Segunda ¿Cómo pueden establecer las conexiones seguras y autenticadas? Tercera ¿Qué sucede cuando un sitio web envía al cliente una pieza del código ejecutable? ALGUNAS AMENAZAS EN LA WEB Algunas páginas de origen de determinadas organizaciones han sido atacadas y reemplazada por una nueva página de origen de la elección de los crackers (personas que irrumpen sin permiso a las computadoras de otra persona) Entre los sitios que han sido atacados por los crackers se incluye Yahoo, El ejército de Estados Unidos, la CIA, la NASA, y el New York Times. En muchas ocasiones, los crackers solo han colocado simples textos graciosos y los sitios fueron reparados en determinadas horas. En algunos casos más serios muchos sitios han sido derribados por ataques de negación de servicio, en los que el cracker inunda con tráfico el sitio, dejándolo incapacitado de contestar a consultas legítimas. Con frecuencia, el ataque se realiza desde algúnas máquinas en las que el cracker ya ha irrumpido (ataques DDoS). Estos ataques son tan comunes que ya no son noticias, pero puede costar al sitio agredido miles de dólares en negocios perdidos. Entre las amenazas que se deben de beber en cuenta son estas dos: Nombres no auto certificable y falsificación de DNS, para esto a continuación veremos dos métodos o medidas con las que podemos eludir que este tipo de amenazas cumplan su cometido. DNS SEGURO El ataque particular de la falsificación de DNS se puede frustrar al realizar que los servidores DNS utilicen IDs aleatorios en cualquiera de las consultas en espacio de solo contar, pero parece que cada vez que se tapa un hoyo, otro se destapa. El asunto real es que el DNS se diseñó en la estación en la que internet era una dispositivo de investigación para determinadas cuentas de universidades y en la que se daban este tipo de ataques. Conformepasóo el tiempo el ámbito ha cambiado radicalmente, porque en ¡))$ el IETD estableció un grupo funcional para que realizar que el DNS afuera seguro. Este programa se dio a conocer como DNSsec (seguridad DNS); su salida se muestra en el RFC 2535. Desgraciadamente, DNSsec aún no se ha distribuido por completo, por lo que numerosos servidores DNS aún son vulnerables a ataques de falsificación. DNSsec es un concepto muy sencillo. Se cimienta en la criptografía de clave pública. Cada zona DNS tiene un par de claves pública/privada. Toda la información enviada por un servidor DNS se firma con la clave privada de la zona originaria, por lo que el receptor puede comprobar su autenticidad. DNSsec proporciona tres servicios fundamentales: 1.- Prueba de donde se originaron los datos. 2.- Distribución de la clave pública. 3.- Autenticación de transacciones y solicitudes. El servidor principal es el que se lista primero, el cual verifica que los datos que se están volviendo han sido aprobados por el dueño de la zona. El segundo es provechoso para Guardar y recuperar de forma segura las claves públicas. El tercero es indispensable para proteger contra ataques de repetición y falsificación. La confidencialidad no es un servicio ofrecido ya que que toda la información en el DNS se estima como pública. Los registros DNS están agrupados en conjuntos llamados RRSets (conjunto de registro de recursos), en los que todos los registros tienen el mismo nombre, clase y tipo en un conjunto. DNSsec introduce varios tipos nuevos de registro. El primero de estos es el registro Key. Estos registros mantienen la clave pública de una zona, usuario, host u otro personaje principal, el algoritmo criptográfico utilizado para firmar, el protocolo utilizado para transmisión y otros bits. La clave pública se almacena tal como está. Los certificados X.509 no se emplean debido a su volumen. El tema de algoritmo contiene 1 para las firmas MD5/RSA (la alternativa preferida) y otros valores para otras combinaciones. El tema de protocolo puede indicar el uso de IPsec y otros protocolos de seguridad, si es que hay. SIG es el segundo nuevo tipo de registro. Contiene el hash firmado de acuerdo con el algoritmo especificado en el registro KEY. La firma se aplica a todos los registros del RESet, incluyendo a cualquiera de los registros KEY presentes, pero excluyéndose a sí mismo. También contiene la fecha en la que la firma inicia su periodo de validación y cuando esta expira, así como el nombre de quien la firma y algunos otros elementos. El diseño del DNSsec tiene la característica de que es probable mantener sin conexión una clave privada de una zona. Una o dos veces al día, el contenido de una fundamento de datos de una zona puede transportarse se manera manual (por ejemplo en un CD) a una máquina desconectada en la que se encuentra una clave privada. Todos los RRSets pueden firmarse ahí y los registros SIG producidos de esa manera pueden transportarse al servidor primario de la zona de CD. De esta manera, la clave privada puede almacenarse en un CD guardado en manera segura excepto cuando se inserta en la máquina desconectada para firmar los nuevos RRSets del día. Después de que se finaliza el proceso de firma, todas las copias de la clave se eliminan de la memoria y el disco y el CD son guardados. Este procedimiento reduce la seguridad electrónica a seguridad física. Este método de pre firmar los RRSets crece la velocidad de forma considerable el proceso de contestar consultas ya que que no es indispensable hacer criptografía sobre la marcha. La desventaja consiste en que se requiere una mayor porción de lugar en disco para Guardar todas las claves firmadas en las fundamentos de datos DNS. Algunos registros incrementará diez veces el dimensión debido a la firma. Cuando un proceso de cliente obtenga un RRset firmado, debe aplicar la clave pública de la zona originaria para desencriptar el hash, calcular el hash mismo y comparar los dos valores. Si concuerdan, los datos se estiman válidos. Sin embargo, este procedimiento asume la manera de como obtiene el cliente la clave pública de la zona. Una manera es adquirirla de un servidor confiable, utilizando una conexión segura (por ejemplo, utilizando IPsec). NOMBRES AUTOCERTIFICABLES El DNS seguro no es la única probabilidad para asegurar los nombres. Un método completamente distinto se emplea en el  Sistema de Ficheros Seguros. En este programa los autores (Mazieres y Cols) diseñaron un sistema de ficheros seguro y escalable a nivel mundial, sin adaptar el DNS (estándar) y sin utilizar certificados o suponer la existencia de una PKI. Comenzaremos suponiendo que cada servidor WEB tiene un par de claves pública/privada. La esencia de la idea es que cada URL contiene un hash criptográfico del nombre del servicio y una clave pública como fracción del URL. Con el hash, es un URL auto certificable. ¿Para qué es el hash? Este se calcula concatenando el nombre DNS del servidor con la clave pública del servidor y ejecutando el fruto mediante la función SHA-1 para conseguir un hash de 160 bits. En este esquema el hash se representa como una secuencia de 32 dígitos y letras minúsculas, a excepción de las letras ?l? y ?o? y los dígitos ?1? y ?0?, para eludir la confusión. Esto deja 32 dígitos y letras. Con 32 caracteres puede contener el hash SHA-1 de 160 bits. Realmente, no es indispensable utilizar el hash; puede utilizarse la clave misma. La ventaja del hash es que reduce la extensión del nombre. Otra manera de conseguir URLs auto certificables podría ser conectándose con una máquina de búsqueda confiable tecleando su URL auto certificable (la primera vez) e ir a través del mismo protocolo como se describió anteriormente, lo que produciría una conexión autenticada segura con la máquina de búsqueda confiable. A continuación podría consultarse felicidad máquina de búsqueda y los frutos aparecerían en una página firmada lleva de URLs auto certificables en los que se podría realizar clic sin tener que teclear cadenas largas. SSL ? La capa de Sockets Seguros El próximo paso sobre seguridad en WEB son las conexiones seguras. Con el paso del tiempo internet solo dejo de ser paginas estáticas y comenzó a ser utilizada para transacciones financieras, operaciones bancarias en línea, uso de fichas de crédito, comercio electrónico, etc. Estas aplicaciones crearon una demanda de conexiones seguras por lo cual en 1995 Netscape Communications Corp lanza un paquete de seguridad llamado  SSL (capa de sockets seguros).  En la actualidad este paquete se usa ampliamente, inclusive por internet Explorer. SSL construye una conexión segura entre los dos sockets, incluyendo: 1.- Negociación de parámetros entre el cliente y el servidor. 2.- Autenticación tanto del cliente como del servidor. 3.- Comunicación secreta. 4.- Protección de la integridad de los datos. SSL es una nueva capa colocada entre la capa de aplicación y la de transporte, que acepta solicitudes del navegador y enviandolas al TCP para transmitir al servidor. Una vez que se ha establecido la conexión segura, el esfuerzo principal de SSL es manejar la compresión y encriptación. Cuando HTTP se emplea arriba de SSL, se conoce como HTTPS (HTTP seguro), aunque es el protocolo HTTP estándar. Sin embargo determinadas veces está disponible en un nuevo puerto (443) en espacio de en uno estándar (80). Además, SSL no está restringido a emplearse sólo o con navegadores WEB, por eso es la aplicación más común. SSL soporta una variedad de algoritmos y alternativas diferentes. Entre felicidades alternativas se incluyen la presencia o ausencia de compresión, los algoritmos criptográficos a utilizar y algunos temas relacionados con la exportación de restricciones en la criptografía. La última es la destinada principalmente para asegurarse que se utilice criptografía seria solo cuando ambos lados de la conexión estén en los Estados Juntos. En otros casos, las claves se limitan a 40 bits, lo que los criptógrafos estiman una broma. El gobierno de los Estados Juntos obliga a Netscape a incluir esta restricción para conseguir una licencia de exportación. SSL consiste en dos subprotocolos, uno para establecer una conexión segura y otro para utilizarla. Como se mencionó anteriormente, SSL soporta múltiples algoritmos criptográficos. El más robusto emplea triple DES con tres claves separadas para encriptación y SHA-1 para la integridad de mensajes. Esta mezcla es relativamente lenta, por lo que se emplea principalmente para operaciones bancarias y otras aplicaciones en las que se necesita la seguridad de gran nivel. Para las aplicaciones comunes de comercio electrónico, se emplea RC4 con una clave de 128 bits para encriptación y MD5 se emplea para la autenticación de mensajes. RC4 coge la clave de 128 bits como semilla y la expande a un número mucho más grande para uso interno. A este se le aplica un OR exclusivo con el texto llano para proporcionar un cifrado clásico de flujo. Las versiones de exportación también emplean RC4 con claves de 128 bits, 88 de los cuales se hacen públicos para que el cifrado sea sencillo de romper. Para un transporte real se emplea un segundo subprotocolo. Los mensajes que provengan del navegador primero se dividen en unidades de hasta 16 KB. Si se activa la compresión, cada unidad se comprime por separado. Después de eso, se deriva una clave secreta a dividir de las dos marcas aleatorias t la clave premaestra se concatena con el texto comprimido y al fruto se le aplica un hash con el algoritmo de hash acordado (por lo común MD5). Este hash se añade a cada pedazo como el MAC. Después el pedazo comprimido y el MAC se encriptan con el algoritmo de encriptación simétrico acordado (por lo común, aplicando un OR exclusivo con el flujo de claves RC4). Por último, se añade un encabezado de pedazo y el pedazo se transmite a través de la conexión TCP. Es necesaria una advertencia. Puesto que se ha probado que el RC4 tiene claves débiles que pueden criptoanalizarse con facilidad, la seguridad de SSL mediante RC4 no es muy confiable. Los navegadores que facultan que el usuario elija el conjunto de cifrado deben configurarse para utilizar todo el tiempo el triple DES con claves de 168 bits y SHA-1, aunque esta mezcla es más lenta que RC$ y MD5. Otro asunto con SSL es que tal vez los personajes principales no tienen certificados e inclusive si los tienen, no siempre verifican que coincidan las claves que se utilizan. Seguridad de código móvil Cuando las páginas web eran solo estáticas no contenían código ejecutable, ahora con frecuencia encontramos páginas con pequeños programas, incluyendo subprogramas de java, controles ActiveX y JavaScript. Descargar y ejecutar tal  código móvil  obviamente es un riesgo de seguridad masivo, por lo que se han diseñado varios métodos para minimizarlo. Seguridad de subprogramas Java Los subproyectos de Java son pequeños proyectos de Java compilados a un lenguaje de maquina orientado a pilas llamado JVM (Java Virtual Machine). Pueden colocarse en una página web para descargarlos junto con felicidad página. Después de que la página se carga, los subproyectos se insertan en un intérprete JVM dentro del navegador. La ventaja de ejecutar código interpretado en espacio de compilado es que cada instrucción es examinada por el intérprete antes de ser ejecutada. Esto da al intérprete la oportunidad de comprobar si la dirección de la  instrucción es válida. Además, las llamadas de sistema también son atrapadas e interpretadas. La manera en que se manejan estas llamadas depende de la política de seguridad. Cuando un subprograma intenta utilizar un medio del sistema, su llamada se pasa al monitor de seguridad para que la apruebe. El monitor examina la llamada a la luz de la política de seguridad local y después coge una decisión para permitirla o rechazarla. De esta manera, es probable proporcionar entrada a los subprogramas a algunos medios pero no a todos. Desgraciadamente, la verdad es que el modelo de seguridad no funciona del todo bien y con frecuencia aparecen errores. ActiveX Los controles ActiveX son proyectos binarios Pentium que pueden incrustarse en páginas WEB. Cuando se descubre sdeterminados de ellos, se realiza una verificación para ver si se debe ejecutar, y si pasa la prueba, se ejecuta. No está interpretado o ya que en una caja de arena (se puede encapsular para restringir su comportamiento y atrapar sus intentos por utilizar los recursos del sistema) de ninguna forma por lo que tiene tanto poder que cualquier otro proyecto de usuario, y puede realizar mucho daño, por lo tanto toda la seguridad recae en la decisión de si se ejecuta o no el control ActiveX. El método que Microsoft eligió para beber esta decisión se cimienta en la idea de la firma de código. Cada ActiveX está acompañado por una firma digital  (un hash del código que está firmado por su creador utilizando la encriptación de clave pública. Cuando surge un control ActiveX, el navegador primero verifica a continuación sus tablas internas para ver si el creador del proyecto es confiable, el proyecto se ejecutan; de lo contrario, no se ejecuta. Este sistema que utiliza Microsoft se conoce como Authenticode. JavaScript JavaScript no tiene ningún modelo de seguridad formal, pero aun así tiene una larga anécdota de implementaciones, el asunto significativo es que permitir la ejecución de código raro en su máquina es abrir la puerta a los asuntos, el asunto aquí es que el código móvil faculta gráficos vistosos e interacciones rápida, y muchos diseñadores de sitios Web piensan que esto es más significativo que la seguridad. VirusLos virus son otra manera de código móvil. Solo que a diferencia de los previos los virus no se invitan de ninguna manera, los virus se redactan para que se reproduzcan a sí mismos. Cuando llegan los virus, ya sea por recurso de una página web, un archivo adjunto de correo electrónico, o determinado otro recurso por lo común inician infectando los proyectos ejecutables del disco duro. Cuando se ejecuta determinado de estos proyectos, el control se transfiere al virus, que por lo común trata de esparcirse a sí mismo a otras máquinas. Algunos virus afectan el tramo de arranque del disco duro, por lo que cuando la maquina se inicia, el virus se ejecuta. Desafortunadamente no hay una solución a este problema. Quizás podría ayudar una nueva generación de sistemas operativos basados en microkernels seguros y el comportamiento de usuarios, procesos y recursos. 7.5 Firewalls Definición de FIREWALL: es una fracción de un sistema o una red que está diseñada para bloquear el entrada no autorizado, permitiendo al mismo tiempo comunicaciones autorizadas. Los FIREWALLS (servidores de seguridad) son simplemente una adaptación moderna de la vieja táctica medieval de seguridad: excavar un foso defensivo profundo alrededor del castillo. Este diseño obliga a que todos los que entraran o salieran del castillo pasarán a través de un puente levadizo, en donde los encargados de la E/S los podían inspeccionar. En las redes es probable el mismo truco: una empresa puede tener muchas LANs conectadas de maneras arbitrarias, pero se obliga a todo tráfico desde o hacia la empresa pase a través de un puente levadizo electrónico (firewall). Para un mejor control de la información dentro de una red es recomendable laborar con dos enrutadores que realicen el filtrado de paquetes y una puerta de enlace de aplicación. También  tiene lugarn configuraciones más simples, pero la ventaja de este diseño es que cada paquete debe transitar a través de dos filtros y una puerta de enlace de aplicación para entrar o salir. No tiene lugar otra ruta. Cada  ?Filtro de paquete?  es un enrutador estándar equipado con cierta funcionalidad extra. Esta faculta inspeccionar cada paquete entrante o saliente. Los paquetes que cumplan con determinado criterio se reenvían de forma normal. Lo que fallen la prueba se descartan. El filtro de paquete de la LAN interna verifica los paquetes salientes y el que está en la LAN externa verifica los paquetes entrantes. Los paquetes que cruzan la primera barrera pasan a la puerta de enlace de aplicación, donde se vuelven a examinar. El meta de ubicar los dos filtros de paquetes en LANs distintos es asegurar que ningún paquete entre o salga sin pasar a través de la puerta de enlace de aplicación. Por lo general, los filtros de paquetes son manejados por tablas configuradas por el administrador del sistema. Felicidades tablas listan orígenes y destinos aceptables, orígenes y destinos bloqueados, y normas predeterminadas sobre lo que se debe realizar con los paquetes que van o vienen de otras máquinas. El bloquear paquetes salientes es un escaso difícil pues aunque la mayoría de los sitios se apegan a las convenciones estándar de numeración de puertos, no están obligados a hacerlo. Además, para algunos servicios importantes, como FTP (Protocolo de Transferencia de Archivos), los números de puerto se asignan de forma dinámica. Asimismo, aunque el bloqueo de conexiones TCP es difícil, el de paquetes UDP lo es aún más debido a que se sabe muy escaso con anticipación sobre lo que harán. La segunda mitad del FIREWALL es la puerta de enlace de aplicación. En espacio de solo buscar los paquetes simples, la puerta de enlace opera a nivel de aplicación. Por ejemplo, es probable configurar una puerta de enlace de correo para examinar cada mensaje que sale o entra. Para cada uno, la puerta de enlace determina si transmitir o eliminar el mensaje con fundamento en los campos de encabezado, el dimensión del mensaje o inclusive el contenido (por ejemplo, en una instalación militar, la presencia de palabras como ?nuclear? o ?bomba? podría causar que se tomara cierta acción en especial. A pesar de que el FIREWALL está configurado perfectamente, aún existirá una mayor porción de problemas. Por ejemplo, si un firewall está configurado para permitir solo paquetes entrantes de redes específicas (por ejemplo, de otras instalaciones de la compañía), un intruso fuera del firewall puede introducir direcciones de inicio falsas para evadir esta verificación. Si un miembro interno quiere enviar documentos secretos, pueden encriptarlos o inclusive fotografiarlos y enviar las fotos como ficheros JPEG, los cuales pueden evadir cualquier filtro de palabra. Hay otra clase de ataques que los firewall ni pueden manejar. La idea escencial de un firewall es eludir que entren intrusos y que salga información secreta. Desgraciadamente, hay personas que no tienen nada mejor que realizar que tratar de perjudicar ciertos sitios. Esto lo hacen enviando masivos porciónes de paquetes legítimos al destino hasta que el sitio se caiga debido a la carga. Los ataques en lo que el meta del intruso es bloquear el destino en espacio de hurtar datos se conocen como ataques  DoS (negación del servicio), una variante aun peor es aquella en la que el intruso ha entrado en cuentos de computadoras en cualquier fracción del mundo, y después ordena a todas ellas que ataquen al mismo meta al mismo tiempo. Este método no solo incrementa el poder del intruso, también reduce la posibilidad de su detección, debido a que los paquetes provienen de una mayor porción de máquinas que pertenecen a usuarios ingenuos. Un ataque de este tipo se conoce como ataque  DDoS (negación de servicio distribuida) 7.6 Sistemas: TCP Wrapper, Socks TCP Wrapper Se emplea para restringir el entrada a los servicios basados en TCP nombre de host, dirección IP, dirección de red, y así sucesivamente. TCP Wrappers apoyo de Secure Shell se da mediante el uso de la biblioteca libwrap. Que es una biblioteca de software de proyecto gratuito que implementa la funcionalidad genérica TCP Wrapper para los demonios de servicios de red a utilizar. Ficheros de configuración de TCP Wrapper Para decidir si una máquina cliente tiene permitido conectarse a SSH, los wrappers TCP referencia a los próximos dos ficheros, los cuales se conocen comúnmente como ficheros de entrada al host: o    / Etc / hosts.allow o    / Etc / hosts.deny Cuando una solicitud de cliente es recibido por un servicio TCP wrapped, coge los próximos pasos básicos: Las referencias de servicio hosts.allow / etc /  El servicio TCP wrapped explora secuencialmente el archivo / etc / hosts.allow y aplica la primera norma especificada para ese servicio.Si descubre una norma que coincide, faculta la conexión. Si no, se mueve al paso 2. Las referencias de servicio / etc / hosts.deny -.  El servicio wrapped TCP explora secuencialmente el archivo / etc / hosts.deny.Si descubre una norma que coincide, rechaza la conexión. Si no es así, el entrada al servicio es permitido. Los próximos son puntos significativos a analizar cuando se usen wrappers TCP para proteger servicios de red: Debido a las normas de entrada en hosts.allow son aplicadas primero, ellas cogen precedencia sobre las normas en hosts.deny. Por lo tanto, si el entrada a un servicio es permitido en hosts.allow, una norma negando el entrada al mismo servicio en hosts.deny es ignorada. Dado que las normas en cada archivo se leen de encima hacia bajo y la primera norma que coincida para un servicio algun es el único que se aplica, el orden de las normas es extremadamente importante. Si no hay normas para el servicio se encuentran en el archivo, o si el archivo no existe, el entrada al servicio es permitido. Los servicios wrapped TCP no hacen caché de las normas desde los ficheros entrada de host, por lo que cualquier cambio a hosts.allow o a hosts.deny tomarán resultado de inmediato sin necesidad de reiniciar los servicios de red. La configuración recomendada es negar todo lo que no faculta explícitamente.Esto se hace agregando la próximo línea en  / etc / hosts.deny # Hosts.deny # Este archivo detalla los nombres de los anfitriones, que son # No se les faculta utilizar los servicios INET locales, tal como se decidió # Por el ?/ usr / sbin / tcpd? servidor. ALL: ALL Luego, de forma explícita la lista en  / etc / hosts.allow  todos los hosts o dominios que quiere el entrada a su máquina.  Un hosts.allow recomienda el próximo aspecto: # Hosts.allow # Este archivo detalla los nombres de los anfitriones, que son # Permitido el uso de los servicios INET locales, tal como se decidió # Por el ?/ usr / sbin / tcpd? servidor. TODOS: 192.168.67.0/255.255.255.0, 193.78.135.208/255.255.255.240 Socks SOCKS es un protocolo de Internet que faculta a las aplicaciones Cliente-servidor usar de forma transparente los servicios de unfirewall de red. SOCKS es una abreviación de ?SOCKetS?. Los clientes que hay detrás de un firewall, los cuales requieren alcanzar a los servidores del exterior, pueden conectarse en su espacio a un servidor proxy SOCKS. Tal servidor proxy controla qué cliente puede alcanzar al servidor externo y pasa la petición al servidor. SOCKS puede ser usado también de la manera contraria, permitiendo a los clientes de afuera del firewall (?clientes exteriores?) conectarse a los servidores de dentro del firewall (servidores internos). Las extensiones no oficiales SOCKS 4a añaden soporte para nombres DNS para resolver nombres con el servidor SOCKS. La versión actual 5 del protocolo, RFC 1928 o  authenticated firewall traversal, extiende la versión previa soportando UDP, autenticación, permitiendo al servidor SOCKS resolver nombres de host para el cliente SOCKS, e IPv6. De acuerdo con el modelo OSI esto es una capa intermedia entre la capa de aplicación y la capa de transporte. Protocolo SOCKS-4 Una petición de conexión típica SOCKS 4 se parece a algo parecida a esto (cada número es un byte): Cliente al Servidor Socks: tema 1: número de versión socks, 1 byte, debe ser 0×04 para esta versión tema 2: código de comando, 1 byte:- 0×01 = establecer una conexión stream tcp/ip 0×02 = establecer un enlazado(binding) al puerto tcp/ip tema 3: número de puerto de orden de byte de red, 2 bytes tema 4: dirección ip de orden de byte de red, 4 bytes tema 5: el string de id de usuario, extensión variable, terminado con un nulo (0×00) Servidor al cliente de socks: tema 1: byte nulo tema 2: estado, 1 byte:- 0x5a = petición concedida, 0x5b = petición rechazada o fallida, 0x5c = petición fallida a motivo de que el cliente no está ejecutando identd (o no es alcanzable desde el servidor) 0x5d = petición fallida debida a que identd de cliente no pudo confirmar el string de identidad de usuario en la petición tema 3: número de puerto con orden de bytes de red, 2 bytes tema 4: dirección ip con orden de bytes de red, 4 bytes Protocolo SOCKS 4a SOCKS 4a  es una expansión simple al protocolo SOCKS 4 que faculta a un cliente que no puede resolver el nombre de dominio de un host destino especificarlo. El cliente debe asignar los primeros tres bytes de DSTIP a NULL y el último byte a un valor diferente de cero (Esto corresponde a una dirección IP 0.0.0.x, siendo x diferente de cero, una dirección destino inadmisible y así no debe ocurrir jamás si el cliente puede resolver el nombre del dominio). Siguiendo al byte NULL que finaliza USERID, el cliente debe enviar el nombre de dominio destino y lo finaliza con otro byte NULL. Esto se usa para ambas peticiones CONNECT y BIND. Cliente al Servidor Socks: tema 1: número de versión socks, 1 byte, debe ser 0×04 para esta versión tema 2: código de comando, 1 byte:- 0×01 = constituye la conexión de stream tcp/ip 0×02 = constituye un enlace(binding) de puerto tcp/ip tema 3: número de puerto con orden de bytes de red, 2 bytes tema 4: dirección IP inválida deliberada, 4 bytes, los primeros tres deben ser 0×00 y el último no debe ser  0×00 tema 5: el string de id de usuario, extensión variable, terminado con un nulo (0×00) tema 6: el nombre de dominio del host con el que deseamos contactar, extensión variable, terminado con un nulo (0×00) Servidor a cliente de socks: tema 1: byte nulo tema 2: estado, 1 byte:- 0x5a = petición concedida, 0x5b = petición rechazada o fallida, 0x5c = petición fallida a motivo de que el cliente no está ejecutando identd (o no es alcanzable desde el servidor) 0x5d = petición fallida debida a que identd de cliente no pudo confirmar el string de identidad de usuario en la petición tema 3: número de puerto en el orden de bytes de la red, 2 bytes tema 4: dirección ip en el orden de bytes de la red, 4 bytes Un servidor que usa el protocolo 4A debe verificar el DSTIP en el paquete de petición. Si esto representa la dirección 0.0.0.x siendo x diferente de cero, el servidor debe leer en el nombre de dominio que el cliente envía en el paquete. El servidor debe resolver el nombre de dominio y hacer la conexión al host destino si puede. Protocolo SOCKS-5 Una expansión del protocolo SOCKS 4 que proporciona más alternativas de autenticación. La negociación (handshake) inicial ahora consiste en lo siguiente: El cliente se conecta y envía un saludo en el cual incluye una lista de los métodos de autenticación soportados. El servidor escoge uno (o envía una respuesta de fallo si ninguno de los métodos ofrecidos es aceptable). Algunos mensajes pueden pasar ahora entre el cliente y el servidor dependiendo del método de autenticación escogido. El cliente envía una petición de conexión parecida a  SOCKS4. El servidor responde de forma parecida a SOCKS4. Los métodos de autenticación soportados son numerados como sigue: 0×00 ? Sin autenticación 0×01 ? GSSAPI 0×02 ? Nombre de Usuario/Password 0×03..0x7F ? métodos asignados por IANA 0×80..0xFE ? métodos reservados para uso privado El saludo inicial desde el cliente es: tema 1: número de versión socks, debe ser 0×05 para esta versión tema 2: número de métodos de autenticación soportados, 1 byte tema 3: métodos de autenticación, extensión variable, 1-byte por método soportado La elección del servidor es comunicada: tema 1: versión socks, 1 byte, 0×05 para esta versión tema 2: método de autenticación escogida, 1 byte, o 0xFF cuando no sean ofrecidos métodos aceptables. La autenticación subsiguiente es dependiente del método. La petición de conexión del cliente es:- tema 1: número de versión socks, 1 byte, debe ser 0×05 para esta versión tema 2: código de comando, 1 byte:- 0×01 = establecer una conexión stream tcp/ip 0×02 = establecer  un enlazado(binding) de puerto tcp/ip 0×03 = asociar un puerto udp tema 3: reservado, debe ser 0×00 tema 4: tipo de dirección, 1 byte:- 0×01 = dirección IP V4 (el tema de direcciones tiene una extensión de 4 bytes) 0×03 = Nombre de dominio (el tema dirección es variable) 0×04 = dirección IP V6 (el tema de direcciones tiene una extensión de 16 bytes) tema 5: dirección destino, 4/16 bytes o extensión de nombre 1+dominio. Si el tipo de dirección es 0×03 entonces la dirección consiste en un byte de extensión seguido del nombre de dominio. tema 6: número de puerto en el orden de bytes de la red, 2 bytes Respuesta del Servidor:- tema 1: versión de protocolo socks, 1 byte, 0×05 para esta versión tema 2: estado, 1 byte:- 0×00 = petición concedida, 0×01 = fallo general, 0×02 = la conexión no se permitió por el conjunto de reglas(ruleset) 0×03 = red inalcanzable 0×04 = host inalcanzable 0×05 = conexión rechazada por el host destino 0×06 = TTL expirado 0×07 = comando no soportado/ yerro de protocolo 0×08 = tipo de dirección no soportado tema 3: reservado, 0×00 tema 4: tipo de dirección, 1 byte:- 0×01 = dirección IP V4 (el tema de direcciones tiene una extensión de 4 bytes) 0×03 = Nombre de dominio (el tema dirección es variable) 0×04 = dirección IP V6 (el tema de direcciones tiene una extensión de 16 bytes) tema 5: dirección destino, 4/16 bytes o extensión de nombre 1+dominio. Si el tipo de dirección es 0×03 entonces la dirección consiste en un byte de extensión seguido del nombre de dominio. tema 6: número de puerto en el orden de bytes de la red, 2 bytes.