Certains devraient apprendre à lire ... d'autres à réfléchir
ahahah !
Concernant le kernel non à jour, si aucun des 3000 utilisateurs n'a de shell, que les serveurs sont à jours et qu'ancun code externe n'est utilisable, par exemple php avec empoisonnement des logs, un noyau troué ne pose pas de problème...
une grosse partie des attaques se fait par un gain remote shell , le fait de ne pas avoir un shell n empeche en AUCUN CAS de peter une machine . un shell ca peut s obstenir de plusieurs facons ( l exemple de savanah ou security.debian.org est assez frappant ) enfin bon chacun sa conception de la securité.
Concernant, l'uptime de "497+60 jours" c'est bien sur moi qui ai rajouté le 497. C'est bien de savoir que le compteur est remis a zéro après 497, c'est une remarque très intéressante !
mm je vois pourquoi tu me parles de ca mais bon , je preciserais que c est corrigé dans le 2.6 , l "uptime ticker etant codé en 64bits , la limite est du fait du codage en 32bits de l uptime ( mesuré en ms cf /proc/uptime ) dans les kernels 2.4.x , ca peut meme passer a 49.7 jours si on s amuse a changer la valeur Hz a1000 ce qui etait conseillé pour avoir un kernel avec une faible latence .
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Prosper . En réponse au journal info sur la Puissance du serveur nécessaire. Évalué à 1.
ahahah !
Concernant le kernel non à jour, si aucun des 3000 utilisateurs n'a de shell, que les serveurs sont à jours et qu'ancun code externe n'est utilisable, par exemple php avec empoisonnement des logs, un noyau troué ne pose pas de problème...
une grosse partie des attaques se fait par un gain remote shell , le fait de ne pas avoir un shell n empeche en AUCUN CAS de peter une machine . un shell ca peut s obstenir de plusieurs facons ( l exemple de savanah ou security.debian.org est assez frappant ) enfin bon chacun sa conception de la securité.
Concernant, l'uptime de "497+60 jours" c'est bien sur moi qui ai rajouté le 497. C'est bien de savoir que le compteur est remis a zéro après 497, c'est une remarque très intéressante !
mm je vois pourquoi tu me parles de ca mais bon , je preciserais que c est corrigé dans le 2.6 , l "uptime ticker etant codé en 64bits , la limite est du fait du codage en 32bits de l uptime ( mesuré en ms cf /proc/uptime ) dans les kernels 2.4.x , ca peut meme passer a 49.7 jours si on s amuse a changer la valeur Hz a1000 ce qui etait conseillé pour avoir un kernel avec une faible latence .