Guía minimización del impacto de un incidente de seguridad sobre la información de una empresa

¡Buenas a todos! Sí que hace tiempo sí! 5 meses para un nuevo post es demasiado tiempo pero no he estado demasiado motivado para escribir, aunque no he dejado de hacer cosas y leer.

En esta entrada traigo una guía para mitigar el impacto de un incidente en los procesos de negocio de la empresa. Con ella pretendo poner en negro sobre blanco resumido, adaptado y completado el contenido de un vídeo muy interesante del que he podido disfrutar mientras hacía un curso de Incibe relacionado con la Ciberseguridad para PYMES y Autónomos. 

Esta guía podría formar parte del Plan de Contingencias TIC de una Organización que a su vez podría formar parte del Plan de Continuidad de dicha Organización. Porque no es lo mismo un Plan de Contingencia que un Plan de Continuidad de Negocio. No está en el alcance de esta entrada especificar los detalles de cada uno de los planes, pero ya que hemos tocado el tema los definiré.

Un Plan de Contingencia TIC [1], “estrategia planificada en fases, constituida por un conjunto de recursos de respaldo, una organización de emergencia y unos procedimientos de actuación, encaminados a conseguir una restauración ordenada, progresiva y ágil de los sistemas de información que soportan la información y los procesos de negocio considerados críticos en el Plan de Continuidad de Negocio de la compañía”. Está más orientado a nivel de IT.

Por otro lado, un Plan de Continuidad de Negocio está por encima del Plan de Contingencia, más a nivel de negocio, según ISACA "Proceso destinado a reducir los riesgos del negocio de una organización originados en una interrupción inesperada en las funciones/ procesos (manuales o automáticos) necesarios para la supervivencia de la organización. Esto incluye los recursos humanos/ materiales que dan soporte a estas funciones/ procesos críticos así como el aseguramiento de la continuidad del nivel mínimo de servicios necesarios para las operaciones críticas".

La guía contendrá una serie de aspectos a considerar para minimizar y mitigar el impacto de los incidentes de seguridad que se pudieran producir en las Organizaciones derivados de los riesgos a los que éstas se encuentran expuestos.

1.     Documentar el equipamiento esencial de la empresa

• Lista de equipos de la empresa

• Crear y establecer una estrategia de acceso seguro a la información almacenada.

2.      Centralizar la información y crear copias de seguridad

• Reunir toda la información/ documentación esencial de la organización en un repositorio documental.

• Realizar copias almacenadas físicamente fuera de las instalaciones de la organización. La frecuencia y el tipo de copias de seguridad deberá estar relacionado con la criticidad de la información que se respalda.

• Documentar el proceso de recuperación de copias con la finalidad de:

• Agilizar el proceso de recuperación frente a alguna contingencia

• Comprobar periódicamente que sabemos y podemos restaurar las copias, así como si éstas se están llevando a cabo correctamente.

3.      Identificar los contratos externos esenciales

• Lista con información de contacto de personas y/ o empresas ajenas a la organización cuya ayuda se podría necesitar en caso de que se produzca un incidente que pueda comprometer la continuidad del negocio.

4.      Determinar el equipo de contingencia

• Hacer uso de proveedores de equipamiento alternativo en caso de que el equipamiento de la empresa resulte dañado.

• Identificar Servicios, Equipos y Recursos que cada proveedor podría proporcionar en caso de contingencia. Con esto se gana tiempo, dado que de lo contrario cuando surjan las necesidades tendríamos que proceder a buscar y comparar los proveedores y no debe ser el momento de hacerlo.

5.      Localizar una ubicación de contingencia

• Ubicación temporal de la empresa o servicio de la misma, dentro de las instalaciones de la empresa o fuera donde se llevarán a cabo las operaciones de la empresa mientras la ubicación original no esté disponible.

• Desde la ubicación temporal deben estar accesibles la información así como los recursos necesarios para que el personal pueda desarrollar su trabajo.

6.      Determinar quién puede realizar teletrabajo

• Si hubiera operaciones que no pudieran continuar en las instalaciones de la empresa y dichas operaciones pudieran realizarse fuera de la misma, el teletrabajo es una opción para que los empleados puedan realizar las funciones propias de sus puestos de trabajo.

• Si se considera el teletrabajo como una opción habría que dotar de una conexión segura la conexión con la organización. Para ello sería conveniente la utilización de un servidor VPN con lo que la información que pase a través del túnel creado vaya cifrada garantizando su confidencialidad.

7.      Formación de los empleados sobre las herramientas que utilizan

• Formación de los empleados para que utilicen de forma correcta los sistemas corporativos.

• Establecer las políticas y los medios necesarios para que los empleados no puedan instalar software sin autorización.

• Navegar por páginas web de contenido de dudosa reputación.

• Concienciación y buen uso del correo electrónico corporativo.

• Cumplimiento de las políticas de seguridad de la empresa.

No es una tarea simple, pero este esfuerzo ahorrará importantes pérdidas económicas así como el desgaste de la imagen de la Organización en caso de producirse un incidente de seguridad.

Todo ésto tiene que ir como he mencionado en ocasiones anteriores a crear una cultura de Seguridad de la Información en la empresa, nadie dijo que fuera fácil.

¿Te ha parecido interesante la entrada? ¿Aburrida? ¿Útil? ¿Patética tal vez? Estaría encantado de que me comentaras tus impresiones y opiniones, así como de completar la entrada con tus sugerencias y apreciaciones.

¡Nos leemos en la próxima! Espero que no sea dentro de 5 meses... 

¡Un saludo!

Referencia

https://www.incibe.es/blogs/post/Empresas/BlogSeguridad/Articulo_y_comentarios/Contingencia_vs_Continuidad

Compra segura por Internet

¡Feliz y seguro año 2016!
Hoy, día 1 de Enero de 2016 y con la entrada del nuevo año tenía pendiente la publicación de una entrada relacionada con la seguridad en las compras on-line. Lo sé habría sido más útil haberla publicado antes de las fiestas navideñas y seguro que alguien más se hubiera beneficado de los consejos y medidas de seguridad que proporcionaré. Todavía tenemos por delante los Reyes, ¿tienes pendiente alguna compra por Internet? Si es así, creo que esta entrada te resultará muy útil.

A continuación describiré algunas de las medidas de seguridad y precauciones que tomo personalmente y recomiendo cuando compro algo por Internet. Seguro que a muchos de vosotros os parecerán paranoicas algunas de ellas, y entiendo que no todo el mundo, en todo momento pueda tener los recursos para desarrollarlas tanto de conocimientos (que intentaremos subsanar en parte con esta entrada) como materiales (tampoco necesitamos nada del otro mundo pero podemos no tenerlos disponibles en un momento dado).
¿Recursos materiales?¿Qué vamos a hacer manualidades o algo? No, pero para los consejos que propongo hacen falta algunas cosillas más allá del sentido común y de un pc.
Necesitaremos un cable Ethernet y un pendrive con una distribución Gnu/Linux. ¿Por qué? Ahora lo veremos.
Las primeras medidas básicas de seguridad a la hora de comprar en Internet deben ser las medidas generales de seguridad que debemos estar implementando diariamente. Dichas medidas son el sentido común (que obviamente es el menos común de los sentidos) y mantener nuestros sistemas actualizados. Esto incluye si haces uso de un programa antimalware tenerlo activo y actualizado. ¡Tópicos a mí!
Una vez dado por supuestos que vamos a estar mentalmente activos frente a posibles "trampas" que podamos encontranos por Internet y con nuestros sistemas perfectamente actualizados, siento decirte que todo ello puede no servir de nada llegado el momento, pero ayuda. Recuerda que la seguridad al 100% no existe.
Vale empezamos con los consejos y medidas de prevención que podemos tomar. Me gustaría que en los comentarios me dijérais paranoico si realmente lo pensáis, así como que medidas adicionales tomáis, o si alguna de las que a continuación expongo os parecen inútiles. Creo que puede ser una entrada algo larguita pero estoy seguro de que merece la pena invertir 5 minutos en leerla.

Medidas

• Primero, no llevar el proceso de compra a cabo desde ordenadores que no sean de confianza. Con nuestras máquinas si tomamos nuestras medidas de seguridad siempre serán más fiables que los ordenadores de terceros que sabrá Dios cómo lo tendrán...

• Segundo, a ser posible dentro de las posibilidades de cada uno, no llevar a cabo transacciones bancarias a través de una conexión Wifi. Ni mucho menos desde "wifis" públicas. Wifis publicas... Caca! De ahí que necesitemos un cable Ethernet, cogemos nuestro cable y conectamos el ordenador a nuestro router o dispositivo de red local. En las"wifis" nunca se sabe. El tema de la seguridad en las redes inalámbricas es superinteresante pero se sale del alcance de esta entrada. No descarto tratar algunas cuestiones independientes en alguna entrada futura. Bien Jose Mari, pero resulta que por lo que sea no puedo tirar el cable hasta el router. Bueno, en este caso podriamos llevar a cabo una comprobación previa a usar la wifi, y es analizar quién está conectado a la red relacionada con la red wifi a través de la cual vamos a comprar. ¿Cómo lo hacemos? 
• Uno, nos conectamos al router y buscamos quien está conectado a la red.
• Dos y más fácil, con una aplicación móvil (con el móvil conectado a la red, yo uso para Android Fing aunque hay muchas) vemos quien está conectado a la red. Esto es una práctica que recomiendo hacer asiduamente nunca se sabe quien puede estar husmeando en nuestra red. Debemos tener controlado nuestros dispositivos conectados, si vemos algo raro mi consejo es cambiar inmediatamente la clave de la red wifi.

• Tercero, yo siempre uso una distribución Gnu/Linux para este tipo de tareas y en la medida de los posible una distribución actual live arrancada desde un pendrive. De este hecho deriva la necesidad de un pendrive con Gnu/Linux. Lo sé rozo la paranoia... ¿O quizás nade en ella? El por qué uso Gnu/Linux para este tipo de tareas tampoco está dentro del alcance de esta entrada, pero para los que no seáis técnicos deciros que en terminos generales (aunque algún técnico puede no estar de acuerdo) Gnu/Linux es más seguro que las plataformas basadas Windows, aunque Windows ha mejorado mucho. Resumiendo, que si podéis os hacéis con un penlive con una distro Gnu/Linux y la "correis". Cuando arranquemos nuestra distro Gnu/Linux si podemos/ sabemos/ queremos la actualizamos.

• Cuarto, el navegador, nuestro caballo de batalla. Independientemente del Sistema Operativo (SO) que utilicemos ojito con nuestro navegador. Es importante que esté actualizado, y además nada de Java, flash y Acrobat Reader. En ellos está el demonio... (¡Risas!) Pero José Mari, ¿quién hoy día no utiliza Java, flash o Acrobat reader? Parafraseando a un gran profesor del Master que tuve: "Mucha gente en su sano juicio". Entre otras cosas por eso uso una distro live, porque por defecto no suelen traer instalados dichos programas, que pueden suponer un riesgo de seguridad para nuestros sistemas. Cuanto más programitas de estos tengamos instalados, corriendo mientras intentamos comprar por Internet más papeletas tenemos de que algún tipo de malware explote alguna de sus vulnerabilidades comprometiendo nuestro sistema y nuestros datos bancarios. ¿No nos gustaría verdad?

 

Vale Jose Mari como sigamos así necesitamos una hora nada más que para empezar... Creeme, no supone tanto tiempo y es una inversión de tiempo que sale muy rentable.
Hasta el momento nos hemos conectado con cable al router, hemos arrancado una distro Gnu/Linux live, no tenemos corriendo ni java, flash ni Acrobat reader y tenemos actualizado el navegador. Mola. ¿Ahora qué? Pues habrá que intentar comprar considerando las peculiaridades y los servicios ofrecidos por cada una de las entidades bancarias.

• Quinto, Siempre que nuestro Banco nos ofrezca el servicio de utilizar para nuestras transacciones tarjetas virtuales las usaremos. Existe un auténtico tráfico en manos de cibercrimilaes, mafias, etc de tarjetas de bancos con los datos de gente desde las que se les roba el dinero. Por lo que, en la medida de lo posible NO poner los datos de nuestras tarjetas reales/ físicas en las transacciones que realicemos.

• Sexto, la url, es decir la dirección de la página web de nuestro banco. Siempre que nos sea posible es preferible escribirla y no acceder a ellas desde "enlaces dudosos". La siguiente circunstancia es crucial, si el navegador os arroja un error en el certificado... ¡Miedito, alerta, alarmas sonando! El tema de los certificados, las entidades certificadoras, etc es un tema muy extenso en sí mismo que se escapa del alcance de esta entrada pero sólo apuntar que se basa en la confianza, y en la comprobación de que una entidad es quien dice ser. Pero la realidad es que alrededor de este tema pueden surgir numerosos problemas. No entraremos ahí. Nos quedaremos en que como regla general si nos estamos conectando a la dirección correcta de nuestro banco el navegador no debe arrojar ningún error de certificados, y tendremos que tener muy en cuenta la dirección del mismo. Ojo con no conectarnos a una página de una "entidad" que se parezca en el nombre, el navegador no falle, nos creamos que estamos en la página correcta y allí comprometamos nuestra información bancaria. Un ejemplo de lo que he querido decir, supongamos que nuestro Banco es el Santander y que su web es https://bancosantander.es y nosotros cometemos un error al escribir la url o de alguna manera a través de un navegador llegamos al sitio https://bancosamtander.es. El certificado del sitio puede darse por bueno, allí podríamos meter nuestras credenciales, etc y comprometer nuestas información. Aquí entra en juego nuestro sentido común. Tenemos que conocer la url de nuestro banco en la medida de nuestras posibilidades. Si lo buscamos a través de un buscador, después nos cercioraremos de que la url es la correcta, que no da error de certificado el navegador, etc.

