viernes, 25 de diciembre de 2015

El misterio del canal 14 del WIFI

6:26 p.m. Posted by LanreB OgeiD , , 3 comments



Screen Shot 2014-01-06 at 16.50.26
Es una de las cosas más molestas relacionadas con la tecnología; despertar en la mañana para encontrar que tu conexión a Internet está funcionando dolorosamente lenta o no funciona en absoluto. Iniciar sesión en la cuenta que tienes con el proveedor de servicios (En el Router) puede ayudar a resolver el problema, se pueden ver todas las conexiones de área local y los canales que operan y elegir una de las opciones menos favorecidas.

Se te presentará con la posibilidad de elegir uno de los canales disponibles, 13 si vives en el Reino Unido o en Asia (excepto Japón y Taiwán). 11 canales están disponibles en América y Taiwán, pero Japón permite a la gente a usar el canal decimocuarto.


Screen Shot 2014-01-06 at 14.43.24 

El canal 14 opera en el extremo más alto del espectro de frecuencias Wi-Fi desde 2.472 GHz en adelante y sólo es compatible con equipos diseñados para trabajar con routers 802.11b, aunque en gran medida se han eliminado.

Todavía es posible acceder al canal Wi-Fi decimocuarto, a pesar de que sólo se puede hacer mediante la modificación del router y es cambiando la configuración del país a Japón. Incluso entonces no es siempre posible.

La Comisión Federal de Comunicaciones o FCC, en realidad ha prohibido el acceso al canal 14. La organización afirma en una presentación de 2005: "Independientemente de los niveles, un dispositivo no puede operar en una banda restringida". La presentación pasa luego a dictar "Operar en el canal 14 no está permitido."


¿Por qué se prohibió?

EL canal con una frecuencia central de 2.48GHz, es conocido como The Industrial Scientific and Medical, o ISM, el canal puede ser elegido en todo el mundo. El dispositivo más común que opera en la frecuencia es el horno de microondas, que supuestamente trabaja en 2.45GHz.
the Industrial Scientific and Medical


Screen Shot 2014-01-06 at 16.03.39 

No se sabe si la señal recibida del canal 14 afecta al microondas o viceversa. Partimos de que las fuertes restricciones en el uso de la gama son el resultado de su uso por los satélites militares y de comunicaciones para transmitir señales en todo el mundo. 

El uso del canal 14, o cualquiera de los otros canales para el caso, podría causar alguna interferencia con el equipo de rango moderado de vigilancia, control de tráfico aéreo, los satélites meteorológicos y el radar marino. El impacto no será devastador, ya que la intensidad de la señal no sería tan grande como para hacer ningún daño grave. De hecho, la mayor parte de la banda de frecuencia 'S' está fuera del alcance de los ordenadores portátiles.Sin embargo, con algunas modificaciones y mejoras en el rendimiento es muy posible poder ajustar las frecuencias disponibles para los routers inalámbricos y portátiles así que se puede acceder a las frecuencias más amplias. De hecho, con un poco de programación  y mejoras, el canal "X" no está fuera de su alcance. 

El canal "X", llamado así debido a su carácter secreto durante la 2da Guerra Mundial es utilizado por los sistemas de misiles de orientación, radar marino y el radar del aeropuerto, así como el seguimiento de corto alcance y de vigilancia terrestre. 

Aunque el canal se prohibió, las consecuencias del uso del canal restringido no se especifican. Se considera un delito grave debido a su ilegalidad, aunque parece poco probable que la FCC vendrá a llamar a tu puerta. 

Fabricantes como Apple han bloqueado a las personas poder acceder al canal ilegal limitando la tarjeta AirPort de las computadoras para el país de venta. Sólo cambiando la tarjeta AirPort o la estación base pueden los usuarios de de Apple acceder al canal.

Fuente: http://kernelmag.dailydot.com/
the Industrial Scientific and Medical




Es una de las cosas más molestas relacionadas con la tecnología; despertar en la mañana para encontrar su conexión a Internet está funcionando dolorosamente lento o no funciona en absoluto. Inicio de sesión en la cuenta que tiene con el proveedor de servicios puede ayudar a resolver el problema, se puede ver en todas las redes en su área local y los canales que operan en y elija una de las opciones menos favorecidas.

Se le presentará con la posibilidad de elegir uno de los canales disponibles, 13 si usted vive en el Reino Unido o en Asia (excepto Japón y Taiwán). 11 canales están disponibles en las Américas y Taiwán, pero Japón permite a la gente a usar el canal decimocuarto.


The mystery of WiFi channel 14
The mystery of WiFi channel 14Screen Shot 2014-01-06 at 16.50.26

jueves, 17 de diciembre de 2015

¡Hablemos de Honeypots!

4:27 p.m. Posted by LanreB OgeiD No comments

Concepto

Un honeypot es un recurso que simula ser un objetivo real, el cual se espera que sea atacado o comprometido en otras palabras es un "equipo trampa". Los principales objetivos son el atraer y distraer a los atacantes y obtener información sobre el ataque y el atacante.
Es una herramienta de seguridad informática cuyo valor se basa en ser escaneado, atacado y comprometido.

http://www.hackersenigma.com/wp-content/uploads/images/Honeypot-Detection-.jpg

Ventajas

  • No hay tráfico "normal",toda la actividad es sospechosa y petencialmente maliciosos
        - No hay falsas alarmas.
        - Menos datos a analizar comparado con los IDS (Sistema de detección de intrusos, por sus siglas en inglés, que después veremos en una nueva entrada).
  • Puede brindar información valiosa sobre los atacantes.
       - Nuevos tipos de malware
       - Herramientas de hacking utilizadas
       - Métodos usados por los atacantes
  • Detener o entretener al atacante con sistemas en los que no puede causar daño.

Desventajas

  • Hay riesgos potenciales sobre la red de datos y los sitemas de producción de la organización (dependiendo del tipo de honeypot usado).
  • El mantenimiento puede consumir mucho tiempo.
  • "narrow view" (Estrecha visión).
  • No es un mecanismo de defensa...

Usos

Investigación:

  • Detectar nuevo tipos de ataques y herramientas de hacking.
  • Obtener mayor conocimiento de los ataques (objetivos, actividades, etc.) y tendencias.
  • Desarrollar nuevas signatures de IDS's.

Producción:

  • Distraer al atacante del objetico real (ganar tiempo para proteger el ambiente de producción).
  • Recolectar suficiente evidencia contra un ataque.

Tipos

Nivel bajo de interacción:

  • Típicamente sólo proveen servicios falsos o emulados.
  • No hay un sistema operativo sobre el cual el atacante pueda interactuar.
  • Fáciles de instalar y mantener.
  • La información obtenida es muy limitada.
  • Minimizan el riesgo considerablemente.

Nivel medio de interacción:

  • Brinda mayor interacción pero sin llegar a proveer un sistema operativo sobre el cual interactuar.
  • Los demonios que emular los servicios son mas sofisticados y brinda mayores posibilidades de interactuar y escanear el sistema.
  • El desarrollo/implementación es más complejo y consume más tiempo.

Nivel alto de interacción:

  • Cuentan con un sistema operativo real.
  • Presentan un mayor nivel de riesgo y complejidad.
  • Son objetivos más "atractivos" a ser atacados.
  • Se obtiene mayor y mejor información de los atacantes.
  • Requiere de mucho tiempo para instalar y mantener.
https://baulderasec.files.wordpress.com/2013/11/sholcroft-4-2002-1.gif

Riesgos

  • Compromisos de seguridad del Sistema Operativo sobre el cual se ejecuta el honeypot.
  • Vulnerabilidades del software que implementa el honeypot.
  • Atrae intrusos/atacantes a la red de servicios o de producción asociada al honeypot (si es detectado).
  • A mayor nivel de interacción mayor riesgo.
  • Errores en los mecanismo de contención o en la configuración pueden:
        – La honeynet ser usada para atacar otras redes.
        – Abrir un puerto a la red de la organización.
  • Un incidente de seguridad asociada a la organización puede afectar la imagen de la misma.
  • Que la honeynet sea identificada. 





Fuente: http://www.fing.edu.uy/

miércoles, 16 de diciembre de 2015

DDoS Análisis de Ataques Distribuidos

4:50 p.m. Posted by LanreB OgeiD , No comments

Entendiendo DDoS

