Ejercicios de Seguridad en Redes 
Escaneo de puertos + Escucha y análisis de tráfico

SSI 2022/23


Índice General

1 Entorno de pruebas

1.1 Software de virtualización VIRTUALBOX

En estas prácticas se empleará el software de virtualización VIRTUALBOX para simular los equipos GNU/Linux sobre los que se realizarán las pruebas.

1.2 Imágenes a utilizar

  1. Scripts de instalación

    Notas:

  2. Imágenes descargadas

  3. Usuarios configurados e inicio en el sistema

2 Introducción

El ejercicio consta de dos partes.

3 Ejercicio 1: Escaneo de puertos

El primer ejercicio consistirá en el uso de la herramienta de escaneo de puertos NMAP para obtener información de los equipos y servicios de la red.

NMAP implementa diversas técnicas para extraer información de los equipos que forman parte de una red y para identificar los puertos y servicios que están disponibles en distintas máquinas. Algunos de los métodos disponibles realizan el escaneo sin apenas dejar rastro, mientras que otros dejarán un rastro en los ficheros de log de las máquinas analizadas.

3.1 PREVIO: Preparación

En la máquina interno1 (192.168.100.11): habilitar y poner en marcha el servicio de LOG del sistema rsyslog

interno1:~# systemctl enable rsyslog
interno1:~# systemctl start rsyslog

Al arrancar, rsyslog empezará a registrar entradas en una serie de ficheros de LOG en el directorio /var/log: syslog, auth.log, messages, daemon.log, kernel.log, etc

3.2 Pasos a seguir

  1. Enumerar equipos de la red y sus servicios

    Desde la máquina observador (192.168.100.33):

    1. Lanzar un escaneado Ping Sweeping [opción -sP] para identificar, mediante Ping, las máquinas que componen la red
      observador:~# nmap -sP 192.168.100.0/24
      

    2. Sobre cada uno de los equipos que aparezcan como activos (exluido observador) realizar un escaneo de tipo TCP connect scanning [opción -sT] para determinar que puertos están abiertos.
      observador:~# nmap -sT -v -T4 192.168.100.11
      observador:~# nmap -sT -v -T4 192.168.100.22
      

    3. Repetir el escaneado sobre INTERNO1(192.168.100.11), añadiendo la opción -O para que NMAP trate de identificar el Sistema Operativo que ejecuta y la opción -sV para determinar la versión concreta de los servicios que tiene activados.
      observador:~# nmap -sT -O -sV -T4 192.168.100.11   (tarda unos segundos)
      

    Los escaneados anteriores dejan rastro. Comprobar los ficheros de log /var/log/syslog, /var/log/daemon.log o logs específicos de servidores en la máquina interno1 y verificar que ha quedado constancia de las conexiones realizadas por NMAP.

    interno1:~# tail -200 /var/log/syslog | less       (ampliar el limite de lineas [200] si es necesario)
    
    Nota: El rastro del escaneo de tipo -sT que queda en /var/log/syslog fue guardado por los servidores in.fingerd, inetd, telnetd, ftpd, dovecot, postfix/smtpd en el momento en que se completó el establecimiento de la conexión TCP (negociación SYV,SYN-ACK,ACK).

  2. Comprobar escaneos ”sigilosos”

    Evaluaremos el comportamiento de los distintos tipos de escaneo sobre la máquina interno1(192.168.100.11)

    1. En la máquina INTERNO1(192.168.100.11) se habilitará una regla del firewall netfilter para hacer log de los paquetes SYN con intentos de conexión TCP.
      • Escribir el siguiente comando iptables
        interno1:~# iptables -A INPUT -i enp0s3 -p tcp \
                                      --tcp-flags SYN SYN -m state --state NEW \
                                      -j LOG --log-prefix "INICIO CONEXION:"
        
        Nota: Esta regla iptables captura los mensajes TCP de inicio de conexión (flag syn a 1) y crea una entrada en el log del sistema etiquetada con INICIO CONEXION:

      • Monitorizar continuamente el fichero de log /var/log/syslog, con el comando tail -f
        				interno1:~# tail -f /var/log/syslog
        
        (el terminal se libera con CONTROL+C)

    2. Desde la máquina observador(192.168.100.33) lanzar 3 tipos de escaneos nmap y comprobar en INTERNO1(192.168.100.11) como evoluciona el log.
      TCP connect scanning
      [opción -sT] Escaneo con conexiones TCP completas (opción por defecto)
      				observador:~# nmap -sT 192.168.100.11
      

      $\to$ Generará entradas etiquetadas con INICIO CONEXION:, junto con las entradas generadas por los servidores (in.fingerd, inetd, telnetd, ftpd, ...)

      SYN scanning
      [opción -sS] Escaneo con paquetes SYN (conexiones parcialmente iniciadas)
      				observador:~# nmap -sS 192.168.100.11
      

      $\to$ Generará entradas etiquetadas con INICIO CONEXION:, pero no las generadas por los servidores (in.fingerd, inetd, telnetd, ftpd, ...)

      NULL scanning
      [opción -sN] Escaneo con paquetes ”nulos” (todos los flags TCP a 0)
      				observador:~# nmap -sN 192.168.100.11
      

      $\to$ No generará entradas etiquetadas con INICIO CONEXION:

