Descubrimiento Automático de Proxy Web. WPAD

Topología de redes, usos de las redes...

Moderador: Moderadores

Descubrimiento Automático de Proxy Web. WPAD

Notapor Vic_Thor » Dom Feb 10, 2008 6:04 pm

WPAD. WeB Proxy Auto-Discovery

Digamos que esto es una frivolidad para este fin de semana.... :P

¿quién no ha visto esto alguna vez?

Imagen

Pues bueno, antecedentes.... El viernes pasado por la tarde en clase me metí en ese “fregao” con mis alumnos... y funcionó pero “a medias” y eso no.... las cosas enteritas :D y prometí que funcionaría del todo, así que elaboré este manual (para ellos y cómo no... para el foro también)

WPAD es un PROTOCOLO, joer... otro más... muchas aplicaciones (entre ellas Internet Explorer) son compatibles con ello, también Firefox y otros navegadores, pero lo que llama la atención del navegador de Microsoft es que “ya viene de serie” la activación del mismo... y el servicio WinHTTP también...

¿Para qué sirve?

Pues como su nombre indica para que se detecte la presencia de un Proxy Web Automáticamente y se use el mismo a la hora de navegar por la red.

Esto que a primera vista puede ser irrelevante, curioso o simplemente desconocido por muchos, tiene como todo en la vida, sus ventajas e inconvenientes.

La ventaja es para los administradores de una red, no tienen por qué “instruir a mano” los navegadores de los puestos de trabajo uno por uno e ir configurando el Proxy web en cada puesto.

Gracias a este servicio, se puede imponer un Proxy (eso ya a elección de cada uno) en toda una red, es mas, se puede configurar de un modo mas “granular” e incluso decidir qué ip’s salen por el Proxy, cuales no, si para acceder a una determinada dirección se debe usar el Proxy, o si por el contrario no conviene o no se quiere sencillamente.

Ya sabemos lo que es un Proxy, no? Pues bueno, para los despistados y dejando a parte los tipos de proxys, etc. Digamos que es una máquina por la que pasarán todas (o parte) de las conexiones de una red a otra.

Usar un Proxy siempre tiene alguna ventaja añadida, se pueden filtrar contenidos, por ejemplo impedir que los usuarios naveguen a páginas “dudosas”, o imagina un colegio con niños en la sala de informática, pues el Proxy puede impedir que acudan a determinadas páginas que por su contenido no son adecuadas para ellos.

También en determinadas ocasiones y dependiendo del Proxy, se puede acelerar esto de la navegación por la red, puesto que los usuarios en lugar de ir directamente al sitio en cuestión, lo entrega el Proxy, eso es un Proxy caché... en fin, las bondades de los proxys son muchas y ciertamente son interesantes su uso.

Ahora bien, este servicio que viene de serie en Windows, el hecho de que el navegador ya considere que puede “auto-detectarlo” de forma automática sin más, tiene una desventaja...

¿qué pasaría si en una red se añade un “falso” Proxy?

¿qué ocurriría si ese Proxy es “aprendido” por el navegador como lo hace Internet Explorer?

¿Qué pasaría si ese Proxy es “propiedad” de un supuesto atacante?


Ya lo veis claro, verdad? Pues sí!!!! Todo el tráfico web pasaría por ese Proxy (o todo el que el “atacante” desee) y podría capturar todo eso que ya sabemos, contraseñas, claves, cookies, etc...

Todavía podemos ir más allá... un peligro mas grave... las redes inalámbricas... si ese “atacante” consiguió unirse a una red inalámbrica (no hablo ya de una red protegida, pongamos un punto de acceso libre, un hotspot público) y pone en marcha todo el artilugio que nos ocupa en este caso, resultará que aquellas personas que dispongan en su navegador esa opción habilitada, pasarán por el Proxy y por tanto por la máquina del atacante...

Como ya dije, no es sólo propio de Internet Explorer, otros navegadores también lo permiten, Fierefox en la pantalla que sigue...

Imagen

La diferencia es que no viene de serie activado....

Ya puestos en antecedentes y sabiendo al menos de que va el asunto, el objetivo final de este pequeño documento es capturar lo que nos de la gana de una ip o de una red entera que usa este protocolo.

Vamos a necesitar varias cosas:

Como poco un Proxy “propio”, un esnifer y un servidor web.

Si usamos Linux, como es el caso, también SAMBA

Si usamos Windows, nada...

Y dependiendo del “entorno” de la red vulnerable, un servidor DHCP, un servidor DNS y si ya existe eso en la red, tendremos que tirarlos abajo con alguna herramienta específica.. un martillo y un mazo es algo exagerado, jajaja... pero ya veremos,

Se van a plantear dos escenarios, uno en el que los clientes reciben una IP asignada por un servidor (DHCP) y otro en el que la IP de los clientes de red es estática.

En ambos casos suponemos que no existe DNS corporativo o si existe, no está bien configurado (como es el caso del muuuchoooos por cien de los casos) aún así, y como deferencia a mis alumnos, no explicaré ahora el método con DNS, todavía no llegamos a ese protocolo y no voy a adelantarles nada, otra vez será... una ampliación posterior.

Antes de ponernos al tajo, es IMPRESCINDIBLE, conocer cómo es posible que el navegador conozca la dirección de un Proxy automáticamente.

Según el RFC correspondiente http://www.wrec.org/Drafts/draft-cooper ... pad-00.txt esto se consigue vía DHCP y/o DNS (luego veremos que lo de Windows no tiene perdón de Dios y que no hace falta nada de eso)

Centrémonos en DHCP, cuando un cliente se “engancha” a una red y solicita una Ip, intercambian una serie de mensajes con el servidor... DHCP Discover – DHCP Offer – DHCP ACK son los habituales... pero también existen otros, como DHCP Inform que contiene alguna otra información relevante, en nuestro caso el famoso (a partir de hoy) WPAD.

Ese servidor DHCP contiene en su configuración la información típica y necesaria para entregar a los clientes:

    dirección IP
    Máscara de Subred
    Puerta de Enlace
    Servidores DNS
    Tiempo de alquiler de la IP prestada
    .....
    .....
Si ese servidor DHCP se configura, además de con todo eso, para informar al/los clientes de que existe un “Proxy para su detección automática” también se lo dirá a los clientes que soliciten esa IP.

Realmente, lo que les entrega es una dirección URL que incluye la configuración del Proxy, el puerto de conexión y las reglas de quien puede usar el Proxy, quien no, etc...

Por esto mismo necesitaremos un servidor WEB, puesto que lo primero que hará el navegador del cliente es “conectarse” a esa URL para cargar el archivo de configuración.

Hay que hacer notar que el servidor Web y el Proxy no tienen por qué ser la misma máquina, ni tan siquiera estar en la misma red, no es el caso de este ejemplo... como es un “chico malo” monta en su portátil tanto el Web Server como el Proxy, y el esnifer y toda la pesca.. pero en un entorno “seguro” no debería ser así.

Usaremos un dhcpd en Linux y Apache para solventar este asunto desde la máquina del atacante... seguro que ya estás pensando

¿Y si ya existe un DHCP “verdadero”?

Pues si lo dejamos al azar, efectivamente puede ser una lotería... igual unos se conectan mediante nuestro “rogue DHCP” y otros no... por eso, si este es el caso, antes inundaremos la red con falsas peticiones DHCP (incluso se registrarán falsas máuiqnas ante el verdadero Server) y le mantendremos entretenido...

Os recuerdo que no hay forma posible de “elegir” un servidor DHCP por parte del cliente, sencillamente el primero que responde es el que se lleva “el gato al agua”, por tanto, si la “bueno” lo mantenemos entretenido, no asignará Ip’s y lo hará el nuestro.

Ya dije antes que esto puede ser MUY grave en redes inalámbricas, porque si antes de la inundación DHCP enviamos paquetes de desautenticación a los clientes legítimamente conectados, se irán de la red y cuando vuelvan, será nuestro DHCP_Malo el que se las asigne.

Me evito comentar “paso a paso” el tema del Server DHCP, nos bastará con saber dos cosas para el caso de Linux y el que nos ocupa:

[list=]El archivo de configuración del Server está situado en /etc/dhcpd.conf

El archivo de “alquileres” de Ips, vamos las que se asignan a los clientes esta en: /var/state/dhcp/dhcpd.leases[/list]
Si queremos informar de un “posible” Proxy para ser “auto-descubierto” tenemos que añadir (al menos) dos líneas en el archivo de configuiración dhcpd.conf, estas son:

Código: Seleccionar todo
option wpad-url code 252 = text; # en la configuración global

option wpad-url = "http://dirección_del_proxy/archivo.pac" # en la configuración de la/las subredes que asigna.


Quedaría así, ,mas o menos:

Código: Seleccionar todo
ddns-update-style none;
option domain-name "Malo_DHCP";
option domain-name-servers 195.235.113.3, 195.235.96.90;
default-lease-time 600;
max-lease-time 7200;
authoritative;
option wpad-url code 252 = text;
subnet 192.168.4.0 netmask 255.255.255.0 {
   range 192.168.4.50 192.168.4.80;
   option routers 192.168.4.254;
   option broadcast-address 192.168.4.255
default-lease-time 600;
max-lease-time 7200;
option netbios-node-type 2;
option wpad-url = "http://192.168.4.66/proxy.pac ";
}


Esto asigna ip’s de la 192.168.4.50 a la 192.168.4.80, con máscara de subred 255.255.255.0, puerta de enlace 192.168.4.254, dns 195.235.113.3 y 195.235.96.90 con un tiempo de alquiler de 600 segundos por defecto y 7200 segundos máximo.

IMPORTANTE LA ÚLTIMA línea, es la dirección IP del servidor web y archivo que se cargará (proxy.pac) y MAS IMPORTANTE TODAVÍA, que después del último carácter y las comillas exista un espacio y/u otro carácter, por ejemplo esto:

Código: Seleccionar todo
option wpad-url = "http://192.168.4.66/proxy.pac\n";


El motivo es porque algunos navegadores fallan si no es así... cosas de la vida...

Recuerda que esa ip ha de ser la del servidor web, no la del Proxy, que en este ejmplo será la misma tanto para uno como para el otro, pero que no tiene por qué ser de ese modo.

Ahora tenemos que plasmar qué diántres contiene el archivo proxy.pac.

Pues es un código javascript, que en su versión más resumida e ínfima puede ser el que se muestra:

Código: Seleccionar todo
function FindProxyForUrl (url, host) {
   return "PROXY 192.168.4.66:8888";
}


Ese pequeño código informará al navegador del cliente que la dirección IP del Proxy es 192.168.4.66 y que está escuchando por el puerto 8888.

Siento ser tan repetitivo... esa IP es la misma que la del web Server, pero no tiene por qué serlo, podría ser otra máquina.

Al final del texto os pondré otras “posibilidades” del archivo .pac, como ya aventuré anteriormente, se puede decidir si unas ips usaran el Proxy o no, si unas direcciones web de Internet o de intranet se accedien mediante le Proxy o no, los puertos... etc....

También hay que reseñar otra cosa... ese archivo lo llevaremos al directorio donde el webserver guarda las páginas web, vamos al document root, si es un apache pues por ejemplo en /usr/local/apache/htdocs

Y mas cosas, hay que “enseñar” a apache o al webserver que se use para que interprete correctamente las extensiones .pac y el autodiscovery... Eso lo conseguimos añadiendo una línea del tipo AddType y/o en la configuración del Virtual Host, este es un ejemplo:

En la sección Addtype de Apache en el archivo httpd.conf añadimos:

Código: Seleccionar todo
AddType application/x-ns-proxy-autoconfig .pac


Y en VirtualHost del mismo archivo httpd.conf, añadimos:

Código: Seleccionar todo
<VirtualHost *:80>
         ServerName 192.168.4.66
         ServerAlias 192.168.4.66
         AddType application/x-ns-proxy-autoconfig .pac
</VirtualHost>


Bueno, el ultimo AddType nos lo podemos ahorrar.. pero ya que está puesto...

Y otra cosa mas... bueno, eso lo digo después...

Bien, ya tenemos todo... antes de intentar nada, vamos a ver si funcionan las cosas como deben ser:

Probando el servidor DCHP en LINUX

Verificamos que el archivo /etc/dhcpd.conf está en su sitio y con el contenido correcto:

Imagen

Creamos el archivo de “alquileres”

Imagen

Y ahora vamos a probar si un cliente cualquiera (en este caso un Windows 2003) obtiene la IP automática:

Imagen

OK

Probando Servidor Web

Verificamos como antes la ubicación de los archivos, las rutas y el contenido de la url proxy.pac

Imagen

También hacemos lo mismo con el archivo de configuración de apache y la sección VirtualHost, el Addtype y eso que ya se dijo...

Imagen


Iniciamos el servidor web y verificamos que los procesos dhcpd y httpd están corriendo:

Imagen

Comprobamos que tenemos acceso al web Server:

Imagen

Ponemos en marcha “nuestro Proxy” usaré 3proxy pero sirve cualquier otro... por supuesto a la espera de conexiones por el puerto 8888

Imagen

Desde el Windows, navegamos un rato... a google, a wadalbertia... y nuestro Proxy “lo capta” como era de esperar....

Imagen

Todo perfecto, no iba a ser menos ;)

Y si resulta que ya existiese un dhcp en la red?

Pues con las ips que ya entregó poco podemos hacer... pero para “los nuevos” podemos entretenerle, inundarle de peticiones.... usaremos un flooder que se llama dhcpx, lo deamos un ratito, con un minuto sera suficiente:

Imagen

Y si vemos la tabla de ese “verdadero” DHCP, curioso.... registros falsos por todas partes:

Imagen

Si esto lo trasladamos a una red inalámbrica, es mucho mas simple... porque si tras inundar al Server dhcp desautenticamos a los usuarios conectados, ya sabes... aireplay-ng y el ataque –0 0....., cuando se vuelven a conectar, obtendrán la IP de nuestro “maldito” dhcp y su tráfico por nuestra máquina ;)

Ahora vamos al segundo caso... aquel en el que el/los equipos de esa red tienen IP estática, por ejemplo...

    ip fija 192.168.4.222
    mascara 255.255.255.0
    puerta de enlace 192.168.4.254
    DNS públicos, 195.235.113.3 195.235.96.90
Imagen

Si lo dejamos “tal cual” no funcionará lo del Proxy, porque ese equipo “no sabe” que existe un Proxy automático de configuración... nadie se lo ha dicho, antes fue dhcp, pero al ponerle una ip “a mano”, nada de nada, se lo tendría que decir.... un DNS.

En estos casos se debe utilizar el servicio DNS, pero ni podemos, ni esa máquina lo hará puesto que los DNS son públicos...

En un entorno “normal” sería el mismo DNS quien ha de guardar la dirección del servidor web y la del Proxy... y aquí es donde caen muchos.... nadie se acuerda de esto ni de quitar lo del auto descubrimiento del Proxy en los navegadores....

Y entonces? Que? Ponemos un DNS?

Hombre es una opción, pero... si ya tienen el DNS “a mano” no podemos hacerlo.... no usarían el nuestro sino el que figura en las casillitas de arriba...

