Security+ — Amenazas, Ataques y Vulnerabilidades: 75 preguntas de práctica

Step 1: Entender el vector de suplantación de identidad (BEC). Los atacantes usan direcciones lookalike y correos falsificados para engañar a empleados y provocar transferencias o divulgación de credenciales. El correo parece legítimo cuando el dominio del remitente es similar o cuando el mensaje emula estilo y lenguaje del CEO.

Step 2: Implementar controles técnicos en correo electrónico: SPF define qué servidores pueden enviar correo en nombre de un dominio; DKIM firma el contenido del mensaje con una clave privada asociada al dominio; DMARC coordina SPF y DKIM y permite establecer una política (none/quarantine/reject) y recibir informes. Al configurar DMARC con política de rechazo (p=reject) y alineación estricta se bloquean correos que no estén autenticados por el dominio legítimo, reduciendo significativamente entregas de correos spoof.

Step 3: Monitoreo y ajustes operativos. Habilitar reportes DMARC para ver fuentes legítimas y ajustar registros; complementar con Filtro de correo avanzado/ATP, reglas de DLP para pagos y procesos administrativos (verificación fuera de banda) para solicitudes financieras. La combinación técnica reduce el volumen de correos falsos y las políticas organizativas cubren excepciones. Trap: Confiar sólo en formación de usuarios o verificación telefónica sin controles técnicos; los usuarios pueden equivocarse y ataques muy persuasivos aún pueden triunfar. Por qué cada respuesta falló: - Insistir en que todos los empleados verifiquen por teléfono cualquier solicitud de pago: Es una buena práctica de proceso (verificación fuera de banda) pero depende del comportamiento humano y no evita que correos falsos lleguen ni la posible presión social que hace saltarse el proceso. - Bloquear todos los correos con enlaces externos: Impráctico e impide la comunicación legítima; muchos correos empresariales contienen enlaces necesarios para operaciones y colaboración. - Crear plantillas de correo prediseñadas para las comunicaciones del CEO: Puede ayudar a reconocer comunicaciones auténticas, pero no impide que los atacantes envíen correos falsos; es un control débil comparado con la autenticación de correo. En conclusión, DMARC con políticas de rechazo, junto a SPF y DKIM, es la mitigación técnica más efectiva para reducir la entrega de correos falsificados y mitigar el riesgo de BEC/CEO fraud, y debe complementarse con procesos de verificación y formación.

Step 1: Corroborar y reducir falsos positivos. Los escaneos no autenticados tienen tendencia a generar más falsos positivos porque no pueden ver el estado interno del host ni validar configuraciones que sí son visibles con credenciales. Reejecutar el escaneo con autenticación y asegurarse de que el inventario de activos y las credenciales usadas sean correctas reduce ruido y mejora la calidad de los datos.

Step 2: Validación técnica de hallazgos críticos restantes. Los hallazgos que se mantienen críticos tras un escaneo autenticado deben ser validados manualmente por un analista o mediante pruebas controladas (exploitación segura en entorno de pruebas o pentest dirigido) para confirmar que son explotables y medir impacto real. Esto evita gastar recursos en remediaciones innecesarias y confirma prioridad.

Step 3: Actualizar proceso de gestión de vulnerabilidades y priorización. Con resultados verificados, actualice la herramienta de gestión de vulnerabilidades y notifique a los responsables de los activos con prioridades basadas en impacto y probabilidad reales. Esto permite asignar recursos eficientemente y aplicar parches/mitigaciones según riesgo real. Trap: Un error común es asumir que el primer escaneo refleja el estado definitivo y actuar sobre todos los hallazgos sin validar; esto desperdicia recursos y puede interrumpir servicios innecesariamente. Why each wrong answer fails: - Opción 1 (Tratar todos los hallazgos del primer escaneo como verdaderos): Esto ignora la diferencia entre escaneos autenticados y no autenticados; actuar sobre falsos positivos puede causar interrupciones y malgastar tiempo/recursos. - Opción 4 (Ignorar la diferencia entre escaneos y aplicar la misma prioridad): Mantener la misma prioridad sin reevaluar la calidad de la señal conduce a decisiones de remediación mal informadas; la priorización debe basarse en datos validados. Why correct answers are right: - Opción 2 (Reejecutar autenticado y actualizar inventario): Mejora la visibilidad y reduce falsos positivos; un inventario actualizado es condición necesaria para priorizar por impacto sobre activos reales. - Opción 3 (Validación manual/explotación de los 2 hallazgos): Confirmar explotabilidad y impacto asegura que las acciones de remediación aborden riesgos reales y no meras alertas. Resumen técnico: Use escaneos autenticados, inventario preciso y validación de hallazgos (pruebas controladas) para priorizar por probabilidad e impacto; esto maximiza eficiencia y minimiza interrupciones operativas.

Step 1: Diferenciar tipos de DoS: volumétrico vs orientado a protocolo/aplicación. Un ataque volumétrico pretende consumir ancho de banda (banda ancha de enlace) mediante gran volumen de bytes o paquetes (p. ej. UDP floods, amplificación). Un SYN flood consume recursos de conexión (tabla de estados del servidor) y puede ser considerado de capa de transporte/protocolar. Los ataques a nivel de aplicación (HTTP POST al /login) buscan agotar recursos de aplicación (CPU, threads) con pocas conexiones.

Step 2: Identificar firmas en los registros. Tráfico UDP masivo proveniente de muchas IPs con paquetes pequeños y de alto volumen suele ser indicativo de un DDoS volumétrico (a menudo spoofed y amplificado). Los paquetes fragmentados elevan la carga de reensamblaje en routers y hosts y son usados para evadir mitigación; la aparición conjunta de respuestas muy grandes de servicios como NTP, DNS, SSDP o Chargen indica amplificación: peticiones pequeñas que generan respuestas mucho mayores y amplifican el volumen de tráfico hacia la víctima.

Step 3: Correlacionar con el impacto observado. Si el ancho de banda entrante al borde de la red se mantiene saturado y la latencia aumenta, se trata de volumétrico — esto se alinea con hallazgos 1 y 4. Un SYN flood (opción 2) sí puede ser volumétrico en ciertos casos, pero típicamente impacta recursos de conexión y estado más que saturar totalmente el ancho de banda; por tanto, cuando el objetivo es la saturación de enlace, los patrones de amplificación y UDP masivo son más concluyentes. Por otro lado, un elevado número de POST válidos con respuestas 200 (opción 3) es característico de un ataque a nivel de aplicación o de abuso legítimo (scripts o bots), no necesariamente de saturación de ancho de banda. Trap: Confundir cualquier pico en tráfico con un ataque volumétrico. Picos legítimos por eventos (backups, despliegues, replicación de datos) o pruebas internas pueden parecer volumétricos. Además, asumir que un SYN flood siempre es un ataque volumétrico es una simplificación: puede ser intensivo en conexiones pero no necesariamente en bytes. Why each wrong answer fails: - Opción 2 (Incremento de SYN desde múltiples IPs): Aunque un SYN flood puede causar denegación de servicio, su naturaleza es más relacionada con el agotamiento de tablas de estado y recursos TCP que con saturación de ancho de banda en todos los casos. Sin datos adicionales que muestren saturación de enlace, no es el indicador más fuerte de un volumétrico dirigido a ancho de banda. - Opción 3 (Alto número de POST /login con respuestas 200): Indica abuso de la aplicación (bots, credential stuffing) o carga legítima alta; provoca carga en la capa de aplicación (CPU, base de datos) pero no necesariamente consumo masivo de banda. Este patrón describe mejor un ataque de capa 7, no uno puramente volumétrico. Por qué las respuestas correctas son válidas: - Opción 1 (UDP masivo desde muchas IPs): Patrón clásico DDoS volumétrico distribuido; alta tasa de paquetes de pequeño tamaño desde múltiples fuentes apunta a saturación de canal de acceso. - Opción 4 (Paquetes fragmentados y amplificación): Las respuestas de amplificación grandes (NTP, DNS, SSDP) son utilizadas para multiplicar el tráfico enviado a la víctima y son un indicador claro de ataque volumétrico. Fragmentación puede incrementar la eficacia y evadir filtros. Acción recomendada: Activar mitigación en el ISP/servicios DDoS, filtrar tráfico de puertos de amplificación, implementar listas de control y rate-limiting, y analizar top-talkers para bloquear fuentes sospechosas.

