Informe de Auditoría SEED 2023

RESUMEN.
Informe de auditoría de ciberseguridad de la Empresa

SmartTag Systems, junio 2023.
INFORME DE AUDITORÍA DE
CIBERSEGURIDAD DEL PROYECTO SEED
En base a las Políticas de seguridad de
SmartTag Systems
Universidad Tecnológica de Bahía de Banderas
Auditores
Alejandro Sánchez Aguilar
José Julián Escobar González
29 de junio, 2023
1
RESUMEN. Informe de auditoría de ciberseguridad de la Empresa
Por qué realizamos esta auditoría

La auditoría del proyecto SEED se realiza con el propósito de evaluar la seguridad
de los sistemas y servicios involucrados. A continuación, se mencionan los motivos
principales por los cuales se lleva a cabo esta auditoría:
Garantizar la protección de la información

La auditoría busca asegurar que se hayan implementado las medidas de seguridad
adecuadas para proteger la integridad, confidencialidad y disponibilidad de la
información relacionada con el proyecto SEED. Se analizarán los servicios del
servidor Raspberry Pi 4b.
Identificar posibles vulnerabilidades y riesgos

La auditoría tiene como objetivo detectar posibles vulnerabilidades en la
configuración de los dispositivos y servicios utilizados en el proyecto. Se examinarán
las configuraciones de red, los sistemas operativos, las aplicaciones y cualquier otro
aspecto relevante que pueda representar un riesgo de seguridad. De esta manera,
se podrán tomar medidas para mitigar estos riesgos y proteger el proyecto contra
posibles amenazas.
Mejorar la seguridad y la protección de datos

La auditoría proporciona la oportunidad de identificar áreas de mejora en la
seguridad y protección de datos del proyecto SEED. Se evaluarán las políticas, los
procedimientos y las prácticas existentes, y se propondrán recomendaciones para
fortalecer la postura de seguridad. Esto permitirá establecer medidas preventivas y
correctivas que contribuyan a mantener la integridad y confidencialidad de la
información.
Cumplir con requisitos y estándares de seguridad

La auditoría se realiza para asegurarse de que el proyecto SEED cumpla con los
requisitos y estándares de seguridad establecidos con ISO 27001. Esto incluye
verificar que se hayan implementado controles adecuados, como autenticación y
autorización sólidas, políticas de contraseñas seguras, cifrado de datos y protección
contra vulnerabilidades conocidas.
2
ÍNDICE
Introducción
1.1 Objetivo de la auditoría
1.2 Alcance de la auditoría
1.3 Metodología utilizada
Descripción del proyecto SEED

2.1 Visión general del proyecto
2.2 Componentes y tecnologías utilizadas
Recopilación de información
3.1 Detalles de hardware y software
Enumeración de activos
4.1 Raspberry Pi (servidor y dispositivo de alta de usuarios RFID)
4.2 ESP32 y RFID
4.3 Servidor DNS (Bind9)
4.4 Servidor web (Apache2)
4.5 Base de datos (PostgreSQL)
4.6 Otros servicios y aplicaciones relevantes
Análisis de vulnerabilidades
5.1 Uso de herramientas; Nikto, Nmap y Nessus
5.2 Resultados de las escaneos y evaluaciones de vulnerabilidades
5.3 Identificación y clasificación de las vulnerabilidades encontradas
3
Evaluación de configuraciones
6.1 Revisión de las configuraciones de seguridad de los dispositivos y servicios

6.2 Verificación de actualizaciones y parches
6.3 Aplicación de mejores prácticas de seguridad
Prueba de penetración (Pentesting)

7.1 Uso de herramientas como Metasploit, Nmap e Hydra
7.2 Escenarios y pruebas realizadas
7.3 Resultados de las pruebas de penetración
Verificación de autenticación y autorización

8.1 Evaluación de los mecanismos de autenticación y autorización
8.2 Comprobación de los niveles de acceso y permisos asignados
Evaluación de políticas de seguridad

9.1 Revisión de políticas de contraseñas, cifrado de datos y restricciones de acceso
9.2 Evaluación de la existencia de políticas y procedimientos claros para el manejo
de incidentes de seguridad
Pruebas de denegación de servicio (DDoS)

10.1 Evaluación de la resistencia de la infraestructura y aplicaciones a ataques
DDoS
10.2 Resultados de las pruebas
4
Evaluación de la configuración de firewall
11.1 Revisión de la configuración del firewall en la Raspberry Pi
11.2 Verificación de reglas de filtrado adecuadas y puertos abiertos necesarios
Evaluación de respaldo y recuperación de datos

12.1 Verificación de los procedimientos de respaldo y recuperación de datos
12.2 Pruebas de restauración de datos y evaluación de la efectividad de los
procesos
Conclusiones y soluciones
13.1 Resumen de los hallazgos y resultados obtenidos
13.2 Implementando soluciones
Anexos
14.1 Detalles técnicos adicionales
14.2 Información adicional relevante
5
Introducción
La presente documentación de auditoría tiene como objetivo evaluar la seguridad y

la protección de la información en el proyecto SEED. Esta auditoría se lleva a cabo
con el fin de identificar posibles vulnerabilidades, evaluar las configuraciones de
seguridad, analizar los riesgos asociados y proporcionar recomendaciones para
fortalecer la postura de seguridad del proyecto.
El proyecto SEED se centra en el desarrollo de un dispositivo de chequeo de

entradas utilizando ESP32 y RFID, en conjunto con dos Raspberry Pi que actúan
como servidor y dispositivo de alta de usuarios RFID, respectivamente. Además, se
emplean servicios como Apache2 para un sistema de login que muestra las entradas
y salidas detectadas por el ESP32 de forma gráfica, Bind9 para el servidor DNS y
PostgreSQL para las bases de datos.
La auditoría abarcará los componentes y servicios mencionados anteriormente, con

el objetivo de evaluar la implementación de medidas de seguridad adecuadas,
detectar posibles vulnerabilidades y riesgos, y garantizar el cumplimiento de las
mejores prácticas de seguridad.
6
Se utilizaron herramientas como Nikto, Nmap y OWASP ZAP para llevar a cabo un
análisis exhaustivo de vulnerabilidades en los sistemas y servicios involucrados.
Además, se realizaron pruebas de pentesting utilizando Metasploit y diversas
herramientas para identificar posibles puntos de entrada no deseados en el sistema
y evaluar la resistencia frente a ataques.
El resultado de esta auditoría es un informe detallado que incluye los hallazgos, las
recomendaciones y las soluciones realizadas para fortalecer la seguridad del
proyecto SEED. Este informe servirá como base para implementar las medidas
necesarias y mejorar la protección de la información y los sistemas involucrados.
Es importante destacar que esta auditoría se realiza con el compromiso de

salvaguardar la integridad, confidencialidad y disponibilidad de la información
relacionada con el proyecto SEED, así como mitigar los riesgos asociados a
posibles incidentes de seguridad.
Objetivo de la auditoría
El objetivo principal de esta auditoría es evaluar la seguridad y protección de la

información en el proyecto SEED. A través de este proceso, se busca identificar
posibles vulnerabilidades y riesgos en los sistemas, servicios y componentes
involucrados, con el fin de fortalecer la postura de seguridad y minimizar la
exposición a amenazas.
7
Los objetivos específicos de esta auditoría son:
• Identificar posibles vulnerabilidades y debilidades en las configuraciones de

red, hardware y software utilizados en el proyecto.
• Evaluar la implementación de medidas de seguridad, como autenticación,
autorización, cifrado de datos y políticas de contraseñas, para garantizar su
eficacia y cumplimiento de las mejores prácticas.
• Realizar pruebas de pentesting controladas para identificar posibles puntos
de entrada no deseados y evaluar la resistencia del sistema ante ataques.
• Analizar los registros de actividad y monitoreo en busca de eventos
sospechosos o actividades anormales que puedan indicar intentos de acceso
no autorizado o brechas de seguridad.
• Verificar la adecuada configuración del firewall y las reglas de filtrado para
proteger la infraestructura del proyecto.
• Evaluar los procedimientos de respaldo y recuperación de datos evaluados
en el documento DRP para garantizar la disponibilidad y la integridad de la
información en caso de incidentes.
Al alcanzar estos objetivos, se busca brindar al proyecto SEED una visión clara de
su estado actual en términos de seguridad, así como establecer una base sólida
para implementar medidas correctivas y preventivas que garanticen la protección
adecuada de la información y los sistemas involucrados.
8
Alcance de la auditoría
La auditoría se realizó con un enfoque integral y abarcó los siguientes elementos y
aspectos relacionados con el proyecto SEED:
Dispositivo de Chequeo de Entradas (ESP32 y RFID)
Se evaluó la configuración y seguridad del dispositivo utilizado para el chequeo de

entradas y salidas, incluyendo el hardware y comunicaciones relacionadas.
Servidor Apache2
Se examinó la configuración de seguridad del servidor Apache2 utilizado para el

sistema de login y visualización de las entradas detectadas por el dispositivo. Se
verificó la implementación de medidas de autenticación, autorización y cifrado, así
como la protección contra posibles ataques DDoS.
Servidor DNS (Bind9)
Se evaluó la configuración del servidor DNS utilizado en el proyecto SEED,

asegurando que esté correctamente configurado y actualizado para prevenir
posibles ataques y garantizar la integridad y disponibilidad de los servicios
relacionados.
9
Base de datos PostgreSQL
Se revisó la configuración y seguridad de la base de datos PostgreSQL utilizada en

el proyecto SEED. Se buscaron vulnerabilidades, como inyecciones SQL, y se
analizó la implementación de controles de acceso, cifrado y protección de la
integridad de los datos almacenados.
Servidor Linux en Raspberry Pi
Se examinó la configuración de seguridad del servidor Linux en la Raspberry Pi

utilizada como servidor central. Se verificó la configuración del firewall, las reglas de
filtrado, las políticas de acceso y las actualizaciones de seguridad para prevenir
posibles intrusiones o accesos no autorizados.
Procedimientos y políticas de seguridad
Se evaluó la existencia y efectividad de procedimientos y políticas de seguridad

implementadas en el proyecto SEED. Se analizaron aspectos como la gestión de
contraseñas, el manejo de incidentes en base al documento DRP y las prácticas de
respaldo y recuperación de datos.
Es importante destacar que la auditoría se centró en los elementos mencionados

anteriormente y su interacción dentro del contexto del proyecto SEED. No abarcó
otros sistemas, dispositivos o servicios no mencionados específicamente.
El alcance de la auditoría se establece con el objetivo de evaluar de manera

exhaustiva los aspectos de seguridad más relevantes del proyecto SEED, identificar
vulnerabilidades y proporcionar recomendaciones para mejorar la postura de
seguridad en relación con los sistemas y la protección de la información.
10
Metodología utilizada
La auditoría se llevará a cabo siguiendo una metodología estructurada que incluye
los siguientes pasos:
Se recopiló la información relevante sobre el proyecto SEED, incluyendo

documentación técnica, configuraciones, y políticas de seguridad.
Análisis preliminar de riesgos
Se realizó un análisis de riesgos para identificar posibles amenazas y

vulnerabilidades en el proyecto.
Ejecución de pruebas
Se llevaron a cabo pruebas de vulnerabilidades utilizando herramientas como Nikto,

Nmap, SSH-Audit, SQLMAP y OWASP. También se realizaron pruebas de
pentesting controladas con Metasploit y Nmap y ataques de fuerza bruta con Hydra
con ayuda de Crunch.
Análisis de hallazgos
Se examinaron los resultados de las pruebas, se analizaron los hallazgos y se

evaluó su impacto en la seguridad del proyecto.
Documentación de resultados
Se elaboró un informe detallado que incluye los hallazgos, recomendaciones y

soluciones propuestas.
Esta metodología garantizará una evaluación rigurosa de la seguridad en el

proyecto SEED, permitiendo identificar y abordar las vulnerabilidades de manera
adecuada.
11
Descripción del proyecto SEED
Visión general del proyecto
El proyecto SEED es un sistema de chequeo de entradas. Su objetivo principal es

proporcionar un control de acceso eficiente y seguro mediante el uso de dispositivos
RFID (Radio Frequency Identification) y tecnología de comunicación inalámbrica
ESP32.
Componentes y tecnologías utilizadas
El proyecto SEED se basa en una infraestructura tecnológica compuesta por los

siguientes componentes y tecnologías:
ESP32
Dispositivos RFID
Raspberry Pi
Apache2
BIND9
PostgreSQL
Estos componentes y tecnologías forman la base del proyecto SEED, brindando las
funcionalidades necesarias para el control de acceso y la gestión de usuarios
mediante el uso de dispositivos RFID y una infraestructura de servidor.
12
Dentro de nuestro desarrollo de información, se implementan algunas

configuraciones de red, se realizó una repetición de red wifi de otro modem el cual
procede de la red de SEED para llamarlo SmartTag Systems el cual está
configurado en un access point ubiquiti Networks, el hardware está asegurado
cubiertamente con una carcasa y cables especiales para su mejor funcionamiento
del sistema, así como área especial para su colocación del servidor y ESP32 dentro
de las aulas correspondientes.
Enumeración de activos
Raspberry Pi (servidor y dispositivo de alta de usuarios RFID)
Se utiliza una Raspberry Pi 4b que funciona como servidor, con un sistema operativo
Linux Ubuntu (Debian) dónde se encuentra el servidor web de Apache, la gestión
de base de datos con PostgreSQL, Bind9 para la configuración de DNS, Python
para desarrollo de scripts, entre otros. Además, tenemos un segundo Raspberry Pi
que sirve como registro de RFID que funciona con Python.
ESP32 y RFID
Utilizamos un microcontrolador ESP32 para el dispositivo de chequeo de entradas,

y tarjetas RFID para que funcione con el ESP32 y se puedan registrar las entradas
y dar acceso a administrativos.
13
Servidor DNS (Bind9)
Utilizamos el servicio de Bind9 para realizar una configuración de DNS que funciona
con un dominio local para el servidor web.
Servidor web (Apache2)
Utilizamos el servicio de apache2 para montar un servidor web dónde tenemos un

login hacia un panel de control que muestra las entradas que recibe el ESP32 de
manera gráfica con tablas.
Base de datos (PostgreSQL)
Se utiliza PostgreSQL para la gestión de bases de datos de toda la infraestructura,

tanto para los usuarios del servidor web, los datos de entradas de administrativos,
entre otras cosas.
Otros servicios y aplicaciones relevantes
Módulo ESP32 para las validaciones, servicios de puertos GPIO de la Raspberry pi

4b, modulo lector ESP32 físico incluye circuitos y pantallas de visualizaciones de
imagen de la Raspberry pi 4b.
14
Análisis de vulnerabilidades
Uso de herramientas; Nikto, Nmap, SSH-Audit, SQLMAP y OWASP
Durante la auditoría de seguridad del proyecto SEED, se emplearon algunas

herramientas de escaneo de vulnerabilidades para identificar posibles debilidades
en los sistemas.
Se utilizó Nikto para llevar a cabo un escaneo exhaustivo de los servicios web, como
el servidor Apache2 utilizado en el sistema de login. Nikto busca vulnerabilidades
conocidas, como archivos y directorios sin protección, versiones desactualizadas de
software y configuraciones inseguras.
Nmap se empleó para realizar un escaneo de puertos en los sistemas del proyecto
SEED. Esto ayudó a identificar los puertos abiertos y los servicios que se están
ejecutando en cada uno de ellos. Además, Nmap puede proporcionar información
sobre la versión del software que se está ejecutando, lo que ayuda a identificar
posibles vulnerabilidades asociadas.
Finalmente se utilizó SSH-Audit, para escanear vulnerabilidades SSH. SQLMAP

utiliza una base de datos actualizada de vulnerabilidades de SQL Inyeccion y realiza
pruebas activas para identificar posibles puntos de entrada no deseados.
15
Resultados de los escaneos y evaluaciones de

vulnerabilidades
Los escaneos y evaluaciones de vulnerabilidades proporcionaron información
valiosa sobre el estado de seguridad de los sistemas del proyecto SEED. Los
resultados de estos escaneos fueron los siguientes:
Escaneos a puertos del servidor con nmap:
El primer escaneo muestra los puertos abiertos y los sistemas que utilizan esos
puertos, el puerto 22 indica que está abierto y corre el servicio SSH, el puerto 53
está abierto y corre el servicio domain, que quiere decir Bind9 para el DNS, el puerto
80 igual está abierto y corre el servicio HTTP que es apache2, el puerto 5432 está
abierto y corre el servicio de PostgreSQL, el puerto 5900 está abierto y corre el
servicio VNC, el puerto 10000 está abierto y corre el servicio snet-sensor-mgmt que
quiere decir que es webmin para la administración gráfica de Bind9.
16
Este escaneo nos muestra más información acerca del servidor, nos muestra lo
mismo que el escaneo anterior, pero aquí también nos especifica las versiones de
cada servicio que corre en los puertos abiertos del servidor, y finalmente muestra el
sistema operativo que utiliza el servidor, en este caso Linux Kernel 4.15, nos
especifica que es una Raspberry Pi y nos muestra su dirección MAC.
Lista de vulnerabilidades encontradas:
SSH
17
Se utilizó el directorio de ssh-audit para realizar un análisis de vulnerabilidades en

el servicio de SSH, no se encontraron vulnerabilidades conocidas para nuestra
versión de OpenSSH 8.4p1.
De igual manera, nos recomendó eliminar algunos ciertos algoritmos:
Recomienda eliminar los siguientes algoritmos: diffie-hellman-group-exchange-

sha256, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, ecdsa-
sha2-nistp256, hmac-sha1, hmac-sha2-256, hmac-sha2-512, umac-64@openssh,
umac-128@openssh, hmac-sha1-etm@openssh
Finalmente se realizó un análisis en los archivos de configuración de SSH y parece

estar todo funcionando correctamente.
Bind9
18
Utilizamos el script dns-recursion de nmap que verifica si el servidor DNS permite

consultas recursivas desde fuentes no confiables, el puerto 53 está abierto, lo que
así que el servidor DNS permite consultas recursivas. Esto puede ser un riesgo si
el servidor DNS está expuesto a Internet, pero en este caso se utiliza de manera
local.
Aquí se utilizó el script dns-zone-transfer de nmap, el cual comprueba si el servidor

DNS permite transferencias de zona no autorizadas, en este escaneo no se obtuvo
ningún resultado específico sobre la transferencia de zona, o sea que no se pudo
realizar una transferencia de zona no autorizada.
De igual manera se analizó el archivo de configuración de Bind9 y parece estar bien

configurada.
PostgreSQL
Se analizó el archivo de configuración postgresql.conf para revisar sus

configuraciones de seguridad, el servidor solo recibe conexiones en la misma
interfaz de red y a dos IP´s específicas, si el intento de inicio proviene de una IP que
no está especificada en el archivo de configuración, PostgreSQL rechaza la
conexión, como tal, vulnerabilidades de manera manual no se encontraron, pero se
realizarán pruebas de pentesting con Metasploit por si existe alguna brecha
vulnerable.
19
Apache
No se encontraron vulnerabilidades de Cross-Site Scripting (XSS) basadas en el

análisis de contenido del sitio web. Tanto las vulnerabilidades de XSS basadas en
DOM como las vulnerabilidades de XSS almacenadas no fueron detectadas en este
caso utilizando el script vuln de nmap. También se encontró la vulnerabilidad CVE-
2011-1002 que tiene que ver con el servicio de avahi, ese servicio no está instalado
en el servidor, así que no hay de que preocuparse por eso.
20
Lo que si es que se identificaron posibles vulnerabilidades de Cross-Site Request

Forgery (CSRF) al analizar los formularios presentes en las páginas del sitio web.
Estas vulnerabilidades podrían permitir que un atacante realice acciones no
deseadas en nombre de un usuario legítimo. En particular, se encontraron dos
posibles vulnerabilidades en las siguientes rutas y acciones de formulario:
Ruta: http://192.168.17.20:80/ (formulario con id: exampleinputemail1 y acción

del formulario: /view/home/verificar2.php).
Ruta: http://192.168.17.20:80/login.php (formulario con id:

exampleinputemail1 y acción del formulario: /view/home/verificar2.php).
Se encontró una posible carpeta de administración (/admin) al analizar el sitio web,

esa carpeta admin se refiere al login.php
No se encontraron configuraciones adecuadas de seguridad en las cookies

utilizadas por el sitio web. En particular, no se ha establecido la marca "httponly"
en las cookies PHPSESSID para evitar el acceso desde scripts de cliente, lo que
podría exponer las sesiones de usuario a ciertos tipos de ataques.
Segundo análisis con Nikto
Nikto arrojó resultados similares a nmap, ambos identificaron la falta de

configuraciones de seguridad recomendadas, como el flag httponly en las cookies
y la ausencia de las cabeceras X-Frame-Options y X-Content-Type-Options.
También encontraron una página de inicio de sesión de administrador, solo que
21
Nikto también informó a cerca de la versión del servicio apache que corre en el
puerto 80 del servidor.
Análisis de vulnerabilidades web con OWASP ZAP
Encontró 7 alertas, una alerta roja, 2 alertas medianas, 3 alertas bajas y 1 alerta
informacional. La alerta roja dice que encontró vulnerabilidades en el servidor web
ante ataques Cross Site Scripting (XSS).
Severidad de las vulnerabilidades: Cada vulnerabilidad identificada se clasificó

en función de su gravedad, ayudando a determinar la urgencia y prioridad de las
medidas de mitigación.
Apache: Resolver vulnerabilidades encontradas
SSH: Eliminar algoritmos recomendados
Políticas de seguridad: Implementar las políticas de seguridad
22
Identificación y clasificación de las vulnerabilidades

encontradas
Todas las vulnerabilidades encontradas durante el análisis fueron cuidadosamente
identificadas y clasificadas. Esto implica categorizar las vulnerabilidades según su
naturaleza y gravedad, lo que facilita su comprensión y priorización para su posterior
mitigación.
Vulnerabilidades de software: En este tipo de vulnerabilidades entran las posibles

malas prácticas de configuración en los servicios del servidor, versiones
desactualizadas o fallos de programación, en este caso, el dispositivo Raspberry Pi
cuenta con buenas prácticas en los archivos de configuración, pero se recomiendan
eliminar algunas cosas, existen versiones de servicios desactualizadas y se tienen
que actualizar.
Vulnerabilidades de red: Eliminar aquellos servicios que no se estén utilizando,

porque de no ser utilizados muy posiblemente a su vez estén desactualizados, lo
cual posiblemente sea vulnerable, también se implementará un firewall ya que el
servidor no cuenta con uno.
Vulnerabilidades de autenticación y autorización: Existen contraseñas débiles,

ya que no se están poniendo en práctica las políticas de seguridad y se deben
implementar.
23
Evaluación de configuraciones
Revisión de las configuraciones de seguridad de los dispositivos y servicios
En cuanto accesos remotos mediante ssh, solo funcionan actualmente de manera

local con una máquina conectada a la red local, ya sea SmartTag Systems o SEED,
actualmente no tenemos asignada ninguna IP pública y tampoco ningún VPN
configurado en la red para conectarnos desde cualquier parte al servidor.
Existen varios puertos abiertos, como lo son el puerto 22 que utiliza el servicio SSH,
el puerto 53 que utiliza el servicio de Bind, el puerto 80 que utiliza apache2, el puerto
5432 que utiliza PostgreSQL, el puerto 5900 que utiliza el servicio VNC y el puerto
10000 que utiliza el servicio de Webmin.
Las políticas de contraseñas con la fecha de 27/06/2023 no están siendo aplicadas.
Verificación de actualizaciones y parches
Los servicios de Apache, Bind y PostgreSQL han sido sometidos a un intento de

actualización de servicios, pero resulta que ya estaban actualizadas en su versión
más reciente.
Aplicación de mejores prácticas de seguridad
Se han hecho cambios de contraseñas predeterminadas en los servicios instalados

en el servidor.
Se cerraron los puertos dónde se ejecutaban los servicios de VNC y Webmin ya que
no serán utilizados, de igual manera los servicios fueron eliminados.
Durante la evaluación de configuraciones, se analizaron los archivos de

configuración de los servicios utilizados en el servidor, los cuales parecen estar
actualizados.
24
Prueba de penetración (Pentesting)
Uso de herramientas como Metasploit, Nmap e Hydra

Se utilizó Metasploit para explotar vulnerabilidades encontradas y no encontradas,
a pesar de haber realizado un análisis de vulnerabilidades exhaustivo y no fueron
encontradas vulnerabilidades, también se realizaron pruebas de pentesting con
vulnerabilidades conocidas en los servicios existentes en el servidor.
Se utilizó nmap para realizar ataques de fuerza bruta, nmap cuenta con un script de
explotación que permite realizar un ataque de fuerza bruta mediante el protocolo
SSH con una base de datos de usuarios y contraseñas comunes.
Finalmente, Hydra para realizar ataques de fuerza bruta con la utilización de más
protocolos, usando combinaciones de contraseñas hechas en directorios por
Crunch, y en bases de datos de contraseñas y usuarios comunes.
Escenarios y pruebas realizadas

Las pruebas realizadas fueron hacia los puertos que utilizan servicios del servidor.
Apache
Se encontraron “posibles” vulnerabilidades en el análisis sobre CSRF Cross-Site
Request Forgery, se identificó la falta de configuraciones de seguridad
recomendadas, como el flag httponly en las cookies y la ausencia de las cabeceras
X-Frame-Options y X-Content-Type-Options, estas recomendaciones para
fortalecer la seguridad son directamente vulnerabilidades que se puedan explotar,
así que al final de la auditoría, esas recomendaciones serán tomadas en cuenta.
25
Explotación de vulnerabilidades conocidas para servidor Apache
Exploit vsftpd CVE-2001-1001
El resultado del exploit indica que se realizó un intento de explotar la vulnerabilidad

en el servidor FTP vsftpd, pero el servidor no respondió como se esperaba y
devolvió un error "400 Bad Request", eso significa que no existe tal vulnerabilidad.
CVE-2014-6271 (Shellshock)
Cuando se intenta realizar el exploit con

linux/http/advantech_switch_bash_env_exec) indica que el exploit ha sido
ejecutado correctamente, pero no devuelve información, se han verificado las
opciones de configuración del exploit y el RPORT, RHOSTS, LPORT y LHOST
están correctamente configurados, al igual que el payload establecido, esto indica
que lo que sucede aquí es que la vulnerabilidad no es explotable o más bien, el
servidor no es vulnerable ante CVE-2014-6271.
PostgreSQL
A pesar de haber analizado los archivos de configuración, los accesos a través del
tráfico de red y demás análisis del servicio, se realizó una prueba de pentesting con
Metasploit, con auxiliary/scanner/postgres/postgres_login, lo cual hace un
intento de inicio de sesión inyectando código en diferentes lenguajes de base de
datos, con MySQL, PostgreSQL y Oracle, un ataque que duró aproximadamente 20
minutos y no tuvo éxito.
26
SSH ataque de fuerza bruta
El ataque de fuerza bruta tuvo una duración de 9 horas y 37 minutos, eso fue lo que
tardó en encontrar la combinación correcta. Se utilizó la herramienta de Crunch para
crear un directorio con todas las combinaciones posibles en base al texto que se le
proporcionó, en este caso, se le indicó que tuviera un límite de fijo de 9 caracteres,
lo cual sabemos que actualmente son los que abarcan la contraseña del servidor.
Se le pasó como parámetro la palabra “utbb” los números del 1 al 9, y un “_”, también
se le indicó que utilizara letras mayúsculas. Con esas simples condiciones logró
crear un directorio con más de 40 millones de combinaciones, era demasiado para
el poco tiempo que al que se le podía dedicar al ataque, así que se redujo a 30 mil.
Para ejecutar el ataque de fuerza bruta se utilizó la herramienta de Hydra, al cual
se le pasó como parámetro el usuario seed con la condición -l, a través del protocolo
ssh a la IP del servidor.
SQL Inyeccion
Se realizó un ataque de SQL Inyeccion automatizado con SQLmap, comprobó la

conexión con el dominio www.seed.com.mx, realizó un escaneo de inyección SQL
en el formulario de inicio de sesión, también editó los datos POST enviados al
formulario, reemplazando los campos "usuario" y "password" por comandos SQL,
finalmente, intentó realizar pruebas de inyección SQL utilizando diferentes técnicas,
como boolean-based blind, time-based blind, stacked queries, entre otras, con
diferentes formas, con de lenguaje SQL, como MySQL, PostgreSQL y Oracle.
Analizó las respuestas recibidas y evaluó si existían indicios de una vulnerabilidad
de inyección SQL, lo cual indicó que no encontró vulnerabilidades SQL.
27
Resultados de las pruebas de penetración

Exploit vsftpd CVE-2001-1001
CVE-2014-6271
28
auxiliary/scanner/postgres/postgres_login PostgreSQL
Ataque de fuerza bruta SSH con Hydra
SQL Inyeccion
29
Verificación de autenticación y autorización
Evaluación de los mecanismos de autenticación y autorización
Nuestra empresa usa unos métodos de autenticación para verificar si se utilizan

métodos adecuados y seguros para el nivel de sensibilidad de los datos y los
sistemas. Fortalecemos de las contraseñas donde se evalúa las políticas de
contraseñas establecidas y si se requieren contraseñas robustas, incluyendo
longitud mínima, complejidad de caracteres y cambio periódico de contraseñas.
Es así como los funcionamientos de mecanismos trabajan conforme se van

desglosando en cada autentificación de cada usuario distinto.
Comprobación de los niveles de acceso y permisos asignados
Los permisos de nuestras carpetas están controlados mediante acceso no

autorizados dentro de las carpetas que están a la vista de cada entrada, por ejemplo
no se puede modificar nada de las carpetas al menos que existan los permisos
desde el documento root, (.config), el servidor está configurado para dar de manera
automática una respuesta de error de autentificación o como su caso error de
permisos o accesos denegados, (403), por la misma parte los archivos de planta
como estilos y códigos base del índex, están protegidos para su visualización aun
así estando dentro de la misma terminal.
Los niveles de acceso van desde un permiso 777 a las carpetas menos importante,
y para su restricción de direccionamiento con url están protegidas con chown -R
www-data:www-data, para su restricción permanente y estar así hasta su
modificación directamente en el archivo de configuración de apache2, es decir
nuestro servidor.
30
Evaluación de políticas de seguridad

Revisión de políticas de contraseñas, cifrado de datos y restricciones de
acceso
Las contraseñas de nuestro servicio del sistema están estrictamente aseguradas

por medio de unas políticas importantes para su creación, por ende, se sabe que
las contraseñas aparte de ser encriptadas están creadas en una orden de algoritmos
a seguir, por ejemplo, las contraseñas no pueden ser número continuos es decir
1234… etc., a la misma forma no se pueden utilizar nombres ni apellidos del mismo
usuario, en otras contraseñas está estrictamente prohibido lo siguiente.
• Longitud mínima: Establecemos una longitud mínima para las

contraseñas, generalmente de al menos 8 caracteres. Cuanto más larga sea la
contraseña, mejor.
Es por ello por lo que SEED cuenta con una gran política de seguridad para el medio
de las contraseñas y esto nos hace más cuantitativos en seguridad. ´
Por otra parte, las restricciones de entradas a nuestro sistema, como a base de
datos, modelos de archivos, documentación y estilos de la misma página, están
controlados por el personal que tiene la contraseña, aparte de que para poder
modificar cada documento se le tiene que solicitar permisos directamente a la
persona que lleva la administración de permisos dentro del servidor.
A parte las restricciones de acceso están controladas con 4 puntos importantes

entre ellos.
31
• Control de acceso basado en roles: asignamos permisos y privilegios

según las responsabilidades y funciones de los usuarios dentro de la organización.
• Autenticación y autorización: verificamos la identidad de los usuarios

y asegurar que tengan los permisos adecuados para acceder a los recursos.
• Monitoreo de acceso: registramos y supervisamos los intentos de

acceso a fin de detectar actividades sospechosas o no autorizadas.
• Eliminación de accesos innecesarios: revisamos y eliminamos los

privilegios de acceso de los usuarios que no los necesiten para realizar sus tareas.
Evaluación de la existencia de políticas y procedimientos claros para el

