Los clientes también tienen puertos TCP/UDP:
Debido a que TCP/IP es un protocolo punto a punto, cada nodo tiene una dirección única. Esta filosofía se lleva al nivel de las aplicaciones, lo que significa que las aplicaciones y los servicios también tienen direcciones (o números de puerto). Tanto el cliente como el servidor deben tener números de puerto único en sus sistemas individuales en orden para que se establezca una conexión TCP o UDP. Por ejemplo, el servidor Telnet atiende las conexiones entrantes sobre el puerto 23. Sin embargo, el cliente Telnet también tiene un número de puerto. Sin esto, el stack IP del cliente no sabría de qué aplicaciones fue el paquete.
Históricamente, casi todas las aplicaciones cliente TCP/IP usan un número de puerto asignado aleatoriamente sobre los 1023 para su fin de conexión. Esto es resultado de los roots TCP/IP en el mundo UNIX. En los sistemas UNIX, los puertos más allá de 1024 son reservados para los servicios del servidor (como Telnet, FTP, etc.). A fin de permitir que trabajen las aplicaciones cliente, ellos deben usar números de puerto sobre 1023.
Para que permita que cualquier tipo de conexión trabaje, debe permitir que cualquier paquete con número de puerto destino más alto que 1023 entre en su red. Si los paquetes de respuesta no retornan, el cliente no será capaz de establecer una conexión.
Desde el punto de vista de firewalls Internet, esto puede ocasionar algunos problemas en el diseño. Si bloquean todos los puertos entrantes, entonces detendrá a todos sus clientes en el uso de los recursos de Internet. Los paquetes de entrada que son las respuestas a sus pedidos de conexión externa no sobrevivirán a los filtros de entrada del firewall.
Otro problema de seguridad viene del hecho que no hay manera de saber que los paquetes entrantes en su red desde el puerto 80 son desde luego paquetes de respuesta del servidor world wide web. Algunos hackers pueden tener compilada su propia herramienta de invasión de red que corre sobre el puerto 80 en su máquina, eso hace que sus datos insidiosos sean considerados inofensivos, por su firewall. Si ellos pueden conseguir entrar en su red colocando manualmente su puerto fuente de la aplicación, entonces pueden hacer lo que ellos quieren con los sistemas vulnerables y su firewall será inútil.
2.- VERIFICAR EL BIT ACK:
TCP es un protocolo "confiable" que soporta corrección de errores y otras capacidades fuertes. Para lograr esta confiabilidad, cada conexión TCP comienza con una sucesión de apretón de manos que establece parámetros específicos de la conexión. Además, cada paquete que consiga enviar debe responderse con un reconocimiento antes que consiga enviar otro paquete.
Por ejemplo, si la PC abre una conexión con un servidor world wide web remoto, genera un paquete de pedido de conexión que no tiene el conjunto de bit ACK. Cuando el servidor responde a este pedido, envía un paquete con el conjunto de bit ACK y con el marcador para mostrar el número de bytes recibidos desde el cliente. El cliente entonces responde a este paquete con su propio paquete de respuesta, que también tiene el conjunto de bit ACK con su marcador propio que también muestra el número de bytes de datos recibidos desde el servidor. La figura de arriba ilustra esta serie de sucesos visualmente.
Un extraño no puede colocar manualmente el bit ACK para su primer paquete. El nodo receptor verá que el paquete es un registro para un paquete que éste envió (referenciado por el marcador) y lo desechará, pero no sería capaz de volver a llamar a cualquier paquete que siempre son enviados.
Este mecanismo no es una panacea, no siendo útil en muchas situaciones. Por ejemplo, si usted tiene un servidor world wide web interno o algunos otros datos que desea proveer sobre una base pública, entonces tendría que abrir el puerto 80 (o cualquier puerto que fuera ser usado) para los pedidos de conexiones externas que pudieran entrar en su red.
3.- EL PROBLEMA CON FTP:
A diferencia de la mayoría de los servicios Internet que usan un par único de números de puerto para todas las comunicaciones, FTP usa dos pares de números de puerto durante las conexiones. El primer par se usa para el "canal comando" FTP que provee una línea de comunicaciones para iniciar el acceso y ejecutar comandos, mientras que el otro par se usa para "canal de datos" FTP que se usa para enviar archivos o listados de directorios entre el cliente y el servidor.
Durante una sesión normal FTP, el cliente enviará un pedido de conexión TCP al puerto 21 (el canal "comando") sobre el servidor y luego ejecutará comandos tales como LOGIN, DIR y el like. Una vez que el usuario solicita que los datos sean enviados, el servidor FTP usa su puerto local 20 (el canal de "datos") para iniciar una conexión con el puerto de "datos" del cliente. Esto presenta un problema espectacular.
Sin embargo, hay un trabajo alrededor de este escenario. Muchos servidores y clientes FTP soportan el uso de transferencias de archivo en "modo pasivo" (nombrados después del comando PASV), que permite al cliente iniciar la conexión de transferencia de archivo. Antes que el servidor use el puerto 20, cuando recibe el comando PASV ubica un puerto sobre 1023 e informa al cliente de su elección (por medio del canal de comando).
El cliente entonces inicia la conexión TCP al número de puerto proporcionado y el servidor entonces comienza a transferir datos. No todos los clientes o los servidores soportan el comando PASV, por lo tanto no trabajará en todas las situaciones, aunque está llegando a ser mucho más común. Casi todos los browsers Web usan el modo PASV por defecto y casi cada cliente FTP tiene provecho buscando soporte también.
4.- FILTRADO DE PUERTO UDP
Como se dijo anteriormente, controlar el bit ACK en los paquetes TCP entrantes es una manera muy efectiva de permitir conexiones fuera de TCP. Sin embargo, el UDP no ofrece este tipo de capacidad, debido a que no tiene ninguna funcionalidad ACK. UDP está diseñado para transmisiones poco fiables que no requiere de conexiones negociadas. Estos tipos de servicios pueden ser dañados fácilmente o usados como rellenos de lanzamiento para ataques adicionales sobre su red.
Una posible solución a este problema es simplemente no permitir ninguna conexión UDP entrante. Para activar esta funcionalidad, usted necesita configurar su firewall para que envíe paquetes UDP recibidos desde la interface interna, pero no los de interface externa. Aunque esto impedirá cualquier conexión UDP entrante, no siempre será factible.
Nuevamente, el problema fundamental con este enfoque es que no hay manera de asegurarse que el host externo que genera el paquete sea el servicio que el cliente interno está esperando para comunicarse. Si un hacker estuviera copiando la dirección IP de su servidor DNS de ISP, entonces ellos podrían lanzar teóricamente un ataque desde el puerto UDP asociado con el DNS.
Sin embargo, esta dificultad particular existiría de cualquier manera si se estuviera filtrando paquetes UDP, por tanto sólo las consultas DNS y los resultados de su ISP se admitirían en la red. Su situación ni se mejora ni se degenera por la evolución de estos productos de paquetes filtradores dinámicos.
El firewall que filtra paquetes compara cada paquete de datos que viaja entre su red interna y externa con un conjunto de reglas. Las reglas verifican la información en un paquete si son fuente o el destino de la red que los está dirigiendo, y la red atiende el paquete implicado con ella. En base a estas reglas, se permite o no el pase al firewall.
Los filtros de paquetes efectivamente examinan cada paquete como una entidad separada, ellos no pueden filtrar paquetes con base en, por ejemplo, el usuario quien generó el paquete. Los filtros de paquetes pueden ser una base de datos única de filtro sobre criterios como:
* La dirección de fuente o de destino
* El tipo de red que atiende
* Si el paquete intenta comenzar una nueva jornada de comunicación de red.
2.-) El comando ping sirve para obtener información en la red, mencione 5 usos prácticos en los que se usa este comando, de sus respectivos ejemplos.