Pero en fin, Windows es como es... UTILIZA NETBIOS!!!!

NetBios es otro protocolo, propietario de los Windows, un engendro que idearon hace años Microsoft e IBM, el caso es que como el DNS no les resolverá el nombre o la IP del Proxy, lo buscarán por NetBIOS, válgame DIOS que penita....

Lo primero que tenemos que hacer es cambiarnos el nombre en la máquina Linux... por cual??? Jajaja, ni mas ni menos que por wpad ;)

Imagen

Una vez hecho esto, lanzamos de nuevo el Proxy como antes:

Imagen

(observa que ya o se llama vic_thor la máquina, sino wpad)

Y cómo usamos NetBios con Linux?

Pues con SAMBA

Para configurar SAMBA al efecto, necesitamos saber cual es el grupo de trabajo de la red... eso es fácil, los Windows y NetBios son muy parlanchines, continuamente está anunciandose...

Con un esnifer cualquiera lo podremos conseguir puesto que gran parte del tráfico NetBios es broadcast (para todos), en el ejemplo vemos claramente que el grupo de trabajo se llama CASA:

Imagen
*Nota: En esta pantalla aparece la IP 192.168.4.111 en lugar de la 192.168.4.222, no "me pienses mal" no hay truco... es simplemente que me equivoqué de máquina en la captura...

Así que ahora, desde un frontend para samba o desde el mismo archivo de configuración (smb.conf) “tuneamos” samba como ha de estar:

Imagen

También hay que cambiar otras opciones, elegirnos como master browser y los puertos netbios....

Imagen

Y los puertos....

Imagen

Ya lo tenemos....

Desde la shell ejecutamos nmbd para lanzarnos a la red Windows diciendo que somos wpad y estamos “listos para participar”

Vamos a ver si “nos ven”, desde el equipo Windows hacemos un ping a wpad

Imagen

Ea!!! Somos nosotros :P

Si nuestro “amigo” el de la ip estática tiene verificada la casilla de detectar Proxy automáticamente... pasará lo mismo de antes...

Imagen

Ahora va a google, luego a debian, a yahoo... vamos, lo de antes pero mediante netbios.

Esto se debe a que también “por defecto” se activa NETBIOS en los Windows...

Imagen

Para impedir todo esto, ya sabes... Desactivar lo del Proxy automático en los navegadores, levantar un DNS privado que registre apropiadamente a sus clientes INCLUYENDO la máquina wpad y wpad. (ojito con el punto al final) también hay que registrar el servidor web y eso... y por supuesto deshabilitar netbios sobre tcp/ip, aunque eso, a pesar de lo que parece no es tan sencillo... pero algo es algo...

Por último, sería conveniente que el archivo proxy.pac del webserver se llame también wpad.dat, vamos que lo copies con ese nombre en el mismo directorio httdocs, realmente buscarán ese archivo por NetBios y si el servidor web no es la misma máquina del Proxy y no es un Windows daría problemas... así que mejor, los dos... un proxy.pac y otro wpad.dat, el mismo perro con dos collares ;)

Y ya para terminar te dejo un ejemplo “mas granular” del archivo de configuración .pac o .dat, no hace falta mucha mas información que la que se muestra:

Código: Seleccionar todo
// Ejemplo Básico. TODO  pasa por el proxy 192.168.4.100:8888

// function FindProxyForURL(url, host)
{
//       return "PROXY 192.168.4.100:8888";
// }


//Ejemplo mas detallado

function FindProxyForURL(url, host) {


// indicar una línea por cada url a la que se accede sin el proxy...
     // Acceso a URL's que no precisen de proxy:
     if (shExpMatch(url,"*.foo.com/*"))       {return "DIRECT";}
     if (shExpMatch(url, "*.foo.com:*/*"))    {return "DIRECT";}
     if (shExpMatch(url, "*.microsoft.com:*/*"))   {return "DIRECT";}

// Si existen varios proxys, se pueden indicar por IP o por nombre DNS

     // Acceso con proxy a ip's determinadas de la red
     // puerto del proxy 8888 del proxy fastproxy.foo.com:

     if (isInNet(host, "192.168.4.33",  "255.255.255.0"))    {
        return "PROXY fastproxy.foo.com:8888";
     // tambien podría ser return "PROXY 192.168.4.100:8888 si esa
     //fuese la ip de fastproxy.foo.com:8888
     }
     
     // Para el resto de condiciones que no se cumplen se indica el
    // nombre del proxy o la dirección IP del mismo

     return "PROXY 192.168.4.100:8888; DIRECT";
     // también podria ser return "PROXY miproxy.foo.com:8888" igual
    //que antes...

  }


Si lo piensas... hasta pueden existir varios proxys... y si investigas por tu cuenta, averiguarás que también hay mas opciones de descubrimiento, hasta para ftp....

Suerte.
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Notapor Death_Master » Dom Feb 10, 2008 9:42 pm

He tardado un poquito en leerlo, y de hecho le he puesto el postit antes de hacerlo... :lol:

Como siempre, genial. Y como siempre, telita con los Windows, entre la configuración por defecto del IE y el NetBios...

Gracias campeón. ;)
Omnium potentior est sapientia
Avatar de Usuario
Death_Master
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 2925
Registrado: Mié Ene 26, 2005 10:36 pm
Ubicación: 404

Notapor Popolous » Lun Feb 11, 2008 1:01 am

Muchas gracias, le echaré un ojo (o los dos) y lo leeré atentamente.

¡Saludos!
A. Einstein, cabello y violín,
hacemos nuestra última reverencia;
aunque sólo comprendido por dos personas,
él mismo y, a veces, Dios.

Jack C. Rosseter

"Sin direccionamiento Físico, no hay direccionamiento Lógico"

Vikingo dixit
Popolous
Wadalbertita
Wadalbertita
 
Mensajes: 1946
Registrado: Mié Ene 26, 2005 10:40 pm
Ubicación: E=mc^2

Notapor NeTTinG » Lun Feb 11, 2008 2:43 am

Hola:

Para mi estos textos siempre son una sorpresa...

Pienso... ¿A ver que nos trae ahora el vikingo?

De nuevo, gracias Vic_Thor.

Todavía no lo he leído, en cuanto pueda me lo miro ;)

Un saludo.
| Blog NeTTinG | Proyecto Destripando iOS |
_____________________________
Todos somos muy ignorantes. Lo que ocurre es que no todos ignoramos las mismas cosas. (Albert Einstein)
Todos recaerán en la necesidad de conocer la única y presumible verdad que el gran embudo emana. (Sire Netting)
Avatar de Usuario
NeTTinG
Wadalbertita
Wadalbertita
 
Mensajes: 6272
Registrado: Mar Sep 20, 2005 5:54 pm
Ubicación: Bajo la trampilla del décimo primer piso.

Notapor NeTTinG » Mar Feb 12, 2008 1:36 am

Hola:

Muy interesante, muy claro y muy tentador :p

Con respecto a esto:

Y si resulta que ya existiese un dhcp en la red?

Pues con las ips que ya entregó poco podemos hacer... pero para “los nuevos” podemos entretenerle, inundarle de peticiones.... usaremos un flooder que se llama dhcpx, lo deamos un ratito, con un minuto sera suficiente:


Si de antemano nosotros nos conectamos con el servidor DHCP original de la red obtendremos la configuración que envía el servidor...

¿No podíamos aprovechar esto para realizar el mismo ataque que realizamos contra los hosts con configuración "manual" (IP estática) contra los hots que ya han recibido la configuración del verdadero servidor DHCP?

Una vez que se han obtenido la configuración de la red... el escenario es el mismo ¿noh?.

