Ayuda Ip Spoofing!!!

Que tal.

Bueno, solo intento aportar mi granito de arena..

Yo pienso en lo que dices "..realizar ip spoofing desde linux hacia otra maquina, esto con la finalidad de poder acceder a un router cisco por medio de la ip de la victima..", y la verdad lo veo no tan sencillo como se pinta.
Lo que yo he entendido es que quieres conectarte con el router usando la IP de la otra maquina ( Spoofing ). Con conectar sobrentiendo TCP sobre IP.
Bien, gracias a que estas en Red Local pienso que es mas idoneo.. pero aun tedioso.

Para ello, creo que no solo debes de realizar el IP Spoofing ( lo cual no es tan dificil ), sino que tambien deberias de envenenar caches. Por que? Porque no te puedes olvidar del entorno: Ethernet! ( Supongo.. ). Es decir, las tramas Ethernet van a ir en los primeros bytes de los paquetes, por lo que deberias de tener en cuenta que el direccionamiento de los paquetes iran desde el principio basados en dichas tramas.

Es decir, cuando en una Red Ethernet vaya a haber una conexion sobre IP ( debemos de recordar que en una Red Local Ethernet, no se tiene por que implementar IP ), entrara en accion el Protocolo ARP ( Address Resolution Protocol ), el cual Resolvera ( Resolution ) la relacion IP-MAC de la maquina a conectar. Por ende, digamos que ARP preguntara por la MAC, a partir de una IP dada. O sea, desde el principio de tu conexion Spoofeada con el router, al ser una conexion Local con topologia basada en Ethernet, puede que tu propia maquina no tenga la direccion IP del router; da igual por ahora el Spoofing.
En ese momento primario de la conexion, tu has puesto la IP en las cabeceras IPs del paquete manualmente o mediante Software. Bien, pero a la hora de formar la Trama Ethernet no importa tanto la IP destino ( router ) sino su MAC.
Ahi hemos dicho que ARP entra en accion. Bueno, para que ARP entre en accion debe de saber de algun modo la IP destino, para asi poder preguntar por su MAC no?! Aqui me explico...

Una Red Ethernet no es como Internet. O sea, en la Internet nosotros usamos un cliente ( el Web Browser ) para navegarla ( es nuestro barco! ). O sea, toda esas conexiones estaran basadas en el modelo cliente-servidor.
En nuestro barco, perdon Browser, ponemos la URL a visitar y, mediante DNS ( Domain Name System ) se resuelve esa URL ( que es un nombre de un dominio ) a la IP de ese dominio; ya que lo que importa es la IP. DNS se creo por varios motivo y uno fue que es mas facil para los humanos ( y delfines, aliens y demas :__) ) el recordar google.com que 208.69.34.230.
Una vez sepa nuestro Browser que la IP de Google es 208.69.34.230, podra iniciar la conexion con el Servidor de Google. No voy a explayarme demasiado!, solo decir que indiferentemente podriamos haber puesto en el navegador la IP de Google ( 208.69.34.230 ) ahorrandonos asi el trafico DNS; o sea, no se efectuaria en el transfondo el gethostbyname(). Cabe decir tambien que DNS se usara para resolver nombres de dominio o hostnames a IPs.
Resulta que, antes de llegar DNS al mundo, se utilizaba el archivo hosts ( en *NIX bajo /etc/hosts ) como base de datos la cual mapea nombres de dominio/host names a IP. HOy dia se sigue usando, pero no tanto como antes.
O sea, hoy dia si en nuestra Red se usan hostnames, estos hostnames los debera de resolver bien DNS o bien el archivo hosts ( o.. ), siendo lo ultimo mas usual.
Cabe decir tambien que la configuracion del archivo ( en *NIX ) /etc/nsswitch.cof decidira mayormente que se usara primero en estos casos, si DNS o el archivo hosts. Ese archivo nsswitch.conf configurara otras cosas aparte de esto..

Bueno, si hemos de decir que, para poder salir a Inet desde nuestro Browser y asi desde nuestra maquina, normalmente saldremos a traves de nuestro router Gateway. Ah... esto ya esta en Red Local Ethernet! ( normalmente, si es que tenemos un router NAT ). O sea, tenemos nuestra IP privada pongamosle 192.168.1.64, y la IP de nuestro router 192.168.1.254, tambien privada por su Interfaz dedicada a esta Red Local. Aqui digo que los routers suelen ser en su gran mayoria dispositivos Multi Homed, con muchos hogares vaya, porque suelen tener mas de una tarjeta de Red ( Interfaces ) ya que lo que hace es eso, unir distintas Redes usando una Interfaz para cada una ( normalmente! ).

Bueno pues que rollo estoy soltando no?! Pues no. Es simplemente que, para entender bien un entorno, debemos de hacernos el mapa lo mas claro posible en nuestras mentes. Una vez puedas visionar el mapa en tu mente, todo queda muchisimo mas claro! :_) ( aunque a veces entro en loop y nada, que no salgo..! ).

Por donde iba.. ah si, la conexion con el router Gateway para asi poder salir a la Inet.. Pues aqui, ya que la conexion se realiza con la Interfaz de Red que conecta al router con nuestra Red Local Ethernet ( a veces la Red solo consta de un PC en nuestros hogares ), se usara la IP del router, pero su MAC para el direccionamiento! Aqui no entrara normalmente DNS, sino que sera ARP y la MAC final del router la base de la conexion. Tras ello, sera el router, DNS, tablas de enrutamiento, protocolos de enrutacion y enrutados...etc. los que se ocupen de encontrar a Google.
Las respuestas vendran directamente hasta nosotros de la misma manera y, si se utiliza un protocolo orientado a conexion dentro de esa comunicacion, este sera el encargado de mantenerla.

Bien, esto venia a que.. y como sabemos la IP del router?! Pues normalmente esta IP y mas informacion de routeo nos la ofrece DHCP ( Dynamic Host Configuration Protocol ). Este protocolo es el sucesor de BOOTPC. Lo que hace es eso mismo, configurar nuestras maquinas para que sepamos por donde se sale de nuestra Red a otra, y como.. DHCP es otra de las aplicaciones cliente-servidor. El router, tendria el Servidor DHCP, y nuestra maquina el cliente. Este cliente se inicia en el booteo del sistema. Todo esto suele conformar nuestras tablas de routeo, que es precisamente lo que hace en si DHCP, organizar nuestras tablas de routeo Dinamicamente. Digo Dinamicamente porque es asi y porque tambien se pueden organizar manualmente/estaticamente.

Bueno, pues digamos que estamos usando DHCP y que tenemos la IP del router.. ahora si que ARP sabe la IP del router y puede preguntar por su MAC!
Bien.. pero ahora que ocurre cuando quiero hacer un telnet a una maquina dentro de nuestra Red Local Ethernet que no es el router!? Pues debemos de proporcionar nosotros a la aplicacion que estemos usando de Telnet ( en este caso ) la IP destino no?? O sea, estaremos poniendo en nuestra shell ( *NIX ):
# telnet 192.168.1.65
Ya ahi ARP sabra cual es la IP! Solo quedara resolver la MAC y asi empezar la conexion, ya que como dije en una Red EThernet lo que importa es la MAC; siendo asi que ni se tiene por que implementar IP.
Hago un comentario acerca del ARP Poisoning:
este ataque se usa en Redes Ethernet las cuales usan Switches para comunicar segmentos. Que ocurre? Por que se le puede enganiar al Switch? En realidad es eso mismo, se le engania al Switch, ya que este trabaja de modo normal incluso con este ataque.
Lo que ocurre en este ataque es que IP solo tiene informacion para capas superiores, no inferiores! Si el modelo OSI se conforma asi

APLICACION --> Capa 7
PRESENTACION --> Capa 6
SESION --> Capa 5
TRANSPORTE --> Capa 4
RED --> Capa 3
ENLACE DE DATOS --> Capa 2
FISICA --> Capa 1

IP ( Capa de Red, 3 ) solo tiene informacion para las capas superiores.
Recordamos que MAC es un direccionamiento fisico que esta en Capa 2, de enlace de datos.

Pues teniendo esto en cuenta digamos mas sobre ARP. ARP trabaja en Capa 2 tambien, y es un protocolo que fue creado para sencillez dado el medio fisico en el que trabaja. O sea, ARP es stateless/ no orientado a conexion para mas rapidez y mejorar el perfomance de la Red. ARP trabaja con ARP Requests y ARP Replies. Un ARP Request sucede cuando queremos saber la MAC de otro dispositivo a partir de su IP. Un ARP Reply sucede cuando ese dispositivo nos responde.
Para hacer las comunicaciones an la Red Local aun mas rapidas, ARP se vale de una cache; la archiconocida ARP Cache. Es esta la que se envenenara..
Esta Cache cachea/guarda por un tiempo ( ~ 4 secs. ) las relaciones IP-MAC que va resolviendo y que nos llegan en los ARP Replies para mejorar la velocidad de las comunicaciones. Pues por la naturaleza explicada de ARP ( stateless ) ARP aceptara un Reply incluso si no mando un Request desde un principio. O sea, si ARP tiene en su Cache la relacion IP-MAC de un Reply legitimo, digamos:
192.168.1.65 esta en 00:0b:88:69:3b:6a

y nosotros le mandamos un Reply diciendo que:
192.168.1.65 esta en 00:14:5b:88:69:4a

ARP cogera y cacheara nuestro Reply sin rechistar..

Bueno, pues lo que ocurre en un ARP Poisoning es eso, que le mandamos un Reply como el citado cada cierto tiempo ( ~ 3 secs. ) para asi mantener la Cache ARP objetivo envenenada.
Y el Switch?! Que coyons hace dejando que esto ocurra!! Pues el pobre Switch trabaja como siempre.. analicemos.
El Switch es un dispositivo que trabaja en capa 2 del modelo OSI. Este, a diferencia del Hub el cual trabaja en Capa 1 ya que lo que hace es repetir una senial por todos sus puertos, dedica las comunicaciones y el Broadband ya que se basa en direcciones MAC para conmutar las comunicaciones.
O sea, un Switch tiene un tabla en la cual hay direcciones MAC asignadas para cada uno de sus puertos. Si por el puerto/boca 3 tiene en su tabla asignada la MAC 00:aa:bb:cc:dd:ee, cuando capte una trama Ethernet que vaya dirigida a dicha MAC, la mandara por el puerto 3.
Ah.. ya vamos viendo mejor.. Entonces supongamos.. supongamos que Manolito es un personaje en nuestra Red Local, con una maquina con IP 192.168.1.65 y MAC 00:aa:bb:cc:dd:ee. Recordamos que la MAC es una direccion fisica que va en un chip de las NICs, y que IP es una direccion logica que es asiganada mediante software... Bien.. Supongamos que nosotros tenemos una IP 192.168.1.64 y tenemos una MAC 00:ff:gg:hh:ii:jj. Tambien estara el router Gateway ( los routers tiene MAC tambien en cada una de sus NICs! ) con IP 192.168.1.254 con MAC 00:kk:ll:mm:nn:oo ( las MACS se suelen escribir en Hexa, esto no es Hexa! es para hacer el ejemplo mas visual :__))
Pues .. Que ocurriria si nosotros fabricasemos un ARP Reply con un generador de paquetes tipo Nemesis u otro software dedicado y lo dirigimos hacia el PC de Manolito, y en ese Reply le decimos que la IP del router ( 192.168.1.254 ) se encuentra en nuestra MAC ( 00:ff:gg:hh:ii:jj ), y fabricamos otro Reply y le decimos al router que la IP de Manolito ( 192.168.1.65 ) esta tambien en nuestra MAC ( 00:ff:gg:hh:ii:jj ) ??? Pues que ARP se tragara nuestros Replies y sus caches quedaran envenenadas. Estos Replies se enviarian cada ~ 3 secs. ya que las Caches ARP se renuevan cada ~ 4 secs. Bien..

