comienza asterisk (parte 2)

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

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

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

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]

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

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

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)

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