Ayudar en la resolución de problemas y la optimización de aplicaciones de red empresarial desde la perspectiva de los paquetes RST en el microcosmos.

1.  Prefacio

Con la popularización y el desarrollo de Internet, las empresas y aplicaciones de diversas industrias dependen cada vez más de Internet. Sin embargo, la inestabilidad y complejidad del entorno de la red aumentan la probabilidad de que se produzcan diversos fenómenos anormales. Estos fenómenos anormales harán que la empresa no funcione normalmente, traerán problemas a los usuarios e incluso afectarán la imagen y los intereses de la empresa. Por lo tanto, se necesita una solución capaz de diagnosticar y localizar rápidamente anomalías en la red.

La tecnología de análisis de captura de paquetes de red es una herramienta de depuración de red de uso común que puede capturar paquetes de datos de red y proporcionar análisis de datos detallados e información estadística para ayudar a los usuarios a localizar rápidamente problemas de red. Entre ellos, el mensaje TCP RST es un fenómeno anormal común en la red, que generalmente indica que la conexión se restablece o se interrumpe, lo que resulta en una falla en el funcionamiento normal del servicio.

En respuesta a este problema, la solución de análisis de seguimiento de tráfico completo de NetInside (en lo sucesivo, tráfico completo de NetInside) recopila y almacena todos los datos de tráfico del enlace especificado mediante la derivación del dispositivo de sonda y realiza una operación desatendida, lo cual es fundamental para el negocio. sistemas, aplicaciones y redes.Los enlaces realizan un monitoreo integral del tráfico las 7 x 24 horas, aprenden de manera inteligente el valor de referencia de los indicadores clave de rendimiento y, cuando hay anomalías en la red, los estados comerciales o relacionados con la red alcanzan los umbrales, se emiten advertencias activas. y análisis en tiempo real/posterior al evento en tiempo real o posterior al evento del original requerido. Descargue, analice y decodifique el paquete para localizar rápidamente la causa del problema.

NetInside ha creado una nueva generación de sistema de análisis retrospectivo de tráfico completo diseñado para el departamento de información con el concepto de orientado a las personas, haciendo pleno uso de los paquetes de datos de la red para establecer una vista de monitoreo integral que cubra enlaces importantes, puertos de equipos clave y servicios principales. y organizarlo de acuerdo con el flujo de trabajo del departamento de red. Las funciones y operaciones lo hacen ampliamente aplicable a varios escenarios.

El método de flujo completo orientado a servicios permite que el sistema NetInside refleje directamente la capacidad de soporte de la infraestructura de red para aplicaciones comerciales y proporciona diagnóstico de fallas en tiempo real, activación de alarmas y análisis en profundidad de las respuestas de las aplicaciones posteriores al evento. Todo el sistema simplifica fundamentalmente el diagnóstico de fallas de la red, la implementación de nuevas aplicaciones y servicios, reduce los costos operativos y proporciona una manera rápida de localizar fallas. Proporcionar una base de datos confiable para analizar ataques a la red, localizar anomalías, evaluar y juzgar la experiencia del usuario, el rendimiento de las aplicaciones y la calidad del servicio de la red. Confiando en el tráfico de red real, descubra y defina aplicaciones rápidamente, y proporcione corrección de datos y capacidades de verificación de resultados de cambios, mejorando en gran medida la cobertura visual del tráfico de red y la eficiencia del trabajo. Utilizando tecnología avanzada de análisis estadístico de datos, funciones como el descubrimiento y la alarma simplifican enormemente el tedioso y complicado proceso operativo del pasado.

2.  Introducción a RST

TCP RST (Restablecer) es un mensaje de control en el protocolo TCP, que se encuentra en la capa de transporte del protocolo TCP y se utiliza para finalizar la conexión TCP o rechazar conexiones ilegales. TCP RST generalmente lo envía una de las partes de una conexión TCP, puede finalizar inmediatamente la conexión TCP y notificar a la otra parte que la conexión se ha restablecido.

El mensaje TCP RST se encuentra en el campo de bits de control (campo de bits de control) en el encabezado TCP, este campo ocupa un byte y su sexto bit (RST) se utiliza para representar el mensaje TCP RST. El siguiente es un diagrama de un encabezado TCP:

