Bonjour Nal,
d'après toi, quelle serait le sujet de sécurité brûlant sur linux actuellement. Pour alimenter le débat, je me dis qu'on pourrait parler d'IOT, de défense en profondeur, de serveur web en php troués de partout, de GRsec ou de containerisation, etc…
Selon toi, si on devait s'intéresser à un aspect de la sécu sous linux (au sens large) et que d'un, lequel serait le plus important?
Merci :-)
# Quelle sécurité ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+14/-0). Dernière modification le 06 juin 2025 à 17:29.
La sécurité et le réglementaire ? CRA, NIS2 ?
La sécurité et la gouvernance ? Gestion des inventaires matériels et logiciels (SBOM)
La sécurité et les utilisateurs ? Plein de sources différentes (paquets natifs, Flatpak, Snap, AppImage, extensions des applis, Docker, de chaque langage de programmation, les magasins d'applications, etc.) et les phishing et autres attaques de plus en plus avancées
La sécurité et les développeurs ? Immutabilité et reproductibilité bit à bit ? Financement des composants d'infra communs ?
La sécurité et les intégrateurs ? Les problématiques des chaînes CI/CD ?
La sécurité et les services en ligne ? La massification des attaques par automatisation et IA ?
La sécurité et les ops ? La configuration fine des règles de sécu avec plein de couches différentes ?
La sécurité et les hoodies ?
….
# Sécurité brûlant
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Il manque un clone libre du jeu The Firemen.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Rust
Posté par uso (site web personnel) . Évalué à 2 (+4/-3).
Rust Rust Rust Rust Rust Rust Rust Rust Rust Rust Rust.
Rust Rust Rust Rust !
Rust Rust Rust Rust Rust Rust Rust Rust.
Rust Rust ?
Rust Rust Rust.
Rust.
[^] # Re: Rust
Posté par ted (site web personnel) . Évalué à 2 (+0/-0).
Chicken, chicken chicken?
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Sécurité brûlant
Posté par eingousef . Évalué à 3 (+1/-0).
Apparemment il existe déjà des jeux de sécurité civile: https://libregamewiki.org/Search_and_Rescue https://libregamewiki.org/Search_and_Rescue_II (je ne les ai jamais testés).
*splash!*
[^] # Re: Sécurité brûlant
Posté par BAud (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 06 juin 2025 à 18:40.
comme Choplifter! ;-)
# containers
Posté par pasBill pasGates . Évalué à 9 (+9/-1).
La terrible habitude de beaucoup de gens de croire qu'un container, au sens namespace/seccomp/cgroup du terme, est une barrière de sécurité suffisament sûre pour faire tourner du code potentiellement dangereux dedans.
Vivement qu'on introduise des microVMs comme primitives de premier plan pour que ces gens arrètent de se tirer une balle dans le pied.
[^] # Re: containers
Posté par Andre Rodier (site web personnel) . Évalué à 10 (+14/-0).
Ça me rapelle un XKCD….
[^] # Re: containers
Posté par Sébastien Wilmet (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
"Containers ou VMs, quel est le plus sécurisé ?" n'est pas une question si simple que ça (à répondre).
Je me rappelle avoir lu cet article sur LWN : Measuring container security, qui était une première étape pour vraiment quantifier le niveau de sécurité d'un container par rapport à un hyperviseur.
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 7 (+7/-1).
C'est assez simple en fait.
Si ce que tu veux faire tourner est non trivial (ex: ffmpeg) alors tu atteris au final avec une liste de system calls à permettre qui est pas mal longue, qui contient des trucs assez dangeureux, et tu te retrouves avec autant d'interfaces pour entrer dans ce gros spaghettis de code C qu'est le Kernel.
Tu prends une microVM et tu interface principalement avec un VMM, qui pourrait typiquement être écrit en Rust, tel Firecracker.
Ensuite les unikernels pourquoi pas, on va dire que pour l'instant ils sont du domaine de la curiosité, ils n'ont pas vraiment pris de ce que je vois.
[^] # Re: containers
Posté par cg . Évalué à 2 (+0/-0).
Merci, je ne connaissais pas l'existence des microVMs, je vais regarder ce truc, ça a l'air très chouette.
[^] # Re: containers
Posté par uso (site web personnel) . Évalué à 3 (+2/-0).
Alors que si tu fais de la virtualisation, alors tu atterris au final avec une liste d'instructions CPU à permettre qui est pas mal longue, qui contient des trucs assez dangereux, et tu te retrouves avec autant d'interfaces pour entrer dans ce gros spaghetti d'instruction set qu'est Intel.
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 1 (+0/-0).
Moi je me contente de comparer le nombre de vulnérabilités amenant à une escalation guest -> host avec KVM - Intel/AMD et le nombre de vulnérabilités dans les appels système du kernel Linux, ca suffit pour tout éxpliquer.
[^] # Re: containers
Posté par uso (site web personnel) . Évalué à 2 (+1/-0).
Pour le coup, les containers ça utilise beaucoup les cgroups, qui ne sont pas des appels système, mais un filesystem. (que tu manipules comme des fichiers)
Donc ce n'est pas que les appels systèmes qui peuvent poser problèmes.
Aussi les appelle système, c'est souvent juste des point d'entrées vers d'autre fonction du kernel, donc rarement le code même des appels système qui pose problèmes.
Après ça ne change pas grand-chose au raisonnement ceci dit.
Ceci dit, si on est sur un compte de point d'entrée sur les intel, t'a plusieurs milliers d'instructions, à côté de ça les 400 syscall de linux paraissent bien peu.
Surtout que ça inclut les getuid et autre, qui ont peu de chance de poser problèmes.
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 2 (+1/-0).
Il y a plein de choses qui peuvent poser problème, aussi les permissions auquel a accès le container, mais cela, ça peut se travailler au moins.
Ensuite, évidemment que le problème est tout le code accessible depuis l'entrée de l'Apple système, le code de l'appel système en lui même est très petit en comparaison et pas le problème.
Les instructions Intel t'en as effectivement plus, mais en complexité elles n'ont rien à voir, et contrairement au noyau elles ne changent pas tous les matins.
Les chiffres sont clairs au niveau des vulnérabilités, le reste c'est de l'opinion et de la théorie
[^] # Re: containers
Posté par Arkem . Évalué à 2 (+1/-0).
Un Apple système dans Linux, ça me paraît particulièrement inquiétant…
[^] # Re: containers
Posté par uso (site web personnel) . Évalué à 2 (+1/-0).
Y'a un problème darling ?
le projet a l'air sympa.
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 2 (+1/-0).
Mais c'est pourtant possible !
https://itsfoss.com/macos-linux-vm/
[^] # Re: containers
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
J’ai jamais vu ça. Tu entends quoi plus précisément ? Tu as des exemples ? J’ai entendu pleins de gens dire que l’argument que ça apporte de la sécurité est un faux sentiment de sécurité oui. Il y a l’idée de kubernetes multi tenant. Mais je crois pas avoir un jour vu quelqu’un parler d’exécuter du code non-sûr avec cette seule sécurité. Par exemple moi je le fais, mais c’est dans une sandbox.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 2 (+2/-1).
L'exemple habituel est les gens qui font tourner plein de services sur le même host, avec le container comme seule barrière entre eux. Le service n'est pas forcément un truc qui fait tourner du code inconnu, mais cela peut aussi etre un service qui fait des conversions de format avec des librairies C. Bref un truc qui a de bonnes chances d'exploser un jour ou l'autre, et quand cela arrive ven les autres services sont compromis aussi.
[^] # Re: containers
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Ben ça quelque soit la manière de le voir c’est pas pire qu’avoir différents services derrière un nginx, apache ou autres. Les jails BSD font peut être un meilleur boulot niveau sécurité, mais les containers ici sont une amélioration par rapport aux habitudes précédentes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 0 (+1/-2).
Oui, effectivement. Et mettre un coussin sur son visage était certainement mieux que rien avant l'obtention de la ceinture de sécurité…
Mais cela fait un moment maintenant qu'on a des VMs, des microVMs. Il y a mieux. Faudrait en faire une primitive de base dans l'OS, bien intégrée, afin que l'adoption grimpe.
[^] # Re: containers
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Alors avant et pendant longtemps ce qui était recommandé c’est juste de faire un chroot. C’est fou de continuer à être méprisant alors que ton argumentaire ne tiens pas de commentaire en commentaire…
Ça dépend, d’un point de vu sécurité les VM c’est très vieux et au moins depuis que la para-virtualisation existe l’overhead en coût d’exécution n’est pas un problème majeur.
Mais on est très loin de ce que propose docker pour tout le reste : que l’on parle d’un point de vu développement ou opérationnel tout reste à faire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 3 (+4/-2).
C'est pas méprisant, c'est juste que d'un point de vue sécurité les gens de prélassent dans les containers parce que c'est facile a utiliser. Je comprends un peu, mais cela souligne le besoin d'intégrer les microVMs dans les OS comme citoyens de première classe plutôt que ce qu'ils sont aujourd'hui : en gros des pansements qui ne tiennent pas facilement.
L'overhead des microVMs est assez faible, le coût d'une microVM n'a rien à voir avec celui d'une VM, et il est certainement possible d'intégrer le tout pour qu'un container soit chargé dans une microVM. Il y aura quelques limitations et differences oui mais cela fonctionne très bien.
[^] # Re: containers
Posté par barmic 🦦 . Évalué à 4 (+4/-2).
De la part de quelqu’un qui a passé des années chez MS qui a passé des décénies à ne pas pouvoir correctement gérer plusieurs utilisateurs et qui maintenant fait ce qu’il peut pour juste tenter de reproduire docker, j’aurais imaginé un peu plus d’humilité.
Essaie de t’en servir tu comprendra mieux. Les gens ne se "prélassent pas dans les containers" (vraiment ? pas de mépris ou de jugement de valeur ?) ils prennent ce qui se fait à l’heure actuel.
Oui et non. Depuis la paravirtualisation l’overhead CPU n’est plus un problème. Par contre les I/O peuvent encore être un sujet (c’est ce que j’ai observé avec firecracker). Ensuite tu as le choix entre :
Dans les grandes lignes tu as raisons, mais il y a un paquet de trucs qu’il va falloir créer pour que ça ai puisse concurrencer sérieusement les containers. Aujourd’hui la pratique répandue c’est d’avoir de grosses VM dans le quel tu met des kube.
Mais du coup l’objet c’est de gérer quel problème de sécurité ? Une exécution de code arbitraire ? Le multitenant est déjà géré par des VM et si tu as du code malveillant dans ton container le fait qu’il sorte du contexte n’est que l’un des problèmes (le DOS et l’extraction de données sont d’autres problèmes pour la quelle des VM ne peuvent rien).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 1 (+1/-1). Dernière modification le 08 juin 2025 à 21:13.
C'est hilarant de toujours me rattacher à Microsoft alors que cela fait plus de 10 ans que je bosses sur Linux, chez ce qui est certainement le plus grand consommateur de Linux au monde.
Sinon, les mixroVMs c'est très bien, notamment parce que leur faible consommation en ressources comparé aux VMs normales et leur capacité à démarrer très vite fait que dans pas mal de cas tu peux isoler quasiment au niveau requête, sinon au niveau utilisateur, au pire à un pool restreint d'utilisateurs. Pour ce qui est dangereux, genre ces conversions de format par exemple, tu peux le faire d'une manière qui limite énormément l'impact d'une instance compromise.
C'est pas par hasard que Firecracker a été créé par Amazon…
[^] # Re: containers
Posté par barmic 🦦 . Évalué à 4 (+3/-1).
Ok je comprends le problème d’ego du coup.
Je l’ai essayé, hein ? Et c’était loin d’être parfait. Il ne rendait pas la mémoire, créer des microvm demandait plus de travail, les déploiements n’étaient pas aussi clean que ce que j’arrivais à faire avec kube,… Je suis pas surpris que des gens comme Clever Cloud aient préféré refaire une stack plutôt que de galérer avec, mais le déploiment c’est leur cœur de métier.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 2 (+1/-0).
Ah mais les trucs parfait cela n'existe nulle part, même hello World n'est pas parfait.
Firecracker a ses avantages et ses inconvénients (pas de support gpu par exemple), mais il rend beaucoup service. Des services massifs comme Lambda et Fargate tournent dessus, tu imagines donc bien que ce problème de retour de RAM que tu as, pour je ne sais quelle raison eux ne l'ont pas.
Ensuite, Firecracker seul comme cela, ou l'utilisateur doit installer, configurer, etc. tour ce bordel c'est douloureux, cela amène certainement des erreurs et autres, parce que c'est compliqué et cela demande des connaissances que tout le monde n'a pas.
Et c'est justement toute la raison pour mon désir qu'on fasse des microVMs des citoyens de première classe dans les OS serveur, histoire que ce soit enfin (plus) simple à utiliser.
[^] # Re: containers
Posté par Faya . Évalué à 4 (+2/-0). Dernière modification le 09 juin 2025 à 14:34.
Humour, j'y connais rien aux MicroVM c'est sûrement génial. Mais les commentaires qui suivent le changement de crémerie ça m'a amusé…
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 2 (+1/-0).
Vu mes positions sur Windows que je réitère souvent, on a va dire que je dis régulièrement du bien du plus gros concurrent de mon employeur. Ensuite, Firecracker est … open source. Il a été crée par AWS-Amazon, mais c'est un projet avec une vraie communauté, plein de contributions sont externes à Amazon : https://github.com/firecracker-microvm/firecracker/blob/main/CREDITS.md
[^] # Re: containers
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
C'est un peu overkill les vms (même micros) pour "juste" limiter les droits d'un processus, non ?
Surtout si on remets un k8s par dessus 😋.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: containers
Posté par pasBill pasGates . Évalué à 3 (+3/-1). Dernière modification le 09 juin 2025 à 09:24.
Tout dépend du profile de risque. Si tu fais tourner un truc tout simple en Java, sans deserialization, oui probablement
Si tu fais tourner ffmpeg, gstreamer,… sur des fichiers envoyés par des inconnus, non parce qu'il y a un historique de vulnérabilités, du code C qui touche ce contenu que tu ne contrôle pas,… et les conséquences si ça merde sont une prise de contrôle du système, exfiltration des données de tes clients, etc…
Il fut une époque où une VM était juste trop coûteuse pour pouvoir isoler de manière fine, mais les choses changent.
Ensuite k8s, vu comment il fonctionne, effectivement faut pas l'utiliser pour du multi tenant non plus, les permissions des noeuds n'aident pas.
[^] # Re: containers
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
VM servent à plusieurs choses à ce moment là :
Donc non c’est tout à fait pertinent et je doute qu’il existe des k8s managés qui ne soient pas dans des VM par exemple.
k8s ensuite c’est le serveur d’app actuel. Au lieu de se questionner sur quel OS dans quel version tu fait tourner dans tes VM, tu met du kube et ça laisse de la flexibilité aux dev.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: containers
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 10 juin 2025 à 08:21.
Tout dépends si tous ces services utilisent le même jeu de données ou pas.
Parce qu'au final c'est ce qui nous intéresse, qu'un attaquant ou un client ne puisse pas accéder à ce qu'il n'a pas le droit. Si tu sépares tes n services mais qu'il y en a un qui a un bug ou une faille importante mais que tous accèdent à la mėme DB, ça ne change pas grand chose que ces services soient plus strictement isolés les uns des autres.
Bref architecture toussa.
À part ça utiliser des containers et l'isolation par vm, ce ne sont pas des sujets incompatibles. Il faut en prendre en compte les limitations mais c'est à ça que servent des projets comme katacontainers par exemple.
Et pourquoi s'arrêter aux VM? Il ya a des projets qui laissent le choix à leur client entre une offre moins chère et multitenant avec une offre single-tenant tournant dans un compte "cloud" dedié.
# Vulnérabilité de projets cruciaux
Posté par eingousef . Évalué à 10 (+15/-0).
Suite à la faille de sécurité dans xz je dirais que la priorité dans le monde du libre serait de faire une liste des "briques de base" en essayant d'estimer un ratio "difficulté de maintenance du projet"/"quantités de ressources humaines actuellement mobilisées pour le maintenir". Et dans le cas où on trouverait dans cette liste des projets nécessitant plusieurs devs à temps plein mais qui sont maintenu sur temps libre par un geek dépressif dans une cave au fin fond de l'Alaska qui n'a pas vu la lumière du jour depuis 1974, essayer d'améliorer la situation (et pourquoi pas commencer par faire un audit).
*splash!*
[^] # Re: Vulnérabilité de projets cruciaux
Posté par raphj . Évalué à 2 (+0/-0).
Note pour la personne lisant ton commentaire qui voudrait peut-être démarrer ce chantier : ça pourrait commencer par les paquets d'une installation minimale de Debian.
Mais je crois que le plus dur c'est plutôt de trouver des gens pour sponsoriser ces temps pleins.
[^] # Re: Vulnérabilité de projets cruciaux
Posté par cg . Évalué à 3 (+1/-0).
En partant d'ici : https://www.oss.fund/, on trouve https://www.oss.fund/backyourstack/, présenté comme un outil d'analyse des dépendances open-source dont vous dépendez, qui propose des manières de les aider ("Analyzes your open source software dependencies to find which projects you rely on, and then provides a way for you to easily support them all.").
Il y a beaucoup de trucs sur oss.fund, OpenCollective a l'air intéressant aussi ("Provides tools for collectives to receive money and mechanisms to spend their money in a transparent way.")
[^] # Re: Vulnérabilité de projets cruciaux
Posté par cg . Évalué à 4 (+2/-0).
J'avais vu une plateforme il y a quelques semaines, qui s'occupe de redistribuer de l'argent à des projets libres et/ou open-source, en prenant en compte les "petits projets" dont les gros dépendent parfois. L'idée étant que les ruisseaux font les grandes rivières.
Je ne retrouve pas le nom, mais ça m'avait eu l'air intéressant.
[^] # Re: Vulnérabilité de projets cruciaux
Posté par Colargol (Mastodon) . Évalué à 4 (+2/-0).
La fondation NLnet ?
# Le flood de bots
Posté par Zatalyz (site web personnel) . Évalué à 7 (+5/-0).
Je ne sais pas si c'est "le plus important" mais c'est d'actualité. Le flux des bots qui ne respectent rien et qui font tomber des sites, c'est devenu un peu le gros cheval de bataille ces derniers mois. Ça s'est senti particulièrement sur les forges, et ça a donné des outils comme Anubis, mais les forges sont loin d'être les seules touchées. Quelle que soit la véritable motivation des personnes derrière ses attaques (je penche pour des crawlers codés par des IA, pour des IA, et déployés par des crétins incompétents), l'impact sur le web est celui de DDOS non ciblés et ça impacte des sites qui jusque là n'avaient pas besoin de trop se poser la question de la quantité de trafic. Il y a plein d'implications, plein de possibilités (de solution, d'explication), le sujet est riche, bref si tu as envie de faire une série sur la sécurité, cela me semble un bon candidat.
[^] # Re: Le flood de bots
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+8/-1). Dernière modification le 07 juin 2025 à 09:55.
Sur les 48 derniers comptes LinuxFr, 42 n'ont pas d'IP associée (compte jamais utilisé), 1 déjà fermé pour spam, reste au mieux 5 potentiellement légitimes (dont 2 n'ayant jamais rien écrit)… le ratio est dramatiquement bas depuis peu.
[^] # Re: Le flood de bots
Posté par Zatalyz (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 07 juin 2025 à 20:20.
Je ne pensais pas à ceux qui s'inscrivent, mais qui visitent. J'ai un serveur qui a bien morflé avec ça (bande passante assez basse, quelle idée aussi d'avoir un petit site web en html&css derrière une ligne en adsl :P), et sur les serveurs de mes assos, dans les datacenters, on a eu une bonne augmentation du trafic et des effets collatéraux ; rien de grave (on a géré en faisant du ban aggressif) mais des histoires comme ça j'en ai vu passer ces derniers mois. Je pense que cela impacte plus les "petits" qui n'ont pas une grosse bande passante ou des machines qui vont gérer le flux, pas sûr que ce soit aussi visible sur les sites qui avaient déjà un fort trafic et donc des ressources et gestions adaptées.
Du coup je suis curieuse, sur Linuxfr vous avez une infra faite pour faire face à un gros trafic si j'ai compris, est-ce que vous avez quand même remarqué une augmentation importante des visiteurs, ou rien de perceptible ?
Et c'est rassurant de voir que ça n'augmente pas trop les inscriptions ici. Ceci dit je n'ai pas non plus constaté plus d'inscriptions dans les services qu'on gère, ce qui est cool parce que nos mesures antispams sont à mon avis pas loin d'être obsolètes.
[^] # Re: Le flood de bots
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
J'avais bien compris, mais je disais justement que ça devient aussi massif sur les inscriptions (en plus du trafic sur les non-inscrits).
Là par contre je disais le contraire : ça fait pas lourd de légitimes dans les chiffres que je donnais.
[^] # Re: Le flood de bots
Posté par Zatalyz (site web personnel) . Évalué à 2 (+0/-0).
Désolé, je n'étais pas réveillée… Mais vraiment pas. Je ne prétendrais pas que c'est mieux aujourd'hui, en plus :P
En effet 3 comptes qui ont donnés la preuve de leur légimité, 2 "peut-être", sur 48, c'est pas extra. Par curiosité, sur quelle période de temps ? Si c'est en une semaine ça fait beaucoup… Vous faites de la vérification à la main ou il y a des procédures auto, genre ceux qui ne se sont pas connectés depuis (qui peuvent devenir des comptes dormants pour spammer plus tard) sont virés automatiquement à un moment ?
[^] # Re: Le flood de bots
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 08 juin 2025 à 16:04.
Tiré de la rétrospective du 01 au 15 mai 2025 : 62 comptes ouverts (dont 26 fermés depuis) ;
Sinon depuis le 1er juin (on est que le 8…) : 133 comptes créés (ie. nettement plus en volume)
- 8 sont ouverts, sont déjà venus et ont écrit quelque chose (hypothèse : probablement largement des comptes légitimes, éventuellement quelques spammeurs encore en mode furtif)
- 12 sont ouverts, dont déjà venus mais n'ont rien écrit (hypothèse : quelques comptes légitimes, quelques spammeurs encore en mode furtif)
- 10 sont ouverts mais sans IP, ie. ne sont jamais venus (hypothèse : beaucoup de spammeurs)
- 85 sont inactifs sans IP (hypothèse : beaucoup/tous de spammeurs), automatiquement fermés car jamais venus
- 6 sont inactifs avec IP et ont écrit : spammeurs avec intervention de la modération
(Et nettement plus en proportion de spammeurs).
Automatiquement on ferme les comptes sans IP. Automatiquement on vire les comptes fermés sans écrits associés.
[^] # Re: Le flood de bots
Posté par Zatalyz (site web personnel) . Évalué à 2 (+0/-0).
Ha oui, c'est violent… Bon courage !
[^] # Re: Le flood de bots
Posté par Zorro . Évalué à 3 (+2/-0).
Récemment, c'est Mageia qui communiquait sur du trafic de bot tellement intense que c'était presque du DDOS : https://blog.mageia.org/en/2025/05/18/an-avalanche-of-ai-bots-is-repeatedly-taking-parts-of-our-website-down/
# L'origine des composants
Posté par cg . Évalué à 7 (+5/-0). Dernière modification le 06 juin 2025 à 21:25.
Ce n'est probablement pas un sujet excitant, mais je vois bien ces trucs, qui sont cousins, sur les "magasins de softs" :
Concernant ce second point, nous avons par exemple sur une distribution classique comme Ubuntu : les repos APT officiels, les PPAs, le(s) repo snap, le(s) repo flatpak. Chaque "source" de logiciels a ses pratiques de sécurité, de mise à jour, facile/pas facile d'y entrer, etc…
Bref, peut-on faire confiance à un flatpak, est-ce que snap c'est mieux ? Un PPA maintenu, est-ce plus secure que le paquet de la distrib qui est sur une vieille version ? Comment je mélange tout ça de manière maîtrisée ?
Concernant le troisième point, y'a tellement de blagues… npm, pip… C'est le bordel. On pourrait aussi parler des magasins de plugin "in-app" genre pour VSCode, pour neovim, pour emacs, pour Firefox… Le moindre outil ou langage de programmation a son store, avec du sérieux et du malware mélangé.
Autre sujet - qui fera peut-être grincer des dents certain·es libristes :
Bref, en un mot comme en cent : dans un monde connecté dans lequel il est facile d'installer des trucs, comment savoir si c'est sûr ou non ?
(désolé pour le côté brouillon du message)
[^] # Re: L'origine des composants
Posté par damiend . Évalué à 7 (+6/-0).
C'est ce que je crains avec le passage (de plus en plus pressant) aux flatpaks (ou équivalent) : quelle gouvernance ?
Car si les dépôts sont a priori revus de très près, avec Flatpak, chacun fera son propre packaging. Les virus seront (probablement) filtrés, mais la télémétrie ? Le stockage de sauvegardes en ligne sans consentement explicite ? L'entraînement IA sur les données perso ?
Bref l'absence de règles pêche encore une fois, et flathub.org ne me renseigne pas sur ce sujet.
[^] # Re: L'origine des composants
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Sans oublier la vérification de base: est-ce que le code est libre?
Pour moi c'est plus facile de faire confiance à Debian que de valider un par un les outils. En entreprise c'es arrivé plusieurs fois que les collègues sous Windows installent un logiciel avec une license non-commerciale par exemple. Ce quei va probablement à terme aboutir à une interdiction d'installer quoi que ce soit sans validation préalable.
# IoT
Posté par abriotde (site web personnel, Mastodon) . Évalué à 5 (+4/-0).
Pour moi le problème majeur ce sont les objets du quotidien non open-source surtout ceux connectés.
Ils représentent une menace multiforme.
Une menace car ils sont souvent non mis à jour (trop complexe et pas rémunéré) surtout si l'entreprise a changé de modèle ou fait faillite. Ils sont une cible de choix pour constituer des bots-net capable de faire tomber des serveurs, ou pour faire des faux profils, ou comme rebonds… Ou faire planter l'appareil voir le réseau (en lançant tous les appareils a la même seconde, on peut faire planter le réseau électrique).
Une menace car l'entreprise éditrice peut s'en servir elle même volontairement pour nous épier ou pour les mêmes menaces cités au dessus… Il peut y avoir un intérêt commercial (revendre du botnet pour un produit peu cher) et une obligation légale… C'est le soupçon officiel des appareils chinois entre autre. Mais la France faut pareil avec les smartphones au minimum.
Ils représentent donc une menace écologique (reparabilité / obsolescence) une menace des entreprises (botnet) une menace de sécurité nationale (attaque, rebond souvent à l'intérieur des entreprises ultra-sécurisées…)
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# flatpaks
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
Le faux sentiment de sécurité dans le monde flatpak.
Sinon dans un entretien d'embauche quand j'ai demandé si l'on pouvait choisir son OS, ça a démarré un troll entre les 3 personnes qui m'interviewaient. Un disait préferer Ubuntu, l'autre MacOS et le CTO disait que Linux c'était super à la maison mais qu'en entreprise à cause des audits SOC2 c'était une plaie, pas parce que ce n'était pas sécurisé en soit, mais parce qu'il n'y avait aucun outil de mise en comformité et que dans le monde MacOS c'était tout juste un peu mieux et que du coup ce serait Windows + WSL etpicétout pour faire plaisir aux auditeurs.
[^] # Re: flatpaks
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+4/-0).
L'enfer est pavé de bonnes certifications.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: flatpaks
Posté par cg . Évalué à 3 (+1/-0).
Là ou je travaille, on propose aux employé·es des Macs, des PCs Windows et des PCs Linux (sur Ubuntu). L'entreprise a une pile de certifications (ISO27K1, SOC2, SOC3, PCI-DSS, SecNumCloud, HDS, et j'en passe…).
Les configs Ubuntu subissent - et passent - ces certifications. Toutefois, pour arriver à un résultat satisfaisant pour ces certifs, il faut faire beaucoup de durcissement de configs. On trouve pas mal de méthodes pour appliquer plein de réglages de sécurité, notamment le CIS Benchmark, avec Ansible, Puppet/Openvox, du pur shell, OpenSCAP…
Ce qui est certain, c'est qu'il faut faire le travail trois fois (doc, développement des confs, temps d'audit…), une fois par OS. Ce supplément de travail n'est pas forcément à la portée de toutes les entreprises, c'est un peu un luxe qu'il faut apprécier à sa juste valeur (et que j'apprécie au quotidien, même si perso j'aurais tendance à ne pas proposer de Macs car on ne peut pas interchanger entre Windows et Linux).
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.