comienza asterisk (parte 2)

30 de septiembre de 2008

Ya tenemos los switches PoE a pleno rendimiento. Hemos movido todas las maquinas de la oficina a PoE para que cuando lleguen los teléfonos Polycom podamos conectar el teléfono a PoE y del teléfono al ordenador. Esto lo hacemos por dos motivos. Primero para ahorranos un transformador de corriente en el teléfono y segundo para hacer un paralelo con la telefonía tradicional que mantendremos hasta que veamos que Asterisk funcionan al 100%. Cada puesto de trabajo tiene dos bocas de ethernets: una para el teléfono tradicional y otra para el teléfono voip + la estación de trabajo.

Este es el aspecto del rack una vez hemos movido (temporalmente) todas las estaciones de la oficina a PoE.


También nos ha llegado el primer teléfono de adelanto para ir probándolo con lo switches y la configuración de las VLANs en ellos. Como en el los swicthes PoE hay teléfonos y estaciones de trabajo tendremos que configurar al menos dos VLANs. Una VLAN para voz y otra para datos. Además los propios teléfonos Voip también tienen protocolo 802.1q para montar VLANs de tal forma que también tendremos que separar la voz de los datos. Otra posibilidad es hacer QoS en los switches, pero no es lo recomendable. Lo recomendable es separar los broadcast y utilizar VLAN y puertos de trunking.

Este es el Polycom 320 de gama baja que nos ha llegado (importante, viene con su cable de red):


Otra cosa importante que se ha decido ya, es el direccionamiento de la red asterisk, el direccionamiento de las sedes que se conectarán por VPN al Asterisk, etc. También hemos decido que hacer con la salida a Internet que tenemos actualmente (ADSL). Dado que con astetisk tendremos nuevas lineas de datos a Internet, hemos decido mantener esta ADSL de forma que todo el trafico de navegación Web (¿emule?) de la empresa saldrá por esta ADSL . Por las lineas nuevas saldrán los servicios críticos: correo, Intranet corporativa, asterisk, etc.

En el próxima entrega hay... esquema de la red (naturalmente con otros direccionamientos publico e internos y con alguna cosa borrada).

tocame

29 de septiembre de 2008

Este fin de semana he probado en la tienda en nuevo bicho de HP TouchSmart que resulta ser una pantalla tft-cristal táctil. Me sentí como Dennis Hwang dibujando...

yo dibujando



Dennis Hwang dibujando


Más información:
+ http://www.hoogle.kr/415

el ahogo de ipv4

28 de septiembre de 2008

He encontrado esta curiosa página IPv6 Backbone Network Topology donde muestra unos gráficos muy chulos de los backbones de IPv6. Oigo hablar de v6 desde mi época moza universitaria, pero aun no he visto nada con v6. Bueno sí, mi Vista y mi Fedora 9 lo levantan por defecto... pero lo quito una vez instalado.



Según esta página nos queda 768 días para que se acaben las direcciones IP a este ritmo. Pero mi pregunta es: ¿alguien de vosotros pondrá ipv6 en su red interna?, está claro que cara a Internet lo tendremos que hacer, pero ¿puertas a dentro?. Esto lo digo no solo porque el rango de Ips aumenta, sino por todas las demás ventajas. Por ejemplo:

+ Ipv6 no hace broadcast.
+ A una misma interfaz podemos ponerle una IP publica y otra privada. Nos olvidamos de NAT.
+ Tendremos una nueva versión llamada DHCPv6 para repartir direcciones.
+ IPv6 permite añadir seguridad entre host-host.

Más información:
+ http://librosnetworking.blogspot.com/2008/09/ipv6-introduccin.html
+ http://es.wikipedia.org/wiki/IPv6
+ http://amperis.blogspot.com/2008/05/cuidar-de-internet.html

tempest en bilbao

Tras finalizar el Asegur@it III de Bilbao se hablaron de muchas cosas: cracking , rootkits (insufrible charla), NAP de Microsoft o sql-injection (gracias por www.fernandoalonso.com). Pero lo que más me entretuvo y que no lo conocía fue Tempest.

Tempest son las siglas de "Transient ElectroMagnetic Pulse Emanation STandard". Se trata de una serie de estándares y reglas (desclasificados por la NSA en 1995) para limitar las emanaciones de todo tipo de radiaciones electromagnéticas que pueden producir los dispositivos electrónicos. Lo que nos interesaría a nosotros son las emanaciones referidas a los monitores, los ordenadores, routers, teléfonos móviles, cableado estructurado, microprocesadores, etc.

Resulta que con el equipo adecuado (miles de $s) podemos llegar a reconstruir gracias a las radiaciones electromagnéticas que emite un CRT, qué es lo que se está visualizando. Existen por Internet papers como el de Markus G. Kuhn (Universidad de Cambridge) llamado "Electromagnetic Eavesdropping Risks of Flat-Panel Displays" que explica como llevar a cabo esto del Tempest sobre monitores CRT. Si alguien no se lo cree, incluso se demostró en directo, es posible montarte tú Tempest tú mismos gracias a "Tempest for Eliza". Esta aplicación lo que hace es lanzar desde tú ordenador una serie de patrones que envían señales electromagnéticas en la banda de AM de forma que desde una radio casera puedes sintonizar la misma señal y escuchar la música que esta enviando tú monitor CRT. En este caso escucharás Elise de Beethoven.

antenas captando las ondas electromagnéticas

imagen real emitida por un CRT


imagen captada desde un equipo Tempest


En la película de Will Smith y Gene Hackman "Enemigo publico" hay una escena en la cual el exagente de la CIA trabaja dentro de una cámara de Faraday para absorber todas las señales electromagnéticas que emiten sus ordenadores.

equipos informáticos rodeados por una camara de faraday


Aunque esto no es todo, porque podemos ir más allá. No solo son necesarias las ondas electromagnéticas para construir lo que estamos haciendo o viendo, sino que con el sonido que emiten las teclas de nuestro teclado o la luz que refleja nuestra pantalla sobre la pared trasera y/o rostro es posible también reconstruir de una forma más o menos exacta lo que se está haciendo.
En los antiguos modems es posible saber que se está trasmitiendo con solo ver los parpadeos de los leds del modem. Si esto os parece imposible también existen papers y demostraciones para saber que instrucciones de código máquina (un SUM, un MOV, un JMP, etc) está haciendo un microprocesador con solo escuchar su emanaciones electromagnéticas. Naturalmente esto no se consigue acercando una antena a la CPU, sino dentro de unas instalaciones especificas sin ningún otro tipo de interferencia electromagnética.

Nota: por favor, a los organizadores de Asegur@it. No dejéis pasar a ningún oyente que venga con un manual de Hacker de Anaya Multimedia debajo del brazo y en mitad de la charla de sqlinjection diga que a el los inyecciones ' OR 1=1; no le han funcionado nunca... ya se que todos estamos para aprender... pero es que fue demasiado.

Más información:
+ http://www.martykaiser.com/ras515a.htm
+ http://www.cl.cam.ac.uk/~mgk25/
+ http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-577.pdf

kirai se sortea

24 de septiembre de 2008

Para los que no lean a Kirai os lo recomiendo. Me encantaría ir a Japón. Este tio (Kirai) es un informático que lleva varios años viviendo en japón y contando por su blog lo que le va pasando. Habla de la cultura Japonesa, de las comidas, las relaciones entre ellos y Europa, de política, de mujeres, etc, etc. Además tiene unas fotos muy buenas que va haciendo él por todo Japón ilustrado sus posts.

Hace poco barrió todos sus post y de allí salio un libro llamado "Un Geek en Japón". Ahora bitacoras.com sortea 10 de estos libros. Yo ya me he apuntado... sino tendré que comprarlo :(.

!Verónica ya sabes que regalarme para la próxima vez!.

proxima parada [Asegúr@IT III]

23 de septiembre de 2008

Este jueves me voy volando con Spanair :( a Bilbao para asistir con mi jefe :( a la conferencia de seguridad Asegúr@IT III. Allí hablará gente que le gusta mucho Microsoft y nos enseñaran hacer cosas malas de verdad. Esta misma gente ya esta el día antes calentando motores para hacernos vibrar con sus explicaciones.

Por si esto no fuera poco el viernes voy a otra de seguridad llamada F.I.S.T donde nos hablarán del ecrime. Básicamente es más de lo mismo, pero con la diferencia de que la gente del ecrime se sacan un dinerillo.

ip to country en php

Una de las aplicaciones que tengo en mi empresa me permite distribuir contenido (manuales, presentaciones, etc) que son descargadas desde Internet. Para controlar desde que parte del mundo se realizan registro, en un archivo de log que país a realizado la descarga. Para ello me baso en la dirección IP que proporciona la variable REMOTE_ADDR de la petición.

Recomiendo ver la nota sobre detección de direcciones IP en PHP cuando estamos utilizando proxy.

Para hacer la conversión IP-pais, utilizo un servicio que proporciona www.webhosting.info. Realizo una llamada a esta página y obtengo un HTML con la respuesta. Luego solo tengo que rastrear el HTML y cortar allí donde dice en nombre del país. Este es el código de la función PHP.
A la función le pasamos la dirección IP (formato a.b.c.d) y esta nos devuelve un string con el nombre del país.

function iptocountry($ip_address) {  
 $url = "http://ip-to-country.webhosting.info/node/view/36";
     
 $inicio = "belongs to ";
 $ch = curl_init();   
 curl_setopt($ch, CURLOPT_URL, $url);   
 curl_setopt($ch, CURLOPT_POST,"POST");   
 curl_setopt($ch, CURLOPT_POST, 1);   
 curl_setopt($ch, CURLOPT_POSTFIELDS, "ip_address=$ip_address");          
 ob_start();         
 curl_exec($ch);   
 curl_close($ch);
 $cache = ob_get_contents();   
 ob_end_clean();
 $resto = strstr($cache,$inici0);
 $resto = strstr($resto,"<b>");
 $resto2 = strstr($resto,"</b>");
 $pais = substr($resto,0,strlen($resto)-strlen($resto2));

 $pais = str_replace("<b>","",str_replace("\n","",trim($pais)));

 return $pais;
}
Esta función se basa en una que encontré por Internet pero no recuerdo de quien era.

Para llamarla podemos hacer algo como:
echo iptocountry("89.129.175.55");
echo iptocountry($_SERVER["REMOTE_ADDR"]);
Para todas aquellas IP que no se sepan traducir se devolverá la cadena "Some Place We Dont Know About". Es el caso de las direcciones IP de clase A, B, C y D.

Para hacer funcionar esta función vuestro PHP tiene que tener soporte para las librerias CURL.

Más información:
+ http://ip-to-country.webhosting.info/node/view/36
+ http://en.wikipedia.org/wiki/Country_IP_database

detectando la araña

21 de septiembre de 2008

Una de las maneras más sencillas de detectar cuando Google visitó nuestra pagina es utilizando la herramienta "Google Webmaster Tool". Una vez dado de alta nuestra web podemos ver la ultima vez que googlebot visitó nuestra web.

Aquí tenéis un ejemplo de como las Webmaster Tools indican la ultima vez que nos visitaron:

Otra manera mucho más artesanal es detectar mediante PHP cuando el crawler de Googlebot entra en nuestra página. Cuando Googlebot entra en nuetra página se identifica durante el request de la página con un user-agent concreto. En www.useragentstring.com podéis encontrar todos los user-agent de los navegadores, crawlers, lectores de RSS, recolectores de mail, etc.

Lo que buscamos es cómo se identifica el user-agent de Google. Estas son las posibilidades:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Googlebot/2.1 (+http://www.googlebot.com/bot.html)
Googlebot/2.1 (+http://www.google.com/bot.html)

Por tanto, sólo basta con detectar el string "Googlebot" en la petición de HTTP. El siguiente código PHP almacen en un archivo de texto en el servidor cada vez que el crawler rastrea nuestra pagina. En el archivo de texto almacenamos el día de la visita, la IP del crawler y la página que ha rastreado.

<?php
   if ( strpos( $_SERVER["HTTP_USER_AGENT"], "Googlebot" ) !== false ) {
      $f = "google_visitas.txt";
      $handle = fopen($f, 'a+');
      $data = date("d-m-Y H:m:s") . " " . $_SERVER["REMOTE_ADDR"] . " " . \ 
              $_SERVER["REQUEST_URI"] . "\n";
      fwrite($handle, $data);
      fclose($handle);
   }
?>

Aquí tenéis una lista de IPs de crawlers de Googleboot.

Más información:
+ http://www.robotstxt.org/orig.html
+ http://www.useragentstring.com/index.php?id=108

mover a desarrollo tú zimbra

18 de septiembre de 2008

Voy a explicar como hacer una copia de todo nuestro Zimbra (buzones, configuración, contactos...) a otra maquina, que yo le llamo maquina de desarrollo de Zimbra, y desde allí poder trastear y hacer todas las pruebas que uno quiera. De esta forma estaremos seguros que las pruebas que hagamos serán sobre un Zimbra que se parece lo máximo posible al que tenemos en producción ya que conservamos todos los buzones, alias, contactos, zimlets, etc.

Por tanto, lo primero que haremos es montar una maquina Linux con la misma vesión y los mismos paquetes que la maquina que tenemos en producción.
Lo único que cambiará en esta maquina de desarrollo será la dirección IP (lógicamente no puede ser igual que la de producción).
Otra cosa muy importante es que el nombre de host debe ser igual que el de la maquina de producción. Esto es debido a que cuando arranca, por ejemplo el LDAP de Zimbra, intenta arrancar en un nombre de host concreto. Si lo cambiamos en la maquina de desarrollo entonces petará durante el arranque de Zimbra.

Una vez tengamos la maquina funcionando, hay que hacer una instalación de Zimbra, con la misma versión que tengamos en producción. Lo que quiero conseguir con esto, es ver si es posible instalar correctamente y que no falte ningun software o librería como pueda ser el fetchamil, libstdc++, etc.

Una vez nuestra instalación de Zimbra en desarrollo ya está funcionando podemos detenerla y renombrar la carpeta /opt/zimbra por /opt/zimbra_bak.

Para hacer la copia de producción detenemos los servicios de Zimbra con "zmcontrol stop" y hacemos un tar teniendo en cuenta de meter en este tar los archivos ocultos (esto es muy importante).

tar -zcvf /tmp/backup_zimbra.tar.gz /opt/zimbra/.

Una vez terminado el backup, que puede tardar bastante dependiendo de la cantidad de mensajes que tengamos, lo copiamos en nuestra maquina de desarrollo dentro de /opt/zimbra. Tendremos que crear la carpeta zimbra si no existe.

Ahora viene lo más importante. Cuando estemos trabajando en nuestra maquina de desarrollo y hacemos un enviar correo, este consultará el DNS y segun sus registros MX lo tendrá que enviar a la maquina de producción, cosa que no queremos. Queremos que cuando yo esté en desarrollo y envie un mail a una cuanta mía, este vaya a parar a la cuenta de correo que tenemos en desarrollo.
Para eso tendremos que crear un servidor de DNS de pruebas con nuestro dominio para que los registros MX apunten a la nueva maquina de desarrollo.
Yo normalmente utilizo RaidenDNSD para hacer las pruebas (aquí teneis un pantallazo). Una vez configurado nuestro servidor de DNS tendremos que decir a nuestro Linux que lo utilize como primera preferencia. En Fedora normalmente modificamos /etc/sysconfig/network.

Hacemos una prueba desde desarrollo para verificar que cuando enviemos correo a nuestro dominio estos se envian por desarrollo:
[root@zimbra ~]# nslookup
> set type=mx
> miempresa.com
Server:         10.3.10.5
Address:        10.3.10.5#53

miempresa.com      mail exchanger = 10 mx.miempresa.com.

Podemos verificar que efectivamente el DNS que utilizamos (10.3.10.5) es mi DNS para hacer pruebas. Ahora ya podemos descomprimir el tar que previamente hemos copiado y ver que debajo de /opt/zimbra tengo toda la estructura de carpetas que necesita Zimbra. Si hacemos un "zmcontrol start" tendría que arrancar sin mayores problemas.

Ya tenemos la maquina de desarrollo lista para entrar por el webmail o por el administrador y hacer todas las pruebas que queramos.

Por último tengo que decir que este mismo proceso puede ser igual de valido para migrar el servidor de Zimbra a una maquina más potente y siempre con la misma versión de Linux y Zimbra. No se puede migrar el Zimbra a otra maquina con otra versión diferente de Linux porque posiblemente esta no arrancaría y daría problemas en algunas librerias.

comienza asterisk (parte 1)

16 de septiembre de 2008

Estas últimas semana ha comenzado a llegar el material para migrar la telefonía actual a VoIP en Asterisk. Lo primero que nos ha llegado son dos switches HP 2650 con 58 bocas a 100Mbps y 2 más a 1Gbps. Los hemos comprado PoE para evitarnos tener que poner una fuente de alimentación extra a cada teléfono IP.

El primer problema que hemos tenido es que no nos caben en el rack actual donde tenemos los patch panels ya que por detrás baja la manguera con 200 cables Ethernet y toca el switch por detrás. Al ser un switch PoE este es más lardo que un switch de la serie HP 2000 sin PoE. Así que una vez este todo configurado tendremos que mover los pach panels para dejar espacio a estos switches. No es recomendable mover los pach panels una vez está todo grimpado y con bridas, pero es la unica solución ya que no queremos otro rack. Además aprovecharemos para parchear todo y volver a peinar el rack.

estos son los dos switches PoE

esto es una castaña de IBM pero que va de perla para configurar por consola... porfa que vuelva el serial a los portatiles

Hoy he estado terminando de configurar los switches, hacer pruebas de conectividad y mirando que las bocas arrancan PoE cuando colocamos un dispositivo PoE. También he estado tocando los Cisco PIX 514E para separar lo que será la red de ordenadores de la red de telefonía. Serán dos redes diferentes con un direccionamiento IP diferente.

Tenemos previsto mantener la telefonía analógica en paralelo mientras hagamos la migración a VoIP. Será todo un follón cuando llegue el día pero es lo que ha decido el jefe :(

También nos ha llegado un servidor Dell 2900 que nos hará junto con un VMware de servidor de backup de la centralita Asterisk. Es decir solo encenderemos el servidor virtual de Asterisk cuando el servidor dedicado a Asterisk falle. Si esto pasara será simplemente cambiar el cable de los primarios y conectarlo a la red.

yo haciendo el panolis con el disco SATA

una vez puesto el servidor DELL en un rack (nuevo) HP... manda narices


mi foto en flickr

Hace unos días me sucedió algo muy peculiar. De esas cosas que podían haber pasado desapercibidas pero que no fue así. Fue una puñetera casualidad.

Verónica llegó a casa a las 8 de la tarde y me dejo una revista de esas que editan gratuitamente en todos los pueblos (revista que lleva más de 20 años editándose).

Cogí la revista y la abrí por una página cualquiera. Mi mirada se centro en la primera foto. ¡Pero si esta foto es mía!.


esta es la revista y esta es la fotografía original

Primero me vino una alegría ver una foto mía en esa revista. Esta foto hace meses que la había colgado en Flickr por un curso de fotografía que hice. Al pasar las horas y navegando por mi cuenta de Flick fui pensando cómo habían llegado a la fotografía y sobretodo porque la había cogido si está bajo licencia de "todos los derechos reservados". Pues muy fácil... buscaron y simplemente la cogieron. Supongo que penarían que todas las fotografías de Flickr son libres.

Dado mi enfado escribí a la revista y al día siguiente me respondieron explicándome la situación y el motivo. La explicación y sus disculpas me bastaron y ya esta todo arreglado.

Flickr por defecto pone a todas las fotografías copyright total pero es posible cambiar los tipos de licencias a otras menos restrictivas como puede ser un Creative Commons.

También hace tiempo en los foros de Flickr se habló de que Flickr pondría una pasarela de pago para que los propios usuarios de Flickr pudieran vender sus fotografías. No hubo acuerdo entre las empresas que lo harían y la cosa al final no se hizo.

Más información:
+ http://www.castelldefels.org/fitxers/mitjans/castell%20SETEMBRE.pdf
+ http://ningunterra.com/2007/02/15/como-poner-todas-nuestras-fotos-de-flickr-con-licencia-creative-commons/

robtex.com

13 de septiembre de 2008

Robtex.com es una de esas paginas para la gente que le gusta saber cómo estan formadas las cosas. A partir de una IP o un nombre de host puedes hacer un nslookup, un whois, puedes saber contra que routers esta conectado, de que sistema autonomo (AS) depende, puedes mirar si el dominio esta dentro de alguna lista negra, etc.

Vale, vale... me dirás que de estas páginas hay muchas. A mí esta me ha llamado la atención poque primero te presenta la información en forma de tablas con enlaces y desde esos enlaces puedes ir navegando por las IPs, por los routers, por los AS, etc. Y segundo, es capaz de presentar un gráfico de como estan conectadas las cosas.

Vamos a probar un ejemplo. Entramos en www.robtex.com y en el cuadro "hostname, IP or AS" le ponemos el servidor web www.lavanguardia.com. Este servidor aloja la pagina web de un periodico editado en Barcelona. Fisicamente este servidor está alojado en un CPD que Colt Telecom tiene en la Zona Franca de Barcelona.


Según la tabla que nos muestra www.lavanguadia.com vemos que:

+ El nombre www.lavanguardia.com se traduce en una dirección IPv4 (record type a) con valor 212.0.125.95.
+ El dominio lavanguardia.com está delegado a dos servidores dns (record type ns) que son dns1.lavanguadia.es y dns2.lavanguardia.es.
Según el nombre de los DNS podriamos deducir que la gestión del DNS la llevan ellos mismos. En mi caso, donde yo trabajo la gestión del DNS lo lleva el propio registrador (que es www.register.com).
+ El servidor encargado de recoger el correo para lavanguardia.com (record type mx) es smtp.lavaguardia.es. Ellos son más chulos que nadie y garantizan que su servidor smtp siempre funciona al 100%. Lo normal en los mx seria ver dos o más registros mx.
+ Todas las ips que aparecen en su infraestructura de Internet está dentro de la red 212.0.96.0/19. Si pulsamos sobre este link nos dará más información del propietario de este rango:


Podemos ver que el proveedor es COLT España y por tanto la información que yo tenia sobre el alojamiento de este servidor aun es valida.

Esta red de Colt (la 212.0.96.0/19) pertenece al sistema autonomo AS8220. Un AS es un conjunto de redes IP (v4 o v6) que comparten una misma politica de rutas BGP.

Este sistema autonomo está conectado contra otros sistemas autonomos entre los cuales se intercambian rutas. Obviamente contra más enlaces (peers) tengan se supone que eres un mejor ISP.

Otra dato que tenemos de este sistema autonomo de Colt es que está compuesto por 1.703.936 IPs que se reparten entre la propia infraestructura del AS de Colt y los clientes que contraten Colt.

Si volvemos a la primera pantalla y pulsamos sobre el link lavanguadia.com podemos subir un nivel más y ver información sobre el propio dominio.


Al subir en el arbol de DNS ya nos aparecen los root servers (a,b,c...) y pordriamos continuar con la red a la que pertenecen, el AS al que pertenecen, etc.

Desde esta página podemos consultar a nombre de quien esta el registro y su información de contacto (whois).

Es curioso ver como por ejemplo la gestión para registrar el dominio utilizaron una agencia de patentes y marcas llamada J.Isern (internet@jisern.com).

Bueno esto és lo más importante. Aun quedan muchas cosas como las webs que comparten la misma IP que www.lavanguardia.com o si el dominio lavanguadia.com está en alguna lista negra de spam.

Más información:
+ Lista de tipos de reigistro del DNS
+ Cuidar internet
+ Protocolo BGP
+ La leyenda de los root servers

kiss.me

12 de septiembre de 2008

Me he estado informando del nuevo dominio para Montenegro: el .me.

Resulta que técnicamente ya existían desde 2006, pero en julio de este año han empezado los registros y también las subastas de los que se consideran "dominios premium". Este dominio parece que esta causando igual revuelo de pujas al igual que lo hizo el .tv en su tiempo y es que en ingles pueden fabricarse dominios tan llamativos como:

kiss.me
love.me
play.me
meet.me
buy.me
etc.

Creo que esta claro el potencial de este dominio ¿no?. En la subasta previa se presentaron más de 2000 "dominio prenium" por una cantidad total de $2.199.230... vamos que unos pocos se van a forrar.

El final de la subasta será el 25 de septiembre en Moniker y si alguien quiere pujar aquí tiene la lista de algunos tops:
toyota.me $90.025
insure.me $68.005
sync.me $41.005
oglasi.me $40.034
oweso.me $24.189
skida.me $20.010
...

Más información:
+ http://dominiosclave.com.es/category/cctld/me-montenegro/
+ http://www.domain.me/

prohibir una dirección de correo en zimbra (o postfix)

9 de septiembre de 2008

Para denegar que una dirección de correo o un dominio entre en nuestro servidor de smtp y llegue a alguna de nuestras cuentas de correo podemos utilizar el parámetro de postfix llamado "smtpd_sender_restrictions". Este parámetro tiene que configurarse dentro de archivo de configuración /opt/zimbra/postfix/conf/main.cf.

Lo primero que tenemos que hacer es crear un archivo de texto donde pondremos las direcciones de correo y dominios que no queremos recibir. Supongamos que no queremos recibir correo de pajarraco@minido.com y del dominio @micuco.com. Además queremos dejar bien claro en el mail de error nuestro malestar por estos mails.

El archivo que crearemos será /opt/zimbra/postfix/conf/access.cf y tendrá el siguiente contenido:

pajarraco@minido.com   453 Que te he dicho que no quiero más mails !!!...
micuco.com             453 Tampoco quiero mail de ti !!!...
El siguiente paso será convertir este archivo de texto en "formato postfix" con el comando postmap.
# ./opt/zimbra/postfix/sbin/postmap access.cf
Como resultado obtendremos el archivo binario access.cf.db que es el que necesitaremos. Cada vez que añadamos una nueva dirección o alguna modificación tendremos que hacer un postmap y reiniciar el postfix.

El siguiente paso es editar el archivo de configuracion main.cf y colocar la siguiente linea:
smtpd_sender_restrictions=check_sender_access hash:/opt/zimbra/postfix/conf/access.cf,
permit_mynetworks
Solo nos queda reiniciar el postfix. Ahora cada vez que llegue un mail hará un check_sender_access sobre access.cf y si corresponde el sender con el que hay dentro del archivo entonces producirá un error 453.

Si intentamos enviar un correo desde pajarraco@minido.com, a la cuenta del administrador le llegará un correo con un aviso de un mail denegado. El mail error le llega al administrador y al pajarraco@minido.com, pero nunca al usuario final.
 Out: 220 Server ready...
 In:  EHLO gv-out-0910.minido.com
 Out:  250-zimbra.miempresa.com
 Out: 250-PIPELINING
 Out: 250-SIZE 52428800
 Out:  250-ETRN
 Out: 250-STARTTLS
 Out: 250 8BITMIME
 In:  MAIL  FROM:<pajarraco@minido.com> 
 Out: 250 Ok
 In:  RCPT TO:<usuario@miempresa.com>
 Out: 453 <pajarraco@minido.com>: Sender address  rejected: Que no te queremos!!!
 In:  QUIT
 Out: 221 Bye
Por otro lado a pajarraco@minido.com le llegará un mail con la denegación y su escarmiento (si no es este el mail tendrá que ser uno muy parecido):
Final-Recipient: rfc822; usuario@miempresa.com
Last-Attempt-Date: Tue, 09 Sep 2008 21:57:32 +0200 (CEST)
Action: failed
Status: 5.0.0
Diagnostic-Code: 554 <pajarraco@minido.com>: Sender address 
rejected: Que no te queremos!!!


Más información:
+ Controles de acceso Postfix
+ SMTP
+ Sender address restrictions

colas en zimbra (parte 2 y última)

7 de septiembre de 2008

Este resumen no está disponible. Haz clic en este enlace para ver la entrada.

profesionales hasta el final

4 de septiembre de 2008

Una de las cosas que más admiro cuando trabajo es la profesionalidad de las personas. Puedes cometer grandes errores o grandes logros y todo se ve diferente según tú actitud y profesionalidad. A Eduard Punset y Randy Pausch los admiro por su profesionalidad llevada al limite.

Eduard Punset es un abogado y "divulgador científico de las tecnologías" al cual le diagnosticaron un cancer. Llevó su profesionalidad hasta el final e hizo un capitulo en su programa REDES dedicado a su enfermedad: "Diálogos sobre cáncer entre un paciente y su oncólogo".



Randy Paush era un profesor de informática de EEUU, llevó su profesionalidad hasta su muerte. Le diagnosticaron también un cancer y un año antes de su muerte dio su ultima conferencia o su testamento intelectual. A esta conferencia (obra maestra) la llamó "Alcanzar realmente tus sueños de la infancia".


a los ojos de php llegó chrome

3 de septiembre de 2008

Como corre la gente. Aparentemente la gente ya utiliza Chrome para trabajar :)... con los problemas (otro y otro) que ya esta dando.

Esto es log creado en php de descargas en este blog...

03-09-2008 16:09:19 66.98.82.244 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) 
AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13 
http://s218907966.mialojamiento.es/doc/blogspot/20080706/parte1.zip
03-09-2008 16:09:00 66.98.82.244 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) 
AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13 
http://s218907966.mialojamiento.es/doc/blogspot/20080707/parte2.zip
03-09-2008 16:09:18 66.98.82.244 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) 
AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13 
http://s218907966.mialojamiento.es/doc/blogspot/20080713/parte3.zip

colas en zimbra (parte 1)

Este post aunque se llama "colas en zimbra" bien se podría llamar "colas en postfix" ya que postfix es el mta que utiliza zimbra.

Postfix tiene varias colas donde va guardando todo el correo que procesa y el correo que no ha podido procesar por cualquier motivo. Por regla general a cada concepto de cola en postfix se le asigna una carpeta fisica dentro del sistema de ficheros. En el caso de zimbra las colas se encuentran dentro de la carpeta "/opt/zimbra/postfix/spool". Si entramos por ejemplo dentro de la cola incoming podremos ver archivos los cuales cada uno corresponden a un mensaje de correo electrónico que esta entrando en este momento. Una vez el mensaje ha entrado desaparecerá de la cola. Lógicamente si no hay ninguno archivo es que no está entrando correo. Como veis hay un montón de colas en postfix y cada una tiene su función. Lógicamente todo este árbol de carpetas no hay que tocarlo para nada porque para eso están las utilidades de postfix.

Si tenemos una maquina dedicada al correo, es seguro que el 99% de la congestión que pueda tener es debido al procesamiento de los mensajes que entran y salen. Las colas más importantes que tiene postfix son las siguientes:

+ cola incoming: en esta cola están todos los nuevos mensajes que entran en postfix. Estos ficheros que se crean por cada mensaje los crea un servicio de postfix llamado cleanup. Este fichero tendrá de propietario postfix y permisos 0600 mientras se esté recibiendo y 0700 una vez se ha terminado de recibir.

+ cola active: desde esta cola se envían los mensajes a sus destinatarios. Esta es una de las colas más importantes ya que internamente hay mucha logica para implementarla. Desde esta cola se crearán todas las conexiones smtp necesarias (consultando los registros MX de los DNS) para los destinatarios. Aunque a esta cola le corresponda una carpeta, internamente en postfix se crean estructuras de memoria para su procesamiento. Las colas de incoming, hold o deferred no ocupan memoria en el sistema. Normalmente el análisis de los cuellos de botella se centran en esta cola.

+ cola hold: en esta cola van a parar indefinidamente los mensajes que el administrador quiere que no se procesen. Es posible configurar postfix para que mueva mensajes a esta cola de forma automática utilizando access.

+ cola deferred: en esta cola van a parar los mensajes que no se han podido enviar alguno de los destinatarios y por tanto postfix tiene que volver a reitentar el envió. Tanto las colas de incoming y deferred se miran periódicamente para ver si hay algún mensaje para enviar. Hay tres parámetros básicos en postfix para controlar cada cuanto se miran estas colas y que afectan al rendimiento de postfix: $queue_run_delay, $minimal_backoff_time y $maximal_backoff_time. El funcionamiento es el siguiente: cuando un mensaje llega este es procesado por el mta y enviado a la cola incoming. Por otro lado cuando se decide enviar un mensaje y postfix se tiene que poner en contacto con otros mta estos mensajes son enviados a la cola active. Si por cualquier motivo el mensaje no puede ser enviado a otro mta este pasará a la cola deferred hasta que pueda ser entregado más tarde o expire el tiempo de vida. El tiempo de vida de un mensaje en la cola deferred viene marcado por la variable $maximal_life_time. Si transcurrido este tiempo el mensaje no se pudo enviar este mensaje se devuelve al remitente pero solo en un tamaño concreto marcado por la variable $bunce_size_limit. Si el remitente ha enviado un mail del 50Mb no tiene sentido devolverle otra vez el mail de 50Mb.

El escaneo de la cola de deferred para los reintentos sigue un algoritmo un poco complicado pero que básicamente es algo así: la cola deferred se escanea cada $queue_run_delay en busca de mensaje para enviar. Cuando un mensaje está en esta cola se le pone una marca de tiempo T. Si a los T segundos se hace el envío y este no tiene éxito, el siguiente envío se hace a los 2T y así sucesivamente.

En la siguiente imagen es la más completa que he podido encontrar por Internet (google images) de la relación entre las colas y lo procesos de postfix:


En el próximo post explicaré los comandos para el manejo de las colas y unos apuntes de tunnig de postfix.

Más informacion:
+ http://www.postfix.org/QSHAPE_README.html
+ http://linux.die.net/man/1/postqueue

navegador google

2 de septiembre de 2008

Google anuncia su nuevo navegador...