En général, une attaque de déni de service (distribuée) ne vous fournira pas beaucoup d'informations directement. Cependant, il existe quelques scénarios dans lesquels des informations pourraient être glanées à la suite d'un DoS. Voici quelques exemples, mais ce n'est pas du tout exhaustif:

• Un équilibreur de charge peut divulguer des informations de sous-réseau interne ou divulguer des noms de machine internes dans des situations où les systèmes de sauvegarde sont hors ligne.
• Un DoS qui arrête d'abord la base de données peut amener une application à révéler le type de moteur de base de données, le nom d'utilisateur de connexion ou l'adresse IP interne via un message d'erreur.
• Une API mal implémentée peut entraîner un "échec -open "scénario - DoS'ing un serveur Single Sign On peut donner à un attaquant la possibilité de se connecter non authentifié, ou avec des informations d'identification locales.
• Dans les scénarios Advanced Persistent Threat, l'infrastructure de détection DoS peut autoriser un attaquant de ne pas être détecté pendant les autres étapes de collecte d'informations.
• De même, la gestion par DoS de l'interface d'administration d'un pare-feu pourrait entraver les efforts de réponse aux incidents de l'administration réseau.
• Dans un cas extrême, DoS contre un service de révocation de clé pourrait permettre à un attaquant de continuer à utiliser révoqué ou connu - informations d'identification compromises.

D'autres motifs d'une attaque par déni de service deviennent apparents si vous considérez les utilisateurs d'un système comme des cibles en plus du système lui-même: Une attaque par déni de service contre un site Web qui vend des billets de concert peut permettre à un attaquant d'acheter des billets pour un événement qui, autrement, se seraient vendus en quelques minutes. Un DoS contre un système de contrôle de version pourrait empêcher une société de développement de livrer un logiciel à temps. Un DoS contre un site de média social pourrait rendre la coordination des manifestations politiques plus difficile, voire impossible.

