Lista negra de phishers con Postfix
El problema
En el lugar donde trabajo nos ocurrió que desde hace un tiempo al día de hoy recibimos muy seguido mails solicitando nombre de usuario y contraseña de nuestras casillas de correo. Desde el punto de vista del usuario, responder este tipo de mails suministrando los datos reales es peligroso porque se facilita el robo de identidad; desde la óptica del administrador del equipo se abre una puerta para realizar spam.
Como administrador de un servidor de mail, es posible aprovechar dichos correos para que las cuentas de nuestros usuarios no sean vulneradas. Por ello, comparto con ustedes la solución que encontramos con un compañero que, si bien no es el remedio definitivo para estos problemas, sí se la puede utilizar como un medio para minimizar los casos éxitosos del atacante.
La solución
La solución de la que les hablo consiste básicamente en interceptar los mails que los usuarios respondan de manera que nunca lleguen a destino. Para ello son necesarias dos cosas:
- Crear una lista con las direcciones de mail de los phishers: esto se puede hacer obteniendo el campo reply-to de los mails que se reciben solicitando información sensible. En este punto, el administrador puede incorporar cada dirección a mano o buscar la forma de automatizar el proceso.
- Interceptar los mails dirigidos a dichas direcciones: para ello, a la lista creada es necesario indicarle la cuenta a la cuál se quiere redirigir los mails. Luego hay que incorporar dicha lista en Postfix.
Manos a la obra
Crear la lista negra con direcciones y la cuenta a la cuál se redigirán:
vi /etc/postfix/blacklist dir1@example.com phishers dir2@example.com phishers
Generar, a partir de dicho archivo, la Berkeley DB que utilizará Postfix.
postmap /etc/postfix/blacklist
El comando anterior dejará como resultado un archivo con extensión .db en el mismo directorio donde se encuentra el fuente:
file /etc/postfix/blacklist.db /etc/postfix/blacklist.db: Berkeley DB (Hash, version 8, native byte-order)
Luego, indicarle a Postfix que lea dicha lista:
vi /etc/postfix/main.cf virtual_alias_maps = hash:/etc/postfix/blacklist
Ahora bien, al armar la lista redirigimos los mails que van a cada dirección de mail de un phisher a una cuenta especial llamada phishers. Esa cuenta puede ser uno de tres casos:
- Una cuenta en el sistema.
- Un alias a la cuenta del administrador.
- Una redirección a /dev/null.
De las opciones anteriores, la ventaja de la primera o la segunda es que si el administrador recibe un mail donde ve que un usuario contestó con sus datos puede ponerse en contacto con el mismo para aconsejarle cómo actuar en esa situación y así evitar que la misma se vuelva a repetir. No obstante, con una redirección a /dev/null y un análisis de los logs podría lograrse el mismo resultado de forma menos invasiva. Optaremos en este caso por la última opción y por ello agregaremos la entrada phishers a los alias de Postfix.
vi /etc/aliases phishers: /dev/null
Regenerar la base de datos de los alias.
newaliases
Finalmente es necesario reiniciar Postfix para que lea la nueva configuración por los cambios efectuados en /etc/postfix/main.cf. A partir de este momento, cada vez que se tenga una nueva dirección de correo de un phisher bastará con agregarla a la lista negra y ejecutar el comando postmap.
Gmail y las cuentas de usuarios con puntos (.)
Desde sus comienzos una de las cosas que permitió y popularizó Gmail fue el uso de los nombres de usuarios utilizando puntos. Un ejemplo muy común es encontrarse con cuentas del tipo nombre.apellido. Ahora bien, como se lee en Google Operating System, hasta el momento era necesario escribir el nombre de usuario de esa manera para poder iniciar sesión en Gmail. La gente de Gmail ha decidido modificar esto para que ya no haya necesidad de incluir el punto por lo que iniciar sesión como nombre.apellido o nombreapellido es exactamente igual.
Otra cuestión que queda aparentemente en el tintero es qué pasa si alguien en lugar de enviar un correo a nombre.apellido lo hace a nombreapellido. Pues bien, como se comenta en dicho blog (y lo he probado), el mail llega de cualquier manera a la cuenta nombre.apellido. Esta cuestión aparentemente era motivo de quejas de varios usuarios que argumentaban que a causa de la situación mencionada no les llegaban correos o bien los mismos eran entregados a otras personas.
Nuevas funcionalidades en Gmail
Google ha anunciado dos nuevas funcionalidades en su servicio de mail. La primera de ellas se trata de la posibilidad de agregar invitaciones a eventos cargados en Google Calendar. De esta manera, al momento de redactar un mail es posible enviar conjuntamente una invitación al destinatario de forma muy sencilla, haciendo click en un link que aparece al lado de la opción de adjuntar un archivo. Al hacerlo se abre una ventana como la siguiente:
Ahora bien, la segunda novedad de Gmail consiste en la incorporación de la capacidad de arrastrar y soltar elementos desde nuestra computadora hacia la ventana de redacción, logrando de esta manera adjuntar archivos al mail de forma más rápida e intuitiva. Esta nueva característica funciona solamente con los navegadores Google Chrome y Mozilla Firefox, no así con Internet Explorer. A continuación una captura:
Gmail será más rápido
En el festival SXSW en Austin, Texas, un miembro del equipo de Gmail ha reconocido, en base a varias quejas recibidas, que su servicio de mail es lento para usuarios avanzados. Lo bueno es que, como se puede leer en TechCrunch, la gente de Google está al tanto del problema e incluso están trabajando para solucionarlo, según las palabras de Jonathan Perlow.
HTTPS por defecto en Gmail
El equipo de Gmail ha decidido que a partir de ahora se utilizará HTTPS por defecto para todas sus cuentas, de manera de mejorar la seguridad para sus usuarios. Hasta el momento HTTPS existía pero no era la opción por defecto. Este cambio no perjudica a los usuarios que alguna vez configuraron que prefieren utilizar HTTP, los cuáles no notarán ningún cambio.
De mi parte no veo ninguna ventaja real que justifique utilizar HTTP, dado que si bien es lógicamente más performante su mejora en rendimiento no justifica la exposición de los datos del usuario. No obstante, que el usuario tenga la opción de elegir HTTP me parece una posibilidad razonable para no quitarle la libertad de decidir; por su parte, utilizar HTTPS por defecto también creo que es lo más atinado, puesto que el común de los usuarios no conoce la diferencia y no probablemente no lo utilizaría.