Es más, resulta más sencillo cuando existe un servidor DHCP que asigne la configuración que cuando los equipos utilizan una configuración estática... Cuando sea estática desconoceremos la configuración de la red... Vale, no. Pero habría que poner andar el sniffer, ¿noh?

Otra posibilidad que se me ocurre es engañar a las posibles víctimas con un Envenenamiento ARP o ARP Spoof... De esta forma creerán que el verdadero servidor proxy es el nuestro...

Y la tercera y última posibilidad que se me ocurre... aunque desconozco el protocolo y no podría confirmarlo...

Si enviamos paquetes ARP Reply con direcciones MAC falsas los hosts perderán la colectividad con el servidor DHCP, aunque creo que no necesitan comunicarse más con el... [de lo contrario (*)]... Enviamos la "nueva" configuración desde el servidor DHCP "maligno" y... ¿podrían picar...? ¿noh? Creo recordar que cuando varías la dirección IP que asigna un servidor DHCP, por ejemplo, el de un Router, y estás conectado a este a través de una configuración IP dinámica, al reiniciarse el Router este ya te pasa la nueva configuración de red... No puedo confirmarlo, no tengo ahora mismo aquí ningún dispositivo con que probarlo...

(*)Antes decía que no creía que los hosts que ya han recibido la configuración del servidor DHCP necesiten "hablar" más con el servidor DHCP... De no ser así, se podría aprovechar esto para engañar a los hosts mediante ARP Spoof o creando paquetes DHCP manipulados a mano... e indicándole a estos host que se ha cambiado la configuración...

Otra cosa que desconozco es si el servidor DHCP puede enviar paquetes para actualizar las máquinas que ya cuentan con la configuración asignada automáticamente... de ser así, creo que sería coser y cantar... ¿Me equivoco?

A ver si podéis refrescarme un poco :p ;)

Un saludo.
| Blog NeTTinG | Proyecto Destripando iOS |
_____________________________
Todos somos muy ignorantes. Lo que ocurre es que no todos ignoramos las mismas cosas. (Albert Einstein)
Todos recaerán en la necesidad de conocer la única y presumible verdad que el gran embudo emana. (Sire Netting)
Avatar de Usuario
NeTTinG
Wadalbertita
Wadalbertita
 
Mensajes: 6272
Registrado: Mar Sep 20, 2005 5:54 pm
Ubicación: Bajo la trampilla del décimo primer piso.

Notapor kramox » Sab Feb 16, 2008 12:46 pm

Otra vez me dejas asombrado con tus conocimientos. Y como siempre tus textos son de una calidad y claridad inmejorable.
Voy a ver que aprendo sobre esta nueva técnica.

Un saludo.
No lo pienses hazlo, otro ya lo hizo, así que no es difícil

Date un paseo por mi blog
kramox
:-D
:-D
 
Mensajes: 65
Registrado: Mié Jul 11, 2007 10:41 am

Notapor Yorkshire » Sab Feb 16, 2008 10:33 pm

Muy interesante y didáctico.

Gracias!
Linux registered user #346840
Avatar de Usuario
Yorkshire
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 4488
Registrado: Mié Ene 26, 2005 5:05 pm
Ubicación: -<|:-P[G]

Notapor vlan7 » Dom Feb 17, 2008 3:50 pm

Creo que es la unica vez que veo un post-it del vikingo y puedo decir "esto ya lo sabia" 8)

Espero que comprendais que esto es un cumplido hacia Vic_Thor ;)

beS.O.S.
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Notapor Arakiss » Vie Abr 04, 2008 7:31 pm

Osti esto no lo habia visto yo...mmmmm muy interesante,muchas gracias por el aporte Vic_Thor como siempre tus trabajos son geniales.

Saludos ;)
Avatar de Usuario
Arakiss
<|:-D
<|:-D
 
Mensajes: 1335
Registrado: Mié Ene 11, 2006 3:41 pm
Ubicación: Madrid


Volver a Redes

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado

cron