4 Ejercicio 2: Intercepción de mensajes: protocolos en claro vs. protocolos cifrados

El segundo ejercicio consistirá en el uso del conjunto de utilidades disponibles en Bettercap y de la herramienta WIRESHARK desde el equipo observador para interceptar el tráfico TELNET, SSH, HTTP y HTTPS entre los equipos interno1 e interno2.

4.1 PREVIO: (Preparación 1) Habilitar TLS/SSL en Apache

PREVIO: Habilitar el soporte SSL en el servidor apache2 de interno2 (192.168.100.22)

En el equipo interno2 (192.168.100.22):

  1. Crear un certificado autofirmado para el servidor web.
    		interno2:~# mkdir /etc/apache2/ssl/
    		interno2:~# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem
    

    El fichero generado (/etc/apache2/ssl/apache.pem) contiene tanto el certificado del servidor como la clave privada asociada al mismo.

    		interno2:~# cat /etc/apache2/ssl/apache.pem
    		interno2:~# openssl x509 -text -in /etc/apache2/ssl/apache.pem
    		interno2:~# openssl rsa -text -in /etc/apache2/ssl/apache.pem
    

    Nota: make-ssl-cert es una utilidad de Debian (incluida en el paquete DEB ssl-cert) para generar certificados autofirmados para pruebas (los datos de configuración del certificado a generar se indican en /usr/share/ssl-cert/ssleay.cnf). Internamente hace uso de las utilidades de la librería openSSL.

    Nota: En un servidor real se suele utilizar un certificado emitido por una autoridad de certificación (CA) reconocida (o bien una CA pública o una CA propia de la organización). No es recomendable utilizar certificados autofirmados en sistemas en producción ya que son fácilmente falsificables.

  2. Editar la configuración SSL por defecto para indicar el certificado del servidor y su respectiva clave privada.
    		interno2:~# nano /etc/apache2/sites-available/default-ssl.conf
    
    Asignar los siguientes valores a los parámetros (en caso de que estén comentados descomentarlos)
    		...
    		SSLEngine on
    		...
    		SSLCertificateFile /etc/apache2/ssl/apache.pem
    		SSLCertificateKeyFile /etc/apache2/ssl/apache.pem
    		...
    
    Asegurar que el fichero /etc/apache2/ports.conf incluya el valor Listen 443

  3. Habilitar soporte SSL en Apache2 y habilitar la configuracion SSL por defecto
    		interno2:~# a2enmod ssl
    		interno2:~# a2ensite default-ssl 
    		interno2:~# systemctl restart apache2
    

    Nota:

4.2 PREVIO: (Preparación 2) Envenenamiento ARP y MITM con Bettercap

4.2.1 Comprobaciones iniciales

  1. Verificar que la máquina observador(192.168.100.33) no tiene acceso al tráfico entre interno1 e interno2

    1. En observador(192.168.100.33): en un nuevo terminal arrancar tshark y ponerlo en escucha sobre la tarjeta enp0s3 para ver (en caso de ser posible) el tráfico que pasa por la red
      observador:~# tshark --color -i enp0s3
      
    2. En interno1(192.168.100.11):

      • Establecer conexión telnet con interno2 (con login usuario y contraseña usuario)
        interno1:~# telnet interno2.ssi.net 
        
        Trying 192.168.100.22...
        Connected to interno2.ssi.net.
        Escape character is '^]'.
        
        Linux 5.18.0-14parrot1-amd64 (interno2.ssi.net) (pts/0)
        
        interno2.ssi.net nombre: usuario
        Contraseña: usuario
        
        Linux interno2.ssi.net 5.18.0-14parrot1-amd64 
        ...
        interno2:~$ ls -l
        interno2:~$ exit
        

      • Establecer conexión HTTP con interno2 usando lynx
        interno1:~# lynx interno2.ssi.net    (salir con tecla Q o [control]+C)
        

    3. En observador: Verificar que el sniffer no ha capturado paquetes de esas conexiones y cerrar tshark con [control]+C

  2. Consultar tablas ARP en interno1 e interno2
    interno1:~# arp -n
    
    Address                  HWtype  HWaddress           Flags Mask            Iface
    192.168.100.33           ether   08:00:27:33:33:33   C                     enp0s3
    192.168.100.1                    (incomplete)                              enp0s3
    192.168.100.22           ether   08:00:27:22:22:22   C                     enp0s3
    

    interno2:~# arp -n
    
    Address                  HWtype  HWaddress           Flags Mask            Iface
    192.168.100.33           ether   08:00:27:33:33:33   C                     enp0s3
    192.168.100.11           ether   08:00:27:11:11:11   C                     enp0s3
    192.168.100.1                    (incomplete)                              enp0s3
    


