/var/log/monapp/*.log {
    daily
    size 500M
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    create 0640 monapp monapp
    postrotate
        systemctl reload monapp.service > /dev/null 2>&1 || true
    endscript
}

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        if [ -d /run/systemd/system ]; then
            systemctl reload nginx.service > /dev/null 2>&1 || true
        fi
    endscript
}

The post Automatiser le nettoyage et la rotation des logs first appeared on DEMARCQ.NET.

Gestion des accès SSH : Bannir les mots de passe au profit des clés de sécurité (FIDO2 / YubiKey)

Dans le paysage cybernétique moderne, le protocole SSH (Secure Shell) constitue l’épine dorsale de l’administration système. Pourtant, la méthode d’authentification la plus couramment répandue — le couple identifiant/mot de passe — représente l’un des maillons les plus faibles de la chaîne de sécurité informatique. Attaques par force brute, hameçonnage ciblé, pulvérisation de mots de passe (password spraying) ou réutilisation d’identifiants compromis : les vecteurs d’attaque exploitant cette vulnérabilité sont nombreux et redoutablement efficaces.

L’authentification par clés SSH traditionnelles (RSA ou Ed25519 stockées sur le disque local) a apporté un gain de sécurité majeur, mais elle n’est pas exempte de risques. Un logiciel malveillant exécuté sur le poste d’un administrateur ou une sauvegarde de poste non chiffrée peut entraîner le vol pur et simple de la clé privée. Pour éliminer définitivement ces risques, l’industrie s’oriente désormais vers le modèle Zero Trust Hardware-Bound en s’appuyant sur la norme FIDO2 / WebAuthn via des clés de sécurité physiques comme la YubiKey.

Les limites des méthodes d’authentification traditionnelles

Pour comprendre l’impératif de migration vers FIDO2, il convient de dresser le bilan des faiblesses des mécanismes historiques.

1. Le mot de passe : un risque permanent

L’utilisation de mots de passe pour se connecter à un serveur SSH expose l’infrastructure à :

• Des attaques automatisées continues : Tout serveur exposé sur Internet subit quotidiennement des milliers de tentatives de connexion par mot de passe via des bots.

• L’ingénierie sociale : Un mot de passe peut être saisi par inadvertance sur un portail de hameçonnage imitant une interface d’administration.

• La fatigue décisionnelle : Les utilisateurs ont tendance à réutiliser ou à simplifier leurs mots de passe si aucune contrainte matérielle ne leur est imposée.

2. Les clés SSH classiques stockées sur disque

Bien que nettement supérieures aux mots de passe, les clés RSA ou Ed25519 standards stockées dans le répertoire ~/.ssh/ posent d’autres défis :

• Le vol de clé privée : Un malware (ex: infostealer) présent sur la machine cliente peut lire le fichier id_ed25519 et l’exfiltrer. Même si le fichier est protégé par une phrase explicative (passphrase), celle-ci peut être interceptée par un keylogger.

• La prolifération des clés (Key Sprawl) : Sans gestion centralisée, suivre quelle clé appartient à qui et sur quels serveurs elle est autorisée devient rapidement ingérable.

La révolution FIDO2 et OpenSSH : Comment ça fonctionne ?

Depuis la version 8.2 d’OpenSSH (publiée au début de l’année 2020), le protocole intègre nativement la prise en charge des jetons de sécurité matériels FIDO2 / U2F. Cette intégration repose sur deux nouveaux types de clés :

• ecdsa-sk (ECDSA Security Key)

• ed25519-sk (Ed25519 Security Key — vivement recommandée)

Le suffixe -sk signifie Security Key. Lorsqu’une clé de ce type est générée, la véritable clé privée ne réside jamais sous forme lisible sur le disque dur de l’ordinateur. Elle est soit générée et conservée exclusivement dans le composant cryptographique sécurisé de la YubiKey, soit chiffrée par le composant matériel sous la forme d’un key handle.

Les mécanismes de protection intégrés

1. Pression physique obligatoire (User Presence) : Lors de chaque tentative de connexion SSH, la YubiKey clignote. L’utilisateur doit toucher physiquement le capteur de la clé pour valider la transaction. Un logiciel malveillant distant ne peut pas simuler cette interaction physique.

2. Code PIN / Biométrie (User Verification) : FIDO2 permet d’exiger la saisie d’un code PIN local configuré sur la YubiKey ou une empreinte digitale (pour les modèles YubiKey Bio). Il s’agit d’un véritable facteur d’authentification multifacteur (MFA) matériel : ce que j’ai (la clé physique) + ce que je sais/ce que je suis (le PIN ou l’empreinte).

3. Résistance au hameçonnage : Les mécanismes FIDO2 lient l’authentification à l’identité du matériel et au contexte, rendant les attaques par relais (Man-in-the-Middle) inopérantes.

Clés résidantes (Resident Keys) vs Clés non-résidantes

OpenSSH et FIDO2 proposent deux modes de fonctionnement distincts :

PortabilitéIl faut copier le fichier de clé publique/stump sur la machine cliente.Cas d’usagePoste de travail fixe d’un administrateur.

Guide pratique de mise en œuvre

Étape 1 : Générer la clé SSH FIDO2 sur la YubiKey

Sur la machine cliente (qui doit disposer d’OpenSSH 8.2 ou supérieur et des bibliothèques libfido2), exécutez la commande suivante :

# Génération d'une clé Ed25519 sécurisée par matériel (mode résidant recommandé)
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "admin-secu@entreprise.com"

Explication des options :

• -t ed25519-sk : Spécifie le type d’algorithme sécurisé par matériel.

• -O resident : Enregistre la clé dans le composant interne de la YubiKey pour pouvoir la récupérer sur n’importe quel poste.

• -O verify-required : Force la vérification du code PIN de la YubiKey lors de chaque signature SSH (MFA strict).

Lors de l’exécution, le système vous demandera d’entrer le code PIN de votre YubiKey, puis de toucher le capteur lumineux.

Étape 2 : Déployer la clé publique sur le serveur cible

Comme pour une clé classique, copiez la clé publique générée (~/.ssh/id_ed25519_sk.pub) sur le serveur distant dans le fichier ~/.ssh/authorized_keys de l’utilisateur concerné :

ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@serveur-distant.com

Étape 3 : Endurcir la configuration du serveur SSH (sshd_config)

Une fois la clé configurée et la connexion validée, il est impératif de désactiver totalement l’authentification par mot de passe sur le serveur. Éditez le fichier /etc/ssh/sshd_config :

# Désactivation totale des mots de passe
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Interdiction de la connexion root par mot de passe
PermitRootLogin prohibit-password

# Exigence stricte des types de clés autorisés (optionnel mais recommandé)
PubkeyAcceptedKeyTypes sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com

Rechargez ensuite le service SSH pour appliquer les modifications :

sudo systemctl reload sshd

Gestion de la résilience et des cas de perte

L’une des réticences majeures lors du passage aux clés physiques concerne la perte, le vol ou la détérioration de la YubiKey. Une stratégie d’accès basée sur la clé physique doit obligatoirement inclure un plan de secours :

1. La règle des deux clés (Primary & Backup) : Tout administrateur doit configurer au minimum deux YubiKeys physiques. La clé principale est portée au quotidien, tandis que la clé de secours est conservée dans un coffre-fort physique sécurisé. Les deux clés publiques sont inscrites dans le fichier authorized_keys.

2. L’utilisation de certificats SSH (OpenSSH CA) : Pour les infrastructures d’envergure, plutôt que de copier des clés publiques sur des milliers de serveurs, il est préférable de déployer une Autorité de Certification (CA) SSH. La CA signe la clé publique temporaire de l’administrateur après validation par la YubiKey.

3. Accès d’urgence d’infrastructures (Break-Glass) : Conserver un accès d’urgence hors-ligne (ex: console KVM/IPMI protégée par un mot de passe maître complexe stocké sous scellé) pour parer à tout blocage.

Bilan : Un alignement parfait sur les exigences NIS 2 et Zero Trust

En éliminant les mots de passe au profit des clés de sécurité matérielles FIDO2 / YubiKey, les organisations réduisent drastiquement leur surface d’attaque. Cette démarche s’inscrit pleinement dans les architectures de sécurité modernes Zero Trust et répond aux exigences de renforcer la sécurité des accès à privilèges imposées par les réglementations européennes telles que NIS 2. Le coût modéré d’un jeton physique est infiniment inférieur à celui d’une compromission globale issue d’un vol d’identifiant SSH.

Pourquoi faire appel à un infogérant pour gérer vos accès FIDO2 / YubiKey ?

Bien que la technologie FIDO2 soit redoutablement efficace, sa mise en œuvre à l’échelle d’une entreprise implique des défis organisationnels et techniques. Faire appel à un expert en infogérance permet de sécuriser cette transition.

1. Expertise technique et intégration sur mesure

Un prestataire spécialisé en infogérance vous accompagne dans l’audit de votre parc (serveurs Linux, instances Cloud AWS/GCP/Azure) pour concevoir une politique d’accès Zero Trust conforme aux exigences de l’ANSSI et aux directives européennes (NIS 2, DORA).

2. Déploiement d’une Autorité de Certification SSH (CA SSH)

Au lieu de copier manuellement des clés sur chaque serveur, un infogérant met en place une PKI / CA SSH. Les administrateurs obtiennent des certificats éphémères signés via leur YubiKey, garantissant un contrôle d’accès dynamique et la suppression des accès résiduels.

3. Gestion de la perte de clé et plan de secours (Break-Glass)

Le risque principal lié aux clés physiques est la perte ou le vol du jeton. L’infogérant garantit la continuité d’activité grâce à :

• La mise en place de clés YubiKey de secours (Backup Keys) stockées sous scellé.

• Des procédures d’urgence sécurisées pour restaurer les accès sans compromettre la sécurité globale.

4. Supervision 24/7 et maintien en condition de sécurité (MCS)

Un infogérant centralise l’analyse des journaux de connexion (logs SSH), détecte les anomalies en temps réel et assure la mise à jour continue de vos serveurs pour pare-feu et configurations OpenSSH.

En résumé : Passez au Passwordless SSH

L’association d’OpenSSH et des clés de sécurité matérielles FIDO2 / YubiKey supprime définitivement le maillon faible du mot de passe. En confiant cette transition et le maintien de votre infrastructure à un prestataire d’infogérance, vous bénéficiez d’une sécurité maximale, d’une conformité réglementaire assurée et d’une gestion sereine au quotidien.

The post Sécuriser un serveur SSH : Bannir les mots de passe first appeared on DEMARCQ.NET.

À l’ère de la transformation numérique, la disponibilité continue de vos services web n’est plus une simple option : c’est un levier direct de rentabilité, de crédibilité et de confiance pour vos clients. Pourtant, la menace des attaques DDoS (Distributed Denial of Service) continue de progresser en fréquence, en intensité et en complexité. Qu’il s’agisse de paralyser un site e-commerce pendant une période stratégique comme les soldes ou d’interrompre l’accès aux outils de travail SaaS d’une entreprise, les répercussions financières et réputationnelles d’une indisponibilité réseau peuvent s’avérer dévastatrices.

Pour prémunir efficacement vos serveurs dédiés ou instances Cloud contre ces paralysies, une approche globale s’impose. La sécurité informatique ne repose pas sur un outil unique, mais sur la superposition de plusieurs couches de protection. Une stratégie anti-DDoS performante doit impérativement combiner la sécurisation de l’infrastructure réseau, la protection au niveau applicatif et une gestion d’infogérance proactive.

1. Sécuriser l’infrastructure réseau : Bloquer les attaques volumétriques (Couches 3 et 4 OSI)

Les attaques au niveau réseau ciblant la couche transport (L4) et la couche réseau (L3) du modèle OSI ont un objectif simple : saturer la bande passante de votre hébergement web ou surcharger la capacité de traitement de vos équipements (routeurs, pare-feux hardware). Elles se manifestent principalement sous forme d’inondations de paquets (SYN Floods, UDP Floods, ou attaques par amplification DNS/NTP).

Pour empêcher ces volumes massifs de données illégitimes d’atteindre votre serveur d’origine, plusieurs mécanismes d’infrastructure doivent être configurés :

Les centres de nettoyage (Scrubbing Centers) et le routage BGP

En cas d’attaque volumétrique majeure, l’un des moyens les plus efficaces consiste à utiliser un service de nettoyage de trafic basé sur le protocole BGP (Border Gateway Protocol). En cas de pic anormal, le trafic destiné à votre IP est automatiquement réacheminé vers des centres de dépoussiérage capables d’absorber des terabits de données par seconde. Les paquets malveillants y sont filtrés, et seul le trafic “propre” est transmis à votre infrastructure.

Le déploiement d’un réseau CDN (Content Delivery Network)

Un CDN comme Cloudflare, Fastly ou KeyCDN joue un rôle de bouclier thermique entre les internautes et votre serveur web. En agissant comme un proxy inverse distribué à travers le monde, le CDN masque l’adresse IP réelle de votre serveur dédié. Les attaques volumétriques viennent alors butter sur le réseau mondial du CDN, préservant ainsi totalement votre serveur source.

La répartition de charge (Load Balancing) et la redondance

La haute disponibilité repose sur l’absence de point unique de défaillance (Single Point of Failure). En plaçant un équilibreur de charge (type HAProxy ou un Load Balancer Cloud) en amont d’un cluster de serveurs, vous répartissez le flux de visiteurs de manière fluide. En cas d’attaque de taille modérée, la charge est lissée sur plusieurs machines au lieu d’effondrer un serveur isolé.

2. Protéger la couche applicative : Faire face aux attaques complexes (Couche 7 OSI)

Plus insidieuses et souvent plus difficiles à détecter, les attaques applicatives (couche 7 OSI) ne cherchent pas à raturer la bande passante, mais à épuiser les ressources système internes du serveur (CPU, mémoire RAM, connexions actives à la base de données MySQL ou processus PHP-FPM). En envoyant des requêtes HTTP/HTTPS en apparence légitimes (HTTP Floods), les pirates provoquent un effondrement des performances applicatives.

Pour contrecarrer ces attaques ciblant la logique applicative, un paramétrage sur mesure des logiciels serveurs est obligatoire :

Déploiement d’un WAF (Web Application Firewall)

Un Pare-feu Applicatif Web (tel que ModSecurity, Nginx Naxsi ou la suite de règles Cloudflare WAF) analyse en temps réel le contenu et l’intention des requêtes HTTP entrantes. Il permet de bloquer les attaques automatisées, les robots malveillants, les injections SQL, le cross-site scripting (XSS) et les requêtes ciblant intentionnellement les scripts lourds de vos applications.

Configuration du Rate Limiting (Limitation de débit)

Indispensable sous Nginx, Apache ou HAProxy, le Rate Limiting consiste à brider le nombre maximal de requêtes qu’une adresse IP peut soumettre dans un temps donné. Il est particulièrement crucial de l’appliquer sur les endpoints vulnérables, comme les pages de connexion (wp-login.php, interfaces d’administration), les formulaires de recherche ou les API de paiement.

Stratégie de mise en cache agressive (Redis, Varnish, Nginx FastCGI)

Le maillon le plus faible d’un serveur web est souvent l’exécution des scripts (PHP, Python, Node.js) et les appels en base de données. En configurant une couche de cache puissante (Redis pour le cache d’objets, Varnish ou Nginx pour le cache de pages complètes), le serveur répond instantanément aux requêtes en mémoire vive sans solliciter la base de données, rendant l’application extrêmement résiliente face aux surcharges de trafic.

3. Le rôle clé de l’infogérance de serveur dans la lutte anti-DDoS

Disposer d’outils performants ne suffit pas : la cybersécurité exige une surveillance constante, des ajustements réguliers et une capacité d’intervention immédiate en cas d’attaque avérée. C’est précisément à ce niveau que l’infogérance de serveur démontre toute sa valeur ajoutée.

Une surveillance et un monitoring 24/7

Un prestataire spécialisé en infogérance met en place des sondes de monitoring réseau et système (Prometheus, Zabbix, Grafana) pour suivre en temps réel le trafic, la charge processeur et l’utilisation de la RAM. Toute anomalie ou pic de trafic suspect déclenche une alerte immédiate avant même que vos utilisateurs ne subissent de ralentissement.

Un paramétrage sur-mesure et l’application des correctifs

Il n’existe pas de configuration de sécurité universelle. L’équipe d’infogérance adapte la configuration de vos pare-feux (IPTables/NFTables, WAF, règles Nginx) en fonction de l’architecture précise de votre projet web. De plus, elle assure la mise à jour préventive continuelle du système d’exploitation et des paquets logiciels pour combler les vulnérabilités du jour zéro (zero-day).

La gestion de crise et l’atténuation d’urgence

Lorsqu’une attaque DDoS complexe survient, chaque minute compte. Un administrateur système dédié est en mesure d’analyser l’empreinte des logs d’attaque en temps réel, de repérer les schémas des requêtes malveillantes et d’appliquer immédiatement des règles de blocage chirurgicales pour rétablir l’accès à vos services sans perturber le trafic légitime.

En conclusion : Faites de la sécurité un avantage concurrentiel

Face à la fréquence des cybermenaces actuelles, la protection contre les attaques DDoS ne doit plus être perçue comme un coût, mais comme un investissement stratégique pour garantir la continuité de vos affaires. En combinant un bouclier d’infrastructure réseau solide, une optimisation fine du serveur web et l’expertise d’une équipe d’infogérance proactive, vous transformez la disponibilité de votre site en un véritable gage de confiance pour vos clients.

The post Infogérance Protection Attaque DDoS first appeared on DEMARCQ.NET.

Un script Cron qui s’exécute avec trop de privilèges, qui s’exécute en double ou qui échoue en silence représente un danger majeur pour la sécurité et l’intégrité de vos données.

Règle 1 : Ne lancez jamais vos scripts sous l’utilisateur root

Un script vulnérable exécuté en root compromet instantanément l’intégralité du serveur dédié. Utilisez le cron de l’utilisateur applicatif dédié (ex: www-data).

# Modifier le cron d'un utilisateur spécifique
crontab -u www-data -e

Règle 2 : Déclarer un environnement d’exécution (PATH) explicite

Contrairement à votre terminal interactif, l’environnement d’un Cron est extrêmement restreint. Spécifiez toujours les chemins absolus pour vos binaires ou déclarez le PATH en haut de votre fichier crontab :

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Exemple de tâche sécurisée avec chemins absolus
0 4 * * * /usr/bin/php /var/www/mon-projet/artisan backup:run

Règle 3 : Éviter l’exécution simultanée (Overlap) avec flock

Si un script de synchronisation configuré pour tourner toutes les 5 minutes met finalement 10 minutes à s’exécuter, une deuxième instance va se lancer en parallèle. Cela provoque souvent des corruptions de données ou des surcharges CPU. Utilisez flock pour verrouiller l’exécution :

*/5 * * * * usr/bin/flock -n /tmp/mon_cron_sync.lock -c "/usr/bin/php /var/www/mon-projet/sync.php"

(Le commutateur -n indique à flock de s’arrêter immédiatement sans attendre si le verrou est déjà actif).

Règle 4 : Capturer et masquer la sortie standard, mais logger les erreurs

Ne laissez pas vos crons polluer les boîtes mail locales ou les fichiers de logs génériques. Redirigez la sortie standard (stdout) vers le vide absolu /dev/null, tout en capturant les erreurs (stderr) :

0 2 * * * /usr/bin/python3 /scripts/clean.py > /dev/null 2> /var/log/cron_e

The post Comment sécuriser ses tâches planifiées ? first appeared on DEMARCQ.NET.

http {
    # 1. Prise en compte de la vraie IP client derrière un Proxy / CDN (Cloudflare, HAProxy)
    set_real_ip_from 10.0.0.0/8; # Plage IP de vos proxys internes
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    # 2. Zone stricte pour les formulaires sensibles (ex: login, inscription, API)
    # Limite à 1 requête par seconde (1r/s) par adresse IP
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

    # 3. Zone globale pour le trafic général du site
    # Limite à 10 requêtes par seconde (10r/s) par adresse IP
    limit_req_zone $binary_remote_addr zone=global_limit:10m rate=10r/s;
}

server {
    listen 443 ssl http2;
    server_name exemple.com;

    # Log des requêtes bloquées au niveau warning
    limit_req_log_level warn;

    # Protection ciblée contre la force brute (Formulaire de connexion, wp-login, API)
    location /login {
        # Applique la zone login_limit avec un tampon (burst) de 5 et l'option nodelay
        limit_req zone=login_limit burst=5 nodelay;

        # Personnalisation de l'erreur : 429 au lieu du 503 par défaut
        limit_req_status 429;

        proxy_pass http://127.0.0.1:8080;
    }

    # Protection contre le scraping massif sur les pages produits / catalogue
    location /catalogue/ {
        limit_req zone=global_limit burst=20 nodelay;
        limit_req_status 429;

        try_files $uri $uri/ /index.php?$query_string;
    }

    # Restreindre l'accès à l'API GraphQL ou REST
    location /api/v1/ {
        limit_req zone=login_limit burst=10;
        limit_req_status 429;
    }
}

