IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII o 07. ENTENDIENDO EL TRAFICO NFS o IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII Vamos a dedicar este articulo a algo perfectamente inutil para lo que hace falta una buena preparacion tecnica, grandes dosis de sentido comun, mucha paciencia y no tener nada mejor que hacer (algo realmente dificil a menos que seas un calamar). Hoy es el gran dia, vamos a hablar del trafico NFS (no os desmayeis por favor). Como supongo que entre nosotros habra quien no sepa lo que es NFS (incultos profesores universitarios, ancianos pastores y periodistas informaticos mayormente) diremos que es el acronimo de Network File System y ahora que esta claro pasemos a poner las manos en la masa. Se trata de un modo de integrar ficheros locales y remotos que se utiliza profusamente y en redes que van desde las pocas decenas de ordenadores a gigantescas redes con miles de ordenadores entrelazados asi que campo para experimentar no nos faltara. Para analizar trafico de un sistema de ficheros distribuido tenemos que tener acceso a la red (Ethernet mostly) y poner nuestra tarjeta en ese modo "de la cosa sesua" promiscuo que tan famoso han hecho los sniffers. Hemos quedado que los ficheros distribuidos viajan a traves de redes, por lo tanto habra que 'escuchar' a los servidores de ficheros (asombroso!) para estar al loro de sus actividades (seguramente insurgentes). Para enterarnos de algo tendremos que decodificar los paquetes de la red y extraer las operaciones NFS de bajo nivel que luego trasladaremos desde ese bajo nivel a comandos de usuario. Para lo primero se necesita un decodificador RPC y un analizador NFS para lo segundo. Una red NFS esta compuesta por servidores en los que se hallan fisicamente los ficheros distribuidos y clientes que ejecutan acciones como si los discos donde se hallan los ficheros fuesen "locales". Como de costumbre una maquina puede ser cliente, servidor o ambos. (otro concepto revolucionario) *NFS Basico* Para un usuario los ficheros NFS y locales se comportan igual, puede manejarlos igual que los locales y no tiene porque darse cuenta de que pide un fichero a otro ordenador. Capici? La manera en que se comunican un cliente y un servidor es mediante una serie de 17 instrucciones RPC (Remote Procedure Call), cada fichero y directorio esta identificado inequivocamente por un "file-handler", los ficheros se pueden leer, escribir, se pueden crear ficheros, consultar atributos y directorios... La mayor parte de operaciones son similares a la de cualquier S.O salvo que no hay implementados comandos del tipo Open/Close. *RPC en NFS* El dialogo RPC consiste en un mensaje de llamada con una serie de argumentos que el cliente pasa al servidor, este contesta entonces con un mensaje que incluye los datos requeridos, estas llamadas se transmiten mediante conexion IP/UDP. (aqui vendria un tipico diagrama pero no me siento con ganas, que estamos en verano!!!!) Como sabe el cliente a que llamada corresponde la respuesta recibida? Elemental querido tocho, el mensaje de llamada incluye un identificativo que el servidor devuelve para que el cliente pueda saber a que peticion responde. Como sabe el servidor el formato en el que enviar los datos? Como el servidor NFS suele ser bastante ignorante lo que se hace es que los datos vienen codificados en XDR para facilitar la integracion de diferentes plataformas. Una caracteristica muy llamativa de NFS es que no guarda ninguna informacion sobre los clientes y no sabe nada de lo que se hace con los archivos a excepcion de los argumentos que se le envian. *El decodificador RPC* Un decodificador de RPC producira un archivo conteniendo los principales datos de la transaccion RPC (recordemos que la transaccion se compone de dos mensajes: llamada y respuesta). Esto incluye. - Marca de tiempo - Nombre del servidor - Cliente - Tiempo de ejecucion del comando - Comando RPC ejecutado - Argumentos de comando / datos retornados Estos datos pueden ser utilizados directamente (trivial para la gente como vosotros, popes del hack hispano) o pasados a otro programa (como un analizador NFS) para que los convierta en algo mas entendible. * La marca de tiempo Tiempo en el que llega el mensaje respuesta * Nombre del servidor Nombre o IP del servidor (quien lo diria!) * Cliente Nombre o IP del cliente (guauu!) y el _usuario_ que libro el comando. * Tiempo de ejecucion del comando Tiempo en microsegundos entre el mensaje llamada y respuesta * Comando RPC La clase de comando (read, getattr...) * Argumentos/Datos retornados Argumentos con que se paso el comando y valores que se devuelven. Ha quedado claro?. Me lo temia, veamos entonces un... Ejemplo: 488987781.265508 - 9998 - cesid - lucas.nek - read - {"6b34a0087e83d", 0, 4096} - ok, 1775 Que seria una salida tipica producto de nuestro decodificador RPC. El mas listo de la clase.. si tu, el de las gafas marrones, si el del fondo!. Tu ya lo sabes verdad?. Para los menos espabilados vamos a explicarlo. Habia una vez un usuario "nek" en una maquina cliente llamada "lucas" que queria leer un archivo (comando read) de un servidor llamado "cesid". A tal efecto envio el comando NFS con los argumentos del file-handler (que identifica el fichero con una cadena hexadecimal) del inicio de lectura (en el byte 0) y de los bytes a leer (4096). Nuestro servidor respondio en 488987781.265508 (tiempo Unix claro esta) a una peticion librada "9998" microsegundos antes. El comando se ejecuto con exito "ok" y envio "1775" bytes de datos, aparte claro esta de los bytes a leer pero eso es otra historia y de ella hablaremos en otra ocasion. :-) Por ultimo recordar que segun las leyes espa€olas el decodificador tiene que ser compatible "Multicrypt" ;-) (cambiando de tercio, la parodia de Aznar, Cascos..como hermanos Marx pidiendo descodificadores Multicrypt fue genial!!!- Noticias del Gui€ol- Canal+- Algun dia de Julio del 97) *Un analizador NFS por favor* Si queremos otra forma de ver los datos obtenidos, si no estamos contentos con lo anterior, si nuestro ordenador se colapsa incapaz de procesar tanta informacion, entonces necesitas tomarte un respiro. No, perdon, entonces necesitas el arma definitiva, el analizador NFS (y seras el tipo mas guay del barrio, ni siquiera los Men in Black tienen uno) Tanto los decoders como los analizadores estan disponibles en muchos FTP dedicados a la seguridad (y no me refiero a sites hack sino a organizaciones que investigan temas de seguridad aunque en los primeros tambien los puedas hallar). En cualquiera de ambos casos un usuario anonimo no debe tener problemas para hacerse con estos u otros programas similares. Si eres incapaz de hallar uno no te preocupes, no sabrias utilizarlo aunque te lo diesen. (ohh que duro!. Pero es rigurosamente cierto.) Los datos presentados por un analizador NFS tipico son: Marca de tiempo - Tiempo transcurrido- Direccion- Identificativo fichero- Cliente- Transferencia- Tama€o. Y esto?. Pues esto es: * Marca de tiempo Lo mismo de antes, si no lo has leido vuelve a empezar el articulo * Tiempo transcurrido Todo el tiempo que nos pasamos manipulando el fichero hasta dejarlo tranquilo * Direccion Lees o escribes? (algunos comandos poseen ambas direcciones) * Identificativo fichero Aqui aparecen tanto el servidor del fichero como el file-handler del mismo * Cliente Y aqui el cliente desde el que se hace la peticion y el usuario que la hace * Transferencia Ta claro norrr?. Los bytes que viajan en la direccion que sea. * Tama€o Del fichero. (O que te pensabas?) ;> Pero ya se que hay algunos que sin un ejemplo no se enteran y todo les suena a chino, asi que dedicado a los cibertarugos (mayoritariamente miembros de la BSA y seguidores de las Spice Girls) el siguiente... Ejemplo: 786542198.999111 - 36800 - read - moncloa:5e2f00011000d00f - pp.bigotin - 0 - 76542 Y ahora fijo que ya, si que no os habeis aclarado. :-? No, que es muy facil, el usuario 'bigotin' del ordenador 'PP' lee un ficherito (con handler '5e2....') del servidor 'Moncloa', esto pasa cuando son las '78654..' (recordamos tiempo Unix) y despues de que el cliente lo pidiese '36800' microsegundos antesss. Pero seguro que el espabilado de antes y algun otro que ya le va cogiendo el truco del almendruco dice: Y el 0?. Ese 0 que pinta donde tenia que salir el numero de bytes transferidos?. Pues me alegro de que me hagais esa pregunta porque demuestra que estais muy atentos y muy interesados en culturizaros y vitamineralizaros. No habiamos dicho, lo hacemos ahora, que si el cliente lee el fichero del **cache** entonces en el campo de bytes transferidos aparece un 0 (logico porque no ha habido que transferir nada). O sea que en este caso 'bigotin' pudo leer el archivo directamente de la cache de su ordenador. LLegado este momento habra algun impaciente que exclame: Pero esto para que COJ*NES vale??? Hombre pues aparte de la cultura que aporta, puede ser interesante saber los habitos de trabajo de un departamento/usuario, se puede aprender de los usuarios viendo que ficheros leen y/o escriben, en sitios comerciales podria darnos una idea de que ficheros son importantes, en que proyectos se esta trabajando... No, si realmente inutil no es. Sobre todo porque esto que estamos viendo se puede aplicar casi directamente al trafico NIS y porque algo como la "caza de claves" (eso del sniffer que se ha puesto de moda entre los ???ers. Donde hay un sniffer?. Como funciona? Dadme uno!!) es esto mismo, la mecanica es esta asi que quiza ahora os parezca algo mas interesante el articulo. ;-) Y si leeis el articulo sobre firewalls vereis que NFS ha sido historicamente "puerta abierta" para las incursiones (glubbs!). Pero no introducazmos malvadas ideas y sigamos con el inocente? analisis del trafico NFS. De que me sirve saber que 'bigotin' lee '5e2..' no se que es eso!! Un documento secreto, un juego, una imagen porno?. Seria interesante saberlo porque sino la utilidad del analisis desciende mucho, quiero saber a que dedican mis empleados su tiempo libre, hacerme una idea de los ficheros mas usados, etc.... No desesperarse porque es posible _mapear_ los file-handlers a nombres de ficheros aunque no siempre sera un mapeado exacto dependiendo mucho de la carga del sistema y de la profusion de borrados y renombrados. Pero asi nuestro analizador NFS cambiara de decirnos que: 'bigotin' leyo el archivo '5e2f00011000d00f' a darnos un nombre descriptivo como: 'bigotin' leyo el archivo 'M0-TRK27J.~TM'. Observad la ganancia de claridad!! Hombre si tenemos esa mala suerte no nos habra servido de mucho pero si el archivo tiene un nombre descriptivo como: 'comisiones.ps' 'timo.html' 'chupona.jpg' 'aquiguardolasclavesdetodo' Pues la cosa sera algo mas interesante. Lo que produce un analizador NFS no es mas que una aproximacion a la actividad del usuario ya que como hemos dicho NFS ni guarda informacion sobre sus clientes ni implementa comandos open/close por lo que el analizador suele utilizar tecnicas heuristicas y ofrece resultados consistentes observados a nivel general. En plain ASCII, ya que NFS no guarda mucha informacion sobre sus clientes no pretendais obtener maravillas de el, tendreis que a€adir algo de sentido comun. Si os pensais dedicar al arte del analisis NFS como trabajo estable puedo aseguraros que tendreis una vida de lo mas aburrida, si vuestro objetivo es "foguearos" para saber analizar otro tipo de trafico..es cosa vuestra pero no espereis que os vaya a ver a la carcel. En cualquiera de ambos casos debeis tener en cuenta que si el volumen de trafico es alto se perderan datos, habra llamadas de las que no se obtenga la respuesta a causa de crashes, desbordamiento de buffers... Pero en fin, cosas mas inutiles se hacen. Y recordad que en la escala social del underground os colocareis justo por encima de los que envian mensajes a las news con el Subject: "Add me" o en su equivalente hispano ===> "Apuntame a mi tambien a la lista warez" Ps: Por cierto, interesan unos CD piratillas por 1.500?. Escribid a soy_un@completo.bobo para detalles. };->>