Un recurso compartido de Samba expuesto en file1 (en la dirección 10.0.0.30) puede revelar archivos a quien acceda al servicio, sin necesidad de descifrar una contraseña ni instalar malware. Este resultado es útil en nuestro laboratorio porque demuestra por qué las pruebas de seguridad requieren límites antes de comenzar. Inspeccionaremos únicamente sistemas de nuestra propiedad o aquellos para los que contemos con autorización por escrito, y registraremos qué información expuso el servicio para que su propietario pueda corregir la vulnerabilidad.
Nuestro entorno fijo es la red privada 10.0.0.0/24. La máquina Kali en 10.0.0.10 actúa como estación de trabajo para las pruebas. web1 (en 10.0.0.20) es un objetivo Metasploitable 2 con servicios en los puertos 21, 22 y 80, mientras que file1 (en 10.0.0.30) expone Samba en los puertos 139 y 445. Ninguna dirección fuera de esta subred forma parte del ejercicio, y el laboratorio no incluye objetivos expuestos a Internet. Mostramos la naturaleza de una vulnerabilidad y su efecto observable, no pasos convertidos en herramientas de ataque que pudieran reutilizarse contra otro sistema. Examinemos el límite que mantiene contenido cada ejercicio posterior:
Este diagrama establece una dirección permitida: desde Kali hacia los dos objetivos del laboratorio especificados. Una solicitud a 10.0.0.30 entra dentro del alcance porque file1 es un objetivo asignado; la misma solicitud dirigida a una dirección desconocida está prohibida, incluso si el servicio parece idéntico.
Dado que el límite de la red por sí solo no define el comportamiento aceptable, necesitamos un acuerdo de Reglas de Compromiso (Rules of Engagement): un contrato escrito que delimita quién puede realizar pruebas, qué activos pueden evaluarse, cuándo pueden llevarse a cabo dichas pruebas y qué métodos están permitidos. Para este curso, el acuerdo especifica web1 y file1, restringe la actividad al rango 10.0.0.0/24 y establece a Kali como el único origen de las pruebas. La autorización por escrito distingue una evaluación controlada de un acceso no autorizado, conforme a leyes como la Computer Fraud and Abuse Act de Estados Unidos y la Computer Misuse Act 1990 del Reino Unido. Este curso ofrece formación técnica, no asesoramiento jurídico.
El acuerdo también evita que un ejercicio para principiantes se vuelva perjudicial. Podemos identificar servicios expuestos y observar de forma segura si un listado anónimo de Samba revela el nombre de un archivo. No ajustamos cargas útiles (payloads), ni eludimos la monitorización, ni creamos persistencia, ni interrumpimos la disponibilidad, ni lanzamos ataques masivos de adivinación de contraseñas, ni incluimos credenciales reales en las notas. Una prueba debe generar evidencias que un defensor pueda verificar, no provocar un cambio incontrolado que obligue al propietario del laboratorio a realizar tareas de recuperación.
Límite de seguridad
Si una acción altera el acceso, la disponibilidad o la persistencia más allá de la observación acordada, deténgase y registre la situación en lugar de continuar.
Cada paso permitido genera un pequeño rastro de evidencia. El cuaderno de notas registra el comando tal como se escribió, la marca de tiempo, la dirección de destino y la salida relevante. Si el listado de un recurso compartido muestra backup.zip, anotamos ese nombre y las condiciones de acceso; luego, nos planteamos qué registro de seguridad mostraría la conexión y qué configuración impediría el acceso anónimo. La tabla siguiente distingue las observaciones útiles de aquellas acciones que exceden los términos de nuestro acuerdo: