REDES-EX2

Miles de empresas utilizan Salesforce para gestionar sus clientes y ventas. Cada empresa accede a la plataforma desde el navegador con sus credenciales, sin instalar nada ni preocuparse por servidores, actualizaciones o mantenimiento. ¿Qué modelo de despliegue y servicio es?. SaaS en nube privada. PaaS en nube pública. SaaS en nube pública. IaaS en nube pública.

El Ministerio de Defensa opera una plataforma de gestión de recursos humanos alojada en su propio centro de datos clasificado, accesible únicamente desde la red interna del ministerio. Los empleados acceden a la aplicación desde el navegador sin instalar nada. ¿Qué modelo de despliegue y servicio es?. SaaS en nube pública. IaaS en nube privada. SaaS en nube privada. PaaS en nube privada.

Una startup utiliza AWS Elastic Beanstalk para desplegar su aplicación web en Python: sube su código y AWS se encarga automáticamente del aprovisionamiento de servidores, balanceo de carga y escalado. ¿Qué modelo de despliegue y servicio es?. IaaS en nube pública. SaaS en nube pública. PaaS en nube pública. PaaS en nube privada.

La OTAN y varios gobiernos aliados comparten una plataforma cloud para desplegar y gestionar aplicaciones de inteligencia y coordinación operativa. La infraestructura es gestionada conjuntamente por los países miembros y está restringida exclusivamente a organizaciones de defensa acreditadas. Los equipos de cada país despliegan sus propias aplicaciones sin gestionar el hardware subyacente. ¿Qué modelo de despliegue y servicio es?. IaaS en nube comunitaria. PaaS en nube privada. PaaS en nube comunitaria. SaaS en nube comunitaria.

Una empresa está evaluando si sus proveedores cloud cumplen con el RGPD y con sus políticas internas de seguridad. Un consultor les recomienda usar el CCM de la CSA. ¿Por qué el CCM es útil en este contexto?. Porque el CCM certifica automáticamente a los proveedores cloud que lo implementan. Porque el CCM define los riesgos más probables a los que se enfrentan los proveedores cloud, ayudando a priorizarlos. Porque el CCM es un cuestionario que los proveedores rellenan para demostrar su cumplimiento normativo. Porque el CCM define controles de seguridad organizados en dominios, alineados con estándares como ISO 27001 o NIST, que permiten evaluar la postura de seguridad de los proveedores cloud.

Una empresa quiere auditar la seguridad de sus proveedores cloud. Para ello, su equipo de seguridad prepara un cuestionario que envía a cada proveedor para que lo rellene. Paralelamente, el equipo interno revisa qué controles técnicos debe exigir en los contratos. ¿Qué herramienta de la CSA corresponde a cada actividad respectivamente?. CAIQ para ambas actividades, ya que incluye tanto controles como preguntas de evaluación. STAR para el cuestionario y CCM para los controles, ya que STAR incluye formularios de autoevaluación. CCM para el cuestionario a proveedores, y CAIQ para definir los controles técnicos. CAIQ para el cuestionario a proveedores, y CCM para definir los controles técnicos exigibles.

El equipo de seguridad de una empresa debate qué modalidad de CASB implantar. El responsable de red argumenta que no quiere introducir latencia adicional en las conexiones. El CISO, en cambio, prioriza poder bloquear transferencias de datos sensibles en tiempo real antes de que lleguen al servicio cloud. ¿Qué modalidad satisface a cada uno respectivamente?. La solución API satisface al CISO porque al acceder directamente a las APIs del servicio cloud puede bloquear cualquier acción antes de que ocurra. La solución Proxy satisface a ambos, ya que inspecciona el tráfico en tiempo real sin añadir latencia. Ninguna solución CASB puede bloquear transferencias en tiempo real, solo detectarlas a posteriori. La solución API satisface al responsable de red por no introducir latencia, y la solución Proxy satisface al CISO por permitir bloqueo preventivo en tiempo real.

Un equipo de desarrollo despliega una aplicación cloud-native usando contenedores. El CISO quiere garantizar que la seguridad se aplica tanto durante el desarrollo del código como en tiempo de ejecución en producción. ¿Qué herramienta es la más adecuada para cubrir ambas fases?. Una solución SASE, ya que integra seguridad de red y acceso seguro en todas las fases del ciclo de vida. Un CASB en modo Proxy, ya que inspecciona el tráfico en tiempo real tanto en desarrollo como en producción. El programa STAR, ya que certifica que los controles de seguridad se aplican desde el desarrollo hasta la operación. Una plataforma CNAPP, ya que integra seguridad desde el desarrollo (shift-left) hasta la protección en tiempo de ejecución.

