Ataque DoS a una Red

Imagen de damage

Tema: 

Hola amigasos, le cuento algo que me paso el día de ayer por la tarde, resulta que yo le doy servicio de administración remota a un pequeño WISP que se encuentra en otra provincia, bueno el asunto que paso es que ayer, el propietario de dichi ISP me llama y me comentaba que la red se habia puesto extremadamente lenta y que ninguno de sus clientes podia navegar en internet, cosa que me llamo la atención, al principio pense que era cuetion de ancho de banda, que quizas ejecutaron una regla que le hizo un flush al mangle y se paro la segmentación, etc, bueno, entre al server via SSH, y revice lo mencionado y todo normal, en realidad no le tome importancia al asunto por que los tecnicos de alla ya habian hecho algunas cagadas y me tenian las que sabemos cuadradas y queria que pasen apuros, despues de unos minutos me vuelven a llamar y me cuenta de que en casi todos los clientes conectados les salia en la pantalla de los Window$ que tenian IP duplicada, le conteste que eso era problema de que no estaba llavando el control IP-MAC con el ip neigh, pero me contesto que si lo estaba haciendo, lo cual ya me comenso a preocupar, entre de nuevo al server y el me envia a mi mail una impresion de la pantalla de una PC cliente y lo que me sorprendio, es que el mensaje que salia no era el tipico cuadrito amarillo en el lado inferior derecho del windows, si no un pantalla completa de color blanco que decia que la IP estaba duplicada, ahi me preocupe en realidad y me propuse a hacer un scaneo de la red a ver que pasaba.

Primero hice fue ver con iptraf el consumo de la red interna, y para mi sorpresa, veia que la mac FFFFFFFFFF tenia un consumo de 500k como minimo, mire a la eth0 conectada hacia el Internet y no presentaba esa anomalia, lo cual me preocupo y a la ves en algo me tranquiliso porque sabia que no era un ataque externo, pero no habia casi ninguna conexion hacia Internet, procedi luego a revisar con tcpdump y para mi sorpresa el 90% de los paquetes eran generados por una IP que no correspondia a las subredes de la LAN por ejemplo la una subred es 172.100.1.1/24 uso siempre en esta red la clase 172.100.1.x/xx y la ip era 192.168.0.2, lo cual me resulto rarisimo, segui viendo lo que tcpdump me mostraba y todos los paquetes eran dirijidos al los puertos 135:139 y al broadcast de la red y de las subredes, luego de el horror que vei procedi a ver que MAC tenia esa ip, lo hice con arping hacia la ip mencionada y me arrojo una MAC "X", la cual pertenecia al equipo wireless de un cliente de este ISP, procedieron a desconectar el equipo y todo se calmo, esa fue la solución más radical y la menos técnica en ese momento, pero mi duda es...

Que paso, eso definitivamente es un ataque DoS o es un Troyano en la red?, como evitar que pase otra vez?. en mi firewall tengo habilitado algunos modulos para evitar esto como:

/sbin/depmod -a
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc
modprobe ipt_REJECT
modprobe ipt_TOS
modprobe ipt_MASQUERADE
modprobe ipt_LOG
modprobe iptable_mangle
modprobe iptable_nat
modprobe ip_nat_ftp
modprobe ip_nat_irc

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 1280 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/conf/default/log_martians

Además de denegar conexiones de INPUT y FORWARD a y desde los puertos 137:139. Aunque al ser un WISP y como un radio en el cual el ataque tenia conexión no tiene firewall, no me servia de nada denegar en el linux los puertos. De ley se va a poner un radio con Linux como firmware y denegar conexiones de ese tipo a nivel de AP.

Pero que más úedo hacer?, como saber en realidad qeu paso y como lo hicieron si fue un ataque real?.

Saludos y gracias por apoyar.

Comentarios

Ya me ha pasado antes, y en

Imagen de Monkito

Ya me ha pasado antes, y en efecto es un troyano, no recuerdo su nombre, al principio me parecía interferencia, pero cuando revisé en AP la cantidad de paquetes de los clientes vi que uno generaba mucho tráfico, le puse un minirouter e impedí su acceso hacia otros equipos de la red de clientes, sólo hacia el servidor, además de ignorar tráfico de broadcast en el server, esa fue la solución.

También solía pasar que los clientes intercambiaban información entre ellos y saturaban el enlace inalámbrico, eso se soluciona con un switch de capa 3 y subneteos en redes /30 para cada cliente

