Protocolos de Enrutamiento. Atacando a RIP

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

Moderador: Moderadores

Protocolos de Enrutamiento. Atacando a RIP

Notapor Vic_Thor » Mar Feb 05, 2008 3:47 am

ATACANDO PROTOCOLOS DE ENRUTAMIENTO

Todos ya estamos algo acostumbrados a los “ataques” del tipo redirect en una red local, envenenamiento arp, icmp redirect y otras técnicas de redirección del tipo Root Bridge en redes conmutadas con STP nos son familiares.

En los escenarios que se mueven los ataques anteriores, el “malvado” juanker-malo-malísimo está en el mismo segmento de la red local atacada... Los tan sonados MiTM están al orden del día...

Imagen

El atacante “armado” con u equipo y dos tarjetas de red (o sólo con una también) es capaz de redireccionar el tráfico legal del equipo 192.168.0.3 con destino a Internet (o hacia cualquier otro de la LAN) haciéndolo pasar por el suyo propio, poniéndose en medio, interceptando las comunicaciones en una red conmutada...

Como decía, esto ya lo conocemos... pero... Quien no ha pensado alguna vez.... Sería posible “desviar” el tráfico existente de una red a otra y hacerla pasar por el/los equipos de una tercera?

Pongamos un ejemplo sencillito...

Imagen

Una empresa con infraestructura propia que dispone de varias sucursales y una sede central.

En la sede central, además de otros usuarios, trabajadores, etc.. existen los recursos típicos, los servidores de Bases de Datos, Intranet, etc., mientras que en las sucursales disponemos únicamente de los recursos locales así como de los equipos de trabajo de los usuarios que pertenecen a las mismas.

La cosa se podría complicar si “nuestra empresa” crece:

Imagen

En cualquiera de los dos escenarios, el/los administradores de redes de la empresa deberían “hacer entender” a los routers que conectan la infraestructura los caminos y rutas para llegar “mejor” de un sitio a otro, obviamente, en el segundo supuesto es más complicado, que pasaría si un enlace se cae.... y si luego se añade otra sucursal mas... o damos “de baja” a una existente... pues hay que reconfigurar los routers para que aprendan la topología de red.

Si se hace “a mano”, los administradores deberán informar estáticamente a cada router de los caminos disponibles, esto es, rutas estáticas... y por cada cambio en la red habrá que volver a configurarlos... con mala suerte TODOS!!!!

Pues bien, una de las tareas de los protocolos de enrutamiento consiste en liberar a los administradores de eso, los protocolos de enrutamiento se encargarán de mantener actualizadas las tablas de rutas cada router, en todo momento se darán cuenta de los posibles cambios en la red y tomarán las medidas pertinentes para que no pierdan conectividad.

Cuando todos los routers de la red conocen todos los caminos (o los mejores caminos) para llegar de un punto a otro, se dice que la red converge.

La convergencia es el fin último del enrutamiento.

Resumiendo, mediante los protocolos de enrutamiento, los routers intercambian información acerca de las redes a las que saben llegar e informan o los otros de ello, a su vez, nuestros vecinos también nos cuentan las redes que conocen y ampliamos conocimientos acerca de cómo es la red y cuando todos sabemos llegar a todas partes, hemos convergido.

Protocolos de enrutamiento hay muchos, los podemos dividir o clasificar de varias formas:

    Internos, externos, frontera
    Vector-distancia, estado enlace


Y seguro que mas de uno ha oído hablar de alguno de ellos: BGP, OSPF, RIP, EIGRP...

No es que haya unos mejor que otros, dependerá de dónde los queramos implementar, del router, etc... bueno, si hay unos mejores que otros...

Es mas, un router puede implementar varios protocolos de enrutamiento a la vez, por ejemplo puede usar RIP y OSPF simultáneamente y descubrir las rutas por uno, por otro o por los dos...

Lógicamente si Router1 y Router2 quieren intercambiar rutas, ambos deben usar el mismo protocolo de enrutamiento, por ejemplo:

