Una historia retro (computación)

Casi cualquier objeto puede convertirse en una historia. Cosas incluso con poco o nulo valor de cambio pueden tener un enorme valor de uso para alguien. Los que amamos ciertos objetos, aún más allá de las posibilidades de nuestro espacio en casa lo sabemos bien.
Esta es la historia de una Commodore 64.

A más o menos 30 años de su punto de mayor suceso en el mercado la conseguí por unos pocos pesos. Claro, no funcionaba y tampoco tenía fuente de alimentación. Lento trabajo y diversión de fin de semana, ayuda de amigos y un poco de cabezadurismo per jodere y la C64 está en funcionamiento otra vez.


Linus Torvalds se refería a las computadoras de la era de los 8 bits de una manera, me parece, muy acertada: bastaba que tuvieras acceso a la documentación e información para que desarrollaras conocimiento con y acerca de esas máquinas. No es casual que varios desarrolladores del kernel Linux sean aficionados fervientes del retro computing, quizá el caso más conocido sea el de John Linville.
Tampoco es casual el éxito de las Raspberry Pi. Dejen que sean populares y si los chicos se interesan de verdad seguramente las aprovechen. Cuanto más básica es una herramienta más necesitas desarrollar una habilidad con ella.
Creo que tantos años después sin duda alguna nostalgia cabe: tener una C64 en la Argentina de aquel tiempo era algo que no todos podíamos tener. Sin no me equivoco, fue algún aristócrata europeo el que dijo, la principal diferencia entre un hombre y un niño es el precio de sus juguetes.
Fue así: a fines de 2016 conseguí por unos pocos pesos esta Commodore 64, en buen estado externo pero sin funcionar

.
El bajo precio se justificaba porque la máquina no funcionaba, y además se le había perdido o destruido la fuente de alimentación original.
Con la ayuda de mi amigo Hernán y Alejandro -con los que desde la secundaria nos hicimos todos radioaficionados- hicimos el troubleshooting básico: pudimos detectar por qué la máquina no generaba señal de video. El chip MOS-8701 era el responsable.

Conseguirlo fue providencial. No creo que hoy en día se use ese integrado para alguna otra cosa supongo, así que me hipótesis es que habrá quedado en stock desde los años '90.
Reemplazado el chip había que encontrar una fuente de alimentación. La fuente de alimentación original de la C64 era su talón de Aquiles. Era una caja estanca que calentaba por los cuatro costados. Recuerdo un amigo de la primaria que la tenía sobre una alfombra. Un milagro que de jugar al Moon Patrol no hayamos prendido fuego la alfombra.

Esquemático de la fuente original

La fuente original era muy básica. Por supuesto no era switching, lo que hacía que fuera mucho menos eficaz. Pero eso era lo habitual para la época.
Quizá lo más revolucionario que tuvo la Apple II, primera computadora masiva de Apple fue que fue la primera en contar con una fuente switching. Era algo que la hacía cara, pero era revolucionario para cuando esa máquina salió al mercado.
El resto de las computadoras similares, no la tenía.
Entonces lo más fácil en el siglo XXI era armar un gabinete con una fuente switching y un transformador convencional para la salida de 9 VAC.
La fuente switching vino de algún switch de red que no sirvió más. Y el trafo, lo compré ex profeso. El gabinete también había pertenecido a alguna fuente y lo había guardado pensando usarlo alguna vez.

Agregué un fusible a los 9VAC (de 2A) ya que la switching provee bastante protección.

Y esa es la historia de esta C64. La fuente funcionando puede verse acá:


Continuar »

conky se integra cada vez mejor con KDE Plasma

Desde que usaba fluxbox como window manager en una vieja notebook Pentium III durante los primeros años 2000 siempre me gustó conky o su antecesor, torsmo.

En la mayoría de los ambientes de escritorio conky se integraba sin problemas. Con KDE lo hacía interfiriendo un poco con los widgets nativos y modificando un poco el comportamiento general del escritorio. Creo que esos días pasaron para siempre. Por lo menos ahora estoy super conforme con cómo conky se integró con Plasma.

Recientemente también conky cambió la forma en que la configuración (en general el archivo ~/.conkyrc) debe estar estructurada. La configuración que venía usando, que se puede ver en la imagen está disponible en este repo:

https://github.com/retux/conky-configs

Una breve guía sobre cómo instalarlo se puede leer en el README.

¿Cómo optimizar la configuració con Plasma?

La clave de esto la encontré por algún foro que ahora no puedo encontrar su url, pero se trata de lo siguiente:

Verán en el archivo de configuración la definición del tipo de ventana para conky es:

own_window_type = 'dock'

Bueno, esto hará la magia. Lo que debemos configurar es el comportamiento que deseamos para esa ventana, lo que en Plasma se hace de esta forma:

Fíjense que el nombre que le demos a la ventana, en este caso 'conky' es significativo. Con eso debe bastar, desde luego hay que ajustar las preferencias en la sección de texto del .conkyrc para que reflejen las características de su equipo.


Continuar »

Proyecto de fin de semana: Usar una fuente ATX como fuente para Lab con termostato (opcional)

Las fuentes ATX genéricas son relativamente económicas y tienen múltiples ventajas: ofrecen una variedad de tensiones de salida con corrientes generosas. 3,3v; 5v, 12V entre otras tensiones de salida sirven para tener una buena fuente de laboratorio con salidas estabilizadas y bien filtradas.

Ideal para probar cualquier circuito digital. A continuación sigue un proyecto muy simple: modificar una fuente ATX genérica y además con un agregado opcional: si no queremos que el cooler funcione constantemente se usa un termostato simple, que encenderá el ventilador cuando la temperatura interna sea superior a los 30° aproximadamente.

En la secundaria, el Cuba del barrio de Belgrano, uno de los primeros trabajos prácticos del taller de electrónica consistía en construir una fuente de alimentación variable de 2-30v. Se empezaba en primer año, en el taller de hojalatería, armando el gabinete de chapa rígida.
Durante un bimestre de segundo año, creo, se mandaba a bobinar el transformador, y con todos los componentes listos, la armábamos. Todavía la conservo y sigue andando muy bien.
La contra de las fuentes como aquella, básicamente es que por no ser switching son muy pesadas. El Apple II fue la primera computadora en tener una fuente switching a fines de los '70 y en aquel tiempo debía resultar muy costoso, pero en términos de "usabilidad" aquella máquina debía pesar menos de la tercera parte de sus competidoras que no usaban fuente switching.
Hoy en día es muy sencillo y relativamente económico encontrar una fuente de tensiones múltiples, con buen filtrado y estabilización: cualquier fuente ATX de PC.

Fuente ATX para Lab, con termostato (opcional)

Este fin de semana me hice de un rato para divertirme adaptando una fuente ATX. Mi idea inicial era la siguiente: precisaba una fuente de 5Vcc con por los menos 2A, para alimentar en simultáneo varias Raspberry Pi que están dando vueltas por ahí. Una de ellas tiene un disco duro que también requiere +12Vcc. Con una fuente que continuamente esté disponible también aprovecharía los 5Vcc para colgar un hub USB que sirviera de cargador para la mayoría de los celulares de la familia.
Además uno de mis TOCs es que no me gustan los coolers. Son necesarios lo sé, pero hacen ruido. Por eso pensé agregarle un termostato a esta fuente modificada. El cooler solo se encendería cuando el calor en el interior fuera superior a cierto umbral.

Para poder conectar todo fácilmente se puede usar una bornera. Yo agregué también una DIN/Canon para usar para la salida para las raspberries.

Una vez hecho eso, hay que cortar los cables y conectarlos uno a uno a la bornera y soldar en la ficha canon. El código de colores usado para identificar las tensiones en las PSU ATX puede encontrarse aquí: http://www.instructables.com/id/A-Makers-Guide-to-ATX-Power-Supplies/step2/Wire-Colors-Functions-in-the-PSU/

Si fuéramos a usar la fuente para un Lab, para probar circuitos o proyectos, con la bornera creo que estaría más que suficiente. Decidí agregar un pequeño termostato, que es un circuito muy similar al que se ve acá: http://www.craig.copperleife.com/tech/thermo/
Basado en un opercacional LM741 como transistor usé un BD140. Entro colector y emisor va a circular la corriente que impulsa el cooler, una vez que la temperatura supere la que se haya calibrado. El termostato es muy simple y con los valores usados sirve para accionarse entre los 25-35 grados centígrados.

Acá se puede ver el termostato ya montado. Hablando eléctricamente, dentro de la fuente el ambiente es muy ruidoso. Pensé que el ruido volvería loco al 741, pero por suerte se comportó de diez.

Así es como quedó una vez cerrado el gabinete.

