Zimbra: Una vez instalado, ¿qué hago? (Administrador) Normalmente cuando acabamos de instalar un servidor de Zimbra, nos surgen dudas, de cómo hemos de ajustar nuestro sistema a nuestras necesidades de una manera ordenada y lógica. Con esto no quiere decir que esta sea la configuración ideal, pero nos puede ayudar ajustando los parámetros a nuestras necesidades a implementar un sistema de Zimbra una vez acabada la instalación. Lo primero que necesitaremos, es saber tres datos fundamentales: Nombre FQDN del servidor se rvidor.. Por ejemplo: zimbra.ilba.cat zimbra.ilba.cat.. HELO que le asignaremos a nuestro servidor: helo.ilba.cat Los logos para hacer el branding, en caso de ser una Network Edition Una dirección de correo electrónico donde enviar los logs, reports, etc….: Ejemplo:
[email protected]
Timestamp
Ajustaremos el timestamp en 60 minutos, para ver los ultimos logins [syntax type=”php”+zmprov mcf zimbraLastLogonTimestampFrequency 60m[/syntax]
Admin Console de Zimbra Collaboration, en concreto hablamos de Home > Manage > Accounts , cuando queremos comprobar cuando fue el último Login de nuestros usuarios.
Lo normal es que el último Login no nos parezca correcto, o al menos no actualizado, ya que parece algo obsoleto, y de hecho así es, Zimbra Collaboration viene con el atributo zimbraLastLogonTimes zimbraLastLogonTimestampFrequency tampFrequency por defecto en 7d (7 días), podemos cambiarlo para que refresque con un tiempo más prudencial y que se ajuste a nuestro entorno de trabajo, por ejemplo 15 minutos, pero podemos ajustarlo por segundos, minutos, horas o días:
Admin Console de Zimbra Collaboration, en concreto hablamos de Home > Manage > Accounts , cuando queremos comprobar cuando fue el último Login de nuestros usuarios.
Lo normal es que el último Login no nos parezca correcto, o al menos no actualizado, ya que parece algo obsoleto, y de hecho así es, Zimbra Collaboration viene con el atributo zimbraLastLogonTimes zimbraLastLogonTimestampFrequency tampFrequency por defecto en 7d (7 días), podemos cambiarlo para que refresque con un tiempo más prudencial y que se ajuste a nuestro entorno de trabajo, por ejemplo 15 minutos, pero podemos ajustarlo por segundos, minutos, horas o días:
[syntax type=”php”+zmprov mcf zimbraLastLogonTimestampFrequency 15m[/syntax] 15m[/syntax]
De esta manera, si un usuario se ha logueado los pasados 30 minutos, aparecerá en nuestra Admin Console y podremos hacer un seguimiento más detallado de nuestros usuarios, así cómo detectar ataques o problemas de seguridad. Descripción completa del atributo
7d how often (nnnnn[hmsd]) the zimbraLastLogonTimestamp is updated. if set to 0, updating zimbraLastLogonTimestamp is completely disabled
Mail de bloqueo
Que nos envíe un mail cuando se bloquee una cuenta: [syntax type=”php”+zmlocalconfig -e
[email protected] -e zimbra_swatch_ipacct_threshold=10 zmlocalconfig -e zimbra_swatch_acct_threshold=15 zmlocalconfig -e zimbra_swatch_ip_threshold=20 zmlocalconfig -e zimbra_swatch_total_threshold=60 echo ‘ ‘ >> / etc/rc.localecho ‘sleep 1800’ >> /etc/rc.local echo ‘su – zimbra -C “zmauditswatchctl start ”‘ >> /etc/rc.local[/syntax] Cabe destacar que he hecho un echo del zmauditswatchctl en el rc.local, pero es más adecuado meterlo en los runlevel’s.
Cuando nuestro sistema de Zimbra, bloquea una cuenta de correo a consecuencia de equivocarse consecutivamente de password, ya sea por un ataque o por descuido.
Nuestro sistema bloquea la cuenta y no nos informa de lo sucedido hasta que nos llama el usuario final. Lo que vamos a ver, es el comando “zmauditswatch”, el cual nos informará por email, cuando se bloquea una cuenta de correo. Cabe destacar que esta funcionalidad no viene habilitada por defecto en nuestros sistema de Zimbra. Lo primero que haremos, es indicarle al sistema una dirección de correo electrónico, en la cual se enviaran los mensajes, que nos indicaran que una de nuestras cuentas de correo ha sido bloqueada y posteriormente, arrancaremos el dominio. [syntax type=”php”+ [zimbra@zimbra ~]$ zmlocalconfig -e
[email protected] [zimbra@zimbra ~]$ zmauditswatchctl start [zimbra@zimbra ~]$ zmauditswatchctl status [/syntax]
Para verificar que ha arrancado sin problemas, podremos ver el log en el fichero: /opt/zimbra/log/zmauditswatch.out
Valores por defecto que vienen por defecto son los siguientes: [syntax type=”php”+ zimbra_swatch_ipacct_threshold=10 zimbra_swatch_acct_threshold=10 zimbra_swatch_ip_threshold=20 zimbra_swatch_total_threshold=100 [/syntax] Los cuales, los podemos modificar a nuestro antojo [syntax type=”php”+ [zimbra@zimbra ~]$ zmlocalconfig -e zimbra_swatch_ipacct_threshold=10 [zimbra@zimbra ~]$ zmlocalconfig -e zimbra_swatch_acct_threshold=15 [zimbra@zimbra ~]$ zmlocalconfig -e zimbra_swatch_ip_threshold=20 [zimbra@zimbra ~]$ zmlocalconfig -e zimbra_swatch_total_threshold=60
A consecuencia, de que este dominio no arranca por defecto con nuestro sistema, nos descargaremos el script de inicio. El cual lo ubicaremos en nuestro runlevel, para cuando rebotemos el equipo, el dominio arranque de manera automática. [syntax type=”php”+ [root@zimbra ~]# cd /usr/local/src/ [root@zimbra src]# wget https://wiki.zimbra.com/images/d/d9/Zmauditswatch.tar [root@zimbra src]# tar xvf Zmauditswatch.tar [root@zimbra src]# cp zmauditswatch.txt /etc/rc.d/init.d/zmauditswatch [root@zimbra src]# chmod 755 /etc/rc.d/init.d/zmauditswatch [root@zimbra src]# systemctl enable zmauditswatch [/syntax] Los mensajes que nos envía el sistema indicándonos que se ha bloqueado una cuenta, están ya predefinidos y los podemos cambiar a nuestro antojo, siempre y cuando conservemos las variables:
[syntax type=”php”+*root@zimbra ~]# cat /opt/zimbra/conf/auditswatchrc.in[/syntax]
Para verificar el funcionamiento, simplemente hemos de superar el umbral de fallos, indicado anteriormente:
Una vez pasado el umbral, el sistema nos enviará un mail. Con un mensaje parecido al siguiente que recibiremos, cuando nuestro sistema bloquee una cuenta de correo:
Antivirus
Deshabilitamos del sistema que nos bloquee los archivos encriptados: [syntax type=”php”+zmprov mcf zimbraVirusBlockEncryptedArchive FALSE[/syntax] Muchos administradores me preguntan sobre el funcionamiento del sistema de AntiVirus de Zimbra. Zimbra usa todas las herramientas OpenSource del mercado y como no, para su sistema de AntiVirus usa el ClamAV
ClamAV se actualiza automáticamente cuando actualizamos la versión de Zimbra, es posible actualizar nuestra versión de ClamAV sin tener que actualizar la versión de Zimbra, pero es totalmente desaconsejable, ya que todos los cambios y el esfuerzo, se eliminará en cuanto actualicemos nuestra versión de Zimbra. Las definiciones de virus se actualizan automáticamente por defecto cada dos horas como podemos ver en el log del freshclam.log. Este valor, se puede modificar desde la administración de Zimbra:
En el log del fresclam, podremos observar que cada 2 horas se va actualizando las definiciones de virus.
[root@zimbra ~]# tail -19 /opt/zimbra/log/freshclam.log
Si deseamos forzar una actualización de las definiciones de virus de manera manual, simplemente lanzaremos el siguiente comando como el usuario zimbra:
[zimbra@zimbra ~]$ /opt/zimbra/clamav/bin/freshclam – config file=/opt/zimbra/conf/freshclam.conf
Para verificar que nuestro demonio de AntiVirus está funcionando, lo podremos verificar de la siguiente manera:
[zimbra@zimbra ~]$ zmclamdctl status
Para saber que versión de ClamAv tenemos instalada en nuestro sistema, lanzaremos el siguiente comando:
[zimbra@zimbra ~]$ /opt/zimbra/clamav/bin/clamscan -V
Una de las opciones que a nivel personal no me gusta, es que el sistema de AntiVirus de Zimbra por defecto bloquea los ficheros encriptados.
Esta funcionalidad, la suelo deshabilitar ya que da más problemas que ventajas. Para poder deshabilitarlo, podemos usar el GUI o lanzar el siguiente comando:
[zimbra@zimbra ~]$ zmprov mcf zimbraVirusBlockEncryptedArchive FALSE
Y como siempre, verificaremos que se han realizado los cambios deseados:
[zimbra@zimbra ~]$ zmprov gacf | grep -i encryptedarchive
Si por algún motivo necesitásemos deshabilitar el sistema de antivirus, realizaríamos esta operación de la siguiente manera: [zim bra@zim bra ~]$ zmprov ms
-zimbraServiceEnabled antivirus
Para verificar que el sistema de antivirus funciona de manera correcta, usaremos un código conocido como EICAR ( http://www.eicar.org/86-0-Intended-use.html ). Este código emula un virus y todos los sistema de AntiVirus lo detectan como tal y lo han de bloquear. Procederemos de la siguiente manera: Enviaremos el mail desde un servidor externo con el código EICAR Veremos que nuestro servidor de Zimbra descarta el mensaje y lo entrega al buzón del administrador
Enviamos el código EICAR desde un servidor externo contra nuestro servidor de Zimbra:
root@firewall:~# telnet 192.168.100.20 25 helo zimbra.ilba.cat mail from:
[email protected] rcpt to:
[email protected] data X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Observamos en el log lo que sucede:
[root@zimbra ~]# tail -f /var/log/maillog
Como podremos ver en el log, el mensaje es reenviado a la cuenta del administrador del servidor. En nuestro caso
[email protected] y si abrimos el buzón, podremos ver el mensaje:
IMAP / POP3 / SMTP
Permitiremos el acceso a los protocolos IMAP, POP3 y SMTP sin necesidad de usar encriptación:
[syntax type=”php”] zmprov mcf zimbraMtaTlsAuthOnly FALSE zmprov mcf zimbraImapCleartextLoginEnabled TRUE zmprov mcf zimbraPop3CleartextLoginEnabled TRUE [/syntax] Si va a ser un servidor IMAP, aumentaremos los threads y las conexiones [syntax type=”php”] zmprov ms zmhostname zimbraImapNumThreads 500 zmprov ms zmhostname zimbraImapMaxConnections 500 [/syntax] En ocasiones, si todos nuestros clientes usan el protocolo IMAP para poder gestionar su correo en una plataforma de Zimbra, podríamos llegar a encontrarnos el siguiente error:
[syntax type=”php”+ 2014-09-17 17:37:38,638 WARN [ImapServer-93] [] imap – Dropping connection (max connections exceeded) 2014-09-17 17:37:39,031 WARN [ImapServer-91] [] imap – Dropping connection (max connections exceeded) 2014-09-17 17:39:03,679 WARN [ImapServer-95] [] imap – Dropping connection (max connections exceeded) 2014-09-17 17:39:25,514 WARN [ImapServer-91] [] imap – Dropping connection (max connections exceeded) [/syntax]
Y los outlooks, nos muestran el siguiente error:
El problema radica, en que cada cliente de correo electrónico que se conecta a nuestro servidor Zimbra mediante el protocol IMAP, usa una conexión. Pero el cliente puede llegar a abrir más de un thread por conexión. A consecuencia de este planteamiento, lo norma para solventar este tipo de errores, es aumentar los dos valores. Por defecto, cuando instalamos nuestro servidor de Zimbra, viene con los siguientes valores por defecto: [syntax type=”php”+ Last login: Tue Sep 16 18:29:08 2014 from 10.222.0.15 root@zcs:~# su – zimbra zimbra@zcs:~$ zmprov gs ‘zmhostname’ zimbraImapNumThreads zimbra@zcs:~$ zmprov gs ‘zmhostname’ zimbraImapMaxConnections [/syntax]
Aumentamos el valor, de una manera lógica. Por ejemplo en 500: [syntax type=”php”] zimbra@zcs:~$ zmprov ms zmhostname zimbraImapNumThreads 500 zimbra@zcs:~$ zmprov ms zmhostname zimbraImapMaxConnections 500 [/syntax]
Reiniciamos los servicios de Zimbra y listo.
Logs del servidor
Reenviaremos todos los logs del servidor a una cuenta en concreto: [syntax type=”php”+ zmprov ma
[email protected] zimbraPrefMailForwardingAddress
[email protected] zmprov ma
[email protected] zimbraFeatureMailForwardingEnabled FALSE [/syntax] HELO
Cambiaremos el HELO del servidor: [syntax type=”php”+ zmlocalconfig -e postfix_smtpd_banner=” helo.ilba.cat NO UCE ESMTP” postconf -e smtpd_banner=”helo.ilba.cat NO UCE ESMTP” zmprov mcf zimbraMtaMyHostname helo.ilba.cat [/syntax] Public service hostname
Cambiaremos los accesos directos de los diferentes componentes de Zimbra: [/syntax]
Tamaño de mensajes
Ajustaremos los tamaños de los mensajes que acepta nuestro sistema: [syntax type=”php”+ zmprov mcf zimbraMtaMaxMessageSize 38912000 zmprov mcf zimbraFileUploadMaxSize 37888000000 [/syntax] Habitualmente, cuando configuramos un servidor de Zimbra, pocas veces nos paramos a pensar en los tamaños de upload y de MTA que nos vienen por defecto, una vez instalado nuestro servidor de Zimbra. Estos valores, los podemos ver de una forma rápida y sencilla, por consola o por GUI.
root@zcs:~# su - zimbra zimbra@zcs:~$ zmprov gacf | grep zimbraMtaMaxMessageSize zimbraMtaMaxMessageSize: 38912000 zimbra@zcs:~$ zmprov gacf | grep zimbraFileUploadMaxSize zimbraFileUploadMaxSize: 37888000000
Los parámetros mostrados, son almacenados por el LDAP interno de Zimbra y posteriormente propagados por el zmmtaconfig. Otro dato importante, es que los valores que le indicamos por consola son en bit (b) y por la GUI son en kilobyte (KB). En la versión 8 de Zimbra, existen más parámetros de gestión de tamaños como por ejemplo: zimbraFileUploadMaxSizePerFile, casi todos ellos solamente se pueden modificar desde la consola.
zimbraMtaMaxMessageSize Es el tamaño máximo que nuestro servidor SMTP (en nuestro caso el Postfix) va a aceptar. Eso quiere decir, que si nos envían desde una cuenta externa un mensaje que se superior al valor que tenemos indicado, el servidor le retornará un mensaje de error. Se puede modificar por consola:
root@zcs:~# su - zimbra zimbra@zcs:~$ zmprov modifyConfig zimbraMtaMaxMessageSize 38912000 zimbra@zcs:~$ postfix reload
Se puede modificar por GUI y la opción es: “ Maximum message size (KB)”
zimbraFileUploadMaxSize Es el tamaño máximo que podemos subir archivos a nuestro servidor de Zimbra, incluyendo: maletín, calendarios, mensajes, etc…. . Esto os aconsejo dejarlo a un valor alto, sobre todo cuando se están haciendo migraciones ya que nos podría dar problemas. Se puede modificar por consola:
root@zcs:~# su - zimbra zimbra@zcs:~$ zmprov modifyConfig zimbraFileUploadMaxSize 37888000000 zimbra@zcs:~$ postfix reload Se puede modifica por GUI, en la opción: “Maximum size of an uploaded file for Briefcase, Email messages, Calendar appointments and Tasks (KB):”
Conexiones web
Permitiremos el acceso a nuestro servidor a ambos tipos de conexiones, tanto HTTP como HTTPS: [syntax type=”php”+zmtlsctl both[/syntax]
Cuando el Score importa, SPF, DKIM, rDNS
Para llegar a todos los destinatarios, aunque estén detrás de una MTA estricta, necesitaremos cumplir varios estándares de seguridad, por ejemplo deberemos tener activo y bien configurado: SPF SenderID DKIM rDNS
Una vez que tenemos nuestro Zimbra Collaboration instalado, podemos enviar un email a Mail Tester, y comprobar nuestro Score.
Certificado de Seguridad SSL
Hace unos años, tener un certificado de seguridad quedaba relegado para grandes Compañías, o negocios online donde hubiera un carrito de la compra, con los precios actuales de los SSL, desde 9 dólares al año, securizar nuestro Zimbra Collaboration es una recomendación básica. Las instrucciones para la correcta generación e instalación de un SSL las encontramos en el siguiente Wiki – https://wiki.zimbra.com/wiki/Jdelacruz-Notes#SingleNode_Commercial_Certificate
Controlando los Logs
No es ningún misterio saber que cuando Zimbra Collaboration tiene algún problema, o sufrimos un ataque, o un problema de recursos, la información estará en los Logs, es por ello que una buena práctica una vez tenemos nuestro Zimbra Collaboration, es centralizar los Logs en un appliance que sea capaz de mostrarnos esos Logs de una forma más sencilla, desgranada y depurada, además con opción de buscar en cierto rango de tiempo.
Zimbra: Logs centralizados con VMware vRealize Log Insight
1.- ¿Qué es VMware vRealize Log Insight? 2.- Zimbra con VMware vRealize Log Insight usando Syslog 2.1.- Configuración en nuestro servidor Zimbra 3.- Monitorizando los Logs de nuestro nuevo Zimbra Server en VMware vRealize Log Insight 4.- Trabajando con VMware vRealize Log Insight, ayuda al instante 5.- Zimbra con VMware vRealize Log Insight usando Agente 5.1.- Instalación del Agente de VMware vRealize Log Insight en nuestro servidor Zimbra 5.2.- Configuración en nuestro Agente de VMware vRealize Log Insight 6.- Trabajando con VMware vRealize Log Insight, ayuda al instante II 7.- Content Packs 8.- Conclusión
¿Qué es VMware vRealize Log Insight?
Antes se llamaba vCenter Log Insight, VMware vRealize Log Insight ofrece gestión de Logs en tiempo real para entornos VMware, o cualquier otro aparato, servidor, etc que le configuremos, con agrupación basada en el aprendizaje inteligente del propio appliance, búsqueda de alto rendimiento y una mejor resolución de problemas de nuestros entornos virtuales, Zimbra, etc.
Zimbra con VMware vRealize Log Insight usando Syslog
En esta configuración vamos a aprender a configurar nuestro Zimbra para que mande mediante Syslog los Logs de Zimbra. Es un primer paso y el más básico de los dos que configuraremos, pero también el más sencillo de implementar. Configuración en nuestro servidor Zimbra
Lo primero que haremos será editar la configuración de Rsyslog de nuestro servidor de Zimbra, deberemos editar el fichero de configuración ubicado en /etc/rsyslog.conf y dejarlo con los siguientes valores: vi /etc/rsyslog.conf Es importante que estemos atentos al cambio e introduzcamos la IP o hostname de nuestro servidor de VMware vRealize Log Insight, así cómo estar seguros que estamos usando el puerto 514 por UDP, todo esto viene configurado por defecto en el VMware vRealize Log Insight, así que si no hemos hecho cambios todo funcionará a la primera. # provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 *.* @IPorHOSTNAMELOGINSIGHT:514
Lo siguiente será lanzar un reinicio al servicio de Rsyslog: etc/init.d/rsyslog restart Una manera muy buena de probar que nuestro VMware vRealize Log Insight recibe mensajes desde nuestro Zimbra server es lanzar una traza por UDP: nc -u IPorHOSTNAMELOGINSIGHT 514 Escribe aquí tu prueba
Y presionar CTRL+C, veremos algo así:
Y si nos vamos a nuestro VMware vRealize Log Insight, en la pestaña de Interactive Analytics veremos lo siguiente, esto es que todo funciona perfecto:
Monitorizando los Logs de nuestro nuevo Zimbra Server en VMware vRealize Log Insight
Es el turno de loguearnos a nuestro VMware vRealize Log Insight y ver que información somos capaces de sacar, etc. Una vez hemos hecho login, nos iremos hasta la pestaña de Interactive Analytics que es donde podremos jugar mucho más. En esta pestaña, tenemos además varias sub-pestañas con las que podemos ver los Logs de maneras diferentes.
Por ejemplo, cómo Field Table, podemos ver los Logs de manera desgranada y ordenarlo además por Host, por App, etc, muy útil esta pestaña.
Y también por tipos de Evento, nada especial en esta vista, pero no deja de ser interesante y nos puede servir en el futuro.
Trabajando con VMware vRealize Log Insight, ayuda al instante
Pero la verdadera funcionalidad de un sistema centralizado de Logs es cuando necesitamos buscar un dato porque tenemos un problema, o un fallo, o un ataque, por ejemplo, una de mis búsquedas más normales es ver los usuarios logeados a Zimbra, para detectar ataques o login indebidos. En Linux el comando suele ser así: cat /var/log/zimbra.log | grep sasl_method Pero en nuestro sistema centralizado de Logs, puedo chequear al mismo tiempo en todos mis servers Zimbra, o solamente en los que yo desee, etc. Lo que haré será en el campo de búsqueda introduciré sasl y el propio sistema me autocompletará con sasl_method, esto sucede con todas las cadenas que busquemos, esto es simplemente maravilloso.
Aquí el resultado del comando lanzado, bueno en mi caso solamente estoy yo, que es mi entorno de pruebas.
Podemos además filtrar por el Source, que será el Servidor Zimbra, y así tener solamente los impactos y logins a ese servidor en concreto.
Y de esta manera, podemos añadir a nuestro Dashboard personalizado la búsqueda con sasl_method y con el source nuestro server Zimbra, uno de ellos al menos.
Podremos elegir el nombre para el complemento que añadiremos a nuestro Dashboard, en mi caso he puesto User login Dashboard .
Y así es cómo se verá nuestro Dashboard 1, con la gráfica total de Eventos, así cómo el nuevo Widget llamado User login Dashboard , con la cantidad de usuarios logueados por tiempo, un dato muy útil para detectar picos de trabajo o cuellos de botella, o ataques.
Zimbra con VMware vRealize Log Insight usando Agente
Como todos los Softwares del mercado, siempre que hay un agente de por medio, encontramos una mayor integración y muchas más opciones. Seguramente con la configuración de arriba os habéis quedado un poco fríos y queréis añadir más logs, especialmente el todopoderoso mailbox.log de Zimbra. Instalación del Agente de VMware vRealize Log Insight en nuestro servidor Zimbra
Los Agentes podemos encontrarlos en la siguiente URL: https://YOURVREALIZELOGINSIGHTSERVER/admin/agents, veremos algo así:
Si ya tuviéramos uno o varios Agentes instalados, entonces veremos algo así:
Descargaremos el fichero de Agente para Linux en nuestro servidor. Y lo instalaremos de la siguiente manera sudo dpkg deb -i VMware-Log-Insight-Agent_2.5.0-2347850.deb Y el proceso de instalación mostrará algo cómo lo siguiente: Preparing to unpack VMware-Log-Insight-Agent_2.5.0-2347850.deb ... Unpacking vmware-log-insight-agent (2.5.0-2347850) ... Setting up vmware-log-insight-agent (2.5.0-2347850) ... Adding system startup for /etc/init.d/liagentd ... /etc/rc0.d/K20liagentd -> ../init.d/liagentd /etc/rc1.d/K20liagentd -> ../init.d/liagentd /etc/rc6.d/K20liagentd -> ../init.d/liagentd /etc/rc2.d/S20liagentd -> ../init.d/liagentd /etc/rc3.d/S20liagentd -> ../init.d/liagentd /etc/rc4.d/S20liagentd -> ../init.d/liagentd /etc/rc5.d/S20liagentd -> ../init.d/liagentd Starting VMware Log Insight Agent: * Installation completed. Please edit /var/lib/loginsight-agent/liagent.ini to configure the agent. For online documentation please visit: http://pubs.vmware.com/log-insight-25/index.jsp?topic=%2Fcom.vmware.loginsight.administration.doc%2FGUID-DB4A27CF-BDA7-443F-94FB-AB9097AD8008.html Processing triggers for ureadahead (0.100.0-16) ... ureadahead will be reprofiled on next reboot
Configuración en nuestro Agente de VMware vRealize Log Insight
La configuración del agente no es nada complicada, simplemente deberemos editar el fichero /var/lib/loginsight-agent/liagent.ini y añadir los logs que queremos monitorizar , por defecto el Agente trae syslog y messages.log, que podemos eliminar si nos reporta demasiada información que no queremos. Ejemplo para un servidor Zimbra Single Server: [filelog|messages] directory=/var/log include=messages;messages.? [filelog|syslog] directory=/var/log include=syslog;syslog.? [filelog|Zimbra-Audit] directory=/opt/zimbra/log include=audit.log;audit.log [filelog|Zimbra-Access] directory=/opt/zimbra/log include=access.log;access.log* [filelog|Zimbra-Clamd] directory=/opt/zimbra/log include=clamd.log;clamd.log [filelog|Zimbra-EWS] directory=/opt/zimbra/log include=ews.log;ews.log [filelog|Zimbra-Mailbox] directory=/opt/zimbra/log include=mailbox.log;mailbox.log [filelog|Zimbra-MYSQL-Error] directory=/opt/zimbra/log include=mysql_error.log;mysql_error.log [filelog|Zimbra-Zmmailboxd]
Después de configurar el Agente de VMware vRealize Log Insight, el propio agente empezará a mandar información al servidor. Si no fuera así podemos hacer un reboot del servicio: /etc/init.d/liagentd restart Stopping VMware Log Insight Agent: * Starting VMware Log Insight Agent: * Trabajando con VMware vRealize Log Insight, ayuda al instante II
Bien, es la hora de volver a nuestro VMware vRealize Log Insight para ver que somos capaces de visualizar con el agente instalado.
Por defecto, nos cargará el menú de vSphere, pero nosotros queremos ver el General, así que haremos Click en el menú donde pone VMware vSphere y cambiaremos a General.
Y allí podremos ver mucha más información acerca de nuestro entorno, nuestros Hosts Logueados, etc.
Pero sin duda, la mejor pestaña aquí es la de Agents, en ella veremos todos nuestros servidores con el Agente instalado, y podremos como siempre autocompletar en el campo de Hostname, o en la derecha en el primer Widget veremos el resumen de los Agentes.
Por ejemplo este es un Dashboard que he creado, le he llamado Zimbra with Agent, y he aglutinado una gráfica con todas las entradas de Log, un widget separado por los impactos de cada Log, y un widget con la tarta por Hosts, solamente tengo uno y queda algo pobre.
Si pinchamos en alguno de los campos de las tartas, por ejemplo en el pedazo de tarta para /opt/zimbra/log/mailbox.log y pulsamos en Interactive Analytics, veremos las trazas de Logs de este fichero, impresionante.
Content Packs
Los fabricantes se están empezando a dar cuenta lo importante qué es tener los Logs centralizados para depurar problemas, para evitarlos y solucionarlos en caso de fallo grave, y se han unido a VMware en proporcionar Content Packs para VMware vRealize Log Insight, de tal forma que añadir Logs de diferentes fabricantes sea un abrir y cerrar de ojos, aquí el ejemplo:
Conclusión
La conclusión es que VMWare vRealize Log Insight es una herramienta muy potente ya preparada para el entorno Business y además con el soporte y garantia de VMware. He quedado más que impresionado con este Software, y no solamente porque recoja perfectamente los Logs de Zimbra Collaboration, si no porque es muy potente y podemos tener centralizados todos los Logs de cientos de dispositivos. Puntos positivos A favor frente a Kibana y Logstash es que viene en formato Appliance, se descarga, se arranca y a funcionar. Cuenta con soporte de VMware detrás Es una solución Business Ready Es una solución preparada para un CAU, o departamento de Sistemas avanzado. Me encanta la manera de tratar los Logs, de pasearlos y de buscar en ellos. Content Packs de diferentes fabricantes, awesome. Puntos negativos Tiene un coste. El tema de particionamiento, etc, al venir en formato Appliance es más complicado tocarlo. Basado en OpenSuse, lo siento prefiero Ubuntu o Red Hat para appliances, pero VMware parece muy unido a Opensuse en todos los appliances que saca.
Securizar Zimbra, Enforce a match between FROM and SASL
Securizar nuestro Zimbra para que compruebe el usuario que se loguea con la dirección de email es una buena práctica que debemos seguir para reducir el SPAM, y los ataques a cuentas que no existen, etc. Flujo por Defecto de envío de correos en Zimbra
Un usuario se autentica, y envía un correo a los destinatarios pertinentes, hasta aquí todo normal.
Vista a Nivel de Outlook:
El correo me llega correctamente.
Pero, por defecto, Zimbra permite que una vez está un Usuario autenticado, pueda enviar emails en nombre de otra dirección de correo . Lo cual es muy peligroso, y puede comprometer el buen funcionamiento de nuestro Sistema de Correo, y sobre todo la seguridad de la Empresa y sus Usuarios. Veamos el flujo de correo de un correo de User 1, autenticado correctamente, usando la dirección de correo electrónico del Jefe de la Empresa.
Vista a Nivel de Outlook:
Primero me cambio la dirección de E-mail desde donde envío para ejecutar el Fake Email.
Creo un correo para un usuario (en este caso yo pero imaginemos el departamento de administración) y le pido que transfiera una cantidad de dinero a un usuario.
La persona que recibe el Correo, lo ve de manera legítima, como si proviniera del Jefe Financiero, con su dirección de correo y todo. Esto es un Fake Email y debe ser corregido de inmediato.
Activando la Seguridad para comprobar que el login de usuario y su dirección de correo, corresponde con lo que dice su username en el sasl
Activar esta seguridad no nos llevará más de 3 minutos y conseguiremos un Sistema Zimbra Robusto y Seguro, lo primero es hacer login como usuario Zimbra mediante SSH:
syntax type=”php”+root@labjorge:/# su zimbra zimbra@labjorge:/$ zmprov mcf zimbraMtaSmtpdSenderLoginMaps proxy:ldap:/opt/zimbra/conf/ldap-slm.cf proxy:ldap:/opt/zimbra/conf/ldap-slm.cf +zimbraMtaSmtpdSenderRestri +zimbraMtaSmtpdSenderRestrictions ctions reject_authenticated_sender_login_mismatch[/syntax] El siguiente paso es abrir el fichero opt/zimbra/conf/zmconfigd/smtpd_sender_restrictions.cf [syntax type=”php”+zimbra@labjorge:/$ vi /opt/zimbra/conf/zmconfigd/ /opt/zimbra/conf/zmconfigd/smtpd_sender_restrictions.cf[/syn smtpd_sender_restrictions.cf[/syntax] tax] p ermit_mynetworks, s, Y una vez en él, añadiremos reject_sender_login_mismatch después de permit_mynetwork el resto no hay que tocar nada :
[syntax type=”php”+permit_mynetworks, reject_sender_login_mismatch[/syntax]
Después de un minuto aproximadamente, zmconfigd actualizará la configuración de postfix y aplicará correctamente correctamente los nuevos cambios que hemos introducido. El Flujo de Correo queda de la siguiente manera; El User 1 se autentica, e intenta enviar un correo usando la dirección de correo de su Jefe, pero el Sistema Zimbra le devuelve un error al instante.
Vista a Nivel de Outlook:
Una vez hemos aplicado esta seguridad, vamos a probar de nuevo a mandar otro correo, solicitando esta vez más dinero:
Lamentablemente para el Usuario con malas intenciones, este problema de seguridad está ya corregido y al intentar enviar el correo, recibirá un bonito error 553 5.7.1 Sender address rejected: not owned by user.
Whitelist para ciertas cuentas
Seguramente necesitemos activar una pequeña Whitelist, para que ciertas cuentas o usuarios si puedan realizar este cambio de dirección de correo, y con un login puedan enviar en nombre de otras cuentas, tipo formularios de contacto, no-reply, etc. El primer paso es crear la base de datos de usuario:
[syntax type=”php”]root@labjorge:/# vim /opt/zimbra/conf/slm-exceptions-db[/syntax] El segundo paso es introducir las direcciones que queremos permitir y luego el usuario real: *syntax type=”php”
[email protected] [email protected][/syntax]
El tercer paso es hacer el postmap para que se cree la Base de Datos correctamente:
[syntax type=”php”]root@labjorge:/# postmap /opt/zimbra/conf/slm-exceptions-db[/syntax] El comando ahora a ejecutar con el zmprov añade la base de datos de Whitelist: [syntax type=”php”+root@labjorge:/# zmprov mcf zimbraMtaSmtpdSenderLoginMaps ‘lmdb:/opt/zimbra/conf/slm-exceptions-db, proxy:ldap:/opt/zimbra/conf/ldap-slm.cf ‘ +
zimbraMtaSmtpdSenderRestrictions reject_authenticated_sender_ login_mismatch[/syntax]
Podemos esperar 1 minuto o forzar el reinicio con el siguiente comando: [syntax type=”php”+root@labjorge:/# zmmtactl stop && sleep 30 && zmmtactl start[/syntax] Y al enviar de nuevo usando la dirección alternativa, no nos dará ningún error:
Monitorización de Zimbra Collaboration
Si tener los Logs era importante, tener el servidor, o servidores de Zimbra Collaboration controlado en todo momento y al detalle es prácticamente impositivo. Es por ello para monitorizar Zimbra Collaboration sobre entorno Nagios.
Preparando nuestro servidor de Nagios
Antes de empezar a monitorizar, dejaremos nuestros ficheros de configuración preparados. Crearemos el servidor de Zimbra y un grupo:
roo t@firewall:~# vim /etc/nagios3/conf.d/ilba_zimbr a.cfg define host{ use generic-host host_name zimbra.ilba.cat alias zimbra.ilba.cat address 192.168.100.20 } roo t@firewall:~# vim /etc/nagio s3/co nf.d/hostg rou ps_nagio s2.cfg define hos tgroup { hos tgroup _nam e zimb ra-servers alias Zimbra members zimbra.ilba.cat }
Instalando NRPE en nuestro servidor de Zimbra
Lo que haremos, es instalar el cliente de Nagios en nuestro servidor de Zimbra . En mi caso es una CentOS y por defecto, este sistema operativo, no viene el cliente de Nagios en los repositorios oficiales, por consiguiente tendremos que añadir el repositorio EPEL ( Linux Empresarial ) para poder instalar el cliente. OS dejo una captura donde se ve claramente como funciona el sistema de monitorización de Nagios con NRPE ( Nagios Remote Plugin Executor ):
Para instalar el cliente haremos lo siguiente, como ya he indicado anteriormente, añadiremos el repositorios EPEL :
[root@zimbra ~]# rpm -Uhv http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-68.noarch.rpm
Una vez añadido el repositorio de EPEL, ya podremos instalar el cliente NRPE en nuestro servidor de Zimbra:
[root@zimbra ~]# yum install nagios-plugins-nrpe nagios-plugins-all nrpe Ahora tendremos que configurar el cliente de Nagios para que nos acepte argumentos y nos permita acceder desde nuestro servidor de Nagios la monitorización: [roo t@zim bra ~]# vim /etc/nagios /nrpe.cfg allowed_hosts=192.168.100.1 dont_blame_nrpe=1 [roo t@zim bra ~]# service nrp e restart [roo t@zim bra ~]# vim /etc/selinux /co nfig SELINUX=disabled
Monitorizando servicio SMTP
El Simple Mail Transfer Protocol (SMTP) (Protocolo para la transferencia simple de correo electrónico), es un protocolo de red utilizado para el intercambio de mensajes de correo electrónico entre ordenadores u otros dispositivos. Lo que haremos es monitorizar desde fuera del servidor de Zimbra, que el servicio SMTP esté levantado:
roo t@firewall:~# vim /etc/nagios 3/co nf.d/services_nagio s2.cfg define service{ use generic-service hostgroup_name zimbra-servers service_description SMTP check_command check_smtp }
Monitorizando servicio SUBMISSION
El Submission, es un protocolo de red (puerto 587) utilizado para el intercambio de mensajes de correo electrónico entre ordenadores u otros dispositivos, este puerto es el alternativo al SMTP. Lo que haremos es monitorizar desde fuera del servidor de Zimbra, que el servicio Submission esté levantado:
oot@firewall:~# vim /etc/nagios3/commands.cfg define command{ command_name check_submission command_line /usr/lib/nagios/plugins/check_smtp -H $HOSTADDRESS$ -p 587 } root@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg define service{ use generic-service hostgroup_name zimbra-servers service_description Submission check_command check_submission }
Monitorizando servicio IMAP
Internet Message Access Protocol (IMAP), es un protocolo de aplicación que permite el acceso a mensajes almacenados en un servidor de Internet. Mediante IMAP se puede tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a Internet. IMAP tiene varias ventajas sobre POP3 (otro protocolo empleado para obtener correos desde un servidor). Por ejemplo, es posible especificar en IMAP carpetas del lado del servidor. Por otro lado, es más complejo que POP3 ya que permite visualizar los mensajes de manera remota y no descargando los mensajes como lo hace POP3. Lo que haremos es monitorizar desde fuera del servidor de Zimbra, que el servicio IMAP esté levantado:
roo t@firewall:~# vim /etc/nagios3/conf.d/services_nagios 2.cfg define service{ use generic-service hostgroup_name zimbra-servers service_description IMAP check_command check_imap }
Monitorizando servicio POP3
En informática se utiliza el Post Office Protocol (POP3, Protocolo de Oficina de Correo o “Protocolo de Oficina Postal”) en clientes locales de correo para obtener los mensajes de correo electrónico almacenados en un servidor remoto. Lo que haremos es monitorizar desde fuera del servidor de Zimbra, que el servicio POP3 esté levantado:
roo t@firewall:~# vim /etc/nagio s3/con f.d/services_nagios 2.cfg define service{ use generic-service hostgroup_name zimbra-servers service_description POP3 check_command check_pop }
Monitorizando servicio IMAP SSL
Este protocolo, es el mismo que el IMAP, pero el acceso se realiza de manera segura mediante certificados. Lo que haremos es monitorizar desde fuera del servidor de Zimbra, que el servicio IMAP SSL SSL esté levantado: roo t@firewall:~# vim /etc/nagios3/com m ands.cfg d e f in e c o m m a n d { command_name check_imaps co m m and_line /usr/lib/nagios /plug ins/check _imap -H $HOSTADDRESS$ -p 993 -S } roo t@firewall:~# vim /etc/nagios 3/con f.d/services_nagios 2.cfg define service{ use generic-service hostgroup_name zimbra-servers service_descriptio n IMAP SSL check_command check_imaps }
Monitorizando servicio POP3 SSL
Este protocolo, es el mismo que el POP3, pero el acceso se realiza de manera segura mediante certificados. Lo que haremos es monitorizar desde fuera del servidor de Zimbra, que el servicio POP3 SSL SSL esté levantado:
roo t@firewall:~# vim /etc/nagios3/com m ands.cfg define com mand{ command_name check_pops com mand _line /us r/lib/nagios /plug ins/check _pop -H $HOSTADDRESS$ -p 995 -S } roo t@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg define service{ use generic-service hostgroup_name zimbra-servers service_descriptio n POP3 SSL check_command check_pops }
Monitorizando el servicio de ClamAV
ClamAv es el antivirus que usa el sistema de Zimbra. Lo que haremos es monitorizar internamente del servidor de Zimbra, que el servicio ClamAV tenga un socket, eso nos indicará que esta funcionando: [roo t@zimbra ~]# vim /etc/nagios/nrp e.cfg com mand[ch eck_clamd]=/usr/lib64/nagios/plugins/check_clamd /opt/zimbra/data/clamav/clamav.sock [roo t@zimbra ~]# service nrp e restart roo t@firewall:~# vim /etc/nagios3/conf.d/services_nagios2.cfg define service { use generic-service hostgroup_name zimbra-servers service_description ClamAV check_command check_nrpe_1arg!check_lmtp }
Monitorizando el servicio LMTP
Local Mail Transfer Protocol o LMTP (Protocolo de transporte local de correo) es un derivado de SMTP, el Simple Mail Transfer Protocol. LMTP es diseñado como una alternativa a SMTP para situaciones donde el lado receptor no dispone de cola de correo (queue mail), como unMTA (Mail Delivery Agent) que entiende conversaciones SMTP.Lo que haremos es monitorizar internamente del servidor de Zimbra, que el servicio LMTP esta funcionando: [roo t@zim bra ~]# vim /etc/nagios /nrpe.cfg com m and[c heck_lm tp] =/usr /lib64/nagios /plugins /check_sm tp -H localho st -p 7025 [roo t@zim bra ~]# service nrp e restart roo t@firewall:~# vim /etc/nagio s3/co nf.d/services_nagios2.cfg define service { use generic-service hostgroup_name zimbra-servers service_description LMTP check_command check_nrpe_1arg!check_lmtp }
Monitorizando el servicio SpellCheck
SpellCheck es el corrector ortográfico de Zimbra. Lo que haremos es monitorizar internamente del servidor de Zimbra, que el servicio SpellCheck esta funcionando: [roo t@zim bra ~]# vim /etc/nagios /nrpe.cfg com m and[c heck_sp ell]=/usr /lib64/nagios /plug ins/check _http -H loc alhost -p 7780 [roo t@zim bra ~]# service nrp e restart roo t@firewall:~# vim /etc/nagio s3/co nf.d/services_nagios2.cfg define service { use generic-service hostgroup_name zimbra-servers service_description SpellCheck check_command check_nrpe_1arg!check_spell }
Monitorizando el servicio DNS
Verificaremos que el servidor de Zimbra tenga acesso a internet y lo que haremos es monitorizar internamente, desde el servidor de Zimbra, que tenga resolución:
[roo t@zim bra ~]# vim /etc/nagios /nrpe.cfg com mand[c heck_dns]=/usr/lib64/nagios/plugins/check_dns -H goo gle.com [roo t@zim bra ~]# service nrp e restart roo t@firewall:~# vim /etc/nagio s3/co nf.d/services_nagios2.cfg define service { use generic-service hostgroup_name zimbra-servers service_description DNS check_command check_nrpe_1arg!check_dns }
Monitorizando el certificado
Ya que el certificado que se instala en nuestro servidor de Zimbra es vital, ya que sin él dejaría de funcionar el sistema. Lo que haremos es monitorizar internamente del servidor de Zimbra, que el certificado no nos haya caduque: [roo t@zimbra ~]# vim /etc/nagios/nrp e.cfg co m m and[c heck_cert]=/usr/lib64/nagios /plug ins/check _http -S -H loc alhost -C 30 [roo t@zimbra ~]# service nr pe restart roo t@firewall:~# vim /etc/nagios 3/con f.d/services_nagios 2.cfg define service { use generic-service hostgroup_name zimbra-servers service_descriptio n Cert HTTPS check_command check_nrpe_1arg!check_cert }
Monitorizando usuarios logueados
Es importante saber cuantos usuarios hay loginados, ya que si hay varias personas trabajando en el servidor, podemos llegar a chafar procesos o configuraciones entre nosotros.
[roo t@zim bra ~]# vim /etc/nagios/nrp e.cfg co m m and[c heck_us ers]=/usr/lib64/nagios/plugin s/check_us ers -w 2 -c 3 [roo t@zim bra ~]# service nrp e restart roo t@firewall:~# vim /etc/nagio s3/co nf.d/services_nagio s2.cfg define service { use generic-service hostgroup_name zimbra-servers service_description Usuarios check_command check_nrpe_1args!check_users }
Monitorizando Load Average Average
El Load Average, se compone de varios elementos, los cuales nos informarán de la carga del servidor. roo t@firewall:~# vim /etc/nagios /etc/ nagios 3/con 3/con f.d/services_nagios f.d/services_nagios 2.cfg 2.cfg define service { use generic-service hostgroup_name zimbra-servers service_de service _description scription Load Average check_command check_nrpe!check_load!5!10 }
Monitorizando PING
Monitorizando el Ping, podemos llegar a saber si nuestro servidor sufre latencias, las cuales pueden llegar a ser problemáticas para el correcto funcionamiento de nuestro servidor. define service { use generic-service hostgroup_name zimbra-servers service_description Ping6 check_command check_ping!100.0,20%!500.0,60% }
Monitorizando espacios
Como podréis ver en la captura, yo tengo mi servidor de Zimbra seccionado en tres particiones: OPT, HSM y Backups. Lo que haremos es monitorizarlas, para que cuando quede poco espacio nos avise.
[roo t@zimbra ~]# vim /etc/nagio /etc/nagio s/nrpe.cfg c o m m a n d [ c h e c k _ o p t ] = /u /u s r / l i b 6 4/ 4/n a g i o s / p l u g i n s /c h e c k _ d i s k - w 2 0% 0% - c 1 0 % - p / o p t c o m m a n d [ c h e c k _ b a c k u p ] = / u s r /l /l i b 6 4 /n /n a g i o s / p l u g i n s /c h e c k _ d i s k - w 2 0% 0% - c 1 0% 0% - p /opt/zimbra/backup c o m m a n d [ c h e c k _ h s m ] = /u /u s r / l i b 64 6 4 /n /n a g i o s / p l u g i n s /c h e c k _ d i s k - w 2 0% 0% -c 1 0 % -p -p /opt/zimbra/hsm [ r o o t @ z im im b r a ~ ] # s e r v i c e n r p e r e s t a r t roo t@firewall:~# vim /etc/nagios /etc/nagios 3/co 3/co nf.d/services_nagio s2.cfg define service { use generic-service hostgroup_name zimbra-servers s e r v i c e _d _d e s c r i p t i o n Espacio OPT check_command check_nrpe_1arg!check_opt } define service { use generic-service hostgroup_name zimbra-servers s e r v i c e _d _d e s c r i p t i o n Espacio HSM check_command check_nrpe_1arg!check_hsm } define service { use generic-service hostgroup_name zimbra-servers s e r v i c e _d _d e s c r i p t i o n Espacio Backup check_command check_nrpe_1arg!check_backup }
Al final de todos estos checks, nos tendría que quedar de la siguiente manera en nuestro Nagios:
Plugin check_zmstatus.pl
Este Plugin nos monitoriza el estado de los servicios, directamente ejecutando en el servidor el comando zmcontrol status, como usuario Zimbra. Debe meterse en la carpeta donde tengamos nuestros plugins, /usr/lib64/nagios/plugins (para CentOS 64bit), /usr/lib/nagios/plugins (para Ubuntu 12.04 64bit) Este plugin es gracias a schose.net También hay que ejecutar algunos comandos adicionales, meter en el fichero /etc/sudoers la siguiente línea: %nagios ALL=(zimbra) NOPASSWD:/opt/zimbra/bin/zmcontrol Y en nuestro fichero de nrpe.cfg lo siguiente: [roo t@zim bra ~]# vim /etc/nagios /nrpe.cfg com m and[c heck_zms tatus] =/usr /lib64/nagios /plu gins /ch eck_zm status .pl -b $ARG1$ [roo t@zim bra ~]# service nrp e restart
Ahora en nuestro server de Nagios: roo t@srvn agios:~# vim /etc/nagios3/conf .d/services_nagios2.cfg define service { use generic-service hostgroup_name zimbra-servers service_descriptio n Zimb ra Status check_command check_nrpe_zimbra }
Y metemos el comando en nuestro commands.cfg define com mand{ command_name co m m and _line check _zm status -u }
check_nrpe_zimbra $USER1$/ch eck_n rp e -H $HOSTA DDRESS$ -c
El aspecto de este plugin es el siguiente:
Monitorizando Mailq
Otro servicio importante es Mailq, el servicio que nos muestra los mensajes que tenemos en cola, podemos monitorizar si tenemos un problema grande de spam, o que se han quedado los mensajes parados, vamos a monitorizarlo de la siguiente manera: [roo t@zimbra ~]# vim /etc/nagios/nrp e.cfg co m m and[ch eck_zim bra_mailq]=/usr/lib/nagios /plugins /ch eck_mailq -w 100 -c 150 -M po stf ix
Para este caso, además, tenemos que modificar un fichero, ya que la ruta de mailq dentro de nuestro utils no es correcta: root@zmmt00:/home/sistemas# vi /usr/lib/nagios/plugins/utils.pm Y cambiar el $PATH_TO_MAILQ que apunta a /usr/bin/mailq
Por lo siguiente /opt/zimbra/postfix-2.10.1.2z/sbin/mailq que es la ruta correcta en Zimbra
Ejecutando el check de nuevo, veremos que ya podemos ver el número de mensajes en cola, 6 en mi caso.