• Séptimo, seguridad en las comunicaciones entre nuestro navegador y el servidor web del banco. Las páginas de nuestros bancos deben empezar por https no por http si es así desconfiar y contrastar la drección de la página o url. Para los que no seáis técnicos a grandes rasgos la s de https está relacionada con una conexión segura en la que se cifrarán las comunicaciones entre el navegador y el servidor web con la seguridad que esto proporciona en caso de que las comunicaciones sean interceptadas.

• Octavo, método de confirmación de transacciones. Los bancos implementan al menos dos medidas relacionadas con la identificación de los individuos en la red. Suele ser algo que sabes (credenciales de acceso), y algo que se tiene (tarjeta de coordenadas, mensaje al móvil con un token, etc). Bueno pues los bancos no nos pedirán NUNCA que pongamos todos los datos de nuestras tarjetas de coordenadas si la tuviéramos, nuestro sentido común nos tendría que alertar. ¿Por qué? Porque para qué quieren saber todos los datos de la tarjeta de coordenadas, si el Banco las conoce porque nos la facilitó. Si nos pide unas coordenadas concretas es para asegurarse de que tenemos dicha tarjeta de coordenadas por ser nosotros quien decimos ser.  Parece de perogrullo pero es importante, ponemos un ejemplo. Imaginemos que nos hemos conectado a una página de un Banco creyendo que era la "página buena" de nuestro Banco porque la página se parecerá muchísimo por no decir que puede ser clonada, hemos metido nuestras credenciales ("los malos" ya tendrían nuestras credenciales de acceso con las que podrán ir a la página real del Banco) y si encima nos solicitan todas las casillas de nuestra tarjeta de coordenadas y nosotros se las damos pues lo tienen todo para operar con nuestro dinero como si fueramos nosotros.

• Noveno, si la página de nuestro banco nos ofrece un teclado en pantalla a la hora de introducir códigos lo utilizaremos. Esto nos ayudará en caso de estar "infectado" por un keylogger y evitará que este capture nuestras pulsaciones del teclado.

Hasta aquí mis consejos para efectuar de una manera segura unas compritas por Internet. Recuerda la seguridad al 100 % no existe.
¿Te ha gustado? ¿Te ha resultado útil? Espero que sí.
¿Nos leemos en la próxima? Eso espero.

Privacidad y Seguridad en Internet.

¡Hola de nuevo!
Quería publicar la que posiblemente sea la última entrada del año, y compartir un ratito más con ustedes que visitáis mi Blog,vuestro Blog.
Estoy leyendo el libro de Antonio Salas, Los hombres que susurran a las máquinas y tengo que decir que me está gustando mucho y lo recomiendo, aunque hasta que no lo termine no podré tener una opinión completa y formada del mismo.
En él he leído algunas analogías muy interesantes que me han inspirado a la creación de esta entrada. En las páginas 66 y 67 podemos leer:

"Nuestra vida digital transcurre en casas de cristal, pero las cortinas están al otro lado del vidrio. No tenemos control sobre ellas. Mantenemos nuestra fantasía de intimidad mientras no hagamos nada que pueda despertar la curiosidad del casero, porque él es quien puede correrlas, cuando le apetezca, para ver que estamos haciendo."

Tras leer esto es imposible que no se nos venga a la cabeza el famoso caso de espionaje de la NSA con programas de vigilancia masiva como PRISM o Xkeyscore desvelado por Edward Snowden.
Aquí, en casa en estos días, España ha comprado un sistema de vigilancia masiva denominado Evident X-Stream por unos 12 Millones de Euros. Evident X-Stream es una tecnología que facilitará el control de las comunicaciones y actividades de la población. Dicha herramienta será controlada por los cuerpos y fuerzas del Estado. Este sistema vendrá a sustituir a SITEL.
Como hemos hablado en otras ocasiones hay que alcanzar una solución de compromiso en la difícil ecuación que contiene variables como la Seguridad y la Privacidad, intentando obtener un complicado equilibrio. En estos tiempos difícles que estamos atravesando con ataques terroristas, etc este tipo de cuestiones siempre están en el centro del debate. ¿Qué opinas?
¿Qué si ésto se convertirá en un Gran Hermano a lo G. Orwell? Estoy seguro de que ya lo es.
Lo peor es que no nos damos cuenta de la cantidad de información que proporcionamos en nuestras interacciones con Internet y las redes sociales. Se indexan nuestras búsquedas, me gustas, ficheros subidos a no se que sistemas/ servicios de intercambio de ficheros, llevamos a cabo publicaciones de todo tipo, de hasta por donde corremos, si nos hemos ido de viaje, no desactivamos las coordenadas gps de las fotos que subimos, etc,etc. ¿Lo habías mirado desde ese prisma?
Si eres de los que piensan que puedes decir y/ o hacer en internet lo que quieras sin consecuencias estás muy equivocado... Si realizas apología del terrorismo, intentas suplantar o suplantas un estado civil, y demás "cosas malas" vivirás más temprano que tarde una escena de película de acción en tu casa. Y no olvides que lo que subes a Internet subido queda, y lo que dices dicho queda...
¡Cuidadín con venirnos arribita con según que comentarios, estados y publicaciones!No sabemos si mañana nos podemos arrepentir de ellos. Como dice mi amigo Pepe, "No demos tres cuartos al pregonero". Piensa que estamos conformando nuestra imagen digital, la imagen que tiene la gente, las empresas de tí en Internet. ¿Cómo quieres que te vean?
Internet es genial, pero vívela con sentido común y responsabilidad. Hazte el favor.
Esto me sirve para enlazarlo con otro fragmento del libro de Antonio Salas que me encantó, repito, si tienes la oportunidad de leerlo hazlo. En la página 94 podemos leer:

"Hoy un anciano de ochenta años y un niño de ocho saben que tiene que mirar a ambos lados al cruzar la calle, que no deben internarse en plena noche (ni tampoco de día) en barrios de dudosa reputación y que si no quieren que les roben sus bienes más preciados, deben guardarlos bajo llave... Pero no sospechan que en Internet también existen lugares de mala reputación. Que deben leer a un lado y a otro antes de darle al clic. Y que para que no les roben sus vidas digitales, deben guardarlas bajo contraseñas seguras."
 

No te fíes de Internet, tampoco le tengas miedo, pero valora tu información, vale mucho dinero aunque no te lo creas. Entre todos tenemos que concienciar a los que tenemos a nuestro alrededor de que la Seguridad en todo lo que hacemos en Internet es importante, como en la vida real. A nadie se le ocurriría coger un coche que no frena, o como dice Antonio Salas en su libro no te meterías en según que barrios, ¿no?
Hay en internet muchos lugares con mucha información buenísima, repleta de consejos, etc. Además de éste claro...
Porque la Seguridad no va sólo de tecnología, va de personas. Y somos vulnerables.
Gracias por leerme. Me encantaría que complementáramos esta entrada con tus reflexiones y opiniones, con ellas la haríamos una entrada buena.
A continuación pongo unos enlaces que me parecen muy interesantes.
¡Hasta la próxima!

Enlaces:

http://www.elladodelmal.com/2015/12/evident-x-stream-deep-packet-inspection.html

http://www.pabloyglesias.com/el-control-por-el-control/

Envío de correos desde scripts

¡Hola de nuevo!
Esta vez traigo una entrada muy interesante y útil (como todas XD) para poder mandar mails desde scripts.
Esta misma semana me he tenido que repasar como hacerlo dado que quería desarrollar un script y desde él a través del comando mail mandar correos.
¿Cómo lo vamos a hacer? Ante todo fácil, sólo para mandar correos no necesitamos configurar un servidor de correo completo, ni configurar las DNS para el correo entrante con un dominio propio, etc.
Existen varias opciones para poder satisfacer la necesidad de envío de correos, me centraré en dos opciones que considero las más fáciles como son Exim4 y sSMTP. Exim4 sólo lo configuraremos para envíar correos.
Configuraremos tanto sSMTP como Exim4 para que envíen correos a través de otro servidor de correo. Básicamente configuraremos sSMTP y Exim4 como configuramos por ejemplo nuestras cuentas de correos en nuestros smartphones a través de una app de gestión de correos, en las que les proporcionamos los parámetros de envío y recepción de correos del servidor.En nuestro caso, en esta entrada los configuraremos través de gmail, usando una cuenta ficticia info.ejemplo@gmail.com cuya contraseña será Passcuentainfo.ejemplo.
En vez de a través de gmail podríamos configurarlos con cualquier otro servidor de correo, por ejemplo, uno que tengamos montado en nuestras empresas.

sSMTP

sSMTP es MTA simple (no es un servidor de correo completo) para enviar correos desde una máquina a través de otro servidor de correos. Es una herramienta sencilla, liviana, segura (cuando se utiliza adecuadamente) y no hace uso de demonios con el consiguiente ahorro de recursos. A diferencia de Exim4, sSMTP no recibe correo, no hace uso de alias ni administra colas.
De forma general un componente importante de la seguridad del correo electrónico, además del uso de la firma digital y el cifrado, es la protección de sus intercambios de autenticación para las conexiones con los servidores de correo, sSMTP proporciona funcionalidad para el uso de TLS / SSL para proteger las conexiones con el servidor SMTP.


Exim4

Exim4 a grandes rasgos es un servidor de correo monolítico completo con un formato de configuración sencillo por lo que resulta más fácil de configurar que otros servidores de correo como Sendmail. Con un dominio propio y las DNS correctamente configuradas Exim4 puede gestionar el envío y  la recepción de correos desde/ hacia dicho dominio. Exim4 sí hace uso de demonios para su funcionamiento.

Instalación, configuración sSMTP

La instalación y configuración la llevaremos a cabo en una máquina Gnu/Linux con Debian. En la Red hay muchos recursos al respecto pero quería hacer "mi versión" con mis palabras para quizás hacerlo si cabe más claro.

Instalamos ssmtp y mailutils
#apt-get install ssmtp mailutils

A continuación configuraremos sSMTP editando el fichero de configuración /etc/ssmtp/ssmtp.conf. Antes es de "buena educación" hacer una copia de dicho fichero por si nos liamos y algo va mal, siempre podamos contar con el original.

Hacemos una copia del fichero de configuración
#cp /etc/ssmtp/ssmtp.conf /etc/ssmtp/ssmtp.conf_original
Editamos /etc/ssmtp/ssmtp.conf con nuestro editor favorito, yo utilizaré nano
#nano /etc/ssmtp/ssmtp.conf

Ahora se muestra el contenido del fichero comentando/ aclarando un poco cada parámetro

#
# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
#Esta cuenta es la que recibiría los correos, pondremos la cuenta de gmail que configuraremos o la dejamos #en blanco ya que no gestionaremos con ssmtp la recepción de correos
root=info.ejemplo@gmail.com

# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named mail.domain.com
#Servidor de correos que usaremos para enviar los correos
mailhub=smtp.gmail.com:587
AuthUser=info.ejemplo@gmail.com
AuthPass=Passcuentainfo.ejemplo
#Añadiremos las siguientes dos líneas para decirle a ssmtp que cifre las comunicaciones con el server
UseTLS=Yes
UseSTARTTLS=Yes

# Where will the mail seem to come from?
#Es el nombre del dominio que queremos mostrar como enviador, pero sólo será visible si abrimos el correo #con las cabeceras de lo contrario veremos la cuenta de gmail que configuremos para el envío
#Ejemplo de correo de pueba X-Google-Original-From: "root" <root@micasa.com>rewriteDomain=micasa.com
# The full hostname
#Si abrimos el correo original con las cabeceras veremos una línea que hace referencia a este parámetro
#Ejemplo línea mensaje original correo de prueba Received: from sysinfo
hostname=sysinfo

Hasta aquí lo relacionado con el contenido de ssmtp.conf

Esta configuración tiene un problema claro de seguridad tanto en cuanto la clave de la cuenta que utilizaremos para enviar correos aparece en claro. Realmente no es lo suyo, sería más adecuado que se le pudiera pasar un fichero con la clave cifrada en él. Una vez más debemos alcanzar un equilibrio entre funcionalidad y seguridad.
Para asegurarlo un poco, lo protegeremos por permisos y cambiaremos su propietario a root y su grupo a mail.

#chmod 640 /etc/ssmtp/ssmtp.conf
#chown root:mail /etc/ssmtp/ssmtp.conf

Hay que tener en cuenta que tendremos que añadir al grupo mail los usuarios del sistema a los que queramos permitir enviar correos, por ejemplo, si quisiéramos permitir al usuario josemaria enviar correos deberíamos ademas ejecutar:

#adduser josemaria mail


Instalación, configuración Exim4

La instalación y configuración de Exim4 la llevaremos a cabo en una máquina Gnu/Linux con Ubuntu Server en esta ocasión. En la Red hay muchos recursos al respecto pero quería hacer también con Exim4 "mi versión".
Una cuestión importante a la hora de hacer uso y antes de instalar Exim4, es que si tenemos instalado Sendmail debemos desinstalarlo porque pueden surgir problemas de incompatibilidades.

#apt-get purge sendmail

Instalamos Exim4
#apt-get install -f exim4

Configuramos Exim4
#dpkg-reconfigure exim4-config

 
 

Seleccionamos enviar a través de smarthost porque haremos uso de otro server para enviar los correos.

Establecemos nombre de sistema de correo por ejemplo correo.prueba.es.

Aceptamos las direcciones ipv4 e ipv6 que aparecen.

Otros dominios con los que se configura el correo lo dejamos en blanco.

Otras máquinas a las que reenviar correo lo dejamos también en blanco.

