Organi zación de Aviación Civil Internacional SAM/IG/17-NE/13 … Arg.pdf · 2016-04-29 ·...

Cuestión Orden de

(

1 1.1 cuestionesAsuntos, necesidad 1.2 determinaexternos. 1.3 ello se cotranscribe 1.4 seguridad

OrganiOficinaDécimo(SAM/(Lima,

4 del el Día:

CONS

(Presentada po

Esta nota drealizadas aconfiguracióafectar los se

Guía2013

Guía Infor

RED

Objetivos es

Introd

La pres de seguridade la RCC/1

d de realizar u

En la rar las accioneQue la soluci

En tal onsideró comen las siguient

De la d a considerar”

ización de Avia Regional Suo Séptimo TaIG/17) - ProyPerú, 9 al 13

Evaluaciónde mejora(CNS) par

SIDERACIO

or Argentina

de estudio tie partir de un actual, los

ervicios brind

a de buenas p3) a de orientaciórme de la Déc

DDIG (Lima, P

stratégicos de

ducción

esente Nota dad en la RED19, entre las un análisis de

reunión se coes necesarias ión debía ser

sentido, se lleo referenciastes premisas y

“Guía de ori”, página 5, s

iación Civil Iudamericanaaller/Reuniónyecto Regionde mayo de 2

n de los requs de las capa operacione

ONES SOBREPROTEGER

– Dirección G

ene por objetun somero a proveedores

dados a través

Refeprácticas en

ón para la impcimo Novena Perú, 7-9 de m

e la OACI:

de Estudio reDDIG II. En

actividades la seguridad

onsideró imppara protege

común para p

evó adelante u las guías disy cuestiones a

ientación parae menciona:

Internacional

n del Grupo nal RLA/06/92016)

uisitos operapacidades de es en ruta y á

E ANÁLISISR A LA RED

General de Co

Resumen

to presentar aanálisis de ss y usuarios de la REDDI

erencias: seguridad pa

plantación deReunión del

marzo de 201

A – SegB - SegC – Pro

efiere a la neel Informe soque los Estaen la REDDI

ortante realizer a la REDDpoder ser aplic

un primer anásponibles y pa tener en cue

a la implanta

de Implanta901

acionales parcomunicaci

área termina

S DE SEGURDDIG II

ontrol de Trán

a los participseguridad tenfinales, que IG II.

ara la ATN V

e redes nacionComité de C

16) (RCC/19)

guridad operaguridad otección del m

cesidad plantobre la Cuestados considerG II.

zar un análisiDIG II de pocada por todo

álisis en cuanpublicadas poenta.

ación de rede

ación SAM

ra determinaones, navega

al

RIDAD PAR

nsito Aéreo -

pantes, obserniendo en cpudieran o p

V5 3(Lima,

nales IP Coordinación d

.

acional

medio ambien

teada a los Etión 7 del Ordraron necesar

is en tal sentosibles interfeos los Estados

nto a la segurior OACI SAM

es nacionales

SAM/IG/1

ar la implantación y vigil

RA

DGCTA)

rvaciones cuenta la pudiesen

abril

de la

nte

Estados refereden del Día, rias, se plant

tido a fin de ferencias o ats.

idad de la redM de las cua

IP”, “Polític

17-NE/13 29/04/16

tación lancia

ente a Otros tea la

poder taques

d. Para ales se

cas de

SAM/IG/17-NE/13 - 2-

a) Los ataques contra redes del IPS se publican bien, y los piratas informáticos gastan mucha energía hacia la concepción de nuevas formas de ataque. El coste de un sistema capaz de infligir daño importante en una red puede estar tan solo en una computadora barata que apoye el IPS.

b) Esto significa que los sistemas del ATS usando el IPS, sin mecanismos de seguridad

eficaces, serían vulnerables a las varias formas de violación de seguridad. Por lo tanto, se recomienda que los servicios de seguridad existentes subyacentes del análisis ATN de la vulnerabilidad estén puestos al día para reflejar el uso del IPS.

c) Hay numerosos mecanismos de seguridad que se pueden utilizar en una red IPS. Los

sistemas actuales pueden utilizar el protocolo de la seguridad del IP (IPSec) para asegurar seguridad de la capa de red y/o el protocolo de SSL/TLS para asegurar seguridad de la capa de transporte del IPS. IPSec puede proporcionar servicios de encripción y/o de autentificación.

d) Por otra parte, la Administración Aeronáutica de cada Estado deberá observar su

incumbencia interna en las Políticas de Seguridad de la Información dictadas por sus propios gobiernos.

e) Es recomendable la lectura de la Norma “Information Technologies – Security techniques

– Codes of practice for information security management “ISO-IEC 17799, del año 2005, publicado por la ISO (International Standardization Organization) y la IEC (International Electrotechnical Commission). La última versión, BS ISO IEC 17799: 2005 reemplaza a las versiones más viejas de los estándares BS 7799 e ISO 17799. Está basada en el British Standard 7799. Aunque la norma ISO 17799 no es de cumplimiento obligatorio, proporciona una base sólida para un programa de seguridad de la información.

f) Asimismo, deberá contemplarse lo estipulado en el Manual de Disposiciones Técnicas de

la Red de Telecomunicaciones Aeronáuticas (ATN) de la OACI (Doc 9705) y las listas de verificación de auditoría de seguridad (Information Security Management BS 7799.2:2005 Audit Check List for SANS).

1.5 De la “Guía de buenas prácticas en seguridad para la ATN”, se extrae lo siguiente:

a) La red satelital está proyectada para operar con el protocolo TCP/IP bajo la administración de los Estados da Región SAM y operada por la OACI, mientras la red terrestre está proyectada para uso del MPLS y es un servicio prestado por una empresa privada.

b) Objetivos de Seguridad. Para atender los requerimientos operacionales de los servicios

ATM, la ATN requiere el atendimiento de los siguientes objetivos fundamentales de seguridad: Protección de los datos de la ATN en contra acceso no autorizado, modificación o apagado; Protección de los activos de la ATN en contra uso no autorizado y negación de servicio. Tales objetivos requieren el atendimiento de los siguientes principios de seguridad de la información, anteriormente descritos, pero con distintos grados de relevancia: Integridad; Disponibilidad; Confidencialidad; Autenticidad; No repudio; y Responsabilidad.

c) Por lo tanto, hay que considerar las vulnerabilidades involucradas a las redes, con base en

las siguientes posibilidades:

Fu

d)

e)

f)

1.6 anteriorm

uente: ISO/IEC 18

) Es reconfide

) Las redpor lo …

Los acfirewal

La gumente, sólo m

8028-1:2006

comendable encialidad e in

des que sopormenos: Uso d

ccesos remotolls; …

uía es más emuestra alguna

-

Tabla 2 de la

el uso de ntegridad de l

rtan convergende QoS para l

s (RAS) debe

específica enas de las con

- 3-

a Guía–Vulnerab

VPN paralas informacio

ncia en IP, coa definición d

en ser implem

n cuanto a lonsideraciones

bilidades en Rede

a proveer cones…

on el tráfico dde las priorida

mentados cons

os tips a tenque se debe

S

es

comunicacione

de voz y datosades de transm

siderando, por

ner en cuenen tener en c

SAM/IG/17-N

es que requ

s, deben consimisión de los

r lo menos: U

nta. Lo transcuenta en cua

NE/13

uieran

iderar, datos;

Uso de

cripto anto a

SAM/IG/17-NE/13 - 4-

seguridad. En función de lo expresad, y teniendo en cuenta las guías enunciadas, se realiza un primer análisis de la REDDIG II en cuanto a cuestiones de seguridad actuales y observadas. 1.7 Seguridad en la REDDIG II

1.8 La seguridad en la REDDIG II debería ser definida como el proceso mediante la cual se protegen los recursos. Los objetivos de la seguridad serán:

Proteger la confidencialidad. Mantener la integridad. Asegurar la disponibilidad.

1.9 Objetivos que determinan el imperativo de proteger toda la red a fin de evitar amenazas y vulnerabilidades. 1.10 Una amenaza es un acceso no autorizado a una red o dispositivo de red. Normalmente las amenazas son persistentes debido a las vulnerabilidades, que son problemas que pueden surgir como resultado de una mala configuración del hardware o del software, un diseño pobre de la red, carencias tecnológicas heredadas, falta de capacitación o el descuido del usuario final.

1.11 Los riesgos en la seguridad no pueden eliminarse o prevenirse completamente; sin embargo, una administración y una valoración eficaces de los riesgos pueden minimizar significativamente su existencia. El riesgo asumido se basa en el costo que se quiera tomar para salvaguardar la información.

1.12 Los tres objetivos principales de la seguridad parecen muy simples. Sin embargo, el desafío de asegurar la red a la vez que se tienen en consideración las necesidades operativas puede ser una tarea compleja. Los administradores deben administrar cuidadosamente las políticas de seguridad para mantener el equilibrio entre el acceso transparente, el uso y la seguridad de la red. 2 Necesidad de seguridad en la REDDIG 2.1 Si bien la REDDIG II es una red cerrada para el mundo no aeronáutico, es una red abierta para el mundo aeronáutico. 2.2 Hoy la implementación de firewalls basados en software y en hardware, si bien permiten el control de acceso, muchas veces no es suficiente. Tampoco basta con mantener fuera a las personas no deseadas, sino que se hace necesario desarrollar formas más complejas para mantener dentro a las personas deseadas.

2.3 La finalidad esperada para los usuarios de la REDDIG II es que las medidas de seguridad garanticen lo siguiente:

Usuarios que sólo puedan llevar a cabo las tareas autorizadas. Usuarios que sólo puedan obtener la información autorizada. Usuarios que no puedan provocar daños en los datos, aplicaciones o entorno operativo de un

sistema. Un sistema que pueda rastrear las acciones de un usuario y los recursos de red a los que esas

acciones acceden.

- 5- SAM/IG/17-NE/13

2.4 La seguridad implica controlar los efectos de los errores y los fallos del equipo. Además, el 80 % de todas las intrusiones en la seguridad son iniciadas por individuos internos. 3 Tendencias que afectan a la seguridad en la REDDIG II 3.1 Hay numerosas tendencias que incrementan la demanda de redes más seguras, entre las cuales podemos citar:

Incremento de amenazas a la seguridad aeroportuaria. Acceso inalámbrico. Incremento de los requisitos de ancho de banda. Problemas legales. Preocupaciones por la privacidad. Falta de personal.

3.2 Problemas legales y preocupaciones por la privacidad

3.3 En cuanto a problemas legales, se observa en la actualidad la falta de resguardo legal en cuánto al software empleado por algunos usuarios de la red. Recordar la implicancia que puede traer aparejado la alteración o modificación de un plan de vuelo por dar un ejemplo.

3.4 La preocupación por definir qué información debe ser pública por parte de los usuarios y cuál debe ser resguardada del resto de los usuarios de la red. 3.5 Acceso inalámbrico

3.6 Actualmente ya no son suficientes las conexiones a nivel WAN y LAN, y el acceso inalámbrico representa no sólo una solución para los usuarios de última milla de un aeropuerto, también representa un aspecto a tener en cuenta desde el punto de vista de la seguridad.

3.7 Escasez de personal

3.8 La escasez de personal capacitado está repercutiendo especialmente en el campo de la seguridad.

3.9 En este sentido se hace prioritario dar curso a la capacitación para no terminar dependiendo de terceros que generalmente aportan soluciones parciales tendientes a generar una dependencia absoluta de los mismos como proveedores.

3.10 Los administradores deben considerar estos temas para conseguir un acceso transparente:

Conectividad. Rendimiento. Facilidad de uso. Manejabilidad. Disponibilidad.

3.11 En cuanto a la seguridad, los administradores deben tener en consideración estos otros temas:

Autenticación. Autorización.

SAM/IG/17-NE/13 - 6-

Contabilidad. Confianza. Confidencialidad. Integridad de los datos.

3.12 Elementos clave de la seguridad en las redes

3.13 El uso satisfactorio de las tecnologías requiere la protección de los datos valiosos y de los recursos de la red ante la corrupción y la intrusión. Una solución de seguridad contiene cinco elementos clave:

Identidad. Seguridad del perímetro. Privacidad de los datos. Administración de la seguridad. Administración de políticas.

4 Análisis 4.1 Básicamente se pueden apreciar como principio del análisis las siguientes características generales de la red:

a) La red terrestre es sobre MPLS VPN, brindada por un proveedor, Level (3), en la cual, el administrador de la REDDIG II, al igual que cualquiera de sus usuarios, no tiene gestión sobre los dispositivos y mucho menos sobre esta red, supuestamente mallada, y, supuestamente, con QoS prevista para priorizar los paquetes pertinentes.

b) Existen dos puntos de acceso externo conocidos por ip pública, en Ezeiza y Manaus,

a través de equipos Netgear ProSAFE VPN Firewall, con administración por parte de la empresa INEO, el administrador de la REDDIG II y personal de los NCCs.

c) Red satelital con equipos de networking sobre los cuales se tiene gestión o

managment.

d) Routers ó equipos de networking de borde hacia las redes internas de cada Estado.

e) Si bien se aplican políticas de seguridad, no hay un estándar establecido en particular para los routers de borde implementados por cada Estado.

f) No están precisados procedimientos tendientes a estandarización de políticas de

seguridad, resguardo de la información (backups de las configuraciones a realizarse en determinados períodos), etc.

g) Se desconoce si existen accesos remotos hacia los routers de borde, propiedad de

cada Estado, y que pueden ser puntos vulnerables a la red. Se supone que esta situación está presente, pero se desconocen los resguardos que adopte cada Estado en tal sentido.

h) Se observan aspectos importantes sobre las tecnologías aplicadas que son

desarrolladas en los anexos de la presente NE.

- 7- SAM/IG/17-NE/13

i) El esquema de direccionamiento es IPv4, Clase A, que obliga a utilizar NAT siendo

una herramienta considerada de seguridad

4.2 A fin de poder dar a conocer un análisis más preciso sobre los puntos expuestos anteriormente, se invita a los lectores a dar lectura a los Anexos presentados a continuación en la presente NE. 5 Conclusiones

5.1 Teniendo en cuenta la posibilidad de redactar directivas sobre la política de seguridad, y con el objetivo de dar cumplimiento a los controles de seguridad, se sugiere la redacción de los siguientes documentos:

Política: compromiso explícito, el enfoque de la política y las directivas estratégicas respecto del manejo de la seguridad del conocimiento y la información.

Estándar: especificar características, funcionalidad, capacidad, calidad y otros atributos/ cualidades mínimas que deben satisfacer los productos y/o servicios utilizados para el procesamiento de la información, al efecto de cumplir con los controles de seguridad de la Política.

Norma: brindar directivas, reglas y características de aplicación obligatoria con el fin de procurar el cumplimiento de los controles de seguridad expresados en la Política.

Ejemplo: Norma de uso de los activos de Información (redes, correo electrónico, etc). Procedimiento: describir maneras probadas y metódicas de realizar operaciones

repetitivas tendientes al cumplimiento de controles de seguridad específicos expresados en la Política. Ejemplo: procedimiento de backup de configuración de dispositivos.

Informe de Insuficiencias: identificar, describir y aprobar la ausencia o debilidad de las salvaguardas que aparecen como oportunas para reducir los riesgos de seguridad. Ejemplo: Informe de inadecuada e insuficiente segregación de ambientes por falta de dispositivos. Implantación de controles adicionales.

5.2 En cuanto a las acciones, en función de la evaluación y la presente NE, se presenta el siguiente diagrama en donde se manifiestan todas las consideraciones sobre el tema que fueron consensuadas con los participantes de la teleconferencia realizada el pasado 26 de abril de 2016.

- 8- SAM/IG/17-NE/13

AMENAZAS IDENTIFICADAS CONSIDERACIONES ACCIONES PROPUESTAS

Subred terrestre MPLS LEVEL 3

La red terrestre es sobre MPLS VPN, brindada por un proveedor, Level (3), en la cual, el administrador de la REDDIG II, al igual que cualquiera de sus usuarios, no tiene gestión sobre los dispositivos y mucho menos

sobre esta red, supuestamente mallada, y, supuestamente, con QoS prevista para priorizar los paquetes pertinentes.

* Que el proveedor de servicio de la subred terrestre (LEVEL 3) debería informar si utiliza el estándar de seguridad RFC 592. * Que en la reunión de mediados de mayo de 2016 se trate con la empresa Level (3) el tema de seguridad. * Que se haga uso de NAT en los routers de frontera de los Estados entre el nodo de la REDDIG II y la subred terrestre de LEVEL 3 , adicionalmente se podrían proceder a la encriptación de la información.

Accesos remotos a través del internet publica en la REDDIG II por VPN

En la REDDIG II el consorcio INEO& LEVEL 3 ha considerado que cada nodo de la REDDIG II tenga instalada una interfaz VPN con el fin de poder acceder remotamente a los equipos de la red (Routers, MODEMs amplificadores) en caso de falla o cambios de configuración. A la fecha se tiene VPN en

operación en los nodos de Brasilia, Ezeiza y Manaus. Se han instalados VPN en Montevideo (Uruguay) y Guayaquil (Ecuador pero no están en operación) el consorcio INEO& LEVEL 3 está utilizando este acceso para corregir problemas en los equipos de los nodos o cambios de configuraciones y lo seguirá utilizando

hasta que proceda la entrega de la red al proyecto (RLA/03/901) que ocurrirá una vez que se haya realizado la aceptación definitiva de la red, también este acceso será utilizado durante el periodo de

garantía (dos años a partir de la aceptación final de la red).

* Cuando la red pase bajo el control de la OACI, el acceso VPN será manual bajo requerimiento del administrador de la REDDIG. De esta forma se reducirían los peligros que se presentan al tener siempre conectado a la REDDIG II redes públicas IP.

* En vista que las manipulaciones ocurren a través del sistema de gestión (NMS) se deberíaactualizar constantemente el antivirus de la aplicación Whats up gold .

* Una vez que la red sea administrada completamente por la OACI, se procederá a cambiar todos los password de acceso. Tener en cuente que en este momento todos los que operan la red conocen los password de todos los nodos de la REDDIG II . Solamente el administrador de la red y aquel personal de cada NCC que este autorice el mismo con un login y password que lo identifique, tendrán el acceso a la red. La administración, configuración, y registro de actividades, estarán a cargo del Adminsitrador de la Red. * Las personas a cargo del mantenimiento del nodo solamente tendrán acceso a su propio nodo con login y password personales y asignado por el Adminsitrador. * Todas las actividades que se realicen en las configuraciones de los equipos de networking quedarán registrados en un servidor al cual tendrá acceso del Administrador y donde quedarán registrados todos los accesos y cambios que el personal autorizado haya realizado.

En el caso de que usuarios realicen cambios en la configuración de equipos de networking de la REDDIG, y estos cambios resulten contrarios a los deseados o afecten servicios.

* Realizar tareas de Backup de todos los equipos de la red de manera automática y con tiempopredeterminados para contar, ante contingencias, con las configuraciones actualizadas.

Asimismo el grupo consideró la necesidad que el servidor del NMS este constantemente registrando las configuraciones de los diferentes equipos de forma tal de poder tener grabado versiones anteriores , de esta forma se garantizaría regresar a versiones anteriores en caso de problemas en las nuevas versiones.

* A fin de poder identificar los potenciales peligros, se debería realizar un relevantamiento de como están conectados los circuitos a las interfaces de entrada de la REDDIG II. Este relevantamiento permitiría identificar si algunos de los circuitos o servicios que entran en la red vienen de alguna red pública.

* Que los servicios y circuitos se interconecten a través de un router de frontera y no directamente a los router de la REDDIG

* Que los router de frontera deben tener los firewall adecuados

* Realizar un estudio sobre un firewall estándar para aplicar a todos los router de frontera y estandarizar el nivel de seguridad en todas las entradas a los nodos REDDIG

* Hacer un inventario de equipamiento licenciado (frecuencia-espectro satelital) por cada nodo.

* Registro de los equipos de Estados ya licenciados nacionalmente y/o MIFR, volcados en Base de datos (Software)

* Monitoreo y Tracking constante del espectro radioeléctrico empleados por los nodos REDDIG, a fin de no ser interferidos y tampoco causa eventuales interferencias

* Con el apoyo o soporte de la UIT hacer control de las amenazas de interferencia invocando al Articulo 45 CS y 15.1 del RR de la UIT

* Grupo de Trabajo capacitado para realizar trabajos de control y mitigación de interferencias

* Implementar Politicas de Seguridad* Tener actualizada y disponible la topología de la red

* Asignar login y password a los responsables de cada nodo, de forma tal de limitar y controlar lasfacilidades con que cada uno gestionará los dispositivos de networking pertenecientes a la red.

* En principio determinar dos tipos: administradores con acceso a toda la red; y usuarios responsablesdesigandos con acceso sólo a los equipos de su nodo.* Prevenir intentos de acceso por fuerza bruta estableciendo parámetros de tiempo para el ingreso de claves en el dispositivo

OTRAS CONSIDERACIONES

Los aspectos tendientes a implementar una adecuada política de seguridad

otros aspectos a considerar para evitar riesgos en la REDDIG II

INTERNAS de la REDDIG (Sub red satelital y Subred

terrestre)

Factores humanos

EXTERNAS de la REDDIG es decir a nivel de los usuarios que acceden a la red

Los aspectos a considerar tienen que ver con la protección de las frecuencias de la REDDIG II

La intervención humana en los nodos de cada sitio, la carga de nuevas configuraciones de software, bajar información almacenada en los equipos, etc; debe hacerse con mucha precaución evitando introducir virus

posiblemente instalados en CD o memorias USB.

EXTERNAS a la REDDIG II

Esta parte se refiere del lado de los usuarios de la REDDIG II. A nivel de usuario los tipos de servicio entrante en la REDDIG son circuitos de voz y datos. Los circuitos de datos representarían el factor más improtante de vulnerabilidad en cuanto a seguridad de la red.

- 9- SAM/IG/17-NE/13

6 Acciones sugeridas

Se invita a la Reunión a:

a) Tomar nota de la información presentada; b) dar lectura de los Apéndices producto del análisis e información.

Apéndice A: primera aproximación sobre auditoría Apéndice B: Netgear y equipos net de la REDDIG II Apéndice C: requerimiento proveedor MPLS Apéndice D: extracto RFC 5920 Apéndice E: SLA y MPLS Apéndice F: Recomendaciones para auditoría

c) analizar la posibilidad de continuar con un estudio más acabado y ejecutar las

acciones pertinentes en función de los resultados obtenidos; y d) analizar las consideraciones que resulten de la misma y complementar las guías de

orientación vigentes para la Región.

--------

1.1

1.2 seguridad 1.3

1.4 a nivel de 1.5 No Confia 1.6 dispositivREDDIG,en los disp 1.7 toda comured, debeprobada a 1.8 de IP hacigestión essentido, cborde con

Conexión

Existen dd.

A continu

La conexie capa de red:

En la REDables.

Dentro devos de capa 3 , hacia los dipositivos de b

Las impleunicación quen ser revisad

antes de ser im

Al mencioia redes privas compartida ccobran vital in aplicación d

Pri

Aspectos ge

n o contactos

dos puntos d

uación, se pres

ión hacia el pIP.

DDIG se pued

e la Conexion(router de bo

spositivos deborde, política

ementacionese no satisfagadas y fortalecmplementada.

onar conexionadas de los precon los diferemportancia p

de políticas ad

AP

imera aproxi

nerales del e

con redes ex

de contacto c

senta esquem

proveedor es a

de hablar de c

nes Confiableorde del lado e los proveedoas adecuadas

con funciona las necesidacidas. Cada p

nes No tan Cestadores, e inentes usuariospolíticas comudecuadas para

PÉNDICE A

imación sobr

esquema de r

xternas

con redes ex

ma conceptual.

a nivel de cap

conexiones de

s, se puede dde la REDD

ores. Hay quepara permitir

nes de firewaades de los sepermiso de a

onfiables, habnclusive de las de cada nodunes a los Es

a permitir sólo

re auditoría

red de la RED

xternas, con

.

pa de enlace d

e tres tipos: C

decir que las mDIG) bajo com

e tener en cur sólo accesos

all o listas deervicios de usacceso debe s

blamos de toas LANes de cdo de la REDDstados e impo los accesos

S

DDIG II

ciertos grad

de datos (LAN

Confiables, No

mismas son ampleto y excluuenta que se ds deseados.

e acceso (ACsuario y de adser cuidadosa

das aquellas cada Estado, DIG II, la empplementación deseados.

SAM/IG/17-N

dos de riesgo

N), o directam

o tan Confiab

a nivel de IP, usivo controldeben implem

CLs) para blodministraciónamente evalu

conexiones aya que el conpresa INEO. de dispositiv

NE/13

os de

mente

bles, y

desde l de la mentar

oquear n de la uada y

a nivel ntrol y En tal

vos de

SAM/IG/

1.9 de capa 2inmediata

1.10 que tieneconfiguraLAN, don 1.11 celosamenel adminis

1.12 donde Lemismo estdepende eservicios, 1.13 riesgo queconfiguraacceso cohacia los N 1.14 la responsun contexproveedorpoco conf

17-NE/13

Debe nota2) de cada E

amente eviden

Es necesa acceso de lción deficient

nde residen lo

Tanto el tnte monitoreastrador de la R

Para elevel (3) es el tá directamenexclusivamendepositando

Nuevae conllevan yción de los dn privilegios,NCC de la RE

Hay qusabilidad y elxto de conexior tiene conexifiable.

arse que la coEstado. Y tante) tiene con

ario realizar alos equipos yte (por mala i

os servidores e

tráfico, comoados, debiendREDDIG II. E

Fig.

l caso de la Cúnico que ti

nte conectadonte de la respla REDDIG I

mente, aunquy deberían serdispositivos, c, al menos parEDDIG II.

ue destacar qul daño en la reones al coraziones a Intern

-

onexión con lambién que exiones a las

acuerdos escriy con relacióintención o inesenciales.

los cambiosdo implementaEsto es válido

. muestra esqu

Conexiones Niene control a la LANes (onsabilidad, II confianza c

ue se considerr reconsideradcontar con mra visualizar l

ue se debe haeputación del

zón de la red, net), este tipo

A2-

as redes localla red del predes pública

itos específicoón a los alcanadvertida) pu

de configuraarse procedimo para los rou

ema conexión

No Confiablesy gestión sob(switch de cadedicación y

ciega en ello.

ra que este tipdos, en la coy

monitoreo del la configurac

acer notar al pl proveedor enublado por de conexione

les se realiza proveedor casas (Internet),

os entre los Eances de la uede dejar un

ación de estomientos de conuters de borde

de nodo Ezeiza

s. En este senbre los dispo

apa 2) de caday cuidado con

po de conexiyuntura deber

tráfico y de ción, y envío d

proveedor, enen caso de inc

tanta incertides también po

directamentesi siempre (acaso LEVEL

Estados en fugestión coma puerta abier

os routers de bntrol de camb

e en cada nodo

a

ntido se plantositivos de caa Estado. La sn la que el pr

ones no es acrían acordarse

los cambiosde mensajes d

n cuanto a la rcidentes de sedumbre (seguodría ser cons

e a la LAN (saunque no r (3).

unción del permpartida. Cua

rta al corazón

borde deberíabios acordadoo

tea el escenarapa 3 (routerseguridad de roveedor honr

ceptable por ee los alcancess de configurade Syslog y a

relación comeeguridad, perouramente la residerada como

switch resulte

rsonal alquier n de la

an ser os con

rio en ) y el la red re sus

el alto s de la ación,

alarma

ercial, o ante ed del o muy

-A3- SAM/IG/17-NE/13

1.15 Cuando los equipos de networking están bajo completo dominio y administración de la REDDIG II, no deben “relajarse” las medidas de seguridad aconsejadas por las reglas del arte, las cuales siempre deben ser aplicadas, mantenidas y revisadas. Entre ellas está el aplicar reglas que eviten que cualquier usuario, desde cualquier parte de la red, pueda llegar a donde quiera, si tal privilegio no es necesario para la ejecución de sus tareas (menor privilegio, segregación de tareas y funciones, etc.). 1.16 En las configuraciones de los routers se observan listas de acceso y uso del servicio snmp como se aprecia en un extracto de un router de la REDDIG a continuación:

snmp-server community public RO access-list 11 permit 10.0.0.0 0.0.0.255 access-list 12 permit 10.0.2.0 0.0.0.255 access-list 13 permit 10.0.1.0 0.0.0.255 access-list 118 permit udp any eq 57 any eq 57 access-list 126 permit tcp any any range 1963 1978 access-list 127 permit tcp any range 1963 1978 any access-list 146 permit udp any range 16384 19000 any range 16384 19000

1.17 No obstante, las mismas deberían ser revisadas, corregidas, fortalecidas, aplicadas y adoptar todas las consideraciones que surjan en tal sentido. Mismo criterio debiera adoptarse para los routers de borde de cada Estado. 2 Riesgos y políticas de seguridad 2.1 En cuanto a conexiones contra redes externas, estas atentas directamente contra la vulnerabilidad de la red ante las amenazas externas. 2.2 Se han identificado puntos de contacto con redes externas, como así también se han podido apreciar contramedidas básicas para reducir los riesgos. Esto no implica necesariamente la tranquilidad que se necesita respecto de la protección de la información. 2.3 Como se mencionó anteriormente, se tienen dudas sobre intrusiones hacia los routers de borde que tiene cada Estado, desde accesos remotos externos y ajenos a la REDDIG pero que permiten el acceso a los diferentes equipos de networking de la red. 2.4 Las contramedidas adecuadas y que resulten efectivas deben elaborarse a partir de un plan maestro o se tendrá como consecuencia que las mismas se vuelvan contra los propios usuarios. 2.5 Este plan maestro debe permitir proteger adecuada y racionalmente los sistemas de información y comunicación, alineados con su misión y objetivos, y que satisfaga el marco de requisitos consecuentes para el desarrollo de las actividades. 2.6 La OACI debe adecuar su diseño de red de manera tal que le permita aplicar el plan de seguridad. 2.7 Inicialmente, la red fue concebida como una entidad cerrada, sin conexiones hacia otras redes, pero ha crecido en la cantidad de nodos, conexiones, usuarios y empresas conectadas a través de redes públicas que influyen sobre el transporte del tráfico a través de la REDDIG II. Esto implica una estrategia de concientización y acciones concretas tendientes a organizar y establecer políticas de seguridad que beneficien a los usuarios.

SAM/IG/17-NE/13 -A4-

2.8 Existe la necesidad de fijar y establecer zonas de seguridad, puntos de control donde implementar las reglas que dicten sus políticas de seguridad (las que por otra parte no están del todo claras). 2.9 No se evidencia la existencia formal de controles de acceso, ni procedimientos elementales de respaldo, gestión de cambios, segregación de ambientes y tareas, monitoreo, ni documentación específica sobre los procedimientos operativos sobre seguridad. 2.10 Si bien existe una guía sobre seguridad, no se puede decir que se cuente con un documento que contenga La Política de Seguridad de la Información en donde se declaren objetivos de control (o Directivas) de alto nivel estratégico que indican “qué” debe hacerse, pero sin indicar el “cómo”. 2.11 Teniendo en cuenta la posibilidad de redactar directivas de la política d seguridad, y con el objetivo de dar cumplimiento a los controles de seguridad, se sugiere la redacción de los siguientes documentos subordinados al plan fundamental:

Política: compromiso explícito, el enfoque de la política y las directivas estratégicas respecto del manejo de la seguridad del conocimiento y la información.

Estándar: especificar características, funcionalidad, capacidad, calidad y otros atributos/ cualidades mínimas que deben satisfacer los productos y/o servicios utilizados para el procesamiento de la información, al efecto de cumplir con los controles de seguridad de la Política.

Norma: brindar directivas, reglas y características de aplicación obligatoria con el fin de procurar el cumplimiento de los controles de seguridad expresados en la Política.

Ejemplo: Norma de uso de los activos de Información (redes, correo electrónico, etc).

Procedimiento: describir maneras probadas y metódicas de realizar operaciones repetitivas tendientes al cumplimiento de controles de seguridad específicos expresados en la Política. Ejemplo: procedimiento de backup de configuración de dispositivos.

Informe de Insuficiencias: identificar, describir y aprobar la ausencia o debilidad de las salvaguardas que aparecen como oportunas para reducir los riesgos de seguridad. Ejemplo: Informe de inadecuada e insuficiente segregación de ambientes por falta de dispositivos. Implantación de controles adicionales.

3 Al listado de routers que se incorpora a este informe a continuación, se deben resaltar tres cuestiones:

a) La mayoría de los routers de la REDDIG II poseen gestión compartida, la cual se circunscribe a todos los que tengan acceso local en cada nodo, al administrador de la REDDIG y a personal de INEO.

b) Todos los nodos tienen un router que es propiedad de Level (3), sobre el cual no se

tiene ningún tipo de acceso, control o visualización a través de un usuario con determinados privilegios.

c) No se contempla en el siguiente listado los routers que hacen de borde entre la

REDDIG II y las redes de cada Estado. No se tienen las características, políticas de seguridad, gestión, etc.

3.1 borde de c

d) Sere

Listado

cada Estado)

e deben destemoto utilizan

o de routers

-

tacar los equndo Ips públic

y switches in

A5-

uipos NetGeacas de ISP ext

nstalados en

ar que son loternos.