Se puede ver que el sexto bit del decimotercer byte (es decir, el campo de bit de control) en el encabezado TCP indica el mensaje TCP RST. Cuando este bit se establece en 1, significa enviar un mensaje TCP RST.

3.  Causas comunes y métodos de confirmación de RST

Las situaciones y motivos comunes para generar paquetes de restablecimiento de TCP incluyen las siguientes siete situaciones. Cabe señalar que el paquete de reinicio de TCP puede afectar la conexión TCP normal, por lo que debe usarse con precaución. Si no está seguro de si debe enviar un paquete de restablecimiento de TCP, consulte primero con su administrador de red o profesional de seguridad.

3.1  Intervención de firewalls o dispositivos de red en conexiones TCP

Cuando un firewall o dispositivo de red interfiere con una conexión TCP, puede enviar un paquete de reinicio de TCP para finalizar la conexión.

Juicio del motivo: verifique los registros del firewall o del dispositivo de red para confirmar si hay alguna interferencia con la conexión TCP. Si se finaliza una conexión TCP y se recibe un paquete de restablecimiento de TCP, es probable que lo envíe un firewall o un dispositivo de red.

3.2  El punto final cree que la conexión ha fallado o es anormal

Cuando un punto final de una conexión TCP cree que la conexión ha fallado o tiene condiciones anormales, puede enviar un paquete de restablecimiento de TCP para finalizar la conexión.

Juicio de motivo: puede verificar si hay un paquete de reinicio de TCP verificando el registro de la conexión TCP o una herramienta de captura de paquetes de red. Si se descubre que una determinada parte ha enviado un paquete de restablecimiento de TCP, es probable que crea que la conexión ha fallado o que existe una situación anormal.

3.3.  Un atacante puede enviar un paquete de reinicio de TCP

En algunos ataques, el atacante puede enviar un paquete de reinicio de TCP para finalizar la conexión o engañar al receptor.

Juicio de motivo: puede verificar si hay paquetes de restablecimiento de TCP anormales verificando la herramienta de captura de paquetes de red. Si se descubre que la dirección de origen del paquete de reinicio TCP es desconocida o no coincide con la dirección IP de la comunicación normal, es probable que sea atacado.

3.4  Congestión de la red

Cuando la red está congestionada, los enrutadores o firewalls pueden descartar algunos paquetes de datos, lo que provoca que las conexiones TCP se agoten o fallen. En este punto, un lado de la conexión puede enviar un paquete de restablecimiento de TCP para finalizar la conexión.

Juicio de motivo: puede verificar si hay un paquete de datos perdido o un tiempo de espera de conexión TCP verificando la herramienta de captura de paquetes de red. Si descubre que se envían paquetes de restablecimiento de TCP durante períodos de congestión de la red, es probable que una de las partes de la conexión crea que la conexión ha fallado.

3.5  Programa anormal

Cuando se produce una anomalía en el programa de aplicación o en el sistema operativo, la conexión TCP puede dañarse o invalidarse. En este punto, un lado de la conexión puede enviar un paquete de restablecimiento de TCP para finalizar la conexión.

Juicio de motivo: puede verificar si hay un comportamiento anormal o información de error verificando los registros del programa de aplicación o del sistema operativo. Si se descubre que una determinada parte ha enviado un paquete de restablecimiento de TCP, es probable que se deba a una excepción del programa.

3.6  Tiempo de espera

Cuando una conexión TCP ha estado inactiva durante mucho tiempo, se puede considerar muerta. En este punto, un lado de la conexión puede enviar un paquete de restablecimiento de TCP para finalizar la conexión.

Juicio de motivo: puede verificar si la conexión ha estado inactiva durante mucho tiempo verificando los registros de la conexión TCP o la herramienta de captura de paquetes de red. Si descubre que una de las partes está enviando un paquete de restablecimiento de TCP y la conexión ha estado inactiva durante mucho tiempo, es probable que se deba a un tiempo de espera.

3.7  Conexión ilegal

Cuando algunos programas maliciosos o atacantes intentan establecer una conexión TCP ilegal, un lado de la conexión puede enviar un paquete de restablecimiento de TCP para bloquear la conexión.

Juicio de motivo: puede verificar si existe una solicitud de conexión TCP ilegal o un comportamiento de conexión verificando la herramienta de captura de paquetes de red. Si se descubre que una parte envía un paquete de restablecimiento de TCP, probablemente se deba a una solicitud de conexión ilegal.

4.  Análisis de casos RST

A continuación se analizará el comportamiento anormal de RST a través de dos casos reales en el sitio para ayudar rápidamente a los usuarios a resolver problemas difíciles.

4.1  Un caso de seguridad pública provincial

4.1.1  Antecedentes

Hay tareas programadas en la plataforma de comando integrada para transmitir datos periódicamente al cuartel general, y el cuartel general envía datos al destacamento de la policía de tránsito municipal con regularidad. El Destacamento de la Policía Municipal de Tránsito constató que la ejecución de las tareas programadas había fallado. El Destacamento de la Policía de Tránsito Municipal se comunicó con la Jefatura y dijo que el Destacamento de la Policía de Tránsito Municipal necesitaba verificar su propia red, hace dos días capturó los paquetes de datos de las tareas programadas en el servidor de la aplicación y descubrió que había sido RST durante la conexión. proceso. No es posible confirmar en qué enlace se realizó RST.

Este análisis utiliza el sistema de análisis de tráfico NetInside, que se ha implementado en el entorno empresarial, utilizando el sistema de análisis de tráfico para proporcionar tráfico bruto histórico y en tiempo real. Este análisis se centra en la resolución de problemas de tareas programadas integradas para la configuración forense, análisis de rendimiento, monitoreo de la calidad de la red y análisis profundo de la red.

4.1.2  Despliegue del entorno

El destacamento de la policía de tránsito municipal y el cuerpo de la policía de tránsito están interconectados por una red privada y una línea dedicada. En el conmutador central de la plataforma de comando de integración del dominio de seguridad del destacamento de la policía de tránsito municipal, el modo de derivación de tráfico se refleja en el sistema de análisis de tráfico NetInside. y el tráfico de tareas programadas se recopila y analiza a través de NetInside.

4.1.3  Tiempo de análisis

El rango de tiempo de análisis del informe es: 2023-05-19 horario laboral diurno.

4.1.4  Propósito del análisis

Analice los motivos de la falla en la ejecución de las tareas programadas en la plataforma de comando integrada, descubra la causa raíz del problema y tome las medidas correspondientes para resolver estos problemas.

A través del análisis es posible determinar qué factores conducen a la falla en la ejecución de las tareas programadas, como problemas de conexión de red, fallas del sistema, errores de configuración, etc. Hacerlo puede ayudar a los administradores a descubrir y resolver problemas de manera oportuna y garantizar el funcionamiento normal de la plataforma de comando integrada. Busque y verifique que no haya problemas de salud del sistema empresarial.

4.1.5  Análisis detallado

A continuación se presenta un análisis detallado de este fracaso.

4.1.5.1  Existen intervalos de tiempo obvios en la transmisión del tráfico.

Al analizar la tendencia de distribución de datos de segundo nivel del sistema, se encuentra que existen intervalos de transmisión obvios y regulares entre 10.61.132.78 (en lo sucesivo, 78) y el servidor 10.56.81.80 (en lo sucesivo, 80). Lo más probable es que esto se deba a algunos factores desconocidos .

4.1.5.2  Análisis en profundidad del fenómeno del intervalo de transmisión de datos

Descargue los paquetes de datos correspondientes del sistema de análisis y busque una gran cantidad de paquetes RST, como se muestra en la siguiente figura.

Verifique aleatoriamente la información de una sesión (diálogo basado en 5 tuplas) en la figura anterior y descubra que hay una anomalía.

En la siguiente figura, todos los paquetes anteriores a la trama 19695 son operaciones de solicitud POST normales, pero las tramas 20756 y 20757 obviamente no están relacionadas con la conexión anterior.

Continúe analizando.

En la transmisión de datos normal, el TTL de los paquetes de datos que fluyen de 80 a 78 es 119, como se muestra en la siguiente figura.

Mirando nuevamente el cuadro 20756, también es un paquete del 80 al 78, pero el TTL es 124 .

Al mismo tiempo, este paquete RST también contiene más información sobre la capa de aplicación como referencia.

Y el cuadro 20757 es el RST del mensaje RST anterior.