manejo de incidentes de seguridad
Las políticas están comprobadas y evaluadas punto por punto lo que las hace
políticas de seguridad seguras.
Los procedimientos claros desde su origen de cada incidente para garantizar una
respuesta eficiente y efectiva ante cualquier evento de seguridad que pueda ocurrir
en una organización, es por ello por lo que tenemos puntos importantes y recalcados
en las políticas de estos datos como los siguientes, son puntos que debemos tener
en alerta y así responder al instante cuando pase cualquier suceso relacionado con
un incidente.
• Definición de incidentes de seguridad, (Intentos de accesos no

autorizados, malware, pérdida o robo de dispositivos).
• Procedimiento de notificación, (seguridad de la información y aloto

rendimiento de los equipos).
• Escalamiento y toma de decisiones, (la toma de dediciones ante una

alerta de un incidente entre los miembros del equipo de seed).
32
Pruebas de denegación de servicio (DDoS)
Evaluación de la resistencia de la infraestructura y aplicaciones a ataques

DDoS
Se simuló un ataque DDoS al servidor con la herramienta slowhttptest, se realizó

un ataque dónde se enviaban 1000 conexiones al servidor simultáneamente, 1000
conexiones quizá no sean suficientes para evaluar la capacidad del servidor al
enfrentarse ataques DDoS, pero tomando en cuenta que, en este punto del
desarrollo de informe de auditoría, el servidor no tiene absolutamente ninguna
protección en cuanto a estos ataques, ni siquiera un firewall.
Se utilizó el siguiente comando: slowhttptest -c 1000 -H -g -o resultados.txt -i 10

-r 200 -t GET -u http://www.seed.com.mx
Dónde -c 1000 especifica el número de conexiones simultáneas, -H habilita el modo

Slowloris, el cual es una técnica de ataque de denegación de servicio (DoS) que se
utiliza para abrumar un servidor web con solicitudes HTTP incompletas, -g habilita
el modo "gzip" para comprimir las solicitudes, -o especifica en que archivo se
guardarán los resultados, -i 10 establece el intervalo de tiempo entre cada solicitud
en segundos, -r 200 especifica la tasa de envío de solicitudes en segundos, -t GET
indica el tipo de solicitud HTTP a enviar, y -u http://www.seed.com.mx es el dominio
objetivo al cual se le realizará el ataque.
33
Resultados de las pruebas
El ataque DDoS se ejecutó exitosamente durante 160 segundos. Durante ese

tiempo, hubo un total de 957 conexiones cerradas y 43 conexiones aún activas en
el servidor. El informe en formato HTML está en el archivo "resultados.txt.html", y
el informe en formato CSV se guardó en "resultados.txt.csv". Analizando el
archivo CSV en el segundo 0, había una conexión pendiente y ninguna conexión
cerrada, también había una conexión activa y el servicio estaba disponible para
todas las 1000 conexiones.
En el segundo 10, no había conexiones cerradas, pero 459 conexiones estaban

pendientes de establecerse y 541 conexiones estaban activas, pero el servicio ya
no estaba disponible para las 1000 conexiones.
A partir del segundo 30, no se realizaron nuevas conexiones, pero el número de

conexiones activas disminuyó gradualmente, mientras que el número de conexiones
cerradas aumentó y el servicio no estuvo disponible durante este período de tiempo.
En el segundo 142, había 126 conexiones cerradas y 874 conexiones aún activas y
el servicio estaba disponible para todas las 1000 conexiones, en el segundo 160,
se cerraron un total de 957 conexiones, y solo quedaban 43 conexiones activas. El
servicio seguía disponible para las 1000 conexiones restantes.
34
Evaluación de la configuración de firewall
Revisión de la configuración del firewall en la Raspberry Pi
Se implementó el firewall iptables al servidor para tener mayor seguridad ante

ataques DDoS, tráfico de red, escaneo de puertos, y bloqueo de IP´s cuando haya
3 equivocaciones al intentar iniciar sesión en el servidor mediante el protocolo SSH.
Verificación de reglas de filtrado adecuadas y puertos abiertos necesarios
La primera regla ACCEPT tcp -- anywhere anywhere tcp dpt:ssh permite el tráfico
TCP entrante al puerto 22 (SSH). La siguiente regla DROP tcp -- anywhere
anywhere tcp flags:FIN,SYN,RST,ACK/SYN #conn src/32 > 50 deniega el tráfico
TCP entrante que tenga la combinación de banderas FIN, SYN, RST, ACK y SYN
establecida, y que exceda las 50 conexiones por segundo desde una misma
dirección IP. La tercera regla ACCEPT all -- anywhere anywhere permite todo el
tráfico entrante, independientemente del protocolo o puerto.
Las dos últimas reglas ACCEPT tcp -- anywhere anywhere tcp dpt:ssh y ACCEPT
tcp -- anywhere anywhere tcp dpt:http permiten el tráfico TCP entrante a los
puertos 22 (SSH) y 80 (HTTP), respectivamente.
La cadena Chain OUTPUT se encarga de filtrar el tráfico saliente de nuestro

servidor, la regla ACCEPT all -- anywhere anywhere permite todo el tráfico
saliente, independientemente del protocolo o puerto.
35
Evaluación de respaldo y recuperación de datos
Verificación de los procedimientos de respaldo y recuperación de datos

Se utilizó Crontab para realizar respaldos automáticos de la base de datos, todos
los días a las 00:00 horas se ejecuta la directiva en Crontab para guardar los
respaldos comprimidos en la ruta /home/seed/respaldos, después de guardar el
respaldo se ejecuta un comando automático con rsync para enviar esos mismos
respaldos a otro servidor con la IP 192.168.17.* a la ruta /home/seed/respaldos, las
rutas se llaman exactamente igual, aunque son diferentes servidores.
Al momento de ejecutarse el rsync automático daba error al principio, ya que lo que

hace es enviar los respaldos a otro servidor, y pedía la contraseña del otro servidor,
eso era un problema ya que así no se podrían estar enviando los respaldos de una
Raspberry Pi a otra, así que se configuraron las dos Raspberry Pi para que hubiera
conexión SSH entre sí sin pedir contraseñas de inicio de sesión.
Pruebas de restauración de datos y evaluación de la efectividad de los

procesos
gunzip -c /home/seed/seed_bd_.sql.gz | psql -U postgres -h localhost -d seed_bd.
Se utiliza gunzip para descomprimir el archivo SQL, después se usa psql para
acceder a la base de datos de PostgreSQL y restaurar los datos de ese archivo.
36
Conclusiones y soluciones
Resumen de los hallazgos y resultados obtenidos
En resumen, fueron encontradas un par de vulnerabilidades para apache, una que

no es alarmante ya que es de un servicio que no existe, además se encontró la falta
de implementación de firewall, falta de implementación de cabeceras, y debilidades
en la contraseña del servidor.
Implementando soluciones
Ataques DDoS
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 --connlimit-mask 32

-j DROP
Se implementó el firewall iptables para limitar la tasa de conexiones SYN entrantes

desde la misma IP a 50 por minuto. Ya que SYN es uno de los métodos más
utilizados en ataques DDoS el cual inunda el servidor con solicitudes de conexión
SQL Inyeccion
Se implementó Modsecurity para evitar inyección de código SQL en el formulario

login, lo que se muestra en la captura son las directivas en el archivo
modsecurity.conf.
37
Apache
Habilitación de hhtpOnly y cabeceras X-Frame-Options y X-Content-Type-Options

que fueron recomendaciones del análisis de vulnerabilidades de nmap.
La alerta roja que nos dio OWASP se refiere a una posible vulnerabilidad de cross-
site scripting (XSS) en la URL del formulario de inicio de sesión. El valor del
parámetro "error" en la URL que tenemos en el código parece es una cadena que
contiene código de script y se modificó en base a la solución de código que nos
ofreció.
Finalmente, cuando se solucionó, también establecimos un token de inicio de sesión

especial para los usuarios que se les asigna en cuanto se conectan al login de
SEED, esto para evitar ataques CSRF (Cross-site Request Forgery o falsificación
de petición en sitios cruzados)
Para verificar la funcionalidad de ambos, se realizó un intento de inicio de sesión