Ahora, fijemosnos.. Las comunicaciones en Ethernet se basan en las direcciones fisicas MAC ( Media Access Control ). Un switch mapea en su tabla direcciones MAC con un puerto de salida determinado ( el cual trabaja en Capa 2 ), y estamos usando un Switches en nuestra Red.. Tambien, un Switch, al trabajar en Capa 2, no se fija en IP!! El switch, solo se fija en la MAC para sus cometidos!
Ah! Entonces, que hara el PC de Manolito cuando quiera conectar con el router Gateway?! Recordemos que la Cache del router esta siendo envenenada cada ~ 3 secs por nosotros.. Pues que al usarse IP en esa comunicacion ( se supone ), la maquina de Manolito ( 192.168.1.65 ) usara ARP para averiguar la relacion IP-MAC y asi poder comunicar mediante la MAC del router con este mismo. Para ello, echara un vistazo a su Cache ARP.. Altorrr!! Pecador de la Praderarr!! Hehe.. nosotros con nuestros Replies, estamos envenenado esa cache!! Asi que en esa fase en la que ARP mira en la cache para formar la trama Ethernet que sera enviada por la Red, esta cogiendo nuestra MAC para la comunicacion de Manolito con el router!!
Bien.. Pues cuando el PC de Manolito ( 192.168.1.65 ) haya fabricado la trama final Ehternet, esa trama ira encabezada con nuestra MAC como destino, gracias a todo lo ocurrido :__).

Pues, y que ocurre con el swtich!!? Pues.. al tan ajetreado switch, le llega una trama mas, y el switch se pone las gafas y mira la Trama Ethernet, que es lo unico que le interesa del paquete y dice... "a ver... hmm.. destino: 00:ff:gg:hh:ii:jj. Pues paya va.." y lo manda por el puerto/boca detinado a nuestra MAC!. Buenoooo!! que acaba de hacer el switch.. dios mio.. nos acaba de mandar a nuestra MAC un paquete de Manolito dirigido al router! Pues el pobre Switch ha trabajado de modo normal, lo unico que hemos enganiado desde un principio a ARP, y el queda enganiado como consecuencia.

Ahora, que ocurre!? Pues que el paquete pasara por nuestra trageta de Red!! Y si ponemos un sniffer?! Pues .. pues veremos el paquete que Manolo mando al router. Aqui debemos de recordar que en las cabeceras IP, si que iba la direccion IP del router; asi que si no configuramos nuestra maquina activando el IP_Forward ese paquete no sera redireccionado a su destino final, el router.
/* Recordemos tambien que con Hub no hace falta hacer ARP Poisoning para sniffar la data ya que este siempre envia los paketes por todas sus bocas/puertos. */

Que ocurre si configuramos nuestra maquina y activamos el IP Forwarding?! Pues con el IP Forwarding nuestro PC actuaria como un router. O sea, en una Red normalmente solo el router tendria activado el IP Forwarding, ya que normalmente no se quieren PCs en la Red que esten direccionando paquetes.
O sea, si lo activamos, cuando nos llegue el paquete que Manolito mando al router, lo leeremos ( sniffer ) y lo remandaremos ahora si a su destino legitimo, el router.
Para este reenvio se usara la MAC del router legitima desde nuestra maquina.
Que no tenemos la MAC del router? Pues entrara ARP de nuevo en accion.
ARP manda a traves de un Broadcast ( la Redes Ethernet son Redes de Broadcast, con un Switch se reduce el envio de Broadcast, pero no se elimina! ) una peticion a todos los nodos/maquinas de la Red preguntando ahora "hey, quien tiene la MAC de 192.168.1.254?? que me responda en 00:ff:gg:hh:ii:jj!!".

Ahora, recordemos que estabamos envenenando la cache del router tambien! Pues, si Manolo mando un paquete al router, paquete que nos llego a nosotros y redirigimos mediante el Forwarding hacia el router.. cuando el router traiga el paquete de vueltas a Manolo, y quiera mandar la trama ethernet a la MAC de Manolo, tambien fabricara una trama envenenada ya que estamos envenenando su Cache ARP tambien. Que locura! Nada nada.. que esas respuestas pasaran tambien por nuestra NIC, la leeremos o lo que sea, y sera redireccionada mediante el Forwarding hacia Manolo correctamente.
Si se observa, estamos justo el el medio de la comunicacion, leyendo los paquetes que se mandan y redireccionandolos finalmente hacia sus destinos finales..

Bueno, no era la intencion el explicar todo eso, pero al final surgio.

El caso es que tu dices que quieres hacer IP Spoofing en Red Local, Spoofear la IP de Manolo ( :__) ) y conectarte al router con la IP de Manolo..
Dijimos que con conectarte usarias un protocolo como TCP seguramente.
Para el IP Spoofing usarias algun softare o programarias algo tu mismo.
Ahora no voy a explicar como funciona TCP ni a grandes rasgos, pero si mencionar que para hacer lo que dices fuera del alcnace de tu Red, deberias saber algo mas sobre TCP y sus sequence numbers..

El caso es que quieres hacer IP Spoofing de manera Local, asi que deberias de tener en cuenta toda la parrafada soltada, ya que por mucho que te cambies la IP, en Ethernet cuenta como base la MAC como direccion fisica!
Por ello, si te cambias simplemente la IP y tratas de conectar con el router con la IP de Manolo y mediante TCP, bien hasta que el router quiera responder. Ahi el router veria que tiene que responder a la IP de Manolo, y preguntaria por la MAC de Manolo para direccionar al trama. Si no has envenenado, la trama se dirigira finalmente a la MAC de Manolo. El PC de Manolo recibira la trama y mirara el paquete. Al ver que el destino no es su propia IP descartara el paquete o, si tiene el IP Forwarding ( que no lo creo ) activado lo reenviara hacia ti. Esto ultimo, es bastante irreal.

Pienso ( me gustaria comprobarlo! ) que igualmente deberias de cambiarte la IP a la IP de Manolo. No bastaria con mandar un paquete con la IP Spoofeada de Manolo para que cuando el router te responda ad ti gracias al ARP Poisoning ( y a que estas en Red Local ), la IP destino no corresponda y el pqeute quede descartado.
La conexion simplemente, no se estableceria.

Bueno, te deseo Suerte y te animo a que vayas comentado como te va, y si he tenido razon en esto ultimo.

P.D: No tiene por que llamarse Manolo!

P.D2: Ah.. supuse lo del switch creo! :__) Hmm.. si no hay switch habria que
envenenar igualmente, ya que la conexion se dara a nivel TCP pero el envio
se hara via MAC. O sea, se supone que tu spoofeas la IP y tal, mas el router
enviara igualmente la trama a la MAC de la IP de Manolito, aunque con un Hub
podrias "solamente" sniffar este trafico, si no haces ARP Redirection.

Lo que a ti te interesa es establecer una conexion ( TCP ) creo con el router
teniendo la IP de Manolito, asi que para que TCP se conecte con exito deberias
de cambiarte la IP igualmente. /* en *NIX con ifconfig mismamente */

P.D3: Hay algo que hmm.. tendria que comprobar :_). O sea, no se si tendrias que
envenenar la cache del router.. Yo creo que cuando le enviamos el pakete en
la trama Ethernet ira nuestra source MAC, la cual siempre va en los primeros
6 bytes creo.. Entonces, creo que el router usara la MAC de ese pakete, no??
Otra cosa es cuando se quiere iniciar la comunicacion, y no se tiene la MAC
destino, pero si la IP...
O utilizara su Cache directamente?? pero .. si imaginamos que el router en
cuanto recibe el pakete, actualiza la cache con la MAC source del pakete que
le llega, igualmente no habria que envenenar... ?? Pero no lo veo tan claro,
ya que el modulo ARP actualiza su cache ante un ARP Reply, cosa que aqui
no se da.. Este PD3 yo lo dejaria en modo paranoia!