Es muy probable que ud ya conozca el Ataque de Denegación de Servicio Distribuido (DDoS) el cual es una extensión del ya conocido DoS (Denial of Service) que sucede cuando el servidor objetivo se ve saturado de peticiones TCP o UDP a determinado servicio (por lo general, servicio web al puerto 80, pero esto depende de las intenciones del atacante, cualquier servicio puede ser vulnerable) dejando de responder incluso a peticiones genuinas.
El concepto de “Distribuido” es concerniente a que estas peticiones son realizadas desde cientos, miles de máquinas infectadas (comúnmente llamadas “zombies” ) las cuales son gobernadas a través de “Botnets” (http://en.wikipedia.org/wiki/Botnet) de manera coordinada al mismo tiempo, lo cual supone una sumatoria de ancho de banda, uso de memoria y procesamiento en el objetivo que, por lo general, ningún servidor podría soportar, terminando en un colapso del servicio atacado por no poder responder cada petición.
En este articulo haremos foco en dos tipos de ataques, los mismos son “SYN flood” y “Slow HTTP DDoS Attack”.
La clave del éxito para los ataques de DDoS es la cantidad de “zombies” con que cuenta cada Botnet. Podemos afirmar que mayor es el número de máquinas atacantes, mayor es la efectividad del ataque.
A modo de ejemplo, hagamos el siguiente cálculo rápido:
Una “botnet” tiene 3000 máquinas zombies listas para atacar. Cada máquina utiliza una conexión hogareña (generalmente xDSL) con un promedio de 128 Kib/s de ancho de banda de subida (upstream):

3000 hosts * 128 KiB/s (upstream) = 384000 KiB/s = 375,00 MiB/s

Es decir, se genera un tráfico resultante de 375,00 MiB/s, el cual es un ancho de banda mas que suficiente para colapsar prácticamente cualquier sistema (aún estando protegido) ya que
los vínculos que los ISP le otorgan a los servidores target son claramente inferiores a este valor.
Pero este no es el único factor que influye en el éxito de un ataque DDoS, también podemos mencionar la variante de ataque que se realizará (descriptos anteriormente), la buena o mala configuración de los servidores target, la duración del ataque, etc…

SYN Flood Attack

Este es uno de los dos tipos de ataques de DDoS que analizaremos en este artículo.
Como lector de este Magazine, usted probablemente sepa que los headers de un paquete TCP/IP contiene banderas (flags), las cuales tienen diferentes funciones, como por ejemplo marcar inicio, prioridad y fin de la conexión, reiniciarla, etc y que el “diálogo” entre las partes se inicia con el “saludo de las tres vías”. En este último punto está la clave de esta técnica.
Pues bien, el ataque de “SYN Flood” consiste en enviarle paquetes manipulados a la maquina target, activando el bit SYN (S flag) en la conexión TCP y alterando la IP origen (mediante técnica de spoofing), la víctima responde con un SYN/ACK (SA flags) considerando que se trata de una conexión legítima y espera por un ACK (A flag) por parte del cliente. Al tratarse de direcciones falsas, la respuesta nunca llegará y la secuencia no llega a completarse ocasionando que la víctima se sature de conexiones no dejando lugar a conexiones genuinas.
En el siguiente gráfico, se aprecia una secuencia normal del “saludo de las tres vías”

En tanto que, modificando los headers, la conexión se realizará del siguiente modo:

Este es sin dudas uno de los ataques mas conocidos por su simplicidad-efectividad y famoso dado que es la técnica principal utilizada por el ya mundialmente conocido grupo hacktivista “Anonymous” que si bien ellos mismos lo emplean como herramienta de “protesta”, está quedando en evidencia que esto no siempre se aplica para el común de los ciberdelincuentes que, en su mayoría, lo emplean como herramienta de extorsión en perjuicio de empresas o gobiernos y en otras ocasiones para obtener ganancias económicas.
Existe gran cantidad de herramientas para efectuar un SYN Flood Attack, entre ellos las armas principales de “Anonymous”, llamadas LOIC (Low Orbit Ion Cannon) y HOIC (High Orbit Ion Cannon). Estas herramientas pueden ser manejadas por el usuario o bien utilizando el modo “Hivemind”, a través de un canal de IRC en un ataque distribuido y coordinado. Son herramientas muy potentes y deben ser utilizadas responsablemente.
Pero en este artículo utilizaré otra herramienta que no tiene el ataque como propósito de uso, estoy hablando de HPING3, que es una grandiosa herramienta de pruebas a reglas de firewall, stress testing, manipulación de paquetes, entre otras utilidades, muy necesaria para todo sysadmin y profesional de la seguridad informática.

¿Cómo este ataque puede ser demostrado?

A los efectos ilustrativos de complementar este artículo y teniendo en cuenta la complejidad de contar con una botnet real, he montado un escenario en mi laboratorio interno en el cual emplearé tres maquinas que simularán ser muchas mas para atacar un servidor vulnerable y desprotegido (corriendo Fedora release 15 (Lovelock)).
La idea es inundar de paquetes manipulados (utilizando el flag SYN) a la víctima, simulando un ataque desde cientos de hosts diferentes.
El escenario podría ser graficado del siguiente modo:
Como ya dijimos, HPING3 es una excelente herramienta con la posibilidad de utilizarla en muchas situaciones, recomiendo ejecutar la ayuda (hping3 -h) para ver las diversas opciones.
Para el caso de esta demostración, desde cada una de las máquinas atacantes, ejecutamos HPING con los siguientes parámetros:

Parámetro
Función
-S seteamos el flag SYN
–flood Enviamos paquetes lo mas rápido posible. No se muestran respuestas.
–rand-source Simulamos diferentes orígenes aleatoriamente al enviar los paquetes.
-d Establecemos el tamaño del cuerpo del paquete (expresado en bytes). Este valor puede variar.
-p Indicamos el puerto de destino

Es importante contar con privilegios de superusuario, es por eso que utilizamos “sudo” para correr el comando.
Teniendo en cuenta que el target entonces es 192.168.1.109, que utilizaremos el flag SYN, que lo haremos en modo “flooding”, con cada request con un origen diferente y al puerto HTTP, el comando quedaría conformado así:
sudo hping3 -S 192.168.1.109 --flood --rand-source -d 5000 -p 80
Se podrían utilizar otras variantes y valores, pero a los efectos de la prueba, con estos parámetros es mas que suficiente para causar un DDoS.
Y lanzamos el ataque simultáneamente en las 3 maquinas atacantes !
:~$ sudo hping3 -S 192.168.1.109 --flood --rand-source -d 5000 -p 80
HPING 192.168.1.109 (eth0 192.168.1.109): S set, 40 headers + 5000 data bytes
hping in flood mode, no replies will be shown

Mientras tanto, veamos que ocurre en el servidor target. Para ello utilizaré el analizador de tráfico “IPTRAF”, pero bien usted puede utilizar el que desee (wireshark o tcpdump por ejemplo).
El flujo de tráfico se ve mas o menos así:
http://www.dragonjar.org/wp-content/uploads/2012/09/CAPTURED-TRAFFIC-SYN.png
Al cabo de unos pocos segundos, el sitio se volverá inaccesible dada la cantidad de requests que el servidor tiene que procesar.
Al intentar acceder al sitio atacado, en el puerto 80, se obtiene un timeout dado que el servidor no puede responder a peticiones genuinas por estar saturado de paquetes mal formados:
 http://www.dragonjar.org/wp-content/uploads/2012/09/Screenshot-Problem-loading-page-Mozilla-Firefox-1.png

Como hemos podido ver, un servidor que no está protegido adecuadamente puede ser fácilmente comprometido utilizando unos pocos recursos.
Sin embargo, esta prueba fue realizada en una red interna, simulando un ambiente similar a internet pero sin intermediarios (routers, proxies, etc) que puedan ayudar a mitigar el riesgo aplicando algunas contramedidas, pero si tenemos en cuenta lo mencionado en la primera parte (“Entendiendo DDoS”), ante un ataque masivo, coordinado a nivel mundial, sin dudas esos controles pueden verse desbordados o poco efectivos.

Slow HTTP DDoS Attacks

Este es el segundo ataque que desarrollaremos en este articulo y uno de mis predilectos en el sentido de admiración a como se logra comprometer un servidor web sin mayores recursos al alcance.
También es conocido como “Slowloris” por ser la primera herramienta liberada para explotar una falla de diseño en el manejo de conexiones concurrentes.
Se trata de una técnica que afecta a servidores web (en su mayoría Apache, pero otros también) que tiene la particularidad de provocar un gran impacto utilizando un mínimo de ancho de banda, incluso utilizando unas pocas conexiones hogareñas xDSL.
La idea principal esta basada en como Apache maneja los hilos de conexiones, y a diferencia de otros ataques (como por ejemplo el tratado anteriormente “SYN Flood”) en los cuales son necesarios cientos, miles de paquetes para saturar la víctima, se trata de mantener abiertas conexiones el mayor tiempo posible enviando una respuesta parcial al servidor.
Dado que el pool de hilos disponibles es finito, el colapso se produce cuando éste se ve saturado, ocasionando así una Denegación de Servicio.
Cabe aclarar que este ataque no afecta al servidor entero sino al servicio web solamente, y el servicio se restablece inmediatamente una vez finalizado el ataque.
Veamos en detalle el funcionamiento de este ataque:
Un cliente realiza una petición GET con una cabecera manipulada, la cual no se enviará por completo al servidor, quien, por diseño del protocolo HTTP, se quedará esperando por el resto de los datos. Para ello se suprime el envío del CRLF (señal de finalización) de la cabecera.
Si se producen muchas conexiones al mismo tiempo, el servidor mantendrá esos recursos ocupados hasta dejar de responder a nuevos requests, algunos posiblemente legítimos.

¿Cómo comprobarlo?

Para esta demostración no precisé de muchas maquinas atacantes, ya que, como explicamos antes, la clave está es comprometer a un servidor con pocos recursos al alcance.
Por lo tanto, utilizaré el siguiente escenario, suficiente para la prueba de concepto:

VICTIMA:
IP: 192.168.1.109
HTTP SERVER: Apache/2.2.22

ATACANTE:
IP: 192.168.1.104
SOFTWARE: slowhttptest-1.4

Existen algunas herramientas para hacer una prueba de concepto de este ataque.
Yo utilizaré una herramienta de capa siete desarrollada por Sergey Shekyan, llamada “Slowhttptest”, la cual es útil para simular (y hacer efectivos) ataques Slow HTTP DoS.
Recomiendo fuertemente esta herramienta dada su flexibilidad para realizar otros tipos de pruebas (como por ejemplo “Apache Range Header Attacks”), la posibilidad de generar gráficos y por ser la mas actualizada de las herramientas disponibles para ataques/tests de Slow HTTP DoS.
Queda fuera de este artículo el procedimiento de instalación, pero no se preocupen que está muy bien documentado en la página oficial del proyecto.
Utilizaré el módulo de monitoreo de Apache (server-status) en el servidor target para monitorear la actividad antes y durante un ataque.
En un estado normal, el servidor luce del siguiente modo:
http://www.dragonjar.org/wp-content/uploads/2012/09/Screenshot-Apache-Normal-Status-109-Mozilla-Firefox-1.png

En la máquina atacante, ejecutamos el siguiente comando (debajo explico las opciones y modificadores):
$ slowhttptest -c 1000 -H -g -o attack_stats -i 10 -r 200 -t GET -u http://192.168.1.109 -x 30 -p 3
  • -c number of connections (limited to 65539)
  • -H tipo de ataque que realizaremos (en este caso Slow Down en Headers)
  • -g genera estadistias en formato CSV y HTML
  • -o archivo de salida
  • -i Segundos. Interval between follow up data in seconds, per connection
  • -r Conexiones por segundo
  • -t header/verb to use
  • -u target URL, the same format you type in browser, e.g https://host[:port]/
  • -x max length of follow up data
  • -p timeout to wait for HTTP response on probe connection, after which server is considered inaccesible
Con este seteo, lanzaré un ataque de tipo “Slow Down Headers”, es decir, haremos los requests al servidor pero no completaremos los mismos, forzando al servidor mantener esas conexiones en estado de lectura generando hasta 1000 conexiones concurrentes.
Como se observa en las opciones, puse como opción generar un archivo HTML para posterior análisis del ataque.
Ahora, lancemos el ataque:
Using:
test type: SLOW HEADERS
number of connections: 1000
URL: http://192.168.1.109/
verb: GET
Content-Length header value: 4096
follow up data max size: 604
interval between follow up data: 10 seconds
connections per seconds: 200
probe connection timeout: 3 seconds
test duration: 240 seconds
Sat Jul 28 08:58:47 2012:slow HTTP test status on 0th second:
initializing: 0
pending: 1
connected: 0
error: 0
closed: 0
service available: YES

Sat Jul 28 08:58:52 2012:slow HTTP test status on 5th second:
initializing: 0
pending: 586
connected: 252
error: 0
closed: 0
service available: NO

Sat Jul 28 08:58:58 2012:slow HTTP test status on 10th second:
initializing: 0
pending: 573
connected: 427
error: 0
closed: 0
service available: NO
Desde el servidor target, capturé el estado de las conexiones:

http://www.dragonjar.org/wp-content/uploads/2012/09/reading_state_attack-.png


Como podemos observar en el proceso de ataque de slowhttptest, luego de 5 segundos de lanzado el mismo, el servicio ya no estaba mas disponible, lo cual es fácilmente comprobable al intentar navegar el sitio atacado y luego de unos minutos sin lograr acceder se obtendrá un timeout. (Ver PIC-03).
Luego de finalizado el ataque, la herramienta slowhttptest nos entrega el reporte del ataque:
http://www.dragonjar.org/wp-content/uploads/2012/09/Screenshot-SlowHTTPTesttm-Connection-Results-Mozilla-Firefox.png

Como se puede observar, es una herramienta muy potente la cual debe usarse con mucha responsabilidad. También es muy útil para realizar “Stress Testings” contra servidores propios y poder así testear la carga que soportan los mismos.
Como ya mencionamos antes, en este caso las pruebas son contra un servidor desprotegido, pero en un escenario real, de grandes infraestructuras protegidas, estos tipos de ataques mantienen su efectividad, mas aún si lo pensamos como una posibilidad de ataque distribuido.

Contramedidas

Ojalá pudiese escribir en esta sección una fórmula mágica para protegerse contra los DDoS, pero desafortunadamente no existe una manera de defenderse completamente contra miles y miles de máquinas atacando, lo que si puedo hacer es brindar algunos consejos para mitigar el riesgo y no estar tan expuestos.
Para no entrar en demasiados tecnicismos, ya que hay muchos productos y variedad de sistemas operativos, etc, daré algunos tips generalizados que los administradores de sistemas deberán tener en cuenta para defenderse de ataques DDoS.
Los tips que se muestran a continuación aplican para los dos tipos de ataque planteados en este artículo, y para otros mas también.

A tener en cuenta:

  • Desde ya, estar al día con las actualizaciones de software en uso que esté expuesto a internet.
  • Sin dudas una de las técnicas mas recomendadas es la implementación mixta de
    • Firewall
    • Balanceo de carga
    • Proxy reverso
  • Limitar la cantidad de conexiones permitidas por cada IP individual (100 estaría bien, una vez superado ese límite, las conexiones se rechazan)
  • Limitar el número de conexiones por segundo.
  • Limitar el tiempo en que cada cliente permanece conectado.
  • Teniendo que el servidor web Apache es uno de los mas usados en internet, seguir las recomendaciones de la documentación oficial: http://httpd.apache.org/docs/trunk/misc/security_tips.html
  • Si su aplicación tiene una audiencia específica, por ejemplo, si el servicio es solamente para personas residentes en Ecuador, las peticiones provenientes desde Rusia o China podrían ser blockeadas mediante uso de blacklists de rangos.
Fuente:  http://www.dragonjar.org/

miércoles, 9 de diciembre de 2015

Diferencias entre DoS y DDoS

5:08 p.m. Posted by LanreB OgeiD , No comments
DoS: Denial of Service (Denegación de servicio).

Un servidor web está preparado para soportar una cierta cantidad de peticiones o conexiones simultáneas. Si supera ese límite de conexiones, pueden pasar dos cosas:

1) La respuesta de las peticiones de los usuarios pueden ser lentas o nulas
2) El Servidor se desconecta de la red y queda sin conexión.







