Durante la semana 38 de 2026, nuestro SOC analizó 1.304 indicadores SonicWall generados por firewalls TZ270 y TZ370 administrados en diferentes entornos empresariales.
Los principales tipos de evento observados fueron:
- Port Scan Probable
- Port Scan Possible
- SMTP Server on RBL Blacklist
Sin embargo, hay una precisión importante:
1.304 indicadores no significan 1.304 ataques confirmados.
SonicWall detecta y registra actividad. Después, nuestro SOC analiza los logs, el contexto y los sistemas relacionados para determinar si estamos ante:
- actividad automatizada de Internet;
- reconocimiento;
- reputación de un servidor SMTP;
- un falso positivo;
- o una situación que requiere revisión adicional.
Además, cuando el evento no confirma expresamente que una conexión haya sido bloqueada, no damos por hecho que lo haya sido.
En ese caso, revisamos:
puerto + servicio + regla + NAT + destino + actividad posterior.
Indicadores SonicWall: qué sectores estamos protegiendo
Los indicadores SonicWall de esta semana proceden de firewalls administrados en organizaciones de distintos sectores.
Entre ellos:
- administraciones de fincas;
- asesorías contables;
- asesorías laborales;
- despachos de abogados;
- estudios de arquitectura;
- empresas de interiorismo;
- constructoras;
- desarrollos de ingeniería;
- despachos profesionales ubicados en viviendas.
Aunque sus actividades sean diferentes, todas comparten una necesidad:
mantener servicios digitales disponibles sin exponer innecesariamente la infraestructura.
Por eso la administración del firewall no consiste únicamente en instalarlo.
También implica:
- revisar reglas;
- controlar accesos;
- comprobar eventos;
- analizar tendencias;
- mantener firmware;
- revisar VPN;
- estudiar alertas.
Indicadores SonicWall: ¿qué significa Port Scan Possible?
SonicWall identifica Port Scan Possible cuando detecta un patrón compatible con un posible escaneo de puertos. La documentación del fabricante define este evento como una detección de posible port scan.
Un escaneo puede intentar descubrir:
- puertos abiertos;
- servicios publicados;
- VPN;
- aplicaciones web;
- servicios heredados;
- dispositivos expuestos.
Sin embargo, un Port Scan Possible no demuestra por sí solo que exista una intrusión.
Puede representar:
actividad de reconocimiento
pero necesita contexto.
Nuestro SOC revisa, entre otros elementos:
- destino;
- puerto;
- frecuencia;
- regla afectada;
- sistema publicado;
- actividad posterior.
Indicadores SonicWall: ¿qué significa Port Scan Probable?
Port Scan Probable indica un patrón que SonicWall considera más consistente con un escaneo de puertos. El fabricante lo diferencia expresamente de la categoría Possible en sus eventos de seguridad.
Aun así:
probable escaneo ≠ compromiso confirmado.
Por ejemplo, alguien puede explorar:
- puerto 22;
- puerto 443;
- VPN;
- servicios de administración;
sin conseguir acceder.
Por tanto, la pregunta importante no es únicamente:
“¿nos escanearon?”
También debemos responder:
“¿qué encontraron y qué ocurrió después?”
¿Qué hacemos si el escaneo no aparece como bloqueado?
Cuando el log no permite afirmar que el evento fue bloqueado, seguimos investigando.
El proceso puede incluir:
1. Revisar el puerto objetivo
¿Está realmente publicado?
2. Revisar el NAT
¿Existe una traducción activa hacia un sistema interno?
3. Revisar la regla
¿La política permite esa conexión?
4. Revisar el servicio
¿Existe realmente un servicio escuchando?
5. Revisar el sistema destino
¿Generó autenticaciones, errores o actividad posterior?
De esta forma evitamos una conclusión incorrecta como:
“el firewall lo detectó, por tanto necesariamente lo bloqueó”.
Detección y acción son conceptos distintos.
Indicadores SonicWall y SMTP Server on RBL Blacklist
Otro tipo de evento observado durante la semana fue:
SMTP Server on RBL Blacklist
Las RBL —Real-time Black Lists— son listas utilizadas para identificar servidores SMTP asociados con reputación negativa o actividad de spam.
SonicWall puede consultar estos servicios RBL mediante DNS y aplicar políticas sobre conexiones SMTP cuando la función está configurada. Su documentación explica que estas listas contienen direcciones asociadas a servidores desde los que se origina o retransmite spam.
Sin embargo:
estar en una RBL no significa automáticamente que el servidor contenga malware.
Puede deberse a:
- spam;
- servidor comprometido;
- mala reputación histórica;
- dirección reutilizada;
- infraestructura compartida.
Por tanto, es un:
indicador de reputación
que debemos analizar dentro del contexto.
¿Qué revisamos ante un evento RBL?
Nuestro SOC puede comprobar:
- dirección origen;
- servidor de correo;
- sentido de la comunicación;
- servicio utilizado;
- política aplicada;
- otros eventos relacionados.
Además, si se trata de infraestructura legítima conocida, debe investigarse antes de aplicar excepciones.
Añadir indiscriminadamente una dirección a una lista blanca puede eliminar precisamente el control que queremos mantener.
SonicWall dispone de mecanismos específicos de listas blancas y negras para servidores SMTP, pero deben administrarse con criterio.
Indicadores SonicWall: geolocalización de la semana 38
Para este informe hemos analizado la información pública de red asociada a los orígenes registrados, sin publicar las direcciones concretas.
La actividad presenta infraestructura asociada principalmente a:
- Estados Unidos
- Canadá
- Singapur
- Rusia
- Seychelles
Además, aparecen redes pertenecientes a operadores cloud, hosting, ISP y servicios de infraestructura.
Entre los proveedores identificados existen direcciones asociadas a:
- OVHcloud
- DigitalOcean
- Microsoft Azure
- UCloud
- otros operadores de hosting, ISP y redes utilizadas por servicios de anonimización o VPN
Por ejemplo, uno de los bloques observados pertenece a infraestructura de OVHcloud en Canadá, mientras que otros rangos están asociados a DigitalOcean, incluyendo infraestructura utilizada en Estados Unidos y Singapur. También aparece infraestructura registrada en redes de UCloud y servicios de hosting/VPN.
La geolocalización no identifica al atacante
Este punto es fundamental.
Si una dirección se geolocaliza en:
Canadá
no podemos afirmar:
“el atacante está en Canadá”.
La dirección puede corresponder a:
- VPS;
- servidor cloud;
- VPN;
- proxy;
- infraestructura comprometida.
Además, las bases de geolocalización ofrecen una ubicación aproximada del recurso de red, no la ubicación física de la persona que origina la actividad.
Por tanto, en nuestros informes hablamos de:
infraestructura geolocalizada o asociada a un país
y no de:
nacionalidad o ubicación real del atacante.
Indicadores SonicWall y proveedores cloud
Que aparezca infraestructura de:
OVHcloud
DigitalOcean
o:
Microsoft Azure
tampoco significa que esos proveedores estén atacando.
Los servicios cloud permiten desplegar servidores de forma rápida.
Eso los convierte en herramientas útiles para:
- empresas;
- desarrolladores;
- investigadores;
pero también pueden ser alquilados o comprometidos por terceros.
Por tanto:
proveedor de hosting ≠ atacante.
Nuestro SOC utiliza la información del proveedor como:
contexto de red
no como atribución.
¿Por qué vemos tantos escaneos desde hosting?
Los centros de datos permiten disponer de:
- conectividad elevada;
- servidores disponibles permanentemente;
- múltiples regiones;
- automatización.
Por ello, es habitual encontrar tráfico automatizado procedente de infraestructura cloud.
Parte puede ser:
- legítima;
- investigación;
- crawlers;
- monitorización.
Otra parte puede corresponder a:
- reconocimiento;
- bots;
- escaneo de vulnerabilidades.
La diferencia se determina estudiando:
comportamiento + destino + frecuencia + contexto.
Indicadores SonicWall: 1.304 eventos no equivalen a compromisos
Este es uno de los errores más frecuentes al interpretar informes de firewall.
Durante la semana hemos analizado:
1.304 indicadores SonicWall
pero eso no significa:
1.304 equipos comprometidos
ni:
1.304 ataques exitosos.
El firewall está precisamente situado en el perímetro donde recibe constantemente tráfico procedente de Internet.
Parte de ese tráfico será normal.
Otra parte será ruido.
Y otra parte puede necesitar revisión.
El trabajo consiste en diferenciarlos.
Firewall instalado frente a firewall administrado
Existen dos escenarios muy distintos.
Firewall instalado
Está encendido.
Tiene unas reglas.
Filtra tráfico.
Firewall administrado
Además:
- se revisan logs;
- se analiza actividad;
- se mantienen reglas;
- se revisan servicios expuestos;
- se controla VPN;
- se estudian alertas;
- se actualiza.
Esta diferencia es especialmente importante en empresas que almacenan:
- información económica;
- documentación de clientes;
- datos personales;
- proyectos;
- contratos.
Indicadores SonicWall en administraciones de fincas
Una administración de fincas puede trabajar diariamente con:
- propietarios;
- proveedores;
- recibos;
- cuentas bancarias;
- documentación.
Por tanto, un acceso no autorizado puede afectar tanto a la empresa como a múltiples comunidades.
La protección del perímetro es una de las capas necesarias.
Indicadores SonicWall en asesorías
Una asesoría contable o laboral puede manejar:
- nóminas;
- contratos;
- DNI;
- datos fiscales;
- información bancaria.
Además, depende intensamente del correo electrónico y de servicios online.
Por eso conviene proteger y monitorizar:
usuarios + equipos + Microsoft 365 + red + firewall.
Indicadores SonicWall en despachos de abogados
Los despachos jurídicos trabajan con documentación que puede tener un elevado nivel de confidencialidad.
Por tanto, una exposición innecesaria de:
- RDP;
- VPN;
- aplicaciones;
- servidores;
puede aumentar el riesgo.
El firewall permite reducir superficie, pero debe configurarse y revisarse correctamente.
Indicadores SonicWall en arquitectura e interiorismo
Estos entornos suelen trabajar con:
- proyectos;
- planos;
- documentación;
- NAS;
- estaciones de trabajo;
- acceso remoto.
Además, los archivos pueden tener gran tamaño y un importante valor profesional.
Por ello, seguridad y rendimiento deben mantenerse equilibrados.
Indicadores SonicWall en constructoras e ingeniería
Las constructoras y empresas de ingeniería pueden disponer de:
- proyectos;
- presupuestos;
- documentación técnica;
- accesos remotos;
- servicios alojados.
En consecuencia, el firewall debe integrarse dentro de una estrategia más amplia.
No debería ser una caja aislada instalada hace años.
Indicadores SonicWall en despachos profesionales desde el hogar
Un despacho profesional ubicado en una vivienda también puede manejar información empresarial sensible.
Sin embargo, el entorno doméstico suele disponer de:
- dispositivos personales;
- IoT;
- televisión;
- móviles;
- invitados.
Por eso la segmentación de red adquiere mayor importancia.
La infraestructura profesional debe separarse siempre que sea posible del resto de dispositivos.
Reducir superficie de ataque
La primera medida frente a los escaneos de puertos es sencilla:
no publicar aquello que no sea necesario.
Conviene revisar periódicamente:
- NAT;
- reglas WAN;
- servicios publicados;
- VPN;
- accesos administrativos.
Una regla antigua puede permanecer activa durante años después de dejar de utilizarse.
Eso crea superficie de ataque innecesaria.
Evitar RDP directamente expuesto
Siempre que sea posible, recomendamos evitar publicar directamente RDP en Internet.
Resulta preferible utilizar:
- VPN;
- MFA;
- controles de identidad;
- acceso restringido.
Un servicio que no puede alcanzarse directamente desde Internet ofrece menos oportunidades a escáneres automatizados.
Indicadores SonicWall y VPN
La VPN también debe administrarse.
Conviene revisar:
- usuarios;
- cuentas antiguas;
- MFA;
- permisos;
- firmware.
No es suficiente con disponer de una VPN.
También hay que controlar:
quién puede utilizarla.
La actualización del firewall también importa
Un firewall es un sistema de seguridad.
Pero también es:
software + firmware + servicios.
Por tanto, necesita:
- mantenimiento;
- actualizaciones;
- revisión de vulnerabilidades.
Mantener firmware obsoleto durante años puede aumentar el riesgo.
Indicadores SonicWall integrados con SIEM Wazuh
Los registros del firewall pueden integrarse dentro de nuestro SIEM Wazuh para empresas.
Así podemos relacionar:
SonicWall
con:
- Windows;
- macOS;
- Linux;
- servidores;
- NAS;
- Microsoft 365;
- Endpoint;
- red.
De esta forma, un evento perimetral puede analizarse junto a lo ocurrido posteriormente en el destino.
Ejemplo de correlación
Imagine:
SonicWall → posible escaneo
Después:
Servidor → autenticación fallida
Después:
Endpoint → comportamiento inesperado
La primera alerta por sí sola puede ser habitual.
Sin embargo, la secuencia completa merece más atención.
Por eso utilizamos correlaciones personalizadas.
El SIEM no sustituye al SOC
Wazuh puede:
- recoger;
- almacenar;
- buscar;
- aplicar reglas;
- correlacionar.
Después nuestro SOC debe analizar:
- activo;
- usuario;
- servicio;
- comportamiento;
- contexto.
La automatización es importante.
Sin embargo, interpretar correctamente la información sigue siendo fundamental.
Indicadores SonicWall y 400 días de histórico
En nuestros servicios podemos conservar hasta 400 días de logs de las fuentes integradas.
Eso permite realizar análisis retrospectivos.
Por ejemplo:
¿habíamos visto anteriormente esta infraestructura?
¿qué puerto buscaba?
¿qué ocurrió después?
¿hay relación con un incidente actual?
Esta capacidad resulta especialmente útil cuando una amenaza se conoce meses después.
Buscar indicadores retrospectivamente
Supongamos que hoy aparece una nueva infraestructura asociada a una campaña de ciberseguridad.
Si conservamos los logs podemos comprobar:
¿contactó con nosotros anteriormente?
Con solo siete días de datos:
probablemente no podremos responder.
Por eso el histórico aporta valor para:
- incidentes;
- threat hunting;
- auditorías;
- investigación.
¿Qué son realmente los indicadores de compromiso?
En seguridad se utiliza frecuentemente el término IoC —Indicator of Compromise—.
Sin embargo, un indicador debe interpretarse con cautela.
Puede ser:
- dirección;
- dominio;
- hash;
- patrón;
- evento.
Que aparezca un indicador no significa automáticamente que la organización esté comprometida.
Es:
una señal que debe ser contextualizada.
Por eso denominamos a estos eventos indicadores analizados y no:
ataques confirmados.
Indicadores SonicWall: análisis SOC frente a acumulación de alertas
Un firewall puede generar una enorme cantidad de información.
Si nadie la revisa, podemos terminar con:
miles de logs almacenados
pero poca visibilidad real.
Nuestro enfoque busca transformar:
logs
en:
contexto.
Y después:
contexto
en:
decisiones.
La importancia de saber qué ocurrió después
Un escaneo de puertos no es necesariamente el final de la investigación.
Podemos preguntar:
¿existía un servicio?
Si la respuesta es no:
el riesgo puede ser bajo.
Si la respuesta es sí:
¿estaba actualizado?
Después:
¿hubo conexiones?
Y:
¿apareció actividad interna?
Ese encadenamiento permite evaluar mejor el riesgo.
Indicadores SonicWall y ciberseguridad por capas
Un firewall no debería ser la única defensa.
Una estrategia empresarial puede incluir:
🔥 firewall
💻 Endpoint / EDR
🔐 MFA
☁️ Microsoft 365
📊 SIEM Wazuh
🔎 SOC
💾 backups
🗄️ histórico de logs
Puede consultar nuestras soluciones de Endpoint y firewall para empresas.
También puede conocer nuestros servicios de ciberseguridad para empresas.
Indicadores SonicWall: resumen de la semana 38
Durante la semana 38 de 2026, nuestro SOC analizó:
1.304 indicadores SonicWall
procedentes de firewalls:
TZ270 y TZ370
Los principales eventos fueron:
Port Scan Possible
Port Scan Probable
SMTP Server on RBL Blacklist
Además, el análisis de infraestructura mostró redes asociadas con:
OVHcloud + DigitalOcean + Microsoft Azure + UCloud + otros proveedores de hosting, ISP y servicios de infraestructura
y localizaciones de red distribuidas entre:
Norteamérica + Europa/Asia + Rusia + Singapur + Seychelles, entre otras ubicaciones.
Sin embargo:
geolocalización ≠ ubicación del atacante
y:
proveedor cloud ≠ atacante.
Indicadores SonicWall: conclusión
Los 1.304 indicadores SonicWall analizados durante la semana 38 muestran nuevamente la cantidad de actividad que recibe diariamente el perímetro de una empresa.
Entre los eventos observados encontramos:
- posibles escaneos;
- escaneos probables;
- reputación SMTP.
Sin embargo, el verdadero valor no está en afirmar:
“hemos recibido 1.304 ataques”.
Eso sería incorrecto.
El valor está en poder determinar:
qué ocurrió
qué servicio estaba implicado
qué política se aplicó
si la conexión fue bloqueada
qué ocurrió posteriormente
Por eso nuestro modelo combina:
SonicWall administrado
SIEM Wazuh
correlaciones personalizadas
SOC
hasta 400 días de histórico
El objetivo es convertir telemetría en información útil para proteger administraciones de fincas, asesorías, despachos jurídicos, arquitectura, interiorismo, constructoras, ingeniería y otros entornos profesionales.
Porque un firewall no debería ser únicamente:
un dispositivo que está encendido.
Debería ser:
una fuente de información que alguien administra, analiza y mantiene.
📩 Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre indicadores SonicWall
¿Cuántos indicadores SonicWall se analizaron en la semana 38?
Nuestro SOC analizó 1.304 indicadores procedentes de firewalls SonicWall TZ270 y TZ370.
¿1.304 indicadores significan 1.304 ataques?
No. Los eventos necesitan contexto antes de considerarse ataques o incidentes confirmados.
¿Qué es Port Scan Possible?
Es un evento que SonicWall utiliza cuando detecta un patrón compatible con un posible escaneo de puertos.
¿Qué es Port Scan Probable?
Es una detección con un patrón más consistente con actividad de escaneo. Aun así, no demuestra por sí sola un compromiso.
¿Qué significa SMTP Server on RBL Blacklist?
Indica que un servidor SMTP aparece en una lista de reputación utilizada para identificar fuentes asociadas con spam.
¿Un evento RBL significa que existe malware?
No. Es una señal de reputación y necesita análisis adicional.
¿SonicWall bloquea todos los eventos detectados?
No debe asumirse. La acción concreta debe comprobarse en los logs y en la política aplicada.
¿Qué se revisa cuando no consta un bloqueo?
Puerto, servicio, NAT, regla, destino y actividad posterior.
¿De qué países procedía la infraestructura observada?
La geolocalización aproximada incluyó, entre otras ubicaciones, Estados Unidos, Canadá, Singapur, Rusia y Seychelles.
¿Eso indica dónde está el atacante?
No. La dirección puede pertenecer a hosting, VPN, proxy o infraestructura comprometida.
¿Qué proveedores aparecieron?
Entre las redes verificadas encontramos infraestructura asociada a OVHcloud, DigitalOcean, Microsoft Azure y UCloud, además de otros operadores.
¿Que aparezca OVHcloud significa que OVHcloud está atacando?
No. Significa únicamente que determinada infraestructura está alojada o anunciada por esa red.
¿Por qué los atacantes utilizan hosting cloud?
Porque permite desplegar infraestructura rápidamente y disponer de conectividad. Sin embargo, los mismos servicios también se utilizan legítimamente por millones de usuarios.
¿Qué aporta integrar SonicWall con Wazuh?
Permite centralizar los logs y relacionarlos con información de otros sistemas.
¿Qué aporta el SOC?
Nuestro SOC analiza el contexto y decide qué eventos necesitan investigación o actuación.
¿Cuánto histórico se puede mantener?
Hasta 400 días de logs de las fuentes integradas en nuestros servicios.
¿Para qué sirven 400 días?
Para investigaciones retrospectivas, auditorías, correlaciones y threat hunting.
¿Un firewall necesita mantenimiento?
Sí. Deben revisarse firmware, reglas, VPN, NAT, usuarios y servicios expuestos.
¿Es recomendable publicar RDP directamente en Internet?
En general es preferible evitarlo y utilizar mecanismos como VPN, MFA y restricciones de acceso.
¿Qué sectores supervisamos con estos SonicWall?
Administraciones de fincas, asesorías contables y laborales, despachos de abogados, arquitectura, interiorismo, constructoras, ingeniería y despachos profesionales, entre otros.
¿Cuál es la principal ventaja de un SonicWall administrado?
Que no solo filtra tráfico: sus eventos se revisan, contextualizan y pueden relacionarse con el resto de la infraestructura.
Documentación oficial de SonicWall sobre RBL
