Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2638 connectés 

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

DDoS/Iptables

n°45103
zhm
Keski se putain de passe ?
Posté le 26-10-2008 à 06:21:04  profilanswer
 

Salut. Un pote se fait DDoS sur son dédié kimsufi OVH. J'aimerais l'aider à stopper l'attaquer.
 
monitoring iptraf :
 
http://img137.imageshack.us/img137/2825/moniroring2fl3.th.jpghttp://img137.imageshack.us/images/thpix.gif
 
 
un peu de log iptraf :
 

Code :
  1. Sat Oct 25 14:40:04 2008; ******** IP traffic monitor started ********
  2. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 212.219.220.226:2873 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  3. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 212.219.220.226:2873 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  4. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 212.214.225.219:1026 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  5. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 212.214.225.219:1026 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  6. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 215.227.213.229:1756 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  7. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 215.227.213.229:1756 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  8. Sat Oct 25 14:40:04 2008; ICMP; eth0; 56 bytes; source MAC address 00d0d3369e40; from 205.171.28.74 to 91.121.99.72; time excd
  9. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 220.224.227.211:2873 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  10. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 220.224.227.211:2873 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  11. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 221.222.223.213:2001 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  12. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 221.222.223.213:2001 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  13. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 217.221.215.216:1026 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  14. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 217.221.215.216:1026 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  15. Sat Oct 25 14:40:04 2008; TCP; eth0; 1500 bytes; from 91.121.99.72:22 to 82.226.75.248:3153 (source MAC addr 001cc002a0f6); first packet
  16. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 218.226.214.216:9000 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  17. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 218.226.214.216:9000 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  18. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 225.224.227.227:9000 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  19. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 228.212.211.211:1756 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  20. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 227.211.223.216:1026 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  21. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 66.130.173.132:33666 to 91.121.99.72:80 (source MAC addr 00d0d3369e40); first packet
  22. Sat Oct 25 14:40:04 2008; TCP; eth0; 1440 bytes; from 91.121.99.72:80 to 66.130.173.132:33666 (source MAC addr 001cc002a0f6); first packet
  23. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 220.223.215.225:2873 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  24. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 220.223.215.225:2873 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  25. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 219.221.225.229:4055 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  26. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 219.221.225.229:4055 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  27. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 213.223.225.226:1234 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  28. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 213.223.225.226:1234 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  29. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 217.222.219.226:2001 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  30. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 217.222.219.226:2001 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  31. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 216.224.220.222:2873 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)
  32. Sat Oct 25 14:40:04 2008; TCP; eth0; 40 bytes; from 91.121.99.72:5121 to 216.224.220.222:2873 (source MAC addr 001cc002a0f6); Connection reset; 1 packets, 40 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
  33. Sat Oct 25 14:40:04 2008; TCP; eth0; 46 bytes; from 221.220.227.217:1739 to 91.121.99.72:5121 (source MAC addr 00d0d3369e40); first packet (SYN)


 
mon iptables :
 

Citation :


#!/bin/bash
 
# Iptable  
 
# Vider les tables actuelles
iptables -t filter -F
iptables -t filter -X
echo - Vidage : [OK]
 
# Autoriser SSH
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
echo - Autoriser SSH : [OK]
 
# Ne pas casser les connexions etablies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
echo - Ne pas casser les connexions établies : [OK]
 
# Interdire toute connexion entrante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
echo - Interdire toute connexion entrante : [OK]
 
# Interdire toute connexion sortante
iptables -t filter -P OUTPUT DROP
echo - Interdire toute connexion sortante : [OK]
 
# Autoriser les requetes DNS, FTP, HTTP, NTP (pour les mises a jour)
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT
echo - Autoriser les requetes DNS, FTP, HTTP, NTP : [OK]
 
# Autoriser loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
echo - Autoriser loopback : [OK]
 
# Autoriser ping chez OVH
iptables -A INPUT -i eth0 -p icmp --source proxy.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source proxy.p19.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source proxy.rbx.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source ping.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source 91.121.99.250 -j ACCEPT  
echo - Autoriser ping : [OK]
 
# Syn Cookies
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo - Syncookies : [OK]
 
# Syn-Flood
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
echo - Limiter le Syn-Flood : [OK]
 
# FDP
iptables -I INPUT -m iprange --src-range 210.0.0.0-230.255.255.255 -j DROP
echo - Anti fdp : [OK]

# Spoofing
iptables -N SPOOFED
iptables -A SPOOFED -s 127.0.0.0/8 -j DROP
iptables -A SPOOFED -s 169.254.0.0/12 -j DROP
iptables -A SPOOFED -s 172.16.0.0/12 -j DROP
iptables -A SPOOFED -s 192.168.0.0/16 -j DROP
iptables -A SPOOFED -s 10.0.0.0/8 -j DROP
echo - Bloquer le Spoofing : [OK]
 
