Le 28/09/2021 à 16:22, François Goudal via frnog a écrit :

Ca fait quand même maintenant plusieurs années qu’on sait que cette ancienne 
manière de penser est mauvaise dans une époque ou les problématiques de 
sécurité sont connues et que les attaques sont bel et bien présentes.
Ceux qui persistent à continuer de fonctionner “à l’ancienne” n’auront que ce 
qu’ils méritent.
Et entre nous, ceux qui utilisent la méthode “on ne touche pas a un truc qui 
marche” et qui opèrent des services du genre apache, nginx, ou autres trucs 
joignables par le réseau d’une manière générale sans appliquer les patches, je 
pense que leur gpsd non patché c’est loin d’être leur principal problème :)

Nous sommes complètement d'accord mais je peux te citer les presque mêmes personnes qui font du cloud native avec des docker qui dépassent pas quelques heures d'uptime car ça livre ci/cd toutes les heures ou presque.

J'en ai deux qui ont rencontrés des soucis, premier réflex on refabrique une nouvelle architecture, même pas ils regardent ce qui est réellement arrivé, ha ça marche toujours pas, bon ben les logs disent quoi, ha on connait pas, ha stackoverflow dit que c'est un bug, ha mince comment on fait pour revenir à la version n-1 de kube ou de tel composant? ha n-1 ça marche pas non plus, au secours!

Ou un autre client qui me dit que si l'application se fait poutrer alors c'est réinstallation ailleurs et restauration des sauvegardes. Je lui dit vous savez c'est peut être l'url qui est visée et pas l'ip publique, donc si l'attaque vous suit vous faites quoi? On verra bien ... Ces gens là ont besoin d'apprendre par la douleur mais le pire c'est que c'est souvent eux qui n'auront jamais subit d'attaque dans leur carrière et donc dirons que c'est limite un mythe ou que ça touche que les gros.

Les on touche pas sont passés à ça dure tellement pas longtemps nos instances que si un gars entre il va se faire dégager rapidement. Par contre sur la partie code ils ont progressé, mais l'infra ...

---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à