Jusqu'en avril 2017, tous mes serveurs tournaient sous Slackware Linux. La distribution maintenue par un seul gars, Patrick Volkerding, qui vit au fin fond du Minnesota avec sa femme et sa fille. J'en garde un excellent souvenir, et surtout une préférence pour les petits projets. Il m'arrivait de temps en temps d'envoyer un bug report à Patrick, et en règle générale la réaction était super rapide, genre un correctif publié le lendemain avec un remerciement dans le ChangeLog. Les rares fois où j'ai eu le malheur de faire un rapport de bogue sous Debian, ça m'a rappelé mon arrivée en France quand il fallait demander un visa parce que mon pays natal n'était pas encore dans l'Union Européenne. Le gars il refuse de traiter ton dossier parce qu'il lui manque encore les radios pulmonaires de ton arrière-grand-mère. :o)
C'est bien possible, mais il faut connaître la personne qui gère pour avoir ce degré de confiance. Avec un dépôt officiel ou une communauté adoubée par la maison mère il y a une garantie de continuité de service.
Certains dépôts tiers mis en place par des particuliers sont parfois mieux maintenus que les dépôts “officiels”. À titre d'exemple, ça fait des années que j'utilise les dépôts Nux (http://li.nux.ro/repos.html) maintenus par le fondateur de Stella Linux. De temps en temps, lorsque j'ai besoin d'un paquet un peu exotique pour CentOS, j'envoie un mail à Lucian, et en règle générale, il me répond dans la journée en m'informant que le paquet est dispo dans son dépôt.
N'oublions pas que le mot “dilettante” vient de l'italien “diletto”, le plaisir. Parfois, un spécialiste, c'est juste un dilettante qui n'a pas de plaisir. Et oui, c'est une boutade. Avec un fond de vérité dans le monde de l'Open Source.
Bah en l'occurrence j'avoue que pour ma part je serais réticent à utiliser ce genre de dépôts, j'ai tendance à préférer les dépôts officiels ou semi-officiels.
Pour RHEL/CentOS il y a également le dépôt Webtatic pour un PHP plus récent. Pour une raison mystérieuse ces dépôts sont méprisés par les admins RHEL, mais perso ça fait des années que je les utilise, et je n'ai jamais eu le moindre souci avec. C'est propre et bien maintenu.
Je trouve la durée de vie des versions récentes de PHP assez courtes… Je me demande comment ça se passe du côté des distributions, par exemple dans les dépôts de Debian 9 on est toujours en PHP 7.0. Du côté CentOS dans les dépôts de base c'est PHP 5.4… mais heureusement qu'il y a les dépôts EPEL ou SCL pour avoir plus récent.
Chaque salle hébergeaient des confs autour d'un même sujet, on peut dire que ça se tient. Même si c'est vrai que ça pourrait être plus logique, sur la page des vidéos, de donner la thématique de la salle.
Je laisse le lien par courtoisie mais la page est en Anglais, on ne comprend pas comment les vidéos sont rangées bref on va dire que le contenu est présent et que ça peut servir à certaines personnes.
Salut Nikaro,
Très intéressant ton feed, je vais me pencher sur AppArmor qui m'a l'air plutôt pas mal foutu, merci pour cette découverte, autant je connais très bien SE Linux mais pas AppArmor, on en apprend tous les jours ! :)
Avec PermitRootLogin à prohibit-password il y a très très peu de chance de se faire compromettre avec un brute-force. Et au pire si on est peu frilleux, avec fail2ban c'est réglé.
À mon sens la sécurisation elle est plus à faire au niveau des services qui sont exposés. Déjà à commencer par n'exposer que les ports nécessaires, bloquer tout le reste dans le pare-feu. Ensuite faire tourner les services avec des utilisateurs restreints, puis un SELinux (ou AppArmor) pour limiter le périmètre des éventuels dégâts d'une faille.
Salut xataz,
Effectivement, j'ai rectifié le tire en proposant la création d'un utilisateur non-root (n'étant ni dans le groupe “sudo”, ni dans le groupe “admin”) et en spécifiant au niveau de la conf SSH que seul le groupe de cet utilisateur peut se connecter.
Merci pour ton retour, c'est mon premier article ! :)
1 petite chose à redire :
- sudo est très mal utilisé dans ce cas, car si l'attaquant chope le mdp de toto, il aura un accès full root sur la machine (sudo su -). sudo doit être utilisé en mode restrictif, on refuse tout, et autorise au compte goute. Surtout dans ce cas ou ssh est accessible via mdp.
Moi qui me pensait relativement à l'abri en chiffrant mes machines !
Jusqu'en avril 2017, tous mes serveurs tournaient sous Slackware Linux. La distribution maintenue par un seul gars, Patrick Volkerding, qui vit au fin fond du Minnesota avec sa femme et sa fille. J'en garde un excellent souvenir, et surtout une préférence pour les petits projets. Il m'arrivait de temps en temps d'envoyer un bug report à Patrick, et en règle générale la réaction était super rapide, genre un correctif publié le lendemain avec un remerciement dans le ChangeLog. Les rares fois où j'ai eu le malheur de faire un rapport de bogue sous Debian, ça m'a rappelé mon arrivée en France quand il fallait demander un visa parce que mon pays natal n'était pas encore dans l'Union Européenne. Le gars il refuse de traiter ton dossier parce qu'il lui manque encore les radios pulmonaires de ton arrière-grand-mère. :o)
Visiblement c'est possible. Cool.
@admins le test étant concluant, je supprime où je laisse, à titre informatif pour la communauté ?
C'est bien possible, mais il faut connaître la personne qui gère pour avoir ce degré de confiance. Avec un dépôt officiel ou une communauté adoubée par la maison mère il y a une garantie de continuité de service.
Certains dépôts tiers mis en place par des particuliers sont parfois mieux maintenus que les dépôts “officiels”. À titre d'exemple, ça fait des années que j'utilise les dépôts Nux (http://li.nux.ro/repos.html) maintenus par le fondateur de Stella Linux. De temps en temps, lorsque j'ai besoin d'un paquet un peu exotique pour CentOS, j'envoie un mail à Lucian, et en règle générale, il me répond dans la journée en m'informant que le paquet est dispo dans son dépôt.
N'oublions pas que le mot “dilettante” vient de l'italien “diletto”, le plaisir. Parfois, un spécialiste, c'est juste un dilettante qui n'a pas de plaisir. Et oui, c'est une boutade. Avec un fond de vérité dans le monde de l'Open Source.
C'est pas trop tôt :DD
Bah en l'occurrence j'avoue que pour ma part je serais réticent à utiliser ce genre de dépôts, j'ai tendance à préférer les dépôts officiels ou semi-officiels.
Pour RHEL/CentOS il y a également le dépôt Webtatic pour un PHP plus récent. Pour une raison mystérieuse ces dépôts sont méprisés par les admins RHEL, mais perso ça fait des années que je les utilise, et je n'ai jamais eu le moindre souci avec. C'est propre et bien maintenu.
Spa trop tôt.
Je trouve la durée de vie des versions récentes de PHP assez courtes… Je me demande comment ça se passe du côté des distributions, par exemple dans les dépôts de Debian 9 on est toujours en PHP 7.0. Du côté CentOS dans les dépôts de base c'est PHP 5.4… mais heureusement qu'il y a les dépôts EPEL ou SCL pour avoir plus récent.
Il vaut mieux donner https://fosdem.org/2019/schedule/events/ , toutes les informations utiles sont présentes. Se balader dans https://video.fosdem.org/ est contre-productif et contre-intuitif.
Attention je veux pas tirer sur l'ambulance mais bon niveau UX (expérience utilisateur), je vois pas comment conseiller https://video.fosdem.org/
Tcho !
Chaque salle hébergeaient des confs autour d'un même sujet, on peut dire que ça se tient. Même si c'est vrai que ça pourrait être plus logique, sur la page des vidéos, de donner la thématique de la salle.
Je suis sur qu'on en trouve encore sur du windows XP :D
Je laisse le lien par courtoisie mais la page est en Anglais, on ne comprend pas comment les vidéos sont rangées bref on va dire que le contenu est présent et que ça peut servir à certaines personnes.
EDIT : C'est rangé par salle (https://fosdem.org/2019/schedule/rooms/), je trouve l'idée curieuse mais bon.
Tcho !
Merci Lord! :)
Bon courage pour ce nouveau blog ;-)
Salut Nikaro, Très intéressant ton feed, je vais me pencher sur AppArmor qui m'a l'air plutôt pas mal foutu, merci pour cette découverte, autant je connais très bien SE Linux mais pas AppArmor, on en apprend tous les jours ! :)
Avec
PermitRootLogin
àprohibit-password
il y a très très peu de chance de se faire compromettre avec un brute-force. Et au pire si on est peu frilleux, avec fail2ban c'est réglé.À mon sens la sécurisation elle est plus à faire au niveau des services qui sont exposés. Déjà à commencer par n'exposer que les ports nécessaires, bloquer tout le reste dans le pare-feu. Ensuite faire tourner les services avec des utilisateurs restreints, puis un SELinux (ou AppArmor) pour limiter le périmètre des éventuels dégâts d'une faille.
Salut xataz, Effectivement, j'ai rectifié le tire en proposant la création d'un utilisateur non-root (n'étant ni dans le groupe “sudo”, ni dans le groupe “admin”) et en spécifiant au niveau de la conf SSH que seul le groupe de cet utilisateur peut se connecter. Merci pour ton retour, c'est mon premier article ! :)
1 petite chose à redire : - sudo est très mal utilisé dans ce cas, car si l'attaquant chope le mdp de toto, il aura un accès full root sur la machine (sudo su -). sudo doit être utilisé en mode restrictif, on refuse tout, et autorise au compte goute. Surtout dans ce cas ou ssh est accessible via mdp.