Es un proyecto simple y creo que útil.

Pero ATENCIÓN con esta advertencia:

Las fuentes switching funcionan con tensiones muy elevadas por eso su manipulación es riesgosa. Por eso hay que tener mucha precaución incluso aunque hayamos desconectado la fuente de los 220V, porque los capacitores quedan cargados de energía por bastante tiempo. Por eso hay que tener mucho cuidado si se desarma una fuente, más si estuvo funcionando recientemente.


Continuar »

Configurar servidor LDAP con STARTTLS y SSSD

Un servidor LDAP es parte central de muchos deployments, sean en la nube o en infraestructura propia.
Aplicar los principios de security in depth, es decir procurar siempre aplicar diversos niveles de seguridad contribuye a que nuestros deployments sean más seguros. Por eso en esta entrada se describe cómo integrar un servidor LDAP usando openLDAP con STARTTLS para encriptación. Se usará además GOSA como interfaz gráfica de usuario para la configuración del directorio.
Usaremos además sssd (System Security Services Daemon) que es un approach más reciente y bastante conveniente.



Esta configuración la estoy probando con containers de LXD/LXC por eso quizá los nombres de hosts algo extraños. La ventaja es que con LXC podemos probar con containers la infra que después vamos a llevar la nube (aws, Azure, etc).
La idea centrar es usar el directorio LDAP para autenticación e identificación de usuarios, por eso, aún cuando el servidor LDAP no esté expuesto directamente a Internet vamos a configurar STARTTLS para que el tráfico entre clientes LDAP y el servidor sea encriptado. También llamada oportunistic TLS nos permite utilizar el puerto LDAP estándar (389).

En la máquina que usamos como nuestra CA interna firmaremos los certificados. Lo ideal es que nuestra CA tenga una entidad intermedia o subsidiaria que será la que efectivamente firme los certificados de nuestra organización y que no requieran sites o servicios públicos. Idealmente la máquina de la CA no debiera tener conexión a internet si nos ponemos el nivel de paranoia elevado /alto :

# cd /root/ca

# openssl genrsa -out intermediate/private/ldap02-debian.lxd.key.pem 2048

# chmod 400 intermediate/private/ldap02-debian.lxd.key.pem

2) Crear el csr:

# openssl req -config intermediate/openssl.cnf -key intermediate/private/ldap02-debian.lxd.key.pem -new -sha256 -out intermediate/csr/ldap02-debian.lxd.csr.pem

3) Create certificate:

# openssl ca -config intermediate/openssl.cnf -extensions server_cert -days 999 -notext -md sha256 -in intermediate/csr/ldap02-debian.lxd.csr.pem -out intermediate/certs/ldap02-debian.lxd.cert.pem

#mkdir -p /etc/ssl/{certs,private}

(copiar los certificados de la CA (trust chain), certificado del servidor y la private key.

cp ldap02-debian.lxd.key.pem /etc/ssl/private
chown -R root:openldap /etc/ssl/private
chmod 440 /etc/ssl/private/ldap02-debian.lxd.key.pem

cp ldap02-debian.lxd.cert.pem /etc/ssl/certs
cp ca-chain.cert.pem /etc/ssl/certs

Configurar LDAP:

Configurar /etc/ldap/ldap.conf con los parametros requeridos (BASE y URI):

BASE dc=ldap02-debian,dc=lxd
URI ldap://ldap02-debian.lxd

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never

# TLS certificates
TLS_CACERT /etc/ssl/certs/ca-chain.cert.pem

Creamos el siguiente archivo ldif para configurar nuestro certificado ssl:

vim /root/certs.ldif

dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ca-chain.cert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap02-debian.lxd.cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap02-debian.lxd.key.pem

Y lo importamos al directorio LDAP:

ldapmodify -H ldapi:/// -Y EXTERNAL -f /root/certs.ldif

(si hay algun error revisar permisos y que la ruta a los certs sea la correcta)


Probar que starttls funcione, con el parámetro -ZZ

ldapwhoami -H ldap:// -x -ZZ

Si está todo bien debemos obtener:

anonymous

Forzar usar siempre starttls (opcional pero recomendado):

Creamos el siguiente archivo ldif:

cat /root/forcetls.ldif:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1

ldapmodify -H ldapi:/// -Y EXTERNAL -f /root/forcetls.ldif

Para probar podemos hacerlo con:

ldapsearch -H ldap:// -x -b "dc=ldap02-debian,dc=lxd" -LLL dn

Si la encriptación está activada obtendremos:

Confidentiality required (13)
Additional information: TLS confidentiality required


En cambio, si con la opción -ZZ forzamos el uso de starttls:

# ldapsearch -H ldap:// -x -b "dc=ldap02-debian,dc=lxd" -LLL -ZZ dn
dn: dc=ldap02-debian,dc=lxd

dn: cn=admin,dc=ldap02-debian,dc=lxd

Con esto último nos habremos asegurado que todas las solicitudes para LDAP se encripten usando STARTTLS.

Recordar: en la instalación de los clientes LDAP se deberá configurar el archivo /etc/ldap/ldap.conf de la misma manera que se indicó arriba. Asegurándose de haber deployado el certificado de la CA o chain trust y referenciarlo a la ubicación correcta.

Instalación de GOSA

Instalar los siguientes paquetes:

# apt-get install gosa gosa-plugin-sudo gosa-plugin-sudo-schema gosa-schema

La configuración básica de GOSA se hace a través de su UI. Es bastante directa. Lo importante es configurar para que use STARTTLS caso contrario no se podrá comunicar con LDAP. Para ello, luego de haber configurado GOSA por la UI debemos agregar en /etc/gosa/gosa.conf:

<location name="default"
ldapTLS="true"
config="ou=gosa,ou=configs,ou=systems,dc=ldap02-debian,dc=lxd">
<referral URI="ldap://localhost:389/dc=ldap02-debian,dc=lxd"
adminDn="cn=admin,dc=ldap02-debian,dc=lxd"
adminPassword="topsecret" />
</location>

Luego podremos ir creando nuestra base de usuarios en LDAP vía gosa:



Configurar sssd en los clientes para que autentifiquen vía LDAP

Lo que resta es configurar sssd en los clientes para que se autentifiquen vía LDAP:

Instalar paquetes para sssd:

ii sssd 1.13.4-3 System Security Services Daemon -- metapackage
ii sssd-ad 1.13.4-3 System Security Services Daemon -- Active Directory back end
ii sssd-ad-common 1.13.4-3 System Security Services Daemon -- PAC responder
ii sssd-common 1.13.4-3 System Security Services Daemon -- common files
ii sssd-ipa 1.13.4-3 System Security Services Daemon -- IPA back end
ii sssd-krb5 1.13.4-3 System Security Services Daemon -- Kerberos back end
ii sssd-krb5-common 1.13.4-3 System Security Services Daemon -- Kerberos helpers
ii sssd-ldap 1.13.4-3 System Security Services Daemon -- LDAP back end
ii sssd-proxy 1.13.4-3 System Security Services Daemon -- proxy back end
ii sssd-tools

Y la configuración de /etc/sssd/sssd.conf:

root@host01-debian:~# cat /etc/sssd/sssd.conf
[sssd]
services = nss,pam
config_file_version = 2
domains = ldap

[domain/ldap]
ldap_schema = rfc2307bis
ldap_search_base = dc=ldap02-debian,dc=lxd
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://ldap02-debian.lxd:389
ldap_id_use_start_tls = True
cache_credentials = True
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_cacert = /etc/ssl/certs/ca-chain.cert.pem


[nss]

[pam]

[sudo]

[autofs]

[ssh]

Verificar que la ubicación de los certificados de la CA sea correcta y que además el modo para el archivo config sea 0600:

# ls -l /etc/sssd/sssd.conf
-rw------- 1 root root 435 Sep 18 23:27 /etc/sssd/sssd.conf

Por último si deseamos que los directorios home de los usuarios (configurados en ldap) se creen automáticamente debemos configurar el módulo pam adecuado:

# cat /etc/pam.d/common-session
#
# /etc/pam.d/common-session - session-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive).
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_sss.so
session optional pam_systemd.so
# Added for creating homedir (line to be added):
session required pam_mkhomedir.so
# end of pam-auth-update config

Continuar »

Hardening mailserver: configurar Postfix como smarthosts (sasl + TLS)

Como se comentaba en un post anterios sobre Kerberos, una red, hogareña pero con wi-fi es una red semi-abierta. Suponiendo que se haya usado WPA2 cuya encriptación no es trivial romper, todos aquellos con los que hayamos compartido la contraseña podrán seguir teniendo acceso a los servicios de la LAN. Por eso, no está demás configurar el servidor de correo (en este caso Postfix) con autenticación y TLS. De esa forma, ese servidor solo podrá ser "relay" de usuarios autenticados.

Un mismo principio simple acerca de la "seguridad" puede aplicarse prácticamente para cualquier cosa que haya de construise: una casa, una herramienta, un software o una serie de servicios de soft: las técnicas para hacer más seguro el objeto se aplican desde el principio o inevitablemente cuando querramos aplicarlo será demasiado tarde. Algo se habrá roto, alguien se habrá lastimado, un site web habrá sido desfigurado, la información de los clientes capturada, etc.
O la seguridad es una preocupación y ciertos principios se aplican desde el momento cero o después va a ser tarde.

Sea para un sistema de alertas o monitoración o para el envío de mail convencionales siempre es útil configurar nuestro servidor de correo dedicado (MTA). Para que un servidor de correo sea "full-blown" (que no solo entregue correo sino también que sea un receptor) es necesario tener un dominio público, registros DNS, etc. Como este servidor de ejemplo será mayoritariamente para enviar correo (alertas) vamos a configurarlo como un smarthost que en realidad le pase los mensajes a un servidor externo (gmail o cualquier otro) que será el que finalmente entregue el correo.
Supongamos el siguiente caso:

En esta configuración, los dispositivos que requieran enviar alertas o mensajes de correo en general tendrán un postfix configurado como smarthost es decir que no entregarán directamente el correo al servidor de destino sino que primero se lo pasarán al postfix instalado en la raspberry Pi, que hará las veces de "gateway". Este último a su vez será también un smarthost que dependerá de google para enviar el correo a sus destinatarios. En caso que contáramos con un dominio público y registros tipo A y MX en servidor DNS podría funcionar como servidor de correo "full-blown".

Los hosts que usen postfix tendrán en su archivo /etc/hosts una entrada para resolver el nombre del "gateway", en este caso pi1.equiscentrico.com.ar.
Un par de requisitos, que no voy a detallar acá para no extenderme demasiado es que como vamos a usar TLS precisaremos firmar los certificados ssl (con openssl) con nuestra propia CA interna. Tendremos tres archivos: la key privada, el certificado firmado por nuestra CA y por último la chain-trust, es decir el o los certificados de nuestra CA. Es chain-trust cuando la CA root delega la firma en otras CA intermedias. Esa suele ser una buena práctica cuando usamos una CA propia.
Vamos a la configuración del gateway (pi1.equiscentrico.com.ar). Donde ya están instalados los paquetes postfix, libsasl2 y sasl2-bin (en Debian y derivados tienen esos nombres):

Archivo config principal de postfix: /etc/postfix/main.cf:

Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_key_file=/etc/postfix/pi1.equiscentrico.com.ar.key.pem
smtpd_tls_cert_file=/etc/postfix/pi1.equiscentrico.com.ar.cert.pem
smtp_tls_CAfile=/etc/postfix/cacert.pem
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = pi1.equiscentrico.com.ar
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = pi1@equiscentrico.com.ar, pi1.equiscentrico.com.ar, localhost.equiscentrico.com.ar, localhost
relayhost = [smtp.gmail.com]:587
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtpd_sasl_local_domain = $myhostname'
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Principales parámetros:

mydestination = pi1@equiscentrico.com.ar, pi1.equiscentrico.com.ar, localhost.equiscentrico.com.ar, localhost
Lógicamente deberá adaptarse al nombre del host

relayhost = [smtp.gmail.com]:587
Acá especificamos que la entrega del correo se hará a través de gmail.

Con estos parámetros configuramos la autenticación de gmail:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes

En la sección TLS configuramos la ubicación del certificado, la private key y los certificados de la CA.

En la sección "smtpd" configuramos los parámetros del servidor propiamente dicho:

smtpd_sasl_local_domain = $myhostname'
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Aquí configuramos para usar autenticación sasl y especialmente con permit_sasl_authenticated le especificamos que el servidor solo aceptará mensajes de usuarios autenticados.

El archivo /etc/postfix/sasl/sasl_passwd debe mapear la cuenta de google y la contraseña, por ejemplo:

[smtp.gmail.com]:587 cachocastanha@gmail.com:SuperSecreta

Donde "cachocastanha" y "SuperSecreta" son el usuario y contraseña respectivamente.

Luego creamos el hash file y damos permisos adecuados:

# chmod 400 /etc/postfix/sasl/sasl_passwd
# postmap /etc/postfix/sasl/sasl_passwd

En el archivo de config de sasl indicamos qué backend usaremos, en este caso la base "nativa" de sasl, pero soporta muchas otras opciones.

/etc/postfix/sasl/smtpd.conf

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: plain login

Es posible que la primera vez Gmail requiera que autoricemos la nueva aplicación que está haciendo el envío.
Hecho eso podemos probar el envío desde el propio servidor:

$ echo "Test mail from postfix" | mail -s "Test Postfix" you@retux.com

Veamos la configuración de los hosts, que enviarán el correo a través del "gateway", aquí comento cada sección:

mtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters - con smtpd_use_tls=yes le indicamos que use TLS para establecer un canal seguro (ssl)
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
myhostname = desktop01.equiscentrico.com.ar
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, desktop01.retux.com.ar, localhost.retux.com.ar, localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = ipv4
# Config de mail relay a gateway Pi1
relayhost = [pi1.equiscentrico.com.ar]
# si hubiera un backup
#smtp_fallback_relay = [relaybackup.equiscentrico.com]
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_passwd
smtp_sasl_security_options =
smtp_use_tls = yes
# force to use TLS
smtp_tls_security_level = encrypt
# Estos dos parámetros son importantes cuando usamos /etc/hosts para resolución de nombres
# le indican a postfix que use el orden establecido en nsswitch.conf, de otra manera va a usar
# primero el servidor dns que tenga configurado el host.
lmtp_host_lookup = native
smtp_host_lookup = native

De forma parecida, la autenticación sasl se debe configurar en /etc/postfix/relay_passwd

pi1.equiscentrico.com.ar retux:SuperSecretisima

# chmod 400 /etc/postfix/relay_passwd
# postmap /etc/postfix/relay_passwd

Donde "retux" y "SuperSecretisima" son el user y contraseña en la base sasl.

En el servidor "gateway" (pi1.equiscentrico.com.ar) deberá haberse creado el usuario:

saslpasswd2 -c -u `postconf -h mydomain` retux

Podemos listar los usuarios:

# sasldblistusers2
retux@pi1.equiscentrico.com.ar: userPassword

Hecho esto no queda más que probar el envío de correo desde los hosts "internos". Posiblemente las primeras veces haya que revisar los logs y
corregir algo.
Podemos además para asegurarnos de que se está usando TLS y las contraseñas no son enviadas en texto plano, hacer una captura con tcpdump y analizarla, con la GUI de wireshark o como prefiramos:

Como podemos ver, se está usando TLS 1.2 lo que nos garantiza que nuestras credenciales van a viajar encriptadas.

Notas finales: Esta configuración es útil para una red pequeña. Para redes mayores usar la base de sasl resulta en demasiado overhead, porque habrá que registrar una entrada por cada usuario. Por eso usar un servidor centralizado para eso como LDAP o quizá kerberos para autenticar sería la opción más adecuada.


Troubleshooting

Podemos utilizar la navaja suiza del email, swaks:

swaks --auth --server pi1.equiscentrico.com.ar --port 25 --au retux@pi1.equiscentrico.com.ar --ap secretisima --from maildeorigen@gmail.com --to destinatario@gmail.com --h-Subject: "Testing SMTP relay" --body 'Testing Postfix SASL relay'

O también openssl/telnet:
$ openssl s_client -starttls smtp -crlf -connect pi1.equiscentrico.com.ar:25
y utilizaremos el mecanismo AUTH LOGIN

read R BLOCK
ehlo retux.equiscentrico.com.ar
250-pi1.equiscentrico.com.ar
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
AUTH LOGIN
334 VXNlcm5hbWU6
bWFzarFzQHBpMS5lcXVpbarlbnRyaWNvLmNvfoocg==
334 UGFzc3dvcmQ6
cJaFDADfx0ZXRl
235 2.7.0 Authentication successful

Nótese el "Authentication successful".

Otra herramienta útil para el troubleshooting es sasl2auth:

1) Levantar saslauthd:

$ sudo saslauthd -a sasldb -d -V

Y luego probamos:

$ testsaslauthd -f /run/saslauthd/mux -s"smtp" -r"pi1.equiscentrico.com.ar" -u"elUsuario" -p"lapasswordSecretísima"

Referencias:

https://wiki.debian.org/PostfixAndSASL https://serverfault.com/questions/1050452/postfix-sasldb-issue-solved-as-of-mar-2021 Continuar »