Cuando nuestros relojes dejen de ser seguros

Josemaría | 24 de agosto de 2014 | 1 comentario

blackhat En el boletín de noticias de seguridad Una al Día de hispasec se hacen eco hoy de un problema de seguridad encontrado en pebble, el smartwatch más popular del mundo android, y que permitiría a un atacante remoto resetear y borrar toda la información del dispositivo sin apenas despeinarse. El problema descrito es apenas molesto y no tiene importancia alguna puesto que no compromete información ni nada parecido. ¡Todo lo más que nos despistemos con la hora y lleguemos tarde al trabajo! Lo que tiene de inquietante es pensar en las posibilidades que tendrán a su alcance los ciberdelincuentes a medida que este tipo de dispositivos se popularicen y diversifiquen. Imaginaos, por ejemplo, cuando se nos pueda hacer pasar un apuro elevando al máximo la temperatura de nuestra camiseta térmica inteligente o alguien pueda ver al mismo tiempo que nosotros a través de nuestras sofisticadas gafas… La cosa promete.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Spam (o phishing) para PPeros

Josemaría | 29 de mayo de 2014 | 1 comentario

icono para asuntos de spam No tengo claro si catalogar esto que acabo de recibir como spam o como phishing, pero aquí lo dejo por si pasa algún carguito del PP despistado y no sabe aún como hacer lo que manda la moda ;-)

Spam para gente con pelas

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Evita que tus correos sean marcados como spam (y II). Registros DMARC

Josemaría | 28 de mayo de 2014 | 2 comentarios

correo Hace un par de meses hablábamos por aquí de como implementar el uso de registros PTR, SPF y DKIM en tu servidor de correo con objeto de que el servidor destinatario de los mismos pudiera comprobar que el servidor remitente es legítimo. Los registros DMARC (Domain-based Message Authentication, Reporting & Conformance) van un paso más allá y dan instrucciones al servidor destinatario de cual debería de ser su forma de proceder (a quién notificarlo, por ejemplo) en caso de sospechar de un uso fraudulento.

MUY IMPORTANTE: No se trata de un método de control que podamos usar de forma aislada. Debe de usarse conjuntamente con DKIM, SPF o ambos puesto que su objetivo, como ya hemos dicho, no es validar la autenticidad del correo sino informar de como proceder en caso de que la validación del mismo a través de uno de los métodos anteriores falle. Así que antes que nada asegúrate de que implementas SPF, DKIM (o mejor ambos) y que funcionan correctamente.

En la página de recursos de la web oficial del estándard existen varios asistentes que te ayudarán a crear un registro DMARC. Por ejemplo este, este o este otro. Como en el caso de DKIM se trata de un registro de tipo TXT que debes de publicar en el DNS de tu dominio. Si pasas de asistentes y quieres hacer tu propio registro a mano puedes echarle un vistazo a esta pequeña guía que publica Google.

A continuación puedes ver un ejemplo del registro DMARC para el dominio micorreo.net en el que se están usando SPF y DKIM como sistemas de validación. Puedes consultar el significado de cada uno de los parámetros aquí:

_dmarc.micorreo.net. IN TXT "v=DMARC1; p=none; rua=mailto:admin@miotrocorreo.net; ruf=mailto:admin@miotrocorreo.net; adkim=r; aspf=r"

El parámetro p indica la política esperada por parte del servidor receptor y el valor none indica que está funcionando en modo monitor (lo más recomendable hasta que le cojas el pulso al protocolo). quarantine y reject son los otros dos posibles valores. El parámetro sirve para indicar la versión de DMARC que usamos. Estos son los dós únicos parámetros obligatorios.

Los dos parámetros que llevan como argumento una dirección de correo electrónico (rua y ruf) sirven para indicar donde recibir, respectivamente, un informe diario (aggregate report) por parte de cada servidor que reciba nuestro correo y realice comprobaciones de los registros DMARC y un informe forense (failure report) por cada correo procedente de tu dominio y rechazado por cualquier servidor que use este método de control.

NOTA: Muy pocos proveedores soportan aún el parámetro ruf. Por ejemplo los servidores de Gmail lo ignoran. No obstante, usarlo no provoca ningún error de validación, así que no está de más incluirlo.

Por último, aspf y adkim indican si el modo de verificación que se realizará del “identifier alignment” con cada uno de estos protocolos es strict (s) o relaxed (r). No sabria como traducir el término de forma correcta (el inglés no es mi fuerte, lo siento), pero tienes una excelente explicación de ambos modos con ejemplos aquí. Para los perezosos, básicamente comprueba que, para SPF, el dominio de las cuentas de origen y de respuesta coinciden (campos From: y Return-path:) y para DKIM, deben de coincidir los dominios de los campos From: y del argumento d= de la firma DKIM.

Existen diversas formas de comprobar que has realizado una configuración correcta. La primera de ellas es, como siempre, enviar un correo a un servicio que implemente esta comprobación (como Gmail) y ver la cabecera del mensaje que recibe el destinatario:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of josemaria@micorreo.net designates 145.255.98.239 as permitted sender) smtp.mail=josemaria@micorreo.net;
       dkim=pass header.i=@micorreo.net;
       dmarc=pass (p=NONE dis=NONE) header.from=micorreo.net

La segunda opción es enviar un correo a una de las muchos servicios de verificación existente como, por ejemplo, checkmyauth@auth.returnpath.net, mailtest@unlocktheinbox.com o pythentic@had-pilot.biz (a este último con la palabra dmarc en el campo asunto del correo que envíes). Como respuesta recibirás un completo informe sobre las validaciones que tus envíos pasan de forma correcta o inválida. Algunas veces la respuesta puede tardar varias horas, así que ten paciencia. El resultado de la validación de, por ejemplo, este último servicio sería así:

2014/05/28 14:50:10 :Your DMARC record for   '_dmarc.micorreo.net'   is   'v=DMARC1; p=none; rua=mailto:josemaria.morales@gmail.com; ruf=mailto:josemaria.morales@gmail.com; adkim=r; aspf=r'  

Here are the results of the message from josemaria@micorreo.net
received on Wed May 28 14:48:25 2014 with Subject dmarc

The message was: Delivered
The SPF result was: pass
The DKIM result was: True

**********************************************************
Enter your email address and this hash stringin the Review My Results link for message header analysis of results: address=josemaria@micorreo.net  hash=YFXQ3KxaKAsWmAS0HmrN

**********************************************************
Full Record

Id[1]:  
	SPF result: pass 
	DKIM result: True 
	Alignment result: Pass 
	Feedback: RecordType 
	Delivery Result: Pass 
	Source IP: 145.255.98.239 
	User Agent: Pythentic 
	Version: 1 
	Recipient: had-pilot.biz 
	Arrival Date: Wed May 28 14:48:25 2014 
	From: josemaria@micorreo.net 
	DKIM Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=micorreo.net; s=mail;
	t=1401302897; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;
	h=Date:From:Reply-To:To:Subject:References:In-Reply-To:From;
	b=Hr4mDbw43WdxyXq93zc5y0FlCJBOuHrxXfJLch6yoYRwqL/aMMcc/YnKD+PI++PDf
	 IDdCXWrUAuNhYEM3nqggrB6gKRvl0d0xxbIhpb/THdj90fq0d2eeyA/P8N5Cj7D+ew
	 dW++rfkwyN2PqI6BKhXPtwkDDc00W1JM3/7hIvf4= 
	Subject: dmarc 
	Reported: 0 
	SPFReason: sender SPF authorized 
	DKIMReason: Good DKIM Signature. 
	DMARCReason: Policy=none; accept. 
	Message: Received: from [192.168.1.5] (125.45.219.87.dynamic.jazztel.es [87.219.45.125])
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by invernalia.micorreo.net (Postfix) with ESMTPSA id 1A1A514200B
	for <pythentic@had-pilot.biz>; Wed, 28 May 2014 20:48:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=micorreo.net; s=mail;
	t=1401302897; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;
	h=Date:From:Reply-To:To:Subject:References:In-Reply-To:From;
	b=Hr4mDbw43WdxyXq93zc5y0FlCJBOuHrxXfJLch6yoYRwqL/aMMcc/YnKD+PI++PDf
	 IDdCXWrUAuNhYEM3nqggrB6gKRvl0d0xxbIhpb/THdj90fq0d2eeyA/P8N5Cj7D+ew
	 dW++rfkwyN2PqI6BKhXPtwkDDc00W1JM3/7hIvf4=
Message-ID: <53862F70.5030601@micorreo.net>
Date: Wed, 28 May 2014 20:48:16 +0200
From: =?UTF-8?B?Sm9zw6kgTWFyw61hIE1vcmFsZXMgVsOhenF1ZXo=?=
 <josemaria@micorreo.net>
Reply-To: josemaria@micorreo.net
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: pythentic@had-pilot.biz
Subject: dmarc
References: <5384CED8.4040701@micorreo.net>
In-Reply-To: <5384CED8.4040701@micorreo.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-dkim: d=micorreo.net,s=mail,DKIMReason=Good DKIM Signature.
X-spf: i=145.255.98.239,h=micorreo.net.,s=josemaria@micorreo.net,SPFResult=pass

