PDF de programación - Tácticas de guerra en el IRC

Imágen de pdf Tácticas de guerra en el IRC

Tácticas de guerra en el IRCgráfica de visualizaciones

Actualizado el 21 de Marzo del 2018 (Publicado el 18 de Noviembre del 2017)
256 visualizaciones desde el 18 de Noviembre del 2017
467,3 KB
48 paginas
Creado hace 17a (24/02/2003)
Tácticas de guerra en el IRC v.4.1



Por: RoMaN SoFt / LLFB (20/09/99)

_______________________________________________________________________________________________

(c) RoMaN SoFt / LLFB, 1998, 1999
La distribución de este documento es "libre", con la única condición de informar al autor en caso
de subirlo a algún ftp site o página web, y siempre que no sea con fines comerciales ni reporte
beneficio económico alguno. Las mismas restricciones se aplican a cualquier otra forma de difusión
pública (revistas, news, étc). En el caso de publicaciones (revistas) ésta deberá ser completamente
gratis. El documento debe ser distribuido de forma íntegra, no está permitida la modificación total o
parcial ni la difusión de partes aisladas del mismo. En caso de incumplimiento se emprenderá las
acciones legales pertinentes. Contactar con el autor para cualquier otra modalidad o forma de
difusión.
###############################################################################################

0.- Contenido.

1.- Introducción.
2.- Principios.
2.1.- Cómo funciona una red IRC.
2.2.- Conseguir op sin que nadie te lo de.
2.3.- Otras formas de conseguir op.
2.4.- Bot de servicio.

3.- Ataques.

3.1.- Flood.
3.2.- Nick collide.

3.2.1.- Split server collide.
3.2.2.- Lag collide.

3.3.- Nuke.

3.3.1.- ICMP nuke.
3.3.2.- OOB nuke.

3.4.- Ping.

3.4.1.- Ping of death.

3.5.- Ssping.
3.6.- Teardrop.
3.7.- Land.
3.8.- Teardrop modificado.
3.9.- Smurf.
3.10.- Bonk (/Boink).
3.11.- Syndrop.
3.12.- Overdrop.
3.13.- Nestea (/Nestea2).
3.14.- Trojans.

3.14.1.- Mirc.ini.
3.14.2.- Dmsetup.exe.
3.14.3.- Back Orifice.
3.14.4.- NetBus.

3.15.- Hanson.
3.16.- Modem DoS.

3.16.1.- /Msg ComX.
3.16.2.- +++ATH0.

3.17.- Fragmento de longitud 0 - Linux DoS.
3.18.- Paquetes ICMP aleatorios - Linux DoS.
3.19.- ICMP/Redirect-host DoS.
3.20.- Paquetes fragmentados IGMP en Windows.
3.21.- Paquetes fragmentados ICMP-type 13 en Windows.
4.- Spoofing.
5.- Técnicas avanzadas.

5.1.- Bouncing.
5.2.- Wingate.
5.3.- DNS Inject.
5.4.- Recursos compartidos.

6.- Defensa.

6.1.- Firewall.

7.- Resources.
8.- Feedback (FAQ).
9.- Agradecimientos.
10.- Modificaciones.
11.- Notas finales.

1.- Introducción.

Ultimamente la guerra en el IRC es, por desgracia, algo bastante común. Conviene, a lo menos, estar
informado de las distintas técnicas que se suelen usar para "luchar", aunque sea simplemente para
detectar que te están atacando, saber cómo lo están haciendo e intentar defendernos. No es mi
intención profundizar demasiado en el tema aunque intentaré detallar algunos puntos que considere
convenientes.

Todo lo que aquí se hable es extensible en general a cualquier red IRC. No obstante en algunos
casos muy particulares me referiré a la red IRC hispana ("*.irc-hispano.org"). Ni que decir tiene que
la información que se proporciona aquí es con fines educativos; en ningún caso debe ser usada salvo
en circunstancias excepcionalmente justificadas. Un uso abusivo puede significar una k/g-line
totalmente merecida. Yo no me hago responsable de un posible mal uso de esta info.

[Indice]

2.- Principios.

Muchas veces el objetivo de un ataque no es otra cosa que hacerse con un canal ("tomarlo"). Esto es
relativamente fácil y hay diversas técnicas para ello. El objetivo es hacerse con el op en el canal. Los
medios: tu inteligencia y astucia... ;-)


2.1.- Cómo funciona una red IRC.-

El servidor de IRC propiamente dicho no es más que un programa corriendo en background (un
daemon) en una máquina determinada (en Unix correría el "ircd"). Los usuarios se conectan a dicha
máquina y acceden al servidor en forma de clientes.

Una red IRC se compone de varios servidores corriendo en paralelo y enlazados entre ellos, de
forma que se mantegan comunicados (puedan intercambiar mensajes entre ellos). Cuando un usuario
se conecta a un servidor determinado, éste (el servidor) lo notifica a los demás servidores que forman
parte de la red IRC. Igualmente, cualquier otra acción es notificada a todos los servidores, de forma
que éstos actuan como una unidad. De esta forma el usuario se deja ver en todos los servidores
aunque físicamente sólo esté conectado a uno. Esto permite tener muchos usuarios repartidos por
diferentes servidores pero que virtualmente es como si estuvieran todos en uno sólo.

La estructura de la red IRC es en forma de árbol (es decir, no puede haber bucles, o "caminos
cerrados": partiendo de un nodo no se llegue por ningún camino otra vez a dicho nodo) aunque un
tanto especial: cada nodo se ve a sí mismo como el nodo raiz de la red y tiene un grafo en forma de
árbol que le indica el camino a seguir para alcanzar cada uno de los restantes nodos. En la
"literatura" esto se conoce como "spanning tree", que podríamos traducir como "árbol de
expansión". Esto quiere decir que en un momento determinado un nodo cualquiera tendrá
almacenada información para alcanzar cada uno de los otros nodos de forma unívoca (tiene un único
camino posible hacia cada nodo). Esa información sería el árbol que está usando el nodo en cuestión.
Pero además este árbol puede ser distinto para el mismo nodo en un instante diferente, es decir,
puede cambiar (digamos que el nodo va reconfigurándose). Esto tiene la ventaja de que permite
adaptarse a posibles variaciones (eventuales) de la topología de la red (así, si un nodo cae, los
restantes nodos lo detectarán y se reconfigurarán de forma que los caminos que antes pasaban por
dicho nodo dejen de hacerlo: se tomarían caminos alternativos con lo cual la red seguiría
funcionando correctamente a pesar de la caida del nodo). Un ejemplo de topología de red podría ser:

[ Server 15 ] [ Server 13 ] [ Server 14]

/

\

/

/
[ Server 11 ] ------ [ Server 1 ] [ Server 12]

/

\

/

/

\

\

/

/

[ Server 2 ] [ Server 3 ]
\

/

\

/

\

\

[ Server 4 ] [ Server 5 ] [ Server 6 ]
/

\

/

|
|

/

\

/

/

/

|
|

\____ /

\

/

[ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]

:

[ etc. ]

:

El paso de un nodo a otro adyacente se conoce como "hop" (salto). Así para alcanzar el nodo 5
partiendo de 4 tendremos que dar 2 saltos (hops): uno de 4 a 2 y otro de 2 a 5.

Podemos visualizar el árbol que está usando el server al que estamos conectados usando el comando
"/links". Este sacará un listado por pantalla de los servidores alcanzables desde el nuestro, de forma
jerarquizada, es decir, respetando la estructura del árbol. Normalmente se indica entre paréntesis al
lado de cada servidor el número de hops que habría que dar para alcanzar cada uno de los nodos
partiendo del nuestro.

Cuando se rompe uno de los eslabones (links) que unen 2 servidores el conjunto se divide en 2
subconjuntos, los cuales intentarán seguir funcionando normalmente aunque de forma aislada. Esto
es, cada subconjunto permanece operativo y mantiene la comunicación entre los servers
pertenecientes a dicho subconjunto. Pero por razones obvias los servidores de un subconjunto no ven
a los del otro y viceversa. Esta situación se conoce como net-split.

En una sesión normal de IRC esto lo veríamos:

[1:23] *** Case_Zer0 has quit IRC (fuego.irc-hispano.org io.irc-hispano.org)

Esto indica que se han spliteado los dos servidores indicados entre paréntesis y que a consecuencia
de ello el usuario Case_Zer0 [ hi Case ;-) ] ha salido "de nuestra red IRC" (lo que está ocurriendo es
que se encuentra en el otro subconjunto de servidores: a todos los efectos es que como si se
encontrase ya en otra red IRC).

Cuando el enlace caido se recupera (i.e. se reestablece la comunicación entre los servers spliteados)
se habla de net-merge. Esto se vería en la sesión anterior como un "join" por parte del usuario que
estaba en el servidor spliteado (tanto el quit como el join anteriores son mecanismos del propio IRC,
es decir, el usuario anterior no dio ninguna orden de quit ni de join, es transparente a dicho usuario).

Hay programas que detectan y avisan cuando se produce algún net-split o net-merge: son los
denominados "link-lookers", y su utilidad es bastante obvia.

Por ejemplo, si el enlace dibujado en rojo (enlace server 2 <-> server 5) cayera, el servidor 5 estaría
aislado de la red. Los usuarios de dicho servidor dejarían de ver a todos los demás pertenecientes a
servidores distintos, y al contrario. Se dice que el servidor 5 está spliteado. Es fácil reconocer a un
servidor en esta situación: si entras en una red a través de un determinado servidor y te encuentras a
muy poca gente es muy normal que se deba a que está spliteado de la red.

Otra posibilidad es que el enlace azul (3 <-> 12) cayera. En este caso el servidor 12 se splitea de la
red, pero también lo hacen los servidores 13 y 14 indirectamente, por conectarse a través del
primero.

Para una información completa del funcionamiento y estructura de una red IRC, y del protocolo
subyacente ("Internet Relay Chat Protocol") os remito al RFC1459.

[Indice]

2.2.- Conseguir op sin que nadie te lo de.-

Cuando alguien se une a un canal donde no hay nadie (hace un /join #canal) el servidor supone que
se trata de un nuevo canal y le da op a dicho usuario. Se dice que ha creado un canal. Vamos a
aprovechar esto para hacernos con el op en un canal ya existente. ¿Cómo? Fácil: solo hay que
aprovechar un net-split. Los pasos serían los siguientes:

- Esperar un split (lo podemos detectar con un link-looker).
- Entrar (conectar) al servidor spliteado.
- /join #canal (donde canal es el canal donde queremos conseguir op).
- El server creará un nuevo canal y tendrás el op.
- Esperar a que se deshaga el split.

Si "hay suerte" (leer más abajo), al deshacerse el split conservaremos el op en los restantes
servidores (el servidor spliteado se encarga de dar las órdenes correspondientes). Entonces se dice
que hemos llevado a cabo un "net-hack". Los usuarios presentes en el canal en el que hemos
  • Links de descarga
http://lwp-l.com/pdf7524

Comentarios de: Tácticas de guerra en el IRC (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios
Es necesario revisar y aceptar las políticas de privacidad