Tarea 1 - Conocer los diferentes procesos de seguridad en NGN

Maria Beronica Bonilla Gomez

Tutor: Efraín Alejandro Pérez

Curso

219007A_764 SEGURIDAD EN NGN

Universidad Nacional Abierta y a Distancia UNAD.

Especialización en redes de Nueva Generación
Sogamoso
Octubre
2020
 PRACTICAS CCNAS UNIDAD 1

2.6.1.3 Packet Tracer - Configurar Cisco Routers for Syslog, NTP, and SSH Operations

Objetivos del ejercicio:

● Configurar la autenticación OSPF MD5

● Configurar NTP
● Configurar los Routers para registrar mensajes en el Servidor Syslog
● Configurar R3 para admitir mensajes SSH

Requisitos de la actividad

En esta actividad, se configurará la autenticación OSPF MD5 para actualizaciones

seguras de enrutamiento.
El servidor NTP es el servidor NTP maestro en esta actividad. Se configurará la
autenticación en el servidor NTP y los enrutadores. Se configurará los enrutadores para
permitir que NTP sincronice el reloj del software con el servidor horario. Además, se
configurará los enrutadores para actualizar periódicamente el reloj del hardware con el
tiempo aprendido de NTP.

El servidor Syslog proporcionará el registro de mensajes en esta actividad. Configurará

los enrutadores para identificar el host remoto (servidor Syslog) que recibirá los
mensajes de registro.

Deberá configurar el servicio de marca de tiempo para iniciar sesión en los

enrutadores. Mostrar la hora y fecha correctas en los mensajes de Syslog es vital
cuando se usa Syslog para monitorear una red.

También se configurará R3 para que se administre de forma segura utilizando SSH en

lugar de Telnet. Los servidores se han sido preconfigurados para los servicios NTP y
Syslog respectivamente. NTP no requerirá autenticación. Los enrutadores se han
configurado previamente con las siguientes contraseñas:

● Habilitar contraseña: ciscoenpa55

● Contraseña para líneas vty: ciscovtypa55

Nota: Nota: MD5 es el cifrado más fuerte admitido en la versión de Packet Tracer
utilizada para desarrollar esta actividad (v6.2). Aunque MD5 tiene vulnerabilidades
conocidas, debe usar el cifrado que cumpla con los requisitos de seguridad de su
organización. En esta actividad, el requisito de seguridad especifica MD5.

Parte 1, Configuración de Autenticación OSPF MD5

Paso 1, Realizar el test de conectividad. Todos los dispositivos deben poder hacer ping
a todas las demás direcciones IP.

Fig. 1, ping de NTP Server al SSH Client

 Fig 2, ping del Syslog Server al SHH Client

Fig 3, ping del SSH Client al NTP Server y del SHH Client al Syslog Server.

Paso 2, Configurar la autenticación OSPF MD5 para todos los routers pertenecientes al
área 0.
 Fig.4, Configuración de la autenticación MD5 para R1,R2 y R3 del área 0

Paso 3, Configurar la clave MD5 para todos los routers del área 0

Fig.5, Configuración de la clave MD5 routers del área 0

Fig.6, Verificación de la configuración de MD5 a través del comando Show IP OSPF interface
 Fig.7, Pruebas de conectividad end-to-end

Parte 2, Configuración de NTP

Paso 1, Habilitar la autenticación NTP en el PCA-A (NTP Server)

Fig.8, Habilitación de NTP en el NTP-Server

Paso 2, Configurar R1, R2 y R3 como Clientes NTP

 Fig.9, Configuración de los routers como Clientes NTP

Paso 3, Configurar los routers para actualizar el reloj del hardware

Fig.10, Configuración de la actualización del reloj del Hardware en R1, R2 y R3

Fig.11, Actualización del reloj de los dispositivos

Paso 4, Configuración de la autenticación NTP en los routers

Para la configuración de la autenticación NTP en R1, R2 y R3 se utiliza la Key 1 y la

contraseña NTPpa55

Fig12, Configuración de la autenticación NTP en los Routers.

Paso 5, Configurar los routers para marcar los mensajes de registro

Configurar el servicio de marca de tiempo para iniciar sesión en los enrutadores.

Fig13, Configuración de la marca de tiempo en los routers

Parte 3, Configurar los Routers para registrar mensajes en el Servidor Syslog

Paso 1, Configurar los routers para identificar el host remoto (Servidor Syslog) que
recibirá los mensajes de registro.

Fig14, Configuración del Servidor Syslog en los Routers

Paso 2, Verificar la Configuración de registro

Fig15, comando show loggin en R1

Paso 3, Examinar los registros del Servidor Syslog

Fig16, Registros de Syslog en el servidor

Parte 4, Configurar R3 para admitir conexiones SSH

Paso 1, Configurar un nombre de dominio (ccnasecurity.com)

 Fig17, Configuración del nombre de dominio en R3

Paso 2, Configurar los usuarios para iniciar sesión en el servidor SSH en R3

Crear un ID de usuario SSHadmin con el nivel de privilegios más alto posible y con la
contraseña ciscosshpa55.

Fig18, Creación y configuración del usuario SSHadmin en R3

Paso 3, Configurar las líneas VTY de entrada en R3

Fig19, Configuración de las líneas VTY de ingreso en R3

Paso 4, Borrar los pares de claves existentes en R3

Cualquier par de claves RSA existentes debe borrarse en el Router R3.

Fig20, Eliminación de claves RCA en R3

Paso 5, Generar el par de claves de cifrado RSA en el router R3

El Router utiliza el par de claves RSA para la autenticación y el cifrado de los datos SSH
transmitidos. Configurar las claves RSA con un módulo de 1024. El valor
predeterminado es 512, y el rango es de 360 a 2048

Fig21, Creación de claves RSA en R3

Paso 6, Verificar la configuración SSH

Usar el comando show ip ssh para ver la configuración actual. Verificar que el tiempo
de espera de autenticación y los reintentos estén en sus valores predeterminados de
120 y 3, respectivamente.

Fig22., Visualización de la configuración de SSH en R3

Paso 7, Configurar los tiempos de espera de SSH y los parámetros de autenticación.

Los tiempos de espera de SSH y los parámetros de autenticación predeterminados se

pueden modificar para que sean más restrictivos. Establecer el tiempo de espera en 90
segundos, el número de reintentos de autenticación en 2 y la versión en 2.

Fig23, Configuración de los tiempos de espera e intentos de autenticación en R3

Verificar con el comando show ip ssh nuevamente para confirmar que los valores han
cambiado

Fig24, Verificación de la configuración SSH en R3

Paso 8, Intentar conectarse al R3 vía Telnet desde PC-C (SSH Client)

Fig24, Intento de conexión por Telnet a R3 desde el SSH Client

Paso 9, Conectarse a R3 usando SSH en el PC-C (SSH Client)

 Fig25, Intento de conexión a R3 usando SSH en el SSH Client

Paso 10, Conectarse a R3 usando SSH en R2

Fig26, Conexión a R3 mediante SSH desde R2

Paso 11, Validación de los resultados

Fig27, Validación de los resultados actividad Configurar Cisco Routers for Syslog, NTP, and SSH Operations
3.6.1.2 Packet Tracer - Configure AAA Authentication on Cisco Routers

Default Switch
Device Interface IP Address Subnet Mask Gateway Port

G0/1 192.168.1.1 255.255.255.0 N/A S1 F0/1

R1
S0/0/0 (DCE) 10.1.1.2 255.255.255.252 N/A N/A
G0/0 192.168.2.1 255.255.255.0 N/A S2 F0/2
R2 S0/0/0 10.1.1.1 255.255.255.252 N/A N/A
S0/0/1 (DCE) 10.2.2.1 255.255.255.252 N/A N/A
G0/1 192.168.3.1 255.255.255.0 N/A S3 F0/5
R3
S0/0/1 10.2.2.2 255.255.255.252 N/A N/A
CACS+ Server NIC 192.168.2.2 255.255.255.0 192.168.2.1 S2 F0/6
RADIUS Server NIC 192.168.3.2 255.255.255.0 192.168.3.1 S3 F0/1
PC-A NIC 192.168.1.3 255.255.255.0 192.168.1.1 S1 F0/2
PC-B NIC 192.168.2.3 255.255.255.0 192.168.2.1 S2 F0/1
PC-C NIC 192.168.3.3 255.255.255.0 192.168.3.1 S3 F0/18

Objetivos de la Práctica

● Configurar una cuenta de usuario local en R1 y configurar la autenticación en la

consola y las líneas vty utilizando AAA local.
● Verificar la autenticación local AAA desde la consola R1 y el cliente PC-A.
● Configurar la autenticación AAA basada en servidor usando TACACS +.
● Verificar la autenticación AAA basada en el servidor desde el cliente PC-B.
● Configurar la autenticación AAA basada en servidor usando RADIUS.
● Verificar la autenticación AAA basada en el servidor desde el cliente PC-C.
Escenario de red

La topología de la red muestra los enrutadores R1, R2 y R3. Actualmente, toda la

seguridad administrativa se basa en el conocimiento de la contraseña secreta de
habilitación. El objetivo de la práctica es configurar y probar soluciones AAA locales y
basadas en servidor.

Se debe crear una cuenta de usuario local y configurar AAA local en el enrutador R1 para
probar los inicios de sesión de consola y vty.

● Cuenta de usuario: Admin1 y contraseña admin1pa55

Luego se configura el enrutador R2 para admitir la autenticación basada en el servidor

utilizando el protocolo TACACS +. El servidor TACACS + se ha configurado previamente con
lo siguiente:

- Cliente: R2 usando la palabra clave tacacspa55

- Cuenta de usuario: Admin2 y contraseña admin2pa55

Finalmente, se configura el enrutador R3 para admitir la autenticación basada en el

servidor utilizando el protocolo RADIUS. El servidor RADIUS se ha configurado
previamente con lo siguiente:

- Cliente: R3 usando la palabra clave radiuspa55

- Cuenta de usuario: Admin3 y contraseña admin3pa55
- Los enrutadores también se han configurado previamente con lo siguiente:
- Habilitar contraseña secreta: ciscoenpa55
- Protocolo de enrutamiento OSPF con autenticación MD5 mediante contraseña:
MD5pa55

Nota: La consola y las líneas vty no se han configurado previamente.

Nota: IOS versión 15.3 usa SCRYPT como un algoritmo de cifrado seguro de hashing; sin
embargo, la versión de IOS que actualmente es compatible con Packet Tracer usa MD5. Se
debe utilizar siempre la opción más segura disponible en su equipo.

Parte 1, Configurar la autenticación Local AAA para el acceso por consola en R1

Paso 1, Test de conectividad

• Ping de PC-A a PC-B.

 Fig.28, ping de PC-A a PC-B satisfactorio

• Ping de PC-A a PC-C.

Fig.29, ping de PC-A a PC-C satisfactorio

• Ping de PC-B a PC-C.

Fig.30, ping de PC-B a PC-C Satisfactorio

Paso 2, Configurar un nombre de usuario local en R1

Configurar el nombre de usuario de Admin1 con la clave secreta admin1pa55

 Fig.31, configuración del nombre de usuario en R1

Paso 3, Configurar la autenticación AAA local para el acceso a la consola en R1

Se habilita AAA en R1 y se configura la autenticación AAA para el inicio de sesión

de la consola para usar la lista de métodos predeterminada.

Fig.32, Habilitación y configuración de AAA en R1,

Paso 4, Configurar la línea de consola para usar el método de autenticación AAA

establecido.

Habilitar AAA en R1 y configurar la autenticación AAA para el inicio de sesión de la

consola para usar la lista de métodos predeterminada

Fig.33,Configuración de la Autenticación AAA para el inicio de consola

Paso 5, Verificar el método de autenticación AAA

Verificar el inicio de sesión EXEC del usuario utilizando la base de datos local.

Fig.34, Verificación del inicio de Sesión en R1

Parte 2, Configurar la autenticación AAA local para las líneas VTY en R1

Paso 1, Configurar el nombre de dominio y la clave criptográfica para usar con SSH

a. Usar el ccnasecurity.com como nombre de dominio en R1

b. Crear una clave criptográfica RSA usando 1024 bits.
 Fig.35, Creación de la clave criptográfica de RSA en R1

Paso 2, Configurar un método de autenticación AAA de lista con nombre para las líneas
VTY en R1

Configurar una lista con nombre llamada SSH-LOGIN para autenticar los inicios de
sesión utilizando AAA local.

Fig.36, Creación de ACL SSH-LOGIN nombrada en R1

Paso 3, Configurar las líneas VTY para utilizar el método de autenticación AAA definido.

Configurar las líneas VTY para usar el método AAA y permitir únicamente SSH para
conexiones remotas.

Fig.37, Configuración de las líneas VTY en R1 para utilizar AAA

Paso 4, Verificar el método de autenticación AAA

Verificar la configuración SSH en R1 desde el command prompt del PC-A

Fig.38, Conexión SSH desde PC-A a R1

Parte 3: Configurar la autenticación AAA basada en servidor usando TACACS + en R2

 Fig.39, Configuración de red en el servidor TACACS + para R2 y Admin2

Paso 3: Configurar las especificaciones del servidor TACACS + en R2.

Configurar la dirección IP y la clave secreta del servidor AAA TACACS en R2.

Nota: Los comandos host tacacs-server y tacacs-server key están en desuso. Actualmente,
Packet Tracer no es compatible con el nuevo servidor de comandos tacacs.

R2 (config) # tacacs-server host 192.168.2.2

R2 (config) # tacacs-server key tacacspa55

Fig.40, Configuración del Servidor TACACS +

Paso 4: Configurar la autenticación de inicio de sesión AAA para el acceso a la consola en

R2.

Habilite AAA en R2 y configurar todos los inicios de sesión para autenticarse utilizando el
servidor AAA TACACS +. Si no está disponible, utilice la base de datos local.

Fig.41, Habilitación de AAA en el servidor TACACS+

Paso 5: Configurar la consola de línea para usar el método de autenticación AAA definido.

Configurar la autenticación AAA para iniciar sesión en la consola para usar el método de
autenticación AAA predeterminado.
 Fig.42, Configuración de AAA para el inicio de sesión por consola

Paso 6: Verificar el método de autenticación AAA.

Verificar el inicio de sesión EXEC del usuario utilizando el servidor AAA TACACS +.

Fig.43, Verificación del inicio de sesión usando AAA TACACS+

Part 4: Configurar Server-Based AAA Authentication Using RADIUS on R3

Paso 1: Configurar una entrada de respaldo de la base de datos local llamada Admin.

