Categorie : Serveurs

Partage Samba, anonyme, sans mot de passe

Aucun commentaire sur Partage Samba, anonyme, sans mot de passe

novembre 8, 2017 at 10:28 Categorie :Serveurs

Loin de moi l’idée d’être léger en sécurité, mais empêcher l’accès à mes partages réseaux à quelqu’un qui aurait déjà un accès complet à mon réseau… Et bien disons que c’est alors le cadet de mes soucis.
Du coup, je me dis, je ne dois pas être le seul. Ce cas d’usage ne doit donc pas être si rare : ne pas mettre de mot de passe, permettre un partage simple et direct, en lecture et même écriture.

Mais il faut croire que si, car la littérature internet sur samba ne couvre quasiment jamais ce point. Et bien soit, je serai alors un mauvaise élève en sécurité, et tant pis !!

Côté serveur, je note dans mon /etc/samba/smb.conf les paramètres intéressants suivant :

map to guest = Bad Password
guest ok = yes
guest only = yes
guest account = ici_un_vrai_user_ayant_access_au_dossier_que_vous_souhaitez_partager

usershare allow guests = yes

Et pour chaque partage :

[nom_partage]
path = /chemin/dossier/partage
available = yes
browsable = yes
public = yes
writable = yes

Côté client, la ligne magique dans fstab :

//serveursamba/partage /point/de/montage cifs guest,uid=nobody,iocharset=utf8,noperm 0 0

Au passage, admirez le « guest » qui doit être complété de « uid=nobody » (pas du tout redondant comme information). Et admirez la puissance et la précision du message d’erreur quand on essaye n’importe quoi d’autre :

mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Bref, toute cette complexité pour ce qui semble être franchement un cas simple… Je n’arrive pas à m’empêcher de croire qu’il y a quelque part une erreur de design.

Auto-hébergement, Let’s Encrypt, et redirection HTTPS

Aucun commentaire sur Auto-hébergement, Let’s Encrypt, et redirection HTTPS

avril 3, 2016 at 12:03 Categorie :Serveurs

Let’s Encrypt, c’est une initiative formidable pour permettre l’auto-hébergement dans de bonnes conditions.
Enfin des certificats valides pour nos serveurs !

Du coup, on peut avoir la tentation (légitime, et même logique) de vouloir rediriger tout le trafic HTTP vers HTTPS.
Mais attention, car si vous souhaitez utiliser les solutions « automatiques », y compris pour le renouvellement de vos certificats, vous ne pouvez pas rediriger tout HTTP : en effet, Let’s Encrypt effectue des requêtes HTTP pour valider vos domaines…

Je vous conseille donc d’utiliser dans vos hôtes virtuels :80 la directive suivante :
RedirectMatch ^/(?!.well-known)(.*)$ https://votre-site

D’ailleurs, il s’agit de la seule directive nécessaire (à part bien sûr ServerName) dans le bloc VirtualHost :80 de Apache.

Qui aura pour effet de tout rediriger, sauf les requêtes nécessaires à Let’s Encrypt (qui commencent par well-known)

Zimbra affiche mal le nombre d’e-mails dans un dossier

Aucun commentaire sur Zimbra affiche mal le nombre d’e-mails dans un dossier

mars 22, 2016 at 12:17 Categorie :Logiciels | Serveurs | Zimbra

Pour une raison X ou Y, mon compte auto hébergé sur Zimbra s’est mis à mal afficher le contenu de mon dossier Brouillon suite à certaines manipulations que je n’ai pas encore clairement identifié.
En particulier, mon dossier « Brouillons » est écrit en gras et dispose d’un horripilant « (1) » à coté, m’indiquant un e-mail non lu alors que lorsque je liste son contenu depuis l’IHM, je ne vois rien.
Je ne sais pas pourquoi ce message ne veut pas s’afficher, alors qu’il est tout à fait là.
La solution est de recourir à la ligne de commande pour effacer l’importun :

zmmailbox -z -m id@domaine.net s « in:drafts »

num: 1, more: false
Id Type From Subject Date
—— —- ——————– ————————————————– ————–
1. 210029 conv Malo, Gwendal (2) Re: object blabla 03/21/16 17:23

zmmailbox -z -m id@domaine.net dm 210029

Lutte anti spam et Zimbra

Aucun commentaire sur Lutte anti spam et Zimbra

novembre 15, 2014 at 7:17 Categorie :Codage | Serveurs | Zimbra

said: 550
SC-001 (BAY004-MC4F10) Unfortunately, messages from weren't
sent. Please contact your Internet service provider since part of their
network is on our block list

Traduction : Votre serveur fait n’importe quoi, vous êtes bannis !
Voici un message que j’ai reçu après avoir tenté d’envoyer un mail sur un serveur Microsoft… Et vu que vous êtes ici, peut-être que vous aussi ? C’est fâcheux, car avoir un serveur mail personnel c’est bien, mais si il ne peut plus envoyer de mail à une partie de l’internet, ça ne sert plus à grand chose…
Pas de panique, ça se corrige. Mais retroussez vos manches, car il y a du travail.

1 – Corriger le problème

Le premier point est de découvrir ce qui s’est passé.
Dans mon cas, j’ai découvert qu’un spammeur avait volé le login / mot de passe d’un membre de ma famille et se servait de mon serveur SMTP comme d’un relais de spam. Un petit tour dans les logs de zimbra dans /var/log devrait vous en dire plus.

Une fois le problème identifié, réglez le en coupant l’accès au fautif (changez le mot de passe, etc.).

Ensuite, il faut demander à Microsoft d’être gentil et de vous enlever de leur liste noire. C’est par ici. Si vous avez de la chance, d’ici quelques heures vous pourrez de nouveau envoyer des e-mails. Sinon, vous recevrez un e-mail vous expliquant que non, vous restez bannis. Préparez alors le violon, les mouchoirs, prenez votre plus belle plume et rédigez un joli mail expliquant à quel point vous êtes désolé, ainsi que les actions que vous avez entreprises pour que cela ne se reproduise plus. Pour ma part, ayant été banni deux fois pour des problèmes similaires, c’est ce que j’ai du faire avant de voir mon accès ré-autorisé.

Maintenant, préparez-vous un thé, planifiez un peu de temps sans être dérangé, et suivez ces quelques étapes pour vous assurer de ne plus rencontrer ce genre de problèmes. En effet, c’est malheureux, mais comme vous ne pouvez maitriser le comportement de vos utilisateurs (d’autant plus que leur compte peut se faire usurper), il va falloir prendre des précautions annexes.

2 – Prévention : Activer une adresse catch-all

Une adresse catch-all, c’est une adresse qui accepte tous les mails qui ne devraient pas arriver (par exemple parce que le destinataire n’existe pas). Ainsi, si quelqu’un écrit à « fausseadresse@votredomaine.extension », l’adresse catch-all le recevra.

Pourquoi faire ça ? Pour que les e-mails de type bounce ne soient plus envoyés. Un mail de type bounce, c’est un e-mail de non-délivrance émis par des serveurs de mails. Dans notre cas, cela veut dire que si quelqu’un tape une mauvaise adresse en voulant vous joindre, il ne sera pas prévenu… C’est dommage, mais parfois nécessaire, parce que c’est une méthode parfois utilisé pour envoyer des spams à travers un innocent relais. Je m’explique : on appelle çà les « backscatter bounces ». On se fait passer pour un expéditeur qu’on veut cibler, on vous envoie un mail, et résultat c’est VOTRE serveur qui se retrouve à envoyer un e-mail au faux émetteur qui lui n’a rien demandé. Et comme parfois le contenu ou les PJ sont renvoyés dans les bounces, vous avez alors servi de vilain relais de spamm…

Allez hop :

su - zimbra
zmprov modifyAccount user@domain.com zimbraMailCatchAllAddress @domain.com

 

3 – Prévention : Activer policyd

Un spammeur, pour avoir quelques touches, doit envoyer beaucoup, beaucoup d’e-mail. C’est même souvent à ça qu’on les reconnait. Donc, si vous parvenez à réduire l’activité d’un spammeur qui aurait pris le contrôle d’un compte, vous limitez grandement les dégâts, ce qui vous donne plus de temps pour agir avant d’être banni. Pour ça, on peut utiliser policyd, un démon pour postfix intégré à Zimbra (mais non actif par défaut) qui nous permet d’appliquer des politiques de limitation. En avant :

zmprov ms `zmhostname` +zimbraServiceInstalled cbpolicyd +zimbraServiceEnabled cbpolicyd
zmprov mcf +zimbraMtaRestriction "check_policy_service inet:127.0.0.1:10031"

Ensuite pour activer l’interface web qui rend les choses beaucoup plus simples, il faut lui dire d’utiliser la base de données de Zimbra, pour cela, éditez le fichier /opt/zimbra/cbpolicyd/share/webui/includes/config.php et mettez en commentaire “#” chaque ligne commençant par $DB_DSN. L’objectif est de mettre à la place:

$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";

Redémarrez Zimbra, et rendez-vous à l’addresse http://votreserveur:7780/webui/index.php (je ne vous fais pas l’affront de vous dire de faire attention avec cette adresse, hein ? Par exemple s’assurer qu’elle ne peut pas être jointe depuis l’extérieur ? Et un fichier .htaccess ? Hein, vous êtes grand, non ?)

Ensuite, comme j’ai la flemme, je recopie un article :

  1.     Select Quotas | Configure menu
  2.     In the Action options, select Add and enter the details as below :
    Name : Delivery Per User
    Track : Select Sender@domain. This means that policy will be applies to each user on the domain
    Period : The length of time that given in seconds. Ideally is in counts per hour or 3600 seconds
    Link to policy : Select Default
    Verdict : The rules that will be apply if it meets the period, such as defer (hold the messages until next time interval)
    Data : Information that is given if it meets the rule, for example the information is a “Maximum 2 email delivery per minute” or “Maximum 300 emails delivery  per hour”
    Stop processing here : choose Yes, means that rule will not processing another rule
    Comment : can be filled with anything you like
  3.     Click Submit
    by default, the newly created rule set in the disabled state. Set it enable by choose PolicyD that you just created, and then on the Action option, select change
  4.     Change the parameter Disable=’Yes’ to Disable=’No’ on the Disabled option and click submit
  5.     Select the newly created policy again  and then select Limits on the Action option
  6.     Select Add, then select the Message Count and fill in with the number of maximum emails  on Counter Limit
  7.     Click Back to Limits and choose the rule that you have just created. Select Change In the Action option
  8.     Change the parameter ‘Yes’ to ‘No’ on the Disabled option and click submit

Je suppose que 100 e-mails par heure, ça laisse de la marge. A vous de voir selon vos usages.

4 – Surveillance : les logs

Vous l’avez vu en 1 lorsque vous avez cherché le coupable : les logs ont toutes les informations nécessaires pour détecter les mauvais usages. Par exemple :

Oct 30 08:49:20 mail amavis[18001]: (18001-16) FWD from <addresse@yahoo.com> -> <addresse@alice.it>,<addresse@alice.it>,<addresse@gmail.com>,<addresse@hotmail.com>,<addresse@hotmail.it>,<addresse@hotmail.it>,<addresse@libero.it>,<addresse@msn.com>,<addresse@yahoo.com>,<addresse@yahoo.com>,<addresse@yahoo.fr>,BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as E5D0D1A0164

En gras, à moins que vous ne soyez Yahoo (!), on voit bien que quelqu’un à envoyé un e-mail avec votre serveur en se faisant passer pour quelqu’un d’autre. J’ai fait un petit script python pour détecter ce genre de fraude. Renseigner les paramètres en début de script pour déterminer les adresses légitimes qui vous appartiennent (y compris les adresses spéciales de votre domaine, comme celle recueillant les spams par exemple), ainsi que l’adresse pour recevoir le rapport si quelque chose est détecté, configurez ensuite une tâche cron pour une exécution fréquente (genre toutes les 10 minutes), et enfin soupirez de soulagement. Ce n’est pas parfait bien sûr, car les spammeurs peuvent utiliser vos adresses en tant qu’adresses émettrices. Cependant c’est plutôt rare et cela devrait couvrir de nombreux cas.

Félicitations, vous avez fait quelques pas pour vous prémunir d’un prochain bannissement !

Zimbra dans un VPS OpenVZ sous Ubuntu 12.04

Aucun commentaire sur Zimbra dans un VPS OpenVZ sous Ubuntu 12.04

janvier 8, 2014 at 7:10 Categorie :Serveurs | Zimbra

Des perfs, de la virtualisation pour mutualiser des ressources, et ce toujours dans l’optique d’avoir ses propres services libres pour avoir « son » Internet.
Et voilà comment on arrive à combinaison intéressante pour cette problématique : Zimbra placé dans un « container » OpenVZ sous Ubuntu 12.04 (LTS)!

Intuitivement ça devrait être possible, non ?…
Pas si vite ! Minute papillon ! Ce serait trop facile ! Pourquoi ferais-je un billet si ça se passait comme sur des roulettes ? Comme j’ai pu le découvrir, il y a quelques ajustements à faire.

Tout d’abord, des paquets à installer :

sudo apt-get install libgmp3c2 netcat-openbsd sqlite3

Ensuite, le paquet sysstat utilisé par Zimbra bloque l’utilisation sous OpenVZ. En effet le sysstat de l’image Ubuntu officiel pour OpenVZ, retourne des erreurs. Il faut le remplacer par une ancienne version de Debian (ma chère Debian, encore et toujours ma sauveuse).

On commence par forcer la suppression de sysstat et installer la version de Debian :

sudo dpkg -r --force-all sysstat
wget http://ftp.fr.debian.org/debian/pool/main/s/sysstat/sysstat_9.0.6.1-2_amd64.deb 
sudo dpkg -i sysstat_9.0.6.1-2_amd64.deb

Ensuite, il faut holder (pardonnez-moi l’anglicisme) le paquet afin de ne pas se faire écraser la modification à chaque mise à jour :

dpkg --get-selections \* > selections.txt

Editez le fichier sortant selections.txt, pour changer à l’intérieur la ligne qui va bien :

sysstat    install

Pour ce résultat :

sysstat    hold

On sauvegarde le fichier et on le recharge dans dpkg comme ceci :

dpkg --set-selections < selections.txt

Voilà !
Plus d'obstacles à l'installation, vous pouvez maintenant profiter des performances de la virtualisation OpenVZ avec Zimbra.

Utiliser iptables dans un VE OpenVZ

Aucun commentaire sur Utiliser iptables dans un VE OpenVZ

octobre 19, 2013 at 9:18 Categorie :Serveurs

Pour avoir un iptables avec toutes les options au poil qui fonctionne dans des conteneurs OpenVZ, j’ai du faire quelques modifications à l’installation de base. Je te les donne, cadeau, cher lecteur :

Sur la machine hôte :

Il faut charger les modules noyaux suivants :

sudo modprobe ip_conntrack
sudo modprobe ip_conntrack_ftp
sudo modprobe xt_state

Et pour que les modifications soient valables au prochain démarrage, il faut éditer /etc/modules et rajouter :

ip_conntrack
ip_conntrack_ftp
xt_state

Pour que OpenVZ autorise les VE à utiliser les modules iptables qui vont bien, éditer /etc/vz/vz.conf :

## IPv4 iptables kernel modules
IPTABLES=”ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state ipt_conntrack ip_conntrack_ftp iptable_nat ipt_REDIRECT ipt_REJECT”

 

Dans les VE :

Editer /etc/vz/conf/100.conf :

IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state ipt_conntrack ip_conntrack_ftp iptable_nat ipt_REDIRECT ipt_REJECT"

Ma conclusion : OpenVZ, c’est excellent, mais plus je l’utilise plus je me rends compte que ça nécessite pas mal de tunning.

Serveur Subsonic sur Rapsberry PI

Aucun commentaire sur Serveur Subsonic sur Rapsberry PI

février 27, 2013 at 9:33 Categorie :PC Home Cinema | Serveurs

Le Raspberry Pi est un excellent petit engin pour bidouiller. Pas cher, peu consommateur, tout petit, des milliers d’utilisateurs sur le web entier ne cesse de lui trouver des utilités.  En effet, son coût modique permet de l’envisager un peu partout dans votre maison dans des rôles très différents et inattendus. Chez moi, j’ai décidé de m’en servir en tant que serveur audio branché sur ma chaîne. Piloté par les PCs ou des applications mobiles/tablettes, on dispose ainsi d’un jukebox de qualité, ultra modulable, pour une fraction du prix dans le commerce d’une machine dédiée et propriétaire.

Bien sûr, il faut prendre sur soi et faire un de peu de « do it yourself », mais rien d’insurmontable, surtout quand on aime apprendre.

Commençons à zéro en allant télécharger la distribution. J’ai choisi Raspyfi, en lieu et place de l’habituel Raspbian, car j’ai eu des difficultés avec cette dernière. Si vous suivez un peu la communauté Raspberry, vous êtes peut-être déjà tombé sur des fils de discussion interminables parlant des problèmes du Raspberry avec l’USB. En effet, il semblerait qu’ils soit victime de perte de paquets lorsque l’USB est trop chargé. Ce qui est assez pénible, vous l’avouerez, quand c’est une clé wifi qui fait la connexion avec votre réseau, et que vous cherchez depuis 4 heures pourquoi vous venez de subir une énième déconnexion. Raspyfi adresse en partie ce problème, avec un peu de « tunning » : quelques options dans les  modules chargés au démarrage, on fait passer l’USB en 1.1, dans un futur proche un noyau RT sera rajouté et hop, le système est optimisé pour une utilisation sans « jutter » et autres barbarismes que les audiophiles adorent.

L’installation de Raspyfi est un jeu d’enfant, je vous conseille de vous orienter vers le site officiel ainsi que sur celui de Raspbian pour plus de détails.

Ensuite coté logiciel, pour remplir ce rôle nous avons le choix entre plusieurs solutions. Ampache, Subsonic, mpd, tous permettent de gérer une bibliothèque de sons et de contrôler la lecture à distance. Quelques points :

  • Ampache se fait vieux, les applications mobiles qui vont bien ne sont pas très belles ou n’ont pas bonne réputation
  • J’avais besoin d’un jukebox faisant aussi office de serveur de streaming, et que l’application mobile soit capable de gérer les deux modes. mpd et ses applis dérivées ne gèrent pas ça nativement. Dommage, mpd est installé de base avec Raspyfi.
  • Subsonic adresse ces deux précédents points. Cependant, à sa décharge il n’est pas tout à fait gratuit. En effet, pour utiliser les applications mobiles au delà d’un mois d’essai, il faut « acheter » une « licence de soutien » (prix libre). Le surcoût d’une « licence » de soutien ne me gênant pas particulièrement (je suis bien plus attaché au concept de liberté de l’open source qu’à la gratuité qui est souvent poussé en tant que premier argument), j’ai donc choisi Subsonic. Au passage, si vraiment vous êtes allergiques au « soutien », il est tout à fait facile de trouver un patch désactivant les limitations, ou même d’utiliser Supersonic, un fork créé à cette occasion. Et l’application mobile Androïd sans publicité est disponible sur le site des développeurs sous forme d’un apk.

Subsonic étant en java, on commence par installer un JRE. De préférence open source, on ne se refait pas. Ne faites pas les malins (comme moi qui a perdu deux heures…) et n’installez pas la version headless en pensant économiser des ressources : les librairies pulseaudio sont dans la version desktop… On installe au passage ffmpeg parce qu’on en aura besoin après :

sudo apt-get install openjdk-7-jre ffmpeg

Ensuite, on récupère et installe le paquet sur le site officiel (vérifiez si de nouvelles versions ne sont pas disponibles au lieu de recopier mon lien, petits fainéants) :

wget http://downloads.sourceforge.net/project/subsonic/subsonic/4.7/subsonic-4.7.deb

dpkg -i *.deb

Ensuite, on édite le fichier de conf de subsonic (/etc/default/subsonic) pour le faire démarrer avec un utilisateur autre que root. Ici on prend l’utilisateur mpd, puisque ça nous évite d’avoir à en configurer un nouveau (l’ajouter, le mettre dans le bon groupe, etc) :

SUBSONIC_USER=mpd

Si vous utilisez le chip audio du Raspberry plutôt qu’un dongle audio USB avec sortie optique, alors il faut réactiver le module. Je ne sais pas pourquoi, éditer le fichier /etc/modules pour rajouter la ligne « snd_bcm2835 » n’a pas marché chez moi. Si vous avez une idée, faites le moi savoir dans les commentaires. En attendant un coup de génie, rajoutez une ligne dans /etc/rc.local juste avant le exit 0 :

modprobe snd_bcm2835

Configurer votre sortie audio par défaut (dans mon cas ‘1’ pour le jack):

sudo amixer cset numid=3 1

Vous utilisez une clé wifi ? Avec WPA-2 parce que vous n’êtes pas un insouciant ? Au plus simple, éditez /etc/network/interfaces :

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid "MonSSID"
wpa-psk "masuperpassphrase"
iface default inet dhcp

Dans mon cas, j’utilise le DHCP avec des baux statiques pour mes IPs, si ce n’est pas votre cas vous devrez utiliser une configuration statique. Vous vous attendiez à ce que je vous mâche le travail en vous donnant les bonnes directives ? Décidément vous êtes vraiment fainéants aujourd’hui ! Cherchez vous-même sur le net !

Ensuite : stockez-vous vos fichiers de musique sur le réseau ? Faites un montage depuis /etc/fstab. Pour ma part, j’ai utilisé ma freebox en tant que stockage et partage Samba : tout simplement parce que je suis certain que celle-ci est toujours allumée. Voilà la ligne qui va bien chez moi (remplacez l’IP par celle qui va bien chez vous)

//192.168.0.254/Disque\040dur\Musiques /media/music cifs username=anonymous,password=,uid=mpd,file_mode=0644,dir_mode=0755,iocharset=utf8,rsize=130048,wsize=4096,_netdev,sec=ntlmv2 0 0

Tiens, on apprend au passage qu’on utilise le caractère spécial \040 pour faire un espace dans un point de montage, ou encore qu’il faut utiliser _netdev pour que le système comprenne qu’il faut que le réseau soit initié complètement avant de faire les montages. On dit merci qui ?

Pour que le mode jukebox fonctionne, il faut préciser à Subsonic quelle sortie audio utiliser. Éditer le fichier ‘/usr/bin/subsonic’ et rajouter le paramètre suivant dans la liste des paramètres de lancement java (qui représente le jack chez moi) :

'-Djavax.sound.sampled.SourceDataLine=#ALSA [plughw:0,0]' \

Allez on a presque fini. La version de ffmpeg livrée avec subsonic n’est pas adaptée à l’architecture ARM du Raspberry, il faut donc la remplacer :

sudo rm /var/subsonic/transcode/ffmpeg
sudo cp /usr/bin/ffmpeg /var/subsonic/transcode

Redémarrez Subsonic (/etc/init.d/subsonic restart), et ensuite rendez-vous sur http://<ip_du_raspberry>:4040. Subsonic est très long à se lancer sur le petit Raspberry, donc pas de panique si il ne se passe rien les premières minutes. De plus les pages jsp sont très très longues à charger les premières fois, rassurez vous là aussi, après c’est tout à fait fluide.
Je ne vais pas décrire en détail la configuration de Subsonic, c’est assez simple et vous trouverez plein de tutos sur internet. Par contre, pour vous évitez de chercher inutilement, voilà quelques points pas évidents pour utiliser Subsonic en mode Jukebox (car par défaut il stream vers votre navigateur) :

  • Configurez un « lecteur » (Paramètres –> lecteur) de type « Jukebox »
  • Configurez un utilisateur en lui donnant les droits d’utiliser le « jukebox » (Paramètres –> Utilisateurs)
  • Pour le contrôle en jukebox depuis l’application mobile/tablette, il faut utiliser le bouton « RC » accessible depuis le player (en bas à gauche).

Voilà !

Tunnel SSH, et rien d’autre

Un commentaire sur Tunnel SSH, et rien d’autre

juin 16, 2011 at 9:33 Categorie :Serveurs

SSH est un outil très polyvalent. Dans certains cas, presque trop !
Oui je sais je suis provocateur. Je vous explique : il y a peu, j’ai voulu fournir une connexion « tunnelisée » à un collègue pour raisons professionnelles. Pour ça, comme vous le savez peut être, SSH et sa fonction de tunneling est idéal.
Je ne vais pas expliquer comment faire du SSH tunneling, Internet est déjà rempli d’articles à ce sujet.
Mon problème à moi, était de fournir cette fonction de tunnel, et absolument rien d’autre.
En effet, on a tendance à l’oublier, mais ouvrir un compte et donner un accès SSH c’est, par défaut, donner énormément de droits. Lecture sur la plupart des répertoires de la machine et exécution de scripts, en sont deux parmi les plus dangereux. Quand la machine est prévue à l’origine en tant que serveur familial et qu’on décide de faire confiance à tous ceux qui y ont accès, le prêt d’une partie de cette machine à un extérieur prend des allures de jeu dangereux et oblige à revoir en profondeur la gestion des comptes.

En mode fainéant, au plus simple, j’ai cherché à atteindre mon but de limitation drastique des droits. Plusieurs étapes sont nécessaires :

– Création d’un compte

sudo adduser invite

Pour ma part, j’ai mis un mot de passe super compliqué que je me suis empressé d’oublier. Je préfère en effet la gestion par clef privé/publique, qui permet une bien meilleure granularité.

– Connexion avec le nouvel utilisateur, puis création d’une clef et copie de sa partie publique dans le magasin des clefs de confiance

sudo su - invite
ssh-keygen
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

La clef privée qui a été générée (id_rsa sans extension) au coté de la clef publique sera celle qu’il faudra fournir à votre invité pour qu’il se connecte.

– Création d’un script très limité faisant office de shell. Par défaut, une connexion SSH exécute un shell (celui défini dans le fichier /etc/passwd pour l’utilisateur), et c’est ce shell qui est chargé de communiquer grâce à ses entrées/sorties standard avec l’utilisateur distant. Un shell standard (bash, sh) permet beaucoup trop de chose. Un shell limité à sa plus simple expression est ce qu’il nous faut. Et si on le codait nous même? En voilà le contenu :

#!/bin/sh
/bin/echo "Bienvenue.
Acces invite restreint, pas de shell !
q pour quitter"
read ans
while [ "$ans" != "q" ]
do
/bin/echo "q (pour quitter) est la seule touche valide"
read ans
done
exit 0

Que fait-il ? Rien, à part attendre la frappe de la lettre « q » qui mettra fin à la connexion. Difficile de faire plus simple.
Placer ce fichier dans un coin de votre disque, en n’oubliant pas de le rendre exécutable à coup de chmod +x

– Arrivé ici, je connais bon nombre de linuxiens qui s’empresserait d’aller coller le chemin du script dans la ligne de /etc/passwd correspondant à l’utilisateur invité. Grave erreur. Si en effet, l’utilisateur se retrouverait alors par défaut connecté à notre nouveau « shell », ceci ne serait que par défaut. Une simple option de la ligne de commande du SSH client permet de choisir le shell de son choix. La solution est d’utiliser les restrictions permises par l’utilisation d’une authentification par clef privée. C’est tout simple, il suffit de rajouter juste avant la clef dans authorized_keys un paramètre forçant la commande exécutée à la connexion de l’utilisateur. Ce qui nous donne par exemple :

command="/home/invite/login.sh" ssh-rsa AAAAB3NT[...]B68w== invite@spammeur.net

– Que nous reste-il à faire? Arrivé ici, l’utilisateur ne peut plus se connecter autrement qu’avec notre shell bidon, mais peut tout à fait exécuter des tunnels, comme nous le souhaitons. Cependant, SSH est vicieux et fourni encore d’autres services. Je pense en particulier au SFTP. Avec un accès SFTP, l’invité est capable d’aller modifier le fichier authorized_keys de son compte pour retirer la restriction de scripts… Réduisant à néant nos efforts pour le limiter ! On pourrait protéger ce fichier par root, et coupler ensuite la protection avec un chrootage « des familles » pour empêcher de surcroît l’indiscret de fouiller le disque, mais faisons au plus simple.
On édite /etc/ssh/sshd_config et on commente comme ceci la ligne suivante :

#Subsystem sftp /usr/lib/openssh/sftp-server

NB : pour une raison inconnue, chez moi commenter cette ligne n’a pas suffit. Qu’à cela ne tienne, aux grands maux les grands remèdes :

sudo mv /usr/lib/openssh/sftp-server /usr/lib/openssh/sftp-serverNO

– On n’oublie pas de recharger sshd avec les nouveaux paramètres :
/etc/init.d/sshd reload

– Dernière chose pour les petits distraits : n’oubliez pas de configurer votre serveur FTP pour empêcher l’accès de l’utilisateur « invite ». De même avec tous les services que vous possédez et qui peuvent se baser sur l’authentification système.

Pfioui, la sécurité, ça n’est pas une mince affaire.

Gestion multi-serveur de Mumble par dbus

Aucun commentaire sur Gestion multi-serveur de Mumble par dbus

septembre 18, 2010 at 7:14 Categorie :Logiciels | Serveurs

Mumble est un excellent serveur vocal open-source, qui se veut le concurrent direct de projets commerciaux comme TeamSpeak ou Ventrilo. Il a pour énorme avantage sa faible latence et son excellente qualité audio.

Comme tout serveur de ce genre, il a été créé dans l’optique d’héberger plusieurs instances sur une seule et même machine. Bien entendu comme dans tous les cas de multi serveurs, la configuration automatique est rarement suffisante. Ce point est rarement couvert par les tutoriels trouvables sur Internet, pour la simple raison que ces pas à pas s’adressent principalement à des utilisateurs aux besoins simples. Voici donc un petit bloc note rapide sur sa configuration.

Mumble est pilotable par dbus. Bien que vieillissant et destiné à être remplacé par Ice, je continue à utiliser ce protocole car l’environnement Ice est parfois plus difficile à mettre à place. Avant toute chose, il faut activer dbus dans le fichier de configuration. Je vous laisse positionner le paramètre « dbus » à la valeur « system » dans le fichier (usuellement /etc/mumble/mumble-server.ini). Attention, par l’activation de cette interface de cette manière, toute personne ayant accès à un shell de votre machine devient de facto capable de gérer mumble avec les droits administrateurs.

Je vous présente ensuite ici quelques commandes, qui sont je crois nécessaires et suffisantes à la compréhension de la configuration de son serveur. Avec elles, vous aurez un panorama de ce qu’il est possible de faire :

Lister les méthodes possibles :

dbus-send --system --dest=net.sourceforge.mumble.murmur --type=method_call
     --print-reply / org.freedesktop.DBus.Introspectable.Introspect

Récupérer la configuration du serveur par défaut :

dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur
     --type=method_call / net.sourceforge.mumble.Meta.getDefaultConf

Paramètrer le mot de passe du serveur par défaut :

qdbus --system net.sourceforge.mumble.murmur / net.sourceforge.mumble.Meta.setSuperUserPassword
     1 supahsecret

Paramètrer le mot de passe du deuxième serveur :

dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /
    net.sourceforge.mumble.Meta.setConf int32:2 string:password string:"supersecret2"

Récupérer la configuration du serveur 1 :

dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /
    net.sourceforge.mumble.Meta.getAllConf int32:1

Ces commandes ne sont pas exhaustives, mais suffisent à comprendre comment marche l’interaction entre Mumble et dbus. Pour le reste, débrouillez-vous !

à la configuration de son

Apache, SSL et hôtes virtuels

Aucun commentaire sur Apache, SSL et hôtes virtuels

septembre 8, 2010 at 11:18 Categorie :Serveurs

J’ai fréquemment lu sur Internet qu’utiliser les hôtes virtuels, en partageant le même couple IP/port par Apache sur SSL était impossible.

La raison avancée est simple : les hôtes virtuels utilisent un champ de l’entête de la requête HTTP pour déterminer quel est le site concerné par la demande. Le problème qui gêne le bon fonctionnement des hôtes virtuels, est que cette entête est chiffrée puisque l’envoi des entêtes intervient après la présentation des certificats. Donc impossible d’identifier le site avant d’avoir envoyé les certificats, alors que cet envoi de certificats requiert d’avoir choisi le site. La boucle est bouclée, les débutants arrêtent de chercher sur les forums, et les achats d’IP supplémentaires augmentent chez les loueurs de serveurs dédiés.

C’était à moitié vrai, c’est complètement faux maintenant. C’est le problème d’Internet : on revient rarement en arrière corriger un vieux message sur les forums. Et les moteurs de recherche étant ce qu’ils sont, de vieilles pages plus du tout actuelles peuvent très bien remonter en haut des recherches.  Mais je diverge.

Donc malgré ce que vous pouvez lire, Apache est maintenant tout à fait capable de gérer les hotes virtuels en SSL.
Comment ? Au choix :
1- Apache (du moins en version 2.3 ou dans la branche 2.2 depuis 2.2.12 grâce à un backport) supporte les extensions SNI, qui permettent au navigateur de présenter le nom de domaine avant d’établir la connexion chiffrée. L’usage de cette extension requiert un navigateur compatible, ce qui inclut tous les navigateurs récents mais exclut le diabolique IE6 (encore et toujours lui). C’est une solution idéale si vous êtes prêts à passer outre ce vieux navigateur qui n’a que trop servi.
2- En utilisant le plus récent TLS, au lieu de SSL, avec le problème étendu de support par les navigateurs. Au passage, c’est la solution d’avenir, mais il vaut mieux l’oublier en attendant qu’il soit plus répandu.
3- Avec une solution plus vieille, qui a ses limitations, mais qui a fait ses preuves dans certains cas particuliers : un seul et même certificat pour tous les sites. On comprend vite qu’avec cette méthode, le problème énoncé en début d’article n’en est plus un. Alors que de base -pour une sécurité accrue- les certificats SSL sont signés à destination d’un seul et unique nom de domaine, il existe donc des variantes permettant les domaines multiples. Vous avez au choix les coûteux certificats wildcard ou l’utilisation de l’extenstion altName. Je vais encore réduire le spectre des solutions et choisir de parler ici du « altName », qui nous autorise à déterminer des noms alternatifs pour notre serveur. Je n’ai pas trouvé directement d’aides  sur Internet couvrant ce sujet du début à la fin avec des commandes simples qui se suffisent à elles-mêmes. D’où ceci :

Un rapide pas-à-pas détaillé

Placez vous dans un répertoire de travail (que je vous laisse créer). On commence par une génération de clés 1024 bits si vous n’en avez pas déjà une :

openssl genrsa -out server.key 1024

On copie ensuite le fichier de configuration d’openssl :

cp /etc/ssl/openssl.cnf .

On édite ce fichier. Dans la section [req] on ajoute (ou décommente) :

[req]
req_extensions = v3_req

Dans la section [v3_req], on ajoute alors la liste des domaines alternatifs sous cette forme :

subjectAltName= DNS:domaine1.org, DNS:autrealternative.domaine1.org, DNS:encoreunautre.com

Maintenant on génère une requête de signature. Si vous êtes riche, vous pouvez utiliser le fichier .csr ainsi généré pour faire certifier votre domaine auprès d’un organisme de confiance comme Thawte ou Verisign. Cela évitera les messages d’avertissement des navigateurs se connectant à votre site sécurisé. Voici la commande pour créer cette requête de signature :

openssl req -new -out server.csr -key server.key -config openssl.cnf

Au lieu d’envoyer votre demande chez les américains, si vous êtes près de vos sous et/ou dans un cadre amateur, ne vous gênez pas pour auto-signer votre certificat :

openssl x509 -req -in server.csr -out server.crt -signkey server.key -extfile openssl.cnf -extensions v3_req

Voilà, vous avez ainsi dans votre répertoire de travail deux fichiers (la clé et le certificat) qui sont suffisants pour faire tourner votre Apache en mode sécurisé !
N’oubliez pas d’activer mod_ssl dans Apache et d’ajouter dans votre configuration d’hôtes virtuels HTTPS les lignes suivantes :

SSLEngine on
SSLCertificateFile <chemin>/server.crt
SSLCertificateKeyFile <chemin>/server.key

Avant de partir, prenez connaissances des limitations de cette solution :  d’une part cette extension n’est pas reconnue par certains très vieux navigateurs (mais, puisque même l’horrible IE6 le fait, on va arrêter les chipotages et remettre au placard Netscape…), et d’autre part tous vos sites alternatifs sont présents dans le certificat en clair, ce qui veut dire que n’importe qui établissant la connexion SSL, peut savoir que ces sites existent sur votre machine.