El blog de Christo

Prólogo

Hasta el día de hoy no encontré en ningun lado un artículo claro y conciso sobre Nmap en español. Los que hay son bastante incompletos, o se enfocan en un caso de uso particular para fines puramente prácticos. Que no están mal, solamente no encudran en mi idea. Siguiendo guías con fines meramente prácticos seríamos como monos en un circo repitiendo las monerías que enseña el adiestrador, pero no estaríamos aprendiendo nada realmente. Por eso este artículo, que se basa en dos ideas: una creadora, y otra motivadora.

El General Juan Domingo Peron, a este asunto, siempre hacía referencia a esta anécdota:

El Mariscal de Sajonia contaba que tenía una mula que lo había acompañado durante más de 20 años en sus campañas, sin embargo la pobresita nunca aprendió nada de estrategia…y sospechaba que algunos de sus hombres tampoco. En cambio, Clausewitz^[x], el gran filósofo de la guerra, que ha escrito la teoría más maravillosa sobre la filosofía de la misma, nunca estuvo en una campaña, ni siquiera en una batalla.

Claro que el General lo decía como puente para profundizar otra idea -la del conductor nato-, sin embargo la escencia de esa comparación, si se quiere, es totalmente válida para lo que intento mostrar. Estoy plenamente convencido que para aprender algo, no solo hay que conocerlo en profundidad, no solo hay que estar familiarizado con su práctica, sino que hay que comprenderlo. Y esa comprensión no viene del conocimiento que se pueda adquirir, ni de la práctica, unicamente. Viene de la capacidad de las personas para la creación mental, para aislar, identificar y unir de forma coherente los conocimientos, formando una imágen concreta y útil -que de otra forma no serían más que datos-. Ofrecer estos datos y acompañar en el proceso creador de la comprensión es la idea creadora de este artículo.

Es necesario en estos días que vivimos, donde las tecnologías de información son omnipresentes e indispensables para la vida diaria, que todos las podamos manejar. Porque algo que no controlamos, inevitablemente nos controla a nosotros.  Y controlar no es solo usar, sino conocer cómo funciona una cosa y comprenderla. Por eso, con este artículo voy a intentar dar herrmaientas para comprender y controlar. Esta idea es la motivadora de este artículo.

La verdad que es todo un desafío encontrar la mejor manera de escribir este artículo para que sea cómodo leerlo, y no resulte duro y chocante como puede pasar con la mayoría de los textos puramente técnicos. Para no sofocar con demasiados conceptos todos juntos, y no se pierda uno en el camino, algunos los voy a ir explicando a medida que sean necesarios para entender lo que se va a leer. Pero también disfruté mucho escribiéndolo, la verdad.

Aprovecho para extender un gran agradecimiento a Gordon “Fyodor” Lyon, el creador de Nmap. No solo por haber creado Nmap, sino por haber escrito un excelente libro sobre él y haberme permitido usar su contenido para este artículo. Es un tipo macanudísimo. Parte de lo que escribí está directamente basado en la versión online del libro^[0] -la historia de Salvando a la humanidad es una traduccion directa, y los esquemas de escaneos son copia traducida-.

Si este artículo los deja con ganas de saber más, no duden un segundo en comprar^[1] el libro de Fyodor que es muy completo, les va a resolver todas las dudas que tengan, y es atrapante, lleno esquemas gráficos y situaciones de ejemplo. No es un libro técnico más del montón. Acá en Argentina no sé dónde puede conseguirse, pero pueden comprarlo online en Amazon u otros sitios similares y hacerlo enviar a Argentina, o comprarlo en PDF -perosnalmente no me gusta leer libros en pantallas-. Este chivo es lo menos que puedo hacer en retribución a la buena voluntad de Fyodor.

Y por último, pero no menos importante, quiero agradecer a mi gente de Foro UADE^[2], que es de donde realmente surgió la idea de escribir este artículo. El año pasado publiqué un post que fue el primer “borrador” de este artículo. La gente del foro lo leyó y les gustó tanto que pensé en mejorarlo, extenderlo y, bueno, finalmente en convertirlo en un artículo. Gracias totales a ellos.

Probablemente se van a preguntar más de un por qué a lo largo de este artículo -por lo menos eso espero-. Seguro uno de los primeros va a ser ¿Por qué Nmap? ¿Por qué hablar sobre una herramienta, si la idea es introducir al lector que no tiene conocimiento previo? Así que esa incógnita la develo acá, de ante mano.

Elegí Nmap porque si quiero que, por jemplo, alguien entienda algo sobre jardinería, tendría que inevitablemente explicar cómo usar una tijera. O cómo usar una pala de jardinería. Son herramientas básicas. Seguramente sin éstas pudiera explicar jardinería. Pero me parece que es mucho más natural y motivante ir incorporando conceptos básicos a medida que sean necesarios para esgrimir la herramienta elegida en función de hacer una tarea determinada. Por ejemplo, podar una planta.

En ese sentido es que en este artículo se van a encontrar con una clara explicación de cómo usar Nmap, como vía para una introducción bastante detallada al funcionamiento de las comunicaciones en redes informáticas -sobre todo Internet-. Todo esto en función de aprender cómo escanear puertos en una red.

¿Qué es Nmap?

Bien, Nmap es una herramienta de software, libre y gratuita, que permite encontrar dispositivos (PC, servidores, impresoras de red, routers, etc) y los servicios asociados a estos, dentro de una red. El nombre Nmap viene de las palabras en inglés network mapper, que justamente significan mapeador^[y] de red, es decir que descubre los caminos de una red -transliterando la palabra mapper-.

El trabajo lo hace enviando paquetes, a uno o más equipos remotos conectados a la red, y después analizando cómo se comportan las respuestas que dan estos equipos. Los paquetes enviados son creados por Nmap con características diseñadas para poder obtener información a partir de las respuestas que provocan. Además del simple escaneo de equipos para saber si están conectados o no, y ver qué puertos están abiertos o cerrados, Nmap puede determinar el sistema operativo que corre cada equipo remoto (con un márgen de error muy pequeño), así como también descubrir qué servicios ofrece cada equipo detectado, estimar el uptime, el tipo de dispositivo, y si existe algún dispositivo de firewall en el camino hacia algún equipo.

Nmap, por ser software libre, ha sido portado^[z] a casi cualqueir sistema operativo y arquitectura existentes. Corre en GNU/Linux, Windows, Solaris, HP-UX, BSD, OSX, AmigaOS, SGI IRIX, sobre procesadores x86, x86_64, Sparc, Mips, ARM, PowerPC, hasta en la PlayStation3 anda (que usa un variante de PowerPC). Imagínense que hasta lo pude compilar para que corra en mi teléfono celular, un Motorola a1200, viejito ya -hoy siendo tan populares los smartphones iPhone y Android puede sonar algo trivial, pero hace cinco años atrás fue toda una aventura y un logro-. Básicamente si un dispositivo puede correr algún sistema operativo con stack TCP/IP, Nmap va a andar en él.

De hecho es tan famoso que apareció en varias películas^[3]. Por ejemplo Matrix, donde lo usó la mismísima Trinity en la famosa escena en que “hackea” la central eléctrica aprovechando una conocida vulnerabilidad de SSHv1 que detectó usando Nmap -justamente va a ser nuestro primer ejemplo de uso-.

Conceptos básicos de la comunicación TCP/IP

Hace falta entender bien claro las funcionalidades básicas de TCP/IP porque Nmap se aprovecha de ellas. Así que se van a tener que fumar un buen pedazo de explicación de todo esto. Voy a asumir que no tienen la más mínima idea de cómo trabaja el protocolo TCP/IP. Los que ya lo conozcan, pueden saltarse esta parte que es un garrón porque voy a explicar muchas nociones básicas con el lenguaje más simple posible para que queden bien claros, y pasar derecho al título Nmap, un trabajador organizado.

En este artículo, más de una vez voy a hacer referencia a unos documentos que se llaman R.F.C. (Request for Comments). Estos documentos son como las leyes que definen Internet. Actualmente los publica y aprueba una organización que se llama Internet Engineering Task Force (I.E.T.F.) fundada en 1986, pero los RFC aparecieron realmente en 1969 como parte del famoso proyecto A.R.P.A.N.E.T. (The Advanced Research Projects Agency Network). Estos documentos describen con un lenguaje claro y exacto los métodos, comportamientos, investigaciones, o innovaciones que pueda aplicar a Internet y sistemas conectados a Internet. Por eso decía que son como las leyes, pero son algo un poco más ámplio, digamos, y menos estricto -no se impone a la fuerza-, es más bien una recomendación. Inclusive, existe el RFC 2119 que define una serie de términos comunes y el lenguaje con que deben redactarse los mismos RFC. Bueno el tema es que voy a andar por ahí diciendo RFC, cada tanto, y quería explicar qué son.

Un dato curioso de los RFC. El 1 de abril de 1990 se publicó el RCF 1149, titulado IP over Avian Carriers (IPoAC)^[4], es decir IP sobre palomas mensajeras. Define  la transmisión de datagramas del protocolo IP, entre computadoras, mediante palomas mensajeras como medio físico. El 1 de abril de 1999 se publicó el RFC 2549, una extensión de la anterior denominada IP sobre palomas mensajeras con calidad de servicio. Obviamente fue una broma porque el primero de abril en muchas partes del mundo, como EE.UU., se celebra el April’s Fool Day (día de los inocentes), y a la gente de la IETF le gusta publicar RFC graciosos y ridículos como este. Lo que tiene en particular el IPoAC es que en 2001 un grupo de noruegos locos lo puso en práctica^[5], aunque solo para hacer un ping. Wikipedia mantiene una lista completa^[6] de los RFC publicados para los April Fool’s Day, que hasta ahora es las más competa que encontré.

Naveguemos la web

En Internet cada vez que abrimos una página web con el navegador (Internet Explorer, Firefox, Chrome, Opera, etc), estamos iniciando una conexión a otro equipo. En este caso, este otro equipo es un servidor web, que es, sin entrar en mayor detalle, una computadora conectada a Internet que tiene como función principal brindar el servicio de mostrarnos una página web. Es un equipo, o host, remoto, que es como vamos a denominar a cualquier otro equipo, que no sea el nuestro, conectado a una red. Cada vez que navegamos una página, estamos usando conexiones TCP/IP sin saberlo. Estas conexiones las realiza el navegador en conjunto con el sistema operativo, siguiendo lo establecido por un conjunto de dos protocolos: el TCP y el IP. Estos protocolos manejan la información dividiéndola en grupos de datos que se llaman datagramas. Un datagrama es la unidad de información básica que se transmite por la red. En nuestro caso, el protocolo IP usa datagramas, y el TCP usa segmentos. Como nosotros vamos a tratar conexiones TCP/IP, sin entrar en mayor detalle de terminología, los vamos a denominar indistintamente como paquetes. Así que cada vez que hablemos de un paquete nos vamos a estar refiriendo a la unidad básica de información en una comunicación TCP/IP.

Volvamos a nuestro ejemplo de navegar una página web. Cuando queremos ver una página, por ejemplo Facebook, lo que hacemos es poner la dirección de la página en la barra de dirección. Cuando hacemos esto y le damos enter, el sistema lo que hace es enviar un paquete -en realidad intervienen cuatro paquetes- a la red cuyo contenido es un pedido solicitando al servidor remoto que nos muestre la página web. Entonces el servidor remoto, para mostranos la página, nos manda una copia de la página,  que el navegador guarda temporalmente y muestra en la pantalla. Esos datos viajan todos empaquetados dentro de estos paquetes, valga la redundancia, que venimos hablando.

Para entender el concepto de paquete vamos a hacer una analogía: es como mandar una carta por correo.

¿Se acuerdan de cómo se manda una carta por correo?

Primero, la escribimos en una hoja. Después la metemos en un sobre, escribimos el remitente y el destinatario, y pegamos la estampilla. Por último, la depositamos en el buzón de correo. Así después el cartero la agarra y sabe a dónde la tiene que entregar. Un paquete es algo bastante parecido.
Un paquete tiene un contenido, denominado payload, que viene a ser la carta que queremos hacer llegar. En este ejemplo el payload es la consulta dirigida al servidor web. El sobre viene a estar representado por la cabecera IP (header), a lo que se denomina encapsulmiento. El payload está precedido por el header. Este ultimo contiene los datos de remitente y destinatario. En nuestro caso serían la dirección IP de orígen y la de destino, respectivamente.
Por lo tanto un paquete está compuesto por el header y el payload. Así es como se organiza, a alto nivel, la información en una red usando IP.

Veamos un dibujo esquemático de un paquete:

Todavía no llegamos la transmisión, solamente estamos hablando de la organización de la información a ser transmitida.

Todo bárbaro, pero…¿qué es un protocolo?

Excelente pregunta. Porque hasta acá, lo que vengo diciendo suena a que los protocolos hicieran algo por sí mismos. Pero esto no es así. Veamos la definición de protocolo que da Wikipedia^[7], que a mi entender, es muy acertada:

“En informática, un protocolo es un conjunto de reglas usadas por computadoras para comunicarse unas con otras a través de una red. Un protocolo es una regla o estándar que controla o permite la comunicación en su forma más simple, un protocolo puede ser definido como las reglas que dominan la sintaxis, semántica y sincronización de la comunicación.”

Como venía diciendo, un protocolo no hace nada, no es ningún proceso, ni es un programa de la computadora. Es un conjunto de reglas que definen cómo debe hacerse algo. En este artículo, vamos en camino de estudiar algunos de los protocolos de comunicaciones más importantes que definen la forma en que la información debe moverse en una red. El movimiento de la información la realizan programas que se ejecutan en una computadora. Estos programas siguen las reglas definidas por estos procolos. Y de esta manera todos los equipos conectados a la red pueden entenderse con las mismas reglas. Es como un idioma. Prestemos atención a la parte de la definición que dice “reglas que dominan la sintaxis, semántica y sincronización de la comunicación”. Las comunicaciones de red tienen una sintaxis. A lo mejor se acuerdan cuando estudiaban análisis sintáctico en la escuela, que identificaban componentes de una oración. Bien, con esto es lo mismo, las “oraciones” con las que se comunican las computadoras en una red tienen componentes sintácticos, por ejemplo la forma en que se ordena el paquete IP, como vimos en el esquema. También tienen una semántica, que define cómo debe interpretarse el mensaje, por ejemplo cómo interpretar la información del hader. Y una sincronización, que es como cuando conversamos con alguien: primero habla una persona, después otra, y así se entienden, porque si todos hablaran la mismo tiempo ninguno se entendería.

El protocolo IP

Al protocolo IP muchos ya lo deben conocer por sus direcciones, por jemplo: 192.168.0.1. IP es una sigla en inglés: Internet Protocol. Muchos, además, lo asocian exclusivamente con Internet. Y hacen bien. El tema es que no es algo exclusivo de Internet. Pero, para entenderlo hay que entender qué es Internet.
Muchos podrían imaginar Internet como “un inmenso océano de información que va de punta a punta del planeta” -si, suena un poco poético-. No hacen mal. Intenet es un montón de redes conectadas entre sí. Imagínense una red de computadoras como si fuera una telaraña -no apto para aracnofóbicos, aviso-, y ahora imagínenese varias telarañas enganchadas entre si formando una telaraña más grande. Eso es Internet -por eso lo del famoso “WWW” que es la sigla para World Wide Web, algo así como Gran Telaraña Mundial-.

El protocolo IP nace en 1974 como un servicio del Transmission Control Program. Más tarde tomó carácter independiente, y es hoy el “alambre” que mantiene unido a Internet -sí, Internet también literalmente está atado con alambre-. Todo comenzó en 1968 cuando DARPA (Defense Advanced Research Projects Agency) licitó un contrato para contruir el Interface Message Processor^[8] (IMP). Este dispositivo iba a ser el primer router de A.R.P.A.N.E.T. que era la red predecsora de Internet. El contrato lo ganó la empresa Bolt, Beranek and Newman (BBN), una pionera de la tecnología de esa época. El entonces Senador Ted Kennedy -hermano del ex presidente estadounidense John F. Kennedy- le envió un telegrama de agradecimiento a la empresa BBN en el cual destacaba su espíritu “ecuménico” por haber ganado el contrato para el, cito textual, “interfaith message processor“^[9]. Se ve que no fue bien asesorado en la materia. Probablemente habrá pensado que se estaba avanzando en la comunicación con Dios. Un hombre de fé, sin lugar a dudas.

Lo que hacía este aparato es interconectar diferentes redes entre sí. Fue la priemra generación de dispositivos denominados gateways, que vienen a ser los que encaminan las comunicaciones entre computadoras desde una red hacia otra. En particular el IMP venía a implementar el novedoso, para la época, método de transmisión de datos que se llama packet switching. El tema es que antes lo que había era circuit switching, que lo que hacía era establecer un canal dedicado para usar en cada comunicación. Algo así como usar un cable que fuera directamente de una computadora a otra. Solamente podía ser usado por una comunicación por vez, y solamente en una dirección. Packet switching usa también un canal de una computadora a otra, pero divide la información en paquetes que se mandan por esa conexión. De esta forma pueden haber varias comunicaciones yendo por esa misma conexión, cada una en sus propios paquetes, y los paquetes pueden tanto ir como venir por el mismo canal. Las especificaciones del IMP están definidas en el RFC1^[10].
La red ARPANET estaba diseñada para garantizar la transmisión de 1822 mensajes. Para eso usaba el protocolo 1822^[11], que también desarrolló la empresa BBN. A diferencia del protocolo IP de hoy en día que no garantiza la tansmisión, sino que para eso descansa en TCP, que lo vamos más adelante. Más tarde se usó el protocolo NCP^[12] (Network Control Program) que fue el veradero antecesor de los protocolos TCP e IP, y del resto de los protocolos de comunicaciones de redes informáticas que tenemos hoy en día.

No fue sino hasta el 1 de enero de 1983. El día que se denominó el Flag Day (día de la bandera), que es una froma de denominar a las fechas en que se hacen cambios extensos, caros, y complejos de sistemas informáticos, que vovlerlos atrás en caso de que saliera mal, sería gual de complejo y costoso. El día en que se implementó el nuevo protocolo TCP/IP en los IMP de ARPANET. Nacía Internet tal como lo conocemos.

Ya que estamos viendo un dato histórico, no quiero perder la oporunidad de ser consecuente con mi mente dispersa e irme por una tangente. Todo esto de Internet, computadoras interconectadas, la nube, y la mar en coche, que hoy todos venden como maravillas del tercer milenio existieron desde los principios de la informática, allá por los 70′. Claro que eran solo algunas computadoras, en universidades y gobiernos, pero los conceptos eran exactamente los mismos. Como un auto que siempre fueron cuatros ruedas y un motor, con el tiempo sigue siendo lo mismo solo que más eficiente. Dicho sea de paso, por ejemplo, los autos elécticos que hoy son novedad existen desde fines del Siglo XIX, y por aquel entonces eran más populares que los que funcionaban a vapor o combustión interna -estos últimos eran muy sucios y ruidosos-. Si queremos ir más allá, el primer diseño de un auto que podía haber funcionado lo creó Leonardo da Vinci en 1478 -aunque, como muchos de sus inventos, quedó solo en el diseño y jamás se construyó-. Esto mismo pasa con casi todas las cosas, y la informática no es la excepción.

Allá por 1972 esataba el sistema PLATO IV^[13]. Basicamente era como una computadora  con pantalla plana de plasma -sí, tal cual un televisor plasma de hoy en día, solo que de dos colores (ámbar y negro)-. Como si fuera poco, la pantalla era táctil, o sea que se podía usar el sistema tocando en la pantalla, tal cual las computadoras que hoy son novedad. Se le podía conectar un sintetizador de audio de 16 voces, tal cual una placa de sonido de una PC actual, ofreciendo todo un sistema multimedia. Se lo creó con fines educativos, su función original era darle herramientas a profesores de música, como ejercicios de dicatado, de teclado, entrenamiento del oído, ejemplos interactivos o laboratorios de acústica musical, y ejercicios de composición y teoría que eran respondidos inmdiatamente por el sistema. PLATO IV se conectaba a un mainframe, lo que hoy llamaríamos servidor, que le permitía que los usuarios se comuniquen mdiante mensajes almacenados en el mainframe. Se podían ejecutar programas tanto localmente, en la terminal, o ejecutarlos en el mainframe, cosa que hoy llamamoscomputación en la nube. Posteriormente se le agregron funcionalidades, sobre todo al poder interconectarse con difernetes mainframes -gracias al Interface Message Processor-.  En 1973, dio nacimiento al primer foro online, permitiendo que los usuarios se conecten entre sí y puedan comunicarse usando un sistema de mensajes online -igual a cualquier foro de internet de hoy en día-. A finales de los 70′, había miles de terminales PLATO IV conctadas a cerca de una docena de mainframes interconectados alrededor del mundo. Digno de una anacronía de ciencia ficción: computadoras multimedia, con pantallas planas de plasma táctiles, conectadas en red alrededor del mundo, foros online, cursos online, hasta juegos online, y computación en la nube, todo esto que hoy es novedad, exitía en los 70′.

Para cerrar esta idea tangente voy a remitirme a citar una frase que se popularizó en el Siglo XIX cuando la usó Sir Isaac Newton, padre de la mecánica clásica, en una de sus cartas a Robert Hooke -unos años antes de sus diferencias sobre la disputa por la paternidad de la Ley de Gravitación Universal- el 15 de Febrero de 1676, fechada originalmente como 5 de Febrero de 1675 usando el calendario Juliano que regía en esa época: “If I have seen further it is by standing on ye sholders of Giants”. En su inglés de la época, Newton, parafraseó la metáfora latina “nani gigantum humeris insidentes” atribuida a Bernardo de Chartres (en latín Bernardus Carnotensis), filósofo neoplatónico y erudito del Siglo XII, que intenta ilustrar la idea de que el desarrollo intelectual futuro se alcanza por comprender el trabajo de los pensadores del pasado.

Volviendo, como vimos antes, un protocolo es un conjunto de reglas. Bien, el protocolo IP^[14] define, entre otras, dos cosas importantes:

• Define la forma en que se identifica un equipo en una red. Esto se llama direccionamiento (addressing). Esta dirección es un número que identifica a cada equipo conectado a una red. Este número se utiliza para etiquetar cada paquete de información que se transmite de un equipo a otro por la red, para que pueda ser enrutado correctamente.

• Define la forma en que debe moverse la información en la red. Esto se llama enrutamiento de red (routing). Es decir, que define la forma en que se elige el camino, a través de una o más redes, para que los datos lleguen a donde tienen que llegar. Para esto usa las direcciones IP. No vamos a meternos más a fondo en el tema del enrutamiento, porque es un tema que rqueriría de todo un artículo aparte y no aporta mucho más a éste.

¿Vieron el diagrama del paquete IP que está más arriba? Bueno, esa estructura está definida por el protocolo IP. Cuando dije que cada paquete se etiqueta con la dirección IP me refería al header, que es la parte del paquete que contiene la IP de orígen y la de destino. Es como pegarle una etiqueta a los datos para que quien deba entregarlos sepa de dónde vienen y a dónde tiene que entregarlos.

Por ahora, eso es todo lo que necesitamos saber del protocolo IP.

El protocolo TCP

El protoclo TCP^[15] es el encargado de asegurar la tranmisión de la información en la red -ya nos vamos  acercando más a poder transmitir información en la red-. TCP es la sigla Transmission Control Protocol (protocolo de control de la transmisión, en castellano). TCP también nació en 1974, junto a IP, como parte del Transmission Control Program, y es por eso que, generalmente cuando se habla de una red que usa IP y TCP, no se habla de TCP o IP por seprado sino que genéricamente se le dice TCP/IP como una unidad indivisible. Como vimos antes, el protocolo IP se encarga exclusivamente del envío de la información. El protocolo TCP es el que se encarga de preparar y supervisar ese envío. El tema es que el trabajo definido por el protocolo TCP se realiza antes del definido por el protocolo IP. Lo que esto quiere decir es que primero se organiza la información como lo dice TCP, y después eso forma parte del payload de un paquete IP, como se ve en el diagrama más abajo. Ahora lo vamos a ver con un poco más de claridad.

TCP no maneja paquetes, sino que su unidad basica de información se llama segmento. El protocolo TCP es el que verdaderamente se encarga de ordenar la información que se va a transmitir. TCP agarra los datos y los separa en pedacitos a los que les agrega un header, parecido a lo que vimos con el protocolo IP. Eentonces un segmento podemos pensarlo como un pedacito de datos más el header TCP. El segmento TCP después es encapsulado en un paquete IP. TCP después se encarga de garantizar que cada segmento llegue a destino sin importarle mucho la parte que maneja el protocolo IP. Inclusive un mismo segmento TCP puede ser enviado más de una vez en diferentes paquetes IP, o también es común que por más que una serie de paquetes tengan el mismo destino, algunos vayan por caminos diferentes en la red (de eso se encarga IP) -puede decirse que TCP e IP trabajan en conjunto pero son idependientes-. TCP define también cómo debe reordenarse la información cuando llega a destino. Porque esos pedacitos que se envían, por sí solos, no dicen nada. TCP tiene esta tarea también, del lado del destinatario, se encarga de que la información sea rearmada sin errores.

¿Se entinde bien, hasta acá, cómo interactuan TCP e IP para ordenar los datos?

TCP prepara los datos, IP elige la ruta, y TCP, de nuevo, se encarga de que los datos lleguen.

Algunos podrían pensar que en realidad no se ordena la información sino que se desordena cuando decimos que se divide en pedacitos y cuando llegan a destino pueden llegar desordenados. Bueno, es complicado…en la práctica es muy comun que los datos viajen desordenados. Pero eso está bien, lo van a entender después.

Veamos un esquema de un paquete TCP/IP completo:

El diagrama está simplificado para dar una idea sencilla de cómo se ordena la información en un paquete. Si quieren ver un diagrama completo y exacto, con todos los detalles, vean el anexo^[16] del libro de Nmap sobre TCP.

¿Cómo hace TCP para garantizar que la información llegue sin errores?

Bueno, TCP implementa una técnica sencilla. Lo que pasa es que el envío de paquetes de un equipo a otro sin controles o métodos para confirmar la llegada, no es confiable. Por ahí si nos encontramos en una red local, con solo dos o tres equipos pueda ser, pero cuando estamos communicándonos entre varias redes, y millones de equipos, no. Y la verdad que no podemos apostar a la suerte a ver si en una de esas anda bien. Por eso es que TCP implementa una técnica que requiere de que el receptor avise que recibió bien los datos, sin imporar si se trata de una red local o Internet. Es algo así como el acuse de recibo cuando mandamos un fax. El remitente guarda un registro de cada paquete que envía, y espera el asentimiento del receptor antes de enviar otro paquete. También el remitente registra el tiempo en que se envía cada paquete, y si pasa mucho tiempo sin que el receptor dé su consentimiento, lo vuelve a transmitir. A este concentimiento, lo vamos a denominar acknowledge, por la palabra en inglés. Y es la principal característica de TCP de la que se aprovecha Nmap.

Los puertos TCP

Cuando hablamos de conexiones, en Internet o en una red local, es común también hablar de puertos^[17]. En nuestro ejemplo, de nevegar una página web, estamos usando el puerto 80, que es el puerto estándar para servidores web.

Los puertos son una particularidad del protocolo TCP. Cada cosa que se envía y recibe por Internet tiene asociado un puerto de orígen y un puerto de destino.

Y acá vamos a parar un poco y hacer una aclaración importante. Cuando hablo de puertos de orígen y destino, a lo mejor, muchos lo deben estar asociando con lugares de orígen y destino. Cosa que suena bastante lógica. Pero ese concepto está equivocado. En este caso un puerto no representa un lugar, sino un canal. Imaginemos que hay una cola de barcos que llegan a destino, a la misma costa, pero tienen cargamentos diferentes para entregar. Entonces unos van al puerto para descargar frutos, otros al puerto para descargar electrodomésticos, y así. Barbaro, ahora pensemos lo mismo pero para los paquetes que viajan por la red. Van felices por la red y llegan a donde tienen que llegar, pero van destinados a diferentes programas, aplicaciones, o procesos corriendo en esa misma computadora. Bien para eso existen los puertos, para asociar distinto contenido de paquetes con diferentes programas, aplicaciones, o procesos.

A lo largo de este artículo voy a usar las palabras programa, aplicación, y proceso como sinónimos para referirme a progrmas ejecutándose en un computadora. También voy a usar host remoto y equipo remoto, para referirme a una computadora, impresora, router, o cualuqier otro equipo conectado a una red. Aviso para que no se confundan.

Los puertos tienen asociado un número. Para los que sepan programación, este número es de tipo unsigned int de 16 bits. Esto quiere decir, en términos sencillos que todo trabajador peronista pueda entender, que es un numero que puede ir desde el 0 al 65535. Pero un puerto no es solo un número, sino que es más bien un concepto que usa el protocolo TCP para representar un canal de datos. La cosa funciona así, un proceso asocia un canal de entrada o salida de datos con un número de puerto. Ese proceso de asociación se llama binding (unión), y el producto de este proceso se llama socket^[18]. Socket, en castellano significa, literalmente, enchufe. Imaginemos que por la conexión física a la red, ya sea con un cable, WiFi, fibra óptica, o paloma mensajera, cada conexión TCP/IP fuera un cablecito diferente que va de una computadora a la otra directamente y se “enchufa” en uno de estos sockets de cada lado. Un socket es una abstracción para representar a donde está “enchufada” una conexión directa a otra computadora. No importan ahora más detalles, solo basta saber que un socket sirve para que un programa envíe y reciba datos por la red. Hasta que no se establezca una conexión, no se sabe si ese canal va a ser usado para enviar o recibir datos, esto solo lo saben los programas, que corren en diferentes computadoras, que lo van a usar para comunicarse entre sí.

Con nmap vamos a tratar de evitar el uso de sockets. Pero por ahora, para nosotros, son la unica forma de comunicación en una red.

Enfoquémonos ahora en la numeración de los puertos, que es algo importantísimo, aunque no lo parezca.

Las direcciones IP, de las que hablé anteriormente, pueden ser públicas o privadas. Una dirección IP privada es aquella que vamos a usar en una red privada, por ejemplo una LAN (local area network) en una casa, una escuela, o cualqueir otro ámbito privado de poca extensión. Por otro lado hay direcciones IP públicas. Estas direcciones públicas son únicas por cada equipo que esté conectado directamente a Internet, y no pueden repetirse. Vale aclarar que las IP privadas tampoco pueden repetirse en una misma red, pero diferentes redes privadas pueden usar las mismas direcciones IP. Ahora, los números de puerto no están tan regulados como las IP, pero a lo largo del tiempo algunos puertos fueron volviéndose estándares de facto para ciertos servicios. Los puertos son únicos solamente para el sistema operativo. Por ello es que dos procesos, ejecutándose en el mismo sistema operativo, no pueden usar un mismo puerto para comunicarse por la red al mismo tiempo. Se cae de maduro que los 65535 números de puerto posibles alcanzan y sobran. De hecho los puertos 0, 1024, y 49151 están reservados y no deben usarse. Pero la realidad páractica es que, como es algo que solo tiene importancia dentro de cada sistema, no es necesario controlar e imponer un uso estricto; está al libre albedrío del usuario, y no representa ningún problema si no se cumple.

De todas formas, es perfectamente comprensible que mantener un acuerdo de uso sería muy beneficioso. Frente a este problema de mantener un orden para que tanto las direcciones IP, como los números de puerto, y otros menesteres numéricos que tienen que ver con Internet, se creó una organización internacional que se llama I.A.N.A.^[19] (Internet Assigned Numbers Authorty) que intenta de alguna manera mantener alguna regulación sobre estos asuntos. Realmente solo aconseja respetar un uso común para mantener la interoperabilidad, sin imponerlo a la fuerza.

Para los puertos TCP, lo que nos aconseja IANA es seguir esta convención de uso de los puertos, dividiéndolos en tres categorías:

• Well Known: Estos puertos van de 0 al 1023 inclusive. Estos son considerados bien conocidos o estándar, y son números de puerto que no definió IANA. Estos son los puertos de los que hablaba al principio, que cuando empezó a usarse el Internet se fueron volviendo los más usados para ciertos servicios. Así es como IANA de alguna manera los oficializa y les da carácter de estándar. Por ejemplo el puerto 80 es el estándar de facto para el servicio www-http, que es el servicio que permite navegar páginas web.

• Registered: Estos puertos van del 1024 al 49151. Los puertos de este rango son asignados por IANA a servicios específicos cuando es solicitado mediante una solicitúd.

• Dynamic^[19] or Ephimeral: Estos van del 49152 al 65535. Los puertos de este rango se llaman dinámicos, o efímeros, porque que se utilizan por poco tiempo. Los puertos dentro de este rango no pueden registrarse para uso privado en IANA.

Ahora sí la cosa se pone divertida porque ya tenemos los datos organziados y vamos a transmitirlos.

Three Way handshake

Una conexión puede entenderse como este cuarteto:

DIRECCION IP DE ORIGEN

PUERTO DE ORIGEN

DIRECCION IP DE DESTINO

PUERTO DE DESTINO

Antes de iniciarse una conexión, tres de los componentes de ese cuarteto, siempre se conocen de antemano:

• la dirección IP de orígen.
• la dirección IP de destino.
• el puerto de destino.

Lo que no puede conocerse es el puerto de orígen, osea desde qué puerto va a iniciarse la conexión, en nuestra computadora, hasta que no lo hagamos. Puede sonar extraño o descuidado, pero tiene una razón realmente sencilla y racional. Esto es así porque el número de puerto de oríge es seleccionado por el software del sistema operativo encargado de manejar el protocolo TCP de una manera casi-impredecible. Digo casi-impredecible porque la forma para seleccionar el puerto de salida es tan simple como sumar uno al último usado. Es decir, cuando un proceso necesita abrir una conexión el sistema le va a asignar el puerto de salida inmediato siguiente al ultimo usado -el algoritmo es n+1-. Digamos que en un momento dado una conexión usó el puerto 30500, el próximo puerto a asignar será el 30501, o sea 30500+1.

Pero esto es predecible, ¿no era que es casi-imprdecible?

Sí, es teóricamente predecible. Pero veamos esto, entre el último puerto de salida que se haya usado y el momento en que va a usarse otro pudo haberse asignado uno, cinco, o diez mil otros más a otras conexiones, y pueden existir miles de conexiones en muy poquito tiempo (segundos). Esto hace imposible de predecir, en la práctica, qué puerto de salida va a ser asignado a una nueva conexión. Estosn son los dinámicos o efímeros, porque su uso dura poco y son impredecibles. No quita que también puedan utilizarse para algún servicio y, aunque es muy raro que así sea, si se hace no pasa nada porque simplemente el sistema va a ver que está en uso y lo va a saltar cuando quiera asignar puertos a nuevas conexiones.

Ahora podemos darnos cuenta de por qué los puertos no son tan estrictamente regulados como las direcciones IP. No es algo necesario, porque es imposible que se de un conflicto fuera del ámbito privado. O sea, si dos o mil computadoras usan el mismo puerto al mismo tiempo para comunicarse, no hay problemas. Porque los puertos de origen y destino son independientes. El unico problema que puede existir es el caso que dos programas quieran usar el mismo puerto al mismo tiempo en la misma computadora. Pero no es algo que afecte a alguien más, como sí sería el caso de que dos computadoras quieran usar la misma IP al mismo tiempo en la misma red.

Bien, cuando queremos comunicarnos con otro equipo de la red, es el trabajo del protocolo TCP/IP establecer la conexión. Para establecer la conexión el protocolo TCP realiza lo que sellama Three Way Handshake (saludo de tres vías), y entender esto es crucial para entender cómo funciona Nmap. Todo lo que expliqué antes, fue para poder entender esto. Así que espero que haya sido lo más claro posible. Vamos a ver…

 

 

…suponiendo que tenemos dos hosts, A y B, y que A quiere conectarse a B, así es como funciona la cosa:

• A envía un paquete incial llamado SYN indicandole a B que quiere establecer la conexión.

• Tras esto B le manda un paquete SYN/ACK a A, indicándole que recibió el pedido de abrir una conexión (que recibió el paquete SYN).

• Por último A envía un paquete ACK a B indicandole que recibió el paquete SYN/ACK.

 

Cuando termina el saludo de tres vías, el software que maneja el protocolo TCP en la computadora marca la conexión como establecida. La pasa al estado ESTABLISHED. La comunciación por esta conexión se va a permitir hasta que alguno de los dos hosts que están comunicándose envíe un paquete FIN, o un paquete RST, o bien la comunicación se termine por timeout. Cada vez que hablemos de una conexión, de ahora en más, en este artículo, estamos hablando de todo este proceso. Que sucede en una fracción de segundo, todo el tiempo, cada vez que, por ejemplo, navegamos la web, o nos conectamos al msn, etc.

Precisamente por esto se denomina a TCP como un protocolo orientado a la conexión. TCP define cómo tiene que hacerse una conexión.

¿Qué es todo esto de estado ESTABLISHED, paquetes SYN, ACK, SYN/ACK, FIN, RST, y timeout?

• La vida de una conexión TCP pasa por varios estados. Uno de estos es el estado ESTABLISHED, que significa que en ese puerto, cualfuera, hay un canal de datos en uso por el que se está enviando y recibiendo datos con otro host.

• Los paquetes FIN y RST son paquetes especiales que tienen marcado el bit de FIN o bien de RST. Como vimos antes, un paquete TCP tiene un header donde dice los puertos de orígen y destino. Bueno, eso no es lo único que hay en el hader TCP. Entre otras cosas, que por ahora no nos hace falta saber, tiene también una serie de registros de un bit que pueden estar activados cuando tienen un 1, o desactivados cuando tienen un 0. Salvo que fuera necesario, estos registros están desactivados. Dos de estos registros son FIN y RST. Cuando un host envía un paquete con el bit FIN activado, o sea en 1, le está diciendo al otro host que no tiene más datos para transmitir. Entonces se cierra la coexión y pasa a estado CLOSED (cerrado). Ahora si el paquete tiene el bit RST activado, lo que está diciendo pueden ser varias cosas. Como regla general es enviado como respuesta cuando en un puerto se recibe un paquete que no tiene nada que ver con la conexión que esté ocurriendo en ese puerto. Y lo que provoca es que se aborte la conexión que está en curso -si alguno de los hosts necesita seguir comunicándose, incia otra conexión igual y listo-. O sea, en los dos casos, la conexion se termina.

• Cuando pasa un tiempo determinado sin haber paquetes enviados ni recibidos en una conexión, esta se cierra. Esto es el timeout. La verdad, les tengo que contar, el tema del timeout es un poco más largo, pero no lo vamos a tratar más a fondo en este artículo.

• Al momento del saludo de tres vias, los dos hosts que establecen comunicación se intercambian dos números, que usa el protocolo TCP para asegurar que los datos lleguen correctamente y en orden. Este proceso se llama sincronización de números de secuencia.  Esos números van en el header TCP. Cuando el host A le manda el paquete SYN a B, ese paquete lleva en el header TCP un número elegido al azar. Después el paquete SYN/ACK, que B manda como respuesta, lleva dos números: uno es el  número que mandó A más uno, y el otro es uno elegido al azar. De ahí en adelante cada paquete que A le mande a B va a llevar un número incremental a partir del que eligió B. Y lo mismo, cada paquete que B le mande a A, va a llevar un número incremenetal a partir del que eligió A. De esta manera de cada lado pueden volverse a armar los datos que se reciben en el orden que corresponde, según estos numeros. Justamente el paquete SYN se llama así por la paabras synchronization, que siginifica sincronización. Esto es necesario porque muchas veces por congestión de la red, errores, y fragmentación IP^[21][22], los datos no llegan a destino en el mismo orden en que se envían, y deben ser reensamblarlos en destino. De todas maneras voy a volver a este tema, más adelante, para explicar el tipo de escaneo más interesnte y divertido, el IP IDle Scan, que los va a fascinar!

Bueno, listo. Hasta acá llegó el asunto del TCP/IP y la mar en coche. Ahora vamos a ver la parte divertida, sobre Nmap.

Si llegaron hasta acá habiendo leído la parte anterior, ya deben estar bastante podridos de leer. Yo estaría… Así que vayan y miren un poco la luz del Sol, si es de día, o duerman un poco si es de noche. Ahora, si se la bancan, sigan que esto se pone cada vez mejor!

Nmap, un trabajador organizado

Lo que va a hacer Nmap es en mayor o menor medida, según lo que le pidamos, tratar de averigüar qué puertos están abiertos en uno o varios hosts conectados a una red. Esa es la principal función de Nmap, fue creado para eso. Después se le fueron agregando otras funcionalidades que lo complementan, pero la tarea principal del tipo es decirnos si un puerto está abierto en un host, o no.
¿Está claro? Joya, sigamos.

Nmap, como diría el General Peron, es una demostración del poder de un trabajador organizado. Cuando queremos que Nmap escanee un host va a hacer las cosas de una manera organizada, siguiendo una serie de pasos metódicos. Lo primero, antes que nada, ver si el host este está accesible o no. El tipo no come vidrio, no va a ponerse a escanear un host al divino botón -porque, aparte, depeniendo del tipo de escaneo puede salir cualquier cosa-. Entonces lo primero que hace es revisar que efectivamente el host que queremos escanear está y no sea un producto de nuetsra imaginación lisérgica o poca habilidad con el teclado numérico. A esta verificación se la llama Host Discovery (descubrimiento de equipos).

Host Discovery

¿Cómo hace para encontrar computadoras en una red?

¿Qué tema, no? Porque parece algo bastante simple, pero no tienen ni idea de cómo se hace. Por ahí a esta altura, después de haber leído todo lo anterior se den cuenta que para esto va a usar la dirección IP. Los que más o menos conocen, se imaginarán que Nmap para saber si una IP está activa puede enviar un simple ping y listo. NO, la verdad ese método no es el más recomendable. En una red local un ping es lento, y si estamos buscando equipos en internet el protocolo ICMP (el protocolo del famoso ping) puede estar filtrado por firewalls. Así que Nmap se maneja de otra manera para evitar problemas y cumplir su objetivo.

Nmap ofrece unas cuantas técnicas para encontrar hosts en una red, y el usuario puede utilizar la que le parezca mejor para el entorno en el que se encuentra. No voy a explicarlas todas, solamente las que va a usar Nmap si no se especifica ninguna. Para esto, se fija por la dirección IP si se trata de una pública o una privada, y elige qué hacer.