Por otro lado me inquieta el hecho de que tengas una red privada 172.100.x.x ya que el rango privado de clase B es 172.16.0.0/12 es decir desde 172.16.0.0. hasta 172.31.255.255 fuera de eso son públicas, no has experimentado algún tipo de problema de rutas?, es posible que causes conflicto con esas redes para tus clientes.

------------
counter.li.org

Cogito Ergo Sum

------------
counter.li.org

Cogito Ergo Sum

Hola pana gracias por

Imagen de damage

Hola pana gracias por compartir y comentar tu experiencia, te cuento algo que de donde provenia el problema era de un router (de esos domesticos con wireless), eso me lo confirmarón hoy, no era de un PC, lo cual se me hace aun más extraño por lo cual no se, si en realidad sea un troyano o fue en realidad un ataque planificado y deliberado, este router lo tenian si protección en la parte Wireless, sin encriptación y dhcp osea tremendo hueco de seguridad, yo creo que alguien debio descubrir esa brecha de seguridad e hizo de las suyas, pero solo es una idea no lo podre comprobar en realidad.

Por lo que comentas de la red 172.x.x.x, no he tenido problemas de enrutamiento, tengo esa red que es 172.100.1.1/24 y varias subredes 192.168.1.x/30, etc. pero nunca me ha pasado nada de lo que me comentas.

Lo del switch capa 3 es interesante si lo habia pensando, cuantame que hiciste en el switch para tener la pelicula 100% clara y aplicarlo.

Saludos.

Keep The Fire Burning.....
Stryper 1988

Por lo general esos equipos

Imagen de Monkito

Por lo general esos equipos trabajan el clase C, es decir ponen al DHCP a trabajar en una red 192.168.1.0/24 es probable que alguien haya entrado y haya querido robar información de los demás equipos en la red, pero con eso no pueden llegar con esa ip hasta tu servidor, también es poco probable que hayas tenido un virus en la red interna del router ya que para atacar saldrían a través del NAT.

Eso me huele a que desconectaron tu router y le pusieron a una pc para ver si navegaban más rápido y puede que hayan saturado la red inalámbrica copiando archivos desde otro cliente.

------------
counter.li.org

Cogito Ergo Sum

------------
counter.li.org

Cogito Ergo Sum

Te cuento que ya descubri

Imagen de damage

Te cuento que ya descubri que pasaba en todo este relajo, el router estaba falloso, procedi a indicarles (via celular jeje) que cambiaran el router y que conecten todas las PC normalment, y no paso nada todo normal, luego les indique que volvieran a poner el router sospechoso y oh sorpresa :O volvio a dar el problema, como estaba monitoreando ese momento, capture lo que tcpdump me devolvia, me olvide que tengo la captura en la PC de la oficina, mañana la posteo para que vean lo que pasaba.
Al fin de cuentas dejaron el Router "nuevo" y todo quedo trabajando bien.
Lo real es que el Lado WAN del Router estaba generando DHCP, enviando cientos de paquetes al broadcast y saturaba la red.
Igual ya les indique a los "tecnicos" y al Dueño del ISP que deben tener mayor control con lo que hacen, han decuidado la red de manera abismal, lamentablemente estan lejos de donde yo resido y remotamente puedo monitorear casi todo, lo unico que no puedo ver es las cagadas que hacen cuando conectan a un cliente nuevo o cuando instalan un nuevo radio base y lo dejan abierto a "Raimundo y todo el mundo", pero bueno son cosas del oficio y los que pierden son ellos porque deben pagar màs por soporte y por arreglarles las cagadas que hacen.

Saludos y buenas noches, voy a ver que màs pasa en la asamblea jeje.

Keep The Fire Burning.....
Stryper 1988

Bueno te dire que hace 4

Bueno te dire que hace 4 dias me comenzo a pasar esacatamente el mismo problema que describiste inicialmente....me llaman y me comentaba que la red se habia puesto extremadamente lenta, rapidamente entro al netreporter que tengo montado para monitorial la red y me daba un trafico super extraño

172.24.72.190 172.24.72.255 netbios-ns 137 UDP Default 364.49 MB
[Show Graph] 0.0.0.0 255.255.255.255 bootps 67 UDP Default 161.02 MB
[Show Graph] 172.24.72.190 172.24.72.255 netbios-dgm 138 UDP Default 107.72 MB
[Show Graph] 172.24.72.216 172.24.72.255 netbios-ns 137 UDP Default 67.74 MB
[Show Graph] 172.24.72.16 172.24.72.255 netbios-ns 137 UDP Default 47.12 MB
[Show Graph] 169.254.168.120 169.254.255.255 netbios-ns 137 UDP Default 41.46 MB
[Show Graph] 169.254.135.128 169.254.255.255 netbios-ns 137 UDP Default 27.75 MB
[Show Graph] 172.24.72.194 255.255.255.255 bootps 67 UDP Default 26.52 MB
[Show Graph] 169.254.33.177 169.254.255.255 netbios-ns 137 UDP Default 23.9 MB
[Show Graph] 172.24.72.195 172.24.72.255 netbios-ns 137 UDP Default 21.7 MB
[Show Graph] 172.24.72.188 255.255.255.255 bootps 67 UDP Default 21.33 MB
[Show Graph] 172.24.72.176 172.24.72.255 netbios-dgm 138 UDP Default 19.52 MB

Entre en google y di con este forun donde encontre tu problema y la solucion que le diste.
El router mio esta en un nodo centrar por lo que a el conectan por diferentes vias (RAS,Inalambrico y FR), analice por donde era que venia el trafico y vi era por la interface Ethernet 1 que era la que se comunicaba con la red de donde venia el trafico.
Nada para no darle mas de largo a la solucion que tome.
1ro Desconecte la interface mientra monitoreaba el trafico para estar seguro que era ese el problema, y verdaderamente disminuyo el trafico.
2do Fuy al swich donde estan las pcs de esa red y comence a desconectarlas para ver donde estaba el conflicto.
Bueno finalmente la cosa era que en una de las officinas me habia hecho un puente de un puerto a otro puertos.

uff de la que te salvaste si

Imagen de rickygm

uff de la que te salvaste si hubiera sido un ataque DDOS , hubieras pasado unos 3 dias , y sin hacer nada , pero lo bueno fue que era el router y asegúrate en si que haya sido el y no una pc , puedes ver el trafico inalambrico con wireshark

saludossss

Si en verdad por suerte no

Imagen de damage

Si en verdad por suerte no fue un ataque DoS, uff, lo que si es seguro es que el router era el culpable, les envio como quede, la captura de tcpdump:

14:19:46.073243 IP u23.eset.com.http > 172.100.3.8.1066: . 565502724:565504116(1392) ack 1996484548 win 6432
14:19:46.088342 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.090649 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.090671 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.092612 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.092632 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.093500 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.094346 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.094996 arp who-has 192.168.100.100 tell 192.168.100.49
14:19:46.096226 arp who-has 192.168.100.100 tell 192.168.100.25
14:19:46.096266 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.097588 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548
14:19:46.097603 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.101598 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548
14:19:46.101613 IP 192.168.0.3.netbios-dgm > 192.168.255.255.netbios-dgm: NBT UDP PACKET(138)
14:19:46.102322 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548
14:19:46.103150 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548
14:19:46.105572 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548
14:19:46.105623 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548
14:19:46.106309 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548
14:19:46.107153 arp who-has 192.168.100.100 tell 192.168.100.49

Pilas que esto corresponde a una fracción de segundo :O , un segundo completo es 10 veces mas paquetes :jawdrop: (aproximadamente).
Como podrán ver se nota las peticiones DHCP, los paquetes enviados al broadcast y par paquetes correspondientes a la red.

Saludos panas.

Keep The Fire Burning.....
Stryper 1988

Ese maldito aparato ni

Imagen de damage

Ese maldito aparato ni siquiera se puede entrar a configuraciòn, tampoco se lo puede resetar, esta totalmente poseido.
Keep The Fire Burning.....
Stryper 1988

re:Ese maldito aparato ni

Imagen de isacnet

Me da la impresion que si fue Hackeado tu wireless router, en eso te recomiendo apliques las mejores procticas con dispositivos Wireless, primero jamas dejar con el password que viene por defecto el router, segundo utilizar un radius server para autentificacion, tercero siempre hacer redes diferenciadas y accesos via vpn en el segmento Wireless, y cuarto usar lo menos posible routers wireless :) .

http://www.pcworld.com/article/id,135386-c,wireless/article.html

Saludos

_______________________________________
Trend Micro el mejor antivirus del mundo 40% del mercado mundial de gateway
240 millones de usuarios no pueden equivocarse
http://www.trendmicro.com.ec
Mercadeo@trendmicro.com.ec

_______________________________________
ISACNET S.A.
Ecuador: +593-2-3238590
Perú: +51-1-4223796

HP y Trend Micro, lo mejor de 2 mundos en un solo Socio de Negocios
http://www.isacnet.com.pe

Páginas