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."

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 configuración 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!,


pdf to word

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.

Recuperar clave. Linksys WRT-54G

Buenas,
Hoy tuve la necesidad de recuperar el password de un router (access point) Linksys modelo WRT54G y luego de revisar varias páginas les indico el procedimiento:

1) Apagar el router
2) Desconectar cualquier cable en los puertos 1-4 y WAN
3) Prende el router
4) Presiona el botón reset en la parte trasera por 30 segundos. Los leds de adelante titilaran (wlan led). Luego espera que el router se inicie por completo (max 2 minutos)
5) Apaga el router
6) Conecta un PC/Laptop al puerto 1 (NO al puerto WAN)
7) Coloca a tu PC/Laptop el IP: 192.168.1.2 Mask: 255.255.255.0
7) Prende el router. Espera 2 Minutos
8) Listo!.., realiza un ping al IP: 192.168.1.1 y debe funcionar.
9) Abre un navegador y apunta el mismo al IP: http://192.168.1.1 te va a pedir usuario y contraseña.

Por defecto el equipo no tiene usuario (dejalo en blanco) y la clave es admin

Como recomendación cambia el channel 6 con el cual viene por defecto la mayoría de los APs. En esta frecuencia seguramente existiran otros APs (sobre todo si vives en un edificio!!) y lamentablemente entre los mismos se crea algún tipo de interferencia. Del lado del cliente nunca es necesario cambiar nada. Realizar este cambio es sencillo y te trae varios beneficios. Por favor utiliza los channel 10 u 11 y con cifrado WPA (NUNCA WEP)

Si quieres ver en que frecuencia se encuentran trabajando los APs en tu zona, en linux puedes utilizar el siguiente comando:

#iwlist wlan0 scan
(donde wlan0 es la interfaz wireless)

o algo más sencillo y ves la "competencia":
#iwlist wlan0 scan | grep Channel


Suerte.

Capturar más de 68 o 96 bytes con tcpdump

Varias veces he tenido la necesidad de capturar y luego analizar más de la información que guarda tcpdump por defecto (con la opción -w) luego de guardarla en un archivo.

TCPDUMP generalmente solo captura 96 bytes del paquete que viaja en el el cable, este valor por lo general es suficiente para analizar ethernet, ip, tcp/udp, icmp. Sin embargo, por ejemplo el contenido de un paquete grane HTTP imposible.

Por ello, en caso de tener la limitante antes mencionada la solución es el flag -s:

Ejemplo de captura por defecto:

tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes


0 packets captured
0 packets received by filter
0 packets dropped by kernel

Ejemplo de captura de todo el paquete en el cable:


[root@localhost tmp]# tcpdump -s 0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C

Notese el flag -s en el pase de parametros para tcpdump. Otros flags importantes:

* port
* host
* dst port
* src port
* dst host
* src host
* -w file

y es muy importante recordar que se puede contruir expresiones como las siguientes:

#tcpdump -s 0 dst port 23 and host 1.1.1.1 -w sniff.dump

Con el ejemplo anterior veremos que solo capturará paquetes donde el puerto destino sea 23 y contenga (origen o destino) el host 1.1.1.1

No voy a indicar más ejemplos porque la red se encuentra llena de ejemplos de tcpdump.

Suerte!

Como recuperar el password de un AP TP-LINK

Hola,
El otro dia tuve la necesidad de recuperar el password de un equipo Access Point TP-LINK y dure muchisimo en buscar una pagina que tuviese un procedimiento efectivo para recuperar la clave del equipo.
En este sentido, les dejo un procedimiento que funciona perfecto en un TP-LINK en los modelos: TL-WR641G / TL-WR642G

a) Apagar el equipo
b) Presionar el boton reset
c) Prender el equipo con el boton reset presionado
d) Dejarlo por 10 segundos
e) admin/admin son los default login/password

Suerte,