Preguntas de entrevista de Cybersecurity (General)

En la práctica, no. AES-128 ya exige unos 2^128 de esfuerzo para romperse por fuerza bruta — totalmente inviable — así que AES-256 no te hace realmente más seguro frente a la fuerza bruta; sobre todo añade margen (reserva poscuántica, cumplimiento). Ambos están estandarizados y sin romper. Tu modo (GCM), el manejo de nonces y la gestión de claves importan mucho más que 128 frente a 256. «AES-256 es el doble de seguro» es la idea errónea.

No. El antivirus es una señal, no una prueba. Omite ataques sin archivo y en memoria, muestras nuevas u ofuscadas, el abuso de herramientas legítimas (living-off-the-land) y los rootkits diseñados para ocultarse de él. La ausencia de prueba no es prueba de ausencia — la garantía real proviene de la telemetría EDR, el análisis forense de memoria, el análisis conductual y la caza de IOC. Tratar un análisis antivirus limpio como prueba de un sistema limpio es un error clásico de respuesta a incidentes.

No. Las tres categorías de factores de autenticación son algo que sabes (contraseña/PIN), algo que tienes (token/teléfono) y algo que eres (biometría). Una huella dactilar o un escaneo facial es «algo que eres», un rasgo físico medido. La trampa: la biometría no es un secreto y no puede rotarse — si la plantilla de tu huella se filtra, no puedes cambiar tu huella. Por eso la biometría funciona mejor como un factor, que a menudo desbloquea una clave local, y no como sustituto autónomo de la contraseña.

No. La validación en el cliente es una pura comodidad de UX — un atacante puede desactivar JavaScript, editar la petición en el navegador o Burp, o llamar a tu API directamente con curl, saltándosela por completo. Los controles de seguridad (validación, autorización, saneamiento) deben imponerse en el servidor, el único lugar que controlas. El error es tratar el navegador como una frontera de confianza; no lo es, porque el cliente corre en la máquina del atacante. Los controles de cliente sirven para dar respuesta rápida, nunca para la seguridad.

No se descifra — los hashes criptográficos son funciones unidireccionales sin inversa. «Crackear» un hash significa adivinar entradas candidatas, hashear cada una y comparar (diccionario, fuerza bruta, rainbow tables), que es justo por lo que se usan hashes lentos y salados para las contraseñas. No hay ninguna clave que «descifre» un hash. Si algo se puede descifrar, fue cifrado, no hasheado — y Base64 es codificación reversible, no hash.

No. El archivo de prueba EICAR es una cadena ASCII deliberadamente inofensiva de 68 bytes que todos los fabricantes de antivirus acuerdan detectar, para verificar con seguridad la detección y las alertas sin tocar malware real. Una detección significa que tu antivirus funciona — no que estés infectado. No es un virus y no hace nada si se ejecuta. Confundir una detección de prueba EICAR con una infección real es una trampa común al inicio de carrera.

En gran medida no. El nombre de host de destino se envía en claro en la extensión SNI del ClientHello de TLS, y tu consulta DNS suele revelarlo también, de modo que un ISP o una red pueden ver QUÉ sitio visitas incluso por HTTPS — solo que no pueden leer la ruta ni el contenido. El ClientHello cifrado (ECH) y el DNS-over-HTTPS pueden cerrar esta brecha, pero no son universales. «HTTPS lo oculta todo» es la idea equivocada.

No. TLS/HTTPS asegura los datos en tránsito entre cliente y servidor; una vez recibidos, la aplicación los descifra y los maneja en texto plano, y luego se almacenan según cómo esté configurada la base de datos. Proteger los datos en reposo es un asunto aparte — cifrado de disco/columna, un KMS y control de acceso. Confundir «usamos HTTPS» con «nuestros datos almacenados están cifrados» es una idea errónea común y peligrosa.

No. HTTPS cifra el canal para que los atacantes no puedan leer ni manipular el tráfico en tránsito, pero la entrada maliciosa llega, se descifra y la procesa tu aplicación igual que antes. La inyección SQL y el XSS son fallos de la capa de aplicación que se corrigen con consultas parametrizadas y codificación de salida, no con cifrado de transporte. El error supone que el cifrado sanea el contenido — no lo hace; el atacante simplemente envía la carga por la conexión HTTPS.

No. El modo privado/incógnito solo impide que el navegador local guarde historial, cookies y datos de formulario tras la sesión — no hace nada al camino de red. Tu ISP, el proxy de tu empleador, el resolutor DNS y los sitios donde inicias sesión siguen viendo tu actividad. El error es «incógnito = invisible»; en realidad es privacidad frente a otras personas que usan el mismo dispositivo, no anonimato frente a la red.

No. Todo el rango 127.0.0.0/8 está reservado para loopback, así que 127.0.0.2, 127.1.1.1, etc., resuelven todas al host local. Importa para el SSRF y el bypass de listas de permitidos — un atacante puede usar 127.0.0.2 u otras codificaciones para esquivar un control ingenuo de «bloquear 127.0.0.1» — y para enlazar varios servicios locales. (En IPv6, el loopback es la única dirección ::1.)

No. Una MAC la asigna el fabricante (OUI más identificador del dispositivo) y va «grabada», pero prácticamente todos los sistemas operativos permiten sobrescribirla por software (macchanger, ip link set address). Por tanto las direcciones MAC son suplantables y no deben usarse para autenticación — el filtrado MAC es débil, y los teléfonos ya aleatorizan la MAC por privacidad. «Permanente y única» es la idea equivocada.

No. La MFA sube mucho el listón, pero los factores OTP y push son phisheables: los kits de adversario en el medio (p. ej. Evilginx) retransmiten el inicio de sesión y el código en tiempo real, y la fatiga MFA / push-bombing empujan al usuario a aprobar. Los códigos capturados son reutilizables dentro de su corta ventana. El error es «MFA = imposible de phishear»; lo que importa es el tipo de factor. La MFA resistente al phishing — passkeys FIDO2/WebAuthn ligados al origen del sitio — es lo que realmente lo derrota.

No. El NAT (y el PAT) asigna direcciones privadas a una IP pública y, como efecto secundario, descarta las conexiones entrantes no solicitadas porque no existe ninguna correspondencia para ellas. Eso no es una política de seguridad — no hay inspección, ni reglas, ni registro — y la travesía de NAT, el hole punching y el C2 iniciado en salida pasan sin problema. El NAT es una herramienta de direccionamiento; aun así necesitas un cortafuegos real. «NAT = cortafuegos» es la idea equivocada.

No por sí solo. Muchos sistemas mantienen válidas las sesiones existentes y los tokens ya emitidos tras un cambio de contraseña — tokens de actualización OAuth, «contraseñas de aplicación», claves de API y cookies persistentes — así que un atacante con una sesión activa puede permanecer dentro. La respuesta correcta es cambiar la contraseña Y invalidar todas las sesiones y tokens, revocar las credenciales de aplicación y auditar los dispositivos MFA y los ajustes de recuperación. Creer que un restablecimiento solo expulsa al atacante es un error clásico de respuesta a incidentes.

No. POST simplemente lleva los parámetros en el cuerpo de la petición en vez de en la URL; ese cuerpo va en texto plano y es totalmente visible para quien pueda ver el tráfico, salvo que se use HTTPS. POST es preferible para acciones que cambian el estado y mantiene los parámetros fuera de URL, registros e historial, pero no aporta confidencialidad por sí mismo. El error confunde «no está en la URL» con «cifrado» — solo TLS cifra los datos de cualquiera de los dos métodos en tránsito.

No. La mayoría de las intrusiones reales establecen persistencia (servicios, tareas programadas, claves de inicio, implantes) que sobrevive a un reinicio, así que el atacante simplemente vuelve. Peor aún, apagar borra las pruebas volátiles — procesos en ejecución, conexiones de red, malware en memoria y claves de cifrado — que necesitas para acotar el incidente. Lo correcto es contener aislando el host mientras se preserva la memoria, y luego investigar. Reiniciar o apagar como «solución» es un instinto dañino.

Pregunta trampa: no existe un único puerto de traceroute. El traceroute clásico de Unix envía datagramas UDP a puertos altos e improbables a partir de 33434 aproximadamente, con un TTL creciente; el tracert de Windows usa en cambio ICMP Echo. Funciona leyendo los mensajes ICMP Time Exceeded que devuelven los routers al expirar el TTL, no apuntando a un puerto reservado. Y el propio ICMP no tiene puertos.

No. Una VPN cifra el tráfico hasta el servidor VPN y oculta tu IP al destino, pero el proveedor puede ver y registrar tu actividad, y los inicios de sesión, las cookies y la huella del navegador siguen identificándote. Traslada la confianza de tu red local/ISP al operador de la VPN — eso es privacidad frente a la red local, no anonimato. Tor y una disciplina operativa estricta son herramientas distintas para un objetivo distinto.

El modelo clásico es PICERL: Preparación, Identificación (detección), Contención, Erradicación, Recuperación y Lecciones aprendidas. El NIST lo agrupa como Preparación; Detección y análisis; Contención, erradicación y recuperación; y Actividad posterior al incidente. El orden importa porque debes delimitar y contener antes de erradicar, y solo recuperas una vez eliminada la amenaza, o reinfectas. Es un bucle, no una línea: las lecciones aprendidas realimentan la preparación.

Un IOC es un artefacto forense de que algo malicioso ya ocurrió: un hash de archivo malicioso, una IP o dominio de C2, una clave de registro conocida como dañina. Un IOA es una señal de comportamiento de un ataque que se desarrolla, independientemente de las herramientas concretas, p. ej. un documento de Word que lanza PowerShell y luego sale a Internet. Los IOC son reactivos y fáciles de evadir cambiando un hash; los IOA capturan la intención y sobreviven a los cambios de herramienta.

El orden de volatilidad clasifica la evidencia según lo rápido que se desvanece, para recopilar primero lo más frágil. A grandes rasgos: registros/caché de CPU, luego RAM y estado en ejecución (procesos, conexiones de red, ARP), luego archivos temporales/swap, luego disco, luego registro y datos de monitorización remotos y, por último, soportes de archivo y copias de seguridad. También trabajas sobre copias forenses, las hasheas y mantienes una cadena de custodia para que la evidencia siga siendo admisible.

El ransomware es malware que cifra (y cada vez más exfiltra) datos y luego exige pago. En un caso activo: aislar los hosts afectados de la red sin apagarlos si puedes preservar la memoria, identificar el alcance, el paciente cero y la cepa, preservar la evidencia, encontrar y expulsar el punto de apoyo y cualquier puerta trasera, y luego restaurar desde copias offline reconocidas como limpias. Pagar es un último recurso y nunca garantiza la recuperación.

SPF publica qué IP pueden enviar correo en nombre de un dominio. DKIM añade una firma criptográfica para que el receptor verifique que el mensaje no fue alterado y proviene del dominio. DMARC liga los resultados de SPF/DKIM al encabezado From: visible mediante la «alineación», indica a los receptores qué hacer ante un fallo (none/quarantine/reject) y envía informes. SPF y DKIM por sí solos no protegen el From que ve el usuario; DMARC es lo que lo impone.

El registro Security es primario: 4624 inicio de sesión correcto (con tipo de inicio), 4625 inicio fallido, 4634/4647 cierre de sesión, 4672 privilegios especiales asignados, 4720 cuenta creada, 4688 creación de procesos (con línea de comandos si está habilitada) y 4768/4769 Kerberos. Añade 7045 instalación de servicio (registro System), 4698 tarea programada creada y el registro de bloques de script de PowerShell (4104). El tipo de inicio de sesión y la auditoría de líneas de comandos son lo que hace útiles estos registros.

Almacena las contraseñas usando una función de hashing de contraseñas deliberadamente lenta, salada y adaptativa —bcrypt, scrypt o Argon2— nunca un hash rápido de propósito general como SHA-256 o MD5. Los hashes rápidos están hechos para la velocidad, así que atacantes con GPU pueden probar miles de millones de intentos por segundo contra una base de datos filtrada. Los hashes lentos tienen un factor de trabajo ajustable (y un coste de memoria) que hace cada intento caro, manteniendo la fuerza bruta impracticable incluso tras una filtración.

Una sal es un valor aleatorio único generado por usuario y combinado con la contraseña antes del hashing. Garantiza que contraseñas idénticas produzcan hashes diferentes y vuelve inútiles los ataques precalculados como las tablas arcoíris, ya que el atacante necesitaría una tabla distinta por sal. Las sales se almacenan junto al hash. Una pimienta es un valor secreto adicional, el mismo para todos los usuarios, guardado por separado (por ejemplo, en la configuración de la app o un HSM) para que una filtración de la base de datos sola no baste.

TOTP (contraseña de un solo uso basada en tiempo) combina un secreto compartido, establecido en el registro, con la hora actual dividida en ventanas fijas (normalmente 30 segundos). Ejecuta HMAC sobre el contador del paso de tiempo con el secreto, luego trunca el resultado a un código de 6 dígitos. Tanto la app como el servidor tienen el mismo secreto y reloj, así que calculan independientemente el mismo código, sin necesidad de llamada de red. El código rota en cada ventana.

La tríada CIA son los tres objetivos centrales de la seguridad de la información: confidencialidad (solo las partes autorizadas pueden leer los datos), integridad (los datos no se alteran sin autorización) y disponibilidad (los usuarios autorizados pueden acceder a los sistemas cuando los necesitan). Casi todo control se relaciona con uno o varios de estos objetivos.

La defensa en profundidad consiste en superponer varios controles de seguridad independientes de modo que, si uno falla, los demás sigan protegiendo el activo. Asume que ningún control es perfecto — por ejemplo, combinando firewall, segmentación de red, protección de endpoints, MFA, mínimo privilegio y cifrado en lugar de confiar solo en el perímetro.

La codificación (como Base64) es un cambio de formato reversible sin secreto — no es seguridad. El cifrado es reversible con una clave y protege la confidencialidad. El hashing es una función unidireccional que produce un resumen de longitud fija, usado para comprobaciones de integridad y almacenamiento de contraseñas, y no puede revertirse para obtener la entrada.

Un IDS (sistema de detección de intrusiones) monitoriza el tráfico y genera alertas pero no bloquea — suele estar fuera de banda. Un IPS (sistema de prevención de intrusiones) se sitúa en línea en la ruta del tráfico y puede descartar o bloquear activamente el tráfico malicioso. El IPS previene, pero un falso positivo puede romper tráfico legítimo.

El mínimo privilegio significa que cada usuario, proceso y servicio recibe solo el acceso mínimo necesario para su tarea, y nada más. Limita el radio de impacto de una cuenta comprometida, reduce el riesgo de amenaza interna y disminuye la superficie de ataque. Se aplica mediante acceso basado en roles, revisiones de acceso periódicas y elevación justo a tiempo.

La MFA exige dos o más factores de autenticación de categorías diferentes — algo que sabes (contraseña), algo que tienes (teléfono/token), algo que eres (biometría). Ayuda porque un atacante que roba un factor, como una contraseña, aún no puede iniciar sesión sin los demás. La MFA resistente al phishing como FIDO2 es la más fuerte.

El phishing es ingeniería social que engaña a las personas para que revelen credenciales, envíen dinero o ejecuten malware, normalmente mediante correos o sitios falsos. La defensa es por capas: filtrado y autenticación de correo (SPF/DKIM/DMARC), MFA para limitar el daño de credenciales robadas, formación de concienciación y una forma sencilla de reportar mensajes sospechosos.

El cifrado simétrico usa una única clave secreta compartida para cifrar y descifrar y es rápido, pero ambas partes ya deben compartir la clave. El asimétrico usa un par de claves pública/privada, resolviendo el problema de distribución de claves pero más lentamente. Protocolos reales como TLS usan criptografía asimétrica para intercambiar una clave simétrica y luego cambian a simétrica para el grueso de los datos.

TCP está orientado a conexión y es fiable: usa un handshake de tres vías, garantiza la entrega ordenada y retransmite los paquetes perdidos. UDP es sin conexión y rápido, sin garantías de entrega, orden ni congestión. Usa TCP para la exactitud (web, correo, transferencia de archivos) y UDP para tráfico sensible a la velocidad (DNS, VoIP, streaming, videojuegos).

Una vulnerabilidad es una debilidad (software sin parchear). Una amenaza es un actor o evento que podría explotarla (un grupo de ransomware). El riesgo es la combinación de la probabilidad de que una amenaza explote una vulnerabilidad y el impacto si lo hace. Riesgo = amenaza x vulnerabilidad x impacto, y es lo que realmente se prioriza.

Un firewall controla el tráfico entre zonas de red permitiéndolo o denegándolo según reglas. Un firewall sin estado evalúa cada paquete de forma aislada frente a las reglas; un firewall con estado rastrea el estado de las conexiones para permitir el tráfico de retorno de las sesiones que autorizó. Los firewalls de nueva generación añaden conocimiento de la capa de aplicación.

Un día cero es una vulnerabilidad que el fabricante aún no conoce (o no ha parcheado), por lo que los defensores han tenido «cero días» para arreglarla. Como no existe parche, la defensa se apoya en controles por capas, detección por comportamiento, segmentación, mínimo privilegio y respuesta rápida a incidentes en lugar de una firma.

Ninguno. ARP es un protocolo de capa 2 (capa de enlace) que se encapsula directamente en una trama Ethernet, no dentro de un paquete IP. Como nunca viaja sobre IP, no puede usar TCP ni UDP, que son transportes de capa 4 que requieren IP por debajo. La función de ARP es resolver una dirección IP conocida a la dirección MAC correspondiente en el mismo segmento de red local.

Confirma el XSS. Si alert() se disparó siquiera, el navegador analizó y ejecutó tu JavaScript inyectado en el contexto de la página: esa es la vulnerabilidad. Una ventana vacía solo significa que el argumento de cadena que pasaste no se mostró como esperabas (el manejo de comillas, la codificación o la alteración del contexto rompieron el mensaje), no que el payload esté bloqueado. El punto de ejecución está activo; a partir de ahí refinas el payload.

Comprime primero y luego cifra. Un buen cifrado produce una salida estadísticamente indistinguible de lo aleatorio, así que el texto cifrado no tiene patrones que comprimir: comprimir después es inútil. La advertencia importante: comprimir juntos datos secretos y datos controlados por el atacante antes de cifrar puede filtrar información a través de la longitud del texto cifrado, que es exactamente lo que hacen los ataques CRIME y BREACH.

No. CORS no es una defensa contra el CSRF: en realidad afloja la política del mismo origen para que una página pueda leer respuestas entre orígenes que de otro modo no podría. El CSRF no necesita leer la respuesta; solo necesita que el navegador de la víctima envíe una petición autenticada que cambie el estado. Las defensas reales son los tokens anti-CSRF, el atributo de cookie SameSite y comprobar Origin/Referer.

Porque «eliminar» normalmente no borra los datos. Quita los metadatos del sistema de archivos (el puntero/la entrada de directorio) y marca los bloques como libres, pero los bytes originales permanecen en el disco hasta que el sistema operativo reutiliza esos bloques para nuevos datos. Hasta que ocurre esa sobrescritura, las herramientas forenses pueden extraer el contenido directamente.

La codificación transforma los datos a otro formato por compatibilidad y es totalmente reversible por cualquiera sin clave (p. ej. Base64, codificación de URL): no aporta confidencialidad. El cifrado solo es reversible con una clave y es lo que aporta confidencialidad. El hashing es una función unidireccional: no puedes recuperar la entrada a partir de la salida, por lo que sirve para comprobaciones de integridad y almacenamiento de contraseñas (con sal y una KDF lenta).

Desde un punto de vista puramente de seguridad, un falso negativo suele ser peor: significa que un ataque real pasó sin detectarse, así que no hay respuesta, ni contención, y la brecha puede permanecer latente sin descubrirse. Pero los falsos positivos no son inofensivos: en grandes volúmenes provocan fatiga de alertas, donde los analistas empiezan a ignorar las alertas y se les escapa la real. La respuesta correcta nombra el compromiso, no solo un ganador.

Filtrado. Un puerto filtrado descarta el paquete en silencio, así que el escáner no obtiene respuesta y debe esperar un tiempo de espera: no aprende nada sobre si el host siquiera existe, y el escaneo se ralentiza drásticamente. Un puerto cerrado devuelve un RST de TCP, que confirma que el host está vivo y respondiendo, entregando gratis al atacante valor de reconocimiento.

No. El candado significa que el transporte está cifrado y que el certificado es válido para ese dominio: no dice nada sobre si el operador es honesto o el contenido es malicioso. Los certificados gratuitos y automatizados hacen que los sitios de phishing y malware casi siempre tengan también un candado perfectamente válido. HTTPS protege el canal, no el destino.

No por sí solo. HTTPS previene el MITM solo cuando la validación del certificado se exige estrictamente y el cliente llega al sitio por HTTPS desde el principio. Si una CA fraudulenta es de confianza (proxy corporativo, raíz instalada por malware), si el usuario pasa por alto las advertencias de certificado, o si el SSL stripping degrada la conexión a HTTP antes de que arranque TLS, un atacante todavía puede situarse en el medio.

HTTPS no es un protocolo propio: es HTTP normal corriendo dentro de un túnel TLS cifrado. SSL es el nombre antiguo: SSL 2.0/3.0 son los predecesores obsoletos e inseguros de TLS, que los reemplazó (de TLS 1.0 a 1.3). Cuando la gente dice «certificado SSL» o «SSL», casi siempre se refiere en realidad a TLS.

Porque son rápidos. MD5 y SHA-256 están diseñados para la velocidad, que es exactamente lo contrario de lo que se necesita para las contraseñas: un atacante que roba los hashes puede calcular miles de millones de intentos por segundo en una GPU. La solución es una función de derivación de clave deliberadamente lenta y dura en memoria —bcrypt, scrypt o Argon2— combinada con una sal por usuario y un factor de trabajo ajustable.

Pregunta trampa: ping no usa ningún puerto. Funciona sobre ICMP, un protocolo de capa 3 que se sitúa directamente encima de IP. Los puertos solo existen en protocolos de capa 4 como TCP y UDP, así que ICMP (y por tanto ping) no tiene ninguno. ICMP usa en su lugar campos de tipo y código, p. ej. Echo Request tipo 8 y Echo Reply tipo 0.

Tres. El cliente envía un SYN, el servidor responde con un SYN-ACK combinado (un paquete que a la vez confirma el SYN del cliente y envía el propio SYN del servidor), y el cliente termina con un ACK. El truco es que SYN-ACK es un único paquete, no dos, así que el total es tres, exactamente lo que nombra «tres vías».

Las revisiones de acceso (recertificación) son comprobaciones periódicas en las que un propietario responsable confirma que el acceso de cada persona sigue justificado, y revoca lo que no lo está. Son la red de seguridad que detecta la acumulación de privilegios, las cuentas huérfanas y los derechos concedidos para un proyecto ya terminado. El control solo funciona si un propietario competente —normalmente el responsable o el dueño del recurso— examina de verdad el acceso en lugar de aprobarlo sin mirar, y si las revocaciones se aplican.

La federación de identidades establece confianza entre un proveedor de identidad (IdP) que autentica usuarios y proveedores de servicios (partes de confianza) que consumen esa autenticación. El IdP verifica al usuario y emite una aserción o token firmado; el proveedor de servicios confía en él en lugar de gestionar sus propias credenciales. Esto habilita el SSO entre dominios y el control centralizado, pero concentra el riesgo: si comprometes el IdP, comprometes todo lo que confía en él.

El moderno NIST SP 800-63B prioriza la longitud sobre la complejidad: permitir frases de contraseña largas (al menos 8, admitir 64+), aceptar todos los caracteres incluidos los espacios, y no imponer reglas de composición como «una mayúscula, un símbolo». Filtrar las contraseñas nuevas contra listas de contraseñas filtradas, eliminar la expiración periódica obligatoria (rotar solo ante evidencia de compromiso), y descartar las «preguntas de seguridad» basadas en conocimiento. El objetivo: reglas que resistan ataques reales en vez de empujar a los usuarios hacia patrones predecibles.

La MFA resistente al phishing significa que el segundo factor no puede reproducirse contra el sitio real aunque se engañe al usuario. Las passkeys FIDO2/WebAuthn lo logran con criptografía de clave pública ligada al origen: el autenticador firma un desafío atado al dominio del sitio real, así que una credencial capturada por un sitio imitador o un atacante en el medio es inútil. Los códigos TOTP y las notificaciones aún se pueden phishear porque pueden retransmitirse en tiempo real.

PAM controla y monitoriza las cuentas que pueden causar más daño: administradores de dominio, root, cuentas de servicio. Custodia y rota sus credenciales para que ningún secreto se comparta ni quede embebido, intermedia las sesiones para que los administradores nunca vean la contraseña en claro, graba lo que hacen los usuarios privilegiados, y concede idealmente la elevación justo a tiempo en vez de acceso permanente. El objetivo es reducir el radio de impacto de las cuentas que más codician los atacantes.

SCIM (System for Cross-domain Identity Management) es una API REST/JSON y un esquema estándar para crear, actualizar y eliminar cuentas de usuario en todas las aplicaciones. Conectado a un sistema de RR. HH. o a un IdP, automatiza el ciclo de vida joiner-mover-leaver: las cuentas y los permisos se aprovisionan en la contratación, se ajustan en el cambio de rol y —lo más importante— se desaprovisionan en la salida, eliminando las cuentas huérfanas que tanto gustan a los atacantes.

SSH usa TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS el 53 (UDP y TCP), RDP TCP 3389 y SMB TCP 445. Conocer los puertos bien conocidos te permite leer la salida de un escaneo, escribir reglas de cortafuegos y triar alertas con rapidez — un servicio en su puerto esperado frente a uno inesperado es una señal inmediata.

Un resolutor stub pide un nombre a un resolutor recursivo. Si no está en caché, el resolutor recursivo recorre la jerarquía: consulta un servidor raíz (que apunta al TLD), el servidor TLD (que apunta a los servidores autoritativos del dominio) y finalmente el servidor autoritativo, que tiene el registro real. La respuesta se cachea por el camino según su TTL. El DNS usa el puerto 53 — UDP para la mayoría de las consultas, TCP para las grandes.

Un proxy directo se sitúa delante de los clientes y hace peticiones salientes en su nombre — para control de salida, filtrado, cacheo y anonimato. Un proxy inverso se sitúa delante de los servidores y recibe peticiones entrantes en su nombre — para balanceo de carga, terminación TLS, cacheo y como fachada de seguridad para un WAF. La dirección a la que mira, lado cliente o lado servidor, es la distinción clave.

Traceroute descubre los routers entre tú y un destino explotando el campo TTL. Envía paquetes con TTL=1, luego 2, luego 3, y así sucesivamente. Cada router decrementa el TTL; cuando el TTL llega a cero, ese router descarta el paquete y devuelve un mensaje ICMP Time Exceeded, revelando su dirección. Al ir subiendo el TTL, traceroute mapea cada salto en orden hasta alcanzar el destino.

NAT (Network Address Translation) reescribe la IP de origen o destino a medida que los paquetes cruzan una frontera, normalmente mapeando direcciones internas privadas a públicas. PAT (Port Address Translation, o NAT overload) lo amplía traduciendo también los puertos, permitiendo que muchos hosts internos compartan una sola IP pública — cada flujo distinguido por su puerto. PAT es lo que usan los routers domésticos y de oficina para poner toda una LAN tras una sola dirección.

El modelo OSI divide la red en siete capas, cada una añadiendo una responsabilidad: Física (bits en el cable), Enlace de datos (tramas y direccionamiento MAC), Red (enrutamiento IP), Transporte (TCP/UDP, puertos, fiabilidad), Sesión (gestión de conexiones), Presentación (codificación, cifrado, compresión) y Aplicación (protocolos como HTTP). Cada capa envuelve a la de encima a medida que los datos bajan por la pila.

Una subred es una subdivisión lógica de una red IP. La máscara de subred marca qué bits de una dirección IP son la porción de red y cuáles la porción de host — por ejemplo, /24 (255.255.255.0) significa que los primeros 24 bits identifican la red y los últimos 8 identifican los hosts. La subdivisión controla cómo se enruta el tráfico y permite segmentar una red en dominios de difusión más pequeños.

TCP abre una conexión en tres pasos. El cliente envía un SYN con un número de secuencia inicial, el servidor responde con SYN-ACK (confirmando el número del cliente y enviando el suyo), y el cliente devuelve un ACK. Tras este intercambio ambos lados han acordado los números de secuencia de inicio y la conexión queda establecida para una entrega de bytes fiable y ordenada.

TCP está orientado a la conexión: negocia, numera bytes, retransmite las pérdidas y controla la congestión, dando una entrega fiable y ordenada a costa de latencia y sobrecarga. UDP no tiene conexión y funciona como disparar-y-olvidar — sin negociación, sin retransmisión, sin orden. Usa TCP cuando importa la corrección (web, correo, transferencia de archivos) y UDP cuando importa más la velocidad que la perfección (DNS, VoIP, juegos, vídeo).

El modelo TCP/IP tiene cuatro capas — Enlace, Internet, Transporte y Aplicación — y describe cómo funciona la Internet real. OSI tiene siete. Se corresponden de cerca: la capa de Aplicación de TCP/IP absorbe las capas de Aplicación, Presentación y Sesión de OSI; su capa de Enlace combina las capas Física y de Enlace de datos de OSI. OSI es la mejor referencia para enseñar y resolver problemas; TCP/IP es la suite de protocolos realmente implementada.

Una VLAN (LAN virtual) particiona lógicamente un switch físico en dominios de difusión de capa 2 separados, de modo que dispositivos en VLAN distintas no pueden alcanzarse directamente aun en el mismo hardware. Se rotula con una etiqueta 802.1Q en los enlaces troncales. El valor de seguridad es la segmentación: aislar el tráfico de usuarios, servidores, invitados e IoT limita el alcance de la difusión y el movimiento lateral, forzando el tráfico entre VLAN a pasar por un router o cortafuegos donde se aplica la política.

Una VPN crea un túnel cifrado a nivel de red/SO, de modo que todo el tráfico de un dispositivo se enruta por él y se protege de extremo a extremo — usada para el acceso remoto seguro. Un proxy opera a nivel de aplicación, retransmitiendo tráfico de aplicaciones o protocolos específicos sin cifrarlo necesariamente. Las grandes diferencias son el alcance (todo el dispositivo vs por aplicación) y que una VPN cifra por diseño mientras que muchos proxys no.

Una DMZ (zona desmilitarizada) es un segmento de red situado entre la Internet no confiable y la red interna de confianza, que aloja servicios expuestos al público como servidores web, de correo y DNS. Las reglas del cortafuegos permiten que Internet alcance la DMZ pero restringen estrictamente el acceso de la DMZ a la red interna. El objetivo es la contención: si un servidor público se ve comprometido, el atacante queda atrapado en la zona de amortiguación en lugar de aterrizar dentro de la LAN.

El reconocimiento pasivo reúne información sin interactuar directamente con los sistemas del objetivo — OSINT, registros DNS, transparencia de certificados. El reconocimiento activo toca el objetivo, como el escaneo de puertos o la captura de banners, que es más ruidoso pero aporta más detalle.

Una pentest avanza por el precompromiso (alcance y reglas de enfrentamiento), el reconocimiento, el escaneo y la enumeración, la explotación, la postexplotación y el informe. Cada fase alimenta la siguiente, y el informe es donde realmente se entrega el valor al cliente.

Un escaneo de vulnerabilidades es un inventario automatizado y en amplitud de debilidades potenciales, a menudo con falsos positivos. Una prueba de penetración la dirige un humano: valida los hallazgos, los encadena y demuestra un impacto de negocio real mediante una explotación efectiva.

La defensa en profundidad consiste en superponer varios controles de seguridad independientes de modo que, si uno falla, los demás sigan protegiendo el activo. Ningún control se supone perfecto, así que se apilan medidas preventivas, de detección y de respuesta en las capas de red, host, aplicación y datos.

El cifrado es reversible: con la clave recuperas el texto plano; protege la confidencialidad. El hashing es una función unidireccional que produce un resumen de tamaño fijo que no se puede revertir; verifica integridad e identidad. Las contraseñas deben hashearse con un algoritmo lento y salado como bcrypt o Argon2, nunca cifrarse.

El cifrado simétrico usa una sola clave compartida para cifrar y descifrar: es rápido, pero la clave debe compartirse de forma segura. El cifrado asimétrico usa un par de claves pública/privada, resolviendo la distribución de claves pero lentamente. Los sistemas reales usan criptografía asimétrica para intercambiar una clave de sesión simétrica y luego el rápido cifrado simétrico para los datos en masa.

El EDR se centra en el endpoint: registra y responde a la actividad de procesos, archivos y red en los hosts. El XDR extiende esa correlación a varios dominios —endpoint, red, identidad, correo, nube— como una stack integrada de un mismo proveedor. El SIEM es la capa amplia de agregación de logs que ingiere datos de cualquier fuente, incluidas las no de seguridad, para detección, búsqueda y cumplimiento.

Examina el correo sin hacer clic: revisa las cabeceras y la autenticación del remitente (SPF/DKIM/DMARC), inspecciona las URL y adjuntos en un sandbox o con herramientas de reputación, y luego mide el alcance: quién más lo recibió, si alguien hizo clic o introdujo credenciales. Según los hallazgos, remedia purgando el correo, bloqueando los indicadores y restableciendo las credenciales expuestas.

Un SIEM ingiere y correlaciona logs de todo el parque para generar alertas: es tu capa de detección y búsqueda. Un SOAR se sitúa aguas abajo y automatiza la respuesta: ejecuta playbooks, enriquece las alertas mediante integraciones y gestiona los casos para que los analistas dediquen menos tiempo a pasos repetitivos.

Confirma que la alerta es real antes de actuar: lee qué se disparó y por qué, luego enriquécela: quién es el usuario, si la IP/geo/dispositivo de origen son esperados, si hay viaje imposible, si hubo fallos previos. Clasifica como verdadero o falso positivo, escala o contén si es real (desactivar la sesión, forzar un restablecimiento de MFA) y documéntalo todo para que el siguiente analista pueda seguir tu razonamiento.

HTTP no tiene estado — cada petición es independiente y no guarda memoria de las anteriores. Las sesiones añaden estado por encima: tras iniciar sesión, el servidor emite un identificador que el navegador almacena en una cookie y reenvía en cada petición. Las sesiones del lado del servidor mantienen el estado en el servidor indexado por un ID de sesión opaco; los tokens sin estado como los JWT ponen el estado firmado en el propio token para que el servidor pueda verificar sin almacenamiento.