root@floyd:~# nmap -vv 192.168.1.141 -p T:1-65535,U:1-65535
Starting Nmap 5.00 ( http://nmap.org ) at 2011-10-07 23:32 ART
NSE: Loaded 0 scripts for scanning.
Initiating ARP Ping Scan at 23:32
...
Bla, bla, bla, bla...
...
Completed SYN Stealth Scan at 23:33, 85.35s elapsed (65535 total ports)
Host 192.168.1.141 is up (0.020s latency).
All 65535 scanned ports on 192.168.1.141 are closed
MAC Address: PU:TO:EL:QU:EL:EE (MediaTek)
Ese fuí yo, tirándole un Nmap a la interface WAN de mi teléfono celular...
Otro título sugerido: Como hacerle la vida imposible a tu sysadmin – parte 2
Si no leyeron el artículo anterior: Como hacerle la vida imposible a tu sysadmin deberían empezar por ahí para entender de que estoy hablando. Para los cortos de tiempo resumo brevemente:
Por un lado: Tenés acceso a una PC que remotamente corre Linux, puede ser un servidor que administres o la PC de tu casa, da lo mismo. No hace falta disponer de privilegios de super-usuario en la PC remota. Esta PC remota corre un servidor SSH que te permite login remoto.
Por el otro: La persona que administra la red de tu trabajo te tiene impedido, no te permite chatear, usar Facebook o Twitter, no podés navegar por ciertas páginas o usar ciertos servicios.
Otra posibilidad: Estas conectado desde una red «pública» en un bar, aeropuerto o simplemente robándole internet el vecino y no tenés ninguna manera de saber quien podría estar olfateando los paquetes de datos que van y vienen, sobre todo ahora, que herramientas como Firesheep hacen que un ataque man-in-the-middle que siempre fue cosa reservada para unos pocos elegidos sea coser y cantar.
También podrías usar este sistema (o un buen tunel SSH por cada servicio a rutear haciendo las veces de Socks Proxy con todas las incomodidades que conllevaría)si estás conectado desde un enlace poco fiable en donde la pérdida de paquetes está fuera de discusión.
O si ninguna de las anteriores te convence: Simplemente por que nunca se es lo suficientemente paranoico, otro mini tutorial: Como encriptar TODO el tráfico que genera tu PC y rutearlo remotamente para evitar cualquiera de los escenarios anteriores.
Usando SSH para rutear todo el tráfico TCP que se genere en tu PC hasta un host remoto.
«Dime cuantos paquetes de datos pierdes y te diré cuán como la mierda navegas.»
… O de como hacer uso y abuso del comando ping para verificar un enlace de datos.
Mas que nada en conexiones inalámbricas pero puede darse en cualquier otra circunstancia también y por motivos de lo mas diversos, además de una buena latencia es muy importante evitar la pérdida de paquetes de datos entre tu PC y su interlocutor a toda costa.
Hay miles de herramientas, algunas que funcionan en modo texto, otras tantas en modo gráfico que te permiten darte una idea muy aproximada de la calidad real de un enlace de datos pero si tengo que poner primera en la lista de las mas usadas al menos por mí –y creo que por el colectivo de informáticos también– definitivamente el comando ping para consola se lleva todos los laureles, además viene preinstalado de serie en cualquier sistema operativo, sea el que sea.
De todo corazón espero que no seas usuario de Windows. Si lo sos, entonces ni te gastes en seguir leyendo, por que si bien el comando ping para windows dispone de alrededor del 2% de las funcionalidades que nos provee el mismo para Linux, todo lo que voy a explicar a continucación queda sin efecto. Si sos usuario de Windows por otro lado, he aquí otra buena razón para tener siempre un Linux cualquiera a mano, en un CD, en un pendrive o en alguna partición pequeñita, por que nunca sabés cuando lo vas a necesitar.
Volviendo al asunto, no voy a entrar en detalles sobre el principio de funcionamiento del comando ping para Linux ni a explicar como entender la salida en pantalla del mismo (para los que se estén desayunando con esto por primera vez y les interese, los remito al manual del comando) si no a centrarme en una característica puntual que lo vuelve una de las mejores herramientas a la hora de hacer verficaciones de calidad de servicio mientras se hacen modificaciones sobre el enlace de datos: La capacidad de inundación, lo que en inglés se conoce como «Flood».
Ping para Linux es la navaja suiza de las herramientas de testeo de calidad del enlace y la capacidad de floodear que posee debe ser una de las mejores herramientas «graficas» para consola que podés encontrar por ahí. Unicamente disponible para superusuarios –necesitás privilegios de root para poder usar esta caraterística– te permite conocer con presición como anda la cosa mientras toqueteás algún que otro parámetro en tu router.
La genialidad de la opción flood radica en su principio de funcionamiento: Por cada paquete de datos que se envía se imprime un punto -un » . «- en la pantalla. Por cada paquete de datos que se recibe, se borra un punto. Eso es todo.
El nombre de «flood» o inundación que sería la traducción literal proviene del hecho de que el kernel no esperará absolutamente nada entre un paquete enviado y otro, inundará la red con peticiones usando el protocolo ICMP tan rápido con el enlace en si mismo lo permita y a menos que específicamente le habilites el modo «adaptativo» pasandole al comando la opción » -A » forzará al enlace a todo lo que dé produciendo inevitablemente fallos que serás capaz de visualizar a golpe de ojo nada mas viendo como se van imprimiendo (o no) puntitos en la pantalla en tiempo real.
Dependiendo del escenario puede que te interese verificar cuanto es el máximo ancho de banda disponible en un enlace inalámbrico o cuantos paquetes pierde tu conexiòn a internet por culpa de lo anterior. Suponiendo que quisieramos hacer esta última prueba, haciendo ping contra el servidor de DNS de Google por ejemplo, el comando en cuestión es tan simple como lo que sigue:
ping -f 8.8.8.8
Que en una red sana debería devolverte algo como esto:
Usando ping con flood habilitado para verificar el estado de la conexión.
Y que por otro lado, en una red con problemas, debería devolverte esto otro:
Verificando una red con problemas de pérdida de paquetes con ping.
Todos los puntitos que se ven en la última captura representaron en tiempo real la pérdida de paquetes que hubo durante todo el proceso. Usé además la opción «count» representada por » -c » para pedirle a ping que solo envíe 1000 paquetes y se detenga a continuación.
Es muy util también la opción «size» para especificar el tamaño de paquete, esto sirve para diagnosticar otro tipo de problemas por ejemplo cuando estás jugando con el MTU de tus routers o interfaces de red o el RTS o el Fragemnation Threshold de tu router inalámbrico.
Como la cabecera del protocolo ICMP utiliza siempre 8 bytes, para forjar un paquete por ejemplo de 512 bytes de tamaño necesitas tener estos 8 bytes en cuenta, restándoselos al momento de ejecutar el comando:
ping -f -c 1000 -s 504
Es muy común ver como una red inalámbrica se desempeña a la perfección con paquetes de datos pequeñitos, los de 64 bytes que envía ping por defecto (la cabecera ICMP + 56 bytes adicionales) cuando no se le especifica el tamaño pero se viene todo a pique cuando el tamaño de paquete excede los 512 o 768 bytes, por ejemplo. Y ni hablar de cuando excede al MTU que por defecto en este tipo de redes es de 1500 bytes.
También es muy útil a la hora de testear redes que tienen implementado QoS por que permite especificar los bits ToS en la cabecera del paquete, con lo que podés ver en tiempo real que tal se desempeña tu router en este sentido. Por ejemplo para el ToS «Maximice Data Throughput» basta con ejecutar:
ping -f -c 1000 -s 504 -Q 0x08
Ping: La herramienta que no te puede faltar a la hora de aislar fallos puntuales en una red. Preinstalada por defecto y gratis. ¿Que mas se puede pedir?
Todo empezó hace un par de años, el día que le puse DD-WRT a mi Linksys WRT54G Versión 8, eso fué lo que desencadenó la sucesión de eventos que a continuación relato:
Al ver que con ese firmware mi router podía hacer de todo, le falta hablar nomás, me dije: «Esto no puede quedar así» y dicho y hecho, no quedó así como estaba, –bajo techo al reparo de las adversidades climáticas y lleno de mimos– si no que fué a parar dentro de un tupperware, ese tupperware arriba del punto mas alto que pude encontrar en mi casa, que viene siendo el tanque de agua y sostenido todo el conjunto para que no se vuele con una batería de UPS de esas de 12V haciéndole peso. Los +9V de alimentación por el mismo cable ethernet en un PoE improvisado pelando cables y listo, mas tercermundista imposible.
Lo primero que hice con el router en su nueva ubicación privilegiada es salir a hacer auto-wardriving si es que existe tal cosa, salir de mi casa y ver hasta donde me llegaba la cobertura, resultó ser que en alrededor de 200 metros a la redonda mi señal era visible. Lo segundo fué volver a casa pensando: ¿Recibiré redes inalámbricas desde 200 metros a la redonda en mi router?
Así fué que volví a casa, entré a la sección «Site Survey» de la configuración del router para buscar redes inalámbricas dentro del radio de cobertura y sorpresa: En donde vivo, la única red inalámbrica que puedo pescar con una laptop es la mía, no veo ninguna otra pero el router colgando ahi arriba puede ver entre 7 y 8 redes inalámbricas distintas de los alrededores.
La primera de las redes wi-fi vecinas que me llamó la atención fué una que rezaba:
TP-LINK_AABBCC AP 00:21:27:AA:BB:CC 8 -86 -92 100 Yes 0 54(b/g)
Donde ese YES estaba indicando una red abierta a todo público y lista para usar o en el peor de los escenarios, con filtrado por mac address, (pero si supieran de filtrado por MAC Address lo mínimo que hubieran hecho sería cambiarle el SSID a la red), sin embargo en este caso, hasta el SSID era el por defecto, la marca del aparato y los últimos tres valores de su MAC Address.
Solo por probar, –por que pago por mi propia conexión a internet y no tengo necesidad de andar haciendo estas cosas-, puse el router en modo cliente de access point, cambié el IP LAN del router a el mas improbable que se me ocurrió encontrar (172.16…) y me conecté al TP-Link.
