Archive

Archives pour 11/2021

Sécurisez votre serveur MySQL sous Unix

30/11/2021 Aucun commentaire

I. Introduction

Les bases de données (notamment MySQL) sont des éléments primordiaux dans un système d’informations. Elles sont incontournables dans de nombreuses entreprises et les données qu’elles contiennent sont souvent d’une importance cruciale. Ignorer la sécurité du système de gestion de base de données serait une erreur grave tant les conséquences d’une détérioration de la base pourraient s’avérer désastreuses.

Ce document explique quelques moyens simples d’améliorer et maintenir la sécurité de MySQL sous système Unix (Linux, BSD…). Il est bien sûr impensable de croire que les conseils de cet article suffiront à obtenir une sécurité optimale.

À l’instar de la sécurisation du SGBD, il faudra veiller à sécuriser le système d’exploitation de la machine hôte, les autres services actifs (serveurs HTTP, FTP…), le réseau, l’accès physique à cette machine et bien sûr vos applications (éviter les failles d’injection SQL).

II. Exécution du serveur : utilisateur système non privilégié

Après installation du serveur MySQL, beaucoup de personnes ont la fâcheuse habitude de lancer le daemon avec les privilèges de l’utilisateur système root. Ce choix peut s’expliquer par une envie d’utiliser la méthode la plus rapide : le serveur MySQL doit lire et écrire dans certains fichiers auxquels l’utilisateur régulier n’a pas accès ; en le lançant avec les privilèges root, on a l’assurance que MySQL aura les droits nécessaires.

Cette méthode d’exécution parait anodine. Cependant, elle peut conduire à des dégâts énormes. Le processus du daemon MySQL tournant avec les privilèges super-utilisateur, il a tous les droits sur le système. Imaginons maintenant qu’un pirate puisse prendre contrôle de ce processus (généralement par exploitation d’une faille de type buffer overflow dans MySQL), il deviendra dès lors le maître absolu de la machine hôte du serveur. Il pourra créer des fichiers, installer des programmes, lire des données confidentielles, ou supprimer des données.

Bien sûr, si une faille est présente dans MySQL, cela n’est pas la faute de l’administrateur. Mais ce n’est pas une raison pour ne pas s’en protéger. Il est impossible d’empêcher un pirate d’exploiter une telle faille. Les seuls à pouvoir le faire sont les développeurs de MySQL AB, qui, dans une telle situation, proposeront une nouvelle version du serveur.

De son côté, l’administrateur du serveur peut limiter les dégâts afin que le pirate ayant pris le contrôle du processus MySQL ne puisse pas détruire autre chose que la base de données (ce qui n’est déjà pas mal !). Le principe est assez simple : créer un utilisateur spécial dont la seule fonction sera de lancer MySQL. Cet utilisateur doit posséder le moins de droits système possible. La solution optimale serait que cet utilisateur n’ait accès qu’aux fichiers propres à MySQL.

Les administrateurs qui ont suivi le fichier INSTALL ou la documentation officielle de MySQL auront remarqué que la création d’un utilisateur « mysql » est préconisée.

Pour les autres, nous allons voir comment y remédier. Les commandes suivantes permettent de créer un groupe système mysql ainsi qu’un utilisateur mysql appartenant au groupe précédemment créé.

# groupadd mysql
# useradd -g mysql mysql

Pour des raisons de sécurité, il est préférable de s’assurer que cet utilisateur ne puisse pas se logger et ne possède pas de home. La commande suivante permet de spécifier ces options sous OpenBSD. Les paramètres de la commande useradd n’étant pas les mêmes d’un système à l’autre, référez-vous au manuel (man useradd) pour obtenir une commande équivalente chez vous.

# useradd -d /nonexistent -s /sbin/nologin -g mysql mysql

Sous Linux, vous pouvez spécifier /bin/false en tant que shell de l’utilisateur pour qu’il ne puisse pas se logger.

Maintenant que notre utilisateur est créé, nous allons lui donner accès en lecture/écriture aux répertoires de données (tables, index, enregistrements…) de MySQL. Pour cela, nous allons le désigner comme propriétaire de ces fichiers. Par la même occasion, nous nous assurons que l’utilisateur système root est propriétaire des autres fichiers de MySQL :