Step 1: Identificar el tipo de incidente y su objetivo. El cambio masivo de extensiones y mensajes de rescate indican un ataque de ransomware que cifra archivos y exige pago para su restauración. El control crítico es la disponibilidad y recuperación de datos.

Step 2: Evaluar controles que reducen impacto inmediato. Las copias de seguridad offline (air-gapped o desconectadas) aseguran que existe una copia íntegra e independiente de los datos que no puede ser cifrada por el atacante en ejecución, permitiendo restauración sin negociar con atacantes. Validar restauraciones garantiza que las copias son utilizables.

Step 3: Implementar y ejecutar recuperación y medidas complementarias. Restaurar desde backups offline para volver a la operación, después forense para entender la vía de entrada, y aplicar parches, segmentación y EDR para evitar reinfección. Trap: Pensar que bloquear tráfico perimetral o crear firmas IDS resolverá de inmediato el problema es una trampa; esos controles ayudan a prevenir o detectar, pero no recuperan archivos ya cifrados. Why each wrong answer fails: Instalar un cortafuegos perimetral adicional solo controla tráfico de red y puede bloquear exfiltración o comandos de C2, pero no restaura archivos ya cifrados ni mitiga el impacto inmediato en la disponibilidad. Crear firmas IDS/IPS puede ayudar a detectar ciertas variantes y tráfico asociado, pero requiere tiempo para desarrollar firmas eficaces y no recupera los datos; además los atacantes usan comunicaciones cifradas o patrones variables que eluden firmas estáticas. Aplicar hardening de sistemas y deshabilitar servicios innecesarios es una buena práctica a medio y largo plazo para reducir la superficie de ataque, pero no es una solución de recuperación inmediata al cifrado de archivos ya ocurrido. En consecuencia, la medida prioritaria para mitigar el impacto inmediato de un incidente de ransomware es disponer de copias de seguridad offline verificadas que permitan restaurar sistemas y datos sin depender de pagar rescates. Posteriormente debe combinarse con medidas preventivas: segmentación de red, detección y respuesta, parcheo y formación para reducir probabilidad de re-infección.

Step 1: Identificar activos y evaluar impacto. La base de datos expuesta contiene información confidencial de clientes; una exfiltración implicaría pérdida de privacidad, multas regulatorias y daño reputacional, lo que constituye un impacto alto. Los endpoints con adware causan impacto operativo bajo a moderado.

Step 2: Evaluar probabilidad y calcular riesgo relativo. Aunque la inyección SQL tiene baja historia de explotación en este caso (probabilidad menor), su alto impacto eleva su riesgo global por encima del adware, que tiene mayor probabilidad pero menor impacto por incidente.

Step 3: Tomar decisión basada en priorización de riesgos. Priorice mitigaciones que reduzcan el riesgo más alto (alto impacto) —en este caso parchear/corregir la inyección SQL— y planifique controles secundarios para los endpoints (EDR y concienciación). Trap: Creer que la mitigación debe priorizarse únicamente por la frecuencia de ocurrencia (probabilidad) es una trampa común; ignorar el impacto puede dejar expuestos activos críticos. Why each wrong answer fails: Desplegar y endurecer una solución EDR es una buena medida para los endpoints y reduce la probabilidad de infecciones futuras, pero no reduce el riesgo mayor asociado a la base de datos expuesta; por tanto no es la primera prioridad. Cifrar copias de seguridad protege la disponibilidad e integridad de los respaldos y ayuda contra ransomware, pero no evita la exfiltración directa de la base de datos en producción ni reduce el impacto inmediato del compromiso de datos. Lanzar una campaña de concienciación puede reducir ciertos ataques basados en usuarios y es útil para el problema del adware, pero es una mitigación lenta y de impacto menor frente al riesgo crítico que representa una base de datos expuesta con vulnerabilidad de inyección SQL. En resumen: aunque el adware es más frecuente y molesto, la vulnerabilidad de la base de datos representa un riesgo de mayor impacto; por eso la remediación técnica del fallo de inyección SQL debe priorizarse, seguida por controles compensatorios (monitoreo, EDR, copias de seguridad y formación) para disminuir tanto probabilidad como impacto en el resto del entorno.

Step 1: Correlación de artefactos con riesgos: procesos que iteran y renombran archivos típicamente indican cifrado masivo, característica de ransomware que afecta disponibilidad. Los picos de DNS hacia dominios raros y transferencias grandes hacia IPs externas son indicadores claros de exfiltración de datos (confidencialidad comprometida).

Step 2: Evaluación de impacto y probabilidad: la encriptación de datos críticos causa alto impacto operativo y de negocio (interrupción, pérdida de productividad, posible pago de rescate), y si los binarios muestran comportamiento de cifrado masivo, la probabilidad es alta. La exfiltración implica pérdida de información sensible, cumplimiento y reputación, también con impacto elevado. Ambas deben priorizarse en la matriz de riesgo por alto impacto y evidencias concretas de probabilidad.

Step 3: Planificación de respuesta basada en prioridades: priorizar contención para limitar cifrado y exfiltración simultáneamente (aislar segmentos, bloquear egress), preservar evidencia y activar recuperación desde backups verificados; además notificar stakeholders de cumplimiento si hay datos sensibles comprometidos. Trap: confundir señales de C2/DNS con solo comunicación legítima; no asumir que todo tráfico inusual es inmediatamente exfiltración sin análisis de payload y volúmenes, pero no ignorarlo si coincide con actividad de archivos. Por qué cada respuesta incorrecta falla: - Opción 3 (DDoS): aunque un servidor comprometido podría participar en DDoS, los artefactos descritos (renombrado de archivos y picos DNS con transferencias grandes) señalan más claramente cifrado y exfiltración; DDoS tendría métricas de tráfico saliente hacia muchos destinos y patrones volumétricos distintos. - Opción 4 (Fuerza bruta de credenciales): los signos no muestran intentos repetidos de login o bloqueos de cuentas; fuerza bruta se detecta normalmente por múltiples intentos de autenticación fallidos, no por encriptación de archivos ni picos de exfiltración. - Opción 1 (correcta): cifrado de datos (ransomware) se evidencia por procesos que itera y cambia archivos y es de alto impacto. - Opción 2 (correcta): tráfico DNS inusual y grandes transferencias externas son indicadores fuertes de exfiltración, con impacto en confidencialidad. En la priorización de riesgos, ambos (disponibilidad y confidencialidad) suelen colocarse en la categoría alta, y la respuesta debe simultáneamente contener y preservar evidencia para recuperación y notificación legal/contractual.

Step 1: Diferenciar las variantes de XSS según el vector. En Stored XSS (persistente), el atacante introduce código malicioso que queda almacenado en la base de datos o en el perfil de la aplicación; luego, cuando otros usuarios acceden a esa página, el servidor devuelve el contenido almacenado con el payload activo, permitiendo la ejecución en el navegador de la víctima. En Reflected XSS, el payload viaja en la solicitud (por ejemplo, un enlace malicioso) y se refleja inmediatamente en la respuesta sin almacenamiento. El XSS basado en DOM ocurre cuando la vulnerabilidad reside en el manejo del DOM en el cliente, sin que el servidor almacene ni refleje directamente el payload.