los nodos (n

S

os puntos de

o se contemp

SAM/IG/17-N

acceso exte

plan los route

NE/13

erno o

ers de

SAM/IG/

17-NE/13 -

A6-

-

A7- S

SAM/IG/17-NNE/13

SAM/IG/

17-NE/13 -A8-

N

A

Netgear y eq

APÉNDICE

uipos net de

B

la REDDIG G II

SAM/IG/17-NE/13

SAM/I

IG/17-NE/13 -B2-

-B3- SAM/IG/17-NE/13

SAM/I

Th

We

Fo

IG/17-NE/13

e multiplexor

e use 2901 m

r the MPLS ac

r / routers use

odels and 29

ccess, Cisco a

ed in REDDIG

11 models.

re of the 180

-B4-

G are of the 29

00 and 1900 fa

900 family.

amily.

29

29

901

911


SAM/I

IG/17-NE/13 -B6-

SAM/I

IG/17-NE/13 -B8-

SAM/I

IG/17-NE/13 -B10-

-B11- SAM/IG/17-NE/13

SAM/I

SSL y

El firedos mred. Lcualquto-sitesofistipor SNserviciloggininformequilibfiabiliddireccla con Segur El FVtúneleDoS ycorreoaccesoalto nasegurofrece

IG/17-NE/13

y túneles VP

ewall Gigabimundos, con Los túneles Vuier lugar y me y soporte cado firewaNMP y que io (DoS), in

ng, informes mación en mbrio de cargdad en la coiones de redexión de ban

ro

S336G cumps VPN IPsey múltiples o electrónicoos por VPN nivel y cararar la protece un alto nive

PN IPsec par

it WAN Duados tipos deVPN SSL omomento, mpara acces

ll y constituaporta segu

nspección dy alertas en

movimiento aga y protecconexión a Intd (NAT) y ronda ancha de

ple con todoc y 10 túneltransmision

o para monitno autorizad

acterísticas cción y privael de defensa

ra acceso re

al Prosafe coe túneles VPofrecen acce

mientras que os de clien

uye una solucuridad multide paquetes n tiempo reaa alta velocidión contra fternet. Ademouting clásice la red.

os los requisiles VPN SS

nes VPN. Otorización dedos. Los túncomo limpieacidad de losa contra las a

-B12-

emoto segur

on SSL y VPPN, SSL y seso remoto los túneles V

ntes remotosción de red idimensionalde estado (l. Dispone ddad, mientrafallos para amás, gracias o, permite e

itos de segurSL, proteccióOfrece servic

e redes. La aneles VPN Seza automáts datos críticamenazas de

ro a la red

PN IPsec deseguridad IPclientless a

VPN IPsec os. Este routde alto rendl, incluyend(SPI), filtradde 4 puertos as que los 4asegurar el ma la tecnolol acceso sim

ridad, soportón contra intcio de SYSLautenticació

SSL soportantica del caccos. El firewe seguridad d

e NETGEARP para una c

la informacofrecen coneter VPN lledimiento quedo proteccióndo de URL LAN Gigab

4 puertos WAmáximo nivgía de routin

multáneo de h

tando simulttrusos vía fiLOG e info

ón IKE ofrecn algoritmosché al termi

wall Gigabit Wde la red.

R ofrece lo monexión segción corporaexiones segueva incorpore se puede gn de denega

por palabrabit para manAN Gigabit

vel de transmng de convehasta 253 us

táneamente hirewall SPI, ormes enviace proteccións de encriptainar la sesiWAN Dual

mejor de gura a la ativa en

uras site-rado un

gestionar ación de a clave,

ntener la ofrecen

misión y rsión de

suarios a

hasta 25 ataques

ados por n contra ación de ón para ProSafe

SAM/IG/17-NE/13

APÉNDICE C

REQUERIMIENTOS A TENER EN CUENTA PARA EL PROVEEDOR DE UNA RED IP PARA LA SOLUCIÓN REQUERIDA

Propósito del Documento Este documento especifica los requisitos para la red IP que se utilizará para la interconexión de los diferentes usuarios que constituyen la red. Se definen los requisitos necesarios que debe garantizar un Proveedor de Servicios de Red (NSP – Network Service Provider) para permitir el correcto funcionamiento del sistema global a implementar. Requerimientos Generales El proveedor del servicio deberá proporcionar una VPN (MPLS) lógica. La red lógica no deberá ser compartida con otros clientes o servicios, a excepción de los servicios del propio usuario (AMHS, voz ATS, datos radar, etc); en cualquier lugar a través de la infraestructura que la soporte.

Nota: Esto se aplica no sólo a la VPN (MPLS) lógica dentro de una infraestructura ruteada, sino también a una infraestructura switcheada - si se proporciona – hasta un sitio de la red.

No puede utilizarse site-to-site bridging. La red deberá ser ruteada. La razón principal es reducir los dominios de broadcast para cada sub-red geográficamente separadas. Por lo tanto, el tráfico de broadcast, que puede generar burst traffic, no será transportado a través de la infraestructura WAN. De esta manera los vínculos con bajo ancho de banda podrán utilizarse de manera más eficiente. Sin embargo, si el NSP dispone de suficiente ancho de banda y es capaz de proporcionar una VPLS (Virtual Private LAN Service), este escenario puede ser analizado nuevamente. Si se utilizan switches, se desactivará el auto-MDX. También se requiere conocer si el empleo de cables rectos o cruzados es indistinto o no. El RTP header incluye información de señalización (PTT / SQU) en el header extension field. Por lo tanto, sólo se utilizará la compresión de encabezados RTP si estos campos se transmiten de forma transparente. El RTP Header extension se implementará de acuerdo a RFC3550 Plan del direccionamiento IP Cada sitio tendrá su propia subred(s). Las direcciones IP deben ser direcciones IPv4 IP (permitir en el futuro implementación IPv6). El esquema de direccionamiento IP debe ser legible para facilitar cualquier debugging de la Red. Se respetará el direccionamiento IP empleado por el usuario, tanto para las direcciones WAN como LAN. El rango de direcciones IP será privada. Por supuesto, la regla de oro del direccionamiento IP debe seguir la topología física con el fin de permitir la sumarización.

SAM/IG/17-NE/13 -C2- Requisitos de QoS Los mecanismos de QoS que se emplearán, deben basarse sólo en la capa 3 DiffServ. La estructura de enrutamiento deberá soportar DiffServ en toda la infraestructura del proveedor de servicio para priorizar los paquetes que pertenecen a diferentes clases de servicio en cada salto de la red. La QoS en capa 2 (por ejemplo, IEEE 802.1p) no será requerida en una infraestructura switcheada. Por lo tanto, no habrá un solo dominio de QoS basado en valores DSCP. Si la QoS es necesaria para la LAN, se requerirán switches Ethernet L2 que soporten las pautas de calidad de servicio en función del campo DSCP L3. Los sistemas de comunicación IP requieren al menos tres clases de calidad de servicio. Clase I: low latency data (voz sobre RTP, NTP) Marcado con Expedited Forwarding (DSCP=EF) El menor delay posible end-to-end, jitter minimizado, reducido packet drop rate. Se utilizará para la sincronización de voz y tiempo. El tráfico, que tiene un origen síncrono, será transportado a través de esta clase. El tráfico en esta clase deberá tener prioridad sobre cualquier otra clase. El low-latency-data (ej. voz sobre RTP) debe tener prioridad de ruteo sobre la infraestructura de la red, con el más bajo delay posible (se sugiere el uso de LLQ). Clase II: mission critical data (señalización, SNMP-traps) Marcado con Assured Forwarding (DSCP=AF31). Bajo delay para responder rápidamente a aplicaciones near-real-time. El Jitter no es un problema en esta clase. El tráfico en esta clase será programado detrás de la Clase I, pero deberá tener prioridad sobre cualquier otra clase. Clase III: default class (cualquier otro tipo de tráfico ) No explícitamente marcada. Ej.: Best Effort (DSCP = 0 = BE) Se basa en la disponibilidad por defecto de la infraestructura de IT. Para esta clase se utilizan mecanismos que no priorizan tráfico. Por ejemplo FTP, HTTP, etc. (tráfico típico de esta clase). Rendimiento y disponibilidad Cada clase de QoS tiene sus propios requisitos para el rendimiento y la disponibilidad. La base para evaluar la latencia de extremo a extremo debe ser el tráfico de la clase respectiva, y no cualquier otro tipo de tráfico que pertenece a una clase diferente. (por ejemplo, mediciones de retardo para la clase I tienen que basarse en los paquetes RTP con 80 bytes de carga útil - payload).

-C3- SAM/IG/17-NE/13

QoS Clase I Telefonía Servicio End-to-end (1-way): depende de los requerimientos del proyecto. Packet loss (1-way): <0,1% End-to-end-jitter (1-way): < 15ms (para datos Clase I - ej. DSCP=EF – y no ping ICMP / BE) End-to-end delay (1-way): < 100ms (para datos Clase I - ej. DSCP=EF - y no ping ICMP / BE) - O de acuerdo a los requerimientos del proyecto QoS Datos Clase I End-to-end service (1-way): depende de los requerimientos del proyecto Packet loss (1-way): <0,1% End-to-end-jitter (1-way): < 15ms (para datos Clase I - ej. DSCP=EF – y no ping ICMP/BE) End-to-end delay (1-way): < 100ms (para datos Clase I - ej. DSCP=EF – y no ping ICMP/BE) – O de acuerdo a los requerimientos del proyecto. QoS Clase II Servicio end-to-end (1 way): depende de los requerimientos del proyecto Packet loss (1 way): < 0.5 % End-to-end- jitter (1 way): N / A End-to-end delay (1 way): N / A QoS Clase III SERVICIO END-TO-END (1 WAY) : DEPENDE DE LOS REQUERIMIENTOS DEL PROYECTO Packet loss (1 way): < 1 % End-to-end-jitter (1 way): N / A End-to-end delay (1 way): N / A Infraestructura switcheada Si el NSP proporciona infraestructura switcheada Capa 2 para el acceso de los equipos del cliente a la red, en lugar de un router, el switch deberá soportar mecanismos de QoS basado en DSCP (es decir, requiere switches L3). El switch debe tratar las clases de QoS descriptos (Clase I / II / III), respectivamente (véase más arriba).

SAM/IG/17-NE/13 -C4- Requerimientos de ancho de banda RTP - (a -law, u- ley, 10ms packet size) requiere 1 canal de voz para radio

• aprox. 136kbps (a -law, u- ley, 10ms packet size) • aprox. 100kbps (a -law, u- ley, 20ms packet size) • aprox. 88kbps (a -law, u- ley, 30ms packet size)

Requerimientos generales:

• El tráfico de SIP puede ser insignificante.

• El tráfico de NTP puede ser insignificante. • El tráfico SNMP puede ser considerable dependiendo de cuáles variables y tablas se

recuperen (y con qué frecuencia éstos se recuperan), y la cantidad de traps SNMP enviados - esto dependerá proyecto.

• Otros protocolos de gestión, tales como: SCP , FTP , HTTP , TFTP , HTTPS, Telnet,

SSH, etc., probablemente residirán en la clase BE, pero el ancho de banda requerido se deberá establecer según los protocolos usados y previstos tanto por el usuario como por el proveedor, en consecuencia dependerá del proyecto.

SAM/IG/17-NE/13

APÉNDICE D

Extracto de la RFC 5920

INFORMATIVO Internet Engineering Task Force (IETF) L. Fang, Ed. Petición de Comentarios: 5920 Cisco Systems, Inc. Categoría: Informativo de julio de 2010 ISSN: 2070-1721

MARCO DE SEGURIDAD PARA MPLS Y GMPLS REDES Abstract Este documento proporciona un marco de seguridad para etiquetas multiprotocolo Switching (MPLS) y Generalizado Multiprotocol Label Switching(GMPLS) Redes. Este documento aborda los aspectos de seguridad que son pertinentes en el contexto de MPLS y GMPLS. En él se describe la amenazas a la seguridad, las técnicas de defensa relacionados, y la mecanismos para la detección y notificación. En este documento se hace hincapié en consideraciones de seguridad RSVP-TE y del PLD, así como inter-AS y consideraciones de seguridad entre proveedores para la construcción y el mantenimiento MPLS y redes GMPLS a través de diferentes dominios o diferente Proveedores de servicio. Tabla de contenido 1. Introducción ......................................... ......... 4 2. Terminología ........................................ .......... 5 2.1. Acrónimos y abreviaturas .................................... 5 2.2. MPLS y GMPLS Terminología ................................... 6 3. Modelos de referencia de Seguridad ............................. 8 4. Amenazas a la Seguridad ........................................10 4.1. Los ataques contra el plano de control ..................... 12 4.2. Los ataques contra el plano de datos ....................... 15 4.3. Los ataques a la operación y el plano de gestión............ 17 4.4. Consideraciones de los ataques internos .................... 19 5. Las técnicas defensivas para MPLS / GMPLS Redes............... 19 5.1. Autenticación .............................................. 20 5.2. Las técnicas criptográficas ................................ 22 5.3. Las técnicas de control de acceso .......................... 33 5.4. El uso de la infraestructura aislada ....................... 38 5.5. El uso de la infraestructura agregada ...................... 38 5.6. Proveedor de Servicios de Control de Procesos de calidad .…. 39 5.7. El despliegue de comprobable MPLS / GMPLS servicio ......... 39 5.8. Verificación de la Conectividad ............................ 40 6. Monitorización, detección y generación de informes de ataques a la seguridad ……...................................................... 40 7. Proveedor de servicios Requisitos Generales de Seguridad ...... 42 7.1. Protección dentro de la Red Central ........................ 42 7.2. Protección de Acceso de Usuario Enlace...................... 46 7.3. Requisitos Generales del Usuario para los proveedores de MPLS / GMPLS ............................................................ 48 8. Requisitos de seguridad entre proveedores ..................... 48 8.1. Control-Plane Protección ................................... 49

SAM/IG/17-NE/13 -D2-

8.2. Protección de datos-Plane................................... 53 9. Resumen de MPLS y GMPLS Seguridad ............................. 54 9.1. MPLS y GMPLS amenazas a la seguridad específica............. 55 9.2. Las técnicas de defensa .................................... 56 9.3. Servicio MPLS y GMPLS Proveedor de prácticas recomendadas Los contornos ........................................................ 57 10. Consideraciones de Seguridad.................................. 59 11. Referencias ............................................... …. 59 11.1. Referencias Normativas..................................... 59 11.2. Referencias informativas................................... 62 12. Agradecimientos .............................................. 64 13. Colaboradores 'Información de Contacto ....................... 65 1 . Introducción La seguridad es un aspecto importante de todas las redes, MPLS y GMPLS redes no es la excepción. MPLS y GMPLS se describen en [ RFC3031 ] y [ RFC3945 ]. Varios consideraciones de seguridad han sido tratados en cada uno de los muchos RFC en tecnologías MPLS y GMPLS, pero ningún documento cubre en general Consideraciones de Seguridad. La motivación para la creación de este documento es proporcionar un marco global y coherente para la seguridad MPLS y GMPLS redes. Cada documento puede señalar a este documento de consideraciones generales de seguridad, además de proporcionar consideraciones de seguridad específicas para las tecnologías particulares del documento está describiendo. En este documento, primero se describen las amenazas a la seguridad pertinente el contexto de MPLS y GMPLS y las técnicas de defensa para combatir esas amenazas. Consideramos que los problemas de seguridad resultantes tanto desde comportamiento malicioso o incorrecto de los usuarios y otras partes y desde conducta negligente o incorrecto de los proveedores. Una parte importante de seguridad y defensa es la detección y notificación de un ataque a la seguridad, que también se aborda en este documento. A continuación, se discute requisitos de seguridad proveedor de servicios posibles en una MPLS o GMPLS medio ambiente. Los usuarios tienen expectativas para la seguridad características de las redes MPLS o GMPLS. Estos incluyen la seguridad requisitos para el equipo de soporte de MPLS y GMPLS y operativa requisitos de seguridad para los proveedores. Los proveedores de servicios deben proteger su infraestructura de red y que sea seguro al nivel requerido para proporcionar servicios en sus redes MPLS o GMPLS. Inter-AS y la seguridad entre proveedores se discuten con especial énfasis, debido a que los factores de riesgo de seguridad son más altos con inter-conexiones de proveedores. Tenga en cuenta que la seguridad MPLS entre operadores es también considerada en [ AMF-MPLS-ICI ]. Dependiendo de MPLS o técnicas GMPLS diferente utilizado, el grado de la mitigación de riesgos y metodologías varían. Este documento analiza los aspectos y requisitos para cierta MPLS básico de seguridad y GMPLS técnicas y modelos de interconexión. Este documento no hace intentar cubrir todas MPLS actuales y futuras y tecnologías GMPLS, ya que no está dentro del alcance de este documento para analizar las propiedades de seguridad de tecnologías específicas.

-D3- SAM/IG/17-NE/13

Es importante aclarar que, en este documento, nos limitamos a la descripción de los requisitos de seguridad de los proveedores que pertenecen a MPLS y redes GMPLS, sin incluir los sitios de los usuarios conectados. Los lectores pueden referirse a los "esfuerzos mejores prácticas de seguridad y Documentos "[ OPSEC-efforts ] y" mecanismos de seguridad para Internet " [ RFC3631 ] por razones de seguridad el funcionamiento de la red general. Eso… No es nuestra intención, sin embargo, la formulación de "requisitos" precisas para cada tecnología específica en cuanto a la definición de los mecanismos y técnicas que se deben implementar para satisfacer dicha seguridad requisitos. 2 . Terminología 2.1 .Acrónimos y abreviaturas AS Sistema Autónomo Border Router Sistema Autónomo asbr Modo de transferencia asíncrono ATM Protocolo BGP pasarela de frontera Detección de Reenvío Bidireccional BFD CE dispositivo cliente-Edge CoS Clase de Servicio Unidad central de procesamiento de la CPU DNS Sistema de Nombres de Dominio DoS Denegación de Servicio Carga útil de seguridad de encapsulación ESP FEC Forwarding clase de equivalencia GMPLS Label Switching Generalizado Multi-Protocolo Modo de contador de Galois GCM La encapsulación GRE Enrutamiento Genérico Interconexión ICI Intercarrier Protocolo de control de mensajes de Internet ICMP ICMPv6 ICMP en IP versión 6 Protocolo IGP gateway interior IKE Internet Key Exchange Protocolo de Internet IP IPsec de seguridad IP VPN basada en IP VPN IP LDP Protocolo de Distribución de Etiquetas L2TP L2TP Protocolo de Gestión de Enlace LMP LSP Label Switched Path LSR Label Switching Router MD5 Message Digest Algorithm MPLS Multiprotocol Label Switching MP-BGP multiprotocolo BGP NTP Protocolo de tiempo de red OAM de operación, administración y mantenimiento Path Computation Element PCE PE dispositivo Proveedor-Edge PPVPN Proveedor-aprovisionada de red privada virtual Red de paquetes conmutados PSN

PW Pseudowire QoS Calidad de Servicio RR Ruta Reflector


Protocolo de reserva de recursos RSVP de Protocolo de reserva de recursos RSVP-TE con Ingeniería de Tráfic extensiones Acuerdo de Nivel de Servicio SLA SNMP Simple Network Management Protocol Proveedor de servicios SP SSH Secure Shell SSL Secure Sockets Layer Sincronizar en paquete SYN TCP Transmission Control Protocol TCP TDM Time Division Multiplexing TE Ingeniería de Tráfico TLS Transport Layer Security ToS Tipo de Servicio TTL Time-To-Live UDP Protocolo de datagramas de usuario VC Circuito Virtual VPN Red Privada Virtual Grupo de Trabajo GT de IETF WSS Web de Servicios de Seguridad 2.2 .MPLS y GMPLS Terminología En este documento se utiliza MPLS y GMPLS la terminología específica. Definiciones y detalles acerca de MPLS y la terminología GMPLS se pueden encontrar en [ RFC3031 ] y [ RFC3945 ]. Las definiciones más importantes se repiten en esta sección; para otras definiciones, se remite al lector a [RFC3031 ] y [ RFC3945 ]. red Core: Un núcleo de red MPLS / GMPLS se define como el centro infraestructura de red que consta de P y PE routers. Una red de núcleo / GMPLS MPLS puede consistir en una o más redes que pertenece a un único SP. Cliente Edge (CE) Dispositivo: Dispositivo de borde del cliente es un router o un interruptor de la red del cliente de interfaz con el Servicio la red del proveedor. Desvío de clase de equivalencia (FEC): Un grupo de paquetes IP que son transmitido de la misma manera (por ejemplo, sobre el mismo camino, con el mismo reenvío de tratamiento). Etiqueta: A, corta longitud fija, identificador físicamente contiguas, por lo general de importancia local. Multiprotocol Label Switching (MPLS): MPLS es una arquitectura para eficiente conmutación de paquetes de datos y enrutamiento. MPLS asigna los datos paquetes con etiquetas. En lugar de realizar la coincidencia más larga para… El destino de cada paquete como en el reenvío de IP convencional, MPLS toma las decisiones de paquetes de reenvío únicamente en el contenido de la etiquetar sin examinar el paquete en sí. Esto permite la creación de los circuitos de extremo a extremo a través de cualquier tipo de medio de transporte, utilizando cualquier protocolo. P: encaminador de proveedores. Un encaminador de proveedores es un router en el Servicio proveedor de la red principal de que no tiene directamente las interfaces hacia el cliente. AP router se utiliza para interconectar el PE enrutadores y / u otros routers P dentro de la red central.


PE: Proveedor dispositivo de borde. Un dispositivo de borde de proveedor es el equipo de la red del proveedor de servicios que interactúa con el equipo en la red del cliente. PPVPN: Proveedor-Provisionado Virtual Private Network, incluyendo Capa 2 VPN y VPN de capa 3. VPN: Red privada virtual, la cual restringe la comunicación entre una conjunto de sitios, haciendo uso de una red troncal IP compartido por el tráfico no va o no procedentes de esos sitios [ RFC4110 ]. 3 . Los modelos de referencia de seguridad En esta sección se define un modelo de referencia para la seguridad en MPLS / GMPLS redes. Este documento define cada núcleo MPLS / GMPLS en un solo dominio sea una zona de confianza. Una preocupación principal es sobre los aspectos de seguridad que se refieren a violaciones de la seguridad del "exterior" de una zona de confianza para el "interior" de esta zona. La figura 1 representa el concepto de… Las zonas de confianza en el marco / GMPLS MPLS. / ------------- \ + ------------ + / \ + ------------ + | MPLS / GMPLS + --- / \ -------- + MPLS / GMPLS | | de usuario | MPLS / GMPLS Core | de usuario | | El sitio + --- \ / XXX ----- + sitio | + ------------ + \ / XXX + ------------ + \ ------------- / | | | | | + ------ \ -------- + / "Internet" | <- Zona de confianza -> | MPLS / GMPLS Core con conexiones de usuario y conexión a Internet Figura 1: El MPLS / GMPLS Zona de confianza Modelo La zona de confianza es el núcleo MPLS / GMPLS en una única dentro de un AS Proveedor de servicios única. Una zona de confianza contiene elementos y los usuarios con una seguridad similar propiedades, tales como la exposición y el nivel de riesgo. En el contexto MPLS, una organización se considera normalmente como una zona de confianza. Los límites de un dominio de confianza deben ser cuidadosamente definidos cuando el análisis de las propiedades de seguridad de cada red individual, por ejemplo, los límites pueden estar a la terminación del enlace, interlocutores remotos, áreas, o con bastante frecuencia, sistemas autónomos. En principio, las zonas de confianza deben estar separadas; sin embargo, típicamente redes centrales MPLS también ofrecen acceso a Internet, en el cual caso de que un punto de tránsito (marcado con "XXX" en la figura 1) se define. En el caso de MPLS / GMPLS conexiones entre proveedores o Intercarrier Interconnect (ICI), la zona de confianza de


cada proveedor termina en el ASBRs respectivos (ASBR1 y ASBR2 para el proveedor A y ASBR3 y ASBR4 para el proveedor de B en la Figura 2). Un requisito clave de redes MPLS y GMPLS es que la seguridad de la zona de confianza no se ve comprometida por la interconexión de MPLS / GMPLS infraestructura central con núcleo de otro proveedor (MPLS / GMPLS o no MPLS / GMPLS), Internet, o usuarios finales. Además, los vecinos pueden ser de confianza o no confiable. Los vecinos pueden estar autorizado o no autorizado. Un vecino autorizado es el vecino uno establece una relación de interconexión con. A pesar de que un vecino podrán ser autorizados para la comunicación, no puede ser de confianza. por ejemplo, cuando se conecta con ASBRs de otro proveedor para establecer inter-AS LSP, el otro proveedor se considera una no es de confianza, pero vecino autorizado. + --------------- + + ---------------- + | | | | | MPLS / GMPLS ASBR1 ---- ASBR3 MPLS / GMPLS | CE1 - PE1 Red | | PE2 Red - CE2 | Un proveedor de ASBR2 ---- ASBR4 proveedor de B | | | | | + --------------- + + ---------------- + Intercarrier Interconnect (ICI) Para Proveedor A: Zona de confianza: / GMPLS red MPLS Un proveedor Autorizados, pero que no es de confianza vecino: proveedor de B vecinos no autorizadas: CE1, CE2 Figura 2: MPLS / GMPLS Zona de confianza y Vecino Autorizados Todos los aspectos de seguridad de la red independiente de si una red es una red MPLS / GMPLS, están fuera del ámbito de aplicación. Por ejemplo, los ataques de Internet para servidor web de un usuario conectado a través de la MPLS / GMPLS la red no se consideran aquí, a menos que la forma en que el MPLS / GMPLS la red se aprovisiona podría hacer una diferencia en la seguridad de servidor del usuario. 4 . Amenazas a la Seguridad En esta sección se analizan las diversas amenazas a la seguridad de red que pueden ponga en peligro MPLS / GMPLS redes. RFC 4778 [ RFC4778 ] proporciona la mejor prácticas operativas de seguridad actuales en Internet Service Provider ambientes. Un ataque con éxito en una determinada red MPLS / GMPLS o en un SP de infraestructura / GMPLS MPLS puede causar uno o más de los siguientes enfermo efectos: - Observación, modificación o supresión de un proveedor de usuario o de datos. - Repetición de los datos de un usuario del proveedor o del. - La inyección de datos no auténticos en el tráfico de un usuario del proveedor o de corriente.


- Análisis de patrones de tráfico en el tráfico de un usuario del proveedor o del. - La interrupción de la conectividad de un usuario del proveedor o del. - La degradación de la calidad del servicio de un proveedor. - Sondeo de red de un proveedor para determinar su configuración, capacidad o uso. Es útil tener en cuenta que las amenazas, ya sea malicioso o accidental, puede provenir de diferentes categorías de fuentes. por ejemplo, pueden provenir de: - Otros usuarios cuyos servicios son proporcionados por la misma MPLS / GMPLS núcleo. - El MPLS / GMPLS SP o personas que trabajan para ella. - Otras personas que obtengan acceso físico a un / GMPLS SP de MPLS sitio. - Otras personas que utilizan métodos de ingeniería social para influir en el comportamiento del personal de un SP. - Los usuarios de la misma red / MPLS GMPLS, por ejemplo, las amenazas VPN-Intra. (Estas amenazas están más allá del alcance de este documento.) - Otros, por ejemplo, los atacantes de Internet en general. - Otros productos especiales en el caso de MPLS / GMPLS conexión entre proveedores. El núcleo del otro proveedor puede o no puede ser el uso de MPLS / GMPLS. - Los que crear, entregar, instalar y mantener el software para equipos de red. Dado que la seguridad es generalmente un compromiso entre costo y riesgo, … También es útil tener en cuenta la probabilidad de diferentes ataques ocurra. Hay por lo menos una diferencia percibida en la probabilidad de que la mayoría de los tipos de ataques estando montado con éxito en diferentes entornos, tales como: - Un núcleo MPLS / GMPLS interconexión con el núcleo de otro proveedor. - Una configuración MPLS / GMPLS que transitan por la Internet pública. La mayoría de los tipos de ataques son más fáciles de montar y por lo tanto más probable que la infraestructura compartida a través de la cual se proporciona el servicio se expande desde un único SP para múltiples productos especiales que cooperan para la Internet global.


Los ataques que pueden no ser de suficiente verosimilitud para justificar la preocupación en un entorno controlado de cerca menudo merecer medidas defensivas en más amplios, los ambientes más abiertos. En comunidades cerradas, a menudo es práctico para hacer frente a la mala conducta después de los hechos: un empleado puede ser disciplinado, por ejemplo. Las siguientes secciones describen los diferentes tipos específicos de ataques en los que amenazar a redes / GMPLS MPLS. 4.1 .Los ataques contra el plano de control Esta categoría abarca los ataques a las estructuras de control operados por el SP con núcleos de MPLS / GMPLS. Hay que señalar que mientras que la conectividad en el plano de control MPLS utiliza los mismos enlaces y recursos de la red como son utilizados por los datos plano, el plano de control GMPLS puede ser proporcionada por los recursos separadas de los utilizados en el plano de datos. Es decir, el plano de control GMPLS puede ser físicamente separado del plano de datos. Los diferentes casos de físicamente congruentes y físicamente separada Control / planos de datos conducen a ligeramente diferentes posibilidades de ataque, aunque la mayoría de los casos son los mismos. Tenga en cuenta que, para ejemplo, el plano de datos puede no estar directamente congestionada por un ataque contra un plano de control separado físicamente como podría ser si el control y planos de datos compartidos los recursos de red. Tenga en cuenta también que si el control avión utiliza diversos recursos del plano de datos, no hay supuestos debe hacerse por la seguridad del plano de control en base a la seguridad de los recursos del plano de datos. Esta sección se centra el ataque de afuera. El ataque interno es discute en la Sección 4.4 .

4.1.1 .LSP Creación de un elemento no autorizado El elemento no autorizado puede ser una CE local o un router en otro dominio. Un elemento no autorizado puede generar la señalización de MPLS mensajes. Al menos, esto puede resultar en plano de control adicional y estado de envío, y si tiene éxito, el ancho de banda de red podría ser reservada innecesariamente. Esto también puede resultar en el robo de servicio o incluso comprometer toda la red. 4.1.2 .LSP mensaje Interceptación Esta amenaza podría ser realizada por el tráfico de red de monitoreo, para ejemplo, después de una intrusión física. Sin intrusión física, se que podría lograrse con una modificación de software no autorizado. Además, muchas tecnologías tales como microondas terrestre, satélite o


En el espacio libre óptica puede ser interceptada y sin intrusión física. Si tiene éxito, podría proporcionar información que lleve a la suplantación de la etiqueta ataques. Asimismo, plantea problemas de confidencialidad. 4.1.3 .Los ataques contra RSVP-TE RSVP-TE, se describe en [ RFC3209 ], es el protocolo de control utilizado para establecer hasta GMPLS y el tráfico de ingeniería túneles MPLS. Hay dos tipos principales de ataques de denegación de servicio (DoS) contra un dominio MPLS basado en RSVP-TE. El atacante podrá crear numerosos LSP no autorizadas o pueden enviar una tormenta de mensajes RSVP. Ha sido demostraron que los routers no protegidos funcionamiento de RSVP pueden ser eficazmente desactivada por ambos tipos de ataques de denegación de servicio. Estos ataques pueden incluso combinarse, mediante el uso de los LSP no autorizadas transporte RSVP adicional mensajes a través de los routers donde (u otro) que de otro modo podrían ser filtrados. ataques de RSVP que se pueden lanzar contra los routers adyacentes a la frontera con el atacante, o en contra routers no adyacentes dentro del dominio MPLS, si no hay una efectiva mecanismo para filtrar hacia fuera. 4.1.4 .Los ataques contra PLD PLD, se describe en [ RFC5036 ], es el protocolo de control utilizado para establecer túneles MPLS sin TE. Hay dos tipos importantes de ataque contra el PLD. Un elemento de red no autorizada puede establecer una sesión de PLD mediante el envío PLD y de saludo PLD Init mensajes, lo que lleva a la configuración de un potencial LSP, así como el consumo de acompañamiento tabla de estado de LDP. Incluso sin establecer con éxito LSP, un atacante puede lanzar un ataque DoS ataque en forma de una tormenta de mensajes LDP hola o LDP TCP SYN mensajes, lo que lleva a una alta utilización de la CPU o la mesa de agotamiento del espacio de en el router de destino. 4.1.5 .Los ataques de denegación de servicio en la infraestructura de red Los ataques DoS podría lograrse a través de una tormenta de señalización MPLS, lo que resulta en una alta utilización de la CPU y puede dar lugar a Control- el hambre de recursos avión. Plano de control ataques DoS pueden ser montados específicamente contra el los mecanismos de la SP utilizados para proporcionar diversos servicios, o encontra de la infraestructura general del proveedor de servicios, por ejemplo, los routers P o aspectos compartidos de routers PE. (Un ataque contra el General infraestructura está dentro del alcance de este documento sólo si el ataque puede ocurrir en relación con la infraestructura MPLS / GMPLS; de lo contrario, no es un problema MPLS / GMPLS-específico).

SAM/IG/17-NE/13 -D10-

Los ataques descritos en las siguientes secciones pueden tener cada negación de servicio como uno de sus efectos. Otros ataques de denegación de servicio son también posible. 4.1.6 .Los ataques a Equipos MPLS / GMPLS del SP a través de Gestión Interfaces Esto incluye el acceso no autorizado a la infraestructura de un SP equipos, por ejemplo, para volver a configurar el equipo o para extraer información (estadísticas, la topología, etc.) perteneciente a la red. 4.1.7 .Conexión Cruzada de tráfico entre usuarios Esto se refiere al caso en el que espera que el aislamiento entre separada usuarios (que pueden ser usuarios de VPN) es violada. Esto incluye casos tales como: - Un sitio que se está conectado a la VPN "equivocado". - El tráfico se replica y se envía a un usuario no autorizado. - Dos o más VPNs está correctamente fusionaron. - Una VPN de punto a punto que conecta los dos puntos equivocadas. - Cualquier paquete o trama siendo entregados indebidamente fuera de la VPN para que pertenece Mala conexión o conexión cruzada de VPNs pueden ser causados por el servicio proveedor o equipos de error del vendedor, o por la acción maliciosa de una agresor. El incumplimiento puede ser física (por ejemplo, enlaces PE-CE está incorrectamente) o lógicos (por ejemplo, la configuración del dispositivo inadecuada).

La evidencia anecdótica sugiere que la amenaza de conexión cruzada es una de las mayores preocupaciones de seguridad de los usuarios (o los posibles usuarios). 4.1.8 .Los ataques contra los protocolos de enrutamiento Esto abarca los ataques contra los protocolos de enrutamiento subyacentes que están a cargo de la SP y que apoyan directamente el núcleo MPLS / GMPLS. (Los ataques contra el uso de los protocolos de enrutamiento para la distribución de rutas de cadena principal están más allá del alcance de este documento.) específica ataques contra los protocolos de enrutamiento populares han sido ampliamente estudiados y se describen en [ RFC4593 ]. 4.1.9 .Otros ataques a Control de Tráfico Además de los protocolos de enrutamiento y gestión (cubierto por separado en las secciones anteriores), un número de otros protocolos de control pueden estar directamente involucrado en la prestación de servicios por el núcleo MPLS / GMPLS. Estos incluyen, pero no se limitan a:

-D11- SAM/IG/17-NE/13

- MPLS señalización (LDP, RSVP-TE) se discutió anteriormente en los apartados 4.1.4 y 4.1.3 - Señalización PCE - Señalización de IPsec (IKE y IKEv2) - ICMP y ICMPv6 - L2TP - El descubrimiento de miembros a base de BGP - Descubrimiento de miembros basados en bases de datos (por ejemplo, RADIUS) - Otros protocolos que pueden ser importantes para el control infraestructura, por ejemplo, DNS, LMP, NTP, SNMP y GRE. Los ataques pueden subvertir o interrumpir las actividades de estos protocolos, por ejemplo, mediante la suplantación o de denegación de servicio. Nótese que todos los ataques de plano de datos también se puede llevar a cabo en contra de los paquetes de los planos de control y de gestión: la inserción, spoofing, reproducción, borrado, análisis de patrones, y otros ataques mencionado anteriormente. 4.2 .Los ataques contra el plano de datos Esta categoría abarca los ataques contra del proveedor o el usuario final de datos. Tenga en cuenta que desde el punto de del usuario final a la red MPLS / GMPLS punto de vista, algunos de esto podría ser el tráfico del plano de control, por ejemplo, enrutamiento protocolos que se ejecutan desde el sitio A al sitio de usuario al usuario B a través de IP o no IP conexiones, que puede ser algún tipo de VPN. 4.2.1 .Observación no autorizada de los datos de tráfico Esto se refiere a "oler" paquetes de proveedor o usuario final y el examen su contenido. Esto puede resultar en una exposición de información confidencial información. También puede ser un primer paso en otros ataques (descrito a continuación) en el que los datos grabados se modifican y se vuelven a insertar, simplemente reproducido más adelante. 4.2.2 .La modificación de los datos de tráfico Esto se refiere a la modificación de los contenidos de los paquetes a medida que atraviesan el MPLS núcleo / GMPLS. 4.2.3 .La inserción de no auténtico tráfico de datos: como la suplantación de Replay Spoofing refiere al envío de unos paquetes de usuario o insertar paquetes en un flujo de datos que no pertenecen, con el objetivo de tenerlos aceptado por el destinatario como legítima. También se incluye en esta categoría es la inserción de copias de los paquetes una vez que legítimos se han registrado y reproducido.

SAM/IG/17-NE/13 -D12-

4.2.4 .La supresión no autorizada de los datos de tráfico Esto se refiere a que causa paquetes a ser desechados a medida que atraviesan el redes MPLS / GMPLS. Se trata de un tipo específico de denegación de servicio ataque. 4.2.5 .Análisis del patrón de tráfico no autorizado Esto se refiere a "oler" paquetes de proveedor o usuario y el examen aspectos o aspectos meta-de los que pueden ser visibles incluso cuando el propios paquetes están cifrados. Un atacante podría ganar útil información basada en la cantidad y el tiempo de tránsito, los tamaños de paquetes, origen y destino, etc. Para la mayoría de los usuarios, este tipo de ataque se considera generalmente que es significativamente menos de una preocupación que los otros tipos discutidos en esta sección. 4.2.6 .Los ataques de denegación de servicio De denegación de servicio (DoS) son aquellos en los que un atacante intento de interrumpir o impedir el uso de un servicio por su legítimo usuarios. Tomando los dispositivos de red fuera de servicio, la modificación de su configuración, o ellos abrumadora de las solicitudes de servicio se varias de las posibles vías de ataque DoS. Abrumadora la red con peticiones de servicio, de lo contrario conocida como un "agotamiento de recursos" ataque DoS, puede dirigirse a cualquier recurso en la red, por ejemplo, el ancho de banda de enlace, la capacidad de reenvío de paquetes, sesión capacidad para varios protocolos, potencia de CPU, tamaño de la tabla, almacenamiento desborda, y así sucesivamente… ataques de denegación del tipo de agotamiento de los recursos se pueden montar en contra el plano de datos de un proveedor o usuario final particular, al tratar de inserte (spoofing) una cantidad abrumadora de datos no auténtico en el proveedor o red del usuario final desde fuera de la zona de confianza. Los resultados podrían ser posibles para agotar el ancho de banda disponible a ese proveedor o usuario final, o abrumar al criptográfica mecanismos de autenticación del usuario del proveedor o al final. Los datos de plano ataques de agotamiento de recursos también se pueden montar por abrumador general del proveedor de servicios (MPLS / GMPLS-independiente) infraestructura con el tráfico. Estos ataques contra el general, infraestructura no suelen ser un problema MPLS / GMPLS-específica, a menos el ataque se monta por otro usuario de la red MPLS / GMPLS de una posición privilegiada. (Por ejemplo, un usuario de MPLS / GMPLS red podría ser capaz de monopolizar los recursos de plano de datos de la red y por lo tanto alterar otros usuarios.) Muchos ataques de denegación de amplificación de uso, por lo que el atacante incorpora a la misma de lo contrario partes inocentes para aumentar el efecto del ataque. los atacantes pueden, por ejemplo, enviar paquetes a una emisión o multidifusión tratar con la dirección de origen falsificada de la víctima, y todos los los receptores pueden entonces responder a la víctima. 4.2.7 .misconnection

-D13- SAM/IG/17-NE/13

Mala conexión puede surgir a través de ataque deliberado, o por medio de mala configuración o mala conexión de los recursos de la red. los resultados es probable que sea la entrega de datos a un destino equivocado o negro-formación de vacíos de los datos. En GMPLS con físicamente diversos planos de control y de datos, puede ser posible fallo en la conexión de datos de plano no fuera detectada por el control avión. En las redes ópticas bajo control GMPLS, mala conexión puede dar lugar a riesgos de seguridad físicos como el láser no protegidas pueden ser activados sin previo aviso. 4.3 .Los ataques a la operación y el plano de gestión Ataques a la Operación y el plano de gestión se han discutido extensivamente como cuestiones generales de seguridad de red en los últimos 20 años. RFC 4778 [ RFC4778 ] puede servir como el mejor funcionamiento actual prácticas de seguridad en entornos de proveedores de servicios de Internet. RFC 4377 [ RFC4377 ] proporciona Operaciones y Gestión de Requisitos Redes MPLS. Ver también las consideraciones de seguridad de la RFC 4377 y la Sección 7 del RFC 4378 [ RFC4378 ]. Funcionamiento y gestión a través de la MPLS-ICI también podrían ser la fuente de amenazas a la seguridad en la infraestructura de proveedor, así como el servicio ofrecido por el MPLS-ICI. Un gran volumen de operación y mensajes de gestión podrían desbordar la capacidad de procesamiento de una Asbr si el ASBR no está adecuadamente protegida. maliciosamente generada observar el tráfico para analizar los patrones de uso y mapa de una red configuración; Un atacante también podría obtener acceso a los sistemas y manipular los datos de configuración o enviar comandos maliciosos. Por lo tanto, además de la autenticación del usuario humano, más… Se necesita la seguridad sofisticado protocolo para la operación y Las interfaces de administración, especialmente cuando se configuran durante Pilas TCP / IP. Finalmente, basándose en un perímetro de defensa, tales como cortafuegos, es insuficiente la protección contra los ataques internos "o" contra las penetraciones que comprometen un sistema dentro del servidor de seguridad como una plataforma de lanzamiento para atacar a los elementos de red. El ataque interno es se discute en la siguiente sesión. 4.4 . Consideraciones de los ataques internos La cadena de modelo de confianza significa que las redes MPLS y GMPLS son especialmente vulnerables a los ataques internos. Estos pueden ser lanzados por cualquier persona maligna con acceso a cualquier LSR en el dominio de confianza. …los ataques internos también podrían ser lanzados por el software comprometida entro el dominio de confianza. Este tipo de ataques podrían, por ejemplo, no hacer publicidad recursos existentes, modificar los anuncios de otros routers, solicitud LSP no deseadas que utilizan recursos de la red, o niegan o modifican LSP peticiones legítimas.

SAM/IG/17-NE/13 -D14-

La protección contra los ataques internos es en gran parte para futuros estudios en MPLS y GMPLS redes. Algunos de protección se puede obtener proporcionar seguridad estricta para actualizaciones de software y acceso OAM apretado procedimientos de control. La protección adicional puede conseguirse por estricta el control de usuario (es decir, el operador) el acceso a LSRs. cambio de software gestión y seguimiento de cambios (por ejemplo, las diferenciaciones de CVS basado en texto archivos de configuración) ayuda en la detección de irregularidades y humana errores. En algunos casos, los procesos de aprobación de cambio de configuración puede.. También se justifica. Las herramientas de software podrían utilizarse para comprobar configuraciones para la coherencia y el cumplimiento. Las herramientas de software puede también puede usarse para monitorear y reportar el comportamiento y la actividad de la red en con el fin de detectar rápidamente cualquier irregularidad que puede ser el resultado de una ataque interno. 5 . Las técnicas defensivas para MPLS / GMPLS Redes Las técnicas defensivas describen en este documento están destinadas a describir los métodos por los cuales algunas amenazas de seguridad pueden ser abordados. No están destinados como requisitos para todos MPLS / GMPLS implementaciones. El proveedor de MPLS / GMPLS debe determinar la aplicabilidad de estas técnicas para servicio específico del proveedor ofrendas, y el usuario final puede desear para evaluar el valor de éstos técnicas a los requisitos de servicio del usuario. el operativo ambiente determina los requisitos de seguridad. Por lo tanto, protocolo diseñadores necesitan para proporcionar un conjunto completo de servicios de seguridad, que se puede utilizar en su caso. Las técnicas descritas aquí incluyen el cifrado, autenticación, filtrado, servidores de seguridad, control de acceso, el aislamiento, la agregación, y otros. A menudo, la seguridad se consigue mediante el diseño del protocolo cuidado, en lugar de mediante la adición de un método de seguridad. Por ejemplo, un procedimiento de mitigar ataques de denegación de servicio es para asegurarse de que las partes inocentes no pueden ser utilizados para amplificar el ataque. Security funciona mejor cuando se está "diseñado en" en lugar de "agregado en". Nada es 100% segura. por lo tanto, implica la protección de Defensa en contra de los ataques de que son más probable que ocurra o que tienen la mayoría de las consecuencias directas en caso de éxito. Para aquellos ataques que son protegidos contra, la protección absoluta es rara vez alcanzable; Más a menudo es suficiente sólo para hacer que el costo de un ataque exitoso mayor que lo que el adversario esté dispuesto o capaz de gastar. Con éxito la defensa contra un ataque no significa necesariamente el ataque se debe evitar que ocurra o llegue a su objetivo. En muchos casos, la red en lugar puede ser diseñado para resistir el ataque. Por ejemplo, la introducción de inauthentic paquetes podían defenderse contra al impedir su introducción en el primer lugar, o por lo que es posible identificar y eliminar antes de la entrega al sistema de la / GMPLS del usuario MPLS. Este último es con frecuencia una tarea mucho más fácil.

-D15- SAM/IG/17-NE/13

5.1 .Autenticación Para evitar problemas de seguridad derivados de algunos ataques de denegación de servicio o desde malicioso o mala configuración accidental, es crítico que los dispositivos en el MPLS / GMPLS sólo debe aceptar conexiones o mensajes de control a partir de fuentes válidos. Autenticación se refiere a métodos para garantizar que fuentes de mensajes están correctamente identificados por los dispositivos MPLS / GMPLS con la que se comunican. Esta sección se centra en la identificación de los escenarios en los que se requiere la autenticación del remitente y recomienda mecanismos de autenticación para estos escenarios. Las técnicas criptográficas (autenticación, integridad y cifrado) no protegen contra algunos tipos de ataques de denegación de servicio, específicamente recursos ataques de agotamiento sobre la base de CPU o ancho de banda agotamiento. De hecho, el procesamiento criptográfico basado en software necesaria para descifrar o verificar la autenticación puede, en algunos casos aumentar el efecto de estos ataques de agotamiento de recursos. Con un hardware del acelerador criptográfico, paquetes de ataque pueden ser dejados en velocidad de la línea sin costo alguno para los ciclos de software. Criptográfico técnicas pueden, sin embargo, ser útiles contra el agotamiento de recursos los ataques basados en el agotamiento de la información de estado (por ejemplo, TCP SYN ataques). El plano de datos MPLS, tal como se define actualmente, no es susceptible de fuente la autenticación, ya que no existen identificadores de origen en el paquete de MPLS para autenticar. La etiqueta MPLS es sólo a nivel local significativa. Puede ser asignado por un nodo intermedio o un nodo aguas arriba de multidifusión apoyo. Cuando la carga útil MPLS lleva identificadores que pueden ser autenticados (Por ejemplo, paquetes IP), la autenticación puede llevarse a cabo en el cliente nivel, pero esto no ayuda a la SP MPLS, ya que estos clientes identificadores pertenecen a una red externa, no es de confianza. 5.1.1 .Autentificación del sistema de gestión autentificación del sistema de gestión incluye la autenticación de un PE a una gestión de la red de gestión centralizada o un servidor de directorio cuando se utiliza a base de directorio "detección automática". También incluye autenticación de una CE para el servidor de configuración, cuando una se utiliza el sistema servidor de configuración. Autenticación debe ser bidireccional, incluyendo PE o CE a la autenticación del servidor de configuración para el PE o CE para tener la certeza de que se está comunicando con el servidor correcto. 5.1.2 . Peer-to-Peer autenticación Peer-to-peer de autenticación incluye la autenticación del mismo para la red protocolos de control (por ejemplo, LDP, BGP, etc.) y otros

SAM/IG/17-NE/13 -D16-

pares autenticación (es decir, la autenticación de una pasarela de seguridad IPsec otro). Autenticación debe ser bidireccional, incluyendo PE o CE a la autenticación del servidor de configuración para el PE o CE para tener la certeza de que se está comunicando con el servidor correcto. Como se indica en la Sección 5.1.1 , la autenticación debe ser bidireccional. 5.2.4 . Consideraciones de seguridad para MPLS Pseudowires Además del tráfico IP, redes MPLS se pueden utilizar para transportar otros servicios, tales como Ethernet, ATM, Frame Relay y TDM. Esto es hecho mediante la creación de pseudowires (PWS) que el servicio de túnel nativa a través del núcleo MPLS mediante la encapsulación en los bordes. el PWE arquitectura se define en [ RFC3985 ]. PW túneles pueden establecerse utilizando el protocolo de control basado en PWE PLD [ RFC4447 ], y por lo tanto las consideraciones de seguridad para el PLD lo más probable ser aplicable al protocolo de control de PWE3 también. paquetes de usuario PW contienen al menos una etiqueta MPLS (la etiqueta PW) puede contener una o más etiquetas de túnel MPLS. Después de la pila de etiquetas, hay una palabra de control de cuatro bytes (que es opcional para algunos PW tipos), seguido de la carga útil de servicio nativo. Hay que subrayar que la encapsulación de paquetes MPLS PW en IP con el propósito de que permite el uso de mecanismos de IPsec no es una opción válida. La siguiente es una lista no exhaustiva de las amenazas PW-específicos: - Configuración no autorizada de un PW (por ejemplo, para acceder a un cliente red) - Desmontaje no autorizado de una PW (causando así denegación de servicio) - El redireccionamiento malicioso de un PW - La observación no autorizada de paquetes PW - El análisis de tráfico de la conectividad PW - La inserción no autorizada de paquetes PW - La modificación no autorizada de los paquetes PW - Supresión no autorizada de PW paquetes repetición de paquetes PW - Denegación de servicio o un impacto significativo en la calidad del servicio PW Estas amenazas no son excluyentes entre sí, por ejemplo, cambios de itinerario puede ser utilizado para espionaje o inserción / deleción / reproducción, etc. multisegmento PWS introducir debilidades adicionales en sus puntos de costura. El plano de usuario PW sufre de la siguiente seguridad inherente debilidades: - Desde la etiqueta PW es el único identificador en el paquete, hay ninguna dirección de origen autentificable. - Desde adivinar una etiqueta PW válido no es difícil, es relativamente fácil de introducir paquetes extranjeros aparentemente válidas.

-D17- SAM/IG/17-NE/13

- Dado que el paquete PW no es auto-descripción, modificación menor de los paquetes de control de plano rinde el tráfico de plano de datos inútiles. 5.3 .Las técnicas de control de acceso técnicas de control de acceso incluyen paquete por paquete o paquetes-Flow control de acceso por paquetes de flujo por medio de filtros y cortafuegos en IPv4 / IPv6 paquetes, así como por medio de la admisión de una "sesión" para una de control, de señalización, o protocolo de gestión. Ejecución de acceso control por parte de las direcciones de infraestructura aisladas se discute en la Sección 5.4 de este documento. En este documento, se distingue entre el filtrado y cortafuegos basado principalmente en la dirección del flujo de tráfico. Definimos filtrando como aplicable al tráfico unidireccional, mientras que un servidor de seguridad puede analizar y controlar ambos lados de una conversación. La definición tiene dos corolarios importantes: - La simetría de enrutamiento o el tráfico de flujo: Un servidor de seguridad requiere típicamente simetría de enrutamiento, que generalmente se aplica mediante la localización de un servidor de seguridad donde la topología de la red asegura que ambos lados de una conversación pasarán a través del firewall. Un filtro puede operar sobre el tráfico que fluye en una sola dirección, sin tener en cuenta el tráfico en la dirección inversa. Tenga en cuenta que este concepto podría resultar en un único punto de fallo. - Statefulness: Debido a que recibe los dos lados de una conversación, una servidor de seguridad puede ser capaz de interpretar una cantidad significativa de información sobre el estado de la conversación y el uso de este la información de control de acceso. Un filtro puede mantener algún limitada información de estado en un flujo unidireccional de paquetes, pero no puede determinar el estado de la conversación bidireccional con la mayor precisión como un servidor de seguridad. Para una descripción general sobre el filtrado y la limitación de velocidad para IP redes, por favor ver también [ OPSEC-FILTER ]. 5.3.1 .Filtración Es relativamente común entre los routers para filtrar los paquetes. Es decir, enrutadores pueden buscar valores particulares de determinados sectores de la IP o De mayor nivel de cabeceras (UDP por ejemplo, TCP o). Los paquetes que concuerden con los criterios asociados con un filtro particular puede o bien ser desechados o recibir un tratamiento especial. Hoy en día, no sólo los routers, pero la mayoría final anfitriones tienen filtros, y cada instancia de IPsec es también un filtro [ RFC4301 ]. En la discusión de los filtros, es útil para separar el filtro características que pueden ser utilizados para determinar si un paquete coincide con un filtro de las acciones de paquetes aplicados a aquellos paquetes búsqueda de un filtro particular. Características o Filtrar características o reglas de filtrado se utilizan para determinar si una particular, paquete o conjunto de paquetes coincide con un filtro especial.

SAM/IG/17-NE/13 -D18-

En muchos casos, las características del filtro pueden ser sin estado. Un sin estado filtro determina si un paquete particular coincide con un filtro basado únicamente en la definición del filtro, la información normal de reenvío (tales como el siguiente salto para un paquete), la interfaz en la que un paquete llegado, y el contenido de ese paquete individual. Típicamente, filtros apátridas pueden considerar la entrada y salida lógica o interfaz física, la información de la cabecera IP y la información en cabeceras de las capas superiores, tales como el TCP o UDP cabecera. La información contenida en la cabecera IP que se considera pueden incluir por ejemplo la fuente y direcciones IP de destino; campo de protocolo, Desplazamiento del fragmento, y TOS campo en IPv4; o de cabecera siguiente, Cabeceras de Extensión, las etiquetas de flujos, etc. IPv6. Los filtros también se pueden considerar los campos en la cabecera TCP o UDP, tales como los números de puerto, el campo SYN en la cabecera TCP, así como ICMP y el tipo de ICMPv6. 5.3.2 . Los cortafuegos Firewalls proporcionan un mecanismo para controlar el tráfico que pasa entre diferentes zonas de confianza en el modelo MPLS / GMPLS o entre una gran zona y una zona insegura. Los cortafuegos suelen ofrecer mucha más funcionalidad que los filtros, ya que pueden ser capaces de aplicar análisis detallado y funciones lógicas a los flujos, y no sólo a paquetes individuales. Ellos pueden ofrecer una variedad de servicios complejos, como protección contra ataques DoS umbral impulsada, detección de virus, actuando como un proxy de conexión TCP, etc. Al igual que con otras técnicas de control de acceso, el valor de cortafuegos depende de una comprensión clara de las topologías de la MPLS / GMPLS red principal, las redes de usuarios, y el modelo de amenaza. Su eficacia depende de una topología con un claramente definido dentro de (Seguro) y fuera (no seguro). Los cortafuegos pueden aplicarse para ayudar a proteger la red central MPLS / GMPLS funciones de los ataques procedentes de Internet o desde MPLS / GMPLS sitios de los usuarios, pero por lo general otras técnicas de seguridad vial ser utilizado para este propósito. Cuando se emplean los servidores de seguridad como un servicio VPN para proteger los sitios de los usuarios desde Internet, diferentes usuarios de VPN, e incluso los diferentes sitios de un solo usuario de VPN, puede tener diferentes requisitos de firewall. El general PPVPN topología lógica y física, junto con las capacidades de los dispositivos de aplicación de los servicios de cortafuegos, tiene un significativo efecto sobre la viabilidad y capacidad de gestión de tan variada cortafuegos ofertas de servicios. Otra consideración con el uso de cortafuegos es que pueden ofrecer algunas opciones para el manejo de paquetes que transportan datos cifrados. Debido a que los datos en sí no son accesibles, solamente cabecera del paquete información, otros campos no cifrados, o el análisis del flujo de paquetes cifrados se pueden utilizar para la toma de decisiones sobre la aceptación o rechazando el tráfico cifrado.

-D19- SAM/IG/17-NE/13

Dos enfoques del uso de servidores de seguridad son para mover el servidor de seguridad fuera de la parte cifrada de la ruta o para registrar y pre-aprobar la sesión cifrada con el servidor de seguridad. Manejo de los ataques DoS se ha vuelto cada vez más importante. Útil se incluyen las siguientes: 1. Realizar el filtrado de entrada en todas partes. 2. Ser capaz de filtrar los paquetes de ataque de denegación de servicio a velocidad de línea. 3. No permita que uno mismo para amplificar los ataques. 4. Continuar procesar el tráfico legítimo. Durante prever pesada cargas. Utilizar diversos lugares, tecnologías, etc. 5.3.3 . Control de acceso a las interfaces de gestión La mayor parte de los problemas de seguridad relacionados con las interfaces de administración puede haber abordado mediante el uso de técnicas de autenticación como se describe en el apartado de autenticación ( Sección 5.1 ). Sin embargo, adicional la seguridad se puede proporcionar mediante el control de acceso a la gestión las interfaces de otras maneras. 5.8 . Verificación de la Conectividad Con el fin de proteger contra el fallo en la conexión deliberada o accidental, mecanismos se pueden poner en marcha para verificar tanto la conectividad de extremo a extremo y los recursos hop-by-hop. Estos mecanismos pueden rastrear las rutas de LSP, tanto en el plano de control y el plano de datos. Debe tenerse en cuenta que, si hay un ataque en el plano de control, mecanismos de prueba de conectividad del plano de datos que se basan en el control avión también puede ser atacado. Esto puede ocultar fallos a través de falsa positivos o interrumpen los servicios que funcionan a través de falsos negativos. 6 . Monitorización, detección y generación de informes de ataques a la seguridad MPLS / GMPLS red y el servicio pueden estar sujetos a los ataques de una variedad de amenazas a la seguridad. Muchas amenazas se describen en la sección 4 de este documento. Muchas de las técnicas defensivas se describen en esta documento y en otras partes proporcionan niveles significativos de protección de una variedad de amenazas. Sin embargo, además de emplear defensiva técnicas de silencio para proteger contra ataques, MPLS / GMPLS servicios También puede agregar valor para los proveedores y clientes mediante la implementación de Los sistemas de monitoreo de seguridad para detectar e informar sobre cualquier valor ataques, independientemente de si los ataques son eficaces. Los atacantes comienzan a menudo mediante el sondeo y análisis de las defensas, por lo que los sistemas que puede detectar e informar adecuadamente estas primeras etapas de ataques puede proporcionar beneficios significativos.

SAM/IG/17-NE/13 -D20-

La información relativa a los incidentes de ataque, especialmente si está disponible rápidamente, puede ser útil en la defensa contra los ataques posteriores. Puede ser utilizado para ayudar a identificar los atacantes o sus objetivos específicos en una etapa temprana. Este conocimiento sobre los atacantes y los objetivos se puede utilizar para fortalecer las defensas contra ataques o atacantes específicos, o a mejorar las defensas para objetivos específicos en función de las necesidades. La información recogida en los ataques también puede ser útil en la identificación de y el desarrollo de defensas contra nuevos tipos de ataques. Los sistemas de seguimiento utilizados para detectar ataques a la seguridad en MPLS / GMPLS habitualmente funcionan mediante la recopilación de información desde el borde de proveedor (PE), Borde del Cliente (CE), y / o proveedor de red troncal (P) dispositivos. sistemas de monitoreo de seguridad deben tener la capacidad de activamente recuperar información de dispositivos (por ejemplo, SNMP GET) o pasivamente recibir informes de dispositivos (por ejemplo, notificaciones SNMP). los sistemas pueden recuperar activamente información de dispositivos (por ejemplo, SNMP GET) o pasivamente recibir informes de dispositivos (por ejemplo, notificaciones SNMP). 7 . Proveedor de servicios Requisitos Generales de Seguridad Esta sección cubre los requisitos de seguridad pueda tener el proveedor de asegurar su infraestructura de red MPLS / GMPLS incluyendo PLD y requisitos RSVP-TE-específicas. requisitos del proveedor de servicios MPLS / GMPLS definidos aquí son para el núcleo MPLS / GMPLS en el modelo de referencia. La red núcleo puede ser implementado con diferentes tipos de tecnologías de red, y cada núcleo de red puede utilizar diferentes tecnologías para proporcionar los diversos servicios a los usuarios con diferentes niveles de seguridad que ofrece. Por lo tanto, un proveedor / servicio MPLS GMPLS puede cumplir con cualquier número de los requisitos de seguridad enumerados en esta sección. En este documento se hace no indica que una red MPLS / GMPLS debe cumplir con todos estos requisitos para ser seguro. Estos requisitos se centran en: 1) la forma de proteger a los MPLS / GMPLS núcleo de varios ataques procedentes del exterior del núcleo que incluye los de usuarios de la red, tanto accidentalmente y maliciosamente, y 2) cómo proteger a los usuarios finales. 7.1 .Protección dentro de la Red Central 7.1.1 . Control-Plane Protección - general - Filtrado de direcciones IP falsa de infraestructura en los bordes Muchos ataques a los protocolos que se ejecutan en un núcleo implican la suplantación de una fuente dirección IP de un nodo en el núcleo (por ejemplo, ataques TCP-RST). Hace sentido aplicar anti-spoofing filtrado

-D21- SAM/IG/17-NE/13

en los bordes, por ejemplo, mediante un estricto unicast revertir path forwarding (uRPF) [ RFC3704 ] y / o mediante la prevención 7.2.3 . QoS de acceso MPLS / GMPLS proveedores que ofrecen servicios habilitados para QoS requieren mecanismos para asegurar que los accesos individuales se validan con su perfil QoS suscrito y, como tal, a tener acceso a los recursos básicos que coincida con su perfil de servicio. Mecanismos como por la clase de servicio la limitación de velocidad o de formación de tráfico en la entrada al núcleo MPLS / GMPLS son dos opciones para proporcionar este nivel de control. Tales mecanismos puede requerir el perfil por clase de servicio que debe ser ejecutada por cualquiera marcado, comentando, o desechar de tráfico fuera del perfil. 7.2.4 . Herramientas de supervisión de Servicio al Cliente Los usuarios finales necesitan estadísticas específicas sobre el núcleo, por ejemplo, enrutamiento de mesa, estado de la interfaz, o QoS estadísticas, establecer requisitos sobre mecanismos en el PE tanto para validar el usuario entrante y limitan la vista disponible para ese usuario en particular. Mecanismos también deben estar en cuenta para asegurar que dicho acceso no puede ser utilizado como medio para construir un ataque DoS (ya sea accidental o maliciosamente) en el PE sí mismo. Esto podría lograrse ya sea a través de la separación de estos recursos dentro del propio PE oa través de la capacidad para clasificar limitante, que se realiza sobre la base de cada interfaz física o cada conexión lógica. 7.3 .Requisitos Generales del Usuario para MPLS / GMPLS Proveedores proveedores de MPLS / GMPLS deben cumplir los requisitos de seguridad de los usuarios finales. Dependiendo de las tecnologías que se utilizan, estos requisitos pueden incluir: - Separación del plano de control de usuario a través del aislamiento de enrutamiento cuando aplicable, por ejemplo, en el caso de MPLS VPNs. - Protección contra la intrusión, ataques de denegación de servicio, y la suplantación de identidad - Autenticación de Acceso - Técnicas de relieve a lo largo de este documento que identifique metodologías para la protección de los recursos y el MPLS / GMPLS infraestructura. Hardware o software errores en el equipo que lleva a las infracciones en de seguridad no están dentro del alcance de este documento. 8 . Requisitos de seguridad entre proveedores Esta sección analiza las capacidades de seguridad que son importantes en el el MPLS / GMPLS conexiones entre proveedores y en los dispositivos (incluyendo routers ASBR) que apoyan estas conexiones. La seguridad en el modo de túnel o de transporte con la autenticación, pero con NULL encriptación, entre los ASBRs igualitarios. IPsec, si es compatible, debe ser apoyado con HMAC-SHA-1 y, alternativamente, con HMAC-SHA-2 y opcionalmente SHA-1. Se espera que los algoritmos de

