Tabla de Contenido. Cisco Configurando ACLs de IP Comúnmente Usadas

Transcripción

1 Tabla de Contenido Configurando ACLs de IP Comúnmente Usadas...1 Introducción Prerrequisitos...2 Versiones de Hardware y Software...3 Ejemplos de Configuración...3 Permitir a un Host Seleccionado Acceder a la Red... 3 Permitir el Acceso a un Rango de Direcciones IP Contiguas....3 Negar a un Host Seleccionado Acceder a la Red..4 Negar Tráfico de Telnet (Puerto 23, TCP) 5 Permitir Solo a Redes Internas Iniciar una Sesión de TCP...5 Negar Tráfico de FTP (Puerto 21, TCP)...6 Permitir Pings (ICMP)..6 Permitir HTTP, Telnet, Mail, POP3, FTP...7 Permitir Actualizaciones de Enrutamiento...7 Información Relacionada...8 i

2 Configurando ACLs de IP Comúnmente Usadas Introducción Prerrequisitos Versiones de Hardware y Software Ejemplos de Configuración Permitir a un Host Elegido Acceder a la Red Permitir el Acceso a un Rango de Direcciones IP Contiguas Negar a un Host Seleccionado Acceder a la Red Negar Tráfico de Telnet (Puerto 23, TCP) Permitir Solo a Redes Internas Iniciar una Sesión de TCP Negar Tráfico de FTP (Puerto 21, TCP) Permitir Pings (ICMP) Permitir HTTP, Telnet, Mail, POP3, FTP Permitir Actualizaciones de Enrutamiento Información Relacionada Introducción Este documento proporciona ejemplos de configuración de listas de control de acceso de IP comúnmente usadas (ACL) las cuales se usan frecuentemente para filtrar paquetes de IP basados en la dirección origen, dirección destino, tipo de paquetes o cualquier combinación de estos aspectos. Las ACLs filtran tráfico de red controlando si los paquetes enrutados son reenviados o bloqueados en la interfaz del router. Su router examina cada paquete para determinar si lo reenviará o tirará el paquete basado en el criterio que especificó dentro de la ACL. El criterio de la ACL puede ser la dirección origen del tráfico, la dirección destino del tráfico o el protocolo de capa superior. Los ejemplos en este documento muestran que una ACL es construida usando los siguientes dos pasos: 1. Crear una ACL 2. Aplicar la ACL a una interfaz La ACL de IP es una colección secuencial de condiciones de permitir y negar que se aplican a una dirección IP. El router compara las direcciones contra las condiciones en la ACL una a la vez. La primera coincidencia determina si el software IOS de Cisco acepta o rechaza la dirección. Porque el software IOS de Cisco se detiene de comparar las condiciones después de la primera coincidencia, el orden de las condiciones es crítico. Si no hay condiciones que coincidan, el router rechaza la dirección debido a una negación implícita a todo. Hay muchos tipos de ACLs de IP que pueden ser configuradas en el IOS de Cisco, tales como: ACLs Estándar ACLs Extendidas Lock and Key (ACLs dinámicas) ACLs de IP nombradas

3 ACLs Reflexivas ACLs Basadas-en-Tiempo usando rangos de tiempo Entradas ACL de IP con comentarios ACL basada-en-contexto Autenticación proxy Turbo ACLs ACLs basadas-en-tiempo Distribuido Este documento discute algunas ACLs estándar y extendidas comúnmente usadas. Para entender más acerca de los diferentes tipos de ACLs soportadas en el software IOS de Cisco y aprender cómo configurar y editar ACLs, refiérase a Configurando Listas de Acceso de IP. La sintaxis de un comando de access-list estándar es mostrada abajo. ACLs estándar controlan el tráfico comparando la dirección origen de los paquetes IP con la dirección configurada en la ACL. access-list access-list-number {permit deny} {host source source-wildcard any} ACLs extendidas controlan el tráfico comparando las direcciones origen y el destino de los paquetes IP con las direcciones configuradas en la ACL. A continuación se presenta la sintaxis del formato del comando de ACLs extendidas. IP ICMP TCP UDP access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny permit} protocol source source-wildcard destination destinationwildcard [precedence precedence] [tos tos] [log log-input] [time-range time-range-name] access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny permit} icmp source source-wildcard destination destinationwildcard [icmp-type [[icmp-type icmp-code] [icmp-message]] [precedenceprecedence] [tos tos] [log log-input] [time-range time-rangename] access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny permit} tcp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [established] [precedence precedence] [tos tos] [log log-input] [time-range time-rangename] access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny permit} udp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [precedence precedence] [tos tos] [log log-input] [time-range time-range-name] La referencia de comandos para una ACL está disponible en Comandos de Servicios IP- Prerequisitos Los lectores de este documento deberán tener conocimiento básico del direccionamiento IP. Para información adicionl, refiérase a Direccionamiento IP y Subredes para Usuarios Nuevos.

4 Esta configuración no esta restringida a versiones específicas de software y hardware. Nota: La información presentada en este documento fue creada de dispositivos en un ambiente específico de laboratorio. Todos los dispositivos usados en este documento empezaron sin configuración (default). Si usted está trabajando en una red activa asegúrese de entender el impacto potencial de cualquier comando antes de usarlo. Ejemplos de Configuración Los siguientes ejemplos de configuración usan las ACLs más comunes de IP. Nota: Para encontrar información adicional de los comandos usados en este documento, use el comando de herramienta de búsqueda del IOS, Permitir a un Host Seleccionado Acceder a la Red A continuación está un ejemplo de un host seleccionado para ser permitido acceder a la red. Todo el tráfico origen del Host B destinado a NetA es permitido, y todo el otro tráfico originado desde NetB destinado a NetA es eliminado. La siguiente salida de router muestra cómo al host se le permitió el acceso a la red. La configuración permite solamente que el host con la dirección IP /32 atraviese la interface Ethernet 0 en R1. Este host tendrá acceso a los servicios de IP de NetA. Ningún otro host en NetB tendrá acceso a NetA. No hay una sentencia de negación en la ACL. Por defecto hay una negación a todo implícita al final de cada ACL. Cualquier cosa que no esté explícitamente permitido o negado. Nota: La ACL de arriba filtra los paquetes IP originados desde Host B. Los paquetes destinados al Host N desde NetA son permitidos. Permitir el Acceso a un Rango de Direcciones IP Contiguas El siguiente ejemplo muestra que todos los hosts en NetB con la dirección de red /24 son permitidos para acceder a la red /24 en NetA.

5 La siguiente configuración permite a los paquetes IP de quienes el encabezado IP tiene el número de red origen /24 y un número de red destino /24 acceder a NetA. Nuevamente, existe la negación implícita a todas las cláusulas al final de la ACL la cual niega todo el otro tráfico que pase a través del Ethernet 0 de entrada en R1. Negar un Host Seleccionado para Acceder a la Red El siguiente ejemplo muestra que el tráfico originado desde el Host B destinado a NetA está siendo negado, mientras se permite todo el otro tráfico desde NetB para acceder a NetA. La configuración siguiente niega todos los paquetes desde el host /32 a través del Ethernet 0 en R1 y permite todo lo demás. Porque hay una negación implícita en todas las cláusulas con cada ACL, deberá permitir explícitamente todo lo demás usando el comando access-list 1 permit any. Nota: El orden de las sentencias es crítico para la operación de una ACL. Si el orden de las entradas es inverso a lo mostrado abajo, la primera línea coincidiría con cada paquete dirección origen. Por lo tanto, la ACL fallaría para bloquear el host /32 de acceder a NetA. access-list 1 permit any access-list 1 deny host

6 Deshabilitar el acceso de Telnet a su red privada del público de la red podría requerir mayores aspectos de seguridad. El siguiente ejemplo muestra cómo el tráfico de Telnet desde NetB (público) destinado a NetA (privado) es negado, permitiendo a NetA iniciar y establecer sesiones de Telnet con NetB mientras permite todo el otro tráfico de IP. Telnet usa el Puerto 23, de TCP. La siguiente configuración muestra que todo el tráfico TCP destinado a NetA por el puerto 23 es bloqueado y todo el otro tráfico es pemitido. Permitir Solo a Redes Internas Iniciar una Sesión de TCP El siguiente ejemplo muestra el tráfico TCP originado desde NetA destinado a NetB siendo permitido, mientras se niega el tráfico TCO desde NetB destinado a NetA. El propósito de la ACL en este ejemplo es lograr lo siguiente: Permitir a los hosts en NetA iniciar y establecer una sesión TCP a hosts en NetB. Negar a los hosts en NetB de iniciar y establecer una sesión TCP destinada a hosts en NetA

7 Esta configuración le permite a un datagrama pasar a través de una interface Ethernet 0 de entrada en R1 cuando el datagrama ha reconocido (ACK) o reiniciado los bits (RST) (indicando una sesión TCP establecida) y tiene un valor de puerto destino más grande que Dado que la mayoría de los puertos bien-conocidos para servicios IP usan valores inferiores a 1023, cualquier datagrama con un puerto destino menor a 1023 y/o un bit ACK/RST no mostrado, será negado por la ACL 102. Por lo tanto, cuando un host desde NetB inicia una conexión TCP enviando el primer paquete TCP (sin paquete de sincronía/inicio bit (SYN/RST)) para un número de puerto menor a 1023, éste será negado y la sesión TCP fallará. Las sesiones TCP iniciadas desde NetA destinadas a NetB serán permitidas porque ellas tendrán el bit ACK/RST para regresar paquetes y estará usando valores de puerto más grandes que Para completar la lista de puertos, refiérase al RFC Negar Tráfico de FTP (TCP, Port 21) El siguiente ejemplo muestra tráfico de FTP (TCP, port 21) y FTP-Data (port 20 ) originado desde NetB destinado a NetA siendo negado, mientras se permite todo el otro tráfico de IP. FTP usa los puertos 21 y 20. Así, el tráfico TCP destinado al puerto 21 y puerto 20 es negado y todo lo demás está explícitamente permitido. Permitir Pings (ICMP) El siguiente ejemplo muestra el Protocolo de Control de Mensajes de Internet (ICMP) siendo permitido, originado desde NetA destinado a NetB, y negando cualquier ping originado desde NetB destinado a NetA.

8 La siguiente configuración, permite solo paquetes echo-replay (ping respuesta) para entrar en la interface Ethernet 0 desde NetB hacia NetA. Sin embargo, la configuración bloquea todos los paquetes ICMP echo-request cuando los pings son originados en NetB destinados a NetA. Por lo tanto, los hosts en NetA pueden hacer ping a los hosts en NetB pero los hosts en NetB no pueden hacer ping a los hosts en NetA. Permitir HTTP, Telnet, Mail, POP3, FTP El siguiente ejemplo muestra solo tráfico HTTP, Telnet, Simple Mail Transfer Protocol (SMTP), POP3, y FTP siendo permitido, y niega el resto del tráfico originado desde NetB destinado a NetA. Refiérase al diagrama arriba. La siguiente configuración permite tráfico TCP con valores de puerto destino coincidente con WWW (puerto 80), Telnet (puerto 23), SMTP (puerto 25), POP3 (puerto 110), o FTP (puerto 21). Note que una negación implícita (deny) a todo al final de una ACL niega todo el otro tráfico, lo cual no coincide con la cláusula permit. Permitir Actualizaciones de Enrutamiento Cada vez que appliqué una ACL de entrada en una interface, asegúrese de que las actualizaciones de enrutamiento no sean filtradas. Para permitir los paquetes del protocolo de enrutamiento, use la ACL permtinente abajo para asegurar que las actualizaciones de enrutamiento no sean filtradas. Para permitir Routing Information Protocol (RIP) use: access-list 102 permit udp any any eq rip

9 Para permitir Interior Gateway Routing Protocol (IGRP) use: access-list 102 permit igrp any any Para permitir Enhanced IGRP (EIGRP) use: access-list 102 permit eigrp any any Para permitir Open Shortest Path First (OSPF) use: access-list 102 permit ospf any any Para permitir Border Gateway Protocol (BGP) use: access-list 102 permit tcp any any eq 179 Información Relacionada TCP/IP Routing and Routed Protocols Support Page All contents are Copyright Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.