Vous rencontrez une attaque par déni de service. Si vous voyez du trafic provenant de plusieurs réseaux (différentes adresses IP sur différents sous-réseaux), vous obtenez un déni de service distribué (DDoS); si tout vient du même endroit, vous avez un vieux DoS. Il peut être utile de vérifier si vous le pouvez. Utilisez netstat pour vérifier. Cela pourrait être difficile à faire, cependant.
Le déni de service est généralement divisé en deux catégories: basé sur le trafic et basé sur la charge. Le dernier élément (avec le service qui tombe en panne) est un déni de service basé sur l'exploit et est très différent.
Si vous essayez d'identifier le type d'attaque en cours, vous souhaiterez peut-être capturer du trafic (à l'aide de wireshark, de tcpdump ou de libpcap). Vous devriez, si possible, mais vous devez aussi savoir que vous allez capturer beaucoup de trafic.
Bien souvent, ils proviendront de réseaux de zombies (réseaux d’hôtes compromis contrôlés par un attaquant dont ils feront les enchères). C’est un bon moyen pour l’attaquant d’acquérir (à moindre coût) la bande passante amont de nombreux hôtes différents sur des réseaux différents pour vous attaquer, tout en couvrant leurs traces. Le Cannon Ion Basse Orbite est un exemple de botnet (bien qu’il soit volontaire au lieu d’un logiciel malveillant); Zeus est plus typique.
Basé sur le trafic
Si vous utilisez un système DoS basé sur le trafic, vous constatez que votre serveur reçoit tellement de trafic que sa connexion à Internet est complètement saturée. Il y a un taux de perte de paquets élevé lorsque vous envoyez une commande ping à votre serveur depuis un autre lieu (et, en fonction des méthodes de routage utilisées), vous constatez parfois une latence très élevée (la commande ping est élevée). Ce type d'attaque est généralement un DDoS.
Bien que cette attaque soit vraiment "forte" et que ce qui se passe réellement soit évidente, il est difficile pour un administrateur de serveur d'atténuer ses effets (et, en gros, impossible pour un utilisateur d'hébergement mutualisé d'atténuer ses effets). Vous allez avoir besoin de l'aide de votre FAI; faites-leur savoir que vous êtes sous un DDoS et qu'ils pourront peut-être vous aider.
Cependant, la plupart des FAI et des fournisseurs de services de transit réaliseront de manière proactive ce qui se passe et publieront un itinéraire de trou noir pour votre serveur. Cela signifie qu'ils publient une route vers votre serveur avec le moins de frais possible, via 0.0.0.0: ils rendent le trafic vers votre serveur ne peut plus être routé sur Internet. Ces itinéraires sont typiquement / 32s et finalement ils sont supprimés. Cela ne vous aide pas du tout. le but est de protéger le réseau du FAI du déluge. Pendant toute cette période, votre serveur perdra effectivement l'accès à Internet.
La seule façon dont votre FAI (ou vous-même, si vous avez votre propre AS) est en mesure de vous aider, s’ils utilisent des adaptateurs de trafic intelligents capables de détecter et de limiter le trafic probable par DDoS. Tout le monde n'a pas cette technologie. Toutefois, si le trafic provient d'un ou deux réseaux, ou d'un hôte, ils peuvent également être en mesure de bloquer le trafic qui vous précède.
En bref, vous ne pouvez rien faire contre ce problème. La meilleure solution à long terme consiste à héberger vos services dans de nombreux endroits sur Internet, qui doivent être DDoSed individuellement et simultanément, ce qui rend le traitement DDoS beaucoup plus coûteux. Les stratégies à cet égard dépendent du service que vous devez protéger. Le DNS peut être protégé avec plusieurs serveurs de noms faisant autorité, SMTP avec des enregistrements MX de sauvegarde et des échangeurs de courrier, et HTTP avec un DNS alternatif ou le multi-hébergement (mais une dégradation peut néanmoins être perceptible pour la durée).
Les équilibreurs de charge sont rarement une solution efficace à ce problème, car l'équilibreur de charge est lui-même soumis au même problème et crée simplement un goulot d'étranglement. IPTables ou d'autres règles de pare-feu ne vous aideront pas, car le problème est que votre canal est saturé. Une fois que les connexions sont vues par votre pare-feu, il est déjà trop tard . la bande passante de votre site a été consommée. Peu importe ce que vous faites avec les connexions; l'attaque est atténuée ou terminée lorsque la quantité de trafic entrant redevient normale.
Si vous le pouvez, envisagez d’utiliser un réseau de distribution de contenu (CDN) tel que Akamai, Limelight et CDN77, ou utilisez un service de nettoyage DDoS tel que CloudFlare ou Prolexic. Ces services prennent des mesures actives pour atténuer ces types d’attaques et disposent d’une bande passante tellement large dans des endroits si divers qu’il n’est généralement pas envisageable de les inonder.
Si vous décidez d'utiliser CloudFlare (ou tout autre CDN / proxy), n'oubliez pas de masquer l'adresse IP de votre serveur. Si un attaquant découvre l'adresse IP, il peut à nouveau DDoS directement sur votre serveur, en contournant CloudFlare. Pour masquer l'adresse IP, votre serveur ne doit jamais communiquer directement avec d'autres serveurs / utilisateurs, à moins qu'ils ne soient en sécurité. Par exemple, votre serveur ne doit pas envoyer de courrier électronique directement aux utilisateurs. Cela ne s'applique pas si vous hébergez tout votre contenu sur le CDN et que vous n'avez pas de serveur vous-même.
En outre, certains fournisseurs de services VPS et d’hébergement atténuent mieux ces attaques que d’autres. En général, plus ils sont grands, mieux ils seront. un fournisseur très homogène et disposant de beaucoup de bande passante sera naturellement plus résilient, et un autre doté d’une équipe d’exploitation réseau active et disposant de tout le personnel nécessaire pourra réagir plus rapidement.
Basé sur la charge
Lorsque vous rencontrez un DDoS basé sur la charge, vous remarquez que la moyenne de charge est anormalement élevée (ou l'utilisation du processeur, de la mémoire vive ou du disque, en fonction de votre plate-forme et de ses spécificités). Bien que le serveur ne semble rien faire d’utile, il est très occupé. Souvent, les journaux contiennent de nombreuses entrées indiquant des conditions inhabituelles. Le plus souvent, cela provient de nombreux endroits et est un DDoS, mais ce n'est pas nécessairement le cas. Il ne doit même pas y avoir beaucoup d'hôtes différents .
Cette attaque est basée sur l’obligation faite à votre service de faire beaucoup de choses coûteuses. Cela peut être quelque chose comme ouvrir un nombre gigantesque de connexions TCP et vous obliger à conserver leur état, ou télécharger des fichiers excessivement volumineux ou nombreux sur votre service, ou peut-être faire des recherches vraiment coûteuses, ou vraiment tout ce qui est coûteux à gérer. Le trafic est dans les limites de ce que vous aviez prévu et pouvez assumer, mais les types de demandes effectuées sont trop coûteux pour être traités en si grand nombre .
Premièrement, le fait que ce type d’attaque soit possible indique souvent un problème de configuration ou un bogue.à votre service. Par exemple, vous pouvez activer la journalisation trop détaillée et stocker des journaux sur quelque chose de très lent à écrire. Si quelqu'un s'en rend compte et fait beaucoup de choses qui vous amènent à écrire de nombreuses quantités de journaux sur le disque, votre serveur ralentira jusqu'à une analyse. Votre logiciel peut également faire quelque chose d'extrêmement inefficace pour certains cas d'entrée; les causes sont aussi nombreuses qu'il y a de programmes, mais deux exemples sont une situation dans laquelle votre service ne ferme pas une session qui est autrement terminée et une situation dans laquelle il engendre un processus enfant et le laisse. Si vous vous retrouvez avec des dizaines de milliers de connexions ouvertes avec l'état à suivre, ou des dizaines de milliers de processus enfants, vous rencontrerez des problèmes.
La première chose à faire est d' utiliser un pare-feu pour supprimer le trafic . Ce n'est pas toujours possible, mais s'il y a une caractéristique que vous pouvez trouver dans le trafic entrant (tcpdump peut être intéressant pour cela si le trafic est léger), vous pouvez le laisser tomber au niveau du pare-feu et cela ne causera plus de problèmes. L'autre chose à faire est de résoudre le problème de votre service (contactez le fournisseur et préparez-vous à une longue expérience de support).
Cependant, s'il s'agit d'un problème de configuration, commencez par là . Réduisez la journalisation sur les systèmes de production à un niveau raisonnable (selon le programme, il s'agit généralement de la configuration par défaut. Vous devrez donc vous assurer que les niveaux de journalisation "débogage" et "détaillé" sont désactivés. Si tout ce que l'utilisateur fait est journalisé exactement et détail, votre enregistrement est trop prolixe). En outre, vérifiez les limites du processus enfant et des demandes , éventuellement, étranglez les demandes entrantes, les connexions par IP et le nombre de processus enfants autorisés, le cas échéant.
Il va sans dire que plus votre serveur est configuré et mis en service, plus ce type d'attaque sera difficile. Évitez d'être radin avec la RAM et le processeur en particulier. Assurez-vous que vos connexions à des éléments tels que les bases de données principales et le stockage sur disque sont rapides et fiables.
Basé sur les exploits
Si votre service plante mystérieusement très rapidement après avoir été activé, en particulier si vous pouvez établir un modèle de demandes qui précède le blocage et si la demande est atypique ou ne correspond pas aux modèles d'utilisation prévus, vous rencontrez peut-être un déni de service basé sur un exploit. Cela peut venir d'un seul hôte (avec pratiquement n'importe quel type de connexion Internet) ou de nombreux hôtes.
Cela ressemble à un DoS basé sur la charge à bien des égards, et a fondamentalement les mêmes causes et atténuations. La différence est simplement que dans ce cas, le bogue ne cause pas le gaspillage à votre serveur, mais la mort. L'attaquant exploite généralement une vulnérabilité d'incident à distance, telle qu'une entrée tronquée qui provoque une déréférence null ou quelque chose de votre service.
Manipulez-le de la même manière qu'une attaque par accès distant non autorisée. Pare-feu contre les hôtes d'origine et le type de trafic s'ils peuvent être épinglés. Utilisez des proxy inversés de validation, le cas échéant. Rassemblez des preuves médico-légales (essayez de capturer une partie du trafic), déposez un ticket de bogue auprès du vendeur et envisagez de déposer une plainte pour abus (ou plainte légale) contre l'origine également.
Ces attaques sont relativement peu coûteuses à monter, si un exploit peut être trouvé, et elles peuvent être très puissantes, mais aussi relativement faciles à localiser et à arrêter. Cependant, les techniques utiles contre les attaques DDoS basées sur le trafic sont généralement inutiles contre les attaques DoS basées sur les exploitations.