Re: [gull] ABUS réseaux
Merci Philippe ! Effectivement OpenBSD était haut dans ma liste pour la fiabilité effectivement. Je vais regarder si on peut faire quelque chose ;) Pour ce qui est des petites machines physique, c'est plus contraignant et lourd a gérer chez nous que de spawner une VM, donc ça n'arrivera pas dans l'immédiat à nouveau. Mais Mythic Beasts fait des RPI hostés, c'est aussi une petite boite, mais en Anglettere ;) Will On Wed, Aug 21, 2024 at 01:15:40PM +0200, Philippe Strauss wrote: OpenBSD (Surface d'attaque minimale des dépendances de SSH). Quid d'hébergements physiques de machines qui idle à, disons de 1 à 3 W, puis de 5 à 12W, à prix pas cher? (Elles sont petites, un RaspPi et un NUC). On Wed, Aug 21 2024 at 12:58:21 PM +02:00:00, Will van Gulik via gull wrote: Salut la liste, Dans la suite de cela, si un hébergeur local (plutôt qu'un énorme fournisseur allemand ou francais) proposait des containers pour jumphost SSH avec 1 port TCP en v4 et une IPv6 à très bas prix, vous préfèreriez quoi comme distro/OS dessus ? Debian ? Ubuntu ? Alpine ? [Open/Net]BSD ? Arch ? (oui je suis obvious, désolé ;) ) Will On Wed, Aug 21, 2024 at 12:16:12PM +0200, Daniel Cordey via gull wrote: Merci pour ces précisions. Pour Ubuntu, les versions LTS sont celles qui sont publiées les années paires au mois d'avril (sauf erreur). C'est-à-dire les 20.0, 22.04, etc. dc Le 21/08/2024 à 12:06, Marc SCHAEFER via gull a écrit : Salut, On Wed, Aug 21, 2024 at 11:37:46AM +0200, Daniel Cordey via gull wrote: Je suis perplexe... la notion de Linux stable n'existe pas, puisque Linux n'est que le kernel. Et... Debian, c'est un tout avec les notions de versions 'stable', 'testing', etc. Mais il me semble que cette notion de LTS n'a été introduite que pour Ubuntu et Red Hat, du moins il me semble... non ? Il existe une notion vague de kernel Linux LTS [2], dont la durée de vie a été sauf erreur ramenée à 5 ans. Une version de kernel qui entre dans le type de maintenance LTS ne voit alors que des corrections de bugs, backportées par les développeurs kernels, et aucune amélioration de fonctionnalité. Les distributions qui veulent plus que 5 ans doivent gérer 100% elles-mêmes ou forcer une nouvelle version sur l'utilisateur (ce qui est normalement interdit avec Debian). En ce qui concerne Debian LTS (qui comprend quasi toute la distribution Debian [3], pour les architectures i386, amd64, armel et armhf, soit moins que les sauf erreur 11 architectures supportées dans stable avant le passage à LTS): - 3 ans pour stable, supporté par debian-security - 2 ans pour LTS, supporté par debian-lts, ensuite - 5 ans pour Extended LTS, ensuite (offre payante, qui peut être limitée, sur demande à certains packages uniquement) Donc, le public dispose gratuitement de 5 ans de support pour chaque release stable. Et ceux qui paient peuvent disposer de 10 ans en tout. De mémoire, ce processus LTS a commencé en 2014. Avant cela, LTS n'existait pas chez Debian, on mettait à jour tous les 3 ans au plus tard. Chez Debian, TOUTES les versions déclarées stables passent par le cycle LTS [1], voire Extended LTS. Chez Ubuntu (dérivé de Debian) et chez Red Hat, à ma connaissance seules certaines versions vont avoir le support LTS et sont déclarées telles quelles par la distribution. Style une fois toutes les 6 releases, par exemple. En conséquence, Debian LTS désigne n'importe quelle version qui est actuellement en maintenance de type LTS. Debian Extended LTS désigne la même chose, en Extended LTS. Par exemple en juillet 2026, deux versions (bullseye et bookworm, respectivement 11 et 12) seront en LTS. Alors que chez Ubuntu ou Red Hat à ma connaissance "Machin LTS" désigne une version qui dès le départ est désignée comme maintenue à long terme, sans qu'elle soit encore dans ce cycle de maintenance à long terme. Chez eux, il me semble d'ailleurs que c'est un sous-ensemble de la distribution qui est concerné, et en général pour une seule architecture. [1] [1]https://wiki.debian.org/LTS [2] [2]https://endoflife.date/linux "Longterm (LTS) are usually several "longterm maintenance" kernel releases provided for the purposes of backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels and they don't usually see very frequent releases, especially for older trees." [3] les exceptions actuelles p.ex. à LTS bullseye sont: les backports, plus quelques packages listés dans le package debian-security-support: schaefer@[3]reliant:~$ check-support-status | grep Source * [4]Source:chromium, ended on 2024-01-23 at version 120.0.6099.224-1~deb11u1 * [5]Source:binutils * [6]Source:mozjs78 * [7]Source:qtwebengine-opensource-src * [8]Source:qtwebkit-opensource-src * [9]Source:samba Cette commande explique les raisons, par exemple pour Samba: [10]"Only non-AD Domain Controller use cases are supported. See https://lists.debian.org/debian-security-announce/
Re: [gull] ABUS réseaux
OpenBSD (Surface d'attaque minimale des dépendances de SSH). Quid d'hébergements physiques de machines qui idle à, disons de 1 à 3 W, puis de 5 à 12W, à prix pas cher? (Elles sont petites, un RaspPi et un NUC). On Wed, Aug 21 2024 at 12:58:21 PM +02:00:00, Will van Gulik via gull wrote: Salut la liste, Dans la suite de cela, si un hébergeur local (plutôt qu'un énorme fournisseur allemand ou francais) proposait des containers pour jumphost SSH avec 1 port TCP en v4 et une IPv6 à très bas prix, vous préfèreriez quoi comme distro/OS dessus ? Debian ? Ubuntu ? Alpine ? [Open/Net]BSD ? Arch ? (oui je suis obvious, désolé ;) ) Will On Wed, Aug 21, 2024 at 12:16:12PM +0200, Daniel Cordey via gull wrote: Merci pour ces précisions. Pour Ubuntu, les versions LTS sont celles qui sont publiées les années paires au mois d'avril (sauf erreur). C'est-à-dire les 20.0, 22.04, etc. dc Le 21/08/2024 à 12:06, Marc SCHAEFER via gull a écrit : Salut, On Wed, Aug 21, 2024 at 11:37:46AM +0200, Daniel Cordey via gull wrote: Je suis perplexe... la notion de Linux stable n'existe pas, puisque Linux n'est que le kernel. Et... Debian, c'est un tout avec les notions de versions 'stable', 'testing', etc. Mais il me semble que cette notion de LTS n'a été introduite que pour Ubuntu et Red Hat, du moins il me semble... non ? Il existe une notion vague de kernel Linux LTS [2], dont la durée de vie a été sauf erreur ramenée à 5 ans. Une version de kernel qui entre dans le type de maintenance LTS ne voit alors que des corrections de bugs, backportées par les développeurs kernels, et aucune amélioration de fonctionnalité. Les distributions qui veulent plus que 5 ans doivent gérer 100% elles-mêmes ou forcer une nouvelle version sur l'utilisateur (ce qui est normalement interdit avec Debian). En ce qui concerne Debian LTS (qui comprend quasi toute la distribution Debian [3], pour les architectures i386, amd64, armel et armhf, soit moins que les sauf erreur 11 architectures supportées dans stable avant le passage à LTS): - 3 ans pour stable, supporté par debian-security - 2 ans pour LTS, supporté par debian-lts, ensuite - 5 ans pour Extended LTS, ensuite (offre payante, qui peut être limitée, sur demande à certains packages uniquement) Donc, le public dispose gratuitement de 5 ans de support pour chaque release stable. Et ceux qui paient peuvent disposer de 10 ans en tout. De mémoire, ce processus LTS a commencé en 2014. Avant cela, LTS n'existait pas chez Debian, on mettait à jour tous les 3 ans au plus tard. Chez Debian, TOUTES les versions déclarées stables passent par le cycle LTS [1], voire Extended LTS. Chez Ubuntu (dérivé de Debian) et chez Red Hat, à ma connaissance seules certaines versions vont avoir le support LTS et sont déclarées telles quelles par la distribution. Style une fois toutes les 6 releases, par exemple. En conséquence, Debian LTS désigne n'importe quelle version qui est actuellement en maintenance de type LTS. Debian Extended LTS désigne la même chose, en Extended LTS. Par exemple en juillet 2026, deux versions (bullseye et bookworm, respectivement 11 et 12) seront en LTS. Alors que chez Ubuntu ou Red Hat à ma connaissance "Machin LTS" désigne une version qui dès le départ est désignée comme maintenue à long terme, sans qu'elle soit encore dans ce cycle de maintenance à long terme. Chez eux, il me semble d'ailleurs que c'est un sous-ensemble de la distribution qui est concerné, et en général pour une seule architecture. [1] [1]https://wiki.debian.org/LTS [2] [2]https://endoflife.date/linux "Longterm (LTS) are usually several "longterm maintenance" kernel releases provided for the purposes of backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels and they don't usually see very frequent releases, especially for older trees." [3] les exceptions actuelles p.ex. à LTS bullseye sont: les backports, plus quelques packages listés dans le package debian-security-support: schaefer@[3]reliant:~$ check-support-status | grep Source * [4]Source:chromium, ended on 2024-01-23 at version 120.0.6099.224-1~deb11u1 * [5]Source:binutils * [6]Source:mozjs78 * [7]Source:qtwebengine-opensource-src * [8]Source:qtwebkit-opensource-src * [9]Source:samba Cette commande explique les raisons, par exemple pour Samba: [10]"Only non-AD Domain Controller use cases are supported. See https://lists.debian.org/debian-security-announce/2023/msg00169.html"; Enfin, debian-volatile (qui contient des paquets mis à jour en fonctionnalités même au sein d'une même version stable: style anti-virus) n'est sauf erreur pas non plus maintenu en LTS: seule la toute dernière version est alors maintenue en sécurité. NB: Les discussions se produisent sur la liste debian-lts, qui est publique. ___ gull mailing list [11][email protected] [12]https://forum.linux
Re: [gull] ABUS réseaux
Salut la liste, Dans la suite de cela, si un hébergeur local (plutôt qu'un énorme fournisseur allemand ou francais) proposait des containers pour jumphost SSH avec 1 port TCP en v4 et une IPv6 à très bas prix, vous préfèreriez quoi comme distro/OS dessus ? Debian ? Ubuntu ? Alpine ? [Open/Net]BSD ? Arch ? (oui je suis obvious, désolé ;) ) Will On Wed, Aug 21, 2024 at 12:16:12PM +0200, Daniel Cordey via gull wrote: Merci pour ces précisions. Pour Ubuntu, les versions LTS sont celles qui sont publiées les années paires au mois d'avril (sauf erreur). C'est-à-dire les 20.0, 22.04, etc. dc Le 21/08/2024 à 12:06, Marc SCHAEFER via gull a écrit : Salut, On Wed, Aug 21, 2024 at 11:37:46AM +0200, Daniel Cordey via gull wrote: Je suis perplexe... la notion de Linux stable n'existe pas, puisque Linux n'est que le kernel. Et... Debian, c'est un tout avec les notions de versions 'stable', 'testing', etc. Mais il me semble que cette notion de LTS n'a été introduite que pour Ubuntu et Red Hat, du moins il me semble... non ? Il existe une notion vague de kernel Linux LTS [2], dont la durée de vie a été sauf erreur ramenée à 5 ans. Une version de kernel qui entre dans le type de maintenance LTS ne voit alors que des corrections de bugs, backportées par les développeurs kernels, et aucune amélioration de fonctionnalité. Les distributions qui veulent plus que 5 ans doivent gérer 100% elles-mêmes ou forcer une nouvelle version sur l'utilisateur (ce qui est normalement interdit avec Debian). En ce qui concerne Debian LTS (qui comprend quasi toute la distribution Debian [3], pour les architectures i386, amd64, armel et armhf, soit moins que les sauf erreur 11 architectures supportées dans stable avant le passage à LTS): - 3 ans pour stable, supporté par debian-security - 2 ans pour LTS, supporté par debian-lts, ensuite - 5 ans pour Extended LTS, ensuite (offre payante, qui peut être limitée, sur demande à certains packages uniquement) Donc, le public dispose gratuitement de 5 ans de support pour chaque release stable. Et ceux qui paient peuvent disposer de 10 ans en tout. De mémoire, ce processus LTS a commencé en 2014. Avant cela, LTS n'existait pas chez Debian, on mettait à jour tous les 3 ans au plus tard. Chez Debian, TOUTES les versions déclarées stables passent par le cycle LTS [1], voire Extended LTS. Chez Ubuntu (dérivé de Debian) et chez Red Hat, à ma connaissance seules certaines versions vont avoir le support LTS et sont déclarées telles quelles par la distribution. Style une fois toutes les 6 releases, par exemple. En conséquence, Debian LTS désigne n'importe quelle version qui est actuellement en maintenance de type LTS. Debian Extended LTS désigne la même chose, en Extended LTS. Par exemple en juillet 2026, deux versions (bullseye et bookworm, respectivement 11 et 12) seront en LTS. Alors que chez Ubuntu ou Red Hat à ma connaissance "Machin LTS" désigne une version qui dès le départ est désignée comme maintenue à long terme, sans qu'elle soit encore dans ce cycle de maintenance à long terme. Chez eux, il me semble d'ailleurs que c'est un sous-ensemble de la distribution qui est concerné, et en général pour une seule architecture. [1] [1]https://wiki.debian.org/LTS [2] [2]https://endoflife.date/linux "Longterm (LTS) are usually several "longterm maintenance" kernel releases provided for the purposes of backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels and they don't usually see very frequent releases, especially for older trees." [3] les exceptions actuelles p.ex. à LTS bullseye sont: les backports, plus quelques packages listés dans le package debian-security-support: schaefer@[3]reliant:~$ check-support-status | grep Source * [4]Source:chromium, ended on 2024-01-23 at version 120.0.6099.224-1~deb11u1 * [5]Source:binutils * [6]Source:mozjs78 * [7]Source:qtwebengine-opensource-src * [8]Source:qtwebkit-opensource-src * [9]Source:samba Cette commande explique les raisons, par exemple pour Samba: [10]"Only non-AD Domain Controller use cases are supported. See https://lists.debian.org/debian-security-announce/2023/msg00169.html"; Enfin, debian-volatile (qui contient des paquets mis à jour en fonctionnalités même au sein d'une même version stable: style anti-virus) n'est sauf erreur pas non plus maintenu en LTS: seule la toute dernière version est alors maintenue en sécurité. NB: Les discussions se produisent sur la liste debian-lts, qui est publique. ___ gull mailing list [11][email protected] [12]https://forum.linux-gull.ch/mailman/listinfo/gull -- -- Daniel Cordey Mail : [13][email protected] Tel Esp : +34 623 517-666 Tel And : +376 692-550 References 1. https://wiki.debian.org/LTS 2. https://endoflife.date/linux 3. reliant:~$ 4. Source:chromium 5. Source:binutils 6. Source:mozjs78 7. Source:qtwebengine-opensource-
Re: [gull] Abus réseaux
Hello, On Wed, Aug 21, 2024 at 08:56:39AM +0200, felix via gull wrote: > > Eviter Debian stable, systemd, OpenSSL, etc :) > > Tu veux dire ``Linux stable'', > (Debian stable utilise Linux LTS, il me semble) Non, Debian stable: le document cité mentionne le problème du backporting (que cela soit au kernel, mais aussi aux autres packages que le kernel bien sûr). Je ne connais pas d'ailleurs la relation exacte entre le kernel Linux backporté dans stable, oldstable, LTS et le "kernel LTS" -- dont la durée de vie, sauf erreur, est aujourd'hui inférieure à ce que Debian semble assurer avec son LTS dans certains cas. C'est peut-être couplé au début (avec de rares patches spécifiques Debian), mais fatalement après un certain temps, ça devient une tâche 100% Debian. Je dois dire que je n'ai jamais, apparemment, eu de souci avec ça -- au contraire, certains bugs graves (le dernier: xz) sont apparus sur unstable et testing et jamais sur stable ou oldstable. Le mail original mentionnait d'ailleurs les 0-days: ceux-ci sont par définition non patché, quelque soit la version. > Cela dit, il est vrai que certains choix récents de Debian > sont discutables (systemd par défaut, entre autres)... Oui, mais on peut faire sans. J'ai systemd sur mes hosts, mais jamais dans les conteneurs, par exemple. Par contre, ce qui est discutable (et semble concerner l'ensemble des distributions Linux) ce sont les dépendances additionnelles injectées dans, par exemple, SSH, à cause de systemd. Quelqu'un gérant un bastion host aurait peut-être intérêt à recompiler openssh sans tout ça, ou à passer p.ex. à OpenBSD. On avait déjà mentionné l'affreuse surface d'attaque de systemd (libs de compression, chiffrement, etc). Quant à pfsense, j'avais testé dans le passé, mais c'est trop haut niveau pour moi. Et sur plateforme apu2, il m'avait semblé que la performance était inférieure à ce que j'arrivais à faire avec Debian. ___ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Abus réseaux
Le Tue, Aug 20, 2024 at 06:56:38PM +0200, Marc SCHAEFER via gull a écrit : > > Eviter Debian stable, systemd, OpenSSL, etc :) Tu veux dire ``Linux stable'', (Debian stable utilise Linux LTS, il me semble) Cela dit, il est vrai que certains choix récents de Debian sont discutables (systemd par défaut, entre autres)... -- Félix ___ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Abus réseaux
Hello, Pour ce qui est de *BSD et des firewalls, nous utilisons à itopie le système pfSense qui tourne sur FreeBSD et qui est plutôt stable et bien documenté. La version communautaire est un système libre (apache licence) avec un grand frère commercial (pfSense+). Il y a sauf erreur un fork "plus libre" OPNSense, mais je n'a pas d'expérience. a+ Samuel Le 20.08.24 à 18:56, Marc SCHAEFER via gull a écrit : Hello, On Tue, Aug 20, 2024 at 01:22:07PM +0200, Philippe Strauss via gull wrote: toujours recompiler son noyau en appliquant les recommendations de configuration de ce site: https://kspp.github.io/Recommended_Settings Effectivement, on est devenu fainéants :) Je dois toutefois mentionner que ces derniers 20 ans, il ne me semble pas avoir eu de problèmes de ce type: les bugs venaient plutôt des applications haut niveau (donc mise en place de WAF, blocklists, etc). Ou carrément passer à un Debian/BSD ou, pour certaines fonctions spécifiques (firewall) envisager OpenBSD? Il y a forcément un risque de perte de compétence (on ne peut pas être bon en Linux et en *BSD), mais pourquoi pas: j'y songe! https://madaidans-insecurities.github.io/guides/linux-hardening.html Eviter Debian stable, systemd, OpenSSL, etc :) ___ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull -- ___ Samuel Chenal [email protected] https://www.ll-dd.ch ___ Empreinte GPG : BD25 7B5F 442B DF2D 4E28 8203 B2A2 7269 4E00 5136 Merci d'utiliser des formats de fichiers ouverts (comme ODF) ! ___ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Abus réseaux
Je me suis pris un mandat de renseignement économique. Curieux de savoir combien ces gens ont mis sur la table. Ils ont utilisé des 0day, d'expérience cela change complétement la donne des bones pratiques en matière de sécurité (notamment rolling release vs. stable release). J'ai eut fin 2022 le trou du stack wifi de Linux en primeur, en 0day. Routeur WiFi largement infiltré, avec un toolkit, même des tentatives de MITM SSH, je me suis fais baiser une fois. Je crains que dès que t'as 50'000 CHF à protéger, il faille passer par où je suis passé en terme de sécu, mais encore une fois je serais très curieux de connaître le montant mis sur la table et ce dernier chiffre. ___ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Abus réseaux
Hello, On Tue, Aug 20, 2024 at 01:22:07PM +0200, Philippe Strauss via gull wrote: > toujours recompiler son noyau en appliquant les recommendations > de configuration de ce site: > https://kspp.github.io/Recommended_Settings Effectivement, on est devenu fainéants :) Je dois toutefois mentionner que ces derniers 20 ans, il ne me semble pas avoir eu de problèmes de ce type: les bugs venaient plutôt des applications haut niveau (donc mise en place de WAF, blocklists, etc). Ou carrément passer à un Debian/BSD ou, pour certaines fonctions spécifiques (firewall) envisager OpenBSD? Il y a forcément un risque de perte de compétence (on ne peut pas être bon en Linux et en *BSD), mais pourquoi pas: j'y songe! > https://madaidans-insecurities.github.io/guides/linux-hardening.html Eviter Debian stable, systemd, OpenSSL, etc :) ___ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Abus réseaux
A mon avis un point extrêmement important est de ne pas faire confiance aux noyaux de distributions qui privilègient le fonctionnement très performant sur une vaste gamme de matériel au détriment de la sécurité. Sur les machine connectées à internet, toujours recompiler son noyau en appliquant les recommendations de configuration de ce site: https://kspp.github.io/Recommended_Settings Aussi, les noyaux récents (6.10.x, 6.11.0-rcX) incorporent beaucoup de "mitigation" concernant les voies standards (buffer overflow, return oriented programming) d'infiltration. Deux liens avec des resources de haute qualité concernant la sécurisation des couches basses de Linux: https://vez.mrsk.me/linux-hardening https://madaidans-insecurities.github.io/guides/linux-hardening.html A+ ___ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Abus réseaux
Bonjourm On Sun, Aug 18, 2024 at 06:59:21PM +0200, Marc SCHAEFER via gull wrote: > Votre machine est souvent attaquée? Suite à quelques questions hors liste, voici quelques recommandations s'il vous faut du SSH ouvert à Internet: - vous pourriez mettre votre SSH sur un autre port que 22, mais dans mon expérience en 5 à 6 semaines vous serez découvert - n'arrivez-vous pas à restreindre avec une liste blanche? - limitez cela à un seul host (bastion), et tous les autres serveurs SSH n'acceptent des connexions que de lui; ça peut être un conteneur hetzner à 6 EUR/mois; avec ssh -o ProxyCommand=... il est facile de passer par le bastion host SANS lui donner votre mot de passe et SANS le mode agent de SSH (qui lui donne l'autorisation de signer avec votre clé privée) - utilisez un VPN (sur votre conteneur à adresse IP publique, ou évt. un service VPN), p.ex. OpenVPN, wireguard, etc. - utilisez un knockd: il faut faire 3 telnet sur les ports X, Y, et Z, de préference non ordonnés, et ça ouvre pour 5 minute SSH sur le port ) -- en dehors des 5 minutes l'ensemble de ces ports répondent comme des ports non desservis - bloquez rapidement avec fail2ban dès 1 essai infructueux (attention au DoS si vous ne vous connectez pas par clé privée) - ajoutez un deuxième facteur d'authentification avec le module PAM pam_google_authenticator.so - logcheck pour voir vos logs Et bien sûr maintenez vos systèmes à jour (shodan.io a des outils pour trouver des versions vulnérables). ___ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
