DDoS/Iptables
DDoS/Iptables - Sécurité - Systèmes & Réseaux Pro
Marsh Posté le 11-02-2010 à 18:05:34
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 
Marsh Posté le 10-03-2010 à 05:10:28
Comme ça c'est toi qui risque la prison. C'est intelligent.
Marsh Posté le 10-03-2010 à 15:16:04
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....
Marsh Posté le 10-03-2010 à 15:41:22
Si tu te prends un Ddos c'est que tes règles iptables sont mal faites / insuffisantes... Quel type d'attaque Ddos ? Attaques SYN ?
Marsh Posté le 13-03-2010 à 13:19:38
| 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 |
oh que c'est intelligent ça 
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 
---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
Marsh Posté le 13-03-2010 à 15:18:14
L'attaque SYN c'est un des premiers trucs qu'on bloque en iptables 
T'as pas mal de trucs sur le net pour t'aider à ajouter les règles qu'il te manque 
Marsh Posté le 16-03-2010 à 00:21:42
| elliotdoe a écrit : L'attaque SYN c'est un des premiers trucs qu'on bloque en iptables |
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...
Marsh Posté le 16-03-2010 à 09:31:56
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
Marsh Posté le 16-03-2010 à 09:35:52
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-
Marsh Posté le 16-03-2010 à 11:24:44
oui ça l'est.
---------------
Les cons, ça ose tout, et c'est même à ça qu'on les reconnait....
Marsh Posté le 17-03-2010 à 14:19:13
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...
Sujets relatifs:
- IPTABLES - Règles un peut complexes ...
- Linux - Probleme Iptables/Masquerade & Interf Réseau Multiples
- [Résolu] Iptables + interface graphique
- iptables NAT deux serveurs web
- Accés bloque ssh à cause d'iptables
- configuration iptables pour DMZ
- Squid + Iptables (sans redirection)[Resolu]
- [iptables] Filtrage par adresse MAC
Marsh Posté le 26-10-2008 à 06:21:04
Salut. Un pote se fait DDoS sur son dédié kimsufi OVH. J'aimerais l'aider à stopper l'attaquer.
monitoring iptraf :
un peu de log iptraf :
mon iptables :
#!/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