Cuestión 1 — Usuarios, grupos y permisos con sticky bit

Objetivo: el grupo alumnos puede crear y leer archivos en /srv/taller/entregas, pero solo el propietario de cada archivo puede borrarlo. Esto se consigue con permiso de escritura para el grupo en el directorio más el sticky bit, que restringe el borrado al propietario del fichero (o del directorio, o root).

# 1. Crear el grupo alumnos
sudo groupadd alumnos

# 2. Crear el directorio (toda la ruta) y asignar propietario:grupo
sudo mkdir -p /srv/taller/entregas
sudo chown profesor:alumnos /srv/taller/entregas

# 3. Fijar permisos: rwx propietario, rws grupo (setgid), sticky bit
#    2 = setgid, 1 = sticky  ->  modo 3770
sudo chmod 3770 /srv/taller/entregas

# Equivalente simbólico:
sudo chmod u=rwx,g=rwx,o=,g+s,+t /srv/taller/entregas

Resultado de ls -ld /srv/taller/entregas:

drwxrws--T 2 profesor alumnos 4096 ... /srv/taller/entregas

Figura 1. Anatomía de los permisos drwxrws--T: los diez caracteres desglosados en tipo, propietario, grupo (setgid) y otros (sticky).

Interpretación de la terna drwxrws--T:

• d → es un directorio.
• rwx (propietario profesor) → el profesor puede leer el contenido, modificarlo (crear/borrar) y entrar (x).
• rws (grupo alumnos) → el grupo puede leer (r), escribir/crear (w) y entrar (x); la s indica el setgid activo: todo archivo nuevo creado dentro heredará el grupo alumnos (que las entregas pertenezcan al grupo común, no al grupo primario del alumno). Como hay x debajo, aparece s minúscula.
• --T (otros) → los demás usuarios no tienen ningún permiso (---); la T mayúscula es el sticky bit activo sin permiso de ejecución para «otros» (si lo tuvieran sería t minúscula). El sticky bit es lo que garantiza que un alumno solo pueda borrar o renombrar sus propios archivos, aunque tenga permiso w sobre el directorio.

Convención de las letras especiales: minúscula (s/t) = bit especial activo y además permiso de ejecución; mayúscula (S/T) = bit especial activo sin permiso de ejecución debajo.

Para que el setgid actúe también sobre los permisos heredados conviene fijar el umask o usar ACL por defecto:

# Opción con ACL por defecto: archivos nuevos legibles/escribibles por el grupo
sudo setfacl -d -m g:alumnos:rw /srv/taller/entregas

Cuestión 2 — Cortafuegos con iptables

Guion iptables ordenado (las reglas se evalúan de arriba abajo; las políticas restrictivas se aplican al final una vez añadidas las excepciones):

#!/bin/bash
# ------- Limpieza inicial -------
iptables -F                # vacía todas las reglas
iptables -X                # borra cadenas de usuario

# ------- Políticas por defecto -------
iptables -P INPUT DROP     # todo lo que entra se descarta salvo excepción
iptables -P FORWARD DROP   # no enrutamos
iptables -P OUTPUT ACCEPT  # permitimos la salida (respuestas del servidor)

# ------- 1) Tráfico de loopback (servicios locales) -------
iptables -A INPUT -i lo -j ACCEPT

# ------- 2) Conexiones ya establecidas / relacionadas -------
# Permite las respuestas a conexiones que el servidor inició o aceptó
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# ------- 3) SSH (22) solo desde la subred de administración -------
iptables -A INPUT -p tcp -s 172.16.0.160/28 --dport 22 -j ACCEPT

# ------- 4) HTTP (80) y HTTPS (443) desde cualquier origen -------
iptables -A INPUT -p tcp --dport 80  -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# (opcional) registrar lo descartado antes del DROP por defecto
iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROP: " --log-level 4

Figura 2. Orden de evaluación de la cadena INPUT: excepciones ACCEPT primero y política DROP al final.

Comentario por bloques:

• Limpieza (-F, -X): se parte de un estado limpio para evitar reglas residuales de arranques anteriores.
• Políticas por defecto: INPUT DROP materializa el principio de lista blanca (denegar todo y permitir solo lo necesario). OUTPUT ACCEPT deja salir las respuestas del servidor.
• Loopback (-i lo): imprescindible; muchos servicios (Apache↔BD, sockets internos) hablan por 127.0.0.1. Sin esta regla, con política DROP, se romperían.
• ESTABLISHED,RELATED (módulo conntrack): permite los paquetes de conexiones ya válidas. Sin ella, aunque admitiéramos el SYN inicial, las respuestas posteriores se bloquearían.
• SSH restringido (-s 172.16.0.160/28): la /28 da 2^{32-28} = 16 direcciones (172.16.0.160–172.16.0.175); solo desde esa subred de administración se acepta el puerto 22, reduciendo la superficie de ataque al servicio de gestión.
• HTTP/HTTPS: la intranet (Apache) debe ser accesible por todo el centro, así que 80 y 443 se abren sin restricción de origen.
• LOG: opcional, registra en el syslog lo que cae al DROP por defecto, útil para diagnóstico.

Persistencia (Debian/Ubuntu/Lliurex):

sudo apt install iptables-persistent
sudo netfilter-persistent save     # guarda en /etc/iptables/rules.v4

Cuestión 3 — Acceso remoto seguro por par de claves SSH

Paso 1 — Generar el par de claves en el equipo del administrador (cliente):

ssh-keygen -t ed25519 -a 100 -C "admin@taller.local"
# (alternativa clásica: ssh-keygen -t rsa -b 4096)

Genera ~/.ssh/id_ed25519 (clave privada, nunca se comparte) y ~/.ssh/id_ed25519.pub (clave pública). Conviene proteger la privada con passphrase.

Paso 2 — Copiar la clave pública al servidor:

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@172.16.0.161

Esto añade la clave pública al fichero ~/.ssh/authorized_keys del usuario admin en el servidor, con los permisos correctos (700 en ~/.ssh, 600 en authorized_keys). Manualmente sería:

ssh admin@172.16.0.161 "mkdir -p ~/.ssh && chmod 700 ~/.ssh"
cat ~/.ssh/id_ed25519.pub | ssh admin@172.16.0.161 "cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Paso 3 — Verificar que la clave funciona ANTES de endurecer (crítico para no quedarse fuera):

ssh admin@172.16.0.161   # debe entrar sin pedir la contraseña del sistema

Paso 4 — Endurecer /etc/ssh/sshd_config en el servidor:

# Solo autenticación por clave pública
PubkeyAuthentication yes

# Prohibir login directo de root
PermitRootLogin no

# Deshabilitar autenticación por contraseña (y métodos relacionados)
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

# Endurecimiento adicional recomendado
Protocol 2
MaxAuthTries 3
AllowUsers admin

Paso 5 — Comprobar la sintaxis y recargar el servicio:

sudo sshd -t                          # valida sshd_config (sin errores = OK)
sudo systemctl reload ssh             # (o 'sshd' según distro)

Recomendación: mantén una sesión SSH abierta mientras compruebas, por si hay que revertir. Con PermitRootLogin no y PasswordAuthentication no se elimina el ataque por fuerza bruta de contraseñas y el acceso directo a root.

Figura 3. Acceso SSH sin contraseña por par de claves: el cliente genera el par, ssh-copy-id sube la pública y el handshake firma con la privada.

Cuestión 4 — Zona directa DNS para taller.local

Fichero de zona BIND (/etc/bind/db.taller.local):

$TTL    86400
$ORIGIN taller.local.

; ----- Registro SOA -----
@       IN      SOA     ns1.taller.local. admin.taller.local. (
                        2026062101      ; Serial (AAAAMMDDnn)
                        3600            ; Refresh  (1 h)
                        1800            ; Retry    (30 min)
                        1209600         ; Expire   (2 semanas)
                        86400 )         ; Negative TTL / Minimum (1 día)

; ----- Servidores de nombres (NS) -----
@       IN      NS      ns1.taller.local.
@       IN      NS      ns2.taller.local.

; ----- Registros A (IPv4) -----
servidor IN     A       172.16.0.161
ns1      IN     A       172.16.0.161
ns2      IN     A       172.16.0.162

; ----- Registro AAAA (IPv6) -----
servidor IN     AAAA    2001:db8::161

; ----- Registro MX (correo) -----
@       IN      MX      10      servidor.taller.local.

; ----- Alias CNAME -----
intranet IN     CNAME   servidor.taller.local.

Justificación de cada elemento:

• $TTL 86400: tiempo de vida por defecto de los registros (1 día) para las cachés resolutoras.
• SOA: declara el servidor maestro (ns1), el correo del responsable (admin.taller.local., donde la primera . sustituye a la @) y los temporizadores. El Serial debe incrementarse en cada cambio (formato fecha 2026062101) para que los esclavos detecten la actualización.
• Dos NS: ns1 y ns2, redundancia del servicio de nombres.
• A: mapea el nombre servidor a la IPv4 172.16.0.161 (IP de servidores del diseño de red).
• AAAA: mapea el mismo host a su dirección IPv6.
• MX 10: indica el servidor de correo de la zona, con prioridad 10 (menor número = mayor preferencia).
• CNAME intranet: alias que apunta a servidor.taller.local.; así http://intranet.taller.local resuelve al servidor Apache. Importante: un nombre con CNAME no puede tener otros registros (regla DNS).

Detalle clave: los FQDN terminan en punto (.) para indicar nombre absoluto; sin él, BIND añade el $ORIGIN.

Cuestión 5 — Diagnóstico: «la intranet no carga» pero el ping responde

El ping correcto indica que la capa de red (L3) y el host funcionan; el problema está en una capa superior (servicio, puerto, cortafuegos o resolución de nombres). Diagnóstico por capas:

(a) ¿Apache está activo y en qué puerto escucha?

# Estado del servicio
sudo systemctl status apache2
#   Esperado: "active (running)". Si aparece "inactive/failed",
#   arrancarlo:  sudo systemctl start apache2  (y 'enable' para el arranque)

# Puertos en escucha (ss, moderno)
sudo ss -tlnp | grep -E ':80|:443'
#   Esperado:  LISTEN 0  511  *:80   ...  users:(("apache2",...))
#              LISTEN 0  511  *:443  ...

# Alternativa con netstat
sudo netstat -tlnp | grep apache2

# Qué proceso tiene abierto el puerto 80
sudo lsof -i :80
#   Esperado: procesos 'apache2' en estado LISTEN

Si Apache no escucha en 80/443, revisar /etc/apache2/ports.conf y los VirtualHost, y los logs:

sudo journalctl -u apache2 --since "10 min ago"
sudo tail -n 50 /var/log/apache2/error.log
sudo apache2ctl configtest          # valida la configuración (Syntax OK)

(b) ¿El cortafuegos bloquea el puerto?

# Listar reglas con números y sin resolver nombres
sudo iptables -L INPUT -n -v --line-numbers
#   Esperado: reglas ACCEPT para tcp dpt:80 y dpt:443 ANTES del DROP

# Prueba de conectividad al puerto desde un cliente del aula
nc -zv 172.16.0.161 80
#   Esperado: "Connection to 172.16.0.161 80 port [tcp/http] succeeded!"

Tras un reinicio, un fallo típico es que las reglas no se hayan persistido (DROP por defecto sin las excepciones de 80/443). Solución: recargar el script o netfilter-persistent reload, y comprobar que iptables-persistent guardó las reglas.

(c) ¿Es problema de resolución de nombres?

El usuario accede por http://intranet.taller.local. Si el ping por IP funciona pero por nombre no, el fallo es de DNS.

# Resolver el nombre contra el DNS interno
dig intranet.taller.local @172.16.0.161
#   o:  nslookup intranet.taller.local 172.16.0.161
#   Esperado: el CNAME a servidor.taller.local y el A 172.16.0.161

# ¿Responde el servicio DNS (bind9)?
sudo systemctl status bind9          # Esperado: active (running)
sudo ss -ulnp | grep :53             # puerto 53 UDP en escucha

# Comprobar el resolutor del cliente
cat /etc/resolv.conf                 # nameserver debe apuntar al DNS interno

# Descartar el problema probando directamente por IP
ping -c1 intranet.taller.local       # si falla por nombre pero la IP responde -> DNS

Si dig no devuelve la dirección, revisar la zona (cuestión 4): serial incrementado, recarga con sudo rndc reload taller.local, sintaxis con named-checkzone taller.local /etc/bind/db.taller.local, y que el cliente tenga el DNS interno en resolv.conf.

Resumen del flujo de diagnóstico: host vivo (ping OK) → servicio Apache active → puerto 80/443 en LISTEN (ss/lsof) → cortafuegos con ACCEPT en esos puertos (iptables -L) → nombre que resuelve a la IP correcta (dig/resolv.conf). El primer eslabón que falle señala la causa.

Figura 4. Diagnóstico por capas: se comprueba host, servicio, puerto, cortafuegos y DNS en orden hasta hallar el eslabón que falla.