Hola!

Hace unos meses me puse a instalar LXC para un cliente, y tenía la necesidad de que sus contenedores estuvieran en la misma red que sus servidores físicos. Por lo general LXC crea una red 10.0.3.0/24 y un puente con la ip 10.0.3.1 llamada “lxcbr0“, por tanto, lo que haremos será agregar otro puente usando la tarjeta de red activa, luego indicamos a LXC que cree los contenedores usando ese nuevo puente, estos son los pasos:

En nuestro /etc/network/interfaces (debian y ubuntu), generalmente tendremos esto:


auto eth0
iface eth0 inet static
       address 192.168.1.250
       netmask 255.255.255.0
       gateway 192.168.1.1
       dns-nameservers 8.8.8.8 8.8.4.4

Lo cambiamos a esto:


auto br0
iface br0 inet static
        bridge_ports eth0
        address 192.168.1.250
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 8.8.8.8 8.8.4.4

Con esto creamos nuestro nuevo puente “br0” ligado a eth0 (puede ser em1 ó enp5s0, etc)

Ahora toca indicarle a LXC que los nuevos contenedores usen este puente, editamos /etc/default/lxc-net y cambiamos USE_LXC_BRIDGE a: USE_LXC_BRIDGE="false"

Y en /etc/lxc/default.conf cambiamos lxc.network.link = lxcbr0 a lxc.network.link = br0

Y listo. Ahora dentro de los contenedores puedes usar configuración estática, o por dhcp.


auto eth0
iface eth0 inet dhcp

auto eth0
iface eth0 inet static
        address 192.168.1.10
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 8.8.8.8

.

Usar IP externa de una red diferente

Ahora, ¿porque me acordé de algo que hice algo meses?, porque lo reintenté para ponerle una IP pública a un servidor LXC en un dedicado que tengo, y ¡No funcionó!

El dedicado tiene una IP del tipo 199.xx.xx.105 al comprarle una IP extra (ó Failover IP) el proveedor me asignó la ip: 146.xx.xx.239 , al querer añadirla a un contenedor, éste se quedaba sin red y no se “veía” (ping) ni con el Host, por ahí ví un error “Network unreachable“, ¡claro! las dos IP’s son de dos redes diferentes y no hay nadie (un router) que les diga como comunicarse, así que la solución fue añadir una nueva ruta a la tabla de ruteo de linux. Estos son los pasos:

Teniendo ya el puente br0 configurado y funcionando, hay que indicarle a LXC que deseamos forzar una dirección IP, esto lo hacemos editando la configuración del contenedor en /var/lib/lxc/MICONTENEDOR/config:


lxc.network.ipv4=146.xx.xx.239
lxc.network.ipv4.gateway=199.xx.xx.105

Aquí hay que hacer notar que hemos puesto como gateway del contenedor la IP del Host. Esto es muy importante.

Y dentro del contenedor la siguiente configuración de red (/etc/network/interfaces) constará solamante de una sóla instrucción: “auto eth0” (dejando también la parte del loopback claro)

En este momento ya puedes levantar el contenedor con lxc-start, métete con lxc-attach y verás como tiene la IP que indicaste en su configuración, si ejecutas un route -n verás como su gateway es también lo indicado en la conf. Pero ¡NO TIENE RED!, déjalo “prendido” y de lado del Host ejecuta lo siguiente:

route add 146.xx.xx.239 br0

Tadá! Si haces un ping a la IP verás como ya responde, si te metes al contenedor verás como ya tiene red y puede responder a todos los servicios. Ahora, por supuesto estar agregando la ruta manualmente cada que iniciemos el contenedor está de hueva, vamos a automatizarlo.

Creamos dos scripts en /var/lib/lxc/MICONTENEDOR/ uno llamado iface-up.sh y otro iface-down.sh

iface-up.sh:


#!/bin/bash
route add 146.xx.xx.239 br0

iface-down.sh:


#!/bin/bash
route del 146.xx.xx.239 br0

No te olvides de darle permisos de ejecución a ambos scripts! Ej. chmod +x iface-up.sh

Y vamos a editar nuevamente la configuración del contenedor para añadir las siguientes dos líneas después de la parte donde añadimos los parámetros de red:

/var/lib/lxc/MICONTENEDOR/config:


