20 Preguntas de Práctica de Cortafuegos, criptografía y cumplimiento con Respuestas

1. 1. En un host Linux, iptables, nftables, firewalld y ufw se describen todos como herramientas de cortafuegos. ¿Qué afirmación describe correctamente cómo se relacionan entre sí?

   • A.Cada una incorpora su propio motor de filtrado en espacio de usuario, así que habilitar dos a la vez aplica dos filtros independientes en secuencia.
   • B.firewalld inspecciona los paquetes por sí mismo y entrega solo el tráfico aprobado a netfilter, que decide después la ruta de cada conexión aceptada.
   • C.El filtrado ocurre en el marco netfilter del kernel; nftables es su interfaz actual en espacio de usuario, y firewalld y ufw son front ends que generan las reglas.✓ Respuesta
   • D.ufw sustituyó a netfilter dentro del kernel de la familia Debian, mientras que nftables solo verifica la sintaxis de reglas en sistemas de la familia RHEL.

   netfilter es el marco de ganchos del kernel que inspecciona realmente los paquetes. La familia de comandos iptables y su sucesor nft son herramientas de espacio de usuario que cargan reglas en él, mientras firewalld (familia RHEL) y ufw (familia Debian) son front ends de más alto nivel que traducen peticiones de zona o servicio a esas mismas reglas del kernel. Ninguno filtra paquetes en espacio de usuario.

   Ref. QB-PWQNRHFuente: Linux kernel networking documentation (netfilter framework) and the nft(8), firewall-cmd(1) and ufw(8) manual pagesReportar un problema con esta pregunta

2. 2. Un host de la familia RHEL se filtra con comandos iptables. La cadena INPUT ya termina con una regla que descarta todo el tráfico restante. El administrador ejecuta `iptables -A INPUT -p tcp --dport 443 -j ACCEPT`, pero HTTPS sigue inaccesible. ¿Qué lo explica?

   • A.Las reglas de una cadena se evalúan de arriba abajo y gana la primera coincidencia, así que la regla de descarte anterior ya trató el paquete; hay que insertarla con `-I`.✓ Respuesta
   • B.El destino ACCEPT solo es válido en la tabla nat, así que la regla debe volver a añadirse con `-t nat -A INPUT` para que permita alguna conexión HTTPS entrante al host.
   • C.Al añadir con `-A` la regla entra en la cadena FORWARD por omisión, de modo que el tráfico dirigido al propio host nunca se compara con la regla nueva.
   • D.La coincidencia `--dport` se ignora si la regla no lleva también `-m conntrack --ctstate NEW`, por lo que el kernel la salta y cae en la regla de descarte.

   Dentro de una cadena, netfilter recorre las reglas en orden y se detiene en la primera cuyos criterios coinciden, aplicando su destino. Como el descarte general está antes de la regla añadida, el paquete se descarta antes de llegar al ACCEPT. `-A` añade al final de la cadena, mientras `-I` inserta al principio o en una posición numerada, que es lo que coloca el permiso delante del descarte.

   Ref. QB-7EWTBJFuente: iptables(8) manual page, rule specification and the -A and -I optionsReportar un problema con esta pregunta

3. 3. Una revisión pregunta por qué una regla de iptables termina en `-j DROP` y otra en `-j REJECT`. ¿Cuál es la diferencia práctica entre ambos destinos?

   • A.DROP devuelve un mensaje ICMP de puerto inalcanzable mientras REJECT descarta el paquete en silencio, así que DROP informa más en una red interna.
   • B.DROP descarta el paquete sin responder, así que el emisor espera hasta el tiempo límite, mientras REJECT devuelve un error ICMP y el emisor falla de inmediato.✓ Respuesta
   • C.DROP descarta el paquete y lo anota en el búfer circular del kernel, mientras REJECT lo descarta sin registrar nada, y por eso se prefiere para auditorías.
   • D.Ambos descartan el paquete de forma idéntica; REJECT es solo un alias conservado por compatibilidad con versiones antiguas y no cambia nada en la red.

   DROP entrega el paquete a la ruta de descarte del kernel y no se devuelve nada, así que el intento de conexión del cliente queda colgado hasta agotar el tiempo límite, lo que además oculta el host ante sondeos casuales. REJECT descarta el paquete pero genera un error ICMP (puerto inalcanzable por omisión, u otro tipo elegido con `--reject-with`), así que el cliente falla de inmediato. Ambos detienen el tráfico; difieren en qué averigua el emisor y con qué rapidez.

   Ref. QB-QW3ZWJFuente: iptables-extensions(8) manual page, REJECT target and its --reject-with optionReportar un problema con esta pregunta

4. 4. Un equipo debe elegir entre una política INPUT de DROP con una lista explícita de permisos y una política INPUT de ACCEPT con una lista explícita de denegaciones. ¿Por qué se dice que el primer diseño falla en estado cerrado?

   • A.Una política DROP solo se aplica a interfaces administrativamente activas, así que el host sigue inalcanzable mientras alguna interfaz se inicializa.
   • B.Una política DROP obliga al kernel a recargar el conjunto guardado cada vez que se borra una regla, restaurando la última configuración válida.
   • C.Una política DROP hace que el seguimiento de conexiones trate cada paquete como NEW, así se limpian los flujos a medias y no se reutiliza un estado.
   • D.Una política DROP descarta lo que ninguna regla iguala, así que una regla perdida al editar cuesta disponibilidad en vez de exponer el host.✓ Respuesta

   Con denegación por omisión, la lista de permisos es la declaración completa de lo permitido, y todo paquete que no coincide con nada llega a la política de la cadena y se descarta. Un error se manifiesta como pérdida de servicio, que es visible y se corrige. Con permiso por omisión, la lista de denegaciones debe enumerar cada caso indeseado, así que lo que el autor no previó, o un servicio que empieza a escuchar más tarde, queda accesible sin ningún error que lo revele.

   Ref. QB-8E96HKFuente: iptables(8) manual page, chain policy (-P); CompTIA Linux+ security content domain, firewall policy designReportar un problema con esta pregunta

5. 5. La política INPUT es DROP, se permite SSH entrante y otra regla dice `-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT`. La navegación web desde el host funciona aunque ninguna regla menciona el tráfico de respuesta. ¿Por qué?

   • A.El tráfico generado localmente queda exento del filtrado INPUT, así que las respuestas a peticiones propias no pasan por la cadena ni necesitan regla.
   • B.El estado RELATED abre todos los puertos por encima de 1024 durante la sesión, y así llega al cliente el tráfico de retorno del servidor web remoto.
   • C.El seguimiento de conexiones registra el flujo saliente, así que los paquetes de vuelta coinciden con ESTABLISHED y se aceptan sin nombrar el servidor.✓ Respuesta
   • D.El criterio de política de la cadena solo se consulta cuando todas las reglas ACCEPT han fallado dos veces, dando a las respuestas otra pasada.

   Un cortafuegos con estado mantiene una entrada de conntrack por cada flujo visto. Cuando el host abre una conexión saliente se crea esa entrada, y los paquetes de respuesta del servidor se reconocen como pertenecientes a ella y se clasifican como ESTABLISHED, así que la única regla ESTABLISHED,RELATED los acepta. RELATED cubre un flujo distinto pero asociado, como un error ICMP de esa conexión. Sin seguimiento de conexiones habría que escribir reglas sin estado para cada respuesta posible.

   Ref. QB-RWEB4MFuente: iptables-extensions(8) conntrack match; Linux kernel networking documentation on connection trackingReportar un problema con esta pregunta

6. 6. En un servidor de la familia RHEL el administrador ejecuta `firewall-cmd --permanent --add-service=https` y prueba el servicio de inmediato desde otra máquina. La conexión sigue rechazada. ¿Qué está ocurriendo?

   • A.El cambio permanente se escribe en la configuración guardada de firewalld y no altera el conjunto activo hasta que `firewall-cmd --reload` lo carga.✓ Respuesta
   • B.El cambio ya está activo, pero el servicio https debe figurar además en /etc/services para que firewalld resuelva ese nombre a un número de puerto.
   • C.El comando modificó solo el conjunto de reglas activo, así que funciona ahora pero se perderá al reiniciar si no se ejecuta `--runtime-to-permanent`.
   • D.Los cambios permanentes se aplican solo a la zona por omisión, y la prueba falla porque la interfaz que lleva ese tráfico está asignada a otra zona distinta.

   firewall-cmd mantiene dos configuraciones separadas. Sin `--permanent` el cambio entra directamente en el conjunto activo y se pierde al recargar o reiniciar; con `--permanent` se escribe en la configuración guardada y el conjunto activo no se toca. `firewall-cmd --reload` lee la configuración permanente y la instala, y ese es el paso que hace accesible el servicio nuevo. `--runtime-to-permanent` hace lo contrario: guarda un conjunto activo que ya funciona.

   Ref. QB-9EMGPMFuente: firewall-cmd(1) manual page, --permanent, --reload and --runtime-to-permanent optionsReportar un problema con esta pregunta

7. 7. Trabajando por SSH en un host gestionado con firewalld, un administrador quita el servicio ssh de la zona activa como cambio solo en tiempo de ejecución y ya no puede abrir sesiones nuevas; la sesión actual sigue viva. ¿Qué acción restaura el acceso SSH desde la configuración guardada?

   • A.Ejecutar `firewall-cmd --runtime-to-permanent`, que reescribe la configuración guardada a partir del conjunto activo y recupera el estado anterior.
   • B.Ejecutar `firewall-cmd --reload`, que descarta el conjunto activo e instala la configuración permanente, donde ssh sigue permitido.✓ Respuesta
   • C.Ejecutar `firewall-cmd --complete-reload`, que vacía el seguimiento de conexiones para que el saludo SSH bloqueado se reintente y funcione.
   • D.Ejecutar `firewall-cmd --panic-on`, que suspende todo el filtrado de paquetes hasta que el administrador lo desactive y deja pasar las sesiones SSH.

   `--reload` descarta el conjunto de reglas activo y recarga la configuración permanente del disco, así que deshace un error de tiempo de ejecución que no se guardó. Por eso los cambios arriesgados se hacen primero en tiempo de ejecución y solo se promueven con `--runtime-to-permanent` cuando ya funcionan; aquí ese comando guardaría el conjunto roto, y `--panic-on` bloquea todo el tráfico en lugar de restaurar el acceso.

   Ref. QB-SWSN9NFuente: firewall-cmd(1) manual page, --reload versus --runtime-to-permanent and --panic-onReportar un problema con esta pregunta

8. 8. Un router Linux con dos interfaces debe (a) permitir que una subred interna salga a internet a través de su única dirección pública dinámica y (b) publicar un servidor web interno en esa dirección pública. Con iptables, ¿qué combinación es correcta?

   • A.DNAT en PREROUTING de la tabla nat para el sentido saliente, y MASQUERADE en POSTROUTING de la tabla nat para redirigir las conexiones entrantes.
   • B.MASQUERADE en POSTROUTING de la tabla nat para el sentido saliente, y DNAT en PREROUTING de la tabla nat para redirigir las conexiones entrantes.✓ Respuesta
   • C.SNAT en la cadena INPUT de la tabla filter para el sentido saliente, y REDIRECT en la cadena OUTPUT de filter para las conexiones entrantes.
   • D.MASQUERADE en la cadena OUTPUT de la tabla mangle para el tráfico saliente, y DNAT en la cadena FORWARD de mangle para las conexiones entrantes.

   La traducción de origen debe ocurrir después de la decisión de ruta, por eso vive en POSTROUTING, y MASQUERADE es la variante que toma la dirección de origen de lo que tenga la interfaz de salida en ese momento, que es lo que exige una dirección pública dinámica. La traducción de destino debe ocurrir antes de la decisión de ruta para que el paquete se encamine luego al servidor interno, así que el reenvío de puertos usa DNAT en PREROUTING. Ambas pertenecen a la tabla nat, y además debe estar habilitado de forma persistente el reenvío de IP.

   Ref. QB-AEYTUNFuente: iptables(8) and iptables-extensions(8) manual pages, nat table chains with the SNAT, MASQUERADE and DNAT targetsReportar un problema con esta pregunta

