OSTicket (2) Estructura de la BD

 1. Relación de tablas:

Estas son las tablas:

ost__search             
ost_api_key             
ost_attachment          
ost_canned_response     
ost_config              
ost_content             
ost_department          
ost_draft               
ost_email               
ost_email_account       
ost_email_template      
ost_email_template_group
ost_event               
ost_faq                 
ost_faq_category        
ost_faq_topic           
ost_file                
ost_file_chunk          
ost_filter              
ost_filter_action       
ost_filter_rule         
ost_form                
ost_form_entry          
ost_form_entry_values   
ost_form_field          
ost_group               
ost_help_topic          
ost_help_topic_form     
ost_list                
ost_list_items          
ost_lock                
ost_note                
ost_organization        
ost_organization__cdata 
ost_plugin              
ost_plugin_instance     
ost_queue               
ost_queue_column        
ost_queue_columns       
ost_queue_config        
ost_queue_export        
ost_queue_sort          
ost_queue_sorts         
ost_role                
ost_schedule            
ost_schedule_entry      
ost_sequence            
ost_session             
ost_sla                 
ost_staff               
ost_staff_dept_access   
ost_syslog              
ost_task                
ost_task__cdata         
ost_team                
ost_team_member         
ost_thread              
ost_thread_collaborator 
ost_thread_entry        
ost_thread_entry_email  
ost_thread_entry_merge  
ost_thread_event        
ost_thread_referral     
ost_ticket              
ost_ticket__cdata       
ost_ticket_priority     
ost_ticket_status       
ost_translation         
ost_user                
ost_user__cdata         
ost_user_account        
ost_user_email          

OSTicket (I) API

1. Introducción

La API de OsTicket es poco funcional ya que de momento solo permite crear tickets. 

Para utilizar la API de OsTicket hay que primeramente crear una clave

Existen proyectos para dar mas funcionalidad a la API como la de BMSVieira que está en Github y en documentación. Pero no he podido hacerlo funcionar

2. Creación de una clave para usar la API

Nos vamos a Tauler de l'administrador

Nos vamos Administració-API y le indicamos el campo Adreça IP

Y obternemos una clave para una determinada IP

3. Crear un ticket

Veamos un programa en python para crear un ticket. 

import requests

def display_response(response):
	try:
		print(response.json())
	except Exception:
		print(response.text)

def get_new_tiket_old():
	headers = {
		"X-API-Key": "XXXXXXXXXXXX",
		"Content-Type": "application/json",  # Lo que envío
    	        "Accept": "application/json"         # Lo que quiero recibir
	}
	data = {
		"name": "Ximo",
		"email": "ximodante@gmail.com",
		"subject": "2ª Prueba llamada a API de creación de tickets",
		"message": "A ver si crea el ticket por 2ª vez",
	}	
	url='http://192.168.XXX.XXX/osticket/api/http.php/tickets.json'
	response = requests.post(url, json=data, headers=headers)
	display_response(response)
	
if __name__ == "__main__":
	get_new_tiket_old()

Y crea un ticket y nos devuelve el id del ticket, en mi caso:

CAU-460357

4. Instalacion de BMSVieira API (no funciona!!!)

Vamos al git , descargamos el proyecto y descomprimimos el fichero zip.

Nos vamos a la carpeta donde se ha descomprimimdo y hacemosun scp para copiarlo al directorio /www del servidor de osticket

scp -r ./ost_wbs usuario@ip_del_servidor:/var/www/osticket

Pero no me funciona !!!!!!!

Gitlab(5): Problemas

1. Después de funcionar bien VS con gitlab durante una temporada, se produce este error:

Node.js v20.18.3

git@gitlab.municipio.es: Permission denied (publickey,password).

fatal: No s'ha pogut llegir del repositori remot.

Assegureu-vos que tingueu els permisos

d'accés correctes i que el repositori existeixi.

SOLUCIÓN: Parece ser que se ha perdido la clave ssh. Para ello, se busc el nombre del fichero de clave ssh (en mi caso es id_ed25519.ximo) y  se ejecuta:

ssh-add ~/.ssh/id_ed25519.ximo

NOTA: Cuando se crea un usuario dentro de Gitlab, se le puede crear una clave ssh para que no vuelva a pedir más la contraseña. Esta clave se guarda en la carpeta ~/.ssh

Esto sucede si en VS se ha configurado para acceder a gitlab con ssh. Para comprobar que estamos accediendo con ssh se ejecuta dentro de la carpeta principal del proyecto

git remote -v

y si el resultado comienza por origin  git@   entonces es ssh y si empieza por origin https entonces es https

INAP curso seguridad (II) Introducción al ENS

 1. Definiciones:

• Política de seguridad:
• Principios:
• Asegurar acceso
• Confidencialidad
• Integridad
• Trazabilidad
• Autenticidad
• Disponibilidad
• Conservación de datos
• Requisitos mínimos:

2. Principios básicos del ENS

• Seguridad como proceso integeral
• Gestión de la seguridad basada en riesgos
• Prevención, detección, respuesta y conservacion
• Gerstión de incidentes
• Existencia de líneas de defensa en varias capas
• Vigilancia continua
• Reevaluación periódica
• Diferenciación de responsabilidades: 
• 3 niveles: 
• Gobierno (dirección)
• Supervisión (RESEG responsable de seguridad  y DPDP delegado de protección de datos).
• Operativo (RS Responsable de sistemas, AD Administrador de seguridad y OS Operadores del sistema)
• 3 roles: Dirección , responsable de información y responsable de servicio
• Otros roles: Responsable de seguridad física, Responsable de gestión de personal, responsable de contratación y adquisición, usuarios del sistema. 
• No se puede ser responsable de sistemas y de seguridead
• La política de seguridad detallará las atribuciones de cada rol
• 4 responsables:
• Información
• Servicio
• Seguridad
• Sistema (pueden ser varias personas delegadas)

INAP curso seguridad (I) Protección de datos personales

 Créditos: https://sede.inap.gob.es/proteccion-de-datos-personales

1. Fuentes de derecho

Constitución española. Su artículo 18.4 otorga el carácter de derecho fundamental a la protección de datos de carácter personal.

Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales.

Reglamento (UE) n.º 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE

2. Responsable del tratamiento de los datos de carácter personal (RTDP)

Es la persona física o jurídica, autoridad pública, servicio u otro organismo que, solo o junto con otros, determine los fines y medios del tratamiento (RUE 2016/679)

3. Delegado de protección de datos (DPD)

El RGPD establece además la obligación de designar un delegado de protección de datos (DPD) a toda autoridad u organismo del sector público que lleve a cabo tratamiento de datos personales

4. Registro de actividades de tratamiento

Primeramente de clasifican las actividades de tratamiento, que antiguamente correspodían a ficheros. Dichas actividades pueden ser:

• Gestión tributaria y recaudatoria
• Gestión de Personal
• Servicios sociales

Para cada actividad se describen los siguientes datos:

• Nombre de la actividad
• Fecha de actualización
• Responsable de tratamiento (normalmente es el responsable del tratamiento (visto en el punto 2)
• Corresponsable: Normalmente la persona o departamento encargado de dicha actividad
• Delegado de protección de datos (normalmente es la persona del punto 3)
• Fines del tratamiento. La gestión de dicha actividad
• Base legal: Normalmente la legislación que ampara dicha actividad (reglamento de reaudación, etc)
• Catagoría de los interesados: Personas físicas, jurídicas ...
• Categoría de los datos personales: (Datos identificativosm y de contacto, datos académicos, datos fiscales,..)
• Categoría de los destinatarios:(Bases dwe convocatorias etc)
• Transferencias internacionales: (solo cuando sw precean)
• Medidas técnicas y organizativas de seguriead:Normalmente:Las medidas de seguridad corresponden a las aplicadas de acuerdo al Anexo II (Medidas de seguridad) del Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.

Ejemplo para el INAP

5. Derechos del interesado. Vías para ejercer los derechos

Los derechos de los interesados se establecen en los artículos 15 al 22 del RGPD

Para ejercer los derechos se dirigirán a:

• RTDP por vía electrónica o Red de oficinas en materia de registro (https://administracion.gob.es)
• DPD (art. 38.4 RGPD)
• AEPD (Agencia Española de protección de Datos) para reclamaciones

 

Certificados: Instalar el certificado raiz en Chrome, Mozilla, Edge y Brave

1. Windows (Resto de navegadores -Chrome, Edge, Brave ..)

1. Crear/Editar GPO

   • Abra Administración de Directivas de Grupo (gpmc.msc)

   • Vincule un GPO nuevo/existente a la OU objetivo

2. Importar certificado al almacén del sistema
   Navegue a:
   Configuración del equipo → Políticas → Configuración de Windows → Configuración de seguridad → Directivas de clave pública → Entidades de certificación raíz de confianza

   • Click derecho → Importar

   • Seleccione el archivo .cer desde una ruta de red accesible (ej: \\servidor\certificados\rootCA.cer)

3. Opciones clave de implementación

   • Almacén destino: Autoridades de Certificación Raíz de Confianza

   • Actualización automática: 90-120 minutos (default) o forzar con gpupdate /force

Verificación en Edge

• Acceda a edge://settings/privacy → Administrar certificados

• En Autoridades de certificación raíz, confirme la presencia del certificado

Notas técnicas:

• Edge usa el almacén de certificados de Windows (Cert:\LocalMachine\Root)

• Formatos compatibles: .cer, .crt, .der (evite .pem sin conversión)

• Para instalaciones masivas:

certutil -f -addstore "Root" \\network\path\rootCA.cer

Este método garantiza compatibilidad con Edge 94+ y versiones Chromium-based, sin requerir configuraciones adicionales en el navegador^[1][2][3].

⁂

1. https://learn.microsoft.com/es-es/windows-server/identity/ad-fs/deployment/distribute-certificates-to-client-computers-by-using-group-policy

2. https://techexpert.tips/es/windows-es/gpo-instalacion-de-un-certificado-raiz/

3. https://woshub.com/how-to-deploy-certificate-by-using-group-policy/

2. Mozilla Firefox en Windows

Lo mas común es crear una GPO para que acepte el certificado raiz del repositorio de Windows. Como ya se instaló antes mediante una GPO, ahora hay que hacer otra GPO para que admita los certificados del repositorio de Windows. Veamos los pasos

1. Descargar las plantillas administrativas del almacén de Firefox

• Descarga las plantillas oficiales de Mozilla: https://github.com/mozilla/policy-templates/releases
• Copia los .admx en C:\Windows\PolicyDefinitions y los .adml (de tu idioma, ej. es-ES) en C:\Windows\PolicyDefinitions\es-ES\.

OJO: Según David hay que copiar dichas plantillas ern el SYSVOL compartido del servidor!!!!

2. Ejecutar en una consola de comandos gpmc.msc

3. Ir a una unidad organizativa (OU) de prueba y con el botón derecho indicar "Crear un GPO en este dominio y vincularlo aqui .. "

4. Darle un nombre por ejemplo EDU-Arrel-Firefox y editar

5. Ir a:

• Configuración de equipo
• Directivas
• Plantillas administrativas: definiciones de equipo
• Mozilla
• Firefox
• Certificates
• Import Enterprise Roots : Habilitada

6. En los PCs de los usuarios hay que ejcutar gpupdate /force

OJO: Si entramos en Firefox a ver las entidades certificadoras raíz, NO APARECERÁ la nuestra, pues solo muestra los certificados de su base de datos y no los del repositorio de Windows aunque si hace referencia a ellos !!!

3. Corrección de Problemas

1. Verificar que en el cliente se han instalado las GPO

Ejecutar en el cliente en modo administrador gpresult /R /scope:computer 

 Y ver si se muestran las GPO aplicadas al equipo

2. Verificar que el certificado raíz esté instalado en al repositorio de windows del cliente.

En el cliente ejecutar en modo administrador:

certmgr.msc

Y vemos que se ha instalado en entidfades de certificación raiz de confianza:

Si entramos en Firefox a ver los certificados raiz instalados, NO APARECERÁ nuestro certificado raíz, pues Firefox se está nutriendo de 2 repositorios de certificados: el suyo propio y el de Wiindows. Cuando consulamos los certificados desde Firefox no aparecerá, pues aunque admite los certificados del repositorio de windows, NO LOS MUESTRA.

Si no va, no queda mas remedio que instalar manaulmente el certificado de la entidad certificadora.!!!1

NO USAR LO QUE VIENE A CONTINUACIÓN

1.1 Idea principal

Se tiene que crear el fichero "policies.json" en la carpeta de instalacioón del Mozilla Firefox: 

"C:\Program Files\Mozilla Firefox\distribution\"

que tendrá este contenido:

{
  "policies": {
    "Certificates": {
      "Install": ["C:\\ruta\\certificado\\rootCA.cer"]
    }
  }
}

Siendo "C:\\ruta\\certificado\\rootCA.cer" la ruta del retificdo raiz a instalar.

1.2 Utilizar una GPO

Lo más cómodo es utilizar una GPO. Vale la pena crear una OU de pruebas y meter un ordenador dentro.

Veamos el fichero power shell que se ejecuta como administrador de la máquina, y busca en las posibles rutas de instalación de Firefox y si lo encuentra crea este fichero para que el certificado raiz se instale en el Mozilla Firefox:

#Requires -RunAsAdministrator

# 1. Posibles rutas de instalación de firefox
$firefoxPaths = @(
    "C:\Program Files\Mozilla Firefox",
    "C:\Program Files (x86)\Mozilla Firefox"
)

# 2. Ruta del certificado a instalar
$certPath = "\\servidor\red\certificados\rootCA.pem"

# 3. Verificar ejecución como administrador
if (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
    Write-Error "Ejecutar como Administrador"
    exit 1
}

try {
    # 4. Buscar instalación existente de Firefox
    $firefoxInstallPath = $firefoxPaths | Where-Object { Test-Path $_ } | Select-Object -First 1

    if ($firefoxInstallPath) {
        $distPath = Join-Path $firefoxInstallPath "distribution"
        
        if (-Not (Test-Path $distPath)) {
            New-Item -ItemType Directory -Path $distPath | Out-Null
        }
		# 5. Contenido del fichero json para copiar el certificado al directorio de distribución
        $jsonContent = @"
{
    "policies": {
        "Certificates": {
            "Install": ["$certPath"]
        }
    }
}
"@
        # 6. Escribir el fichero json en el directorio de distribución
		#    Para que al rearrancar firefox se instale el certificado
		$jsonContent | Out-File -FilePath "$distPath\policies.json" -Encoding utf8 -Force
		
		# 7. Copiar el certificado al directorio de distribución
		Copy-Item -Path $certPath -Destination $distPath -Force

		# 8. Crear el fichero policies.json en el directorio de distribución
		#    y escribir el contenido del json en él
		$jsonContent | Set-Content -Path "$distPath\policies.json" -Force
        Write-Output "Política aplicada en: $distPath\policies.json"
    }
    else {
        Write-Warning "Firefox no está instalado en rutas estándar"
    }
}
catch {
    Write-Error "Error en la implementación: $_"
    exit 1
}

ahora guardamos el fichero como Deploy-FirefoxCert.ps1

Ahora vamos al Windows 2019 server y en el Administrador de Directivas de Grupo:

• Crear nueva GPO > Editar
• Navegar a: Configuración del equipo/Preferencias/Configuración de Windows/Tareas programadas 
• Crear tarea:
• Acción: Iniciar programa
• Programa/script: powershell.exe
• Argumentos: -ExecutionPolicy Bypass -File "\\ruta\netlogon\Deploy-FirefoxCert.ps1"
• Ejecutar con privilegios más altos: Habilitado

Vincular GPO a la OU correspondiente

Verificación post-implementación:

En cliente Windows, abrir "about:policies en Firefox" y verificar certificado en "about:certificate"

Consideraciones clave:

El certificado debe estar accesible desde todas las estaciones ([ruta de red])

Para actualizaciones de certificado, modificar el archivo rootCA.pem y forzar reimplementación GPO

Python(XXVII). Beforeware. Aplicando el ENI (II). Comprobación de las entradas de datos. FastHTML beforeware

 1. Beforeware en FastHTML

Cuando creamos una aplicacion FastHTML utilizando app = FastHTML(), podemos pasar un parámetro que es "before=Beforeware(función)" siendo "función" el nombre de una función que hemos definido para ejecutarse justo antes de ejecutar una ruta. Si la función devuelve "None", la petición sigue normalmente. Andreas Stokl lo explica muy bien.

Uno de nuestros objetivos a verificar es que el "tab_id" sea el correcto y que tengamos un usuario correcto.Para ello, sino se cumplen estos requisitos, se redirigirá a la pantalla de login.

Para ello se define una función que será la del beforeware:

#2. Beforeware function to be executed in all endpoints
def my_before_function(req, tab_id, sess):
	'''
	Beforeware function: checks that the user is authenticated
	'''
	print('Des de beforeware, la URL es:', req.url)
	# 1. Validem que haja tab_id i que l'usuari estiga en la sessió de la BD
	my_response,myerror=xmsession.validate(tab_id=tab_id, req=req)
	if (len(myerror.strip())>1):
		print ("redirecting from my_before_function " )
		return my_response

Otra cosa importante, es decirle al beforeware que regex hay que saltarse "skip"para que no haga comprobaciones en cada caso. En AnswerDotAi se puede ver mirando el comentario del código.

# To create a Beforeware object, we pass the function itself, and optionally a list of regexes to skip.
my_before_function = Beforeware(my_before_function, skip=[r'/favicon\.ico', r'/static/.*', r'.*\.css', '/login'])

Ahora hay que indicarselo a la aplicación:

app = fh.FastHTML(
	hdrs=my_headers, 
	before=my_before_function,
	secret_key=xmother.new_id(25), 
	exception_handlers=exception_handlers)

 2. Lo que se puede hacer con beforeware:

Se puede:

• Guardar para auditar en la BD, las peticiones (url, usuario, fecha y hotra, IP ...)
• Verificar si el usuario tiene permisos para acceder a dicha URL
• Detectar si hay código malicioso en la petición (inyección de SQL ...)