Ir al contenido

noname2016gc

+Miembro
  • Contenido

    18
  • Ingreso

  • Última visita


Actividad de reputación

  1. Like
    noname2016gc reaccionó a vaxx en Comtrend AR-5387un firmware 3º   
    si lo haces mal te quedas sin aparato
    es mejor que lo hagas con un router que no necesites o no uses
    con las dudas que has planteado es posible que la mejor opcion sea que compres un router con los manuales correspondientes y lo uses en tu linea una vez lo tengas todo listo 
    podrias usar el otro para experimentos
    pero es mejor que busques leas mucho sobre los ruters que usas que firmwares soportan que opciones añaden ventajas inconvenientes y mucho mas
    lo mejor es documentarse mucho y cuando ya casi tengas todas las dudas resueltas con los manuales y la informacion de las webs preguntes cosas mas concretas y especificas
    algunas aqui que es generica y en la web del firmware seleccionado las especificas sobre el software
     
    ahora mismo da la impresion de que a modo de ejemplo no sabes nada de mecanica y preguntas en foros como cambiar la correa de distribucion tu solo en casa 
  2. Like
    noname2016gc reaccionó a vaxx en Comtrend AR-5387un firmware 3º   
    en la web de cada firmware tendras informacion de si ese router esta soportado por ese firmware
    en caso de estarlo tambin tendras los manuales para hacerlo
    pero es mejor que lo hagas con esos pasos primero averiguar si se le puede poner otro firmware y eso tendras que consultar la web del firmware a veces lleva mucho encontrar toda la info necesaria 
    sobre todo si son equipos de un isp que suelen ser muy especificos
  3. Like
    noname2016gc reaccionó a winkel en Comtrend AR-5387un firmware 3º   
    A veces con esos FW te quedas con un buen repetidor o un punto de acceso o un router neutro pero deja de funcionar como ADSL porque no soportan esa función.
    Yo tenía un CT536+ con el bitswitcher haciendo de cliente (como si fuese un adaptador wifi con cuatro salidas ethernet).
    Cuando dejé de usarlo, por experimentar, le monté el openwrt y lo tuve que quitar porque la interfaz web de gestión era tan lenta que nunca pude terminar de configurarlo y no me apetecía configurarlo por telnet.
    No todos los routers aceptan de buen grado FW alternativos, más que nada porque no disponen de suficiente memoria y les pasan esas cosas.
     
  4. Like
    noname2016gc reaccionó a winkel en Administrador del Router Jazztel AR-5315u? Estas seguro?   
    No son puertas traseras. No está oculto. Aparece en el menú del router y no es lo que de verdad es una puerta trasera que solo conoce el programador.
  5. Like
    noname2016gc reaccionó a winkel en WPS o WLAN?   
    No entiendo que quieres decir.
     
  6. Like
    noname2016gc reaccionó a vaxx en WPS o WLAN?   
    y el wps no es seguro del todo ya que muchos se pueden romper por fuerza bruta segun su configuracion en muchos casos es ,ejor desactivarlo y conectarse a la wifi poniendo la clave en el equipo cliente
    a no ser que como comenta winkel estes confundiendo las siglas con las de wds
  7. Like
    noname2016gc reaccionó a vaxx en Comtrend AR-5315u   
    lo que voy a comentar es generico 
    en los routers con esos usuarios el admin tiene control total el user gestiones basicas 
    y el otro es por si se quiere crear por ejemplo un usuario de supervision
    la clave por como lo pones te rederiras a la de acceso asi que prueba a ver hasta donde te deja escribir pero normalmente no se pueden usar espacion y en algunos casos tampoco caracteres especiales
  8. Like
    noname2016gc reaccionó a winkel en Administrador del Router Jazztel AR-5315u? Estas seguro?   
    Puedes anularles el acceso en
    TR-069 Client   Pero luego, si tienes un problema, te las apañas tu solo o se lo vuelves a activar.  
  9. Like
    noname2016gc reaccionó a winkel en WPS o WLAN?   
    Te estás liando.
     
    WLAN es lo que se llama el wifi del router.
     
    WPS es un mecanismo para que un cliente se conecte a un punto de acceso (o router wifi) sin tener que teclear toda la contraseña. Hay dos procedimientos. El del botón consiste en apretar el botón WPS en el router o punto de acceso y mientras parpadea presionar el botón del cliente (los botones pueden ser botones físicos o simulados en pantalla). El de PIN consiste en sustituir durante unos segundos la contraseña por un PIN que sirve para que router o punto de acceso y cliente se comuniquen la clave wifi.
     
    Metiendo la contraseña por WPS o a mano el cliente se va aconectar a la misma WLAN.
     
    Igual estás confundiendo WPS con WDS que un modo de interconexión wifi entre dos puntos de acceso pero no entre un punto de acceso y un cliente.
     
  10. Like
    noname2016gc reaccionó a truso04 en ALGUNOS CONSEJOS SEGURIDAD WIRELESS   
    Hola, este post lo dedico a toda esa gente q tiene alguna duda acerca de seguridad wn Wi-fi o no sabe hasta donde llegar para crearse su pequeño muro en la red inalambrica.

    Un comentario antes de empezar, todo esta basado en experiencias y opiniones personales, si hay algo de lo que discierna alguien, que lo comente y asi podremos enriquecernos todos un poco mas.

    Lo primero, no os lleveis a engaño; la redes Wi-fi hoy por hoy NO son seguras; por mas que os molesteis en cubrir de seguridad, hoy en dia estan mas avanzadas las tecnicas de filtrado e intrusismo que las de propia seguridad casi. Si teneis algo importante que compartir y es confidencial, no lo hagais por wifi, hay programas especificos para que hasta el mas nuevo en 2 horas puede reventar casi cualquier red.

    "Esconded" el SSID, es decir, que con el explorador de redes de windows no se vea la red a menos que la confgiureis manualmente con el SSID correspondiente y el canal por el que emite. Hay programas como el xxxxxxxx (Ya no lo pongo xD) y muchisimos mas que te encontraran la red, pero si de momento no la pones visible en windows a primera vista, nadie tiene porque ponserse a buscar redes alli "donde no las ve"

    Acerca del SSID, ponerle un nombre que haga pensar que esta la red caida o sin servicio, como por ejemplo Offline, Null, Zero Signal,... Sinceramente es un poco gilipollesco, pero algun newbie (con todos mis respetos hacia los newbies) habra que se lo trague.

    Por otro lado, por dios! Desactivad el DHCP! para el que no sepa que es, es una forma automatica de que el router reparta ips locales automaticamente a los que se conectan; si lo teneis activado cualquiera que vea la red, si no teneis nada de seguridad, le estareis abriendo las puertas de par en par. (No es una medida de seguridad, simplemente se trata de ponerselo mas dificil al intruso y quitarle las ganas xD) Si lo teneis desactivado, aunque el susodicho vea la red, tendra que ponerse a tirar ping o a localizar el rango de ips por el que emite y despues asignarse una el mismo.

    EL filtrado MAC, hoy en dia casi todos los router lo ofrecen (por no decir todos). Activarlo y usadlo con cabeza. Si alguien no sabe lo que es, a grosso modo se lo puedo resumir; las direcciones MAC son direcciones fisicas de la tarjeta de red, adaptador wifi... con el que te conectas a internet. Con el Mac Filtering, le dices al router que solo le deje acceso a las MAC que tu quieras, de modo que si alguien llega hasta aqui, tenga que cambiar la direccion MAC de su dispositivo, que es tambien sencillo, pero seguimos poniendole pegas para cansarlo y que lo deje. es vulnerable tambien, hay programas de spoofing que "roban" pquetes de la red y los analizan, deduciendo las direcciones MAC que permite el router, y posteriormente, cambiando la de su dispositivo por una permitida y colandose.

    Las claves WEP y WPA; teoricamente la WPA es mas segura, pero es tan franqueable como la WEP. Ponerlas, que para algo estan, y repito obligaremos al intruso nuevamente a sacar la clave, que se puede con programas del estilo al anterior, que escuchan paquetes y analizan la clave. Si usais WEP, por ejemplo, ponerle 128 bit, que como es logico, se tardara mas en deducir la clave, aunque siga siendo posible, le pondremos otra pega mas al supuesto atacante.

    Si utilizais una tarjeta wifi o un centrino ligeramente antiguo, que transmitan por 11.b, limitar el acceso al router atraves de unicamente 11.b, esto provocara que si intenta conectarse alguien con 11.g le produzcan colisiones los paquetes y se harte de vuestra red. Haced lo mismo si trabajais con 11.g, limitar el acceso para 11.b.

    Si teneis el router ligeramente cerca de vuestro portatil/ordenador... no necesitareis mucha potencia de emision, asique reducirsela al router. Esto quiza es algo mas complicado, hay algunos que te dejan hacerlo via web, en otros deberis cambiar la antena, taparla...

    Creo que con eso se tiene algo de material para ir empezando, pero ahora mismo no caigo en nada mas.

    Conesjo personal: si la red es de cuestra casa, y no teneis informacion confidencial ni vais a hacer transacciones bancarias etc... NO OS EMPARANOYEIS, por probabilidad, es realtivamente baja que alguien vaya a colarse en vuestra red, y si lo hace, que conseguira, internet gratis? olisquear las pelis porno que guardeis en el disco duro? Si manejais algo el tema ponerle seguridad, y si no, tampoco es cuestion de crear alarma social.

    Si teneis informacion confidencial realmente importante, olvidaros del wifi, si teneis que tirar 10 metros de cable (para area local sin internet) pues se tiran, pero ahi no entra ni dios a no ser que se pinche con el pc al switch directamente.

    Bueno, siento haberos aburrido un rato, pero me paecia interesante resumir estas cosillas en un solo post para los que andan empezando.

    Saludos a todos. cualquier respuesta os la contestare encantado, al mail o por donde sea.
  11. Like
    noname2016gc reaccionó a winkel en Administrador del Router Jazztel AR-5315u? Estas seguro?   
    Con admin puedes hacer de todo y solo controlas la posibilidad de cambiar la contraseña pero no el nombre.
     
    Con user tienes un control limitado.
     
    Con support te pueden tocar cosas desde el proveedor.
     
    Cada uno tiene privilegios diferentes.
     
    Las contraseñas de admin y user las puedes cambiar para que no sean las de fábrica pero no estoy seguro que puedas hacerlo con la se support.
     
  12. Like
    noname2016gc reaccionó a XPi en Listado de puertos comunes.   
    A parte de nuestro listado que tenéis en la sección documentación os dejo aquí otro:

    21 TCP FTP
    21 UDP FTP
    22 TCP SSH
    22 UDP SSH
    23 TCP Telnet
    23 UDP Telnet
    25 TCP SMTP
    25 UDP SMTP
    66 TCP Oracle SQLNet
    66 UDP Oracle SQLNet
    79 TCP Finger
    79 UDP Finger
    80 TCP HTTP - Web Aliens vs. Predator
    80 UDP HTTP - Web
    107 TCP Remote Telnet Service
    107 UDP Remote Telnet Service
    110 TCP POP3
    110 UDP POP3
    118 TCP SQL Services
    118 UDP SQL Services
    119 TCP NNTP - Grupos de Noticias
    119 UDP NNTP - Grupos de Noticias
    137 TCP NetBios Name Service
    137 UDP NetBios Name Service
    138 TCP NetBios Datagram Service
    138 UDP NetBios Datagram Service
    139 TCP NetBios Session Service
    139 UDP NetBios Session Service
    150 TCP SQL-Net
    150 UDP SQL-Net
    161 TCP Snmp
    194 TCP Internet Relay Chat
    194 UDP Internet Relay Chat
    209 TCP Quick Mail Protocol
    209 UDP Quick Mail Protocol
    217 TCP dBASE Unix
    217 UDP dBASE Unix
    389 TCP NetMeeting
    407 TCP Timbuktu pro
    407 UDP Timbuktu pro
    443 TCP HttpS
    445 TCP Microsoft-Ds (compartir archivos en win 2000)
    515 TCP printer
    522 TCP NetMeeting
    531 TCP Conference
    531 UDP Conference
    568 TCP Microsoft Shuttle
    568 UDP Microsoft Shuttle
    569 TCP Microsoft Rome
    569 UDP Microsoft Rome
    666 TCP doom ID Software
    666 UDP doom ID Software
    700 UDP Buddy Phone
    701 UDP Buddy Phone
    992 TCP Telnet SSL
    992 UDP Telnet SSL
    993 TCP IMAP4 SSL
    993 UDP IMAP4 SSL
    995 TCP POP3 SSL
    995 UDP POP3 SSl
    1024 - 5000 TCP Dwyco Video Conferencing
    1414 UDP CuSeeMe
    1417 TCP Timbuktu pro
    1417 UDP Timbuktu pro
    1418 TCP Timbuktu pro
    1418 UDP Timbuktu pro
    1419 TCP Timbuktu pro
    1419 UDP Timbuktu pro
    1420 TCP Timbuktu pro
    1420 UDP Timbuktu pro
    1424 UDP CuSeeMe
    1503 TCP NetMeeting CuSeeMe
    1547 TCP LapLink
    1720 TCP NetMeeting CuSeeMe
    1731 TCP NetMeeting
    1812 UDP CuSeeMe
    1813 UDP CuSeeMe
    2300 TCP Everquest
    2300 UDP Everquest Age of Empires
    2300 - 2400 TCP Battlecom
    2300 - 2400 UDP Battlecom Aliens vs. Predator
    2301 TCP Age of Empires
    2301 UDP Age of Empires
    2302 TCP Age of Empires
    2302 UDP Age of Empires
    2303 TCP Age of Empires
    2303 UDP Age of Empires
    2304 TCP Age of Empires
    2304 UDP Age of Empires
    2305 TCP Age of Empires
    2305 UDP Age of Empires
    2306 TCP Age of Empires
    2306 UDP Age of Empires
    2307 TCP Age of Empires
    2307 UDP Age of Empires
    2308 TCP Age of Empires
    2308 UDP Age of Empires
    2309 TCP Age of Empires
    2309 UDP Age of Empires
    2310 TCP Age of Empires
    2310 UDP Age of Empires
    2311 TCP Age of Empires
    2311 UDP Age of Empires
    2400 TCP Everquest Age of Empires
    2611 TCP Black and White
    2612 TCP Black and White
    3000 TCP Active Worlds
    3000 UDP Calista IP phone (saliente)
    3100-3999 TCP Delta Force
    3100-3999 UDP Delta Force
    3128 TCP Squid Proxy
    2301 TCP Age of Empires
    3389 TCP Windows 2000 Terminal Server
    3389 UDP Windows 2000 Terminal Server
    3568 UDP Delta Force 2
    3569 UDP Delta Force 2
    4000 TCP Diablo II ICQ
    4099 TCP AIM Talk
    4661 TCP Edonkey 2000
    4662 TCP Edonkey 2000 Overnet
    4662 UDP Overnet
    4665 UDP Edonkey 2000
    5190 TCP Calista IP phone (entrante)
    5500 TCP Virtual Network Computing
    3568 UDP Delta Force
    5631 TCP pcAnyWhere (host)
    5632 UDP pcAnyWhere (host)
    5670 TCP Active Worlds
    5800 TCP Virtual Network Computing
    5900 TCP Virtual Network Computing
    6003 UDP Half Life
    6112 TCP Diablo II
    6112 UDP Diablo II
    6112 TCP StarCraft
    6112 UDP StarCraft
    6257 UDP WinMX
    6346 TCP SwapNut
    6346 UDP SwapNut
    6500 TCP Black and White
    6667 TCP Ircd Black and White MSN Game Zone
    6699 TCP WinMX
    6700 - 6702 TCP Dwyco Video Conferencing
    6880 TCP Dwyco Video Conferencin
    6891 TCP MSN Messenger (archivos)
    6892 TCP MSN Messenger (archivos)
    6893 TCP MSN Messenger (archivos)
    6894 TCP MSN Messenger (archivos)
    6895 TCP MSN Messenger (archivos)
    6896 TCP MSN Messenger (archivos)
    6897 TCP MSN Messenger (archivos)
    6898 TCP MSN Messenger (archivos)
    6899 TCP MSN Messenger (archivos)
    6900 TCP MSN Messenger (archivos)
    6901 TCP MSN Messenger (voz)
    6901 TCP MSN Messenger (voz)
    7000-7100 TCP Active Worlds
    7002 UDP Half Life
    7013 TCP Anarchy Online
    7013 UDP Anarchy Online
    7500 - 7501 TCP Anarchy Online
    7500 - 7501 UDP Anarchy Online
    7640 TCP CuSeeMe
    7642 TCP CuSeeMe
    7648 UDP CuSeeMe
    7648 TCP CuSeeMe
    7649 TCP CuSeeMe
    7777 UDP Unreal Tournament (cliente) Active Worlds
    7778 UDP Unreal Tournament (servidor)
    7779 UDP Unreal Tournament
    7780 UDP Unreal Tournament
    7781 UDP Unreal Tournament
    8000 - 8999 UDP Aliens vs. Predator
    8080 TCP Unreal Tournament (UT Server Admin) HTTP Proxy
    9000 UDP Asheron's Call
    9004 UDP Asheron's Call
    9005 UDP Asheron's Call
    9008 UDP Asheron's Call
    9012 UDP Asheron's Call
    9013 UDP Asheron's Call
    12000 - 16090 UDP Dwyco Video Conferencing
    12053 TCP Delta Three PC to Phone
    12083 TCP Delta Three PC to Phone
    12080 UDP Delta Three PC to Phone
    12120 UDP Delta Three PC to Phone
    12122 UDP Delta Three PC to Phone
    20000-20019 TCP ICQ
    24150 - 24179 UDP Delta Three PC to Phone
    26000 UDP Elite Force
    26214 TCP Dark Reign 2
    26214 UDP Dark Reign 2
    27015 UDP COUNTER STRIKE
    27500 UDP Unreal Tournament (uplink) Elite Force
    27660 UDP Quake III (primer jugador)
    27661 UDP Quake III (segundo jugador)
    27662 UDP Quake III (tercer jugador)...
    27900 UDP Unreal Tournament (uplink) Black and White
    27910 UDP Elite Force
    27960 UDP Elite Force
    28800 - 29000 TCP MSN Game Zone
    47624 TCP Battlecom
    47624 UDP Battlecom
    56800 UDP CuSeeMe
  13. Like
    noname2016gc reaccionó a Marway en Puertos abiertos, cerrados, ocultos.....   
    Un puerto cerrado siempre es más seguro.
    Siempre que se pueda configurar bien, es mucho más seguro el firewall en el router que en el ordenador. Si se bloquea en el router de ahí no pasa el "intruso", si se bloquea en el ordenador quieras o no, ya está más adentro
  14. Like
    noname2016gc reaccionó en [Resuelto] TIPOS DE ATAQUES EN INTERNET   
    **** Tipos comunes de Ataques en Internet ****

    1 Ataques de Negación de Servicio (DoS)
    1.1 ¿Qué es un ataque de negación de servicio.
    1.2 ¿Porqué los ataques de negación de servicio son un problema persistente.
    1.3 Riesgos que conllevan los ataques de negación de servicio.
    1.4 Ataques de consumo de ancho de banda.
    1.5 Ataques de Saturación de Recursos.
    1.6 Ataques de Sistema y Fallo de Aplicaciones.
    1.7 Ataques de Protocolo de Red
    1.8 Algunos ataques DoS.
    2 Ataques de Negación de Servicio Distribuido (DDoS).
    2.1 ¿Qué es un ataque de negación de servicio distribuido...
    2.2 Algunos ataques DDoS.
    3 Raw Sockets, Windows y los ataques DoS.
    4 Spoofing.
    4.1 ¿Qué es Spoofing.
    4.2 La mecánica de un ataque Spoofing.
    4.3 Los ingredientes de un ataque Spoofing con éxito.
    4.4 Quién puede ser objetivo de Spoofing y con qué frecuencia se producen ataques de Spoofing.
    4.5 Herramientas de Spoofing y Hijacking (secuestro).
    4.6 ARP Spoofing.
    4.7 Soluciones al Spoofing.



    1 Ataques de Negación de Servicio (DoS)

    1.1 ¿Qué es un ataque de negación de servicio?

    En su forma más básica un ataque de negación de servicio (DoS) es cualquier acción, iniciada por una persona o no, que incapacita tu el hardware de tu host, el software, o ambos haciendo tu sistema inalcanzable y por consiguiente denegando el servicio a usuarios legítimos (o ilegítimos) . El fin último de un ataque DoS es dejar
    inutilizado tu host en la red.


    1.2 ¿Porqué los ataques de negación de servicio son un problema persistente.

    Primero porque los ataques DoS son rápidos, fáciles y generan un resultado significativo inmediatamente. Estos ataques son populares
    entre cackers principiantes o incluso entre adolescentes con un poco de tiempo libre.

    Pero hay otra razón todavía más importante y es que esos ataques revelan en la mayoría de las veces errores, limitaciones o
    inconsistencias en las implementaciones del TCP/IP que los fabricantes han realizado, y todos estos hosts permanecen vulnerables hasta que el problema es resuelto.


    1.3 Riesgos que conllevan los ataques de negación de servicio.

    Hubo un tiempo en que los ataques DoS eran considerados simplemente como tonterías, había problemas que solucionar, pero no eran considerados problemas críticos. Algunas personas todavía hoy mantienen ese punto de vista, argumentando que la mayoría de los ataques DoS afectan solamente a servicios que son fácilmente reiniciables. Pero este no es el punto de vista dominante. Por el contrario los ataques DoS hoy en día están considerados como desastrosos, básicamente porque los hábitos de uso del ordenador han cambiado radicalmente. Hoy en día los servidores son elementos esenciales en el comercio electrónico así como en otros servicios críticos. Es en este nuevo entorno, donde los ataques DoS pueden suponer perdidas de importantes cantidades de dinero, donde se empieza a tener en cuenta
    este problema. De todas maneras son muy pocas las empresas que pueden hacer frente a un ataque DoS.

    1.4 Ataques de consumo de ancho de banda

    Cada red puede soportar solamente una cantidad finita de tráfico a la vez, y esta cantidad depende de varios factores: velocidad de la red, tipos de equipamiento, y su funcionamiento. Enlaces comunes entre un ISP y las empresas son: ISDL, DSL, Banda Ancha (Usando cable módems), T1, y T3. Estas conexiones tienen distintas capacidades de ancho de banda. Negación de servicio por consumo de ancho de banda tiene lugar cuando toda la capacidad de la red esta siendo utilizada.
    Cuando se alcanza la totalidad del ancho de banda, no pueden introducirse en la red nuevos datos, es decir la red está inutilizada y no se puede transmitir nada a través de ella, por lo que nuevas conexiones a Internet, servidores de ficheros, servidores de Web, servidores de correo o cualquier otra función que requiera de la red estarán fuera de servicio. Las conexiones que hasta el momento hubiera abiertas se ralentizarán, se quedarán “colgadas” o serán desconectadas. Los ataques de consumo de ancho de banda se pueden generar a través de programas especializados y una mala configuración de los equipos de red. La mala configuración de la red incluye cualquier dispositivo que se conecta a la red, como PCs, routers, switches, y otros dispositivos. Los ataques de ancho de banda son activos, el ataque perdura solamente mientras todo el acho de banda esta siendo utilizado. Tan pronto como el programa que genera el ataque deje de enviar datos o los dispositivos configurados correctamente, entonces el ancho de banda comienza a estar disponible. Muchas de las funcionalidades de la red vuelven a la normalidad cuando esto ocurre, excepto unas pocas que deben ser reiniciadas. Ataques comunes incluyen “exploits” basados en los protocolos de red que consumen recursos enviando datos de red
    “trucados”, con una estructura particular. El dispositivo de acceso, por ejemplo un router, puede fallar si se ve inundado con más tráfico del que puede procesar. Otros ataques de ancho de banda están basados en las acciones que realiza un dispositivo a unos datos concretos. Muchas, o todas las maquinas de la red objetivo pueden ser forzadas a responder
    simultáneamente a tráfico de red como puede ser mensajes IP de broadcast, consumiendo todo el ancho de red disponible.

    1.5 Ataques de Saturación de Recursos

    Al igual que una red, cada sistema tiene una serie de recursos que son finitos, incluyendo memoria, almacenamiento y capacidades del procesador. Saturación de recursos significa utilizar toda la capacidad de uno o varios recursos dejando al resto de aplicaciones sin recursos para poder ejecutarse. El ataque “SYN flood” (inundación de paquetes SYN) es un ejemplo muy popular de un ataque que utiliza todos los recursos de red de un sistema. Cada sistema operativo que soporta conectividad con redes TCP/IP tiene un límite de número de conexiones que puede mantener a la vez. “SYN flood” consigue éxito creando multitud
    de conexiones “medio-abiertas” en el puerto del servidor objetivo. Normalmente estas conexiones son cerradas bien porque vence el time-out o porque el protocolo de conexión a tres bandas cierra la conexión. Cada puerto solamente puede soportar un número finito de conexiones “medio-abiertas” y cuando este número es excedido, no se puede realizar ninguna otra conexión. Enviando solamente el primer paquete de una conexión a tres bandas TCP con una dirección IP fuente inválida, el servidor responde a ese paquete SYN con un reconocimiento de la conexión, pero como la dirección no es la correcta, es una dirección falsa, se queda a la espera de un reconocimiento que nunca llegará y así por cada uno de los paquetes SYN que sean enviados consiguiendo que no se puedan realizar más conexiones en esa máquina. Los servidores de Web son normalmente los objetivos de este tipo de ataques DoS, pero cualquier máquina que se conecte mediante TCP es susceptible de ser atacada. Para entender este tipo de ataques en servidores Web primero hemos de entender como funciona un servidor ante una petición http. Una petición y una conexión simple se realizan cuando el navegador se conecta al servidor. Esta petición se hace para un fichero concreto; el servidor envía el fichero y cierra la conexión. Bajo estas circunstancias
    un servidor puede atender un gran número de peticiones porque estas consultas se realizan muy rápidamente. Para que un servidor Web deje de funcionar debido a este tipo de ataque quien genera el ataque debe incrementar el tiempo para manejar esas peticiones o incrementar la cantidad de potencia de procesamiento necesario para cada petición. “SYN flood” hace al servidor incapaz de atender nuevas peticiones de conexión porque se supera el número de conexiones que el puerto puede atender. Muy similares a este ataque son los ataques “ICMP flood” y “UDP flood”, donde la única diferencia reside en el
    protocolo utilizado para conseguir el mismo fin. Es muy difícil defenderse de este tipo de ataques. Otro ejemplo se saturación de recursos puede ocurrir debido al uso de programas externos como puede ser “Common Gateway Interface” (CGI) por parte del servidor de Web. Programas que almacenan datos en los servidores pueden ser “trucados” para que llenen los discos duros del servidor causando el mal funcionamiento del sistema. Del mismo modo las aplicaciones que requieren mucha asignación de memoria o mucha potencia de procesamiento para cálculos comput#cionales complejos pueden ser “trucadas” para que utilicen todos los recursos y bloquear el sistema. Estos ataques no solo se pueden hacer vía la red, sino que cualquier acceso al sistema puede permitir que ocurra un ataque. Otro ejemplo de ataques de saturación de recursos es
    el ataque “e-mail Bomb”. Un ataque de este tipo no es más que una serie de mensajes (quizá miles) que saturan un buzón de correo en el servidor o el disco duro del servidor o tu disco duro. Si lo que se satura es el buzón no se podrá recibir nuevos mensajes en ese buzón hasta que se borren los mensajes. Si lo que se llena es el disco del servidor ningún usuario podrá recibir mensajes hasta que se borren mensajes y se haya espacio libre en el sistema. Los ataques e-mail bombs van destinados a la perdida de datos importantes y ocupan un gran ancho de banda del canal por lo que además el resto de servicios se ralentiza. Una variante de los ataques “e-mail bomb” son los llamados “list linking” aunque su apariencia no sea maligna a simple vista, ya que estar suscrito a una lista de correo no parece que pueda afectar mucho a tu sistema,
    pero si lo que ocurre es que sin tu conocimiento te suscriben a decenas de listas de distribución de correo, entonces lo que ocurre es que pueden llenar tu buzón y posiblemente el servidor con correos provenientes de estas listas, ya que muchas de estas listas pueden llegar a generar hasta 50 mensajes por día, y muchos de esos mensajes tienes datos adjuntos
    con lo que si el objetivo del ataque ha sido incluido por ejemplo en 100 de estas listas puede llegar a recibir 5000 mensajes por día. Además este tipo de ataques tiene difícil solución, porque los filtros de correo no resuelven el problema, sino que lo ocultan, el problema se resuelve cuando dejas de estar suscrito a esas listas de distribución,
    y hacerlo manualmente de todas las listas a las que estas suscrito puede convertirse en una tarea muy costosa, por lo que ese ataque generalmente tiene una duración aproximada de unos 6 meses que suele ser la periodicidad con la que ese tipo de listas normalmente requieren que sus miembros actualicen su deseo de estar inscrito en la lista o no.
    Actualmente para luchar contra este tipo de ataques muchas de estas listas requieren la confirmación de los suscriptores además de ofrecer contraseñas a los miembros de las listas. Esas contraseñas se utilizan para que los miembros de las listas modifiquen sus datos de suscripción y se autentifiquen. Son útiles para mantener copias de los mensajes originales de suscripción después de añadirse a una lista. Esos mensajes no ocupan espacio apenas, pero contienen la información
    necesaria para darse de baja de la lista o mantener la suscripción.

    1.6 Ataques de Sistema y Fallo de Aplicaciones

    Son aproximaciones rápidas y sencillas a ataques de DoS, cuando un flujo de programa genera un “exploit” y fuerza a
    la aplicación o al sistema a fallar. Un ejemplo muy conocido de este tipo de ataques es el ataque “Ping of Death”
    (Ping de la Muerte) que utiliza un mensaje de petición ICMP de mayor tamaño que el permitido. La maquina objetivo
    fallará debido a la mala implementación del manejador de este tipo de mensajes. Estos ataques también son dirigidos
    a menudo hacia dispositivos de acceso de red como pueden ser routers IP, Ethernet Switches, VPNs. Estos dispositivos
    normalmente soportan una configuración a través de una interfaz incluyendo una Command Line Interface (CLI) y
    una interfaz de manejo vía Web. Por medio de varios métodos, incluidas un gran número de conexiones simultáneas,
    desbordamiento de buffers y validaciones de datos incorrectos, se ha hecho fallar esos dispositivos. Un ataque DoS
    en esos dispositivos tiene una repercusión más amplia que un ataque en una simple máquina debido a qué normalmente
    detrás de estos dispositivos hay múltiples redes. Muchos de estos ataques pueden ser evitados gracias a una buena
    configuración de los dispositivos de red, esto incluye el correcto uso de las contraseñas y que solamente unas máquinas
    concretas puedan configurarlos.

    1.7 Ataques de Protocolo de Red

    Una gran parte de los ataques de DoS son ataques contra protocolos de red. Estos ataques sobre los protocolos dan como resultado consumo de ancho de banda, que los sistemas
    fallen, y saturación de recursos, causando condiciones de DoS. Estos ataques son una gran amenaza y pueden detener la
    conectividad con la red y la funcionalidad del sistema durante una cantidad indeterminada de tiempo. La prevención de este
    tipo de ataques requiere procedimientos más complejos y avanzados y tomar contramedidas. Este tipo de ataques van
    dirigidos al núcleo de las implementaciones del protocolo IP, y como las implementaciones de este protocolo no difieren
    mucho de una plataforma a otra, un simple ataque DoS puede funcionar en distintos sistemas operativos. Un ejemplo muy
    conocido es el ataque “Land”, que dejó incapacitados alrededor de dos docenas de sistemas operativos, entre ellos
    Windows NT, y varias versiones de UNIX. Otros ejemplos son los ataques “SYN / ICMP / UDP flood” que como hemos comentado
    anteriormente se apoyan en los protocolos de red para conseguir la saturación de los recursos de la maquina afectada.
    Análisis de los ataques DoS muestran que cuando un nuevo ataque entra en funcionamiento, eventualmente funciona en todas
    o casi todas las plataformas incluso a veces no tiene porque ser al principio de que el ataque salga a la luz. Nuevas
    variantes de ataques de DoS salen a la luz cada dos semanas más o menos, esas variantes están escritas en una plataforma
    (ej. Linux) para atacar una plataforma concreta (ej. Windows NT). Después ese código es “revisado” por la comunidad de
    hackers y crackers y pasados unos días aparecen distintas versiones (mutaciones) del mismo código que pueden dejar
    incapacitadas una mayor variedad de plataformas.


    1.8 Algunos ataques DoS

    Sesquipedalian
    Fichero: Sesquipedalian.c
    Autor:
    Creado en (S.O.): UNIX
    Creado para (S.O.): Cualquier sistema que responda a mensajes ICMP
    Fecha: Marzo 1999
    Resultado: Mata la conectividad IP de la maquina
    Funcionamiento: Este ataque ejecuta un error en ip_fragment.c en la función ip_glue(). Ip_fragment.c ejecuta la
    fragmentación de Ip para Linux. Durante el tránsito, los datagramas IP son fragmentados y deben ser reensamblados en
    el destino. Cuando Linux acepta los datagramas, los cuenta, este proceso continúa hasta que todos los fragmentos han
    sido recibidos. Si el primer datagrama IP tiene longitud 0 se crean 2 entradas de cache una la que debe generar y una por
    error, como Linux tiene un tamaño de cache máximo cuando este se desborda no se pueden atender más peticiones.

    Smurf
    Fichero: smurf.c
    Autor: TFreak
    Creado en (S.O.): UNIX
    Creado para (S.O.): Cualquier sistema que responda a mensajes ICMP
    Fecha: Enero 1998
    Resultado: Negación de servicio debido a la recepción de múltiples mensajes ICMP ECHOREPLY.
    Funcionamiento: Se envían mensajes ICMP ECHO_REQUEST a una dirección de Broadcast con una dirección IP origen que no es
    la de quien envía el mensaje, sino la dirección IP de la victima del ataque, con lo todas las contestaciones al mensaje
    ICMP de la red irán dirigidas a una sola máquina, causando una negación de servicio que provoca que la red sea
    inaccesible para ese host. Del mismo modo las maquinas de la red que responden al mensaje ICMP ECHOREQUEST pueden sufrir
    ellos mismos la negación del servicio si la red se colapsa o tienen que responder a gran cantidad de mensajes.
    Solución: Deshabilitar el tráfico IP dirigido a direcciones de Broadcast en el router de la red y configurar el sistema
    para que no responda a paquetes enviados a direcciones IP de Broadcast, es útil para las maquinas de tu red no sirvan
    de intermediario, pero no hay solución posible para la victima.

    Fraggle
    Fichero: fraggle.c
    Autor: TFreak
    Creado en (S.O.): UNIX
    Creado para (S.O.): Cualquier sistema que responda a mensajes UDP. Fecha: Enero 1998 Resultado: Negación de servicio
    debido a la recepción de múltiples mensajes UDP. Funcionamiento: Se envían mensajes UDP al puerto 7 (echo)a una dirección
    de Broadcast con una dirección IP origen que no es la de quien envía el mensaje, sino la dirección IP de la victima del
    ataque, con lo todas las contestaciones al mensaje UDP de la red irán dirigidas a una sola máquina, causando una negación
    de servicio que provoca que la red sea inaccesible para ese host. Del mismo modo las maquinas de la red que responden al
    mensaje UDP echo pueden sufrir ellos mismos la negación del servicio si la red se colapsa o tienen que responder a gran
    cantidad de mensajes. Solución: Deshabilitar el tráfico IP dirigido a direcciones de Broadcast en el router de la red y
    configurar el sistema para que no responda a paquetes enviados a direcciones IP de Broadcast, es útil para las maquinas
    de tu red no sirvan de intermediario, pero no hay solución posible para la victima.

    ICMP Flood
    Fichero: pingflood.c
    Autor: AntireZ
    Creado en (S.O.): UNIX, Linux.
    Creado para (S.O.): Varios.
    Fecha: Abril 1999
    Resultado: Negación de servicio debido a la saturación del ancho de banda de la red. Funcionamiento: Se envían multitud
    de mensajes ICMP ECHO_REQUEST a la dirección que se quiere atacar. Se consigue enviando muchas SIGALARMS al sistema,
    por lo que envía muchos más pings por segundo en vez de uno cada segundo que es lo que realiza normalmente un ping normal
    en UNIX, Linux. Solución: Bloquear todo el tráfico ICMP en el. Firewall y en el S.O.

    SYN Flood
    Fichero: synflood.c
    Autor: Varios
    Creado en (S.O.): UNIX, Linux.
    Creado para (S.O.): Varios.
    Fecha: Abril 1999
    Resultado: Negación de servicio debido a que el sistema supera el número de conexiones “medio abiertas” que puede soportar.
    Funcionamiento: Se envían multitud de mensajes SYN a la dirección que se quiere atacar con una dirección fuente falsa.
    El sistema solamente puede soportar cierto número de conexiones “medio abiertas” y cuando se alcanza ese número no se
    pueden tener más conexiones de otro tipo por lo que no podemos utilizar la red. Solución: Configurar el S.O. para que
    soporte más conexiones “medio abiertas”.

    UDP Flood
    Fichero: udpflood.tgz
    Autor: Varios
    Creado en (S.O.): UNIX, Linux.
    Creado para (S.O.): Varios.
    Fecha: Noviembre 1999
    Resultado: Negación de servicio debido a que el sistema no puede manejar a la vez tantas peticiones UDP. Funcionamiento:
    Se envían multitud de mensajes UDP a la dirección que se quiere atacar con una dirección fuente falsa. El sistema
    solamente puede manejar un número determinado de peticiones en un instante de tiempo por lo que no podemos utilizar
    la red mientras el sistema está ocupado manejando esas peticiones. Solución: Prohibir el tráfico y los servicios UDP en
    el firewall y en el S.O.

    Los dos siguientes ataques son ataques históricos bien conocidos.

    Ping of Death
    Fichero: pingexploit.c ; win95ping.c
    Autor: Bill Fenner
    Creado en (S.O.): BSD UNIX
    Creado para (S.O.): Windows 95 y Windows NT 3.51
    Fecha: Octubre 1996
    Resultado: El sistema falla, se queda “colgado” y debe ser reiniciado.
    Funcionamiento: Se envían mensajes ICMP ECHO_REQUEST de un tamaño mayor 64k los cuales el sistema no puede manejar
    correctamente y falla.
    Solución: Instalar un parche del fabricante del S.O. (Microsoft).

    Winnuke (Out of Bouns)
    Fichero: winnuke.c
    Autor: _eci
    Creado en (S.O.): Linux
    Creado para (S.O.): Windows (v 3.11/v 95) y Windows NT (v 3.51/v 4.0)
    Fecha: Octubre 1996
    Resultado: El sistema falla y debe ser reiniciado.
    Funcionamiento: Se envían paquetes “junks” al puerto 139 del sistema con el flag OOB activo y el sistema no puede
    procesar correctamente esos paquetes y falla. Solución: Instalar un parche del fabricante del S.O. (Microsoft).

    2 Ataques de Negación de Servicio Distribuido (DDoS)

    2.1 ¿Qué es un ataque de negación de servicio distribuido?

    Los ataques de negación de servicio distribuidos son aquellos ataques de negación de servicio que han sido generados por
    un gran número usuarios, cientos incluso miles. La realidad pronto demostró que este nuevo tipo de ataques DDoS se iba
    a convertir en una pesadilla para los servidores Web y de negocio. Al principio de que este tipo de ataques surgieran
    aparecieron rumores de que una comunidad underground de “crackers” conspiraba para atacar simultáneamente. Posteriormente
    se vio que este tipo de ataques funcionaban mediante un mecanismo master-slave (maestro-esclavo). La estación master es
    quien decide cual es el objetivo y el método de ataque. Las estaciones slave son estaciones remotas que han sido
    “infectadas” anteriormente por lo que tienen la herramienta de ataque instalada en el sistema. La estación master envía
    una señal a las estaciones slave y estas comienzan el ataque, éste termina cuando la estación master envía otra señal
    indicando que el ataque ha finalizado. Se dice que las estaciones slave han sido “infectadas” porque en la mayoría de
    los casos los usuarios de estas estaciones no tienen conocimiento de que su máquina está participando en un ataque DDoS.
    Esto se consigue mediante la utilización de pequeños ficheros ejecutables los cuales se instalan en el sistema y están
    siempre en ejecución esperando recibir la señal apropiada para comenzar el ataque. El usuario del sistema normalmente no
    se da cuenta que está participando en un ataque porque solamente está participando en el ataque para enviar mensajes a
    través de la red y su canal de entrada desde la red no se ve afectado por lo que su ancho de banda para recibir mensajes
    es el mismo no notando diferencia alguna en la utilización de su sistema.


    2.2 Algunos ataques DDoS

    Trinoo (Trin00)
    Fichero: trinoo.tgz
    Autor: Project DoS
    Creado en (S.O.): UNIX
    Creado para (S.O.): UNIX
    Fecha: Abril 1999
    Resultado: Negación de servicio hasta que cesa el ataque.
    Funcionamiento: Se instalan unos demonios en muchas maquinas y quedan a la espera de ser ejecutados remotamente
    (maquinas slave). Después quien genera el ataque inicia el master en un servidor trino y este llama a todos los
    slaves que tiene disponibles y generan el ataque, enviando paquetes a puertos UDP aleatorios (0-65534) a la dirección IP
    que el master ha especificado durante un periodo de tiempo.
    Solución: Bloquear el tráfico UDP en muchos puertos de la máquina solucionará el problema, pero algunas aplicaciones de
    red pueden dejar de funcionar correctamente.

    Tribe Flood Network (TFN)
    Fichero: tfn.tgz
    Autor: Mixter
    Creado en (S.O.): UNIX
    Creado para (S.O.): UNIX
    Fecha: Abril 1999
    Resultado: Negación de servicio hasta que cesa el ataque.
    Funcionamiento: Se instalan unos demonios en muchas maquinas y quedan a la espera de ser ejecutados remotamente
    (maquinas slave). La comunicación entre el cliente TFN (master) y los demonios se realiza a través de paquetes
    ICMP_ECHOREPLY, para que el cliente no responda al master. Los demonios pueden generar ataques “UDP/ICMP/SYN flood”.
    En caso que el ataque sea mediante “SYN flood”, si no se especifica el puerto, éste se selecciona aleatoriamente.
    Solución: Bloquear todo el tráfico “echo” ICMP solucionará el problema, pero esto puede no ser posible dependiendo de
    las necesidades de la red de utilizar ICMP.

    Tribe Flood Network 2K (TFN2K)
    Fichero: tfn2k.tgz
    Autor: Mixter
    Fecha: Febrero 2000
    Creado en (S.O.): UNIX
    Creado para (S.O.): UNIX, Windows NT/2000
    Resultado: Negación de servicio hasta que cesa el ataque.
    Funcionamiento: Se instalan unos demonios en muchas maquinas y quedan a la espera de ser ejecutados remotamente
    (maquinas slave).La comunicación entre el cliente TFN2K (master) y los demonios se realiza a través de paquetes
    ICMP, TCP y UDP. Los demonios pueden generar ataques “UDP/ SYN/ ICMP echo/ICMP broadcast flood” a una o varias
    direcciones IP objetivo. Solución: Bloquear el tráfico TCP, UDP y ICMP innecesario es una solución al problema, del
    mismo modo que se pueden utilizar proxies para prevenir el ataque.

    Stachledraht (Barbed Wire)
    Fichero: satchel.tgz
    Autor: Desconocido
    Creado en (S.O.): Linux, Solaris
    Creado para (S.O.): Linux, Solaris
    Fecha: Septiembre 1999
    Resultado: Negación de servicio hasta que cesa el ataque.
    Funcionamiento: Se instalan unos demonios en muchas maquinas y quedan a la espera de ser ejecutados remotamente
    (maquinas slave).La comunicación entre el manejador satchel (master) y los demonios se realiza a través de
    paquetes TCP e ICMP ECHOREPLY en los puertos 16660 o 60001. Los demonios pueden generar ataques “UDP/SYN/ICMP flood”,
    a una o varias direcciones IP objetivo. En caso que el ataque sea mediante “SYN flood”, puede ser dirigido a un grupo
    de puertos. Solución: Bloquear todo el tráfico “echo” ICMP solucionará el problema, pero esto puede no ser posible
    dependiendo de las necesidades de la red de utilizar ICMP.

    3. Raw Sockets, Windows y los ataques DoS

    En 1981 The Computer Systems Research Group (CSRG), en la Universidad de California, Berkeley unió el sistema operativo
    UNIX a Internet implementando los protocolos y creando el “TCI/IP Stack” para UNIX. Para simplificar la tarea de crear
    aplicaciones que se conectaran a Internet, CSRG diseñó una abstracción simple de los protocolos que estaban por debajo.
    Ellos llamaron a esta abstracción Sockets, también conocida como Berkeley Sockets. Con este sistema las aplicaciones no
    tienen porqué conocer los detalles de los protocolos que quieren utilizar, esta tarea la realizan los Sockets por las
    aplicaciones. Los datos son transmitidos por Internet estableciendo conexiones TCP bidirecionales o mediante conexiones
    UDP unidireccionales entre dos máquinas. Ambos tipos de conexiones utilizan Standard Sockets. Pero la gran cantidad de
    datos que circulan por Internet, requieren de máquinas que informen de varios eventos que ocurren, como puede ser el
    caso de que haya puertos cerrados, congestión en la red, direcciones IP inalcanzables, etc. El protocolo ICMP, fue
    creado con este propósito, para informar de los eventos que ocurren en la red. Los S.O. construidos con el TCI/IP Stack
    generan y reciben automáticamente este tipo de mensajes, sin que nos demos cuenta de ello. Para facilitar la creación
    de herramientas que permitan recorrer la red como si de una tubería se tratara, los diseñadores de Berkeley permitieron
    a los programadores generar y recibir manualmente sus propios mensajes ICMP, y otro tipo de tráfico de mensajes. Para
    este tipo de mensajes en los Berkeley Sockets se crearon unos Sockets especiales llamados Raw Sockets, los cuales
    crean un puente entre el núcleo del sistema de red y la pila TCI/IP y crean una “puerta de atrás” en el nivel de
    transporte. Esto provee al programador de una capacidad directa y total de acceso a Internet a nivel de paquete físico.
    Más allá del uso para herramientas como ping y traceroute, los diseñadores de los Berkeley Sockets crearon los Raw
    Sockets para ser utilizados como una potente herramienta de investigación para IP, nunca fueron creados para ser
    incluidos en S.O. enfocados con un gran mercado de usuarios finales. Aun así y debido al gran peligro que supone
    el abuso de esta herramienta, se negó el acceso a la misma a aquellos procesos UNIX que no tuvieran los máximos
    privilegios posibles (Root). Las aplicaciones de nivel de usuario no pueden acceder a los Raw Sockets. Por otra parte
    están los S.O. de Microsoft, que tradicionalmente utilizaban su propio sistema de Sockets, llamado WinSock. La
    implementación que Microsoft hacía de los Raw Sockets, no penetraba la capa IP para comunicarse con el núcleo del
    sistema de red como pasa en los Raw Sockets de UNIX y sistemas “Estilo-UNIX”. Esto significa que mientras los Raw
    Sockets de Windows podían ser utilizados para el propósito que fueron diseñados de generar y recibir válidos ICMP ping
    y traceroute, las aplicaciones no pueden penetrar en el núcleo del sistema y tener acceso a Internet a nivel de paquete
    físico. Esta implementación incompleta de los Raw Sockets que Windows hacía en su WinSock, no se sabe si por “pereza”
    o por seguridad, suponía un gran beneficio a Internet, contribuyendo enormemente en su estabilidad, ya que desde estos
    sistemas las aplicaciones Windows eran incapaces de “trucar” su dirección IP o hacer Spoofing, con lo cual no podían
    ocultar el origen de cualquier tráfico que ellos pudieran generar, incluido el malvado. Esto se traduce en que la
    cantidad de troyanos y zombis que hay en multitud de equipos Windows han sido incapaces de hacer spoofing con su
    dirección IP, sabiendo que máquinas han participado en ataques y/o están “infectadas”. Del mismo modo tampoco se
    podían generar deliberadamente ataques SYN Flood, y otros de este estilo, los cuales generalmente no pueden ser
    filtrados y suelen ser efectivos. Pero Microsoft en sus nuevos S.O. Windows 2000 y Windows XP ha realizado en su
    Winsock una implementación competa de los Raw Sockets. En otras palabras lo que Microsoft ha hecho con Windows 2000 y
    Windows XP, es añadir un número de potentes e innecesarias características de red, simplemente para complacer a unos
    pocos usuarios expertos que se quejaban de la incompleta implementación de las Raw Sockets que se hacía en el WinSock.
    A pesar de estas quejas, solamente el código maligno que circula por Internet es el que necesita este avanzado “acceso
    directo” que suministra este nuevo WinSock con una implementación completa de los Raw Sockets. Como ha quedado
    sobradamente demostrado con el éxito de los servidores con tecnología Windows NT y el buen funcionamiento de los
    sistemas Windows 95/98/ME en Internet, todos ellos sin disponer de la implementación completa de los Raw Sockets
    en el WinSock, el soporte total de los Raw Sockets es totalmente innecesario en un S.O. para el uso de cualquier
    aplicación “no maligna” de Internet. Extensiones de los protocolos de Internet, que puedan representar un uso legítimo
    de los Raw Sockets, podrían ser implementadas sin utilizar el núcleo del sistema de red. Sockets son una interfaz de
    nivel de aplicación, no un recurso de sistema, y las aplicaciones no tienen necesidad real de Raw Sockets completos.
    Microsoft argumenta que ha incluido una implementación completa de los Raw Sockets debido a que los programadores
    demandaban la estandarización del interfaz WinSock, y debido también, a que con los “viejos” sistemas Windows
    un hacker podía, instalando parches y ciertas utilidades utilizar en Sockets con control total sobre el nivel
    de red. Además Microsoft argumenta que so bien es cierto que un programa corriendo en Windows XP, tiene acceso
    a Raw Sockets completos, es mucho más difícil introducir un troyano o un zombi si estos sistemas están correctamente
    configurados. Veremos que ocurre a partir de que la mayoría de usuarios de sistemas Windows que utilicen Internet
    migre sus “viejos” sistemas por Windows XP, que consecuencias puede tener para el buen, o mal, funcionamiento de
    Internet. Pese a que Windows 2000 también implementa esta nueva versión de WinSock, debido al mercado que va destinado
    este sistema, no es apreciable el impacto que pueda tener esta característica.


    4 Spoofing

    4.1 ¿Qué es Spoofing?

    Es una técnica más o menos sofisticada de autenticar una maquina en otra maquina con una dirección fuente de
    “confianza”. En otras palabras, consiste en modificar en los mensajes que salen de una máquina la dirección fuente
    haciendo creer a los destinatarios de esos mensajes que es otra dirección quien le envía el mensaje y además esa es
    una dirección de “confianza”. Por una dirección de “confianza” se entiende que esa dirección esta autorizada a mantener
    una relación con la máquina destino. Autenticación es el proceso mediante el cual las maquinas se identifican una con la
    otra. Normalmente confianza y autenticación mantienen una relación de inversa proporcionalidad, es decir a mayor
    confianza menos autenticación es requerida, y a mayor autenticación, menor confianza hay. A pesar de que no nos damos
    cuenta nosotros estamos autenticándonos constantemente, por ejemplo tenemos que utilizar nombre usuario y contraseña
    para utilizar alguno de los siguientes servicios: • La Conexión a Internet • FTP Sites • Servicios de Telnet y cuentas
    de usuario El significado de que todas estas autenticaciones y muchas más sean requeridas es la poca confianza que
    existe en Internet con los usuarios que se conectan. Las máquinas se pueden autenticar de muchas maneras, dependiendo
    de su relación de confianza. Por ejemplo una máquina puede ser autenticada por su nombre de host o por su dirección
    IP.

    4.2 La mecánica de un ataque Spoofing

    El hecho de que la autenticación de direcciones fuente falle, no supone que
    sea posible el Spoofing. Esto es porque el mecanismo de conexión requiere mucho más que simplemente una dirección
    IP correcta, requiere un dialogo entre las dos máquinas. Este dialogo puede explicarse por pasos: • IP es responsable
    del transporte de los paquetes, pero este transporte es inseguro, no hay garantía alguna de que los paquetes lleguen
    intactos. IP a veces no consigue que lleguen los paquetes, así que el primer paso para iniciar una conexión es que
    lleguen los paquetes intactos al host apropiado. • Después de que los paquetes hayan llegado, actúa TCP. TCP es un
    servicio más seguro y tiene herramientas para comprobar si los paquetes llegan y si lo hacen intactos. Cada paquete
    es verificado individualmente. TCP procesa si los paquetes tienen error secuencialmente, si 5 paquetes son enviados
    (1,2,3,4,5), estos son procesados en orden de llegada. Cuando se inicia una conexión TCP el primer paquete del
    cliente se identifica con un número de secuencia aleatorio, los siguientes paquetes están numerados con respecto a
    este número. El servidor responde a este mensaje con el reconocimiento de este núm de secuencia y con un número de
    secuencia propio que debe ser reconocido por el cliente. Este procedimiento de inicio de una conexión TCP se llama
    protocolo a tres bandas. El problema para quien quiere generar un ataque de spoofing se puede caracterizar como sigue.
    Primero debe “trucar” la dirección fuente y segundo debe mantener un diálogo con la máquina objetivo. Es esta segunda
    parte de este proceso la que hace complejo el ataque, y el porqué es debido a que la secuencia de dialogo no es
    arbitraria, es la máquina objetivo quien genera el número de secuencia al cual debe responder el atacante con el
    reconocimiento pertinente. Además el atacante debe adivinar este número de secuencia ya que no recibe los paquetes
    que envía el objetivo puesto que la dirección IP fuente que el atacante ha enviado estaba “trucada”.

    - Pongamos un ejemplo: • El cracker conoce que 207.171.0.111 y 199.171.190.9 mantienen una relación de confianza, es
    decir tienen una conexión establecida y quiere entrar en 207.171.111. Para entrar debe hacerse pasar por 199.171.190.9
    y lo consigue “trucando” la dirección de su máquina. • El problema reside en que las respuestas de 207.171.0.111
    son enrutadas hacia 199.171.190.9 y no a la máquina del cracker. Es por esto que el cracker no puede ver el tráfico
    de paquetes, y es por esta incapacidad de ver el tráfico de estos paquetes por lo que a esta técnica de spoofing se
    le llama “blind spoofing”. Si por el contrario el trafico de estos paquetes puede ser visto por el cracker entoces
    la técnica se llama “Non blind spoofing”.

    El caso de los ataques “blind spoofing” presenta una mayor problemática. Mirando el ejemplo que hemos puesto si la
    maquina 199.171.190.9 responde a la maquina objetivo mientras se está produciendo el ataque entonces fallará todo
    el proceso. Debido a esto el atacante deberá además realizar un paso antes de realizar el ataque. Deberá realizar
    el spoofing cuando la máquina 199.171.190.9 no esté en marcha o implementar un mecanismo para que 199.171.190.9 se
    ponga a “dormir” y deje de enviar tramas a la máquina objetivo. La máquina 199.171.190.9 puede ser “matada” mediante
    un ataque SYN flood, de esta manera el sistema será incapaz de tener más conexiones “medio abiertas” y no puede utilizar
    la red.

    4.3 Los ingredientes de un ataque Spoofing con éxito

    Los principales pasos que se deben llevar a cabo en un ataque spoofing son:
    • El cracker debe identificar su objetivo.
    • Debe “domir” el host por el que él se quiere hacer pasar.
    • Debe “trucar” su dirección IP con la del host por el que se quiere hacer pasar.
    • Se debe conectar al objetivo como si fuera el host dormido.
    • Debe adivinar el número de secuencia correcto que espera el objetivo.

    Los primeros cuatro pasos son sencillos, pero adivinar el número de secuencia resulta muy complicado. Para realizar
    esta tarea el cracker debe ejecutar una conexión de prueba solicitando al objetivo una petición de conexión.
    El objetivo responde a esta petición con una ráfaga de números de secuencia. El cracker entonces registra esos números
    de secuencia y cierra la conexión. El cracker examina los números de secuencia que ha obtenido del objetivo, en este
    análisis el intenta descubrir un patrón ya que el conoce que esos números de secuecia son incrementados uniformemente
    por un algoritmo especialmente diseñado para ese propósito. Su tarea es descubrir ese algoritmo con el fin de averiguar
    los valores numéricos con los que los números de secuencia son incrementados. Cuando él conoce esto puede predecir que
    numero de secuencia es solicitado en la conexión para la autenticación y está listo para generar el ataque. Spoofing
    es una difícil y extraordinaria técnica, pero lo más sorprendente de todo es que en ambientes de seguridad relativa a
    redes desde 1985 se sabía que spoofing era posible. Cuando el proceso de conexión y autenticación han concluido, el
    cracker debe crear un agujero más apropiado a través del cual “colarse” en el sistema y no tener que utilizar spoofing
    cada vez que quiere conectarse con el objetivo. El agujero más fácil es rescribir el fichero .rhosts de manera que el
    objetivo aceptara conexiones sin necesidad de pedir autenticación adicional. De esta manera el cracker puede cerrar
    la conexión y reconectarse cuantas veces quiera sin necesidad de contraseña y tiene control sobre el sistema.

    4.4 Quién puede ser objetivo de Spoofing y con qué frecuencia se producen ataques de Spoofing

    IP Spofing solamente puede ser implementado contra un cierto tipo de máquinas corriendo ciertos servicios.
    Muchos sistemas UNIX son potenciales objetivos, aunque los sistemas NO-UNIX no son invulnerables a este tipo de
    ataques. Los siguientes servicios se conoce que son vulnerables:
    • Cualquier dispositivo ejecutando Sun RPC.
    • Cualquier servicio de red que utiliza autenticación de las direcciones IP.
    • El sistema X Windows de MIT.
    • Los servicios “r”.

    Aunque parecen pocos los servicios que se conoce que son vulnerables, tengamos en cuanta que la
    mayoría de servicios de red que conocemos utilizan autenticación basada en direcciones IP y aunque los otros servicios
    son propios de sistema UNIX, el resto de sistemas NO-UNIX no son inmunes. Windows NT por ejemplo es vulnerable a ataques
    de números de secuencia. Las sesiones pueden ser “secuestradas” a través de adivinar el número de secuencia TCP. En el
    fondo es un problema de spoofing, que incluso afecta a conexiones NetBIOS y SMB. Los ataques de Spoofing solían ser
    raros, debido a la complejidad del proceso, pero después de Enero de 1995 se volvieron más comunes. Esto es así porque
    antes de 1995 quien generaba un ataque de este tipo debía tener un amplio conocimiento acerca de TCP/IP, sockets y
    programación de red, pero ahora eso ya no es preciso, ya que empezaron a aparecer programas que realizaban Spoofing. Hoy
    en día aplicaciones que implementan Spoofing están ampliamente difundidas y pueden ser descargadas incluso desde Internet.


    4.5 Herramientas de Spoofing y Hijacking (secuestro)

    1644
    Autor: Vasim V.
    Lenguaje de programación: C
    Creado en (S.O.): FreeBSD
    Creado para (S.O.): UNIX
    Requerimientos: Compilador de C, ficheros de cabecera IP, FreeBSD.

    Hunt
    Autor: Pavel Krauz
    Lenguaje de programación: C
    Creado en (S.O.): Linux
    Creado para (S.O.): Linux
    Requerimientos: Compilador de C, Linux.

    IPSpoof
    Autor: Desconocido
    Lenguaje de programación: C
    Creado en (S.O.): UNIX
    Creado para (S.O.): UNIX
    Requerimientos: Compilador de C, ficheros de cabecera IP, UNIX.

    Juggernaut
    Autor: Route
    Lenguaje de programación: C
    Creado en (S.O.): UNIX
    Creado para (S.O.): UNIX
    Requerimientos: Compilador de C, ficheros de cabecera IP, UNIX.

    Rbone
    Autor: Desconocido
    Lenguaje de programación: C
    Creado en (S.O.): Linux
    Creado para (S.O.): UNIX
    Requerimientos: Compilador de C, ficheros de cabecera IP, Linux.


    4.6 ARP Spoofing

    Un ataque ARP Spoofing es una técnica que altera la caché ARP. La caché ARP contiene una tabla en la que se
    relacionan direcciones máquina con direcciones IP. Este sistema consiste en mantener tu dirección hardware en la
    tabla pero relacionada con la dirección IP de una máquina de “confianza”. Esta información se le envía a la caché ARP
    de tu máquina y a la caché ARP de la máquina objetivo. A partir de ese momento los paquetes del objetivo se encaminan
    hacia tu máquina ya que la máquina objetivo se cree que tu eres su host con quien el “confía”. Hay grandes
    limitaciones en este tipo de ataques. Una es que el “invento” fallará al atravesar routers inteligentes, además
    ARP Spoofing es realizable sólo bajo ciertas condiciones e incluso en esas condiciones es probable que pueda
    utilizarse solo en tu segmento de red. Además las cachés expiran en muy poco tiempo por lo que se debería actualizar
    constantemente la caché mientras se genera el ataque.

    4.7 Soluciones al Spoofing

    Las organizaciones de usuarios y los proveedores de servicio de Internet (ISP), pueden asegurar que el tráfico que
    sale del site de una organización, o el que entra en la red de un ISP desde un site, lleva una dirección fuente con
    el rango de direcciones de ese site de red. Aunque esto permite hacer Spoofing con direcciones de dentro de ese rango,
    puede permitir trazar una ruta del tráfico del ataque hasta el site del que parte, localizando el problema solo en un
    rango de direcciones, más o menos amplio, dependiendo de la magnitud del site. Además las organizaciones de usuarios
    quieren asegurar que no sale tráfico de esos sites con direcciones inalcanzables, listadas en RFC 1918, este proceso
    se llama “egress filtering”, el cual lo pueden realizar los Routers de estos sites porque tienen la capacidad de ello.
    ISP pueden además pueden detener el Spoofing, aceptando tráfico solo de fuentes autorizadas, este proceso se llama
    “ingress filtering”. Los usuarios que utilizan conexiones telefónicas a Internet, no a traves de servicios de banda
    ancha, son la fuente de algunos ataques. Detener el Spoofing de estos usuarios es un paso importante, donde los ISP
    y todos aquellos que sirven estos servicios, deben asegurarse de instalar los filtros adecuados que sean necesarios
    para que evitar que estos usuarios utilicen direcciones “trucadas”. Los fabricantes deben asegurar que sea imposible
    realizar Spoofing desde equipamiento de acceso telefónico a redes.
×
×
  • Crear nuevo...

Información importante

Términos de Uso Política de privacidad Hemos colocado cookies en su dispositivo para ayudar a mejorar este sitio web. Puedes ajustar la configuración de tus cookies ; de lo contrario, asumiremos que quieres continuar.