9. 9. Un servidor de la familia Debian necesita un cortafuegos mínimo: rechazar el tráfico entrante no solicitado pero mantener SSH accesible, configurado con ufw. ¿Qué secuencia es correcta y qué hace ufw con las reglas?

   • A.`ufw default drop all`, luego `ufw permit ssh` y `ufw start`; ufw actúa como su propio demonio e inspecciona los paquetes antes de que los vean los ganchos de netfilter.
   • B.`ufw allow OpenSSH` basta por sí solo, porque ufw deniega el tráfico entrante en cuanto se referencia algún perfil de /etc/ufw/applications.d.
   • C.`ufw enable`, luego `ufw allow 22` y `ufw reload`; ufw guarda las reglas en su propia base de datos y cada permiso exige un reload para activarse.
   • D.`ufw default deny incoming`, luego `ufw allow OpenSSH` y `ufw enable`; ufw traduce las reglas a netfilter y las vuelve a aplicar en cada arranque.✓ Respuesta

   ufw es el front end simplificado que distribuye la familia Debian. `ufw default deny incoming` fija la dirección general, `ufw allow OpenSSH` usa el perfil de aplicación que nombra el puerto, y `ufw enable` activa la política ahora y hace que se restaure al arrancar, así que a diferencia de los comandos iptables sueltos el conjunto es persistente. Por debajo, ufw genera reglas de netfilter en lugar de filtrar paquetes él mismo.

   Ref. QB-TW5ZEPFuente: ufw(8) manual page, default policy, application profiles and the enable subcommandReportar un problema con esta pregunta

10. 10. Un administrador debe enviar un archivo grande a un socio externo de modo que solo el socio pueda leerlo, usando GnuPG en Linux. ¿Qué enfoque es adecuado y qué papel cumple cada clave?

    • A.Cifrar con `gpg -c` y una frase de paso compartida, porque el modo simétrico permite que un receptor sin ningún par de claves descifre el archivo entregado.
    • B.Firmar el archivo con `gpg --detach-sign`, porque una firma separada deja el contenido ilegible para quien no tenga la clave pública del firmante.
    • C.Cifrar con `gpg --encrypt --recipient` indicando la clave pública del propio administrador, porque el par del emisor es lo que acredita el origen.
    • D.Cifrar con `gpg --encrypt --recipient` indicando la clave pública importada del socio, porque solo la clave privada que él guarda puede descifrarlo.✓ Respuesta

    El cifrado de clave pública es direccional: lo cifrado hacia una clave pública solo se descifra con la clave privada correspondiente. Para dar confidencialidad a un destinatario concreto se cifra hacia su clave pública, que antes debe importarse al llavero con `gpg --import` y comprobarse por su huella. `gpg -c` es simétrico y exigiría compartir una frase de paso por otro canal, mientras que una firma separada aporta autenticidad e integridad pero ninguna confidencialidad.

    Ref. QB-PRX7BRFuente: gpg(1) manual page, --encrypt with --recipient, --symmetric and --detach-signReportar un problema con esta pregunta

11. 11. Una partición libre acaba de inicializarse con `cryptsetup luksFormat /dev/sdb1` y luego abrirse con `cryptsetup open /dev/sdb1 secure`. ¿Cuál es el paso siguiente correcto y por qué?

    • A.Ejecutar `mkfs.ext4 /dev/sdb1`, porque el sistema de archivos debe estar en la partición para que la cabecera LUKS se añada detrás de él.
    • B.Ejecutar de nuevo `cryptsetup luksFormat` sobre /dev/mapper/secure, porque el dispositivo mapper necesita su propia cabecera antes de formatear.
    • C.Ejecutar `mkfs.ext4 /dev/mapper/secure`, porque el mapper es la vista descifrada y todo lo escrito por él se cifra en disco.✓ Respuesta
    • D.Ejecutar `mount /dev/mapper/secure /mnt`, porque luksFormat ya creó un sistema de archivos dentro del contenedor al escribir la cabecera.

    `cryptsetup open` crea un nodo de device-mapper, /dev/mapper/secure, que presenta el contenido descifrado del contenedor, y el sistema de archivos debe crearse en ese nodo porque lo escrito a través de él se cifra con la clave maestra del volumen antes de llegar a /dev/sdb1. Formatear la partición en crudo sobrescribiría la cabecera LUKS y destruiría el acceso; como la clave maestra vive en esa cabecera, respaldarla es lo que protege los datos y destruirla los vuelve irrecuperables.

    Ref. QB-69S2RQFuente: cryptsetup(8) manual page, luksFormat and open with the device-mapper node under /dev/mapperReportar un problema con esta pregunta

12. 12. Se comparan tres mecanismos sobre el mismo archivo: un resumen SHA-256, un HMAC calculado con SHA-256 y un secreto compartido, y una firma GnuPG. ¿Qué afirmación describe lo que establece cada uno?

    • A.El resumen solo detecta cambios, el HMAC muestra además que el emisor conocía el secreto compartido y la firma liga el archivo a una clave privada.✓ Respuesta
    • B.Los tres prueban el origen por igual y solo difieren en la longitud de salida, así que elegir depende del espacio que ocupe el valor guardado.
    • C.El resumen y el HMAC prueban el origen porque ambos dependen de un secreto, mientras que la firma solo muestra que el archivo no se alteró en tránsito.
    • D.El resumen prueba el origen porque solo el editor puede calcularlo, el HMAC no añade nada más y la firma solo comprime el resumen para transmitirlo.

    Un resumen simple se calcula solo a partir de los datos, así que cualquiera puede recalcularlo: detecta modificaciones pero no dice nada sobre quién produjo el archivo. Un HMAC mezcla un secreto compartido en el cálculo, así que un valor correcto muestra que el productor tenía ese secreto, aunque cualquiera de los dos poseedores podría haberlo generado. Una firma se hace con una clave privada y se comprueba con la pública correspondiente, así que liga el archivo a un titular concreto y aporta autenticidad además de integridad.

    Ref. QB-NRKV5QFuente: gpg(1) --verify and openssl-dgst(1) -hmac; CompTIA Linux+ security content domain, hashing and message authenticationReportar un problema con esta pregunta

13. 13. Se descarga un tarball desde un espejo comunitario y su salida de `sha256sum` coincide con el resumen mostrado en la página de descargas del proyecto. ¿Qué queda realmente establecido?

    • A.Que el archivo es auténtico y viene del proyecto, porque nadie salvo el proyecto podría producir un resumen que coincida con los bytes descargados.
    • B.Que el archivo no contiene ningún código malicioso, porque un resumen calculado sobre un archivo alterado nunca puede coincidir con el valor publicado.
    • C.Que los bytes coinciden con el resumen publicado; quien controle el espejo y esa página pasaría la prueba, por lo que hace falta `gpg --verify`.✓ Respuesta
    • D.Que la descarga estuvo protegida de extremo a extremo, porque el resumen solo llega intacto por una conexión TLS cuyo certificado se validó.

    Comparar una suma de comprobación solo demuestra que los bytes que tienes son los bytes sobre los que se calculó el resumen: es una comprobación de integridad frente a corrupción y frente a quien no pudiera cambiar además el valor publicado. Si una misma parte controla el archivo y la página que lista su resumen, ambos cambian juntos y la prueba sigue pasando. La autenticidad exige algo que el atacante no pueda falsificar, y por eso los proyectos publican una firma separada del archivo de sumas.

    Ref. QB-59EQJPFuente: sha256sum(1) and gpg(1) --verify; CompTIA Linux+ security content domain, file integrity and signed package verificationReportar un problema con esta pregunta

14. 14. Para un servidor web público, un administrador ejecuta `openssl genpkey` y luego `openssl req -new -key server.key -out server.csr`. ¿Qué contiene la solicitud resultante y qué aporta la CA?

    • A.Lleva la clave pública junto con los datos de identidad, y la CA lo firma entero para que cualquier cliente que confíe en esa CA acepte esa identidad.✓ Respuesta
    • B.Lleva un certificado autofirmado, y la CA le cambia las fechas para que los clientes acepten la firma existente durante el resto de su validez.
    • C.Lleva la clave privada para que la CA la verifique, y la CA devuelve esa misma clave dentro de un certificado junto con su propia clave raíz.
    • D.Lleva la lista de cifrados prevista, y la CA elige el par de claves en nombre del administrador antes de emitir el certificado firmado.

    Una solicitud de firma de certificado se genera a partir del par de claves pero contiene solo la mitad pública, más el nombre del sujeto y las extensiones pedidas, autofirmada para demostrar la posesión de la clave privada; esa clave privada nunca sale del servidor. El aporte de la CA es su firma, que atestigua que la identidad indicada se verificó según su estándar declarado, y los clientes aceptan el certificado porque ya confían en la raíz de la CA, no por algo intrínseco a la solicitud.

    Ref. QB-RRNVNTFuente: openssl-req(1) manual page, certificate request generation; X.509 certificate path validationReportar un problema con esta pregunta

15. 15. Un servidor web Linux interno presenta un certificado creado con `openssl req -x509`. El nombre de host coincide, las fechas de validez están vigentes y la clave privada es correcta, pero los navegadores siguen avisando de que la conexión no es privada. ¿Cuál es la razón?

    • A.Porque un certificado generado con `-x509` no contiene ninguna clave pública, así que el cliente no puede completar el intercambio y lo marca como no confiable.
    • B.Porque los certificados autofirmados tienen una vigencia muy corta y los navegadores rechazan todo certificado por debajo de su mínimo admitido.
    • C.Porque `-x509` produce una solicitud de firma y no un certificado, de modo que el cliente no logra interpretar el archivo ofrecido como certificado.
    • D.Porque lo firma su propia clave y no algo del almacén de confianza del cliente, así que la cadena termina en un firmante que no se puede verificar.✓ Respuesta

    La validación del cliente recorre la cadena de certificados hasta llegar a uno que ya está en el almacén de confianza local. Un certificado autofirmado es su propio emisor, así que la cadena termina en un ancla que al cliente nunca se le dijo que confiara, y el aviso aparece por correctos que sean el nombre y las fechas. La solución es un certificado de una CA cuya raíz ya sea confiable, o instalar deliberadamente la raíz de una CA interna en el almacén de los clientes; `openssl req -x509` sí produce un certificado real, solo que no confiable.

    Ref. QB-89GQ3TFuente: openssl-req(1) manual page, -x509 self-signed output; X.509 certificate path validation and local trust anchorsReportar un problema con esta pregunta

16. 16. Un servicio HTTPS que funcionó durante un año falla de pronto para todos los clientes un lunes por la mañana, y no se desplegó nada el fin de semana. ¿Qué comprobación debe hacerse primero y por qué la caducidad es un riesgo operativo permanente?

    • A.Reiniciar el servidor web y revisar su diario, porque un certificado caducado se recarga y se renueva solo la próxima vez que arranca el servicio.
    • B.Leer la vigencia con `openssl x509 -enddate -noout -in server.crt`; el certificado deja de aceptarse por su propio calendario, sin cambios en el host.✓ Respuesta
    • C.Comparar la huella del certificado con la raíz de la CA, porque la cadena deja de valer cuando la CA rota su raíz a una clave más larga.
    • D.Comprobar que la clave privada sigue coincidiendo con el certificado, porque los archivos de clave se desajustan con el uso continuado del sistema de archivos.

    Un certificado lleva marcas notBefore y notAfter fijas, así que falla la validación en el instante en que el reloj pasa notAfter aunque ningún archivo haya cambiado y no se haya tocado la configuración, y por eso un servicio intacto que antes funcionaba se rompe por sí solo. `openssl x509 -enddate` lee esa fecha del archivo y `openssl s_client -connect host:443` muestra lo que el servidor sirve realmente, de modo que la renovación debe seguirse y automatizarse en lugar de recordarse.

    Ref. QB-QRAJGSFuente: openssl-x509(1) manual page, -dates and -enddate; openssl-s_client(1) for the served chainReportar un problema con esta pregunta

17. 17. Un equipo instala AIDE en un servidor recién aprovisionado de la familia RHEL, edita /etc/aide.conf, ejecuta `aide --init` y luego `aide --check`, que informa de que no encuentra la base de datos. ¿Qué falta y qué hace fiable la línea base?

    • A.AIDE necesita `--config /etc/aide.conf` en cada comprobación, y la base es fiable porque AIDE recalcula toda la base en cada ejecución.
    • B.AIDE exige registrar la base con `aide --update` antes de la primera comprobación, y la base es fiable porque viene dentro del paquete instalado.
    • C.AIDE escribe la base nueva como aide.db.new.gz y hay que renombrarla; solo es fiable si se crea en un host limpio y se guarda fuera.✓ Respuesta
    • D.AIDE requiere descomprimir primero la base guardada, y esa base es fiable porque sus resúmenes se recalculan a partir del gestor de paquetes.

    `aide --init` escribe a propósito en un archivo nuevo para no sobrescribir por accidente una línea base existente, y hay que moverlo o renombrarlo a la ruta de base definida en /etc/aide.conf antes de que `aide --check` tenga algo con lo que comparar. El mecanismo solo responde si algo cambió desde la línea base, así que esta debe crearse en un sistema conocido como limpio y guardarse donde un intruso no pueda reescribirla, o el atacante simplemente rehará la línea base con sus propios cambios.

    Ref. QB-795DWRFuente: aide(1) and aide.conf(5) manual pages, --init and --check with the database_out settingReportar un problema con esta pregunta

18. 18. Un host de la familia RHEL podría haber sido manipulado. El administrador debe (a) confirmar que un paquete descargado proviene realmente del fabricante y (b) averiguar si los archivos ya en disco difieren de lo que entregó el paquete. ¿Qué combinación es correcta?

    • A.`rpm --checksig pkg.rpm` con la clave del fabricante importada para el archivo, y `rpm -Va` para los instalados, que los compara con la base de RPM.✓ Respuesta
    • B.`rpm -Va` para el archivo descargado, porque valida la firma de cualquier paquete, y `rpm --checksig pkg.rpm` para los archivos ya instalados.
    • C.`sha256sum pkg.rpm` para el archivo, porque el resumen por sí solo acredita al fabricante, y `rpm -qa` para los instalados, porque lista lo que entregó cada paquete.
    • D.`rpm --import` para el archivo, porque importarlo lo registra como confiable, y `rpm -qi` para los instalados, porque imprime sus resúmenes esperados.

    Son dos trabajos distintos. `rpm --checksig` (equivalente a `rpm -K`) comprueba la firma incrustada en el archivo de paquete contra claves importadas antes con `rpm --import`, y eso es lo que acredita que el archivo viene del fabricante sin modificar. `rpm -V` y `rpm -Va` no hacen nada con firmas: comparan los archivos instalados con el tamaño, modo, resumen, propietario, grupo y marca de tiempo registrados en la base de RPM, imprimiendo un indicador por prueba fallida y nada para un archivo intacto, y los archivos de configuración se marcan con `c` porque se espera que difieran.

    Ref. QB-TRCJZVFuente: rpm(8) manual page, --checksig and -K, and the -V verify options with their result flagsReportar un problema con esta pregunta

19. 19. En un servidor de la familia Debian hay cuatro tareas de seguridad: averiguar qué servicios de red están realmente a la escucha, comparar la configuración del host con una línea base de refuerzo publicada, saber si algún archivo vigilado cambió desde un punto conocido como bueno, y buscar rastros de un rootkit conocido. ¿Qué correspondencia entre herramientas y tareas es correcta?

    • A.Un escáner de puertos revisa la línea base de configuración, OpenSCAP halla los servicios a la escucha, rkhunter detecta archivos cambiados y AIDE busca rootkits.
    • B.OpenSCAP halla los servicios a la escucha, AIDE revisa la línea base de configuración, un escáner de puertos detecta archivos cambiados y rkhunter informa del perfil.
    • C.AIDE halla los servicios a la escucha, rkhunter revisa la línea base de configuración, OpenSCAP detecta archivos cambiados y un escáner de puertos busca rootkits.
    • D.Un escáner de puertos halla los servicios a la escucha, OpenSCAP revisa la línea base de configuración, AIDE detecta archivos cambiados y rkhunter busca rootkits.✓ Respuesta

    Responden a preguntas distintas y no son intercambiables. Un escáner de puertos sondea desde la red los puertos alcanzables para mostrar qué servicios están expuestos, y localmente `ss -tulpn` muestra esos mismos procesos a la escucha con su dueño. OpenSCAP evalúa la configuración en ejecución contra contenido SCAP legible por máquina, como un perfil de refuerzo publicado, e informa de aprobado o fallido por regla. AIDE compara el sistema de archivos con una línea base guardada de resúmenes y atributos, así que detecta cambios, no exposición. rkhunter busca indicadores de rootkits conocidos.

    Ref. QB-A97DEVFuente: oscap(8), aide(1), rkhunter(8) and ss(8) manual pages; CompTIA Linux+ security content domain, vulnerability scanning and file integrityReportar un problema con esta pregunta

20. 20. Un host de la familia RHEL se analiza con `oscap xccdf eval --profile <profile_id> --results results.xml --report report.html` usando contenido de SCAP Security Guide. Varias reglas fallan. ¿Cuál es la lectura correcta del resultado y el paso siguiente?

    • A.El análisis corrigió por sí mismo las reglas fallidas mientras las evaluaba, así que el informe describe un host que ya cumple el perfil elegido por completo.
    • B.El informe documenta el estado del host en ese momento; la remediación es un paso aparte y un nuevo análisis evidencia que se cerraron los hallazgos.✓ Respuesta
    • C.Las reglas fallidas indican que el perfil no aplica a este host, así que hay que elegir otro perfil hasta que el análisis no devuelva fallos.
    • D.El informe es el entregable que pide el auditor, así que una vez archivado los hallazgos quedan cerrados y solo hay que programar el siguiente.

    Una evaluación XCCDF compara la configuración en ejecución con las reglas del perfil elegido y escribe resultados más un informe legible; no cambia nada salvo que se pida la remediación explícitamente, con la opción correspondiente o generando un guion o playbook de remediación a partir de los resultados y aplicándolo. Por tanto el informe es evidencia del estado en un momento dado, no un resultado: un hallazgo se cierra solo después de cambiar la configuración y de que un nuevo análisis muestre la regla como aprobada. `oscap info` sobre el flujo de datos lista los identificadores de perfil disponibles para `--profile`.

    Ref. QB-STXCUUFuente: oscap(8) manual page, xccdf eval with --profile, --results, --report and the remediation optionReportar un problema con esta pregunta

Preguntas de práctica redactadas según los objetivos publicados del examen CompTIA Linux+ y la práctica estándar de administración de Linux. CompTIA y Linux+ son marcas de CompTIA, y Linux es una marca registrada de Linus Torvalds; este sitio no está afiliado ni respaldado por CompTIA. El examen real combina preguntas de opción múltiple con preguntas basadas en desempeño que piden ejecutar una tarea en un entorno simulado: eso no puede reproducirse en un formato de cuatro opciones, así que este banco cubre la mitad teórica y conviene practicar en un sistema real en paralelo. CompTIA revisa y numera las versiones de los objetivos periódicamente: confirma los objetivos, el código de examen y los requisitos vigentes con CompTIA antes de examinarte. Sobre la certificación CompTIA Linux+ →