Durante la semana 37 de 2026, nuestro SOC ha analizado 2.195 indicadores de compromiso SonicWall generados por firewalls SonicWall TZ270 y TZ370 que gestionamos en diferentes infraestructuras empresariales.
Los eventos registrados durante el periodo se concentraron principalmente en tres categorías:
- Port Scan Possible
- Port Scan Probable
- SMTP Server on RBL Blacklist
Pero antes de continuar hay una diferencia fundamental:
2.195 indicadores no significan 2.195 ataques confirmados.
Tampoco podemos afirmar que los 2.195 eventos hayan sido bloqueados si el registro concreto no confirma la acción aplicada por el firewall.
SonicWall detecta y registra actividad.
Después, nuestro SOC analiza los logs, revisa el contexto y determina si estamos ante:
- tráfico legítimo;
- escaneo automatizado;
- infraestructura de hosting;
- reconocimiento;
- problemas de reputación;
- actividad sospechosa;
- o un evento que requiere intervención.
Ese análisis posterior es lo que convierte miles de registros técnicos en información útil para una empresa.
¿Qué son los indicadores de compromiso SonicWall?
Utilizamos el término indicadores de compromiso SonicWall para agrupar señales y eventos de seguridad que pueden merecer análisis.
Sin embargo:
indicador de compromiso ≠ compromiso confirmado.
Una dirección perteneciente a un centro de datos puede aparecer realizando un escaneo.
Eso puede ser relevante.
Pero no demuestra por sí solo que:
- haya conseguido acceder;
- exista malware;
- se haya comprometido el firewall;
- se haya comprometido un servidor.
Por tanto, analizamos el evento dentro de su contexto.
¿Qué ocurrió durante la semana 37?
Los eventos detectados estuvieron relacionados principalmente con:
Port Scan Possible
Actividad que presenta características compatibles con un posible escaneo de puertos.
Port Scan Probable
SonicWall ha encontrado un patrón con mayor grado de coincidencia con comportamiento de exploración de servicios.
SMTP Server on RBL Blacklist
Una comunicación relacionada con un servidor SMTP cuya dirección aparece incluida en una lista de reputación o bloqueo.
Son tres escenarios diferentes.
Por tanto, también necesitan respuestas distintas.
Port Scan Possible: ¿qué significa realmente?
Un Port Scan Possible indica que el firewall ha observado actividad que podría corresponder con una exploración de puertos o servicios.
Los escaneos son extremadamente habituales en Internet.
Existen sistemas automatizados que recorren constantemente direcciones públicas buscando:
- SSH;
- RDP;
- VPN;
- paneles web;
- correo;
- cámaras;
- NAS;
- servicios antiguos;
- aplicaciones expuestas.
El objetivo puede ser simplemente identificar:
qué responde detrás de una dirección IP.
Un escaneo de puertos no significa que hayan entrado
Esta diferencia es esencial.
Podemos tener:
Internet → intento sobre un puerto → firewall
sin que exista ningún acceso al sistema interno.
Por tanto:
escaneo detectado ≠ intrusión confirmada.
Pero tampoco debemos ignorarlo automáticamente.
Hay que valorar:
- puerto objetivo;
- servicio;
- regla del firewall;
- destino;
- frecuencia;
- comportamiento posterior.
¿Qué significa Port Scan Probable?
Un evento Port Scan Probable indica una actividad que SonicWall considera más consistente con un patrón de escaneo.
Es decir, puede observarse una secuencia de intentos sobre:
diferentes puertos
o:
diferentes servicios
dentro de un determinado periodo.
Puede tratarse de herramientas automáticas de reconocimiento.
La finalidad habitual de este tipo de actividad es descubrir superficie expuesta.
¿Qué busca un atacante durante un escaneo?
Podría estar intentando saber:
¿hay una VPN?
¿existe RDP?
¿responde SSH?
¿hay un servidor web?
¿qué producto parece estar publicado?
Después puede comparar los servicios encontrados con vulnerabilidades conocidas.
Por eso la primera medida defensiva es muy sencilla:
no publicar en Internet aquello que no necesita estar publicado.
Reducir la superficie de ataque
Un firewall empresarial no debería convertirse simplemente en:
Internet → todas las aplicaciones internas.
Cada regla publicada debería responder a una necesidad concreta.
Conviene revisar periódicamente:
- reglas antiguas;
- NAT;
- servicios publicados;
- VPN;
- puertos;
- accesos de proveedores.
Una regla que dejó de utilizarse hace dos años sigue siendo superficie de ataque si continúa activa.
Indicadores de compromiso SonicWall y geolocalización
El análisis de la infraestructura asociada a los eventos de esta semana muestra actividad procedente de redes distribuidas por distintas regiones.
Entre las localizaciones observadas aparecen principalmente infraestructuras asociadas a:
🌍 Europa
🌎 Norteamérica
🌏 Asia
Entre los países o registros de red presentes encontramos ejemplos vinculados a:
- Países Bajos;
- Francia;
- Alemania;
- Estados Unidos;
- Rusia;
- diferentes ubicaciones asiáticas.
Pero debemos hacer una advertencia importante.
El país de una IP no identifica al atacante
Una IP geolocalizada en Estados Unidos no significa:
“el atacante está en Estados Unidos”.
Una IP registrada en Países Bajos tampoco significa:
“el ataque procede de una persona situada físicamente allí”.
Muchas de las direcciones observadas pertenecen a:
- VPS;
- cloud;
- servidores dedicados;
- proveedores de hosting;
- infraestructura de centros de datos.
Un tercero puede contratar esa infraestructura desde prácticamente cualquier lugar.
Por tanto:
geolocalización de la IP ≠ ubicación real del operador.
Proveedores cloud y hosting observados
Dentro de las redes relacionadas con la actividad analizada aparecen infraestructuras asociadas a proveedores como:
- Microsoft Azure
- Google Cloud
- DigitalOcean
- OVHcloud
- DataCamp
- otros operadores de hosting y centros de datos europeos e internacionales.
También aparecen rangos de hosting registrados en Países Bajos y redes registradas en Rusia.
En el caso de OVHcloud, el proveedor mantiene infraestructura geolocalizada en distintos países europeos, entre ellos Francia, Alemania, España, Países Bajos y otros mercados europeos.
Que aparezca OVHcloud, Azure o Google Cloud no convierte al proveedor en atacante
Este punto también es fundamental.
Si detectamos una conexión desde infraestructura de:
Azure
Google Cloud
DigitalOcean
o:
OVHcloud
no significa que Microsoft, Google, DigitalOcean u OVHcloud estén realizando el ataque.
Simplemente significa que la dirección pública pertenece o está asociada a infraestructura alojada en esa red.
Los proveedores cloud alojan millones de servicios legítimos.
También pueden ser utilizados temporalmente por terceros para:
- escaneo;
- proxies;
- automatización;
- servidores comprometidos;
- infraestructura maliciosa.
El análisis debe centrarse en el comportamiento.
No en culpar al proveedor.
¿Por qué se utiliza tanto el hosting para escanear Internet?
Un VPS tiene varias ventajas para quien quiere automatizar actividad.
Puede ofrecer:
- conectividad permanente;
- ancho de banda;
- direcciones públicas;
- despliegue rápido;
- automatización;
- bajo coste.
Por eso es habitual observar tráfico de reconocimiento procedente de centros de datos.
Y no todo es necesariamente malicioso.
También existen:
- buscadores;
- servicios de monitorización;
- investigadores;
- motores de inventario de Internet.
Por tanto, volvemos a necesitar contexto.
SMTP Server on RBL Blacklist
Otro de los eventos detectados durante la semana 37 fue:
SMTP Server on RBL Blacklist
Una RBL es una lista utilizada para asociar direcciones o servidores con problemas de reputación relacionados principalmente con correo.
Puede aparecer cuando un servidor ha sido relacionado con:
- spam;
- campañas abusivas;
- equipos comprometidos;
- mala reputación previa;
- infraestructura reutilizada.
Sin embargo:
estar en una RBL no demuestra automáticamente la presencia de malware.
¿Qué hacemos con un evento SMTP en una RBL?
Debemos comprobar:
- quién inicia la comunicación;
- hacia qué servicio;
- si corresponde a correo esperado;
- reputación;
- frecuencia;
- existencia de eventos relacionados.
Por ejemplo:
un servidor legítimo podría encontrarse temporalmente en una lista de reputación.
Eso no es lo mismo que:
un endpoint interno comunicándose de forma inesperada con infraestructura de mala reputación.
El contexto cambia completamente la prioridad.
¿Los 2.195 eventos fueron bloqueados?
No debemos afirmarlo sin revisar el campo de acción de cada evento.
Esta precisión es importante.
Una detección del firewall puede terminar en diferentes situaciones:
bloqueado
descartado
permitido por una política
registrado
dependiendo del evento y de la configuración.
Por tanto, nuestro análisis no parte de:
“si SonicWall lo ha detectado, está bloqueado”.
Partimos de:
“SonicWall lo ha registrado; ahora comprobamos qué ocurrió”.
¿Qué revisamos cuando el evento no aparece bloqueado?
Si un evento relacionado con un posible escaneo no muestra una acción de bloqueo clara, revisamos varios puntos.
1. Puerto de destino
¿Qué servicio estaban buscando?
No es igual:
HTTPS
que:
RDP
o:
SSH.
2. Existencia de NAT
Comprobamos si existe realmente una publicación hacia un sistema interno.
3. Regla aplicada
¿Qué política permitió o gestionó la conexión?
4. Estado del servicio
¿Había algo escuchando detrás?
5. Eventos posteriores
¿La misma dirección realizó más conexiones?
6. Logs del destino
¿El servidor o endpoint registró autenticación o actividad?
Esta última parte resulta especialmente importante.
El firewall ve una parte de la historia
Imagine esta secuencia:
Firewall → posible escaneo
Eso por sí solo aporta una señal.
Pero después encontramos:
Windows → autenticación fallida repetida
y:
Endpoint → comportamiento anómalo
Entonces el contexto cambia.
Por eso integramos los logs del firewall con otras fuentes.
SonicWall + SIEM Wazuh
Los logs generados por SonicWall pueden centralizarse en nuestro entorno de SIEM Wazuh.
Esto permite relacionarlos con información procedente de:
- Windows;
- Linux;
- macOS;
- servidores;
- NAS;
- Microsoft 365;
- antivirus;
- infraestructura UniFi.
Puede conocer nuestro servicio de SIEM Wazuh para empresas.
Un ejemplo de correlación
Imaginemos:
10:14 → SonicWall detecta actividad externa
Después:
10:15 → Windows registra intentos de autenticación
Posteriormente:
10:17 → Endpoint detecta un proceso sospechoso
Individualmente son tres eventos.
Relacionados temporalmente sobre un mismo activo pueden contar otra historia.
Eso es lo que buscamos mediante:
correlaciones personalizadas.
No todas las empresas necesitan las mismas correlaciones
Nuestro SonicWall administrado está desplegado en entornos como:
- administraciones de fincas;
- asesorías contables;
- asesorías laborales;
- despachos de abogados;
- arquitectura;
- interiorismo;
- constructoras;
- desarrollos de ingeniería;
- despachos profesionales ubicados en viviendas.
Las necesidades son diferentes.
Indicadores de compromiso SonicWall en administraciones de fincas
Una administración de fincas puede depender de:
- Microsoft 365;
- programa de gestión;
- banca;
- servidores;
- acceso remoto.
Aquí puede ser especialmente importante supervisar:
- VPN;
- accesos;
- correo;
- servicios publicados.
Asesorías contables y laborales
En una asesoría encontramos frecuentemente:
- certificados digitales;
- Seguridad Social;
- banca;
- documentación de clientes;
- nóminas.
Un incidente puede tener impacto operativo y de confidencialidad.
Por eso firewall y endpoint deben formar parte de una estrategia más amplia.
Despachos de abogados
La confidencialidad es especialmente importante.
Pueden existir:
- expedientes;
- comunicaciones;
- documentación jurídica;
- datos personales.
El firewall ayuda a reducir exposición, pero también necesitamos:
- Endpoint / EDR;
- MFA;
- copias;
- monitorización.
Arquitectura, interiorismo, construcción e ingeniería
Estos sectores pueden disponer de:
- NAS;
- archivos de gran tamaño;
- documentación técnica;
- proyectos;
- acceso remoto;
- estaciones de trabajo especializadas.
En muchos casos la continuidad operativa es tan importante como la confidencialidad.
Por eso no podemos valorar únicamente:
“¿nos han robado datos?”
También:
“¿podemos seguir trabajando?”
Despachos profesionales en vivienda
Un despacho situado en una vivienda puede seguir manejando información empresarial.
Por tanto:
estar en casa no convierte la red en doméstica desde el punto de vista del riesgo.
Cuando existen:
- información de clientes;
- acceso remoto;
- Microsoft 365;
- aplicaciones profesionales;
conviene separar correctamente:
red profesional
de:
dispositivos personales e IoT.
SonicWall TZ270 y TZ370
Los modelos SonicWall TZ270 y TZ370 permiten desplegar seguridad perimetral en pequeñas y medianas empresas.
Pero el hardware por sí solo no resuelve la seguridad.
Un firewall necesita:
- firmware actualizado;
- reglas revisadas;
- objetos limpios;
- VPN administrada;
- logs;
- seguimiento;
- copias de configuración.
Una instalación que no se vuelve a revisar durante años termina acumulando riesgo.
Firewall instalado frente a firewall administrado
Existe una diferencia importante.
Firewall instalado
Se configura inicialmente.
Funciona.
Nadie vuelve a revisarlo salvo cuando hay una incidencia.
Firewall administrado
Se revisan:
- eventos;
- configuración;
- firmware;
- reglas;
- VPN;
- exposición;
- logs.
Nuestro objetivo es trabajar con el segundo modelo.
Una regla antigua también es una vulnerabilidad operativa
No hace falta que exista un CVE para asumir riesgo.
Imagine una regla:
Internet → servidor antiguo → puerto publicado
que ya no se utiliza.
El software puede estar completamente actualizado.
Pero mantener un servicio innecesario expuesto sigue aumentando la superficie de ataque.
Por eso la revisión de reglas forma parte del mantenimiento.
RDP directamente publicado: evitarlo siempre que sea posible
Los escaneos automáticos buscan constantemente servicios remotos.
Por eso recomendamos evitar configuraciones del tipo:
Internet → RDP
cuando sea posible.
Una arquitectura mucho más razonable sería:
Internet → VPN → autenticación → red interna → RDP
acompañada de MFA cuando la solución utilizada lo permita.
VPN también necesita seguridad
Publicar una VPN no significa:
“ya estamos seguros”.
Debemos controlar:
- usuarios;
- contraseñas;
- MFA;
- firmware;
- permisos;
- logs.
Y eliminar cuentas antiguas.
Una credencial que pertenecía a un proveedor que dejó de trabajar con la empresa no debería seguir activa.
Indicadores de compromiso SonicWall y histórico de logs
La detección inmediata es importante.
Pero existe otra capacidad que consideramos especialmente valiosa:
poder mirar hacia atrás.
En nuestros servicios podemos conservar hasta 400 días de logs de las fuentes integradas.
Eso permite realizar investigaciones retrospectivas.
¿Por qué necesitamos 400 días?
Imagine que hoy aparece información sobre una infraestructura maliciosa.
La pregunta puede ser:
¿se comunicó alguno de nuestros sistemas con ella anteriormente?
Si conservamos siete días:
no podremos revisar enero.
Con histórico suficiente:
podemos investigar.
Threat hunting retrospectivo
Esta capacidad permite realizar búsquedas como:
¿apareció este proveedor anteriormente?
¿hubo más intentos desde la misma red?
¿qué equipos recibieron conexiones?
¿qué ocurrió después?
No significa que todo indicador detectado sea una amenaza.
Significa que tenemos información para investigar.
Indicador nuevo, búsqueda hacia atrás
Este modelo es especialmente útil cuando aparece:
- un nuevo CVE;
- una nueva campaña;
- un dominio;
- infraestructura de mando y control;
- una dirección identificada posteriormente.
Hoy podemos descubrir que algo era relevante.
Entonces necesitamos comprobar:
qué ocurrió ayer.
El histórico hace posible esa pregunta.
El SOC analiza el contexto
Automatizar es necesario.
Con miles de eventos semanales sería imposible leer cada log manualmente.
Pero la automatización no debe sustituir completamente al análisis.
La plataforma puede indicar:
Port Scan Probable.
Nuestro SOC debe interpretar:
- quién;
- contra qué;
- por qué;
- qué ocurrió después.
Esa diferencia es fundamental.
Más alertas no significa más seguridad
Un sistema que genera:
50.000 alarmas
no es necesariamente mejor que uno que genera:
50 alertas útiles.
El exceso de ruido puede provocar:
fatiga de alertas.
Y cuando todo parece urgente:
nada lo es.
Por eso trabajamos en:
- filtrado;
- correlación;
- contextualización.
Semana 37: 2.195 indicadores analizados
Durante esta semana nuestro SOC revisó 2.195 indicadores de compromiso SonicWall en los entornos administrados.
Los eventos principales fueron:
Port Scan Possible
Port Scan Probable
SMTP Server on RBL Blacklist
La infraestructura asociada mostró una combinación de:
- proveedores cloud;
- VPS;
- centros de datos;
- hosting internacional.
Entre ellos encontramos redes asociadas a Microsoft Azure, Google Cloud, DigitalOcean, OVHcloud y otros operadores de alojamiento.
La actividad se distribuyó geográficamente por distintos puntos de:
Europa + Norteamérica + Asia.
Pero volvemos a recordar:
el proveedor no es el atacante.
el país de la IP no es necesariamente el país del atacante.
¿Debemos bloquear países completos?
No automáticamente.
El geobloqueo puede ser útil en determinados escenarios.
Por ejemplo:
si una empresa únicamente opera en España y un servicio no necesita ser accesible desde otros países.
Pero aplicar:
“bloquear todo el mundo”
sin analizar necesidades puede afectar:
- servicios cloud;
- proveedores;
- trabajadores desplazados;
- aplicaciones.
Las decisiones deben adaptarse al entorno real.
¿Qué hacemos después de detectar un Port Scan Probable?
El proceso puede resumirse así:
1. identificar el evento
↓
2. comprobar acción
↓
3. revisar puerto
↓
4. analizar reputación y proveedor
↓
5. comprobar reglas
↓
6. revisar sistema destino
↓
7. correlacionar con otras fuentes
↓
8. actuar si corresponde
Esta última parte es importante.
No bloqueamos indiscriminadamente cada dirección que aparece en un log.
Bloquear cada IP no escala
Internet cambia constantemente.
Una dirección puede desaparecer.
Otra puede aparecer minutos después.
Por tanto, la defensa no puede depender únicamente de:
listas manuales de IP.
Necesitamos también:
- reducir servicios expuestos;
- actualizar;
- segmentar;
- aplicar MFA;
- proteger endpoints.
Bloquear una IP concreta puede ser útil.
Pero eliminar la causa de exposición suele ser más importante.
SIEM y firewall: funciones diferentes
SonicWall y Wazuh no hacen lo mismo.
SonicWall
Actúa en el perímetro y genera eventos.
Wazuh
Centraliza, almacena y correlaciona información.
SOC
Interpreta el contexto.
Por tanto:
SonicWall registra
↓
Wazuh centraliza
↓
nuestro SOC analiza
Esta diferenciación es importante para entender el servicio.
El firewall no sustituye al Endpoint
Si una amenaza llega mediante:
- phishing;
- documento;
- navegador;
- USB;
puede no entrar mediante una conexión iniciada directamente desde Internet hacia el firewall.
Ahí necesitamos protección en el dispositivo.
Puede conocer nuestras soluciones de Endpoint y firewall para empresas.
Endpoint / EDR aporta otra perspectiva
Mientras el firewall observa tráfico:
Endpoint puede observar:
- procesos;
- archivos;
- ejecución;
- comportamiento.
Cuando ambas fuentes coinciden:
podemos obtener mucho más contexto.
Microsoft 365 también entra en la correlación
Muchos incidentes modernos comienzan con:
identidad.
Por ejemplo:
una cuenta Microsoft 365 comprometida.
Por eso podemos relacionar:
Entra ID
con:
firewall
y:
endpoint.
Imagine:
inicio de sesión anómalo
actividad local del equipo
conexión exterior
Puede ser más significativo que cualquiera de esos eventos individualmente.
Seguridad por capas
Una infraestructura empresarial puede combinar:
Firewall
Endpoint / EDR
MFA
segmentación
copias
SIEM
SOC
No existe una herramienta única capaz de cubrir todos los escenarios.
¿Necesita una pyme este nivel de control?
No todas las empresas necesitan exactamente la misma arquitectura.
Pero cualquier empresa que dependa de:
- correo;
- servidores;
- acceso remoto;
- NAS;
- datos de clientes;
tiene activos que proteger.
La solución debe dimensionarse.
No ignorarse.
Una pequeña empresa también es visible desde Internet
Los escáneres automáticos no preguntan:
“¿esta empresa factura diez millones?”
Escanean:
direcciones IP.
Si encuentran un servicio vulnerable:
pueden probarlo.
Por eso una pyme también aparece en estos registros.
La automatización ha cambiado el volumen de reconocimiento
Un atacante ya no necesita revisar manualmente una dirección.
Puede automatizar:
- escaneos;
- búsquedas;
- enumeración;
- explotación.
Y con la evolución de las herramientas de IA y automatización:
el coste técnico de determinadas tareas puede seguir reduciéndose.
Por eso la defensa necesita también automatización.
Pero automatizar no significa eliminar al analista
Nuestro objetivo no es:
que una herramienta tome todas las decisiones.
Es utilizar automatización para procesar volumen y dejar que el analista concentre su atención en:
lo relevante.
Esto mejora la capacidad de respuesta.
Conclusión: 2.195 indicadores de compromiso SonicWall analizados en la semana 37
Durante la semana 37 de 2026, nuestro SOC ha analizado 2.195 indicadores de compromiso SonicWall procedentes de firewalls TZ270 y TZ370 administrados en distintos entornos profesionales.
Los principales eventos fueron:
- Port Scan Possible
- Port Scan Probable
- SMTP Server on RBL Blacklist
La infraestructura asociada a las conexiones incluye redes de cloud, VPS y hosting vinculadas, entre otros, a:
- Microsoft Azure;
- Google Cloud;
- DigitalOcean;
- OVHcloud;
- otros centros de datos internacionales.
Se observó infraestructura geolocalizada principalmente en diferentes zonas de:
Europa, Norteamérica y Asia.
Sin embargo, estos datos deben interpretarse correctamente:
2.195 indicadores no equivalen a 2.195 ataques.
una IP extranjera no identifica la nacionalidad del atacante.
un proveedor cloud no es el atacante.
y:
un evento detectado no debe darse automáticamente por bloqueado.
Cuando no tenemos confirmación de bloqueo, revisamos:
puerto + regla + servicio + destino + actividad posterior + correlaciones.
Nuestros SonicWall administrados protegen actualmente infraestructuras de:
- administraciones de fincas;
- asesorías contables;
- asesorías laborales;
- despachos de abogados;
- arquitectura;
- interiorismo;
- constructoras;
- desarrollos de ingeniería;
- despachos profesionales en viviendas.
Además, podemos integrar los logs con SIEM Wazuh, aplicar correlaciones adaptadas a cada infraestructura y conservar hasta 400 días de histórico para investigaciones y auditorías.
Puede conocer nuestro servicio de SIEM Wazuh para empresas y nuestras soluciones de Endpoint y firewall para empresas.
Porque la pregunta importante no es:
“¿Cuántas alertas genera mi firewall?”
La pregunta es:
“¿Quién las analiza y sabe qué hacer cuando una realmente importa?”
📩 Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre indicadores de compromiso SonicWall
¿Cuántos indicadores de compromiso SonicWall se analizaron durante la semana 37?
Nuestro SOC analizó 2.195 indicadores y eventos de seguridad generados por firewalls SonicWall TZ270 y TZ370.
¿2.195 indicadores significan 2.195 ataques?
No. Un indicador o detección necesita contexto y no confirma por sí solo que exista una intrusión.
¿Qué eventos fueron los más frecuentes?
Principalmente Port Scan Possible, Port Scan Probable y SMTP Server on RBL Blacklist.
¿Qué significa Port Scan Possible?
Indica que SonicWall ha detectado actividad potencialmente compatible con una exploración de puertos o servicios.
¿Qué diferencia existe con Port Scan Probable?
El patrón observado presenta características más consistentes con un posible escaneo, aunque sigue necesitando contexto para determinar su relevancia.
¿Un escaneo significa que alguien ha conseguido entrar?
No. Un escaneo normalmente intenta descubrir qué servicios están disponibles. No demuestra por sí mismo que se haya producido acceso.
¿Qué significa SMTP Server on RBL Blacklist?
Que una infraestructura SMTP relacionada con la comunicación aparece en una lista de reputación o bloqueo utilizada para combatir spam y abuso.
¿Estar en una RBL significa que existe malware?
No necesariamente. Es un indicador de reputación que debe analizarse dentro del contexto de la comunicación.
¿Los 2.195 eventos fueron bloqueados por SonicWall?
No debe afirmarse sin comprobar la acción registrada en cada evento. Una detección no implica automáticamente bloqueo.
¿Qué se revisa si una conexión no fue bloqueada?
Puerto, servicio, regla aplicada, NAT, sistema de destino, actividad posterior y otros logs relacionados.
¿De qué países procedía la actividad?
La infraestructura observada estaba distribuida entre diferentes localizaciones de Europa, Norteamérica y Asia, incluyendo redes registradas o geolocalizadas en países como Países Bajos, Francia, Alemania, Estados Unidos y Rusia.
¿Eso significa que los atacantes se encuentran en esos países?
No. La geolocalización identifica normalmente la red o centro de datos asociado a la IP, no la ubicación física del operador.
¿Qué proveedores de hosting aparecieron?
En el análisis aparecen redes asociadas a Microsoft Azure, Google Cloud, DigitalOcean, OVHcloud, DataCamp y otros operadores de alojamiento y centros de datos.
¿Esos proveedores están atacando las empresas?
No. Los proveedores únicamente alojan infraestructura que puede ser utilizada por clientes legítimos o por terceros con diferentes finalidades.
¿Se deberían bloquear todas las conexiones procedentes de otros países?
No necesariamente. El geobloqueo debe aplicarse según las necesidades reales de cada empresa y los servicios que necesite publicar.
¿Por qué es importante reducir puertos expuestos?
Porque cada servicio publicado aumenta la superficie que puede ser identificada y analizada desde Internet.
¿Es recomendable publicar RDP directamente?
En general, recomendamos evitarlo y utilizar VPN u otras soluciones de acceso remoto seguras.
¿Qué aporta SonicWall?
Control perimetral, políticas de red y generación de eventos de seguridad, entre otras funciones según la configuración y licenciamiento.
¿Qué aporta SIEM Wazuh?
Centraliza y correlaciona logs de diferentes sistemas para facilitar detección e investigación.
¿Qué aporta el SOC?
Nuestro SOC analiza los logs, su contexto y las correlaciones para determinar si la actividad es legítima, sospechosa o requiere intervención.
¿Cuánto tiempo pueden conservarse los logs?
En nuestros servicios podemos mantener hasta 400 días de histórico de las fuentes integradas.
¿Por qué interesa guardar 400 días?
Porque puede ser necesario investigar meses después si un indicador conocido recientemente apareció anteriormente.
¿Un firewall sustituye a Endpoint / EDR?
No. El firewall protege principalmente las comunicaciones y el perímetro, mientras que Endpoint / EDR proporciona visibilidad y protección sobre el dispositivo.
¿Un SonicWall necesita mantenimiento?
Sí. Firmware, reglas, VPN, usuarios, servicios publicados y logs deben revisarse periódicamente.
¿Qué sectores utilizan estos SonicWall administrados?
Administraciones de fincas, asesorías contables y laborales, despachos de abogados, arquitectura, interiorismo, constructoras, ingeniería y despachos profesionales en viviendas.
¿Cuál es la principal ventaja de un firewall administrado?
Que no se limita a estar instalado: se supervisa, se mantiene y sus eventos pueden analizarse dentro del contexto real de la infraestructura.
