VPSs y mas.

miércoles, 24 de junio de 2009

Conectando back2back routers Cisco. Frame Relay, HDLC y PPP

En estos dias he estado montando un laboratorio de CCNA y he tenido que realizar diferentes conexiones Back2Back entre diferentes routers Cisco. En fin les doy un pequeno resumen. Espero sea util:

1) Back2Back con enlaces seriales
Lo primero que necesitas son dos cables seriales: Uno debe ser DTE (generalmente con conector macho) y el otro debe ser DCE (generalmente con conector hembra)

a) Conectando HDLC (mas facil)
Configuracion del lado donde hayas colocado el cable DCE:

interface Serial0
ip address 10.0.0.1 255.255.255.252
clockrate 64000
no cdp enable

Configuracion del lado donde hayas colocado el cable DTE:

interface Serial1
ip address 10.0.0.2 255.255.255.252
no cdp enable


Notese que la configuracion del cable donde se encuentra el cable DCE debe tener el comando clockrate. Esto es muy necesario porque el router con el cable DTE necesito recibir el reloj porque son enlaces sincronos y es necesario un dispositivo que entregue el reloj a la red.

troubleshooting
#show controller s0
#ping 10.0.0.1
#ping 10.0.0.2
#show interface s0

b) Conectando utilizando Frame Relay (mi recomendacion en caso de un Laboratorio)
El motivo porque recomiendo esta configuracion sobre todo para un laboratorio de Cisco es que te permite crear varios enlaces (PVCs) entre los dos routers lo que te dara mas flexibilidad para tus configuraciones (protocolos de enrutamiento dinamico, suspender un enlace para una prueba, etc)

Configuracion del lado donde hayas colocado el cable DCE:
!
interface Serial0
no ip address
encapsulation frame-relay
no keepalive
clock rate 64000
!
interface Serial0.1 point-to-point
ip address 10.0.01 255.255.255.252
frame-relay interface-dlci 101


Configuracion del lado donde hayas colocado el cable DTE:
!
interface Serial0
no ip address
encapsulation frame-relay
no keepalive
!
interface Serial0.1 point-to-point
ip address 10.0.0.2 255.255.255.252
frame-relay interface-dlci 101


Notese que donde se encuentra el cable DCE tuvo que colocarse nuevamente el comando clockrate para que dicho router diera reloj a la red. En esta oportunidad adicionalmente hubo que colocar el comando no keepalive el cual deshabilita el procesamiento de LMI. Por ultimo, notese que se crearon subinterfaces point-to-point. A pesar de que la configuracion se puede realizar dentro de la interfaz madre (S0) aconsejo realizarlo dentro de la subinterfaz para ganar flexibilidad (por ejemplo, crear nuevas subinterfaces como s0.2, s0.3)

Troubleshooting:
#show interface
#show frame-relay pvc
#show frame-relay map
#ping
#show controller


2) Utilizando las interfaces Aux
Si te encuentras construyendo un Lab seguramente deseeas tener muchas conexiones para realizar muchas pruebas. Algo que puede ser muy util es conectar dos routers back2back utilizando el cable de consola entre dos routers en sus puertos Aux. La configuracion seria la siguiente:

Primo debes averiguar en cada router el numero de la interfaz Async, recomiendo que entres en modo configuracion global e intentes configurar la interfaz async1 a la async5.

En ambos routers lleva una configuracion como esta (ojo con los IPs). Esta configuracion permite IP, protocolos de enrutamiento, etc. Es muy importante que el txspeed en un router sea el rxspeed en el otro y viceversa.

interface Async1
ip address 192.168.10.1 255.255.255.0
encapsulation ppp
async default routing
async mode dedicated
!
line aux 0
modem InOut
transport input all
rxspeed 38400
txspeed 38400
flowcontrol hardware

Troubleshooting:
#show line
#ping


3) Utilizando enthernet

Tan solo es necesario un cable cruzado entre los puertos ethernet de los routers


Suerte y espero haya sido util esta informacion

viernes, 19 de junio de 2009

Comando oculto en Cisco. EIGRP

Esta es un post muy corto.
Otro comando oculto en Cisco. No esta documentado pero tiene información valiosa


2801#show ip eigrp timers
IP-EIGRP timers for process 1111
Hello Process
Expiration Type
| 0.548 (parent)
| 0.548 Hello (FastEthernet0/0.21)

Update Process
Expiration Type
| 10.840 (parent)
| 10.840 (parent)
| 10.840 Peer holding

SIA Process
Expiration Type
| 0.000 (parent)
2801#

miércoles, 17 de junio de 2009

Problemas con Postfix dsn= 4.4.2

En el dia de ayer, una empresa a la que a veces le presto servicios me llamo porque estaban teniendo fallas con su servicio de correo.

El primer paso que hice, fue revisar los logs, y al hacerlo me encontre con estos errores que ocurrian con varios Dominios:

dsn=4.4.2, status=deferred (lost connection with alt1.gmail-smtp-in.l.google.com[209.85.222.27] while sending message body)

dsn=4.4.2, status=deferred (lost connection with f.mx.mail.yahoo.com[98.137.54.237] while sending end of data -- message may be sent more than once)

Estos errores tienden a ser por problemas de latencia, que la transmision del correo se cierra debido al delay que se presenta, pero para mi sorpresa, el enlace estaba bien, no habia latencia en la red de la empresa.

Intente disminuir el MTU de la interfaz eth0:

debian:/home/xxxx# ifconfig eth0 mtu 1000
debian:/home/xxxx# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1a:4b:5e:10:c8
inet addr:10.10.10.10 Bcast:192.168.127.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1000 Metric:1

Pense que esto iba a solucionarlo, pero no fue asi, despues de correr "mailq -q" para forzar la salida de los correos en cola, los mismos se mantenian en las mismas condiciones.

Capaz era problema se relacionaba con el MTU discovery

"debian:/home/xxxx#echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc"

Luego de volver a correr "mailq -q", seguia dando el mismo error.


Por lo que procedi a instalar tcpdump "debian:/home/xxxx# aptitude install tcpdump" y sniffear el trafico del puerto 25.

"debian:/home/xxxx# tcpdump -i eth0 port 25"

Y lo deje corriendo un rato, mientras enviaba correos a la empresa y de la empresa enviaba correos a otros dominios. Luego de obtener bastante informacion procedi a analizarla con Wireshark (esta herramienta es lo mejor creado por el ser Humano, junto con nmap :P).

Comparte con ustedes lo que vi en Wireshark


Al ver el error que estaba teniendo en cuanto al "TCP checksum offload", procedi a deshabilitarlo en la interfaz eth0.

Esto se puede hacer con una herramienta que se llama ethtool, que te permite manipular las propiedades de la interfaz.


debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: on <============
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off

debian:/home/xxxx# ethtool --offload eth0 tx off

y luego

debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: off <============ :)
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off


Al hacer esto, los correos empezaron a salir :)....

Para quienes no tengan muy claro que es esto, les dejo una pequenha nota;

"If you are experiencing network problems and while trying to figure
it out with Wireshark you found these checksum errors, you may have a
network card with TCP checksum offload enabled and for some reason the
packet is not being fixed by the adapter (NAT, bridge or route
redirection is sending the packet to another interface). In this case,
you may want to check and disable checksum offload for the adapter, if
possible."

Mas detallado:

"tcp checksum offloading will not offer you very much performance wise
since it is so cheap to calculate it with the CPU. tcp checksum
offloading is dangerous for data however since it means that you will
send your packets across the least reliable component of your computer
(the pci bus) and without tcp checksum calculated by the stack you
will not detect bits being flipped/corrupted by the pci bus and thus
data might be corrupted. tcp checksum offloading is not as good as it
initially might be thought."

viernes, 12 de junio de 2009

Policy Based Routing, HSRP y redundancia. Cisco

Necesidad
Contar con dos routers y una dirección IP en Standby (HSRP), donde ciertas redes origen enrutarlas por el Carrier A y otras redes por el Carrier B, sin embargo en caso de fallar algún proveedor funcione la redundancia.
En el caso descrito anteriormente no se puede utilizar un protocolo de enrutamiento dinámico porque se desea enrutar por dirección fuente. Por otro lado, si pueden existir otros modos de realizar esta tarea.

Escenario

2 Router Cisco 1841
2 Enlaces WAN
HSRP
Redes a enviar por el Carrier 1:
10.1.0.0 0.0.255.255
192.168.30.0 0.0.0.255
Redes a enviar por el Carrier 2:
10.144.192.0 0.0.15.255

Diagrama





Procedimiento

Lo primero que haremos es configurar la parte de HSRP. Para ello utilizaremos la siguiente configuración:

En RTR-1
interface FastEthernet0/0
description TO-LAN
ip address 10.1.1.207 255.255.0.0
standby 1 ip 10.1.1.206
standby 1 timers 1 5
standby 1 priority 110
standby 1 preempt
standby 1 authentication CISCO
standby 1 track 1 decrement 20

En RTR-2
interface FastEthernet0/0
description TO-LAN
ip address 10.1.1.204 255.255.0.0
standby 1 ip 10.1.1.206
standby 1 timers 1 5
standby 1 preempt
standby 1 authentication CISCO

Con la configuración anterior tendremos en RTR-1 el IP 10.1.1.207 y en RTR-2 el IP 10.1.1.204. El IP virtual es el 10.1.1.206

2) Indicarle a cada router como alcanzar la WAN del router contrario e indicarles las listas de acceso:

En RTR-1
ip route 10.0.0.1 255.255.255.255 10.1.1.204
access-list 120 REMARK Por el carrier 1
access-list 120 permit ip 10.1.0.0 0.0.255.255 any
access-list 120 permit ip 192.168.30.0 0.0.0.255 any

access-list 121 REMARK Por el carrier 2
access-list 121 permit ip 10.144.192.0 0.0.15.255 any

En RTR-2
ip route 172.16.100.225 255.255.255.255 10.1.1.207
access-list 120 REMARK Por el carrier 1
access-list 120 permit ip 10.1.0.0 0.0.255.255 any
access-list 120 permit ip 192.168.30.0 0.0.0.255 any

access-list 121 REMARK Por el carrier 2
access-list 121 permit ip 10.144.192.0 0.0.15.255 any

3) Es necesario habilitar SLA (Service Level Agreement) y tracks en los routers para mantener el monitoreo vía ping de los enlaces WAN en cada router. Esto es necesario para que a través de PBR los route-maps puedan tomar la decisión de por donde enrutar los paquetes.

En RTR-1

ip sla monitor 2
type echo protocol ipIcmpEcho 172.16.100.225
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 2 life forever start-time now

ip sla monitor 3
type echo protocol ipIcmpEcho 10.0.0.1
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 3 life forever start-time now

track 2 rtr 2 reachability
track 3 rtr 3 reachability

En RTR-2

ip sla monitor 2
type echo protocol ipIcmpEcho 10.0.0.1
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 2 life forever start-time now

ip sla monitor 3
type echo protocol ipIcmpEcho 172.16.100.225
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 3 life forever start-time now

track 2 rtr 2 reachability
track 3 rtr 3 reachability

En el ejemplo anterior, en ambos routers se estan monitoreando los IPs WAN vía ping con un timeout de 1000 ms, un umbral de 50 ms cada 3 segundos.

4) Configurar los route-maps en cada router

RTR-1

route-map CARRIER permit 5
match ip address 120
set ip next-hop verify-availability 172.16.100.225 10 track 2
set ip next-hop verify-availability 10.0.0.1 20 track 3

route-map CARRIER permit 10
match ip address 121
set ip next-hop verify-availability 10.1.1.207 10 track 3
set ip next-hop verify-availability 172.16.100.225 20 track 2

RTR-2

route-map CARRIER permit 5
match ip address 121
set ip next-hop verify-availability 10.0.0.1 10 track 2
set ip next-hop verify-availability 10.1.1.207 20 track 3

route-map CARRIER permit 10
match ip address 120
set ip next-hop verify-availability 10.1.1.207 10 track 3
set ip next-hop verify-availability 10.0.0.1 20 track 2


5) Finalmente es necesario aplicar el comando ip policy route-map en la interfaz f0/0 en cada router

#conf termin
(config)#inter f0/0
(config-if)#ip policy route-map CARRIER

Explicación
Ahora bien, vamos a intentar correr esto en frio:
1) El host 10.1.0.100 envia un paquete a la red 192.168.1.0
2) El paquete lo recibe RTR-2 por la interfaz F0/0
3) La politica es aplicada según el route-map CARRIER
4) En RTR-1, el route-map CARRIER identifica la red origen 10.1.0.100 y coloca como next-hop el IP 10.1.0.207
5) Lo recibe la interfaz f0/0 de RTR-1 quien nuevamente aplica la politica CARRIER y sabe que debe enviar el paquete por la interfaz F0/1 con next-hop 172.16.100.225

Ahora bien, vamos a intentar correr esto en frio con el enlace f0/1 caido en RTR-1:

1) El host 10.1.0.100 envia un paquete a la red 192.168.1.0
2) El paquete lo recibe RTR-2 por la interfaz F0/0
3) La politica es aplicada según el route-map CARRIER. El route-map sabe que no puede ser alcanzado el IP 172.16.100.225 gracias a los comandos SLA previamente configurados (el router cada 3 segundos verifica si puede hacerle ping a este IP).
4) El route-map CARRIER identifica la red origen 10.1.0.100 y coloca como next-hop el IP 10.0.0.1

Verificacion
1) Traceroute desde las redes pertinentes
2) #show track 2
3) #show track 3

NAT en Cisco. 2 ISPs diferentes

Necesidad:
Tener un enlace primario y un enlace secundario en un mismo router con dos proveedores a Internet diferentes.

Escenario(abajo la configuracion detallada y explicada):
Router Cisco 1760 donde:
Interfaz Fastethernet0/0 LAN (IP 172.20.0.1)
Internaz Serial1/0.1 ISP Primario (IP 10.0.0.58)
Internaz Serial0/0.1 ISP Secundario (IP 10.1.1.58)

Diagrama:








Procedimiento:

Primero es necesario configurar unas rutinas en el router que se van a encargar de monitorear las interfaces WAN.

ip sla monitor 1 (deseo monitorar el next-hop del enlace del ISP primario)
type echo protocol ipIcmpEcho 10.0.0.57 source-interface Serial1/0.1
timeout 1000
threshold 400
frequency 3
ip sla monitor schedule 1 life forever start-time now (esta linea es para activar realmente el monitoreo)
ip sla monitor 2 (deseo monitorar el next-hop del enlace del ISP secundario)
type echo protocol ipIcmpEcho 10.1.1.57 source-interface Serial0/1.1
timeout 2000
threshold 1000
frequency 3
ip sla monitor schedule 2 life forever start-time now (esta linea es para activar realmente el monitoreo)
!

Con las lineas arribas indicadas lo que se hace es monitorear si el next hop en el enlace WAN esta levantado. Por ejemplo en el primer caso se hace ping (ipIcmpEcho) al IP 10.0.0.57, con un timeout de 2000 ms, un umbral de 1000 ms cada 3 segundos.


Posteriormente es necesario habilitar los comandos track en Cisco. Estos son muy utiles para conocer luego el estado de los SLA previamente configurados. Los comandos son:

track 123 rtr 1 reachability
delay down 15 up 10
!
track 345 rtr 2 reachability
delay down 15 up 10
!

El truco se encuentra en el NAT (tanto asi que lo anterior se puede hacer con rutas flotantes, sin embargo de la manera implementada es la mejor practica). El NAT debe ser realizado en base a route-maps (no lo intentes de otra manera). Las lineas que personalmente utilice fueron:

ip nat pool POOL-MINAT 200.30.30.30 200.30.30.30 prefix-length 29
ip nat inside source route-map ISP-1 pool POOL-MINAT overload
ip nat inside source route-map ISP-2 interface Serial0/1.1 overload

access-list 150 remark PARA-NAT
access-list 150 permit ip 172.20.0.0 0.0.0.255 any

route-map ISP-1 permit 5
match ip address 150
match interface Serial1/0.1
!
route-map ISP-2 permit 5
match ip address 150
match interface Serial0/1.1


En el ejemplo anterior vemos que el NAT es en base a los route-maps ISP-1 e ISP-2, el ACL a utilizar es el 150 extendido donde estamos nateando toda la red 172.20.0.0/24

Cuando los paquetes salgan por el ISP-1 saldran nateados con el IP 200.30.30.30 y cuando salgan con el ISP-2 saldran con el IP de la interfaz WAN. Logicamente puedes ajustar esto a tu necesidad.

Ahora bien, la ruta de los paquetes de salida son definidas con la siguiente configuracion:

ip route 0.0.0.0 0.0.0.0 Serial1/0.1 track 123
ip route 0.0.0.0 0.0.0.0 Serial0/1.1 track 345

La ruta por default es la interfaz s1/0.1 cuando el IP 10.0.0.57 se encuentre UP, en caso de que se caiga la interfaz y/o el ping al IP 10.0.0.57 NO sea satisfactorio se utilizara la ruta por la interfaz S0/1.1 (enlace secundario)


Verificacion:

1760-WAN#sh track 123
Track 123
Response Time Reporter 1 reachability
Reachability is Up
33 changes, last change 08:27:17
Delay up 10 secs, down 15 secs
Latest operation return code: OK
Latest RTT (millisecs) 11



1760-WAN#sh track 345
Track 345
Response Time Reporter 2 reachability
Reachability is Up
36 changes, last change 3d01h
Delay up 10 secs, down 15 secs
Latest operation return code: OK
Latest RTT (millisecs) 8



1760-WAN#sh ip nat t
[OUTPUT SUPRESSED]




Links de informacion:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a0080950834.shtml
y
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a00808d2b72.shtml



Espero haya sido de tu ayuda,

Suerte!,

viernes, 5 de junio de 2009

Tips de Seguridad para Linux

A la hora de instalar un Servidor en Linux, el paso del tiempo me ha dado ciertas experiencia a la hora de ajustar politicas de seguridad. Muchas de ellas van a ayudar a que nuestro servidor se encuentre mas seguro.

A continuacion, comparto varias de las politicas que siempre mantengo en mente a la hora de configurar un servidor.

Siempre despues de instalar un servidor, aprovecho para hacer estos cambios.

1) Con el comando chkconfig, elimino los siguientes daemons:
ppp, bind9 ( a menos que sea un servidor DNS), lwresd, portmap, exim4, netatalk, samba, fam, nfs-common, atd, apache2.

E inclusive, sino son necesarios, los elimino

2) Me aseguro de que el siguiente parametro este en el archivo /etc/security/limits.conf

* hard core 0

3) Asegurarse tambien de que las siguientes lineas esten en el archivo /etc/pam.d/login

session required /lib/security/pam_limits.so

4) Comento la siguiente linea en el archivo /etc/inittab

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

ejm:

#ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

5) Las claves deben de expirar cada 90 dias, esto se hace editando el siguiente parametro en /etc/logins.def

MASS_MAX_DAYS 90

6) Elimino las siguientes cuentas (/etc/passwd, /etc/shadow)

games, lp, news, uucp, proxy, irc, gnats, list


7)Cambio el shell por defecto de los siguientes usuarios a /bin/false
bin, daemon, mail, nobody, sync, sys

8) Elimino cualquier informacion que contengan los archivos

/etc/issue
/etc/issue.net

9)Todo los ejecutables que tenga el setuid y setgid, por defecto, ninguno puede ser escrito por el grupo "others"

find / -perm -4000 -exec ls -l {} \;
find / -perm -2000 -exec ls -l {} \;

Ejm
-rwsr-xr-x 1 root root 31640 2008-11-22 11:01 /usr/bin/passwd
||



9) Modifico el parametro a continuacion en el archivo /etc/login.defs:

LOGIN_RETRIES 3

( crear el archivo /var/log/faillog para grabar todo los intentos de acceso)

10) Editamos el archivo /etc/pam.d/common-password y nos aseguramos de que la opcion min=8 este en la configuracion de pam_unix


Estos tips van a ayudar de cierta manera a asegurar el servidor, mas adelante, colocare unas herramientas que van a ayudarnos a realizar tareas sobre el sistema y verificar la integridad del mismo.