En la red SDN del diagrama, el canal de control entre switches y controlador no usa TLS. Un atacante ha comprometido el switch s2. ¿Qué secuencia de acciones le permitiría suplantar al controlador SDN legítimo ante el resto de switches?. Enviar paquetes TCP RST suplantando la IP del controlador hacia s1, s3 y s4 para cerrar sus sesiones OpenFlow, y acto seguido iniciar un handshake OpenFlow enviando OFPT_HELLO desde s2 suplantando al controlador. Enviar mensajes OFPT_FEATURES_REQUEST a todos los switches suplantando al controlador para obtener sus capacidades y así tomar el control de la red. Comprometer físicamente el enlace entre el controlador y s2 para interceptar los mensajes OFPT_ECHO_REQUEST y redirigirlos al resto de switches. Modificar las tablas de flujo de s2 para que todo el tráfico de datos pase por él, y a continuación enviar un OFPT_FLOW_MOD a todos los switches con acción CONTROLLER.

Durante una auditoría de seguridad en una red SDN, descubres que el canal de control entre switches y controlador usa TLS pero sin autenticación mutua. Un atacante ha conseguido acceso físico a un segmento de la red. ¿Cuál de las siguientes acciones podría llevar a cabo con éxito?. Suplantar al controlador SDN ante los switches existentes, ya que TLS sin autenticación mutua no incluye certificado de servidor y por tanto los switches no pueden verificar la identidad del controlador. Realizar un ataque de replay capturando mensajes OFPT_FLOW_MOD legítimos y reinyectándolos posteriormente, ya que TLS sin autenticación mutua no incluye mecanismos de protección contra replay a nivel de sesión. Interceptar el tráfico OpenFlow entre switch y controlador realizando un ataque de downgrade TLS hacia una versión vulnerable, aprovechando que sin autenticación mutua el handshake no valida la versión mínima aceptable. Desplegar un dispositivo que suplante a un switch legítimo ante el controlador, ya que sin certificado de cliente el controlador no puede verificar la identidad del switch que inicia la sesión OpenFlow.

En una red SDN sin mecanismos de autenticación en el canal de control, cualquier dispositivo podría intentar registrarse como switch legítimo ante el controlador. ¿Qué medida es más eficaz contra este riesgo?. Aplicar listas de control de acceso basadas en dirección IP en el controlador SDN, de forma que solo las IPs registradas previamente puedan establecer una conexión TCP en el puerto 6653. Configurar el controlador para que solo acepte conexiones desde switches que anuncien en el OFPT_HELLO soporte para OpenFlow 1.3, rechazando cualquier handshake de versiones anteriores. Usar mensajes OFPT_ECHO_REQUEST periódicos desde el controlador hacia cada switch y verificar que las respuestas OFPT_ECHO_REPLY contienen el payload original sin modificaciones. Establecer TLS con autenticación mutua mediante certificados digitales entre cada switch y el controlador, de forma que solo dispositivos con certificado válido puedan establecer sesión OpenFlow.

Un controlador SDN detecta que un host está generando tráfico sospechoso hacia un servidor crítico. El controlador decide instalar una regla en el switch más cercano al host para descartar ese tráfico de forma inmediata y con alta prioridad. ¿Qué mensaje OpenFlow debe enviar y con qué parámetros clave?. Enviar un OFPT_PACKET_OUT al switch con acción DROP, especificando la IP de origen del host en el campo buffer_id para que el switch descarte los paquetes en cola. Enviar un OFPT_MULTIPART_REQUEST al switch con acción DROP a todos los paquetes entrantes del switch. Enviar un OFPT_FLOW_MOD al switch con comando OFPFC_ADD, match en ip_src del host, prioridad alta y acción DROP, para que el switch descarte inmediatamente el tráfico sospechoso. Enviar un OFPT_BARRIER_REQUEST al switch para pausar el procesamiento de flujos existentes, seguido de un OFPT_ECHO_REQUEST para verificar que el switch está listo para recibir la nueva regla.

