Manual del IP spoofing

Tema en 'Guías y Tutoriales' iniciado por KurtCobain, 2 Jun 2007.

  1. Kur

    KurtCobain
    Expand Collapse
    Cabo

    Mensajes:
    104
    Me Gusta recibidos:
    0
    Manual del IP spoofing


    Que es el Spoofing?
    -------------------
    El spoof tradicional es cuando los'atacantes' falsean el origen de los
    paquetes haciendo que la victima piense que estos son de un host de confianza o autorizado
    para saltar un firewall o que la victimas no nos detecten.

    TCP y IP spoofing
    ------------------
    Centremonos en Nuestro server (linux/unix/Bsb) que protege varios servicios al mismo tiempo
    atravez de los ya conocidos Tcp Wrappers y con herramientas tipo Firewalls que protegen
    toda una RED.

    La mayoria de estas herramientas protege, comparando Host y IP y utilizandolos para identificarlos
    por ejemplo los archivos /etc/host.allow y /etc/host.deny.


    /etc/host.allow
    (supongamos que es una red local y yo 192.168.0.1 soy el server y nada mas quiero
    que ellos usen mis servicios)
    AllowHosts
    caos.ezkracho.com.ar,192.168.0.2
    kuazar.ezkracho.com.ar,192.168.0.3
    bach.ezkracho.com.ar,192.168.0.4
    giba.ezkracho.com.ar,192.168.0.5
    hellraiser.ezkracho.com.ar,192.168.0.6

    /etc/host.deny
    (estos son los que no quiero que usen mis servicios)
    DenyHosts
    gerente.ezkracho.com.ar, 192.168.0.7
    cinic.ezkracho.com.ar, 192.168.0.8
    sperman.ezkracho.com.ar, 192.168.0.9

    pero tambien se pueden poner rangos de ip tipo 200.0.212.* o 200.*.*.*

    Vamos a un caso de spoof basico
    -------------------------------
    Supongamos bach.ezkracho.com.ar esta corriendo un NT server con wingate y cinic.ezkracho.com.ar
    que quiere entrar a mi server, pero no tiene acceso a mi server, entonces cinic hace:
    $telnet 192.168.0.4 23
    wingate>192.168.0.1 21...conected
    200 Ezkracho Server (wu-ftp 6.9) on host powertech.ezkracho.com.ar
    ---------------
    Bienvenido Ezkracho Server
    ---------------
    ftp>user ftp
    331 Anonymous access allowed, send identity (e-mail name) as password
    pass email@email.com
    230 Anonymous user logged in.

    0-----0
    Ataque Spoof de numeros secuenciales
    ----------------------------------
    Tenemos un Webserver y tenemos al CLASICO atacante, vamos a dar el servicio rhosts que
    es un buen ejemplo porque rhosts hace una conexion de confiansa entre dos makinas porque
    tiene 'autentificacion remota'rlogin,rsh,rcp y rcmp porque los usuarios que tienen acceso a estos
    servicios son confiados y estan autorizados a entrar a: systema local sin passwd

    un ejemplo del archivo .rhosts
    node1.ezkracho.com.ar caos
    node2.ezkracho.com.ar kuazar
    node3.ezkracho.com.ar giba
    node4.ezkracho.com.ar bach
    node5.ezkracho.com.ar hellraiser

    Cuando el circuito virtual esta establecido,los dos hosts tienen que tener iguales
    maneras de verificacion que los datos sean transferidos limpiamente.
    Por esto TCP usa en (ingles) sequence numbers. TCP le asigna a cada paquete un numero como
    index identificatorio. Los dos hosts usan este numero para chequear errores y reportarlos. Es
    mas, este proceso de pasar los numeros secuenciales cuando el circuito ya esta establecido.
    El siguiente articulo fue escrito por Rik Farrow que explica el sistema de numeros secuenciales.

    La secuencia es usada para aceptar los datos que llegan. Al principio de la conección, el cliente
    que manda los paquetes TCP con un numero en secuencia inicial, pero no certificada (no puede haber
    una ahora). Si la aplicacion del server esta corriendo del otro lado de la coneccion, el server
    manda de vuelta el paquete con su propia inical de numero secuencial desde el paquete del cliente mas
    uno. Cuando el sistema cliente resive este paquete, lo debe mandar de vuelta con su propia
    confirmacion: el numero inicial del server mas uno.

    El atacante tiene dos problemas el primero es cambiar la direccion y la otra es mantenerla secuencia en el
    dialogo con la makina victima, el segundo es el mas complica el ataque ya que el numero secuencial ya
    que el cambio del mismo no es arbitrario.

    Si el atacante adivina correctamente el numero, este puede sincronisarse con la victima y iniciar
    una sesinon. Desde ahora la makina del atacante quedavinculada a la makina victima como un host de
    confiansa, y puede iniciar conecciones tipo rhosts asi pude logearse.

    Un caso de ataque secuencial
    -----------------------------
    Aplicacion:mendax para linux
    lenuage:c
    http://esperosun.chungnam.ac.kr/-jmk...ndax_linux.tgz
    Para usarlo tenemos que hacer
    gunzip mendax_linux.tgz
    tar -xvf mandax_linux.tar
    make
    ./mendax
    estas son las opciones
    -p Port
    -s Port
    -l Username
    -r Username
    -c command
    -w Port
    -d
    -t
    -L TERM
    -S PORT
    ahora mi objetivo es ejecutar el comando rsh desde 192.168.0.8 a 192.168.0.1 spoofeando me por
    192.168.0.2 ,el commando que quiero ejecutar es:
    mv .rhosts .r; echo + + > .rhosts
    para spoofearme
    [root@gerente># mendax -p 514 192.168.0.2 192.168.0.1 -l caos -r caos
    Flooding sourse con TCP SYN packets from 192.168.0.8
    samplin secuense numbers
    seq number: 816640001, ack number: 64001 difference:64000
    seq number: 816640001, ack number: 128001 difference:64000
    seq number: 816640001, ack number: 192001 difference:64000

    using 64000 as prediction difference (3 hits)
    spoofing rshd
    reseting TCP target connection:
    reseting source: ..............
    [root@gerente>#
    para ver si funciono
    ls -l .r*
    -rw-r--r-- 1 caos user fecha .rhosts
    el archivo rhosts tiene que tener en el ++
    y deaspues en el log aparece
    fecha gnss rshd: caos@192.168.0.2
    ================================================== ============================
    En el proximo capiulo explicare
    Como prevenir el IP spoofing, ARP spoofing, DNS spoofing, y Spoof estra;os
    ================================================== ============================
    Bibliografia
    RPC 325
    Robert Morris Theorie
    M.i.t
    ________
    _/ezkracho\_________________________
    Texto hecho por Powertech *
    skydarck@zonagamerz.com *
    Ezkracho Team *
    http://www.ezkracho.piratas.org *
    ___________________________________*


















    /|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\
    \|/ \|/
    /|\ /|\
    \|/ \|/
    /|\ IP-Spoofing pero muy, muy, muy facil. /|\
    \|/ ------------------------------------- \|/
    /|\ /|\
    \|/ por Caos - Ezkracho Team \|/
    /|\ /|\
    \|/ \|/
    /|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\
    \|/ \|/
    /|\ mail: skydarck@zonagamerz.com /|\
    \|/ \|/
    /|\ web: www.ezkracho.com.ar /|\
    \|/ www.ezkracho.piratas.org \|/
    /|\ /|\
    \|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/







    -----------------------------------------------
    Este texto esta escrito dentro de los primeros
    "127" caracteres del codigo ASCII para evitar
    posibles errores al visualizarlo; por lo que no
    se usaran acentos y la "enie" se pondra como ~.
    -----------------------------------------------




    T E M A R I O

    0. Introduccion.
    1. Que es el IP-Spoofing ?
    3. Un poco de TCP/IP.
    4. Como funciona el IP-Spoofing ?
    5. Comentario final.



    0. Introduccion.


    El objetivo de este texto es simplemente que podamos entender que es
    el IP-Spoofing y para que sirve a un nivel muy basico. Este texto va
    dirigido para quienes todavia no tienen muchos conocimientos sobre
    las artes del Hacking, asi que no esperen despues de leer esto
    convertirse en unos "Spoofer's Master's" o algo asi, espero que con
    suerte puedan comprender que es el IP-Spoof.
    Si una vez comprendido todo esto desean avanzar mas sobre el tema hay
    muchos textos con una explicacion mas tecnica que pueden conseguir,
    entre ellos algunos escritos por el Ezkracho Team.
    Tambien quiero pedir disculpas por las animaladas que voy a cometer
    al intentar explicar esto, ya que voy a hacer todo lo posible para no
    entrar en tecnicismos y hacer que esto sea accesible para todo el
    mundo.
    Como siempre cualquier comentario, consulta o critica me la pueden
    hacer a esta direccion de correo: skydarck@zonagamerz.com




    1. Que es el IP-Spoofing ?


    El IP-Spoofing es basicamente el aprovechamiento de una relacion de
    confianza entre dos "trusted hosts".
    Supongamos que nosotros trabajamos diariamente en un server llamado
    CAOS y tambien lo hacemos diariamente en otro server llamado RAXR,
    veran rapidamente que seria muy molesto tener que estar a cada rato
    telneteando a CAOS para ingresar el user y el pass, y luego
    deslogueandonos para telnetearnos a RAXR para volver a poner el user
    y el pass, y si tenemos que hacer distintas tareas secuencialmente en
    cada uno de los servers directamente nos queremos matar. Bueno, para
    evitar una serie de suicidios en masa se invento el concepto de
    "trusted hosts", o podriamos traducirlo como "hosts de confianza";
    que quiere decir esto.. que si yo soy un usuario del servidor CAOS y
    tambien lo soy del servidor RAXR y no quiero estar logueandome a cada
    rato en cada uno de estos servidores, pues establezco una relacion de
    confianza entre ambos (trusted hosts) con lo cual yo estando logueado
    en CAOS puedo pasar directamente a RAXR usando un comando y sin
    necesidad de desloguearme ni poner contrase~a; en sistemas *nix el
    comando que se utiliza para pasar de un server a otro es "rlogin".
    Bueno, ya se estaran dando cuenta por donde viene esto del IP-Spoofing;
    vamos a explicarlo de la forma divertida, ahora yo soy el sujeto "X"
    que quiero entrar al server RAXR aprovechando la relacion de confianza
    que tiene con CAOS, lo que hago es ir al server RAXR y decir que soy un
    usuario de CAOS y como habiamos quedado el otro dia en que eramos
    "trusted hosts" me tenes que dejar pasar, y como el servidor RAXR
    verifica que evidentemente venimos del server CAOS nos dice "pasa que
    esta todo bien".
    Una cosa que tenemos que tener en cuenta es el que el IP-Spoofing no es
    un ataque, es solo un paso en el ataque; porque digo esto, porque si el
    sujeto "X" entra a RAXR diciendo que es un usuario de CAOS, estariamos
    en el server RAXR pero con los privilegios que tenia ese usuario, una
    vez estando en RAXR tendriamos que buscar la forma de hacernos "root"
    si es que ese es nuestro objetivo.




    2. Un poco de TCP/IP.


    El IP-Spoofing es una tecnica muy complicada ya que necesita de un
    amplio conocimiento del protocolo TCP/IP. Siendo que no es el
    objetivo de este texto entrar en el ambito tecnico no me extendere
    mucho en la explicacion del protocolo, al que le interese saber mas
    sobre esto puede buscar en el RFC 1180.

    El TCP/IP es en realidad 2 protocolos que estan unidos, el TCP
    (Transmission Control Protocol) es el encargado de las comunicaciones,
    y el IP (Internet Protocol) es el encargado de enviar los paquetes.

    El IP a diferencia de los protocolos "seguros" no esta orientado a la
    conexion, lo que se puede decir que hace el IP es encargarse de mandar
    los datos pero sin saber si llegan o no.

    EL protocolo IP tiene varios campos de 32 bits en los que se almacena
    diferente tipo de informacion como ser las direcciones de origen y
    destino, la longitud del paquete, la version del protocolo, etc.
    Todos estos campos los podemos modificar facilmente y podemos encontrar
    muchos programas para hacerlo.

    Dentro del TCP/IP, el TCP es el protocolo mas seguro y es el que se
    encarga de que se haga la conexion.
    El TCP estable la conexion utilizando un proceso denominado "saludo de
    las tres direcciones" (traducido es algo asi) y como habran deducido
    consta de tres pasos:

    1. CAOS ---SYN--> RAXR
    2. CAOS <--SYN/ACK--- RAXR
    3. CAOS ---ACK--> RAXR

    Aqui vemos como el server CAOS quiere establecer una conexion con el
    server RAXR y le envia un indicador SYN, luego RAXR autentifica con un
    SYN/ACK, y CAOS le vuelve a confirmar con otro ACK.
    A todo esto, en el SYN enviado por CAOS ya aparece el "numero de
    secuencia" que al ser lo primero en enviarse se lo llama ISN (Initial
    Secuence Number) y es diferente en cada paquete; cuando RAXR responde
    con el SYN/ACK tambien le envia su ISN, y por ultimo cuando CAOS vuelve
    a responder con un ACK envia el ISN que le habia enviado antes RAXR pero
    sumandole 1 (osea ISN+1).

    Podemos simplificar todo este "saludo de las tres direcciones" que sirve
    para iniciar una conexion de esta forma:

    1. CAOS: Hola! te puedo mandar algo ?
    2. RAXR: Si, me lo podes mandar, me lo mandas ?
    3. CAOS: Si, ahora te lo mando.




    4. Como funciona el IP-Spoofing ?


    Muchos estaran pensando que despues de todo lo unico que tenemos que
    hacer es buscar algun programita que cambie nuestra direccion IP y
    listo, logramos spoofearnos y conseguimos la muy codiciada shell en
    nuestro objetivo, pues no

    Recordemos que para establecer una conexion debemos saber el ISN de
    nuestro objetivo (RAXR), puesto que de lo contrario no podremos
    responderle a su SYN/ACK, y nosotros al estar falsificando una
    direccion IP (CAOS) no recibimos ninguna respuesta de la victima,
    estamos totalmente ciegos; aparte ahora surge un nuevo problema ya que
    el host CAOS va a estar recibiendo datos de RAXR hablandole sobre una
    conexion, y CAOS al no entender nada de esto va a terminar el dialogo
    con RAXR y aqui se termino nuestro ataque.

    Bueno, veamos ahora cuales son los pasos que deberiamos seguir para
    lograr un IP-Spoof exitoso:

    1. Elegir un host victima.
    2. Buscar algun trusted host de nuestra victima.
    3. Desactivar el trusted host.
    4. Conseguir los numeros secuenciales (ISN) de la victima.
    5. Usurpar la identidad del trusted host (Spoofearse!).

    Y si hacemos las cosas bien habremos vencido a nuestra victima.

    Ahora veamos mas en profundidad cada uno de estos pasos, salvo el 1
    que cada uno sabra porque y para que elegir la victima

    2. Encontrar un trusted host de nuestra victima puede ser algo para
    nada facil, pero algunas de las cosas que podemos hacer para
    conseguirlo es un "showmount -e" para ver adonde se exportan los
    archivos del sistema, o usar el comando "rcpinfo" que nos puede dar
    informacion muy interesante.

    3. Supongo que ya sabran la necesidad de desactivar al trusted host,
    puesto que si no lo hacemos a CAOS le va a llegar el SYN/ACK en
    respuesta al SYN que envio X suplantando a CAOS.
    Bueno, y como desactivamos a CAOS ? lo hacemos facilmente mediante un
    "SYN Flooding"! Vamos a suponer que ya todos alguna vez hemos
    floodeado a alguien y conocemos la teoria del flood asi que el
    proceso es simple enviamos SYN consecutivos al puerto TCP que
    queramos desactivar y nos aseguramos de que de la direccion IP de la
    que estamos enviando el ataque sea un host inalcanzable, osea hacemos
    un spoof antes de floodear, para que si CAOS en una de esas alcanza a
    mandar un SYN/ACK a la IP de la que vienen las peticiones SYN, que
    esta no desactive la conexion puesto que no sabe de que se trata y nos
    arruine todo nuestro noble floodeo.

    4. Como ya habiamos dicho al principio necesitamos saber el ISN de
    nuestro objetivo para terminar la conexion, puesto que a nosotros no
    nos llega el SYN/ACK de RAXR con el ISN de este, y sin este ISN que
    envia no podemos mandarle el ACK con el ISN+1; espero que todavia
    recuerden "el saludo de las tres direciones" y todo lo que me gaste
    explicando mas arriba..
    Bueno y como conseguimos el ISN (o numeros secuenciales) de nuestra
    victima ?? lo que hacemos es lo siguiente, nos conectamos a un puerto
    TCP de nuestra victima (como ser el SMTP), todo esto lo hacemos justo
    antes de iniciar nuestro ataque, y completamos "el saludo de las tres
    direcciones"; este procedimiento es el normal que ya conocemos pero
    con la sola excepcion de que ahora nos vamos a guardar el ISN de el
    otro host Este proceso ("el del saludo..." es factible que se
    repita varias veces y recien se guarde el ultimo ISN que nos envie,
    tambien nos sirve para poder calcular el tiempo de ida y vuelta (osea
    cuanto tarda) entre la victima y nosotros.

    5. Aqui hemos llegado al ultimo paso, a la etapa en la que la totalidad
    del IP-Spoofing es completado. Veamos como seria:

    a). CAOS(X) ---SYN--> RAXR
    b). CAOS <--SYN/ACK--- RAXR
    c). CAOS(X) ---ACK--> RAXR
    d). CAOS(X) ---PSH--> RAXR

    Primero lo que hacemos es spoofearnos para que X tome la identidad de
    CAOS y aproveche la relacion de confianza que tiene con RAXR; en este
    paso X envia un SYN al puerto 513 para entablar una conexion con RAXR
    diciendo que viene de CAOS.
    Segundo RAXR recibe nuestro SYN que supuestamente viene de CAOS y le
    manda a este un SYN/ACK, por supuesto que este SYN/ACK nunca le va a
    llegar a CAOS porque le estamos haciendo un "SYN Flooding" y no va a
    dar abasto para atender a lo que le dice RAXR, en el caso que si
    atendiera a CAOS este terminaria la conexion y nuestro ataque habria
    finalizado.
    Tercero esperamos un poco a que RAXR le envie el SYN/ACK a CAOS, cada
    uno sabra como hacer esta prediccion en base a los datos adquiridos,
    y una vez transcurrido este tiempo nosotros "X" le enviamos a RAXR un
    ACK con el ISN de RAXR que ya antes habiamos conseguido mas 1, osea
    ISN+1.
    Cuarto paso, si acertamos en todas nuestras predicciones RAXR habra
    aceptado nuestro ACK, la conexion se habra establecido y comenzara la
    transmision de datos !!




    5. Comentario final.


    Vamos a aclarar que toda la tecnica de IP-Spoofing explicada en este
    texto es muy basica, y como dije al principio va dedicado para entender
    el concepto a un nivel de conocimientos bajo.
    Posiblemente se pregunten como realizar muchas de las tecnicas
    explicadas aqui, para todo esto hay muchos programas que nos van a
    facilitar la tarea y que los pueden conseguir en cualquier parte de la
    red. Pero igualmente no olvidemos que todo esta en la buena prediccion
    que hagamos, y cuanto mayor conocimientos sobre el Spoof y el TCP/IP
    tengamos nuestra prediccion va a ser mucho mas certera.
    Por ultimo quiero decir que el IP-Spoof es solo una de las muchas
    formas que tiene el Spoof, explique esta porque me parece que es la
    mas general y la que puede ayudar a entender otras mas complejas y
    por supuesto el concepto en si mismo.

    Bueno, espero que hayan disfrutado en leer este texto tanto como yo
    en escribirlo. Y ya saben cualquier comentario, consulta o correccion
    la pueden hacer a ezkracho@hotmail.com


    Hasta la proxima, CAOS.

    |En WIN visualisar con "wordpad"|
    ___________________________________________
    / -=Spoofing N-2=- /
    / /
    /By Powertech 5/5/1900 /____________
    / skydarck@zonagamerz.com /Hecho con /
    / /UW PICO 3.5 /
    /Ezkracho Tm / -----------/
    /Http://www.ezkracho.com.ar / _|____________________
    \__________________________________________\ /Yeah My ASCII Art SUX/
    ---------------------
    ---[Indice>
    /
    [Palabras del autor ............1>
    \
    [ARP spoofing ..............2>
    /
    [DNS spoofing ..................3>
    \
    [Previniendo IP Spoof.......4>
    /
    [Previniendo ARP Spoof..........5>
    \
    [Previniendo DNS Spoof......6>
    /
    [Palabras Finales...............7>
    \
    [Comunicate con el autor....8>
    /



    "Pain made to order!"
    Slipknot


    ----[1>[Palabras del Autor>

    Bueno este texto esta dedicado a todas aquellas personas
    Interesadas en la Seguridad Informatica, Admins de Redes.
    Vamos a tocar Varios temas relacinonados con el Spoofing
    y como prevenirlo en plataformas *NIX en general
    que pueden ser Linux 2.2.x, OpenBSD, FreeBSD y BSD en general.
    Los usuarios del sistema operativo Windows/9x/NT/2k
    estan casi desprotegidos totalmente, salvo si estan atras
    de algunas de las plataformas nombradas o de un Router o/y
    Firewall.
    Bueno, espero que lo disfruten igual que lo disfrute escribiendolo.

    Powertech.


    ----[2>[ARP Spoofing>

    ARP Spoofing es la variacion de IP Spoofing porque explota una debilidad
    del protocolo TCP/IP.
    ARP "authentification" es tambien basado en la "Source Adress" direccion
    de donde provienen los paquetes, lo que lo diferencia a ARP es que se fija
    en una direccion en el Hardware.

    Para verla, lo hicelo siguiente :

    [toor@powertech toor># ifconfig eth0
    ne2k-pci.c: PCI NE2000 clone 'Winbond 89C940' at I/O 0x6400, IRQ 9.
    eth0: Winbond 89C940 found at 0x6400, IRQ 9, 00:00:E8:57:82:6B.<-\
    eth0 Link encap:Ethernet HWaddr 00:00:E8:57:82:6B <--------|Hwaddr
    BROADCAST MULTICAST MTU:1500 Metric:1
    Interrupt:9 Base address:0x6400

    Para los que quieren saber exactamente que es la HWaddress: son valores
    unicos, que estan "quemados" en tu targeta de red por el fabricante, que
    identifica tu direccion fisica. Estas consisten en 48-bits
    (12 caracteres).
    Un ejemplo de una direccion de hardware es esta:
    HWaddr 00:00:E8:57:82:6B

    Si no estan conformes lean HWAddress HOWTO
    http://network.uhmc.sunysb.edu/hdw_addr


    ARP significa en ingles "Address Resolution Protocol". ARP resuelve la IP
    a una direccion fisica. Cuando un host quiere una sesion, manda para
    afuera un ARP broadcast llevando la IP de su objetivo deseado. Sin
    embargo, por conveniencia, nuestro sistema crea lo que se podria llamar
    "ARP cache" asi la maquinas se pueden conectar a Host conocidos mas
    rapidamente sin hacer un broadcast. Es con este cache que los atacantes
    pueden utilizarlo para spooferase ya que lo que guarda es la hardware
    address.


    En el ARP spoofing, el atacante mantiene su HWaddress pero asume el IP de un
    trusted Host, para hacerlo el atacante manda "la informacion de mapeo"
    al objetivo y al cache. Desde ese punto, los paquetes provenientes del objetivo
    son ruteadas hasta la HDaddress del atacante.
    Desde ahora el objetivo piensa que el atacante es un trusted host.





    ----[3>[DNS spoofing>

    DNS spoofing es cuando el atacante compromete al Domanin Name Server
    (DNS) y altera la tabla con los Hostnames y IP.
    Estos cambios son escritos adentro de la base de datos de traduccion del
    DNS server. Cuando el cliente hace un nslookup a un host el DNS le da la
    IP y tambien el reves, esta direccion queda en la manos del atacante.
    Normalmente ejemplo:

    [toor@powertech toor># nslookup www.ezkracho.com.ar
    Server: relay3.impsat1.com <|____Nuestro DNS
    Address: 200.31.1.8 <------|

    Non-authoritative answer:
    Name: www.ezkracho.com.ar
    Address: 63.65.251.8

    [toor@powertech toor># nslookup www.yahoo.com.ar
    Server: relay3.impsat1.com <|____Nuestro DNS
    Address: 200.31.1.8 <------|


    Non-authoritative answer:
    Name: ar.yahoo.com
    Addresses: 200.49.66.82, 200.49.66.83
    Aliases: www.yahoo.com.ar, ar.rc.yahoo.com

    Pero supongamos que el atacante ingresa al DNS de impsat y con un programa
    que automatize la tarea de cambiar. Si alguien busca www.yahoo.com
    el DNS le ponge el IP de ezkracho.com.ar, redirecionandolo.
    Un ejemplo de estos tipo de programas es el paquete de ADM se llama
    ADMidpkd.tar.gz.

    Con este programa, tambien si estas en LAN podes poner en funcion el
    snifer sin igresar al DNS ya que trabaja igual que un snifer normal
    pone la tarjeta de red en modo promiscuo e intersepta el paquete del
    Query y lo cambia haciendo lo que comente antes.

    "hackeado" ejemplo:

    [toor@powertech toor># nslookup www.yahoo.com.ar
    Server: relay3.impsat1.com
    Address: 200.31.1.8

    Non-authoritative answer:
    Name: ar.yahoo.com
    Addresses: 63.65.251.8 <-------IP de ezkracho
    Aliases: www.yahoo.com.ar, ar.rc.yahoo.com

    Y entonces todos aquellos que usen el DNS de impsat y quiera ir a yahoo
    veran la pagina de ezkracho.
    En el paquete de programas que le comente de ADM hay un sniffer que ante
    CUALQUIER request o query, o como lo llamen lo mandara a ezkracho*.
    *A la direccion que elijamos.

    Tambien hay varios programas mas:

    -=Jizz=-
    author: unknown
    OS: *NIX ,MS-DOS

    -=ERECT=-
    author: Johan y Dioxide
    OS:*NIX

    -=Snoof=-
    authorOC_Chaos [RoC>
    OS:*NIX

    Los pueden bajar en:
    http://www.anticode.com





    ----[4>[Previniendo IP Spoofing>

    -Nota-
    Para los que no saben de que se trata el IP spoof ni para que sirve,
    tienen dos textos muy buenos que se llaman "Spoofing muy pero muy facil"
    de mi amigo CAOS y tienen el numero 1 de este texto "Spoofing N-1" de
    Powertech .

    La mejor manera de prevenir estos ataques son:

    -Restringir direcciones locales que vengan de la afuera de nuestra RED.


    -Intentar no tener Trusted Host.

    -Utilizar SYN Loggers asi se podra detectar si alguien intenta Hacerle un
    DoS a tu maquina, se preguntaran y porque un SYN logger, bueno porque este
    ataque es el mas efectivo contra sistemas *NIX, y asi pueden tomar su
    "identidad".

    -Utilisar Firewall que trabajen con los modulos del kernel y no un soft
    que escucha puertos, firewalls recomendados:

    * IPchains
    * IPfwadm
    * IP filter

    (Si no saben utilizar IPchains les recomiendo que lean del HOWTO que viene
    con su distro.)

    - Activar el modulo del kernel rp_filter, en muchas distros lo activan
    por default por ejemplo Debian, lo que tienen que hacer es poner en
    /etc/rc.d/rc.local la siguiente linea:
    echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

    Esto tiene que utilisarce con IPchains.


    -Filtrar servicios que son vulnerables a este ataque por ejemplo:

    * X Windows
    * Servicios R, (rlogin, rsh. rexec)
    * Servicios RCP
    * TCP Wrappers
    * Cualquier servicio que use IP para autentificar


    -Utilisar sevicios con encriptacion integrada ejemplos:

    * OpenSSH
    * OpenSSL
    * SSH
    * SSH2
    * FtpSSL

    Ya que con conectarse a un puerto y al recibir un par de paquetes se puede
    calcular secuencia TCP y se puede Spoofear el Servicio.
    Ademas las conexiones no podran ser "Snifeadas" esto significa que no
    podran capturar los paquetes, que pueden llevar los datos del login.






    ----[5>[Previniendo ARP Spoof>


    Ya les explique como es esta ataque aca vemos como protegernos del mismo.
    Hay muchas maneras de defenderse de esto, la mejor manera es grabar
    nuestra HWaddr en piedra, pero seria algo incomodo.

    Los ataques de ARP spoofing son muy limitados en muchas maneras. Una
    de la maneras es que las nuevas tarjetas de red le hacen un update al
    cache mas o menos cada 5 minutos haciendo que el ataque no sea de gran
    riesgo a una red.

    "ARP": Una Herramienta para manipular tablas de ruteo. ARP, te permite
    interactuar y manipular el cache de arp, aca voy a explicar como usar esta
    herramienta:

    -----------------------------------------------------------------------------
    Opcion | Funcion |
    ----------------------------------------------------------------------------|
    -a [hostname> | Specifica un host en particular al |
    | que le queres hacer el query. |
    | |
    -d [hostname> | Borra una entrada a un Host en |
    | particular. |
    | |
    -f [archivo de conf.> | Archivo de configuracion. |
    | |
    | |
    -a [hostname> [address_type> | Specifica la HWaddr al Host seleccionado. |
    | |
    | |
    -t [type> | Para las distintas tipo de entrada por ejm: |
    | ether, ax25, arcnet, and pronet (token ring)|
    | |
    | |
    -v | Para activar el modo Verbose |
    -----------------------------------------------------------------------------

    Si igual quieren estar seguros que no les hagan este ataque instalen en su sitema
    "ARPwatch" que observa los cambios de IP/Ethernet, se se detectan cambios o
    nuevas direcciones este programa le envia un mail al root.





    ----[6>[Previniendo DNS Spoofing>


    DNS spoofing en muy facil detectar. Si sospechas de tu DNS, hace nslookup
    desde varias maquinas de tu red fijarse en los prosesos , en la tabla cron
    para ver si estan corriendo un programa "desconosido" o si lo inicia y
    fijarse si su tarjeta de red esta en modo promiscuo, Salvo si tu DNS haya
    sido comprometido por algun tiempo
    va a ser rapidamente decubierta ya que si esto es hecho en un ISP los
    usuariose quejaran.

    Pero revisando las maquinas capas no puede ser suficiente, por eso
    recomiendo que utilisen este fabuloso programa, este se llama DOC
    (Domain Obsenity Control) que viene con mucha documentacion.

    DOC es un programa que diagnostica tu DNS mandando distintos Querys
    y despues analisa el contenido de lo obtenido, DOC lo pueden bajar de:
    http://coast.cs.purdue.edu/pub/tools...doc.2.0.tar.gz





    ----[6>[Palabras Finales>


    Bueno este es el final de mi texto, espero que lo hayan disfrutado
    y haber podido implementar lo que explique.

    En este texto ayudaron:
    Inspiracion musical : Slipknot, Cypress Hill, KoRn y 2pac

    Inspiracion comestible: Hamburgesas de McTonto's (aprovecho para
    agradecele a mystify por contarme de que eran las hamburgesas ),
    Huevos de pascua vencidos

    -[saludos>-
    Les mando un saludo a la gente de #linux no voy a nombrar gente
    porque me voy a olvidar de algunos y se calientan en cambio asi
    estan todos felices.

    Saludos especiales a:

    CAOS \
    GiBA \_Ezkracho Team
    Bach /
    [Hellraiser> /

    (Creo que todo esto sono muy cursi, ja)

    "Lo unico seguro
    es la inseguridad"


    ----[7>[Comunicate con el autor>

    Si queres contactarte conmigo o preguntarme algo podes encontrame en los
    siguientes lugares:

    Mail: skydarck@zonagamerz.com
    Web: http://www.ezkracho.com.ar , en el Forum
    Irc: irc.ciudad.com.ar #linux
    ICQ: 20484186




    --------------------------------------------------------------------------------

    - = [ Un vistazo corto del IP spoofing : PARTE I > =-
    -= [ Parte de 'El Proyecto Packet'> =-

    (Incluye fuente para Linux 1.3.X y kernels siguientes)
    Todo texto y codigo fuente escrito por Brecht Claerhout (Derechos de copia 1996)
    Todo codigo fuente probado en Linux kernel 2.0.X
    Todos los packets capturados con Sniffit 0.3.2 (pre-release en ese tiempo)
    -----------------------------------------------------------------------------------------------

    PARTE I: Spoofing simple (No blind)
    ------------------------------------

    0. Introduccion
    0.1 Que
    0.2 Para Quien
    0.3 Disclaimer
    0.4 Licencia

    1. Explicacion corta de algunas palabras

    2. Descripcion del codigo fuente
    2.1 fuente incluida
    2.2 Notas del programador

    3. TCP/IP (UDP) en una hazelnutshell

    4. Non-Blind spoofing
    4.1 Saber que estas haciendo
    4.2 SYN flooding
    4.3 killing la conexion
    4.3.1 Usando reset (RST)
    4.3.2 Cerrando una conexion (FIN)
    4.3.3 Improvisando.
    4.4 Hijacking la conexion
    4.5 Otro
    5. El codigo fuente

    -----------------------------------------------------------------------------------------------
    PARTE I: Spoofing simple (No-blind)
    -----------------------------------------------------------------------------------------------


    0. Introduccion
    ---------------

    0.1 Que
    -------

    Este documento describe algunos ataques IP spoofing y te da codigo fuente de ejemplo de los programas usados para estos ataques (y logs de packet sniffer, para ver exactamente que sucede).
    Este tambien te provee con un archivo incluido facil de usar para experimentar un poco uno mismo.
    Oh, si haces algo agradable con el archivo "spoofit.h", por favor mandamelo por correo (o una referencia de donde esta disponible) con una corta explicacion de que es (unas cuantas lineas son suficientes)...

    Si tu tienes cosas interesantes que remarcar, comentar, ideas, ... por favor contactame
    Brecht Claerhout <Coder@reptile.rug.ac.be>
    PoBox 144
    9000 Gent 12
    Belgica

    Si TU piensas de ti mismo, que eres "3n 3><Tr3/\/\o 3Le3T", por favor no te molestes en contactarme.
    Flames > /dev/null o > /dev/echo depende que tan listo eres.

    No es muy inteligente usar algo que no conoces/entiendes, por eso lee esto antes de tratar cualquier cosa... esto te tomara unos pocos minutos, y probablemente te ahorrara algunas horas de fallas...

    Este codigo no esta crippleado en la forma usual (Quitando algunas partes vitales), el poder esta limitado por su briefness, solo por que quise dejar todo simple e ilustrativo (pero trabajando). Es un trabajo simple mejorarlo, y ese es el objetivo de este documento, que lo mejores tu mismo.

    Gracias tambien Wim Vandeputte por el chequeo ortografico, y por recopilarlo con mis constantes quejas acerca del IP durante la captura de toda esta m!erda...

    0.2 Para quien
    --------------

    Para gente con conocimientos elementales de TCP/IP, algo de conocimientos en C (solo en la configuracion basica) y algo de conocimientos generales en UNIX.
    No tiene ningun caso leer este documento su tu estas completamente desconectado de estas cosas, pero te recuerdo, solo un poco de conocimientos son suficientes.

    0.3 Disclaimer
    ---------------

    Yo no soy de ninguna forma responsable por el uso de este codigo. Por el hecho de usar este software y leer este documento tu aceptas el hecho de que cualquier daño (emocional,fisico, perdida de datos y el fin del mundo tal como lo conocemos ...)
    causado por el uso o almacenamiento de estos programas/documentos no es MI responsabilidad.

    Yo proclamo que durante la escritura y prueba de este documento/fuente, Yo nunca viole ninguna ley. Todo el Spoofing fue hecho entre maquinas donde Yo tengo acceso legitimo como root, o donde Yo tengo el permiso de el root legitimo.

    Este codigo puede ser escrito por cualquier programador competente, entonces este codigo fuente no es tan dañino como algunos pregonarian (Porque estoy seguro que algunas personas no les gusta este grado de divulgacion).

    0.4 Licencia
    ------------

    Todo el codigo fuente y texto esta disponible gratuitamente. Puedes repartirlo, mientras que no cobres por ello ( excepciones son con un pequeño cargo de reproduccion, si este no es distribuido junto con software comercial, textos .)
    No deberas distribuir partes del documento, este debe ser distribuido como un solo paquete. No deberas modificar el texto y/o codigo fuente.

    Podra usarse el spoofit.h o codigo derivado en tus propios programas mientras no sean comerciales (ej. GRATIS), y si me das los creditos por el.

    1. Explicacion corta de algunas palabras
    ----------------------------------------

    Esta es una corta explicacion de algunas palabras que se veran en el texto/codigo fuente. Tu probablemente sepas todo esto, pero lo pongo aqui de todas maneras.

    Sniffit
    Mi sniffer de Packets favorito, todas las sequencias sniffed en este documento fueron creadas con esto. Sniffit puede obtenerse en:
    http://reptile.rug.ac.be/~coder/sniffit/sniffit.html
    Por supuesto cualquier otro sniffer decente lo hara (pero este gasta mis marcas personales y aprovacion).
    (En el tiempo de escribir esto es una pre-realizacion 0.3.2)

    IP-spoofing (referenciado como spoofing)
    La falsificacion de IP packets
    NOTA que No solo protocolos basados en IP son spoofeados.
    NOTA que Spoofing es tambien usado en una base constructiva (LAN spoofing, no discutida aqui).
    NOTA que Yo no lo uso en una base constructiva

    Non-blind spoofing
    Usando el spoofing para interferir con una coneccion que manda packets a lo largo de tu subred, o todo el trafico de datos que tiene que pasar por tu dispositivo de red,... tu deberias considerar tomar trabajo en algun proveedor de ruta trasatlantica).

    Blind spoofing
    Usando el spoofing para interferir con una coneccion (o creando una),
    que no mande packets por el cable.

    2. Descripcion de codigo fuente
    -------------------------------

    2.1 Fuente incluida
    -------------------
    spoofit.h
    El archivo incluido que provee algunas funciones spoofing faciles de usar.
    Para entender el archivo incluido y sus funciones, lee el encabezado del archivo para usarse on funciones en C.

    *.c
    Programas de ejemplo (en el uso de spoofit.h) que son discutidos en este documento.
    Detalles en estos programas estan incluidos en las secciones apropiadas.

    sniper-rst.c
    Basico mata-conecciones TCP.
    (denial-of-services)

    sniper-fin.c
    Basico mata-conecciones TCP.
    (denial-of-services)

    hijack.c
    Simple y automatizado ladron(hijacker) de coneccion telnet.

    2.2 Notas del programador
    -------------------------

    Estos programas son solo ejemplos. Esto significa, que estos pueden ser mejorados mucho. Porque los tenia que mantener cortos y ademas dejar algo a tu imaginacion, estos son muy simples.
    Como sea todos funcionan y son un buen punto de partida.

    3. TCP/IP (UDP) en muy pocas palabras.

    Esto ha sido explicado lo suficiente en 'Phrack Volumen Siete, ejemplar cuarenta y ocho, Archivo 14 de 18' por daemon9/route/infinity , y hay muchisima documentacion disponible acerca del tema, solo repetire algunas cosas a grandes rasgos. (Por favor lee el archivo en phrack #48
    o cualquier otro documento acerca de este tema antes de leer esto).

    Una coneccion esta definida completamente con 4 parametros, un host y puerto fuente, y un host y puerto destino.

    Cuando se hace una coneccion, los datos son enviados en paquetes llamados packets. Estos packets se encargan del trafico de bajo nivel, y se aseguran de que los datos lleguen (algunas veces con manejos de error especiales). El lazo de la mayoria de las redes es el protocolo IP version 4. Este es totalmente independiente de todos los protocolos de hardware.

    TCP y UDP son los protocolos de alto nivel envueltos en los packets IP.

    Todos estos packets consisten en encabezado (header) y datos (data).

    El encabezado IP contiene (ademas de otras cosas): IP del host fuente y el IP del host destino para ese packet, y el tipo del protocolo envuelto en el packet. (TCP=6, UDP=17, etc.).

    Los packets UDP contienen (ademas de otras cosas): numeros de puerto de host fuente y destino. UDP no tiene cosa tal como SEQ/ACK, este es un protocolo muy debil.

    Los packets TCP contienen (ademas de otras cosas): numero de puerto de host fuente y destino,
    numeros de sequence y acknowledge (referidos despues de SEQ/ACK), y un puño de banderas.

    Numero SEQ: es contado byte por byte, y da el numero de el (NEXT) siguiente byte a ser mandado, o enviado en este packet.
    Numero ACK: es el numero SEQ esperado por el otro host.
    los numeros SEQ son escogidos en la iniciacion de coneccion.

    Dije que hiba a ser corto... Si tu no entendiste el texto anterior, lee acerca de eso primero , por que si no entonces no estenderas ni sh!t de lo que sigue.

    4. Non-blind spoofing
    ---------------------

    4.1 Saber que se esta haciendo
    ------------------------------

    El concepto de spoofing non-blinding (NBS mas adelante en este doc) es muy simple. Porque los packets viajan dentro de tu alcance, se puede obtener la secuencia actual y el acknowledge (SEQ/ACK mas adelante en este doc)estos son numeros en la conexion.

    NBS es un metodo muy facil y preciso de ataque, pero limitado a las conexiones que pasan en tu subred.
    En documentacion spoofing estos ataques son a veces omitidos, porque la mayoria son ataques 'denial of service', o quiza porque la gente no se da cuenta de las ventajas del spoof (en particular en un hijack) que puede tener sobre el simple sniffing de passwords.

    Spoofing en general es referido como un ataque de muy alto nivel. Esto se refiere al blind spoofing (BlS mas adelante en este doc), por la simple razon de que NBS es cosa de niños para un programador competente.

    4.2 SYN flooding
    ----------------

    Discutido ampliamente en 'Phrack Volumen seven', Issue Forty-Eight, File 13 of 18'. Asi que no gastare mucho tiempo en esto.

    Configuracion:

    host A <----->[----------X--------------->host B
    |
    host S <-----------------/


    Concepto:
    El host S se hace pasar por SYN(connection init) viniendo del host A, hacia el host B.
    El host A deberia ser inalcanzable (unreachable)(ej. apagado, inexistente,...).
    B manda el segundo packet de los 3 way TCP handshake. Host B esperara ahora respuesta de el host A.
    Si host A es alcanzable (reachable)este le dira al host B (con un reset: RST) que el NO INICIO una conexion, y por lo tanto que el host B recibio un packet disfrazado. (En este caso host B ignorara el SYN, y *normalmente* nada pasara)
    Entonces si A es unreachable, B esperara respuesta un momento)
    Cuando se hacen ataques multiples, el backlog del host B estara siendo excedido y host B no aceptara nuevas conexiones (lee los TCP bugs para caracteristicas adicionales por algun tiempo.

    4.3 Killing conexion
    --------------------

    Configuracion:

    host A <------X------------------------->host B
    | A,B tiene una conexion TCP corriendo
    host S <------/ A,S en la misma subred

    (la configuracion es la misma en ambos casos)

    Uso:
    Elimina embrollosos de tu red, fastidiando a ese dude que teclea un papel importante, etc... diversion pura.

    4.3.1 Usando el reset (RST)
    ---------------------------

    Concepto:
    Los packets TCP tienen banderas (flags) que indican el estado de el paquete, como RST.
    Esta es un a bandera usada para resetear una conexion. Para ser aceptado, solo el numero de secuencia debe ser correcto (no hay ACK en un packet RST).
    Entonces vamos a esperar packets en una conexion entre A y B.
    Suponga que esperamos packets de A. Calcularemos (de los packets de B)
    el numero de secuencia para los packets de A (de los ACK de B), y lanzamos un packet RST falso desde S (fingiendo ser A) hacia B.

    un ataque real:
    (Estos son packets sniffeados reales, aunque los numeros IP de host esten cambiados)
    host A: 166.66.66.1
    host B: 111.11.11.11
    (S en la misma subred de A)

    (Este es un buen ejemplo de como las cosas no siempre son como uno quisiera, ver abajo la solucion)
    1) connection running...
    esperamos un packet para obtener el SEQ/ACK corriente (A->B)

    TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
    SEQ (hex): 57E1F2A6 ACK (hex): B8BD7679
    FLAGS: -AP--- Window: 3400
    (datos irrelevantes removidos, 2 bytes data)

    2) Este es el ACK de este + datos incluidos (lo cual provoca que el numero SEQ cambie, y hechando a perder nuestro plan, por que este llega muy rapido.)
    (B->A)

    TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
    SEQ (hex): B8BD7679 ACK (hex): 57E1F2A8
    FLAGS: -AP--- Window: 2238
    (datos irrelevantes removidos, 2 bytes data)

    3) ACK de este. (A->B)

    TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
    SEQ (hex): 57E1F2A8 ACK (hex): B8BD767B
    FLAGS: -A---- Window: 3400
    (datos removidos por irrelevantes)

    4) datos adelantados (B->A)

    TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
    SEQ (hex): B8BD767B ACK (hex): 57E1F2A8
    FLAGS: -AP--- Window: 2238
    (datos removidos por irrelevantes)

    5) ACK de este (A->B)

    TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
    SEQ (hex): 57E1F2A8 ACK (hex): B8BD7691
    FLAGS: -A---- Window: 3400

    6) Ahora tenemos 2 packets RST. COmo puedes explicar eso? Bueno, el primer packet reset
    ha sido almacenada en un buffer en alguna parte de nuestro sistema, porque el segmento de ethernet estaba ocupado cuando queriamos mandarlo. Esto es lo 'inesperado' que discutia anteriormente, aqui somos afortunados, el flujo de datos se enfrio tan rapido.
    Cuando este no se enfria tan rapido, podriamos perder nuestro RST (o la conexion sera matada
    un poco despues de cuando queriamos), veras algunas ideas de como arreglar el problema.

    TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
    SEQ (hex): B8BD7679 FLAGS: ---R--


    TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
    SEQ (hex): B8BD7691 FLAGS: ---R--
    (Este era el packet que mato la conexion)

    Discusion de el programa:

    La discusion aqui es un poco extraña, esto es porque 'sniper-rst.c' no esta diseñado para ser un killer optimo, es meramente un ejemplo.
    Aqui tenemos el problema de la velocidad. Perdemos algunos packets que causan esos re-envios.
    Entonces deberiamos diseñar un mejor 'sniper' si hacemos lo siguiente:
    - usar blocking IO (no necesariamente, porque el RST killer podria perder algo de su belleza (looping), este es manejado con y en el ejemplo del
    FIN killer. Bloquear es un poco mas rapido cuando muchos packets vienen uno detras de otro.)
    - disparos multiples de packets... lanzar mas packets con SEQ incrementado.
    (esto es comentado en el codigo fuente)
    - espera por un packet ACK puro (sin datos), porque de otra forma se arriesga mucho a que darse a la mitad de la transmision y no ser suficientemente rapido.
    (la desventaja es el 'periodo de espera' antes de que la conexion sea
    matada)

    NOTA estos ejemplos fueron hechos en redes no-cargadas, con servidores no-cargados, lo que hace que sea un peor escenario para problemas de velocidad.

    4.3.2 Cerrando una conexion (FIN)
    ---------------------------------

    Concepto:
    otra de las banderas es FIN y dice asi: "no more data from sender".(no hay mas datos del emisor). Esta bandera es usada cuando se cierra una conexion de forma legitima. entonces si existe alguna forma de hacer un packet que sea aceptado por uno de los dos hosts, este host creeria que el 'emisor' no le quedan mas datos.
    Los siguientes packets (reales) serian ignorados puesto que serian considerados falsos.
    Eso es todo,como podemos sniffear el SEQ/ACK actual de la conexion, podemos pretender ser el host A o el B, y proveer al otro host con la informacion de packet CORRECTO, y una malvada bandera de FIN.
    La belleza de todo esto es, que despues de un FIN es mandado al otro host siempre con uno si este es aceptado, entonces tenemos una forma de verificar nuestro killing , y se puede estar 100% seguro del exito (si por alguna razon perdemos un SEQ o ACK, podemos simplemente re-mandarlo).
    El killing con RST es mas popular y es preferido, pero he puesto este como un ejemplo, y personalmente este me gusta mas.

    Un ataque real
    (Estos son packets sniffeados realmente, aunque los numeros IP de los hosts fueron cambiados)
    host A : 166.66.66.1
    host B : 111.11.11.11
    (S en la misma subred que A)

    1) connection is running....
    sniper es iniciado en el host S como un 'sniper-fin 166.66.66.1 23 111.11.11.11 1072'
    y espera un packet para entrar en accion(nesecitamos obtener el SEQ/ACK)
    (ten en cuenta que cambiar A por B es lo mismo, solo S estara
    fingiendo ser A en lugar de B)
    repentinamente un packet llega... (A->B)

    TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
    SEQ (hex): 19C6B98B ACK (hex): 69C5473E
    FLAGS: -AP--- Window: 3400
    Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
    45 E 00 . 00 . 2A * 30 0 5E ^ 40 @ 00 . 40 @ 06 . 5E ^ AD . 9D . C1 . 45 E 33 3
    9D . C1 . 2B + 0D . 00 . 17 . 04 . 30 0 19 . C6 . B9 . 8B . 69 i C5 . 47 G 3E >
    50 P 18 . 34 4 00 . 3A : 61 a 00 . 00 . 0D . 0A .
    ~~~~~~~~~ > 2 data bytes

    2) sniper lo ha detectado, y manda un packet falso. (S como B -> A)
    calculamos nuestro SEQ como: ACK del packet (A->B)
    calculamos nuestro ACK como: SEQ del packet (A->B)+ longitud de los datos del packet
    (19C6B98B + 2 = 19C6B9)
    (entonces le decimos a A, que recibimos el ultimo packet, y este no transmitira
    mas datos)

    TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
    SEQ (hex): 69C5473E ACK (hex): 19C6B9
    FLAGS: -A---F Window: 7C00
    (datos removidos por irrelevantes)

    3) el host A ahora dice: 'bien, terminas la sesion, entonces aqui esta mis ultimos datos'
    (A->B)

    TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
    SEQ (hex): 19C6B9 ACK (hex): 69C5473E
    FLAGS: -AP--- Window: 3400
    (datos removidos por irrelevantes)

    TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
    SEQ (hex): 19C6B998 ACK (hex): 69C5473F
    FLAGS: -A---- Window: 3400
    (datos removidos por irrelevantes)

    4) host A ahora a flusheado (vaciado) su buffer y en su turno hace el FIN a la conexion.
    (A->B)
    sniper, intercepta este packet y ahora sabe que el host cayo en la trampa del spoof y que el killing fue un exito!
    (host A ya no aceptara mas datos )

    TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
    SEQ (hex): 19C6B998 ACK (hex): 69C5473F
    FLAGS: -A---F Window: 3400
    (datos removidos por irrelevantes)

    5) fingimos ser B, haciendo que A creyera que no teniamos mas datos. Pero B no lo sabe y continua mandando packets.
    (B->A)
    el host A tiene esa conexion cerrada, y por lo tanto piensa que los packets reales de B estan spoofeados (o al menos falsos)! entonces el host A manda algunos packets reset
    (RST).

    TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
    SEQ (hex): 69C5473E ACK (hex): 19C6B9
    FLAGS: -A---- Window: 3750
    (datos removidos por irrelevantes)


    TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
    SEQ (hex): 19C6B9 FLAGS: ---R--
    (datos removidos por irrelevantes)

    6) Esto continua todavia con algunos packets.

    Discusion del programa (los numeros corresponden con aquellos de 'Un ataque
    real'):

    1) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P ,DEST,DEST_P,ACK,10);
    if(stat==-1) {printf("Connection 10 secs idle... timeout.\n";exit(1);}

    2) sp_seq=pinfo.ack;
    sp_ack=pinfo.seq+pinfo.datalen;
    transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,
    sp_seq,sp_ack,ACK|FIN);
    3) N/A

    4) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P ,DEST,DEST_P,FIN,5);
    if(stat>=0)
    {printf("Killed the connection...\n";
    exit(0);}




    --------------------------------------------------------------------------------




    __________________________________________________ ___________



    IP-SPOOFING DEMISTIFICADO



    por daemon9 / route / infinity

    ==Phrack Magazine==

    Volumen 7, Número 48, Archivo 14 de 18

    Junio 1996 Guild Productions



    Traducido por IPgh0st (1997)

    __________________________________________________ ___________





    El propósito de este documento es explicar el IP-spoofing a las masas. Solamente se requiere un poco de conocimiento Page Rankingáctico de Unix y TCP/IP para entenderlo sin problemas. Oh, y que no seas un inútil...

    IP-spoofing es una compleja técnica de ataque constituida por varias partes. (En la actualidad, IP-spoofing no es el ataque, sino sólo un paso en el ataque. El ataque es actualmente un aprovechamiento de la relación entre dos trusted hosts. Sin embargo, en este documento, IP-spoofing irá referido al ataque completo.) Explicaré la técnica en detalle, incluyendo información relevante sobre sistemas operativos y redes.





    [SECCIÓN I. INFORMACIÓN PREVIA>





    -- [Los Protagonistas>--





    A: host objetivo

    B: host con el que se establece la relación (“trusted host”)

    X: host no alcanzable

    Z: host atacante

    (1)2: host 1 disfrazado como host 2





    --[Los Esquemas>--





    Hay muchos esquemas en el documento y tienen que ser interpretados como el siguiente ejemplo:



    tick host a control host b

    1 A ---SYN---> B



    tick: un paso de tiempo. No hay distinción entre *cuanto* tiempo pasa entre cada paso, simplemente que el tiempo pasa. Generalmente no es mucho.

    host a: Un sistema participando en una conversación basada en TCP.

    control: Este campo muestra cualquier conjunto de bits de control relevantes en la cabecera de TCP y la dirección que están tomando los datos.

    host b: Un sistema prticipando en una conversación basada en TCP.



    En este caso, en el primer paso el host a le está enviando un segmento TCP al host b con el bit de SYN ac-tivado. A menos que se indique lo contrario, no nos importa la porción de datos de dicho segmento TCP.





    --[Trusted Hosts>--





    En el mundo del Unix, la confianza se da fácilmente. Digamos que tienes una cuenta en el sistema A, y otra en la máquina B. Para facilitar ir de una a la otra con un mínimo esfuerzo, deseas establecer una rela-ción o unión entre ambas. En tu directorio home en A creas un archivo .rhosts: `echo “B nombre-de-usuario” > ~/.rhosts´ En tu directorio home en B creas otro archivo .rhosts: `echo “A nombre-de-usuario” > ~/.rhosts´ (Como alternativa, el root puede establecer una configuración similar en /etc/hosts.equiv, la diferencia está en que entonces sería a nivel del host entero, no sólo a nivel individual.) Ahora, puedes usar cualquiera de los comandos r* sin necesidad de tener que perder el tiempo con verificaciones de passwords. Estos comandos permitirán la autentificación en base a las direcciones, lo que ofrecerá o negará el acceso dependiendo de la dirección IP del solicitante.





    --[Rlogin>--





    Rlogin es un simple protocolo cliente-servidor que utiliza TCP como medio de transporte. Rlogin permite a un usuario identificarse (hacer login) remotamente desde un host a otro, y, si el host objetivo confía en el otro (ver apartado anterior), no nos pedirá ningún password. En lugar de esto habrá comprobado la identidad del cliente (nosotros) analizando nuestra dirección IP. Por tanto, como en el ejemplo de arriba, podemos usar rlogin para hacer login remotamente desde A a B (o viceversa) y no nos pedirán ningún password.





    --[Internet Protocol (IP)>--





    IP es el protocolo de red menos fiable de todo el sistema TCP/IP. Posee dos campos de encabezamiento de 32-bits para la información de las direcciones. IP es también el más empleado de todos los protocolos TCP/IP ya que casi todo el tráfico TCP/IP está encapsulado en datagramas IP. El trabajo del IP es enrutar paquetes de la red. No ofrece ningún mecanismo de comprobación (es un protocolo “sin conexión”). IP simplemente envía datagramas y confía que lleguen intactos a su destino. Si no lo hacen, IP puede intentar enviar un mensaje ICMP de error al origen, aunque por supuesto este paquete también puede extraviarse. (ICMP significa Internet Control Message Protocol, y se usa para informar sobre las condiciones en las que se encuentra una red y sobre los errores que se van produciendo al IP y a otros protocolos). IP no tiene ningún medio para garantizar el envío de paquetes. No mantiene ninguna información sobre el estado de la conexión. Cada datagrama IP es enviado sin niguna relación con el último enviado o el siguiente a mandar. Esto, unido al hecho de que es sencillísimo modificar la pila de IP para permitir la elección de una dirección IP arbitrariamente en los campos de origen (y de destino) convierten al protocolo IP en algo fácilmente modificable.





    --[Transmission Control Protocol >--





    TCP es el protocolo orientado a la conexión, el protocolo de transporte en el que se puede confiar plenamente dentro del sistema TCP/IP. Orientado-a-la-conexión significa simplemente que los dos hosts que participan en una discusión deben establecer previamente una conexión antes de que los datos puedan liarse a tortas. La seguridad se consigue a través de diferentes modos, pero los dos que nos conciernen ahora mismo son secuenciación de datos e identificación. TCP asigna números secuenciales a cada segmento e identifica todos los segmentos de datos recibidos desde el otro extremo. (Se revisa la secuencia de números, no los segmentos en sí). Estas características hacen que TCP sea mucho más difícil de trucar que IP.





    --[Números Secuenciales, Identificaciones y otras indicaciones>--





    Dado que TCP posee una seguridad bastante aceptable, debe ser capaz de recuperar datos perdidos, dupli-cados, o fuera-de-servicio. Asignando una secuencia de números a cada byte transmitido, y requiriendo una identificación para cada uno recibido del extremo opuesto, TCP puede garantizar una transmisión sin errores. El extremo receptor utiliza la secuencia de números para asegurar el orden correcto de los datos y eliminar bytes duplicados.

    Los números secuenciales del TCP se pueden imaginar como contadores de 32-bits. Se encuentran en un rango desde el 0 hasta el 4.294.967.295. Cada byte de datos intercambiado en una conexión TCP (junto a otros indicadores) va secuenciado. El campo del número secuencial en la cabecera TCP contendrá el número secuencial correspondiente al *primer* byte de datos en el segmento TCP. El campo del número de identifi-cación (ACK) en la cabecera TCP muestra el valor del siguiente número secuencial *esperado*, y también identifica *todos* los datos hasta este número de ACK menos uno.

    Para el control del flujo, TCP envía un paquete para decirle al otro extremo cuántos datos puede buffear. Dado que este paquete es de 16 bits, se puede notificar un máximo de 65535 bytes. El objetivo de este méto-do es enviar una notificación desde un TCP al otro sobre la amplitud de la secuencia de números a emplear de manera que sea aceptable.

    Otros indicadores en la cabecera TCP a mencionar son RST (reset), PSH (push) and FIN (finish). Si se re-cibe un RST, se corta inmediatamente la comunicación. Los RSTs se envían normalmente cuando un extre-mo recibe un segmento que simplemente no tiene relación con la conexión que está establecida (veremos un ejemplo abajo). El indicador PSH le dice al receptor que pase tan pronto como sea posible todos los datos que se han ido almacenando a la aplicación correspondiente. El indicador FIN es la manera en que una aplica-ción comienza el amable cierre de la conexión (el corte de una conexión es un proceso de 4 direcciones). Cuando un extremo recibe un FIN, lo ACKea (autentifica) y ya no espera recibir más datos (sin embargo el envío es todavía posible).





    --[Estableciendo una Conexión TCP>--





    Para poder intercambiar datos usando TCP, los hosts deben establecer una conexión. TCP establece una conexión siguiendo un proceso de 3 pasos llamado el Saludo de las 3 direcciones. Si la máquina A está utilizando un cliente de rlogin y desea conectar a un daemon de rlogin en la máquina B, el proceso es el siguiente:



    fig(1)



    1 A ---SYN---> B



    2 A <---SYN/ACK--- B



    3 A ---ACK---> B





    En (1) el programa cliente le está diciendo al servidor que quiere una conexión. Este es el único propósi-to del indicador SYN. El cliente le está diciendo al server que el campo de secuencia numérica es válido, y que debería ser comprobado. El cliente configurará el campo de secuencia numérica en la cabecera TCP a su ISN (Initial Sequence Number, número inicial de la secuencia). El server, al recibir este segmento (2) responderá con su propio ISN (por lo tanto el flag SYN está activado) y una autentificación (ACK) del primer segmento enviado por el cliente (que será el ISN-del-cliente + 1). El cliente entonces ACKea (autentifica) el ISN del servidor (3). Ahora ya puede tener lugar la transferencia de datos.





    --[El ISN y el Incremento de los Números Secuenciales>--





    Es importante entender cómo son elegidos los números secuenciales inicialmente, y cómo cambian con respecto al tiempo. El número secuencial inicial se cambia a 1 cuando el host se inicializa. (TCP llama a esta variable “tcp_iss” dado que se trata del número secuencial inicial *de envío* (initial*send* sequence number). La otra variable de número secuencial, “tcp_irs” es el número secuencial inicial *de recepción* (initial *receive* sequence number) y se establece al crearse la conexión de 3 direcciones que tratamos antes. Pero no nos vamos a preocupar por las distinciones entre las dos variables). Esto da a entender un error, y se autentifica como tal con el correspondiente comentario en la función tcp_init() de dónde aparece. El ISN se incrementa en 128.000 cada segundo, lo que provoca que el contador de ISN de 32-bits quede agotado cada 9.32 horas si no se establece ninguna conexión. Sin embargo, cada vez que se establece un connect(), el contador es incrementado en 64.000.

    Esto es así por una importante razón, y es hacer mínimo el riesgo de que datos de una vieja encarnación pasada (jeje, quiero decir, desde el mismo cuarteto de direcciones-IP y puertos TCP locales y remotos) de la conexión actual pueda llegar y joder las cosas. Aquí se aplica el concepto del tiempo de espera de 2MSL, pero no lo analizaremos porque no es el objetivo de este documento. Si los números secuenciales fuesen elegidos al azar cuando llega una conexión, no se podría garantizar que esos números secuenciales fuesen distintos de los empleados en una conexión anterior. Si una porción de datos quedase retenida en mitad de su recorrido y después consiguiese llegar a su destino interfiriendo con el reenvío de la vieja conexión, ten por seguro que se joderán las cosas.





    --[Puertos>--





    Para garantizar el acceso simultáneo al módulo de TCP, TCP provee un interfaz de usuario llamado puerto. Los puertos son utilizados por el kernel para identificar procesos de red. Y éstos son estrictamente entidades de transporte (que es lo mismo que decir que al IP le importa un pimiento su presencia). Junto a una dirección IP, un puerto TCP forma lo que hemos llamado extremo de una comunicación de red. De hecho, en un momento dado *cualquier* conexión de Internet puede ser descrita por 4 números: la dirección IP de inicio y su puerto , y la dirección IP de destino y el correspondiente puerto de destino. Los servers suelen ceñirse a puertos corrientes para que puedan ser localizados a través de puertos estandar en sistemas diferentes. Por ejemplo, el daemon de rlogin se encuentra en el puerto TCP 513.









    [SECCIÓN II. EL ATAQUE>





    ...El diablo encuentra trabajo para las manos que no hacen nada...





    --[Antes de nada...>





    El IP-spoofing se compone de varios pasos, que resumiré brevemente ahora y luego analizaremos con más profundidad. Primero, se elige el host objetivo. A continuación descubrimos un indicio de “confianza” con otro host, es decir, nos lleva a un trusted host. Entonces se desactiva el trusted-host, y se hace un muestreo de los números secuenciales de TCP del objetivo. Se usurpa la personalidad del trusted host, se averiguan los números secuenciales correspondientes, y se intenta la conexión a un servicio que sólo requiera identifica-ción basada en direcciones. Si sale bien, el atacante ejecuta un simple comando para dejar una puerta trasera en el sistema.





    --[ Cosas Necesarias >--





    Hay varias cosas que se necesitan para llevar a cabo esta técnica:



    - cerebro, mente, o cualquier otro dispositivo pensante

    - host objetivo

    - trusted host

    - host atacante (con acceso de root)

    - software de IP-spoofing



    Generalmente el ataque se hace desde la cuenta root del host atacante contra la cuenta de root del objetivo. Si el atacante se va a tomar todas estas molestias, sería estúpido no aspirar como mínimo a ser root. (Dado que se necesita ser root para ejecutar el ataque, esto no debería ser problema).





    --[ IP-Spoofing es un “Ataque Ciego”>--





    Un factor que muchas veces no se analiza pero que es crítico en el IP-spoofing es el hecho de que el ataque es ciego. El atacante va a estar suplantando la identidad de un trusted-host para poder saltarse la seguridad del host objetivo. El trusted-host se desactiva empleando el método explicado abajo. Lo que el host objetivo cree es que está manteniendo una conversación con otro colega. En realidad, el atacante está sen-tado en alguna oscura esquina de Internet, falsificando paquetes desde este trusted-host mientras está enfrascado en una batalla de DoS (denial of service). Los datagramas IP enviados con la dirección IP falsificada alcanzan su objetivo sin problemas (recordemos que IP es un protocolo “sin conexión” , cada datagrama es enviado sin tener en cuenta lo que pase con el otro extremo) pero los datagramas que el host objetivo envía de vuelta (destinados al trusted-host) se van a la . El atacante nunca los ve. Los routers que intervienen conocen dónde se supone que tienen que ir los datagramas. Se supone que van hacia el trsuted-host. En lo que respecta al nivel de red, desde aquí es desde dónde fueron originados y ahí es donde deberían ir las contestaciones. Por supuesto una vez que los datagramas son enrutados hacia allí y la infor-mación es desmultiplexada y llega al TCP, se desecha (el TCP del trusted-host no puede responder --ver abajo). Por lo tanto el atacante tiene que ser inteligente y *saber* qué fue enviado, y *saber* qué respuesta está buscando el server. El atacante no puede ver lo que el host objetivo le envía, pero puede *predecir* lo que le enviará; eso unido al conocimiento con certeza de lo que *enviará*, le permite al atacante librarse de esta “ceguera”.





    --[ Encontrando Trusted-Hosts>--





    Después de elegir un objetivo el atacante debe averiguar los posibles trusted-hosts disponibles (por el bien de todo esto, daremos por hecho que el host objetivo *SI* confía en alguien. Si no es así, el ataque se acaba-ría aquí). Averiguar en quién confía un host puede no ser fácil. Un “showmount -e” puede mostrarte a dónde se exportan los archivos del sistema, y rcpinfo también puede ofrecerte información interesante. Si se tiene abundante información sobre el host, no debería ser difícil. Si todo esto falla, probar direcciones IP vecinas en un esfuerzo de fuerza bruta puede ser una opción viable.





    --[ Desactivación del Trusted-Host Empleando Synflooding >--





    Una vez que hemos encontrado el trusted-host, debemos desactivarlo. Dado que el atacante va a hacerse pasar por él, debe asegurarse de que este host no reciba ningún tráfico de la red y nos fastidie las cosas. Existen muchas maneras para hacer esto, la que voy a explicar es el TCP SYN flooding.

    Una conexión TCP se inicia cuando un cliente hace una petición a un server con el SYN flag activado en la cabecera TCP. Normalmente el server devolverá un SYN/ACK al cliente identificado por la dirección de 32-bits en la cabecera IP. El cliente enviará entonces un ACK al server (como veíamos en la figura 1 al principio) y la transferencia de datos podrá comenzar.Sin embargo, existe un límite máximo de las peticiones de SYN concurrentes que TCP puede procesar para una determinada conexión. Este límite se denomina “backlog” y es la longitud de la cola donde se almacenan las conexiones entrantes (por tanto todavía incompletas). Este límite de la cola tiene en cuenta el número de conexiones incompletas (el saludo de 3 direcciones está incompleto) y el número de conexiones completadas que han sido sacadas de la cola por la aplicación correspondiente por medio del sistema de llamada accept(). Si este límite “backlog” se alcanza, TCP desechará en silencio todas las peticiones de SYN hasta que las conexiones pendientes puedan ser resueltas. Este es el quid de la cuestión.

    El host atacante envía varias peticiones de SYN al puerto TCP que se desea desactivar. Este host también debe asegurarse de que la dirección-IP del origen sea cambiada por otra, en este caso un host inalcanzable (el TCP del host objetivo enviará su respuesta a esta dirección. (IP puede informar al TCP de que el host no es alcanzable, pero TCP considera que estos errores son temporales y deja la resolución de ellos al IP (reen-rutar los paquetes, etc.) , quien en efecto los ignora). La dirección-IP debe ser inalcanzable porque el atacante no desea que ningún host reciba los SYN/ACKs que llegarán enviados por el TCP del host objetivo (si lo anterior sucediese, daría como resultado un RST que se enviaría al TCP del host objetivo, lo que anularía nuestro ataque). El proceso es así:



    fig(2)



    1 Z(x) ---SYN---> B



    Z(x) ---SYN---> B



    Z(x) ---SYN---> B



    Z(x) ---SYN---> B



    Z(x) ---SYN---> B



    ...



    2 X <---SYN/ACK--- B



    X <---SYN/ACK--- B



    ...



    3 X <---RST--- B





    En (1) el host atacante envía un gran número de peticiones SYN al objetivo (recuerda que el objetivo en esta fase del ataque es el “trusted-host”) para llenar su cola de backlog con conexiones pendientes.

    (2) El host objetivo responde con SYN/ACKs a lo que él cree es el origen de los SYNs que le llegan. Durante todo esto todas otras peticiones a este puerto TCP serán ignoradas.

    Diferentes implementaciones de TCP poseen tamaños de backlog distintos. BSD generalmente tiene un backlog de 5 (Linux tiene un backlog de 6). Pero además existe un `gracioso´ margen de 3/2. Esto es, TCP permitirá un número de conexiones de hasta backlog*3/2+1. Esto hará posible una conexión incluso si el backlog señala 0.



    Nota-del-Autor:[ Para un análisis más exhaustivo del TCP SYN flooding, leer mi trabajo sobre este tema. Cubre el proceso completo al detalle, con teoría y Page Rankingáctica. Está acompañado de código para su funciona-miento, un análisis estadístico y más.

    Búscalo en el número 49 de Phrack. -daemon9 6/96>





    --[ Muestreo de los Números Secuenciales y Predicción >--





    Ahora el atacante necesita hacerse una idea de dónde se encuentra el TCP del host objetivo de entre el espacio de la secuencia numérica de 32-bits. El atacante conecta a un puerto TCP del host objetivo (SMTP es una buena elección) justo antes de lanzar el ataque y completa el “saludo” de 3 direcciones con dicho host. El proceso es exactamente como en la fig(1), excepto que el atacante guardará el valor del ISN enviado por el host objetivo. Muchas veces, este proceso se repite varias veces y el último ISN enviado se almacena. El atacante necesita saber cuál es el RTT (round-trip time, tiempo de ida/vuelta) desde el objetivo a su host. (El proceso puede repetirse varias veces, y se calcula una media de todos los RTTs hallados). El RTT es necesa-rio para poder predecir con seguridad el siguiente ISN. El atacante tiene un punto de referencia (el último ISN enviado) y conoce también cómo funciona el incremento de los números secuenciales (128.000/segundo y 64.000 por cada connect) y ahora tiene una idea bastante aproximada de cuánto tardará un datagrama IP en viajar por Internet hasta alcanzar al objetivo (aproximadamente la mitad del RTT, dado que la mayoría de las veces las rutas son simétricas). Después de que el atacante haya conseguido esta información, inmediata-mente se procede a la siguiente fase del ataque (si otra conexión TCP llegase a algún puerto del objetivo antes de que el atacante haya podido continuar con el ataque, el ISN real tendría una diferencia de 64.000 con el ISN previsto).

    Cuando el segmento spoofeado recorre su camino hasta el objetivo, pueden pasar varias cosas dependien-do de la exactitud de la predicción del atacante:

    - Si el número secuencial está EXACTAMENTE donde el TCP receptor espera que esté, los datos que llegan serán colocados en la siguiente posición disponible del búffer receptor.

    - Si el número secuencial es MENOR que el valor esperado el byte de datos se considera como una repetición de la transmisión, y es desechado.

    - Si el número secuencial es MAYOR que el valor esperado pero todavía dentro de los límites de la capacidad del búffer, el byte de datos se considera que es un byte futuro, y es controlado por el TCP, pendiente de la llegada de los bytes que faltan antes que él. Si llega un segmento con un número secuencial MAYOR que el valor esperado y que NO está dentro de los límites de la capacidad del búffer el segmento es excluido, y TCP enviará un segmento de respuesta con el número secuencial *esperado*.





    --[ Alteración... >--





    Aquí es donde empieza la parte más emocionante del ataque:



    fig(3)



    1 Z(b) ---SYN---> A



    2 B <---SYN/ACK--- A



    3 Z(b) ---ACK---> A



    4 Z(b) ---PSH---> A



    [...>





    El host atacante spoofea su dirección-IP para que sea la del “trusted-host” (el cual todavía debería estar sufriendo los efectos del ataque de D.O.S , denial of service) y envía su petición de conexión al puerto 513 del host objetivo (1). En (2), el host objetivo responde a la petición de conexión spoofeada con un SYN/ACK, que recorrerá su camino hasta el trusted-host (el cual, si *pudiera* procesar este segmento entrante, lo consideraría un error, e inmediatamente envía un RST al host objetivo). Si todo va de acuerdo con lo previsto, el SYN/ACK será ignorado por el trusted host. Después de (1), el atacante puede descansar un poco para darle tiempo al host objetivo para enviar el SYN/ACK (el atacante no puede ver este segmento). Entonces, en (3) el atacante envía un ACK al host objetivo conteniendo el número secuencial previsto (más uno, porque estamos ACKeándolo). Si el atacante acierta en su predicción, el host objetivo aceptará el ACK. El host objetivo establece la conexión y la transferencia de datos puede comenzar (4).

    Generalmente, después de establecer la conexión , el atacante insertará una backdoor en el sistema que le permitirá llevar a cabo nuevas intrusiones de una manera más fácil. (Con un `cat + + >> ~/.rhosts´ suele bastar. Esta es una buena idea por varias razones: es rápido, permite accesos más simples, y no es interacti-vo. Recuerda, el atacante no puede ver el tráfico que proviene del host objetivo, por lo tanto todas las respuestas caerán en el olvido).





    --[ Por Qué Funciona >--





    El IP-Spoofing funciona porque los servicios de trust entre ordenadores (como los “trusted-hosts”) solamente basan su seguridad en autentificaciones de las direcciones de red. Dado que el IP es fácilmente engañable, la falsificación de direcciones no es difícil. La parte más complicada del ataque es la predicción de los números secuenciales, porque es ahí donde las suposiciones y conjeturas entran en escena. Reducir las dudas y las adivinanzas al mínimo es básico para tener más posibilidades de éxito. Incluso un sistema que utilice los TCP wrappers de Wietse Venema es vulnerable al ataque. Los TCP wrappers se basan en los hostnames o en direcciones-IP para las autentificaciones de los usuarios...









    [ SECCIÓN III. MEDIDAS PREVENTIVAS >



    ...Más vale prevenir que curar...





    --[ No Confiar en Nadie >--





    Una sencilla solución para prevenir este ataque es no utilizar la autentificación basada en direcciones. Desactivar los comandos r*, borrar todos los archivos .rhosts y vaciar el archivo /etc/hosts.equiv. Esto forzará a todos los usuarios a emplear otras medidas de acceso remoto (telnet, ssh, skey, etc.)





    --[ Filtrado de Paquetes >--





    Si tu host tiene una conexión directa a Internet, puedes utilizar tu router para ayudarte. Primero asegúrate de que únicamente hosts de tu propia LAN interna pueden participar en relaciones de trust (ningún host interno debe ser trusted-host de otro sistema externo a la LAN, o viceversa). Entonces simplemente filtra *todo* el tráfico desde fuera (desde Internet) que desea llegar hasta el interior (a tu LAN).





    --[ Métodos Criptográficos >--





    UN método obvio para evitar el IP-spoofing es obligar a que todo el tráfico de la red sea encriptado y/o autentificado. Mientras se debaten otras posibles soluciones, puede establecerse ésta como medida estandar de seguridad.





    --[ Número Secuencial Inicial Aleatorio >--





    Dado que los números secuenciales no son escogidos aleatoriamente (o incrementados aleatoriamente) el ataque funciona. Bellovin aporta un parche para TCP que implica una partición del espacio dedicado al número secuencial. Cada conexión tendría su propio espacio separado de número secuencial. Los números secuenciales serían incrementados como antes, sin embargo, no habría ninguna relación obvia o apreciable entre la numeración en estos espacios. Se sugiere la fórmula siguiente:



    ISN=M+F(localhost,localport,remotehost,remoteport)



    Donde M es el cronómetro de 4 microsegundos y F es un hash criptográfico. F no debe ser calculable desde el exterior o el atacante podría todavía averiguar la secuencia numérica. Bellovin sugiere que F sea un hash de el id de la conexión y un vector secreto (un número aleatorio, o un número de host secreto relacionado combinado con el tiempo que lleva encendida la máquina).



    [ SECCIÓN IV. RECURSOS >


    - Libros: TCP/IP Ilustrado, vols. I, II & III

    - RFCs: 793, 1825, 1948

    - Gente: Richard W. Stevens, y los usuarios de Information Nexus.

    - Código disponible: rbone, mendax, SYNflood




    Este documento fue posible gracias a una beca de Guild Corporation.

    y la sabiduria de kurt de gzl.:!!
    :adios:
     

Compartir esta página