1 votes

Plusieurs attaques DDOS par jour

Je gère un site web technologique populaire et depuis des semaines, mon site subit des attaques DDOS. Les attaques se produisent à des moments aléatoires, et souvent environ 10 fois par jour. En général, les attaques ne durent que quelques minutes, puis s'arrêtent.

Lorsque mon site est attaqué, il devient inaccessible. La charge du serveur n'augmente pas, les services comme MySQL, Nginx et FPM ne sont pas affectés. Il semble qu'il s'agisse d'une attaque SYN ou de quelque chose de similaire.

Je travaille sous CentOS 5.6 (64bit), sur une machine puissante. J'ai déjà essayé de durcir un peu SYSCTL, mes réglages se trouvent ci-dessous. J'ai également configuré iptables pour bloquer tous les ports à l'exception de ceux dont j'ai besoin. Ce script se trouve également ci-dessous.

Je sais que cette question a déjà été posée à de nombreuses reprises, mais y a-t-il d'autres conseils à me donner pour lutter contre ces attaques ? Cela devient vraiment très ennuyeux.

Je suis prêt à tout essayer.

PARAMÈTRES SYSCTL

net.ipv4.ip_forward                         = 0
net.ipv4.conf.default.rp_filter             = 1
net.ipv4.conf.default.accept_source_route   = 0
kernel.sysrq                                = 1
kernel.core_uses_pid                        = 1
net.ipv4.tcp_syncookies                     = 1
kernel.msgmnb                               = 65536
kernel.msgmax                               = 65536
kernel.shmmax                               = 68719476736
kernel.shmall                               = 4294967296
net.ipv4.conf.all.send_redirects            = 0
net.ipv4.conf.default.send_redirects        = 0
net.ipv4.tcp_max_syn_backlog                = 2048
net.ipv4.icmp_echo_ignore_broadcasts        = 1
net.ipv4.conf.all.accept_source_route       = 0
net.ipv4.conf.all.accept_redirects          = 0
net.ipv4.conf.all.secure_redirects          = 0
net.ipv4.conf.all.log_martians              = 1
net.ipv4.conf.default.accept_redirects      = 0
net.ipv4.conf.default.secure_redirects      = 0
net.ipv4.icmp_echo_ignore_broadcasts        = 1
net.ipv4.icmp_ignore_bogus_error_responses  = 1
net.ipv4.conf.default.rp_filter             = 1
net.ipv4.tcp_timestamps                     = 0
net.ipv4.conf.all.rp_filter                 = 1
net.ipv4.conf.default.rp_filter             = 1
net.ipv4.conf.eth0.rp_filter                = 1
net.ipv4.conf.lo.rp_filter                  = 1

PARAMÈTRES D'IPTABLES

*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT
-A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT
-A INPUT -p tcp --dport 22 --syn -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT

Graphique MRTG des dernières 24h. Les pics correspondent à des attaques, et c'est à ce moment-là que le serveur devient inaccessible.

MRTG Graph

2voto

Ryan Sampson Points 2898

"Il semble qu'il s'agisse d'une attaque du SYN" - sur quelles preuves vous basez-vous pour affirmer cela ? Est-ce que votre table conntrack se remplit, ou avez-vous un nombre ridicule d'entrées incomplètes dans votre sortie netstat ? Étant donné que les cookies SYN sont généralement assez efficaces, je serais plus enclin à penser qu'il s'agit d'une simple attaque par remplissage de tuyaux, pour laquelle la seule solution est d'obtenir un tuyau plus grand, de demander à votre fournisseur de bloquer le trafic abusif en amont (s'il s'agit d'un trafic simple comme une attaque par réflexion DNS) ou d'obtenir un service de nettoyage de tuyaux (s'il s'agit d'un trafic plus compliqué), soit de votre fournisseur en amont, soit d'un tiers comme Arbor networks -- parce que le pare-feu sur votre machine est du mauvais côté de la connexion réseau contrainte.

Sur la base des informations supplémentaires concernant la nature du graphique, je pense qu'il est assez probable que vous soyez simplement inondé de trafic ("pipe-filling") - les graphiques de comptabilisation du trafic fournis par votre fournisseur devraient pouvoir le confirmer, en montrant que votre taux de trafic se stabilise au niveau de la capacité de liaison que vous payez auprès de votre fournisseur.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X