Después del análisis, se produjeron un total de 1846 RST similares en un rango de tiempo de aproximadamente 43 minutos.

4.1.5.3  El impacto de un RST anormal en la transmisión de datos

El análisis encontró que después de que ocurre el RST mencionado anteriormente, 78 se estancará por un período de tiempo, iniciará una solicitud de protocolo de enlace TCP a 80 nuevamente y luego realizará la operación de datos POST.

Los siguientes son algunos datos vistos aleatoriamente como evidencia.

Después del RST anormal, 78 espera 8,19 segundos antes de enviar una solicitud de establecimiento de conexión a 80.

Después del RST anormal, 78 espera 13,14 segundos antes de enviar una solicitud de establecimiento de conexión a 80.

Después del RST anormal, 78 espera 34,34 segundos antes de enviar una solicitud de establecimiento de conexión a 80.

Después del RST anormal, 78 espera 58,43 segundos antes de enviar una solicitud de establecimiento de conexión a 80.

Ya no los enumeres uno por uno.

4.1.6  Conclusión del análisis

Cuando los datos se transmiten entre 78 y 80, habrá una gran cantidad de paquetes de datos RST de sistemas o nodos desconocidos, y los paquetes de datos causarán un retraso obvio en la solicitud de 78 al mismo tiempo.

4.1.7  Sugerencias de resolución

Dado que el paquete de datos anormal contiene dirección e información de aviso, el dispositivo que envía RST se puede ubicar de acuerdo con esta información. La ubicación del dispositivo también se puede calcular y ubicar en función de la información TTL.

Configure y optimice políticas para dispositivos que envían RST anormales.

4.1.8  Verificación de preguntas

Al analizar el RST anormal, se determinó que fue enviado por el software de control del terminal, y el personal de administración realizó los ajustes correspondientes en el software para que ya no enviara mensajes RST.

Después de descargar la política modificada del sistema de análisis de tráfico NetInside, abra y vea los paquetes de transmisión de datos entre 78 y 80, y no aparecerá ningún paquete RST anormal.

De manera similar, dentro de un período de tiempo, ya no aparecerá un RST anormal, como se muestra en la siguiente figura.

Esto indica que la configuración de la política del software de control del terminal es válida.

4.1.9  Comparación de eficiencia antes y después de la anormalidad

Finalmente, analice y compare las características de transmisión del tráfico antes y después de la anomalía.

4.1.9.1  Comparación del estado de transmisión del tráfico

La siguiente es la transmisión de datos entre 78 y 80 antes del ajuste de política.

La siguiente es la transmisión de datos entre 78 y 80 después del ajuste de política.

En comparación, se puede ver que después de ajustar la política, la transmisión de datos se acelera significativamente y no hay intervalos obvios ni períodos de espera en blanco en el medio.

4.2  El caso de una oficina de electrificación

4.2.1  Antecedentes

Según los comentarios de los usuarios de la Oficina de Electrificación, el sistema de video ha experimentado interrupciones frecuentes durante su uso recientemente, lo que afecta la experiencia de video del usuario y la eficiencia del trabajo.

Para resolver este problema, implementamos el sistema de análisis de tráfico NetInside en la sala de computadoras de la oficina de electrificación y utilizamos el sistema de análisis de tráfico para proporcionar tráfico bruto histórico y en tiempo real. Concéntrese en el análisis de fallas del sistema de video de la Oficina de Electrificación para descubrir las razones específicas de la interrupción del sistema de video.

4.2.2  Fenómeno de falla

Según los comentarios de los usuarios, hubo una interrupción del video a las 7:20 del 8 de febrero de 2023 y el tráfico de video se desconectó a través del terminal de administración del sistema de video, como se muestra en la siguiente figura:

4.2.3  Despliegue del entorno

En la ubicación del conmutador de agregación en el área de video de la sala de computadoras central de la intranet, el modo de derivación de tráfico relevante se refleja en el sistema de análisis de tráfico NetInside, y todo el tráfico de video se recopila y analiza a través de NetInside.

4.2.4  Análisis de fallas

Para este problema, analicémoslo en detalle.

4.2.4.1  Análisis del diagrama de recolección de flujo de equipos

Comuníquese con el personal de la red en el sitio para comprender la estructura real de la red. El siguiente es el diagrama de recopilación de tráfico de la videoconferencia:

