Bienvenido al Panel de Control

1) Revisión de seguridad a nivel ISP (núcleo/acceso)

• Correlacionar fallos de DNS, HTTP/HTTPS y latencia para detectar degradación en salida o tránsito.
• Confirmar estabilidad de resolutores autorizados y detectar respuestas anómalas (timeouts, vacíos o NXDOMAIN inesperado).
• Identificar segmentos con rachas de error por RB/POP y priorizar mitigación antes de que escalen tickets.
• Verificar que servicios críticos del ISP expongan solo puertos y protocolos necesarios.

2) Revisión de red cliente (detrás de la ONT)

• Ejecutar Pruebas de campo para validar conectividad real desde vivienda y comportamiento bajo carga.
• Detectar latencia alta, pérdida intermitente o resolución DNS inestable en LAN del cliente.
• Revisar exposición innecesaria: UPnP activo, puertos abiertos no autorizados, administración remota habilitada sin control.
• Verificar segmentación y credenciales: WiFi seguro (WPA2/WPA3), cambio de claves por defecto, aislamiento cuando aplique.

3) Vulnerabilidades prioritarias y corrección

• Críticas: credenciales por defecto, gestión remota abierta a Internet, puertos sensibles expuestos.
• Altas: DNS inseguro o inconsistente, cifrados obsoletos, firmware desactualizado en CPE/ONT.
• Medias: reglas laxas de NAT/firewall, falta de listas de control por rol/dispositivo.
• Bajas: hardening pendiente (desactivar servicios no usados, fortalecer políticas internas).

Flujo recomendado de operación segura

1. Detectar evento en mediciones de sonda.
2. Determinar si el origen es ISP o cliente detrás de ONT.
3. Aplicar corrección técnica (red, DNS, firewall, firmware, configuración CPE).
4. Reejecutar prueba y dejar evidencia en detalle JSON/resultado de campo.

Ingesta al dashboard

• Endpoint: POST /api/dashboard/sondas/ingest (mismo origen que el dashboard, vía nginx).
• Query: tenant_id debe coincidir con el perfil activo (FibraRed: T01-Fibrared).
• Opcional: si la API define SONDA_INGEST_TOKEN, enviar cabecera X-Sonda-Token.
• Agente: en config.yaml, webhook_url con la URL completa incluyendo ?tenant_id=….

Identidad de la sonda

probe_id, probe_name, RB y ubicación deben ser coherentes con el catálogo en base de datos (fibrared_sondas). Nuevas sondas o cambios de RB pueden requerir migración SQL o endpoint de administración cuando esté disponible.

Próximos pasos (UI)

Formularios para umbrales por tenant, repetición de alertas y destinos (correo, Telegram, webhook) se integrarán aquí cuando la API de configuración esté lista.

Planeado

• Latencia y pérdida por destino (HTTP, ping, DNS) con umbrales por tipo.
• Rachas de fallos consecutivos antes de alertar (evitar ruido).
• Horarios y ventanas de mantenimiento por RB o por sonda.
• Canales: correo, Telegram, webhook genérico hacia n8n.
• Resumen diario / semanal para NOC.

Hasta activar el backend de alertas, use monitorización externa o flujos n8n apuntando a los mismos datos o webhooks duplicados desde el agente si su infraestructura lo permite.

Estados y tipos de prueba

• HTTP/HTTPS: disponibilidad y tiempo hasta primer byte o código esperado; útil para portales, APIs internas y enlaces críticos.
• Ping / latencia: conectividad IP y RTT; no implica que la aplicación responda bien.
• DNS: resolución correcta y tiempos; detecta fallos de DNS interno o carrier.
• MTR / traceroute: ayuda a localizar pérdida en un salto (cuando el agente lo envíe).

Interpretación

Compare la misma métrica en el tiempo (tendencia) y entre sondas (RB1 vs RB3) para distinguir incidente de acceso local vs núcleo o salida a Internet. Cruce con tickets y cortes anunciados reduce falsos positivos.

Datos que suelen hacer falta

• Topología y rol del host de la sonda (CT, OLT, segmento VLAN).
• Horarios de mantenimiento y ventanas de corte programado.
• Correlación con CRM/tickets (misma zona o mismo POP).
• Histórico de ancho de banda o SNMP si está disponible en otra herramienta.