NetBSD + nginx + naxsi + MySQL + PHP == 3NMP

Magazine
Marque
GNU/Linux Magazine
Numéro
159
|
Mois de parution
avril 2013
|
Domaines


Résumé
LAMP[1] par-ci, LAMP par-là, nous sommes en 2013 que diable ! Les technologies ont évolué, les besoins aussi, et si le standard de fait reste encore et toujours Apache muni du module mod_php[2], l'interprétation et l'affichage de pages Web programmées en PHP peuvent s'effectuer de façon bien plus élégante. Dans cet article, nous allons sortir des sentiers battus, et paramétrer un système NetBSD 6.0 afin d'en faire une plateforme web simple et sûre.

Body

1. Environnement

Pour mettre en place notre plateforme, nous aurons besoin d'un système NetBSD 6.0 capable de joindre l'Internet.

Avant de démarrer la configuration de notre serveur Web, sachez que deux options s'offrent à vous pour installer les logiciels dont nous aurons besoin :

- pkgin dans le cas d'une installation de paquets binaires

- pkgsrc si vous souhaitez utiliser des paquets source

Dans ce dernier cas, vous devrez vous munir de l'arbre pkgsrc :

$ cd /usr

$ sudo cvs -d anoncvs@anoncvs.fr.NetBSD.org:/cvsroot co -rpkgsrc-2012Q4 pkgsrc

Cette commande aura pour effet de télécharger l'arbre pkgsrc 2012Q4, qui sera alors disponible dans le répertoire /usr/pkgsrc. Notez qu'il est probable qu'à l'heure où vous lirez cet article, pkgsrc 2013Q1 sera disponible, il suffira alors de remplacer 2012Q4 par 2013Q1.

La première étape de notre périple consiste à installer les logiciels nécessaires, dans l'ordre :

- nginx muni du module naxsi[3]

- php-fpm [4]

- MySQL

1.1 nginx + naxsi

On ne présente plus nginx, le serveur Web / Reverse Proxy HTTP / Proxy POP3/IMAP dont la réactivité et la faible empreinte mémoire ont fait de lui le second serveur Web le plus utilisé selon Netcraft[5]. Adossé à nginx, naxsi est un logiciel tierce partie dont un article faisait la présentation dans ces colonnes voici quelques mois. Pour rappel, naxsi est un module de nginx, développé par des employés de la société NBS-System dont je suis le directeur des opérations. Ce module est ce qu'il convient d'appeler un WAF, pour Web Application Firewall, dont l'objectif est de stopper les attaques classiques permettant de compromettre un site Web. Au contraire des WAF connus, naxsi ne se base pas sur une liste de signatures d'attaques, mais propose une liste de requêtes anormales qu'on trouve dans la quasi-totalité des tentatives d'intrusions. Par exemple, on peut lire dans le fichier naxsi_core.rules des règles très simples qui affectent un score lorsqu'une requête présente des caractères ou chaînes de caractères inhabituels. Il revient alors à l'administrateur d'ajouter des listes de règles (listes blanches) si l'utilisation d'un caractère suspect devait être autorisée. Nous reviendrons plus loin sur l'écriture des listes blanches.

Dans les dépôts officiels de paquets binaires NetBSD, nginx est compilé avec le strict minimum, cependant, NetBSDfr[7] met à disposition des utilisateurs des dépôts maison où l'on trouvera entre autres une version packagée de nginx disposant du module naxsi mais également real ip, ce dernier permettant d'inscrire des logs munis de l'IP réelle du client lorsque l'on se trouve derrière un Reverse Proxy[9].

Pour utiliser ce dépôt, il suffira de renseigner le fichier /usr/pkg/etc/pkgin/repositories.conf avec la ligne suivante :

http://packages.netbsdfr.org/latest/6.0/amd64/packages/All

Bien entendu, si votre plateforme est de type i386, il conviendra de remplacer amd64 par i386. Notez que NetBSDfr ne construit des paquets « que » pour i386 et amd64 par simple manque d'espace et d'architectures différentes (appel à contribution à peine masqué).

Après avoir mis à jour la base de données de paquets disponibles via la commande :

# pkgin up

On peut installer le couple nginx/naxsi en tapant simplement :

# pkgin in nginx

Pour les plus téméraires d'entre vous, si vous souhaitez installer ces logiciels au travers de pkgsrc, prenez soin d'ajouter les lignes suivantes au fichier /etc/mk.conf :

PKG_OPTIONS.nginx+=     naxsi realip

Ce qui aura pour effet de provoquer l'inclusion des modules naxsi et realip dans nginx lors de sa compilation. L’installation du paquet via pkgsrc se fait de cette façon :

$ cd /usr/pkgsrc/www/nginx

$ sudo make install clean

On s'assure que le serveur sera exécuté à chaque démarrage de la machine hôte :

# cp /usr/pkg/share/examples/rc.d/nginx /etc/rc.d/

# echo "nginx=YES" >> /etc/rc.conf

Il est désormais possible de démarrer le serveur Web :

# /etc/rc.d/nginx start

1.2 php-fpm

Il existe deux méthodes très connues pour faire interpréter le langage PHP afin d'en faire rendre le contenu par un serveur Web : mod_php et un des multiples systèmes de type FastCGI. Dans notre cas, mod_php est à proscrire, car il n'existe simplement pas d'implémentation de ce module pour nginx. De plus, l'exécution de script PHP déportée sur un programme tiers n'est certainement pas une mauvaise idée, car si la légende selon laquelle l'exécution de PHP serait plus rapide en passant par une socket (FastCGI) que par un pointeur (mod_php) est grotesque, il n'en reste pas moins que mod_php produit des processus Apache gigantesques. Notez par ailleurs que les documentations officielles, sur php.net, déconseillent fortement l'utilisation du mode Worker (threadé) couplé au module mod_php pour des raisons de réentrance[10] (rassurant, n'est-ce pas ?).

Pour toutes ces raisons, nous utiliserons PHP-FPM pour l'interprétation du code PHP qui viendra peupler notre DocumentRoot. Ce logiciel est livré avec PHP depuis la version 5.3.3 et dispose d'un paquet dédié dans pkgsrc, aussi, son installation est triviale :

# pkgin in php54-fpm

Ou si vous souhaitez rester en version 5.3 :

# pkgin in php53-fpm

Si l'on désire passer par pkgsrc et compiler toute la chaîne, on s'assurera en premier lieu de spécifier la version de PHP préférée dans le fichier /etc/mk.conf :

$ grep PHP /etc/mk.conf

PHP_VERSION_DEFAULT= 54

Puis on lance la chaîne d'installation :

# cd /usr/pkgsrc/www/php-fpm

# make install clean

Comme pour tous les démons, on demande son exécution au démarrage de cette façon :

# cp /usr/pkg/share/examples/rc.d/php_fpm /etc/rc.d

# echo "php_fpm=YES" >> /etc/rc.conf

Le paramétrage de PHP-FPM s'effectue dans le fichier /usr/pkg/etc/php-fpm.conf, et les différentes directives destinées à PHP se trouvent classiquement dans /usr/pkg/etc/php.ini. Un paramétrage par défaut suffira largement à notre mise en place, il conviendra cependant de s'assurer que PHP-FPM fonctionne avec le même utilisateur que nginx. Il faudra donc vérifier que les valeurs de user et group dans le fichier php-fpm.conf sont identiques à la ligne user du fichier nginx.conf.

1.3 MySQL

L'installation du serveur de bases de données MySQL est triviale, mais dans le cas où vous avez choisi d'installer les versions binaires des logiciels que nous allons manipuler, il est important de correctement choisir sa version de MySQL. En effet, le module php-mysql binaire livré par les dépôts NetBSDfr est lié à la version 5.1, aussi, l'installation s'effectue comme suit :

# pkgin in mysql-server-5.1

Dans le cas d'une installation via pkgsrc, il suffira de se rendre dans le répertoire de la version souhaitée, par exemple :

$ cd /usr/pkgsrc/databases/mysql55-server

$ sudo make install clean

2. Now Kiss

Les briques essentielles de notre serveur-à-chatons étant posées, nous allons nous assurer de la bonne communication entre nginx et PHP-FPM. Pour ce faire, nous créons une section location dans le fichier nginx.conf qui aura pour tâche de prendre en charge les URI[11] de type .php :

location ~ \.php$ {

  fastcgi_pass   unix:/tmp/fcgi-php.sock;

  fastcgi_index index.php;

  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

  fastcgi_buffers 256 4k;

  include        /usr/pkg/etc/nginx/fastcgi_params;

}

Nous plaçons cette location dans la section server déjà présente dans le fichier nginx.conf installé par le paquet. Dans cet exemple, nous passons les fichiers PHP à interpréter via une socket UNIX que met en place PHP-FPM. Le chemin de cette socket est défini dans le fichier php-fpm.conf :

listen = /tmp/fcgi-php.sock

Il est également possible d'utiliser un port TCP, par exemple pour déporter l'exécution des scripts sur une machine tierce, la syntaxe serait alors :

listen = 192.168.0.1:9000

Ou encore, pour une écoute locale :

listen = 127.0.0.1:9000

Il convient alors de modifier, dans la section location de notre fichier d'exemple nginx.conf, la valeur du paramètre fastcgi_pass de cette façon :

fastcgi_pass 127.0.0.1:9000;

En ayant préalablement démarré PHP-FPM de cette façon :

# /etc/rc.d/php-fpm start

Nous vérifions que la syntaxe du fichier nginx.conf est correcte grâce à cette commande :

# nginx -t

nginx: the configuration file /usr/pkg/etc/nginx/nginx.conf syntax is ok

nginx: configuration file /usr/pkg/etc/nginx/nginx.conf test is successful

On peut alors recharger sereinement notre nouvelle configuration :

# nginx -s reload

Reste à vérifier le bon fonctionnement d'un script PHP, en créant dans l'arborescence connue comme root par nginx, un simple fichier PHP :

$ cat > test.php

<?php phpinfo(); ?>

^D

Et de constater :

netbsd-fpm

NetBSD + nginx + PHP-FPM : check.

3. Des p'tits trous

Aaaah, PHP. Aaaah la magie du développement permissif… Soyons clairs, je suis une quiche en PHP. Je ne peux l'exprimer autrement. Vraiment. Non, c'est pas mon truc. Après une soirée anormalement arrosée, je serais certainement en mesure d'écrire quelque chose de cet acabit :

<?php

  $content = file($_GET['path']);

  foreach($content as $line) {

    echo $line;

  }

?>

Et laisser ainsi la porte ouverte à l'ensemble des informations présentes sur le système de fichiers du serveur Web où serait situé ce vilain script.

Cet exemple est grossier et simpliste, mais malheureusement, non seulement ce type d'erreur fait légion, mais dans d'innombrables cas de figures, des machineries complexes telles que WordPress, Drupal, Magento, PrestaShop ou encore Joomla (rires) sont inconsciemment truffées d'exploits potentiels. Il suffit pour s'en convaincre de parcourir rapidement les CVE (Common Vulnerabilities and Exposures) de ces divers applicatifs pour qu'un frisson parcoure votre échine d'administrateur système hébergeant des dizaines, centaines, milliers de sites PHP hors de contrôle.

C'est dans cette scène angoissante qu'entre en jeu le WAF naxsi.

L'intégration de naxsi dans nginx n'est pas une tâche complexe. L'installation du paquet nginx a provoqué la création d'un fichier d'exemple /usr/pkg/share/examples/nginx/conf/naxsi_core.rules. Ce fichier, comprenant les règles de base de naxsi, est à copier dans le répertoire de configuration de nginx :

# cp /usr/pkg/share/examples/nginx/conf/naxsi_core.rules \

/usr/pkg/etc/nginx/

On inclut ce fichier dans la section http du fichier nginx.conf :

include /usr/pkg/etc/nginx/naxsi_core.rules;

Reste maintenant à préparer les locations que nous souhaitons sécuriser. On crée pour cela un fichier, appelons-le naxsi.rules dans lequel on spécifiera :

- l'activation des règles

- l'URL de redirection en cas de rejet

- les scores associés aux différentes détections

- d'éventuelles listes d'exception

Dans son aspect minimal, le fichier sera de cette forme :

SecRulesEnabled;

DeniedUrl "/denied";

## check rules

CheckRule "$SQL >= 8" BLOCK;

CheckRule "$RFI >= 8" BLOCK;

CheckRule "$TRAVERSAL >= 4" BLOCK;

CheckRule "$EVADE >= 4" BLOCK;

CheckRule "$XSS >= 8" BLOCK;

Il convient de créer une location denied, par exemple :

location /denied {

        rewrite ^ http://foobar.net/503.gif break;

}

Pour « activer » naxsi, la simple inclusion du fichier naxsi.rules précédemment créé suffit. Par exemple, pour sécuriser nos scripts PHP, nous ajoutons à notre location ~ \.php$ :

include /usr/pkg/etc/nginx/naxsi.rules;

Un rechargement de nginx plus loin, voici le résultat d'une tentative d'exploitation de notre backdoor :

$ curl -I -o- http://coruscant/own.php?path=/etc/passwd

HTTP/1.1 302 Moved Temporarily

Server: nginx/1.2.6

Date: Sun, 17 Feb 2013 13:43:32 GMT

Content-Type: text/html

Content-Length: 160

Connection: keep-alive

Location: http://foobar.net/503.gif?ip=192.168.0.1&server=coruscant&uri=/own.php&learning=0&total_processed=4&total_blocked=4&zone0=ARGS&id0=1202&var_name0=path

4. Monsieur Propre

Bien que fonctionnelle, cette configuration peut s'avérer pénible à copier/coller, et rendre l'administration de notre serveur Web fastidieuse, alors que ce dernier est syntaxiquement beaucoup plus ordonné et simple que notre bon vieux Apache. Nous allons utiliser et abuser des fonctionnalités d'inclusion que nous propose nginx.

Bien loin de l'expérimentation, l'organisation que vous allez découvrir est celle utilisée sur le serveur Web affichant les sites du groupe GCU-Squad[11]. Le groupe propose plusieurs services, certains statiques, certains dynamiques, nous allons voir comment proprement disposer ces différents sites, en protégeant ceux qui doivent l'être.

Il m'est fastidieux de parcourir des dizaines de fichiers de logs d'erreur, aussi n'aurais-je qu'un seul et même error.log pour tous les hôtes virtuels que sert la machine (virtuelle, elle aussi) :

error_log /var/log/nginx/error.log;

Les différents sites sont en réalité servis par l'excellent proxy inverse varnish (voir les non moins excellents articles sur ce sujet sur le site UnixGarden[13][14]), ainsi, ce ne sont pas directement les IPs des clients que voit arriver nginx, mais celle du proxy. Ce problème se contourne aisément à l'aide du module real_ip :

        set_real_ip_from 192.168.0.254;

        real_ip_header X-Forwarded-For;

Aucune autre directive concernant nos hôtes virtuels ne viendra polluer le fichier de base nginx.conf, nous inclurons le reste :

include /usr/pkg/etc/nginx/sites/*;

Notre fichier se résume alors à ces quelques lignes :

user   www www;

worker_processes 1;

error_log /var/log/nginx/error.log;

events {

    worker_connections 1024;

}

http {

    include /usr/pkg/etc/nginx/mime.types;

    default_type text/plain;

    sendfile on;

    keepalive_timeout 65;

    set_real_ip_from 192.168.100.254;

    real_ip_header X-Forwarded-For;

    include /usr/pkg/etc/nginx/naxsi_core.rules;

    include /usr/pkg/etc/nginx/sites/*;

}

Dans le répertoire sites/, nous distinguons deux fichiers :

ls sites/

dynamic   static

Qui correspondent aux deux types de services que nous trouvons sur ce serveur Web, des sites statiques, et des sites dynamiques. Nous mettrons l'emphase sur la structure d'un vhost dynamique :

server {

        server_name gcu.info www.gcu.info gcu-squad.org www.gcu-squad.org;

        root /chemin/vers/gcu/www;

        include /usr/pkg/etc/nginx/php.conf;

}

Là encore, peu de directives, la liste des FQDN autorisés, un simple DocumentRoot et une inclusion. Voyons cette dernière de plus près :

client_max_body_size    20M;

include /usr/pkg/etc/nginx/logs.conf;

include /usr/pkg/etc/nginx/denied;

include /usr/pkg/etc/nginx/global.conf;

location / {

        index index.php index.html;

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

}

location ~ \.php$ {

        include /usr/pkg/etc/nginx/naxsi.rules;

        include /usr/pkg/etc/nginx/fastcgi_params;

}

Nous avons parlé de la location ~ \.php$ plus haut dans cet article, aussi voyons le contenu des 3 inclusions :

$ cat /usr/pkg/etc/nginx/logs.conf

if ($host ~ gcu) {

    set $log_fqdn $host;

}

access_log /var/log/nginx/$log_fqdn.access_log;

Nginx permet l'utilisation de certaines variables dans des paramètres comme access_log, ainsi, chaque vhost disposera de son fichier de log personnalisé, à condition que le FQDN contienne le mot-clé « gcu ». Attention, cette astuce ne fonctionne étrangement pas pour l'error_log

Nous avons déjà étudié la location /denied, mais notez qu'il s'agit désormais d'un fichier séparé qu'il est possible d'inclure au lieu d'en copier-coller le contenu.

Le fichier global.conf regroupe des paramètres que nous souhaitons inclure dans chacun des vhosts :

listen 80;

location = /favicon.ico {

        log_not_found off;

        access_log off;

}

location = /robots.txt {

        allow all;

        log_not_found off;

        access_log off;

}

location ~ /\.ht.* {

        deny all;

}

On écoute sur le port 80, on ne souhaite pas logger les erreurs 404 liées aux recherches automatiques de fichiers favicon ni de robots.txt. Enfin, nous interdisons la lecture de potentiels fichiers de type htaccess / htpasswd.

La structure d'un site statique est similaire aux hôtes dynamiques :

server {

    server_name tuhs.gcu.info tuhs.gcu-squad.org;

    root /home/ftp/mirrors/tuhs;

    autoindex on;

    include /usr/pkg/etc/nginx/logs.conf;

    include /usr/pkg/etc/nginx/denied;

    include /usr/pkg/etc/nginx/global.conf;

    include /usr/pkg/etc/nginx/static_location;

}

On autorise, pour certains vhosts, l'auto-indexation afin de montrer le contenu d'un répertoire à l'aide de la directive autoindex on. Le contenu du fichier static_location quant à lui, se résume à la déclaration d'une location /:

$ cat static_location

location / {

        include /usr/pkg/etc/nginx/naxsi.rules;

        index   index.html;

}

Bien découpée, notre configuration nous permet de manipuler très simplement nos multiples vhosts, en épargnant au maximum nos fragiles petits doigts de rébarbatifs copier-coller.

5. La blanche règle

Serveur en place et configuré, ne reste plus qu'à spécifier à naxsi les exceptions qu'il devra faire. En effet, le site GCU-Squad est propulsé par WordPress, et ce dernier utilise de façon intensive de multiples caractères douteux dans un contexte parfaitement licite. Pour présenter le fonctionnement des whitelists, je partirai d'un exemple simple ; WordPress, parmi les innombrables variables qu'il utilise, fait passer en POST (appelé “BODY” dans la terminologie naxsi) la valeur update dans une variable action. Cela lèvera un blocage qui se traduira dans le fichier error.log par quelque chose de ce genre :

2013/02/02 23:57:19 [error] 17370#0: *535 NAXSI_FMT: ip=192.168.0.254&server=www.gcu-squad.org&uri=/wp-login.php&total_processed=3&total_blocked=1&zone0=BODY&id0=1000&var_name0=action, client: 192.168.100.254, server: gcu.info, request: "POST /wp-login.php?action=update HTTP/1.0", host: "www.gcu-squad.org"

On constate ici que la variable de type BODY et de valeur action a provoqué un blocage correspondant à l'id 1000. Dans le fichier de règles de base, on peut lire :

MainRule "rx:select|union|update|delete|insert|table|from|ascii|hex|unhex|drop" "msg:sql keywords" "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:4" id:1000;

Le mot update est souvent utilisé dans le cadre d'injections SQL, mais ici, il est inoffensif, nous allons donc l'ajouter en whitelist. Ceci est réalisé dans notre fichier naxsi.rules, ou éventuellement un fichier tiers inclus, en déclarant une BasicRule. Dans le cas qui nous occupe, cette règle aura la forme suivante :

BasicRule wl:1000 "mz:$BODY_VAR:action";

Décryptage : nous plaçons une whitelist (wl) pour l'id 1000, la zone de match (mz, match zone) est le BODY sur la variable action.

And voila !

Notez que ces règles pouvant d'avérer pénibles à maintenir, l'équipe de développement de naxsi propose sur un dépôt public des règles mises à jour pour plusieurs applicatifs PHP connus[15].

6. Keep control

Une nouvelle génération d'hébergement s'offre à nous, toujours bien heureusement articulée autour de Logiciels Libres, nous gagnons ici plus de contrôle, de lisibilité, mais aussi de sécurité. Bien que cela ne doive pas motiver plus de nonchalance dans les méthodes de développement, la conjonction d'un démon HTTP léger et puissant, d'un moteur de sécurité simple et compréhensible, et d'un système d'interprétation décorrélé du service de rendu, permet une granularité plus marquée, et par conséquent une isolation fort agréable des rôles.
Bien que cette démonstration a pris comme socle le système NetBSD, GNU/Linux n'est pas en reste puisque toutes les briques citées dans cet article sont bien évidemment disponibles dans les distributions majeures, quoique parfois moins à jour. De plus, il est à noter que nous sommes bien loin de l’expérimentation, puisque cette configuration est actuellement en place et en production sur de nombreux sites professionnels dans le cadre d'offres d'hébergement sécurisées, entre autres articulées autour du duo
nginx/naxsi.

Références

- [1] http://fr.wikipedia.org/wiki/LAMP

- [2] http://php.net/manual/en/install.unix.apache2.php

- [3] http://code.google.com/p/naxsi/

- [4] http://php-fpm.org/

- [5] http://news.netcraft.com/archives/2013/02/01/february-2013-web-server-survey.html

- [6] http://www.nbs-system.com/

- [7] http://www.netbsdfr.org/

- [8] http://wiki.nginx.org/HttpRealipModule

- [9] http://fr.wikipedia.org/wiki/Proxy_inverse

- [10] http://fr.wikipedia.org/wiki/R%C3%A9entrance

- [11] http://www.gcu-squad.org/

- [12] https://www.varnish-cache.org/

- [13] http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-138/Varnish-un-proxy-qui-vous-veut-du-bien

- [14] http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-140/Plus-loin-avec-Varnish

- [15] https://github.com/nbs-system/naxsi-rules


Sur le même sujet

Gesturefy : utilisez la navigation « gestuelle » pour gagner en rapidité

Magazine
Marque
Linux Pratique
Numéro
120
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Voilà un module original à ajouter à votre navigateur web : Gesturefy va en effet vous permettre de personnaliser votre navigation en configurant des gestes à réaliser à l’aide de votre souris, le but étant évidemment de vous permettre de gagner en rapidité lors de vos explorations sur le Web.

Crostini : débridez Chrome OS avec les applications Linux

Magazine
Marque
Linux Pratique
Numéro
120
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Chrome OS est basé sur un système Linux (Gentoo), mais l'approche adoptée par Google est de limiter les possibilités de paramétrage et d'installation d'applications. Pour améliorer la polyvalence de son système sans remettre en cause son modèle sécuritaire, Google a, par la suite, introduit Crostini : une solution basée sur LXC pour que les utilisateurs de Chrome OS puissent travailler avec Linux dans un conteneur.

Analysez, diagnostiquez et dépannez votre système avec Sysdig

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Un système ne manque pas d’avoir des problèmes matériels, de plantage système, de performances, au niveau utilisateur ou noyau. Et malheureusement, les systèmes Linux ne sont pas exempts de ces problèmes à dépanner. Mais heureusement, Linux n’est pas en reste d’outils pour vous aider à diagnostiquer les problèmes. Des outils simples comme top pour surveiller l’usage CPU, ou ps pour les processus. Vous voulez tracer un appel système d’un processus : strace est votre ami. tcpdump, ou tshark vous aideront à inspecter le trafic réseau en ligne de commandes. Vous avez donc beaucoup d’outils à disposition, dans l’esprit « un outil précis pour une tâche unique », cher à Linux. Le problème c’est que lorsque l’on dépanne un système, on n’a pas le temps de se souvenir de tous les outils à disposition et taper toutes ces commandes en live. Outils qui ont chacun une philosophie différente, une interface d’entrée et de sortie différentes, ce qui peut poser soucis dans des situations stressantes et créer de la confusion lors d’occasions qui demandent de réagir dans l’urgence. Surtout que la plupart de ces outils ne sont pas pensés et optimisés pour être utilisés dans des conteneurs, plateformes de plus en plus utilisées et répandues.

Partagez vos fichiers volumineux facilement et de manière sécurisée avec Firefox Send

Magazine
Marque
Linux Pratique
Numéro
120
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Firefox Send est un service de Mozilla de partage de fichiers en ligne. Pour des utilisateurs non techniques, qui ne sauraient pas utiliser un serveur FTP ou tout autre partage réseau, c’est une très bonne alternative web pour mettre en ligne des fichiers volumineux de manière simple. Il existe déjà de nombreux services similaires, parfois gratuits et souvent propriétaires. Dans cet article, nous allons voir comment utiliser ce service pour partager de manière sécurisée vos fichiers, et surtout pour héberger votre instance.

Mettez en place une gestion efficace de vos journaux système avec Loki

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Bien avant les métriques et les graphiques de performances, les journaux système étaient la première source pour dépanner un système ou un service qui posait problème. Et ils le sont toujours : par défaut, sans aucune configuration, n’importe quel système Linux ou service journalise son activité et ses erreurs. Mais tout comme les métriques, si vous commencez à avoir à administrer plusieurs systèmes, la question se pose de centraliser ces journaux pour pouvoir les consulter simplement. Et quel stockage utiliser ? Des solutions, privées comme Splunk, ou libres comme Kibana sont déjà très populaires. Mais leur type de stockage (ElasticSearch pour Kibana), avec un indexage pour la recherche plein texte, prend beaucoup de place à l’utilisation et en sauvegarde, pour un intérêt limité dans la majorité des cas d’utilisation. Dans cet article, nous allons découvrir Loki, une solution toute récente, plus légère, pour gérer vos journaux.

Basez votre supervision sur des logs de qualité avec Rsyslog

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Les événements systèmes (aussi nommés logs dans la suite de l’article) sont des éléments déterminants pour la supervision du bon fonctionnement du système d’exploitation. Leur intérêt est souvent sous-coté aussi bien du point de vue maintenance du système que de sa sécurité. Cet article a pour ambition de poser les bases d’une bonne gestion des logs.

Par le même auteur

Amazon <3 Linux

Magazine
Marque
GNU/Linux Magazine
Numéro
207
|
Mois de parution
septembre 2017
|
Domaines
Résumé
Qui d'entre vous n'a jamais entendu parler de AWS (Amazon Web Services), LE cloud public qui domine le marché, la panacée du DevOps, le destructeur de toute une industrie, l'hébergeur qui soutient désormais un bon 40% du Web mondial ? Si tu réponds « moi » à cette question, tu devrais visiter autre chose que des sites en HTML v2 et cesser d’éditer tes fichiers de conf à la main.La triple pique d'entrée de jeu c'est gratos, ça me fait plaisir. AWS, c'est le rouleau compresseur, et cette position de leader n'est pas liée à la chance, puisque comme nombre de solutions disruptives, les analystes les plus pointus proféraient à son lancement que « ça marchera jamais » ©®™ ; non, le succès de ce cloud réside en grande partie dans son API, ses outils, le plus souvent libres, et la puissante communauté qui s'est construite autour. Ce que je vous propose dans cet article, c'est de faire connaissance avec ces outils, et en particulier l'AWS cli [1] basée sur boto3[2], tous les deux sous licence Apache 2[3].

Des bits comme s'il en pleuvait : une appliance SAN/NAS sous NetBSD

Magazine
Marque
GNU/Linux Magazine
Numéro
181
|
Mois de parution
avril 2015
|
Domaines
Résumé
À Noël, je suis le désespoir de ma famille. En effet, là où d'autres demandent des Blu-ray, de quoi s'habiller en hiver ou encore une nouvelle poêle à frire, moi je demande des composants. Des disques, des cartes, des trucs super pas excitants pour les personnes qui vous les offrent. Cette année, je voulais plus de place sur mon NAS [1], plein de bits pour y coller des documents à haute teneur multimédia.

NetBSD, le système du futur du subjonctif

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Domaines
Résumé
« The Original UNIX », c'est pour cette punchline que j'avais voté lorsque le groupe chargé du marketing chez NetBSD cherchait une approche différente du classique « of course it runs NetBSD » ; néanmoins, s'il est l'héritier le plus direct des travaux du CSRG [1] et l'un des plus grands défenseurs de la portabilité du code, le projet NetBSD n'est certainement pas un système d'exploitation du passé, loin s'en faut. Bénéficiant des avancées standards d'autres OS, NetBSD dispose en outre d'avantages uniques dont l'administrateur système aguerri saura faire usage. Dans cet article, nous allons monter un serveur web articulé autour de briques modernes, et allons dans notre périple découvrir l'ensemble des éléments nécessaires au déploiement d'un système aussi réactif que respectueux des standards.

Préface

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Résumé

Huit ans. Huit ans se sont écoulés depuis les deux derniers numéros hors-séries BSD et le mook que vous tenez entre les mains. Il y a huit ans, il est probable qu'une bonne partie d'entre vous n'avait même jamais touché un système UNIX/Linux, et réalisait plutôt son grand œuvre Lego(c)(tm).

Pendant ces huit années, le monde du Libre a proprement explosé, il est partout, omniprésent sur vos mobiles, vos tablettes, votre télé ou votre point d'accès Wi-Fi ; et si des sociétés telles que Google ne se cachent pas d'utiliser le système GNU/Linux comme socle entre l'espace utilisateur et le matériel, d'autres, sans totalement le masquer, ne font pas étalage des technologies libres constituant la pierre angulaire de leurs systèmes. En tête de liste notons particulièrement la société Apple, dont l'espace utilisateur du système d'exploitation Mac OS X est directement issu de FreeBSD.

Les différents BSD

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Domaines
Résumé

« Salut, je voudrais installer *BSD, vous me conseillez quoi ? »Cette phrase, lue et relue des centaines, des milliers de fois, est fondamentalement incorrecte. *BSD n'existe pas. Plus important, lorsque l'on souhaite mettre le pied à l'étrier d'un système BSD, un minimum de contexte est nécessaire, car chacun des héritiers de BSD UNIX suit une philosophie bien définie, et si chacun d'entre eux s'avère éminemment versatile, certains seront plus adaptés et faciles d'accès fonction de l'utilisation souhaitée. Nous allons ici faire connaissance avec les trois systèmes BSD les plus connus, NetBSD, FreeBSD et OpenBSD et évoquer leurs forces et faiblesses afin de guider votre choix de façon la plus objective possible.

Jouons un peu (plus) avec nginx

Magazine
Marque
GNU/Linux Magazine
Numéro
172
|
Mois de parution
juin 2014
|
Domaines
Résumé
Il existe pour le serveur web / proxy inverse nginx une foule de modules tierce partie, à ajouter au besoin, pas encore intégrés upstream mais pourtant de très bonne facture. Parmi les auteurs de ces modules, il en est un qui sort du lot par la quantité mais surtout la qualité de ses contributions, il s'agit de Yichun Zhang, plus connu sous son pseudo : agentzh.