SAM/IG/17-NE/13 -D22-

autenticación se evolucionar con el tiempo y el apoyo se pueden actualizar según sea necesario. operaciones de OAM de MPLS a través de la-ICI también podrían ser la fuente de amenazas a la seguridad en la infraestructura de proveedor, así como la servicio ofrecido por el MPLS-ICI. Un gran volumen de mensajes OAM podría desbordar la capacidad de procesamiento de un ASBR si el ASBR es no está debidamente protegido. mensajes OAM generados maliciosamente podría también puede usarse para derribar a un servicio de otro modo saludable (por ejemplo, MPLS Pseudowire), y por lo tanto afectan a la seguridad del servicio. LSP de ping hace no soporta la autenticación de hoy, y que el apoyo debe ser una sujetos para su futura consideración. Detección de Reenvío Bidireccional (BFD), sin embargo, tiene apoyo para la realización de una autenticación objeto. También es compatible con el procesamiento de Time-To-Live (TTL) como una anti medida de repetición. Conforme implementaciones con este MPLS-ICI debe BFD soporte de autenticación y debe ser compatible con los procedimientos para la TTL tratamiento. 9.1 . MPLS y GMPLS amenazas a la seguridad específica 9.1.1 . Los ataques del plano de control Tipos de ataques en el plano de control: - Creación LSP no autorizada - La interceptación de mensajes LSP Los ataques contra RSVP-TE: los ataques de denegación que se instalan LSP no autorizada mensajes y / o LSP. Los ataques contra PLD: ataque DoS con tormentas de mensajes hola o LDP mensajes TCP SYN. Los ataques pueden ser lanzados desde fuentes externas o internas, o por medio de sistemas de gestión de un SP. Los ataques pueden estar dirigidas a los protocolos de enrutamiento del propietario único o elementos de infraestructura. En general, los protocolos de control pueden ser atacados por: - MPLS señalización (LDP, RSVP-TE) - Señalización PCE - Señalización de IPsec (IKE y IKEv2) - ICMP y ICMPv6 - L2TP - El descubrimiento de miembros a base de BGP - Descubrimiento de miembros basados en bases de datos (por ejemplo, RADIUS)

-D23- SAM/IG/17-NE/13

- OAM y de diagnóstico, tales como protocolos de ping LSP y LMP - Otros protocolos que pueden ser importantes para el control infraestructura, por ejemplo, DNS, LMP, NTP, SNMP y GRE 9.1.2 . Los ataques de datos-Plane - La observación no autorizada de tráfico de datos - Modificación de datos de tráfico - Suplantación de identidad y reproducción - Supresión no autorizada - El análisis del tráfico de patrón no autorizada - Negación de servicio 9.2 .Las técnicas de defensa 1) Autenticación: - Autentificación bidireccional - La gestión de claves - Autentificación del sistema de gestión - Peer-to-peer de autenticación 2) Las técnicas criptográficas 3) El uso de IPsec en redes MPLS / GMPLS 4) Cifrado para la configuración y gestión de dispositivos 5) Las técnicas criptográficas para pseudowires MPLS 6) End-to-End frente Hop-by-Hop protección (CE-CE, PE-PE, PE-CE) 7) Las técnicas de control de acceso - Filtrado - Los cortafuegos - Control de acceso a las interfaces de administración 8) el aislamiento de Infraestructura 9) El uso de la infraestructura agregada 10) Los procesos de control de calidad 11) MPLS comprobables / servicio GMPLS 12) Verificación de la conectividad de extremo a extremo 13) Verificación de la configuración de recursos Hop-by-hop y el descubrimiento 9.3.2 . Seguridad Inter-Proveedor

