> Donc à la base cela reste un problème de stabilité.
Dans la sécurité il y a un attaquant et un attaqué. Tout ce qui permet à l'attaquant de nuire à l'attaqué est une faille de sécurité. Les DoS en font parti.
Notons bien que l'attaquant n'est pas "sous-contrôle". Ce n'est pas un utilisateur de confience.
Que la faille soit exploitable (par l'attaquand et non l'utilisateur) ou non en fonction du problème est une autre histoire.
Mais si la faille est exploitable, ta seule solution est de corriger le problème.
Pour la fiabilité, c'est une autre histoire. Il n'y a pas d'attaquant, il n'y a pas de personne qui veut nuire et qui n'est pas "sous-contrôle", etc.
Si l'admin en jouant à tuxracer fait planter le serveur, il y a un correctif simple à ce problème => engueuler l'admin pour qu'il ne recommence pas. En général ça marche très bien. Par contre, engueuler les attaquants pour qu'il ne recommence pas, marche très très très mal.
Si la sécurité n'est pas de tes préocupations, ben classe les DoS comme un problème de fiabilité. Mais tu vas vite voir qu'il y a une différence entre un admin qui n'est pas content de ne plus pourvoir jouer à tuxracer durant ses heures perdues et des clients qui ne peuvent plus utiliser un service que tu leur as vendu ou ton serveur qui enregistre les payements qui ne marche plus. D'un le premier cas, t'as un mécontent, dans le second ton business est en jeu. T'es dans l'insécurité. Que cette insécurité vienne d'un système peu solide est accessoire. C'est avant un problème de sécurité.
> Ton serveur aurait très bien pu planter dans les même condition avec un client plein de bonne volonté, mais ayant juste un comportement bogué ou légèrement différent des autres.
La sécurité ce n'est pas l'art de chercher des arguments pour croire qu'on est en sécurité. C'est souvent l'inverse. Si un client plein de bonne volonté l'a fait, un cracker peut le faire. C'est donc un problème de sécurité. La sécurité doit se faire si possible avant que tout soit cassé. Pas après. Il ne faut pas attendre que tout soit cassé pour agir.
[^] # Re: SIGTROLL
Posté par IsNotGood . En réponse au journal Évaluation des risques de RHEL 4. Évalué à 1.
Dans la sécurité il y a un attaquant et un attaqué. Tout ce qui permet à l'attaquant de nuire à l'attaqué est une faille de sécurité. Les DoS en font parti.
Notons bien que l'attaquant n'est pas "sous-contrôle". Ce n'est pas un utilisateur de confience.
Que la faille soit exploitable (par l'attaquand et non l'utilisateur) ou non en fonction du problème est une autre histoire.
Mais si la faille est exploitable, ta seule solution est de corriger le problème.
Pour la fiabilité, c'est une autre histoire. Il n'y a pas d'attaquant, il n'y a pas de personne qui veut nuire et qui n'est pas "sous-contrôle", etc.
Si l'admin en jouant à tuxracer fait planter le serveur, il y a un correctif simple à ce problème => engueuler l'admin pour qu'il ne recommence pas. En général ça marche très bien. Par contre, engueuler les attaquants pour qu'il ne recommence pas, marche très très très mal.
Si la sécurité n'est pas de tes préocupations, ben classe les DoS comme un problème de fiabilité. Mais tu vas vite voir qu'il y a une différence entre un admin qui n'est pas content de ne plus pourvoir jouer à tuxracer durant ses heures perdues et des clients qui ne peuvent plus utiliser un service que tu leur as vendu ou ton serveur qui enregistre les payements qui ne marche plus. D'un le premier cas, t'as un mécontent, dans le second ton business est en jeu. T'es dans l'insécurité. Que cette insécurité vienne d'un système peu solide est accessoire. C'est avant un problème de sécurité.
> Ton serveur aurait très bien pu planter dans les même condition avec un client plein de bonne volonté, mais ayant juste un comportement bogué ou légèrement différent des autres.
La sécurité ce n'est pas l'art de chercher des arguments pour croire qu'on est en sécurité. C'est souvent l'inverse. Si un client plein de bonne volonté l'a fait, un cracker peut le faire. C'est donc un problème de sécurité. La sécurité doit se faire si possible avant que tout soit cassé. Pas après. Il ne faut pas attendre que tout soit cassé pour agir.