Satura el servidor por medio de muchas peticiones de una misma pc que poco a poco va consumiendo recursos hasta que comience a rechazar las peticiones y comenzara a denegar el servicio (DoS)
Como ventaja tiene que el administrador puede ver de dónde vienen todos esos ataques, banea la IP y el ataque cesa…

Este tipo de ataque se realiza con programas de estilo escritorio como este que se puede apreciar en la imagen:


En el cual se coloca una IP y la potencia del ataque y listo.
El uso de este tipo de programas en el hacking es muy mal visto, ya que solo le dan mal uso, es decir, lo utilizan para tirar sitios web.

Así como este, existen varios programas más y son pocos los que les dan buen uso a los programas de este tipo. Un buen uso seria realizar un test de carga o estrés, para saber cuánto trafico podría soportar un sitio web.

DDoS: Distributed Denial of service (Denegacion de servicio distribuida)

Esto es algo similar al ataque DoS, ya que este tipo de ataque también consiste en tirar el servidor. La diferencia está en que este ataque es distribuido. Esto quiere decir que no se ataca desde una sola PC como en el DoS, sino que son muchas PCs, haciendo peticiones al mismo servidor. El administrador de la web no podrá saber de dónde viene el ataque, por lo tanto cuesta más detenerlo. A esto se lo llama Denegación de Servicio Distribuida (DDoS)


Este tipo de ataque (DDoS) Se hace con una red Zombie. En otras palabras, se hace con una Botnet.
En ambos casos lo que se busca es consumir el ancho de banda del servidor para tirar la web.
Obviamente es mucho más potente un ataque con una Botnet ya que son varias PCs las que atacan a un solo sitio.

Este tipo de ataque se realiza con software de escritorio muy similares a los troyanos (tanto el cliente como el servidor son ejecutables), también están los de panel web y finalmente por IRC.
A continuación, algunas capturas de paneles de botnets:

IRC

Web:

En todos los casos, los métodos de propagación son iguales. Un caso muy visto, son los videos llamativos de facebook


Al ser infectados, luego nosotros infectaremos a nuestros contactos y asi sucesivamente hasta formar una cadena con una gran cantidad de infectados


Existen más formas de infección, como la web:


Al abrir o ejecutar cualquiera de estos, es muy probable que acabemos infectados por una botnet y nuestra conexión sería utilizada para atacar sitios.

¿Cómo prevenir ataques?

Como webmasters podemos instalar en nuestro servidor el famoso mod_evasive

Básicamente lo que hace es mantener una tabla dinámica con las URIs accedidas por las distintas IPs de los clientes del Apache, y permite ejecutar algunas acciones cuando una misma IP solicita un mismo recurso (una misma URI o elementos de un mismo sitio) más de n veces en m segundos. La acción por default que ejecuta el mod_evasive es, una vez superado el máximo de requests por segundo permitidos, bloquear durante una cantidad de segundos al cliente (la IP) devolviendo un error 403 (Forbidden) a la petición HTTP. Pero lo interesante es que también permite ejecutar un comando de sistema al registrarse un intento de ataque, con lo cual se puede agregar una regla al iptables para bloquear la IP del cliente.

Otra forma es utilizando Cloudflare que es un sistema gratuito que actua como un servidor "proxy" entre sus visitantes y nuestro servidor. Al actuar como un "proxy", CloudFlare cachea (almacena en memoría) el contenido estático de su web, lo que disminuye el número de peticiones a nuestros servidores, pero todavía permite a sus visitantes el acceso a su web. Existen varias ventajas del sistema CloudFlare.

Mejora del Rendimiento de la Web: CloudFlare tiene servidores "proxy" situados en todo el mundo. Los servidores "proxy" están situados cerca de sus visitantes, lo que significa que noten mejoras en el tiempo de carga de una página, ya que el contenido "cacheado" se entrega desde servidor "caché" más cercano en vez de directamente desde nuestro servidor. Muchos estudios demuestran que cuanto más rápida es una web más tiempo los visitantes permanecen en ella.

Protección contra Comentarios no Deseados (Spam): CloudFlare aprovecha datos de los recursos de terceros para reducir el número de comentarios "spam" en su web.

Alerta a los Visitantes de Ordenadores Infectados: CloudFlare alerta a los visitantes humanos de que tienen un ordenador infestado y que necesitan tomar las acciones apropiadas para limpiar el "malware" o los virus de su ordenador. Los visitantes deberan introducir un CAPTCHA (conjunto visual de números y letras) para acceder a su web.

Modo de Navegación Offline: El el caso de que nuestro servidor esté no disponible, los visitantes podrán aún acceder a su web ya que CloudFlare servirá a los visitantes las páginas desde su memoría caché. Entre otras ventajas más.

Fuente: https://underc0de.org/foro/