http {
    # 1. Cartographie des IP de confiance
    geo $white_ip {
        default 1;
        127.0.0.1 0;          # Localhost
        192.168.1.0/24 0;     # Réseau interne de l'entreprise
        203.0.113.42 0;       # IP publique de vos administrateurs
    }

    # 2. Associe l'IP au compteur uniquement si elle n'est pas "white-listée"
    map $white_ip $limit_key {
        0 "";                 # Si l'IP est de confiance, la clé est vide (pas de calcul)
        1 $binary_remote_addr;# Sinon, la clé utilise l'IP client
    }

    # 3. La zone utilise la clé dynamique $limit_key
    limit_req_zone $limit_key zone=smart_limit:10m rate=2r/s;
}

The post Mettre en place une limitation de débit avec Nginx first appeared on DEMARCQ.NET.

Attendre que votre serveur s’éteigne pour agir est une erreur critique. Le noyau Linux et le système d’exploitation envoient des signaux d’alerte bien avant la panne finale. Voici comment les traquer.

dmesg : Le journal du noyau (Kernel)

dmesg affiche les messages du tampon circulaire du noyau. C’est l’outil numéro un pour repérer les défaillances physiques directes.

• Vérifier les erreurs d’écriture disque / SATA :

  Bash

  dmesg | grep -Ei "ata|scsi|sd|sector|ext4|io error"
  

  Signe d’alerte : Des erreurs de type I/O error ou Buffer I/O error on dev sda indiquent que votre disque dur ou SSD est en train de rendre l’âme.