Caso a)

R1: Utiliza RIP y OSPF
R2: Utiliza EIGRP y RIP

Las tablas de rutas que se intercambien se hará por medio de RIP que es el protocolo de enrutamiento “común” que usan los dos.

Caso b)

R1 Utiliza OSPF y RIP
R2: Utiliza EIGRP

Pues no podrán intercambiarse nada porque no hay protocolos de enrutamiento comunes.

Caso c)

R1: Utiliza RIP y OSPF
R2: Utiliza RIP y OSPF

Intercambiarán rutas por medio de OSPF. Ahhh!!! Y por qué no usarán RIP???

Pues por un nuevo concepto que hay que añadir a esto... LA DISTANCIA ADMINISTRATIVA.

La distancia administrativa es un valor numérico que representa el grado de confianza que ofrece un protocolo de enrutamiento, a menor distancia administrativa mejor se supone que es el protocolo de enrutamiento.

RIP utiliza por defecto una distancia administrativa de 120 mientras que OSPF utiliza 110, por tanto se supone que OSPF es mejor, que las rutas descubiertas mediante OSPF son mejores que las descubiertas por RIP y se usaran las de OSPF en su lugar.

Caso d)

R1: Usa RIP, OSPF, rutas estáticas hacia R3 y está directamente conectado a R2 y a R4
R2: Usa RIP, OSPF, rutas estáticas hacia R6 y está directamente conectado a R1 y a R5

R1 sabe como llegar a R2, R3 y R4
R2 sabe como llegar a R1, R5 y R6

Como ves, R1 no se entera de que existe una red... R6, y de la misma forma, R2 no sabe de la existencia de R4

Esto es porque a menos que se REDISTRIBUYAN las rutas estáticas los protocolo de enrutamiento no las descubren por sí mismos

Aún podemos complicar mas el asunto, imagina que R1 sabe mediante OSPF que existe una red X, pero usa RIP para conversar con R2....

Qué pasa con la red X???

Pues que al igual que con las rutas estáticas, las redes descubiertas mediante otros protocolos de enrutamiento no se distribuyen sin más... vamos, al grano... Si se usan varios protocolos de enrutamiento y/o rutas estáticas, es necesario redistribuirlas bajo los otros protocolos de enrutamiento que usemos o el “router del otro extremo” no se enterará que existen...

También es importante aclarar que las distancias administrativas de las rutas estáticas es 1 y las de las redes directamente conectadas es 0 (cero), por ello, si un router descubre que para ir a una red es mejor llegar por X pero existe una ruta estática que dice que es por Y, se irá por donde dice la ruta estática y no mediante la descubierta por el protocolo de enrutamiento en cuestión...

Y cual es la mejor ruta???

Pues esto lo resuelven los protocolos de enrutamiento mediante la MÉTRICA.

La métrica es otro valor numérico que le dice al router el “lo que cuesta” ir de un punto a otro, al igual que las distancias administrativas, cuanto menor métrica (menor coste) mejor camino.

Las métricas dependen mucho del protocolo de enrutamiento usado, los hay que toman como métrica el menor número de saltos, los que utilizan el ancho de banda y también los que toman en cuanta factores como la congestión, el retardo, la fiabilidad o incluso una “mezcla de ellas”, vamos que por ejmplo un router puede decidir si un dato va por un sitio u otro por muchos factores, dependerá del protocolo de enrutamiento elegido.

Bien, creo que lo básico de protocolos de enrutamieto ya está expuesto... ahora vamos a trabajar sobre el título del post: ATACANDO PROTOCOLOS DE ENRUTAMIENTO

En este ejemplo atacaremos a RIP v2, para ello vamos a decir alguna cosita de RIPv2 antes de nada,

RIPv2

· Es un protocolo de enrutamiento vector distancia
· Utiliza como métrica el número de saltos
· Utiliza multitast (224.0.0.9) para comunicarse con los otros routers RIPv2
· Puede ser autenticado, es decir, puede utilizar contraseñas y métodos de autenticación PAP o CHAP para recibir o promulgar las rutas
· Su cuenta al infinito es de 15 saltos, esto es, entre un destino y otro no puede haber mas de 15 saltos o la ruta será inalcanzable
· Utiliza Horizonte Dividido (Split Horizon) esto es, una ruta no debe ser promulgada por la misma interface que fue recibida, con esto se eliminan ciertos tipos de bucles de enrutamiento.
· Utiliza o puede utilizar, rutas envenenadas para evitar bucles de enrutamiento, esto es, marca una ruta con 16 saltos si el router no sabe alcanzarla.
· Informa al origen mediante mensajes ICMP de las posibles incicdencias del enrutamieto
· Utiliza temporizadores para la convergencia y disipar bucles, esto es:
o Cada 30 segundos envía actualizaciones periódicas
o Si se da cuenta que una ruta “ha caído” la mantiene en una especia de “congelador” antes de eliminarla por completo, este tiempo es de 120 seg.
o A los 180 segundos la elimina “de verdad”
· Puede usar máscaras de subred, VLSM y subredes
· Puede usar o usa, actualizaciones desencadenadas para evitar los tiempos de espera que indican los temporizadores
· Utiliza o puede utilizar la validación del origen de la ruta, esto es, sólo aceptar actualizaciones (o enviarlas) a determinadas IP’s
· Utiliza protocolo UDP puerto 520.

Vaaaleee, lo principal está.... lo que no debemos olvidar (ahora en cristiano) es:

· La convergencia de una red RIP puede llevar varios minutos (debido a los temporizadores) si bien, al usar actualizaciones desencadenadas la convergencia de la red puede ser mucho más rápida.
· El máximo número de saltos es 15
· Utiliza direcciones de multicast para “pasarse” las tablas y/o rutas
· Puede que se usen contraseñas (cifradas en MD5 o no) para validar una actualización
· Utiliza la validación en origen (por IP) de las actualizaciones recibidas.

Los pasos del ataque a RIPv2 son:

· Escuchar el tráfico RIP, de ello averiguaremos:
o IP’s Origen de las actualizaciones
o Si se usan contraseñas o no para validar las actualizaciones
o Si la contraseña está cifrada habrá que romperla también, aunque ya te adelanto que se puede “pasar” el hash MD5 sin más para evitar la ruptura de la contraseña que siempre puede ser una tarea larga en el tiempo.

· Enviar actualizaciones falsas con IP origen autenticado o validado, esto lo habremos conseguido mediante el esnifer ;)
· La falsa actualización será encaminar a TODA una RED por “otra” máquina, otro router o “similar” que esté bajo el control del atacante
· Escuchar el tráfico de interés redirigido
· Volver a encaminar los paquetes hacia el verdadero destino.

Y R.I.P. de RIP (Requiescant In Pace, Routing Information Protocol) jajaja...

Para ello vamos a necesitar simplemente una máquina Linux con capacidad de reenvío, un generador de paquetes cualquiera y nuestro querido IPTABLES para hacer un POSTROUTING del tráfico de la red.

También hay otro método mas chulo, usando Zebra o Quagga que emulan dispositivos CISCO en un Linux, podríamos configurar nuestra máquina como otro router más de la red mediante Quagga, habilitar RIPv2 y ponerla a funcionar... pero, nos bastará con lo primero.

El escenario propuesto (para no ser muy complicados) es el siguiente:

Imagen

Disponemos de 4 Routers, tres de ellos corriendo RIP que están situados en la Central y en las dos sucursales, el cuarto router conecta a la central con los recursos externos, entre ellos Internet y en este no hay RIP (aunque pudiese haberlo, claro... no importa)

La RED de la central es 172.28.0.x/24 y conecta a las oficinas remotas, entiende el término remoto como “otra red con otros routers”, perfectamente podrían estar situados en el mismo edificio, en plantas distintas o en edificios cercanos...

La RED de la Oficina 1 es 192.168.200.x/24

La RED de Oficina 2 es 10.0.0.x/24

La RED de RECURSOS es 192.168.4.x/24 en la que están situados recursos corporativos, por ejemplo DNS, BBDD, etc... y también el acceso a redes remotas, en el caso... Internet.

Los routers involucrados en RIP son los de la Central y las Oficinas, mediante el esnifer iremos “adivinando” la topología y las diferentes Ip’s de los medios que nos conectan.

El atacante va estar situado en la oficina CENTRAL, esto es una conveniencia puesto que ya Está en medio, pero luego comentaremos qué pasaría si estuviese en una de las oficinas en lugar de en la central.

Quiero hacerte notar que aunque el atacante ya está en el medio, el tráfico entre oficinas y/o entre oficinas y recursos y/o entre oficinas e Internet no pasará por él, puesto que para ello tendría que modificar la tabla de enrutamiento de los routers y se supone que éstos están bien configurados (es un decir) o al menos bien protegidos y sin acceso físico a los mismos.

También pensarás que sería mejor que RECURSOS fuese una red distinta conectada de otra forma a CENTRAl, así:

Imagen

Efectivamente, podría ser, y de hecho será así , ea!!!! Da igual, el “efecto” será el mismo, pero es que no tengo un router con 4 interfaces (ojito que digo 4 interfaces, no un router con un switch de 4 puertos....) hay que hacer routing “de verdad” entre las interfaces...

Por eso el gráfico anterior y no éste último....

Bien, pues escenario en mano (suerte que tenemos de poder verlo en lugar de imaginarlo, jeje) vamos ahora con lo que necesitamos:

· 4 Routers, al menos 3 de ellos con RIPv2 funcionando
· Al menos una máquina en cada red
· Conexión a Internet para ofrecer ese servicio a las sucursales
· Un Linux en la central (el atacante)
· Un generador de paquetes
· Un esnifer
· Otro router en la máquina atacante (que es el mismo Linux, menos mal, con quagga o zebra, o en su defecto, enviar las rutas “mal intencionadas” al menos cada 30 segundos...)

Todo esto “lo tenemos”, bueno lo tengo ahora... (os imagináis como está mi casa, joder!!!!)

Para evitar lo de “convertir” Linux en un router emulando la IOS de cisco, esto puede quedar para otra ocasión, usaremos el generador de paquetes y para mantener la convergencia, nos ocuparemos de enviar el paquete RIP con frecuencia, COMO!!! Que no entiendes por qué hay que enviarlo de vez en cuando???

Pues hombre... ya hemos hablado de los cambios de topología, de la convergencia, etc... recuerda que RIP envía actualizaciones cada 30 segundos... si no lo hacemos con la máquina atacante los otros routers entenderán que esa red o ese router ya no está y dejaran de promulgar su existencia.... claro, no???

Aunque esto lo vamos a descubrir en un momentito, está bien que sepamos las Ip’s de los routers que interconectan nuestra empresa...

Veamos:

RS: Es el router que conecta recursos con Internet, tiene 2 interfaces:

· LAN: 192.168.43.254
· WAN: xxx.xxx.xxx.xxx (es la pública, claro)

RC: Es el router de la sede central que conecta recursos con la sede central y con las oficinas:

· Interface1: 192.168.4.111, conecta Central con Recursos
· Interface2: 172.28.0.111, Conecta Central con Oficina 1 y Oficina2

RO1: Es el Router de Oficina 1 que conecta con central

· Interface1: 172.28.0.112 que conecta Oficina 1 y central
· Interface2: 192.168.200.111 que conecta la red de Oficina1, vamos, que será la puerta de enlace para la gente de ficina1

RO2: Es el router que conecta Oficina 2 con la Central

· Interface 1: 172.28.0.113 que conecta Oficina 2 y Central
· Interface 2: 10.0.0.111 que conecta que conecta la red de Oficina2, vamos, que será la puerta de enlace para la gente de Oficina2

ATACANTE: Máquina Linux situada en central

· Interface1: 172.28.0.66 y puerta de enlace 172.28.0.111

Otro gráfico... uno mas para verlo mas claro:

Imagen

El ataque consistirá en hacer pasar el tráfico de las oficinas por la máquina del atacante mediante el envío de actualizaciones RIP a los routers de la topología, para ello la máquina 172.28.0.66 (el atacante) falseará su IP y enviará dichas actualizaciones a los routers R01 y R02 haciéndose pasar por RC, los paquetes a enviar les indicarán a los routers involucrados que para llegar a Internet o a la red de recursos corporativos, la mejor manera de llegar es a través de él mismo... luego re-enrutará el tráfico hacia el verdadero destino de los paquetes y las respuestas de vuelta las enviará de nuevo a los legítimos orígenes.

La ip objetivo del ataque será la 10.0.0.55 que está situada en la red de la oficina2, este equipo se conecta habitualmente a una web importantísima para su trabajo diario...

http://www.wadalbertia.org/phpBB2/index.php ;)

Para lograr el objetivo, el atacante necesita saber:

· Ip origen: nuestra víctima la ip 10.0.0.55
· IP destino: la de estos foros... 67.225.138.174

Realmente necesitamos la red destino... que bien puede ser 67.225.138.0/24, pero en este ejemplo usaremos sólo la IP.

También necesitaremos saber o estar seguros de que la métrica hacia esa red desde el origen es mayor a 1, puesto que si fuese uno el router de la oficina 2 podría hacer tres cosas:

a) Balancear la carga, el 50% de los paquetes irían por la interface del router y la otra mitad por la de la máquina del atacante
b) Usar únicamente la interface del router de oficina 2
c) Usar únicamente la máquina del atacante.

Esto lo podremos averiguar con un simple trazado de rutas hacia la víctima y otro trazado hacia wadalbertia, sumamos los saltos y será la métrica que aplicará el router de la oficina2.

Hombre, esto ya lo sabíamos de antes, tenemos unos dibujitos maravillosos, pero claro... no siempre sería así, verdad?

Bien, para verlo mas claro, hagamos como si estuviésemos en la máquina 10.0.0.55 y lanzamos un esnifer para RIP... se llama ass (no... no es culo como su significado indica :D) es Autonomous System Sniffer, ciertamente no sólo sirve para RIP, pero aquí lo usaremos para ello.

Imagen

Podemos apreciar que para llegar a la red 172.28.0.0 (que se supone que es donde está el atacante) necesita de un salto, mientras que para ir a otras redes precisa de 2 ó 3 saltos... por tanto, si le decimos que para ir a wadalbertia se necesita sólo un salto y es por 172.28.0.66 (ip del atacante) se lo tragará....

Ahora veámoslo desde el punto de vista del atacante...

Primero hacemos un traceroute a la ip 10.0.0.55 (víctima), luego otro traceroute hacia wadalbertia (red destino que queremos ponernos en medio)

Imagen

Nota: La salida del traceroute a wadalbertia la paré antes de que terminase,

Si te fijas, desde el atacante se pasan por los routers 172.28.0.111 y 172.28.0.113 para llegar a la red 10.0.0.0, recuerda también que el router 172.28.0.113 es el que nos conecta a la red víctima...

Y para llegar a wadalbertia, se pasan por los routers 172.28.0.111 y 192.168.4.254 (y mas... pero como ya te dije lo paré antes de que terminase puesto que el resto de saltos no nos interesan)

Por tanto, necesitará al menos dos saltos, por tanto, si conseguimos “enseñar” al router 172.28.0.113 que para ir a wadalbertia en lugar de dos saltos necesita uno sólo, la cosa está finiquitada.

Si corremos el esniffer desde “nuestra” posición, nos haremos una idea mas clara de la topología... casi, casi como en los gráficos (casi)

