Ça parle de blocage pare-feu, ça, ça va.
Et ensuite de AppLocker (je ne connais pas) qui est de la pure administration Windows. Bon… Et pour Linux, la solution, c'est quoi ? N'installer que des logiciels libres ? Tiens, d'ailleurs je vais aller voir Codium :)
Bon, en même temps, y a tellement moyen de faire des reverse shells en pure Bash…
Posté par Toto .
Évalué à 5.
Dernière modification le 24 septembre 2023 à 12:07.
Les RSSI ne considèrent pas les dev comme méchant, ils considère tout être humain, sauf eux, comme méchant et voulant contourner les règles :)
Sinon, ce n'est pas vraiment un problème de compétences lié au développement sécurité, c'est un problème lié à un outil qui peut faire un reverse shell sur ta machine. Le problème aurait été identique si l'outil en question était LibreOffice Calc, et la conclusion aurait été la même, mais sur une population différente.
Ici, tu as deux problématique :
- le développeur qui va utiliser l'option de VSCode, sans connaitre les impacts
- un attaquant qui va utiliser cette option (soit via ton VSCode, soit un VScode qu'il va télécharger) pour avoir ce reverse shell. Or VSCode étant un binaire signé, connu et donc globalement considéré comme "de confiance", la plupart des outils d'analyse ne le verront pas, ce qui en fait tout l'intérêt par rapport à une backdoor développée sur mesure.
Du coup, l'approche serait plutôt sensibiliser les utilisateurs sur l'impact de télécharger tout et n'importe quoi, de les sensibiliser également sur cette option.
Et pour Linux, l'approche AppLocker peut être remplacée par un SeLinux ou AppArmor correctement configuré pour t'assurer que le seul VSCode autorisé est celui préconisé par l'IT/ta distrib et qu'en plus tu lui interdit de faire du reverse shell
Posté par cg .
Évalué à 10.
Dernière modification le 24 septembre 2023 à 15:25.
Quand tu discutes en entreprise sur la limitation des accès à Internet pour les personnes qui manipulent du contenu sensible ou de valeur (c'est à dire quasiment tout le monde, si tu y penses), chaque équipe est ok pour le mettre en œuvre, mais "sauf pour mon équipe, on est conscient des risques, nous1".
à . chaque . fois .
Une solution simple et moderne, c'est l'isolation du navigateur (Remote Browser Isolation), qui permet d'aller visiter tout ce qu'on veut, mais limite drastiquement les téléchargements et les connexions louches. Faudrait que je fasse un journal là-dessus, tiens.
traduire par : on est pas des nazes contrairement aux nanas de la compta (raccourci sexiste volontairement provoquant). ↩
Je veux bien un journal là dessus, mais le brouteur n'est un vecteur d'attaque que je redoute.
Je me bats plus avec les devs qui utilisent 420000 dépendances npm/maven/docker/… depuis les depots centraux sans verifier ne serait ce que les licences ou encore les accrocs au curl|sh.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Et le blocage pour Linux ?
Posté par Glandos . Évalué à 2.
Ça parle de blocage pare-feu, ça, ça va.
Et ensuite de AppLocker (je ne connais pas) qui est de la pure administration Windows. Bon… Et pour Linux, la solution, c'est quoi ? N'installer que des logiciels libres ? Tiens, d'ailleurs je vais aller voir Codium :)
Bon, en même temps, y a tellement moyen de faire des reverse shells en pure Bash…
[^] # Re: Et le blocage pour Linux ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
L'article a une approche "RSSI, les devs sont méchants, achetons un produit pour tout surveiller et verrouiller".
La Bonne Approche est de former les devs au développement sécurisé.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et le blocage pour Linux ?
Posté par Toto . Évalué à 5. Dernière modification le 24 septembre 2023 à 12:07.
Les RSSI ne considèrent pas les dev comme méchant, ils considère tout être humain, sauf eux, comme méchant et voulant contourner les règles :)
Sinon, ce n'est pas vraiment un problème de compétences lié au développement sécurité, c'est un problème lié à un outil qui peut faire un reverse shell sur ta machine. Le problème aurait été identique si l'outil en question était LibreOffice Calc, et la conclusion aurait été la même, mais sur une population différente.
Ici, tu as deux problématique :
- le développeur qui va utiliser l'option de VSCode, sans connaitre les impacts
- un attaquant qui va utiliser cette option (soit via ton VSCode, soit un VScode qu'il va télécharger) pour avoir ce reverse shell. Or VSCode étant un binaire signé, connu et donc globalement considéré comme "de confiance", la plupart des outils d'analyse ne le verront pas, ce qui en fait tout l'intérêt par rapport à une backdoor développée sur mesure.
Du coup, l'approche serait plutôt sensibiliser les utilisateurs sur l'impact de télécharger tout et n'importe quoi, de les sensibiliser également sur cette option.
Et pour Linux, l'approche AppLocker peut être remplacée par un SeLinux ou AppArmor correctement configuré pour t'assurer que le seul VSCode autorisé est celui préconisé par l'IT/ta distrib et qu'en plus tu lui interdit de faire du reverse shell
[^] # Re: Et le blocage pour Linux ?
Posté par Glandos . Évalué à 4. Dernière modification le 24 septembre 2023 à 13:36.
Si j'ai bien compris, c'est surtout que y a un outil qui peut être lancé par un script malveillant, qui peut faire un reverse shell sans être détecté.
[^] # Re: Et le blocage pour Linux ?
Posté par cg . Évalué à 10. Dernière modification le 24 septembre 2023 à 15:25.
Quand tu discutes en entreprise sur la limitation des accès à Internet pour les personnes qui manipulent du contenu sensible ou de valeur (c'est à dire quasiment tout le monde, si tu y penses), chaque équipe est ok pour le mettre en œuvre, mais "sauf pour mon équipe, on est conscient des risques, nous1".
à . chaque . fois .
Une solution simple et moderne, c'est l'isolation du navigateur (Remote Browser Isolation), qui permet d'aller visiter tout ce qu'on veut, mais limite drastiquement les téléchargements et les connexions louches. Faudrait que je fasse un journal là-dessus, tiens.
traduire par : on est pas des nazes contrairement aux nanas de la compta (raccourci sexiste volontairement provoquant). ↩
[^] # Re: Et le blocage pour Linux ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Je veux bien un journal là dessus, mais le brouteur n'est un vecteur d'attaque que je redoute.
Je me bats plus avec les devs qui utilisent 420000 dépendances npm/maven/docker/… depuis les depots centraux sans verifier ne serait ce que les licences ou encore les accrocs au curl|sh.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.