Step 2: Coincidencia con el escenario. El escenario describe que el atacante introduce JavaScript en su perfil y que otros usuarios que visitan la página ejecutan el script, lo que es la definición exacta de Stored XSS (el payload persiste en el servidor y se entrega a múltiples víctimas al visualizar la página). Además, el robo de tokens de sesión por ejecución de script del lado del cliente es un resultado típico de XSS persistente.

Step 3: Mitigaciones y controles. Para prevenir Stored XSS se debe sanitizar y escapar todo contenido almacenado que se renderice en HTML, usar Content Security Policy (CSP) para limitar ejecución de scripts, validar y codificar entrada/salida, y usar frameworks que automaticen el escape. También reducir privilegios de cookies (HttpOnly) para evitar que scripts lean tokens de sesión. Trap: la confusión habitual es pensar que todas las XSS son iguales; la diferencia entre persistente (almacenado), reflejado y basado en DOM define cómo se exfiltran datos y qué contramedidas priorizar. Why each wrong answer fails: Reflected XSS no encaja porque en ese caso el ataque requiere que la víctima haga clic en un enlace con payload (no almacenado en el servidor) y la ejecución ocurre en la respuesta inmediata; el escenario indica persistencia en el perfil del atacante. DOM-based XSS implica que el cliente manipula el DOM de forma insegura, y aunque puede derivar en un resultado similar, en este caso el vector fue almacenar el script en el perfil del servidor, no únicamente en manipulaciones del DOM en el navegador. CSRF es una técnica diferente donde se induce a un usuario autenticado a ejecutar acciones involuntarias (por ejemplo, cambiar contraseña) explotando la confianza del servidor en la sesión del usuario; no permite ejecutar JavaScript en el contexto del sitio para robar tokens, que es precisamente lo que ocurre en XSS. Por todo ello, el tipo específico en este escenario es XSS almacenado (Stored XSS) y requiere controles de entrada/salida, políticas CSP y protección de cookies para mitigar el riesgo.

Step 1: Comprender la naturaleza del ataque: Un SYN flood es un ataque de agotamiento de recursos que explota la cola de conexiones TCP al iniciar muchas conexiones incompletas (SYN) y no completar el handshake. Cuando es distribuido (DDoS), la escala es grande y abrumadora para la infraestructura local.

Step 2: Medidas técnicas inmediatas: Habilitar SYN cookies en los servidores TCP/IP evita que la pila de red reserve recursos por cada SYN recibido; en vez de eso, el servidor valida el ACK del cliente antes de asignar recursos. Aplicar rate limiting en dispositivos edge o balanceadores reduce la tasa de nuevas conexiones por IP/prefijo. Estas contramedidas ayudan a mitigar el impacto a corto plazo.

Step 3: Escalado y mitigación por proveedores: Para ataques a gran escala, coordinar con el proveedor de tránsito o con un servicio de mitigación DDoS (scrubbing service) es crucial; pueden desviar y filtrar/limpiar el tráfico malicioso antes de que llegue a la red de la empresa. Combinar mitigaciones locales con servicios de proveedor mantiene la disponibilidad y evita bloqueos masivos erróneos. Trap: Un error frecuente es intentar bloquear cada IP de origen manualmente; en ataques DDoS las IPs suelen ser spoofeadas o provienen de botnets con miles de IPs, lo que hace inviable el bloqueo manual y puede provocar falsos positivos si se bloquean rangos legítimos. Why each wrong answer fails: - Bloquear manualmente en el firewall cada IP fuente: Impracticable en un DDoS moderno por el gran número de IPs y posible IP spoofing; además añadir muchas reglas degrada el rendimiento del firewall y puede interrumpir tráfico legítimo. - Apagar los servidores afectados y confiar en la conmutación por error manual: Apagar servidores sin plan puede causar pérdida de servicio y datos; la conmutación por error manual es lenta y no resuelve la saturación a nivel de red que también puede afectar a los nodos de respaldo. - Actualizar el sistema operativo sin cambiar la configuración de red: Aunque mantener sistemas parcheados es buena práctica, no mitiga el problema de agotamiento de conexiones en tiempo real; la actualización no remedia la naturaleza del SYN flood ni restaura la disponibilidad inmediata. Resumen: Para un SYN flood distribuido, la combinación de SYN cookies, límites de tasa y colaboración con el proveedor/servicio DDoS es la respuesta más completa y rápida para proteger la disponibilidad del servicio mientras se realizan análisis forenses y medidas adicionales.

Step 1: Identificar firmas técnicas del MITM en una red local. Técnicas comunes de MITM, como ARP spoofing/poisoning, introducen entradas ARP conflictivas porque el atacante anuncia una dirección MAC diferente para la misma IP; esto provoca duplicidad de IP->MAC en tablas ARP y tráfico que pasa por el atacante. Además, ataques que manipulan o interceptan TLS (por ejemplo, SSL stripping o el uso de certificados falsos) generan conexiones TLS con certificados autofirmados, no válidos o emitidos por una CA no confiable, y son registrados por sistemas de monitoreo.

Step 2: Correlacionar datos del informe con técnicas de ataque. La presencia de duplicidad de IP/MAC es un indicador de envenenamiento ARP o de un dispositivo mal configurado que responde por direcciones ajenas; en entornos planos, esto típicamente apunta a un MITM local. El aumento de conexiones TLS que presentan certificados no válidos sugiere que el tráfico cifrado está siendo interceptado y re-firmado por el atacante, o que se está llevando a cabo un downgrade/strip del cifrado. Ambos son indicadores directos y complementarios de un MITM activo.

Step 3: Descartar ruidos y falsos positivos. Un aumento de traffic ICMP (ping) desde una estación hacia múltiples equipos puede indicar escaneo, troubleshooting o malware, pero no es indicativo exclusivo de MITM. De igual modo, conexiones a puertos atípicos en un servidor pueden indicar reconnaissance o servicios mal configurados, pero no muestran evidencia de redirección de tráfico ni manipulación de cifrado. Por tanto, priorice investigar duplicidad ARP y certificados TLS no válidos, conteniendo con aislamiento y captura de tráfico (pcap) para validar. Trap: Un error común es asumir que cualquier anomalía de red (por ejemplo, escaneo ICMP o puertos abiertos) implica MITM. Muchos eventos operativos o actividades de administración generan ruido similar; sin evidencia de envenenamiento ARP o manipulación de TLS, no se puede concluir MITM. Why each wrong answer fails: - Opción 3 (Aumento de ICMP echo): Aunque un pico de ICMP puede indicar reconocimiento o una prueba de conectividad, no demuestra que alguien esté interceptando o alterando el tráfico entre dos hosts. Es un indicador de sondas, no de interposición de tráfico. - Opción 4 (Conexiones TCP a puertos atípicos): Conexiones a puertos inusuales pueden señalar escaneo de puertos o servicios desplegados indebidamente, pero no prueban la existencia de un punto intermedio que modifique o reenvíe sesiones entre hosts. Sin correlación con ARP o cifrado manipulado, es un falso positivo para MITM. Por qué las respuestas correctas son válidas: - Opción 1 (Duplicidad ARP): Técnica clásica de ARP poisoning; cuando múltiples MAC responden por la misma IP o las tablas contienen entradas inconsistentes, es una señal fuerte de redirección de tráfico. - Opción 2 (Certificados TLS no confiables): MITM que intercepta TLS normalmente presenta certificados que no coinciden con la cadena de confianza esperada, o reduce la seguridad (downgrade). La presencia de estos certificados en las sesiones TLS sugiere interposición y re-firmado del tráfico cifrado. Recomendación de respuesta: Capturar tráfico en la VLAN afectada (tcpdump/wireshark), comparar tablas ARP, validar huellas de certificados TLS, y aplicar contramedidas (aislar la estación atacante, endurecer ARP, habilitar 802.1X/port-security).