Para fines de respaldo, configurar un nombre de usuario local de Admin3 y una contraseña
secreta de admin3pa55.

Fig.44, Configuración de la autenticación utilizando RADIUS

Paso 2: Verificar la configuración del servidor RADIUS.

Haga clic en el servidor RADIUS. En la pestaña Servicios, haga clic en AAA. Observe que hay
una entrada de configuración de red para R3 y una entrada de configuración de usuario
para Admin3.

Paso 3: Configurar las especificaciones del servidor RADIUS en R3.

Configurar la dirección IP y la clave secreta del servidor RADIUS AAA en R3.

Nota: Los comandos host del servidor radius y la clave del servidor radius están en desuso.
Actualmente Packet Tracer no es compatible con el nuevo servidor de radios de
comandos.

Fig.45, Configuración de la IP y la clave secreta del servidor RADIUS

Paso 4: Configurar la autenticación de inicio de sesión AAA para el acceso a la consola en

R3.

Habilite AAA en R3 y configurar todos los inicios de sesión para autenticarse utilizando el
servidor AAA RADIUS. Si no está disponible, utilice la base de datos local.

Fig.46, Habilitación de AAA utilizando el servidor RADIUS

Paso 5: Configurar la línea de consola para usar el método de autenticación AAA definido.

Configurar la autenticación AAA para iniciar sesión en la consola para usar el método de
autenticación AAA predeterminado.

Fig.47, configuración de AAA para iniciar sesión en la consola

Paso 6: Verificar el método de autenticación AAA.

Verificar el inicio de sesión EXEC del usuario utilizando el servidor AAA RADIUS.

Fig.48, Verificación del inicio de sesión utilizando RADIUS

Paso 7: Verificar los resultados.
 Fig.49, Resultados de la actividad “Configure AAA Authentication on Cisco Routers”

4.1.1.10 Packet Tracer - Configuring Extended ACLs Scenario 1

Fig.50, Arquitectura de red para el ejercicio (Configuring Extended ACLs Scenario 1)

Device Interface IP Address Subnet Mask Default Gateway

G0/0 172.22.34.65 255.255.255.224 N/A
R1 G0/1 172.22.34.97 255.255.255.240 N/A
G0/2 172.22.34.1 255.255.255.192 N/A
Server NIC 172.22.34.62 255.255.255.192 172.22.34.1
PC1 NIC 172.22.34.66 255.255.255.224 172.22.34.65
PC2 NIC 172.22.34.98 255.255.255.240 172.22.34.97
Tabla 3, Direccionamiento de red - ejercicio (Configuring Extended ACLs Scenario 1)
Objetivos

Parte 1: configurar, aplicar y verificar una ACL numerada extendida

Parte 2: configurar, aplicar y verificar una ACL nombrada extendida

Escenario

Dos empleados necesitan acceso a los servicios proporcionados por el servidor. PC1
solo necesita acceso FTP, mientras que PC2 solo necesita acceso web. Ambas
computadoras pueden hacer ping al servidor, pero no la una a la otra.

Parte 1: configurar, aplicar y verificar una ACL numerada extendida

Paso 1: Configure una ACL para permitir FTP e ICMP.

a. Desde el modo de configuración global en R1, ingrese el siguiente comando para

determinar el primer número válido para una lista de acceso extendida.

Fig.51, Opciones de lista de acceso en R1

b. Agregue 100 al comando, seguido de un signo de interrogación.

Fig.52, Opciones de permisos de la ACL 100 en R1

c. Para permitir el tráfico FTP, ingrese el comando permit, seguido de un signo de

interrogación.

Fig.53, Opciones de permiso según el tipo de tráfico/protocolo en R1

 c. Esta ACL permite FTP e ICMP. ICMP aparece en la lista anterior, pero FTP no,
porque FTP usa TCP. Por lo tanto, ingrese tcp para filtrar aún más la ayuda de
ACL.

Fig.54, Opciones de permiso de TCP en la ACL 100

e. Se puede filtrar solo para PC1 usando la palabra clave host o podríamos permitir
cualquier host. En este caso, se permite cualquier dispositivo que tenga una
dirección que pertenezca a la red 172.22.34.64/27. Ingrese la dirección de red,
seguida de un signo de interrogación.

Fig.55, Opciones de Wild Card para la IP de PC-1

f. Calcule la Wild Card que determina el opuesto binario de una máscara de subred.

11111111.11111111 .11111111.11100000=255.255 .255 .224

00000000.00000000 .00000000.00011111=0.0 .0 .31

g. Ingrese la Wild Card, seguida de un signo de interrogación.

Fig.56, Opciones de permisos para PC-1

h. Configurar la dirección de destino. En este escenario, se está filtrando el tráfico

para un solo destino, que es el servidor. Ingrese la palabra clave del host seguida de
la dirección IP del servidor.
 Fig.57, Opciones de permisos para la conexión entre PC-1 y el Server

i. Observe que una de las opciones es <cr> (retorno de carro). En otras palabras,
puede presionar Enter y la instrucción permitiría todo el tráfico TCP. Sin embargo,
solo permitimos el tráfico FTP; por lo tanto, ingrese la palabra clave eq, seguida de
un signo de interrogación para mostrar las opciones disponibles. Luego, ingrese ftp y
presione Enter.

Fig.58, permiso exclusivo a tráfico FTP en R1

j. Cree una segunda declaración de lista de acceso para permitir el tráfico ICMP
(ping, etc.) desde la PC1 al servidor. Tenga en cuenta que el número de la lista de
acceso sigue siendo el mismo y no es necesario especificar ningún tipo particular de
tráfico ICMP.

Fig.59, ACL de permiso para tráfico ICMP

k. Todo el resto del tráfico es denegado, por defecto.

Paso 2: aplique la ACL en la interfaz correcta para filtrar el tráfico.

Desde la perspectiva de R1, el tráfico al que se aplica ACL 100 es entrante desde la
red conectada a la interfaz Gigabit Ethernet 0/0. Ingrese al modo de configuración
de la interfaz y aplique la ACL.

Fig.60, Aplicación de la ACL a la interface de entrada de tráfico

Paso 3: Verifique la implementación de ACL.

a. Haga ping desde la PC1 al servidor. Si los pings no tienen éxito, verifique las
direcciones IP antes de continuar.

Fig.61, ping de PC-1 al Server

b. FTP desde la PC1 al servidor.

El nombre de usuario y la contraseña son ambos de Cisco.

Fig.62, FTP de PC-1 al Server

b. Salga del servicio FTP del servidor.

Fig.63, Desconexión del servicio FTP en PC-1

c. Haga ping de PC1 a PC2. El host de destino no debería ser accesible, porque el
tráfico no estaba explícitamente permitido.
 Fig.64, ping inalcanzable de PC-1 a PC-2 debido a los ACL's configurados

Parte 2: configurar, aplicar y verificar una ACL nombrada extendida

Paso 1: Configure una ACL para permitir el acceso HTTP y ICMP.

a. Las ACL nombradas comienzan con la palabra clave ip. Desde el modo de
configuración global de R1, ingrese el siguiente comando, seguido de un signo de
interrogación.

Fig.65, Tipos de ACL's

b. Puede configurar ACL estándar y extendidas con nombre. Esta lista de acceso
filtra las direcciones IP de origen y de destino; por lo tanto, debe extenderse.
Ingrese HTTP_ONLY como nombre. (Para la puntuación de Packet Tracer, el
nombre distingue entre mayúsculas y minúsculas).

Fig.66, Lista de acceso extendida para HTTP

c. El nivel de vista cambia. Ahora está en modo de configuración ACL con nombre
extendido. Todos los dispositivos en la PC2 LAN necesitan acceso TCP. Ingrese la
dirección de red, seguida de un signo de interrogación.

Fig.67, Opciones de Wild Card para PC-2

d. Una forma alternativa de calcular un comodín es restar la máscara de subred de

255.255.255.255.
255.255 .255 .255
−255.255 .255 .240
¿ 0.0 .0.15
e. Termine la declaración especificando la dirección del servidor como lo hizo en la
Parte 1 y filtrando el tráfico de www.

Fig.68, Permiso de tráfico www por medio de la ACL extendida

f. Cree una segunda declaración de lista de acceso para permitir el tráfico ICMP
(ping, etc.) desde PC2 al servidor. Nota: La solicitud sigue siendo la misma y no es
necesario especificar un tipo específico de tráfico ICMP.

Fig.69, Lista de acceso para permitir tráfico ICMP

g. Todo el resto del tráfico es denegado, por defecto. Salga del modo de
configuración de ACL con nombre extendido.

Paso 2: aplique la ACL en la interfaz correcta para filtrar el tráfico.

Desde la perspectiva de R1, el tráfico al que se aplica la lista de acceso HTTP_ONLY

es entrante desde la red conectada a la interfaz Gigabit Ethernet 0/1. Ingrese al
modo de configuración de la interfaz y aplique la ACL.

Fig.70, Aplicación de la ACL a la interfaz de entrada en R1

Paso 3: Verifique la implementación de ACL.

a. Haga ping desde la PC2 al servidor. El ping debe ser exitoso, si el ping no tiene
éxito, verifique las direcciones IP antes de continuar.

Fig.71, ping de PC-2 al Server

 b. FTP desde PC2 al servidor. La conexión debería fallar.

Fig.72, FTP de PC-2 al Server (Sin Conexión)

c. Abra el navegador web en PC2 e ingrese la dirección IP del servidor como la URL.
La conexión debe ser exitosa.

Fig.73, Conexión del PC-2 al Server por el navegador web

Fig.73, Resultados de la Actividad Configuring Extendes ACLs – Scenario 1 Activity

4.1.1.11 Packet Tracer - Configuring Extended ACLs Scenario 2

 Fig.74, Topología de red para el ejercicio " Configuring Extended ACLs Scenario 2"

Interfac
Device e IP Address Subnet Mask Default Gateway
10.101.117.4 255.255.255.24
G0/0 N/A
9 8
10.101.117.3 255.255.255.24
RTA G0/1 N/A
3 0
255.255.255.22
G0/2 10.101.117.1 N/A
4
10.101.117.5 255.255.255.24
PCA NIC 10.101.117.49
1 8
10.101.117.3 255.255.255.24
PCB NIC 10.101.117.33
5 0
10.101.117.5 255.255.255.24
SWA VLAN 1 10.101.117.49
0 8
10.101.117.3 255.255.255.24
SWB VLAN 1 10.101.117.33
4 0
255.255.255.22
SWC VLAN 1 10.101.117.2 10.101.117.1
4
 Tabla 4, Direccionamiento de red - ejercicio “Configuring Extended ACLs Scenario 2"

Objetivos

Parte 1: Configurar, aplicar y verificar una ACL numerada extendida

Parte 2: Preguntas de reflexió n

Escenario

En este escenario, los dispositivos en una LAN pueden acceder de forma remota
a dispositivos en otra LAN utilizando el protocolo SSH. Ademá s de ICMP, se niega
todo el trá fico de otras redes.

Los conmutadores y el enrutador también se han configurado previamente con

lo siguiente:

• Contraseñ a secreta: ciscoenpa55

• Contraseñ a de consola: ciscoconpa55

• Nombre de usuario y contraseñ a local: Admin / Adminpa55

Parte 1: configurar, aplicar y verificar una ACL numerada extendida

Configurar, aplicar y verificar una ACL para satisfacer la siguiente política:

● El trá fico SSH desde dispositivos en la red 10.101.117.32/28 está permitido

a dispositivos en las redes 10.101.117.0/27.
● El trá fico ICMP está permitido desde cualquier fuente a cualquier destino.
● El resto del trá fico a 10.101.117.0/27 está bloqueado.

Paso 1: Configurar la ACL extendida.

a. Desde el modo de configuració n apropiado en RTA, use el ú ltimo nú mero

vá lido de la lista de acceso extendido para configurar la ACL. Utilice los
siguientes pasos para construir la primera instrucció n ACL:

1) El ú ltimo nú mero de la lista extendida es 199.

 2) El protocolo es TCP.

3) La red de origen es 10.101.117.32.

4) La wildcard se puede determinar restando 255.255.255.240 de

255.255.255.255.

5) La red de destino es 10.101.117.0.

6) La Wildcard se puede determinar restando 255.255.255.224 de

255.255.255.255.

7) El protocolo es SSH (puerto 22).

Fig.75, Configuración de la lista de acceso 199

¿Cuá l es la primera declaració n de ACL?

RTA (config) #access-list 199 permit tcp 10.101.117.32 0.0.0.15 10.101.117.0

0.0.0.31 eq telnet

b. Se permite ICMP y se necesita una segunda declaració n de ACL. Use el mismo

nú mero de lista de acceso para permitir todo el trá fico ICMP,
independientemente de la direcció n de origen o de destino. ¿Cuá l es la segunda
declaració n de ACL? (Sugerencia: use la palabra clave any)

Fig.76, Configuración de los parámetros de la ACL 199

C. El resto del trá fico IP se deniega, de manera predeterminada.

Paso 2: aplique la ACL extendida.

La regla general es colocar la ACL extendida cerca de la fuente. Sin embargo,

debido a que la lista de acceso 199 afecta el trá fico que se origina en ambas
redes 10.101.117.48/29 y 10.101.117.32/28, la mejor ubicació n para esta ACL
podría estar en la interfaz Gigabit Ethernet 0/2 en la direcció n de salida. ¿Cuá l es
el comando para aplicar ACL 199 a la interfaz Gigabit Ethernet 0/2?

Fig.77, Asignación de la ACL 199 a la interfaz Gigabit Ethernet 0/2

Paso 3: Verifique la implementación extendida de ACL.

a. Haga ping desde PCB a todas las otras direcciones IP en la red. Si los pings no
tienen éxito, verifique las direcciones IP antes de continuar.

Fig.78, ping de verificación de PCB a las demás direcciones IP de la red

b. SSH de PCB a SWC. El nombre de usuario es Admin y la contraseñ a es

Adminpa55.

PC> ssh -l Admin 10.101.117.2

 Fig.79, Conexión SSH de PCB a SWC exitosa

d. Salga de la sesió n SSH a SWC.

Fig.80, Cierre de la sesión SSH de PCB a SWC

d. Haga ping desde PCA a todas las otras direcciones IP en la red. Si los pings no
tienen éxito, verifique las direcciones IP antes de continuar.

Fig.81, ping de verificación de PCA a las demás direcciones IP de la red

e. SSH de PCA a SWC. La lista de acceso hace que el enrutador rechace la

conexió n.
 Fig.82, Conexión SSH NO exitosa de PCA a SWC

f. SSH de PCA a SWB. La lista de acceso se coloca en G0 / 2 y no afecta a esta

conexió n. El nombre de usuario es Admin y la contraseñ a es Adminpa55.

Fig.83, Conexión SSH de PCA a SWB exitosa

g. Después de iniciar sesió n en SWB, no cierre sesió n. SSH a SWC en modo EXEC
privilegiado.

SWB # ssh -l Admin 10.101.117.2

Fig.84, Conexión SSH desde SWB a SWC por medio de la conexión SSH de PCA a SWB

Parte 2: Preguntas de reflexión

1. ¿Có mo pudo PCA omitir la lista de acceso 199 y SSH a SWC?

Primero se utilizó la conexión SSH de PCA a SWB, al estar permitido SSH
desde SWB a SWC se logró omitir la ACL 199 y SSH configurados en PCA
2. ¿Qué se podría haber hecho para evitar que PCA acceda a SWC
indirectamente, al tiempo que permite el acceso de PCB SSH a SWC?
Debido a que se bloqueó todo el tráfico proveniente 10.101.117.0/27
excepto el tráfico SSH que se originó en 10.101.117.32/28, la lista de
acceso podría escribirse tal como está. En lugar de aplicar la ACL a la
 interfaz G0/2 saliente, se debe aplicar la misma ACL a G0/0 y G0/1
entrante.

Fig.85, Resultado de la actividad Configuring Extended ACLs Scenario 2

4.1.2.5 Packet Tracer - Configure IP ACLs to Mitigate Attacks

Fig.86, Topología de red para el ejercicio "Configure IP ACLs to Mitigate Attacks"

Default
Device Interface IP Address Subnet Mask Gateway Switch Port
192.168.1. S1 F0/5
G0/1 1 255.255.255.0 N/A
R1
S0/0/0 N/A
(DCE) 10.1.1.1 255.255.255.252 N/A
S0/0/0 10.1.1.2 255.255.255.252 N/A N/A
S0/0/1 N/A
R2 (DCE) 10.2.2.2 255.255.255.252 N/A
192.168.2. N/A
Lo0 1 255.255.255.0 N/A
 192.168.3. S3 F0/5
R3 G0/1 1 255.255.255.0 N/A
S0/0/1 10.2.2.1 255.255.255.252 N/A N/A
192.168.1. 192.168.1. S1 F0/6
PC-A NIC 3 255.255.255.0 1
192.168.3. 192.168.3. S3 F0/18
PC-C NIC 3 255.255.255.0 1
Tabla 5, Direccionamiento de red - ejercicio “Configure IP ACLs to Mitigate Attacks"

Objetivos

• Verifique la conectividad entre dispositivos antes de la configuració n del

firewall.
• Utilice las ACL para garantizar que el acceso remoto a los enrutadores solo
esté disponible desde la estació n de administració n PC-C.
• Configure las ACL en R1 y R3 para mitigar los ataques.
• Verifique la funcionalidad de ACL.

Escenario

El acceso a los enrutadores R1, R2 y R3 solo se debe permitir desde la PC-C, la

estació n de administració n. La PC-C también se usa para las pruebas de
conectividad con la PC-A, que es un servidor que proporciona servicios DNS,
SMTP, FTP y HTTPS.

El procedimiento operativo está ndar es aplicar ACL en los enrutadores de borde

para mitigar las amenazas comunes basadas en la direcció n IP de origen y
destino. En esta actividad, se crea ACL en los enrutadores de borde R1 y R3 para
lograr este objetivo. Luego se verifica la funcionalidad ACL de los hosts internos
y externos.

Los enrutadores se han configurado previamente con lo siguiente:

● Contraseñ a: ciscoenpa55
 ● Contraseñ a para la consola: ciscoconpa55
● Nombre de usuario y contraseñ a de inicio de sesió n SSH: SSHadmin /
ciscosshpa55
● direccionamiento IP
● Enrutamiento está tico

Parte 1: verificar la conectividad de red básica

Verifique la conectividad de la red antes de configurar las ACL de IP.

Paso 1: desde la PC-A, verifique la conectividad a la PC-C y R2.

a. Desde el símbolo del sistema, haga ping a PC-C (192.168.3.3).

b.

Fig.87, Ping de PC-A a PC-C y R2

b. Desde el símbolo del sistema, establezca una sesió n SSH para la interfaz R2
Lo0 (192.168.2.1) utilizando el nombre de usuario SSHadmin y la contraseñ a
ciscosshpa55. Cuando termine, salga de la sesió n SSH.

SERVIDOR> ssh -l SSHadmin 192.168.2.1

Fig.88, Conexión SSH de PC-A a la Interfaz loopback de R2

Paso 2: desde la PC-C, verifique la conectividad a la PC-A y R2.

a. Desde el símbolo del sistema, haga ping a la PC-A (192.168.1.3).

 Fig.89, Ping de PC-C a PC-A

b. Desde el símbolo del sistema, establezca una sesió n SSH para la interfaz R2
Lo0 (192.168.2.1) utilizando el nombre de usuario SSHadmin y la contraseñ a
ciscosshpa55. Cierre la sesió n SSH cuando haya terminado.

Fig.90, Conexión SSH de PC-C a la interfaz loopback de R2

c. Abra un navegador web en el servidor PC-A (192.168.1.3) para mostrar la

pá gina web. Cierre el navegador cuando haya terminado.
 Fig.91, Conexión HTTP en el Servidor

Parte 2: acceso seguro a los enrutadores

Paso 1: Configure ACL 10 para bloquear todo acceso remoto a los enrutadores,
excepto desde PC-C.

Use el comando de lista de acceso para crear una ACL de IP numerada en R1, R2
y R3.

Fig.92, Configuración de la ACL 10 numerada en R1, R2 y R3, respectivamente

Paso 2: aplique ACL 10 al trá fico de entrada en las líneas VTY.

Use el comando access-class para aplicar la lista de acceso al trá fico entrante en
las líneas VTY.

Fig.93, Aplicación de la ACL's 10 a las líneas VTY de R1, R2 y R3, respectivamente

Paso 3: Verifique el acceso exclusivo desde la estació n de administració n PC-C.

a. Establezca una sesió n SSH a 192.168.2.1 desde PC-C (debería tener éxito).

Fig.94, Conexión SSH de PC-C a la interfaz loopback R2, exitosa.

b. Establezca una sesió n SSH a 192.168.2.1 desde la PC-A (debería fallar).

Fig.95,Conexión SSH de PC-A a la interfaz loopback R2, Fallida.

Parte 3: Crear un IP ACL 120 numerado en R1

Cree una IP ACL numerada 120 con las siguientes reglas:

● Permitir que cualquier host externo acceda a los servicios DNS, SMTP y
FTP en el servidor PC-A.
● Denegar cualquier acceso de host externo a los servicios HTTPS en la PC-A.
● Permita que PC-C acceda a R1 a través de SSH.

Nota: Verificar resultados no mostrará una configuració n correcta para ACL 120
hasta que la modifique en la Parte 4.

Paso 1: Verifique que la PC-C pueda acceder a la PC-A a través de HTTPS

utilizando el navegador web.

Fig.96, Conexión HTTPS desde PC-C a PC-A

Asegú rese de deshabilitar HTTP y habilitar HTTPS en el servidor PC-A.

Paso 2: Configure ACL 120 para permitir y denegar específicamente el trá fico
especificado.

Utilice el comando de lista de acceso para crear una ACL de IP numerada.

 Fig.97, Configuración de la ACL 120 en R1

Paso 3: aplique la ACL a la interfaz S0/0/0.

Use el comando ip access-group para aplicar la lista de acceso al trá fico entrante
en la interfaz S0/0/0.

Fig.98, Aplicación de la ACL 120 a la interfaz serial S0/0/0

Paso 4: Verifique que la PC-C no pueda acceder a la PC-A a través de HTTPS

utilizando el navegador web.

Fig.99, Conexión fallida por HTTPS de la PC-C a PC-A

Parte 4: Modificar una ACL existente en R1

Permita respuestas de eco ICMP y mensajes inalcanzables de destino desde la

red externa (en relació n con R1). Denegar todos los demá s paquetes ICMP
entrantes.

Paso 1: Verifique que la PC-A no pueda hacer ping con éxito a la interfaz
Loopback en R2.
 Fig.100, ping fallido de PC-A a la interfaz loopback de R2

Paso 2: Realice los cambios necesarios en ACL 120 para permitir y denegar el
trá fico especificado.

Utilice el comando de lista de acceso para crear una ACL de IP numerada.

Fig.101, Reconfiguración de la ACL 120 en R1

Paso 3: Verifique que la PC-A pueda hacer ping exitosamente a la interfaz

loopback en R2.

Fig.102, ping exitoso de PC-A a la interfaz loopback de R2 luego de la reconfiguración de la ACL 120

Parte 5: Cree un IP ACL 110 numerado en R3

Denegar todos los paquetes salientes con direcció n de origen fuera del rango de
direcciones IP internas en R3.
Paso 1: Configure ACL 110 para permitir solo el trá fico de la red interna.

Utilice el comando de lista de acceso para crear una ACL de IP numerada.

Fig.103, Creación de la ACL numerada 110 en R3

Paso 2: aplique la ACL a la interfaz G0/1.

Use el comando ip access-group para aplicar la lista de acceso al trá fico entrante
en la interfaz G0/1.

Figura Fig.104, Asignación de la ACL numerada 110 a la interfaz Gigabit Ethernet 0/1 de R3

Parte 6: Crear un IP ACL 100 numerado en R3

En R3, bloquee todos los paquetes que contengan la direcció n IP de origen del
siguiente grupo de direcciones: cualquier direcció n privada RFC 1918,
127.0.0.0/8 y cualquier direcció n de multidifusió n IP. Dado que la PC-C se está
utilizando para la administració n remota, permita que el trá fico SSH de la red
10.0.0.0/8 regrese a la PC-C del host.

Paso 1: Configure ACL 100 para bloquear todo el trá fico especificado desde la
red externa.

También debe bloquear el trá fico proveniente de su propio espacio de

direcciones interno si no es una direcció n RFC 1918. En esta actividad, su
espacio de direcciones internas es parte del espacio de direcciones privadas
especificado en RFC 1918.

Utilice el comando de lista de acceso para crear una ACL de IP numerada.

 Fig.105, Configuración de la ACL numerada 100 en R3

Paso 2: aplique la ACL a la interfaz Serial 0/0/1.

Use el comando ip access-group para aplicar la lista de acceso al trá fico entrante
en la interfaz Serial 0/0/1.

Fig.106, Aplicación de la ACL numerada 100 a la interfaz serial S0/0/1 de R3

Paso 3: Confirme que el trá fico especificado que ingresa a la interfaz Serial 0/0/1
se maneja correctamente.

a. Desde el símbolo del sistema PC-C, haga ping al servidor PC-A. La ACL
bloquea las respuestas de eco ICMP, ya que se obtienen del espacio de
direcciones 192.168.0.0/16.

Fig.107, ping de PC-C a PC-A

b. Establezca una sesió n SSH a 192.168.2.1 desde PC-C (debería tener éxito).

Fig.108, Conexión SSH desde PC-C a la interfaz loopback de R2, Exitoso.

Paso 4: verifica los resultados.

 Fig.109, Resultados de la actividad " Configure IP ACLs to Mitigate Attacks "

4.1.3.4 Packet Tracer - Configuring IPv6 ACLs

Fig.110, Topología de red para el ejercicio "Configuring IPv6 ACLs"

Device Interface IPv6 Address/Prefix Default Gateway

Server3 NIC 2001:DB8:1:30::30/64 FE80::30
Tabla 6, Direccionamiento de red - ejercicio “Configuring IPv6 ACLs"

Objetivos

Parte 1: configurar, aplicar y verificar una ACL IPv6

Parte 2: configurar, aplicar y verificar una segunda ACL IPv6

Parte 1: configurar, aplicar y verificar una ACL IPv6

Los registros indican que una computadora en la red 2001: DB8: 1: 11 :: 0/64
está actualizando repetidamente una pá gina web. Esto está causando un ataque
de denegació n de servicio (DoS) contra Server3. Hasta que se pueda identificar y
limpiar el cliente, debe bloquear el acceso HTTP y HTTPS a esa red con una lista
de acceso.

Paso 1: Configure una ACL que bloqueará el acceso HTTP y HTTPS.

 Configure una ACL llamada BLOCK_HTTP en R1 con las siguientes
instrucciones.

a. Bloquee el trá fico HTTP y HTTPS para que no llegue al Servidor3.

Fig.111, Configuración de la ACL BLOCK_HTTP en R1

b. Permita que pase el resto del trá fico IPv6.

Fig.112, Configuración para permitir el tráfico IPv6 en R1

Paso 2: aplique la ACL a la interfaz correcta.

Aplique la ACL en la interfaz má s cercana a la fuente del trá fico a bloquear.

Fig.113, Aplicación de la ACL BLOCK_HTTP al tráfico entrante de la interfaz Gigabit Ethernet 0/1

Paso 3: Verifique la implementació n de ACL.

Verifique que la ACL esté funcionando segú n lo previsto realizando las

siguientes pruebas:

• Abra el navegador web de PC1 en http://2001:DB8:1:30::30 o

https://2001:DB8:1:30::30. El sitio web debería aparecer.
 Fig.114, Verificación del funcionamiento de la ACL BLOCK_HTTP en el Web Browser de PC1

• Abra el navegador web de PC2 en http://2001:DB8:1:30::30 o

https://2001:DB8:1:30::30. El sitio web debe estar bloqueado.

Fig.115,Verificación del funcionamiento de la ACL BLOCK_HTTP en el Web Browser de PC2

• Ping de PC2 a 2001:DB8:1:30::30. El ping debe ser exitoso.

Fig.116, Ping de PC2 al servidor

Parte 2: configurar, aplicar y verificar una segunda ACL IPv6

Los registros ahora indican que su servidor está recibiendo pings de muchas
direcciones IPv6 diferentes en un ataque de denegació n de servicio distribuido
(DDoS). Debe filtrar las solicitudes de ping ICMP a su servidor.

Paso 1: cree una lista de acceso para bloquear ICMP.

Configure una ACL llamada BLOCK_ICMP en R3 con las siguientes instrucciones:

a. Bloquee todo el trá fico ICMP desde cualquier host a cualquier destino.

b. Permita que pase el resto del trá fico IPv6.

Fig.117, Configuración de la ACL BLOCK_ICMP en R3

Paso 2: aplique la ACL a la interfaz correcta.

En este caso, el trá fico ICMP puede provenir de cualquier fuente. Para garantizar
que el trá fico ICMP esté bloqueado, independientemente de su origen o de
cualquier cambio que ocurra en la topología de la red, aplique la ACL má s
cercana al destino.

Fig.118, Aplicación de la ACL BLOCK_ICMP al tráfico saliente de la interfaz Gigabit Ethernet 0/0 de R3

Paso 3: Verifique que funcione la lista de acceso adecuada.

a. Haga ping desde PC2 a 2001:DB8:1:30::30. El ping debería fallar.

 Fig.119, Ping de PC2 rechazado por el servidor

b. Haga ping desde PC1 a 2001:DB8:1:30::30. El ping debería fallar.

Fig.120, Ping de PC1 rechazado por el servidor

Abra el navegador web de PC1 en http://2001:DB8:1:30::30 o

https://2001:DB8:1:30::30. El sitio web debe mostrar.

Fig.121, Verificación del funcionamiento de las ACL de IPv6 a través del Web browser (Tráfico HTTP y
HTTPS)
 Fig.122, Resultados de la actividad “Configuring IPv6 ACL’s “

4.4.1.1 Packet Tracer - Configuring a Zone-Based Policy Firewall (ZPF)

Fig.123, Topología de red ejercicio "Configuring a Zone-Based Policy Firewall (ZPF)"

Default Switch
Device Interface IP Address Subnet Mask Gateway Port
192.168.1. S1 F0/5
G0/1 1 255.255.255.0 N/A
R1
S0/0/0 N/A
(DCE) 10.1.1.1 255.255.255.252 N/A
S0/0/0 10.1.1.2 255.255.255.252 N/A N/A
R2 S0/0/1 N/A
(DCE) 10.2.2.2 255.255.255.252 N/A
192.168.3. S3 F0/5
R3 G0/1 1 255.255.255.0 N/A
S0/0/1 10.2.2.1 255.255.255.252 N/A N/A
PC-A NIC 192.168.1. 255.255.255.0 192.168.1. S1 F0/6
 3 1
192.168.3. 192.168.3. S3 F0/18
PC-C NIC 3 255.255.255.0 1
Tabla 7, Direccionamiento de red - ejercicio "Configuring a Zone-Based Policy Firewall (ZPF)"

Objetivos

• Verifique la conectividad entre dispositivos antes de la configuració n

del firewall.
• Configure un firewall de política basada en zonas (ZPF) en R3.
• Verifique la funcionalidad del firewall ZPF utilizando ping, SSH y un
navegador web.

Escenario

Los ZPF son el ú ltimo desarrollo en la evolució n de las tecnologías de firewall de

Cisco. En esta actividad, configurará un ZPF bá sico en un enrutador de borde R3
que permite a los hosts internos acceder a recursos externos y bloquea el acceso
de los hosts externos a los recursos internos. Luego verificará la funcionalidad
del firewall de los hosts internos y externos.

Los enrutadores se han configurado previamente con lo siguiente:

● Contraseñ a de la consola: ciscoconpa55

● Contraseñ a para líneas vty: ciscovtypa55
● Habilitar contraseñ a: ciscoenpa55
● Nombres de host y direccionamiento IP
● Nombre de usuario y contraseñ a locales: Admin / Adminpa55
● Enrutamiento está tico

Parte 1: verificar la conectividad de red básica

Verifique la conectividad de la red antes de configurar el firewall de políticas

basado en zonas.

Paso 1: desde el símbolo del sistema de la PC-A, haga ping a la PC-C en

192.168.3.3.
 Fig.124, ping de PC-A a PC-C

Paso 2: Acceda a R2 utilizando SSH.

a. Desde el símbolo del sistema de PC-C, SSH a la interfaz S0/0/1 en R2 direcció n

10.2.2.2. Use el nombre de usuario Admin y la contraseñ a Adminpa55 para
iniciar sesió n.

b. Salga de la sesió n SSH.

Fig.125, Conexión SSH de PC-C a la interfaz serial 0/0/1 de R2

Paso 3: desde la PC-C, abra un navegador web en el servidor de la PC-A.

a. Haga clic en la pestañ a Escritorio y luego en la aplicació n Navegador web.

Ingrese la direcció n IP de la PC-A 192.168.1.3 como URL. Se debe mostrar la
pá gina de bienvenida de Packet Tracer del servidor web.
 Fig.126, Conexión a través del Web Browser de PC-A al servidor

b. Cierre el navegador en PC-C.

Parte 2: crear las zonas de firewall en R3

Nota: Para todas las tareas de configuració n, asegú rese de usar los nombres
exactos como se especifica.

Paso 1: habilite el paquete de Tecnología de seguridad.

a. En R3, emita el comando show version para ver la informació n de la licencia

del Paquete tecnoló gico.

Fig.127, comando #show version en R3

b. Si el paquete de Tecnología de seguridad no se ha habilitado, use el siguiente

comando para habilitar el paquete.

Fig.128, Habilitación del paquete de tecnología de seguridad en R3

c. Acepte el acuerdo de licencia de usuario final.

d. Guarde la configuració n en ejecució n y vuelva a cargar el enrutador para

habilitar la licencia de seguridad.

Fig.129, Guardado de la configuración en ejecución en R3

e. Verifique que el paquete de Security Technology se haya habilitado utilizando

el comando show version.
Fig.130, comando #show version después de habilitar el paquete de tecnología de seguridad en R3

Paso 2: crea una zona interna.

Use el comando de seguridad de zona para crear una zona llamada IN-ZONE.

Fig.131, creación de zona interna de seguridad en R3

Paso 3: crea una zona externa.

Use el comando de seguridad de zona para crear una zona llamada OUT-ZONE.

Fig.132, creación de zona externa de seguridad en R3

Parte 3: Identificar el tráfico usando un mapa de clase

Paso 1: cree una ACL que defina el trá fico interno.

Utilice el comando access-list para crear ACL 101 extendido para permitir todos
los protocolos IP desde la red de origen 192.168.3.0/24 a cualquier destino.

Fig.133, Creación de ACL extendida 101 en R3

Paso 2: Cree un mapa de clase que haga referencia a la ACL de trá fico interno.

Use el comando de inspecció n de tipo de mapa de clase con la opció n de

coincidencia para crear un mapa de clase llamado IN-NET-CLASS-MAP. Use el
comando match access-group para hacer coincidir ACL 101.
 Fig.134, creación de Class-map IN-NET-CLASS-MAP en R3

Parte 4: especificar políticas de firewall

Paso 1: cree un mapa de políticas para determinar qué hacer con el trá fico
coincidente.

Utilice el comando de inspecció n de tipo de mapa de políticas y cree un mapa de

políticas llamado IN-2-OUT-PMAP.

Fig.135, creación de Class-map IN-2-OUT-PMAP en R3

Paso 2: Especifique un tipo de clase de inspecció n y mapa de clase de referencia

IN-NET-CLASS-MAP.

Fig.136, Tipo de clase de inspección en IN-NET-CLASS-MAP

Paso 3: especifique la acció n de inspecció n para este mapa de políticas.

El uso del comando inspect invoca el control de acceso basado en el contexto

(otras opciones incluyen pasar y soltar).

Fig.137, uso del comando #inspect en R3

% Ningú n protocolo específico configurado en la clase IN-NET-CLASS-MAP para

inspecció n. Todos los protocolos será n inspeccionados.

Emita el comando de salida dos veces para salir del modo config-pmap-c y volver
al modo config.

Fig.138, Salir del modo config-pmap-c en R3

Parte 5: aplicar políticas de firewall

Paso 1: crea un par de zonas.

Usando el comando de seguridad de par de zonas, cree un par de zonas llamado
IN-2-OUT-ZPAIR. Especifique las zonas de origen y destino que se crearon en la
Tarea 1.

Fig.139, creación del par de zonas en R3

Paso 2: especifique el mapa de políticas para manejar el trá fico entre las dos
zonas.

Adjunte un mapa de políticas y sus acciones asociadas al par de zonas utilizando

el comando de inspecció n de tipo de política de servicio y haga referencia al
mapa de políticas creado previamente, IN-2-OUT-PMAP.

Fig.140, Mapa de políticas en R3

Paso 3: Asignar interfaces a las zonas de seguridad apropiadas.

Use el comando de seguridad de miembro de zona en el modo de configuració n

de interfaz para asignar G0 / 1 a IN-ZONE y S0 / 0/1 a OUT-ZONE.

Fig.141, Asignación de interfaces a las zonas de seguridad

Paso 4: Copie la configuració n en ejecució n a la configuració n de inicio.

Fig.142, Guardar la configuración en ejecución a la de inicio en R3

Parte 6: Pruebe la funcionalidad del firewall de IN-ZONE a OUT-ZONE

Verifique que los hosts internos aú n puedan acceder a los recursos externos
después de configurar el ZPF.

Paso 1: Desde la PC-C interna, haga ping al servidor externo de la PC-A.

Desde el símbolo del sistema de la PC-C, haga ping a la PC-A en 192.168.1.3. El

ping debería tener éxito.
 Fig.143, ping desde la PC-C al Servidor externo

Paso 2: desde la PC-C interna, SSH hasta la interfaz R2 S0/0/1.

a. Desde el símbolo del sistema de PC-C, SSH a R2 en 10.2.2.2. Use el nombre de

usuario Admin y la contraseñ a Adminpa55 para acceder a R2. La sesió n SSH
debería tener éxito.

Fig.144, Conexión SSH de PC-C a R2

b. Mientras la sesió n SSH está activa, emita el comando show policy-map type
inspeccione sesiones de pares de zonas en R3 para ver las sesiones establecidas.

Fig.145, comando show policy-map type

¿Cuá l es la direcció n IP de origen y el nú mero de puerto?

La direcció n es 192.168.3.3:1028 (puerto aleatorio 1028)

¿Cuá l es la direcció n IP de destino y el nú mero de puerto?

La direcció n destino es la 10.2.2.2:22 (SSH / puerto 22)

Paso 3: desde PC-C, salga de la sesió n SSH en R2 y cierre la ventana del símbolo
del sistema.

Fig.146, Cierre de la sesión SSH entre PC-C y R2

Paso 4: desde la PC-C interna, abra un navegador web en la pá gina web del
servidor de la PC-A.

Ingrese la direcció n IP del servidor 192.168.1.3 en el campo URL del navegador y

haga clic en Ir. La sesió n HTTP debería tener éxito. Mientras la sesió n HTTP está
activa, emita el comando show policy-map type inspect zone-pair sessions en R3
para ver las sesiones establecidas.

Fig.147, Conexión por medio del Web Browser desde PC-C al Servidor
 Fig.148, show policy-map type inspect zone-pair sessions

Nota: Si se agota el tiempo de espera de la sesió n HTTP antes de ejecutar el

comando en R3, deberá hacer clic en el botó n Ir en la PC-C para generar una
sesió n entre la PC-C y la PC-A.

¿Cuá l es la direcció n IP de origen y el nú mero de puerto?

La direcció n IP de origen es la 192.168.3.3:1031 (puerto aleatorio 1031)

¿Cuá l es la direcció n IP de destino y el nú mero de puerto?

La direcció n destino es 192.168.1.3:80 (HTTP web / Puerto 80)

Parte 7: Pruebe la funcionalidad del firewall desde OUT-ZONE a IN-ZONE

Verifique que los hosts externos NO PUEDEN acceder a los recursos internos
después de configurar el ZPF.

Paso 1: desde el símbolo del sistema del servidor PC-A, haga ping a PC-C.
Desde el símbolo del sistema de la PC-A, haga ping a la PC-C en 192.168.3.3. El
ping debería fallar.

Fig.149, ping de PC-A a PC-C, fallido

Paso 2: desde R2, haga ping a PC-C.

Desde R2, haga ping a PC-C en 192.168.3.3. El ping debería fallar.

Fig.150, ping de R2 a PC-C

Paso 3: verifica los resultados.

Fig.151, Resultado de la actividad Configuring a Zone-Based Policy Firewall (ZPF)

 CONCLUSIONES

En la aplicación de sistemas de seguridad a nivel de acceso es importante realizar una

correcta configuración del servidor NTP, ya que si no se aplican los parámetros correctos
de sincronización de reloj se pueden presentar pérdidas de paquetes en la transmisión y
problemas de sincronismo que pueden resultar en problemas más graves como la pérdida de
gestión o la aparición de alarmas registradas en el Syslog, que según su configuración
pueden ejecutar rechazos indeseados.
Las listas de control de acceso son uno de los sistemas de filtrado de paquetes más comunes
y más efectivos, ya que se pueden configurar para permitir o denegar el tráfico, además que
al no permitir el paso de la información de transporte contenida en el datagrama, hace que
el desempaquetado sea imposible de realizar por el receptor.
En la administración de redes juega un papel fundamental el administrador de Firewall, ya
que hay muchos programas y contenidos que pueden ser perjudiciales para la red, y en la
correcta aplicación de políticas está el éxito de este sistema de protección. Por ello, a nivel
empresarial se aplican normas de seguimiento, autorización y requisitos precisos a la hora
de tener que realizar un cambio de políticas; lo que conlleva a centralizar la administración
en un grupo muy reducido de especialistas.
 BIBLIOGRAFIA

Álvarez, A. (17 de Mayo de 2009). Entre Redes y Servidores. Obtenido de

https://alexalvarez0310.wordpress.com/category/listas-de-control-de-acceso-en-router-
cisco/

Ariganello, E. (31 de Octubre de 2006). Aprende Redes.com. Obtenido de

https://aprenderedes.com/2006/10/tipos-de-listas-de-acceso/

Baluja, W., & Anías, C. (2006). Arquitectura de Seguridad para las redes de
Telecomunicaciones . Departamento de Telecomunicaciones, Instituto Superior
Politécnico José Antonio Echeverría, CUJAE., 11.

Galleon Systems. (2008). Galleon Systems. Obtenido de https://es.galsys.co.uk/time-

reference/ntp-time-servers/ntp-security.html

Hernández, J. (29 de Mayo de 2013). Blog Hostalia. Obtenido de

https://blog.hostalia.com/white-papers/white-paper-protocolo-ssh/

López, A. (05 de Febrero de 2015). Incibe-Cert. Obtenido de https://www.incibe-

cert.es/blog/protocolos-aaa-radius.

Alonso, I. (2013). ANALISIS COMPARATIVO DE DOS PROTOCOLOS PARA

CONTROL DE ACCESO Y ADMINISTRACION DE EQUIPOS DE
TELECOMUNICACIONES. UNIVERSIDAD CATOLICA DE COLOMBIA, 22.