externo con la herramienta cURL, en la cual le pasábamos la contraseña y usuario
correctos, al igual que un token válido que es del usuario Alex en la base de datos:
response=$(curl -s -i -X POST -d
"usuario=Alex&password=utbb2023&csrf_token=9d488c7c0636b802c9b62f74
ebdbbae47b96f5209185e535e1eaf6d354f0bb28"
http://www.seed.com.mx/view/home/verificar2.php)
echo "$response"
38
Los resultados fueron los siguientes:
Al final dice “Solicitud no válida” Incluye la cookie "PHPSESSID" con el atributo

"HttpOnly" lo cual fue lo que los análisis de vulnerabilidades de Nikto y nmap nos
recomendó, aquí se puede ver que fueron implementadas correctamente.
Las demás banderas son de riesgo medio, riesgo bajo, y las azules son solamente
informativas. La única bandera de riesgo medio Content Security Policy (CSP) es
para los archivos de páginas de errores y también porque las imágenes tienen todos
los permisos para los usuarios en el servidor.
39
SSH
Se implementó la herramienta Fail2ban para bloquear IP´s al tener 3 intentos

fallidos al intentar iniciar sesión mediante el protocolo SSH, los baneos duran 3
horas. Esto para mitigar ataques de fuerza bruta.
Anexos
Detalles técnicos adicionales
En este anexo, se proporcionarán detalles técnicos adicionales relacionados con el

proceso de auditoría. Estos detalles incluyen información sobre las herramientas
utilizadas, los procedimientos específicos seguidos durante la auditoría y cualquier
otro aspecto técnico relevante.
Herramientas utilizadas:
Nmap: Herramienta de escaneo de puertos utilizada para identificar los puertos

abiertos en el servidor y escaneo de vulnerabilidades en los servicios.
Nikto: Herramienta de escaneo de vulnerabilidades utilizada para identificar

posibles problemas de seguridad en el servidor web.
SQLmap: Herramienta para realizar ataques SQL Inyeccion al servidor web, y para
análisis de vulnerabilidades en el puerto 5432.
40
ssh-audit: Herramienta utilizada para auditar el servicio SSH en busca de

vulnerabilidades.
Metasploit: Framework para explotar vulnerabilidades conocidas.
Crunch: Herramienta utilizada para la creación de archivos de contraseñas con

todas las combinaciones posibles para realizar ataques de fuerza bruta.
Hydra: Herramienta utilizada para realizar ataques de fuerza bruta al servidor.
OWASP: Se implementó OWASP ZAP para analizar vulnerabilidades en todos los

archivos web.
cURL: Se utilizó la herramienta para intentar iniciar sesión desde una herramienta
externa para verificar que la bandera httponly estuviera bien configurada y para
verificar la seguridad de los tokens de los usuarios.
Slowhttptest: Herramienta utilizada para simular ataques DDoS.
Modsecurity: Herramienta utilizada para configurar directivas ante ataques SQL

Inyeccion.
iptables: Utilizado para configurar reglas de firewall y controlar el tráfico de red.
Fail2ban: Herramienta de prevención de intrusiones utilizada para proteger el

servidor contra intentos de acceso no autorizados.
Procedimiento de auditoría
Escaneo de puertos: Se realizó un escaneo de puertos utilizando la herramienta

Nmap para identificar los puertos abiertos en el servidor.
Análisis de vulnerabilidades: Se utilizó la herramienta Nikto para buscar posibles

problemas de seguridad en el servidor web, como directorios revelados o páginas
de inicio de sesión administrativas expuestas. También se utilizó nmap para buscar
vulnerabilidades en los demás servicios.
41
Configuración de iptables: Se aplicaron reglas en iptables para restringir el acceso

a determinados puertos y protocolos, finalmente se implementó una nueva regla no
vista en la captura anterior para bloquear los paquetes ICMP entrantes para evitar
que otros equipos realicen ping al servidor, todas las reglas para mejorar así la
seguridad del servidor.
Implementación de Fail2ban: Se instaló y configuró Fail2ban para detectar y

bloquear intentos de acceso no autorizados al servidor, como intentos de fuerza
bruta en SSH.
Información adicional relevante
Contexto del servidor: El servidor auditado es un servidor con la dirección IP

192.168.17.20. Se trata de un servidor con el sistema operativo Linux Ubuntu para
Raspberry Pi y con los servicios SSH y HTTP (puertos 22, 53, 80 y 5432) habilitados.
Recomendaciones adicionales
Mantener el software del servidor actualizado: Es importante mantener el

sistema operativo y todos los servicios y aplicaciones instalados en el servidor
actualizados con las últimas versiones y parches de seguridad. Esto ayuda a
corregir vulnerabilidades conocidas y garantizar un entorno más seguro.
Monitorear regularmente los registros de actividad: Realizar un seguimiento y

análisis periódico de los registros de actividad del servidor puede ayudar a identificar
patrones de comportamiento sospechosos, ataques en curso o intentos de acceso
no autorizados. Esto permite una respuesta rápida y adecuada a cualquier incidente
de seguridad.
Implementar autenticación de dos factores: La autenticación de dos factores

agrega una capa adicional de seguridad al requerir no solo una contraseña, sino
también un segundo factor de autenticación, como un código generado por una
42
aplicación en el teléfono móvil del usuario. Esto dificulta aún más el acceso no
autorizado incluso si se compromete la contraseña.
Realizar auditorías de seguridad periódicas: Es recomendable realizar auditorías

de seguridad de forma regular para evaluar y verificar la efectividad de las medidas
de seguridad implementadas, identificar posibles vulnerabilidades y tomar medidas
correctivas.
¿Qué vulnerabilidades conocidas fueron explotadas?
CVE-2001-1001 (vsftpd) Se refiere a una vulnerabilidad de desbordamiento de

búfer en el servidor FTP vsftpd. Esta vulnerabilidad permite a un atacante remoto
enviar un comando especialmente diseñado para provocar un desbordamiento de
búfer en el servidor y potencialmente ejecutar código malicioso o causar un bloqueo
del sistema.
CVE-2014-6271 (Shellshock): Esta vulnerabilidad afecta a Bash, un intérprete de

comandos ampliamente utilizado en sistemas Unix y Linux. Se explota
aprovechando una deficiencia en el manejo de variables de entorno. Al enviar una
variable de entorno manipulada a través de un CGI vulnerable en un servidor
Apache, un atacante puede ejecutar comandos arbitrarios en el sistema.
Explicación de las directivas en modsecurity.conf
SecRuleEngine On: Habilita el motor de reglas de ModSecurity.
SecRule REQUEST_METHOD "!^(?:GET|HEAD|OPTIONS)$" \: Esta regla

verifica si el método de la solicitud no es GET, HEAD o OPTIONS. Si el método no
cumple con esta condición, se activa la siguiente regla en cadena.
"chain,phase:2,t:none,deny,status:403,msg:'Forbidden method.'": Esta regla,

que es una regla en cadena, niega la solicitud y devuelve un código de estado 403
(prohibido) junto con un mensaje indicando que se ha detectado un método no
permitido.
43
SecRule REQBODY_ERROR "!@eq 0" \: Esta regla verifica si se produjo un error

al analizar el cuerpo de la solicitud. Si se encuentra un error, se registra y se niega
la solicitud con un código de estado 400 (solicitud incorrecta) y un mensaje
indicando que ha fallado el análisis del cuerpo de la solicitud.
SecRule ARGS_NAMES|ARGS|XML:/* \: Esta regla se aplica a los parámetros de

la solicitud (ARGS), los nombres de los parámetros (ARGS_NAMES) y a los
elementos XML de la solicitud. Busca patrones asociados con ataques de inyección
de SQL.
44

Informe de Auditoría SEED 2023

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe de Auditoría SEED 2023

Cargado por

Copyright:

Formatos disponibles

RESUMEN.

Informe de auditoría de ciberseguridad de la Empresa

Universidad Tecnológica de Bahía de Banderas

Por qué realizamos esta auditoría

Garantizar la protección de la información

Identificar posibles vulnerabilidades y riesgos

Mejorar la seguridad y la protección de datos

Cumplir con requisitos y estándares de seguridad

Descripción del proyecto SEED

6.1 Revisión de las configuraciones de seguridad de los dispositivos y servicios

Prueba de penetración (Pentesting)

Verificación de autenticación y autorización

Evaluación de políticas de seguridad

Pruebas de denegación de servicio (DDoS)

Evaluación de la configuración de firewall

11.1 Revisión de la configuración del firewall en la Raspberry Pi

11.2 Verificación de reglas de filtrado adecuadas y puertos abiertos necesarios

Evaluación de respaldo y recuperación de datos

La presente documentación de auditoría tiene como objetivo evaluar la seguridad y

El proyecto SEED se centra en el desarrollo de un dispositivo de chequeo de

La auditoría abarcará los componentes y servicios mencionados anteriormente, con

Es importante destacar que esta auditoría se realiza con el compromiso de

El objetivo principal de esta auditoría es evaluar la seguridad y protección de la

Los objetivos específicos de esta auditoría son:

• Identificar posibles vulnerabilidades y debilidades en las configuraciones de

Dispositivo de Chequeo de Entradas (ESP32 y RFID)

Se evaluó la configuración y seguridad del dispositivo utilizado para el chequeo de

Se examinó la configuración de seguridad del servidor Apache2 utilizado para el

Servidor DNS (Bind9)

Se evaluó la configuración del servidor DNS utilizado en el proyecto SEED,

Base de datos PostgreSQL

Se revisó la configuración y seguridad de la base de datos PostgreSQL utilizada en

Servidor Linux en Raspberry Pi

Se examinó la configuración de seguridad del servidor Linux en la Raspberry Pi

Procedimientos y políticas de seguridad

Se evaluó la existencia y efectividad de procedimientos y políticas de seguridad

Es importante destacar que la auditoría se centró en los elementos mencionados

El alcance de la auditoría se establece con el objetivo de evaluar de manera

Se recopiló la información relevante sobre el proyecto SEED, incluyendo

Análisis preliminar de riesgos

Se realizó un análisis de riesgos para identificar posibles amenazas y

Se llevaron a cabo pruebas de vulnerabilidades utilizando herramientas como Nikto,

Se examinaron los resultados de las pruebas, se analizaron los hallazgos y se

Se elaboró un informe detallado que incluye los hallazgos, recomendaciones y

Esta metodología garantizará una evaluación rigurosa de la seguridad en el

Descripción del proyecto SEED

Visión general del proyecto

El proyecto SEED es un sistema de chequeo de entradas. Su objetivo principal es

Componentes y tecnologías utilizadas

El proyecto SEED se basa en una infraestructura tecnológica compuesta por los

Dentro de nuestro desarrollo de información, se implementan algunas

Utilizamos un microcontrolador ESP32 para el dispositivo de chequeo de entradas,

Servidor DNS (Bind9)

Servidor web (Apache2)

Utilizamos el servicio de apache2 para montar un servidor web dónde tenemos un

Base de datos (PostgreSQL)

Se utiliza PostgreSQL para la gestión de bases de datos de toda la infraestructura,

Otros servicios y aplicaciones relevantes

Módulo ESP32 para las validaciones, servicios de puertos GPIO de la Raspberry pi

Uso de herramientas; Nikto, Nmap, SSH-Audit, SQLMAP y OWASP

Durante la auditoría de seguridad del proyecto SEED, se emplearon algunas

Finalmente se utilizó SSH-Audit, para escanear vulnerabilidades SSH. SQLMAP

Resultados de los escaneos y evaluaciones de