Bonjour,
sous réserve, je pense qu’il y a 2 pbs s’appuyant sur les messages:
le 31/12 maintenant tout le monde envoie des "smesses"
les valeurs limites sont rapidement atteint,
un autre exemple le concours de Miss Picardie avec le Théleton,
cela fait du monde à gérer (rôle de l’IN)
A+
JB1
La remarque est pertinente, mais elle doit être modérée.
- Une machine n’attend pas que des paquets sur des ports ouverts en écoute par ses services. Il y a aussi tous les paquets de réponse attendus par les connexions sortantes (même un serveur en fait aussi), sur des ports par définition aléatoires.
- Si j’étais un attaquant, je ciblerais mon DoS sur des ports ouverts du serveur. Ainsi je cumulerai l’impact global sur conntrack et l’impact sur les services utilisant ces ports.
- Une nouvelle entrée de conntrack est détruite si le paquet qui l’a créée est bloqué. Il faudrait vérifier si sa création et sa suppression font intervenir le verrou dont il est question ou s’il n’intervient que lorsque l’entrée est confirmée. Dans le cas contraire, la pénalité serait moindre.
Ce ne sont pas forcément les même personnes qui font l’un et l’autre.
Si tu met de l’intelligence en plus en entrée de ton service, alors cette intelligence demandera plus de ressources et pourra elle-même être victime d’un DOS. C’est ce qui est fait actuellement avec les firewall.
Pascal tu pourra me dire si je me plante, mais je présume que pour faire de la répartition de charge avec netfilter, il faut utiliser conntrack (pour qu’un client accède toujours au même serveur). Si conntrack est utilisé ainsi, c’est normal d’avoir une machine qui fait office de répartititeur de charge et qui puisse se faire attaquer par un deny de conntrack avant que les services qui sont derrière soient inquiétés.
Si la répartition se fait à l’aide de NAT “à état” (ex: DNAT), alors oui puisque ce type de NAT a besoin du suivi de connexion.
Sachant tout de même que les méthodes les plus courantes que je rencontres sont les DDOS en UDP sur le port 53, le DNS ‘posionning’ et le DNS ‘spoofing’.
Ce type d’attaque ne réclamant pas autant de ressources qu’un DDOS ‘classique’ sur un port 80, 443, 3306 par exemple.
Il arrive très souvent malgré tout de voir de petites attaques DDOS dite classique attaqué des plateforme protéger (ou croyant être protégé) par un firewall ne plus répondent car la bande passante allouée est entièrement consommé, par exemple votre plateforme est sur un lien 100Mbit/s croyais le ou non mais la location pour une paire d’heure d’un botnet ayant assez de ressources pour rendre indisponible votre plateforme n’est pas si inaccessible que ça 
Idem imaginé qu’une plateforme soit visée chez un hébergeur, le temps que l’attaque soit mitigée il est très fortement possible qu’il y est un impact sur tous les client qui partagerai une partie de l’équipement réseau (les pauvres hubs et switchs en amont 
).
En générale les protections anti-ddos, commence par diviser les flux entrants afin de pouvoir les analysé et tenter au maximum de mitigé l’attaque afin de permette à la plateforme visée de répondre par fois lentement mais de pouvoir continuer à répondre.
Malgré tout le point limite est la consommation de bande passante et l’épuissement des dits verrous.
Pour ceux qui ne l’auraient pas compris la première cible de ce genre d’amélioration dans le kernel n’est clairement pas madame Michu (n’en déplaisent à certains) mais bel et bien le mode de l’entreprise.
Les routeurs et les firewalls sur lesquels je me connecte souvent m’offrent un shell 
et si vous chercher des exemples pratique pour cette amélioration regarder du côté de Sophos, Vyatta par exemple qui se retrouvent souvent dans l’industrie de l’hébergement et tourne sur du kernel Linux.
Les Routeurs professionnels des hébergeur vous pensé qu’il utilise quoi comme OS ?