# HTTP
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 8443 -j ACCEPT
echo - Autoriser serveur Apache : [OK]
 
# TEAMSPEAK
iptables -t filter -A INPUT -p tcp --dport 14534 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 51234 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 8767 -j ACCEPT
echo - Autoriser TeamSpeak : [OK]
 
# emulateur
iptables -t filter -A INPUT -p tcp --dport 6900 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 6121 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 5121 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 3306 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 6900 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 6121 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5121 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 3306 -j ACCEPT
echo - Autoriser eAthena : [OK]
 
# FTP
iptables -t filter -A INPUT -p tcp --dport 20 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 21 -j ACCEPT
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
echo - Autoriser serveur FTP : [OK]
 
# Mail
iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 110 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT
echo - Autoriser serveur Mail : [OK]


 
En gras la plage ip du DDoS que j'ai essayer de contrer, mais en vain... des idées?


Message édité par zhm le 26-10-2008 à 06:25:56
mood
Publicité
Posté le 26-10-2008 à 06:21:04  profilanswer
 

n°62580
efimo
Posté le 21-01-2010 à 11:34:52  profilanswer
 

Je déterre car ça m'intéresse de savoir si il y a une ou des solutions efficaces, excluant les plus onéreuses.

Message cité 1 fois

---------------
FeedBack
n°63372
nitro-n2o
Posté le 11-02-2010 à 18:05:34  profilanswer
 

désoler de répondre aussi tard je suppose que depuis il n'y a plus d'attaque cependant je t'envoie se site http://deflate.medialayer.com/ qui permet de iptables une ip automatiquement quand elle génère trop de connexions tcp abusive a toi de configurer le nombre de connexion a tcp a ne pas dépasser:
nano /usr/local/ddos/ddos.conf
NO_OF_CONNECTIONS=100 tu règle ceci et aussi ceci a 0 pour que sa prenne iptables en compte:
APF_BAN=0
une dernière chose a savoir la meilleur défense et l'attaque dans se genre de situation j'ai déjà gérer plusieurs team avec des kimsufi et se genre de situation mes arriver plusieurs fois j'ai repliquer avec 4 ou 5 machine jusqu'à inonder mon adversaire et j'ai laisser sa tourner jusqu'a 23h et croit moi sa calme :p

Message cité 1 fois
n°64600
elliotdoe
Posté le 10-03-2010 à 05:10:28  profilanswer
 

Comme ça c'est toi qui risque la prison. C'est intelligent.

n°64626
vrobaina
Hecho a Mano
Posté le 10-03-2010 à 15:16:04  profilanswer
 

pour bloquer les attaques de type DDOS, tu peux aussi utiliser le petit logiciel PSAD sous linux.


---------------
Les cons, ça ose tout, et c'est même à ça qu'on les reconnait....
n°64627
elliotdoe
Posté le 10-03-2010 à 15:41:22  profilanswer
 

Si tu te prends un Ddos c'est que tes règles iptables sont mal faites / insuffisantes... Quel type d'attaque Ddos ? Attaques SYN ?

n°64727
zhm
Keski se putain de passe ?
Posté le 12-03-2010 à 17:51:47  profilanswer
 

Attaque SYN oui

n°64755
bardiel
Debian powa !
Posté le 13-03-2010 à 13:19:38  profilanswer
 

nitro-n2o a écrit :

une dernière chose a savoir la meilleur défense et l'attaque dans se genre de situation j'ai déjà gérer plusieurs team avec des kimsufi et se genre de situation mes arriver plusieurs fois j'ai repliquer avec 4 ou 5 machine jusqu'à inonder mon adversaire et j'ai laisser sa tourner jusqu'a 23h et croit moi sa calme :p


oh que c'est intelligent ça :o  
dans le meilleur des cas, si les admins d'OVH qui gèrent les serveurs remarquent ce manège, même pour 1 fois c'est la case rupture de contrat directe avec paiement jusque la fin prévue de location :heink:


---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
n°64765
elliotdoe
Posté le 13-03-2010 à 15:18:14  profilanswer
 

L'attaque SYN c'est un des premiers trucs qu'on bloque en iptables :whistle:
T'as pas mal de trucs sur le net pour t'aider à ajouter les règles qu'il te manque :jap:

Message cité 1 fois
n°64833
reckoner
Posté le 16-03-2010 à 00:21:42  profilanswer
 

elliotdoe a écrit :

L'attaque SYN c'est un des premiers trucs qu'on bloque en iptables :whistle:
T'as pas mal de trucs sur le net pour t'aider à ajouter les règles qu'il te manque :jap:


 
Je demande à voir comment tu bloques si facilement un DDoS en SYN flood avec ton iptables !
 
