La sécurité de nos serveurs

Dernière révision: 2023-12-19

 

Avec les nouvelles lois actuellement en place depuis 2023, de nombreux clients se sont tournés vers des entreprises spécialisées en cybersécurité pour effectuer des audits sur leur site web. Dans bien des cas, ces entreprises renvoient un rapport incomplet et dépourvu de contexte, indiquant à leur client que leur site est exposé à des failles de sécurité importantes. Ce type de service, dépourvu d'explications, est souvent perçu comme malhonnête et provoque plus d'angoisse chez le client payeur qu'autre chose.

Dans cet article, nous allons tenter de démystifier cette situation et vous expliquer que les résultats de ces tests sont biaisés et non véridiques.

 

Voici un exemple typique de "failles" découvertes lors de ces audits de sécurité :

 

CPE Based Vulnerabilities for OpenSSH

 

CPE Based Vulnerabilities for ISC BIND

 

TLS Version 1.X Protocol Detection

 

La sécurité de votre site web est notre priorité absolue, et nous sommes fiers d'utiliser CloudLinux comme système d'exploitation sur votre serveur.

Voici une plongée technique dans la manière dont CloudLinux mitige les failles de sécurité pour assurer une protection robuste.

 

1. CageFS : Isolation Multi-Niveau pour une Résistance Inébranlable

CageFS adopte une approche de virtualisation au niveau des utilisateurs, créant des environnements d'exécution isolés pour chaque site web.
Cette isolation multi-niveau garantit que même en cas où un site serrait compromis, les autres restent intacts, grâce à des systèmes de fichiers montés spécifiquement pour chaque utilisateur, limitant ainsi les attaques potentielles.

 

2. ModSecurity : Pare-feu Applicatif Web (WAF) Intelligemment Configuré

ModSecurity, notre bouclier avancé, fonctionne comme un pare-feu applicatif web (WAF) personnalisé.
Avec des règles personnalisées spécifiques à notre environnement, il analyse en temps réel chaque requête HTTP, détectant les anomalies et bloquant les attaques avant qu'elles ne puissent causer des dégâts.
Les règles ModSecurity sont mises à jour régulièrement pour rester en phase avec les dernières menaces.

 

3. RPM Patch Management : Sécurisation Dynamique contre les CVE

CloudLinux utilise RPM pour gérer les paquets logiciels.
Ce système permet une veille constante des bases de données CVE (Common Vulnerabilities and Exposures).
Les mises à jour sont automatiquement déployées pour remédier aux failles de sécurité connues, assurant ainsi une protection proactive.
Les utilisateurs bénéficient ainsi de correctifs rapides et efficaces sans nécessiter une intervention manuelle.

 

4. KernelCare : Sécurisation Continue du Noyau sans Interruption de Service

Le noyau Linux est au cœur de la sécurité du serveur.
KernelCare garantit une mise à jour en temps réel du noyau, sans nécessiter de redémarrage du système.
Cela élimine les fenêtres de vulnérabilité liées aux mises à jour du noyau et maintient la stabilité du serveur tout en assurant une sécurité continue.

 

5. Support et Maintenance Continue :

CloudLinux propose un support actif et des mises à jour régulières pour garantir la sécurité continue de l'environnement.
Les équipes de CloudLinux travaillent à la résolution rapide des problèmes de sécurité et à la mise en œuvre de correctifs.

 

CloudLinux est une armure complète, intégrant des technologies pointues pour prévenir et répondre aux menaces de sécurité émergentes.
Avec ces mesures en place, votre site web est non seulement sécurisé contre les failles de sécurité, mais également équipé pour faire face à un paysage numérique en constante évolution.

 

 

 

Lorsqu'un audit de sécurité est réalisé sur un serveur mutualisé, plusieurs facteurs peuvent induire en erreur et créer des inquiétudes inutiles pour les utilisateurs.
Cependant, CloudLinux propose des solutions innovantes qui contribuent à résoudre ces problèmes de manière efficace.
Voici comment un audit de sécurité peut être trompeur dans un environnement mutualisé et comment CloudLinux intervient pour atténuer ces préoccupations :

 

  1. Partage des Ressources :
    Dans un environnement mutualisé, plusieurs utilisateurs partagent les mêmes ressources.
    Un audit peut détecter des activités ou vulnérabilités sur le serveur, mais il peut être difficile de les attribuer spécifiquement à un seul utilisateur.

  2. Rapports Génériques :
    Certains outils d'audit génèrent des rapports basés sur des modèles génériques qui ne tiennent pas compte des particularités d'un environnement mutualisé.
    Les alertes générées peuvent ne pas être spécifiques à un utilisateur, provoquant ainsi des inquiétudes non fondées.

  3. Dépendance du Fournisseur d'Hébergement :
    La sécurité sur un serveur mutualisé dépend également des pratiques de sécurité du fournisseur d'hébergement.
    Les vulnérabilités ou les activités suspectes détectées peuvent provenir d'autres utilisateurs partageant le même serveur, impactant ainsi la perception de la sécurité du serveur.

  4. Limitations dans la Détection d'Intrusion :
    Certains outils de détection d'intrusion peuvent générer des alertes basées sur des comportements anormaux sans comprendre pleinement le contexte de l'environnement mutualisé.
    Cela peut conduire à des fausses alertes qui ne reflètent pas nécessairement une menace réelle pour le site spécifique.

  5. Faux Positifs dans les Scans de Vulnérabilités :
    Les scans automatisés de vulnérabilités peuvent parfois générer des faux positifs en interprétant mal les configurations spécifiques à un environnement mutualisé, conduisant ainsi à des alertes erronées.

 

