añadir antivirus f-prod a zimbra

26 de febrero de 2009

Describo como añadir otro de los pocos antivirus gratuitos que hay para Linux para que trabaje junto Zimbra. El F-prot antivirus for Linux.

+ Descargar la versión free de F-Prot Antivirus para Linux (fp-Linux-i686-ws.tar.gz) desde:

http://www.f-prot.com/products/home_use/linux/

+ Copiar el archivo comprimido en /opt y descomprimir:
# tar -xzvf fp-Linux-i686-ws.tar.gz
# cd /opt/f-prod

+ Una vez decomprimido instalar con el siguiente script:
# ./install-f-prot.pl 

El proceso de instalación es muy rápido y no pide nada de especial.

+ Lanzar el comando "fpupdate" para actualizar las firmas. Utilizar este mismo comando para programar un cron para que se actualice el antivirus de forma automática varias veces al dia.

+ Para que lo reconozca Amavis debemos añadir esta nueva definición de antivirus dentro del amavisd.conf.in. Si esta definición no existe dentro de tú Zimbra 4 o 5 añadirla tal cual:
@av_scanners = (
...
### F-prot Antivirus
['F-PROT Antivirus for UNIX',
['fpscan'],
'--report --mount --adware {}',
# consider: --applications -s 4 -u 3 -z 10
[0,8,64], [1,2,3, 4+1,4+2,4+3, 8+1,8+2,8+3, 12+1,12+2,12+3],
qr/^\[Found\s+[^\]]*\]\s+<([^ \t(>]*)/
],
### fin F-prod
...

+ Reiniciamos Zimbra o el daemon de amavis:
# su - zimbra
# cd /opt/zimbra/bin
# ./zmamavisdctl stop
# ./zmamavisdctl start

+ Verificamos que una vez arrancado el Amavis este es capaz de encontrar el nuevo antivirus. Para ello miramos dentro del log de Zimbra:
# cat /var/log/zimbra.log grep F-PROT
Feb 26 13:07:59 srvzimbra amavis[25125]: Found primary av scanner F-PROT Antivirus for
 UNIX at /usr/local/bin/fpscan

+ Utilizamos un virus Eicar y vemos si realmente el nuevo antivirus (junto al resto) están detectando los virus:



scp entre maquinas

23 de febrero de 2009

Existen varias formas de copiar archivos entre dos maquinas Linux: rsync, nfs, samba o como en este caso scp.
SCP es una tool para copiar archivos de forma segura entre dos maquinas utilizando el protocolo SSH.

El siguiente ejemplo copia de forma segura el archivo "backup.tar.gz" de la maquina srv1 a la maquina srv2 y lo deja en la carpeta /tmp.

[root@srv1 tmp]# scp backup.tar.gz srv2.miempresa.com:/tmp
The authenticity of host 'srv2.miempresa.com (10.1.2.34)' can't be established.
RSA key fingerprint is e9:40:f0:67:6b:4c:3b:03:ad:22:9f:38:98:51:56:29.
Are you sure you want to continue connecting (yes/no)? 

root@srv2.miempresa.com's password: 
backup.tar.gz      100%    0     0.0KB/s   00:00  

scp es de lo más fácil de utilizar y seguro, pues a diferencia de nfs o samba no tienes que configurar nada de especial, ni dar permisos especiales ni nada. Normalmente todos los servidores Linux tienen levantado el daemon de SSH para la gestión remota, por tanto scp hará uso de ello.

El problema es cómo hacer que scp sea automático y no pida el intercambio de llaves, ni la contraseña cada vez que lancemos el comando contra un servidor. Esto puede ser necesario si queremos programar scp en un cron para que copie archivos de un servidor a otro de forma automática.

+ Generamos unas llaves de autentificación 1024 bits.
[root@srv1 tmp]# ssh-keygen -t rsa -b 1024
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase):
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
10:cc:98:90:5b:7f:9e:ef:bb:7a:f7:6c:d2:a2:ca:7d root@srv1.miempresa.com

+ Copiamos la clave publica al servidor de destino. En nuestro caso “srv2”.

[root@srv1 tmp]# scp /root/.ssh/id_rsa.pub srv2.miempresa.com:/root/.ssh/
root@srv2.miempresa.com password: 
id_rsa.pub          100%  232     0.2KB/s   00:00

+ En la maquina remota renombramos el archivo copiado y damos los permisos oportunos.

[root@srv2 .ssh]# cp id_rsa.pub authorized_keys
[root@srv2 .ssh]# cd
[root@srv2 ~]# chmod go-w . .ssh .ssh/authorized_keys 

+ Ahora como ya hemos intercambiado las llaves entre estos dos servidores ya podemos entrar de uno al otro sin necesidad de password. Podemos utilizar tanto ssh como scp.

[root@srv1 tmp]# ssh srv2.miempresa.com
Last login: Fri Feb 20 22:00:56 2009 from srv1.miempresa.com
[root@srv2 ~]#


controlando la cola con qshape (parte 2 de 2)

21 de febrero de 2009

El siguiente ejemplo nos permite detectar un ataque llamado "de rebote". Veamos la cola de deferred:

$ qshape deferred | head

                         T  5 10 20 40 80 160 320 640 1280 1280+
                TOTAL 2234  4  2  5  9 31  57 108 201  464  1353
  heyhihellothere.com  207  0  0  1  1  6   6   8  25   68    92
  pleazerzoneprod.com  105  0  0  0  0  0   0   0   5   44    56
       groups.msn.com   63  2  1  2  4  4  14  14  14    8     0
    orion.toppoint.de   49  0  0  0  1  0   2   4   3   16    23
          kali.com.cn   46  0  0  0  0  1   0   2   6   12    25
        meri.uwasa.fi   44  0  0  0  0  1   0   2   8   11    22
    gjr.paknet.com.pk   43  1  0  0  1  1   3   3   6   12    16
 aristotle.algonet.se   41  0  0  0  0  0   1   2  11   12    15

Vemos que en total hay 2234 correos pendientes de enviar y que por un motivo desconocido no se han podido entregar. Veamos ahora el remitente de estos correos:

$ qshape -s deferred | head

                     T  5 10 20 40 80 160 320 640 1280 1280+
            TOTAL 2193  4  4  5  8 33  56 104 205  465  1309
    MAILER-DAEMON 1709  4  4  5  8 33  55 101 198  452   849
      example.com  263  0  0  0  0  0   0   0   0    2   261
      example.org  209  0  0  0  0  0   1   3   6   11   188
      example.net    6  0  0  0  0  0   0   0   0    0     6
      example.edu    3  0  0  0  0  0   0   0   0    0     3
      example.gov    2  0  0  0  0  0   0   0   1    0     1
      example.mil    1  0  0  0  0  0   0   0   0    0     1

Vemos que el remitente es el MAILER-DAEMON. Lo que nos están haciendo es enviar correos desde un dominio que no existe a un usuario de nuestro dominio que tampoco existe. Esto provoca un correo de vuelta al remitente el cual no se puede entregar porque el dominio de origen no existe. El resultado es que la cola de deferred se va llenando y llenando de correos del MAILER-DAEMON.

El siguiente ejemplo muestra una estadística de envío de mucho correo hacia un dominio el cual su MTA es muy lento o da timeouts.

$ qshape deferred | head

                    T   5  10  20  40   80  160 320 640 1280 1280+
           TOTAL 5000 200 200 400 800 1600 1000 200 200  200   200
 muchocorreo.com 4000 160 160 320 640 1280 1440   0   0    0     0

Vemos como rápidamente el correo se va acumulando y cada vez es más viejo. Esto puede llegar a ser peligroso porque si realmente el MTA de destino no está caído todo este correo seguirá reintentando dentro de la cola active, y esto si que puede resultar preocupante.

Más información:
+ qshape postfix

controlando la cola con qshape (parte 1 de 2)

19 de febrero de 2009

qshape es una utilidad de postfix para controlar la "vejez" de los correos en la cola. Es decir nos permite detectar cuanto tiempo llevan los correos entrando o saliendo de las colas. El objetivo es determinar cuellos de botella. Si un correo lleva mucho tiempo en la cola eso quiere decir que hay una bottleneck y que algo puede estar pasando.

Ejecutemos un qshape a secas:

[zimbra@servidor ~]$ qshape 
                     T  5 10 20 40 80 160 320 640 1280 1280+
              TOTAL  4  4  0  0  0  0   0   0   0    0     0
      miempresa.com  3  3  0  0  0  0   0   0   0    0     0
        greenlog.es  1  0  0  1  0  0   0   0   0    0     0

La llamada a qshape sin parámetros muestra la vejez de la cola incoming y active al mismo tiempo y solo de los destinatarios.
En total tenemos 4 correos procesándose en esta cola. Tres correos pertenecientes al dominio miempresa.com y uno al dominio greenlog.es. Los tres correos de miempresa.com llevan menos de 5 minutos en la cola y el de greenlog.es lleva entre 10 y 20 minutos en la cola. En este caso algo está pasando con este correo de greenlog.es porque entre 10 y 20 minutos en la cola de incoming/active es mucho tiempo.
Si tuviéramos algún correo dentro de la columna "1280+" estaríamos con un correo que lleva posiblemente un día entero en la cola. Un día son 1440 minutos.

Si utilizamos el parámetro -s estaríamos viendo la misma estadística pero los remitentes. Ejecutar el comando "qshape" es equivalente a ejecutar el comando "qshape incoming active".

Veamos ahora lo mismo pero con la cola deferred:

[zimbra@servidor ~]$ qshape deferred       
                T  5 10 20 40 80 160 320 640 1280 1280+
         TOTAL  3  0  0  0  1  0   0   0   0    0     2
      yahoo.es  1  0  0  0  1  0   0   0   0    0     0
  hotmailo.com  1  0  0  0  0  0   0   0   0    0     1
gruponegro.com  1  0  0  0  0  0   0   0   0    0     1

Vemos que en la cola de deferred (correos que no se pueden entregar) hay un correo para el dominio hotmailo.com que se acerca a casi un día en la cola. Me huele que el dominio hotmailo.com no existe y que alguien se ha equivocado al escribir la dirección de correo.
Si consultamos ahora lo mismo pero desde el lado contrario (el remitente):

[zimbra@servidor ~]$ qshape -s deferred
                      T  5 10 20 40 80 160 320 640 1280 1280+
               TOTAL  3  0  0  0  1  0   0   0   0    0     2
       miempresa.com  3  0  0  0  1  0   0   0   0    0     2

Podemos ver claramente la relación entre "qshape -s deferred" y "qshape deferred".

Vemos que está pasando algo con el correo del dominio gruponegro.com porque lleva más de 1280 minutos en la cola de deferred.

[zimbra@servidor ~]$ cat /var/log/zimbra.log | grep gruponegro.com
Feb 19 21:31:28 servidor postfix/smtp[28428]: connect to gruponegro.com 
[208.87.149.250]: Connection timed out (port 25)
Feb 19 21:31:28 servidor postfix/smtp[28428]: AF8B2682E2: to=, relay=none, delay=172570, 
status=deferred (connect to gruponegro.com[208.87.149.250]: Connection timed out)

Lo que está pasando es que el servidor MTA del dominio gruponegro.com (IP 208.87.149.250) no está disponible porque da timeouts.

metadatos en mi ayuntamiento o cómo buscar el correo de mi alcalde

18 de febrero de 2009

Estamos expectantes a que algún día liberen la FOCA, pero mientras tanto tendremos que conformarnos con esta poquita FOCA en online.

La extracción de metadatos en archivos ofimáticos (o no ofimáticos como imágenes) puede ser algo divertido... pero más que divertido es peligroso. Te puede permitir obtener una estructura de la red, nombres de usuario, caminos, servidores... que de otra manera no podría obtenerse (¿o sí?).

Veamos cómo está puesto mi ayuntamiento en estos temas. Busquemos unos cuantos Words y unos cuantos Excels. Aunque muchos otros archivos contienen información oculta, son las herramientas ofimáticas las mejores nutridas.

Le pasamos a la FOCA un Word que hemos encontrado y luego un Excel:




Para sacar provecho de esta información tienes que ser "perverso". ¿Que puede ser útil?. Pues bien, tenemos un servidor llamado "psaj15". También sabemos que en la red hay una impresora que se llama "psim601". Y lo más importante sabemos cuatro nombres de usuario: ismael.garces, assessor.equal, informatica y sergio.medina (seguramente sean cuentas de usuario Windows).

Podemos ir un poco más lejos. ¿Es posible determinar las direcciones de correo de estas personas?. Sólo basta una prueba:


¿Alguien quiere enviar un correo al alcalde con una queja?

buscando en lo prohibido

16 de febrero de 2009

adminsearch.py es un script en Python para buscar páginas Web de administración en un url dada. Se basa en una lista de paths y web pages de administración.
Para añadir nuevas paginas de administración es tal fácil como añadirlas a la variable “rutas” dentro del script. La idea original es de admin-scan de darkc0de.com con unas correcciones mías porque no acababa de ir del todo bien.


transacciones en mysql con php

10 de febrero de 2009

Primero de todo aclarar el tipo de engine que se está utilizando en MySql. Normalmente hay dos engines clásicos que podemos utilizar en MySql: MyISAM e InnoDB. Inicialmente el engine por defecto era MyISAM, pero la tendencia es utilizar InnoDB por la posibilidad de utilizar transacciones (MyISAM no tiene), bloqueo de registros e integridad referencial.

Actualmente la empresa que desarrolla InnoDB (InnoBase) fue comprada por Oracle. También se está trabajando en otro engine para MySql 6 llamado Falcon. Aquí tenéis un benchmark entre MyISAM vs InnoDB vs Falcon muy interesante.
He leído por algún sitio que la creación de Falcon viene a suplir la falta de engine transaccional propio de MySql y la compra de InnoDB por parte de Oracle.

Si lo que queremos es velocidad en las consultas lo mejor es utilizar MyISAM. Si lo que queremos es seguridad en nuestra aplicación lo recomendable es InnoDB (y en el futuro Falcon).
Por tanto, para seguir con los siguientes ejemplos, tenemos que tener un schema de MySql de tipo InnoDB.

Lo que vamos hacer con el siguiente ejemplo es el típico ejemplo de transacción bancaria de donde sacamos dinero de la cuenta "12345" y la transferimos a la cuenta "12346".

Tenemos la tabla "cuentas" con los siguientes valores.

mysql> select * from cuentas;
+----+------------+-------+
| id | num_cuenta | saldo |
+----+------------+-------+
|  1 |      12345 |  1200 |
|  2 |      12346 |     0 |
+----+------------+-------+
2 rows in set (0.00 sec)

Si ejecutamos el siguiente código PHP:

$cuenta_origen  = 12345;
$cuenta_destino = 12346;
$importe_mover  = 1000;

mysql_select_db($database, $bancobb);

$sql = "UPDATE cuentas SET saldo=saldo-$importe_mover 
        WHERE num_cuenta=$cuenta_origen";
mysql_query($sql, $bancobb) or die(mysql_error());

$sql = "UPDATE cuentas SET saldo=saldo+$importe_mover 
        WHERE num_cuenta=$cuenta_destino";
mysql_query($sql, $bancobb) or die(mysql_error());

echo "Fin...";

Lo que hemos hecho es quitar 1000€ de la cuenta "12345" y transferirla a la cuenta "12346". Si miramos el resultado de la tabla cuentas tenemos:

mysql> select * from cuentas;
+----+------------+-------+
| id | num_cuenta | saldo |
+----+------------+-------+
|  1 |      12345 |   200 |
|  2 |      12346 |  1000 |
+----+------------+-------+
2 rows in set (0.00 sec)

Que pasaría si entre un UPDATE y el otro UPDATE nuestro servidor tiene un problema y se reinicia sólo (un corte de luz o un reinicio del admin). Volvamos a dejar la tabla de cuentas como estaba y provocamos un "corte de luz" entre un UPDATE y otro UPDATE.

$cuenta_origen  = 12345;
$cuenta_destino = 12346;
$importe_mover  = 1000;

mysql_select_db($database, $bancobb);

$sql = "UPDATE cuentas SET saldo=saldo-$importe_mover 
        WHERE num_cuenta=$cuenta_origen";
mysql_query($sql, $bancobb) or die(mysql_error());

echo "Opss! se fue la luz...";
exit();

$sql = "UPDATE cuentas SET saldo=saldo+$importe_mover 
        WHERE num_cuenta=$cuenta_destino";
mysql_query($sql, $bancobb) or die(mysql_error());

echo "Fin...";

Si ejecutamos ahora el script y miramos el contenido de la tabla vemos como hemos quitado 1000€ de una cuenta, pero la otra sigue estando a 0€.
Hemos hecho desaparecer 1000€. Explica tú ahora al banco que has cometido un error en la programación y que has hecho desaparecer 1000€ de 1000 usuarios diferentes.

mysql> select * from cuentas;
+----+------------+-------+
| id | num_cuenta | saldo |
+----+------------+-------+
|  1 |      12345 |   200 |
|  2 |      12346 |     0 |
+----+------------+-------+
2 rows in set (0.00 sec)

Para hacer correcta la serie de instrucciones debemos enmarcar los dos updates dentro de una transacción. Si utilizamos transacciones aseguraremos las 4 propiedades básicas: atomicidad, consistencia, aislamiento y durabilidad.

+ atomicidad: o se realiza todo o nada.
+ consistencia: si se viola alguna regla de integridad no se realizará la operación.
+ aislamiento: las operaciones de una transacción no influyen a la operaciones de otra transacción aunque estén trabajando con los mismos datos.
+ durabilidad: una vez hecho el commit los datos persistirán en la base de datos.

Para arrancar en MySql una transacción utilizamos la sentencia Sql "START TRANSACCTION". Para finalizarla utilizaremos un "COMMIT" si queremos guardar los cambios o un "ROLLBACK" si queremos cancelar toda la transacción. Recuerda que la idea es "o se ejecuta todo o no se ejecuta nada".

$cuenta_origen  = 12345;
$cuenta_destino = 12346;
$importe_mover  = 1000;

mysql_select_db($database, $bancobb);

$sql = "START TRANSACTION";
mysql_query($sql, $bancobb) or die(mysql_error());

$sql = "UPDATE cuentas SET saldo=saldo-$importe_mover 
        WHERE num_cuenta=$cuenta_origen";
mysql_query($sql, $bancobb) or die(mysql_error());

$sql = "UPDATE cuentas SET saldo=saldo+$importe_mover 
        WHERE num_cuenta=$cuenta_destino";
mysql_query($sql, $bancobb) or die(mysql_error());

$sql = "COMMIT";
mysql_query($sql, $bancobb) or die(mysql_error());

echo "Fin...";

Si miramos el resultado veremos como al igual que en el primer ejemplo movemos 1000€ de una cuenta a otra:

mysql> select * from cuentas;
+----+------------+-------+
| id | num_cuenta | saldo |
+----+------------+-------+
|  1 |      12345 |   200 |
|  2 |      12346 |  1000 |
+----+------------+-------+
2 rows in set (0.00 sec)

Provocamos ahora un "corte de luz", pero utilizando transacciones, tenemos:

$cuenta_origen  = 12345;
$cuenta_destino = 12346;
$importe_mover  = 1000;

mysql_select_db($database, $bancobb);

$sql = "START TRANSACTION";
mysql_query($sql, $bancobb) or die(mysql_error());

$sql = "UPDATE cuentas SET saldo=saldo-$importe_mover 
        WHERE num_cuenta=$cuenta_origen";
mysql_query($sql, $bancobb) or die(mysql_error());

echo "Opss! se fue la luz...";
exit();

$sql = "UPDATE cuentas SET saldo=saldo+$importe_mover 
        WHERE num_cuenta=$cuenta_destino";
mysql_query($sql, $bancobb) or die(mysql_error());

$sql = "COMMIT";
mysql_query($sql, $bancobb) or die(mysql_error());

echo "Fin...";

Si miramos ahora el contenido de la tabla vemos como no se ha producido ningún cambio. A pesar de que “se ha ido la luz” el primer UPDATE no se ha producido porque no se ha finalizado la transacción. La transacción finaliza cuando se hace el COMMIT. ¿Fácil no?. Pues a mover millones de una cuenta a otra.

mysql> select * from cuentas;
+----+------------+-------+
| id | num_cuenta | saldo |
+----+------------+-------+
|  1 |      12345 |  1200 |
|  2 |      12346 |     0 |
+----+------------+-------+
2 rows in set (0.00 sec)

Todas las sentencias SQL son atómicas por si solas. Es decir si no utilizamos transacciones después de un update o insert, este viene implícito con un commit.

Más información:
+ Transacciones MySql.
+ Errores informáticos.

cómo cambia el cuento de una ip a otra

6 de febrero de 2009

El simple hecho de cambiar de dirección IP puede provocar que todos los correos se consideren spam. Los portátiles que utilizamos y entregamos a nuestros vendedores vienen todos con su tarjeta de Vodafone 3G para conectarse a Internet y les obligamos a utilizar la conexión VPN para descargarse el correo en su cliente de correo. Aunque la conexión VPN no es necesaria lo normal es que lo hagan así.

Pues un buen día, un vendedor me llamó diciéndome que todos los mails que envía a la empresa no llegaban. Resulta que tío decidió dejar de lado la VPN y utilizar la conexión ADSL de su casa. Todos los correos que llegaban iban a parar a la basura del destinarario. Todos los mails eran considerados como spam.

Veamos las cabeceras de un mail considerado como spam.


Vemos el Spam-Score con un valor de 6,088. El mínimo para ser considerado spam es de 5 (required=5). Vemos también como está utilizado una ADSL de telefónica (dynamicip.rima-tde.net) y por tanto no está navegando por la red de Vodafone. Lo llamé y le pregunté: "¿oye, estas enviando el correo como siempre?"... "sí, sí, como siempre".

Si miramos los test que realiza el spam vemos FH_HOST_EQ_DYNAMICIP debido a que el correo esta enviado desde una IP dinámica.
Vemos también RCVD_IN_PBL con 0.905 porque la dirección IP esta dentro de la lista de Spamhaus PBL (Policy Block List). Este es uno de los mayores problemas.


Veamos ahora el mismo mail, enviado desde la misma ADSL, pero a través de una conexión VPN. Ahora quien envía el correo, no es una IP dinámica y publica, sino una dirección IP privada de mi red interna.

El Spam-Score en -0,813… vamos que debemos puntos y todo…



Más información:
+ zimbra y spamassessin: bajar los niveles de las puntuaciones

envio de spam por formularios web

4 de febrero de 2009

En mis tiempos mozos cuando programaba webs en ASP, un antiguo jefe me mandó que hiciera un script en ASP para mandar correo. La idea era que los clientes de los hostings pudieran tener su formulario web de contacto. Desde estos formularios el cliente hacía una llamada al script pasándome el “from” y el “to” del email. Rápida y abispádamente me percaté que cualquiera podía capturar el campo “from” y “to” y enviar correo a su antojo.
La respuesta del jefe fue: “¿Quién se va a mirar el código?... hazlo así y ya tendremos tiempo de mejorarlo”. Otra frase celebre suya era cuando me mandaba a un cliente 30 minutos antes de plegar y me decía: “…total, te pilla de camino a casa”, si claro, pero en sentido contrario a casa.

5 años después veo que aun hay formularios webs de contacto que utilizan esta técnica tan primitiva.
Aquí tenéis un ejemplo real de un código de un formulario de contacto. El campo “recipe” está visible por código, al igual que “required” y “dominio”. Este código está sacado de unos diseñadores web de Bilbao.


Vamos a modificar los campos “recipe” y “required” a nuestro antojo. La única validación que toma el script check.php es el campo “dominio”, por tanto lo dejaremos tal como está en el original.

Ahora enviamos este código miles de veces cambiando el campo “recipe” y ya tenemos nuestro relay de correo para el envío de spam.


¿Cuáles son las medidas a tomar?

Primero: la dirección del remitente no tiene que estar en el código HTLM. Tiene que estar en el lado del servidor. Segundo: validación y formateo todos los valores que llegan al servidor. Lo ideal sería que las direcciones de correo se validaran con expresiones regulares dentro el código PHP/ASP. Tercero: utilizar mod_security para aplicar reglas de ataques y evitar inyecciones SQL, XSS, etc. Cuarto: utilizar códigos de validación como captcha antes de enviar el formulario. Y quinto: diseñar el formulario de envío en varias paginas para poner dificultad a los robots.

1 router 2 isps

2 de febrero de 2009

El sueño de todo departamento de informática. Tener para el solito una salida hacia Internet para navegar /descargar cosas guarras y otra salida solo para los servicios prioritarios para la empresa (correo, voip, conexiones VPN, etc).

Este post describe como tener un router Cisco (por ejemplo un 1800) con dos ISP’s. Por un ISP envío todo el tráfico de navegación de la red interna y por otro ISP el tráfico "importante" de los servidores...

Para entrar en materia: el primer ISP (le llamaremos malo) nos entra por una ADSL de 8Mb con IP pública x.x.x.x. El segundo ISP (le llamaremos bueno) nos entra por una FastEthernet (que nos vienen de otro router Cisco de fibra) de 2Mb de envío y recepción garantizados y con una IP pública y.y.y.y.


Lo primero que hacemos es configurar cada una de las dos interfaces. Para la ADSL configuramos la interfaz de ATM y para la otra una interfaz de FastEthernet. También configuramos el NAT para cada una de las interfaces:

interface ATM0.1 point-to-point
 description --- WAN del ISP malo
 ip address x.x.x.x 255.255.255.192
 ip nat outside
 ip virtual-reassembly
 pvc 8/32
  encapsulation aal5snap
!
interface FastEthernet0
 description --- WAN del ISP bueno
 ip address y.y.y.y 255.255.255.248
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
!
...
ip nat inside source list 101 interface FastEthernet0 overload
ip nat inside source list 102 interface ATM0.1 overload
...

Ahora le decimos al router que por defecto envíe todo por la interfaz y.y.y.y (el ISP bueno):

ip route 0.0.0.0 0.0.0.0 y.y.y.y

El siguiente paso es crear una lista de acceso de forma que todos los paquetes que cumplan esa lista de acceso irán por el ISP malo. La lista de acceso será la siguiente:

access-list 103 remark --- route-map para el ISP malo
access-list 103 deny   ip host 192.168.1.45 any
access-list 103 deny   ip host 192.168.1.67 any
access-list 103 permit ip 192.168.1.0 0.0.0.255 any

En esta lista de acceso le digo que permita por el ISP malo toda la red 192.168.1.0 a excepción de dos servidores 192.168.1.45 y 192.168.1.67 que les obligo a ir por el ISP bueno.
Una vez creada la lista de acceso utilizamos el comando route-map que es el que hace posible toda esta diferenciación de rutas por dos ISP diferentes.

route-map datos permit 10
 match ip address 103
 set interface ATM0.1
!

Con este comando route-map lo que le estoy diciendo al router es que si el paquete cumple la access-list 103, envie ese paquete por la interfaz ATM (el ISP malo).

Para finalizar aplicamos el route-map a la interfaz la cual decidirá si los paquetes deben seguir un camino u otro:

interface FastEthernet1
 description --- LAN interna
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 ip tcp adjust-mss 1452
 ip policy route-map datos
!

Este ejemplo es muy básico, pero lógicamente la lista de acceso 103 se puede complicar todo lo que uno quiera para dejar pasar o no los servidores o redes que uno quiera.

Mas información:
+ Cisco route-map
+ How to: route map