CCN-STIC-1410 Procedimiento de Empleo Seguro OMNISWITCH AOS
CCN-STIC-1410 Procedimiento de Empleo Seguro OMNISWITCH AOS
CCN-STIC-1410 Procedimiento de Empleo Seguro OMNISWITCH AOS
CCN-STIC 1410
Abril 2020
CCN-STIC-1410 Procedimiento de Empleo Seguro OMNISWITCH AOS
Edita:
2.5.4.13=Qualified Certificate: AAPP-
SEP-M-SW-KPSC, ou=sello electrónico,
serialNumber=S2800155J, o=CENTRO
CRIPTOLOGICO NACIONAL, c=ES
2020.04.29 17:38:43 +02'00'
Centro Criptológico Nacional, 2020
NIPO: 083-20-078-X
LIMITACIÓN DE RESPONSABILIDAD
El presente documento se proporciona de acuerdo con los términos en él recogidos, rechazando
expresamente cualquier tipo de garantía implícita que se pueda encontrar relacionada. En ningún caso,
el Centro Criptológico Nacional puede ser considerado responsable del daño directo, indirecto, fortuito
o extraordinario derivado de la utilización de la información y software que se indican incluso cuando se
advierta de tal posibilidad.
AVISO LEGAL
Quedan rigurosamente prohibidas, sin la autorización escrita del Centro Criptológico Nacional, bajo las
sanciones establecidas en las leyes, la reproducción parcial o total de este documento por cualquier
medio o procedimiento, comprendidos la reprografía y el tratamiento informático, y la distribución de
ejemplares del mismo mediante alquiler o préstamo públicos.
PRÓLOGO
En un mundo cada vez más complejo y globalizado, en el que las tecnologías de la información
y la comunicación (TIC) desempeñan un papel de suma importancia, hemos de ser conscientes
de que la gestión adecuada de la ciberseguridad constituye un reto colectivo al que
necesariamente hemos de enfrentar. Resulta necesario garantizar la protección de la
capacidad económica, tecnológica y política de nuestro país, máxime cuando la proliferación
de ataques dirigidos y el robo de información sensible representan una realidad incontestable.
Por ello, resulta imprescindible estar al día de las amenazas y vulnerabilidades asociadas al uso
de las nuevas tecnologías. El conocimiento de los riesgos que se ciernen sobre el ciberespacio
ha de servir para implementar con garantías las medidas, tanto procedimentales como
técnicas y organizativas, que permitan un entorno seguro y confiable.
La Ley 11/2002, de 6 de mayo, reguladora del Centro Nacional de Inteligencia (CNI),
encomienda al Centro Nacional de Inteligencia el ejercicio de las funciones relativas a la
seguridad de las tecnologías de la información y de protección de la información clasificada, a
la vez que confiere a su Secretario de Estado Director la responsabilidad de dirigir el Centro
Criptológico Nacional (CCN).
Partiendo del conocimiento y la experiencia del CNI sobre amenazas y vulnerabilidades en
materia de riesgos emergentes, el Centro realiza, a través del Centro Criptológico Nacional,
regulado por el Real Decreto 421/2004, de 12 de marzo, diversas actividades directamente
relacionadas con la seguridad de las TIC, orientadas a la formación de personal experto, al
empleo de tecnologías de seguridad adecuadas y a la aplicación de políticas y procedimientos
de seguridad.
Precisamente, esta serie de documentos CCN-STIC es un claro reflejo de la labor que este
organismo lleva a cabo en materia de implementación de seguridad, permitiendo la aplicación
de políticas y procedimientos, pues las guías han sido elaboradas con un claro objetivo:
mejorar el grado de ciberseguridad de las organizaciones, conscientes de la importancia que
tiene el establecimiento de un marco de referencia en esta materia que sirva de apoyo para
que el personal de la Administración lleve a cabo la difícil tarea de proporcionar seguridad a los
sistemas de las TIC bajo su responsabilidad.
Con esta serie de documentos, el Centro Criptológico Nacional, en cumplimiento de sus
cometidos y de lo reflejado en el Real Decreto 3/2010 por el que se regula el Esquema
Nacional en el ámbito de la Administración electrónica, contribuye a mejorar la ciberseguridad
española y mantener las infraestructuras y los sistemas de información de todas las
administraciones públicas con unos niveles óptimos de seguridad. Todo ello, con el fin de
generar confianza y garantías en el uso de estas tecnologías, protegiendo la confidencialidad
de los datos y garantizando su autenticidad, integridad y disponibilidad.
Abril de 2020
ÍNDICE
1. INTRODUCCIÓN ................................................................................................... 5
2. OBJETO Y ALCANCE .............................................................................................. 6
3. ORGANIZACIÓN DEL DOCUMENTO ....................................................................... 6
4. FASE DE DESPLIEGUE E INSTALACIÓN ................................................................... 7
4.1 ENTREGA SEGURA DEL PRODUCTO .........................................................................7
4.2 INSTALACIÓN SEGURA .............................................................................................7
5. FASE DE CONFIGURACIÓN .................................................................................... 8
5.1 ADMINISTRACIÓN DEL PRODUCTO ..........................................................................8
5.2 CONTROL DE ACCESO, AUTENTICACIÓN Y NO-REPUDIO.........................................8
5.2.1 AUTENTICACIÓN Y AUTORIZACIÓN .....................................................................9
5.2.2 CONTROL DE ACCESO ........................................................................................19
5.2.3 CONFIGURACIÓN DE LOGON BANNER ..............................................................20
5.2.4 REGISTRO DE EVENTOS .....................................................................................21
5.2.5 SINCRONIZACIÓN HORARIA ..............................................................................25
5.3 CONFIDENCIALIDAD DE LOS DATOS Y SEGURIDAD DE LA COMUNICACIÓN .........25
5.3.1 PERMITIR ÚNICAMENTE LOS PROTOCOLOS SEGUROS .....................................25
5.3.2 CONFIGURACIÓN DE SNMPV3 ..........................................................................27
5.3.3 REEMPLAZAR EL CERTIFICADO SSL POR DEFECTO ............................................27
5.4 DISPONIBILIDAD .....................................................................................................28
5.4.1 VLAN HOPPING ..................................................................................................28
5.4.2 ATAQUES DOS EN RANGOS DE RED RESERVADOS ............................................29
5.4.3 IGMP FLOODING................................................................................................30
5.4.4 DHCP FLOODING................................................................................................30
5.4.5 CONTROL DE TORMENTAS DE TRÁFICO ............................................................30
5.4.6 LEARNED PORT SECURITY - ATAQUES POR CAM OVERFLOW ...........................31
5.4.7 FUNCIONALIDADES DE SEGURIDAD DE DHCP ...................................................33
5.4.8 ATAQUE POR STP RECLAMANDO EL ROL DE ROOT ..........................................36
5.4.9 ATAQUES EN LOS PROTOCOLOS DE ROUTING ..................................................38
5.4.10 ATAQUE POR IGMP QUERIER NO CONFIABLE ...................................................41
5.4.11 MECANISMO DE SEGURIDAD DE AGENTE LLDP NO CONFIABLE ......................42
5.4.12 FILTRADO DE ATAQUES DOS EN INTERFACES DEL ROUTER ..............................44
5.4.13 EJEMPLO DE CONFIGURACIÓN..........................................................................47
6. FASE DE OPERACIÓN Y MANTENIMIENTO ........................................................... 50
6.1 ACTUALIZACIÓN Y PARCHES ..................................................................................50
6.1.1 ACTUALIZACIÓN ESTÁNDAR ..............................................................................51
6.1.2 ACTUALIZACIÓN ISSU ........................................................................................52
7. REFERENCIAS ..................................................................................................... 55
8. ABREVIATURAS .................................................................................................. 56
1. INTRODUCCIÓN
1. La familia OmniSwitch de Alcatel-Lucent Enterprise se compone de conmutadores
de capa 2 y capa 3 diseñados para ofrecer baja latencia, alto rendimiento,
disponibilidad y robustez.
2. Los conmutadores de la familia OmniSwitch ejecutan el sistema operativo AOS
(Alcatel-Lucent Operating System), común para todos los equipos de la familia y que
utilizan un mismo juego de comandos de línea para su configuración.
3. Los conmutadores disponen herramientas y aplicaciones de seguridad estándar
integrada y automatiza para rechazar activamente las amenazas, tanto internas
como externas.
4. En el presente documento se describen las recomendaciones para la configuración
de los equipos de la forma más segura posible, activando o desactivando diferentes
servicios o protocolos de los conmutadores.
5. La estructura del documento y sus contenidos no exigen una lectura lineal del
mismo, sino que se recomienda al lector utilizar el índice de contenidos para
localizar aquél capítulo que trate aquél aspecto sobre el que desea mejorar la
seguridad. Así mismo, aunque estas páginas han sido escritas pensando en la familia
de switches OmniSwitch de Alcatel-Lucent Enterprise, la mayoría de las
recomendaciones descritas sobre seguridad son aplicables a otros equipos de red.
2. OBJETO Y ALCANCE
6. En la presente guía se recoge el procedimiento de empleo seguro para equipos
OmniSwitch de Alcatel-Lucent Enterprise. A lo largo de los diferentes apartados, se
ofrecen consejos y recomendaciones sobre la activación o desactivación de servicios
y determinadas funcionalidades de esta familia de switches con el fin de poder
establecer una configuración lo más segura posible.
7. Los ejemplos y comandos de configuración incluidos en este documento se
corresponden con la versión 8.x de AOS (ALE Operating System).
8. Para una mayor detalle acerca de las funcionalidades descritas se recomienda la
lectura de las guías de uso y configuración de OmniSwitch:
• OmniSwitch AOS Release 8 Switch Management Guide
• OmniSwitch AOS Release 8 CLI Reference Guide
• OmniSwitch AOS Release 8 Network Configuration Guide
• OmniSwitch AOS Release 8 Advanced Routing Configuration Guide
9. Los algoritmos criptológicos utilizados en esta guía cumplen con los requisitos
estipulados en la CCN-STIC-807 Criptología de empleo en el ENS para la Categoría
Alta.
5. FASE DE CONFIGURACIÓN
usuarios
67. En AOS 8 hay una opción para reducir la cantidad de recursos TCAM consumidos
usando "qos switch-group compact". A continuación se puede ver un ejemplo de
configuración en OS6900, que consume 16 (4 × 4) entradas TCAM en el modo
expanded y 4 (4 × 1) en el modo compact.
68. Es necesario reiniciar el switch para aplicar los cambios.
-> show configuration snapshot qos ip
! IP:
ip interface "vlan100" address 192.168.100.1 vlan 100
ip interface "vlan101" address 192.168.101.1 vlan 101
ip interface "vlan102" address 192.168.102.1 vlan 102
ip interface "vlan103" address 192.168.103.1 vlan 103
! QOS:
qos switch-group compact
policy network group management 192.168.100.1192.168.101.1
policy network group management 192.168.102.1192.168.103.1
policy condition trusted source network group management destination network
group Switch
policy action accept
qos apply
69. Con la configuración inicial se consumen 16 entradas, mientras que con la
segunda, tras el reinicio del switch se usan solo 4 entradas.
116. Por defecto los switches vienen con un certificado auto-firmado en el directorio
/flash/switch del sistema de archivos del equipo. Se recomienda reemplazar
estos certificados por otros certificados y clave RSA.
117. Para ello hay que conectarse al switch vía consola/SSH y cambiar el nombre de
los archivos "wv-cert.pem" y "wv-key.pem" en el directorio /flash/switch por ej.
"Wv-cert.bak" y "wv-key.bak".
118. Una vez hecho esto hay que conectarse al switch a través de FTP para copiar los
nuevos certificados. Hay que copiar los archivos en el directorio /flash/switch
del switch.
119. Una vez cargados los nuevos certificados hay que reiniciar el switch para que
estos certificados se carguen. Tras el reinicio, cuando se conecta al switch
mediante https, se presentarán los nuevos certificados cargados.
5.4 DISPONIBILIDAD
130. En AOS, todos los paquetes de protocolos multicast con dirección IPv6 de
destino ff02::/32 y con dirección IPv4 de destino 224.0.0.0/24 siempre se
copian por defecto a la CPU. El uso intensivo de CPU puede afectar las
operaciones normales de los protocolos de OmniSwitch tales como LACP, ERP,
IGMP.
131. Para proteger los switches AOS contra la alta utilización de la CPU debido al
tráfico no deseado que se copia en esta, se utilizan reglas QoS de calidad de
servicio usando la prioridad 17 de CPU.
132. La CPU descarta los paquetes que se clasifican en la cola 17, pero aun así se
reenvían. De esta manera, la CPU está protegida y la red es transparente para
este tipo de tráfico.
133. A continuación, se puede ver un ejemplo de configuración de regla con
prioridad de CPU 17:
! QOS:
policy condition mdc-dvmrp destination ip 224.0.0.4
policy condition mdc-ipv4mc-reserved destination ip 224.0.0.0 mask 255.255.255.0
policy condition mdc-ipv6mc-reserved destination ipv6 ff02:: mask ff:ff:ff:ff::
policy condition mdc-ospf-5 destination ip 224.0.0.5 ip-protocol 89
policy condition mdc-ospf-6 destination ip 224.0.0.6 ip-protocol 89
policy condition mdc-pim destination ip 224.0.0.13
policy condition mdc-ripv2 destination ip 224.0.0.9 destination udp-port 520
policy condition mdc-vrrp destination ip 224.0.0.18 ip-protocol 112
policy action accept
policy action q17 cpu priority 17
policy rule mdc-vrrp precedence 65070 condition mdc-vrrp action accept
policy rule mdc-ripv2 precedence 65060 condition mdc-ripv2 action accept
policy rule mdc-pim precedence 65050 condition mdc-pim action accept
policy rule mdc-ospf-6 precedence 65040 condition mdc-ospf-6 action accept
policy rule mdc-ospf-5 precedence 65030 condition mdc-ospf-5 action accept
policy rule mdc-dvmrp precedence 65020 condition mdc-dvmrp action accept
policy rule mdc-ipv6mc-reserved precedence 65010 condition mdc-ipv6mc-reserved
65000
condition mdc-ipv4mc-reserved action q17
qos apply
134. En AOS 8.x, el caudal de paquetes IGMP que se copia a la CPU está limitado por
defecto, por lo que no es necesario hacer ninguna configuración específica al
respecto.
(el puerto permanece habilitado) o solo bloquear el tráfico que viole los
criterios de LPS.
145. LPS se soporta en puertos fijos, en puertos 802.1Q (tagged) o puertos UNP. En
cambio, no se soporta en agregados de enlaces, ni en agregados de enlaces
etiquetados (troncales), ni en miembros de los agregados.
146. De manera predeterminada, LPS está deshabilitado en todos los puertos del
conmutador. Para habilitar LPS en un puerto, deberá utilizarse el comando
port-security. Por ejemplo, el siguiente comando habilita LPS en el puerto 1 de
la ranura 4:
-> port-security 1/1 admin-status enable
147. Se puede habilitar LPS en rangos de puertos o puertos en diferentes slots:
-> port-security 1/1-5 admin-status enable
-> port-security 1/1-5 1/10-15 admin-status enable
148. Cuando LPS está habilitado en un puerto activo, todas las direcciones MAC
aprendidas en ese puerto antes de habilitar LPS se borran de la tabla de
direcciones MAC de origen.
149. Para deshabilitar LPS en un puerto, se utilizará el comando port-security con el
parámetro deshabilitar. Por ejemplo, el siguiente comando deshabilita LPS en
un rango de puertos:
-> port-security 1/1-5 1/10-15 admin-status disable
150. Para convertir todas las direcciones MAC aprendidas por el switch en un puerto
LPS en direcciones MAC estáticas, se puede usar el comando port-security
chassis con el parámetro convert-to-static. Por ejemplo:
-> port-security chassis convert-to-static
-> port-security port 1/8 convert-to-static
151. Para deshabilitar LPS en un switch se usa el siguiente comando:
-> port-security chassis admin-state disable
152. Se puede configurar la ventana de aprendizaje de direcciones MAC. El valor de
la ventana de aprendizaje se especifica en minutos. Si se configura con un valor
0, el tiempo de aprendizaje es infinito:
-> port-security learning-window 2
153. Se puede especificar que las direcciones MAC aprendidas tras el tiempo de la
ventana de aprendizaje se conviertan en estáticas:
-> port-security learning-window 2 convert-to-static enable
154. Para configurar el máximo número de direcciones MAC que se pueden
aprender en un puerto o rango de puertos se usan los comandos siguientes:
-> port-security port 2/14 maximum 5
-> port-security port 2/10-15 maximum 10
155. Por defecto, cada vez que se aprende una MAC en un puerto se envía un trap
SNMP al administrador. Se puede especificar un umbral por debajo del cual no
se envían traps. Una vez que se alcanza el umbral, se envía un trap por cada
nueva MAC con información sobre la MAC, el switch y el puerto por el que se
ha aprendido.
-> port-security port learn-trap-threshold 10
156. Con LPS se puede configurar el modo en que se quiere que el puerto se
comporte cuando hay una violación de la política LPS. Cuando esto sucede, el
puerto se puede configurar en uno de los siguientes modos:
• Restrict: el puerto sigue habilitado pero se bloquean la direcciones MAC
no autorizadas. Todas las direcciones MAC aprendidas y autorizadas
pueden seguir cursando tráfico normalmente
• Discard: el puerto continúa habilitado administrativamente, pero todo
el tráfico que se cursa por este puerto se descarta. Las direcciones MAC
aprendidas dinámicamente en el puerto se eliminan de la tabla de
direcciones.
• Shutdown: el puerto se deshabilita administrativamente y no se cursa
tráfico por él.
157. Por defecto, el modo de funcionamiento de LPS es Restrict. Para cambiarlo se
puede usar los siguientes comandos:
-> port-security port 4/1-10 violation shutdown
-> port-security port 1/10-15 violation restrict
158. Un atacante puede utilizar un ataque por servidor DHCP no confiable para
configurar un servidor DNS y/o un puerta de enlace falsos. El atacante puede
usar su propia dirección IP como puerta de enlace en las ofertas de DHCP para
poder rastrear el tráfico.
159. En AOS hay dos funciones de seguridad DHCP disponibles: la opción de
información del agente DHCP relay (Option-82) y DHCP Snooping.
• La función DHCP Option-82 permite que el agente dhcp-relay inserte
información de identificación en los paquetes DHCP originados por el
cliente antes de que se envíen al servidor DHCP.
• La función DHCP Snooping filtra los paquetes DHCP entre fuentes no
confiables y un servidor DHCP de confianza y crea una base de datos de
vínculos para registrar la información del cliente DHCP.
160. Aunque DHCP Option-82 es un subcomponente de DHCP Snooping, estas dos
funcionalidades son mutuamente excluyentes. Si la función DHCP Option-82
está habilitada en el switch, entonces DHCP Snooping no está disponible. Lo
172. La tabla de vínculos (binding table) de DHCP Snooping se habilita por defecto
cuando se configura DHCP Snooping en el switch o VLAN. Esta tabla se usa para
filtrar el tráfico DHCP que se recibe pro los puertos no confiables. Se pueden
además introducir entradas estáticas en la tabla de vínculos. Para habilitar,
deshabilitar o incluir entradas en la tabla de vínculos se pueden usar los
comandos siguientes:
-> dhcp-snooping binding admin-state enable
-> dhcp-snooping binding admin-state disable
-> dhcp-snooping binding 00:2a:95:51:6c:10 port 1/1/15 address 17.15.3.10
vlan 200
173. Un ejemplo de configuración de DHCP Snooping podría ser el siguiente:
! DHCP Snooping:
dhcp-snooping admin-state enable
dhcp-snooping binding admin-state enable
dhcp-snooping ip-source-filter port 1/1/1-24 admin-state enable dhcp-
snooping port 1/1/25-26 trust
174. Los ataques por STP están orientados a desestabilizar la operación de STP
(Spanning Tree Protocol) en la red.
175. Si un atacante tiene acceso a puertos de los switches de la red que pueden
convertirse en puertos troncales, puede insertar un switch no autorizado en la
red. De esta forma tiene la posibilidad de formar otra conexión con un segundo
conmutador de esa red y manipular la prioridad del árbol. Si configura el switch
atacante para que tenga una prioridad que sea menor que en cualquier otro
conmutador de la empresa, la mayor parte del tráfico pasará teóricamente a
través de ese conmutador.
176. El switch atacante con, por ejemplo, prioridad 0, anuncia sus "BPDU superiores"
y la topología STP converge. El switch atacante se convertirá en el root y todo el
tráfico pasará por este conmutador. Esto le da la posibilidad de ver todo el
tráfico de la empresa.
177. También puede redirigir el tráfico desde enlaces de gran ancho de banda entre
otros conmutadores a por ejemplo un enlace de 100 Mbps en el conmutador
atacante. Esto reducirá significativamente la velocidad de la red.
178. El siguiente diagrama refleja la problemática presentada. Un atacante con dos
tarjetas de red puede simular un conmutador que intercambia BPDUs con los
dos conmutadores existentes en la red, reconfigurando la topología de STP y
haciéndose pasar por el root de la red STP. De esta forma el switch 1 pondría en
estado blocking el puerto que conecta con el 2 y todo el tráfico se enviaría a
través del atacante, con lo que éste tendría visibilidad de todo el tráfico
intercambiado entre el usuario y el servidor.
179. Para evitar esto, AOS dispone de varios mecanismos: QoS User Port y STP Root
Guard.
187. Es necesario proteger los protocolos de routing para evitar que se inyecten
rutas de forma no autorizada.
comunicarse los vecinos que usan el mismo tipo de autenticación y usan las
mismas contraseñas o claves.
189. En OSPF hay dos tipos de autenticación: simple y HMAC-SHA La autenticación
simple requiere solo una cadena de texto como contraseña, mientras que
HMAC-SHA (método recomendado desde el punto de vista de la seguridad) es
una forma de autenticación cifrada que requiere una clave y una contraseña.
Ambos tipos de autenticación requieren el uso de más de un comando.
Autenticación simple
190. Para habilitar la autenticación simple en un interfaz OSPF, introducir el
comando ip ospf interface auth-type con el nombre de interfaz:
-> ip ospf interface vlan100 auth-type simple
191. A continuación se introduce el comando ip ospf interface auth-key para
establecer la clave:
-> ip ospf interface vlan100 auth-key switch
192. De esta forma únicamente los interfaces OSPF con autenticación simple y clave
switch podrán utilizar el interfaz configurado.
Autenticación SHA
193. Para configurar el mismo interfaz con autenticación SHA, se define la clave de
seguridad mediante el comando security key:
-> security key 5 algorithm sha256 “securitykey1234”
194. A continuación, se usa la clave definida anteriormente para la autenticación del
interfaz OSPF. Esto se hace mediante el parámetro auth-type key-chain del
comando ip ospv interface:
-> ip ospf interfaz vlan100 auth-type key-chain 5
195. Una vez se ha hecho esto, el interfaz está habilitado con autenticación SHA.
196. Para deshabilitar la autenticación OSPF en un interfaz se hace mediante el
siguiente comando:
-> ip ospf interface vlan100 auth-type none
197. A continuación se puede ver un ejemplo de configuración con OSPF
autenticado:
! OSPF:
ip load ospf
ip ospf area 0.0.0.0
ip ospf interface "vlan100"
ip ospf interface "vlan100" area 0.0.0.0
security key 5 algorithm sha256 "securitykey1234"
ip ospf interface "vlan100" status enable
205. En caso de que IPMS Querying esté habilitado en una red multicast L2, solo
habrá uno elegido (el de dirección IP más baja) como querier activo y solo este
querier podrá enviar consultas generales IGMP. Todos los dispositivos con IPMS
habilitado en la red multicast L2 mantienen una tabla con los queriers activos y
envían informes de pertenencia IGMP al querier activo. Un atacante puede usar
una dirección IP más baja para inyectar un IGMP General Query en un puerto
no confiable.
206. Antes del ataque tenemos que el switch de agregación es el Querier activo. Si
miramos desde el switch de acceso (Access switch).
Total 1 Queriers
Host Address VLAN Port Static Count Life
---------------+-----+-----+-------+------+-----
192.168.0.10 1 1/1 no 1 167
208. Este tipo de ataque se puede prevenir usando políticas QoS de calidad de
servicio.
! QOS :
policy port group untrusted 1/1-23
policy condition general-query-sw destination port group untrusted
multicast ip 224.0.0.1
policy action drop disposition deny
policy rule deny-general-query-sw condition general-query-sw action drop
qos apply
209. Esta política no descarta el IGMP General Query malintencionado sino que
previene que éste se aprenda en el switch donde esta política se configura.
222. El switch filtra los ataques de denegación de servicio (DoS), que son ataques de
seguridad dirigidos a dispositivos disponibles en una red privada o en Internet.
Determinados ataques apuntan a fallos del sistema o vulnerabilidades (por
ejemplo, ataques teardrop), mientras que otros tipos de ataques implican
generar grandes volúmenes de tráfico para que el servicio de red sea denegado
a los usuarios legítimos de la red (como los ataques pepsi). Por defecto está
habilitado en los conmutadores OmniSwitch el filtrado de los siguientes tipos
de ataques de denegación de servicio excepto el de Sobrecarga de ping que hay
que activarlo explícitamente:
• Ping de la muerte ICMP: se envían a un host paquetes ping que
exceden el tamaño máximo de un datagrama IP (65535 bytes) y
bloquean el sistema.
• SYN Attack: se inunda un sistema con una serie de paquetes TCP SYN, a
los que el host responde con SYN-ACK. Las conexiones TCP a medio abrir
pueden agotar los recursos TCP, de modo que no se aceptan otras
conexiones TCP.
• Land Attack: se envían paquetes falsificados con el indicador SYN
establecido a un host en cualquier puerto abierto que esté escuchando.
La máquina puede bloquearse o reiniciarse para responder.
• Pepsi Attack: es la forma más común de inundación UDP dirigida a
dañar las redes. Un ataque pepsi es un ataque que consiste en muchos
paquetes UDP falsificados destinados a puertos de diagnóstico en
dispositivos de red. Un ataque pepsi puede hacer que los dispositivos de
red usen mucho de tiempo de CPU para responder a estos paquetes.
• ARP Flood Attack: inunda un switch con muchas solicitudes ARP, lo que
hace que el switch utilice una gran cantidad de tiempo de CPU para
responder a estas solicitudes. Si el número de solicitudes ARP excede el
valor predeterminado de 500 por segundo, se detecta un ataque.
• Ataque por IP no válida: el switch recibe paquetes con direcciones IP de
origen o destino no válidas. Cuando se detecta un ataque por IP no
válida, los paquetes se descartan y se generan traps SNMP. Los
siguientes son algunos ejemplos de direcciones IP de origen y destino
no válidas:
Dirección IP de origen no válida
• 0.x.x.x
• 255.255.255.255
• broadcast de subred, es decir, 172.28.255.255, para una interfaz IP
172.28.0.0/16
• en el rango 224.x.x.x - 255.255.255.254
• La dirección IP de origen es igual a una de las direcciones de
interfaz IP del Switch
Dirección IP de destino no válida
• 127.x.x.x
• en el rango 240.x.x.x - 255.255.255.254
• 0.0.0.0 (excepciones válidas: ciertos paquetes DHCP)
• 172.28.0.0 para una red de routers 172.28.4.11/16
• 0.x.x.x
• No coinciden las direcciones IP y MAC de multicast. Este ataque se
detecta cuando:
La dirección MAC de origen de un paquete recibido por un
switch es una dirección MAC multicast.
Las direcciones IP y MAC de destino de un paquete recibido por
un switch son las mismas que las direcciones IP y MAC de
multicast, pero las direcciones IP y MAC multicast no coinciden.
Nota. En las dos condiciones descritas anteriormente en "No
coinciden las direcciones IP y MAC multicast", los paquetes se
descartan y se generan traps SNMP.
• La IP de destino es una IP unicast y la dirección MAC de destino es una
dirección broadcast o multicast. En dicha condición, se registra un
evento en las estadísticas DoS. No se generan traps SNMP, ya que los
paquetes válidos también pueden incluirse en esta categoría.
• Sobrecarga de ping: se inunda un switch con muchos paquetes ICMP, lo
que hace que el switch utilice una gran cantidad de tiempo de CPU para
responder a estos paquetes. Si el número de paquetes ICMP excede 100
por segundo, se detecta un ataque DoS. Por defecto, la detección de
! AAA:
aaa authentication console "local"
aaa authentication snmp "local"
aaa authentication ssh "local"
user password-size min 9
user password-expiration 180
user password-policy min-uppercase 1
user password-policy min-lowercase 1
user password-policy min-digit 1
user password-policy min-nonalpha 1
! NTP:
ntp server 192.168.100.253 key 1
ntp client admin-state enable
! QOS:
qos user-port shutdown bpdu bgp ospf rip vrrp dhcp-server dvmrp isis dns-reply policy port
group UserPorts 1/1/1-24
policy condition mdc-dvmrp destination ip 224.0.0.4
policy condition mdc-ipv4mc-reserved destination ip 224.0.0.0 mask 255.255.255.0
policy condition mdc-ipv6mc-reserved destination ipv6 ff02:: mask ff:ff:ff:ff::
policy condition mdc-ospf-5 destination ip 224.0.0.5 ip-protocol 89
policy condition mdc-ospf-6 destination ip 224.0.0.6 ip-protocol 89
policy condition mdc-pim destination ip 224.0.0.13
policy condition mdc-ripv2 destination ip 224.0.0.9 destination udp-port 520 policy condition
mdc-vrrp destination ip 224.0.0.18 ip-protocol 112
policy action accept
policy action q17 cpu priority 17
policy rule mdc-vrrp precedence 65070 condition mdc-vrrp action q17
policy rule mdc-ripv2 precedence 65060 condition mdc-ripv2 action q17
policy rule mdc-pim precedence 65050 condition mdc-pim action q17
policy rule mdc-ospf-6 precedence 65040 condition mdc-ospf-6 action accept policy rule mdc-
ospf-5 precedence 65030 condition mdc-ospf-5 action accept policy rule mdc-dvmrp
precedence 65020 condition mdc-dvmrp action q17
policy rule mdc-ipv6mc-reserved precedence 65010 condition mdc-ipv6mc-reserved
-action q17
policy rule mdc-ipv4mc-reserved precedence 65000 condition mdc-ipv4mc-reserved
action q17
qos apply
! LLDP:
lldp all chassis tlv management port-description enable system-name enable
system-description enable
lldp all chassis tlv management management-address enable
lldp all port 1/1/1-24 lldpdu disable
! Session manager :
session prompt default "OS6860E->" command-log enable
! SNMP :
snmp security authentication all
snmp authentication-trap enable
snmp station 192.168.100.253 162 "snmp3" v3 enable
! Web:
webview server disable
webview access disable
! System Service:
swlog output socket 192.168.100.253
! VRRP:
ip load vrrp
! OSPF:
ip load ospf
ip ospf area 0.0.0.0
ip ospf interface "vlan1"
ip ospf interface "vlan1" area 0.0.0.0
ip ospf interface "vlan1" hello-interval 0
ip ospf interface "vlan1" admin-state enable
ip ospf interface "vlan100"
ip ospf interface "vlan100" area 0.0.0.0
ip ospf interface "vlan100" auth-type md5
ip ospf interface "vlan100" admin-state enable
ip ospf interface "vlan100" md5 1
ip ospf interface "vlan100" md5 1 key switch
ip ospf admin-state enable
! DA-UNP:
port-security port 1/1/1-24 maximum 2
port-security port 1/1/1-24 learn-trap-threshold 2
port-security port 1/1/1-24 admin-state enable
! DHCP Snooping:
dhcp-snooping admin-state enable
dhcp-snooping binding admin-state enable
dhcp-snooping ip-source-filter port 1/1/1-24 admin-state enable
dhcp-snooping port 1/1/25-26 trust
231. Para la actualización estándar de AOS se han de seguir los pasos indicados a
continuación y en el orden indicados:
a) Descargar los ficheros de actualización correspondientes al modelo de
conmutador que se quiere actualizar de la web de soporte de Alcatel-
Lucent Enterprise.
b) Cargar los ficheros de actualización en el directorio “Running” del switch
que se quiere actualizar. Para ello se usa SFTP. El nombre del directorio
Running y los ficheros pueden variar dependiendo de la configuración y
el modelo de switch.
c) Actualizar la imagen de software. Para ello se introduce el comando de
reinicio del switch y se confirma, según se indica a continuación:
-> reload from working no rollback-timeout
Confirm Activate (Y/N) : y
This operation will verify and copy images before reloading.
It may take several minutes to complete....
SYNCHRONIZATION STATUS
Running Configuration : SYNCHRONIZED
7. REFERENCIAS
8. ABREVIATURAS
AES Advanced Encription Standard
AOS ALE Operating System
ARP Address Resolution Protocol
ASA Acceso Autenticado al Switch
BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol
BUM Broadcast, Unknown unicast y Multicast
CAM Conditional Access Memory
CCN Centro Criptológico Nacional
CPSTIC Catálogo de Productos de Seguridad de las Tecnologías de la
Información y la Comunicación
DAI Dynamic ARP Inspection
DPP Dispositivo de Protección de Perímetro
ENS Esquema Nacional de Seguridad
FTP File Transfer Protocol
ICMP Internet Control Message Protocol
IP Internet Protocol
ISSU In Service Software Upgrade
LPS Learned Port Security
LLDP Link Layer Discovery Protocol
MVRP Multiple VLAN Registration Protocol
OSPF Open Shortest Path First
RSA Rivest, Shamir y Adleman
SHA Secure Hash Algorithm
SNMP Simple Network Management Protocol
SSH Secure Shell
STIC Seguridad de las Tecnologías de la Información y la Comunicación
STP Spanning Tree Protocol
TCAM Ternary Content Addressable Memory
VSA Vendor Specific Atributes