Step 1: Entender la naturaleza de cada vulnerabilidad. SQL Injection explota la concatenación insegura de entradas de usuario en consultas SQL y permite alterar la lógica de la consulta; payloads que manipulan condiciones booleanas (' OR '1'='1') o que provocan errores SQL son técnicas comunes de prueba. XSS (Cross-Site Scripting) explota la falta de sanitización o escape al reflejar contenido del usuario en una página web, permitiendo la inyección de scripts que el navegador ejecutará.

Step 2: Diseñar pruebas específicas y seguras. Para SQLi, enviar ' OR '1'='1' en campos usados en consultas puede cambiar la semántica (por ejemplo, convertir una consulta de autenticación en siempre verdadera), mostrando resultados no esperados o acceso sin credenciales. Para XSS reflejado/almacenado, introducir <script>alert(1)</script> en campos que son devueltos por la aplicación y observar si el navegador ejecuta la alerta confirma la ejecución de script en contexto del sitio.

Step 3: Interpretar resultados y plan de mitigación. Si la inyección booleana altera las consultas, es prueba de que la entrada no se parametriza; la mitigación es usar consultas preparadas (parametrizadas), validación y el principio de mínimo privilegio en cuentas de BD. Si la alerta de script se ejecuta, existe XSS; mitigar con escape/encoding en salida, Content Security Policy (CSP) y validación contextual de entrada. Trap: Una trampa común es asumir que cualquier entrada que muestre símbolos o errores es vulnerable; algunos sistemas devuelven datos sin ejecutar scripts (escape mostrado como texto) o generan mensajes de error pero no permiten explotación. Por eso hay que observar ejecución real (p. ej., la alerta del navegador) y efectos sobre la lógica de base de datos. Por qué cada respuesta incorrecta falla: 2) Subir un archivo con payload que intenta explotar la ejecución remota en el servidor: Esto está relacionado con ejecución remota de código (RCE) o vulnerabilidades en manejo de archivos, no es una prueba directa para SQLi ni XSS. Aunque podría detectar otra clase de fallo, no confirma inyección SQL ni XSS. 4) Utilizar caracteres ../ para intentar acceder a archivos del sistema de ficheros: Esto prueba Path Traversal (salto de directorios), que no está relacionado con SQL Injection ni Cross-Site Scripting. Es una técnica distinta usada para comprobar exposición de ficheros del sistema, no manipulación de consultas SQL ni inyección de script en páginas web. En resumen, para confirmar SQLi se usan payloads que cambian la semántica de la consulta (p. ej. ' OR '1'='1'), y para confirmar XSS se usan payloads que provoquen ejecución en el navegador (p. ej. <script>alert(1)</script>).

Step 1: Identificar la naturaleza del XSS reflejado: En XSS reflejado, la entrada maliciosa llega al servidor y se devuelve en la respuesta HTTP sin el escapado adecuado, provocando que el navegador interprete y ejecute código JavaScript inyectado en el contexto de la aplicación.

Step 2: Aplicar mitigaciones técnicas correctas: La defensa primaria es el output encoding o escaping por contexto (HTML, atributos, JavaScript, URL, CSS). Esto transforma caracteres especiales en entidades que el navegador mostrará como texto y no ejecutará. Por ejemplo, en HTML convertir < a &lt; y similares; en contextos JavaScript, usar funciones de escape específicas del lenguaje/entorno. Complementar con una política de seguridad de contenido (CSP) que restrinja las fuentes de scripts (script-src) reduce la capacidad de ejecutar scripts inyectados o cargar scripts desde orígenes no autorizados.

Step 3: Implementación y pruebas: Revisar todas las rutas donde la aplicación refleja datos al cliente y aplicar encoding por contexto en el servidor, no sólo en el cliente. Realizar pruebas de seguridad (fuzzing, herramientas de escaneo y pruebas manuales) para confirmar que las cargas XSS no se ejecutan. Mantener CSP en modo aprendizaje antes de bloquear agresivamente en producción para minimizar interrupciones. Trap: Un error común es confiar únicamente en la validación en el cliente o en eliminación de etiquetas, o pensar que HttpOnly detiene XSS; estas medidas pueden reducir riesgo pero no son suficientes por sí solas. Why each wrong answer fails: - Confiar exclusivamente en la validación de entrada en el lado del cliente para eliminar etiquetas <script>: El filtrado en cliente puede ser bypassed por peticiones directas, proxies o clientes maliciosos. Además, eliminar etiquetas no cubre vectores que usan atributos, contextos de evento (onload) ni inyecciones en atributos o URL. - Marcar las cookies como HttpOnly y Secure para bloquear ejecución de scripts: Marcar cookies como HttpOnly evita que scripts accedan a dichas cookies, pero no evita que se ejecute código malicioso en el DOM ni que realice acciones en nombre del usuario (ejecución de scripts, cambios en la interfaz, redirecciones). Es una mitigación complementaria pero insuficiente para impedir XSS. - Bloquear todas las etiquetas HTML en la entrada permitiendo solo texto plano sin filtros adicionales: Forzar texto plano puede ser efectivo en algunos campos, pero en aplicaciones que requieren HTML seguro (p. ej. editor enriquecido) no es práctico. Además, el bloqueo inadecuado puede romper el uso legítimo, y si se hace incorrectamente puede seguir permitiendo vectores encubiertos. La medida recomendada es output encoding por contexto y CSP. Por tanto, la medida más adecuada y práctica para mitigar XSS reflejado en un portal corporativo es implementar codificación/escapado de salida por contexto combinada con una política CSP para añadir una capa de defensa en profundidad.

Step 1: Identificar el riesgo técnico — El escaneo indica una versión específica de OpenSSH (7.2) y la nota de cifrados débiles. Esa información sugiere vulnerabilidades conocidas (por ejemplo, problemas con algoritmos o implementación) que pueden permitir ataques de cifrado débil, negociación descendente o explotación remota. Un parche actualizado contiene correcciones de seguridad y ajustes en configuraciones de cifrado.

Step 2: Determinar la mitigación apropiada — La mitigación más directa es actualizar el software a una versión que haya corregido esas vulnerabilidades y, a continuación, revisar la configuración de cifrados, protocolos (deshabilitar SSHv1 si aplica), y limitar ciphers/mac/kex a suites modernas. Esto elimina la raíz del problema: el software vulnerable o la configuración insegura.

Step 3: Acciones complementarias — Después de parchear, aplicar políticas de configuración segura (hardening), realizar pruebas de regresión, volver a escanear para verificar la remediación, y monitorizar logs para detectar intentos de explotación previos. También se pueden aplicar controles adicionales como autenticación de dos factores para SSH y listas de acceso (firewall) que restrinjan qué IPs pueden conectarse. Trap: Creer que cambiar el puerto o implementar solo detección cubre la vulnerabilidad. Mover servicios a puertos no estándar (security by obscurity) no corrige fallos en el software; un atacante puede detectar puertos alternativos. Un IDS únicamente detecta intentos, no impide la explotación si el servicio sigue vulnerable. Why each wrong answer fails: - Deshabilitar el servicio SSH por completo: aunque eliminaría la exposición, en entornos empresariales SSH suele ser necesario para administración remota; deshabilitar sin plan de acceso alternativo puede interrumpir operaciones críticas. Además, la solución esperada es parcheo y configuración segura, no una parada abrupta salvo en emergencia controlada. - Cambiar el puerto SSH a uno no estándar: esto solo dificulta ligeramente el descubrimiento para atacantes no sofisticados, pero herramientas y atacantes bien provistos escanean puertos y servicios; no corrige la vulnerabilidad en OpenSSH ni los cifrados débiles. - Implementar un IDS: un IDS puede detectar intentos de explotación pero no corrige vulnerabilidades ni evita que un exploit tenga éxito si se dirige contra el servicio. Además, un IDS genera alertas que requieren respuesta; no es una mitigación completa por sí sola. En resumen, la actualización y el hardening son la respuesta inmediata y correcta para eliminar la vulnerabilidad del software y restringir el uso de cifrados inseguros, mientras que las otras opciones son complementarias o inadecuadas por sí solas.