El diagrama de recopilación de tráfico incluye principalmente: 1 cliente del sistema de video, 1 servidor del sistema de video y 1 conmutador central;

Las direcciones MAC correspondientes se muestran debajo del cliente del sistema de vídeo y del servidor del sistema de vídeo;

El conmutador central está marcado para mostrar las direcciones MAC de los dos puertos correspondientes;

El conmutador central envía tráfico al sistema de análisis de tráfico mediante duplicación.

4.2.4.2  Ideas de análisis

1. Encuentre paquetes de datos anormales en el sistema de análisis de tráfico y descárguelos.

2. Abra el paquete de datos y busque el contenido del paquete de datos en el momento anormal.

3. Analice el protocolo y el contenido detallado del paquete de datos de video.

4.2.4.3  Análisis detallado

Descarga de paquetes

Según el sistema de análisis de tráfico, se encuentra rápidamente el nodo anormal y se descarga el paquete de datos.

Análisis de tráfico

El sistema de análisis de tráfico deduplica el tráfico reflejado, por lo que el sistema de análisis solo obtiene el tráfico enviado al conmutador central por 10.21.106.11 y el tráfico enviado al conmutador central por 10.21.30.106.

transmisión normal

Según el análisis del paquete de datos, la dirección mac enviada por el cliente 10.21.106.11 al servidor 10.21.30.106 es: Src: HuaweiTe_XX:XX:26 ———> dst: HuaweiTe_XX:XX:01.

Según el análisis del paquete de datos, la dirección mac enviada por el servidor 10.21.30.106 al cliente 10.21.106.11 es: Dst: HuaweiTe_XX:XX:0f <——— src: EdgeCore_XX:XX:a8.

El TTL dentro del paquete es 64.

Al mismo tiempo, el paquete de datos lleva el protocolo VLAN y el ID de VLAN es 59.

transmisión anormal

Según el análisis del paquete de datos, se encontró RST en el momento en que se interrumpió el video y la dirección MAC del paquete de datos era anormal. La dirección MAC enviada por el servidor 10.21.30.106 al cliente 10.21.106.11 fue: src: HuaweiTe_XX:XX:01, dst:HuaweiTe_XX:XX: 26. Normalmente debería ser src: EdgeCore_XX:XX:a8, dst: HuaweiTe_XX:XX:0f.

El TTL dentro del paquete es 127.

No se encontró ningún protocolo VLAN.

La comparación anterior encontró que la dirección MAC del paquete anormal era anormal, no había protocolo VLAN y el recuento de saltos TTL era anormal.

4.2.5  Conclusión del análisis

A través del análisis del sistema anterior, se descubre que cuando se interrumpe el video, aparece un paquete de datos RST anormal en la red, lo que resulta en la interrupción de la conexión TCP entre las dos partes que se comunican.

4.2.6  Recomendaciones

Mediante el análisis de los datos de video de la Oficina de Electrificación, se encuentra que hay mensajes anormales en la red y se recomienda realizar un análisis más detallado en función de la situación real de la red.

5.  Resumen

Además de la tecnología de análisis de captura de paquetes de red, existen otros métodos que pueden ayudar a las empresas a diagnosticar y localizar anomalías rápidamente, como la tecnología de detección de anomalías basada en inteligencia artificial y aprendizaje automático. Esta tecnología puede aprender patrones y reglas comerciales normales analizando datos comerciales y luego detectar datos anormales y tratarlos en consecuencia. Este método tiene las ventajas de alta precisión y alta eficiencia, lo que puede ayudar a las empresas a encontrar y resolver problemas rápidamente.

En resumen, las anomalías de la red son problemas que todas las industrias pueden encontrar y se necesita una solución que pueda diagnosticarse y localizarse rápidamente. La tecnología de análisis de captura de paquetes de red es una solución de uso común que puede ayudar a los usuarios a localizar rápidamente problemas de red. Además, existen otros métodos que pueden ayudar a las empresas a diagnosticar y localizar anomalías rápidamente, como la tecnología de detección de anomalías basada en inteligencia artificial y aprendizaje automático.

Supongo que te gusta

Origin blog.csdn.net/NetInside_/article/details/131172779
Recomendado
Clasificación