4.2.2 Envenenamiento ARP (ARP spoofing) y ataque MITM

Objetivos:

Para llevar a cabo el ARP spoofing y el ataque MITM se usarán los suguientes módulos de Bettercap

Nota: opcionalmente se puede habilitar el interfaz web de Bettercap haciendo uso de los módulos api.rest y http.ui (ver https://www.bettercap.org/usage/webui/).

Pasos a seguir:

  1. En observador(192.168.100.33): desde un terminal propio, arrancar Bettercap y sondear la red para identificar los equipos conectados

    observador:~#  bettercap -iface enp0s3
    
    192.168.100.0/24 > 192.168.100.33  » help net.probe
    192.168.100.0/24 > 192.168.100.33  » help net.recon
    
    192.168.100.0/24 > 192.168.100.33  » net.recon on
    192.168.100.0/24 > 192.168.100.33  » net.probe on         (esperar unos segundos)
    192.168.100.0/24 > 192.168.100.33  » net.probe off
    192.168.100.0/24 > 192.168.100.33  » net.show
    
    +----------------+-------------------+-------------------+---------------------------+-------+-------+----------+
    |      IP        |        MAC        |       Name        |          Vendor           | Sent  | Recvd |   Seen   |
    +----------------+-------------------+-------------------+---------------------------+-------+-------+----------+
    | 192.168.100.33 | 08:00:27:33:33:33 | enp0s3            | PCS Computer Systems GmbH | 0 B   | 0 B   | 19:39:12 |
    |                |                   |                   |                           |       |       |          |
    | 192.168.100.11 | 08:00:27:11:11:11 | interno1.ssi.net. | PCS Computer Systems GmbH | 120 B | 92 B  | 19:39:36 |
    | 192.168.100.22 | 08:00:27:22:22:22 | interno2.ssi.net. | PCS Computer Systems GmbH | 120 B | 92 B  | 19:39:36 |
    +----------------+-------------------+-------------------+---------------------------+-------+-------+----------+
    
    192.168.100.0/24 > 192.168.100.33  »
    

    Nota 1: No se debe salir de la consola de Bettercap durante la sesión de ARP Spoofing y MITM, es necesario que los módulos de Bettercap estén en funcionamiento.

    Nota 2: (opcional) Es posible poner en marcha el interfaz Web de Bettercap

  2. En observador(192.168.100.33): en un terminal propio (diferente al de Bettercap), arrancar tshark y ponerlo en escucha sobre la tarjeta enp0s3 para ver el tráfico ARP generado por Bettercap durante el ataque de ARP spoofing
    observador:~# tshark --color -i enp0s3
    

  3. En observador(192.168.100.33): desde el terminal de Bettercap configurar y arrancar el ataque ARP spoofing
    192.168.100.0/24 > 192.168.100.33  » help arp.spoof
    192.168.100.0/24 > 192.168.100.33  » help net.sniff
    	
    192.168.100.0/24 > 192.168.100.33  » set arp.spoof.internal true
    192.168.100.0/24 > 192.168.100.33  » set arp.spoof.targets 192.168.100.11,192.168.100.22
    192.168.100.0/24 > 192.168.100.33  » arp.spoof on
    

  4. En observador(192.168.100.33): verificar el tráfico capturado por tshark y cerrar la captura con [control]+C

  5. Consultar las tablas ARP en interno1 e interno2
    interno1:~# arp -n
    

    interno2:~# arp -n
    

    CUESTION 1: ¿Cómo son los mesajes ARP que envia el módulo arp.spoof? ¿Cómo quedan las tablas ARP de interno1 e interno2 y qué significan esos valores?

4.3 Tarea 1: Escucha del protocolo TELNET

  1. En observador (192.168.100.33): iniciar la captura de tráfico con el módulo net.sniff de Bettercap, dejará los paquetes capturadas en el fichero /tmp/telnet.pcap
    192.168.100.0/24 > 192.168.100.33  » set net.sniff.filter "not arp"
    192.168.100.0/24 > 192.168.100.33  » set net.sniff.output /tmp/telnet.pcap
    192.168.100.0/24 > 192.168.100.33  » net.sniff on
    

  2. En interno1 (192.168.100.11): iniciar una conexión TELNET con interno2 (192.168.100.22)
    interno1:~#  telnet interno2.ssi.net
    
    Trying 192.168.100.22...
    Connected to interno2.ssi.net.
    Escape character is '^]'.
    
    Linux 5.18.0-14parrot1-amd64 (interno2.ssi.net) (pts/1)
    
    interno2.ssi.net nombre: usuario
    Contraseña: usuario
    
    Linux interno2.ssi.net 5.18.0-14parrot1-amd64		
    ...
    interno2:~$ ls -l
    ...
    interno2:~$ exit
    

  3. En observador (192.168.100.33): analizar el tráfico recopilado

4.4 Tarea 2: Escucha del protocolo SSH

  1. En observador (192.168.100.33): iniciar la captura de tráfico con el módulo net.sniff de Bettercap, dejará los paquetes capturadas en el fichero /tmp/ssh.pcap
    		192.168.100.0/24 > 192.168.100.33  » set net.sniff.output /tmp/ssh.pcap
    		192.168.100.0/24 > 192.168.100.33  » net.sniff on
    

  2. En interno1 (192.168.100.11): iniciar una conexión SSH con interno2 (192.168.100.22)
    interno1:~# ssh usuario@interno2.ssi.net
    
    usuario@interno2.ssi.net's password: usuario
    Linux interno2.ssi.net 5.18.0-14parrot1-amd64
    ...
    interno2:~$ ls -l
    ...
    interno2:~$ exit
    

  3. En observador (192.168.100.33): analizar el tráfico recopilado

4.5 Tarea 3: Escucha del protocolo HTTP

  1. En observador (192.168.100.33): iniciar la captura de tráfico con el módulo net.sniff de Bettercap, dejará los paquetes capturadas en el fichero /tmp/http.pcap
    	192.168.100.0/24 > 192.168.100.33  » set net.sniff.output /tmp/http.pcap
    	192.168.100.0/24 > 192.168.100.33  » net.sniff on
    

  2. En interno1 (192.168.100.11): iniciar una conexión HTTP con interno2 (192.168.100.22) usando el navegador lynx (también puede hacer con el navegador gráfico Falkon)
    interno1:~# lynx interno2.ssi.net
    
    (para generar tráfico, acceder a alguna de las aplicaciones disponibles, por ejemplo DVWA con admin/password)
    

    Nota: En caso de no obtener respuesta, reiniciar el servidor apache2 en la máquina interno2 (192.168.100.22)

    			interno2:~# systemctl restart apache2
    

  3. En observador (192.168.100.33): analizar el tráfico recopilado

4.6 Tarea 4: Escucha del protocolo HTTPS

  1. En observador (192.168.100.33): iniciar la captura de tráfico con el módulo net.sniff de Bettercap, dejará los paquetes capturadas en el fichero /tmp/https.pcap
    		192.168.100.0/24 > 192.168.100.33  » set net.sniff.output /tmp/https.pcap
    		192.168.100.0/24 > 192.168.100.33  » net.sniff on
    

  2. En interno1 (192.168.100.11): iniciar una conexión HTTP con interno2 (192.168.100.22) usando el navegador lynx (también puede hacer con el navegador gráfico Falkon, importante añadir https)
    		interno1:~# lynx https://interno2.ssi.net
    	
    		(para generar tráfico, acceder a alguna de las aplicaciones disponibles, por ejemplo DVWA con admin/password)
    

    Nota: El navegador pedirá confirmación (lynx varias veces) al tratarse de un certificado autofirmado emitido por una CA no reconocida (no está en /etc/ssl/certs/ca-certificates.pem) y considerarlo no fiable.

  3. En observador (192.168.100.33): analizar el tráfico recopilado

5 Documentación y entrega

El material entregable de esta práctica constará de una pequeña memoria documentando los ejercicios realizados y los resultados obtenidos en cada paso realizado, junto con las conclusiones que se deriven de dichos resultados.

ENTREGA: en MOOVI, hasta 27/12/2022 (individual o parejas)