Si on regarde les quelques exemples cités plus haut, on peut faire une recherche sur un de nos serveur au hasard pour vérifier que les correctifs de sécurité ont bel et bien étés appliqués:

Exemple CPE Based Vulnerabilities for OpenSSH:

la commande suivante sur le serveur permet d'afficher le journal des changements pour le module openssh:
rpm -q --changelog $(rpm -qa | grep openssh)  |more

voici une partie du résumé de la réponse du serveur:

  • Thu Jul 20 2023 Dmitry Belyavskiy <dbelyavs@redhat.com> - 7.4p1-23 + 0.10.3-2
    - Avoid remote code execution in ssh-agent PKCS#11 support
      Resolves: CVE-2023-38408

    * Thu Sep 30 2021 Dmitry Belyavskiy <dbelyavs@redhat.com> - 7.4p1-22 + 0.10.3-2
    - avoid segfault in Kerberos cache cleanup (#1999263)
    - fix CVE-2021-41617 (#2008884)

    * Tue Jun 25 2019 Jakub Jelen <jjelen@redhat.com> - 7.4p1-21 + 0.10.3-2
    - Avoid double comma in the default cipher list in FIPS mode (#1722446)

    * Tue May 21 2019 Jakub Jelen <jjelen@redhat.com> - 7.4p1-20 + 0.10.3-2
    - Revert the updating of cached passwd structure (#1712053)

    * Mon Mar 04 2019 Jakub Jelen <jjelen@redhat.com> - 7.4p1-19 + 0.10.3-2
    - Update cached passwd structure after PAM authentication (#1674541)

    * Wed Feb 13 2019 Jakub Jelen <jjelen@redhat.com> - 7.4p1-18 + 0.10.3-2
    - invalidate supplemental group cache used by temporarily_use_uid()
      when the target uid differs (#1583735)

    * Mon Jan 14 2019 Jakub Jelen <jjelen@redhat.com> - 7.4p1-17 + 0.10.3-2
    - Fix for CVE-2018-15473 (#1619079)
    - Enable GCM mode for AES ciphers in FIPS mode (#1600869)

    * Fri Nov 24 2017 Jakub Jelen <jjelen@redhat.com> - 7.4p1-16 + 0.10.3-2
    - Fix for CVE-2017-15906 (#1517226)

    * Mon Nov 06 2017 Jakub Jelen <jjelen@redhat.com> - 7.4p1-15 + 0.10.3-2
    - Do not hang if SSH AuthorizedKeysCommand output is too large (#1496467)

 

 

Exemple CPE Based Vulnerabilities for ISC BIND:

la commande suivante sur le serveur permet d'afficher le journal des changements pour le module openssh:
rpm -q --changelog $(rpm -qa | grep bind )  |more

voici une partie du résumé de la réponse du serveur:

 

  • Mon Sep 25 2023 Stepan Broz <sbroz@redhat.com> - 32:9.11.4-26.P2.15
    - Limit the amount of recursion possible in control channel (CVE-2023-3341)

    * Mon Jul 03 2023 Stepan Broz <sbroz@redhat.com> - 32:9.11.4-26.P2.14
    - Prevent the cache going over the configured limit (CVE-2023-2828)

    * Wed Dec 14 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.13
    - Tighten cache protection against record from forwarders (CVE-2021-25220)

    * Wed Dec 14 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.12
    - Include test of forwarders (CVE-2021-25220)

    * Thu Sep 29 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.11
    - Prevent excessive resource use while processing large delegations.
      (CVE-2022-2795)

    * Thu Sep 22 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.10
    - Fix memory leak in ECDSA verify processing (CVE-2022-38177)
    - Fix memory leak in EdDSA verify processing (CVE-2022-38178)

    * Mon Jan 24 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.9
    - Fix possible assertion failure isc_refcount_current == 0 in free_rbtdb
      (#1935152)

    * Thu Oct 14 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.8
    - Prevent a race after zone load (#2011220)

    * Tue Jul 13 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.7
    - Apply again patch 172, got removed by mistake

    * Mon May 17 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.6
    - Insufficient IXFR checks could lead to assertion failure (CVE-2021-25214)

    * Tue Apr 27 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.5
    - Possible assertion failure on DNAME processing (CVE-2021-25215)

    * Mon Feb 15 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.4
    - Fix off-by-one bug in ISC SPNEGO implementation (CVE-2020-8625)

    * Fri Nov 06 2020 Tomas Korbar <tkorbar@redhat.com> - 32:9.11.4-26.P2.3
    - Fix inline re-signing (#rh1889902)

    * Fri Oct 02 2020 Tomas Korbar <tkorbar@redhat.com> - 32:9.11.4-26.P2.2
    - Fix unsupported algorithms validation (#rh1769876)

    * Wed Aug 26 2020 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.1
    - Fix tsig-request verify (CVE-2020-8622)
    - Prevent PKCS11 daemon crash on crafted packet (CVE-2020-8623)
    - Correct update-policy type subdomain to match documentation (CVE-2020-8624)

    * Fri May 29 2020 Artem Egorenkov <aegorenk@redhat.com> - 32:9.11.4-26.P2
    - Fix EDNS512 loops on broken servers
    [root@box5 ~]# rpm -q --changelog $(rpm -qa | grep bind )  |more
    * Mon Sep 25 2023 Stepan Broz <sbroz@redhat.com> - 32:9.11.4-26.P2.15
    - Limit the amount of recursion possible in control channel (CVE-2023-3341)

    * Mon Jul 03 2023 Stepan Broz <sbroz@redhat.com> - 32:9.11.4-26.P2.14
    - Prevent the cache going over the configured limit (CVE-2023-2828)

    * Wed Dec 14 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.13
    - Tighten cache protection against record from forwarders (CVE-2021-25220)

    * Wed Dec 14 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.12
    - Include test of forwarders (CVE-2021-25220)

    * Thu Sep 29 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.11
    - Prevent excessive resource use while processing large delegations.
      (CVE-2022-2795)

    * Thu Sep 22 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.10
    - Fix memory leak in ECDSA verify processing (CVE-2022-38177)
    - Fix memory leak in EdDSA verify processing (CVE-2022-38178)

    * Mon Jan 24 2022 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.9
    - Fix possible assertion failure isc_refcount_current == 0 in free_rbtdb
      (#1935152)

    * Thu Oct 14 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.8
    - Prevent a race after zone load (#2011220)

    * Tue Jul 13 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.4-26.P2.7
    - Apply again patch 172, got removed by mistake

 

Exemple TLS Version 1.X Protocol Detection:

Supporter de vieux protocoles TLS (Transport Layer Security) et des anciens chiffrements (ciphers) peut présenter des risques pour la sécurité, mais uniquement pour les utilisateurs qui utilisent ces protocoles, ces risques peuvent sont nuls si l'utilisateur maintient son système à jour.

Comme nous travaillons avec toutes sortes de clients, certains d'entre eux ont de très vieux systèmes qui dépendent de ces technologies.
Par exemple, une entreprise avec des automates programmés sur un vieil appareil fonctionnant sur un vieux système pourrais avoir besoin d'envoyer des rapports par courriels. Le système d'exploitation peut ne pas supporter les nouvelles technologies et il est préférable d'utiliser une encryption à risque plutôt que de ne pas encrypter dutout.Ce genre de machine peut couter des milliers de dollars pour mettre à jour et le cout ne justifie pas toujours l'investissement, les entreprises utilisant ces vieilles technologies sont souvent au fait des risques et appliquent des sécurités à l'interne pour mitiger le tout. Le fait que EUX peuvent utiliser une vieille technologie ne vous met pas dutout à risque puisque VOUS utilisez une technologie plus récente vu que votre système le supporte. Seul EUX sont à risque si les conditions sont rencontrées.

Voici quelques explications plus techniques sur pourquoi cela pourrait ne pas être nécessairement dangereux pour un utilisateur à jour :

  1. Compatibilité avec des Systèmes Anciens :

    • Explication : La prise en charge de vieux protocoles et de vieux chiffrements peut être nécessaire pour permettre la communication avec des systèmes ou des applications plus anciennes qui ne prennent en charge que ces versions.
    • À jour : Si l'utilisateur maintient son système à jour, il peut bénéficier des correctifs de sécurité qui atténuent les vulnérabilités potentielles associées à ces anciens protocoles et chiffrements.
    •  

  2. Normes de Sécurité Actuelles :

    • Explication : Les protocoles et les chiffrements plus anciens peuvent ne pas respecter les normes de sécurité actuelles, mais avec des mises à jour régulières, les nouvelles versions sont généralement conformes aux dernières normes de sécurité.
    • À jour : En maintenant son système à jour, l'utilisateur peut bénéficier des améliorations continues de la sécurité intégrées dans les versions les plus récentes des protocoles et des chiffrements.

  3. Risque en Fonction de l'Utilisation :

    • Explication : Le risque lié à la prise en charge de vieux protocoles dépend de l'utilisation spécifique de l'application ou du service. Dans certains cas, les risques peuvent être acceptables.
    • À jour : Les mises à jour régulières peuvent adapter la sécurité du système en fonction des nouvelles menaces et des meilleures pratiques de l'industrie.

  4. Cohérence avec l'Écosystème :

    • Explication : Dans certaines situations, maintenir une certaine compatibilité avec des versions plus anciennes peut être essentiel pour assurer la cohérence avec l'ensemble de l'écosystème logiciel.
    • À jour : En maintenant les logiciels à jour, l'utilisateur peut bénéficier des compromis entre la compatibilité et la sécurité introduits dans les versions plus récentes.

 

Nous pouvons donc constater que malgré le fait que les audits de sécurité disent que le serveur est en faute ou à risque, la réalité est toute autre.
Les audits ne se fient qu'à un numéro de version uniquement et font fie des correctifs appliqués, induisant en erreur le client.

 

 

Dans le cas d'un serveur Web, une nouvelle version d'un module n'est pas toujours la meilleure approche.

Dans certains cas, il peut sembler contre-intuitif d'opter pour une version logicielle plus ancienne plutôt que pour la dernière version. Cependant, il existe des arguments en faveur de cette approche, en particulier lorsqu'il s'agit d'assurer la sécurité d'un système.

Voici quelques raisons expliquant pourquoi il peut être plus sécuritaire d'avoir une version ancienne avec les correctifs de sécurité appliqués plutôt qu'une version récente :

 

  1. Stabilité des Correctifs :
    Les versions plus anciennes d'un logiciel ont souvent subi des tests et des évaluations de sécurité approfondis au fil du temps.
    Les correctifs de sécurité appliqués à ces versions ont généralement été éprouvés dans des environnements de production, ce qui peut contribuer à une stabilité accrue par rapport aux correctifs appliqués à une version plus récente.

  2. Maturité des Correctifs :
    Les correctifs de sécurité pour les versions plus anciennes ont eu le temps de mûrir, de s'adapter et de répondre à des scénarios de sécurité variés.
    Cela signifie que les vulnérabilités spécifiques qui ont pu être découvertes et corrigées dans ces versions ont pu bénéficier d'une attention approfondie.

  3. Compatibilité des Applications :
    Les applications et plugins tiers peuvent être optimisés pour fonctionner avec des versions logicielles plus anciennes.
    Une migration vers une version plus récente peut entraîner des problèmes de compatibilité et les correctifs appliqués peuvent maintenir une version existante en évitant des ruptures potentielles.

  4. Réduction des Nouvelles Vulnérabilités :
    Les nouvelles versions de logiciels peuvent introduire de nouvelles fonctionnalités, mais avec ces ajouts peuvent également venir de nouvelles vulnérabilités.
    En optant pour une version ancienne avec les correctifs de sécurité appliqués, on minimise le risque d'introduction de nouvelles failles de sécurité.

  5. Cycle de Vie du Support :
    Les versions plus anciennes qui ne bénéficient plus du support officiel peuvent encore recevoir des correctifs de sécurité de la part de la communauté open source.
    Dans certains cas, cela peut prolonger le cycle de vie d'une version plus ancienne tout en maintenant un niveau de sécurité acceptable.

  6. Moins de Surface d'Attaque :
    Les nouvelles versions peuvent inclure des fonctionnalités étendues qui augmentent potentiellement la surface d'attaque.
    Une version plus ancienne, bien qu'elle puisse manquer de certaines fonctionnalités, peut également offrir une surface d'attaque réduite, ce qui peut être avantageux en termes de sécurité.

 

Donc, en résumé, les versions plus anciennes des modules, si leurs correctifs de sécurité sont efficacement appliqués, peuvent être plus sécuritaires et plus stables que les nouvelles versions qui proposent les mêmes correctifs mais avec de nouvelles fonctionnalités.



Si vous avez des inquiétudes face à la sécurité de nos serveurs, n'hésitez pas à communiquer directement avec nous.

  • 0 Utilisateurs l'ont trouvée utile
Cette réponse était-elle pertinente?