Por último, existen servicios que validan directamente el registro que has introducido en el DNS dándote, además, una completa explicación de lo que implican los parámetros que has elegido y las alternativas que tienes. Este es mi favorito.

En la dirección que has indicado como valor del argumento rua recibirás un correo electrónico diario por cada servidor al que envíes correo y use la validación DMARC informándote de las validaciones y/o acciones realizadas. En estos correos recibirás un adjunto comprimido en formato zip con un xml en su interior. El contenido de dichos xml es fácil de interpretar pero, si lo deseas, tienes aquí un convertidor a “formato humano” y a continuación un ejemplo del resultado:

Informe Diario XML DMARC

Por cierto: si, como yo, usas un correo de un dominio distinto al que estás validando para recibir los correos con los informes, puede que algún servidor o servicio te de algún error. La solución está en añadir un nuevo registro en el DNS indicando esto. Este segundo registro debería de ir en el DNS del dominio correspondiente a la cuenta de correo donde quieres recibir los informes, ojo, así que deberías de tener control sobre él o, al menos, alguien que te lo permita. Aquí te lo explican muy bien y a continuación tienes el mío:

micorreo.net._report._dmarc.miotrocorreo.net. IN TXT "v=DMARC1"

Ah, y si quieres configurar tu servidor posfix para que realice la comprobación de los registros dmarc en los correos que recibe puedes usar OpenDMARC.

ACTUALIZACI?N: Y casi se me olvida… En dmarcian tienen un servicio que te permite habilitar una suerte de panel de control para controlar el estado de SPF, DKIM y DMARC en todos los dominios que controles:
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Desde China ¿con amor?

Josemaría | 26 de mayo de 2014 | 6 comentarios

blackhat Si tienes un servidor con presencia en Internet, usas (como deberías) algún sistema para bloquear los intentos de acceso no autorizados como fail2ban o denyhosts y analizas de vez en cuando los logs, no voy a decirte nada nuevo: en los últimos meses hemos experimentado un aumento inusitado de intentos de intrusión desde direcciones IP procedentes de China. En mi caso, en los últimos tres meses el 83% de los intentos irregulares de entrada a través de ssh que he observado proceden de este país. Concretando aún más, el 50% del total de estos intentos procede de la subred 116.10.191.0/24 y el 25% de la subred 61.174.51.0/24. Así que ya sabes: si eres de los que prefieres los métodos preventivos ya tardas en banear ambas subredes en tus cortafuegos.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Evita que tus correos sean marcados como spam usando registros PTR, SPF y DKIM

Josemaría | 3 de marzo de 2014 | 6 comentarios

correoInstalar y configurar un servidor de correo es algo relativamente sencillo y un tema que hemos tratado en alguna ocasión por aquí. También hemos hablado de la forma de reducir el spam que entra en nuestros buzones implementando un sistema de Greylisting. De lo que no hemos hablado aún es de las formas que tenemos de evitar que nuestros correos legítimos acaben abandonados en la carpeta de correo no deseado del destinatario. Algo que cada vez es más frecuente si tienes tu propio servidor de correo personal o de empresa y escribes habitualmente a buzones de los grandes proveedores (Gmail, Hotmail y Yahoo, por ejemplo) que hace tiempo se declararon en guerra abierta contra el spam.

Las técnicas de control de spam usadas más frecuentemente pasan por contrastar la autenticidad del remitente a través de algún tipo de comprobación contra el dominio de procedencia del correo electrónico. Lo que se persigue es que si recibo un correo procedente de una cuenta de determinado dominio, el propietario de dicho dominio debería de tener correctamente identificadas cuales son las máquinas autorizadas para enviar correo en su nombre. Recuerda que lo habitual (e indispensable) es identificar las máquinas receptoras del correo (mediante registros MX), pero muchos administradores aún continúan sin identificar de forma alguna a las emisoras a pesar de que tenemos varias opciones para hacerlo. Veamoslas.

Para ilustrar nuestro ejemplo supondremos que tenemos un servidor de correo que actúa como único emisor autorizado y que también funciona como receptor del correo. Su nombre es estafeta.micorreo.net y su IP la 145.255.98.239. Nuestro servidor es un VPS contratado a una empresa de hosting, que es la que nos proporciona la IP, usará postfix sobre una máquina con Debian 7, estará perfectamente configurado y atenderá a dos dominios diferentes (ya hemos hablado también aquí de como hacerlo) llamados midominio.com y midominio.net

La existencia de un registro PTR de resolución inversa para la IP de la máquina que entrega el correo es una de las primeras cosas que valorará de forma positiva un filtro antispam. El problema que vamos a encontrar con esto es que, habitualmente, no podremos crearlo nosotros mismos. Si la IP fija que usa nuestro servidor nos la ha proporcionado nuestro ISP tendremos que pedírle a ellos que creen este registro para nosotros. Si nuestro servidor de correo está alojado en una empresa de hosting se lo solicitaremos a ellos o, tal vez, nos proporcionarán algún mecanismo para que lo hagamos nosotros mismos a través de su panel de configuración. Si tienes la posibilidad de configurarla por ti mismo en un servidor BIND nuestros buenos amigos de systemadmin te dicen aquí como debes de hacerlo, así que no pierdo más el tiempo en ello ;-) .

Para nuestro ejemplo, pediríamos a la empresa de hosting que nos aloja el servidor (yo así lo hice a Gigas, mi empresa actual de hosting que de de alta un registro de resolución inverso para la IP 145.255.98.239 que se resuelva como estafeta.micorreo.net

Para comprobar si lo han hecho correctamente puedes usar nslookup:

nslookup -query=PTR 145.255.98.239

Los registros SPF (Sender Policy Framework o Marco Normativo de Remitentes) constituyen uno de los métodos más comunes y fáciles de implementar para identificar a las máquinas de nuestro dominio autorizadas para enviar correo electrónico. El método es tan sencillo como dar de alta un nuevo registro en la zona de tu dominio donde identifiques a los servidores que autorizas para enviar correo. Originalmente se usaba un registro TXT pero posteriormente se amplió la funcionalidad de las bases de datos DNS añadiendo un nuevo tipo de registros denominado SPF. Hoy en día es recomendable usar ambos métodos por si acaso el servidor que realiza la validación busca aún el tipo de registros antiguo.

La sintaxis de definición de un registro SPF tiene muchas alternativas y puede variar según nuestras necesidades. En esta entrada tienes la especificación completa muy bien explicada y con todo lujo de detalles. Para nuestro ejemplo (un único servidor de correo tanto para envío como para recepción y que coincide con el que aparece en el registro MX) puedes usar los siguientes registros:

@ IN MX 10 estafeta.micorreo.net.

@ IN TXT "v=spf1 mx ip4:145.255.98.239 ~all"
@ IN SPF "v=spf1 mx ip4:145.255.98.239 ~all"

Puesto que el correo de ambos dominios es gestionado por el mismo servidor debemos repetir esos mismos registros exactamente iguales en las bases de datos de ambas zonas. Y, por supuesto, hacer un reload del servidor bind9 después de hacer los cambios.

Tenemos muchas formas de hacer pruebas si hemos configurado correctamente nuestros resgistros SPF. Una de ellas es usar alguno de los muchos tests online disponibles por ahí. Mis favoritos son estos:

Otra opción es enviar un correo a una cuenta de los grandes proveedores (GMail, Outlook o Yahoo, por ejemplo, comprueban la validez de los registros SPF para valorar si un correo es marcado como SPAM) y observar lo que pone en la cabecera del correo que recibe el destinatario. Ten en cuenta que la validación que hace cada uno de ellos es ligeramente diferente. Por ejemplo, si retiras la partícula ip4 de los registros anteriores Gmail y Yahoo seguirán validando correctamente pero Outlook dejará de hacerlo.

Si, por ejemplo, enviamos un correo a Gmail y no hemos definido aún registros SPF, Google insertará en la cabecera del correo una marca como esta definiéndolo como neutral. Eso quiere decir que no puede determinar si el correo es válido o es spam.

Received-SPF: neutral (google.com: 145.255.98.239 is neither permitted nor denied by best guess record for domain of josemaria@midominio.com) client-ip=145.255.98.239;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 145.255.98.239 is neither permitted nor denied by best guess record for domain of josemaria@midominio.com) smtp.mail=josemaria@midominio.com

Por el contrario, cuando contemos con unos registros SPF correctos la valoración que Google hará constar anunciará que el correo es correcto (pass):

Received-SPF: pass (google.com: domain of josemaria@midominio.com designates 145.255.98.239 as permitted sender) client-ip=145.255.98.239;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of josemaria@midominio.com designates 145.255.98.239 as permitted sender) smtp.mail=josemaria@midominio.com