SAM/IG/17-NE/13 -D24-

conexiones entre proveedores son zonas de alto riesgo de seguridad. Similar técnicas y procedimientos como se describe para el núcleo general del SP la protección se enumeran a continuación para las conexiones inter-proveedor. 1) la protección del plano de control en las conexiones entre proveedores - Autenticación de sesiones de señalización - Protección contra ataques DoS en el plano de control - Protección contra paquetes mal formados - Posibilidad de activar / desactivar los protocolos específicos - Protección contra la conexión cruzada incorrecta - Protección contra cambios falsificados y los anuncios de rutas - Protección de la información confidencial - Protección frente a un número sobre-aprovisionado de RSVP-TE LSP y la reserva de ancho de banda 2) La protección de datos a bordo en las conexiones entre proveedores - Protección contra DoS en el plano de datos - Protección contra la suplantación de la etiqueta Para interconexiones VPN MPLS [ RFC4364 ], en la práctica, inter-AS opción a), VRF-a-VRF conexiones en la frontera AS (Sistema Autónomo), es comúnmente utilizado para las conexiones inter-proveedor. La opción c), Multi-hop EBGP redistribución de rutas VPN-IPv4 marcadas entre la fuente y Sistemas autónomos de destino con la redistribución de rutas IPv4 EBGP etiquetadas de AS a un AS vecino, por otra parte, no se utiliza normalmente para conexiones entre proveedores debido a los riesgos de seguridad más altos. Para más detalles, véase [ RFC4111 ]. 10 . Consideraciones de Seguridad Las consideraciones de seguridad constituyen el único objeto de esta nota y por lo tanto, se discuten a lo largo. Aquí recapitular lo que ha sido presentado y explicar a un alto nivel la función de cada tipo de la consideración de un sistema de MPLS / GMPLS seguro general. El documento describe una serie de posibles amenazas a la seguridad. Algunos de estas amenazas ya han sido observados se producen en el funcionamiento redes; otros son en gran medida hipotética en este momento. DoS ataques y ataques de intrusión de Internet en contra de un SPS infraestructura se han visto. DoS "ataques" (por lo general no malicioso) también se han visto en el que el equipo CE abruma PE equipos con altas cantidades o tipos de tráfico de paquetes o encaminamiento información. los errores de manejo o de aprovisionamiento son citados por MSF como una de sus principales preocupaciones.

-D25- SAM/IG/17-NE/13

El documento describe una variedad de técnicas de defensa que pueden estar utilizado para contrarrestar las amenazas sospechosas. Todas las técnicas presentan implican tecnologías maduras y ampliamente implementadas que son práctico de implementar. El documento describe la importancia de la detección, monitoreo y ataques de informes, tanto con y sin éxito. Estas actividades son esenciales para "comprender al enemigo", la movilización nuevas defensas, y la obtención de métricas sobre cómo asegurar el MPLS / GMPLS red es. Como tales, son componentes vitales de cualquier PPVPN completa sistema de seguridad. El documento evalúa los requisitos de seguridad MPLS / GMPLS de una la perspectiva del cliente, así como de un proveedor de servicios de perspectiva. Estas secciones volver a evaluar las amenazas identificadas a partir de las perspectivas de las distintas partes interesadas y tienen por objeto ayudar proveedores de equipos y proveedores de servicios, que deben decidir en última instancia ¿Qué amenazas para proteger contra en cualquier configuración o servicio determinado ofrecimiento?

SAM/IG/17-NE/13

APÉNDICE E

Sobre MPLS

SLA de Level (3)

SAM/IG/

17-NE/13 -EE2-

-EE3- SSAM/IG/17-NNE/13

SAM/IG/

La atenc“Calidad

En la actupara ofreccomercialen IP/ATM

La duda EntendienMPLS es

Se hace imque no exsu reto, co

LA SEGU Sin lugar será útil p

Servicios

17-NE/13

ción por parde Servicio”

ualidad, MPLcer servicios l. De esta maM hacía una b

de los clientendo que es uninsegura o se

mportante conxiste ninguna omo el del res

URIDAD EN

a dudas, es ipara entender

para la segur

rte de los op (QoS).

LS constituyede Red Priv

anera, progresbackbone IP/M

es, es la faltana tecnología egura, o sólo s

nocer qué es tecnología qu

sto de tecnolo

NUESTRAS

mportante qumejor las am

ridad

-E

SeguridadINTR

peradores se

e un escalón ada Virtual (sivamente hanMPLS.

a de confianzque trabaja ase trata de mi

la seguridad ue sea perfectogías, es inten

S REDES

ue nosotros, loenazas y cont

E4-

d referida a MRODUCCIÓN

focaliza en

fundamental(RPV - VPN)n ido substitu

za en una tea este nivel nuedo al cambio

y las grandesta, segura. In

ntar tapar los a

os usuarios ntramedidas

MPLS N

poder ofrece

l para una m) y para el truyendo sus an

cnología queunca puede seo.

s amenazas qncluso ATM tagujeros que

nos preocupem

er servicios a

mejor escalabiransporte delntiguas redes

e trabaja en eer segura. De

que existen hotiene problemdeja su diseñ

mos por la se

adecuándolos

lidad y eficiel tráfico telefs centrales ba

el nivel 3 deallí la discus

oy en día y amas de seguridño.

eguridad. Tam

s a la

encia; fónico asadas

e OSI. sión si

asumir dad, y

mbién,

Para preseintentar as El uso deautenticar Firewall

La aplicahardware

Un firewacontrol, seadministra Existen cumultinivelinspeccióncapa OSI

ervar la segusegurar la inf

e palabras clar y asegurar la

s

ación más utily software qu

all es un mee revisan los ador de la red

uatro tipos dl de estados yn multinivel en el que trab

uridad de las formación o e

ave, a través das comunicac

lizada en los úue utilizan las

Fig.

ero control dedatagramas o

d, actuará en c

de firewalls: dy Circuit Level mejor con

bajan

-E

comunicacionl acceso legal

de claves púbiones.

últimos años es empresas y

. 1.1 Red adm

e acceso del o paquetes quconsecuencia

de filtrado devel Gateways.nsiderado. La

E5-

nes y de las rl.

blicas y priva

es el conocidlos usuarios p

ministrativa co

tráfico entraue por él pas: eliminando,

e paquetes, p. Los dos prigran diferen

redes privada

adas, es tamb

do firewall (copara aislar la r

on cortafuego

ante/saliente san y según l reenviado o

pasarelas de nimeros son lo

ncia que exist

S

as, existen di

bién de uso h

ortafuegos), cred privada d

os

de la red delas reglas quepreguntando

nivel de aplicos más utilizate entre ellos

SAM/IG/17-N

stintas maner

habitual para p

ombinación ddel exterior.

l usuario. Ene haya impueal administra

cación, inspeados, pero es s, es el nivel

SAM/IG/17-NE/13

APÉNDICE F

Recomendaciones para proyectar la evaluación de la realización de una auditoría de la REDDIG II a fin de determinar factores de riesgos para la seguridad

1 Conexiones contra redes externas

1.1 Respecto de este tema, se analizarán cuántos y cuáles son los puntos de contacto con redes externas a la red ATN.

1.2 De esta forma, y habiendo determinado cuales son los dispositivos de frontera con redes externas, se deberá evaluar cuales son los riesgos potenciales que conlleva cada uno de ellos, y cuáles serán las políticas de seguridad que habrá que implementar para reducirlos o eliminarlos.

2 Políticas de ruteo

2.1 A nivel de WAN se deberá analizar cuáles son los protocolos de ruteo implementados en

función de la topología de red, y se verificará si hay convergencia de los mismos cuando todos los enlaces funcionan normalmente, como así también la forma en que se comportan en el momento en que alguno de los citados vínculos queda fuera de servicio.

3 Tareas de backup

3.1 A nivel general, se identificarán cuáles son las políticas de backup implementadas para resguardar los archivos de configuración de los dispositivos que conforman la red, como así también de los sistemas operativos de los mismos.

3.2 De verificarse que no exista backup, se realizará una copia de respaldo de cada una de las configuraciones de cada dispositivo de la red (routers, switches, access points y demás dispositivos de networking) y de cada uno de las versiones de IOS (Sistema operativo de los dispositivos de networking).

3.3 Para resguardar esta información, se implementará un servidor TFTP (Trivial File Transfer Protocol), accesible para todos los dispositivos de la red, ya sea para salvar configuraciones como así también para tomarlas si fuera necesario volver a instalar un sistema operativo o restaurar la configuración de alguno de los dispositivos.

4 Accesos (locales y remotos) a los dispositivos de red

4.1 Al respecto se comprobará cuantos usuarios de acceso remoto y local hay configurados en cada uno de los dispositivos que integran la red, como así también de que privilegios goza cada uno de ellos.

SAM/IG/17-NE/13 -F2-

4.2 Si no existiera ninguna política al respecto se coordinará la implementación de un determinado grupo de usuarios con diferentes privilegios para cada uno de ellos, de forma tal de limitar y controlar las facilidades de cada uno de los usuarios que gestionarán los dispositivos de networking pertenecientes a la red.

5 Registro de eventos (logs)

5.1 Se comprobará si se ha implementado un servidor de eventos (logs) que funcione como repositorio central en el que se registren todos los eventos de la red. En caso de no haber un servicio de red que registre estos eventos, deberá implementará uno.

5.2 Posteriormente, se deberá realizar un análisis en conjunto con el personal a cargo de la red, para determinar qué tipo de eventos es recomendable tomar registros (ejemplo: accesos a los dispositivos, cambios de estado de las interfaces de red, reinicios en caliente, cambios en los parámetros de configuración, etc).

6 Servicios de red no utilizados

6.1 Con el objeto de mantener al máximo la performance de los dispositivos que integran la red, como así también de preservar la seguridad de la misma, se deberá verificar que los servicios que generalmente no son utilizados, estén deshabilitados. Especialmente aquellos que hacen uso del UDP (User Datagram Protocol), que generalmente es utilizado para propósitos tales como ataques por denegación (DoS) de servicio.

6.2 De esta forma, se verificaran los siguientes servicios: Echo (port number 7). Discard (port number 9). Daytime (port number 13). Chargen (port number 19)

6.3 Asimismo, sino estuvieran siendo utilizados, también se deshabilitarán los siguientes servicios:

Finger. Bootstap Protocol. Maintenance Operation Protocol (MOP). Domain Name System (DNS). Packet Assembler/Disassembler (PAD) para redes X.25. HTTP y HTTPS. Cisco Discovery Protocol (CDP) en aquellos dispositivos de borde o de frontera contra redes externas.

-F3- SAM/IG/17-NE/13

7 Particularidades

7.1 Finalmente, se comprobará en cada uno de los dispositivos de la red los aspectos que a continuación se detallan y que, de no haber sido implementados correctamente, perjudican la seguridad y performance de la red:

7.2 Si se ha habilitado el hash MD5 para las contraseñas de los usuarios locales.

7.3 Cuantos intentos de acceso a los dispositivos de networking son permitidos al introducir erróneamente la contraseña correspondiente.

7.4 Si los dispositivos de networking permiten realizar operaciones que permitan recuperar contraseñas.

7.5 Si el servicio de TCP- Keepalive ha sido habilitado para sesiones de management.

7.6 Verificar si se han implementado listas de acceso, para filtrar accesos indebidos a los dispositivos.

7.7 Si las sesiones de acceso virtual (VTY) a los dispositivos han sido configuradas para que luego de un determinado tiempo de inactividad, se cierren automáticamente.

7.8 Que hayan sido implementado protocolos de transporte encriptados para accesos remotos.

7.9 Que hayan sido deshabilitados los re direccionamientos ICMP.

7.10 Que los protocolos de ruteo hayan sido asegurados.

7.11 Que se hayan implementado políticas de seguridad sobre los FHRP (First Hop Redundancy Protocols) utilizados (ejemplo: GLBP, HSRP, VRRP).

---------------

Organi zación de Aviación Civil Internacional SAM/IG/17-NE/13 … Arg.pdf · 2016-04-29 ·...

Documents

Transcript of Organi zación de Aviación Civil Internacional SAM/IG/17-NE/13 … Arg.pdf · 2016-04-29 ·...