Título: Intentando detener un ataque DDoS Publicado por: el-brujo en 25 Agosto 2006, 11:12 am v 2.38
Intentando Detener o mitigar un Ataque de Denegación de Servicio Distribuido Porque un null-route a una ip no es una solución, es una chapuza. Si unos script-kiddies están DDoSeando tu web..... (http://r.i.elhacker.net/cache?url=http://foro.elhacker.net/images/bad-kids.jpg) Index: a) Detectando el ataque 1) Usando el comando netstat 2) Mirando el server-status del Apache 3) Mirando los logs del mod_evasive 4) Mirando los logs del syslog (del kernel) 5) Mirando las gráficas del MRTG, RRDtool, ntopng, Monitorix B) Intentar parar el ataque 1) - mod_evasive 2) - mod_security 3) tcplimit, ipdrop, ipblock 4) Optimizando y asegurando la red con el sysctl.conf 5) APF Firewall con el módulo anti-ddos 6) Parar el/la botnet 7) Usando reglas de iptables 8) Usando el mod_throttle 9) DDoS Deflate, Floodmon 10) CloudFlare, Akamai, Incapsula, Arbor, ProjectShield a) Se basa en ataques reales. b) No hay nada de teoría, solo parte práctica. A) Detectando el ataque 1) Usando el comando netstat Código: netstat -an | grep :80 | sort Código: netstat -n -p | grep SYN_REC | awk '{print $5}' | awk -F: '{print $1}' Código: netstat -n -p|grep SYN_REC | wc -l Código: netstat -lpn|grep :80 |awk '{print $5}'|sort Código: netstat -an | grep :80 | awk '{ print $5 }' | awk -F: '{ print $1 }' | sort | uniq -c | sort -n Ejemplo de ataque SYN_RECV o SYN Flooding al Apache (puerto 80). 192.168.0.3 es la ip del servidor apache y 192.168.0.105 es la ip del "atacante". Código: [..] tcp 0 0 192.168.0.3:80 192.168.0.5:60808 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60761 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60876 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60946 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60763 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60955 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60765 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60826 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60951 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60942 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:61113 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60909 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60822 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60894 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60952 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60928 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60936 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60906 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:61466 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60919 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60914 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60926 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60939 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60931 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60831 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60743 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:61076 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60912 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60816 SYN_RECV [..] Claro ejemplo de SYN Attack al Apache. 2) Mirando el server-status del Apache Si miramos el server-status del apache veremos conexiones en estado "Reading" ("R" Reading Request). (http://2.bp.blogspot.com/-j6EYGuQzIJY/U5RI1lOiSRI/AAAAAAAAGKk/XkUwEjXxBEc/s1600/ataque_reading_marzo2014.png) El problema es que cuando el número de conexiones "Reading" llena el "MaxClients" del Apache no acepta nuevas peticiones, por lo que los nuevos clientes, aunque sean legítimos, no serán aceptados. Podemos aumentar el valor del "MaxClients" para que no se llene la cola de peticiones y acepte a todos los clientes, sean atacantes o no. Otra buena medida es bajar el valor del "Timeout" del Apache para que las peticiones "Reading" sean "matadas" rápidamente, antes que pueda llenarse el MaxClients a su tope. Por defecto en Apache: Código: Timeout 300 Se puede bajar hasta 100 sin problemas, teniendo en cuenta que las conexiones muy lentas pueden tener problemas. Para aumentar el MaxClients en el fichero httpd.conf Apache 2 basta con añadir la directiva: ServerLimit 350 antes de MaxClients y ya dejará. Código: <IfModule prefork.c> [..] ServerLimit 500 MaxClients 450 [..] </IfModule> Y la directiva ListenBackLog Código: #por defecto ListenBacklog 511 ataque tcp syn flood Herramienta Floodmon: alerta, detecta y mitiga ataques SYN Flood#http://httpd.apache.org/docs/2.0/mod/mpm_common.html#listenbacklog ListenBackLog 1024 http://blog.elhacker.net/2014/05/floodmon-alerta--detecta-mitiga-ataques-tcp-syn-flood-ip.html 3) Mirando los logs del mod_evasive Citar Jun 22 18:24:04 lan mod_evasive[3835]: Blacklisting address 82.228.169.50: possible attack. Jun 22 18:24:45 lan mod_evasive[3600]: Blacklisting address 81.206.164.163: possible attack. Jun 22 18:25:46 lan mod_evasive[3589]: Blacklisting address 155.232.250.19: possible attack. Jun 22 18:27:23 lan mod_evasive[3671]: Blacklisting address 83.227.217.2: possible attack. Jun 22 18:28:10 lan mod_evasive[3673]: Blacklisting address 68.187.171.89: possible attack. Jun 22 18:29:57 lan mod_evasive[3605]: Blacklisting address 70.143.2.130: possible attack. Jun 22 18:30:45 lan mod_evasive[3803]: Blacklisting address 69.157.93.88: possible attack. Jun 22 18:31:45 lan mod_evasive[10397]: Blacklisting address 146.64.81.22: possible attack. Jun 22 18:35:01 lan mod_evasive[3794]: Blacklisting address 66.38.192.134: possible attack. Jun 22 18:35:15 lan mod_evasive[3553]: Blacklisting address 81.190.204.64: possible attack. Jun 22 18:40:10 lan mod_evasive[16602]: Blacklisting address 64.231.39.129: possible attack. Jun 22 18:48:04 lan mod_evasive[16479]: Blacklisting address 84.99.195.100: possible attack. Jun 22 18:48:12 lan mod_evasive[16467]: Blacklisting address 201.0.10.142: possible attack. Jun 22 18:52:57 lan mod_evasive[16573]: Blacklisting address 219.95.39.242: possible attack. Jun 22 18:53:07 lan mod_evasive[16534]: Blacklisting address 86.129.3.91: possible attack. Jun 22 18:53:26 lan mod_evasive[16527]: Blacklisting address 62.254.0.32: possible attack. Jun 22 18:54:41 lan mod_evasive[30473]: Blacklisting address 24.196.199.191: possible attack. Jun 22 18:55:17 lan mod_evasive[30520]: Blacklisting address 142.161.157.227: possible attack. Jun 22 18:55:24 lan mod_evasive[30461]: Blacklisting address 65.92.145.133: possible attack. Jun 22 18:55:33 lan mod_evasive[30509]: Blacklisting address 88.111.227.200: possible attack. Jun 22 18:56:13 lan mod_evasive[30473]: Blacklisting address 69.199.94.227: possible attack. Jun 22 18:57:45 lan mod_evasive[30517]: Blacklisting address 86.125.135.212: possible attack. Jun 22 18:57:54 lan mod_evasive[30479]: Blacklisting address 84.192.141.65: possible attack. Jun 22 18:58:46 lan mod_evasive[30527]: Blacklisting address 83.140.97.106: possible attack. Jun 22 18:59:31 lan mod_evasive[30469]: Blacklisting address 82.173.216.196: possible attack. Jun 22 19:00:33 lan mod_evasive[30517]: Blacklisting address 80.176.157.245: possible attack. Jun 22 19:00:38 lan mod_evasive[30470]: Blacklisting address 86.133.102.51: possible attack. Jun 22 19:01:35 lan mod_evasive[30870]: Blacklisting address 24.42.134.253: possible attack. Jun 22 19:01:48 lan mod_evasive[30509]: Blacklisting address 62.254.0.34: possible attack. Jun 22 19:02:57 lan mod_evasive[31009]: Blacklisting address 81.227.219.125: possible attack. Jun 22 19:03:29 lan mod_evasive[31056]: Blacklisting address 172.209.173.153: possible attack. Jun 22 19:05:07 lan mod_evasive[31385]: Blacklisting address 84.6.12.110: possible attack. Jun 22 19:06:52 lan mod_evasive[31008]: Blacklisting address 85.227.144.249: possible attack. Jun 22 19:06:56 lan mod_evasive[31263]: Blacklisting address 213.222.156.222: possible attack. Jun 22 19:07:13 lan mod_evasive[31393]: Blacklisting address 62.163.143.166: possible attack. Jun 22 19:07:37 lan mod_evasive[31021]: Blacklisting address 62.135.101.73: possible attack. Jun 22 19:08:03 lan mod_evasive[31251]: Blacklisting address 82.201.249.69: possible attack. Jun 22 19:08:17 lan mod_evasive[31200]: Blacklisting address 81.62.65.53: possible attack. Jun 22 19:11:04 lan mod_evasive[31263]: Blacklisting address 82.39.148.204: possible attack. Jun 22 19:12:37 lan mod_evasive[31241]: Blacklisting address 213.222.154.13: possible attack. Jun 22 19:13:54 lan mod_evasive[31027]: Blacklisting address 81.51.79.4: possible attack. Jun 22 19:24:04 lan mod_evasive[31041]: Blacklisting address 84.221.118.156: possible attack. Jun 22 19:48:47 lan mod_evasive[3400]: Blacklisting address 62.135.101.192: possible attack. Jun 22 19:53:04 lan mod_evasive[31031]: Blacklisting address 62.30.33.13: possible attack. Jun 22 19:54:32 lan mod_evasive[31016]: Blacklisting address 72.14.194.18: possible attack. Jun 22 19:56:10 lan mod_evasive[31067]: Blacklisting address 198.96.34.58: possible attack. Jun 22 20:03:24 lan mod_evasive[5144]: Blacklisting address 172.213.33.242: possible attack. Jun 22 20:08:31 lan mod_evasive[5137]: Blacklisting address 83.241.11.16: possible attack. Jun 22 20:21:59 lan mod_evasive[6645]: Blacklisting address 201.23.193.20: possible attack. Jun 22 20:32:28 lan mod_evasive[7801]: Blacklisting address 212.38.134.172: possible attack. Jun 22 20:45:46 lan mod_evasive[7836]: Blacklisting address 81.247.11.48: possible attack. Jun 22 20:48:03 lan mod_evasive[7796]: Blacklisting address 70.245.98.186: possible attack. Jun 22 20:49:38 lan mod_evasive[7832]: Blacklisting address 61.8.138.203: possible attack. Jun 22 20:51:21 lan mod_evasive[7801]: Blacklisting address 201.132.197.161: possible attack. Jun 22 20:57:18 lan mod_evasive[10426]: Blacklisting address 82.201.249.67: possible attack. Jun 22 20:57:51 lan mod_evasive[7822]: Blacklisting address 81.77.26.162: possible attack. Jun 22 21:00:25 lan mod_evasive[7817]: Blacklisting address 200.39.202.243: possible attack. Jun 22 21:12:04 lan mod_evasive[7794]: Blacklisting address 84.27.139.25: possible attack. Jun 22 21:22:27 lan mod_evasive[7816]: Blacklisting address 217.208.98.254: possible attack. Si es un DDoS muy distribuido enseguida notaremos que muchas ip's diferente DoSean el Apache. 4) Mirando los logs del syslog (del kernel) Citar May 17 13:39:01 lan kernel: possible SYN flooding on port 80. Sending cookies. May 17 13:39:02 lan kernel: ip_conntrack: table full, dropping packet. May 17 13:39:35 lan kernel: NET: 4 messages suppressed. May 17 13:39:35 lan kernel: ip_conntrack: table full, dropping packet. May 17 13:39:38 lan kernel: NET: 1 messages suppressed. May 17 13:39:38 lan kernel: ip_conntrack: table full, dropping packet. May 17 13:39:43 lan kernel: NET: 6 messages suppressed. May 17 13:39:43 lan kernel: ip_conntrack: table full, dropping packet. May 17 13:39:48 lan kernel: NET: 4 messages suppressed. May 17 13:39:48 lan kernel: ip_conntrack: table full, dropping packet. May 17 13:39:52 lan kernel: NET: 9 messages suppressed. May 17 13:39:52 lan kernel: ip_conntrack: table full, dropping packet. May 17 13:39:57 lan kernel: NET: 15 messages suppressed. May 17 13:39:57 lan kernel: ip_conntrack: table full, dropping packet. May 17 13:40:01 lan kernel: possible SYN flooding on port 80. Sending cookies. Líneas a mirar: Citar possible SYN flooding on port 80. Sending cookies. "Sending Cookies" si lo tenemos activado en el /etc/sysctl.conf # Enable TCP SYN Cookie Protection Código: net.ipv4.tcp_syncookies = 1 A veces es mejor deshabilitarlo: Código: net.ipv4.tcp_syncookies = 0 De esta manera podemos ver las ip's del ataque: Citar Jul 14 12:46:50 lan kernel: TCP: drop open request from 80.171.45.81/63069 Jul 14 12:46:55 lan kernel: NET: 1401 messages suppressed. Jul 14 12:46:55 lan kernel: TCP: drop open request from 80.103.166.148/4403 Jul 14 12:46:59 lan kernel: NET: 1772 messages suppressed. Jul 14 12:46:59 lan kernel: TCP: drop open request from 200.127.62.215/4019 Jul 14 12:47:05 lan kernel: NET: 2362 messages suppressed. Jul 14 12:47:05 lan kernel: TCP: drop open request from 85.57.169.142/19899 Jul 14 12:47:11 lan kernel: NET: 2618 messages suppressed. Jul 14 12:47:11 lan kernel: TCP: drop open request from 83.19.73.122/2710 Jul 14 12:47:14 lan kernel: NET: 898 messages suppressed. Jul 14 12:47:14 lan kernel: TCP: drop open request from 80.235.39.64/3554 Jul 14 12:47:19 lan kernel: NET: 1120 messages suppressed. Jul 14 12:47:19 lan kernel: TCP: drop open request from 80.171.45.81/62095 Jul 14 12:47:24 lan kernel: NET: 1714 messages suppressed. Jul 14 12:47:24 lan kernel: TCP: drop open request from 84.62.152.44/34014 Jul 14 12:47:29 lan kernel: NET: 2274 messages suppressed. Jul 14 12:47:29 lan kernel: TCP: drop open request from 200.127.62.215/3207 Jul 14 12:47:34 lan kernel: NET: 1552 messages suppressed. Jul 14 12:47:34 lan kernel: TCP: drop open request from 80.103.166.148/4797 Jul 14 12:47:39 lan kernel: NET: 4044 messages suppressed. Jul 14 12:47:39 lan kernel: TCP: drop open request from 80.235.39.64/2678 Jul 14 12:47:44 lan kernel: NET: 4360 messages suppressed. Jul 14 12:47:44 lan kernel: TCP: drop open request from 80.103.166.148/1312 Jul 14 13:04:15 lan kernel: TCP: drop open request from 200.14.237.83/4787 Jul 14 13:04:22 lan kernel: NET: 147 messages suppressed. Jul 14 13:04:22 lan kernel: TCP: drop open request from 81.38.172.161/4892 Jul 14 13:04:30 lan kernel: NET: 6 messages suppressed. Jul 14 13:04:30 lan kernel: TCP: drop open request from 200.14.237.83/4934 Jul 14 13:04:30 lan kernel: TCP: drop open request from 200.14.237.83/4935 Jul 14 13:04:38 lan kernel: NET: 76 messages suppressed. Jul 14 13:04:38 lan kernel: TCP: drop open request from 81.84.212.34/2861 Jul 14 13:04:40 lan kernel: NET: 269 messages suppressed. Jul 14 13:04:40 lan kernel: TCP: drop open request from 200.14.237.83/3070 Jul 14 13:04:45 lan kernel: NET: 287 messages suppressed. Jul 14 13:04:45 lan kernel: TCP: drop open request from 81.203.228.102/4400 Jul 14 13:04:50 lan kernel: NET: 98 messages suppressed. Jul 14 13:04:50 lan kernel: TCP: drop open request from 81.84.212.34/3961 Jul 14 13:04:54 lan kernel: NET: 245 messages suppressed. Jul 14 13:04:54 lan kernel: TCP: drop open request from 200.84.169.200/1183 Jul 14 13:05:00 lan kernel: NET: 1787 messages suppressed. Jul 14 13:05:00 lan kernel: TCP: drop open request from 81.203.228.102/2050 Jul 14 13:05:04 lan kernel: NET: 3208 messages suppressed. Jul 14 13:05:04 lan kernel: TCP: drop open request from 86.212.167.27/4720 Jul 14 13:05:09 lan kernel: NET: 2031 messages suppressed. Jul 14 13:05:09 lan kernel: TCP: drop open request from 81.203.228.102/1794 Jul 14 13:05:14 lan kernel: NET: 2221 messages suppressed. Jul 14 13:05:14 lan kernel: TCP: drop open request from 81.38.172.161/4908 Jul 14 13:05:21 lan kernel: NET: 730 messages suppressed. Jul 14 13:05:21 lan kernel: TCP: drop open request from 81.203.228.102/1430 Jul 14 13:05:25 lan kernel: NET: 234 messages suppressed. Jul 14 13:05:25 lan kernel: TCP: drop open request from 81.203.228.102/2939 Jul 14 13:05:30 lan kernel: NET: 1594 messages suppressed. Jul 14 13:05:30 lan kernel: TCP: drop open request from 200.14.237.83/3876 Jul 14 13:05:36 lan kernel: NET: 633 messages suppressed. Jul 14 13:05:36 lan kernel: TCP: drop open request from 86.212.167.27/1116 Jul 14 13:05:39 lan kernel: NET: 970 messages suppressed. Jul 14 13:05:39 lan kernel: TCP: drop open request from 81.38.172.161/3040 Jul 14 13:05:45 lan kernel: NET: 548 messages suppressed. Jul 14 13:05:45 lan kernel: TCP: drop open request from 81.203.228.102/2119 Jul 14 13:05:50 lan kernel: NET: 421 messages suppressed. Jul 14 13:05:50 lan kernel: TCP: drop open request from 81.203.228.102/2478 Jul 14 13:05:56 lan kernel: NET: 379 messages suppressed. Jul 14 13:05:56 lan kernel: TCP: drop open request from 81.203.228.102/4005 Jul 14 13:05:59 lan kernel: NET: 891 messages suppressed. Jul 14 13:05:59 lan kernel: TCP: drop open request from 81.38.172.161/3568 Jul 14 13:06:04 lan kernel: NET: 2221 messages suppressed. Jul 14 13:06:04 lan kernel: TCP: drop open request from 81.203.228.102/4532 Jul 14 13:06:09 lan kernel: NET: 243 messages suppressed. Jul 14 13:06:09 lan kernel: TCP: drop open request from 81.203.228.102/1939 Jul 14 13:06:14 lan kernel: NET: 2166 messages suppressed. Jul 14 13:06:14 lan kernel: TCP: drop open request from 81.38.172.161/2137 Jul 14 13:06:19 lan kernel: NET: 2071 messages suppressed. Jul 14 13:06:19 lan kernel: TCP: drop open request from 81.38.172.161/3136 Jul 14 13:06:24 lan kernel: NET: 2069 messages suppressed. Jul 14 13:06:24 lan kernel: TCP: drop open request from 81.84.212.34/4600 Jul 14 13:06:29 lan kernel: NET: 1797 messages suppressed. Jul 14 13:06:29 lan kernel: TCP: drop open request from 86.212.167.27/3171 Jul 14 13:06:35 lan kernel: NET: 1292 messages suppressed. Jul 14 13:06:35 lan kernel: TCP: drop open request from 81.203.228.102/1394 Jul 14 13:06:39 lan kernel: NET: 715 messages suppressed. Citar May 17 14:13:24 lan kernel: ip_conntrack: table full, dropping packet. Tabla llena. Tenemos un problema porque no admitiremos más conexiones aunque sean legítimas. Podemos aumentar el valor de dicha tabla si nuestra red da para más. Directamente: Código: echo "65535" > /proc/sys/net/ipv4/ip_conntrack_max Para que el valor quede guardardo y no se pierda al reiniciar, debemos añadirlo en el sysctl.conf Código: net.ipv4.ip_conntrack_max = 65535 Recuerda reiniciar la red para aplicar los cambios en el /proc (service network restart). Paquetes Marcianos: Citar Aug 31 12:41:29 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 12:45:07 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 12:52:57 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 12:58:55 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 13:08:12 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 13:12:03 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 13:34:38 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 13:37:38 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 13:52:42 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 13:56:18 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 13:59:54 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 14:13:32 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 14:38:08 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 14:43:42 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 14:50:05 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 14:51:05 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 14:57:58 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 15:05:27 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 15:06:14 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Aug 31 15:09:08 lan kernel: martian source 192.168.0.10 from 0.0.0.0, on dev eth0 Son paquetes inesperados que llegan por un camino por el cual no pueden llegar indica algún problema de audacia (cracker). Usando paquetes como éstos se pueden atacar vulnerabilidades remotas en stacks TCP/IP . UDP: bad checksum y UDP: short packet Ataques inundación paquetes UDP seguramente usando reflectores y técnicas de amplificación DrDDoS http://blog.elhacker.net/2014/06/udp-flood-inundacion-reflection-attack-ataque.html Citar [..] Sep 8 15:17:03 ns7 kernel: UDP: bad checksum. From 113.9.245.94:1388 to 108.162.206.73:80 ulen 328 Sep 8 15:17:04 ns7 kernel: UDP: bad checksum. From 113.0.136.151:1388 to 108.162.206.73:80 ulen 330 Sep 8 15:17:04 ns7 kernel: UDP: bad checksum. From 221.208.29.91:1388 to 108.162.206.73:80 ulen 328 Sep 8 15:17:05 ns7 kernel: UDP: bad checksum. From 1.62.206.110:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:17:06 ns7 kernel: UDP: bad checksum. From 1.62.120.124:1388 to 108.162.206.73:80 ulen 276 Sep 8 15:17:06 ns7 kernel: UDP: bad checksum. From 220.192.216.53:1388 to 108.162.206.73:80 ulen 250 Sep 8 15:17:10 ns7 kernel: UDP: bad checksum. From 1.62.206.110:1388 to 108.162.206.73:80 ulen 330 Sep 8 15:17:13 ns7 kernel: UDP: bad checksum. From 221.207.182.119:1388 to 108.162.206.73:80 ulen 334 Sep 8 15:17:13 ns7 kernel: UDP: bad checksum. From 1.190.191.225:1388 to 108.162.206.73:80 ulen 276 Sep 8 15:17:14 ns7 kernel: UDP: bad checksum. From 221.207.218.4:1388 to 108.162.206.73:80 ulen 276 Sep 8 15:17:23 ns7 kernel: UDP: bad checksum. From 113.9.245.94:1388 to 108.162.206.73:80 ulen 250 Sep 8 15:17:23 ns7 kernel: UDP: bad checksum. From 221.207.203.17:1363 to 108.162.206.73:80 ulen 352 Sep 8 15:17:26 ns7 kernel: UDP: bad checksum. From 1.190.191.225:1388 to 108.162.206.73:80 ulen 250 Sep 8 15:17:27 ns7 kernel: UDP: bad checksum. From 221.208.29.91:1388 to 108.162.206.73:80 ulen 334 Sep 8 15:17:29 ns7 kernel: UDP: bad checksum. From 221.208.50.50:1388 to 108.162.206.73:80 ulen 278 Sep 8 15:17:31 ns7 kernel: UDP: bad checksum. From 221.207.182.119:1388 to 108.162.206.73:80 ulen 276 Sep 8 15:17:32 ns7 kernel: UDP: bad checksum. From 221.208.16.42:1388 to 108.162.206.73:80 ulen 296 Sep 8 15:17:35 ns7 kernel: UDP: bad checksum. From 220.192.216.53:1388 to 108.162.206.73:80 ulen 276 Sep 8 15:17:35 ns7 kernel: UDP: bad checksum. From 221.207.182.119:1388 to 108.162.206.73:80 ulen 334 Sep 8 15:17:42 ns7 kernel: UDP: bad checksum. From 220.192.216.53:1388 to 108.162.206.73:80 ulen 296 Sep 8 15:17:42 ns7 kernel: UDP: bad checksum. From 1.62.120.124:1388 to 108.162.206.73:80 ulen 298 Sep 8 15:17:47 ns7 kernel: UDP: bad checksum. From 1.62.120.124:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:17:47 ns7 kernel: UDP: bad checksum. From 1.58.196.127:1388 to 108.162.206.73:80 ulen 330 Sep 8 15:17:48 ns7 kernel: UDP: bad checksum. From 113.9.227.210:1388 to 108.162.206.73:80 ulen 298 Sep 8 15:17:48 ns7 kernel: UDP: bad checksum. From 1.62.206.110:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:17:53 ns7 kernel: UDP: bad checksum. From 113.0.136.151:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:17:59 ns7 kernel: UDP: bad checksum. From 1.190.191.225:1388 to 108.162.206.73:80 ulen 328 Sep 8 15:18:00 ns7 kernel: UDP: bad checksum. From 1.62.206.110:1388 to 108.162.206.73:80 ulen 296 Sep 8 15:18:01 ns7 kernel: UDP: bad checksum. From 221.208.18.228:1388 to 108.162.206.73:80 ulen 334 Sep 8 15:18:04 ns7 kernel: UDP: bad checksum. From 113.0.4.194:1388 to 108.162.206.73:80 ulen 250 Sep 8 15:18:07 ns7 kernel: UDP: bad checksum. From 113.9.227.210:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:18:10 ns7 kernel: UDP: bad checksum. From 221.208.50.50:1388 to 108.162.206.73:80 ulen 300 Sep 8 15:18:14 ns7 kernel: UDP: bad checksum. From 221.207.182.119:1388 to 108.162.206.73:80 ulen 330 Sep 8 15:18:17 ns7 kernel: UDP: bad checksum. From 113.0.74.11:1388 to 108.162.206.73:80 ulen 296 Sep 8 15:18:17 ns7 kernel: UDP: bad checksum. From 221.212.160.140:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:18:18 ns7 kernel: UDP: bad checksum. From 113.9.114.231:1388 to 108.162.206.73:80 ulen 334 Sep 8 15:18:18 ns7 kernel: UDP: bad checksum. From 221.208.18.228:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:18:18 ns7 kernel: UDP: bad checksum. From 1.58.196.127:1388 to 108.162.206.73:80 ulen 296 Sep 8 15:18:20 ns7 kernel: UDP: bad checksum. From 1.190.191.225:1388 to 108.162.206.73:80 ulen 314 Sep 8 15:18:23 ns7 kernel: UDP: bad checksum. From 113.9.146.207:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:18:25 ns7 kernel: UDP: bad checksum. From 1.62.120.124:1388 to 108.162.206.73:80 ulen 314 Sep 8 15:18:26 ns7 kernel: UDP: bad checksum. From 221.208.18.228:1388 to 108.162.206.73:80 ulen 314 Sep 8 15:18:26 ns7 kernel: UDP: bad checksum. From 113.0.136.151:1388 to 108.162.206.73:80 ulen 276 Sep 8 15:18:26 ns7 kernel: UDP: bad checksum. From 1.190.134.140:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:18:28 ns7 kernel: UDP: bad checksum. From 1.62.120.124:1388 to 108.162.206.73:80 ulen 334 Sep 8 15:18:29 ns7 kernel: UDP: bad checksum. From 113.9.146.207:1388 to 108.162.206.73:80 ulen 328 Sep 8 15:18:30 ns7 kernel: UDP: bad checksum. From 1.190.191.225:1388 to 108.162.206.73:80 ulen 328 Sep 8 15:18:31 ns7 kernel: UDP: bad checksum. From 221.207.218.4:1388 to 108.162.206.73:80 ulen 276 Sep 8 15:18:35 ns7 kernel: UDP: bad checksum. From 221.207.203.17:4413 to 108.162.206.73:80 ulen 321 Sep 8 15:18:35 ns7 kernel: UDP: bad checksum. From 113.0.189.87:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:18:36 ns7 kernel: UDP: bad checksum. From 1.190.134.140:1388 to 108.162.206.73:80 ulen 298 Sep 8 15:18:36 ns7 kernel: UDP: bad checksum. From 113.0.74.220:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:18:36 ns7 kernel: UDP: bad checksum. From 221.208.29.91:1388 to 108.162.206.73:80 ulen 330 Sep 8 15:18:37 ns7 kernel: UDP: bad checksum. From 221.207.182.119:1388 to 108.162.206.73:80 ulen 276 Sep 8 15:18:37 ns7 kernel: UDP: bad checksum. From 221.207.218.4:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:18:40 ns7 kernel: UDP: bad checksum. From 221.212.160.140:1388 to 108.162.206.73:80 ulen 322 Sep 8 15:18:43 ns7 kernel: UDP: bad checksum. From 113.0.250.3:1388 to 108.162.206.73:80 ulen 334 Sep 8 15:18:43 ns7 kernel: UDP: bad checksum. From 221.208.50.50:1388 to 108.162.206.73:80 ulen 330 Sep 8 15:18:45 ns7 kernel: UDP: bad checksum. From 1.58.196.127:1388 to 108.162.206.73:80 ulen 330 Sep 8 15:18:47 ns7 kernel: UDP: bad checksum. From 221.207.218.4:1388 to 108.162.206.73:80 ulen 296 Sep 8 15:18:48 ns7 kernel: UDP: bad checksum. From 1.62.120.124:1388 to 108.162.206.73:80 ulen 322 [..] 5) Mirando las gráficas del MRTG, RRDtool Si ves que el tráfico inbound sube hasta los 100mbps es que te están doseando. (http://ns2.elhacker.net/segundo_ddos.png) (http://ns2.elhacker.net/ddos.png) Importante mirar la tasa de PPS (packets per second). En ataques se pueden llegar a más de 100k (100 mil) paquetes por segundo. Analizar e inspeccionar el tráfico de red (wireshark, tshark, ntopng, tcpdump, iptraf) en busca de patrones o playload. B) Intentar detener o mitigar un ataque DDoS 1) - mod_evasive Web Oficial: http://www.nuclearelephant.com/projects/mod_evasive/ Consideramos que 50 conexiones por segundo a 2 páginas es suficiente motivo como para bloquear esa ip: Código: <IfModule mod_evasive.c> DOSHashTableSize 3097 DOSPageCount 2 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 DOSBlockingPeriod 900 </IfModule> Igual que el anterior pero con 50 peticiones en un segundo a 1 sola página: Código: <IfModule mod_evasive.c> DOSHashTableSize 3097 DOSPageCount 1 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 </IfModule> Si queremos bloquear las ips que floodean, podemos usar el iptables: DOSSystemCommand "sudo -u root -c '/sbin/iptables -A INPUT -s %s -j DROP" Recordar mirar el syslog por si hay posibles falsos positivos (ip's que no hacian flood). Para evitar falsos positivos: Código: <IfModule mod_evasive.c> # añadir estas líneas que corresponden a rangos de los bots de google DOSWhitelist 66.249.65.* DOSWhitelist 66.249.66.* </IfModule> Importante: Para que el mod_evasive funcione correctamente deberás modificar el: Citar MaxRequestsPerChild 0 Para poner un valor alto pero nunca ilimitado (0). Citar MaxRequestsPerChild 10000 Config ejemplo: http://www.eth0.us/mod_evasive 2 - mod_security El único problema del mod_security es que necesitamos al menos un argumento para detectar el ataque. En el ejemplo usamos en http_referer y el User Agent para detectar el DDoS: Bloqueando un ataque Iframe http://foro.elhacker.net/seguridad/bloqueando_un_ataque_iframe-t127481.0.html 3- tcplimit, ipdrop, ipblock Usando firewalls dinámicos. 4- Optimizando y asegurando la red con el sysctl.conf cat /proc/sys/net/ipv4/tcp_syncookies Código: # Enable IP spoofing protection, turn on Source Address Verification net.ipv4.conf.all.rp_filter = 1 # Enable TCP SYN Cookie Protection net.ipv4.tcp_syncookies = 1 # Enable ignoring broadcasts request net.ipv4.icmp_echo_ignore_broadcasts = 1 1). Activate SynCookies protection It works by sending out 'syncookies' when the syn backlog queue of a socket overflows. => echo 1 >/proc/sys/net/ipv4/tcp_syncookies or => /sbin/sysctl -w net.ipv4.tcp_syncookies=1 2). Disable source routing => for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f done or => /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0 3). Reverse Path Filtering Reject incoming packets if their source address doesn't match the network interface that they're arriving on => for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done or => /sbin/systcl -w net.ipv4.conf.all.rp_filter=1 4). Log RP filter dropped packets (martians) => for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done or => /sbin/sysctl -w net.ipv4.conf.all.log_martians=1 5). Maximal number of remembered connection requests => /sbin/sysctl -w net.ipv4.tcp_max_syn_backlog=256 6). How may times to retry before killing TCP connection (default 7 on most systems) => /sbin/sysctl -w net.ipv4.tcp_orphan_retries=4 7). Number of SYN packets the kernel will send before giving up => /sbin/sysctl -w net.ipv4.tcp_syn_retries=5 8). Disable broadcast icmp reply => /sbin/sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 9). Ignore Bogus icmp packets => /sbin/sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1 10). Disable ICMP redirect => echo 0 >/proc/sys/net/ipv4/conf/all/accept_redirects => echo 0 >/proc/sys/net/ipv4/conf/all/send_redirects or => /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0 => /sbin/sysctl -w net.ipv4.conf.all.send_redirects=0 11). Disable timestamps => echo 0 >/proc/sys/net/ipv4/tcp_timestamps or => /sbin/sysctl -w net.ipv4.tcp_timestamps=0 12). Reduce DOS ability by reducing timeouts => echo 30 >/proc/sys/net/ipv4/tcp_fin_timeout => echo 1800 >/proc/sys/net/ipv4/tcp_keepalive_time => echo 0 >/proc/sys/net/ipv4/tcp_window_scaling => echo 0 >/proc/sys/net/ipv4/tcp_sack or => /sbin/sysctl -w net.ipv4.tcp_fin_timeout=30 => /sbin/sysctl -w net.ipv4.tcp_keepalive_time=1800 => /sbin/sysctl -w net.ipv4.tcp_window_scaling=0 => /sbin/sysctl -w net.ipv4.tcp_sack=0 - Lista de todas las variables del TCP: (Lista de Variables del /proc/sys/net/ipv4/* (con varlores por defecto y explicaciones)) http://www.frozentux.net/ipsysctl-tutorial/ipsysctl-tutorial.html - Optimizando el kernel de linux mediante tuning y hardering sysctl.conf http://wiki.elhacker.net/sistemas-operativos/gnulinux/tuning-sysctl-conf - Opciones de seguridad en Linux a través de /proc (I) y (II) http://www.elhacker.net/opciones-seguridad-linux-proc.html Más ejemplos de configuración completa del sysctl.conf en las referencias del documento. 5- APF Firewall con el módulo anti-ddos Código: wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz tar xvzf apf-current.tar.gz cd apf-0.9.6-1/ ./install.sh service apf start /usr/local/sbin/apf -s Fichero de configuración: Citar /etc/apf/conf.apf Despues de hacer las pruebas dejar: DEVEL_MODE="0" Si nos sale un error parecido a este: apf(9413): unable to load iptables module (ip_tables), aborting. Cambiamos esto: SET_MONOKERN="1" Puertos que queremos abrir (inbound) IG_TCP_CPORTS="21,22,25,53,80,110" Si queres bloquear todo el tráfico de salida lo ponemos en 1 (outbound) EGF="0" Si queremos usar el módulo antddos poner a 1: USE_AD="0" Log: /var/log/apf_log Para ver los paquetes que dropeamos: LOG_DROP="1" Lo guardará en el syslog, ejemplo: Proto= Protocolo SRC= ip origen SPT= Source Port (puerto d origen) DST= Destination Port (puerto destino) Citar Oct 20 13:59:27 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=18779 PROTO=TCP SPT=11629 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:16 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=20376 PROTO=TCP SPT=27734 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:17 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=20382 PROTO=TCP SPT=25943 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:17 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=20387 PROTO=TCP SPT=19026 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:17 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=20397 PROTO=TCP SPT=2155 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:17 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=20407 PROTO=TCP SPT=9294 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:22 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=20687 PROTO=TCP SPT=9269 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:22 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=20694 PROTO=TCP SPT=27223 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:23 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=20830 PROTO=TCP SPT=30938 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:25 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=21038 PROTO=TCP SPT=5377 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:27 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=21219 PROTO=TCP SPT=13341 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:00:42 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=21990 PROTO=TCP SPT=22960 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Oct 20 14:02:32 ns2 kernel: ** SANITY ** IN=eth0 OUT= SRC=213.27.201.254 DST=192.168.0.3 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=26386 PROTO=TCP SPT=2826 DPT=80 WINDOW=0 RES=0x00 RST FIN URGP=0 Recuerda que para usar el antidos debes añadir el cron job: */8 * * * * root /etc/apf/ad/antidos -a >> /dev/null 2>&1 http://www.r-fx.org/apf/README.antidos KISS My Firewall es una alternativa. Script PHP http://www.prism-hosting.com/AntiDoS 6- Parar el botnet ZmbScap - Zombie Scapper - Stoopt DDoS Programs http://www.metaeye.org/projects/zmbscap/ Tracking Botnets - Bot-Commands http://www.honeynet.org/papers/bots/botnet-commands.html Tracking Botnets http://www.honeynet.org/papers/bots/ Tracking Botnets - DDoS-attacks http://www.honeynet.org/papers/bots/botnet-ddos.html Phatbot Trojan Analysis http://www.lurhq.com/phatbot.html F-Bot by f-secure- Elimina el Agobot y todas sus variantes http://www.f-secure.com/tools/f-bot.zip Nepenthes - Autoinfecarse sin peligro para analizar http://nepenthes.mwcollect.org/ honeytrap – trap attacks against tcp services http://honeytrap.sourceforge.net/ 7) Usando reglas del iptables - Los paquetes del DDoS (Ataque de denegación de servicio distribuido) podrían venir de cualquier parte del mundo Podemos limitar con iptables el tráfico udp Código: # Limitar el UDP flood # Crear la cadena para UDP flood iptables -N cadena-udp-flood # Saltar a la cadena cuando el UDP es detectado iptables -A INPUT -p udp -j cadena-udp-flood # Limitar la velocidad UDP a 10/segundos con limite de 20 iptables -A cadena-udp-flood -m limit – -limit 10/s – -limit-burst 20 -m comment – -comment “Limite velocidad UDP” -j RETURN # Logear iptables -A cadena-udp-flood -m limit – -limit 6/h – -limit-burst 1 -j LOG – -log-prefix “Probable udp flood “ # Baneados durante 5 minutos los que más floodean iptables -A cadena-udp-flood -m recent – -name blacklist_300 – -set -m comment – -comment “BlackList origen IP” -j DROP Módulo limit (iptables) Diferencias entre limit y limit burst Usando el módulo limit Citar -m limit Podemos hacer uso de limit y limit burst Código: iptables -I FORWARD -p udp -m limit --limit 200/s --limit-burst -j DROP Con --limit se especifica una media (average), no un caudal. Por ejemplo: decir 200/s (200 por segundo) puede significar que en el primer minuto se reciben 50 paquetes y en el segundo también 50 o puede significar que en el primer minuto se reciben 100 y en el segundo 50... la media sigue siendo 200/segundo. El limite puede ser /second (/s) /minute (/m) /hour (/h) /day (/d) --limit-burst especifica un máximo, si no se especifica un --limit-burst por defecto vale 5 y significa que se aceptaran los primeros 5 paquetes y luego se esperara hasta alcanzar la media para seguir aceptando. Módulo Recent (iptables) El módulo de IPTables recientes tiene algunas limitaciones. Por defecto, sólo hace un seguimiento de las 100 más recientes 100 IPs, y los últimos diez paquetes de cada una. Si tienes una gran cantidad de direcciones IP de origen de golpe, estos límites pueden no ser suficientes. Código: # todo el trafico syn -P INPUT DROP -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset -A INPUT -m state --state INVALID -j DROP -P OUTPUT DROP -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A OUTPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset -A OUTPUT -m state --state INVALID -j DROP -P FORWARD DROP -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT -A FORWARD -p tcp ! --syn -j REJECT --reject-with tcp-reset -A FORWARD -m state --state INVALID -j DROP -A INPUT -i lo -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A FORWARD -i lo -o lo -j ACCEPT # sube las cargas pero muchos wwww buena señal -A INPUT -p tcp --syn -j REJECT --reject-with icmp-port-unreachable # la que mejor va -N syn-flood -A syn-flood -m limit --limit 100/second --limit-burst 150 -j RETURN -A syn-flood -j LOG --log-prefix "SYN flood: " -A syn-flood -j DROP # igual que el de arriba pero muy bestia -N syn-flood -A INPUT -i eth0:2 -p tcp --syn -j syn-flood -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN -A syn-flood -j DROP -A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m limit --limit 1/sec -j ACCEPT -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j ACCEPT # no es muy efectivo -A INPUT -s 0/0 -p tcp --syn --source-port 1000:5000 --destination-port 80 -j DROP # no es muy efectivo -A INPUT -p tcp -m tcp --dport 80 --sport 1000:5000 --tcp-flags SYN SYN -j DROP # Descartar paquetes mal formados -N PKT_FAKE -A PKT_FAKE -m state --state INVALID -j DROP -A PKT_FAKE -p tcp --dport 80 --tcp-flags ALL ACK,RST,SYN,FIN -j DROP -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,FIN SYN,FIN -j DROP -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,RST SYN,RST -j DROP -A PKT_FAKE -p tcp --dport 80 ! --syn -m state --state NEW -j DROP -A PKT_FAKE -f -j DROP -A PKT_FAKE -j RETURN # syn-flood -N syn-flood -A INPUT -i eth+ -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j syn-flood -A FORWARD -i eth+ -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j syn-flood -A syn-flood -m limit --limit 4/s --limit-burst 16 -j RETURN -A syn-flood -m limit --limit 75/s --limit-burst 100 -j RETURN -A syn-flood -j LOG --log-prefix "SYN FLOOD " --log-tcp-sequence --log-tcp-options --log-ip-options -m limit --limit 1/second -A syn-flood -j DROP # By pepel. Requiere módulo "recent" -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 10 --hitcount 10 -j DROP #explicación: Se añade cada ip que se conecte a la tabla de recent Por por cada ip en la tabla de recent si hace mas de x hits en x segundos, se dropea. iptables -I INPUT -p tcp –syn -m recent –set iptables -I INPUT -p tcp –syn -m recent –update –seconds 10 –hitcount 30 -j DROP UDP Flood /sbin/iptables -A OUTPUT -p udp -m state --state NEW -j ACCEPT /sbin/iptables -A OUTPUT -p udp -m limit --limit 100/s -j ACCEPT /sbin/iptables -A OUTPUT -p udp -j DROP Lo que hace es contar el número de paquetes SYN (inicio de conexión TCP) para cada dirección IP en los últimos 10 segundos. Si llega a 30 descarta ese paquete por lo que no se establecerá la conexión (el TCP volverá a intentar varias veces, cuando baje del límite podrá establecerse). 8) Limitar el ancho de banda servidor web http://www.snert.com/Software/mod_throttle/ Limitar ancho de banda en Apache (http://blog.elhacker.net/2013/02/limitar-ancho-de-banda-en-apache.html) Limitar ancho de banda en Apache Citar mod_bandwidth para Apache versión/rama 1.3.x mod_bw para Apache versión/rama 2.x mod_cband para Apache2 mod_ratelimit para Apache 2.4.x y 2.5.x mod_qos para Apache 2 (quality of service (QoS)) Otros: Mod_Throttle, mod_bandwidth, mod_iplimit, mod_tsunami, mod_limitipconn.c Para Apache 2: mod_cband Código: cd /usr/src wget http://www.snert.com/Software/mod_throttle/mod_throttle312.tgz tar zxvf mod_throttle312.tgz cd mod_throttle-3.1.2 pico Makefile Then edit the line that reads: APXS=apxs And change it to read: APXS=/usr/local/apache/bin/apxs make make install service httpd restart Citar <IfModule mod_throttle.c> ThrottlePolicy Volume 10G 30d </IfModule> <Location /throttle-me> SetHandler throttle-me </Location> http://www.webhostgear.com/160.html 9) Script herramienta Floodmon Floodmon o Script herramienta DDoS Deflate http://blog.elhacker.net/2013/12/ddos-deflate-script-bash-para-mitigar-ataques-ddos-dos.html http://blog.elhacker.net/2014/05/floodmon-alerta--detecta-mitiga-ataques-tcp-syn-flood-ip.html 10) Usar sistemas gratuitos como CloudFlare Servicios basados en una gran infraestructura de red que incluyen técnicas de mitigación pro-activas, filtrado e inspección de paquetes Funcionamiento y configuración protección DDoS de CloudFlare (http://blog.elhacker.net/2014/10/funcionamiento-configuracion-proteccion-ataques-ddos-cloudflare.html) Título: Re: Intentando detener un DDoS Publicado por: Codename!! en 25 Agosto 2006, 19:49 pm OOooh Yeahh, muy buen trabajo, date por seguro que te pitaran los oidos, en concreto el derecho, porke te alabaran XD, enserio muy bueno, gracias.
Título: Re: Intentando detener un DDoS Publicado por: - n0sEcReT - en 25 Agosto 2006, 20:43 pm Epa! Brujo , las experiencias siempre nos dejan algo que aprender ..no ? Muy buen tutorial brother ;)
Salu2! Título: Re: Intentando detener un DDoS Publicado por: Neobius en 26 Agosto 2006, 20:35 pm Magnifico tutorial, felicidades brujo.
PD: Acaba de salir en portada de meneame :D Título: Re: Intentando detener un DDoS Publicado por: Division-x en 27 Agosto 2006, 03:38 am el p**o amo........
Pd: muchisimas gracis por este aporte, lo agrego a favoritos...... Título: Re: Intentando detener un DDoS Publicado por: дٳŦ٭ en 27 Agosto 2006, 12:22 pm Excelente guia pero creo que donde se tiene que enfocar mucho es en firewall, claro, el mod_evasive es una maravilla pero siempre es mejor tener a los dos de nuestro lado xD
Saludos y felicitaciones Título: Re: Intentando detener un DDoS Publicado por: dxr en 27 Agosto 2006, 15:33 pm Es un buen tutorial. Pero hay que seguir trabajando buscando soluciones a atakes alternativos. Esta defensa esta orientada a atakes via HTTP y TCP.
Seguro que en un tiempo se seguiran publicando documentacion para parar este tipo de atakes sobre distintos protocolos. Enorabuena Alex. Título: Re: Intentando detener un DDoS Publicado por: XpyXt en 28 Agosto 2006, 07:55 am Texto magnifico :P
Venga tio a seguir asi. Saludos Título: Re: Intentando detener un DDoS Publicado por: icisneros en 28 Agosto 2006, 14:48 pm Portada de barrapunto (http://barrapunto.com/articles/06/08/27/0759214.shtml)
Enhorabuena! Saludos!! Título: Re: Intentando detener un DDoS Publicado por: Sagman en 28 Agosto 2006, 17:43 pm Muy buen manual Alex ;)
Título: Re: Intentando detener un DDoS Publicado por: o2T7f6j2 en 29 Agosto 2006, 01:09 am Los frutos del caldo de cultivo. Muy bueno.
Trataré de seguirlo para adaptarlo a "packet filter" ;) Salu2 Título: Re: Intentando detener un DDoS Publicado por: Azielito en 30 Agosto 2006, 00:09 am no lo habia leido >.< esta muy buenno, felicidades el-brujo yo creo que gracias a que te atacan el server aprendes todo eso :D
Título: Re: Intentando detener un DDoS Publicado por: дٳŦ٭ en 30 Agosto 2006, 04:18 am Wenas
5- APF Firewall con el módulo anti-ddos */8 * * * * root /etc/apf/ad/antidos -a >> /dev/null 2>&1 KISS My Firewall es una alternativa. Aquí dejo un excelente "how to" para el KISS: KISS My Firewall http://www.geocities.com/steve93138/ También hay alternativas para Windows, el Kapersky anti-hacker es efectivo cuando nos hacen un DoS, en los dDos nunca he tenido la oportunidad de verlo en acción. Ah, también banea la ip cuando te hacen un scan de puertos a la Ip. Saludos Título: Re: Intentando detener un DDoS Publicado por: Hyde en 12 Septiembre 2006, 06:38 am Parece que el-jefe sabe mas de lo que creemos jejeje enhorabuena Alex eres uno de los grandes compañero
Salu2 Hyde Título: Re: Intentando detener un DDoS Publicado por: -[ §@NTTI ]- en 14 Septiembre 2006, 18:27 pm :D Excelente amigo, muuuy bien.... Cada dia mas...
SANTTI... DESDE CHILE... Título: Re: Intentando detener un DDoS Publicado por: AGE_vs_shory en 27 Septiembre 2006, 21:17 pm wow que buen documento master exelente muchas gracias ;D
Título: Re: Intentando detener un DDoS Publicado por: [Prescott] en 21 Octubre 2006, 08:58 am Telo concedo Sarjo!!. Para que lo estudies. :)
Título: como poder evitarlo usando htaccess Publicado por: kavastudios en 9 Diciembre 2006, 08:41 am Hola que tal soy nuevo en este foro y he estado checandolo y de verdad que se encuentra informacion muy util un saludo y felicitacion a todos los que escriben tutoriales y responden preguntas, gracias por compartir sus conocimientos.
fijense que soy webmaster de varias paginillas las cuales tengo hospedadas en servicios de hosting comunes y corrientes ( osea hosting compartido ) y recientemente a una de mis webs ha tenido ataques DoS y no he podido bannear las maquinas atacantes pues constantemente cambia de ips, leyendo este articulo vi que modificando uno de los mods del apache podiamos limitar el numero maximo de conexiones de cada ip, pero mi pregunta es ver si hay algun metodo de hacer esto usando archivos htaccess pues yo no tengo acceso a la configuracion del server ni del apache. En caso de ser asi cual seria la sintaxis, espero me peudan ayudar gracias Título: Re: Intentando detener un DDoS Publicado por: phacker en 15 Septiembre 2007, 03:07 am wow =)
excelente tutorial... segui asi ;) Título: Re: como poder evitarlo usando htaccess Publicado por: дٳŦ٭ en 15 Septiembre 2007, 03:24 am Hola que tal soy nuevo en este foro y he estado checandolo y de verdad que se encuentra informacion muy util un saludo y felicitacion a todos los que escriben tutoriales y responden preguntas, gracias por compartir sus conocimientos. fijense que soy webmaster de varias paginillas las cuales tengo hospedadas en servicios de hosting comunes y corrientes ( osea hosting compartido ) y recientemente a una de mis webs ha tenido ataques DoS y no he podido bannear las maquinas atacantes pues constantemente cambia de ips, leyendo este articulo vi que modificando uno de los mods del apache podiamos limitar el numero maximo de conexiones de cada ip, pero mi pregunta es ver si hay algun metodo de hacer esto usando archivos htaccess pues yo no tengo acceso a la configuracion del server ni del apache. En caso de ser asi cual seria la sintaxis, espero me peudan ayudar gracias Pues por htaccess no xD pero te dejo algo ;) : Código
Suerte Título: Re: Intentando detener un DDoS Publicado por: xDie en 19 Septiembre 2007, 17:37 pm Los paquetes llegan al servidor igual, estas en la misma
Título: Re: Intentando detener un DDoS Publicado por: l337* en 10 Noviembre 2007, 08:03 am Citar Ejemplo de ataque SYN_RECV o SYN Flooding al Apache (puerto 80). 192.168.0.3 es la ip del servidor apache y 192.168.0.105 es la ip del "atacante". Código: tcp 0 0 192.168.0.3:80 192.168.0.5:60808 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60761 SYN_RECV tcp 0 0 192.168.0.3:80 192.168.0.5:60876 SYN_RECV . . . la ip del atacante seria 192.168.0.5 que no? Título: Re: Intentando detener un DDoS Publicado por: Dr.SysCrack en 16 Noviembre 2007, 22:47 pm Exelente manual muy completo y es el primer foro que veo un manual haci muy bien explicado
sa1u2 Título: Re: Intentando detener un DDoS Publicado por: Artikbot en 22 Diciembre 2007, 23:40 pm Felicidades, el-brujo, un tuto de putísima madre :D :D
Salu2! Título: Re: Intentando detener un DDoS Publicado por: Sk9ITk5Z en 9 Enero 2009, 20:29 pm Pues despues de tanto tiempo y aun sirve el manual te sacaste undiez el-brujo...
Título: Re: Intentando detener un DDoS Publicado por: ViperDoom en 27 Febrero 2009, 12:08 pm muy buen material ...
Una dudita: Un amigo tiene un server de mu, y es muy comun que jugadores de otros mu servers traten de tumbar los servers de la competencia por medio de ataques DoS, con el programa turbina; y los ataques se realizan generalmente al puerto 44405. Como puedo detectar y detener un ataque en un windows server? desde ya muchaas gracias! Título: Re: Intentando detener un DDoS Publicado por: Artikbot en 13 Mayo 2009, 23:57 pm con TurbinaS? Pues estudia el patrón de ataque (fácil de econtrar) y crea una regla que filtre todas las conexiones de ese tipo.
Título: Re: Intentando detener un DDoS Publicado por: juato4 en 26 Febrero 2010, 19:29 pm Hola!.
La verdad me está ayudando muchisimo tu post. la verdad es que no se si estoy recibiendo un DDOS, pero supongo que si. Me escanean con el famoso DFIND, hasta que el apache supera el MaxConnections... el problema que tengo es que la version de iptables que tengo es vieja y no puedo usar algunos comandos, actualizar demandaria tambien la kernel a lo que no se puede actualmente. La verdad no se que hacer, porque banneo ips con iptables, he usado el modulo mod_limitipconn.c pero no se si está funcionando, sinceramente. ahora, cuando le doy al comando que tu expones: Código: miservidor:/etc/apache2# netstat -an | grep :80 | awk '{ print $5 }' | awk -F: '{ print $1 }' | sort | uniq -c | sort -n ]1 200.119.153.3 2 190.67.192.160 3 200.80.241.2 4 189.180.73.116 150 el numero de conexiones a veces no concuerda con las conexiones por IP, a veces el numero que ahora dice 150, está en 600 y solo hay 2 o 3 ip conectadas con 3 conexiones abiertas. que puede ser?. Saludos y espero que sepas que puede estar pasando!. Título: Re: Intentando detener un DDoS Publicado por: tecasoft en 7 Junio 2010, 19:22 pm wenas gente, queria saber de este codigo que me explicarán un poco pork hay opciones que no termino de entender sobre todo el modulo recent como hago esto correctamente. ademas tendria que escribir todo el codigo tal cual¿?
y que conflictos puede haber con esto¿? ya que estoy montando (debian), un apache,vsftpd,ssh,sendmail Citar # todo el trafico syn -P INPUT DROP -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset -A INPUT -m state --state INVALID -j DROP -P OUTPUT DROP -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A OUTPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset -A OUTPUT -m state --state INVALID -j DROP -P FORWARD DROP -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT -A FORWARD -p tcp ! --syn -j REJECT --reject-with tcp-reset -A FORWARD -m state --state INVALID -j DROP -A INPUT -i lo -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A FORWARD -i lo -o lo -j ACCEPT # sube las cargas pero muchos wwww buena señal -A INPUT -p tcp --syn -j REJECT --reject-with icmp-port-unreachable # la que mejor va -N syn-flood -A syn-flood -m limit --limit 100/second --limit-burst 150 -j RETURN -A syn-flood -j LOG --log-prefix "SYN flood: " -A syn-flood -j DROP # igual que el de arriba pero muy bestia -N syn-flood -A INPUT -i eth0:2 -p tcp --syn -j syn-flood -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN -A syn-flood -j DROP -A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m limit --limit 1/sec -j ACCEPT -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j ACCEPT # no es muy efectivo -A INPUT -s 0/0 -p tcp --syn --source-port 1000:5000 --destination-port 80 -j DROP # no es muy efectivo -A INPUT -p tcp -m tcp --dport 80 --sport 1000:5000 --tcp-flags SYN SYN -j DROP # Descartar paquetes mal formados -N PKT_FAKE -A PKT_FAKE -m state --state INVALID -j DROP -A PKT_FAKE -p tcp --dport 80 --tcp-flags ALL ACK,RST,SYN,FIN -j DROP -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,FIN SYN,FIN -j DROP -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,RST SYN,RST -j DROP -A PKT_FAKE -p tcp --dport 80 ! --syn -m state --state NEW -j DROP -A PKT_FAKE -f -j DROP -A PKT_FAKE -j RETURN # syn-flood -N syn-flood -A INPUT -i eth+ -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j syn-flood -A FORWARD -i eth+ -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j syn-flood -A syn-flood -m limit --limit 4/s --limit-burst 16 -j RETURN -A syn-flood -m limit --limit 75/s --limit-burst 100 -j RETURN -A syn-flood -j LOG --log-prefix "SYN FLOOD " --log-tcp-sequence --log-tcp-options --log-ip-options -m limit --limit 1/second -A syn-flood -j DROP # By pepel. Requiere módulo "recent" -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 10 --hitcount 10 -j DROP #explicación: Se añade cada ip que se conecte a la tabla de recent Por por cada ip en la tabla de recent si hace mas de x hits en x segundos, se dropea. iptables -I INPUT -p tcp –syn -m recent –set iptables -I INPUT -p tcp –syn -m recent –update –seconds 10 –hitcount 30 -j DROP Lo que hace es contar el número de paquetes SYN (inicio de conexión TCP) para cada dirección IP en los últimos 10 segundos. Si llega a 30 descarta ese paquete por lo que no se establecerá la conexión (el TCP volverá a intentar varias veces, cuando baje del límite podrá establecerse). Título: Re: Intentando detener un DDoS Publicado por: tecasoft en 7 Junio 2010, 20:15 pm este es el script que voy probando pero termina de funcionar, si quito la ultima linea no funciona. asi que no se que e escrito mal, os lo agradezco, es que me estoy volviendo loco, gracias
Código: #!/bin/sh ## SCRIPT DE IPTABLES v1.4.3.2 ## Fecha del script 22/04/2010 ## Hecho por Sergio para los server ########################### # Declaracion de variables ########################### INORIGEN="0.0.0.0/0.0.0.0" OUTORIGEN="0.0.0.0/0.0.0.0" INDESTINO="0.0.0.0/0.0.0.0" OUTDESTINO="0.0.0.0/0.0.0.0" IFACE1="lo" IFACE2="eth0" echo "Aplicando reglas de Firewall" ## FLUSH de reglas iptables -F iptables -X iptables -Z iptables -t nat -F ## Todo el trafico syn iptables -P INPUT DROP iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset iptables -A INPUT -m state --state INVALID -j DROP iptables -P OUTPUT DROP iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset iptables -A OUTPUT -m state --state INVALID -j DROP iptables -P FORWARD DROP iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp ! --syn -j REJECT --reject-with tcp-reset iptables -A FORWARD -m state --state INVALID -j DROP iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A FORWARD -i lo -o lo -j ACCEPT ## sube las cargas pero muchos www buena señal #iptables -A INPUT -p tcp --syn -j REJECT --reject-with icmp-port-unreachable ## la que mejor va iptables -N syn-flood iptables -A syn-flood -m limit --limit 100/second --limit-burst 150 -j RETURN iptables -A syn-flood -j LOG --log-prefix "SYN flood: " iptables -A syn-flood -j DROP ## Descartar paquetes mal formados iptables -N PKT_FAKE iptables -A PKT_FAKE -m state --state INVALID -j DROP iptables -A PKT_FAKE -p tcp --dport 80 --tcp-flags ALL ACK,RST,SYN,FIN -j DROP iptables -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,FIN SYN,FIN -j DROP iptables -A PKT_FAKE -p tcp --dport 80 --tcp-flags SYN,RST SYN,RST -j DROP iptables -A PKT_FAKE -p tcp --dport 80 ! --syn -m state --state NEW -j DROP iptables -A PKT_FAKE -f -j DROP iptables -A PKT_FAKE -j RETURN ## Requiere modulo "recent" iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 10 --hitcount 10 -j DROP ## Contar paquetes syn iptables -I INPUT -p tcp --syn -m recent --set iptables -I INPUT -p tcp --syn -m recent --update --seconds 10 --hitcount 30 -j DROP ## Empezamos a filtrar # Conexiones SSH - En el puerto 22,registro,bloquear 1º intento de conexion rechazado(scanner puerto),3 conexiones por minuto(ataques diccionario) iptables -A INPUT -s $INORIGEN -i $IFACE2 -p tcp --sport 30000:65535 --dport 22 -m state --state NEW -j LOG --log-prefix "Conexion ssh: " iptables -A INPUT -s $INORIGEN -i $IFACE2 -p tcp --sport 30000:65535 --dport 22 -m limit --limit 1/minute -m state --state NEW -j DROP iptables -A INPUT -s $INORIGEN -i $IFACE2 -p tcp --sport 30000:65535 --dport 22 -m limit --limit 3/minute -m state --state NEW -j ACCEPT # Conexiones DNS iptables -A INPUT -s $INORIGEN -d $INDESTINO -i $IFACE2 -p tcp --sport 53 -j ACCEPT && echo "regla-20 ok" iptables -A INPUT -s $INORIGEN -d $INDESTINO -i $IFACE2 -p udp --sport 53 -j ACCEPT && echo "regla-21 ok" iptables -A OUTPUT -s $OUTORIGEN -d $OUTDESTINO -o $IFACE2 -p tcp --dport 53 -j ACCEPT && echo "regla-22 ok" iptables -A OUTPUT -s $OUTORIGEN -d $OUTDESTINO -o $IFACE2 -p udp --dport 53 -j ACCEPT && echo "regla-23 ok" ## iptables -A INPUT -p tcp --dport 80 -j ACCEPT Título: Re: Intentando detener un DDoS Publicado por: Gurowner en 13 Diciembre 2010, 17:54 pm Brutal... Sobre todo en esta época en que a todos los peques les da por picarse a h4x0r2.
Título: Re: Intentando detener un DDoS Publicado por: Foxy Rider en 19 Mayo 2011, 01:02 am Revivo el tema para agregar algo de info.
En un reciente artículo de la BSD Magazine (http://www.bsdmag.org/) salió cómo mitigar un DDoS con pf (https://secure.wikimedia.org/wikipedia/en/wiki/PF_%28firewall%29) ... les dejo el enlace : http://www.freebsdnews.net/2011/05/17/bsd-magazine-2011-05-embedded-bsd-freebsd-alix/ Saludos. Título: Re: Intentando detener un DDoS Publicado por: kadenasman en 2 Agosto 2011, 07:02 am que buen trabajo, exelente info!!
Título: Re: Intentando detener un DDoS Publicado por: VanX en 21 Agosto 2011, 23:25 pm +10 E-X-C-E-L-E-N-T-E!! ;-) ;-) ;-)
Título: Re: Intentando detener un DDoS Publicado por: P-Joe en 24 Septiembre 2011, 11:52 am Tengo una pregunta, quizás un poco tonta.
¿Esto solo se puede hacer cuando tengas un servidor en tu ordenador instalado? Por ejemplo, yo tengo un servicio únicamente de hosting en la empresa Hetzner, para hacer todo esto se necesitaría un servidor virtual ¿no? ¿O puedo yo hacerlo desde mi hosting? Saludos Título: Re: Intentando detener un DDoS Publicado por: el-brujo en 25 Septiembre 2011, 23:08 pm si, para hacer casi todo lo que indica el manual, debes tener un servidor dedicado y ser root, no sirve un hosting que te ofrece un servicio, entonces el propio hosting debe encargarse de la seguridad del mismo y tu no puedes configurar los servicios, ni protegerlos (apache, etc).
Título: Re: Intentando detener un DDoS Publicado por: P-Joe en 2 Octubre 2011, 22:12 pm Muchas gracias me ha quedado todo claro.
Saludos! Título: Re: Intentando detener un DDoS Publicado por: chericco en 27 Enero 2012, 19:52 pm Excelente trabajo, me has abierto los ojos de verdad muy muy bueno.
Título: Re: Intentando detener un ataque DDoS Publicado por: sergix en 13 Marzo 2012, 22:55 pm Muy bien dicho intentando* ya que siempre habran otras formas de hacer attaques dos me a servidor para mi servidor web.
Título: Re: Intentando detener un ataque DDoS Publicado por: Cergath en 6 Agosto 2012, 03:03 am Hay riesgo si hablamos de 20 conexiones provenientes de la misma IP?...
Título: Re: Intentando detener un ataque DDoS Publicado por: iPαndα en 24 Agosto 2012, 06:35 am Excelente guía. Muy útil, thanks!
Título: Re: Intentando detener un ataque DDoS Publicado por: agrelsoft en 2 Noviembre 2012, 19:33 pm Eres todo un capo, una salvación para mucho como uno que nos la vemos muchas veces negras por culpa de ciertos desadaptados.
Título: Re: Intentando detener un ataque DDoS Publicado por: tecasoft en 8 Febrero 2014, 16:51 pm me podriais ayudar con esto es que nose si se muchas cosas sobre el codigo:
Código: ## Hotlinking (esto funciona) RewriteEngine On RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://tecasoft.com [NC] RewriteCond %{HTTP_REFERER} !^https://tecasoft.com [NC] RewriteCond %{HTTP_REFERER} !^http://www.tecasoft.com [NC] RewriteCond %{HTTP_REFERER} !^https://www.tecasoft.com [NC] RewriteRule .*\.(gif|jpg|png|js)$ - [NC,F] ## Ataque iframe (esto funciona) RewriteEngine On RewriteCond %{HTTP_REFERER} ^http://()?tecahosting.*$ [OR] #RewriteCond %{HTTP_REFERER} ^http://()?piupiu23.*$ [OR] # and so on RewriteCond %{HTTP_REFERER} ^http://www.tecahosting.com/ RewriteRule .* - [F,L] # Evitar escaneos y cualquier intento de manipulación malintencionada # de la URL. Con esta regla es casi imposible lanzar ataques de inyección (SQL, XSS, etc)(estoy hay que probarlo) #RewriteCond %{HTTP_USER_AGENT} ^$ [OR] #RewriteCond %{HTTP_USER_AGENT} ^(-|\.|') [OR] #RewriteCond %{HTTP_USER_AGENT} ^(.*)(<|>|%3C|%3E)(.*) [NC,OR] #RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget)(.*) [NC,OR] #RewriteCond %{HTTP_USER_AGENT} ^(.*)(libwww-perl|libwwwperl|snoopy|curl|wget|winhttp|python|nikto|scan|clshttp|archiver|loader|email|harvest|fetch|extract|grab|miner|suck|reaper|leach)(.*) [NC,OR] ## Denegar el acceso a robots dañinos, browsers offline, etc (esto hay que probarlo) RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR] RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR] RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR] RewriteCond %{HTTP_USER_AGENT} ^Custo [OR] RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR] RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR] RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR] RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR] RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR] RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR] RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR] RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR] RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR] RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR] RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR] RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR] RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR] RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR] RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR] RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR] RewriteCond %{HTTP_USER_AGENT} ^HMView [OR] RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR] RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR] RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR] RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR] RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR] RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR] RewriteCond %{HTTP_USER_AGENT} ^larbin [OR] RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR] RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR] RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR] RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR] RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR] RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR] RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR] RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR] RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR] RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR] RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR] RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR] RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR] RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR] RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR] RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR] RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR] RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR] RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR] RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR] RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR] RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR] RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR] RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR] RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR] RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR] RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR] RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR] RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR] RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR] RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR] RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR] RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR] RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR] RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR] RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR] RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR] RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR] RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR] RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR] RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR] RewriteCond %{HTTP_USER_AGENT} ^Wget [OR] RewriteCond %{HTTP_USER_AGENT} ^Widow [OR] RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR] RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR] RewriteCond %{HTTP_USER_AGENT} ^Zeus RewriteRule .* - [F] ## Servidores proxys (esto hay que probarlo) #RewriteCond %{HTTP:VIA} !^$ [OR] #RewriteCond %{HTTP:FORWARDED} !^$ [OR] #RewriteCond %{HTTP:USERAGENT_VIA} !^$ [OR] #RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR] #RewriteCond %{HTTP:PROXY_CONNECTION} !^$ [OR] #RewriteCond %{HTTP:XPROXY_CONNECTION} !^$ [OR] #RewriteCond %{HTTP:HTTP_PC_REMOTE_ADDR} !^$ [OR] #RewriteCond %{HTTP:HTTP_CLIENT_IP} !^$ #RewriteRule ^(.*)$ - [F] #1 megabyte por segundo (esto hay que probarlo) #LimitRequestBody 1024 #redireccionar a los robots a otra web #RewriteRule ^.*$ http://www.google.es [R,L] # Si existe la cookie te deja entrar sino no (hay que ponerlo a prueba sobre todo para que no caduquen las cookies en el navegador*) #RewriteBase / #RewriteCond %{HTTP_COOKIE} !^.*PHPSESSID.*$ [NC] #RewriteRule .* - [F] |