Aquí configuramos la dirección y el puerto del servidor a través del que enviaremos los correos, en este caso es gmail pero podríamos configurar otro.

Decimos No a ocultar la dirección de los correos salientes.

Seleccionamos No al límite de consultas DNS

Seleccionamos mbox como formato de almacenamiento de correo local.

A continuación se reiniciará el MTA...

El siguiente paso es editar con nuestro editor preferido el fichero que contendrá los datos relacionados con las credenciales de la cuenta con la que enviaremos los correos a través del servidor de gmail. Dicho fichero es /etc/exim4/passwd.client.

#nano /etc/exim4/passwd.client

Se muestra un ejemplo del contenido del fichero /etc/exim4/passwd.client donde tendremos que añadir las líneas que están en negrita

# password file used when the local exim is authenticating to a remote
# host as a client.
#
# see exim4_passwd_client(5) for more documentation
#
# Example:
### target.mail.server.example:login:password

gmail-smtp.l.google.com:info.ejemplo@gmail.com:Passcuentainfo.ejemplo
*.google.com:info.ejemplo@gmail.com:Passcuentainfo.ejemplo
smtp.gmail.com:info.ejemplo@gmail.com:Passcuentainfo.ejemplo

Hasta aquí el fichero de ejemplo

Reiniciamos servicio de exim4

#/etc/init.d/exim4 restart

Ejemplo de uso

Con independencia de la solución que adoptemos, en nuestros scripts podemos mandar correos mediante el comando mail.

Un ejemplo sencillo sería:

#echo "prueba correo desde exim4"|mail -s "Test desde Exim4" correo.destino@dominio.com

Con -s Especificamos un asunto y correo.destino@dominio.com es la dirección a la que queramos mandar el correo.

El comando mail tiene un mayor número de parámetros, podremos encontrar información al respecto a través de man o en la Red.

Como en cada entrada, sólo pretendo hacer referencia a lo más importante y funcional, e intentar ser un buen punto de partida en los diferentes temas tratados. De estas cuestiones hay mucho escrito, donde podremos indagar y encontrar las soluciones que mejor se adapten a nuestras necesidades.

Espero que os haya resultado al menos útil.

Me gustaría completar y añadir valor a mi blog con tus comentarios, experiencias, etc. ¿Me ayudas?

Nos leemos en la próxima entrada.

¿De qué será? Tengo algo en la cabeza pero no lo tengo decidido.

Saludos.

Fuentes

http://www.techrepublic.com/blog/it-security/use-ssmtp-to-send-e-mail-simply-and-securely/

https://wiki.debian.org/es/sSMTP

https://jolthgs.wordpress.com/2012/05/15/configurar-exim4-como-smarthost-para-envio-de-avisos-del-sistema-por-e-mail/

Miniguía tcpdump

¡Hola de nuevo!¿Qué de tiempo no?
Llevo dos meses queriendo redactar esta entrada con las anotaciones que me hice en verano en una hojita guarra que hacía las veces de chuleta. Lo reconozco, he estado a punto de perderla y/ o tirarla en varias ocasiones y quería redactar esta entrada para poder despreocuparme de que si la tiro o la pierdo.
Reconozco y me da mucho coraje (pero lo hago) mirar 7 veces lo mismo...Miro un tema porque me interesa y/ o me hace falta manejarlo, durante unos días genial "lo tengo fresquito". Al cabo de los días... De no usarlo... Uff! Olvido los parámetros, el orden de los mismos...
Pues a mirarlo otra vez, ahora no encuentras las fuentes que tanto te sirvieron la vez anterior...¡Se acabó!Me hago una chuletilla, miro algún libro, consulto en internet etc y lo pongo por escrito en mi blog. La próxima vez ya sé donde mirar directamente.
Con tcpdump me ha pasado ésto en varias ocasiones, por lo que a continuación describiré unos ejemplos básicos que nos servirán para despegar con tcpdump. En la Red hay multitud de material al respecto, y tcpdump es una herramienta para escribir una biblioteca.
Yo sólo pretendo proporcionar unos ejemplos básicos y a la vez útiles que nos permitirán resolver un porcentaje importante de los problemas a los que nos enfrentaremos, intentando hacer efectivo el principio de Pareto o del 80-20.Resumiéndolo muy mucho viene a decir que el 80% de lo que necesitas saber se encuentra en el 20% que resulta más importante. Ya me estoy yendo por las ramas otra vez.No aprendo.
Tcpdump es un sniffer de red supercompleto por línea de comandos muy útil porque no siempre se dispone de entorno gráfico en el que podríamos usar por ejemplo wireshark. Con él podremos ver los paquetes que viajan por la red/ segmento de red a las que están conectadas las interfaces de la máquina que ejecuta tcpdump y decidamos "escuchar".
Tcpdump proporciona una gran potencia y granularidad, por ejemplo hasta nivel de flags en cabeceras tcp entre otras cosas. Una pasada.
El scope de esta entrada no pretende abarcar tanto aunque dejaré algunos enlaces interesantes para profundizar o mirar algo más concreto algún día.
Empecemos.
Hacer notar que para ejecutar tcpdump es necesario ser/ tener permisos de root.

#tcpdump -D --> Saca una lista con las interfaces disponibles

#tcpdump -i eth0 --> Definimos la interfaz eth0 para "escuchar"

#tcpdump -i eth0 [tcp|udp|icmp] --> Filtra lo que escucha por eth0 por protocolo

#tcpdump -i eth0 not icmp --> Captura el trafico que escucha por eth0 menos el trafico icmp, especificado por not icmp

#tcpdump -i eth0 tcp port 80 --> Captura el tráfico tcp que escucha por eth0 que vaya por el puerto 80. Con port filtramos un puerto

#tcpdump -i eth0 -w captura --> Guarda el tráfico que "escucha" por eth0 en un fichero denominado captura

#tcpdump -r captura --> Lee la captura de tráfico recogida en el fichero captura

#tcpdump src 192.168.1.29 [and|or] dst 192.168.1.105 --> Captura trafico con origen (src) en 192.168.1.29 [and|or] destino (dst) 192.168.1.105

#tcpdump 'src 192.168.1.29 and (dst 192.168.1.105 and icmp)' --> Ojo con las expresiones anidadas, si no les ponemos comillas simples nos arrojarán un error.

#tcpdump ether [src|dst] AA:BB:CC:DD:EE:FF --> Captura el trafico con origen|destino (src|dst) con la MAC (ether) AA:BB:CC:DD:EE:FF 

#tcpdump -i eth0 [-v|-vv|-vvv] --> Captura el trafico que llega a eth0 con un nivel de detalle definido por -v,-vv,-vvv cada cual con más detalle

#tcpdump -i eth0 [-n|-nn] --> Captura el tráfico que llega a eth0 pero no resuelve los hostname con -n, o no resuleve ni los hostanames ni los puertos con -nn

#tcpdump -i eth0 -c100 --> Captura 100 paquetes de los que le llegan por la interface eth0 y se para.

#tcpdump -s 0 --> Captura todos los bytes que conformen los paquetes

Con una combinación de todo lo anterior podemos afrontar el filtrado de una gran cantidad de situaciones. Siempre nos quedará #man tcpdump.
Espero que os haya resultado interesante y útil la entradita.
Me encantaría completarla con las aportaciones de vuestros comentarios.
¿Alguien se anima?
¡Vamos!
Bueno...Al menos nos leemos en la próxima entrada ¿no?

 Fuentes y enlaces interesantes

https://danielmiessler.com/study/tcpdump/
http://www.hackplayers.com/2013/12/que-deberiamos-saber-sobre-tcpdump-1.html
http://www.hackplayers.com/2013/12/que-deberiamos-saber-sobre-tcpdump-2.html
http://www.hackplayers.com/2014/01/que-deberiamos-saber-sobre-tcpdump-3.html
http://rm-rf.es/tcpdump-ejemplos/

Blacklist y SPF en Zimbra

¡Hola de nuevo!
Traigo una nueva entrada relacionada con un tema tan extenso como es el del correo electrónico. Vamos a tratar un caso real de envío/recpción de correos fraudulentos relacionados con la suplantación del remitente, llevar a cabo una valoración de las causas que pudieron provocarla, así como unas recomendaciones básicas para evitarlas y contrarestarlas.
También se hará referencia a la creación de una blacklist/whitelist en Zimbra, una introdución a SPF y su activación también en Zimbra.
¿Zimbra?
Zimbra es una suite colaborativa que proporciona servicios de correo electrónico.
Más información podemos obtenerla aquí.

Hace algunos días un amigo me comentó que había sufrido un incidente de seguiridad que aún estaba investigando,posiblemente relacionado con un caso de physing en el que se podría haber visto comprometida su cuenta de correo, o al menos sus contactos.

¿Cómo se dio cuenta?

 
Detectó que recibía reportes ante la imposibilidad de entregar correos destinados a muchos de sus contactos,recibió correos con nombres parecidos (sospechosos) al de sus contactos en la que la dirección del remitente era la suya y varios de sus compañeros le llamaron para preguntarle acerca de que era ese correo que estaba mandando.
Dicho correo contenía un enlace a una página donde se solicitaban datos que de ser proporcionados serían robados.
Él no había llevado a cabo esos envíos, y dichos correos no se encontraban en su bandeja de enviados. Abrió el correo junto con todas sus cabeceras y pudo observar que los envíos se estaban llevando a cabo desde otro dominio.
Por lo que de alguna manera, habían "secuestrado" sus contactos y habían "spoofeado"/suplantado la dirección del remitente utilizando la suya.
Esta circunstancia es muy peligrosa porque según que usuarios pueden "picar" y proporcionar la información indebidamente pensando que se trataba de un correo legítimo del remitente, pudiendo ser utilizada la información comprometida recabada para futuros usos fraudulentos.Aquí ha entrado en juego la ingeniería social.

¿Cómo pudo verse comprometido su correo y/o sus contactos?

 

• Esta circunstancia pudo ser motivada por:Si se hace uso de servicios de correo electrónica vía web pudo ser provocado por la explotación de alguna vulnerabilidad del navegador, flash, java, acrobat reader o algún complemento del mismo en la que hubieran quedado expuesta la cuenta de correo y/ o sus contactos.

• Explotación de alguna vulnerabilidad del sistema operativo, de alguna aplicación de gestión de correo electrónico o de gestión de contactos por parte de algún tipo de malware.

• Haber sido presa de alguna app maliciosa de gestión de contactos en su smartphone

• Haber sido presa/ victima de algún "artefacto" de ingeniería social.

¿Qué medidas se deben tomar en estas situaciones?

• La primera y más urgente cambiar la contraseña de la cuenta de correo.

• Revisar las versiones del navegador, flash, java, Acrobat Reader, etc y llevar a cabo las actualizaciones necesarias.

• Actualizar el sistema operativo y las aplicaciones instaladas, prestando especial atención a las relacionadas con la gestión de correos y/ o contactos.

• Revisar las apps del smartphone en busca de alguna sospechosa haciendo especial hincapié en las relacionas con la gestión de correos y/ o contactos.

• Hacer uso de algún sistema antivirus/antimalware.

• Además de las precauciones básicas a la hora de navegar, instalación de aplicaciones, etc, incrementar el nivel de atención a la hora de fiarnos de los correos que recibimos, no sólo del nombre mostrado sino también prestar atención a la dirección desde la que se manda  el correo. En caso de duda eliminarlo y por supuesto no abrir ninguna url que éstos pudieran contener.

Medidas técnicas

 
La seguridad en un servidor de correo es un tema muy interesante y extenso que se escapa del objeto de esta entrada, aunque no descarto dedicarle una en el futuro. En esta entrada sólo daremos "dos pinceladas".
 

Activar Sender Policy Framework (SPF) es un sistema de validación de correos electrónicos basado en la comprobación de que el remitente efectivamente tiene permiso para enviar correos con el dominio desde el que lo hace mediante la verificación de la dirección IP del remitente con un servidor DNS.

La siguiente imagen muestra de forma gráfica como funciona.

Esto permite prevenir el "spoofeado"/ suplantación de los remitentes, ayudando a reducir el correo spam.
Es muy importante configurar bien SPF de lo contrario se puede sufrir problemas con el envío de correos.
 

Por otra parte, podemos querer crear una blacklist para evitar recibir correos desde un dominio, una determinada cuenta de correo a nuestro servidor zimbra.

Creación de blacklist en Zimbra

A continuación se expone como elaborar una blacklist en Zimbra. Por ejemplo si sufrieramos la oleada de correo con el remitente suplantado que sufrió nuestro amigo, mientras que estudiamos como activar SPF, etc y proteger las cuentas de nuestro correo de dichos envíos podríamos empezar por crear una blacklist.
Para crear una balcklist/whitelist en Zimbra, (nosotros nos quedaremos con la blacklist como medida de contención) usaremos un parámetro de de configuración de Amavis llamado read_hash(). Amavis es un filtro de contenido opensource para correo electrónico, y con read_hash() le diremos a Amavis donde debe ir a buscar los ficheros de configuración relacionados con las blacklist/whitelist. EL proceso podríamos definirlo como:

1. Creamos fichero que contendrá los dominios o correo que formarán parte de la blacklist, con permisos 664 así como propietario y grupo zimbra:zimbra.El fichero lo podemos crear donde queramos, yo recomiendo alguna ubicación relacionada con Zimbra para tenerlo todo "recogidito".Por ejemplo en /opt/zimbra
1. Supongamos que estamos en /opt/zimbra con vuestro editor de ficheros favoritos vi, nano creamos un fichero que se llame por ejemplo blacklist (imaginación al poder) y dentro pondremos los dominios y/o cuentas de correos de los que queramos evitar recibir correos.
2. Damos los permisos 664 con #chmod 664 blacklist y establecemos propietario y grupo al fichero #chown zimbra:zimbra blacklist
2.  El siguiente paso es configurar Amavis con read_hash() para decirle como se llama y donde está el fichero de blacklist que tiene que tener en cuenta, en este ejemplo en /opt/zimbra/blacklist.Para ello tenemos que editar /opt/zimbra/conf/amavisd.conf.in. Justo debajo de la línea que dice #ENVELOPE SENDER SOFT-WHITELISTING/ SOFT-BLACKLISTING añadiremos la siguiente línea read_hash(\%blacklist_sender, '/opt/zimbra/blacklist'); el segundo parámetro alberga la ubicación del fichero blacklist si se ha creado en otra ubicación, habrá que poner ahí dicha ubicación.Guardamos el fichero.
3.  Con el usuario zimbra, cambiamos a el con #su zimbra reiniciamos Amavis y la mta para ello respectivamente haremos #zmamavisdctl restart y  #zmmtactl restart

A partir de ahora si hacemos el intento de mandar un correo con esa cuenta y hacemos cat /var/log/mail.log y filtramos con grep el correo/dominio que hayamos incluido en la blacklist, aparecerá como BloquedSPAM.
Sólo decir que si en vez de una blacklist queremos hacer una whitelist es lo mismo, crearemos un fichero whitelist con los mismos permisos,propietario y grupo que el del ejemplo y en amavisd.conf.in pondremos en el mismo sitio que blacklist read_hash(\%whitelist_sender, '/opt/zimbra/whitelist');


Activación SPF

 
Para hacer referencia a SPF y su activación en Zimbra voy a enlazar a una entrada de MFCP blog  http://blog.kvs-solutions.com/?p=940. Ahí aparece descrito superclaro.¿Reinventar la rueda?No, gracias.

Conclusiones

¿Con estas medidas se solucionaría el problema de nuestro amigo?
Se solucionaría sólo el problema relacionado con la recepción de correos enviados en su nombre hacia los contactos de su dominio, para los demás contactos si sus correspondientes servidores de correos no tienen implementados SPF si los recibirán, ya que los envíos pueden seguir sucediéndose exponiédolos a los correos maliciosos.
Entonces,¿las blacklist y SPF sirven para lo mismo? No. Las blacklist "cortarán" la recepción de los correos desde determinados dominios o cuentas de correos concretas pero no implementa mecanismo alguno de comprobación de remitentes.SPF sólo impedirá que se reciban correos desde servidores que no tienen permisos para enviar correos de determinados dominios por desgracia algo muy común, con la consiguiente disminución de correos no deseados.

Espero que os haya resultado útil.
Nos leemeos en la próxima entrada.

Fuentes

https://linuxyotrascosas.wordpress.com/2013/01/17/crear-blacklist-en-zimbra/

http://soporte.itlinux.cl/hc/es/articles/200120578-Whitelists-y-Blacklist-globales 

 http://blog.kvs-solutions.com/?p=940

Creación y restauración de backups en Proxmox

Hola de nuevo,esta entrada voy a dedicarla a una cuestión básica pero importante relacionada con creación y restauración de backups en Proxmox. ¿Qué es Proxmox? Dediqué una entrada a hablar de esta tecnología en http://uninformaticoenisbilya.blogspot.com.es/2015/05/virtualizacion-low-cost-con-proxmox-ve.html, venga anda te dejo que te la leas y seguimos.
El proceso de creación y restauración de máquinas virtuales en Proxmox es trivial pero nunca me acuerdo de como hacerlo...Ni de manera gráfica, ni de los parámetros para hacerlo desde la consola.Vamos un desastre...¿Nunca te ha sucedido? A mí continuamente de ahí que le quiera dedicar una entrada en este blog.
La versión de Proxmox que usaré para ilustrar el proceso será la 3.3-1.

Creación de backups de nuestras máquinas virtuales

Al grano que empiezo a divagar, sí, tenemos dos formas de crear y restaurar un backup de nuestras máquinas virtuales en Proxmox. Una a través de su interfaz web o a través de la consola mediante línea de comandos. Las dos funcionan bien, quizá como casi siempre, a través de la línea de comandos tienes más versatilidad. Yo suelo hacer uso de la línea de comandos, ya que me gusta saber cómo funcionan las cosas "por dentro".
Antes que nada me gustaría hacer referencia al concepto de "storage" como lugar de almacenamiento, el cual puede ser un disco local, un sistema de almacenamiento compartido por red con NFS o con una SAN por iSCSI. Si queremos profundizar en este concepto podemos visitar https://pve.proxmox.com/wiki/Storage_Model
Vamos a suponer que tenemos un pendrive, u otro disco adicional de donde está instalado Proxmox que queremos convertir en un staorage para , por ejemplo guardar nuestros backups seguiremos los siguientes pasos:

1. Vemos que dispositivos tenemos conectados con #fdisk -l
2. Supongamos que tenemos un pendrive por ejemplo etiquetado como sdb con una partición sdb1 en /dev/sdb1 que queremos montar por ejemplo en /tmp.
   #mount /dev/sdb1 /tmp
   En este momento tenemos montado el pendrive en /tmp en el árbol de directorios de la máquina donde tenemos instalado Proxmox pero aún no es un storage.
3. Entramos en la interface web de Proxmox, y hacemos clic en el padre (Datacenter) del árbol jerárquico que está a la izquierda, en el panel que aparecerá a la derecha hacemos clic en la pestaña Storage, a continuación haremos clic en Add y aparecerá una pantalla con diferentes opciones a la hora de crear un storage, por ejemplo por NFS, en un directorio, etc. En nuestro caso, vamos a seleccionar Directory y estableceremos /tmp que es el directorio donde teníamos montado el pendrive así como un storage de backup. Una cuestión importante como en todo sistema Gnu/Linux si queremos que el pendrive se monte siempre que se inicie el sistema tendremos que añadirlo en /etc/fstab o si en vez de un pendrive fuera otro disco. ¿Por qué digo ésto? Porque el storage se quedará creado independientemente de si los dispositivos están montados en el directorio o no. De hecho a mí me pasó, monte un disco, olvidé meterlo en /etc/fstab creeé el storage,trabajé con él, reincié y cuando quise ver el contenido del storage no había nada. No había nada porque en el directorio donde apunta el storage estaba vacío, en el momento que monté ahí el disco ya pude ver su contenido (y respiré...)

Una vez que ya sabemos montar un dispositivo y crear un storage por si queremos usarlo, llega el momento de crear un backup.

Creación de backups en Proxmox de forma gráfica

1. Desde la vista Server View, seleccionamos del árbol jeráquico la máquina de la cual queramos hacer el backup
2. De la ventana de la derecha seleccionaremos la pestaña Backup.
3. Aparecerán backups anteriores si los hubiera, a continuación sólo tenemos que hacer click en Backup now.
4. A continuación aparecerá una pantalla donde seleccionaremos algunas opciones para hacer el backup como el modo y tipo de compresión. Un poco más adelante en este artículo hago referencia a los diferentes modos y tipos de compresión de los backups.

La imagen que se muestra a continuación muestra la pantalla con las opciones de creación del backup.

Creación de backups a través de líneas de comandos

Por consola a través de líneas de comandos no es mucho más difícil, aunque aquí nos centraremos sólo en los parámetros más comunes y prácticos bajo mi humilde punto de vista.
Para ello usaremos un "programita" que se llama vzdump, si quieres conocer todos los detalles puedes usar su manual con #man vzdump.
En /etc/vzdump.conf podemos configurar los parámetros por defecto. Los parámetros principales
son:
--storage Especifica el storage donde se guardará el backup
--mode (stop|suspend|snapshot) donde a grandes rasgos:

• stop Con stop la máquina se para durante el proceso de backup
• suspend  
• Con máquinas virtuales openvz se hace uso de rsync para copiar la máquina virtual a un directorio temporal, a continuación la máquina es suspendida,un segundo rsync copia los ficheros y se reanuda el funcionamiento de la máquina.

• Con máquinas qemu y kvm el funcionamiento es similar a stop pero suspendiendo/reanudando las máquinas en vez de pararla e iniciarla.

• snapshot Hace uso de LVM para llevarlo a cabo. No se necesita parar la máquina pero se necesita espacio adicional para la creación del LVM.

--compress (0|1|gzip|lzo) Comprime el backup, por defecto es lzo y 1 es igual que lzo
--dumpdir directorio Establece el directorio donde se guardará el backup creado
--maxfiles 1-N Establece el número máximo de backups que puede almacenar de la misma máquina, por defecto es 1.De manera que si por ejemplo hubieramos puesto --maxfiles 2 y ya hubiera dos backups en el directorio, borraría el más antiguo haciendo que quearan dos backups.

Ejemplos:

#vzdump 102 --storage backups --mode snapshot --maxfiles 2 ->Por defecto la compresión es 1=lzo
#vzdump 110 --mode stop --compress gzip --dumpdir /tmp ->Si especificamos un directorio no debemos usar el argumento --storage de lo contrario lo guardará en el storage y no en el directorio especificado.

Tablas comparativa relacionada con el modo de backups y tipos de compresión

Cómo quería comparar cuanto tiempo tardan en hacerse los backups en función de sus diferentes modos considerando las particularidades de funcionamiento de cada uno de ellos me pareció interesante llevar a cabo unas tablas comparativas.

Los resultados se obtuvieron ejecutando vzdump sobre una máquina virtual de  646 Mb de peso, sobre un storage denominado backups que estaba montado en /tmp y era un pendrive.

Modo suspend

Se ejecutó #vzdump 102 --storage backups --mode suspend --compress [0|1|lzo|gzip] cambiando los correspondientes parámetros de compress y se obtuvieron los siguientes resultados:

Modo stop

Se ejecutó #vzdump 102 --storage backups --mode stop --compress [0|1|lzo|gzip] cambiando los correspondientes parámetros de compress y se obtuvieron los siguientes resultados:

Modo snapshot

Se ejecutó #vzdump 102 --storage backups --mode snapshot --compress [0|1|lzo|gzip] cambiando los correspondientes parámetros de compress y se obtuvieron los siguientes resultados:

Como podemos ver en los resultados de las ejecucuiones no hay apenas diferencias entre los tiempos entre los diferentes modos, aunque como se describió con anterioridad sí en su forma de funcionar. Entre los tipos de compresión el más rápido es lzo aunque el que mayor grado de compresión proporciona es gzip. Por lo tanto a igualdad de condiciones si se dispone de espacio suficiente para poder ejecutar el backup en modo snapshot dado que no es necesario parar la máquina para llevarla acabo se postula como la mejor opción. Entre gzip y lzo tendremos que escoger entre la velocidad de ejecución y el grado de compresión. El grado de compresión influye directamente en el tamaño del backup y la diferencia de tiempo tampoco es importante, por lo que para aprovechar mejor los recursos de almacenamiento yo me decantaría por la opción gzip.

Programación de copias

Por otra parte gráficamente también tenemos la posibilidad de crear una plantilla/horario de backups donde podemos configurar los días, las horas, el tipo de backups etc para ello:

1. Nos vamos a la raiz del arbol de directorios que tenemos a la izquierda
2. Hacemos clic en Backup
3. Add
4. Seleccionamos los parámetros
5. Create

La siguiente imagen ilustra un poquito las opciones de creación del backup.

Por la línea de comandos también lo podríamos hacer con una tarea en crontab etc.

Restauración de un backup de una máquina virtual

Si la creación de backups es importante también lo es por ende la restauración del mismo. En este caso también podremos llevar a cabo la restauración a través de la interfaz web que nos proporciona Proxmox o vía línea de comandos.
En cualquier caso recordar que si los backups están en discos o unidades extraíbles es necesario montarlas con anterioridad en el sistema de ficheros de Proxmox, crear el storage tipo backups para que a partir de ellas restaurar los backups, tal y como describimos al comienzo del artículo.

Restauración a través de la GUI de Proxmox

1. Seleccionamos del arbol jerárquico que tenemos a la izquierda la vista Storage View, ahí seleccionaremos el storage donde se encuentran los backups.
2. Seleccionamos la pestaña Content
3. Aparecerán listados los ficheros de backups disponibles de entre los que escogeremos el backup que queramos restaurar
4. Seleccionamos Restore
5. Ahora seleccionaremos el storage de destino y el vm id, ojo con esto del storage que si seleccionamos un storage con espacio limitado nos arrojará un error y no se restaurará el backup y hacemos clic en Restore.
6. Comenzará el proceso de restauración que tardará en función del tamaño de la máquina a restaurar.

A continuación se muestra una imagen de ejemplo con la situación de los principales objetos mencionados. Tened en cuenta que para mí, el storage donde se alojan los backups se llama backups (en un alarde de imaginación), en vuestro caso se llamará como se llame el storage donde tengáis alojado el backup. Además para mí el storage destino se llama local, el vuestro se llamará como se llame vuestro storage destino.

Restauración a través de la línea de comandos

A través de la línea de comandos tenemos dos aplicaciones, vzrestore para vm openVz y qmrestore para vm KVM.
La estructura es similar en ambas aplicaciones.
Nos situamos en el directorio donde se encuentren los ficheros de backups

#vzrestore [--storage storage_name] archivo vmid
#qmrestore [--storage storage_name] archivo vmid

Ejemplos

#vzrestore --storage local vzdump-openvz-110-2015_09_08-18_43_39.tar.gz 110
#qmrestore --storage local vzdump-qemu-111-2015_09_08-18_43_39.tar.gz 111

Sin más y esperando que esta entrada sea de utilidad, ¡nos leemos en la próxima!

Un saludo.