Si Google recibe un correo de un dominio que usa registros SPF pero el servidor emisor del mismo no está autorizado en estos registros lo marcará como fail o softfail. En el caso de los registros que he puesto como ejemplo lo hará como softfail gracias a la partícula ~all que he especificado (consulta la página de sintaxis que he referenciado antes para entender las diferencias entre ambos).

NOTA: Microsoft propuso hace años una variante de los SPF que denominó Sender ID y que decía corregir alguna de las carencias del protocolo original, pero su empecinamiento en mantener ciertas patentes sobre el mismo impideron que se popularizara su uso. Aquí tienes más información acerca de sus diferencias. Hoy en día lo normal es que si un servidor realiza una comprobación del Sender ID la de por buena si se encuentra un SPF correcto.

El tercer tipo de registros que veremos son los DKIM (DomainKeys Identified Mail), un sistema de identificación que usa firmas realizadas con criptografía de clave pública. El método en el que se basa también es sencillo de entender. Nuestro servidor de correo firmará todos sus mensajes salientes mediante su clave privada y esta firma se incluirá en la cabecera del mensaje en una sección llamada “DKIM-Signature”.

La clave pública deberá de estar disponible para que quien lo quiera pueda realizar la verificación de la firma. Esto se hace en un registro TXT de nuestro DNS. La implementación de este sistema en nuestros servidores es, sin embargo, bastante más complicada ya que necesitamos generar previamente la pareja de claves, configurar nuestro servidor de correo para que realice la firma de los mensajes y, por último, insertar la clave pública en el registro TXT correspondiente de nuestra zona DNS… Vamos a ver como hacerlo.

En primer lugar instalamos los paquetes necesarios:

apt-get install opendkim opendkim-tools

A continuación creamos un directorio para las claves y archivos de configuración. Podemos, por ejemplo, hacerlo en el directorio /etc. En el crearemos un subdirectorio por cada dominio de correo que usamos y tres ficheros adicionales que luego explicaremos como rellenar:

mkdir /etc/opendkim
mkdir /etc/opendkim/midominio.com
mkdir /etc/opendkim/midominio.net
touch KeyTable
touch SigningTable
touch TrustedHosts

Vamos ahora a generar las parejas de claves necesarias para que DKIM funcione. Entramos en el directorio que hemos creado para el primer dominio y ejecutamos lo siguiente:

cd /etc/opendkim/midominio.com
opendkim-genkey -s mail -d midominio.com

El parametro detrás de la -s es el llamado “selector” y el que va detrás de la -d el dominio para el que generas las claves. La instrucción anterior nos generará un par de ficheros: uno llamado mail.private con la clave privada y otro denominado mail.txt que incluye el registro que, con ligeras modificaciones, tendremos que incluir en nuestra zona DNS y que contiene la clave pública. Fíjate en el contenido en bruto de este fichero:

mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHBGfg26egqLbX2B1K7HW5NQLKpD/9kOcYsfMzH6fiGo0qtjxAjIAUykoO3GoAqiU7UHgsOv0XU67ONiCMoKrM2IxxL/D0Qt4ePojeqNm55lwk6kSHZDIRAqBCt+r2O4Gc78RVudI4RE17GWnxKzhHEsCG6kHyNb46oYiN1tg3OwIDAQAB" ; ----- DKIM key mail for midominio.com

Y ahora mira lo que yo he incluido en mi DNS:

_domainkey.midominio.com. IN TXT "o=~; r=josemaria@midominio.com"

mail._domainkey.midominio.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHBGfg26egqLbX2B1K7HW5NQLKpD/9kOcYsfMzH6fiGo0qtjxAjIAUykoO3GoAqiU7UHgsOv0XU67ONiCMoKrM2IxxL/D0Qt4ePojeqNm55lwk6kSHZDIRAqBCt+r2O4Gc78RVudI4RE17GWnxKzhHEsCG6kHyNb46oYiN1tg3OwIDAQAB" ; ----- DKIM key mail for midominio.com

Como ves, he incluido un primer registro TXT denominado _domainkey.midominio.com. (mail es el selector usado al generar la clave y midominio.com. el dominio) cuyo contenido es la política que usaremos (puedes consultar aquí que significa). El segundo registro es el contenido íntegro del fichero mail.txt al que simplemente le he añadido el dominio correspondiente al final del primer campo.

Esta primera parte ya está lista. Ahora tienes que hacer un reload de las zonas de tu servidor DNS (service bind9 reload) y, por último, podrías probar si tienes correctamente configurado estos registros con esta herramienta.

Tenemos aún que dotar de contenido a los tres ficheros que hemos creado inicialmente en el directorio /etc/opendkim. Los dos primeros sirven para seleccionar la clave privada que se usará para la firma en función del correo del remitente.

El fichero KeyTable contendrá una línea por cada pareja de claves que hemos creado. La sintaxis de cada una de estas líneas con arreglo a como hemos realizado el proceso hasta ahora sería así:

keyid dominio:selector:path_a_la_clave_privada

Nosotros usaremos como keyid el mismo nombre de dominio, así que en nuestro ejemplo quedará así:

midominio.com midominio.com:mail:/etc/opendkim/midominio.com/mail.private
midominio.net midominio.net:mail:/etc/opendkim/midominio.net/mail.private

El fichero SigningTable identifica los correos con los keyid del fichero anterior y, por tanto, con la clave privada usada para la firma. La sintaxis de cada línea es esta:

expresion_para_identificar_el_correo keyid

Y en nuestro ejemplo:

*@midominio.com midominio.com
*@midominio.net midominio.net

El último de ellos, TrustedHosts, debería de incluir a los servidores autorizados para usar opendkim. Nosotros tenemos sólo uno pero especificaremos todas sus posibles direcciones y/o identificaciones para evitar problemas:

127.0.0.1
145.255.98.239
invernalia.unlugarenelmundo.es

Muy importante: debemos de asegurarnos que el usuario opendkim y sólo él tiene acceso a estos directorios

chown opendkim:opendkim /etc/opendkim/* -R
chmod go-rwx /etc/opendkim/* -R

Configuramos ahora /etc/opendkim.conf incluyendo o modificando las siguientes líneas (échale un vistazo con detenimiento porque alguna podría aparecer con otros valores distintos a los que aquí ponemos):

Syslog yes
SyslogSuccess yes
LogWhy yes
UMask 002
OversignHeaders From

KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts

SignatureAlgorithm rsa-sha256
AutoRestart yes
UserID opendkim:opendkim
Socket inet:8891@localhost

Canonicalization relaxed/simple
Mode s

En el fichero /etc/postfix/main.cf incluimos las siguientes líneas para instruir a postfix de lo que queremos hacer:

#OpenDKIM
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
#smtpd_milters = inet:8891@localhost
non_smtpd_milters = inet:localhost:8891

Por último, reiniciamos los dos servicios en los que hemos hecho cambios:

service opendkim restart
service postfix restart

Puedes comprobar que tu servidor está firmando los mensajes salientes simplemente mirando en la cabecera de los mensajes que hayas enviado (ojo, no vale con mirar esto en la carpeta de enviados de tu cliente de correo: tienes que mirarlo en el buzón de alguién a quién hayas enviado un mensaje ;-) ). Deberías de encontrar una sección como esta:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=midominio.com;
	s=mail; t=1393841181;
	bh=WOdEGJCY/0JhPY8jx68CyFKNQxxdoD1qEPM2Bike+fA=;
	h=Date:From:Reply-To:To:Subject:From;
	b=dtHZW0UMlXcKt6c8IY6DS1IVclv7KZTo6IIK0+r/yLWdKet/G9jkvSxmp7MhTeL9t
	 p5Jh87PMKJD0GuRWIJAKx/QLSVAhf9/scXbR7GH9dRPipwxM4lRzaWwxgyCFfKafca
	 SnBJ81jsaKpQgB8sUi2CY4YWt0Y0Vdy7CKCDbpxA=

Además, también puedes mirar los logs de tu servidor postfix (en /var/log/mail.log):

Mar  3 06:22:05 estafeta opendkim[2738]: 4DA1D14206A: DKIM-Signature header added (s=mail, d=midominio.com)

Para saber que la configuración a la que has llegado es correcta, puedes envíar un correo a gmail y comprobar en la cabecera del mensaje recibido que la autenticación a través de DKIM es correcta:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of josemaria@midominio.com designates 145.255.98.239 as permitted sender) smtp.mail=josemaria@midominio.com;
       dkim=pass header.i=@midominio.com

Como con los SPF, te recomiendo que pruebes también con Yahoo, Outlook y otros proveedores para asegurarte de que has llegado a una configuración correcta.

También te pueden resultar útiles las herramientas de DKIM Core para generación o verificación de tus claves.

NOTA: Al igual que ocurría en el caso de los SPF, DKIM también tiene un hermano bastardo llamado DomainKeys que fue impulsado por yahoo! pero que ya nadie más usa… salvo ellos. Si miras en las cabeceras de un correo enviado a yahoo podrás ver que con la configuración que hemos visto aquí valida DKIM como pass y DomainKeys como neutral:

Authentication-Results: mta1040.mail.bf1.yahoo.com  from=midominio.com; domainkeys=neutral (no sig);  from=midominio.com; dkim=pass (ok)

Finalmente, tenemos un mecanismo para realizar una comprobación global de los mecanismos de identificación que nuestro correo es capaz de pasar que consiste en enviar un mail a la dirección check-auth@verifier.port25.com. Como respuesta recibiremos un resumen con los tests de autenticación que pasamos y los que no:

From: auth-results@verifier.port25.com
To: josemaria@midominio.com
Subject: Authentication Report
Message-Id: <1393852132-602016@verifier.port25.com>
Precedence: junk (auto_reply)
In-Reply-To: <53147EDC.1060808@midominio.com>

This message is an automatic response from Port25's authentication verifier
service at verifier.port25.com.  The service allows email senders to perform
a simple check of various sender authentication mechanisms.  It is provided
free of charge, in the hope that it is useful to the email community.  While
it is not officially supported, we welcome any feedback you may have at
<verifier-feedback@port25.com>.

Thank you for using the verifier,

The Port25 Solutions, Inc. team

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         pass
Sender-ID check:    pass
SpamAssassin check: ham

==========================================================
Details:
==========================================================

HELO hostname:  estafeta.micorreo.net
Source IP:      145.255.98.239
mail-from:      josemaria@midominio.com

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass 
ID(s) verified: smtp.mailfrom=josemaria@midominio.com
DNS record(s):
    midominio.com. 86400 IN SPF "v=spf1 mx ip4:145.255.98.239 ~all"
    midominio.com. 86400 IN MX 10 estafeta.micorreo.net.
    estafeta.micorreo.net. 14400 IN A 145.255.98.239

----------------------------------------------------------
DomainKeys check details:
----------------------------------------------------------
Result:         neutral (message not signed)
ID(s) verified: header.From=josemaria@midominio.com
DNS record(s):

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: josemaria@midominio.com)
ID(s) verified: header.d=midominio.com
Canonicalized Headers:
    date:Mon,'20'03'20'Mar'20'2014'20'14:08:44'20'+0100'0D''0A'
    from:=?UTF-8?B?Sm9zw6kgTWFyw61hIE1vcmFsZXMgVsOhenF1ZXo=?='20'<josemaria@midominio.com>'0D''0A'
    reply-to:josemaria@midominio.com'0D''0A'
    to:josemaria.morales@gmail.com,'20'jmmoralesv@outlook.com,'20'jmmoralesv@yahoo.com,'20'check-auth@verifier.port25.com'0D''0A'
    subject:prueba'20'desde'20'morales-vazquez'20'a'20'dkim'0D''0A'
    dkim-signature:v=1;'20'a=rsa-sha256;'20'c=relaxed/simple;'20'd=midominio.com;'20's=mail;'20't=1393852124;'20'bh=bTRBPsyNE9vY+br0wyWV6XaM4bHp8xfOlCzTWRPryRY=;'20'h=Date:From:Reply-To:To:Subject:From;'20'b=

Canonicalized Body:
    xxxx'0D''0A'
    '0D''0A'
    --'20''0D''0A'
    --'20'Jos'C3''A9''20'Mar'C3''AD'a'20'Morales'20'['20'josemaria@midominio.com'20']'0D''0A'
    ------------'20'Blog:'20'['20'http://blog.unlugarenelmundo.es/'20']'0D''0A'
    ------------'20'Perfil:'20''20'['20'http://cv.morales-vazquez.es/'20']'0D''0A'
    

DNS record(s):
    mail._domainkey.midominio.com. 86400 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHBGfg26egqLbX2B1K7HW5NQLKpD/9kOcYsfMzH6fiGo0qtjxAjIAUykoO3GoAqiU7UHgsOv0XU67ONiCMoKrM2IxxL/D0Qt4ePojeqNm55lwk6kSHZDIRAqBCt+r2O4Gc78RVudI4RE17GWnxKzhHEsCG6kHyNb46oYiN1tg3OwIDAQAB"

Public key used for verification: mail._domainkey.midominio.com (1024 bits)

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

----------------------------------------------------------
Sender-ID check details:
----------------------------------------------------------
Result:         pass 
ID(s) verified: header.From=josemaria@midominio.com
DNS record(s):
    midominio.com. 86400 IN SPF "v=spf1 mx ip4:145.255.98.239 ~all"
    midominio.com. 86400 IN MX 10 estafeta.micorreo.net.
    estafeta.micorreo.net. 14400 IN A 145.255.98.239

----------------------------------------------------------
SpamAssassin check details:
----------------------------------------------------------
SpamAssassin v3.3.1 (2010-03-16)

Result:         ham  (-2.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
-0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from author's
                            domain
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
Si has llegado hasta aquí y quieres continuar con los registros DMARC puedes dar un salto a esta otra entrada ;-)
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Políticas de contraseñas y control de acceso en Debian

Josemaría | 8 de febrero de 2014 | 8 comentarios

seguridad Existe un falso tópico por ahí que viene a decir, de una u otra forma, que Linux es más seguro que Windows. Para nada. Es cierto que, normalmente, el usuario medio de Linux está más comprometido con la seguridad, abundan más los usuarios expertos y menos los usuarios domésticos y que existe una mayor variedad de posibilidades y herramientas para hacer seguros nuestros sistemas. También que al existir un volumen menor de equipos con Linux no es objetivo prioritario de los creadores de virus. Pero “recién salido de la caja” y en manos de un usuario torpe y/o despreocupado, un Linux es, por regla general, tan poco seguro como cualquier Windows. De veras.

Veamoslo, por ejemplo, desde el punto de vista de la política de usuarios y contraseñas, uno de los aspectos que mas se critica en los Windows de escritorio. Una Debian 7.3 (la última en el momento de escribir esto) te permite poner cualquier contraseña para el root y la cuenta inicial que se crean de forma obligatoria durante la instalación. Y cuando digo cualquiera, digo cualquiera y sin ningún tipo de advertencia. ¡Hasta una de un sólo carácter o el maldito 123456 (que hace años que ya ni siquiera en Hotmail está permitida aunque sigue siendo una de las passwords más usadas)! Además, el único tipo de protección ante ataques de diccionario y/o fuerza bruta es un retraso de tres segundos entre cada intento de login fallido. No, no parece un planteamiento muy seguro a priori ¿Verdad? Bueno, por lo menos no nos permite dejar las cuentas sin contraseña. Algo es algo…

NOTA: Si durante la instalación dejamos la password del usuario root en blanco nos lo permitirá pero en ese caso, afortunadamente, lo que hará sera deshabilitar la cuenta de root y conceder privilegios a través de sudo a la cuenta del primer usuario que… igualmente, podremos inicializar con cualquier contraseña sin ningún tipo de advertencia. ¡Ay!

La parte positiva del asunto es que con un poquito de trabajo por nuestra parte este esquema puede mejorar sustancialmente. Para ello, lo primero es conocer como funciona la autenticación de usuarios en Linux. Vamos a ello.

Antes que nada vamos a ubicar algunos de los ficheros importantes en este asunto. En el directorio /etc se encuentran los ficheros passwd y shadow que guardan, respectivamente, las cuentas de usuario y los “hashes” de las contraseñas. Además, repartido entre ellos, existe mucha información relacionada con el proceso de autenticación: si el usuario puede hacer login interactivo o no, el bash que usará, información de caducidad de la cuenta, etc. Veamos una línea típica de cada uno de estos ficheros y hagamos una disección de su contenido.

Empezamos por el fichero passwd. Cada línea se corresponde con un usuario y consta de siete campos en los que el separador es el signo “:”. Por ejemplo así:

josemaria:x:1001:1001:Jose Maria Morales,,,:/home/josemaria:/bin/bash

El significado de cada uno de los campos es este:

1Nombre que el usuario utilizará en el login
2Tradicionalmente aquí se encontraba la hash del password. Ahora, una x simboliza que la hash de la password se encuentra en el fichero shadow. Un * o un ! indican que la cuenta está desactivada. Por el contrario, si eliminamos la x (o cualquier otra cosa) de este campo, el sistema nos dejará entrar sin necesidad de contraseña pero sólo a través de una conexión "in situ" frente a la máquina mientras que las conexiones remotas no se permitiran.
3UID del usuario
4GID del grupo primario del usuario
5Infomación personal del usuario. Los diferentes campos están separados por comas.
6Directorio home del usuario
7Path absoluto al shell por defecto que usará cuando realice una conexión interactiva. Se suele poner /bin/false cuando no queremos permitir una conexión interactiva.

Aquí ya podemos hacer la primera “personalización” relativa a la seguridad. Si queremos que un usuario no pueda hacer una conexión interactiva con el sistema basta con que pongamos un * o un ! en el campo 2 o un shell inexistente en el campo 7 (por convención suele ponerse /bin/false). La diferencia entre usar uno u otro método es que el segundo permitirá que, aún así, esa cuenta de usuario pueda seguir usándose para otro tipo de servicios (correo, por ejemplo) mientras que si usamos el primero la cuenta quedará totalmente inutilizable para ningún servicio.

Vayamos ahora con el fichero shadow. Primero un ejemplo. Como podemos ver, en este caso tenemos 8 campos:

josemaria:$6$F3PRa1Vu$fXK1ZYXex67wi5XdbnTokhWle416I87oAtgs0ynFdhn.c6IBqrvGhmnCUC.Ue2AbLJtn9C9ZH.3pgNfSeneTF0:15675:0:99999:7:::
1Nombre que el usuario utilizará en el login
2Se trata de un campo compuesto que contiene información del algoritmo que usará el sistema para calcular el hash, la salt que aplicaremos a la password antes de calcular este y el hash resultante. Cada uno de estos tres subcampos se separan por el símbolo $. En el ejemplo de aquí arriba el 6 del primer campo indica que usaremos SHA512 (la opción por defecto en las Debian actuales), la salt es F3PRa1Vu y el resto después del último símbolo $ es la hash ya calculada al resultado de concatenar la salt con el password. Un 5 en el primer campo indica que usaremos SHA256, un 4 SHA1, un 3 NT Hash, un 2 blowfish y un 1 MD5. Un * o un ! en este campo también indican que la cuenta está deshabilitada.
3Fecha del último día en que se cambió la password indicada, como es habitual, mediante el número de días transcurridos desde el 1 de Enero de 1970
4Número mínimo de días requeridos entre cambios de contraseñas. Un 0 indica que se puede cambiar tan a menudo como se quiera.
5Número máximo de días para obligar a un cambio de contraseña. Por defecto 99999. O sea, casi 274 años. O sea, nunca.
6Número de días antes de que el password expire en que se mostrará un aviso al usuario indicando que debe de cambiarla. Por defecto 7 días
7Número de días del periodo de gracia después de que el password expire transcurridos los cuales la cuenta será deshabilitada. En blanco por defecto (no habrá periodo de gracia).
8Fecha (indicada también mediante el número de días transcurridos desde el 1 de enero de 1970) en que la cuenta será deshabilitada. En blanco por defecto (la cuenta nunca expira).

La expiración de passwords y de cuentas de los parámetros que hemos visto se puede manejar de dos formas: editando directamente la información del fichero shadow o con el comando chage. Por ejemplo, el siguiente comando fija en 30 días la validez máxima de una contraseña para el usuario josemaria y en 2 el mínimo número de días que deben de transcurrir entre cambios:

chage -M 30 -m 2 josemaria

Otros parámetros interesantes son -d y -E para establecer la fecha del último cambio de contraseña y la de caducidad de la misma respectivamente (en formato YYYY-MM-DD), -I para establecer los días de gracia antes de desactivar la cuenta, o -W para establecer el número de días antes de la fecha de caducidad para emitir una advertencia.

También podemos cambiar todos estos datos de forma interactiva:

comando chage en forma interactiva

O listar los valores establecidos para una cuenta usando el argumento -l:

chage -l josemaria

Pero ¿Dónde se establecen estos valores por defecto para que se tengan en cuenta a la hora de crear nuevos usuarios y no tener que modificarlos uno a uno? En el fichero /etc/login.defs podemos editar los siguientes parámetros que sirven, respectivamente, para ajustar el número máximo y mínimo de días de validez de una password y la antelación a que caduque con que recibiremos una advertencia:

PASS_MAX_DAYS   60
PASS_MIN_DAYS   2
PASS_WARN_AGE   5

En el fichero /etc/default/useradd ajustamos los días de gracia en que las cuentas permarecerán activas después de caducar las contraseñas y la fecha global de expiración de las mismas:

INACTIVE=2
EXPIRE=

Un -1 en el primer campo indica que la cuenta se deshabilitará tan pronto como caduque la contraseña. Si el segundo campo está en blanco indica que la cuenta no tendrá una fecha predeterminada de expiración.

Pero la verdadera potencia en el sistema de identificación de Linux reside en la gran variedad y flexibilidad que tenemos a la hora de usar métodos que refuerzan el sistema clásico de autenticación o nos proporcionan alternativas al mismo mediante módulos adicionales. Estos módulos residen en el directorio /lib/i386-linux-gnu/security/ y se configuran a través de los ficheros que tenemos en /etc/pam.d. En este enlace podemos ver todos los disponibles en una Debian 7 estable, aun los no instalados por defecto. Empecemos por ver dos de los que vienen instalados “de serie”. pam_faildelay y pam_tally nos permiten, a través del fichero /etc/pam.d/login, controlar el retraso entre varios intentos de login fallidos y la configuración de bloqueo de cuentas después de sucesivos intentos erroneos con los siguientes parámetros:

auth optional pam_faildelay.so delay=5000000
auth required pam_tally.so deny=5 unlock_time=7200

En la primera línea el retraso entre logins fallidos se especifica en microsegundos (5000000, o sea, 5 segundos). En la segunda línea decimos que tras cinco intentos de login fallido la cuenta se bloqueará durante 7200 segundos (2 horas). En una instalación limpia y por defecto la primera línea aparece configurada a 3 segundos y la segunda no aparece, es decir, la cuenta no se bloquea nunca.

El control manual de las cuentas bloqueadas o intentos fallidos de login puede llevarse mediante dos utilidades: pam_tally o faillog.

pam_tally y faillog para control de cuentas bloqueadas e intentos fallidos de login

Podemos, además, consultar los datos relativos a una única cuenta de usuario con cualquiera de estos dos comandos:

pam_tally --user josemaria
faillog -u josemaria

Desbloquear manualmente una cuenta o hacer un reset a los intentos fallidos de la misma así:

pam_tally --user josemaria --reset=0
faillog -r -u josemaria 

O modificar el número máximo de intentos fallidos así:

faillog -m 3
NOTA: Los bloqueos tras sucesivos intentos fallidos se pueden controlar también con utilidades externas como denyhost (de la que hablamos aquí hace años) o fail2ban que añaden muchas otras funcionalidades.

El tipo de contraseñas permitidas y alguna otra característica asociada a las mismas se configura en el fichero /etc/pam.d/common-password. La configuración por defecto usa el módulo pam_unix y se define mediante esta línea:

password [success=1 default=ignore] pam_unix.so obscure sha512

El argumento obscure realiza una mínima comprobación de la complejidad de la contraseña: si esta es demasiado simple o una modificación fácilmente reproducible a partir de la anterior, mientras que sha512 define el algoritmo que se usará para guardar el hash en el fichero shadow. Otros argumentos interesantes que podemos añadir son remember, que dicta el número de contraseñas que son memorizadas por el sistema para que el usuario no las repita o minlen que fija la longitud mínima de la contraseña. Por ejemplo, para recordar las 12 contraseñas anteriores y fijar una longitud mínima de 10 caracteres modificaríamos la línea anterior así:

password [success=1 default=ignore] pam_unix.so obscure remember=12 minlen=10 sha512

El módulo pam_cracklib, que no viene instalado por defecto, nos permite una configuración mucho más flexible. Lo instalamos así:

apt-get install libpam-cracklib

Y, tras hacerlo, se nos añadirá automáticamente la siguiente línea en el fichero /etc/pam.d/common-password justo encima de la que define la forma de funcionar del módulo pam_unix:

password requisite pam_cracklib.so retry=3 minlen=8 difok=3

pam_cracklib es mucho más restrictivo que pam_unix a la hora de permitir contraseñas puesto que, además de las comprobaciones de complejidad, contrasta la password elegida por el usuario con las de un diccionario que instala en el directorio /var/cache/cracklib. Además, en su configuración por defecto que acabamos de ver exige una longitud mínima de 8 caracteres de los cuales, al menos, tres no debería de estar presentes en la password anterior (argumento difok). Otros argumentos interesantes son reject_username (rechaza contraseñas que contengan de alguna forma el nombre de usuario escrito normal o invertido) o maxrepeat=n (rechaza contraseñas con más de n caracteres iguales seguidos).

Particularmente flexible es el método que nos permite definir el tipo de caracteres que exigiremos a la contraseña. pam_cracklib considera que existen cuatro grupos de caracteres: letras mayúsculas, letras minúsculas, cifras y signos de puntuación. La forma más sencilla es definir el mínimo número de estos tipos que deberían de estar presentes en cada contraseña con el argumento minclass=n, donde n es un número entre 1 y 4.

Contamos, además, con los argumentos lcredit, ucredit, dcredit y ocredit que representan, respectivamente, a las letras minúsculas, las mayúsculas, los dígitos y los signos de puntuación, los cuatro grupos de caracteres a considerar. Cuando aparecen con valores negativos indican el mínimo número de caracteres de ese grupo con que debería de contar nuestra password. Por ejemplo, minlen= 8 ucredit=-1 lcredit=-1 dcredit=-1 indica que la contraseña debería de tener al menos una mayúscula, una minúscula y un dígito y contar con 8 caractéres mínimos de longitud. Cuando se utilizan con valores positivos, sin embargo, validan nuestra contraseña según un sistema de créditos donde minlen indicaría el número de “puntos” mínimo que validaría una contraseña como correcta. La contraseña sumaría un punto por cada carácter de longitud y los puntos correspondientes a las clases de caracteres que incluya. Pongamos, por ejemplo, que hemos establecido los argumentos minlen= 13 ucredit=1 ocredit=2 dcredit=2. La contraseña tristr4s suma diez puntos (ocho por longitud y dos más por contener un dígito) y no sería valida, mientras que Tristr4s! sumaría 14 (nueve por longitud, una por tener mayúsculas, dos por tener un dígito y otros dos por tener un signo de puntuación) y si sería permitida.

En las páginas del manual de cada uno de estos módulos puedes encontrar algunos otros argumentos interesantes.

IMPORTANTE: La mayor parte de estas restricciones se tendrán en cuenta sólo en el caso de que sea el propio usuario quien realice su cambio de contraseña. Si es el usuario root quien la establece inicialmente o la cambia se le permitirá saltarse a la torera la gran mayoría de estas normas, a veces sin siquiera una advertencia.
ACTUALIZACI?N: En Security by Default publican esta semana esta entrada con información mucho más técnica sobre los módulos de autenticación PAM donde, además, los analizan como posible punto para comprometer a un sistema.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Backups y recuperación de datos en PYMEs

Josemaría | 16 de diciembre de 2013 | Comentar
Una buena ración de estadísticas para preocuparse un poco…
especiales Según un reciente estudio realizado entre SMBs (“Small and Medium Business”, el nombre que reciben nuestras PYMES en el mundo anglosajón) de Estados Unidos, Francia, Alemania y Reino Unido por una importante empresa del sector de la virtualización, el 85% de los interrogados tenían problemas con el coste de sus soluciones de backup, el 83% con la capacidad o el espacio de almacenamiento requerido por las mismas y el 80% con la complejidad técnica necesaria para su uso.

El estudio no tiene desperdicio y hay muchas otras cifras interesantes en él. A veces, cuentan, recuperar un simple correo electrónico borrado puede llevar hasta 12 horas, el 17% de las recuperaciones de datos que se realizan presentan algún tipo de problema o error y hasta el 55% de las empresas está considerando cambiar sus métodos de backup para el año que entra.

No conozco ningún estudio similar en nuestro país, pero lo que he visto en las PYMEs (y también en alguna gran empresa) en las que he tenido algo que ver en los últimos años es similar a lo que se cuenta aquí. O, incluso, peor. Lo que me sigue sorprendiendo es la desidia a implementar soluciones robustas en este terreno cuando todos sabemos que los discos duros fallan (¡y mucho!), pero sobre todo que las personas cometemos errores y, más a menudo de lo que nos gustaría, borramos archivos por error. O de forma malintencionada. Mirad, si no, lo que ha ocurrido en la UGT hace bien poco ;-)

De lo segundo es bastante difícil conseguir datos fiables, pero de lo primero hay suficientes números como para echarse a temblar. El tiempo de vida medio de un disco duro en un entorno empresarial se estima en entre tres y cinco años. Los estudios realizados por Google dicen que a partir del segundo año la probabilidad anualizada de error en un disco se dispara al 8% y se mantiene entre este valor y el 10% en los tres años siguientes. Los estudios de ExtremeTech indican un porcentaje menor de errores en el segundo año pero los disparan a cerca del 12% a partir del tercero. Y ¿son más fiables los nuevos discos SSD? Es difícil comparar una tecnología con poco más de cinco años con otra de más de 50, pero los pocos estudios que se han hecho por el momento indican que el incremento en la fiabilidad de esta tecnología es escaso o inexistente.

Las técnicas de backup y de recuperación de datos son, hoy en día, inexcusables en un entorno informático y, si me apuran, en el personal. Cualquier empresa que se precie debería de tomarse ambas cosas muy en serio y asegurarse de que usa mecanismos acordes a lo que trata de proteger. Porque luego lamentarse es gratis, pero no sirve ya de nada.

Referencias:

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

RAID por software en Debian 7 con mdadm

Josemaría | 23 de octubre de 2013 | 2 comentarios

hard disk Para el que no lo sepa, un RAID en informática no es una carrera de aventuras sino un disco duro lógico creado a partir de la union de dos o más discos duros físicos con objeto (por lo general aunque no siempre) de proporcionar tolerancia a fallos. Las siglas vienen de Redundant Array of Inexpensive Disks y hace referencia a que, en su día, constituían una alternativa para proporcionar un almacenamiento seguro usando discos baratos en lugar de unos mucho más caros (por lo general SCSI). Ahí está la wikipedia para quién quiera aprender un poquito más ;-)

El método más seguro de usar esta tecnología es mediante hardware dedicado. Eso que quede claro. Pero cuando no queremos o no podemos gastarnos el dinero que esto requiere tenemos la alternativa de implementarlo mediante software. En Linux tenemos para ello mdadm, una herramienta en línea de comando muy sencilla de usar si entendemos los conceptos básicos de lo que estamos haciendo.

La instalación en una Debian es así de sencilla:

apt-get install mdadm

El script de configuración posterior a la instalación sólo nos planteará dos cuestiones. Leelas atentamente (como siempre… ;-) ). En la primera se nos pregunta si el sistema de ficheros raíz de nuestro Linux estará en un RAID con objeto de iniciarlo antes de la secuencia de arranque. En este ejemplo le diremos que no puesto que sólo usaremos RAID para los discos de datos, así que responderemos con none como se nos indica en el mensaje siguiente:

Instalación de mdadm en Debian Linux
En la segunda pregunta se nos interroga acerca de si queremos que los discos RAID que vamos a crear se inicialicen de forma automática durante cada inicio de la máquina o si preferimos hacerlo nosotros manualmente. Contestaremos que queremos que lo haga de forma automática.

Instalación de mdadm en Debian Linux
Una vez instalado mdadm ya podemos crear nuestro RAID. En el ejemplo que vamos a ver crearemos un RAID5 con tres discos de 500GB. El comando lsblk es muy cómodo para ver que asignación de nombres le ha hecho nuestro sistema a estos dispositivos:

Comprobando la asignación de nombres de dispositivos a nuestros discos duros con lsblk
El comando básico para crear un RAID es este:

mdadm --create dispositivo-md --level=x --raid-devices=z dispositivos-sd

O en formato abreviado:

mdadm --create dispositivo-md -l x -n z dispositivos-sd

Donde x es el nivel de RAID (admite los básicos 0, 1, 4, 5, 6, 10 y alguno más) y z el número de discos que formarán el array. El dispositivo-md será el nombre de dispositivo que recibirá el nuevo disco lógico (y que debería de estar en el directorio /dev y, por convención, llamarse md seguido de un número, por ejemplo /dev/md0) y los dispositivos-sd serían los discos físicos que forman el array separados por espacios (por ejemplo /dev/sdb /dev/sdc). Podemos añadir también la opción --verbose para obtener información más detallada del proceso de creación y los posibles fallos. Veamos un par de ejemplos:

Para crear un RAID0 con los tres discos indicados:

mdadm --create --verbose /dev/md0 --level=0 --raid-devices=3 /dev/sda /dev/sdb /dev/sdc

Para crear un mirror (RAID1) con los discos indicados:

mdadm --create /dev/md0 -l 1 -n 2 /dev/sdb /dev/sdc

La creación admite, aparte de estas, otras opciones avanzadas que puedes consultar en el manual que se ha instalado con él (man mdadm). Y vamos ya a seguir con nuestro ejemplo. Para crear el RAID5 que necesitamos ejecutamos lo siguiente:

mdadm --create --verbose /dev/md0 --level=5 -n 3 /dev/sdb /dev/sdc /dev/sdd

Si todo ha salido bien se nos mostrarán algunos mensajes informativos y el comando finalizará indicando que el disco md0 ha sido inicializado y arrancado. Podemos comprobar el estado de nuevo con lsblk o con more /proc/mdstat
Comprobando el estado de un RAID5 recién creado con mdadm

Para poder utilizar nuestro disco debemos aún formatearlo y montarlo en nuestro sistema de ficheros. Vamos a formatearlo como ext4 y a montarlo en un directorio que se llame datos dentro del subdirectorio /mnt:

mke2fs -t ext4 /dev/md0
mkdir /mnt/datos
mount /dev/md0 /mnt/datos

Si usamos ahora, por ejemplo, el comando df (df -k /mnt/datos) para ver el espacio de la partición y el porcentaje de uso veremos que, efectivamente, disponemos de cerca de 1TB correspondiente al tamaño del RAID5 con tres discos de 500GB que hemos montado.

Nos falta aún algo más. Durante la instalación le hemos dicho a mdadm que inicie de forma automática todos los arrays, pero eso no significa que los monte en el sistema de ficheros. Si queremos que lo haga automáticamente en cada arranque y en el mismo directorio donde lo acabamos de hacer de forma manual, tendremos que añadir una línea como la siguiente al fichero /etc/fstab:

/dev/md0  /mnt/datos  ext4  defaults  0  1

Vamos a echarle ahora un vistazo a diversos comandos de gestión y monitorización. Si queremos detener el volumen usamos el argumento --stop. No olvides desmontarlo antes para evitar que haya pérdida de datos:

umount /dev/md0
mdadm --stop /dev/md0

Luego, para volver a arrancarlo de forma manual:

mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Y si habíamos incluido la línea que indicamos antes en el fichero fstab para volver a montar el disco en nuestro sistema de ficheros basta con hacer esto:

mount /dev/m0 /mnt/datos

Para ver información de todos los arrays que tenemos en funcionamiento en la máquina usamos el argumento --detail:

mdadm --detail --verbose --scan

Información de los RAID en una máquina con mdadm

Sólo tenemos uno, claro. Para ver información en detalle del mismo:

mdadm --detail --verbose /dev/md0

Información en detalle de un RAID con mdadm

O también podemos usar el argumento --examine para ver información y el estado de cualquier a de los discos que forman nuestro array:
Información en detalle de uno de los discos de un RAID con mdadm

Vamos a simular ahora la rotura de uno de los discos. Para ello apagamos la máquina bruscamente y desconectamos uno de los tres discos del RAID. Podemos hacer fácilmente esta prueba tanto en una máquina real (¡que no esté en producción!) como en una virtual. Tras arrancar de nuevo nuestro RAID habrá perdido la tolerancia a fallos. No obstante, si hemos creado o copiado datos en el directorio /mnt/datos veremos que estos siguen siendo perfectamente accesibles.

OJO: Si el RAID no estaba aún totalmente inicializado (hemos usado discos muy grandes y no ha pasado suficiente tiempo desde su creación o desde la última vez que se recuperó de un fallo) el volumen no arrancará correctamente. Es por tanto muy importante no comenzar a usarlo hasta que no se ha inicializado completamente y extremar las precauciones después del fallo de algún disco hasta que volvemos a recuperar la tolerancia a fallos. Si miramos el pantallazo de aquí arriba en el que aparece la salida de ejecutar more /proc/mdstat vemos que allí aparece una barra de progreso donde se indica el estado de creación o reconstrucción del RAID. Mientras que esa barra no llegue al 100% y desaparezca mejor que no tengas ningún problema ;-)

Para recuperar la tolerancia a fallos debemos de añadir un disco nuevo. Lo hacemos y una vez arrancada de nuevo la máquina ejecutamos lo siguiente para añadir el disco /dev/sdc a nuestro RAID en sustitución del que hemos simulado que se ha roto:

mdadm /dev/md0 --add /dev/sdc

El RAID se reconstruirá sólo de forma automática pero dependiendo del tamaño y del volumen de datos podrá tardar más o menos tiempo. Observa de vez en cuando la salida de more /proc/mdstat para estar al tanto.

OJO: Después de perder un disco los nombres de los dispositivos pueden haber ??bailado?. Es muy importante que comprobemos antes (con lsblk, por ejemplo) cuales son los que siguen formando parte del array y cual el nuevo que queremos añadir.

Si lo que queremos es añadir al RAID un nuevo disco para que sea usado como hot spare basta con sumarlo a un RAID ya creado y funcional con el mismo comando que usamos antes para añadir un disco a un RAID estropeado:

mdadm /dev/md0 --add /dev/sde

Si lo que queremos es añadir el disco para agrandar el tamaño del RAID y no para que sea usado como hot spare tendríamos que usar los siguientes comandos:

mdadm /dev/md0 --add /dev/sde
mdadm --grow /dev/md0 ??raid-devices=4

En el fichero /proc/mdstat podemos ver el proceso como siempre:
Haciendo crecer nuestro RAID añadiendo un nuevo disco

Lo que no nos va a resolvernos mdadm es hacer que la partición que habíamos creado en el disco y sobre la que estábamos trabajando crezca. Eso es tarea nuestra:

umount /dev/md0
e2fsck -f /dev/md0
resize2fs /dev/md0
mount /dev/md0 /mnt/datos

Y el resultado:
Extendiendo la partición de un RAID al que hemos añadido un nuevo disco

NOTA: Como se puede observar, durante este último proceso de crecimiento del RAID hemos trabajado con cuatro discos (tres originalmente) de 1GB cada uno en lugar de los de 500GB que hemos usado en el resto del tutorial. Quería que se apreciara el cambio de tamaño del volumen y la resincronización de discos tan grandes habría supuesto tener que esperar muchas horas para poder visualizar el proceso completo.

Si lo que queremos es eliminar uno de los discos del RAID (para reemplazarlo por otro, por ejemplo) tenemos antes que marcarlo como fail. Luego lo eliminamos:

mdadm /dev/md0 --fail /dev/sdd
mdadm /dev/md0 --remove /dev/sdd

Y si quisiéramos eliminar el RAID usamos este comando:

mdadm --remove /dev/md0

mdadm tiene también un argumento llamado --monitor que le permite generar alertas cuando ocurre alguna incidencia en el RAID. Por defecto en una Debian el monitor se arranca como un daemon que graba las incidencias en el fichero de logs de la máquina (/var/log/syslog) de esta forma:

mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog

Si, además, quisiéramos que nos enviara dichas incidencias a nuestra cuenta de correo deberíamos de añadir la opción --mail:

mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog --mail josemaria@uponday.net
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Greylisting en Postfix y Debian 7

Josemaría | 27 de septiembre de 2013 | 2 comentarios

correoNadie se acuerda de Santa Bárbara hasta que truena, que dice el refrán. Yo tenía pendiente configurar un sistema de Greylisting (listas grises) en mi servidor de correo pero no lo he visto como urgente e inmediato hasta el aumento inusitado de actividad de los bots de spam de los últimos días.

El Greylisting es, hoy por hoy, uno de los métodos más efectivos a la hora de controlar el spam y su funcionamiento es sencillo y fácil de entender. Cuando un servidor de correo recibe un mensaje anota en una lista tres datos que lo identifican (la IP desde donde viene, el correo del remitente y el del receptor) y a continuación lo rechaza indicando al emisor que lo intente de nuevo más tarde. Esto se hace con un código 45x:

-> MAIL FROM: <sender@somedomain.com>
<- 250 2.1.0 Sender ok
-> RCPT TO: <recipient@otherdomain.com>
<- 451 4.7.1 Please try again later

Si el mensaje ha sido enviado por un servidor SMTP legítimo reconocerá el mensaje de rechazo y en un tiempo predefinido (típicamente de 300 segundos) reenviará de nuevo el correo que, en este caso, será aceptado por el servidor del destinatario. Un bot preparado para enviar spam no realizará el segundo envío. De esta forma, si el correo no es spam llegará al destinatario con 5 minutos de retraso. Salvo este detalle el emisor no se enterará de nada (todo el trabajo se hace entre los servidores de correo sin que los clientes intervengan). Si el receptor abre la cabecera del mensaje recibido verá una línea parecida a esta:

X-Greylist: delayed 300 seconds by postgrey-1.34 at invernalia; Thu, 19 Sep 2013 16:30:33 CEST

El sistema de control del spam mediante Greylisting fue originalmente ideado por Evan Harris en este whitepaper de 2003. El señor Harris mantiene, además, una lista de implementaciones de su método para diversos servidores de correo. Si quieres más información conceptual sobre esta técnica, esta página y la entrada correspondiente de la wikipedia también tienen información interesante.

Si ya tienes una Debian con un servidor de correo postfix funcionando la implementación en perl del Greylisting es muy, muy fácil de poner en marcha. Basta con instalar el paquete postgrey y añadir check_policy_service inet:127.0.0.1:10023 en la lista de restricciones del fichero main.cf de configuración de postfix en el directorio /etc/postfix:

smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023

Por supuesto, una vez hechas ambas cosas debemos de reiniciar el servicio postfix. La instalación nos ha creado un nuevo servicio llamado postgrey que arranca como daemon y escucha en el puerto 10023 y que responde a los argumentos habituales: start, stop, restart, reload, force-reload y status. En el directorio /etc/postgrey tenemos dos ficheros denominados whitelist_clients y whitelist_recipients donde, respectivamente, se pueden especificar las direcciones de ciertos servidores smtp o direcciones de correo que no se someteran al procedimiento de rechazo temporal de los mensajes y que se aceptaran al primer intento. Tenemos, además, un fichero donde se encuentra la configuración principal del servicio llamado /etc/default/postgrey que veremos más adelante.

Si observamos ahora el log de nuestro postfix (/var/log/mail.log) podemos estudiar el funcionamiento y si este es correcto. Cuando recibimos cualquier correo (salvo uno ya identificado como válido en las whitelist) será inmediatamente registrado y rechazado:

Al cabo de cinco minutos si el correo es legítimo el servidor remitente volverá a intentarlo y ahora el correo si será aceptado:

Puede que el servidor emisor se impaciente y antes de que transcurran esos cinco minutos vuelva a intentarlo. En ese caso el correo volverá a ser rechazado:

Como puedes observar en los mensajes del log, aparte de la razón del rechazo el servidor enviará una dirección web personalizada donde se informa detalladamente de lo que está ocurriendo:

mensaje de información de postgrey en castellano

Postgrey crea, además, una base de datos en el directorio /var/lib/postgrey donde guarda información acerca de los mensajes recibidos. Después de aceptar cinco mensajes de un servidor, este será automáticamente incluido en una whitelist de tal forma que, a partir de este momento, ya no se le volverá a exigir el trámite de los reintentos. Podemos consultar en cualquier momento los servidores de esta lista ejecutando el siguiente script:

perl /usr/share/doc/postgrey/postgrey_clients_dump

Y una ejecución de ejemplo:

Servidores incluidos en la whitelist de greylist

Tenemos aún pendiente ver el fichero de configuración principal: /etc/default/postgrey. En el podemos modificar, por ejemplo, el texto que aparecerá en el mensaje de rechazo:

POSTGREY_TEXT="Si tu sevidor funciona como debiera debería de intentar enviarme de nuevo el mensaje en 5 minutillos de nada"

También podemos enviar al demonio cualquiera de los argumentos que tenemos disponibles para modificar su funcionamiento (ver man postgrey) mediante el parámetro POSTGREY_OPTS. Por ejemplo, en la siguiente línea se dice al demonio que escuche en el puerto 60000, subimos el retraso para aceptar el mensaje a 600 segundos y le indicamos que incluya las direcciones de los clientes en la whitelist después de aceptarles 3 envíos:

POSTGREY_OPTS="--inet=60000 --delay=600 --auto-whitelist-clients=3"

Para terminar, si quieres comprobar la configuración de tu servidor de correo electrónico para ver si es vulnerable de alguna forma y puede ser usado como un Open Relay, si el correo saliente que envía puede verse bloqueado de alguna forma, etc. existen muchas herramientas en línea pero las más cómodas y completas, a mi juicio, son las de mxtoolbox y el test de allaboutspam.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Instalación y primeros pasos con ntop 5 en Debian 6

Josemaría | 25 de marzo de 2013 | 6 comentarios

ntop es la herramienta más popular y completa para monitorizar el tráfico de una red cuando nos interesa, no sólo conocer la magnitud del mismo sino su procedencia y características. Colocado en un punto estratégico de nuestra red nos sirve para detectar cualquier tipo de anomalía en la misma. Si lo instalamos en un servidor nos sirve para auditar el tipo de tráfico que este emite y recibe de forma gráfica y muy didáctica.

Como ocurre en algunas ocasiones la versión en la paquetería de debian (4.0.33 en la estable y 4.99.3 en testing y unstable) va bastante por detrás de la del producto (5.0.1) así que si te apetece jugar con lo último lo mejor es bajarte los fuentes y compilarlos en tu máquina. Pero ya sabes que, en este caso, tendrás que preocuparte de posibles actualizaciones de forma manual. ntop, en particular, no parece tener ningún aviso automático de la aparición de nuevas versiones. Vamos a ello.

Antes que nada, instalamos los paquetes necesarios para realizar la instalación, las dependencias y alguna otra cosa necesaria:

apt-get install build-essential libtool automake autoconf libpcap-dev libgdbm-dev rrdtool librrd-dev libssl-dev python-dev libgeoip-dev graphviz subversion python-pip

A continuación nos descargamos de aquí la última versión estable de ntop, la copiamos en, por ejemplo, el directorio /tmp de nuestra máquina y la descomprimimimos:

wget -c http://sourceforge.net/projects/ntop/files/ntop/Stable/ntop-5.0.1.tar.gz
tar xvfz ntop-5.0.1.tar.gz

Ahora entramos al directorio donde se han descomprimido los fuentes (ntop-5.0.1 en este caso) y generamos los binarios.

cd ntop-5.0.1/
./autogen.sh
make
make install
ldconfig

Y listo. Sólo nos quedan unos cuantos retoques. Los datos que ntop capture una vez esté en funcionamiento se guardarán en /usr/local/var/ntop. El daemon de ntop se ejecuta con el usuario nobody, así que debemos de hacerlo propietario de dicho directorio para que pueda escribir libremente en él:

chown -R nobody /usr/local/var/ntop

El binario de ntop ya está listo para ejecutarse y se encuentra en el directorio /usr/local/bin. Si escribes ntop -help tendrás una detallada lista de posibles opciones. Las mías son estas:

/usr/local/bin/ntop -i eth0 -w 3001 -L -d

De esta forma ntop monitorizará todo el tráfico enviado y recibido por el interfaz de red eth0 de nuestra máquina, el interface web de ntop escuchará peticiones en el puerto 3001 (por defecto lo haría en el 3000), guardará los mensajes de log en el syslog de la máquina (/var/log/syslog) y se ejecutará como daemon o servicio en segundo plano.

En la primera ejecución nos pedirá que introduzcamos la contraseña para el usuario admin necesaria para entrar a ciertas páginas restringidas del programa. Muy pocas, la verdad, pero luego veremos como solucionar esto.

ACTUALIZACI?N: Las últimas compilaciones llevan por defecto la contraseña admin para el usuario admin

Para acceder a ntop ya sólo tenemos que ir a nuestro navegador y escribir lo siguiente sustituyendo ip-de-la-maquina por la dirección o nombre correcto donde hemos hecho la instalación y cambiando el puerto por el adecuado si lo hemos modificado en la orden de inicio anterior:

http://ip-de-la-maquina:3001

Pantalla principal de ntop (Traffic Summary)

Para proteger el acceso a cualquier página de ntop (imprescindible sobre todo si es visible desde Internet) debemos de entrar en el menú superior (Admin -> Configure -> Protect URLs) y añadir una regla con un asterisco ‘*’ al limitado grupo de usuarios que deseemos (o al usuario admin si es una instalación de uso particular).
Protegiendo el acceso a ntop

Ahora ya sólo nos quedan unos pequeños ajustes para disponer de algunos gráficos y diagramas adicionales que, por defecto, no vienen configurados. El plugin Round-Robin Database debería de estar activado para disponer de los gráficos de Network Load generales o por protocolo.
Gráficos de carga por protocolo en ntop con rrd activado

Para ello, además de activar el plugin (Plugins -> Round-Robin Database -> Activate), deberíamos de comprobar que en la pantalla de Preferencias (Admin -> Configure -> Preferences) la cadena rrd.rrdPath apunta a un directorio donde el usuario nobody tenga permisos de escritura (típicamente /usr/local/var/ntop/rrd), que en la configuración del plugin (Plugins -> Round-Robin Database -> Configure) las dos cadenas del bloque RRD Files Path apuntan al mismo directorio y que en el bloque Data to Dump de esta misma pantalla tenemos seleccionada, al menos, la opción de Interfaces. Si seleccionamos todas las opciones tendremos muchos más datos de captura pero a costa de cargar más la ejecución y el espacio ocupado por las capturas. Mucho cuidado con el espacio en disco, que podemos necesitar fácilmente 2 Gigas por día en un servidor con un tráfico corrientito.
Configurando rrd en ntop

Para ver los mapas por regiones tenemos que instalar las plantillas Mako para python. Como al principio de todo hemos instalado el paquete python-pip nos basta con salir a línea de comandos y ejecutar lo siguiente:

pip install Mako

Graficos geográficos con Mako y ntop

Por último, aunque hemos instalado graphviz y Dot es uno de sus elementos integrantes, nos hace falta añadir un path en las Preferencias (Admin -> Configure -> Preferences) para disponer de los Mapas de Tráfico de Red Locales. Entramos en ellas y, al final de la tabla, añadimos la cadena dot.path con el valor /usr/bin/dot. Pulsamos Add, confirmamos y listo.
Gráficos de tráfico de red local en ntop

ntop tiene muchas otras gráficas y páginas de información útil e interesante además de estas que he mostrado y cuyo único motivo para aparecer aquí es que necesitan de algún retoque extra en la configuración para poder usarlas, así que lo mejor es que las explores una a una. La documentación para interpretarlas es escasa, todo hay que decirlo, pero últimamente se están poniendo las pilas en este sentido y han prometido, por fin, un manual de usuario en breve.

Y ya sólo nos queda un pequeño detalle para concluir. Si quieres que ntop se ejecute de forma automática como servicio cada vez que hagas un reinicio de la máquina donde la tienes instalada sólo tienes que crear un fichero .sh (por ejemplo ntop.sh) con la línea de ejecución que has usado antes para ponerlo en marcha, crear un enlace al mismo en el directorio init.d y ejecutar lo siguiente:

ln -s /opt/Scripts/ntop.sh /etc/init.d/ntop
update-rc.d ntop defaults 99
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes