Buscando mensajes de correo de Zimbra con Kibana

Como muchos de ustedes no saben, porque aun no publico el post correspondiente, en IT Linux y ZBox usamos el stack ELK para indexar los logs producidos por las plataformas Zimbra que administramos.

ELK no es más que las siglas de Elasticsearch, Logstash y Kibana. Y es usado ampliamente para el análisis de logs. De hecho hace unos meses Zimbra hizo un concurso sobre esto.

Nosotros no participamos del concurso, pero si publicamos nuestra configuración para quien quiera usarla: https://github.com/ITLinuxCL/zimbra_logstash.

Tengo un monton de logs, ¿Cómo encuentro un mensaje?

El uso más comun de esta herramienta es para responder preguntas del tipo: ¿Puedes decirme qué pasó con el mensaje enviado por xx a yy?. O como dice el cliente: ¿Qué diablos paso con el correo que aún no llega?.

Como veremos, existen dos tipos de consultas:

  • Tenemos Amavisd funcionando
  • No tenemos Amavisd

Empecemos con la primera que es la más rápida. Todas las búsquedas las haremos en Kibana.

Buscando con Amavisd

Supongamos que nos piden un listado de todos los correos de las ultima hora de pbruna@example.com para deugenin@example.com.

Para ello ejecutamos los siguientes pasos en Kibana.

1. Buscar Message-ID en registros de Amavis

En el cuadro de búsqueda de Kibana ingresa lo siguiente:

1
tags:"amavis" AND tags:"result" AND from:"pbruna@example.com" AND to:"deugenin@example.com"

Del reultado obtenido sólo nos interesa el campo messageid

Como se ve en la imagen en nuestro caso el messageid es 200345754.22435379.1432571094009.JavaMail.zimbra@itlinux.cl

¿Por qué solo nos interesan los campos messageid?

Porque es lo único que identifica exclusivamente a un mensaje. El Message-ID es la huella digital del mensaje. Mientras que cosas como el queue_id pueden ser muchos y todos apuntar al mismo mensaje.

2. Buscar todas las colas generadas para este mensaje

Ahora que tenemos el messageid debemos buscar todas las colas que se generaron. Postfix genera una cola por cada proceso que trabaja con el mensaje. Estos procesos pueden ser Amavisd, DKIM, y otro filtro que tengas.

En el cuadro de búsqueda de Kibana ingresa lo siguiente:

1
component:"cleanup" AND messageid:"200345754.22435379.1432571094009.JavaMail.zimbra@itlinux.cl"

La cantidad de resultados pueden variar según los filtros que se apliquen al mensaje. Para este ejemplo obtuvimos 4 resultados. Por cada resultado anota el valor del campo qid, que en nuestro caso fueron:

  • 5261B2816D5,
  • 31D4F2816E1,
  • 2D79C2816DD y
  • 0CCC62816D5

El encontrar 4 queue_id diferentes para el mismo mensaje quiere decir que el mensaje fue procesado por 4 diferentes programas, sabemos que el primero de ellos es smtpd que recibe el correo y el último debería ser smtp o lmtp que entrega el correo al destinatario.

3. Obtener traza completa del mensaje

Por último tenemos que buscar todos los registros (logs) relacionados con los qids obtenidos en el paso anterior y así tendremos la traza completa del mensaje.

En el cuadro de búsqueda de Kibana ingresa lo siguiente:

1
qid:"5261B2816D5" OR qid:"31D4F2816E1" OR qid:"2D79C2816DD" OR qid:"0CCC62816D5"

Esto resultó en 21 registros, 21 líneas de un archivo de log. A continuación ofrecemos una explicación resumida de que nos cuenta cada uno de ellos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 # 1. Se establece la conexión
2015-05-25T13:24:54.053455-03:00 mta-in-01 postfix/smtpd[27693]: 0CCC62816D5: client=mailbox-02.zboxapp.com[182.168.0.152]

# 2. Se asigna el Message-ID
2015-05-25T13:24:54.058674-03:00 mta-in-01 postfix/cleanup[31598]: 0CCC62816D5: message-id=<200345754.22435379.1432571094009.JavaMail.zimbra@itlinux.cl>

# 3. Se encola
2015-05-25T13:24:54.062257-03:00 mta-in-01 postfix/qmgr[1595]: 0CCC62816D5: from=<pbruna@example.com>, size=2750, nrcpt=1 (queue active)

# 4. Lo Entregamos a DKIM
2015-05-25T13:24:54.306708-03:00 mta-in-01 postfix/smtp[31504]: 0CCC62816D5: to=<deugenin@example.com>, relay=127.0.0.1[127.0.0.1]:10026, delay=0.26, delays=0.01/0/0.01/0.24, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10030): 250 2.0.0 Ok: queued as 31D4F2816E1)

# 5. Lo sacamos de la cola
2015-05-25T13:24:54.323934-03:00 mta-in-01 postfix/qmgr[1595]: 0CCC62816D5: removed

# 6. Nos saltamos algunos pasos para mostrar que ahora DKIM lo pasa a Amavisd
2015-05-25T13:24:54.342114-03:00 mta-in-01 postfix/smtp[31468]: 31D4F2816E1: to=<deugenin@example.com>, relay=127.0.0.1[127.0.0.1]:10025, delay=0.14, delays=0.12/0/0.01/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5261B2816D5)

# 7. Amavis lo recibe y le asigna queue_id
2015-05-25T13:24:54.186406-03:00 mta-in-01 postfix/amavisd/smtpd[28298]: 2D79C2816DD: client=localhost[127.0.0.1]

# 8. Amavis lo procesa
2015-05-25T13:24:54.305138-03:00 mta-in-01 amavis[31520]: (31520-03) Passed CLEAN {RelayedInternal,Archived}, ORIGINATING/MYNETS LOCAL [192.168.0.152]:33696 <pbruna@example.com> -> <deugenin@example.com>, quarantine: deugenin-20150309@itlinux.cl.archive, pbruna-20150307@itlinux.cl.archive, Queue-ID: 0CCC62816D5, Message-ID: <200345754.22435379.1432571094009.JavaMail.zimbra@itlinux.cl>, mail_id: bStz4_w6-5Pp, Hits: -, size: 2750, queued_as: 31D4F2816E1, 239 ms

# 9. Postfix recibe nuevamente el mensaje procesado por Amavisd
2015-05-25T13:24:54.342158-03:00 mta-in-01 postfix/qmgr[1595]: 5261B2816D5: from=<pbruna@example.com>, size=3910, nrcpt=1 (queue active)

# 10. Postfix entrega el mensaje en la casilla
2015-05-25T13:24:54.453188-03:00 mta-in-01 postfix/lmtp[28300]: 5261B2816D5: to=<deugenin@example.com>, relay=mailbox-02.zboxapp.com[182.168.0.172]:7025, delay=0.12, delays=0.01/0/0/0.1, dsn=2.1.5, status=sent (250 2.1.5 Delivery OK)

# 11. Se elimina el mensaje de la cola
2015-05-25T13:24:54.453439-03:00 mta-in-01 postfix/qmgr[1595]: 5261B2816D5: removed

Wow!!!! Ese si que fue un paso por la vida de un mensaje de correo :). Para mantener el artículo lo más breve posible omitimos algunos pasos.

Buscando sin Amavisd

Como te habrás dado cuenta, toda la magia se basa en el campo messageid, y la gracia de contar con Amavisd es que guarda en un sólo registro la información de los campos: From, To y messageid, como se ve resumido en el siguiente ejemplo:

1
2
3
2015-05-25T13:24:54.... <pbruna@example.com> -> <deugenin@example.com>, ....,
Message-ID: <200345754.22435379.1432571094009.JavaMail.zimbra@itlinux.cl>...
queued_as: 31D4F2816E1, 239 ms

Sin Amavisd la cosa se hace un poco más tediosa, ya que debes hacer un mapa de todos los messageid. El plan en estos casos es el siguiente, por brevedad solo veremos para el campo From:

1. Busca los posibles qids

En el cuadro de búsqueda de Kibana ingresa lo siguiente:

1
component:"qmgr" AND from:"pbruna@example.com"

Anota todos los qids que resultaron.

2. Busca los posibles Message-ID con los qids obtenidos

En el cuadro de búsqueda de Kibana ingresa lo siguiente:

1
component:"cleanup" AND (qid:"0CCC62816D5" OR qid:"31D4F2816E1"....)

De los resultados anota los valores de los campos messageid. Anótalo una sola vez, aunque se repitan.

3. Obtener la traza

Por cada uno de los messageid resultantes, debes ejecutar los pasos 2 y 3 que vimos cuando tenemos Amavisd, es decir:

  1. Buscar todas las colas generadas para este mensaje, y
  2. Obtener traza completa del mensaje

Palabras al cierre

Este artículo resultó un poco más largo de lo esperado y gracias si aún sigues leyendo. Recuerda nuestra configuración de Logstash esta disponible para ser usada por quien quiera en: https://github.com/ITLinuxCL/zimbra_logstash.

La ayuda es siempre bienvenida, sobre todo si tiene que ver con documentación.

Saludos y hasta el próximo artículo, que será si o si sobre como instalamos ELK y lo que hemos aprendido al respecto.

Chao.

Actualizacion de Time Zone en Zimbra 8 y superiores

Para quienes vivimos en Chile y trabajamos en computación se ha convertido en un ritual anual tener que actualizar nuestros sistemas porque la fecha de cambio de horario de Verano a Invierno o vice versa no es siempre la misma. Aunque este año se tomo la brillante, y si por brillante quiero decir estúpida, desición de dejar fijo el horario de Verano.

Pero bueno este post no es sobre mis opiniones, por más acertadas que sean, si no sobre como corregir la base de datos de Zonas Horarias que viene integrada en la máquina virtual de Java que usa Zimbra.

Como ya sabrán la zona horaria de Linux se mantiene actualizada con la simple actualización del paquete tzdata, pero Java al igual que otros programas trabaja con su propia DB de Zonas Horarias. Nosotros ya contamos en nuestra Base de Coonocimientos con un artículo de como corregir la zona horaria, pero sólo aplica para versiones inferiores a Zimbra 8.

El síntoma más claro de que la Zona Horaria de Zimbra es incorrecta es que al mirar en línea el archivo /opt/zimbra/log/mailbox.log verás que existe una diferencia con la hora del Sistema Operativo.

Qué cambió?

Las nuevas versiones de Zimbra vienen con OpenJDK versión 8, y esta nueva versión cambia la forma en que se manejan las zonas horarias. En las versiones 7 de OpenJDK, toda la información de zonas horarias estaba en el directorio jre/lib/zi/, que para el caso de Zimbra sería:

1
2
3
4
5
6
 # Zimbra version 7

[root@zimbra ~]# ls /opt/zimbra/java/jre/lib/zi/
Africa   Antarctica  Atlantic   CET      EET  EST5EDT  Europe  HST     MET  MST7MDT  PST8PDT  WET
America  Asia        Australia  CST6CDT  EST  Etc      GMT     Indian  MST  Pacific  SystemV  ZoneInfoMappings
[root@zimbra ~]#

En las nuevas versiones de OpenJDK todo este directorio fue reemplazado por un sólo archivo llamado tzdb.dat:

1
2
3
4
5
 # Zimbra version 8.5

[root@zimbra8.5 ~]# ls /opt/zimbra/java/jre/lib/tzdb.dat
/opt/zimbra/java/jre/lib/tzdb.dat
[root@zimbra8.5 ~]#

Como lo actualizó si no existe una actualización de Zimbra?

Si Zimbra no ha liberado una actualización, o simplemente no quieres aplicar una actualización completa a tu plataforma de más de 10 servidores como tenemos en ZboxApp, puedes seguir el siguiente procedimiento (probado en CentOS 6 y 7):

1. Instala la última versión de OpenJDK

Que al momento de escribir este artículo era 1.8.0.45

1
2
3
4
$ yum install java-1.8.0-openjdk.x86_64
$ rpm -qa java-1.8.0-openjdk
java-1.8.0-openjdk-1.8.0.45-28.b13.el6_6.x86_64
$

2. Reemplaza el archivo tzdb.dat de Zimbra por el de OpenJDK

1
2
3
4
5
6
7
8
 # Primero un respaldo por buenas costumbres
$ cp /opt/zimbra/java/jre/lib/tzdb.dat /opt/zimbra/java/jre/lib/tzdb.dat.`date +%Y%m%d`

 # Actualizamos el archivo
$ cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.45-28.b13.el6_6.x86_64/jre/lib/tzdb.dat /opt/zimbra/java/jre/lib

 # Reiniciamos el mailboxd para que tome los cambios
$ zmmailboxdctl restart

Y eso es todo, ahora Zimbra se encuentra con la hora que corresponde.

Zimbra Logs Optimization

This is a short but valuable post. Next week we will Open Source our ELK Stack

By default when you do a Multi-Server Installation of Zimbra, one of the servers gets elected as a central log server. This server must have installed the Zimbra-Logger package to work correctly.

Later on you have to configure the local Syslog software on every other server of the platform, you do this running the /opt/zimbra/libexec/zmsyslogsetup command. What this command do is:

1. Read the value of the zimbraLogHostname variable

1
2
$ zmprov -l gacf zimbraLogHostname
zimbraLogHostname: server.example.com

2. Modify the local Syslog software

If we take as an example Rsyslog, the configuration is done on the /etc/rsyslog.conf file of your servers, which should look something like this:

1
2
3
4
5
6
7
8
local0.*                @server.example.com
local1.*                @server.example.com
auth.*                  @server.example.com
local0.*                -/var/log/zimbra.log
local1.*                -/var/log/zimbra-stats.log
auth.*                  -/var/log/zimbra.log
mail.*                @server.example.com
mail.*                -/var/log/zimbra.log

What is wrong with this?

If you have several servers as we do at ZBox, you are going to start wasting a lot network bandwidth with all this logs, and in reallity, you don’t need to send all the logs to server.example.com.

The only log you need to send to server.example.com is local1.*, because Zimbra Logger use the information of the /var/log/zimbra-stats.log file to show the status of the server in the Web Admin Console.

So you can optimize your configuration to something like this:

1
2
3
4
local1.*                @server.example.com
local0.*                -/var/log/zimbra.log
auth.*                  -/var/log/zimbra.log
mail.*                -/var/log/zimbra.log

You can improve it a bit more an reduce it to this:

1
2
3
local1.*                @server.example.com
local0.*                -/var/log/zimbra.log
auth.*                  -/var/log/zimbra.log

Because Rsyslog by default store mail.* into the maillog file, so you really don’t need mail.* -/var/log/zimbra.log.

That’s all. Next post we are going to show how we use Elasticsearch, Logstash and Kibana and from where you can get and use our setup.

Zimbra Preauth Router: 0 downtime migrations

At ZBox Mail we are faced with migrations from production Zimbra servers to Our Cloud Platform. Some times the source servers are small enough that you can bring down the service for a couple of hours, migrate all the mailboxes and start again in the new home.

But luckily for us we are migrating a lot of big platforms. For big we mean over 1,000 mailboxes and Terabytes of mail data. And One Does Not Simply migrate this in a couple of hours.

So we came up with this procedure to do a 0 downtime migration:

  1. Setup a split domain between the 2 platforms, customer and ours,
  2. The company must announce that a migration is in place, and for as long as the migration take place, only the Webmail is allowed
  3. Every day we migrate a group of N mailboxes.
  4. Repeat 3 until finish
  5. Celebrate

The exclusive use of the Webmail is paramount. This way we can use Zimbra Preauth Router an let it redirect the user to the old or new platform.

The way the Zimbra Preauth Router (ZPR) works is by replacing the standard Zimbra Login Page, and decide where the user should be redirected. The steps followed are:

  1. The user authenticate against ZPR,
  2. ZPR looks into a DB file for an entry for this user. Any user listed was migrated.
  3. If it’s a migrated user, ZPR redirects him to the new platform, if not, to the current platform.
  4. Thanks to Zimbra Preauth the user enter directly to the Webmail, without the need of another validation.

This way the users doesn’t need to learn a new URL and the migration process is mostly transparent for them.

For ZPR to works you need to configure Preauth Keys for the Domains, as explained at the Zimbra Wiki

All the information on how to install and use ZPR can be found here: https://github.com/pbruna/zimbra_preauth_router

As always, all ideas are welcome.

VPN Facil con SSH y Proxy Socks

Todos hemos necesitado conectarnos a una red remota y trabjar en los equipos internos, para esos casos generalmente usamos algún tipo de VPN, y por algún tipo me refiero a una jungla de diferentes productos, algunos de ellos sin soporte para Linux.

Pero para fortuna de aquellos que usamos Linux, todo lo que necesitamos para simular una VPN es un equipo remoto al que podamos conectarnos por SSH y estamos. El siguiente comando habilita un túnel que puedes usar como Endpoint para un Proxy Socks:

1
$ ssh -D localhost:1080 user@remote_host

Usando este túnel puedes re-enviar toda la comunicación a través de remote_host, como si fuera un Gateway. En tu equipo lo único que debes hacer es configurar el navegador web para que lo use, o también puedes hacerlo de forma global con un par de reglas de IPTABLES que vamos a dejar como ejercicio al lector.

Si usas otro Unix como Mac OS, sólo debes ir a las preferencias de red y habilitar Proxy Socks con la IP 127.0.0.1 y puerto 1080.

Configuración de listas dinámicas en Zimbra

Una de las nuevas características en Zimbra 8.x es el trabajo con listas de distribución dinámicas, la gracia de esto es que podemos crear una lista de distribución y que esta se valla “alimentando” de forma automática en la medida que nosotros creamos o eliminamos usuarios del servidor de correos, al contrario de las listas de distribución genéricas en donde nosotros tenemos que agregar o sacar un usuario manualmente para que esta se actualice.

  • Creando nuestra lista dinámica
  • Para poder trabajar con este tipo de lista, Zimbra incorpora un nuevo comando llamado cddl para trabajar con zmprov el cual nos permitirá crear la lista conectada al ldap mediante el valor que le asignemos al atributo memberURL Ej.

    1
    
    [zimbra@mail ~]$ zmprov cddl todos@example.local memberURL 'ldap:///??sub?(objectClass=zimbraAccount)' zimbraIsACLGroup FALSE
    

    Lo anterior nos crea la lista todos@example.local que es del tipo dinámica y que se conectará al ldap local de Zimbra. Ahora, si nos vamos a nuestro panel web la podremos ver con todos los usuarios de Zimbra, cuando digo todos son todos, por que aparecerán incluso los usuarios de sistema (virus, spam, gal, etc), como vemos en la imagen siguiente:

    Para evitar lo anterior nos conectamos vía web al servidor, nos vamos al apartado de las listas de distribución, buscamos y editamos nuestra lista. En la opción Propiedades cambiamos la query del memberURL dejandola así:

    1
    
    memberURL ldap:///??sub?(objectClass=zimbraAccount)(zimbraAccountStatus=active)(!(zimbraIsSystemAccount=TRUE))
    

    Y ahora veremos que aparecen solo cuentas de usuarios La query que utilizamos como conexión al Ldap la podemos modificar como nos sea mas conveniente para ir filtrando aún mas los miembros que componen cada lista. Para mas información y ejemplos podemos ver la documentación de Zimbra .

    Instalación desatendida de Zimbra

    Zimbra nos permite realizar una instalación de forma desatendida usando el archivo config.xxxx, archivo que se crea en cada instalación Zimbra y almacena la información de la configuración utilizada. Te recomiendo que guardes este archivo para que lo tengas como referencia.

    La ventaja que tiene el método que vamos a ver es que en nuestras futuras instalaciones solo deberemos ejecutar un comando similar a:

    1
    
    $ /opt/zimbra/libexec/zmsetup.pl + <NombreDelArchivo>
    

    y se realizará el proceso automáticamente.

    Pero bueno, ahora veamos esto en la práctica y como anda; en este escenario nosotros vamos a realziar una instalación del tipo Multi-Servidor, lo anterior implica que necesitaremos los siguientes roles zimbra:

    • 1 Servidor Ldap Master
    • 1 Servidor Mailbox
    • 1 Servidor MTA/Proxy

    Nota: asumimos que cada servidor se encuentra ya con los paquetes instalados según su rol install.sh -s

    Lo anterior también aplica para el orden en que tenemos que realizar la instalación y que recomienda Zimbra. Por lo tanto, el primer paso será instalar nuestro servidor Zimbra Ldap Master.

    Nuestro archivo de configuración para este rol fue reutilizado de una instalación anterior en donde se adicionaron los siguientes valores (líneas 2 a 9):

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    
    [root@zco-ldapmaster-1 zimbra-conf]$ cat zcsOpenLdapMasterConfig
    CREATEADMINPASS="zcs_password"
    LDAPAMAVISPASS="MyPassword"
    LDAPPOSTPASS="MyPassword"
    LDAPROOTPASS="MyPassword"
    LDAPADMINPASS="MyPassword"
    LDAPREPPASS="MyPassword"
    ldap_nginx_password="MyPassword"
    ldap_bes_searcher_password="MyPassword"
    AVDOMAIN="example.local"
    AVUSER="admin@example.local"
    CREATEADMIN="admin@example.local"
    CREATEDOMAIN="example.local"
    DOCREATEADMIN="no"
    DOCREATEDOMAIN="yes"
    EXPANDMENU="no"
    HOSTNAME="zco-ldapmaster-1.example.local"
    ....
    ....
    

    Las líneas agregadas corresponden a todas las password necesarias para la configuración de Zimbra, las pide cuando realizamos una instalación manual. Hay algunas passwords que no necesitamos configurarlas, ya que no son requeridas (ldap_bes_searcher_password) y el mismo proceso de configuración las agrega automáticamente. Lo valores anteriores son importante ya que serán utilizados en los procesos de instalación de los demás servidores y si no coinciden fallará el proceso. Por lo mismo, estos valores también tienen que estar en los otros archivos de configuración.

    Bueno, configurados los valores anteriores es cosa de instalar el Zimbra Ldap Master, para lo cual ejecutamos el comando:

    1
    
    /opt/zimbra/libexec/zmsetup.pl  -c /root/zimbra-conf/zcsOpenLdapMasterConfig
    

    En el log que escribe la instalación podemos ver en línea la información de proceso de instalación:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    
    [root@zco-ldapmaster-1 ~]# tail -f /tmp/zmsetup02262015-104418.log
    Wed Feb 25 11:45:48 2015 Operations logged to /tmp/zmsetup02252015-114548.log
    Wed Feb 25 11:45:48 2015 Installing LDAP configuration database...
    Wed Feb 25 11:45:49 2015 done.
    Wed Feb 25 11:45:49 2015 *** Running as zimbra user: /opt/zimbra/libexec/zmldapschema 2>/dev/null
    Looking for LDAP installation...succeeded
    Installing core schema...
    Installing cosine schema...
    Installing inetOrgPerson schema...
    Installing zimbra schema...
    Installing amavis schema...
    Installing dyngroup schema...
    Installing OpenDKIM schema...
    Installing PGP schema...
    Wed Feb 25 11:45:50 2015 Determining installed web applications
    Wed Feb 25 11:45:50 2015 Getting installed packages
    Wed Feb 25 11:45:51 2015 checking isEnabled zimbra-core
    Wed Feb 25 11:45:51 2015 zimbra-core not in enabled cache
    Wed Feb 25 11:45:51 2015 enabled packages
    Wed Feb 25 11:45:51 2015 Newinstall enabling all installed packages
    Wed Feb 25 11:45:51 2015 Enabling zimbra-core
    Wed Feb 25 11:45:51 2015 Enabling zimbra-ldap
    Wed Feb 25 11:45:52 2015 Setting defaults...
    Wed Feb 25 11:45:52 2015 Setting local config zimbra_java_home to /opt/zimbra/java
    Wed Feb 25 11:45:52 2015 *** Running as zimbra user: /opt/zimbra/bin/zmlocalconfig -f -e zimbra_java_home='/opt/zimbra/java' 2> /dev/null
    

    Terminado todo el proceso anterior, podemos chequear que el proceso zimbra este operativo:

    1
    2
    3
    4
    5
    6
    
    [zimbra@zco-ldapmaster-1 ~]$ zmcontrol status
    Host zco-ldapmaster-1.example.com
      ldap                    Running
      stats                   Running
      zmconfigd               Running
    [zimbra@zco-ldapmaster-1 ~]$
    

    Y vemos nuestros valores correctamente configurados:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    
    [zimbra@zco-ldapmaster-1 ~]$ zmlocalconfig -s |grep password
    antispam_mysql_password =
    antispam_mysql_root_password =
    client_ssl_truststore_password = ${mailboxd_truststore_password}
    ldap_amavis_password = MyPassword
    ldap_bes_searcher_password = MyPassword
    ldap_nginx_password = MyPassword
    ldap_postfix_password = MyPassword
    ldap_replication_password = MyPassword
    ldap_root_password = MyPassword
    mailboxd_keystore_base_password = zimbra
    mailboxd_truststore_password = changeit
    mysql_root_password = zimbra
    zimbra_ldap_password = MyPassword
    zimbra_mysql_password = zimbra
    zimbra_vami_password = vmware
    [zimbra@zco-ldapmaster-1 ~]$ 
    

    Una vez, finalizado la instalación anterior, se instala el servidor Zimbra Mailbox

    1
    
    /opt/zimbra/libexec/zmsetup.pl  -c /root/zimbra-conf/zcsOpenMailboxConfig
    

    Y luego el Zimbra MTA/Proxy

    1
    
    /opt/zimbra/libexec/zmsetup.pl  -c /root/zimbra-conf/zcsOpenMTAConfig
    

    Como mencionamos antiormente: Los restantes archivos de configuración (Mailbox y MTA) tambien tienen que tener los valores de password, además de los respectivos valores de configuración para cada tipo de rol. A continuación te dejamos algunos ejemplos.

    Archivo Zimbra Mailbox

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    
    [root@zco-ldapmaster-1 ~]# cat zimbra-conf/zcsOpenMailboxConfig 
    CREATEADMINPASS="zcs_password"
    LDAPAMAVISPASS="MyPassword"
    LDAPPOSTPASS="MyPassword"
    LDAPROOTPASS="MyPassword"
    LDAPADMINPASS="MyPassword"
    LDAPREPPASS="MyPassword"
    ldap_nginx_password="MyPassword"
    ldap_bes_searcher_password="MyPassword"
    AVDOMAIN="zco-mailbox-1.example.local"
    AVUSER="admin@zco-mailbox-1.example.local"
    CREATEADMIN="admin@example.local"
    CREATEDOMAIN="example.local"
    DOCREATEADMIN="yes"
    DOCREATEDOMAIN="no"
    DOTRAINSA="yes"
    ENABLEGALSYNCACCOUNTS=""
    

    Archivo Zimbra MTA/Proxy

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    
    [root@zco-ldapmaster-1 ~]# cat zimbra-conf/zcsOpenMTAConfig 
    CREATEADMINPASS="zcs_password"
    LDAPAMAVISPASS="MyPassword"
    LDAPPOSTPASS="MyPassword"
    LDAPROOTPASS="MyPassword"
    LDAPADMINPASS="MyPassword"
    LDAPREPPASS="MyPassword"
    ldap_nginx_password="MyPassword"
    ldap_bes_searcher_password="MyPassword"
    AVDOMAIN="zco-mta-1.example.local"
    AVUSER="admin@zco-mta-1.example.local"
    CREATEADMIN="admin@example.local"
    CREATEDOMAIN="example.local"
    DOCREATEADMIN="no"
    DOCREATEDOMAIN="no"
    ENABLEGALSYNCACCOUNTS=""
    

    Saludos

    ZBox Mail: Reporte de la caída del servicio de correo 09/02/2015

    A continuación se explican los eventos que resultaron en la caída de los servicios de correo el día Martes pasado, y que duró un poco más de 45 minutos. Esta caída afectó al 70% de los usuarios de ZBox Mail.

    ZBox Mail es una plataforma distribuida, es decir, existen varios servidores que cumplen funciones específicas, no uno sólo que realiza todo el trabajo. Cada servidor pertenece a uno de estos roles:

    • Mailbox, servidor donde residen los datos de las casillas de correo. El repartir las casillas en más de un servidor se mejora la velocidad de acceso y en caso de falla, no se ven afectados todos los usuarios.

    • MTA, servidor encargado de recibir y despachar los correos hacia y desde Internet. También realiza el trabajo de filtrar los correos para permitir que sólo quienes estén autorizados, puedan enviar correo usando nuestra plataforma.

    • Balanceador de Carga / Proxy, es el servidor que responde cuando los usuarios se conectan para revisar sus correos. Este servidor los redirigi al Mailbox correspondiente.

    • Base de Datos de Usuarios y Configuraciones (LDAP), aquí reside la información sobre las cuentas de correos y sus contraseñas.

    1. Lunes 09 22:00 - Incorporación de segundo servidor LDAP

    Con la intención de poder balancear las configuraciones de las cuentas de correo, incorporamos otro servidor LDAP que funcionaría como par del ya existente (Master/Master). La instalación se completó sin mayores problemas, al menos por ese día.

    2. Martes 10 10:30 - Incorporación de nuevo servidor Mailbox

    Este es un trabajo que se realiza siempre sin mayores contratiempos, y consiste en habilitar un nuevo servidor para ir alojando los nuevos usuarios de ZBox Mail o re-balanceando de los existentes en caso de que utilicen más recursos. También se finalizó sin problemas.

    3. Martes 10 12:30 - Activación de nuevo Mailbox

    Al ingresar el nuevo servidor Mailbox a la plataforma, se vació el caché de los servidores de Balanceo de Carga. El Balanceador de carga mantiene en cache RAM la ubicación de las casillas en los diferentes Mailbox, esto hace que las respuestas sean mucho más rápida al no tener que ir a preguntar cada vez a cada servidor Mailbox.

    4. Martes 10 12:40 - Problema de validación de usuarios

    Al vaciarse el caché se hizo manifiesto un problema con el trabajo realizado en el paso 1, el día Lunes. La incorporación del nuevo servidor LDAP produjo que se perdiera la información de usuario y contraseña del 70% de los usuarios. El motivo de esto aun lo estamos revisando con Zimbra, ZBox Mail está basado en Zimbra Collaboration Suite, y contamos con su apoyo para resolver problemas de cierta gravedad o que correspondan a bugs en el software.

    Vale aclarar que los datos de las casillas, es decir los correos, citas, contactos, etc, no fueron afectados por este problema. Sólo la información usuario:contraseña.

    5. Martes 10 13:30 - Recuperación de Respaldo

    Luego de intentar por más de 30 minutos y no dar con una solución al problema de la sincronización entre los servidores LDAP, se decide apagar el nuevo servidor LDAP y recuperar la información pérdida desde nuestros respaldos. El respaldo correspondía a la noche anterior, por eso quienes cambiaron contraseña o crearon nuevos usuarios en la mañana del Martes pueden haber encontrado problemas durante los días que siguieron.

    6. Martes 10 13:45 - Servicio Re-establecido

    En este momento el 90% de los usuarios ya cuentan con acceso al correo.

    7. Martes 10 14:00 - Habilitación de Replica LDAP

    Se tomó la desición de habilitar inmediatamente un nuevo servidor LDAP que sólo funcionara como una copia en línea del existente. Esto hasta que tengamos resuelto con Zimbra el motivo de porque falló la implementación en modalidad Activo / Activo.

    Este respaldo en línea permitirá recuperar los datos en un plazo menor. Mucho menos de casi la hora que nos tomó este Martes.

    8. Jueves 12 18:00 - Falló de servidor virtualización

    Uno de nuestros servidores de virtualización falló, fallando con él algunos servidores Mailbox. Esto afectó a las cuentas de correo que viven en esos Mailboxes. La plataforma de Alta Disponibilidad actuó por si sóla y recuperó los servidores en otro servidor de Virtualización en aproximadamente 5 minutos.

    ¿Qué estamos haciendo para mejorar?

    Sabemos que es técnicamente imposible contar con una plataforma que esté operativa el 100% del tiempo, pero cada día trabajamos para acercarnos lo más posible. En este mes estamos agregando más servidores y un nuevo sitio para contar con más medidas de contingencia.

    Pero lo anterior no vale de mucho si el en caso de fallo nos demoramos mucho en resolver los problemas. Por lo que también debemos mejorar nuestros procedimientos para solucionar los problemas en menos tiempo y dar información más clara a nuestros usuarios.

    Para lograr estos objetivos realizaremos las siguientes acciones durante la próximas semanas:

    1. Sitio web de estado de la Plataforma

    Habilitaremos un nuevo sitio, externo a nosotros, en el cual podrán revisar transparentemente el estado de la plataforma y métricas de la misma.

    2. Información inmediata durante fallos

    En el mismo sitio anterior se publicará información de forma constante cuando ocurra un problema y también estará disponible en nuestra cuenta de Twitter para que puedan seguir en línea el proceso de recuperación y el estado de la plataforma.

    3. Nueva dirección de correo de Soporte

    Sabemos que la dirección de correo actual no es muy amigable, así que habilitaremos una nueva más simple, como ayuda@zboxapp.com

    4. Agenda de trabajos pública

    Gracias a ustedes estamos creciendo, y eso nos obliga a realizar trabajos en la plataforma casi todas las semanas. Por lo tanto los mantendremos informados cada vez que se planifique una operación en la plataforma.

    Desde ya le pedimos las disculpas por los contratiempos que estos cortes han probocado, también disculpas por el atraso de este informe, disculpas a nuestros clientes y también al equipo de ZBox. Tomó más tiempo de lo presupuestado el poder examinar correctamente la plataforma y estar seguro de la raíz del problema.

    Todos los puntos anteriores estarán en funcionamiento el próximo Miércoles 18 de Febrero y los informaremos por este mismo medio.

    Equipo ZBox

    www.zboxapp.com

    @ZBoxApp

    GHOST: nueva vulnerabilidad crítica de Linux

    Investigadores de la empresa de seguridad Qualys han descubierto un severo agujero de seguridad en la librería GNU C de Linux (glibc). Esta vulnerabilidad, llamada GHOST (CVE-2015-0235), permitiría a hackers tomar control remoto de cualquier sistema sin siquiera conocer usuarios o contraseñas.

    Qualys alertó inmediatamente a los distribuidores de Linux acerca del agujero de seguridad, y la mayoría ya ha publicado parches para corregir el problema. Al final de este artículo entregamos un listado con todos los enlaces de descarga.

    Este agujero existe en cualquier sistema Linux que fue construido con glibc-2.2, la cual fue liberada en Noviembre 10 del año 2000. Qualys también identifico que el bug ya fue resuelto con un parche que se aplicó entre las versiones glibc-2.17 y glibc-2.18, liberadas el 21 de Mayo de 2013.

    De todas formas, esta corrección no fue clasificada como un problema de seguridad, y como resultado, muchas distribuciones de nivel empresarial no la aplicaron. Algunos sistemas Linux que están vulnerables incluyen: Debian 7 (Wheezy), RHEL 5, 6, and 7, CentOS 6 and 7 and Ubuntu 12.04. Además de Red Hat, Debian ya reparó su distribución principal y Ubuntu a parchado el bug para 12.04 and the older 10.04.

    La vulnerabilidad se gatilla al explotar la función gethostbyname de glibc. Esta función se usa en todo tipo de interacción con redes en los sistemas Linux, ya sea utilizando el archivo /etc/hosts o resolviendo nombres a través de DNS.

    Para utilizar la vulnerabilidad, el atacante sólo tiene que producir un buffer overflow enviando un hostname inválido a alguna aplicación que realice resolución DNS. La vulnerabilidad permitirá al atacante ejecutar cualquier tipo de código o comandos con los mismos permisos del usuario que ejecuta la aplicación afectada. En resumen, una vez que el atacante utilizó la falla GHOST pueden tomar control del sistema.

    Como saber si nuestros sistemas son vulnerables

    En sistemas Red Hat o CentOS puedes utilizar la siguiente herramienta para comprobar si el sistema es vulnerable a este agujero de seguridad:

    1
    2
    3
    
    $ wget https://gist.githubusercontent.com/pbruna/16c27df9ccb333f08f10/raw/30bcfd1da9cc250bf8c9bbf91eb4645780c77129/GHOST-test.sh
    $ chmod +x GHOST-test.sh
    $ ./GHOST-test.sh
    

    Si su sistema es vulnerable debería obtener un resultado similar al siguiente:

    1
    2
    3
    
    This system is vulnerable to CVE-2015-0235 <https://access.redhat.com/security/cve/CVE-2015-0235>
    
    Please refer to 'https://access.redhat.com/articles/1332213' for more information
    

    Corrección del problema

    Si tienes algún sistema vulnerable, recomendamos que en cuanto antes apliques las correciones a tus sistemas. Debes tener en cuenta que una vez aplicada la corrección es necesario re-iniciar el servidor para que tome efecto.

    Para aplicar las actualizaciones se recomienda utilizar el administrador de paquetes de cada distribución, por ejemplo:

    1
    2
    3
    4
    5
    6
    7
    8
    
     # Para Red Hat o CentOS
     $ yum install glibc -y
    
     # Para Ubuntu o Debian
     $ apt-get install libc6 libgcc1 -y
    
     # En ambos casos es necesario re-iniciar
     $ reboot
    

    A continuación dejamos el listado de los parches liberados por las diferentes distribuciones:

    Ubuntu Lucid Lynx 10.04 LTS x64

    http://launchpadlibrarian.net/102638240/libc6_2.15-0ubuntu10_amd64.deb http://launchpadlibrarian.net/195506965/libc-bin_2.15-0ubuntu10.10_amd64.deb http://launchpadlibrarian.net/102638240/libc6_2.15-0ubuntu10_amd64.deb http://launchpadlibrarian.net/102057143/libgcc1_4.6.3-1ubuntu5_amd64.deb http://launchpadlibrarian.net/187931405/tzdata_2014i-0ubuntu0.12.04_all.deb

    Ubuntu Lucid Lynx 10.04 LTS x32

    http://launchpadlibrarian.net/195520980/libc6_2.11.1-0ubuntu7.20_i386.deb http://launchpadlibrarian.net/195520980/libc6_2.11.1-0ubuntu7.20_i386.deb http://launchpadlibrarian.net/43553544/debconf_1.5.28ubuntu4_all.deb http://launchpadlibrarian.net/40588211/findutils_4.4.2-1ubuntu1_i386.deb http://launchpadlibrarian.net/195520986/libc-bin_2.11.1-0ubuntu7.20_i386.deb http://launchpadlibrarian.net/96023674/libgcc1_4.4.3-4ubuntu5.1_i386.deb http://launchpadlibrarian.net/187931399/tzdata_2014i-0ubuntu0.10.04_all.deb

    Ubuntu Precise Pangolin 12.04 LTS x64

    http://launchpadlibrarian.net/195506798/libc6_2.11.1-0ubuntu7.20_amd64.deb http://launchpadlibrarian.net/43553544/debconf_1.5.28ubuntu4_all.deb http://launchpadlibrarian.net/40588199/findutils_4.4.2-1ubuntu1_amd64.deb http://launchpadlibrarian.net/195506802/libc-bin_2.11.1-0ubuntu7.20_amd64.deb http://launchpadlibrarian.net/96032925/libgcc1_4.4.3-4ubuntu5.1_amd64.deb http://launchpadlibrarian.net/187931399/tzdata_2014i-0ubuntu0.10.04_all.deb

    Ubuntu Precise Pangolin 12.04 LTS x32

    http://launchpadlibrarian.net/129759665/libc6_2.15-0ubuntu10.4_i386.deb http://launchpadlibrarian.net/195509227/libc-bin_2.15-0ubuntu10.10_i386.deb http://launchpadlibrarian.net/102057932/libgcc1_4.6.3-1ubuntu5_i386.deb http://launchpadlibrarian.net/187931405/tzdata_2014i-0ubuntu0.12.04_all.deb

    Red Hat 5 x86

    https://rhn.redhat.com/errata/RHSA-2015-0090.html

    Red Hat 6

    https://rhn.redhat.com/errata/RHSA-2015-0092.html#Red%20Hat%20Enterprise%20Linux%20Server%20%28v.%206%29

    Red Hat 7

    https://rhn.redhat.com/errata/RHSA-2015-0092.html#Red%20Hat%20Enterprise%20Linux%20Server%20%28v.%207%29

    CentOS 5 i386

    http://mirror.centos.org/centos/5/updates/i386/RPMS/glibc-2.5-123.el5_11.1.i386.rpm http://mirror.centos.org/centos/5/os/i386/CentOS/libgcc-4.1.2-55.el5.i386.rpm http://mirror.centos.org/centos/5/updates/i386/RPMS/glibc-common-2.5-123.el5_11.1.i386.rpm http://mirror.centos.org/centos/5/updates/i386/RPMS/tzdata-2014g-1.el5.i386.rpm

    CentOS 5 x64

    http://mirror.centos.org/centos/5/updates/x86_64/RPMS/glibc-common-2.5-123.el5_11.1.x86_64.rpm http://mirror.centos.org/centos/5/updates/x86_64/RPMS/tzdata-2014g-1.el5.x86_64.rpm http://mirror.centos.org/centos/5/os/x86_64/CentOS/glibc-common-2.5-123.x86_64.rpm http://mirror.centos.org/centos/5/os/x86_64/CentOS/libgcc-4.1.2-55.el5.x86_64.rpm

    CentOS 6 i386

    http://mirror.centos.org/centos/6/updates/i386/Packages/glibc-2.12-1.149.el6_6.4.i686.rpm http://mirror.centos.org/centos/6/os/i386/Packages/libgcc-4.4.7-11.el6.i686.rpm http://mirror.centos.org/centos/6/updates/i386/Packages/nss-softokn-freebl-3.14.3-18.el6_6.i686.rpm http://mirror.centos.org/centos/6/updates/i386/Packages/tzdata-2014h-1.el6.noarch.rpm http://mirror.centos.org/centos/6/updates/i386/Packages/glibc-common-2.12-1.149.el6_6.4.i686.rpm

    CentOS 6 x64

    http://mirror.centos.org/centos/6/updates/i386/Packages/tzdata-2014h-1.el6.noarch.rpm http://mirror.centos.org/centos/6/updates/x86_64/Packages/glibc-common-2.12-1.149.el6_6.4.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libgcc-4.4.7-11.el6.x86_64.rpm http://mirror.centos.org/centos/6/updates/x86_64/Packages/glibc-2.12-1.149.el6_6.4.x86_64.rpm

    CentOS 7 x64

    http://mirror.centos.org/centos/7/updates/x86_64/Packages/glibc-2.17-55.el7_0.1.x86_64.rpm http://mirror.centos.org/centos/7/updates/x86_64/Packages/glibc-common-2.17-55.el7_0.1.x86_64.rpm http://mirror.centos.org/centos/7/updates/x86_64/Packages/tzdata-2014e-1.el7_0.noarch.rpm http://mirror.centos.org/centos/7/updates/x86_64/Packages/libgcc-4.8.2-16.2.el7_0.x86_64.rpm

    Tutorial: Cálculo de direcciones IP

    Aunque las direcciones IPv4 disponibles ya están a punto de acabarse, sólo hay disponibles 3.432.192 de ip, igual sigue siendo importante saber calcular la cantidad de hosts disponibles en una red, que a pesar de ser una información básica que se debe manejar, se me olvidó.

    Empecemos este tutorial con los siguientes el siguiente segmento 192.168.3.0/24 red:

    • red: 192.168.3.0
    • netmask: 255.255.255.0

    ¿Cuántos hosts caben en esta red red?

    Primero quiero que observes lo siguiente y luego comenzarás a entender como se realia el cálculo.

    1
    2
    
    /32 = 11111111.11111111.11111111.11111111 = 255.255.255.255
    /24 = 11111111.11111111.11111111.00000000 = 255.255.255.0

    Donde:

    • /{CIDR} : Representa los bits activados que se usará para la red y lo restante para los hosts
    • 11111111.11111111.11101100.00000000 : Esto se le llama octetos, está dado de 4 octectos por 8 bits, lo cual multiplicado sería: 8 (bits) x 4 (octetos) = 32 bits y es lo que está soportado por IPv4.

    Para calcular la cantidad de hosts que representa /24, se restó:

    1
    
    32 - (la mascara de red o prefijo) = 32 - 24 = 8 bits de hosts

    como ejemplo para la regla general se utiliza :

    1
    
    2 ^ 8 - 2 # traducido sería: 2 elevado a 8 menos 2
    • 2: que es la realación de 0 y 1.
    • 8: bits de hosts, este se obtuvo de la resta 32 - máscara de red.
    • -2: se resta la ip de broadcast y la dirección de red.

    Entonces sería: 2 ^ 8 - 2 = 254 ip disponibles para la red con CIDR /24. que daría algo como esto:

    • 192.168.0.0 dirección de red
    • 192.168.0.1 hasta 192.168.0.254 direcciones ip disponibles
    • 192.168.0.255 dirección de broadcast

    Y para saber la máscara de esta red, es más fácil aún, sólo tienes que dejar activados los bits, de la resta de 32 - 8.

    Máscara de red:

    1
    
    11111111.11111111.11111111.00000000 = 255.255.255.0