• Traquer l’instabilité de la mémoire RAM :

  Bash

  dmesg | grep -i "MCE"
  

  Signe d’alerte : Les erreurs MCE (Machine Check Exception) sont générées directement par le processeur lorsqu’il détecte une défaillance matérielle (souvent un problème de RAM ECC ou de surchauffe CPU).

journald et syslog : Les journaux du système

Avec systemd, journalctl centralise la majorité des logs.

• Lister uniquement les erreurs graves et critiques depuis le dernier démarrage :

  Bash

  journalctl -p 0..3 -b
  

  (Le paramètre -p 0..3 cible les niveaux Emergency, Alert, Critical et Error).

• Surveiller les kills par manque de mémoire (Out of Memory) : Si votre serveur s’arrête de répondre de façon aléatoire ou si vos services (comme MySQL) coupent tout seuls :

  Bash

  journalctl -ke | grep -i "oom-killer"
  

  L’OOM-Killer intervient pour tuer les processus gourmands lorsque la RAM est totalement saturée.

The post Comment analyser les logs système first appeared on DEMARCQ.NET.

Le choix et la configuration du gestionnaire de processus (process manager ou pm) dans votre pool PHP-FPM déterminent la réactivité de vos applications PHP sous forte charge.

Comparatif des 3 modes PHP-FPM

Comment calculer vos limites de processus (pm.max_children) ?

La mauvaise configuration de cette directive provoque l’erreur classique : [Server deadlocks / Gateway Timeout].

1. Calculez la mémoire RAM moyenne consommée par un seul de vos processus PHP. Exécutez :

   Bash

   ps -o rss -C php-fpm | tail -n +2 | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
   

   (Disons que le résultat est de 50 MB par processus).

2. Déterminez la RAM maximale que vous souhaitez allouer à PHP-FPM (ex: laissez au moins 1-2 GB pour le système, MySQL et Nginx). Sur un serveur de 8 GB, vous décidez d’allouer 5 GB à PHP.

3. Calculez pm.max_children : $5000 text{ MB} / 50 text{ MB} = 100$.

Exemple de configuration optimale (static pour production)

Modifiez le fichier de configuration de votre pool (ex: /etc/php/8.x/fpm/pool.d/www.conf) :

pm = static
pm.max_children = 100
pm.max_requests = 1000 # Évite les fuites de mémoire en recyclant les processus après 1000 requêtes

3. Comment analyser les logs système (journald, syslog, dmesg) pour identifier une panne matérielle ou système imminente ?

Attendre que votre serveur s’éteigne pour agir est une erreur critique. Le noyau Linux et le système d’exploitation envoient des signaux d’alerte bien avant la panne finale. Voici comment les traquer.

dmesg : Le journal du noyau (Kernel)

dmesg affiche les messages du tampon circulaire du noyau. C’est l’outil numéro un pour repérer les défaillances physiques directes.

• Vérifier les erreurs d’écriture disque / SATA :

  Bash

  dmesg | grep -Ei "ata|scsi|sd|sector|ext4|io error"
  

  Signe d’alerte : Des erreurs de type I/O error ou Buffer I/O error on dev sda indiquent que votre disque dur ou SSD est en train de rendre l’âme.

• Traquer l’instabilité de la mémoire RAM :

  Bash

  dmesg | grep -i "MCE"
  

  Signe d’alerte : Les erreurs MCE (Machine Check Exception) sont générées directement par le processeur lorsqu’il détecte une défaillance matérielle (souvent un problème de RAM ECC ou de surchauffe CPU).

journald et syslog : Les journaux du système

Avec systemd, journalctl centralise la majorité des logs.

• Lister uniquement les erreurs graves et critiques depuis le dernier démarrage :

  Bash

  journalctl -p 0..3 -b
  

  (Le paramètre -p 0..3 cible les niveaux Emergency, Alert, Critical et Error).

• Surveiller les kills par manque de mémoire (Out of Memory) :

  Si votre serveur s’arrête de répondre de façon aléatoire ou si vos services (comme MySQL) coupent tout seuls :

  Bash

  journalctl -ke | grep -i "oom-killer"
  

  L’OOM-Killer intervient pour tuer les processus gourmands lorsque la RAM est totalement saturée.

The post Comment configurer PHP-FPM pour maximiser les performances ? first appeared on DEMARCQ.NET.

Pourquoi votre base de données rame-t-elle et comment y remédier ?

Dans toute architecture logicielle, la base de données est souvent le cœur battant de l’application… mais aussi son maillon le plus sensible. Un temps de réponse qui grimpe, des requêtes qui s’accumulent, un CPU à 100 % ou des entrées/sorties disque complètement saturées : les symptômes d’un goulot d’étranglement (bottleneck) peuvent paralyser l’intégralité de vos services et impacter directement l’expérience de vos utilisateurs.

Identifier l’origine exacte d’une baisse de performance s’apparente parfois à une enquête. Est-ce une requête mal optimisée qui scanne toute une table ? Un manque de mémoire vive qui force des écritures permanentes sur le disque ? Ou encore un verrou (lock) posé par une transaction trop longue qui bloque toutes les autres ?

Que vous utilisiez MySQL ou PostgreSQL, la méthode de diagnostic reste structurée. Ce guide vous détaille les étapes clés et les outils incontournables pour isoler le problème, analyser les métriques système et SQL, et restaurer la fluidité de votre base de données.

Un goulot d’étranglement sur une base de données ralentit l’ensemble de votre pile applicative. Pour diagnostiquer efficacement l’origine de la lenteur (disque, CPU, verrouillage), suivez cette méthodologie d’analyse.

Étape 1 : Analyser l’utilisation des ressources système

Avant de plonger dans le moteur SQL, utilisez des outils système pour identifier la ressource saturée :

• htop ou top : Vérifiez si le processus mysqld ou postgres s’accapare l’intégralité du CPU.

• iotop ou iostat -xz 1 : Surveillez la valeur %util (utilisation du disque) et le temps d’attente d’écriture (await). Un disque saturé est le bottleneck le plus fréquent en base de données.

Étape 2 : Traquer les requêtes lentes (Slow Queries)

Identifiez les requêtes SQL mal indexées qui lisent des millions de lignes inutilement.

• Pour MySQL : Activez le Slow Query Log dans votre fichier /etc/mysql/my.cnf :

  Ini, TOML

  slow_query_log = 1
  slow_query_log_file = /var/log/mysql/mysql-slow.log
  long_query_time = 1.0 # Logge les requêtes de plus d'une seconde
  log_queries_not_using_indexes = 1
  

  Analysez ensuite ce fichier avec mysqldumpslow ou l’outil pt-query-digest (Percona Toolkit).

• Pour PostgreSQL : Utilisez l’extension incontournable pg_stat_statements. Ajoutez ceci dans postgresql.conf :

  Ini, TOML

  shared_preload_libraries = 'pg_stat_statements'
  

  Puis exécutez cette requête pour lister les requêtes les plus gourmandes en temps cumulé :

  SQL

  SELECT query, calls, total_exec_time, rows FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;
  

Étape 3 : Diagnostiquer les verrous (Locks)

Deux requêtes concurrentes qui s’attendent mutuellement peuvent paralyser votre base.

• MySQL : Visualisez l’état des verrous avec SHOW ENGINE INNODB STATUS; ou examinez la table information_schema.innodb_trx.

• PostgreSQL : Détectez les blocages actifs grâce à la table système pg_locks jointe à pg_stat_activity pour repérer quelle transaction bloque les autres.

Conclusion / Étapes suivantes (Optionnel)

Une fois le problème localisé grâce à ce diagnostic, l’étape suivante consiste à appliquer le correctif adapté : ajouter un index pertinent, revoir la modélisation des tables, ajuster le paramétrage de la mémoire (innodb_buffer_pool_size sur MySQL ou shared_buffers sur PostgreSQL), ou encore optimiser le code applicatif pour réduire le temps de maintien des verrous.

The post Comment diagnostiquer un goulot d’étranglement sur une base de données first appeared on DEMARCQ.NET.

Comment diagnostiquer une baisse de performance ou une panne sur son serveur dédié ?

Lorsqu’un serveur dédié ralentit ou ne répond plus, chaque minute compte. Face à l’urgence, une méthodologie de diagnostic structurée permet de remonter rapidement à la source du problème, qu’il s’agisse d’une surcharge de ressources ou d’une erreur applicative. Voici le guide de secours pour identifier le goulot d’étranglement.
Étape 1 : Traquer les processus gourmands en temps réel

Le premier réflexe consiste à se connecter en SSH et à analyser l’état de la machine. Lancez la commande top ou, idéalement, htop (plus visuelle).

Regardez immédiatement la Load Average (charge moyenne) en haut à droite : si elle dépasse largement le nombre de cœurs de votre processeur, le serveur est saturé. Identifiez ensuite le coupable dans la liste : un processus PHP-FPM qui s’emballe ? Une requête MySQL mal optimisée qui bloque le CPU ? Un manque de mémoire RAM qui force le serveur à swapper ? htop vous donne la réponse en un coup d’œil.
Étape 2 : Analyser les journaux système (Syslog)

Si le serveur a planté ou si un service s’est arrêté brusquement (comme MySQL victime du Out Of Memory Killer), la mémoire vive a probablement saturé. Pour le vérifier, examinez les logs système généraux avec la commande suivante :
sudo tail -n 100 /var/log/syslog (ou /var/log/messages sur CentOS/RHEL). Vous y trouverez les alertes matérielles et les arrêts critiques de services.
Étape 3 : Inspecter les logs des serveurs web (Apache / Nginx)

La panne peut aussi être causée par une surcharge de trafic ou une attaque par déni de service (DDoS). Inspectez les fichiers de votre serveur web :

Les Access Logs (/var/log/nginx/access.log ou /var/log/apache2/access.log) : Un volume anormal de requêtes identiques provenant d’une même adresse IP indique souvent une attaque ou un bot malveillant à bannir.

Les Error Logs (/var/log/nginx/error.log) : Ils révèlent les scripts PHP défaillants, les ruptures de communication avec la base de données ou les problèmes de permissions de fichiers.

En combinant l’analyse des ressources matérielles et la lecture des logs, vous transformez une panne inexpliquée en un problème technique simple à résoudre.

The post Comment diagnostiquer une baisse de performance sur son serveur dédié ? first appeared on DEMARCQ.NET.

Incendie, cyberattaque par ransomware, panne matérielle majeure ou simple erreur humaine : le risque zéro n’existe pas en informatique. Face à un sinistre, la question n’est pas de savoir si vous allez être touché, mais quand vous le serez.

Le Plan de Reprise d’Activité (PRA) est la police d’assurance de votre infrastructure. Il regroupe l’ensemble des procédures techniques et organisationnelles permettant de reconstruire vos serveurs et de relancer vos services après un arrêt critique.

Voici les clés pour bâtir un PRA solide, centré sur le véritable moteur de la reprise : la stratégie de sauvegarde.

1. Définir les deux indicateurs stratégiques : RTO et RPO

Avant de parler technique, vous devez fixer le seuil de tolérance de votre entreprise à travers deux métriques fondamentales :

• Le RPO (Recovery Point Objective – Perte de données maximale admissible) : Quelle quantité de données pouvez-vous vous permettre de perdre ? Si votre dernière sauvegarde a 24 heures et que votre serveur crash, vous perdez une journée de travail. Pour des données critiques, le RPO doit souvent être réduit à quelques minutes.

• Le RTO (Recovery Time Objective – Durée maximale d’interruption admissible) : Combien de temps votre entreprise peut-elle rester à l’arrêt ? C’est le temps nécessaire pour restaurer vos systèmes et rouvrir les accès aux utilisateurs.

2. Le cœur du PRA : L’automatisation des sauvegardes

Compter sur une action humaine pour effectuer une sauvegarde est le meilleur moyen d’échouer le jour où le sinistre survient. L’oubli d’une clé USB ou le report d’une manipulation à un lendemain “plus calme” sont des classiques du crash informatique.

• L’automatisation élimine le facteur humain. Vos scripts (qu’il s’agisse de snapshots de machines virtuelles, de dumps de bases de données ou de synchronisations de fichiers) doivent s’exécuter à intervalles réguliers (toutes les heures, toutes les nuits) sans aucune intervention.

• Le monitoring des sauvegardes : Une sauvegarde automatisée qui échoue en arrière-plan sans prévenir est invisible… jusqu’au jour de la restauration. Vos outils de supervision (ou des rapports quotidiens par email/Slack) doivent valider le succès de chaque tâche.

3. L’externalisation : La règle d’or du 3-2-1

Sauvegarder vos serveurs sur un disque dur posé sur la même baie informatique ou dans la même pièce ne sert à rien si le bâtiment subit un incendie ou un dégât des eaux. De même, si un ransomware chiffre votre réseau, il infectera également vos sauvegardes locales si elles sont accessibles.

Pour sécuriser vos données, appliquez rigoureusement la stratégie de sauvegarde 3-2-1 :

• 3 copies de vos données au total (la production + 2 sauvegardes).

• 2 supports différents (par exemple : un stockage local NAS et un stockage Cloud).

• 1 copie externalisée, hors de votre infrastructure principale (Cloud sécurisé, deuxième centre de données géographiquement distant).

L’importance de l’immuabilité (Object Lock) : Pour contrer les rançongiciels les plus agressifs qui cherchent à détruire vos sauvegardes cloud, optez pour des stockages externalisés dits immuables. Une fois écrites, les données ne peuvent être ni modifiées ni supprimées pendant une période définie, même avec les identifiants administrateur.

4. Un PRA n’existe que s’il est testé

Le piège le plus courant est de rédiger un magnifique document de PRA, de configurer les sauvegardes, puis de refermer le dossier.

Une stratégie de sauvegarde n’est valide que si la procédure de restauration fonctionne. Un fichier de sauvegarde peut être corrompu, une clé de chiffrement peut être perdue, ou le temps de téléchargement depuis le cloud peut s’avérer beaucoup plus long que prévu (impactant directement votre RTO).

• Simulez des pannes : Organisez au moins une à deux fois par an un “exercice de crise”.

• Restaurer à blanc : Testez la reconstruction d’un serveur web ou d’une base de données sur un environnement isolé pour mesurer le temps réel de reprise et ajuster vos procédures.

En résumé : Le PRA n’est pas un projet informatique optionnel, c’est une stratégie de survie d’entreprise. Automatiser pour ne pas oublier, externaliser pour se protéger des sinistres physiques, et tester pour garantir l’efficacité : voilà le triptyque d’une infrastructure résiliente.

The post Plan de Reprise d’Activité (PRA) informatique first appeared on DEMARCQ.NET.