Reprise du message précédent :

J'ai vu des clients, souvent après de gros hacks, blinder leur infra Windows, ou du moins être habitués à patcher régulièrement les serveurs correspondants. Côté Linux/Unix, rien. Ensuite mon expérience est forcément limitée, mais ça s'est vérifié dans tous types de boîtes.

 
Pareil chez nous.
 
A chaque audit sécu, j'étais "vert" partout (responsabilité/infra windows), par contre sur l'infra linux c'était toujours dans le rouge. Leur crédo c'etait "tant que ça marche, on touche pas"..

Non, mais pas dans ce sens là
Dans le sens : "pourquoi vouloir régulièrement rebooter ton serveur, et surtout, pourquoi relier ça au patching de sécurité ?".

 
Parceque c'est bien beau de patcher le noyau en live sans avoir besoin de redémarrer pour appliquer le patch, mais ne pas redémarrer après l’application de gros patch, c'est ne pas pouvoir garantir l'incidence de ton patch et comme je disais plus haut pouvoir garantir que ton système est bêtement capable de rebooter après le changement que tu lui as apporté.
 
C'est pas directement lié à la sécurité, mais à les gestion des changements sur tes serveurs.
 
Si tu fais trois ans de patchs live et que le premier reboot forcé ensuite ne marche pas, tu ne sauras pas où piocher et tu devras peut-être restaurer un backup d'il y a trois ans pour que ça redémarre...

Parceque tu patch en prod sans avoir validé avant que ça marche et que ça tiendra la durée ?

Bah vous êtes dans/connaissez des boîtes qui ont pas les personnes avec des compétences Linux (qui sont en France plus dures à trouver que des « admins » Windows).

Une infra Linux pas standardisée/industrialisée aujourd'hui c'est has been, les bonnes pratiques c'est des suivi de confs (via gestionnaires de Conf) et maintenues sous Git en prime, des shells distribués et des valid' dev/qualif/prod

Je fais plus souvent des confs à l'étranger, mais même en France je trouve que c'est pas mal du tout dans les boîtes dont je connais un peu l'état de l'infra (mettons une 50 aine)

 
Valider un environnement de test n’empêche pas de valider l'environnement de prod. Quand on valide un environnement de test, ça donne juste l'autorisation d’appliquer en prod, ça ne te permet pas de bypasser la validation sur la prod.
 
Mais bon, tu fais ce que tu veux ...

Si ta des environnements à 100% reproductibles en qualif (genre du Docker ou des VMs avec gestion de conf auto), je vois pas l'intérêt de faire des tests manuels en prod. Faut automatiser, ta recette marche, et zou

Et dans tests ça passe aussi par des tests de montée en charge si nécessaire, coupure de nœuds random pour tester la HA de ton app etc.

edit : d'ailleurs pour une app sympa j'ai déjà pu voir de la prod avec des coupures volontaires et au hasard de certains nœuds . En prod Là dans ces conditions, pas de surprises, jamais

Ce que tu appel "la validation sur la prod", c'est quoi exactement ?  
Vérifier que ton patch est bien passé ? Ok. Vérifier que ton patch empêche pas le système de rebooter ? Et tu fait ça sur tout ? Hyperviseurs, filers, ... ? (vrais questions )
T'a un plan de tests complets qui vérifie toutes les fonctionnalités de toutes tes applis/systèmes à chaque patch (test unitaires système ) Ou juste 2/3 trucs au pif ?

Erreur typique : activer les maj automatiques sur un serveur avec une partition /boot séparée mal dimensionnée. Les maj de kernel se font petit à petit jusqu'au jour où le /boot est full, les dernières maj du kernel passent pas, etat inconsistant... Tout continue de marcher jusqu'au reboot suivant avec un beau VFS Sync Error, Kernel Panic

1. Jamais de maj auto sur un serveur
2. Bien dimensionner le /boot si séparé
3. Toujours redémarrer après des maj pour appliquer les modifs kernel + test du reboot
4. Virer les vieilles versions de kernel après validation (Pas plus de 2 versions en arrière)

Ah les erreurs qu'on fait quand on débute

Je vois deux erreurs typiques là
 Celle que tu cite et l'absence de supervision de remplissage des partition

 
Tu sais que ça peut s'automatiser tout ça hein (et faire les MAJ de sécu auto c'est pas un mal)
 
Et pas d'alertes sur l'espace de /boot Il est plutôt là le problème

Y avait des alertes mais le compte mail se faisait regulièrement bloquer à l'époque.
Mais pire que ça y avait jamais eu de monitoring de rien mis en place dans la boite à l'époque où je suis arrivé.
Mais c'est fini tout ça Maintenant je bosse dans une vraie infra avec preprod qualif monitoring etc

man rm

EDIT: rm n'est pas un builtin

Les mails c'est bien, mais si le serveur de mail/ton outlook/un relay smtp/... se casse la gueule, bah tu le vois pas, vu que tu reçoit pas le mail qui est sensé te prévenir.
Jetter un oeil de temps en temps à l'outil de sup, c'est pas mal. Tu peux même le faire faire à un stagiaire si tu veux

Chaos monkeys de Netflix

Chez nous les serveurs ne sont pas mis à jour, nos sysadmins préfèrent détruire et recréer les VMs systématiquement. Après on héberge tout chez AWS aussi donc ça aide (toutes les base de données sont managées donc pas besoin de se préoccuper des failles de sécurité, qui de toute façon n'ont aucune raison d'être exposées).

oe, en même temps le cloud c'est une grosse faille de sécu surtout quand c'est hébergé au US

 
Oui c'est pas déconnant, en mode cloud l'OS devient secondaire (pet vs cattle)

un 24" collé au mur avec un auto-it qui fait des alt-tab toutes les 5 secondes sur les differents ecrans, ca va bien aussi

On a placé un PC avec 8 24" chez un client, ils sont content, il fait clair dans la pièce

Ya les SMS aussi sinon

 
Tu peux consulter windowsupdate.log (ou un truc du genre), et tu sauras tout ce que tu veux  

 
Y'a pas de problème,  
 
quand Vista est sorti XP a été plus lent dans les Windows Update. C'est la même chose ici
 
Sinon, j'ai téléchargé "Windows update standalone installer", de mémoire, qui m'a débloqué la situation

On a certaines machine qui tournent une journée entière (voir plus) si tu laisse faire le Windows update "classique"
 
** edit **
j'ai l'impression qu'il y a des timeouts donc que la puissance de l'infra ne joue en rien.
 
Mais n'étant plus vraiment concerné, je n'ai pas vraiment investigué.

Ce n'est pas vraiment du bricolage, j'étais tombé sur cette solution en parcourant les sites et solutions MS.
Essaie ce pgm dans le pire des cas, ça ne change rien et dans le meilleur ça règle ton problème
 
Mais j'admets que ça n'est pas normal
 
Et madame Michu ne fait pas attention ou demande au magasin du coin ou aux kissikonè

Désolé, je ne retrouve plus la manœuvre que j'avais dû effectuer, essaie le WSUS Offline
 
C'est facile et ça va pas trop mal
 
Sinon  
http://answers.microsoft.com/en-us [...] cdccb77aca

EowynCarter tu as la barre de progression qui reste à 0% ? J'ai remarqué ça sur mon laptop pro. J'ai essayé de passer les maj une par une, j'ai réussi à en faire... 1 Les définitions windows defender

 
elle arrete l'ordinateur de force.
On a eu le cas pas plus tard que ce matin.
au reboot suivant, elle a eu un message "annulation des mises a jour en cours..."
a nouveau un reboot et hop windows 7 etait revenu.
Je suspecte une install de windows 10, mais j'ai pas pu le verifier c'est pas moi qui a traiter le ticket.

essaye de telecharger la 3135445 sur https://catalog.update.microsoft.com/
 
source: http://forum.hardware.fr/hfr/Windo [...] 1223_5.htm

 
Le genre de remarque que je trouve débile.
 
C'est pas parceque tu vas protéger l'utilisateur par défaut, qu'il peut pas le faire en utilisant un switch specifique si besoin
 
Pour 1 rm -rf / vraiment voulu, combien fait par erreur ?
Je vois meme pas dans quel cas il peut etre nécessaire de faire un rm -rf / vu que le seul résultat possible c'est de plus avoir de machine

Ouais mais ca c'est la "nouvelle mentalite" qui est franchement derangeante: penser a ta place.
 
- Non, il n'est pas possible de faire 'x' car ca n'a aucun interet.
- Ce n'est pas prevu car ce n'est pas beau
- Pourquoi feriez-vous cela? Non monsieur...
 
Et c'est louable, mais je trouve que ce courant va a l'encontre de *NIX.
Je ne PEUX pas -> OK
Je ne VEUX pas -> mele-toi de tes oignons!

Mais on te force jamais la main hein. Tu peux toujours passer outre, c'est bien ça la philosophie du libre. Ya des conventions, si tu veux faire autrement tu peux (genre t'es pas obligé d'utiliser systemd si t'aime pas )
 
Et au PIRE du pire du pire, tu peux forker

à la sauce MS avec un petit paramètre /IAmSureIWantToDestroyMySystem ca serait très bien
(toi même tu sais si t'as déjà utilisé l'installeur en ligne de commande d'exchange )

/ihavereadandiacceptthelicenceagreement

J'ai un script powershell avec tache planifiée qui remonte les logs par mail tous les jours, je le porterai à mon retour.

C'est le serveur qui c'est fait hacker et non une infection classique par mail !