...
lxc.network.ipv4=146.xx.xx.239
lxc.network.ipv4.gateway=199.xx.xx.105

lxc.network.script.up = /var/lib/lxc/MICONTENEDOR/iface-up.sh
lxc.network.script.down = /var/lib/lxc/MICONTENEDOR/iface-down.sh

Done. Ya con esto puedes probar parar e iniciar el contenedor varias veces, vigilando el estado de su red y de la IP y no debería tener problemas para acceder a Internet y viceversa.

Hola mundo,

Finalmente y después de tanta espera, Let’s Encrypt ha entrado en fase de Public Beta, es decir ya cualquiera que desee probarlo puede entrar y generar sus certificados.

Para quienes no conozcan que es Let’s Encrypt, es una nueva Autoridad de Certificación, abierta y gratis. Es administrado por la Internet Security Research Group (ISRG), y es patrocinado por las mas importantes Fundaciones de Internet, tales como la EFF, Mozilla, y también por grandes empresas como Cisco, Facebook, Ident Trust, Internet Society, entre otros.

La idea de Let’s Encrypt es que cualquiera tiene derecho de poder ofrecer seguridad a través de la encriptación (HTTPS) en sus sitios web, antes de la llegada de Let’s Encrypt, uno tenía que pagar a una Autoridad de certificación tales como Symantec, GoDaddy, DigiCert, Verizon, etc… cierta cantidad desde unos cientos y hasta los miles de USD dependiendo el nivel de certificación deseada.

Pero para la mayoría de usuarios un certificado de validación de nombre de dominio es mas que suficiente y esto es lo que ofrece Let’s Encrypt, que tus usuarios tengan plena seguridad de que los datos que viajan desde su máquina a tu servidor/sitio no puede ser leída por nadie mas, pues el certificado sólo puede provenir del servidor donde reside el dominio auténtico y no de un suplantador (ó de una agencia de espionaje cofcofNSAcofcof)

 

Instalación

Primero que nada, todo lo siguiente debes correrlo en el servidor en donde residen los dominios para los que quieres generar los certificados, pues Let’s Encrypt debe poder escribir ciertos archivos en su WebRoot (a.k.a. DocumentRoot) para poder validar efectivamente que eres el dueño del dominio y tienes control sobre él.

Paso 1, Debes tener Git instalado y clonar el depósito:

user@webserver:~$ git clone https://github.com/letsencrypt/letsencrypt.git

Paso 2, Córrelo una vez para que pueda instalar todas sus dependencias (la mayoría bibliotecas en python), por tanto debes tener privilegios de administrador ya sea acceso a root directo o por medio de sudo, posteriormente generará una nueva llave privada y con el email que le especifiques creará una nueva cuenta para ti en los servidores de Let’s Encrypt, todo esto es un proceso automático. NOTA: De momento no le especifiques ningún dominio.


root@webserver:~$ cd letsencrypt
root@webserver:~/letsencrypt$ ./letsencrypt-auto --email tudireccion@deemail.com --agree-tos

Paso 3, Let’s Encrypt tiene plugins para poder leer archivos de configuración de Apache, saber que dominios tienes, donde están y modificar estas configuraciones para añadir los certificados de manera automágica, pero esto es un grave problema para los que tenemos servidores web con algún tipo de panel de control que genera sus propias configuraciones y sobreescribirían los cambios hechos por Let’s Encrypt, otra opción es que dejes a Let’s encrypt levantar un web server standlone, pero esto implica que debes detener tu web server principal.

En mi caso estos 2 primeros métodos no son una opción, así que me fuí por la tercera, puedes darle a Let’s Encrypt el path al DocumentRoot de tu dominio para que realice la validación con unos archivos especiales que debe guardar allí. Aclarado esto, digamos que tienes tus dominios en /var/www/$dominio, por ejemplo /var/www/fulanito.com, correríamos lo siguiente:


root@webserver:~/letsencrypt$ ./letsencrypt-auto certonly --webroot -w /var/www/fulanito.com/ -d fulanito.com

¡Y listo!, generará automáticamente tu CSR (Certificate Signing Request), lo firmará, lo enviará a los servidores de Let’s Encrypt, estos validará que existan los archivos en fulanito.com/.well-known/acme-challenge/ y de ser así devolverá el certificado firmado. Se generarán 4 archivos en /etc/letsencrypt/live/fulanito.com/


root@webserver:~# ls /etc/letsencrypt/live/fulanito.com/
cert.pem  chain.pem  fullchain.pem  privkey.pem

Los cuales contienen:

  • cert.pem – contiene el certificado firmado
  • chain.pem – certificado “intermedio”
  • fullchain.pem – contiene ambos cert.pem y chain.pem, para los servicios que soporten este formato
  • privkey.pem – la llave privada del certificado

Configurar el webserver (Apache y NginX)

Esto sería lo único a añadir en tu virtualhost de Apache, (si antes no usabas SSL, asegúrate de activar los módulos y habilitar el virtualhost de SSL que contiene las entradas para el puerto 443)


<VirtualHost ww.xx.yy.zz:443>
        ...
        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/fulanito.com/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/fulanito.com/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/fulanito.com/chain.pem
        ...
</VirtualHost>

Y para NginX, algo como lo siguiente:


server {
    listen      ww.xx.yy.zz:443;
    server_name fulanito.com www.fulanito.com;
    ssl         on;
    ssl_certificate      /etc/letsencrypt/live/fulanito.com/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/live/fulanito.com/privkey.pem;
    ...

Y eso es todo, espero este artículo les sirva en algo y les ayude a brindar mas seguridad a sus sitios web. Como ven es bastante fácil utilizar Let’s Encrypt.

Sólo resta mencionar que quienes tienen su hosting/cloud server/dedicado con ideaslabs.com pueden solicitar su certificado gratis y se les será configurado casi al instante sin costo alguno ;)

Saludos!

Hay momentos donde necesitamos tener plena seguridad de que los datos que son transmitidos desde nuestra máquina hacia internet no son leídos por terceros (¡eso sería siempre!), cómo cuando vamos a un café con wireless disponible ó un congreso lleno de ávidos “hackers” todos con sus sniffers llenando sus logs de contraseñas de terceros y luego aparecen los blogs de “hackers éticos” “defaceados” (ñ_ñ). En fin, necesitamos seguridad, y no todo lo que usamos se encuentra bajo SSL, ó no sabes que tiene la opción, por ejemplo, ¡levante la mano quien usa twitter con https!. Hay otras situaciones molestas como cuando un maldito proxy nos filtra contenido, no podemos ver todos los sitios ó usar todos los servicios que necesitamos, o simplemente nos cierran puertos que necesitamos, como el sagrado IRC.

Bien, para todos estos males existen los túneles SSH, quienes realizan una conexión segura, encriptada, y desde un servidor remoto, por lo que nuestro origen queda anónimo. Todo lo que necesitas es una máquina en una red externa (típicamente un servidor) en la que tengamos acceso ssh. Según la necesidad, podemos requerir de 3 diferentes esquemas:

  1. Estás tras un proxy y no te deja salir a todas las redes o te filtra sitios que realmente necesitas. ¡Tú necesitas Dynamic application-level port forwading!
  2. Te cerraron los puertos y necesitas acceder a algún servicio del servidor A con el puerto XX. ¡Tú necesitas Local Port forwarding!
  3. Estás tras un router, con ip privada y necesitas que alguien entre a algún servicio de tu máquina sea HTTP, SSH, FTP, etc. ¡Tú necesitas Reverse Port Forwarding! (también llamado Remote port forwarding)

1. Dynamic application-level port forwarding

El esquema mas sencillo, funciona como un proxy para cualquier aplicación para cualquier servicio, SMTP, HTTP, POP, IMAP, etc. Bajo este esquema, puedes redireccionar todo el tráfico de un puerto local hacia un servidor remoto a través de otro servidor “de redirección” para cualquier tipo de aplicación que trabaje con protocolo Socks, aunque en la mayoría de los casos si no lo soporta puedes forzarlo con una utilidad que veremos mas adelante. En pocas palabras, haces que un servidor B baje por ti el contenido del servidor A y lo reenvíe a tu máquina local.

El escenario es el siguiente, tienes tu maquina “local” restringida, y tienes acceso a “shell.server.tld” y quieres usar la conexión abierta de “shell.server.tld” para que te reenvíe todo hacia “local”, esto lo hacemos mediante:

fulanito@local $ ssh -N -D 8888 shell.server.tld

La opción -N es para que no lanze ningún comando al hacer la conexión, solo establezca el tunel. Puedes añadir -f para que además se vaya a background. Y claro añade las opciones que necesites como -pPuerto -lUser, etc. para realizar la conexión ssh.

Y listo!, ahora vamos al Firefox (¿que?, ¿que no usas firefox? ¿en que mundo vives? osea jelou!) y en Edit->Preferences->Advanced->Network->Settings , seleccionamos “Manual proxy configuration” y en la entrada de text de “Socks Host” metemos 127.0.0.1 puerto 8888, desde luego puedes cambiar el puerto por otro aquí y en el comando ssh. ¡Presto! ahora ve a tu firefox y abre, digamos, http://www.whatismyip.org/, verás como ya estás saliendo desde la ip del servidor “shell.server.tld”

Si estas usando algún programa que no soporte Socks, puedes instalar “tsocks” y configurar en /etc/tsocks.conf la conexión. Por ejemplo hasta el final del archivo yo tengo:


server = 127.0.0.1
server_type = 5
server_port = 8888

Ahora, abre el tunel con el comando antes descrito, y posteriormente corre tu programa anteponiendo “tsocks”, por ejemplo:

fulanito@local $ tsocks opera

Et voilá!. Está de mas decir que puedes abrir mas de una conexión y usar varios navegadores saliendo por diferentes IP’s. Muy útil cuando andas mmm digamos, analizando un sitio de forma anónima ;-).

Local Port forwarding

Ahora sí vamos a forwardear puertos de verdad, El anterior esquema es a nivel aplicación, SSH entiende que debe servir de proxy para lo que le pida la aplicación, si pides la página de google por socks, ssh entiende que tiene que conectarse a google y reenviar el contenido a tu máquina local a través de un tercer servidor, y dinámicamente cambia del servidor de google al de yahoo, o hotmail, o facebook, etc. En este esquema de Local Port forwarding (y también el Remote/reverse port forwading) SSH simplemente reenvía todo lo que mandes a un puerto local hacia un servidor destino a través de un servidor donde tienes shell. Es decir, sólo puedes redirigir el tráfico hacia un sólo servidor. Usemos el vano ejemplo del IRC, no se porque siempre nos bloquean el puerto IRC (6667) así que tenemos el escenario:

Estamos en maquina “local”, tenemos acceso shell a “shell.server.tld” y queremos conectarnos a irc.freenode.net. Lo que tenemos que hacer es lo siguiente:

fulanito@local $ ssh -N -L 3337:irc.freenode.net:6667 shell.server.tld

Y listo, tenemos un tunel desde nuestra máquina en el puerto 3337 a irc.freenode.net:6667 a través de shell.server.tld. Ahora todo lo que nos queda hacer es:

fulanito@local $ irssi -c localhost -p 3337

Y irssi nos mostrará el MOTD (Message Of The Day) de freenode, tal y como si nos estuvieramos conectando directamente desde shell.server.tld.

Y claro, podemos usar el tunel para diversos servicios:

  1. Para conectar a un proxy externo: fulanito@local $ ssh -N -L 1080:proxy.server.com:8080 shell.server.tld
  2. Para conectarse a un servidor POP: fulanito@local $ ssh -N -L 1110:pop.server.com:110 shell.server.tld
  3. Para conectarnos al webserver de una máquina de la chamba: fulanito@casa $ ssh -N -L 8080:maquinadelachamba:80 maquina-con-ip-externa-de-la-chamba.dyndns.com
    Con este ejemplo aprovecho para mencionar un pequeño detalle: cuando especificamos “-L puerto:hostdestino:puerto shell.server.tld”, ponemos a “hostdestino” tal y como “shell.server.tld2 lo vé, es decir, si “shell.server.tld” puede ver a maquinas con ip’s privadas dentro de su red, podremos especificar en -L una ip privada, por ejemplo: “ssh -N -L 8080:192.168.1.100:80 189.10.20.30

Reverse/Remote Port forwarding

Este esquema es quizás el más divertido y confuso de los tres, basicamente es lo mismo que -L pero “en inversa”, expliquemos.

Con -L le dices a ssh que reenvíe el tráfico que vaya a un puerto local hacia uno remoto, con -R le dices a ssh que reenvíe el tráfico que llegué a un puerto remoto hacia uno local. ¿Para que nos sirve algo así?, pongamos dos escenarios:

1. El Soporte Técnico.
Tienes un problema con tu linux/mac os x/unix/whatever, y quieres que un amigo se conecte a tu máquina para ayudarte y estas detrás de un router, con ip privada, y sin privilegios para poder abrir un puerto en el router que redirija el tráfico a tu máquina. Solución, abres un tunel “reverso”:

fulanito@local $ ssh -N -R 2200:localhost:22 shell.server.tld

Lo cual quiere decir: “abre un tunel desde shell.server.tld en el puerto 2200 que reenvíe el tráfico hacia mi máquina (localhost) en el puerto 22”. Y ahora le dices a tu amigo que se conecte a shell.server.tld y desde ahí el tiene que correr:

sutanito@shell $ ssh -p2200 localhost

Y se reenviará la conexión hasta tu máquina, en otras palabras, podrá conectarse a tu máquina desde otra, pero sólo mientras mantienes abierto el tunel. Por default, todos los túneles escuchan sólo a la interfaz loopback, es decir, solo aceptan conexiones desde la misma máquina en donde se está abriendo el tunel, es por ello que tu amigo debe primero entrar a shell.server.tld y luego conectarse a “localhost”. Existe la posibilidad de que tu amigo se conecte directamente a shell.server.tld:2200 desde su máquina, eso lo veremos en el siguiente ejemplo:

2. Publicar un servicio.
Ahora, digamos que estas en un starbucks, o algo así. Y necesitas enseñar lo que tienes en tu webserver local a un cliente, como ya establecimos, no puedes abrirte un puerto para que el cliente mire hasta tu máquina con ip privada. Solución, abres un tunel “reverso”:

fulanito@local $ ssh -N -R 8888:localhost:80 shell.server.tld

Y listo, el túnel leerá la página de tu máquina y la servirá a través de shell.server.tld:8888, entonces le das a tu cliente la dirección http://shell.server.tld:8888/

Pero como decíamos en el anterior ejemplo, los túneles solo atienden a “localhost” por lo que para que tú cliente pueda acceder directo a shell.server.tld:8888, debemos agregar una opción al final del archivo /etc/ssh/sshd_config:

GatewayPorts yes

Y listo ahora los túneles escucharán en cualquier interfaz.

Nota:
Ten en mente siempre, la información viajará encriptada solamente desde tu máquina local hacia el servidor donde estás estableciendo el tunel, de acuerdo a nuestros ejemplos, la información viajará encriptada desde local <=> shell.server.tld, pero desde shell.server.tld <–> irc.freenode.net (u otro destino final) no estará encriptada. En el 99% de los casos esto servirá para mantener tus datos seguros.

Y bien, espero me haya sabido explicar, si creen que algo está demasiado confuso por favor, exprésenlo en un comentario. Si tienen mas ideas de como usar los túneles SSH, ó tienen una anécdota sobre alguna vez que tuvieron que ingeniárselas para resolver un problema usando túneles SSH, por favor, compártanla.

NaCl U 2

Hoy, como todos los últimos viernes de Julio de cada año, se festeja el día de apreciación del sysadmin. Generalmente lo recuerdo porque es cerca de mi cumpleaños (27), pero esta vez me lo recordaron mis estimados compañeros de ideaslabs, Así que si lees esto, agradécele a tu sysadmin, porque:

  • Un sysadmin es quien desempaca los equipos, les instala el sistema operativo, los configura, los asegura contra hackers, crackers, defacers, scriptkiddies, lammers, virus, worms, SPAM, etc., y los pone en red, para que tu puedas ver tus páginas favoritas, tus videos, tu facebook, tu myspace, tu hi5, etc.
  • Un sysadmin es quién pone la red de tu empresa, casa, ISP, etc, se asegura de la calidad de transmisión y de que tú puedas leer tu correo, ver el blog de tu novia, y hasta tener la posibilidad de trabajar cómodamente desde tu casa sin tener que ir a la oficina.
  • Un sysadmin es quién se despierta a las 3am porqué el servidor de mail no funciona correctamente, o el servidor web se cayó, etc., el tiene que levantarse y ponerse a trabajar, un sysadmin trabaja 24x7x365 sin descansos, todo para que tu puedas disfrutar de todos los beneficios de la Web.

Así que si tu puedes leer esto, es seguramente por uno o varios sysadmin’s que realizaron perfectamente todo su trabajo para que este sitio funcionara y tu pudieras leerlo.

Así que si tu eres trabajador de una empresa, ve al departamento de sistemas y agradécele el que puedas leer diariamente tu correo.

Si hospedas tu página web en un servicio de hosting, envía un correo a soporte, esta vez, no para quejarte, si no para agradecerles el arduo trabajo que realizan diariamente.

En fin, si conoces a un sysadmin, vé y demuéstrale que reconoces su trabajo, y no sólo lo recuerdas cuando no funciona algo.

Feliz día de apreciación del sysadmin!

Ref. www.sysadminday.com

¿Eres administrador de sistemas?, ¿Administras un servidor de correo?, ¿Te harta lidiar con el spam?, ¿Tienes ese spammassasin lleno de reglas que ya ni recuerdas y aun así te sigue llegando spam?, ¿Usas Postfix?, ¿Te dejó tu novia?, bueno eso no :-p, pues Postgrey es para ti !

Postgrey es un pequeño script en perl (pequeño de 800 líneas :-/) que te permite implantar listas grises (Greylisting) en tu postfix, ¿Que que es greylisting?:

Greylisting es el método por el cual se deniega el primer envío de un remitente desconocido, mediante un código de error 450 (deferred). Muchos de los virus y spammers no siguen el protocolo SMTP correctamente, con lo que nunca volverán a enviar ese mensaje. Mediante el greylisting podemos evitar que nos lleguen mensajes de virus y proxies abiertos, pero no podemos evitar que nos lleguen de servidores de correo mal configurados que permiten relay, aunque con un poco de suerte en el siguiente reenvío ese servidor ya esté en alguna lista RBL y podremos evitarlo.

¿Y eso de que me sirve? , bien, como todos sabemos los spammers tienen scripts que se conectan a servidores smtp mal configurados, y desde ahi te envian su spam con direcciones falsas tipo hot_jenny_wants_you@xYab34S09.com , y es imposible responderles para mentarselas :-), pues bueno en esto está la ventaja del greylisting, lo que hace es:

  1. Recibe el mail, guarda en una pequeña bd la dirección del remitente, si ésta no existe en la bd de mail’s auténticos prosigue con el paso 2, si está paso 4
  2. inmediatamente lo rechaza con un código de error 450 (delay ó intentar después)
  3. el servidor SMTP remoto entiende el mensaje y vuelve a mandar el mail en el tiempo especificado
  4. postgrey recibe de nuevo el mail se da cuenta que ya habia llegado antes, revisa el delay, agrega el remitente a la bd de cuentas de mail auténticas (si es que aun no está) y lo deja pasar al mta (postfix)
  5. el mail llega a su destino (tu cuenta)

¿Y que ganamos con esto?, la seguridad de que te van a llegar mails sólo de cuentas existentes, adiós spam!, ¿demasiado bueno para ser verdad?, así es :-D, los spammers podrían adaptar su software para engañar al postgrey enviando spam desde cuentas existentes, pero esto te da una enorme ventaja, ya que puedes bloquear facilmente esas cuentas, o rango de ip, o dominios o como se te plazca, que de otra forma no podrías, como bloquear un dominio inexistente de la forma xYab34S09.com, por ejemplo, o un usuario xyasdyigsf2314.yahoo.it que tampoco existe

Lo he probado desde hace 1 mes en dos servidores de mail y hasta ahora 0 spam, lo juro! (si split_yo, por mi madre que si), CERO, altamente recomendado ;-)

Página de PostGrey:
http://isg.ee.ethz.ch/tools/postgrey/
Informacion de postfix acerca de greylisting
http://www.postfix.org/SMTPD_POLICY_README.html
Sobre greylisting
http://greylisting.org/
Guía rápida de Postfix (buenísima)
http://www.servitux.org/view.php/page/postfix

Anterior Utilidad – Las Pequeñas Grandes Utilidades (Woof)