T1 CEP Modern Network Security Threats

Securing Network
Devices
© 2007 Cisco Systems, Inc. Todos los derechos reservados. Cisco Public 1
Introducción
Asegurar el tráfico saliente y entrante.
Asegurar el router perimetral.
Metodologías de prevención en routers mediante CLI y mediante
SDM.
Protección de accesos administrativos, gestión de claves, SSH.
Definición de roles administrativos.
Gestión de Syslog y SNMP.
Configuración de NTP.
Empleo del comando “auto secure”
La práctica “Securing the Router for Administrative Access” permite
introducir varias posibles medidas de seguridad en los accesos
administrativos a un router.
Hay tambien una actividad de Packet Tracer en la que aprenderemos
la configuracion de Syslog, NTP y SSH.
ASEGURAR DISPOSITIVOS DE
ACCESO
Asegurar el Router perimetral
Es muy importante asegurar la infraestructura de red:

routers, switches, dispositivos finales y otros
dispositivos.
Es necesario implementar políticas de seguridad que
permitan prevenir el acceso no autorizado a la
infraestructura de red.
El denominado “Edge router” llamado por • nosotros
router perimetral es el último router de una empresa
que separa la red interna segura y la externa
potencialmente insegura. Supone la primera y la ultima
línea de defensa de la red.
Asegurar el Router perimetral (y II)
La implementación del router perimetral depende del tamaño de la

organización. Hay varias aproximaciones a la solución de este problema.
–Router único: En este caso todas las políticas de seguridad están configuradas
en este dispositivo. Propia de redes pequeñas
Asegurar el Router perimetral (y II)
Aproximación más profunda de defensa: Es una aproximación más
segura. En este caso el router perimetral actúa como primera línea de
defensa. Este router investiga el tráfico antes de entregárselo a un
Firewall dedicado. El FW es la segunda línea de defensa.
–El FW realiza filtrados adicionales al Router. Proporciona control de acceso
analizando el estado de las conexiones.
–El FW por defecto prohíbe el tráfico de la red insegura (Outside) a la red segura
(Inside) si este tráfico se genero externamente.
–Se pueden implementar mecanismos de autenticación proxy para garantizar el
acceso a los recursos de red.
Asegurar el Router perimetral (y III)
Aproximación DMZ: Variación del caso anterior en el
que el router delimita una zona intermedia denominada
DMZ en la que se alojan los servidores que se
pretende que sean accedidos desde las redes
externas.
–La DMZ se puede establecer entre dos routers o incluso como
un puerto adicional de un único router.
Asegurar el Router perimetral (y IV)
Cuando hablamos de asegurar un router perimetral hay tres áreas
a cubrir
–Seguridad física: Localización física, control de acceso, UPS…
–Seguridad del sistema operativo: Garantizar las características y el
rendimiento del sistema operativo del router.
•Instalar la máxima cantidad posible de memoria (intenta evitar ataques
DOS)
•Usar la versión estable mas moderna de SO
•Mantener backups de la imagen del SO y de los ficheros de
configuración.
–Router hardening (Endurecimiento de las medidas de seguridad en el
router)
•Eliminar el abuso potencial de puertos y servicios no empleados
•Controlar los accesos administrativos al dispositivo.
•Deshabilitar puertos e interfaces no empleados
•Deshabilitar servicios innecesarios
Asegurar el Router perimetral (y V)
El acceso administrativo al router es necesario para

gestionar el dispositivo.
Para asegurar dicho acceso podemos tomar las siguientes
medidas:
–Restringir la accesibilidad al dispositivo.
–Loguear el acceso de todas las cuentas.
–Permitir solo el acceso para usuarios autenticados. Limitar el
numero de intentos.
–Restringir las acciones autorizadas
–Mostrar un banner de información legal
–Asegurar la confidencialidad de los datos almacenados y también
de los datos en transito (intentar evitar sniffing, hijacking y Man in
the Middle)
Asegurar el Router perimetral (y VI)
A la hora de proteger el acceso
administrativo hay dos modalidades a
proteger el acceso local y el acceso
remoto.
Acceso local basado en puertos de
consola y software de emulación de
terminal.
Acceso remoto
– Telnet y/o SSH
– HTTP y/o HTTPS
– SNMP
En los accesos remotos se envían
Usernames/Password en texto claro y
pueden ser capturadas. Por ello es
preferible emplear accesos locales y no
remotos,
Caso de emplear el acceso remoto es
recomendable emplear conexiones con
tráfico cifrado, establecer una red de
gestión dedicada y filtrar los hosts desde
los cuales se puede realizar dicha tarea.
Configurando el acceso administrativo
seguro
Los atacantes que intentan obtener las claves de acceso
pueden emplear varios métodos
–Obtención de claves a partir de información personal
–Sniffing de paquetes TFTP con claves en texto plano
–Ataques de fuerza bruta
–Búsqueda de claves de invitado
Para protegernos es necesario emplear claves robustas y
seguras. Podemos tomar algunas de las siguientes
medidas.
–10 caracteres como mínimo
–MAY y min, números, símbolos y espacios
–Evitar palabras del diccionario, mascotas, secuencias …
–No escribir claves.
–Cambio de claves a menudo
seguro (y III)
Hay varios puertos de un router que pueden requerir claves:
–Puertos de consola, AUX y conexiones de terminal virtual
En redes grandes se puede emplear TACACS y RADIUS
mediante un Servidor de autenticación CSACS.
En redes pequeñas las claves se almacena en una base de datos
mantenida localmente.
Se pueden emplear niveles de privilegio a la hora de acceder al
dispositivo.
Las claves se configuran en EXEC privilegiado.
–“Enable secret password”:Se ejecuta en modo EXEC privilegiado. Clave
codificada con algoritmo HASH MD5. Si se pierde la clave hay que
emplear un procedimiento de recuperación de claves.
–Linea de consola.
•Por defecto no se necesita clave para acceder desde consola. Si se
desea que se requiera clave al acceder hay que emplear el comando
“line console 0” y luego en el modo de configuración de consola
requerir el login con la clave correspondiente.
seguro (y II)
Configuración de las líneas de terminal virtual VTY.
– Por defecto los router Cisco soportan hasta 5 conexiones simultaneas VTY (Telnet o SSH).
Linea AUX: Se emplea para realizar configuraciones remotas a través de una línea de
modem. Por defecto no tienen claves
Por defecto con excepción de la clave enable todas las demás son almacenadas sin
cifrar y por lo tanto pueden ser vistas con “show running-config” o mediante sniffers en
conexiones TFTP al hacer backups de ficheros de configuración.
seguro (y III)
Para aumentar la seguridad de las claves es posible
tomar las siguientes medidas:
–Forzar a una longitud mínima de la clave: Con el comando
“security password min-length length” es posible configurar una
longitud mínima de 0 a 16 caracteres.
–Deshabilitar conexiones desatendidas: Por defecto esta
establecido a 10 minutos. El temporizador puede controlarse a
través del comando “exec-timeout”
–Encriptar todas las claves: A través del comando “service
password encryption” el cual no afecta al comando “enable
secret” puesto que este ya cifra con MD5.
seguro (y IV)
Una característica de seguridad disponible es la autenticación.

Es posible emplear una base de datos local que mantengan una lista de usuarios y claves. Hay dos métodos.
– Username name password password
– Username name secret password
La segunda opción es más segura puesto que emplea el algoritmo MD5 el cual es mucho mas seguro que MD7
que es el que emplea el comando “service password encryption”
Para habilitar la base de datos local para autenticación se puede emplear el comando “login local”
Configurando seguridad mejorada para
logins virtuales
En términos de seguridad es necesario evitar en la medida de lo
posible accesos remotos encaminados a obtener las parejas
usuario/clave.
En consecuencia es necesario bloquear al sistema ante intentos
repetidos de autenticación incorrecta. Este bloqueo debe durar un
cierto tiempo.
Es necesario mediante ACL programar la posibilidad de acceso
durante ese “quiet time” de los legítimos administradores.
Para ello Cisco IOS proporciona entornos mas seguros que
intentan evitar o mitigar ataques de DOS basados en HTTPS y
SSH. Para conseguir este entorno mas seguro es posible
configurar los siguientes parámetros.
–Retrasos entre intentos sucesivos de logueados.
–Login shutdown si se sospecha que se esta produciendo un ataque DOS
–Generación de mensajes de log para la detección de logueados.
Todas estas medidas NO se aplican a las conexiones de consola.
logins virtuales (y II)
Los comandos necesarios para
conseguir las mejoras de seguridad
anteriores son.
–“login block –for seconds attempts tries
within seconds”
–“login quiet-mode access-class {acl-
name|acl-number}
–“login delay seconds”
–“login on-failure log [every login]”
–“login on-success log [every login]”
Todas estas mejoras de configuración
solo son posibles emplearlas usando
una configuración de usuario/clave si
solo se emplea clave en líneas vty no
es posible sacar partido a estas
mejoras.
logins virtuales (y III)
Todas las mejoras de seguridad por defecto están deshabilitadas.
El comando “login block-for” monitorea la actividad de logins y opera en dos
modos
– Modo normal: cuenta el numero de intentos a lo largo de un tiempo.
– Modo quiet (periodo de tranquilidad): Si el numero de intentos fallidos sobrepasa un
limite todos los intentos de acceso basados en SSH, Telnet y HTTP serán denegados.
– Al habilitar el modo quiet es necesario crear una ACL que se identifica con el comando
“login quiet mode access-class”
Cuando se realizan ataques a la búsqueda de una clave se hacen multitud de

intentos en muy cortos intervalos de tiempo, por ello hay un comando que
permite gestionar el tiempo mínimo necesario entre intentos de login
sucesivos.
– Comando “login delay”
– Ayuda a mitigar ataques de diccionario.
logins virtuales (y IV)
El comando “auto secure” habilita los mensajes de logging para
intentos fallidos de logueado. Se puede emplear para analizar el
numero de intentos exitosos y fallidos.
–Comando “login on-failure log [every login]” el cual genera logs para
peticiones de login fallidas.
–Comando “login on-success log [every login]” el cual genera logs para
peticiones de login exitosas.
–Para controlar el numero de intentos antes de la generación del mensaje
se especifica con “[every login]”
–También se podría emplear el comando “security authentication failure rate
tresholdrate log” que genera un mensaje de log al exceder una tasa de
fallos concreta.
Tenemos el comando “show login” para poder analizar si el router
se encuentra en modo normal o en modo quiet.
Para obtener más información tenemos el comando “show login
failures” que muestra información de los fallos, desde que IPs y
cuantas veces.
logins virtuales (y V)
Es importante emplear banners que informen a los legítimos
usuarios y a los posibles intrusos en un sistema.
Es importante ubicar correctamente el banner.
Por defecto los banners están deshabilitados.
El comando es el siguiente:
–“banner {exec | incoming | login | motd | slip-ppp} d message d
El comando “banner” permite emplear alguna de las siguientes
variables dentro del comando “banner”
–$(hostname): Nombre del router.
–$(domain): Nombre del dominio del router.
–$(line): Muestra el numero de la línea vty o tty(asincrona)
–$(line-desc): Muestra la descripción de la línea.
• También es posible emplear SDM para configurar el comando
“banner”
Configurando SSH
Tradicionalmente las tareas de configuración remota se hacen a través del protocolo
TELNET que envía la información en texto claro.
SSH frente a telnet proporciona confidencialidad e integridad en las comunicaciones. La

funcionalidad es similar a Telnet, en consecuencia de este modo podemos obtener
comunicaciones seguras a través de redes no seguras.
Los pasos para configurar SSH son las siguientes:

– Asegurar que los routers disponen de una imagen IOS que soporte SSH lo cual ocurre a partir de
la versión 12.1(1)T.
– Asegurar que cada router tiene un nombre de host único.
– Asegurar que cada router tiene un nombre de dominio correcto.
– Asegurar de que los routers están configurados para autenticación local AAA.
Configurando SSH (y II)
Configuración de SSH a través de CLI
– PASO 1: Si el router tiene un nombre de host único, pero también hay que configurar el
nombre de dominio con el comando “ip domain-name domain-name”
– PASO 2: Es necesario generar una clave secreta de una direccion para que el router
encripte el trafico SSH.
Cisco IOS emplea el algoritmo de claves asimetricas RSA
El comando a emplear es “crypto key generate rsa general-keys modulus
modulus-size”
La clave RSA puede ser de 360 a 2048 bits (Minimo recomendado de 1024
bits)
Para verificar el fucnionamiento emplearemos el comando “show crypto key
mypubkey rsa”
Si ya existiera una pareja de claves podemos usar el siguiente comando para
sobreescribir las claves “crypto key zeroide rsa”
– PASO 3: Asegurar que el nombre de usuario existe en la base de datos local, en caso
contrario emplear el comando “username name secret secret”
– PASO 4: Habilitar las conexiones entrantes VTY SSH con el comando “login local” y
“transport input ssh”
Configurando SSH (y III)
Comandos opcionales SSH
– Versión SSH
– Periodo de Timeout SSH
– Numero de intentos de autenticación.
Hay dos versiones soportadas SSHv1 y SSHv2 la cual incorpora el algoritmo
Diffie-Hellman como mecanismo de intercambio de claves e incorpora mejoras
relacionadas con la integridad a través de MAC (Message Authentication
Code)
Cisco IOS 12.1(1)T y posteriores soportan SSHv1.
Cisco IOS 12.3(4)T y posteriores soportan SSHv1 y SSHv2. El comando que
lo permite es “ip ssh versión {1|2}”
Para controlar el tiempo que el router espera a una respuesta por parte del
cliente mediante el comando “ip ssh time-out seconds”. Por defecto es 120
segundos
Para controlar el numero de intentos antes de que un usuario sea
desconectado podemos emplear el comando “ip ssh authentication-retries
integer”
Para verificar las configuraciones anteriores tenemos disponible el comando
“show ip ssh”
Configurando SSH (y IV)
Modos de conexión a un router con SSH habilitado

–Conexión empleando el comando “ssh” (Conexión Router-
Router)
–Conectar a través de un cliente SSH (Por ejemplo Putty o
OpenSSH) (Conexión Host-Router)
Configurando SSH (y V)
También es posible configurar SSH a través de SDM
– Podemos ver la pareja de claves RSA mediante Configure ->
Aditional tasks -> Router Access -> SSH y podemos encontrarnos
ante dos casos:
•La pareja de claves RSA no está establecida en el Router.
•La pareja de claves RSA SI está establecida en el Router.
En cuyo caso SSH esta habilitado en el Router.
– Para generar la clave RSA hay un botón que nos permite crearlas
con la elección del parámetro modulo de la clave.
– También es necesario configurar las líneas VTY para que
soporten SSH a través de Configure -> Additional tasks -> Router
Access -> VTY
ASIGNACIÓN DE ROLES
ADMINISTRATIVOS
Configuración de niveles de privilegio
La configuración de distintos niveles de privilegio permite
determinar quien esta permitido que se conecte a un dispositivo y
que es lo que puede hacer.
A priori hay dos niveles de acceso:
–Modo EXEC de usuario (Nivel de privilegio 1): Proporciona el nivel de
seguridad mas bajo y solo permite ejecutar comandos de modo usuario
router>
–Modo privilegiado (Nivel de privilegio 15): Este nivel proporciona la
posibilidad de emplear cualquier comando del modo privilegiado router#
Hay dos modos de proporcionar acceso a la infraestructura:
–Niveles de privilegio
–Gestión basada en Roles
Configuración de niveles de privilegio (y II)
Asignación de niveles de privilegio
A partir de la versión 10.3 de IOS es posible trabajar con niveles de privilegio.
Es posible asignar diferentes comandos a diferentes niveles de privilegio.
Un nivel de privilegio permite ejecutar también los comandos de los niveles de privilegio
de niveles inferiores.
Para configurar niveles de privilegio el comando es: “privilege mode {level level
command | reset} command”
En el caso de asociar un comando como por ejemplo “show ip route” a un nivel de
privilegio determinado automaticamente se asocian a dicho nivel todos los comandos
que empiezan por esa secuencia o subcomando.
El nivel 0 esta predefinido para privilegios de usuario con cinco comandos: disable,
enable, exit, help, logout
El nivel 1 es el nivel por defecto router> En este nivel de privilegio no es posible realizar
cambios en el fichero de configuración.
Los niveles de 2 al 14 son configurables por el administrador.
El nivel 15 es el modo privilegiado (enable) y es posible realizar cualquier tarea.
Configuración de niveles de privilegio (y III)
Para realizar la asignacion de claves a los niveles de
privilegio hay dos metodos:
–Asignacion de clave a un nivel mediante el comando “enable
secret level level password”
–Asignacion de clave a un nivel usuario “username name
privilege level secret password”
Configuración de Acceso CLI Basado en
Roles
Cisco introduce CLI basado en Roles a partir de la versión 12.3(11)T.
Este sistema proporciona un sistema más flexible que el empleo de
niveles de privilegio.
–Permite un control mucho mas granularizado.
–Permite crear diferentes vistas del router para diferentes usuarios.
–Cada vista define los comandos CLI que cada usuario puede ejecutar.
En términos de seguridad gracias a los roles se mejora sustancialmente
esta debido a que se controla mucho mas que usuario puede ejecutar que
comandos.
El empleo de Roles permite evitar la ejecución no intencionada de
determinados comandos.
El empleo de Roles supone una mayor eficiencia operacional, puesto que
para cada usuario gestionar el router es mas sencillo puesto que solo se
preocupa de los comandos que tiene asignados.
Roles (y II)
Los roles CLI proporciona tres tipos de vistas:
–Vista Root: Tiene los mismos niveles de privilegio que el nivel 15. Aun asi
no es lo mismo puesto que solo en la Vista Root se pueden crear o
eliminar comandos de las vistas. Permite definir vistas CLI y Supervistas.
–Vista CLI
•Podemos especificar un conjunto de comandos bajo una vista
especifica.
•En una vista CLI no hay jerarquia de comandos.
•No hay herencia de comandos de otras vistas.
•Un mismo comando puede estar asociado a multiples vistas.
–Supervista: Consiste en una o mas vistas CLI.
•La supervista permite asignar usuarios y grupos a multiples vistas.
•Los comandos no se asocian a supervistas sino a Vistas CLI las
cuales a su vez forman parte de una supervista.
•Cada supervista tiene una clave con la cual se puede cambiar entre
una supervista o una vista CLI.
•Al borrar una supervista no se borran las vistas CLI. Estas pueden
seguir siendo usadas por otras supervistas.
Roles (y III)
Antes de emplear y crear una vista es necesario habilitar AAA con el
comando “aaa newmodel” o mediante SDM.
Para loguearse en Cista Root es necesario ejecutar el comando “enable
view” o el comando “enable view root” y que pedira la clave de acceso.
Para gestionar las vistas hay que realizar lo siguiente:
–Paso 1: Habilitar AAA con “aaa new-model” y entrar en la vista Root mediante
“enable view”
–Paso 2. Crear una vista con el comando “parser view view-name”. De este
modo creamos una vista y entramos en su modo de configuración de vista. Se
pueden crear hasta 15 vistas.
–Paso 3: Asignar una clave secreta a la vista con el comando “secret
encryptedpassword”
–Paso 4. Asignar comandos a la vista con el comando “parser-mode
{include|includeexclusive|exclude} [all] [interface interface_name | command]”
Roles (y IV)
Ejemplo de creación de roles
Roles (y III)
Creación y configuración de una supervista.
Para crear o gestionar una supervista es
necesario estar en vista root para ello se puede
emplear el comando “enable view” o bien el
comando “enable view root”
Paso 1: Crear una supervista con el comando
“parser view view-name superview” y con ello
entramos en modo de configuración de
supervista.
Paso 2: Asignar una clave secreta a la vista con
el comando “secret encrypted-password”
Paso 3: Asignar una vista existente con el
comando “view view-name”
Se pueden asociar varias vistas a una
supervista y a su vez varias supervistas pueden
compartir una vista.
Para acceder a una vista emplearemos el
comando “enable view viewname” e
introduciremos la clave correspondiente
Si deseamos verificar los comandos disponibles
en la vista ejecutaremos el comando ?
MONITOREANDO Y
GESTIONANDO DISPOSITIVOS
Asegurando la imagen de Cisco IOS y los
ficheros de configuración
Es necesario proteger el acceso no autorizado a las imágenes del
IOS asi como a los ficheros de configuración.
Con ello se intenta:
–Evitar la alteracion y borrados no permitidos de los ficheros de configuración.
–Ser capaces de garantizar la restauracion de las imágenes IOS si fuera
necesario.
La caracteristica “Configuracion Resistente Cisco IOS” es muy util
cuando alguien borra la memoria Flash o los ficheros de
configuración alojados en la NVRAM. Y permite mantener una copia
segura de los ficheros de configuración.
Al asegurar una imagen Cisco IOS se deniegan las peticiones de
copia, modificación y borrado de los mismos.La copia segura de los
ficheros de configuración se aloja en Flash segura igual que el IOS. A
esa copia segura se le denomina “bootset”.
La caracteristica “Resilient” esta disponible solo en sistemas que
soporten Interfaz PCMCIA ATA Flash.
Para configurar el sistema resistente se emplean dos comandos:
“secure boot-image” y “secure boot-config”
El comando “secure boot-image” habilita Cisco IOS Image Resilience y el log
correspondiente.
Este comando solo funciona cuando la imagen se ejecuta desde una unidad
Flash con un interfaz ATA.
No es posible securizar imágenes arrancadas via TFTP.
La configuración Cisco IOS resistente detecta versiones de IOS que no
coinciden se muestra un mensaje como “ios resilience: Archived image and
configuration version 12.2 differs from running version 12.3”
Para actualizar la imagen de IOS se emplea el comando “secure boot-config”
El fichero de configuración esta oculto y no se puede ver a tarvés del
comando “dir” ni borrar directamente a través de CLI. Cisco IOS previene que
esos ficheros no puedan ser visualizados.
Para verificar la existencia de los ficheros de configuracion running-config y
startup-config se emplea el comando “show secure bootset”
El modo Monitor de ROM ROMmon no tiene restricciones de visualización de
los ficheros de configuración.
Los pasos para restaurar un bootset desde un archivo
seguro son los siguientes:
–Paso 1: recargar el router con el comando “reload”
–Paso 2: Desde el modo ROMmon ejecutar el comando “dir” para
ver el contenido del dispositivo que contiene el fichero seguro
bootset. También desde CLI podemos ejecutar el comando “show
secure bootset”
–Paso 3: Arrancar una imagen segura bootset mediante el
comando “boot” con el fichero que localizamos en el Paso 2.
Cuando el router arranque cambiar al modo EXEC y restaurar la
configuración.
–Paso 4: Entrar en modo de configuración de terminal.
–Paso 5: Restauar la configuración segura empleando el comando
“secure boot-config restore filename”
Procedimiento de recuperación de claves en el caso de perdida de clave de acceso al router.
– Requiere acceso físico al puerto de consola del router.
– El procedimiento se resume en 14 pasos:
Conectar al puerto de consola.
Con el comando “show versión” analizamos el registro de configuración que controla el proceso de
arranque que habitualmente tiene el valor 0x2102 0x102
Apagamos el router.
Durante los 60 primeros segundos del arranque se interrumpe el arranque para entrar en modo
ROMmon.
Modificamos el registro de configuración con “confreg 0x2142” Con lo que en el siguiente arranque el
sistema ignora el fichero de configuración.
En el modo ROMmon rearrancamos el router con el comando “reset”
Durante el arranque NO entramos en el menú de configuración e interrumpimos el proceso con
CRTL+C
Entramos en modo enable
Ejecutamos copy startup-config running-config (OJO no al revés)
Entramos en modo de configuración y cambiamos la clave con “enable secret nuevaclave”
Volvemos a poner el registro de configuración al valor inicial con “config-register 0x2102”
Ejecutamos copy running-config startup-config y reiniciamos normalmente
Si un potencial atacante tiene acceso físico al router podría

ejecutar un proceso de recuperación de emergencia.
Con el comando “no service password-recovery” se deshabilita el
acceso al modo ROMmon y no será posible realizar procesos de
recuperación de emergencia.
Para recuperar un sistema que tenga habilitado el comando “no
service password-recovery” seria necesario interrumpir la
secuencia de arranque durante los cinco primeros segundos
durante la descompresión del IOS.
Habría que borrar completamente el fichero de configuración y de
nuevo arrancar con un fichero de configuración por defecto
Gestión segura y Documentación e Informes
Cuanto más grande es una red más compleja es su gestión por ello se hace
necesario implementar mecanismos de gestión lo más automatizados
posibles de modo que mediante autenticación previa y con un mínimo numero
de cambios en los dispositivos y archivos de configuración se pueda acceder
y volcar dicha información vía FTP y/o TFTP.
Es necesario realizar logs de todas las tareas de gestión y configuración de
los dispositivos.
Hay disponibles distintos protocolos para realizar las tareas de monitorización
entre ellos SNMP.
Mediante SNMP podemos monitorear y gestionar dispositivos remotamente.
Cuando se gestiona y loguea información hay dos vías
– OOB (Fuera de Banda): En este caso la información fluye a través de una red de gestión
dedicada en la cual no hay tráfico de producción.
– En Banda: La información fluye a través de la red de producción, internet o ambos canales.
En el caso de OOB el servidor de terminal se conecta a todos los dispositivos
a través de los puertos de consola de cada dispositivo gestionado y
monitorizado.
En el caso “En Banda” si el trafico fluye por Internet seria necesario filtrar y
cifrar la información
Gestión segura y Documentación e Informes
(y II)
La gestión OOB es apropiada para grandes empresas.
Proporciona altos niveles de seguridad
En cuanto a la modalidad “En Banda” se suele emplear
en redes pequeñas.
Para garantizar la seguridad en la modalidad “En
banda” se emplean los protocolos Ipsec SSH y SSL
cuando sea posible.
Usar Syslog para proporcionar seguridad en
la red
Los routers pueden loguear las siguientes
informaciones:
– Cambios de configuración.
– Violaciones ACL
– Estado de los interfaces y otros eventos.
Los mensajes de LOG se pueden enviar de varios
modos:
– Consola (es la modalidad por defecto)
– Líneas de terminal
– Buffered logging (Los mensajes se almacenan en el router
durante un tiempo)
– SNMP Traps: Los eventos al exceder un valor se procesan y
se transmiten a un servidor externo SNMP
– Syslog: Se transmiten los mensajes de LOG a un servicio
SYSLOG externo.
Los mensajes de LOG pueden tener hasta ocho
niveles donde el nivel mas alto es aquel con menor
numero.
Los mensajes de LOG tienen tres partes. Sello
temporal, Nombre del Mensaje de Log con el nivel de
severidad asociado y texto del mensaje
correspondiente.
la red (y II)
Las implementaciones syslog contienen dos tipos de sistemas:
– Servidores Syslog: Son las maquinas que aceptan y procesan los mensajes de LOG que
provienen de los clientes,
– Clientes Syslog: Routers o cualquier otro tipo de equipamiento que generan y transmiten
mensajes de LOG a los Servidores de SYSLOG.
Si se quieren emplear servidores de SYSLOG centralizados una solución es
emplear “Cisco Security Monitoring, Analysis, and Response System (MARS)”
que son dispositivos dedicados que se encargan de recibir y analizar
mensajes de syslog procedentes de muchas fuentes.
• Pasos necesarios para configurar SYSLOG:
– Paso 1: Establecer la maquina destino de los mensajes de LOG con el comando “logging
host [host_name|ip_address]
– Paso 2: Establecer el nivel de severidad (trap) mediante el comando “logging trap level”
(opcional)
– Paso 3: Establecer el interfaz fuente de los mensajes de LOG mediante el comando
“logging sourceinterface interface-type interface-number”
– Paso 4: Habilitar el logging con el comando “logging on”. Si el comando “logging on” está
deshabilitado no se mandan mensajes y solo lo recibe la consola. Si se quiere controlar
diferentes destinos emplearemos:
•Logging buffered
•Logging monitor
•Logging global
la red (y III)
Configuración de syslog mediante SDM
– Paso 1: Menú Configure -> Addtional Tasks -> Router Properties -> Logging
– Paso 2: Pulsar en el botón “Edit”
– Paso 3: En la ventana de logging elegir el nivel de logging en la lista desplegable
– Paso 4: Pulsamos en Add e introducimos la IP de destino de los mensajes de LOG.
– Paso 5 y 6: se aceptan los cambios
Usando SNMP para proporcionar seguridad
de red
SNMP se emplea para gestionar nodos, servidores, estaciones de

trabajo, routers, switches, hubs y dispositivos de seguridad.
SNMP es un protocolo de capa de aplicación que permite analizar el
rendimiento de la red.
SNMP esta basado en agentes, sistemas gestores de red (NMSs) y
bases de datos de información (MIBs)
A través del protocolo SNMP se puede obtener información de los
agentes y cambiar o establecer información en dichos agentes.
de red (y II)
SNMP acepta comandos y peticiones desde sistemas de gestión
NMS solo si los sistemas tienen el “community string” adecuado que
se emplea para autenticar mensajes entre la estación de gestión y el
agente de modo que se permita el acceso a la información MIB.
Hay dos tipos de community strings
–De Solo lectura: Proporcionan acceso de solo lectura a todos los objetos de la
MIB. (GET)
–De Lectura/Escritura: Proporcionan acceso de R/W a los objetos de las MIB.
(SET)
Los valores por defecto de los community string R y R/W son “public”
y “private” lo que supone una gran vulnerabilidad del dispositivo.
La versión SNMPv3 incorpora varias funcionalidades relacionadas
con la seguridad:
–Autenticación – El mensaje proviene de una fuente valida
–Privacidad – Encriptación de los datos
–Control de acceso e Integridad
de red (y III)
Configuración de SNMP en SDM

–– Es muy importante decidir el modelo de seguridad que vamos a emplear lo
cual esta muy relacionado con la versión del protocolo SNMP que vamos a
emplear. SNMP v1, v2c y v3.
•Noauth: Se autentica cada paquete con un nombre de usuario o un
community string.
•Auth. Se autentica un paquete empleando HMAC con MD5 o SHA.
• Priv: Autentica un paquete empleando HMAC MD5 o HMAC SHA y la
información se cifra con DES, 3DES o AES.
–Solo SNMPv3 soporta “auth” y “priv” y SDM no soporta SNMPv3.
–En consecuencia con SDM solo podemos configurar SNMPv1 o v2
•Paso 1: Menú Configure -> Additional tasks -> Router Properties -> SNMP
y pulsamos Edit
•Paso 2: en la ventana de propiedades SNMP habilitamos SNMP
• Paso 3: Introducimos el community string de R o R/W
–También es posible hacerlo vía CLI mediante el comando “snmp-server
community cisco123 ro” por ejemplo donde cisco123 es el string y ro y rw
identifican R o R/W
de red (y IV)
Mediante SDM podemos configurar a que dispositivos envía

TRAPS un router.
–Paso 1: En el panel SNMP pulsamos Edit.
–Pasos 2,3 y 4: Pulsamos en Añadir un Trap Receiver e
introducimos la IP de la maquina que recibirá los mensajes y una
clave y pulsamos aceptar.
–Podemos editar o eliminar un receptor de TRAPS en el botón
correspondiente.
Usando NTP
En una red es sumamente importante la sincronización horario,
prueba de ello es que los LOGS portan información de la hora a la
que se produce el evento.
Por ello es muy importante mantener sincronizados los relojes de los
dispositivos de red.
Hay dos métodos para ello:
–Editar manualmente fecha y hora.
–Configurar NTP: Podemos sincronizar con una fuente interna o externa.
Usando NTP (y II)
En una red es sumamente importante la sincronización horario, prueba de ello es que los LOGS
portan información de la hora a la que se produce el evento.
Por ello es muy importante mantener sincronizados los relojes de los dispositivos de red.
Hay dos métodos para ello:
– Editar manualmente fecha y hora.
– Configurar NTP: Podemos sincronizar con una fuente interna o externa.
Para configurar un Router como servidor Maestro de NTP el comando es “ntp master [startum]” donde
stratum muestra el numero de saltos desde una fuente autorizada.
Los clientes NTP identifican el servidor NTP a través del comando “ntp server {ip_address | hostname}
de este modo un cliente sincroniza con el servidor NTP.
Con el comando “ntp broadcast client” configuramos el dispositivo para recibir mensajes broadacast
por un interfaz.
Usando NTP (y III)
Para evitar actualizaciones de tiempo maliciosas o incorrectas hay dos
mecanismos disponibles:
– Esquemas basados en ACLs
– Emplear NTP v3 que proporciona mecanismos de autenticación entre peers (iguales)
Los comandos empleados son los siguientes:
– “ntp authenticate” que habilita la autenticación.
– “ntp authentication-key key_number md5 key_value” que define la clave de autenticación
– “ntp trusted-key key_number” que define la clave que emplearemos para autenticar.
– La operación de creación de claves hay que hacerla en los dos en el cliente y en el servidor
De este modo se autentica NTP a partir de una fuente segura
El comando para ver los clientes autenticados es “show ntp associations
detail”
También podemos configurar NTP mediante SDM para ello:
– Paso 1: Menú Configure -> Additional Tasks -> Router Properties -> NTP/SNTP.
– Paso 2: Añadimos un servidor NTP bien por IP o por nombre DNS
– Paso 3: De modo optativo podemos elegir el interfaz del router que emplearemos para
comunicarnos con el servidor NTP
– Paso 4: Si empleamos autenticación cubrimos los campos de autenticación y pulsamos
OK.
USANDO CARACTERÍSTICAS DE
SEGURIDAD AUTOMÁTICAS
Realizando una auditoria de seguridad
Los routers tienen multitud de servicios habilitados por defecto.
Es conveniente para evitar vulnerabilidades desactivar los que no
se utilicen.
Por ejemplo CDP.
Un atacante con CDP Monitor podría obtener información muy
valiosa de la red.
Realizando una auditoria de seguridad (y II)
Realizando una auditoria de seguridad (y III)
Realizando una auditoria de seguridad (y IV)
A través de SDM podríamos realizar

una auditoria de seguridad.
En primer lugar debemos localizar las
vulnerabilidades, el software de
auditoria localiza esas
vulnerabilidades, a continuación se
modifican las configuraciones para
evitar dichas vulnerabilidades.
Las herramientas de las que
disponemos son:
– Asistente de auditoria de seguridad.
– Cisco Auto Secure: característica
disponible a través de CLI que realiza
automáticamente cambios de
configuración o requiere la intervención del
administrador.
– One-Step Lockdown: Proporciona una lista
de vulnerabilidades a través de SDM y
automáticamente realiza los cambios de
configuración.
Realizando una auditoria de seguridad (y V)
• El asistente de auditorias de seguridad realiza una comparación de

la configuración actual del router con una configuración recomendada
y realiza como consecuencia las siguientes tareas:
–Shuts down servidores innecesarios.
–Deshabilita servicios innecesarios.
–Aplica el firewall a los interfaces outside.
–Deshabilita o complica la configuracion de SNMP.
–Shuts down los interfaces no empleados.
–Chequea la robustez de las password.
–Obliga a emplear ACLs
Al terminar la auditoria esta muestra las posibles vulnerabilidades y la
vía para solucionarlas. Puede corregir los problemas
automáticamente o puede hacerlo el administrador manualmente.
Locking Down de un Router con AutoSecure
A partir de la versión 12.3 se incorpora en IOS la característica AutoSecure

que se inicia desde CLI y ejecuta un script.
Este proporciona recomendaciones para solucionar vulnerabilidades y a
continuación realiza las modificaciones en los ficheros de seguridad.
Los servicios y funciones que gestiona AutoSecure son:
– BOOTP seguro, CDP, FTP, TFTP, PAD, UDP, y pequeños servicios TCP, MOP, ICMP
(redirección , mask-replies), IP source routing, Finger, cifrado de claves, TCP keepalives,
gratuitous ARP, proxy ARP, y directed broadcast
– Notificaciones Legales empleando banners
– Secure password y funciones de login
– NTP seguro.
– Acceso SSH seguro
– Servicios de interceptación TCP
Para habilitar Autosecure el comando es “auto secure [no-interact]”
– Hay un modo interactivo en el que pregunta acerca de la habilitación de servicios
individualmente.
– Y hay un modo no interactivo parecido a SDM Security Audit One-Step lockdown
– Para ello hay dos comandos “auto secure full” y “auto secure no-interact”
Locking Down de un Router con SDM
• Cisco One-Step Lockdown deshabilita
multitud de servicios por ejemplo:
– Finger service
– PAD service
– TCP small servers service …
Cisco One-Step Lockdown habilita por
ejemplo:
– Servicio de encriptado de claves.
– Firewall en todos los interfaces outside
– Numeros de secuencia y sellos temporales de
debugs …
Cisco One-Step Lockdown establece por
ejemplo:
– Longitudes de claves minimas de 6 caracteres
– Tasas de fallo de autenticacion inferiores a tres
intentos
– TCP synwait time ….

T1 CEP Modern Network Security Threats

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

T1 CEP Modern Network Security Threats

Încărcat de

Drepturi de autor:

Formate disponibile

Securing Network

Es muy importante asegurar la infraestructura de red:

La implementación del router perimetral depende del tamaño de la

El acceso administrativo al router es necesario para

Una característica de seguridad disponible es la autenticación.

Cuando se realizan ataques a la búsqueda de una clave se hacen multitud de

SSH frente a telnet proporciona confidencialidad e integridad en las comunicaciones. La

Los pasos para configurar SSH son las siguientes:

– Asegurar que cada router tiene un nombre de host único.

– Asegurar que cada router tiene un nombre de dominio correcto.

Modos de conexión a un router con SSH habilitado

Ejemplo de creación de roles

Si un potencial atacante tiene acceso físico al router podría

SNMP se emplea para gestionar nodos, servidores, estaciones de

Configuración de SNMP en SDM

Mediante SDM podemos configurar a que dispositivos envía

A través de SDM podríamos realizar

• El asistente de auditorias de seguridad realiza una comparación de

A partir de la versión 12.3 se incorpora en IOS la característica AutoSecure

S-ar putea să vă placă și