Nada del otro mundo, pero tampoco reinventar la rueda. La documentación de pihole incluye instrucciones para habilitar DNS-over-HTTPS en un entorno en el que pihole está instalado directamente en el host: https://docs.pi-hole.net/guides/dns-over-https/

Para casos en el que pihole se ejecuta en un container la manera recomendada de usar el proxy para hacer las consultas a los servidores DNS de Cloudflare es con otro container que cumpla esta función. A continuación mis cambios con respecto a la guía de pi-hole.

Read More

Anuncios

Recientemente estuve implementando algunos métodos de validación y verificación de autenticidad de correos como SPF, DKIM y DMARC en servicios que administro. Durante la implementación me encontré con validaciones de dkim fallidas con el siguiente mensaje de opendkim:

Feb 15 03:12:52 smtp amavis[24502]: (24502-18) dkim: FAILED Author+Sender+MailFrom signature by d=domain.com, From: <account@domain.com>, a=rsa-sha256, c=relaxed/relaxed, s=3537AC8A-2420-11E9-91C1-9E0AD15FCAC0, i=@domain.com, ORIG [127.0.0.1]:56217, invalid (public key: missing p= tag)

El error indica lo siguiente entre otras cosas:

  • dkim: FAILED: La validación DKIM falló
  • ORIG [127.0.0.1]: El correo se origina localmente, es correo saliente
  • s=3537AC8A-2420-11E9-91C1-9E0AD15FCAC0: El subdominio de _domainkeys
  • invalid (public key: missing p= tag): La llave pública es inválida porque carece de la etiqueta p.

Read More

Estuve realizando troubleshooting en un FortiAP 321C y antes de ello nunca me había conectado a su CLI, para mi sorpresa un BusyBox con acceso directo al sistema a diferencia de otros productos de Fortinet en los que hay una línea de comandos reducida con herramientas propias del fabricante y diseñadas para la operación de las funciones de red del dispositivo.

busybox

Read More

Recientemente estuve habilitando SSH en unos enrutadores algo viejitos de marca CISCO para unas pruebas de laboratorio y me encontré con dos errores del lado del cliente (OpenSSH) una vez que me intentaba conectar a dispositivos que tenían habilitado el servidor SSH:

  • Dispositivos con IOS Version 15.2(4): Unable to negotiate with X.X.X.X port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
  • Dispositivos con IOS Version 12.4: Unable to negotiate with X.X.X.X port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Para este tipo de casos OpenSSH tiene opciones “Legacy” las cuales permiten habilitar tipos de cifrado, métodos de intercambio del llave o códigos de autenticación de mensaje que vienen deshabilitados por defecto por razones de seguridad (cifrados débiles hoy en día).

Para mi caso añadí a mi archivo ssh_config las siguientes reglas para los hosts en específico:

Match Host X.X.X.X #router con IOS 15.2
  Ciphers +aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
Match Host X.X.X.X #router con IOS 12.4
  KexAlgorithms +diffie-hellman-group1-sha1
  Ciphers +aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

Hoy 8 de Junio de 2018 -en medio de la crisis que afecta al país- me reportan amigos y familiares que el SSID de su router aDSL que les provee el ISP CLARO ha sido cambiado a “QUITEN LOS TRANQUES”. No se trata únicamente de los routers con la configuración por defecto, si no también en routers con SSID personalizados, passphrase cambiada e inclusive filtro de MAC activo. Read More