En général, les attaques DoS sont uniquement conçues pour provoquer (comme leur nom l'indique) un déni de service, c'est-à-dire une compromission de la disponibilité du service.

Autres formes de DoS, par exemple déclenchant un déréférencement de pointeur nul, peut être utilisé pour compromettre l'intégrité en plantant un service sans qu'il ait le temps de fermer proprement les fichiers, entraînant une corruption des données (perte d'intégrité). Les bases de données sont une cible évidente pour ce genre de choses.

Les pare-feu et autres services de sécurité devraient échouer fermés s'ils sont effectivement DoS. Je ne suis au courant d'aucun cas où quelque chose comme ça échouerait. Cependant, je pourrais prévoir un scénario où un serveur derrière un équilibreur de charge tombe à une attaque DoS, donc l'équilibreur de charge passe à un système secondaire, qui est configuré de manière plus faible, révélant ainsi cette vulnérabilité en externe.

En dehors de la triade CIA, vous constaterez peut-être que les attaques DoS sont utilisées pour détourner l'attention et les ressources en personnel d'une attaque plus subtile.

Oui, l'attaque DoS peut être utile à un attaquant.

(Au fait, il ne s'agit pas d'une attaque uniquement contre les services Web. Elle peut être dirigée contre n'importe quel périphérique réseau).

Le but de DoSing un appareil dans de tels cas est de le faire répondre plus lentement ou plus tard qu'il ne le ferait normalement. Du haut de ma tête, je vois:

• Empoisonnement du cache DNS (attaque de Kaminsky) - Cela dépend de la capacité de l'attaquant à fournir une réponse DNS plus tôt que le serveur DNS faisant autorité, ce qui pourrait être accompli par Faire le serveur faisant autorité.
• L'attaque d'insertion Quantum de la NSA repose sur une réponse plus tôt que le serveur légitime
• L'usurpation d'adresse TCP / IP est également facilitée en ralentissant la réponse légitime
• Les serveurs OCSP (état des certificats) sont tellement peu fiables et surchargés que certains navigateurs Web ne les vérifient pas par défaut, ouvrant la voie à de fausses attaques de certificats

Dans un autre ordre d'idées, les serveurs DoSing clearnet ( par exemple par un DOS classique, ou simplement en coupant l'accès au réseau) pourrait être utilisé pour vérifier l'identité du service caché de Tor - par exemple il aurait pu être utilisé pour localiser le serveur de Silk Road.

Dans la même veine, les nazis pendant la Seconde Guerre mondiale ont utilisé une sorte de DoS (couper l'électricité dans les quartiers et les rues de la ville) pendant la résistance les transitions des radios pour connaître leur emplacement.

Une attaque DoS (abréviation de «déni de service») est une forme d'attaque utilisée sur les services Web qui vise à «planter» le service. *

Pas exactement . Comme son nom l'indique, le but est de rendre le service indisponible pour les utilisateurs légitimes. La manière la plus courante de procéder pour un service Internet tel qu'un serveur Web est de saturer les connexions afin que personne d'autre ne puisse se connecter. Cela peut être fait par ex. via un flux SYN.

Modifier: comme @RoryAlsop l'a commenté, un attaquant pourrait également essayer de planter le service afin de le rendre complètement hors ligne.

Serait-il possible d'obtenir des données du service avec une attaque DoS? Si oui, comment?

Non, c'est un type d'attaque complètement différent - qui, cependant, pourrait être mené en conjonction avec un DoS, ce dernier ayant pour but de saturer les ressources de un appareil lié à la sécurité, par exemple un IDS, un pare-feu ou même un enregistreur.

Un résultat d'une attaque DoS qui, je pense, n'a été mentionné dans aucune des autres réponses, est la possibilité qu'une action particulière puisse entraîner le stockage de données, même s'il ne s'agit que d'octets. Par exemple, si la visite d'une URL particulière peut enregistrer quelque chose dans un fichier, le but de l'attaquant pourrait être de remplir le disque dur.

Cela pourrait créer des ravages pour libérer l'espace disque, en particulier si les données sont créées dans des fichiers séparés, avec éventuellement des noms aléatoires, ou si les données sont ajoutées à une base de données avec des données légitimes.

Bien qu'un DoS ne puisse normalement pas être utilisé pour causer des dommages autres que simplement mettre le serveur hors ligne, dans certaines circonstances (le plus souvent en raison de systèmes mal configurés), ils peuvent entraîner de graves conséquences, telles que des fuites de données.

Un exemple célèbre est la fuite d'informations sur le site Web de la loi ACS. Le serveur mal configuré, lorsqu'il est redémarré après la fin de l'attaque DoS, a perdu ses paramètres d'origine et a permis à sa racine de répertoire d'être visible publiquement.

«Leur site est revenu en ligne [après l'attaque DDoS] - et sur leur page d'accueil se trouvait accidentellement un fichier de sauvegarde de l'ensemble du site (liste par défaut du répertoire, leur site était vide), y compris les e-mails et mots de passe », a déclaré un chef du groupe attaquant à TorrentFreak. "L'e-mail contient des mots de passe de facturation et des informations indiquant qu'ACS: Law a des problèmes financiers."

Cela a ensuite entraîné de graves répercussions financières et de réputation pour ACS Law.

Je pense à des gains non techniques pour l'attaquant:

• Extraction d'une rançon du service attaqué pour arrêter l'attaque DoS
• Attirer l'attention du public pour une cause politique (le groupe anonyme a utilisé des attaques DoS dans le passé de cette manière)
• Obtenir un avantage commercial en faisant tomber le site Web du concurrent (un attaquant peut proposer cela comme un service illégal)

La plupart des réponses ici mentionnent les effets secondaires des attaques DOS. Cependant, je pense qu'il y a aussi l'option inverse possible: que l'attaque DOS n'est pas la cause des effets secondaires, mais plutôt elle-même un effet secondaire d'une autre attaque. Par exemple, une attaque DOS peut être un effet secondaire d'une force brute de botnet énumérant les adresses e-mail via un écran de mot de passe oublié, ralentissant le service ou même le plantant.

Le motif de cette forme de l'attaque n'est pas de détruire le système, mais plutôt d'obtenir une liste d'utilisateurs du service, où la méthode utilisée pour obtenir la liste des utilisateurs a pour effet secondaire de détruire le système.

Habituellement, mais pas nécessairement. Tout dépend de ce qui se passe ensuite lorsque le service prévu échoue en raison de l'attaque. Imaginons que l'attaque ait pour effet de surcharger l'authentification de l'utilisateur pour un site, et que l'effet de l'échec soit d'autoriser le service au lieu de le refuser. Probablement pas le comportement prévu, facilement un comportement qui pourrait être manqué lors des tests normaux.