Parce qu'avec des milliers d'IP source sont générées aléatoirement :
-m limit est dégueu et va bloquer le service pour tout le monde
-m iplimit idem
-m recent bloque en effet les DoS en SYN flood, mais il est ici totalement inutile vu que chaque IP n'envoie qu'un seul SYN...
 
Bref, c'est bien beau de protéger la CPU des serveurs, si le débit est pourri pour tout le monde, ça risque pas de bien marcher non plus... Tu peux faire la démo avec un pc et hping au cul d'une ligne ADSL sans masquerading. Ca semble bidon comme attaque, mais si tu y réfléchis bien : comment faire la différence entre un SYN légitime et un SYN de l'attaquant ? => on peut pas. Donc si on commence à les bloquer/limiter, on impacte tout le monde.
 

efimo a écrit :

Je déterre car ça m'intéresse de savoir si il y a une ou des solutions efficaces, excluant les plus onéreuses.


 
Les DDos en SYN flood sont super bien contrées par le mécanisme de SYN-cookies. Quand il est activé, lorsque ta machine a trop de sessions à ouvrir pendant un laps de temps donné, elle ne stocke plus les sessions TCP dans sa table sur simple réception de paquets SYN, elle ne le fait qu'après avoir échangé le 3 way handshake complet à chaque fois. Ceci est normalement impossible (car il faut au moins se souvenir du numéro de séquence qu'on envoie au client !), mais via une méthode assez élégante, lorsque ce mode est activé les numéros de séquence envoyés dans les SYN/ACK sont générés de manière "intelligente" (et pas trop prévisible !) pour pouvoir les retrouver sans les stocker. Du coup ton serveur ne sature pas quand on lui balance des millions de SYN.
 
Tous les firewalls propriétaires modernes le font, sous Linux tu peux modifier le paramètre :  
 
sysctl -w net.inet.tcp.syncookies=1
 
Tu peux tester ensuite avec un hping et comparer, c'est juste impressionnant :)
 
C'est quand même mieux de le faire sur un firewall dédié, mais bon...

mood
Publicité
Posté le 16-03-2010 à 00:21:42  profilanswer
 

n°64845
elliotdoe
Posté le 16-03-2010 à 09:31:56  profilanswer
 

Je suis pas sûr que limiter le nombre de connexions SYN par user soit si impactant que ça (dépend du type de site bien entendu). Après t'as pas mal de solutions différentes, notamment de la corrélation de logs + triggers pour être informé de l'attaque me semble être le minimum. Pour le technique je suis pas spécialiste en iptables, je vais regarder ton syn-cookie qui a l'air d'être une réponse intéressante à la problématique.

 

C'était surtout pour dire qu'il existait des solutions faciles pour ce genre d'attaques.


Message édité par elliotdoe le 16-03-2010 à 09:32:26
n°64847
dreamer18
CDLM
Posté le 16-03-2010 à 09:35:52  profilanswer
 

le syn cookie c'est le standard contre le syn flood. Je pensais même que c'était implémenté par défaut dans toutes les stack récentes unix/linux.


---------------
"Parceque toi tu fracasses du migrant à la batte de baseball, c'est ça ?" - Backbone-
n°64865
vrobaina
Hecho a Mano
Posté le 16-03-2010 à 11:24:44  profilanswer
 

oui ça l'est.


---------------
Les cons, ça ose tout, et c'est même à ça qu'on les reconnait....
n°64949
zhm
Keski se putain de passe ?
Posté le 17-03-2010 à 14:19:13  profilanswer
 

Ca je sais pas.
 
A l'époque quand j'ai pris cette attaque, j'ai activé le tcp_syncookies sur ma machine OVH, l'attaque faisait toujours autant de dommage. Quand j'ai changé pour une dedibox, quand j'ai activé le tcp_syncookies, bizarrement avec la même attaque mais une machine différente j'ai réussi à stopper l'attaque.
 
Pourtant c'était toutes les 2 des débian 4, après peut-être que c'était un probleme de compilation sur le système OVH, je sais pas trop...


Aller à :
Ajouter une réponse
 

Sujets relatifs
IPTABLES - Règles un peut complexes ...Linux - Probleme Iptables/Masquerade & Interf Réseau Multiples
[Résolu] Iptables + interface graphiqueiptables NAT deux serveurs web
Accés bloque ssh à cause d'iptablesconfiguration iptables pour DMZ
Squid + Iptables (sans redirection)[Resolu][iptables] Filtrage par adresse MAC
Plus de sujets relatifs à : DDoS/Iptables

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.096 secondes

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)