Durante el diseño de una aplicación SDN, un desarrollador necesita implementar la lógica de reenvío de un paquete que ha llegado al controlador vía OFPT_PACKET_IN y cuyo destino ya ha sido calculado. ¿Qué mensaje debe enviar el controlador al switch y qué información debe incluir?. Enviar un OFPT_FEATURES_REQUEST al switch para verificar que el puerto de salida calculado está activo antes de ordenar el reenvío del paquete. Enviar un OFPT_FLOW_MOD con comando OFPFC_ADD y acción OUTPUT al puerto calculado, sin incluir el buffer_id, ya que el paquete original ya está almacenado en el switch y será reenviado automáticamente. Enviar un OFPT_PACKET_OUT al switch incluyendo el buffer_id del paquete original y la acción OUTPUT con el puerto de salida calculado, para que el switch reenvíe ese paquete concreto por el puerto indicado. Enviar un OFPT_PACKET_IN de vuelta al switch con el puerto de salida calculado, ya que este mensaje es simétrico y puede ser usado tanto por el controlador como por el switch.

Un ingeniero de redes está depurando por qué un switch OpenFlow no aparece en el controlador SDN tras arrancar. Revisando los logs, observa que el switch nunca llega a enviar un OFPT_HELLO. ¿Cuál es la causa más probable?. El controlador no ha enviado el OFPT_HELLO inicial, ya que en OpenFlow siempre es el controlador quien inicia el intercambio de versiones. El switch no ha recibido un OFPT_FEATURES_REQUEST del controlador, que es el mensaje que inicia el handshake OpenFlow. El switch está esperando un OFPT_ECHO_REQUEST del controlador para confirmar la conectividad antes de iniciar el handshake OpenFlow. La sesión TCP entre el switch y el controlador no se ha establecido correctamente, ya que OpenFlow requiere una conexión TCP activa en el puerto 6653 antes de intercambiar cualquier mensaje OpenFlow.

Un estudiante está analizando una captura de tráfico OpenFlow entre un controlador y un switch. Identifica un mensaje enviado por el switch al controlador sin que el controlador haya enviado ningún mensaje previo. ¿Cuál de los siguientes mensajes OpenFlow podría ser?. OFPT_PACKET_OUT, ya que el switch lo envía al controlador cuando recibe un paquete que no coincide con ningún flujo instalado en su tabla. OFPT_FEATURES_REPLY, ya que el switch lo envía espontáneamente al arrancar para anunciarse al controlador sin esperar ningún mensaje previo. OFPT_FLOW_MOD, ya que el switch lo envía al controlador para notificarle que ha modificado su tabla de flujos de forma autónoma. OFPT_PACKET_IN, ya que el switch lo envía al controlador de forma asíncrona cuando recibe un paquete que no coincide con ninguna regla de su tabla de flujos.

Un operador de red necesita conocer el número de paquetes que ha procesado cada flujo instalado en un switch OpenFlow para detectar posibles anomalías de tráfico. ¿Qué secuencia de mensajes OpenFlow debe producirse?. El controlador envía un OFPT_BARRIER_REQUEST al switch para forzar la sincronización del estado, y el switch responde con un OFPT_BARRIER_REPLY incluyendo el estado actual de la tabla de flujos. El controlador envía un OFPT_ECHO_REQUEST al switch con el identificador del flujo, y el switch responde con un OFPT_ECHO_REPLY incluyendo los contadores de paquetes y bytes. El controlador envía un OFPT_MULTIPART_REQUEST con tipo OFPMP_FLOW al switch, y este responde con un OFPT_MULTIPART_REPLY incluyendo las estadísticas de cada flujo instalado. El controlador envía un OFPT_FLOW_MOD con flag OFPFF_SEND_FLOW_REM al switch, que responde con un OFPT_FLOW_REMOVED incluyendo las estadísticas del flujo.

En una red SDN, un administrador detecta que cierto tráfico desaparece silenciosamente sin ninguna alerta en el controlador. Tras analizar los flujos, confirma un ataque "black-hole". ¿Cuál es la causa más probable?. El controlador ha perdido conectividad con todos los switches simultáneamente por un fallo en el canal de control. Una aplicación Northbound está instalando flujos con prioridad 0 que no coinciden con ningún paquete. Un switch comprometido tiene instalada una regla que descarta silenciosamente el tráfico hacia ciertos destinos sin notificar al controlador. Un atacante está enviando mensajes OFPT_HELLO falsos para reiniciar sesiones OpenFlow entre switches y controlador.

El controlador SDN ha detectado que el host h8 ha iniciado una reverse shell conectándose al puerto TCP 8888 de h3. Usando el diagrama de la red, ¿qué acción debería tomar el controlador para bloquear la conexión en el origen? (h8 cuelga de s4, puerto p7). Enviar un OFPT_FLOW_MOD a s2 con match en ip_dst=h3, tcp_dst=8888, egress port s2:p6 y acción DROP. Enviar un OFPT_FLOW_MOD a s3 con match en ip_src=h8, tcp_dst=8888, ingress port s3:p4 y acción CONTROLLER. Enviar un OFPT_FLOW_MOD a s4 con match en ip_src=h8, tcp_dst=8888, ingress port s4:p7 y acción DROP. Enviar un OFPT_PACKET_OUT a s4 indicando que reenvíe el tráfico de h8 al controlador para su inspección.

El diagrama de arriba representa la arquitectura de redes NFV. Indique el nombre de los componentes marcados por las letras (A, B, C, D, E, F, G). Solución de referencia (ETSI NFV-MANO):

¿Cuál de las siguientes afirmaciones sobre las credenciales de una ServiceAccount en Kubernetes es correcta?. Las credenciales de una ServiceAccount se generan una única vez al crear el clúster y no pueden renovarse. Las credenciales de una ServiceAccount son un token JWT que Kubernetes monta automáticamente dentro del contenedor en /var/run/secrets/kubernetes.io/serviceaccount/token. Las credenciales de una ServiceAccount son un certificado X.509 firmado por la CA del clúster. Una ServiceAccount no tiene credenciales propias, usa las del usuario que desplegó el pod.

¿Cuál es el riesgo de seguridad de ejecutar un contenedor en Kubernetes con privileged: true en su securityContext?. El contenedor tiene acceso completo al kernel del nodo, equivalente a ejecutarse como root en el propio nodo, lo que compromete toda la seguridad del host. El contenedor tiene acceso completo al kernel del nodo y además no puede correr como usuario no root. El contenedor hereda automáticamente la ServiceAccount del nodo en lugar de la del pod. El contenedor puede leer los Secret de cualquier namespace sin necesidad de RBAC.

¿Cómo se almacenan los valores en el campo data de un Secret de tipo Opaque en Kubernetes?. En texto plano, ya que base64 solo se aplica si se activa manualmente en el API Server. Cifrados mediante el certificado TLS del API Server antes de persistirse en etcd. Cifrados con AES-256 de forma automática sin necesidad de configuración adicional. Codificados en base64.

¿Qué ocurre si la variable de entorno KUBECONFIG no está definida y el fichero ~/.kube/config no existe cuando se ejecuta kubectl?. kubectl intenta conectarse al API Server en localhost:8080 con las credenciales del usuario root del sistema. kubectl solicita usuario y contraseña de forma interactiva por consola. kubectl usa automáticamente el token de la ServiceAccount del pod en ejecución. kubectl no puede autenticarse y devuelve un error indicando que no encuentra configuración válida.

En el modelo RBAC de Kubernetes, ¿qué diferencia hay entre usar un RoleBinding y un ClusterRoleBinding para vincular un ClusterRole a una ServiceAccount?. Un RoleBinding limita los permisos del ClusterRole al namespace donde se crea el RoleBinding, mientras que un ClusterRoleBinding los otorga a nivel de todo el clúster. Un RoleBinding solo puede vincularse a un Role local, nunca a un ClusterRole. Un ClusterRoleBinding restringe los permisos del ClusterRole al namespace donde se define el binding. No hay diferencia, ambos otorgan los mismos permisos independientemente del scope.

Un desarrollador quiere crear un Role en Kubernetes que permita a una ServiceAccount únicamente listar y ver pods. ¿Cuál de las siguientes definiciones es correcta?. resources: [pods], verbs: [read, view]. resources: [pods], verbs: [create, delete]. resources: [pods], verbs: [get, list, watch]. resources: [pods], verbs: [exec, logs].

¿Cuál es la principal diferencia de seguridad entre un Secret y un ConfigMap en Kubernetes?. Los Secret requieren siempre un Role explícito para ser accedidos por un pod, los ConfigMap no. Los Secret están cifrados por defecto en SHA256 en sus ficheros de montaje, mientras que los ConfigMap no. Los ConfigMap almacenan sus valores en texto plano mientras que los Secret de tipo Opaque codifican sus valores en base64 en el campo data. Los ConfigMap no pueden montarse como volúmenes por razones de seguridad, a diferencia de los Secret.

¿Qué implica establecer runAsNonRoot: true en el securityContext de un pod en Kubernetes?. Kubernetes rechaza arrancar el contenedor si la imagen está configurada para ejecutarse como root (UID 0). Kubernetes automáticamente cambia el usuario del contenedor a nobody (UID 65534) si la imagen usa root. El contenedor corre como usuario no root pero sin ninguna capability kernel habilitada. El contenedor no puede montar volúmenes persistentes ya que requieren permisos de root.

