
Db Herramienta de Evaluación de Bases de Datos
Herramienta de Evaluación de Bases de Datos DbDat
DbDat realiza numerosas comprobaciones en una base de datos para evaluar la seguridad. Las categorías de comprobaciones realizadas son configuración, privilegios, usuarios e información. Las comprobaciones se realizan ejecutando consultas o leyendo archivos de configuración de la base de datos. El objetivo de esta herramienta es destacar los problemas que requieren atención inmediata e identificar ajustes de configuración que deben revisarse para determinar su idoneidad. Esta herramienta no está diseñada para identificar vulnerabilidades de inyección SQL en una aplicación; ya existen buenas herramientas para eso (por ejemplo, https://github.com/sqlmapproject). Además, esta herramienta no intenta determinar qué CVE pueden afectar la versión de la base de datos objetivo (pero podría hacerlo en el futuro, quizás). Más bien, esta herramienta puede ayudarle a comprender mejor el impacto potencial de un ataque de inyección SQL exitoso debido a una configuración débil o controles de acceso inadecuados. La mayoría de las comprobaciones provienen de los Benchmarks de Seguridad CIS (https://cisecurity.org) para bases de datos, ¡gracias a CIS! Los documentos de referencia se pueden encontrar aquí: https://benchmarks.cisecurity.org/downloads/browse/index.cfm?category=benchmarks.servers.database
Recomiendo encarecidamente descargar el documento de referencia para su base de datos objetivo, ya que contiene información adicional sobre las comprobaciones realizadas.
Finalmente, DbDat está diseñado para ser un marco que permita la creación fácil de nuevos plugins y comprobaciones. Las contribuciones de la comunidad de seguridad, o incluso de administradores de bases de datos, son lo que harán de esta una gran herramienta. El conjunto actual de comprobaciones no está completo, ciertamente se necesita hacer más. ¡Por favor, contribuya!
Desarrollando Nuevas Comprobaciones de Base de Datos
¡Las pull requests son muy bienvenidas! Las comprobaciones están organizadas por tipo de base de datos (por ejemplo, MySQL, Oracle, MS SQL, etc.) en la carpeta de plugins. Cada comprobación es un archivo Python que debe comenzar con check_ al inicio del nombre del archivo. Cada archivo contiene una clase con un método . Este método es la lógica principal de las comprobaciones. La forma rápida de empezar es copiar un archivo de comprobación existente y modificarlo. Sin embargo, consulte la sección Desarrollo de Plugins a continuación para más detalles.
do_checketc/dbdat.conf para cada base de datos que desee evaluar.python dbdat.py -p <nombre_del_perfil>cd al directorio de informes y ejecute python -m SimpleHTTPServer 9000 (o elija un número de puerto de su preferencia). Luego abra su navegador y navegue a http://localhost:9000.Para ver una lista de argumentos de línea de comandos adicionales, ejecute python dbdat.py -h
El informe organiza los resultados por niveles, que son ROJO, AMARILLO, NARANJA, GRIS y VERDE.
Hasta ahora, DbDat ha sido probado en Debian Linux, CentOS Linux y Windows 7 con Python 2.7
Ejecute: pip install MySQL-python
O en Debian, ejecute: apt-get install python-mysqldb
Ejecute: pip install psycopg2
Ejecute: pip install cx_Oracle
Nota: necesitará instalar las bibliotecas cliente de Oracle para que esto funcione.
Ejecute: pip install pymssql
Ejecute: pip install ibm_db o easy_install ibm_db
Nota: deberá asegurarse de que el usuario que ejecuta DbDat tenga acceso para ejecutar comandos CLP de DB2 (por ejemplo, db2 y db2level).
Ejecute: pip install pymongo
Para soportar archivos de configuración YAML de MongoDB, ejecute: pip install pyyaml
Ejecute: pip install couchdb
Dentro de la carpeta de plugins hay una carpeta para cada tipo de base de datos, y cada carpeta contiene archivos de comprobación. Esta es una estructura muy simple, pero también puede explorar la carpeta de plugins para familiarizarse https://github.com/foospidy/DbDat/tree/master/plugins
Las carpetas de base de datos contendrán:
__init.py - El archivo init tiene una declaración de importación para cada archivo de comprobación.check_ - Estos son los archivos que realizan las comprobaciones de la base de datos. El archivo y la clase definida dentro del archivo deben tener el mismo nombre.helper.py - Un archivo que contiene funciones comunes. Los archivos de comprobación pueden importar helper.py para aprovechar funciones comunes.Al agregar un nuevo archivo de comprobación, se debe agregar una declaración de importación al archivo __init__.py del directorio de plugins correspondiente. El patrón de código para las comprobaciones es bastante consistente. Revise los archivos existentes para tener una idea de cómo están estructurados. Observe la diferencia entre las comprobaciones de tipo sql y configuration_file.
Hay diferentes "tipos" de comprobaciones que se pueden definir. El tipo de comprobación está determinado por la variable TYPE y puede ser sql, configuration_file, nosql o clp. A continuación se presentan ejemplos de implementaciones para los diferentes escenarios de tipo de comprobación.
Para comprobaciones sql, la firma del método do_check debe ser: do_check(self, *results)
En este ejemplo, necesitamos la variable appuser de la clase padre que llama. El appuser debe agregarse dinámicamente a la sentencia sql, por lo que la variable self.SQL se establece en el método __init__. Además, dado que este método do_check necesita ejecutar el sql, también necesitamos el cursor DB (conexión), esto se establece en el método __init__ con self.dbcurs = parent.dbcurs.
Para comprobaciones configuration_file, la firma del método do_check debe ser: do_check(self, configuration_file)
En este ejemplo, el archivo de configuración de PostgreSQL no tiene secciones (por ejemplo, [nombre_seccion]), por lo que el módulo helper en la carpeta de PostgreSQL contiene una función que maneja esto. Consulte la función get_config_value definida en helper.py.
Para otros formatos de archivos de configuración, necesitará definir su propia lógica de análisis.
Para comprobaciones nosql, la firma del método do_check debe ser: do_check(self)
Las consultas NoSQL deben ejecutarse dentro del método do_check, por lo que el método __init__ de la clase debe implementar self.db = parent.db. Luego, la variable self.db se puede usar para ejecutar consultas NoSQL dentro del método do_check.
Para comprobaciones clp, la firma del método do_check debe ser: do_check(self, *results). Las comprobaciones clp son necesarias para bases de datos IBM DB2, de modo que se pueda ejecutar el procesador de línea de comandos db2 para obtener información sobre la base de datos. Sin embargo, este tipo de comprobación podría usarse para ejecutar cualquier comando de línea de comandos arbitrario. Todo el resultado de la línea de comandos se puede analizar a partir de la variable results pasada al método do_check. Además, deberá definir el método de clase CMD. Esta variable es una lista del comando y los argumentos relacionados.
Cada comprobación debe tener una categoría especificada usando la variable CATEGORY. La categoría es una forma de organizar las comprobaciones. Las categorías posibles son: Information, Configuration, Privilege y User. Especifique la categoría que sea más relevante para el contexto de la comprobación.
Este es un ejemplo aproximado que demuestra el patrón que debe seguir un archivo de comprobación:
# (OPCIONAL): Agregar declaraciones de importación, incluir cualquier módulo necesario para esta comprobación
import helper
# (REQUERIDO): Definir la clase, la clase debe tener el mismo nombre que su archivo.
class check_configuration_evaluate_something():
# (REQUERIDO): Agregar documentación, proporcionar información sobre esta comprobación ya que se mostrará en el informe.
"""
check_configuration_evaluate_something:
¡Aquí va una descripción!
"""
# (OPCIONAL): Agregar referencias, esto son solo comentarios en el código, agregar referencias es útil para otros.
# References:
# https://www.percona.com/blog/2012/12/28/auditing-login-attempts-in-mysql/
# https://dev.mysql.com/doc/refman/5.7/en/password-security-user.html
# (REQUERIDO): Agregar el conjunto estándar de variables
TITLE = 'Client Password'
CATEGORY = 'Configuration'
TYPE = 'configuration_file'
SQL = None
verbose = False
skip = False
result = {}
# (OPCIONAL): Agregar cualquier variable personalizada específica de esta comprobación
custom_var = 'custom_val'
# (REQUERIDO): Definir el método do_check, esta es la lógica real de la comprobación y es llamado por el programa principal.
def do_check(self, *results):
# (REQUERIDO): la lógica de comprobación va aquí, asegúrese de establecer los valores para self.result['level'] y self.result['output']
# Los resultados de la variable SQL se pueden procesar usando:
for rows in results:
for row in rows:
# (REQUERIDO):
# Siempre establezca las variables self.result['level'] y self.result['output'] antes de retornar.
if row[0] == 'bad':
self.result['level'] = 'RED'
self.result['output'] = 'Result is %s' % (row[0])
elif row[0] == 'needs review':
self.result['level'] = 'YELLOW'
self.result['output'] = 'Result is %s' % (row[0])
else:
self.result['level'] = 'GREEN'
self.result['output'] = 'Result is %s' % (row[0])
# Siempre retorne self.result
return self.result
# (REQUERIDO): como mínimo, el método __init__ debería imprimir la comprobación que se está realizando.
def __init__(self, parent):
print('Performing check: ' + self.TITLE)
# obtener valores de la clase padre que llama
self.verbose = parent.verbose