Una cosa antes de ponerte la captura de pantalla, hay que dejar un minuto mas o menos el esniffer corriendo, QUE NO SABES POR QUÉ???? Coña, lo de las actualizaciones de RIP, los 30 segundos de rigor y todo eso... que para ello lo expliqué antes ;)

Bien, saldrán unos numeritos, unos y doses, eso son paquetes RIPv1 y RIPv2 respectivamente... veámoslo:

Imagen

Como observarás en la pantalla anterior, claramente descubrimos como es el enrutamiento, los routers, los vecinos, las Ip’s, las métricas... vamos, todo....

Bueno, pues ahora hay que preparar el ataque... inyectaremos un paquete con destino a 172.28.0.113 (router de la red 10.0.0.0) haciéndonos pasar por 172.28.0.111 (siguiente salto de la red 10.0.0.0), diciéndole que para ir a Wadalbertia (67.225.138.174) se va “mejor” (métrica 1) por 172.28.0.66 (máquina del atacante)

Y TODO el tráfico de 10.0.0.55 con destino a Wadalbertia pasará por nuestra máquina ;)

PERO ANTES!!! Antes, si queremos que la red víctima reciba respuestas, tendremos que poner nuestra IP como origen de los paquetes y no la de la víctima!!! Vamos que si no hacemos NAT el tráfico de salida pasará por nosotros pero el de vuelta no...

Y cómo hacemos NAT en Linux???? Pues claro, hombre claro... IPTABLES!!!

Por tanto, ANTES de inyectar nada:

· Habilitamos el reenvío:

Código: Seleccionar todo
 echo 1 > /proc/sys/net/ipv4/ip_forward


· Hacemos nat en origen:

Código: Seleccionar todo
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.55 -j SNAT --to-source 172.28.0.66


Y ZAS!!! TODO el tráfico entre la IP 10.0.0.55 y Wadalbertia pasará por nuestra máquina (cuando inyectemos el paquete) y seremos capaces de capturar también el tráfico de vuelta y entregárselo a la red de la víctima ;)

Ahora, si... un generador de paquetes, podemos usar el que queramos, nemesis es buan opción, pero hay uno también especializado en RIP, se llama srip

Lo que haremos es:

Código: Seleccionar todo
srip -2 -n 255.255.255.0 -g 172.28.0.111 172.28.0.66 172.28.0.113 67.225.138.174 1


Que es:

–2 (RIP versión 2)

-n 255.255.255.0 máscara de subred

-g 172.28.0.111 IP del router o gateway que enviará el paquete ip-spoofing)

172.28.0.66 máquina del siguiente salto

172.28.0.113 Router al que se le enviará el paquete

67.225.138.174 Red ó IP que se llega vía 172.28.0.66

1 Métrica (numero de saltos)

Y se actualizará la tabla de rutas del router 172.28.0.113 con esa entrada... la aceptará porque viene de 172.28.0.111, aunque valide el origen del paquete, llegará....

Veamos que pasa ANTES de inyectar el paquete, supongamos que la máquina 10.0.0.55 hace un trace route a wadalbertia (salida cortada)

Imagen

Y ahora DESPUES de inyectar el paquete:

Imagen

Como ves hay un salto “extra” la máquina 172.28.0.66 que somos nosotros ;)

Si ponemos un esnifer y la máquina Linux para capturar contraseñas y eso, pues.... está claro, no?

Por cierto... ahora nuestros en nuestros foros la contraseña ya no viaja en texto plano,

Imagen

El usuario, si se ve en texto plano... “pepillo

Y el password en md5 que era... “eldelospalotes

Imagen

En fin, espero que haya sido de interés, he de decir que este fin de semana nos entretuvimos un poco en clase con este asunto, venga que lo sé... que más de un alumno mio anda por aquí... a que sí? Jajaa, menudo tema... entre esto, lo del secuestro de sesiones y STP, vaya fin de semana que nos pasamos.

Saludos, a mis alumnos también ;)

PD:

ass (pertenece a la suite de IRPAS) lo podéis encontrar en:

http://www.phenoelit-us.org/irpas/download.html


srip (fuente en C, hay que compilarlo) en:

http://packetstormsecurity.org/groups/horizon/srip.c

Ayy!!! que se me olvidan "las soluciones"...

* Autenticar RIP mediante CHAP

* Silenciar las interfaces del router por las que no se deben enviar actualizaciones, p.e. las ethernet (interfaces pasivas y/o ACLS)

* Filtros y listas de acceso al puerto 520 de UDP y/o a las direcciones de multicast

* validar el origen de los paquetes

* Usar rutas estáticas (cuando se pueda)

* Utilizar protocolos "mas fuertes" como OSPF (que también es vulnerable a este tipo de ataques, pero algo mas complejo)

* Vigilar... un simple traceroute delatará el asunto ;)

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

Notapor Bebbop » Mar Feb 05, 2008 11:01 am

Te lo pongo como post-it para que no se quede abajo.
Avatar de Usuario
Bebbop
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 3424
Registrado: Mié Dic 14, 2005 2:46 pm
Ubicación: El Inframundo

Notapor NeTTinG » Mié Feb 06, 2008 12:21 am

Hola:

Como nos cuida este vikingo :badgrin: :badgrin:

Gracias Vic ;)

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 » Mié Feb 06, 2008 12:56 am

Hola:

Me lo he comido...

¡Cojonudo! ¡Chapeau!

Como siempre en tu linea ;)

Me muero de envidia de tus alumnos :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 Andrew_Wiggin » Mié Feb 06, 2008 12:57 am

Gracias Victhor! :o
<<"Bueno es ir a la lucha con determinación, abrazar la vida y vivir con pasión, perder con clase y vencer con osadía, porque el mundo pertenece a quien se atreve y la vida es mucho para ser insignificante".>>Charles Chaplin
Andrew_Wiggin
<|:-)
<|:-)
 
Mensajes: 684
Registrado: Jue Nov 17, 2005 1:05 pm
Ubicación: La ciudad invisible.

Notapor SeThuR » Mié Feb 06, 2008 1:04 am

NeTTinG escribió:
Me muero de envidia de tus alumnos


Ya te digo, me lo has quitado de la boca.
La llama eterna de la sabiduría sólo la mantienen aquellos que conservan innata la chispa de la curiosidad
Avatar de Usuario
SeThuR
:-D
:-D
 
Mensajes: 187
Registrado: Jue Abr 20, 2006 5:13 pm

Notapor Delfi » Mié Feb 06, 2008 4:24 am

Como siempre, Muchas gracias Vic_Thor.
Delfi
:-)
:-)
 
Mensajes: 48
Registrado: Sab Jul 21, 2007 6:41 pm

Re: Protocolos de Enrutamiento. Atacando a RIP

Notapor soez » Mié Jul 06, 2011 6:30 am

Espero que alguien lea esto, alguien tiene el programa o codigo fuente srip.c ? Saludos y gracias.
soez
:-)
:-)
 
Mensajes: 2
Registrado: Dom Abr 20, 2008 1:54 pm

Re: Protocolos de Enrutamiento. Atacando a RIP

Notapor vlan7 » Mié Jul 06, 2011 6:53 am

Si, google. Pero que no nos tome por robots, a mi me cambia la busqueda a script.c, pero justo debajo pone

"Resultados de script.c. Ver resultados de srip.c."

Suerte,
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

Re: Protocolos de Enrutamiento. Atacando a RIP

Notapor soez » Mié Jul 06, 2011 7:00 am

joder tio si es un perro me muerde, no me he dao cuenta q me lo cambiaba a script.c thanks ;)
soez
:-)
:-)
 
Mensajes: 2
Registrado: Dom Abr 20, 2008 1:54 pm


Volver a Redes

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 5 invitados

cron