Linux & Open Source · Software · ficha YoctoIT

Sicurezza Linux

SELinux/AppArmor, CIS benchmarks y cifrado: el Linux de producción se blinda por políticas, no por suerte.

FOCUS · EL PINGÜINO BLINDADOMAC activo, baselines CIS y parches rápidos: la seguridad Linux como proceso medible
Material YoctoIT para clientes y partners · Linux es una marca de Linus Torvalds; las distribuciones y los productos citados son marcas de sus respectivos propietarios.
01 · Qué es

Sicurezza — SELinux & hardening, en claro.

El Linux seguro no es el que no tiene virus: es el endurecido por políticas. SELinux (o AppArmor) en enforcing — el proceso comprometido se queda en su jaula — las baselines CIS aplicadas y medidas (OpenSCAP), el cifrado (LUKS) sobre los datos, SSH reducido al hueso, y las CVE priorizadas por exposición real, no por titular de periódico.

Enforcing
SELinux activo de verdad: el exploit confinado por la política
CIS
las baselines aplicadas y MEDIDAS: la desviación visible, remediada
MFA+key
SSH sin contraseñas, con segunda verificación: la puerta principal, blindada
Sicurezza — SELinux & hardening
IMAGEN OFICIAL LINUX · SEGURIDAD LINUX
INTERFACCIA REALE · SCAP WORKBENCH · FONTE: OPENSCAP
INTERFAZ REAL · SCAP WORKBENCH · FUENTE: OPENSCAP
02 · Cómo usarlo bien

Las cosas que marcan la diferencia.

Las capas

Aplicaciones & datoslo que hay que defender
MAC (SELinux)
Hardening CIS
Cifrado & accesos
la jaula · la base · las llaves
OpenSCAP · la medidael compliance con números
Parches priorizadoslas CVE correctas, primero
La defensa que se demuestra

Enforcing sin dolor

SELinux encendido con método (audit, tuning, luego enforcing): la seguridad que no rompe la aplicación.

El escaneo que gobierna

OpenSCAP programado sobre el parque: el informe de compliance que guía las remediaciones.

Prioridad por exposición

La CVE sobre el servicio expuesto antes que la del paquete inerte: el patching inteligente.

Accesos dignos de 2026

sudo granular, claves rotadas, sesiones registradas: quién hace qué, siempre escrito.

03 · En profundidad

Hardening: SELinux, auditd y la baseline

La seguridad Linux se construye por capas: SELinux/AppArmor confinan los procesos (el servidor web comprometido no lee /etc/shadow), auditd registra las syscalls relevantes (la evidencia para el forensics), las baselines CIS/STIG se aplican y se miden con OpenSCAP (el informe de conformidad generado, no declarado), fapolicyd hace el allowlisting de los ejecutables, SSH se blinda (claves, MFA, sin root), el kernel se calibra (sysctl, lockdown); el secreto es la automatización: la baseline en Ansible, el drift medido.

  • SELinux enforcing — el proceso en el recinto: el exploit que no se extiende
  • OpenSCAP — CIS/STIG medidas: el informe de conformidad automático
  • auditd — las syscalls registradas: quién tocó qué, con las pruebas
  • fapolicyd — solo los ejecutables aprobados corren: el malware en seco
  • SSH hardening — claves+MFA, root cerrado: la puerta principal blindada
  • Baseline as code — el hardening en Ansible: igual en todas partes, medido siempre
04 · Números y ciclo de vida

Los números que cuentan.

100%
de los sistemas medibles con OpenSCAP
CIS L1/L2
los perfiles aplicados por criticidad
0
logins root directos: la trazabilidad total
NIS2
el hardening con evidencias: el requisito cubierto
El hardening de verdad es repetible: baselines, escaneos y remediaciones en automatización — la conformidad que se demuestra.
05 · Casos de uso

Dónde rinde de verdad.

Servidores expuestos

Web y API con la jaula SELinux activa.

Compliance NIS2

Las baselines con las evidencias, generadas por el proceso.

Post-incidente

El hardening serio después (o mejor: antes) de la lección.

Linux es seguro si alguien lo endurece: políticas, medida y parches — nuestro tríptico diario.