Configuración de interfaces de servicios
Descripción general de nomenclatura de interfaz de servicios
Cada interfaz tiene un nombre de interfaz, el cual especifica el tipo de medio, la ranura en la que se encuentra la FPC, la ubicación en la FPC en la que está instalada la PIC y el puerto PIC. El nombre de interfaz identifica de forma exclusiva a un conector de red individual en el sistema. Utilice el nombre de interfaz al configurar interfaces y cuando habilite varias funciones y propiedades, como protocolos de enrutamiento, en interfaces individuales. El sistema utiliza el nombre de interfaz cuando se muestra información de la interfaz, por ejemplo, en el show interfaces
comando.
El nombre de interfaz se representa mediante una parte física, una parte lógica y una parte de canal con el siguiente formato:
physical<:channel>.logical
La parte de canal del nombre es opcional para todas las interfaces, excepto las interfaces canalizadas DS3, E1, OC12 y STM1.
La parte física de un nombre de interfaz identifica el dispositivo físico, el cual corresponde a un único conector de red físico. Esta parte del nombre de interfaz tiene el siguiente formato:
type-fpc/pic/port
type
es el tipo de medio, el cual identifica el dispositivo de red. En el caso de las interfaces de servicio, puede ser uno de los siguientes:
ams
: interfaz de multiservicios agregados (AMS). Una interfaz AMS es un conjunto de interfaces de servicios que puede funcionar como una sola interfaz. Una interfaz AMS se indicaamsN
como en la configuración,N
donde es un número único que identifica una interfaz AMS (por ejemplo,ams0
). Las interfaces miembro de una interfaz AMS se identifican en la configuración con unmams-
prefijo (por ejemplo,mams-1/2/0
).cp
: interfaz de recopilador de flujo.es
: interfaz de cifrado.gr
— Interfaz de túnel de encapsulación de enrutamiento genérico.gre
: esta interfaz se genera internamente y no se puede configurar.ip
— interfaz de túnel de encapsulación IP sobre IP.ipip
: esta interfaz se genera internamente y no se puede configurar.ls
: interfaz de servicios de vínculo.lsq
: interfaz de cola inteligente (IQ) de servicios de vínculo; también se usa para servicios de voz.mams
: interfaz de miembro en una interfaz AMS.ml
— Interfaz multilink.mo
: interfaz de servicios de supervisión. La interfaz lógicamo-fpc/pic/port
.16383 es una interfaz noconfigurable generada internamente para el tráfico de control del enrutador.ms
: interfaces multiservicios en tarjetas de interfaces modulares (MS-MIC) y concentradores de puertos modulares multiservicios (MS-MPC).mt
— Interfaz de túnel de multidifusión. Esta interfaz se genera de forma automática, pero puede configurar propiedades en ella si es necesario.mtun
: esta interfaz se genera internamente y no se puede configurar.rlsq
— Interfaz LSQ de redundancia.rsp
: interfaz de servicios adaptables con redundancia.si
: interfaz en línea de servicios, configurada únicamente en enrutadores serie MX3D.sp
— Interfaz de servicios adaptable. La interfaz lógicasp-fpc/pic/port
.16383 es una interfaz noconfigurable generada internamente para el tráfico de control del enrutador.tap
: esta interfaz se genera internamente y no se puede configurar.vt
— Interfaz de túnel de circuito cerrado virtual.
Consulte también
Habilitar paquetes de servicio
Para las AS, las CPC multiservicios, las DPC multiservicios y el módulo interno de servicios adaptables (ASM) en el enrutador de M7i, hay dos paquetes de servicio: capa 2 y capa 3. Ambos paquetes de servicio se admiten en todas las interfaces de servicios adaptables, pero solo puede habilitar un paquete de servicio por PIC, con la excepción de un paquete combinado compatible con el ASM. En un solo enrutador, puede habilitar ambos paquetes de servicio instalando dos o más CPC en la plataforma.
El motor de enrutamiento cambio automático (GRES) se habilita automáticamente en todas las PIC y DPC de servicios, excepto en la PIC ES. Se admite en todos los M Series, serie MX y serie T, excepto en los enrutadores tx Matrix. Los servicios de capa 3 deben conservar el estado después de la conmutación, pero los servicios de capa 2 se reiniciarán. En el caso de los servicios IPsec, Intercambio de claves por red (ICR) no se almacenan y se deben reiniciar después de la conmutación. Para obtener más información acerca de GRES, consulte Junos OS del usuario de alta disponibilidad.
Habilitar paquetes de servicio por PIC, no por puerto. Por ejemplo, si configura el paquete de servicio de capa 2, toda la PIC utilizará el paquete configurado. Para habilitar un paquete de servicio, incluya la instrucción service-package en el nivel [edit chassis fpc slot-number pic pic-number adaptive-services]
de jerarquía y especifique layer-2
o layer-3
:
[edit chassis fpc slot-number pic pic-number adaptive-services] service-package (layer-2 | layer-3);
Para determinar qué paquete admite una PIC de AS, show chassis hardware
emita el comando: si la PIC admite el paquete de capa 2, Link Services II
se muestra como y, si admite el paquete de capa 3, Adaptive Services II
se muestra como . Para determinar qué paquete admite una PIC de varios servicios, emita el show chassis pic fpc-slot slot-number pic-slot slot-number
comando. El Package
campo muestra el valor Layer-2
o Layer-3
.
El ASM tiene una opción predeterminada (layer-2-3
) que combina las funciones disponibles en los paquetes de servicios de capa 2 y capa 3.
Después de confirmar un cambio en el paquete de servicio, la PIC se desconecta y, luego, vuelve a estar en línea de inmediato. No es necesario que tome la PIC de forma manual fuera de línea y en línea.
Cambiar el paquete de servicio hace que se pierda toda la información de estado asociada con el paquete de servicio anterior. Solo debe cambiar el paquete de servicio cuando no haya tráfico activo en la PIC.
Los servicios admitidos en cada paquete difieren según la PIC y el tipo de plataforma. En la tabla 1 se enumeran los servicios admitidos en cada paquete de servicio para cada PIC y plataforma.
En las CPC de AS y multiservicios, la compatibilidad de servicios de vínculo incluye componentes de CoS de Junos OS, LFI (FRF.12), MLFR de extremo a extremo (FRF.15), MLFR UNI NNI (FRF.16), MLPPP (RFC 1990) y MLPPP multiclase. Para obtener más información, consulte Capacidades e interfaces del paquete de servicio de capa 2 y capacidades e interfaces del paquete de servicio de capa 2.
El AS PIC II para el servicio de capa 2 se dedica a admitir solo el paquete de servicio de capa 2.
Servicios |
ASM |
AS/AS2 y LAS PICs multiservicios |
AS/AS2 y LAS CPC multiservicios |
PICs AS2 y Multiservicios |
PICs AS2 y Multiservicios |
---|---|---|---|---|---|
Paquete de servicio de capa 2 (solo) | M7i | M7i, M10i y M20 | M40e y M120 | M320, T320 y T640 | Matriz de transmisión |
Servicios de vínculo: |
|||||
|
Sí |
Sí |
Sí |
Sí |
No |
|
Sí |
Sí |
Sí |
Sí |
No |
Servicios de voz: |
|||||
|
Sí |
Sí |
Sí |
Sí |
No |
|
Sí |
Sí |
Sí |
Sí |
No |
|
Sí |
Sí |
Sí |
Sí |
No |
Paquete de servicio de capa 3 (solo) | M7i | M7i, M10i y M20 | M40e y M120 | M320, T320 y T640 | Matriz de transmisión |
Servicios de seguridad: |
|||||
|
Sí |
Sí |
Sí |
Sí |
No |
|
Sí |
Sí |
Sí |
Sí |
No |
|
Sí |
Sí |
Sí |
Sí |
No |
|
Sí |
Sí |
Sí |
Sí |
No |
|
Sí |
Sí |
Sí |
Sí |
No |
Servicios de cuentas: |
|||||
|
Sí |
Sí |
Sí |
Sí |
Sí |
|
No |
No |
No |
Sí |
No |
|
Sí |
Sí |
Sí (solo M40e) |
Sí |
No |
|
No |
Sí |
Sí (solo M40e) |
Sí |
No |
|
Sí |
Sí |
Sí |
Sí |
Sí |
Servicios de LNS: |
|||||
|
Sí |
Sí (M7i y M10i único) |
Sí (solo M120) |
No |
No |
Servicios de voz: |
|||||
|
Sí |
Sí |
Sí |
Sí |
No |
Paquete de servicio de capa 2 y capa 3 (características comunes) | M7i | M7i, M10i y M20 | M40e y M120 | M320, T320 y T640 | Matriz de transmisión |
Servicios RPM: |
|||||
|
Sí |
Sí |
Sí |
Sí |
No |
Servicios de túnel: |
|||||
|
Sí |
Sí |
Sí |
Sí |
Sí |
|
Sí |
Sí |
Sí |
No |
No |
|
Sí |
Sí |
Sí |
Sí |
No |
|
Sí |
Sí |
Sí |
Sí |
Sí |
|
No |
No |
No |
No |
No |
|
Sí |
Sí |
Sí |
Sí |
Sí |
|
Sí |
Sí |
Sí |
Sí |
Sí |
|
Sí |
Sí |
Sí |
Sí |
Sí |
|
Sí |
Sí |
Sí |
Sí |
Sí |
Capacidades e interfaces del paquete de servicio de capa 2
Cuando habilite el paquete de servicio de capa 2, puede configurar los servicios de vínculo. En las AS y multiservicios, y en el ASM, los servicios de vínculo incluyen compatibilidad con lo siguiente:
Componentes de Junos CoS: las interfaces y las capacidades del paquete de servicio de capa 2 describen cómo los componentes de Junos CoS funcionan en interfaces IQ (
lsq
) de servicios de vínculo. Para obtener información más detallada acerca de los componentes de Junos CoS, consulte la Guía del usuario Junos OS clase de servicio para dispositivos de enrutamiento.LFI en vínculos de Frame Relay que utilizan fragmentación de extremo a extremo FRF.12: el estándar de FRF.12 está definido en la especificación FRF.12, Acuerdo de implementación de fragmentación de Frame Relay.
LFI en vínculos MLPPP.
MLFR UNI NNI (FRF.16):El estándar de FRF.16 se define en la especificación FRF.16.1, Acuerdo de implementación UNI/NNI multilink Frame Relay.
MLPPP (RFC 1990)
MLFR de extremo a extremo (FRF.15)
Para la interfaz LSQ en las AS y LASIC multiservicios, la sintaxis de configuración es casi la misma que para las PIC de multilink y de servicios de vínculo. La diferencia principal es el uso del descriptor de tipo de interfaz lsq
en lugar de ml
o ls
. Cuando habilite el paquete de servicio de capa 2, se crean automáticamente las siguientes interfaces:
gr-fpc/pic/port ip-fpc/pic/port lsq-fpc/pic/port lsq-fpc/pic/port:0 ... lsq-fpc/pic/port:N mt-fpc/pic/port pd-fpc/pic/port pe-fpc/pic/port sp-fpc/pic/port vt-fpc/pic/port
Los tipos gr
de interfaz , ip
, mt
, pd
pe
y vt
son interfaces de túnel estándar que están disponibles en las CPC de AS y Multiservicios, ya sea que habilite el paquete de servicio de capa 2 o de capa 3. Estas interfaces de túnel funcionan de la misma manera para ambos paquetes de servicio, excepto que el paquete de servicio de capa 2 no admite algunas funciones de túnel, como se muestra en la Tabla 1.
El tipo de lsq-fpc/pic/port
interfaz es la interfaz IQ (lsq
) de servicios de vínculo físico. Los tipos de lsq-fpc/pic/port:0
interfaz a través lsq-fpc/pic/port:N
de representan paquetes FRF.16. Estos tipos de interfaz se crean cuando se incluye la mlfr-uni-nni-bundles
instrucción en la [edit chassis fpc slot-number pic pic-number]
opción. Para obtener más información, consulte Funcionalidades e interfaces del paquete de servicio de capa 2, y guía del usuario de interfaces de servicios de vínculo y multilink para dispositivos de enrutamiento.
El tipo sp
de interfaz se crea porque es necesario para el Junos OS. Para el paquete de servicio de capa 2, la sp
interfaz no es configurable, pero no debe deshabilitarla.
Consulte también
Procedimiento de configuración de servicios
Siga estos pasos generales para configurar los servicios:
Ejemplo: configuración de interfaces de servicio
La siguiente configuración incluye todos los elementos necesarios para configurar los servicios en una interfaz:
[edit] interfaces { fe-0/1/0 { unit 0 { family inet { service { input { service-set Firewall-Set; } output { service-set Firewall-Set; } } address 10.1.3.2/24; } } } fe-0/1/1 { unit 0 { family inet { filter { input Sample; } address 172.16.1.2/24; } } } sp-1/0/0 { unit 0 { family inet { address 172.16.1.3/24 { } } } } } forwarding-options { sampling { input { family inet { rate 1; } } output { cflowd 10.1.3.1 { port 2055; version 5; } flow-inactive-timeout 15; flow-active-timeout 60; interface sp-1/0/0 { engine-id 1; engine-type 136; source-address 10.1.3.2; } } } } firewall { filter Sample { term Sample { then { count Sample; sample; accept; } } } } services { stateful-firewall { rule Rule1 { match-direction input; term 1 { from { application-sets Applications; } then { accept; } } term accept { then { accept; } } } rule Rule2 { match-direction output; term Local { from { source-address { 10.1.3.2/32; } } then { accept; } } } } ids { rule Attacks { match-direction output; term Match { from { application-sets Applications; } then { logging { syslog; } } } } } nat { pool public { address-range low 172.16.2.1 high 172.16.2.32; port automatic; } rule Private-Public { match-direction input; term Translate { then { translated { source-pool public; translation-type source napt-44; } } } } } service-set Firewall-Set { stateful-firewall-rules Rule1; stateful-firewall-rules Rule2; nat-rules Private-Public; ids-rules Attacks; interface-service { service-interface sp-1/0/0; } } } applications { application ICMP { application-protocol icmp; } application FTP { application-protocol ftp; destination-port ftp; } application-set Applications { application ICMP; application FTP; } }
Configuración de la configuración predeterminada de tiempo de espera para interfaces de servicios
Puede especificar la configuración predeterminada global para ciertos temporizadores que se apliquen a toda la interfaz. Hay tres instrucciones de este tipo:
inactivity-timeout
: establece el período de tiempo de espera de inactividad para los flujos establecidos, después de lo cual ya no son válidos.open-timeout
: establece el período de tiempo de espera para el establecimiento de sesión del Protocolo de control de transmisión (TCP), para su uso con defensas de syn-cookie contra intrusiones en la red.close-timout
: establece el período de tiempo de espera para el desgarro de la sesión del Protocolo de control de transmisión (TCP).
Para configurar una configuración para el período de tiempo de espera de inactividad, incluya la inactivity-timeout
instrucción en el nivel [edit interfaces interface-name services-options]
jerárquico:
[edit interfaces interface-name services-options] inactivity-timeout seconds;
El valor predeterminado es de 30 segundos. El intervalo de valores posibles va de 4 a 86.400 segundos. Cualquier valor que configure en la definición de protocolo de aplicación anula el valor especificado aquí; para obtener más información, consulte Configuración de propiedades de aplicación.
Para configurar una configuración para el período de tiempo de espera del establecimiento de sesión TCP, incluya la open-timeout
instrucción en el nivel [edit interfaces interface-name services-options]
de jerarquía:
[edit interfaces interface-name services-options] open-timeout seconds;
El valor predeterminado es de 5 segundos. El intervalo de valores posibles va de 4 a 224 segundos. Cualquier valor que configure en la definición servicio de detección de intrusiones (IDS) reemplaza el valor especificado aquí; para obtener más información, consulte Configurar IDS reglas de desarrollo en una MS-CPC.
Para configurar una configuración para el período de tiempo de espera de desmontaje de la sesión TCP, incluya la close-timeout
instrucción en el nivel [edit interfaces interface-name services-options]
de jerarquía:
[edit interfaces interface-name services-options] close-timeout seconds;
El valor predeterminado es 1 segundo. El intervalo de valores posibles va de 2 a 300 segundos.
Uso de mensajes keep-Alive para un mayor control de los tiempos de espera de inactividad de TCP
Los mensajes keep-alive se generan de forma automática para evitar tiempos de espera de inactividad de TCP. El número predeterminado de mensajes keep-alive es 4. Sin embargo, puede configurar el número de mensajes keep-actuales ingresando la tcp-tickles
instrucción en el nivel [edit interaces interface-name service-options]
jerárquico.
Cuando se genera el tiempo de espera para un flujo TCP bidireccional, se envían paquetes keep-alive para restablecer el temporizador. Si el número de paquetes consecutivos keep-alive enviados en un flujo alcanza el límite predeterminado o configurado, la conversación se elimina. Hay varias situaciones posibles, dependiendo inactivity-timer
de la configuración de la cantidad máxima predeterminada o configurada de mensajes de mantener vivo.
Si el valor configurado de los mensajes keep-actuales
inactivity-timeout
es cero y NO está configurado (en cuyo caso se usa el valor predeterminado de tiempo de espera de 30), no se envían paquetes keep-alive. La conversación se elimina cuando cualquier flujo de la conversación está inactivo durante más de 30 segundos.Si el valor configurado de los mensajes keep-actuales
inactivity-timeout
es cero y está configurado, no se envían paquetes keep-alive y la conversación se elimina cuando cualquier flujo de la conversación está inactivo para más que el valor de tiempo de espera configurado.Si el número máximo predeterminado o configurado de mensajes keep-alive es algún entero positivo,
inactivity-timeout
y cualquiera de los flujos de una conversación está inactivo para más que el valor predeterminado o configurado para los paquetes keep-alive se envían. Si los hosts no responden al número configurado de paquetes consecutivos keep-alive, la conversación se elimina. El intervalo entre paquetes keep-alive será de 1 segundo. Sin embargo, si el host devuelve un paquete ACK, el flujo correspondiente se activa y los paquetes de mantener vivo no se envían hasta que el flujo vuelve a estar inactivo.
Consulte también
Configuración del registro del sistema para interfaces de servicios
Se especifican propiedades que controlan cómo se generan los mensajes de registro del sistema para la interfaz como un todo. Si configura valores diferentes para las mismas [edit services service-set service-set-name]
propiedades en el nivel de jerarquía, los valores de conjunto de servicios reemplazan los valores configurados para la interfaz. Para obtener más información sobre cómo configurar propiedades de conjunto de servicios, consulte Configurar el registro del sistema para conjuntos de servicios.
A partir de Junos OS release 14.2R5, 15.1R3 y 16.1R1, para interfaces de multiservicios (ms-), no puede configurar el registro del sistema para PPG y ALG incluyendo las instrucciones syslog-logs y alg-logs en el nivel de jerarquía [edit services-set service-set service-set-name syslog host class]. Se muestra un mensaje de error si intenta confirmar una configuración que contiene las opciones de los registros de los p.s. y los registros alg para definir el registro del sistema para ELS y las ALG para interfaces ms-.
Para configurar los valores de registro predeterminados del sistema para toda la interfaz, incluya la syslog
instrucción en el nivel [edit interfaces interface-name services-options]
de jerarquía:
[edit interfaces interface-name services-options] syslog { host hostname { services severity-level; facility-override facility-name; log-prefix prefix-value; port port-number; } }
Configure la host
instrucción con un nombre de host o una dirección IP que especifique el servidor de destino del registro del sistema. El nombre de local
host dirige los mensajes de registro del sistema al motor de enrutamiento. Para los servidores de registro del sistema externos, se debe tener acceso al nombre de host desde la misma instancia de enrutamiento a la que se entrega el paquete de datos inicial (que desencadenó el establecimiento de sesión). Solo puede especificar un nombre de host de registro del sistema.
A partir de Junos OS versión 17.4R1, puede configurar hasta un máximo de cuatro servidores de registro del sistema (combinación de hosts de registro del sistema local y recopiladores de registros del sistema remoto) para cada conjunto de servicios para la interfaz ms [edit interfaces interface-name services-options]
bajo jerarquía.
La tabla 2 enumera los niveles de gravedad que puede especificar en instrucciones de configuración en el nivel [edit interfaces interface-name services-options syslog host hostname]
jerárquido. Los niveles desde emergency
hasta están info
en orden desde la mayor gravedad (mayor efecto sobre el funcionamiento) hasta la más baja.
Nivel de gravedad |
Descripción |
---|---|
|
Incluye todos los niveles de gravedad |
|
Pánico del sistema u otra condición que hace que el enrutador deje de funcionar |
|
Condiciones que requieren corrección inmediata, como una base de datos del sistema dañada |
|
Condiciones críticas, como errores de disco duro |
|
Condiciones de error que generalmente tienen consecuencias menos graves que los errores en los niveles de emergencia, alerta y críticos |
|
Condiciones que garantizan el monitoreo |
|
Condiciones que no son errores, pero que pueden justificar un manejo especial |
|
Eventos o condiciones de interés no ambientales |
Recomendamos establecer el nivel de gravedad del registro del sistema en durante error
el funcionamiento normal. Para supervisar el uso de recursos de PIC, establezca el nivel en warning
. Para recopilar información acerca de un ataque de intrusiones cuando se detecte un error en el sistema de detección de intrusiones, establezca el nivel en notice
para una interfaz específica. Para depurar una funcionalidad de configuración Traducción de direcciones de red registro (TDR), establezca el nivel en info
.
Para obtener más información acerca de los mensajes de registro del sistema, consulte el Explorador de registros del sistema.
Para usar un código de instalación determinado para todo el registro en el host de registro del sistema especificado, incluya la facility-override
instrucción en el nivel [edit interfaces interface-name services-options syslog host hostname]
de jerarquía:
[edit interfaces interface-name services-options] facility-override facility-name;
Las instalaciones compatibles incluyen authorization
, daemon
ftp
, kernel
, user
, y local0
through local7
.
Para especificar un prefijo de texto para todo el registro en este host de registro del sistema, incluya la log-prefix
instrucción en el nivel [edit interfaces interface-name services-options syslog host hostname]
de jerarquía:
[edit interfaces interface-name services-options] log-prefix prefix-value;
Consulte también
Configuración del protocolo Syslog TLS en MS-MPC y MS-MIC
- capa de transporte de seguridad de red (TLS)
- Descripción general de la configuración del protocolo de transporte TLS para mensajes syslog
- Configuración de TCP/TLS para mensajes syslog
capa de transporte de seguridad de red (TLS)
A partir de Junos OS versión 19.1R1, puede configurar capa de transporte Security (TLS) para los mensajes syslog generados por los servicios que se ejecutan en las tarjetas de servicio MS-MPC o MS-MIC en un enrutador MX. Los servicios pueden ser uno de los siguientes:
Junos Address Aware (antes conocido como TDR feaures)
Junos VPN Site Secure (antes denominadas características de IPsec)
Junos Network Secure (conocidas anteriormente como funciones de firewall stateful)
capa de transporte Security (TLS) es un protocolo a nivel de aplicación que proporciona tecnología de cifrado para Internet. TLS depende de certificados y pares de intercambio de claves pública y privada para este nivel de seguridad. Es el protocolo de seguridad más utilizado para las aplicaciones que requieren el intercambio seguro de datos a través de una red, como transferencias de archivos, conexiones VPN, mensajes instantáneas y voz sobre IP (VoIP).
El protocolo TLS se utiliza para el intercambio de certificados, la autenticación mutua y los cifrados de negociación para proteger la transmisión de posibles manipulaciones y escuchas. Tls a veces se denomina capa de conexión segura (SSL). TLS y SSL no son interoperables, aunque TLS actualmente proporciona cierta compatibilidad con versiones anteriores.
- Beneficios de TLS
- Tres servicios esenciales de TLS
- Protocolo TLS
- Cifrar el tráfico de Syslog con TLS
- Versiones de TLS
Beneficios de TLS
TLS garantiza la transmisión segura de datos entre un cliente y un servidor mediante una combinación de privacidad, autenticación, confidencialidad e integridad de datos.
Tres servicios esenciales de TLS
El protocolo TLS está diseñado para proporcionar tres servicios esenciales a las aplicaciones que se ejecutan por encima de él: cifrado, autenticación e integridad de datos.
Cifrado: para establecer un canal de datos criptográficomente seguro, el servidor y el cliente deben coincidir en qué conjuntos de cifrado se utilizan y las claves que se utilizan para cifrar los datos. El protocolo TLS especifica una secuencia de apretón de manos bien definida para llevar a cabo este intercambio. TLS utiliza criptografía de clave pública, lo que permite al cliente y al servidor negociar una clave confidencial compartida sin tener que establecer ningún conocimiento previo entre sí, y hacerlo a través de un canal no cifrado.
Autenticación: como parte del protocolo TLS, el protocolo permite que tanto el servidor como el cliente autentificar su identidad. La confianza implícita entre el cliente y el servidor (porque el cliente acepta el certificado generado por el servidor) es un aspecto importante de TLS. Es sumamente importante que la autenticación del servidor no se vea comprometida; sin embargo, en realidad, los certificados y certificados auto firmados con anomalías son abundantes. Las anomalías pueden incluir certificados caducados, instancias de nombre común que no coincidan con un nombre de dominio, etc.
Integridad: con el cifrado y la autenticación en su sitio, el protocolo TLS hace un mecanismo de trama de mensajes y firma cada mensaje con un código de autenticación de mensajes (MAC). El algoritmo mac hace la suma de comprobación eficaz y las claves se negocian entre el cliente y el servidor.
Protocolo TLS
Cada sesión de TLS comienza con un apretón de manos durante el cual el cliente y el servidor coinciden en la clave de seguridad específica y los algoritmos de cifrado que se deben usar para esa sesión. En este momento, el cliente también autentica el servidor. Opcionalmente, el servidor puede autenticar al cliente. Una vez completado el contacto, puede comenzar la transferencia de datos cifrados.
Cifrar el tráfico de Syslog con TLS
El protocolo TLS garantiza que los mensajes syslog se envíen y reciban de forma segura a través de la red. TLS usa certificados para autenticar y cifrar la comunicación. El cliente autentica el servidor mediante la solicitud de su certificado y clave pública. Opcionalmente, el servidor también puede solicitar un certificado al cliente, por lo que también es posible la autenticación mutua.
Un certificado en el servidor que identifique al servidor y el certificado de autoridad de certificación (AC) emitido por el servidor debe estar disponible con el cliente para TLS para cifrar el tráfico syslog.
Para la autenticación mutua del cliente y el servidor, debe estar disponible en el servidor un certificado con el cliente que identifique al cliente y el certificado de AC emitido por el cliente. La autenticación mutua garantiza que el servidor syslog acepte solo mensajes de registro de clientes autorizados.
TLS se usa como un transporte seguro para contrarrestar todas las amenazas principales a syslog enumeradas a continuación:
Confidencialidad para contrarrestar la divulgación del contenido del mensaje.
Comprobación de integridad para contrarrestar modificaciones de un mensaje salto a salto.
Autenticación de servidor o mutua para contrarrestar el enmascaramiento.
Versiones de TLS
A continuación, se encuentran las versiones de TLS:
TLS versión 1.0: proporciona comunicación segura a través de las redes proporcionando privacidad e integridad de datos entre las aplicaciones que se comunican
TLS versión 1.1: esta versión mejorada de TLS proporciona protección contra ataques de encadenamiento de bloques de cifrado (CBC).
TLS versión 1.2: esta versión mejorada de TLS proporciona una flexibilidad mejorada para la negociación de algoritmos criptográficos.
Descripción general de la configuración del protocolo de transporte TLS para mensajes syslog
A partir de Junos OS versión 19.1R1, puede configurar un enrutador serie MX para usar capa de transporte Security (TLS) para los mensajes syslog generados por los servicios que se ejecutan en las tarjetas de servicio MS-MPC o MS-MIC en un enrutador serie MX.
Los siguientes paquetes de servicios están preinstalados y preconfigurados en MS-MIC y MS-MS-MCS:
Junos Traffic Vision (antes llamado Jflow)
Junos Address Aware (conocidas anteriormente como funciones TDR funciones)
Junos VPN Site Secure (antes denominadas características de IPsec)
Junos Network Secure (conocida anteriormente como función de firewall stateful)
Paquete de PIC de base de criptodivisas de Junos Services
Puertas de enlace de nivel de aplicación de servicios Junos
Puede configurar un máximo de cuatro servidores syslog para cada conjunto de servicios y enviar datos cifrados a los servidores.
Los mensajes syslog se envían a través de una conexión dedicada creada para un conjunto determinado de parámetros de configuración únicos:
Dirección IP de origen
Dirección IP de destino (servidor TCP/TLS)
Puerto
Nombre de perfil SSL (para la conexión TLS)
Nota:Si el perfil ssl no está configurado en la jerarquía tcp-log, entonces es un transporte TCP que no es TLS.
Si hay varios conjuntos de servicios que tengan la configuración de registro TCP/TLS con los mismos parámetros mencionados anteriormente, los registros generados a partir de las sesiones de todos esos conjuntos de servicios comparten la misma conexión.
Esta función es compatible tanto con IPv4 como con IPv6.
La conexión TCP/TLS configurada permanece activa hasta que la configuración esté presente, incluso si no hay eventos de registro.
La compatibilidad con la configuración de sicólogo TCP/TLS se proporciona para el registro seguro y confiable solo en el plano de datos.
Para servicios múltiples agregados (AMS) con varios miembros activos, cada miembro crea una conexión TCP/TLS independiente y los syslog generados por cada PIC miembro se envían a través de sus conexiones únicas.
Configuración de TCP/TLS para mensajes syslog
Puede usar los protocolos de transporte TCP/TLS para enviar mensajes syslog de manera confiable y segura a servidores syslog externos.
Para configurar los protocolos TCP/TLS para mensajes syslog: