PAB's blog

Le serveur web Apache est extrêmement modulable quand il s'agit de filtrer des requêtes. Si tout le monde connaît les habituelles commandes Require all denied, Require all granted, Require Host example.org, nous allons voir ici comment utiliser une variable interne d'environnement et l'utiliser comme contrôle d'accès à un hôte virtuel.

Imaginons par exemple le cas suivant : nous souhaitons n'autoriser que certaines IP à se connecter, sauf pour les navigateurs dotés d'un User-Agent très spécifique.

Avant toute chose, il est nécessaire d'activer le module SetEnvIf (https://httpd.apache.org/docs/2.4/mod/mod_setenvif.html) qui permet de paramétrer une variable d'environnement d'Apache. Sous Debian (ou dérivé), cela se fera par :

a2enmod setenvif

Commençons par placer une condition sur l'IP :

SetEnvIf Remote_Addr 1.2.3.4 variable

ou alors si le serveur se trouve derrière un proxy qui fournit l'adresse d'origine dans le champ X-Forwarded-For :

SetEnvIf X-Forwarded-For 1.2.3.4 variable

La valeur fixe 1.2.3.4 peut-être remplacée par toute expression régulière de son choix.

Puis filtrons sur le User-Agent :

SetEnvIf User-Agent ^MaValeurPerso variable

Et finalement, expliquons à Apache qu'il faut interdire l'accès si aucune des conditions n'a été atteinte :

Require env variable

Dès lors, une fois la configuration rechargée, Apache n'autorisera l'accès qu'aux requêtes provenant de 1.2.3.4 ou émises par un navigateur au User-Agent correspondant à l'expression régulière ^MaValeurPerso. Ces éléments de configuration offrent beaucoup de richesse !

Pour que le DTMF d'une pieuvre Polycom IP 7000 fonctionne avec Xivo, il faut forcer l'usage du DTMF selon la RFC 2833 tel que ci-dessous :

Il est souvent plus commode de voir s'afficher le nom de son correspondant plutôt qu'un numéro. Cela est bien sûr possible sur Xivo (au moins avec les terminaisons VOIP compatibles, mais je subodore non testé cependant que cela fonctionnerait pour toutes).

Nous allons voir ici comment faire.

Sur les téléphones

Il n'y a rien à faire :-)

Sur le serveur Xivo

Nous allons procéder en 3 temps :

1. nous allons d'abord activer la fonction d'annuaire inversée sur Xivo en précisant quel(s) annuaires doivent être consultés pour la fonctionnalité
2. nous allons ensuite paramétrer les champs qui seront interrogés pour la requête inversée
3. et enfin nous définirons le champ retourné pour affichage si le numéro est reconnu*

Activer l'annuaire inversé

Il faut se rendre dans Services > CTI server > Directories > Reverse directories : puis faire glisser vers la boîte de droite les annuaires que l'on veut voir utilisés pour la fonction d'annuaire inversé.

Paramétrer les champs utilisés pour la requête inversée

Dans Services > CTI server > Directories > Definitions, on choisit de modifier l'annuaire xivodir :

Dans le champ Match reverse directories, on spécifie chaque champ qui est utilisé pour retrouver le numéro de téléphone de l'appelant, par ex.

phonebooknumber.office.number,phonebooknumber.mobile.number,phonebooknumber.home.number

Attention ! Il est très important d'avoir une ligne dans "Mapped fields" pour chacun des champs ! Ainsi, si Match reverse directories contient "phonebooknumber.office.number,phonebooknumber.mobile.number,phonebooknumber.home.number" alors il faut voir une ligne pour chacun dans la liste ci-dessous. On peut ajouter une nouvelle ligne à l'aide du bouton plus.

Paramétrer le champ affiché

Lorsqu'un numéro est trouvé dans l'annuaire, c'est le contenu du champ "reverse" qui est envoyé au téléphone pour affichage. Par défaut, "reverse" pointe vers "phonebook.fullname" : vous pouvez modifier ce champ à votre gré.

Redémarrer les services pour la bonne forme

Pour la bonne ferme, on pourra redémarrer les services en charge des annuaires :

service xivo-ctid restart
service xivo-agid restart

Xivo est un logiciel libre d'autocommutateur privé (PBX) basé sur Asterisk et Debian, et (cerise sur le gateau) développé par des français : que des bons arguments. Nous allons détailler ici l'installation de Xivo et quelques paramétrages pour bien démarrer.

Installation à partir de l'iso Xivo sur une machine physique

La dernière version peut être téléchargée sur le site de Xivo : http://www.xivo.io/. Une fois placée sur une clé USB ou tout autre périphérique bootable, on peut lancer le processus d'installation qui est basé sur l'installateur de Debian.

Si Xivo ne m'a apporté que du bonheur une fois installé, il faut noter que l'installation a été quelque peu difficile. Avec l'installateur non graphique, en fin d'installation, on a l'impression que l'installateur se fige (souvent sur console-setup à 97%). Ce bug est déjà rapporté ici. Toutefois, dans mon expérience, le gel n'est qu'apparent : si l'on exécute Ctrl+Alt+F1 puis Ctrl+Alt+F2 on rafraîchit manuellement l'affichage. Clairement pas idéal, mais au moins cela permet d'achever l'installation.

Il se lit sur internet que l'installation ne pose pas de problème en mode graphique, je recommanderai donc ce choix par défaut à ceux qui veulent tenter l'aventure !

Il est également possible d'installer Xivo depuis une installation fraîche de Debian Wheezy en suivant les instructions détaillées ici. Cela fonctionne plutôt bien, cela me semble une bonne alternative !

Et pour le test ?

Xivo se déploie sans peine sur Virtualbox (4.3.30_Debian) à condition d'installer une version minimale de Debian Wheezy puis d'exécuter le script d'installation tel que détaillé ici. Pratique !

Premier démarrage

Là encore, mon premier démarrage n'a pas été aussi facile qu'espéré. Après plusieurs essais infructueux, je présente ici la suite d'actions qui a fonctionné chez moi. Notez que cela n'est pas tout à fait identique à la documentation officielle. Je vous conseille de suivre d'abord la documentation officielle et de n'utiliser ma petite "méthode" qu'en cas de besoin. Dans mon cas, le démon xivo-provd ne démarrait pas lors du premier démarrage de la machine ce qui bloquait la configuration avec l'interface web...

Au premier démarrage de la machine xivo, si nécessaire, on modifie la configuration réseau dans /etc/network/interfaces puis on affecte la valeur startup = yes dans /etc/default/xivo. Et on redémarre.

Une fois la machine à nouveau prête, on peut se connecter à l'interface d'administration de Xivo depuis une autre machine en saisissant l'adresse http://192.168.a.b où 192.168.a.b est l'adresse IP de la machine Xivo.

Et on peut alors se laisser guider dans la configuration avec l'utilitaire assisté.

Quelques ressources pour bien démarrer

Paramétrer un SIP trunk

Si vous avez l'ambition d'atteindre l'extérieur depuis les postes connectés au PBX Xivo, il est probable que vous souhaitiez connecter un SIP trunk. Tout se passe dans IPBX > Trunk management > SIP protocol.

Pour ce faire, vous pouvez suivre cette documentation : http://xivo.readthedocs.org/en/latest/administration/interconnections/xivo_with_voip_provider.html

En sus des paramétrages évoqués, j'ai ajouté ces 2 options :

• DTMF : RFC2833, cela a ensuite fonctionné sans souci avec un SIP trunk d'OVH
• Monitoring : 2000ms, car la machine Xivo se trouve derrière un NAT

Retrouver un mot de passe perdu

Si vous avez égaré le mot de passe d'accès à l'interface web de Xivo, pas de panique : cette commande exécutée en root sur la machine vous permettra de le retrouver :

sudo -u postgres psql -c 'select login, passwd from "user"' asterisk

TightVNC Server se déploie assez facilement sur un parc de machines Windows à l'aide de la commande :

msiexec /i tightvnc-2.7.10-setup-64bit.msi /quiet /norestart ADDLOCAL="Server" VIEWER_ASSOCIATE_VNC_EXTENSION=1 SERVER_REGISTER_AS_SERVICE=1 SERVER_ADD_FIREWALL_EXCEPTION=1 VIEWER_ADD_FIREWALL_EXCEPTION=1 SERVER_ALLOW_SAS=1 SET_USEVNCAUTHENTICATION=1 VALUE_OF_USEVNCAUTHENTICATION=1 SET_PASSWORD=1 VALUE_OF_PASSWORD=unmotdepasse SET_USECONTROLAUTHENTICATION=1 VALUE_OF_USECONTROLAUTHENTICATION=1 SET_CONTROLPASSWORD=1 VALUE_OF_CONTROLPASSWORD=autremotdepasse

Les paramètres fournis à l'installateur sont assez explicites : on demande au serveur de s'enregistrer comme un service, on paramètre les mots de passe d'accès pour le client mais aussi pour le changement de configuration du serveur...

Le déploiement se passe à merveille avec Updatengine dont nous avons déjà parlé ici :

La connexion via SSH (échange de clés) à l'une de mes machines (Debian Jessie 64 bits) mettait un temps certain à s'établir : une petite dizaine de secondes. Mon beau-frère (celui fort en ordinateur, on en a tous un) m'a sauvé, il m'a annoncé doctement que la machine manquait sans doute d'entropie.

Et il avait raison !

Pour vérifier le stock d'entropie sur la machine :

cat /proc/sys/kernel/random/entropy_avail

me retournait des valeurs proches de 700 sur la machine à laquelle je me connectais.

Nous installâmes alors un démon pour récolter l'entropie :

apt install haveged

et dès lors

cat /proc/sys/kernel/random/entropy_avail

retournait des valeurs proches de 2000.

Et la connexion SSH s'établissait en un clin d'oeil.

Trop fort mon beau-frère.

Unicorn et Thin sont deux serveurs pour Ruby assez fréquemment utilisés et cités dans la littérature informatique. A titre d'exemple, Unicorn est utilisé notamment chez Github: une bonne référence ! Thin est souvent cité pour sa robustesse et sa légèreté. Lequel choisir ?

Avant d'envisager le déploiement d'une application en production (prévision de charge : quelques centaines d'utilisateurs simultanément), j'ai souhaité les comparer.

Protocole de test

• Linux Debian Jessie, Core M 5Y10, 4 Go de RAM, disque dur SSD ; les tests sont effectués en local sur la machine et le réseau n'intervient donc pas comme facteur dans le test.
• Le stress test est réalisé avec Gatling (dont j'ai déjà décrit le fonctionnement ici) qui simule l'arrivée de 200 utilisateurs en 120 secondes sur l'application, chaque utilisateur exécute 8 requêtes sur l'application.
• L'application Ruby on Rails (Rails 4.2.1, Ruby 2.2.2) est prête à l'emploi en environnement de production, les 2 gems Thin et Unicorn sont installés et fonctionnels.
• Quand cela est nécessaire, Pound est utilisé comme "load balancer".
• Thin est exécuté avec la commande :

thin -s 4 -e production -p 8080 start

ou, quand on le lance avec un seu

thin -e production -p 8080 start

• Unicorn est exécuté par la commande :

unicorn -c config/unicorn.rb -E production -p 8080

avec pour contenu du fichier de config unicorn.rb une configuration très proche de celle proposée par Github sur cet article :

rails_root = "/path/to/app"
rails_env = ENV['RAILS_ENV'] || 'production'

# 4 workers, may be changed to 1 for the tests
worker_processes (rails_env == 'production' ? 4 : 1) 

# Load rails+app into the master before forking workers
# for super-fast worker spawn times
preload_app true

# Restart any workers that haven't responded in 30 seconds
timeout 30

before_fork do |server, worker|
  ##
  # When sent a USR2, Unicorn will suffix its pidfile with .oldbin and
  # immediately start loading up a new version of itself (loaded with a new
  # version of our app). When this new Unicorn is completely loaded
  # it will begin spawning workers. The first worker spawned will check to
  # see if an .oldbin pidfile exists. If so, this means we've just booted up
  # a new Unicorn and need to tell the old one that it can now die. To do so
  # we send it a QUIT.
  # Using this method we get 0 downtime deploys.

  old_pid = rails_root + '/tmp/pids/unicorn.pid.oldbin'
  if File.exists?(old_pid) && server.pid != old_pid
    begin
      Process.kill("QUIT", File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
      # someone else did our job for us
    end
  end
end

after_fork do |server, worker|
  # Unicorn master loads the app then forks off workers - because of the way
  # Unix forking works, we need to make sure we aren't using any of the parent's
  # sockets, e.g. db connection
  ActiveRecord::Base.establish_connection
end

Les résultats

Match 1 : Unicorn vs Thin, avec un seul processus pour chacun

Quand un seul processus (un seul "worker" dans le vocable propre à Unicorn) est activé, l'arrivée ininterrompue de nouveaux utilisateurs charge considérablement l'application...

Voici les résultats du "stress test" :

On observe que :

• Thin parvient à servir tout le monde, mais au prix de temps de réponse assez longs
• Les temps de réponse sont un petit plus courts avec Unicorn mais en revanche Unicorn échoue à servir un certain nombre d'utilisateurs - le résultat du second graphe montre que l'unique worker d'Unicorn arrête de répondre aux requêtes à plusieurs reprises et pendant des durées assez longues... je n'explique pas bien ce comportement... J'ai pensé à l'impact du paramètre 'timeout 30' mais je n'ai pas observé de différence lorsque j'ai porté la valeur du timeout à 300 (j'ai même observé une amplification du phénomène)...
• Thin semble donc vainqueur sur ce match avec un seul processus... mais voyons vite avec plusieurs processus ce qui sera plus proche d'un déploiement réel !

Match 2 : Unicorn vs Thin, avec 4 processus pour chacun

Nous démarrons cette fois Unicorn avec 4 "workers" et 4 instances de Thin. Afin d'accéder de manière aléatoire aux différentes instances de Thin, nous utilisons cette fois Pound comme "load balancer". Pound a également été utilisé avec Unicorn pour rendre les conditions des tests équivalentes. Pound n'est toutefois "en théorie" pas nécessaire pour Unicorn qui répartit automatiquement les requêtes sur les différents "workers".

Place aux résultats :

On constate que :

• Thin et Unicorn parviennent à servir tous les utilisateurs plus efficacement (normal, la multiplication des processus profite des plusieurs coeurs de la machine hôte)
• Mais Unicorn est plus véloce que Thin : 97% des requêtes sont servies en moins de 800ms par Unicorn alors que seules 63% sont servies dans le même délai par Unicorn
• On remarque également que les 4 processus d'Unicorn jugulent le flux des nouveaux utilisateurs avec au pic 24 utilisateurs en attente là où Thin faiblit peu à peu jusqu'à atteindre un pic à plus de 50 utilisateurs en attente dans l'application (pour rappel, dans le scénario testé, 200 utilisateurs se connectent régulièrement au cours des 120 secondes à l'application et exécutent 8 requêtes)
• C'est donc une victoire d'Unicorn qui se tire mieux cette fois de la situation !

Conclusion

Je suis tenté de préférer Unicorn pour servir un site Ruby on Rails chargé. Cependant, il conviendra d'offrir suffisamment de workers à Unicorn pour qu'il puisse faire le travail correctement !

Quelques enseignements annexes :

L'impact de Pound sur les temps de réponse

Sans Pound, le temps de réponse moyen de Unicorn est de 117 ms. Avec Pound, toute autre chose étant égale par ailleurs, le temps de réponse moyen est de 161 ms. Il semble donc que le passage par Pound augmente le temps moyen de réponse d'environ 40 ms.

La multiplication des workers pour Unicorn : bonne ou mauvaise idée ?

La machine de test dispose de 4 coeurs. J'ai testé 4 workers et 16 workers avec Unicorn. Les résultats sont très similaires : respectivement 131 et 130 secondes pour effectuer le scénario de test complet. Les temps de réponse moyens sont là encore très proches : 113 ms vs 117 ms. Je ne pense pas que les différences constatées soient significatives. Les écart-types sur le temps de réponse diffèrent plus : 216 ms avec 4 workers et 265 ms pour 16 workers... Compte-tenu du nombre de coeurs sur la machine de test (4), l'utilisation de 16 workers ne semble pas permettre des gains substantiels. Un petit excès du nombre de workers par rapport au nombre de coeurs est peut-être à conseiller toutefois.

It is not obvious to change the VLAN for the WAN port on a router using the Tomato firmware. This might be a necessity when the PPPoE infrastructure of your internet provider requires such a setting.

This is the case in France with the Orange provider (not for DSL but for fiber access): the internet traffic should transit on the VLAN 835.

To do so with Tomato:

1. choose the PPPoE connection for the WAN (do not forget username and password if needed)
2. get to the Advanced settings, VLAN page and change the VID for the WAN to correspond to the required VLAN. With some routers (such as the Asus RT-N16), changing the VID does not work and you should in fact add an offset and change the VLAN number. As an example, for VLAN 835, you have to choose a VID offset of 832 and set the WAN to the VLAN 3. Then VID should automatically change to 835.
3. save and reboot, the WAN connection should now work

You can see below the appropriate setting for a WAN over VLAN 835 as requested by French Orange provider.

Hope this helps!

On ne présente plus ownCloud/Nextcloud, plateforme de stockage et partage de fichiers fort aboutie. Pour ceux qui hébergent leur propre instance d'ownCloud/Nextcloud, voici deux petites astuces pour bien entretenir et sécuriser l'installation.

La rotation des logs

La rotation des logs évite que le fichier owncloud.log n'occupe une place trop importante sur votre serveur. On pourra utiliser logrorate pour effectuer la rotation automatique et régulière.

Dans /etc/logrotate.d/owncloud, on placera le paramétrage (assez explicite) suivant :

/var/www/owncloud/data/owncloud.log {
        weekly
        missingok
        rotate 8
        compress
        notifempty
        create 640 www-data www-data
}

et le tour est joué. On prendra bien sûr le soin d'adapter le chemin vers le fichier et le nom de l'utilisateur créateur du fichier (ici www-data car c'est l'utilisateur propriétaire du serveur web sous Debian) ! Si l'on utilise Nextcloud plutôt qu'ownCloud, on remplacera owncloud.log par nextcloud.log sans surprise !

Surveillance avec fail2ban

Fail2ban est capable de détecter des connexions non autorisées et de bannir (via iptables) l'adresse IP offensante. Un éventuel attaquant n'aura ainsi pas tout le loisir de tester les combinaisons nom d'utilisateur / mot de passe à son aise. Concrètement, on paramètre fail2ban pour vérifier régulièrement un fichier de log et pour détecter dans ce fichier les tentatives d'accès frauduleuses (i.e. qui se répètent). Puis, quand une tentative frauduleuse est repérée, on bannit l'adresse IP correspondante.

Nous allons créer un nouveau filtre pour fail2ban dans /etc/fail2ban/filter.d/owncloud.conf :

[Definition] 
#Pour owncloud <8
failregex = {"app":"core","message":"Login failed:(.*)IP: '<HOST>'
#Pour owncloud 8
failregex = {"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>', X-Forwarded-For: '.*'\)","level":2,"time":".*"}

Si l'accès est contrôlé par un proxy, on pourra modifier la règle pour repérer l'adresse IP associée au champ X-Forwarded-for :

[Definition]
#Pour owncloud <8
failregex = {"app":"core","message":"Login failed:(.*)X-Forwarded-For: '<HOST>'
#Pour owncloud 8
failregex = {"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '.*', X-Forwarded-For: '<HOST>'\)","level":2,"time":".*"}

On peut alors créer une nouvelle règle dans /etc/fail2ban/jail.local :

[owncloud]
enabled  = true
port     = http,https
filter   = owncloud
logpath  = /var/www/owncloud/data/owncloud.log
maxretry = 6

et désormais, toute tentative d'accès répétée conduira à l'exclusion de l'IP douteuse !

'PS Merci à Arnaud Collarde pour la mise à jour de l'expression régulière pour ownCloud 8 et à Guillaume pour mise à jour de la regexp pour Nextcloud 15 qui m'indique que celle-ci pourrai ressembler à

failregex ={"reqId":".*","level":2,"time":".*","remoteAddr":".*","user":".*","app":"core","method":".*","url":".*","message":"Login failed: '.*' \(Remote IP: ''\)","userAgent":".*","version":".*"}

J'ai réalisé que par défaut, il n'était pas possible de rechercher dans l'historique des commandes avec mon shell ZSH (avec la commande Ctrl+R que j'avais déjà utilisée avec d'autres shells). Quà cela ne tienne ! Paramétrons correctement le ~/.zshrc pour réactiver cette fonctionnalité.

Il suffit d'ajouter ces quelques lignes à son .zshrc (celui de son /home ou bien celui général /etc/zsh/zshrc si l'on veut que cela s'applique à tous les utilisateurs) :

bindkey -v
bindkey '^R' history-incremental-search-backward
HISTSIZE=1000
SAVEHIST=1000
HISTFILE=~/.history

pour que désormais Ctrl+R permette d'activer la recherche de commandes historiques, avec par défaut les 1000 dernières commandes saisies enregistrées.

Attention, n'oubliez pas de faire attention alors à tout mot de passe saisi à un moment ou un autre en clair en ligne de commande (par exemple pour se connecter à un FTP, un partage Samba, un webdav...) car alors le mot de passe en clair sera conservé visible dans l'historique jusqu'à sa péremption !