151 lines
14 KiB
Markdown
151 lines
14 KiB
Markdown
> **📝 Exame de Nivel Avanzado v2.0: "Buscando as cóxegas"**
|
|
|
|
# Pregunta 1: Administración de Sistemas e Scripting (Castellano) (Temas 32 y 35)
|
|
|
|
Has escrito un script en Bash (`backup_db.sh`) perfecto que automatiza la copia de seguridad de una base de datos usando el comando `mysqldump` y luego sube el archivo a un servidor mediante `rsync`. Si tú, logueado con el usuario `admin_tic`, escribes `./backup_db.sh` en la terminal, el script funciona como un reloj.
|
|
|
|
Para automatizarlo, añades el script al `crontab` del mismo usuario `admin_tic` para que se ejecute a las 3:00 AM. Al día siguiente, revisas los logs y el cron ha fallado con el error: `mysqldump: command not found`.
|
|
|
|
- **Tu labor**: Explica técnicamente por qué el sistema encuentra el comando cuando lo ejecutas tú a mano, pero no lo encuentra cuando lo ejecuta `cron` (siendo el mismo usuario). ¿Cuál es la forma más profesional y robusta de solucionar esto dentro de tu script?
|
|
|
|
## Respuesta
|
|
|
|
Voy a tirar un triple, pero no tengo ni idea del motivo. Cuando ejecutas el Script con el usuario desde `./backup_db.sh` haces uso de su sesión Bash, pero desde `cron`, éste hace una ejecución a partir de la orden `sh`, que es distinta, de ahí las cabeceras del archivo Bash `#!/bin/bash` y `#!/bin/bash` entre otras.
|
|
|
|
> **Anotaciones**: Estuve indagando tras la respuesta triplazo que me marqué pero no encontré nada que los clásicos errores de escapes y poco más. La orden `rsync` no tiene nada que ver pues es una copia sincronizada de todo el contenido, inclyendo los valores EXT4.
|
|
|
|
## Corrección
|
|
|
|
Tu "triple" iba bastante bien encaminado al pensar en el entorno (`sh` vs `bash`), pero el problema principal con `cron` es mucho más específico y es un clásico en la administración de sistemas Linux.
|
|
|
|
**El problema técnico:**
|
|
|
|
Cuando tú te logueas como `admin_tic`, el sistema carga todo tu perfil de usuario (los archivos `.bashrc` o `.bash_profile`). Esto incluye la variable de entorno `$PATH`, que es la lista de directorios donde el sistema busca los comandos ejecutables. Gracias a eso, cuando escribes `mysqldump`, el sistema sabe que tiene que buscarlo en `/usr/bin/` o `/usr/local/bin/`.
|
|
|
|
Sin embargo, `cron` se ejecuta en un entorno mínimo. No carga tu `.bashrc`. Por defecto, el `$PATH` de cron suele ser súper básico, a menudo solo `/usr/bin:/bin`. Si `mysqldump` está instalado en una ruta diferente (como es muy habitual con bases de datos específicas), cron literalemente te dice: "comando no encontrado" porque no sabe dónde buscarlo.
|
|
|
|
**La solución profesional:**
|
|
|
|
La regla de oro para cualquier script que vaya a ser ejecutado por cron es **usar siempre rutas absolutas (completas) para los comandos críticos**, o redefinir el `$PATH` al principio del script.
|
|
|
|
Dentro de `backup_db.sh` deberías escribir:
|
|
|
|
```sh
|
|
/usr/bin/mysqldump -u usuario -p... # (o la ruta exacta donde esté el ejecutable, que puedes averiguar ejecutando which mysqldump en tu terminal).
|
|
```
|
|
|
|
# Pregunta 2: Redes Locais e Subnetting (Galego) (Temas 39 e 40)
|
|
|
|
Estás a configurar os equipos nunha nova oficina do Concello. A un equipo asígnaslle a dirección IP `10.0.0.255` cunha máscara de subrede `255.255.254.0` (un /23). O compañeiro que está a axudarche diche que estás a cometer un erro de principiante, xa que "as IP rematadas en `.255` son sempre direccións de *broadcast* e ese ordenador non vai ter conectividade".
|
|
|
|
- **O teu labor**: Quen ten razón? Demostra matematicamente (ou loxicamente) cal é a dirección de rede, o rango de IPs válidas para hosts e a dirección de *broadcast* real desta subrede para xustificar a túa resposta.
|
|
|
|
## Resposta
|
|
|
|
Esta vouna responder a cegas a ver qué tal, por mor de vela sinxela. A rede `10.0.0.0/8` é a rede privada de clase A, aínda que neste caso fans subdivisións a nivel de subrede, cousa moi común, neste caso, á subrede `10.0.0.0/23`. No termo de máscara, ésta representa a rede, e o resto Host. Neste caso temos 23 bits de máscara e 9 de Host, polo que temos o seguinte símil:
|
|
|
|
- Ámbito de rede binaria: 11111111.11111111.11111110.00000000
|
|
- Ámbito de Host binaria: 00000000.00000000.00000001.11111111
|
|
|
|
A nivel binario atopamos que a IP asinada ven sendo:
|
|
|
|
- Ámbito de rede binaria: 00001010.00000000.00000000.00000000
|
|
- Ámbito de Host binario: 00000000.00000000.00000000.11111111
|
|
|
|
Polo tanto, estamos como Host. O Broadcast é a última dirección de rede, é dicir, cuando o ámbito de Host ven sendo todo 1. Nes tecaso falta un aínda para compretalo Broadcast, polo que o novo compañeiro ten razón fronte o veterano.
|
|
|
|
## Corrección
|
|
|
|
¡Buen intento con el cálculo binario! Pero la conclusión se te ha torcido al final. Aquí el compañero "novato" no tenía razón, pero tú te has liado un poco en la demostración. Vamos a verlo paso a paso, es más fácil de lo que parece.
|
|
|
|
Tenemos la IP `10.0.0.255 /23`.
|
|
|
|
La máscara `/23` en decimal es `255.255.254.0`.
|
|
|
|
Esto significa que nuestra red va variando en el tercer octeto en bloques de 2 (porque 256 - 254 = 2).
|
|
|
|
Por tanto, las redes disponibles en este rango serían:
|
|
|
|
- Red 0: `10.0.0.0`
|
|
- Red 1: `10.0.2.0`
|
|
- Red 2: `10.0.4.0` ... y así sucesivamente.
|
|
|
|
Nuestra IP (10.0.0.255) pertenece a la Red 0 (`10.0.0.0`).
|
|
|
|
- Dirección de Red: `10.0.0.0`
|
|
- Primer Host válido: `10.0.0.1`
|
|
- Último Host válido: `10.0.1.254`
|
|
- Dirección de Broadcast: `10.0.1.255` (todos los bits de host a 1).
|
|
|
|
Conclusión: La IP `10.0.0.255` SÍ es una dirección de host completamente válida en una subred `/23`. El compañero se equivoca porque asume la regla antigua de las redes de Clase C (las `/24`), donde el `.255` siempre es broadcast. Al tener una máscara más amplia, el límite de la subred se desplaza. ¡Tú tenías razón en dudar de él!
|
|
|
|
# Pregunta 3: Protección de Datos e Dereitos das Persoas (Galego) (Temas 8 e 30)
|
|
|
|
Un cidadán preséntase no rexistro do Concello e exerce formalmente o seu "Dereito de Supresión" (o famoso dereito ao esquecemento) esixindo que se borren absolutamente todos os seus datos persoais da base de datos tributaria do Imposto sobre Bens Inmobles (IBI), argumentando que vendeu a súa casa fai un mes, que xa non é propietario e que retirou o seu consentimento explícito para que o Concello trate os seus datos.
|
|
|
|
- **O teu labor**: Como técnico municipal, debes informar xuridicamente esta solicitude. Baseándote no RGPD e na LOPDGDD, ¿débense borrar os datos inmediatamente ao ser revocado o consentimento? Xustifica a base lexitimadora do tratamento neste caso e o motivo legal para estimar ou desestimar a petición.
|
|
|
|
## Resposta
|
|
|
|
Aquí voume marcar un triple diciendo a cegas que hay un tempo que se teñen que gardar os datos dalgo tan sensible. A maiores diso, por simple lóxica, se se eliminan os datos, éstes poden descadrar datos dependentes, o cal pode verse claramente nos ámbitos relacionais das bases de datos, polo tanto, non é un proceso sinxelo, pero o que sí poderíase tratar é a anonimización dos datos do cidadán.
|
|
|
|
Agora que xa me marquei o triple, imos ver qué nos di a Lei sobre isto.
|
|
|
|
Vendo no máis básico da Lei Orgánica 3/2018, do 5 de Decembro de Protección de Datos Persoais e Garantía dos Dereitos Dixitais, no seu Apartado 2 do Artigo 15, do Dereito de Supresión, do Capítulo II, do Exercicio dos Dereitos, do Título III, dos Dereitos das Persoas, temos que o responsable poderá conservar os datos identificativos do afectado necesarios co fin de impedir tratamentos futuros para fins de mercadotecnia directa.
|
|
|
|
Por outra banda, se afinamos máis e imos ao Reglamento 2016/679 do Parlamento Europeo e do Consello do 27 de Abril relativo á Protección das Persoas Físicas no que Respecta ao Tratamento de Datos Persoais e á Libre Circulación destes Datos, concretamente o seu artigo 21, do Dereito de Oposición, no seu Apartado 2 dinos o mesmo, por relación do LOPDGDD, pero en afección ao Dereito de Oposición, concretamente ó Artigo 21 do Reglamento Europeo, vinculado no Artigo 18, do Dereito de Oposición, éste nos leva ao Artigo 6 do Reglamento Europeo, concretamente o Apartado 1, aos seus puntos *e* e *f*, onde no *f* atopamos que ven sendo lícito o uso dos datos cando foi a partires dunha xestión de interese público. Pese a ser un ámbito privado a tenencia dun ben, o pago do IBI pertence ao interese público por mor da natureza da Administración que o leva, e á cal pídeselle que se eliminen os datos. Por mor disto, non habería obriga ninguna por parte do Concello, é máis, sería lícito.
|
|
|
|
- **Anotacións**: Qué ven sendo *mercadotecnia*?
|
|
|
|
## Corrección
|
|
|
|
Aquí has mezclado varios conceptos y te has ido por una rama legal que no es la principal para este caso (mercadotecnia/interés público), aunque la intuición de fondo ("no se puede borrar todo así como así") era totalmente correcta.
|
|
|
|
**La trampa principal:**
|
|
|
|
El ciudadano argumenta que "retira su consentimiento". ¡Pero el cobro de impuestos (el IBI) **no** se basa en el consentimiento del ciudadano!
|
|
|
|
**La justificación legal (RGPD Art. 6):**
|
|
|
|
La base legitimadora para que el Ayuntamiento trate los datos del IBI **NO es el consentimiento** (Art. 6.1.a), sino el **cumplimiento de una obligación legal** (Art. 6.1.c) y el **ejercicio de poderes públicos** conferidos al responsable (Art. 6.1.e). Tú no das permiso para pagar impuestos; la ley te obliga.
|
|
|
|
Por tanto, el Derecho de Supresión (Art. 17 del RGPD) no es absoluto. El artículo 17.3.b establece claramente que **no procederá la supresión cuando el tratamiento sea necesario para el cumplimiento de una obligación legal**.
|
|
|
|
Aunque el ciudadano haya vendido la casa y ya no sea propietario actual, el Ayuntamiento debe conservar esos datos tributarios durante el tiempo que la ley marque (por ejemplo, los 4 años de prescripción de la Ley General Tributaria) por si hubiera que revisar o reclamar impagos pasados.
|
|
|
|
*Nota sobre tu anotación: "Mercadotecnia" se refiere al marketing directo, envío de publicidad comercial. No aplica en absoluto a la gestión tributaria municipal.*
|
|
|
|
# Pregunta 4: Ciberseguridad y Autenticación MFA (Castellano) (Temas 20 y 31)
|
|
|
|
En la implantación de un sistema de Autenticación Multifactor (MFA) para el acceso remoto mediante VPN de los funcionarios al Ayuntamiento, decides configurar un factor basado en "Algo que el usuario SABE" (su contraseña de Directorio Activo). Como segundo factor ("Algo que el usuario TIENE"), propones el envío de un código numérico (OTP) por SMS al teléfono móvil corporativo del trabajador.
|
|
|
|
Al presentar el proyecto, el responsable de seguridad (CISO) te lo rechaza basándose en las directrices actuales del Esquema Nacional de Seguridad (ENS) y las guías del CCN-CERT.
|
|
|
|
- **Tu labor**: Explica por qué el envío de códigos por SMS ya no se considera un método robusto para el segundo factor en entornos corporativos. Nombra al menos un tipo de ataque técnico específico que haga vulnerable al SMS frente a otras alternativas modernas (y nombra una alternativa mejor).
|
|
|
|
## Respuesta
|
|
|
|
Esta la tuve que buscar pues la lógica de inseguridad me falla enormemente en estos conceptos. Para empezar, pese a que no entra dentro del concepto MFA, uno de los patrones de seguridad más seguros que hay, sino es el que más, no es el MFA, sino el uso de dos dispositivos disintos y aislados, por ejemplo, la red de Internet y la línea móvil de un teléfono, por lo que pese a no ir cifrado ni asegurado, la información sólo la tiene el servidor de origen y mi sesión en el dispositivo de internet, por tanto, para que ése sea vulnerado tendrían que vulnerar dos equipos.
|
|
|
|
Ahora bien, si nos regimos explícitamente al MFA, como tal, con opción general a un dispositivo, el SMS es un peligro mayúsculo, así como cualquier otro medio que se use, sea cifrado o no pues si se vulnera el equipo, adiós muy buenas, pero como se ignora sistemáticamente este concepto tan básico y fundamental de la ciberseguridad pues nos lanzamos a la piscina y decimos que al no ir cifrado ni garantizado el SMS ni las llamadas, motivo por el cual existe en Phone Spoofing entre otros males absurdamente arreglables pues la siguiente solución es la autenticación vía Authenticators como el de Google o Microsoft.
|
|
|
|
Siento ponerme drástico con este tema pero es que me flipa como se exigen cosas de forma descontralada y absurda sin ver el problema básico real de un simple Click que te vulnere el equipo único que se suele usar.
|
|
|
|
## Corrección
|
|
|
|
Tu desahogo inicial es muy comprensible. El debate sobre si el usuario usa un único dispositivo para el factor "algo que sabe" (contraseña en el PC) y "algo que tiene" (SMS en el móvil que tiene al lado) es recurrente. Pero a nivel de examen (y de normativas como el ENS o el CCN-CERT), hay que ceñirse a las vulnerabilidades técnicas del propio medio.
|
|
|
|
El rechazo del CISO al SMS es correcto según los estándares actuales de alta seguridad.
|
|
|
|
**Por qué el SMS ya no es seguro:**
|
|
|
|
La red de telefonía móvil por la que viajan los SMS (como el protocolo SS7) es antigua y tiene vulnerabilidades conocidas que permiten interceptar los mensajes en tránsito sin necesidad de tocar el teléfono físico del usuario.
|
|
|
|
Ataques específicos al SMS (lo que pedía la pregunta):
|
|
|
|
- **SIM Swapping (Duplicado de SIM)**: El atacante engaña a la operadora telefónica haciéndose pasar por el usuario para conseguir una copia de su tarjeta SIM. A partir de ese momento, todos los SMS (incluidos los OTP) le llegan al atacante, no al trabajador.
|
|
- **Interceptación SS7**: Explotando fallos en la infraestructura de la red celular para redirigir los mensajes.
|
|
|
|
**La alternativa mejor:**
|
|
|
|
Tal y como tú mismo indicaste al final, la solución estándar hoy en día son las **Apps Autenticadoras** (Google Authenticator, Microsoft Authenticator). Se basan en el protocolo TOTP (*Time-based One-Time Password*). Son más seguras porque los códigos se generan localmente en el dispositivo sin depender de una red de telecomunicaciones externa vulnerable a la interceptación en tránsito. |