Cuando queremos escanear un host, a Nmap le tenemos que decir la dirección IP del host. Y sí, si no, ¿cómo va a saber qué queremos que haga? Entocnes, si detecta que la IP es pública, o sea que queremos escanear un host en Internet, lo primero que va a hacer Nmap es mandar un ICMP echo request (ping), un paquete SYN al puerto 443, un paquete ACK al puerto 80, y un ICMP timestamp request. Así en un ráfaga tipo AK-47 de paquetes. Si el usuario no tiene privilegios de root, se jode, y solo va a mandar un paquete SYN al puerto 80 y otro al 443. Esto pasa así, no porque Nmap discrimina al usuario común, sino porque así funcionan los sistemas operativos basados en UNIX, como Linux. Pasa que mandando un paquete ACK sin estar haciendo un saludo de tres vias o tener una conexión establecida, estamos dejando de cumplir con el protocolo TCP, y para eso hay que ser Chuck Norris y puentear al sistema operativo. Porque el manejo del protocolo TCP lo hace el componenete principal del sistema, que se llama Kernel. Y para decirle al Kernel que nos deje a nostros encargarnos de una de sus funciones tenemos que tener los permisos más altos. En sistemas Windows es casi lo mismo.

Con esto de ping, protocolo ICMP, ICMP echo request, ICMP timestamp request, y la gan siete, ya bastante los volví a marear.  Sí, vamos a ver más protocolos. Van a ver protocolos hasta en la sopa. Y si no les gusta, el fondo de pantalla está a un click de distancia

A partir de acá todo empieza a ser más complicado e inexacto. Así es la vida…

Como ya vimos, para asegurase que un host está en la red Nmap le manda un paquete SYN al puerto 443, un paquete ACK al puerto 80, y un ICMP timestamp request. Veamos de qué se tata todo esto, y por qué los hace.

Nmap usa el protocolo ICMP. El nombres es la sigla Internet Control Message Protocol (Protocolo de Mensajes de Control de Internet), que junto a IP y TCP es parte del grupo elite de protocolos que se llama Internet Protocol Suite (Suite de Protocolos de Internet). Es un protocolo que auxilia a TCP e IP. Por regla general este protocolo se usa para dar mensajes de error. Digamos cuando en una conexión hay un problema con TCP/IP, es el protocolo ICMP el que se usa para diagnosticar problemas y avisar de problemas. Para esto, ICMP define una serie de “mensajes” que va a mandar cualqueira de los hosts que se estén comunicando, para informarle al otro de un problema, o para diagnosticar un problema. Los mensajes ICMP van encapsulados en un paquete IP, igual que los segmentos TCP.

• ICMP Echo Request: este es el responsable del famoso ping. Los que sepan algo básico de redes, seguro se cansaron de usar el ping para ver si una computadora en la red estaba bien conectada. Echo Request, en castellano significa pedido de eco. O sea esto es como el eco. ¿Vieron que cuando estamos en un lugar abierto o habitaciones vacías a veces se escucha el eco? Que es el sonido que rebota en algun lado y vuelve a nuestros oidos. Bueno, esto es algo así también. Una computadora manda un echo request a otra, y esta otra le devuelve un Echo Reply como reapuesta. Este echo reply es la respuesta al echo request. Y así la computadora que mandó el echo request sabe que la otra está conectada a la red y puede llegar a ella.

• ICMP Timestamp Request:  es un tipo de mensaje, que permite que dos computadoras sincronizen la hora por la red. Sin entrar en más detalle, el contenido de este tipo de paquetes es, generalmente, un número de 32 bits que representa la cantidad de milisegundos pasados desde la medianoche en la zona horaria UTC. Una computadora manda un timestamp request, y la otra responde un Timestamp Reply como respuesta. Es como que una le dice a la otra: che, yo tengo esta hora, y la otra le dice: capo, yo tengo esta hora, vos fijate, y así la que mandó el timestamp request puede usar esa hora que le respondió la otra para ajustar su reloj.

Como se podrán dar cuanta las dos cosas necesitan que el otro host responda algo. Si lo hace, Nmap ya sabe que está conectada y que es alcanzable.

Volviendo, más o menos lo mismo pasa con el paquete SYN al puerto 443, y el paquete ACK al puerto 80. Pasa que es muy común que esten deshabilitados, o bloqueados los mensajes ICMP, sobre todo en Internet, por razones de seguridad. Entonces a veces hace falta algo menos sospechoso.

• Paquete SYN al puerto 443: Como vimos antes, cuando dos computadoras se quieren conectar, hacen el saludo de tres vías, que empieza con un paquete SYN. Bueno, Nmap agarra y le manda un SYN al puerto 443 del host remoto, y si responde un SYN/ACK, listo, ya sabe que el host es alcanzable.

• Paquete ACK al puerto 80:  Más o menos lo mismo que el otro, pero con una vuelta de tuerca. Volviendo al saludo de tres vías -por eso dije que eran TAN importante-, el paquete ACK es el ultimo que se envía para cerrar el saludo. Bueno si un host recibe un ACK antes de tiempo, agarra y responde un paquete RST para avisar que eso no esta bien. Es como si alguien le entra a hablar de la nada  a alguien más y este otro le responde: qué te pasa flaco? me entrate a habalr de la nada. Pero es apropósito, a Nmap con el RST le alcanza y sobra para saber que el otro host es alcanzable.

Sí, al principio les dije que un ping no servía porque es muy lento. Y ahora, de pronto salgo con que Nmap lo usa. Bueno es complicado y cuando las cosas se pongan compicadas sigan la regla número uno: no crean nada de lo que les digo…por lo menos no al principio.

Ahora, si Nmap detecta que estamos escaneando un equipo dentro de la red local, es decir una dirección IP del mismo rango privado que el propio, el tipo va a agarrar y usar otra técnica mucho más rápida: ARP Scan. Y ahora, para que se sigan entreteniendo, vamos a ver otro protocolo muy importante.

El protocolo ARP

El protocolo ARP, es el que se usa para saber qué computadora de una red tiene determinada dirección IP. Porque, claro, tenemos una direción IP, macanudo, pero ¿qué hacemos con una dirección IP? Así sola es como si yo dijera Rivadavia al 4525. Puede ser en Capital, en San Martín, o en el Chaco. Suponiendo que nos dicen que es Capital, igual no sabemos qué casa o edificio es. ¿Qué hacemos? Vamos a Rivadavia al 4500 y vamos buscando el 4525. Ahora ¿si ninguna casa tuviera la altura a la vista? Al horno, ¿vamos por Rivadavia tocando el timbre de todas las casas a ver cuál es?. Suena una locura pero, sí, esto es casi literalmente para lo que sirve el protocolo ARP. Se le pregunta a todas las computadoras de la red quién tiene la dirección IP, por ejemplo 192.168.1.1. La forma en que se hace esto, está definida por el protocolo ARP.
Seguro en algún momento habrán escuchado hablar de las direcciones MAC, bueno este protocolo usa estas direcciones. Bueno, estas direcciones son un poco más dificil de acordárselas que las IP porque es un chorizo de letras y números bastante pesado. En términos técnicos son doce números hexadecimales. El sistema hexadecimal usa números del 0 al 9 y letras de la A a la F, y las letras serían números también. Por ejemplo 00:eb:24:b2:05:ac es una dirección MAC. Cada dos números va separado por dos puntos. Estas direcciones vienen de fábrica en cada placa de red, no importa si es Ethernet o WiFi, son únicas por cada placa de red. Así que, está claro como el agua que también son únicas por cada computadora. Y estas sí que son únicas, a diferencia que las direcciones IP que pueden cambiar. Por eso el protocolo ARP las usa como punto de partida.

Acá les dejo un dibujo de cómo una computadora averigua qué otra computadora tiene una determinada dirección IP.

Como podrán ver en este esquema la cosa es así, usando otra analogía: supongamos que estamos en una fiesta de japoneses, está lleno de japoneses, dandole al champagne,a la birra, y comiendo. No es racismo, pero son todos más o menos aprecidos, vieron, y nos dijeron “andá y hablá con Pepe el japonés”. O sea, SON TODOS JAPONESES. ¿Cómo sabemos cuál es Pepe? ¿Qué hacemos? Simple, vamos y preguntamos a todos: ¿Quién es Pepe? Eventualmente Pepe va a responder “soy yo”. Listo, vamos y hablamos con Pepe, le preguntamos por qué le dicen Pepe -que siendo japonés, sería un muy buena pregunta para hacerle-, o lo que sea.

Bueno, en una red local es lo mismo. Una PC con IP 192.168.0.101 necesita comunicarse con la IP 192.168.0.1, pero no sabe cuál de todas las PC en al red es. Entonces manda una consulta ARP preguntando: ¿Quién es 192.168.0.1?, pero la manda a la dirección MAC de broadcast 00:00:00:00:00:00, o sea todo en cero, que lo que hace es que le llegue a todas las PC conectadas a esa red local. Las PC que no sean 192.168.0.1 van a ignorar la pregunta, y 192.168.0.1 va a responderle a 192.168.0.101: Yo soy 192.168.0.1. Y listo, ya pueden comunicarse.

Un dato importante y que no es algo que la gente se de cuenta sola es que en las computadoras en redes informáticas se manejan por una especie de honor de caballeros. Por eso es posible esto de usar direcciones de breoadcast, que es una dirección que se usa como destino para que le llegue un paquete a todos. Estas direcciones existen en IP también. Por ejemplo acá en el rotocolo ARP, se manda la pregunta a todos, y solo el que corresponde va a responder. No es como las cosas funcionen entre las personas, lamentablemente.

Entonces Nmap, cuando manda un paquete, como por ejemplo un ping, el sistema operativo tiene que averiguar la dirección MAC que le corresponde a la IP de destino del paquete (consulta ARP). Y la verdad que si estamos escaneando muchos equipos (toda una red, o gran parte) vuelve todo lento, justamente porque los sistemas operativos no están pensados con la expectativa de necesitar hacer millones de consultas ARP en poquito tiempo. Entonces para esto Nmap toma la posta y se encarga él mismo. En lugar de las rutinas del sitema operativo, el tipo maneja directamente las consultas ARP, para hacer más rápido. Manda una por cada dirección IP. Entonces si recibe una respuesta de un host, Nmap ni se calienta por mandar los paquetes ICMP, SYN, ni ACK, que van por TCP/IP, porque ya sabe que ese host está activo sin lugar a ninguna duda. Por eso la prueba por ARP es mucho más rápida y confiable que las basadas en ICMP e IP.

 

¿Cómo encuentra puertos abiertos Nmap?

De nuevo, Nmap tiene varios métodos. Voy a explicar detalladamente los dos escaneos más básicos que hay: TCP Scan y SYN Stealth Scan. Y como soy muy copado también voy a explicar el tipo de escaneo más divertido de todos: TCP Idle Scan. Con ejemplos y todo.

Estados de un puerto

Si no le decimos a Nmap qué puertos queremos saber si estaán abiertos, va a probar 1000 puertos TCP. Y a diferencia de la mayoría de los escaner de puertos, Nmap, no solamente va a decirnos si un puerto está abierto o cerrado. Nmap entiende seis estados. Estos estados no son una propiedad intrínseca de un puerto, o sea, no es algo questé escrito en algún protocolo ni nada. Es algo propio de Nmap, son la forma en que Nmap ve un puerto. Por ejemplo, un escaneo a una computadora en una misma red puede mostrar el puerto 135 abierto, cuando el mismo escaneo hecho al mismo tiempo pero desde Internet (suponiendo que esta computadora tiene acceso a Internet) puede detectarlo como filtrado. Es decir, el puerto en cuestión puede verse de manera diferente dependiendo desde donde estamos haciendo el escaneo.
Entonces, Nmap usa estos estados para decirnos lo que encuentra.

• open (abierto): Un aplicación está aceptando conexiones activamente.

• closed (cerrado): Un puerto cerrado es accesible. Es decir, recibe y reponde a los paquetes que envía Nmap. Pero no hay ningun programa “escuchando” (recibiendo conexiones). Si bien no sirven para acceder a ningún servicio, nos sirven para saber si determinada IP está activa. Por lo general es recomendable que si un puerto no está en uso se bloquee usando un firewall.

• filtered (filtrado): Nmap no puede determinar si el puerto está abierto porque algún filtrado de paquetes está evitando que los paquetes enviado lleguen al puerto. esto fuerza a Nmap a que reintente varias veces probar ese puerto por las dudas de que los pauetes no estén llegando por congestión de la red, por tanto ralentiza muchísimo el escaneo.

• unfiltered (no filtrado): El estado no-filtrado significa que el puerto es accesible, pero Nmap no puede determinar si está abierto o cerrado.

• open|filtered (abierto|filtrado): Nmap asigna este estado a un puerto cuando le es imposible determinar si está abierto o filtrado. Esto pasa en escaneos donde un puerto abierto no devuelve ningún paquete de respuesta. Solo los métodos de escaneo UDP, IP protocol, FIN, NULL, y Xmas clasifican puertos de esta forma.

• closed|filtered (cerrado|filtrado): Este estado se usa cuando Nmap no puede determinar si un puerto está cerrado o filtrado. Solamente se usa para el escaneo de tipo IP IDle Scan.

Listo, ya vimos todo lo que hace falta para poder entender el funcionamiento de los escaneos de Nmap. Si algo no quedó claro, lo vuelven a leer, y listo el pollo.

Métodos básicos de escaneo

Como dije antes, voy a empezar explicando los métodos más básicos de escaneo de puertos. ¡Igual acá sí agárrense que se viene el viaje!

TCP connect() Scan.

Este tipo de escaneo se debe su nombre a que al programar sockets en UNIX se llama a una función llamada connect() para iniciar una conexión TCP a un host remoto. Por este método, para detectar si un puerto está abierto Nmap va a intentar conectarse a cada puerto, de uno por vez, y registrar si la conexión fue satisfactoria o no. Los puertos donde la conexión fue satisfactoria los va marcar como abiertos “OPEN” y los demás se los considera cerrados “CLOSED”. Este método de escaneo es muy efectivo y da una clara imágen de los puertos que pueden accederse y los que no. Porque si nmap pudo conectarse con un puerto determinado eso significa sin lugar a dudas que ese puerto está abierto y atendiendo conexiones. Pero este método no es el más aconcejable siempre. Por un lado es más lento, porque hay que esperar a que se complete totalmente el saludo de tres vías para saber si un puerto está abierto o cerrado. Por otro, y muy importante, es más fácil de que alguien se avive. Un firewall o un sistema de detección de intrusos que exista del lado del host que estemos escaneando, va registrar todas las conexiones que hacemos cuando escaneamos y probablemente diparar una alerta. Además, la mayoría de los servidores guardan un registro de las conexiones y las direcciones IP de orígen, así que sería MUY fácil detectar de dónde viene el potencial ataque.

¿Qué? ¿Ataque? ¿Qué pasó?

Bueno, seamos honestos, un escaneo de puertos no es algo que uno haga porque sí. Por lo gneral se lo considera un ataque. Porque es como ir a una casa y probar de abrir la puerta. Es raro que alguien quiera hacerlo solo porque sí. Lo más probable es que el que esté adentro piense que le quieren entrar a desvalijar la casa. Es corta la bocha, salvo que seas un profesional de la seguridad informática, si estás usando Nmap estás en la piel de un criminal. Que lo uses para ver si tus equipos son seguros, o para aprender, son casos aparte.

Ejemplo de este escaneo:

christo@Drusilla:~$ nmap 10.0.0.2 Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-27 02:16 ART Interesting ports on 10.0.0.2: Not shown: 997 closed ports PORT STATE SERVICE 21/tcp open ftp 23/tcp open telnet 80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 6.58 seconds christo@Drusilla:~$

Ese es un escaneo a mi modem/router Arnet. Acá Nmap está mostrando que descubrió los puertos, 21, 23, y 80 abiertos. En la priemr columna muestra número de puerto/protocolo, en la del medio el estado, y en la de la izquierda el servicio que atiende en ese puerto, según el listado que vimos que establece IANA, aunque en realidad podría haber cualquier otra cosa en ese puerto.

No hay mucho más que agregar a este método, pasemos al siguiente que es mucho más interesante.

 

Salvando a la humanidad

Los que no vieron la trilogia de Matrix, paren acá, vayan, y véanla. COMPLETA. Después pueden seguir leyendo.

Resulta que la ciudad subterránea de humanos libres (Zion) estaba siendo atacada por miles de sentinelas. Lo unico que puede salvarlos es desactivar el sistema de energía eléctrica de emergencia que alimenta 27 cuadras de la matrix, en menos de cinco minutos. Un equipo ya lo intentó antes y los hiceron boleta. Ahora es Trinty la que lo va intentar. En momentos sombríos de la vida, como este, cuando toda esperanza parece escaparse como arena entre los dedos, ¿a qué recurrimos desesperadamente? ¡A Nmap, obviamente! Pero todavía no.

Tiene que pasar la seguridad perimetral, que en la mayoría de las redes son firewalls y sistemas de detección de intrusos (Intrussion Detection System, IDS). Trinity la tiene clara, es experta en técnicas para saltarse estos dispositivos. Lamentablemente, los administradores de los sistemas de la planta de energía, claramente, no iban a conectar un sistema tan crítico a Internet, ni siquiera indirectamente. Así que ningún tipo de técnica por esotérica que fuera la iba a ayudar a superar la falta de conexión. Trinity piensa rápido y se le ocurre un plan genial que básicamente consiste en saltar del techo de un edificio vecino en moto, aterrizar en el techo de la planta de nergía y hacer boleta a los guardias de seguridad. Si bien esta técnica tan avanzada no la vamos a encontrar en ningún manual de seguridad informática, Trinity demostró que es altamente efectiva. Esto nos muestra la viveza con que los hackers investigan e inventan sus propias técnicas de ataque, en vez recurir a esos exploits enlatados de script-kiddies inscípidos y patéticos.
Así es como Trinity ejecuta su plan a la perfección, les da salsa a los guardias y llega a la sala donde están las computadoras. Se sienta en la terminal, y rápidamente se da cuenta que la red usa direcciones IP privadas del rango 10.0.0.0/8. Un ping a la dirección de red le devuelve respuestas de docenas de computadoras -un Ping Scan con Nmap podría haberle devuelto mejor información sobre las computadoras conectadas a la red, pero usando la técnica del broadcast le ahorró preciados segundos-. Sin perder tiempo, ahora sí usa Nmap. La terminal que está usando tiene instalada la versión 2.54BETA25. Esta versión es arcáica (del 2001) y mucho menos eficiente que versiones más nuevas, pero bueno ahí no tenía tiempo para ponerse a instalar una versión nueva. Igual este laburo no va a llevar mucho tiempo, así que no importa la eficiencia. Trinity corre el comando nmap -v -sS -O 10.2.1.3. Esto lanza un TCP SYN Scan con detección de sistema operativo contra la IP 10.2.1.3 y devuelve un informe bien descriptivo. Bueno, según Nmap, el host parece tener serios problemas de seguridad -sistema operativo AIX 3.2, con cerca de una docena de puertos abiertos-. Lamentablemente, esa no es la computadora que ella necesita. Así que corre el mismo comando pero esta vez contra la IP 10.2.2.2. Esta vez no se pudo reconocer el sistema operativo (si tan solo hubiera actualizado Nmap!) y solo tiene abierto el puerto 22. Ese puerto es del servicio SSH (Secure Shell) para administrar remotamente por un canal encriptado. Como toda diosa hacker sexy en ropa de cuero ajustado bien sabe, muchos servidores SSH de aquel entonces (2001) tienen una vulnerabilidad conocida en las funciones del CRC32 compensation attack detector. Ahí nomás Triniti saca de la galera un exploit de puro assembler, y lo usa para cambiar la password de root de ese server, le puso: Z10N0101 -sabemos que Trinity usa password mucho más seguras, en otras sircuntancias, claro-. Entonces se logea al server como root, y tira un comando que deshabilita el sistema de energía de emergencia de esas 27 cuadras justo a tiempo! Todo gracias a Nmap!

Ahora veamos cómo funciona este tipo de escaneo que salvó a Zion.

TCP Stealth Scan (TCP SYN Scan)

Este es el método de escaneo más popular, y es el que va a usar Nmap si lo corremos como root y sin especificarle ningún método. Esto es por muy buenas razones: es muy rápido, escaneando milles de puertos por segundo, y es relativamente discreto y sigiloso. Porque no completa una conexión TCP. Momento, ¿cómo que no completa una conexión TCP?¿Y cómo hace para saber si un puerto está abierto sin conectarse? No se la veían venir esta, ¿no?
Esta es la parte interesante. Para poder entender esto es que antes quería dejar bien claro el funcionamiento del protocolo TCP y el saludo de res vías…ya se van imaginando por dónde viene la mano. Como vimos antes, cuando queremos conectarnos a un puerto en un host remoto inicamos una conexión TCP y completamos el saludo de tres vías. Que consiste en mandar un SYN, recibir un SYN/ACK, y devolver un ACK. Bien, esta técnica le hace como un “osooo” al host remoto, es decir, no completa el saludo de tres vias.
¿Cómo, no era que el protocolo TCP dice que hay que completar el saludo de tres vías, que hay que cumplirlo a rajatabla para poder comunicarse en una red? Bueno, entendamos algo, acá no queremos coenctarnos a leer el clarín, queremso escanear puertos. Y la verdad que el protocolo TCP no vino en las tablas que Moisés bajó del monte Sinaí.
A esta técnica, se la denomina half-open scanning, algo así como escaneo semi-abierto, porque no abre una conexión TCP completa. Nmap envía un paquete SYN, como si se quisiera abrir una conexión normal, y espera una respuesta. Si recibe un SYN/ACK significa que en ese puerto hay una aplicación escuchando (abierto). Listo acá se terminó la joda, el puerto está abierto, no manda más nada. Si recibe un paquete RST significa que el puerto no tiene una aplicación escuchando (cerrado). En este caso también, acá se treminá la charla. Ahora si no se recibe ninguna respuesta, se considera al puerto como filtrado, y tampoco se hace más nada. Se sigue adelante con lo que siga. Claramente, nunca se completó el saludo de tres vías. Debería haberse enviado un paquete ACK después de recibir el SYN/ACK, pero no se hace porque no hace falta. Y de esta manera no quedan huellas del intento de conexión del lado de la aplicación que esté escuchando en los puertos que se prueban. La aplicación que estuviera escuchando en determinado puerto que estemos probando jamás se entera porque es el sistema operativo el que recibe el pedido de conexión, y al no completar el saludo, la conexión realmente nunca existió y es simplemente descartado por el sistema antes de informarle al proceso sobre la fallida conexión. Además de esta forma se acelera el proceso de escaneo evitando mandar un paquete por puerto.
También se marca el puerto como filtrado si en respuesta al paquete SYN se recibe un paquete ICMP (type 3, code 1, 2, 3, 9, 10, ó 13). Y como abierto si se recibe un paquete SYN (sin el ACK) como respuesta. Este ultimo caso pasa cuando la computadora que estamos escaneando está en una red que usa una característica muy rara y oscura del protocolo TCP, que casi no se usa, conocida como saludo simultaneamente abierto o dividido^[23] (simultaneous open or split handshake connection). Lo comento como para explicar bien todo lo que hace Nmap.

Ejemplo de este escaneo:

root@Drusilla:~# nmap -sS 192.168.1.1 Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-27 02:24 ART Interesting ports on 192.168.1.1: Not shown: 998 closed ports PORT STATE SERVICE 80/tcp open http 113/tcp filtered auth MAC Address: 68:7F:74:76:9A:5C (Unknown) Nmap done: 1 IP address (1 host up) scanned in 7.51 seconds root@Drusilla:~#

Este escaneo fue contra mi router WiFi. Como está en la misma red local también muestra la dirección MAC.

Para ejecutar este escaneo hay que correr nmap con el modificador -sS sin otro parámetro más que la dirección IP.

Bueno, esos fueron los dos tipos de escaneo básicos de Nmap.

Métodos avanzados de escaneo.

Xmas Tree Scans [-sF, -sN, -sX]

Hoy en día la mayoría de los firewalls e IDS ya no comen vidrio. El SYN Scan existe hace rato, y estos tipos ya saben cómo detectarlo. A ver, el tipo ve los paquetes que van a cada computadora, entonces si ve que hay muchos saludos de tres vías cortados, por decirlo de alguna forma, se aviva que es un SYN Scan. Entonces hay que rebuscárselas de otra forma. Ahí es donde aparecen estos escaneos más rebuscados.
Cada uno de estos, así como el SYN Scan, debe su nombre a los flags del header TCP. ¿Se acuerdan que lo vimos cuando estudiamos el protocolo TCP?
Bien, estos tres escaneos comparten una idea básica y común, por eso puede englobárselos dentro de una misma categoría. A diferencia del TCP Scan y el SYN Scan, estos no usan conexiones ni conexiones incompletas. Acá se trata de mandar paquetes que no deberían existir, que no cumplen con el protocolo TCP, y ver cómo responde el host que se está escaneando.

Los tres se basan en estos dos posibles casos:

• Un puerto cerrado va a responder con un paquete RST siempre.
• Un puerto abierto nunca va a responder nada.

El primer punto, es el comportamiento de toda la vida, que ya vimos antes. Si un puerto está cerrado, siempre va a reponder a cualqueir paquete que se le mande, con un RST. Sin mucha vuelta, esto es aporque así lo dice el protocolo TCP, cuando un puerto está cerrado, responde un RST y punto.
El segundo punto también es algo normal. Un puerto abierto siempre está esperando recibir un paquete SYN, no otra cosa. Porque así funcionan las coenxiones TCP, como vimos antes. Primero se manda un paquete SYN y así empieza el saludo de tres vias para conectarse.

Veamos ahora cada uno de los tres escaneos en detalle para entender mejor.

FIN Scan

Este escaneo manda un paquete con el flag FIN. Que es un paquete TCP/IP que tiene activado el flag FIN en el header TCP. Por lo general este paquete se envía para temrinar una conexión y significa que el host que está nviando datos ya no tiene más nada para enviar. Entonces si un host lo recibe de la nada, sin ser parte de una conexión, va a reaccionar así como vimos arriba, o responde con un paquete RST, o lo ignora.

Null Scan

Este escaneo manda un paquete sin ningún flag. O sea que están todos los flags en 0. Es un paquete que no debería existir, no cumple ninguna función. Entonces un host que recibe esto hace lo mismo que con el paquete FIN que vimos arriba.

Xmas Tree Scan

Este escaneo manda un arbolito de navidad por la red. Porque Nmap es un tipo muy alegre y le encanta la navidad al loco -no, no, todavía no estoy desvariando-. Este escaneo lo que hace es mandar un paquete con los flags FIN, URG, y PUSH activados. El nombre Xmas Tree, es Arbol de navidad en inglés. ¿Y qué carancho tendrá que ver un árbol de navidad con un paquete? Imagínense que cada flag del header TCP es una lucecita de un color diferente. Bueno un paquete como este tiene todas las lucecitas de distinto color prendidas, ¡es un arbolito de navidad! ¡si tuviera datos en el payload, serían los regalitos! -sí, ahora sí estoy desvariando un poquitín-.

No voy a hablar de los flags URG y PUSH porque se usan para funcionalidades bastante esotéricas y complejas del protocolo TCP que no nos sirven para esta guía. Nosotros los usamos solo para camuflarnos.

A ver el tema es así, hoy en día la mayoría de los firewalls, tanto por hardware como por sofware, ya saben que si ven una gran cantidad de paquetes SYN alguien está haciendo un escaneo de puertos. Lo que no se va a esperar nunca es ver un paquete sin ningún flag, ni uno con casi todos prendidos, y los paquetes FIN no les da importancia porque no tienen nada que ver con inciar una conexión. Entonces pasan totalmente despaercibidos por los controles de los firewalls. Es una Engaña pichanga que le hacemos al firewall para que no se de cuenta que estamos escaneando puertos.

Estos escaneos van a funcionar contra cualquier host con una implementación del protocolo TCP/IP que respete la RFC 793. Por ejemplo -y no es de extrañar-, Microsoft Windows no respeta el RFC 793, e ignora estos paquetes inclusive si el puerto está cerrado. Así que no sirve para escanear un sistema Windows. Pero si nos es posible escanearlo también con un SYN Scan y vemos puertos abiertos y cerrado, nos sirve para darnos cuenta que el host que estemos escaneando es un Windows casi con seguridad.

TCP IDle Scan.

Este escaneo es, si se hace bien, indetectable. Es virtualmente imposible que el equipo que estamos escaneando, un firewall, o un IDS se den cuenta que somos nosotros los que estamos realizando el escaneo.

Este escaneo cae dentro de un tipo de técnicas que se les dice Side Channel Attack. En otras palabras, significa aprovecharse de un camino alternativo. Algo así como entrar por una ventana abierta si la puerta está cerrada. En el caso del TCP Idle Scan, el camino alternativo no es en realidad un camino por el que vaya a enviarse o recibir paquetes. Justamente por eso es tan brillante. No hace falta ningun tipo de comunicación directa con la computadora que queremos escanear. Lo que va a hacer es provechar una característica del protocolo IP: el incremento del IP ID.

Se le vían venir, seguro. Volvamos al protocolo IP. Cuando expliqué un poco del protocolo IP, al principio de todo, no quise hablr sobre el IP ID porque los iba a comfundir un poco, y se lo iban a olvidar cuando llegaran a esta parte…si es que llegaban.

IP Identification

Como vimos antes, los paqutes tienen una cabecera. En esta cabecera hay información que se usa, como fuimos viendo, para que los equipos que los envían y reciben sepan de donde vinen, a donde van, y esas cosas que hacen que la información que llevan los paquetes llegue a donde tiene que llegar. Bueno, uno de esos datos que van en la cabecera es un numerito que sellama IP Identification, que en catellano significa Identificación de IP, y le vamos a llamar IP ID. Es un número que identifica a un paquete IP, como un número de documento que tiene cada paquete. Según establece la RFC 791, es un número de 16 bits ubicado en el header del paquete IP. Se usa para reordenar los paquetes, pero para nosotros va tener otra utilidad.
Cuando una computadora se está comunicando con otra en uan red TCP/IP, por cada paquete que manda incrementa el IP ID. Por ejemplo, supongamos que se incia una conexión y el primer paquete tiene 1 como valor del IP ID. Los paquetes que se manden después van tener como valor de IP ID: 2, 3, 4, etc. O sea que le suma uno a cada paquete. La idea es que el que los recibe, si por una se esas cosas misteriosas de la red, sobre todo en Interent que los paquetes viajan largas distancias, recibe el paquete con IP ID 456 antes del 455 pueda usar jstamente ese número para ordenarlos. Esto es por la fragmentación, que no voy a explicar del todo, pero la idea es que cuando los datos son muy grandes se mandan fragmentados en varios paquetes, y el que los recibe los vuelve a ordenar. Bueno, para eso sirve este bendito número.

Bárbaro, y mi abuelita patea calefones…

¡¿Qué tiene que ver esto con ver si un puerto está abierto?!

Tranquilos, tranquilos, que no estoy desvariando…creo…
Si bien este escaneo es el más rebuscado que tiene Nmap, no es TAAAN difícil de entender. Puede deducirse a partir de estos conceptos básicos del funcionamiento normal de una red IP:

• Una forma que ya conocemos de averiguar si un puerto está ebierto en un host remoto es mandarle un paquete SYN al puerto que queremos saber si esta abierto. Nos va a reponder con un SYN/ACK si el puerto está abierto, o un RST si el puerto está cerrado.

• Una computadora que recibe un paquete SYN/ACK inesperado siempre va a responder con un paquete RST.

• Si un host recibe un paquete RST inesperado simplemente lo va a ignorar.

• Como ya vimos, el IP ID se incrementa con cada paquete que se envía.

¿Cómo podemos aprovechar este comportamiento para saber que un puerto está abierto?
Necesitamos usar una técnica avanzada que llama IP Spoofing. Esto es mandar paquetes con una IP falsa. O sea mandamos paquetes poniendo como dirección IP de orígen una que no sea la nuestra. Es algo totalmente posible. No es algo normal, porque las repsuestas van a ir a esa IP falsa, pero técnicamente es posible. Y para nosotros va a ser de mucha utilidad. Lo que vamos a hacer es usar como dirección IP de nuestros paquetes, la de alguna otra computadora de la red. A esta otra PC que vamos a incriminar la vamos a llamar zombie, y al host que queremos escanear lo vamos a llamar víctima en el resto del artículo.

Bueno,  el TCP Idle Scan funciona así:

• Registrar el ultimo IP ID de nuestro fiel zombie: para esto Nmap le manda un paquete, y se guarda el IP ID que tiene el paquete que nos responda.

• Falsificar un paquete SYN como si proveniera del zombie y dirigirlo al puerto que queremos escanear de la víctima. Dependiendo de si el puerto de la víctima está abierto o cerrado va a provocar que el IP ID del zombie aumente o no.

• Registrar de nuevo el IP ID del zombie, de la misma manera que el primer paso. El estado del puerto de la víctima va a depender de la comparación entre el IP ID del zombie, que estamos mirando ahora y el que guardamos en el primer paso.

El IP ID del zombie debería aumentar en una o en dos unidades dependiendo del estado del puerto de la víctima.
Un aumento de una unidad quiere decir que el zombie no mandó ungún otro paquete a excepción de este útimo que le hicimos enviarnos para verificar el incremento de su IP ID. Esto significa que el puerto de la víctima no está abierto. Lo que pasó es que la víctima le mandó al zombie un paquete RST en respuesta al paquete SYN que le mandamos nosotros y no mandó más nada porque lo ingoró.
Un aumento de dos unidades significa que el zombie sí envió un paquete entre nuestra primera prueba y esta útima. Esto casi siempre quiere decir que el puerto de la víctima está abierto. Lo que pasó es que la vicitma le mandó al zombie un paquete SYN/ACK en respuesta al SYN, que le mandamos nosotros. Como el zombie en realidad no mandó el SYN a la víctima, cuando recibe el SYN/ACK le devuelve un RST. Así aumenta en dos unidades el IP ID del zombie.

Así es como podemos saber si un puerto está abierto sin mandar ningún paquete. O sea, en realidad mandamos paquetes, pero como la IP de orígen que lleva es la de otro -la del zombie-, no hay forma de que alguien sepa que nosotros tenemos algo que ver. Solomandamos dos paquetes normales ocn nustra IP, pero al zombie para ver si IP ID, no hay forma de que eso pueda ser relacionado.

¿Qué pasa si el puerto de la víctima está en estado filtrado? Y la verdad es que la diferencia del comportamiento de la comunicación entre víctima y zombie en caso de un puerto cerrado o filtrado es distinta. Pero nosotros no podemos diferenciarlo desde nuestro punto de vista. Lo que nmap va a ver es un incremento de una unidad en el IP ID del zombie, sin posibilidad de diferenciar si ese incremento fue  porque el puerto está cerrado o porque está filtrado. Nmap, en estos caso, etiqueta el puerto como closed|filtered (cerrado|filtrado).

Acá podemos ver un esquema de cada caso, cuando el puerto está abierto, cuando está cerrado, y cuando está filtrado.

 nosotros,  el zombie, y  la víctima.

  

 

 

 

Los unicos contras de este tipo de escaneo es la limitación en espectro de estados de los puertos, o sea que solo podemos saber si un puerto está abierto o cerrado|filtrado. Y por otro lado la velocidad, porque tiene que hacer un montón de cosas para detectar los puertos. El esquema que vimos arriba lo muestra de manera simplificada, pero Nmap hace un par de cositas más.

¿Cómo funciona internamente el TCP IDle Scan?

Si bien el funcionamiento de este escaneo parece bastante sencillo, como vimos hasta acá, lo que de verdad hace Nmap es muchísimo más complicado. Para acelerar el escaneo y evitar falsos positivos ejecuta varios escaneos en paralelo y repite el proceso unas cuantas veces. Por esto también es que antes dije que una contra de ste escaneo es la velocidad. Pero bueno ¿qué quieren, la chancha, los veinte y la máquina de hacer chorizos también?
Bueno para darle velocidad al escaneo, lo que hace Nmap es escanear varios puertos en paralelo en vez de ir uno por uno. Pero en el caso del TCP IDle Scan esto trae un problema, por la naturaleza indirecta de detectar el estado de un puerto. Por ejemplo si nmap escanea varios puertos en la víctima y después mira el incremento del IP ID en el zombie va a ser bastante grande, de este incremento lo unico que podemos saber es cuántos de esos puertos están abiertos, pero no cuales porque no podemos diferenciar. Igual, Nmap lo resuelve de una manera bastante elegante, usa un método que se llama búsqueda binaria. Funciona así, supongamos que Nmap escanea un grupo de puertos y ve que el IP ID del zombie se incrementó en n unidades, entonces claramente debe haber n puertos abiertos en la víctima. Barbaro, ahora para saber cuales son esos puertos usa la búsqueda binaria: separa el grupo de puertos en dos y los escanea por separado. Si el escaneo de uno de estos subgrupos no provoca incremento del IP ID del zombie, entonces los marca a todos los de ese gurpo como closed|filtered. Si el escaneo de un grupo provoca incremento del IP ID del zombie, entonces a ese grupo lo divide en otros dos subgrupos, y así sigue hasta que no pueda dividir más subgrupos y solo queden uno o más puertos individuales que estén provocando incremento del IP ID del zombie. Esos son los puertos abiertos. Hacer esto reduce considerablemente el tipo, porque si no tendría que escanearlos uno por uno y mirar el IP ID del zombie cada vez. Así solo mira el IP ID del zombie una vez por grupo y va descartando. Si escaneamos 3 puertos es lo mismo, pero si son 3000, ahí se nota la diferencia.

¿Por qué el zombie es una impresora?

El dibujo de la impresora no está porque sí. Los aparatos que se conectan a la red y no son computadoras o servidores, como por ejemplo impresoras, discos rígidos externos, televisores, etc, suelen ser los mejores candidatos para usar de zombie. Porque el software que corren para usar la red suele ser bastante simple, con implementaciones del stack TCP/IP muy básicas y descuidadas que son suceptibles a esta técnica, y aparte suelen tener muy poco tráfico. Y esto es importantísimo, porque legir un equipo para usar de zombie no es fácil. No en todas las redes va a haber impresoras y cosas así conectadas a la red. Lo importante es que se un equipo que no tenga mucho tráfico, o sea que no esté mandando y recibiendo muhos paquetes en la red, porque nostros necesitamos que durante el teimpo que duar el escaneo no se mande o reciban otros paquetes que no sean los que tienen que ver con el escaneo. Si el zombie que se elige tiene tráfico que no tenga que ver con nuestro escaneo, su IP ID se va incrementar y podría confundir a Nmap haciendo creer que encontró puertos abiertos. Supongamos que Nmap escanea 100 puertos y el incremento en el IP ID indica que hay dos puertos abiertos, entonces se divide el grupo en dos. Cuando se escaneen los dos grupos por separado, más vale que el incremento total sea dos de nuevo. Si es inconsistente, nmap se da cuenta y vuelve a escanear todo el grupo de 100 completo. También modifica el tamaño de los subgrupos y el tiempo basandose en la tasa de confiabilidad del zombie (o sea cuántas inconsistencias biene presentando). Si nmap detecta muchas inconsistencias directamente deja de escanear y nos va a pedir que busquemos un zombie mejor.

Ejemplo de este escaneo:

root@Drusilla:~# nmap -PN -p80 -sI 10.0.0.2 192.168.1.1 Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-27 02:29 ART Idle scan using zombie 10.0.0.2 (10.0.0.2:80); Class: Incremental Interesting ports on 192.168.1.1: PORT STATE SERVICE 80/tcp closed|filtered http MAC Address: 68:7F:74:76:9A:5C (Unknown) Nmap done: 1 IP address (1 host up) scanned in 1.79 seconds root@Drusilla:~#

Lindo ejemplo, es el mismo puerto que el TCP SYN Scan mostró abierto en el ejemplo anterior. El TCP Idle Scan lo muestra cerrado. Era algo que esperaba, igual. Porque usé como zombie a mi modem/router, y tengo el router WiFi configurado para que solo pueda accederse a su interfaz web (puerto 80) desde la red local, no desde Internet -se entiende que el modem/router está del lado de Internet-. Y sale como closed|filtered por lo que ya expliqué antes, no puede ser diferenciado.

Para ejecutar este escaneo hay que correr nmap con el modificador -PN y el modificador -sI con la dirección IP del zombie como parámetro.

.EOF

Referencias

[0] http://nmap.org/book/toc.html
[1] http://nmap.org/book/#purchase
[2] http://www.forouade.com.ar
[3] http://nmap.org/movies.html
[4] https://tools.ietf.org/html/rfc1149
[5] http://www.blug.linux.no/rfc1149/
[6] https://en.wikipedia.org/wiki/April_Fools%27_Day_RFC
[7] http://es.wikipedia.org/wiki/Protocolo_(inform%C3%A1tica)
[8] http://computer.howstuffworks.com/arpanet.htm/printable
[9] http://www.walthowe.com/navnet/history.html
[10] http://tools.ietf.org/html/rfc1
[11] http://www.bitsavers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf
[12] http://www.livinginternet.com/i/ii_ncp.htm
[13] http://platohistory.org/
[14] https://tools.ietf.org/html/rfc791
[15] http://www.rhyshaden.com/tcp.htm
[16] http://nmap.org/book/tcpip-ref.html
[17] http://en.wikipedia.org/wiki/Port_number
[18] https://en.wikipedia.org/wiki/Network_socket
[19]  http://www.iana.org/
[20] http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html
[21] http://www.tech-faq.com/packet-fragmentation.html
[22] http://penguin.dcs.bbk.ac.uk/academic/networks/network-layer/fragmentation/index.php
[23] http://nmap.org/misc/split-handshake.pdf

[x] Aparentemente este dato sobre Clausewitz no es del todo cierto. Desconozco completamente los motivos que habrán llevado al General Peron a esa afirmación, pero según he averigüado Clausewitz sí tuvo participación en campañas militares. Aunque sí es cierto que carecía de la experiencia que uno podría imaginar necesaria para escribir sus obras.

[y] Estoy bastante seguro que la palabra mapeador no existe. Sino que es una transliteración de mapper, de la cual tampoco estoy seguro de su existencia.
[z] La palabra portado es una transliteración de la palabra ported, que se usa cuando un programa se compila para funcionar en un lenguaje de programación o una arquitectura de computadora diferente al que fue funciona originalmente.

Share on Facebook