Los cortafuegos del mundo dirán al menos dos palabras: sí o no, directamente hablando, significa aceptación o rechazo. El firewall más simple es un puente Ethernet. Pero pocos pensaron que este primitivo cortafuegos sería de mucha utilidad. La mayoría de los firewalls utilizan una variedad de tecnologías y estándares. Estos firewalls vienen en muchas formas: algunos reemplazan la pila de protocolos TCP/IP ya equipada en el sistema; algunos construyen sus propios módulos de software sobre la pila de protocolos existente; otros son simplemente un sistema operativo independiente. También existen firewalls orientados a aplicaciones que solo brindan protección para tipos específicos de conexiones de red, como los protocolos SMTP o HTTP. También existen algunos productos de firewall basados en hardware que en realidad deberían clasificarse como enrutadores de seguridad. Todos estos productos pueden denominarse firewalls porque todos funcionan de la misma manera: analizan los paquetes de datos que entran y salen del firewall y deciden si los dejan pasar o los descartan.
Todos los firewalls tienen capacidades de filtrado de direcciones IP. Esta tarea consiste en inspeccionar el encabezado IP y tomar una decisión de liberación/eliminación en función de sus direcciones IP de origen y destino. Mira la imagen de abajo. Hay un firewall entre los dos segmentos de la red. Hay una computadora UNIX en un extremo del firewall y un cliente de PC en el otro segmento de la red.
Cuando el cliente de PC envía una solicitud de telnet a la computadora UNIX, el cliente de telnet de la PC genera un paquete TCP y lo envía a la pila de protocolo local para su transmisión. A continuación, la pila de protocolos "inserta" este paquete TCP en un paquete IP y luego lo envía a la computadora UNIX a través de la ruta definida por la pila TCP/IP de la PC. En este ejemplo, los paquetes IP deben pasar a través del firewall entre la PC y la computadora UNIX para llegar a la computadora UNIX.
Ahora "ordenamos" (en términos técnicos, configuramos) el firewall para que niegue todos los paquetes enviados a la computadora UNIX. Después de completar este trabajo, "Heart" Better Firewall notificará al programa cliente. Dado que los datos IP enviados al destino no se pueden reenviar, solo los usuarios en el mismo segmento de red que la computadora UNIX pueden acceder a la computadora UNIX.
En otro caso, puedes ordenar al firewall que encuentre problemas para esa PC pobre, y no funcionará si pasan paquetes de otras personas. Esta es la función más básica de un firewall: reenviar juicio basado en la dirección IP. Sin embargo, este movimiento no se puede utilizar en escenas importantes. Debido a que los piratas informáticos pueden utilizar técnicas de suplantación de direcciones IP, una computadora disfrazada de una dirección legítima puede superar un firewall que confía en esa dirección. Sin embargo, el mecanismo de toma de decisiones de reenvío basado en direcciones sigue siendo el más básico y necesario. Otra cosa a tener en cuenta es no utilizar nombres de host DNS para crear tablas de filtros. Es mucho más fácil falsificar DNS que falsificar una dirección IP.
Filtrado de puertos TCP/UDP del servidor
No es factible filtrar datos solo por dirección. Otra razón es que hay muchos servicios de comunicación ejecutándose en el host de destino. Por ejemplo, no queremos que los usuarios se conecten al sistema vía telnet, pero eso no significa que tengamos que prohibirles usar el servidor de correo SMTP/POP al mismo tiempo, ¿verdad? Entonces, además de la dirección, también necesitamos filtrar el puerto TCP/UDP del servidor.
Por ejemplo, el número de puerto de conexión del servicio telnet predeterminado es 23. Si no permitimos que el cliente de la PC establezca una conexión telnet con la computadora UNIX (creemos que es el servidor en este momento), entonces solo necesitamos ordenar al firewall que verifique los paquetes de datos enviados al servidor UNIX y los filtre. los paquetes de datos con el puerto de destino número 23. En este caso, ¿es posible combinar la dirección IP y el puerto TCP/UDP del servidor de destino como estándar de filtrado para lograr un firewall bastante confiable? No, no es tan simple.
El cliente también dispone de puertos TCP/UDP.
TCP/IP es un protocolo de extremo a extremo y cada nodo de la red tiene una dirección única. Lo mismo ocurre con la capa de aplicación de los nodos de red.
Cada aplicación y servicio en la capa de aplicación tiene su propia "dirección" correspondiente, es decir, un número de puerto. Solo cuando las direcciones y los puertos estén disponibles podremos establecer una comunicación efectiva entre varias aplicaciones en el cliente y el servidor. Por ejemplo, un servidor telnet escucha en el puerto 23 las conexiones entrantes. Al mismo tiempo, el cliente telnet también tiene un número de puerto. De lo contrario, ¿cómo puede saber la pila de IP del cliente a qué aplicación pertenece un paquete de datos?
Debido a razones históricas, casi todos los clientes TCP/IP utilizan números de puerto asignados aleatoriamente mayores que 1023. Sólo el usuario root en una máquina UNIX puede acceder a los puertos inferiores a 1024, que todavía están reservados para los servicios en el servidor. Por lo tanto, varias conexiones de red no funcionarán correctamente a menos que permitamos que todos los paquetes con números de puerto superiores a 1023 ingresen a la red.
Esto es problemático para los cortafuegos. Si todos los puertos de entrada están bloqueados, todos los clientes no pueden utilizar los recursos de la red. Porque los paquetes entrantes enviados por el servidor en respuesta a la solicitud de conexión externa (es decir, ingresando al firewall) no pueden pasar el filtrado entrante del firewall. Por el contrario, ¿es factible abrir todos los puertos superiores a 1023? No exactamente. Porque muchos servicios utilizan puertos superiores a 1023, como el cliente X, los servicios NFS basados en RPC y muchos productos IP que no son UNIX (NetWare/IP). Entonces, si se permite que todos los paquetes de datos que cumplen con el estándar del puerto 1023 ingresen a la red, ¿se puede decir que la red es segura? Incluso estos programas cliente no se atreven a decir que sean lo suficientemente seguros.
Filtrado bidireccional
Bien, pensemos en ello desde otro ángulo. Le damos una orden al firewall: pueden entrar paquetes de servicios conocidos, pero todos los demás quedan bloqueados fuera del firewall. Por ejemplo, si sabes que un usuario quiere acceder a un servidor web, entonces sólo los paquetes con el número de puerto de origen 80 pueden ingresar a la red:
Sin embargo, surge un nuevo problema. En primer lugar, ¿cómo saber en qué números de puerto se está ejecutando el servidor al que desea acceder? Los servidores como HTTP se pueden configurar a voluntad y los puertos utilizados también se pueden configurar a voluntad. Si configura su firewall de esta manera, no podrá acceder a ningún sitio web que no utilice un número de puerto estándar. Por el contrario, no puede garantizar que los paquetes de datos que ingresan a la red con el puerto número 80 deban provenir del servidor web. ¡Algunos piratas informáticos utilizan esta herramienta de intrusión casera para ejecutarla en el puerto 80 de su máquina local!
Comprueba el bit ACK
No confiamos en la dirección de origen ni en el puerto de origen. En este mundo loco donde tenemos que bailar con los hackers, ¿qué más podemos creer? Afortunadamente, las cosas no han llegado al punto de la desesperación. Existen algunas contramedidas, pero este método solo se puede utilizar con el protocolo TCP.
TCP es un protocolo de comunicación confiable. La palabra "confiable" significa que el protocolo tiene algunas propiedades especiales, incluidos mecanismos de corrección de errores. Para lograr su confiabilidad, cada conexión TCP debe pasar por un proceso de "apretón de manos" para intercambiar parámetros de conexión. Además, cada paquete enviado debe recibir una respuesta de acuse de recibo antes de que se envíen otros paquetes posteriores. Sin embargo, no es necesario responder a cada paquete TCP con un paquete ACK especial. De hecho, esta funcionalidad se puede lograr configurando un bit especial en el encabezado TCP. Por lo tanto, siempre que se genere un paquete de respuesta, el bit ACK debe establecerse en 1. El primer paquete de la sesión de conexión no se utiliza para reconocimiento, por lo que no establece el bit ACK; los paquetes TCP intercambiados en sesiones posteriores tendrán el bit ACK establecido.
Por ejemplo, una PC inicia una conexión a un servidor web remoto y el servidor genera un paquete de solicitud de conexión con el bit ACK no establecido. Cuando el servidor responde a una solicitud, devuelve un paquete con el bit de confirmación establecido y marca la cantidad de bytes recibidos del cliente en el paquete. Luego, el cliente responde al paquete con su propio paquete de respuesta, que también establece el bit ACK y marca el número de bytes recibidos del servidor. Al monitorear el bit ACK, podemos limitar los datos que ingresan a la red a los paquetes de respuesta. Por lo tanto, el sistema remoto no puede iniciar ninguna conexión TCP, pero puede responder a los paquetes recibidos.
Este mecanismo no es perfecto.
Como ejemplo sencillo, supongamos que tenemos un servidor web interno, entonces se debe abrir el puerto 80 para que puedan entrar solicitudes externas a la red. Además, es imposible monitorear el bit ACK de los paquetes UDP porque los paquetes UDP no tienen ningún bit ACK. También hay algunas aplicaciones TCP, como FTP, donde la conexión debe ser iniciada por estos propios programas de servidor.
Dificultades causadas por FTP
Los servicios generales de Internet sólo utilizan un par de números de puerto para todas las comunicaciones, mientras que los programas FTP utilizan dos pares de números de puerto al conectarse. El primer par de números de puerto se utiliza para el "canal de comandos" de FTP, que proporciona un enlace de comunicación para iniciar sesión y ejecutar comandos, mientras que el otro par de números de puerto se utiliza para el "canal de datos" de FTP, que proporciona transferencia de archivos entre el cliente. y el servidor.
En una sesión FTP normal, el cliente primero envía una solicitud de conexión TCP al puerto 21 del servidor (canal de comando) y luego ejecuta varios comandos como LOGIN y DIR. Una vez que el usuario solicita al servidor que envíe datos, el servidor FTP utiliza su puerto 20 (canal de datos) para iniciar una conexión al puerto de datos del cliente. El problema es que si el servidor inicia una conexión con el cliente para transmitir datos, enviará un paquete de datos sin el bit ACK establecido. El firewall rechazará el paquete de datos de acuerdo con las reglas anteriores, lo que significa que la transmisión de datos no tiene remedio. . Por lo general, sólo los cortafuegos avanzados, es decir, los cortafuegos que son lo suficientemente inteligentes, pueden ver el puerto que el cliente acaba de indicar al servidor y permitir conexiones entrantes a ese puerto.
Filtrado de puertos UDP
Bien, ahora volvamos y veamos cómo resolver el problema UDP. Como acabo de decir, los paquetes UDP no tienen el bit ACK, por lo que no se pueden filtrar con el bit ACK. UDP es una comunicación "no confiable" y se envía de todos modos. Este tipo de servicio se utiliza normalmente para tareas de comunicación como transmisión, enrutamiento y multimedia. NFS, DNS, WINS, NetBIOS sobre TCP/IP y NetWare/IP utilizan UDP.
Parece que la solución más sencilla posible es no permitir que se establezcan conexiones UDP entrantes. El firewall está configurado para reenviar paquetes UDP únicamente desde la interfaz interna y no desde la interfaz externa. Ahora el problema es que, por ejemplo, las solicitudes de resolución de nombres DNS utilizan UDP. Si proporciona un servicio DNS, al menos algunas solicitudes internas deben permitirse a través del firewall. También existen programas cliente como IRC que también utilizan UDP. Si desea que sus usuarios lo utilicen, también debe permitir que sus paquetes UDP entren a la red. Lo que podemos hacer es limitar las conexiones de sitios locales a sitios confiables. Sin embargo, ¡qué es digno de confianza! Si los piratas informáticos utilizan la suplantación de direcciones, ¿no volverían a las andadas?
Algunos enrutadores más nuevos pueden resolver este problema "memorizando" los paquetes UDP salientes: si el paquete UDP entrante coincide con la dirección de destino y el número de puerto del último paquete UDP saliente, déjelo entrar. Si no encuentra un paquete UDP coincidente en la memoria, ¡debe rechazarlo! Pero, ¿cómo determinamos que el host externo que generó el paquete es el servidor con el que el cliente interno desea comunicarse? Si un hacker miente sobre la dirección del servidor DNS, en teoría puede lanzar un ataque desde el puerto UDP conectado al DNS. Es probable que este problema exista siempre que permita que las consultas DNS y los paquetes de comentarios ingresen a la red. La solución es utilizar un servidor proxy.
El llamado servidor proxy, como su nombre indica, es un servidor que representa su red en el trato con el mundo exterior. Los servidores proxy no permiten conexiones directas desde dentro o fuera de la red. Él mismo proporciona DNS público * * * y privado, servidor de correo y otras funciones. Un servidor proxy reescribe el paquete en lugar de simplemente reenviarlo. Da la impresión de que los hosts de la red se encuentran en el borde de la red, pero en realidad están ocultos detrás del proxy, pero aparecen en la máscara del proxy.
Resumen
La dirección IP puede ser falsa. Esto se debe al mecanismo de ruta de origen del protocolo IP que le indica al enrutador que no utilice la ruta normal para el paquete de datos. pero de acuerdo con la ruta de origen en el encabezado del paquete para transmitir paquetes de datos. Luego, el pirata informático puede utilizar la dirección IP del sistema para obtener los paquetes devueltos. Algunos firewalls avanzados permiten a los usuarios bloquear el enrutamiento de origen.
Normalmente, nuestra red se conecta a través de una ruta al ISP y luego a Internet. Deshabilitar el enrutamiento de origen obligará a los paquetes a regresar por la ruta normal.
Además, necesitamos saber qué más hace el firewall al rechazar paquetes. Por ejemplo, ¿el firewall envía un mensaje ICMP "Host inalcanzable" al sistema que inició la conexión? ¿O el firewall realmente no hace nada más? Estos problemas pueden presentar riesgos de seguridad. El mensaje ICMP "Host inalcanzable" le indicará al hacker que "algunos puertos están bloqueados por el firewall" y el hacker inmediatamente podrá oler algo en este mensaje. Si ICMP "Host inalcanzable" es un error de comunicación, entonces es posible que un sistema honesto realmente no envíe nada. Por otro lado, la falta de respuesta hace que el sistema que inicia la comunicación siga intentando establecer una conexión hasta que se agote el tiempo de espera de la aplicación o de la pila de protocolos, lo que deja al usuario final con un mensaje de error. Por supuesto, este enfoque hace imposible que los piratas informáticos sepan si un puerto está cerrado o no está en uso.