# cd REPERTOIRE_MYSQL
# chown -R root .
# chown -R mysql data
# chgrp -R mysql .

La commande précédente suppose que le dossier de données de MySQL se trouve dans le même répertoire que les autres fichiers de MySQL. Dans le cas contraire, adaptez la commande selon votre installation.

Assurons-nous ensuite que seuls l’utilisateur et le groupe mysql puissent avoir accès aux fichiers de données :

# chmod -R 660 data
# chmod 700 data/mysql

Une fois les droits attribués, nous pouvons lancer le serveur MySQL en spécifiant que l’utilisateur mysql que nous venons de créer sera le propriétaire du processus. Pour cela, deux possibilités s’offrent à nous.

La première est de rajouter une option à la commande permettant de lancer le serveur MySQL :

# cd REPERTOIRE_MYSQL
# bin/mysqld_safe --user=mysql &

La seconde consiste à modifier le fichier de configuration de MySQL (ex : /etc/my.cnf) afin de spécifier que l’utilisateur par défaut pour l’exécution du serveur est mysql. Il ne sera dès lors plus nécessaire de le répéter lors du lancement du serveur.

[mysqld]
user= mysql

Vérifions enfin que notre serveur MySQL tourne avec des droits limités. Pour cela, nous allons utiliser la commande ps après lancement de MySQL.

ps -aux | grep 'mysql'

La première colonne du résultat de la commande indique le propriétaire du processus. Si votre configuration est correcte, vous devriez donc voir mysql.

Lire la suite…

MySQL: Améliorer les performances grâce au partitionnement

29/11/2021 Aucun commentaire

mysql partitionnementI. Introduction

I-A. Définition

Pour tout bon informaticien, le terme « partitionnement » n’est pas inconnu. Cependant, bien que le partitionnement d’un disque dur soit devenu une banalité, l’utilisation du partitionnement en base de données reste encore rare.

Faisons tout d’abord un rappel sur le partitionnement d’un disque dur. L’intérêt de créer différentes partitions est de pouvoir organiser les données : des partitions sont réservées aux fichiers des systèmes d’exploitation installés et d’autres pour les données personnelles (photos, téléchargements…).

Dans cet article, nous allons nous intéresser au partitionnement dans le domaine des bases de données, et plus exactement au partitionnement de tables. Le but est, comme pour les disques durs, d’organiser les données. Néanmoins, nous n’allons pas utiliser cette organisation pour simplifier nos requêtes, mais bien pour en améliorer les performances !

I-B. Les types de partitionnement

Deux grands types de partitionnement sont utilisés pour partitionner une table :

  • partitionnement horizontal : les enregistrements (= lignes) d’une table sont répartis dans plusieurs partitions. Il est nécessaire de définir une condition de partitionnement, qui servira de règle pour déterminer dans quelle partition ira chaque enregistrement.

Exemple : nous disposons d’une table Amis et nous choisissons de la partitionner en

deux partitions :

  1. Les amis dont la première lettre du prénom est comprise entre A et M,
  2. Les amis dont la première lettre du prénom est comprise entre N et Z.
Image non disponible

Pour récupérer la liste complète de nos amis, il sera nécessaire de regrouper le contenu de nos deux partitions. Pour ce faire, une simple opération d’union d’ensembles suffit ;

  • partitionnement vertical : les colonnes d’une table sont réparties dans plusieurs partitions. Cela peut être pratique pour écarter des données fréquemment utilisées d’autres auxquelles l’accès est plus rare.

Exemple : nous disposons d’une table Amis contenant les prénom et photo de chacun de nos amis. Les photos prenant de la place et étant rarement accédées, nous décidons de les écarter des autres données.

Image non disponible

Comme vous pouvez le remarquer, les deux partitions contiennent l’identifiant des amis. Cela est nécessaire afin de garder le lien entre les données de chaque enregistrement. Ainsi, pour récupérer toutes les informations des amis, il suffit de faire une jointure entre les deux partitions.

