Reporte de evento en Servidores KAFKA PRD y UAT

13 • 12 • 2022

1
 Versión:
1.0

Preparado por:
Marvin Guzman
Infrastructure Support Engineer

Ricardo Guidos
Infrastructure Support Engineer

I. REGISTRO DE CAMBIOS

Fecha Autor Rol Email Empresa Versión Referencia de cambios

Marvin Infraestructure mguzman@hightech

14/12/2022 Hightech 1.0 Versión inicial del documento
Guzman support -corp.com

II. REVISORES

Fecha Autor Rol Email Empresa Versión Referencia de cambios

III. DISTRIBUCIÓN

Fecha Autor Rol Email Empresa Versión Referencia

2
TABLA DE CONTENIDO

INTRODUCCIÓN .......................................................................................................................... 4
SERVIDORES INTERVINIENTES ............................................................................................. 5
PROCESO DE ANALISIS ........................................................................................................... 6
SOLUCIÓN DEL EVENTO: ...................................................................................................... 10
PLAN DE PREVENCIÓN .......................................................................................................... 10

3
INTRODUCCIÓN

La revisión del proceso de análisis de causa principal es un método de evaluación

estructurado que identifica las causas principales para un evento indeseado y
acciones adecuadas para prevenir de forma recurrente.

El análisis de las causas principales debería continuar hasta que todos los factores
que intervienen en la organización han sido identificados o hasta que han sido
determinados y resueltos.

El método determina:
• ¿Qué sucedió?
• ¿Cómo sucedió?
• ¿Por qué sucedió?

Y a partir de las respuestas a las anteriores interrogantes proponer medidas

correctivas y preventivas, teniendo el panorama completo a corto y largo plazo.

4
SERVIDORES INTERVINIENTES

La infraestructura de Kafka se compone de los siguientes servidores afectados:

Nodo / IP / DNS Servidor / SO Programa / rpm

192.168.162.241 Red Hat Enterprise Linux Kafka PRD

192.168.105.200 Red Hat Enterprise Linux Kafka UAT

5
PROCESO DE ANALISIS

¿Qué sucedió?

El día 13/12/2022 se reportó problemas de encolamiento y conectividad en los

aplicativos Kafka en servidor srv-vmptmykafka-01 de PRD y así mismo en el
servidor srv-vmp-tmykafka-uat-01 de UAT.

¿Cómo Sucedió?

• Revisiones realizadas

Nos conectamos a las 6:55 PM Martes 13 de diciembre 2022 ya que se nos

notifica que requieren apoyo con las validaciones para verificar estado del
servidor a nivel de recursos y porque se generaba la falla de conectividad en
los aplicativos Kafka. Realizamos las siguientes validaciones en los dos
servidores que presentaban este inconveniente y se detectó que el firewall
estaba denegando todas las conexiones:

¿Por qué sucedió?

Servidor srv-vmp-tmykafka-01 192.168.162.241

El problema se causó porque se encendió el firewall de los dos servidores.

Evidencia del día que se encendió el firewall fecha 13-11-2022, se realiza

debido a la realización del reporte de formato de seguridad de TIGO HN indica
que el firewall debe estar funcional.

6
Evidencia de la fecha desde cuando esta apagado el firewall en el servidor la cual
es: 15 de noviembre 2022.

Evidencia del usuario que hizo Login el día que apagaron el firewall (oscar.garcia)
únicamente se registra en el servidor que ese usuario hizo login en esa fecha (15-
11-2022).

Evidencia del login en el /var/log/messages del usuario oscar.garcia para el día 15

de noviembre 2022. Usuario que fue solicitado creación que no fue gestionado por
HTC.

7
Datos de contacto
Nombre: Oscar Javier García Alvarez
Teléfono: +503 78850040
Correo: ogarcia@rinnovocorp.com

Evidencia de creación del usuario oscar.garcia en el servidor Kafka PRD Usuario

que fue solicitado creación que no fue gestionado por HTC.

Servidor srv-vmp-tmykafka-01 192.168.162.241

Evidencia del día que se encendió el firewall, se realiza debido a la realización

del reporte de formato de seguridad indica que el firewall debe estar funcional.

Evidencia que el firewall se dejó abajo luego de la instalación de la VM pero sin

embargo no se logra evidenciar quien bajo el firewall ya que en los logs del sistema
no se logra evidenciar quien bajo por la cantidad de logs que se generan se
eliminaron los logs antiguos.

8
En la creación del servidor se evidencia que el servidor contaba con el firewall
funcionando, cabe mencionar que la creación de la VM se realizó en los rimeros
días del mes de octubre 2022.

Esta es la evidencia del documento que se entrega a TIGO HN cuando se crean

los servidores piden la realización de un reporte en los que uno de los puntos es
el estado del firewall.

9
SOLUCIÓN DEL EVENTO:

Se procedió a configurar reglas permanentes para los puertos de Kafka en ambos

servidores y se dejó en la configuración del SO que, aunque reinicien el servidor
el firewall va a iniciar en automático.

PLAN DE PREVENCIÓN

No se procederá al encendido de ningún firewall después que ya se realizo la

entrega y en caso se encuentre un firewall apagado solo se informara por correo
el estado de ese servidor y que sea el personal de TIGO HN el encargado de
realizar las remediaciones necesarias o que se le solicite a HTC que solucione
ese fallo de seguridad, pero de parte de TIGO HN deberán de proporcionar el
horario para la actividad y los puertos que se necesita aperturar en el firewall.

10