Como detectar broadcast
Pedro GM
saxeusgm en gmail.com
Sab Mar 21 19:35:14 CLT 2009
El sáb, 21-03-2009 a las 17:42 -0400, Sebastián Veloso Varas escribió:
> Pedro GM escribió:
> > El sáb, 21-03-2009 a las 10:04 -0600, Vida Luz Arista escribió:
> >
> >> Hola a todos,
> >>
> >>
> >>
> >> Actualmente tengo un enlace 12 MBps, este entra a un cisco 3550, tenemos un
> >> problema porque distribuimos el tráfico hacia varias recintos de una
> >> universidad, sin embargo en determinado momento se dispara el trafico
> >> entrante y se vuelve lento todo, configuramos uno de los puertos del switch
> >> como monitor port, y redirigimos el tráfico hacia un Linux con NTOP, en le
> >> summary del NTOP sale un broadcast con el 29%, el problema es que en el NTOP
> >> no hemos encontrado la manera de saber que IP generan ese broadcast, asi
> >> mismo el NTOP consume mucha memoria y a cada momento se detiene.
> >>
> >>
> >>
> >> Agradecería cualquier sugerencia.
> >>
> >>
> >>
> >> Saludos,
> >>
> >> “La Vida”
> >>
> >>
> > Ntop tiene una opcion "-l" con esta lo que va capturando se guarda en
> > un archivo con el formato .pcap, entonces lo puedes analizar
> > posteriormente con algun analizador de protocolos compatible con libpcap
> > como tcpdump o wireshark (este ulimo tiene interfaz grafica).
> >
> >
> Sip, pero es mucho más detallista Wireshark para sus cosas.
Cierto estoy de acuerdo con esa afirmacion, pero ella esta usando Ntop
por un tema de estadisticas y graficas del trafico, puede usar
ambos(ntop para las graficas y wireshark para analisis) ya que wireshark
es muy util para analizar en profundidad.
> > De esta forma puedes analizar mas en calma los datos de la encapsulacion
> > de los paquetes de broadcast para poder llegar a observar una ip de
> > origen o una mac de origen (que te podria llevar al switch que esta
> > propagando el broadcast, observando con los comandos show del 3550 a que
> > puerto esta asociado esa mac de origen). también notaras si hay algun
> > servicio de aplicación involucrado en esto y te pueda dar mas pistas.
> >
> >
> Estoy seguro que el problema es un equipo generando trafico en la red
> con algún virus/troyano (que podría ocasionar ataques DoS, spoofing ARP
> entre otros) o sino ya un loop de red ... algo que debiese ser
> controlado por switching. Yo he tenido varios dolores de cabeza por
> estas causas. La idea es hacer un levantamiento desde lo fisico hasta la
> aplicacion, distinguir las capas de acceso, distribuicion y core en tu
> red (si es que las posees claramente identificadas) para solucionar tu
> problema.
En mi experiencia es lo mas probable, hace poco tube un caso similar en
mi trabajo y eran unas estaciones(infectadas) que inundaban con trafico
a toda la lan y se generaban muchas solicitudes arp, una vez localizadas
las estaciones un simple netstat mostro muuuuchos sockets abiertos.
Por otro lado si fuese una tormenta de broadcast entre switches, el
spanning-tree del 3550 lo habria detenido ya.
> > Eso es lo que se me ocurre a primera instancia para ayudar a detectar el
> > origen del broadcast.
> >
> > La solución del storm control es buena pero es muy util que encuentres
> > desde donde vienen esos broadcast.
> >
> >
> Claramente esta es una solución del tipo "aspirina para el dolor de
> cabeza" .... .Son utiles para entender la naturaleza y solucion de la
> problemática y calmar el momento.
> > suerte.
> >
> >
--
::Pedro::GM::
User #397462
http://counter.li.org
Más información sobre la lista de distribución Linux