Nous connaissons maintenant les deux types de partitionnement. Il est bien sûr possible d’utiliser un partitionnement vertical et un partitionnement horizontal sur une même table, ainsi que de partitionner sur plusieurs niveaux, c’est-à-dire définir des partitions de partitions.

I-C. Les avantages du partitionnement

Le partitionnement apporte plusieurs avantages à un administrateur de base de données. Voici les principaux intérêts du partitionnement :

  • pouvoir créer des tables plus grandes que la taille permise par un disque dur ou par une partition du système de fichiers : il est tout à fait possible de stocker des partitions à des endroits (partitions, disques, serveurs…) différents ;
  • pouvoir supprimer très rapidement des données qui ne sont plus utiles et utilisées : si ces données sont placées sur une partition séparée, il suffit de détruire la partition pour supprimer toutes les données ;
  • optimiser grandement certaines requêtes : les données étant organisées dans différentes partitions, le SGBD n’accède qu’aux données nécessaires lors des requêtes. Sans partitionnement, tous les enregistrements sont pris en compte.

Enfin, notons que le partitionnement de tables est généralement utilisé avec des bases de données réparties où les données sont placées sur des sites géographiques (éloignés ou proches) différents. Cet article se limite au partitionnement sur site local, mais les principes évoqués sont valides pour le partitionnement distant.

I-D. Notes à propos de MySQL

Dans MySQL, le partitionnement n’est géré de manière automatique qu’à partir de la version 5.1. Lors de la rédaction de cet article, MySQL 5.1 est encore en version bêta et par conséquent, il est possible que des bogues subsistent.

De plus, il est important de noter que seules les fonctionnalités de base du partitionnement seront disponibles dans la version finale de MySQL 5.1. Mais il est évident que les versions futures du SGBD apporteront leur lot d’améliorations.

Lire la suite…

Phishing: Un développeur web recommande l’utilisation de “rel=noopener”

29/11/2021 Aucun commentaire

Pour empêcher les attaques par hameçonnage lancées en se servant du window.opener

phishingEn HTML, l’attribut “rel” peut être utilisé sur les balises <a> (qui permet de créer un lien hypertexte pointant vers un document en spécifiant l’URL de celui-ci au niveau de l’attribut “href” et qui permet également de définir des ancres au sein d’un document et les liens pour y accéder), <area> (qui permet de définir une zone particulière d’une image et peut lui associer un lien hypertexte) et <link> (qui permet de définir l’emplacement d’un fichier qui sera accessible au sein de la page où elle est déclarée couramment utilisée pour mettre en relation d’autres documents comme les feuilles de style).

Dans ces différentes balises, il est utilisé pour détailler la relation existante entre le document courant et le document qui sera ouvert par le lien et il prend pour valeur des éléments d’une liste de différentes relations dont les valeurs sont séparées par des virgules (par exemple “alternate”, “author”, “bookmark”, “help”, “license”, “next”, “nofollow”, “noreferrer”, “prefetch”, “prev”, “search”, “tag”).

Mathias Bynens, un développeur web front-end dans la ville de Termonde en Belgique, a voulu partager avec la communauté des développeurs web les bienfaits de l’une des valeurs de l’attribut “rel”, notamment “noreferrer” qui permet entre autres de résoudre un problème, mais lequel ?

En guise de démonstration, dans un billet blog il a proposé une petite expérience. Bynens propose les URL index.html et index/malicious.html. En définissant un lien vers la seconde URL avec l’attribut “target” qui avec la valeur “_blank”, cela va déclencher l’ouverture de la page cible dans une nouvelle fenêtre (dans ce cas la page malicious.html). Pour rappel, lorsqu’une fenêtre est ouverte depuis une autre fenêtre, elle conserve une référence à cette première fenêtre dans window.opener. Si la fenêtre courante n’a pas été ouverte par une autre fenêtre, la méthode renvoie null.

Bynens note que « le document malicious.html dans cette nouvelle page a l’élément windows.opener qui pointe vers l’élément window du document que vous regardez actuellement, c’est-à-dire index.html. Ce qui signifie que lorsque l’utilisateur clique sur le lien, malicious.html a un contrôle total sur l’objet window du document ». Dans le cas d’espèce, malicious.html vient remplacer l’onglet contenant index.html par index.html#hax, qui affiche un message caché.

« Ceci est un exemple relativement inoffensif, mais le lien aurait pu rediriger vers une page d’hameçonnage conçue pour ressembler à la vraie page index.html, demandant des informations de connexion. L’utilisateur ne l’aurait probablement pas remarqué, parce que l’accent est mis sur la page malveillante dans la nouvelle fenêtre tandis que la redirection se passe en arrière-plan. Cette attaque pourrait être encore plus subtile en ajoutant un retard avant de rediriger vers la page de phishing en arrière-plan », a-t-il avancé.

Dans cet exemple, index.html et index/malicious.html ont la même origine. Mais Bynens a indiqué qu’il est possible d’effectuer la même attaque avec des origines différentes.

Que faire pour empêcher que les pages n’abusent de window.opener ? Bynens recommande simplement de se servir de “rel=noopener”, « cela va permettre de vous assurer que window.opener a la valeur “null” sur Chrome 49 et Opera 36. Pour les navigateurs plus anciens, vous pouvez vous servir de “rel=noopener” qui va également désactiver l’en-tête HTTP “Refer”, ou alors vous servir de ce script JavaScript qui va potentiellement activer le bloqueur de popup.

var otherWindow = window.open();
otherWindow.opener = null;
otherWindow.location = URL;
Ne vous servez pas de “target=_blank” (ou tout autre “target” qui ouvre un nouveau contexte de navigation) en particulier pour les liens dans le contenu généré par l’utilisateur, à moins que vous n’ayez une bonne raison ».

Il a déjà averti les éditeurs de navigateurs dans des rapports de bogues. Le problème semble corrigé du côté de Chrome et Opera, mais pas encore chez Firefox, Safari et Edge.

Source : billet Mathias Bynens

Categories: Logiciel Tags: , ,

Voyage au centre du noyau: Traffic Control, la QoS

28/11/2021 Aucun commentaire

Gérer la QoS.

On peut aujourd’hui largement envisager d’héberger un ou plusieurs services sur son serveur à domicile, et des mouvements comme auto-hebergement.fr l’on bien illustré. Reste le problème de la bande passante en upload, qui bien que largement suffisante pour héberger des serveurs web, email, jabber ou autre, reste à utiliser intelligemment.

Linux fournit cette intelligence, sous forme d’un scheduler de paquets nommé Traffic Control (TC, pour les intimes), et l’objectif de cet article est de présenter cette technologie et sa mise en place dans un cas d’étude d’hébergement Web, DNS et même BitTorrent. Notons au passage que bon nombre de scripts et programmes existent pour simplifier la mise en place de la QoS (Quality of Service). Citons Wondershaper, Shorewall, ADSL-Optimizer par exemple. Cet article n’en parlera pas, car l’objectif est ici de faire mais aussi de comprendre comment ça marche sous le capot, et pour ça, il faut démonter le moteur et mettre les mains dans le cambouis.

1. Traffic Control, la QoS, les bases

Traffic Control travaille sur les paquets sortant du noyau. Il n’a pas, initialement, pour objectif de contrôler le trafic des paquets entrants. Cette portion de code du noyau se situe entre la couche IP et le pilote du matériel qui transmet sur le réseau. On est donc très bas dans les couches. En réalité, c’est Traffic Control qui est constamment en charge de transmettre au driver de la carte réseau le paquet à envoyer.

figure1-tcgeneral

Cela signifie, en fait, que le module TC – le scheduler de paquet – est en permanence activé dans le noyau, même quand vous ne pensez pas l’utiliser. Par défaut, ce scheduler maintient une queue (prononcer kiou, une file d’attente) similaire à FIFO dans laquelle le premier paquet entré est donc le premier sortit.

La base de TC est la Queuing Discipline (qdisc) qui représente la politique de scheduling appliquée à une queue. Il existe différentes qdisc. Comme pour le scheduling processeur, on retrouve les méthodes FIFO, FIFO à plusieurs files, FIFO avec hash et round robin (SFQ). On a également un système Token Bucket Filter (TBF) qui attribue des jetons (tokens) à une qdisc pour en limiter le débit (pas de token = pas de transmission = on attend d’avoir un jeton disponible). Cette dernière politique a ensuite été étendue à un TBF hiérarchique, le HTB (Hierarchical Token Bucket). Les politiques que nous allons étudier ici sont TBF, qui pose les fondamentaux, SFQ et HTB. Nous allons également jeter un coup d’oeil à la politique par défaut, que, tout Monsieur Jourdain que nous sommes, nous utilisons sans le savoir: pfifo_fast.

1.1 Premier contact

Jean-Kevin est pressé, il n’a pas de temps à perdre, et tout de suite maintenant, il doit limiter la bande passante sortante de son serveur web à 200kbits par secondes (25ko/s). Au diable la théorie, on y reviendra plus tard, mettons tout de suite les mains dans le cambouis. La mécanique que nous allons mettre en place est simple. Nous allons utiliser une règle Netfilter pour marquer les paquets qui nous intéressent. Ensuite, nous allons fournir à TC une politique qui s’appliquera sur les paquets contenant la marque définie. C’est parti.

1.2 Netfilter MARK

Netfilter permet d’interagir directement avec la structure représentant un paquet dans le noyau. Cette structure, le sk_buff, possède un champ « __u32 nfmark » que l’on va renseigner et qui sera lu par le filtre de TC pour sélectionner la classe de destination du paquet. La règle iptables suivante va appliquer la marque ’80’ sur les paquets sortant (chaine OUTPUT) ayant pour port source le port 80:

# iptables -t mangle -A OUTPUT -o eth0 -p tcp --sport 80 -j MARK --set-mark 80

On peut vérifier que cette règle est bien appliquée aux paquets sortants en visualisant les statistiques de Netfilter.

# iptables -L OUTPUT -t mangle -v
Chain OUTPUT (policy ACCEPT 74107 packets, 109M bytes)
 pkts bytes target prot opt in  out  source   destination
73896  109M MARK   tcp  --  any eth0 anywhere anywhere    tcp spt:www MARK xset 0x50/0xffffffff

1.3 Deux classes dans un arbre

Le binaire /sbin/tc est compris dans le package iproute (sous Debian). Un simple aptitude suffit à l’installer, s’il ne l’est pas déjà. Nous allons créer un arbre dont la racine appliquera la politique HTB. Cet arbre va contenir deux classes: une pour notre trafic marqué, l’autre pour tout le reste et qui sera donc considérée par défaut.

# tc qdisc add dev eth0 root handle 1: htb default 20
# tc class add dev eth0 parent 1:0 classid 1:10 htb rate 200kbit ceil 200kbit prio 1 mtu 1500
# tc class add dev eth0 parent 1:0 classid 1:20 htb rate 1024kbit ceil 1024kbit prio 2 mtu 1500

Les deux classes filles sont raccrochés à la racine. Ces classes possèdent un débit garantie (rate) et un débit maximal opportuniste (ceil). Si la bande passante n’est pas utilisée, alors une classe pourra monter son débit jusqu’à la valeur de ceil. Sinon c’est la valeur de rate qui s’applique. Cela veut dire que la somme des valeurs de rate doit correspondre à la bande passante disponible. Dans le cas d’un upload ADSL classique chez un fournisseur correct, cela sera d’environ 1024kbits (dans le meilleur des cas, éloignement du DSLAM, etc…).

Nous avons maintenant d’un côté un arbre de contrôle de trafic, et d’un autre côté du marquage de paquets. Il reste donc à relier les deux. Cela est fait avec les règles de filtrage de TC. Ces règles sont très simples. On dit à TC de prendre en charge (handle) les paquets portant la marque 80 et de les envoyer (fw flowid) à la classe correspondante. Un point important toutefois, un filtre doit être rattaché à la racine « root » de l’arbre. Sinon, il n’est pas pris en compte.

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 80 fw flowid 1:10

Faisons maintenant le test avec NetCat, on ouvre un port en écoute qui renvoi des zéro. C’est basique et parfait pour tester notre politique. On lance donc :

# nc -l -p 80 < /dev/zero

Et sur une autre machine, on lance un telnet vers le port 80 de la machine en écoute. L’outil iptraf permet de visualiser la connexion en cours et, surtout, son débit (voir figure 2).

figure2-debitqos

Comme on le voit dans l’encadré rouge, en bas à droite, le débit de la connexion est de 199,20kbps. On s’approche de beaucoup des 200kbps, la précision dépendant quelques paramètres que nous allons étudier. Si l’on teste une connexion du même type sur un autre port, on verra un débit limité à 1024kbps, ce qui correspond au débit de la classe par défaut qui s’applique à tous les paquets non marqués.

Lire la suite…

Owncloud: Using the occ Command

28/11/2021 Aucun commentaire

occ: la commande d’administration de ownCloud

ownCloud’s occ command

[ ATTRIBUTE: Please check: http://www.flickr.com/photos/91795203@N02/23828677959 to find out how to attribute this image]

owncloud
ownCloud’s occ command (ownCloud console) is ownCloud’s command-line interface. You can perform many common server operations with occ:

* Manage apps
* Manage users
* Convert the ownCloud database
* Reset passwords, including administrator passwords
* Convert the ownCloud database from SQLite to a more performant DB
* Query and change LDAP settings

occ is in the owncloud/ directory; for example /var/www/owncloud on Ubuntu Linux. occ is a PHP script. You must run it as your HTTP user to ensure that the correct permissions are maintained on your ownCloud files and directories.

The HTTP user is different on the various Linux distributions. See the Setting Strong Directory Permissions section of Installation Wizard to learn how to find your HTTP user.

  • The HTTP user and group in Debian/Ubuntu is www-data.
  • The HTTP user and group in Fedora/CentOS is apache.
  • The HTTP user and group in Arch Linux is http.
  • The HTTP user in openSUSE is wwwrun, and the HTTP group is www.

Running it with no options lists all commands and options, like this example on Ubuntu:

$ sudo -u www-data php occ
ownCloud version 8.0.3
Usage:
 [options] command [arguments]

Options:
 --help (-h)           Display this help message
 --quiet (-q)          Do not output any message
 --verbose (-v|vv|vvv) Increase the verbosity of messages: 1 for normal
                       output, 2 for more verbose output and 3 for debug
 --version (-V)        Display this application version
 --ansi                Force ANSI output
 --no-ansi             Disable ANSI output
 --no-interaction (-n) Do not ask any interactive question

Available commands:
 check                       check dependencies of the server environment
 help                        Displays help for a command
 list                        Lists commands
 status                      show some status information
 upgrade                     run upgrade routines after installation of a new
                             release. The release has to be installed before.

This is the same as sudo -u www-data php occ list.

Run it with the -h option for syntax help:

$ sudo -u www-data php occ -h

Display your ownCloud version:

$ sudo -u www-data php occ -V
  ownCloud version 8.0.3

Query your ownCloud server status:

$ sudo -u www-data php occ status
  - installed: true
  - version: 8.0.3.4
  - versionstring: 8.0.3
  - edition: Enterprise

occ has options, commands, and arguments. Options and arguments are optional, while commands are required. The syntax is:

occ [options] command [arguments]

Get detailed information on individual commands with the help command, like this example for the maintenance:mode command:

$ sudo -u www-data php occ help maintenance:mode
  Usage:
  maintenance:mode [--on] [--off]

  Options:
  --on                  enable maintenance mode
  --off                 disable maintenance mode
  --help (-h)           Display this help message.
  --quiet (-q)          Do not output any message.
  --verbose (-v|vv|vvv) Increase the verbosity of messages: 1 for normal
  output, 2 for more verbose output and 3 for debug
  --version (-V)        Display this application version.
  --ansi                Force ANSI output.
  --no-ansi             Disable ANSI output.
  --no-interaction (-n) Do not ask any interactive question.

 

Apps Commands

The app commands list, enable, and disable apps. This lists all of your installed apps, and shows whether they are enabled or disabled:

$ sudo -u www-data php occ app:list

Enable an app:

$ sudo -u www-data php occ app:enable external
  external enabled

Disable an app:

$ sudo -u www-data php occ app:disable external
  external disabled
Categories: Logiciel Tags: