Security

Fundamentos de seguridad de sistemas y redes

Resumen

Esta guía de estudio independiente presenta los conceptos que sostienen la seguridad de sistemas Linux y redes. No está afiliada ni avalada por la Linux Foundation ni por ningún fabricante. La seguridad se trata como gestión de riesgo: no existe un estado "seguro" permanente, sino decisiones que reducen la probabilidad y el impacto de un incidente.

El recorrido cubre la triada CIA, la diferencia entre autenticación y autorización, el control de acceso en Linux, el cifrado y las amenazas habituales, y su operación.

Objetivos de aprendizaje

Al terminar este tema deberías poder:

• Distinguir amenaza, vulnerabilidad, riesgo y control.
• Explicar la triada CIA, la autenticidad y el no repudio.
• Diferenciar identificación, autenticación, autorización y auditoría.
• Aplicar mínimo privilegio con usuarios, grupos y sudo.
• Elegir entre cifrado simétrico, asimétrico y funciones hash.
• Relacionar vectores comunes con controles preventivos y detectivos.

Prerrequisitos y conexiones

Conviene dominar linux-operating-system para entender propietarios, permisos y procesos, y networking para interpretar direcciones, puertos, DNS y TLS. Este tema es la base de sensitive-data, que profundiza en clasificación y secretos, y de compliance, que traslada los controles a gobernanza y evidencia. También se relaciona con cloud-best-practices y con troubleshooting por el análisis de registros.

Modelo de amenazas, triada CIA y defensa en profundidad

Un activo es lo que se protege: datos, cuentas, servicios o reputación. Una amenaza es quien o qué puede causar daño; una vulnerabilidad es una debilidad explotable; y el riesgo combina probabilidad e impacto. Así se evita confundir vulnerabilidad con incidente.

La triada CIA: la confidencialidad limita quién lee; la integridad evita o detecta modificaciones no autorizadas; la disponibilidad mantiene el servicio accesible. Se añaden autenticidad (el origen es quien dice ser) y no repudio.

La defensa en profundidad combina controles independientes: segmentación, permisos mínimos, cifrado, registro y respaldo. El mínimo privilegio reduce el daño de una cuenta comprometida; la separación de funciones impide que una persona complete sola una operación crítica. El diseño debe fallar de forma segura: ante un error, deniega.

Identidad: autenticación, autorización y responsabilidad

La identificación declara una identidad; la autenticación demuestra que es cierta; la autorización decide qué puede hacer; y la auditoría registra lo ocurrido. Un inicio de sesión correcto no implica permiso para todas las operaciones; confundirlas produce fallos de control de acceso, una categoría destacada del OWASP Top Ten.

Los factores son conocimiento, posesión y biometría. MFA exige dos categorías distintas. Los códigos por SMS pueden interceptarse o sufrir phishing; las llaves de seguridad resisten mejor, y CISA las prioriza en cuentas de alto valor.

NIST SP 800-63B aconseja frases largas, comparación contra valores comprometidos y no imponer composición ni rotación arbitraria. La longitud y el bloqueo de intentos importan más que símbolos predecibles. Las cuentas administrativas deben ser individuales y trazables.

La autorización puede basarse en roles (RBAC), atributos (ABAC) o políticas. RBAC asigna permisos a roles y usuarios a roles; el riesgo aparece cuando los roles acumulan privilegios. Revisar accesos y dar de baja cuentas a tiempo es esencial.

Control de acceso en Linux

El modelo tradicional de Linux es DAC: el propietario decide los permisos. Cada archivo tiene lectura, escritura y ejecución para propietario, grupo y otros. umask retira permisos al crear archivos, y las ACL permiten reglas más finas.

root evita las comprobaciones ordinarias. Por eso las tareas administrativas se canalizan mediante sudo, con reglas concretas en sudoers. Conceder ALL=(ALL) NOPASSWD: ALL a un grupo amplio reparte privilegios totales. Los bits setuid y setgid pueden elevar privilegios y deben auditarse; el bit sticky evita que un usuario borre archivos ajenos en directorios compartidos.

Los controles obligatorios (MAC), como SELinux o AppArmor, restringen incluso a procesos con permisos DAC suficientes: un servicio comprometido queda confinado a su perfil. SSH debe usar claves, evitar el acceso de root y desactivar contraseñas cuando sea viable; los servicios necesitan cuentas propias, sin shell y con acceso mínimo.

Cifrado, integridad y comunicaciones

El cifrado simétrico usa una misma clave para cifrar y descifrar; es rápido y adecuado para grandes volúmenes. El asimétrico usa un par de claves y facilita intercambio, firmas y autenticación, con mayor coste. Las funciones hash producen una huella unidireccional: verifican integridad y almacenan contraseñas, pero no permiten recuperar el contenido.

Una contraseña no debe cifrarse de forma reversible. Se guarda con un hash lento y salado, como bcrypt, scrypt o Argon2, calibrado según el hardware. Un hash rápido sin sal no resiste diccionarios ni tablas precalculadas. "Hash" no es sinónimo de "cifrado": el primero no permite descifrar, el segundo sí.

TLS protege datos en tránsito con cifrado, integridad y autenticación del servidor mediante certificados. El cliente debe validar la cadena y el nombre del host; desactivarlo abre la puerta a intermediarios. Se recomiendan TLS 1.2/1.3 y gestionar certificados y claves privadas. Cifrar en tránsito no protege datos almacenados; cifrar en reposo no protege una sesión interceptada.

Amenazas comunes y respuesta

El OWASP Top Ten agrupa riesgos web: control de acceso quebrado, fallos criptográficos, inyección, diseño inseguro, mala configuración, componentes desactualizados, fallos de autenticación e integridad, monitoreo insuficiente y falsificación de solicitudes. La inyección se mitiga con consultas parametrizadas y validación.

Otras amenazas son phishing, fuerza bruta y credential stuffing, malware y ransomware, interceptación y abuso interno. Los controles se combinan: MFA, parches, segmentación, copias probadas, registros centralizados, alertas y formación.

El NIST CSF 2.0 organiza la gestión en Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar. Ante un incidente conviene contener, preservar evidencia, erradicar la causa, recuperar con copias verificadas y documentar lecciones. Restaurar sin corregir la causa puede repetir el compromiso.

Comparación de mecanismos criptográficos

Mecanismo	Material de clave	Coste por operación	Uso principal	Ejemplos
Cifrado simétrico	una clave compartida	bajo	grandes volúmenes y sesiones activas	AES-128 y AES-256 en modos AEAD
Cifrado asimétrico	par público y privado	alto	pactar claves, firmar y autenticar	RSA-2048, ECDSA, Ed25519
Función hash	sin clave, o con clave en HMAC	muy bajo	huella de integridad y verificación de archivos	SHA-256, SHA-3, HMAC
Derivación de claves	contraseña y sal	alto y ajustable	obtener una clave a partir de una contraseña débil	Argon2, scrypt, bcrypt

Para elegir entre ellos conviene preguntar tres cosas: si existe un canal seguro para compartir material de clave, cuántos datos se van a proteger y si quien recibe necesita verificar el origen. El simétrico presupone que ambas partes ya comparten la clave; el asimétrico resuelve esa distribución y produce firmas, pero su coste por operación lo obliga a quedarse en el intercambio.

En TLS, por ejemplo, la negociación inicial usa claves públicas y el tráfico posterior viaja cifrado con claves simétricas derivadas, porque procesar gigabytes con operaciones asimétricas sería inviable. El hash sirve de puente entre ambos mundos: varios protocolos firman primero la huella del mensaje y firman después esa huella, en lugar de firmar el mensaje completo.

Una firma se produce con la clave privada y se comprueba con la pública, y aporta integridad, autenticidad del origen y no repudio, propiedades que el cifrado por sí mismo no garantiza. Por eso las actualizaciones de software se publican con un archivo de firma aparte: el paquete puede descargarse de cualquier espejo y la comprobación sigue siendo concluyente.

Los modos contemporáneos son autenticados (AEAD), como AES-GCM o ChaCha20-Poly1305, y devuelven una etiqueta que detecta manipulación antes de entregar el texto plano. En estos modos la pareja de clave y número deveces no debe repetirse: reutilizarla degrada la confidencialidad y permite falsificar la etiqueta, por lo que los protocolos generan esos valores con contadores o fuentes criptográficas.

TLS 1.3 fija canjes efímeros de Diffie-Hellman, de modo que el posterior decomiso de la clave privada del servidor no permite descifrar conversaciones anteriores (secreto a futuro o forward secrecy); en TLS 1.2 podía negociarse un intercambio estático sin esa propiedad, y retirar esa versión elimina la elección débil del catálogo de suites.

Filtrado, firewalls y segmentación de red

Tipo	Capa	Mantiene estado	Aporta	Límite habitual
Filtrado de paquetes	L3/L4	opcional	reglas por IP, puerto y protocolo	no interpreta el contenido
Firewall estatal	L3/L4	sí	descarta lo que no pertenece a una sesión abierta	ninguna visión de aplicación
Proxy de aplicación	L7	sí	inspecciona peticiones y respuestas completas	exige terminar el TLS o instalar agentes
Firewall de nueva generación	L4-L7	sí	inspección profunda y reglas por usuario	coste y puesta en marcha
WAF	HTTP/HTTPS	sí	patrones contra inyección, rutas y fuzzing	no compensa componentes desactualizados

En Linux el filtrado local se expresa con nftables o con su predecesor iptables: política por cadena de denegar, reglas por dirección y puerto, y seguimiento del estado de conexión. Este filtrado complementa al perímetro porque sigue operando cuando el tráfico ya está dentro del host y hasta entonces nadie lo había inspeccionado.

Las reglas deben reflejar flujos concretos: entre bastidores, la base de datos escucha en la red del servicio y acepta únicamente al host de aplicación. Ese resultado no se consigue abriendo rangos enteros ni desactivando el filtrado para que algo funcione; la excepción demasiado amplia es la forma más corriente de anular un firewall sin darse cuenta.

La segmentación por proyecto limita el movimiento lateral: que un contenedor quede comprometido no debería habilitar conexiones al almacén de otra aplicación. Si el firewall solo separa "interno" de "externo", esa separación interna no existe y cada host comprometido abre el camino al resto.

Amenaza → control: del catálogo a la operación

Amenaza	Vía de entrada	Control preventivo	Control detectivo
Credential stuffing	reutilización de credenciales filtradas	MFA, contraseñas comprometidas revocadas, límite de intentos	alertas de origen inusual y picos de fallos de acceso
Inyección SQL	consultas construidas con entrada del usuario	consultas parametrizadas y privilegio mínimo en la base de datos	registros de error inesperado y reglas puntuales en el WAF
Fuerza bruta contra SSH	servicio expuesto con contraseñas débiles	claves en lugar de contraseñas y lista corta de orígenes	ráfagas de intentos fallidos por dirección de origen
Phishing dirigido	correo con enlaces falsificados	formación, autenticación del sobre (SPF, DKIM, DMARC) y llaves de seguridad	reportes de usuarios y simulacros con métrica de clics
Ransomware	acceso inicial y cifrado masivo	segmentación, parches de prioridad y respaldos aislados	escrituras masivas y procesos que cifran miles de ficheros
Dependencias alteradas	paquete malicioso en una biblioteca	repositorio interno, versiones fijadas y revisión de cambios	alertas de dependencia nueva o de hash inesperado

Cada fila exige dos piezas: una medida que reduzca la probabilidad y otra que revele el intento producido a pesar de aquella. Un diseño exclusivamente preventivo deja al equipo ciego cuando el control falla, y el descubrimiento llega como aviso de un tercero en el peor momento posible.

Gestión de vulnerabilidades y línea base

El escaneo combina pasos externos (lo que ve Internet), internos (lo que ve la red corporativa) y autenticados (versión real de paquetes y configuración, con credenciales). Cada hallazgo se identifica con un CVE público en el catálogo común del NVD, y su puntuación CVSS orienta la gravedad técnica, mientras que el orden final lo fija la exposición real y el valor del activo: una base de datos sin ruta exterior no tiene la misma urgencia que un servicio publicado.

Una política interna de plazos puede fijar corrección en 72 horas para vulnerabilidades críticas expuestas, dos semanas para graves y un trimestre para el resto, siempre con registro de la excepción aprobada. Un ticket sin responsable ni fecha de compromiso es deuda técnica disfrazada de plan.

La línea base de endurecimiento describe la configuración esperada por rol; los Benchmark del CIS son un punto de partida verificable. Comprende cuentas innecesarias dadas de baja, servicios sin uso desactivados, credenciales por defecto cambiadas, versiones de bibliotecas fijadas y permisos acordes al mínimo privilegio. La desviación respecto de esa referencia se mide con escaneo de configuración, no con la memoria de quien instaló el servidor.

Detección con registros: señal antes que volumen

Los eventos se envían a un destino central con marca de tiempo sincronizada por NTP; sin relojes alineados no se puede reconstruir el orden de un incidente ni correlacionar entradas de hosts distintos. Los ficheros locales se restringen para que un atacante no los altere ni los vacíe, y una copia remota añadida mientras el host sigue en línea conserva la evidencia si más tarde lo comprometen.

Una vez cerrada la ingesta, el valor está en la señal: ráfagas de autenticaciones fallidas, sesiones elevadas mediante sudo desde cuentas de servicio, escrituras masivas sobre directorios de datos o conexiones salientes a destinos nunca vistos describen comportamientos anómalos. El mapa de tácticas y técnicas ATT&CK sirve para pautar la búsqueda y localizar huecos de detección.

Umbrales calibrados contra el patrón normal de la semana y supresión del ruido conocido evitan la fatiga de alertas; una alarma que se descarta siempre aporta menos que un control que sí se revisa. Antes de emitir una alerta conviene definir qué hará el turno de guardia cuando la reciba.

Flujo de TLS: recorrido de un canje

Con TLS 1.3 una sesión nueva ocupa una ida y vuelta:

1. El cliente envía un ClientHello con las versiones y suites que admite, los grupos de curva soportados y una clave pública efímera.
2. El servidor responde con un ServerHello que fija la versión y entrega su propia clave efímera; ambas partes calculan el mismo secreto con Diffie-Hellman.
3. Acto seguido, ya bajo cifrado, el servidor envía sus extensiones y su certificado, mientras que en TLS 1.2 ese contenido viajaba en claro junto a la negociación de suite.
4. El cliente valida la cadena hasta una autoridad de confianza de su almacén, comprueba vigencia, nombre del certificado (campo SAN) y, cuando procede, el estado de revocación mediante CRL u OCSP.
5. Cada parte envía un mensaje Finished con un resumen de todo el canje; si la comprobación falla, la sesión se aborta antes de entregar datos.
6. Del secreto compartido se derivan claves separadas por etapa y dirección con HKDF, y TLS 1.3 admite únicamente suites AEAD.

El modo de datos tempranos (0-RTT) permite enviar una carga en la ida inicial sin esperar a la respuesta, pero ese paquete es repetible: una posición de red maliciosa puede reproducir la petición, así que no debe usarse en acciones con efecto, como pagos o transferencias. Un certificado autodedicado solo resulta admisible en laboratorio, nunca en un servicio real.

Mínimo privilegio en la práctica diaria

En el proyecto tienda trabajan tres perfiles con derechos distintos. ana (desarrollo) escribe en los fuentes bajo /srv/tienda con permisos de grupo, pero la configuración de producción pertenece al propietario deploy y solo el pipeline de despliegue la modifica: sus credenciales personales jamás bastan para alterarla.

luis (operaciones) tiene en sudoers dos entradas concretas para recargar el servicio web y consultar su registro; no dispone de sesión libre como root ni de permisos para editar ficheros arbitrarios. nerea (pruebas) accede a la base de datos con una cuenta de solo lectura sobre una vista que no expone datos personales.

El acceso extraordinario para incidencias se concede como elevación temporal, mediante una sesión registrada que desaparece al cerrar el evento. Cada trimestre se cruzan los miembros de los grupos con la plantilla activa, de modo que nadie conserva derechos de un proyecto abandonado.

Ejemplos prácticos

Panel administrativo. Una web permite borrar clientes. Se habilita MFA para administradores, se separa el rol de soporte del de borrado, se registra cada acción con identidad y hora y se fuerza TLS con validación. La autorización se comprueba en el servidor, no ocultando botones.

Servidor Linux. SSH usa claves individuales, se desactiva el acceso de root y se exige sudo para tareas concretas. Los servicios corren sin privilegios. Una revisión detecta un archivo editable por un grupo amplio; se corrige el propietario y se rotan las credenciales.

Ransomware. El equipo se aísla, se conserva una imagen y se comprueban los respaldos antes de restaurar. Luego se investiga el vector, se aplican parches y se revisan las cuentas con acceso.

Base de datos interna expuesta. Un escaneo exterior detecta el puerto de datos accesible desde la red pública. Se cierra la regla en el firewall, la base queda escuchando solo en la interfaz del servicio, se revisa el registro de conexiones recientes y se rotan las credenciales; un segundo escaneo confirma el cierre con evidencia.

Ráfaga de intentos de acceso. Una alerta informa de cuarenta fallos por minuto desde un rango poco habitual. Se activa bloqueo progresivo, se retira el acceso por contraseña en favor de claves y se cruzan las direcciones con el registro de sesiones exitosas: no hay ninguna, de modo que el intento queda como intento fallido documentado y sin efecto.

Errores frecuentes

• Creer que autenticación y autorización son lo mismo.
• Confiar solo en HTTPS y descuidar permisos, parches, secretos y respaldos.
• Imponer contraseñas cortas y rotaciones frecuentes en lugar de longitud y bloqueo.
• Conceder sudo amplio y compartir cuentas administrativas.
• Desactivar la validación de certificados para "solucionar" un error de TLS.
• Mantener respaldos conectados con las credenciales de producción.
• Registrar datos sensibles, tokens o contraseñas en los logs.

Puntos clave para el examen

Relaciona cada propiedad CIA con un ejemplo y distingue riesgo de vulnerabilidad. MFA combina categorías distintas; RBAC aplica mínimo privilegio con roles. En Linux, diferencia DAC, sudo, setuid y MAC. Separa cifrado simétrico, asimétrico y hash, y explica qué aporta TLS. Asocia OWASP y NIST CSF con controles preventivos, detectivos y de recuperación.

Recuerda además la tabla de mecanismos criptográficos y su lógica de coste, la jerarquía de firewalls por capas, el doble requisito preventivo-detectivo en cada fila de amenazas y el papel de la línea base al detectar desviaciones. El recorrido de canje TLS 1.3 y el escenario de mínimo privilegio suelen plantearse como casos prácticos, no como definiciones.

Recursos externos

• NIST Cybersecurity Framework
• OWASP Top Ten
• CISA: autenticación multifactor
• NIST SP 800-63B: guía de autenticación digital
• CIS Controls

Autoevaluación

1. Un atacante modifica una factura sin que nadie lo detecte. ¿Qué propiedad falla? Respuesta: Integridad. Justificación: El dato sigue disponible, pero fue alterado; los controles deben impedir o detectar esa modificación.

2. ¿Por qué no se debe almacenar una contraseña con cifrado reversible? Respuesta: Porque quien obtenga la clave podría recuperar todas. Justificación: Se usa un hash lento con sal, que verifica sin conservar el valor original.

3. Un usuario inicia sesión pero recibe "acceso denegado" al abrir una sección. ¿Qué etapa falló? Respuesta: La autorización. Justificación: La autenticación ya se completó; la decisión sobre permisos es independiente y se valida en el servidor.

4. ¿Qué riesgo tiene un archivo de configuración con permisos 0666? Respuesta: Cualquier usuario puede leerlo y modificarlo. Justificación: La escritura para "otros" permite alterar la configuración y, si hay credenciales, las expone.

5. Tras un compromiso, ¿por qué contener antes de restaurar? Respuesta: Porque restaurar sin erradicar la causa puede reinfectar. Justificación: La contención limita el movimiento lateral y preserva evidencia; la recuperación usa copias verificadas.

6. Se firma el hash de un paquete con la clave privada del distribuidor. ¿Qué queda demostrado? Respuesta: Que el contenido no cambió y quién lo publicó. Justificación: La huella resume el archivo y la firma enlaza esa huella con el emisor, sin cifrar el paquete.

7. ¿Qué gana un firewall estatal frente a una regla simple de filtrado? Respuesta: Descarta paquetes que no continúan una sesión válida. Justificación: El filtrado simple evalúa reglas paquete a paquete; el estado recuerda las conexiones abiertas y evita abrir puertos uno a uno.

8. Con TLS 1.3, ¿la clave privada del servidor robada hoy permite leer las conversaciones anteriores? Respuesta: No. Justificación: El canje usó claves efímeras, y la clave robada no permite reconstruir la derivación de aquellas sesiones previas.

9. ¿Qué se pierde cuando los servidores no sincronizan su hora? Respuesta: El orden fiable de los eventos. Justificación: Sin relojes alineados no se reconstruye la secuencia de un incidente ni se correlacionan registros de máquinas distintas.

10. ¿Qué representa una línea base de endurecimiento? Respuesta: La configuración esperada para cada rol. Justificación: Permite comparar el estado real con una referencia objetiva y detectar desviaciones sin apoyarse en criterios personales.