02-23-2026, 03:11 AM
¿Qué conexiones de red realiza GetOverX Shield (si aplica) y qué reglas de firewall o proxies corporativos pueden requerirse?
|
Reglas de firewall / red para una empresa
|
02-23-2026, 05:01 PM
(This post was last modified: 02-23-2026, 05:04 PM by mrwebfeeder.)
Get Over X Shield no requiere conexiones salientes permanentes para “funcionar” como protección local, pero sí puede realizar tráfico de red en escenarios específicos (actualizaciones, licencias, telemetría opcional, funciones remotas, etc.). En entornos corporativos conviene definir qué se permite y qué se bloquea según el perfil de red seleccionado.
1) ¿Qué conexiones de red puede realizar GetOverX Shield? Dependiendo de los módulos habilitados, pueden existir estos tipos de conexiones: Actualizaciones de componentes / firmas (si aplica) Descarga de definiciones o actualizaciones del motor/paquetes. Esto suele ser salida HTTPS (443) hacia endpoints oficiales. Validación de licencia (si aplica) Verificación periódica o al activar la licencia. Normalmente HTTPS (443). Servicios en segundo plano / agentes Algunos módulos pueden usar servicios Windows que consultan estado del sistema y reportan localmente (sin red). Solo habrá red si se habilita algún componente que requiera sincronización. Funciones remotas (si aplica) Si usas un módulo tipo “Remote / Console / Management”, puede requerir acceso a un servidor central por **HTTPS (443)** o un puerto específico interno. Telemetría o reportes (solo si está habilitado) Si existe telemetría, lo ideal es que sea opt-in y documentada; en corporativo normalmente se deja apagada o se enruta a un endpoint permitido. En resumen: la red se usa principalmente para actualización y validación, y opcionalmente para servicios remotos. --- 2) Perfiles de control de red en GetOverX Shield GetOverX Shield usa perfiles: Booster – Normal – In domain – Strict. La idea es que cambie el nivel de bloqueo, el tipo de excepciones permitidas, y el comportamiento por contexto corporativo. A) Booster Pensado para rendimiento y compatibilidad máxima. Bloqueo mínimo, prioriza que el sistema “no se rompa”. Permite la mayoría de conexiones salientes habituales (navegadores, actualizadores, apps comunes). Útil para: equipos de prueba, estaciones donde prima compatibilidad, troubleshooting. Riesgo: menos control, más superficie de ataque (apps no autorizadas pueden tener salida). --- B) Normal Equilibrio entre seguridad y usabilidad (modo recomendado para la mayoría). Bloquea categorías típicas de riesgo: ejecutables desconocidos con comportamiento sospechoso, herramientas de administración remota no autorizadas, etc. (según tu lógica interna). Mantiene permitidas apps comunes del usuario y servicios del sistema. Útil para: estaciones estándar, laptops corporativas, operación diaria. --- C) In domain Perfil orientado a ambientes unidos a dominio (AD) y redes corporativas. Ajusta reglas para no interferir con Active Directory / GPO / recursos internos. Suele permitir con prioridad:
Útil para: PCs en dominio, escritorios gestionados, redes con proxy/autenticación. --- D) Strict Máximo control. Modelo de “deny-by-default” más agresivo. Bloquea más procesos por categoría y reduce al mínimo aplicaciones con salida. Ideal cuando: Equipos de alto riesgo o bajo ataque hacker Estaciones con política muy cerrada Riesgo: puede generar fricción (apps legítimas bloqueadas) y requerir más excepciones. --- 3) Modo Avanzado: permitir / bloquear por aplicación En Advanced, el objetivo es que el administrador pueda: Permitir programas específicos (allowlist) aunque el perfil sea estricto Bloquear más programas (denylist) aunque el perfil sea flexible Esto permite aplicar una política corporativa real: el perfil da una base y el “Advanced” hace el ajuste fino. 4) Reglas recomendadas para firewall y proxies corporativos (enfoque práctico) Opción 1: Política “cerrada” (recomendada en corporativo) Permitir solo lo necesario en su firewall hardware: Salida HTTPS (443) desde: `GetOverXShield.exe` (UI) `GetOverXShieldService.exe` (servicio) `freshclam.exe` / updater (si aplica) Módulo de licencia (si aplica) Y bloquear salida del resto de ejecutables no autorizados. En proxy corporativo: Permitir tráfico HTTPS para esos binarios (si el proxy filtra por aplicación) O permitir por destino si tu proxy usa allowlist por FQDN/URL (lo ideal es publicar endpoints oficiales). Opción 2: Política “compatibilidad” Permitir salida general, y usar GetOverX para bloquear por perfil + listas. Útil cuando el proxy/firewall no permite control granular por app. --- 5) Recomendación operativa para admins
|
Users browsing this thread: 1 Guest(s)