¿Cuál es la diferencia entre eliminar un contenedor y eliminar una imagen en Docker?. No hay diferencia: en Docker, contenedor e imagen son el mismo objeto en distintos estados de ejecución. Eliminar un contenedor borra su instancia y sistema de ficheros, y también elimina la imagen base de la que fue creado si no hay otros contenedores activos que la estén utilizando. Eliminar un contenedor borra su instancia y sistema de ficheros en ejecución, pero la imagen permanece. Eliminar una imagen borra la plantilla, pero falla si hay contenedores que la usan. Eliminar una imagen borra también todos los contenedores que la estén usando, estén o no en ejecución, pero conserva los volúmenes asociados.

¿Qué comando lanza un contenedor con la capability necesaria para configurar interfaces de red del host (añadir rutas, cambiar IPs) desde dentro del contenedor?. docker run --rm -it --cap-add NET_RAW ubuntu bash. docker run --rm --net host --cap-add NET_RAW -it ubuntu bash. docker run --rm --net host --cap-add NET_ADMIN -it ubuntu bash. docker run --rm --privileged --net none -it ubuntu bash.

¿Cuál de las siguientes afirmaciones es correcta sobre el componente dockerd dentro del stack de Docker?. dockerd es el binario que ejecuta directamente los contenedores aplicando namespaces y cgroups en el kernel sin ningún intermediario. dockerd es un demonio que expone una API REST/gRPC, gestiona imágenes, redes y volúmenes, y ejecuta directamente los contenedores aplicando namespaces y cgroups sin depender de containerd. dockerd se comunica directamente con runc mediante comandos de shell para lanzar cada contenedor de forma independiente. dockerd es un demonio que expone una API REST/gRPC, gestiona imágenes, redes y volúmenes, y delega la ejecución de contenedores a containerd.

¿Cuál de las siguientes afirmaciones describe correctamente el papel de containerd dentro de la arquitectura de Docker?. containerd es el componente que interpreta los comandos del usuario (docker CLI) y los traduce a llamadas al kernel directamente sin intermediarios. containerd es un demonio que gestiona el ciclo de vida de los contenedores (descarga de imágenes, creación, ejecución) y delega en runc la ejecución a nivel de kernel. containerd es un demonio que gestiona el ciclo de vida de los contenedores y los ejecuta directamente en el kernel mediante namespaces y cgroups, sin necesidad de un proceso intermediario como runc. containerd gestiona la red y el almacenamiento de las imágenes Docker, pero delega en dockerd el ciclo de vida de los contenedores.

¿Cuál de las siguientes afirmaciones es verdadera sobre la comunicación entre el cliente docker CLI y el demonio dockerd?. Por defecto el cliente docker CLI se comunica con el docker daemon a través de un socket local de Unix sin autenticación. Por defecto el cliente docker CLI no se comunica directamente con dockerd, sino que envía los comandos a containerd, que expone el socket Unix al cliente. Por defecto el cliente docker CLI se comunica con el docker daemon a través de un socket local de Unix, requiriendo autenticación mediante certificado X.509 almacenado en ~/.docker/. Por defecto el cliente docker CLI se comunica con dockerd mediante gRPC a través del socket Unix, del mismo modo que dockerd se comunica internamente con containerd.

Dado el siguiente Dockerfile: FROM alpine / ENTRYPOINT ["cat"] / CMD ["/etc/hostname"], construido con docker build -t my_cat .. ¿Qué ocurrirá al ejecutar docker run my_cat /etc/passwd?. Se ejecutará cat /etc/hostname ignorando el argumento /etc/passwd, porque CMD tiene precedencia sobre los argumentos pasados en docker run. Se ejecutará cat /etc/passwd. El argumento pasado a docker run sobreescribe el CMD, pero el ENTRYPOINT cat se mantiene. El contenedor fallará porque al proporcionar un argumento en docker run que no coincide con el CMD definido, Docker lanza un error de configuración. Se ejecutará /etc/passwd como comando independiente, ignorando el ENTRYPOINT, porque los argumentos de docker run sobreescriben tanto CMD como ENTRYPOINT.

¿Qué tipo de namespace de Linux se utiliza para aislar el nombre de host (hostname) de un contenedor respecto al sistema anfitrión y al resto de contenedores?. El namespace IPC aísla el hostname de cada contenedor, impidiendo que los procesos de distintos contenedores compartan el mismo nombre de host. El namespace NET se encarga de aislar el hostname, haciendo que cada contenedor tenga una identidad de red diferente. El namespace UTS (Unix Time-sharing System) permite que cada contenedor tenga su propio hostname y domainname. El namespace PID permite aislar el nombre de host de cada contenedor del resto del sistema.

¿Cuál de las siguientes afirmaciones sobre el ciclo de vida de los contenedores Docker es correcta?. Un contenedor detenido conserva su sistema de ficheros y configuración, y puede listarse e iniciarse de nuevo hasta que se elimine explícitamente. Docker elimina automáticamente los contenedores detenidos pasadas 24 horas para liberar espacio en disco. Cuando un contenedor termina su proceso principal pasa a estado "pausado" y conserva sus recursos hasta ser reiniciado. Un contenedor eliminado con docker rm puede recuperarse con docker start si la imagen original sigue disponible.

¿Cuál es la diferencia principal entre docker stop y docker rm?. docker stop detiene el contenedor y elimina su sistema de ficheros; docker rm elimina el contenedor pero conserva sus volúmenes y su sistema de ficheros para poder reiniciarlo. docker stop detiene el proceso principal del contenedor pero lo conserva en el sistema; docker rm elimina el contenedor y su sistema de ficheros permanentemente. docker stop elimina el contenedor del sistema; docker rm solo detiene su proceso principal temporalmente. docker stop y docker rm son equivalentes: ambos detienen el contenedor y lo eliminan del sistema.

Un contenedor con nginx ya está en ejecución. Necesitas abrir una shell interactiva dentro de él para revisar sus ficheros de configuración sin detenerlo. ¿Qué comando usarías?. docker start, porque reactiva el contenedor en modo interactivo. docker run, porque permite iniciar un proceso interactivo dentro de una imagen. docker attach, porque conecta el terminal al proceso principal de nginx para ver su configuración. docker exec, porque permite lanzar un proceso adicional dentro de un contenedor ya en ejecución.

Dado el comando docker run -v /etc:/host-etc -it ubuntu bash, ¿qué riesgo de seguridad implica ejecutarlo tal como está, en comparación con añadir :ro al final del volumen?. El contenedor podría leer ficheros sensibles del directorio montado, algo que no ocurriría añadiendo :ro. Ninguno, porque el contenedor tiene su propio namespace de ficheros y los cambios en /host-etc no afectan al directorio original del host. Sin :ro el montaje es de lectura-escritura, por lo que el proceso del contenedor podría modificar ficheros críticos del host como /etc/passwd o /etc/sudoers, comprometiendo su seguridad. El riesgo es el mismo con o sin :ro porque Docker aplica SELinux automáticamente sobre cualquier directorio montado desde el host.

¿Cuál es la diferencia de seguridad entre dar acceso a un contenedor a un dispositivo concreto del host frente a ejecutarlo en modo privilegiado?. Dar acceso a un dispositivo concreto limita la exposición a ese recurso específico; el modo privilegiado elimina prácticamente todas las restricciones de seguridad del contenedor, dándole acceso a todos los dispositivos y capacidades del host. No hay diferencia: cualquier contenedor con acceso a un dispositivo del host tiene implícitamente acceso a todos los dispositivos. Dar acceso a un dispositivo concreto requiere siempre combinar --device con --privileged para que Docker aplique los permisos correctamente. El modo privilegiado es más seguro porque Docker aplica políticas de AppArmor adicionales sobre los dispositivos accesibles.

¿Por qué es una buena práctica de seguridad ejecutar los procesos dentro de un contenedor con un usuario sin privilegios en lugar de como root?. Porque Docker no permite ejecutar contenedores como root salvo que se use --privileged, por lo que es obligatorio usar otro usuario. Si el proceso es comprometido, un atacante operaría con privilegios limitados dentro del contenedor, reduciendo el impacto de un escape o de accesos no autorizados al host. Porque los namespaces de usuario de Linux impiden completamente que un proceso root dentro del contenedor tenga cualquier efecto sobre el host. Ese UID=0 no es el mismo que el del host a nivel de kernel, es un root "diferente", y por tanto si el proceso escapa del contenedor no tendría privilegios de root en el host.

Desde el punto de vista del aislamiento del kernel, ¿cuál de las siguientes afirmaciones es verdadera al comparar contenedores Docker con máquinas virtuales?. Una máquina virtual brinda mayor aislamiento que un contenedor porque el hipervisor cifra todas las comunicaciones entre el sistema operativo invitado y el hardware del host. El aislamiento por namespaces de un contenedor equivale al aislamiento hardware de una máquina virtual, por lo que tienen el mismo nivel de seguridad. Los contenedores Docker son más seguros porque usan un kernel propio independiente del host que impide el escape al sistema anfitrión. Una máquina virtual brinda mayor aislamiento al interactuar con el hardware solo a través del hipervisor, mientras que un contenedor comparte el kernel del host.

(Puede haber más de una correcta) ¿Cuáles de las siguientes afirmaciones sobre las tecnologías del kernel utilizadas para aislar los contenedores son CORRECTAS?. Cada proceso asociado a un namespace sólo puede ver o usar los recursos asociados a ese namespace. Docker utiliza cgroups para limitar el uso de CPU, memoria y red por parte de los contenedores. Cuando se ejecuta un contenedor, Docker crea un cgroup y asocia el proceso del contenedor a dicho cgroup mediante su PID. Los cgroups permiten aislar el espacio de nombres de red de un contenedor, de modo que cada contenedor tenga su propia interfaz de red virtual. Los namespaces permiten limitar el consumo de CPU y memoria de cada proceso al que están asociados.

Un contenedor de base de datos necesita que sus datos persistan aunque el contenedor se elimine y se vuelva a crear. ¿Qué mecanismo de Docker usarías y por qué?. Las variables de entorno, porque permiten pasar rutas de directorios al contenedor para que sepa dónde guardar los datos. La red host, porque permite al contenedor acceder directamente al sistema de ficheros del host sin restricciones. El modo privilegiado, porque da al contenedor acceso completo al sistema de ficheros del host para escribir sus datos. Un volumen o bind mount, que monta un directorio del host dentro del contenedor de forma que los datos escritos persisten independientemente del ciclo de vida del contenedor.

(Rellenar Dockerfile Nginx) Requisitos: imagen base Debian; variables de entorno de usuario, grupo (mismo para ambos) y directorio de logs (NGINX_LOG_DIR); instalar Nginx y limpiar paquetes; copiar default.conf y entrypoint.sh; exponer puerto 80; dar permisos de ejecución al script; Nginx como proceso principal y entrypoint.sh como argumento por defecto.

(Rellenar Dockerfile PostgreSQL) Requisitos: ejecutar PostgreSQL como proceso principal; init.sh inicializa la BD; la BD escucha en el puerto 5432; basado en ubuntu:22.04.

En la práctica 6, ¿qué comando debes usar desde el host para copiar el fichero de topología personalizada custom_topology.py al contenedor Mininet?. sudo docker cp custom_topology.py mininet-c:/root/custom_topology.py. docker exec mininet-c cp custom_topology.py /root/custom_topology.py. docker mv custom_topology.py mininet-c:/root/custom_topology.py. sudo docker exec -it mininet-c scp custom_topology.py /root/custom_topology.py.

En la práctica 6, tras lanzar Mininet con una topología personalizada, ¿qué comando debes ejecutar en la consola de Mininet para verificar que ningún host puede comunicarse con otro cuando la aplicación Reactive Forwarding está desactivada?. pingall. h1 ping h2. net. links.

En la práctica 6, tras configurar correctamente TLS en el canal southbound entre ONOS y el switch OVS, capturas el tráfico del puerto 6653 con Wireshark. ¿Qué deberías observar en la captura respecto a antes de configurar TLS?. No hay ninguna diferencia visible en Wireshark ya que TLS opera a nivel de aplicación y Wireshark solo captura hasta la capa de transporte. Los mensajes OpenFlow que antes eran visibles en claro ahora aparecen cifrados, siendo imposible distinguir el tipo de mensaje o su contenido en la captura. Los mensajes OpenFlow siguen siendo visibles en claro pero ahora aparece un handshake TLS previo a la conexión que no afecta al contenido de los mensajes. Wireshark deja de capturar tráfico en el puerto 6653 porque TLS cambia dinámicamente el puerto de comunicación.

En la práctica 6, ¿a qué puerto debes conectarte por SSH para acceder a la CLI de ONOS en el contenedor onos-c?. ssh -p 830 onos@localhost. ssh -p 6653 onos@localhost. ssh -p 8101 onos@localhost. ssh -p 8181 onos@localhost.

El comando cfg set tlsMode enabled ejecutado en la CLI de Karaf no persiste tras reiniciar el contenedor ONOS. ¿Cuál es la causa principal y el mecanismo más adecuado para solucionarlo?. El comando cfg set sí persiste siempre entre reinicios; si se pierde es porque Docker destruye el sistema de ficheros del contenedor al pararlo, y la solución es usar docker commit antes de cada parada. La causa es que ONOS cifra su base de datos de configuración con la contraseña del keystore, y al cambiar el JKS en cada arranque los valores quedan inaccesibles; la solución es regenerar el JKS con la misma contraseña. La configuración aplicada con cfg set se almacena en memoria volátil del proceso Karaf; para que persista habría que incluir las propiedades TLS directamente en el fichero de arranque onos-service mediante parámetros -D de la JVM. La CLI de Karaf solo guarda cambios de configuración cuando se ejecuta el comando cfg save a continuación; sin ese paso, ningún parámetro queda registrado en disco.

Si se añadiera un segundo switch OVS (s2) al escenario, ¿qué afirmación describe correctamente los pasos necesarios para que también se conecte a ONOS por TLS?. Sería necesario importar el certificado de s2 en el onos.jks de ONOS (para que el controlador confíe en él) y configurar set-ssl en s2 apuntando a sus propios ficheros de clave y certificado. El segundo switch debe usar obligatoriamente un certificado firmado por una CA externa reconocida; los certificados autofirmados solo son válidos para el primer switch registrado en el keystore de ONOS. Habría que generar un nuevo onos.jks por cada switch añadido y reiniciar el contenedor ONOS cada vez, ya que un único JKS solo puede almacenar la identidad de un switch externo. No es necesario ningún cambio adicional; una vez que ONOS tiene TLS activado, acepta automáticamente la conexión de cualquier switch OVS que use el puerto 6653, sin importar si presenta certificado o no.

En la práctica se usa el mismo fichero onos.jks como keystore y como truststore para ONOS. ¿Cuál de las siguientes afirmaciones describe correctamente una limitación o riesgo de este enfoque?. En un entorno de laboratorio con un único switch, usar ficheros separados es obligatorio, ya que Karaf no admite que keystore y truststore apunten al mismo fichero JKS. Usar el mismo fichero como keystore y truststore implica que cualquier certificado importado como "de confianza" queda almacenado junto a la clave privada de ONOS, lo que reduce el aislamiento. La principal desventaja es que el algoritmo RSA no puede coexistir con certificados de terceros en un JKS, por lo que ONOS lanzaría una excepción al arrancar. No existe ninguna diferencia funcional ni de seguridad entre usar un único fichero o dos ficheros separados; la separación es únicamente una convención de nomenclatura.

En la práctica 6, tienes un intent configurado entre h1 y h3 que enruta el tráfico a través del switch s5. Desactivas el enlace entre s1 y s5 desde la consola de Mininet. ¿Qué ocurre con la conectividad entre h1 y h3?. El controlador ONOS detecta la caída del enlace, recalcula la ruta y actualiza las tablas de flujo de los switches afectados para mantener la conectividad por un camino alternativo. Los switches s1 y s5 detectan automáticamente la caída del enlace y recalculan sus tablas de flujo de forma autónoma sin intervención del controlador. La conectividad se pierde permanentemente porque el intent queda invalidado al caer el enlace principal y es necesario crear uno nuevo. La conectividad se pierde temporalmente hasta que el administrador ejecuta de nuevo el comando wipe-out please en ONOS y reconfigura el intent.

En la práctica 6, tras activar Reactive Forwarding en ONOS y comprobar que el ping entre h1 y h2 funciona, desactivas la aplicación. ¿Qué ocurre con las tablas de flujo del switch y con el ping?. El controlador envía un OFPT_FLOW_MOD con comando OFPFC_DELETE a todos los switches para eliminar las reglas instaladas por Reactive Forwarding, cortando el ping de forma inmediata. El switch elimina inmediatamente todas sus reglas de flujo al detectar que el controlador ha desactivado Reactive Forwarding, provocando la caída instantánea del ping. Las reglas instaladas por Reactive Forwarding expiran por timeout y el ping deja de funcionar, ya que sin la aplicación activa el controlador no vuelve a instalar nuevas reglas cuando el switch eleva los paquetes vía OFPT_PACKET_IN. Las tablas de flujo del switch se mantienen intactas indefinidamente y el ping sigue funcionando porque las reglas ya están instaladas en el switch y no dependen del controlador.

En la práctica 6, estás usando la API REST de ONOS para implementar un firewall L2 que bloquee el tráfico entre h1 y h3. ¿Qué método HTTP y endpoint debes usar para crear una nueva regla ACL?. GET a /onos/v1/acl/rules para consultar las reglas existentes, y a continuación MODIFY a /onos/v1/acl/rules para modificar la que afecta a h1 y h3. PUT a /onos/v1/acl/rules con un body JSON indicando las IPs de h1 y h3 y el campo isPermit: false. POST a /onos/v1/acl/rules con un body JSON indicando las IPs de h1 y h3 y el campo isPermit: false. DELETE a /onos/v1/acl/rules para eliminar las reglas que permiten el tráfico entre h1 y h3.