Gnu/Linux
#Gnu/Linux, Planet Libre, pfsense
IP FAILOVER MULTIPLES - DEDIBOX - PFSENSE - ESXi
Depuis quelques années j'utilise une Dédibox pour héberger mes machines virtuelles sous VMWare ESXi6.5
J'ai deux types de VM
- Des VM portant directement une IP Failover Online
- Des VM portant une IP dans un réseau Privé derrière un Firewall PFSense ( aussi une VM)
Cela est assez pratiques, les VM portant des IP Failover sont des serveurs accessibles en direct
sur Internet portant des services Open.
L'avantage est que je peux porter des multiples services Web sur les port 80 et 443 sans faire du NAT
Sauf que le problème est que ces VM sont très peu protégées ( seulement le pare feu Linux)
A contrario des VM derrière le PFSense qui bénéficie de toutes les protections.
Actuellement
J'ai donc étudié la possibilité de pouvoir passer toutes mes VM derrière le PFSENSE
Cela permettra d'avoir un filtrage Fin et de bénéficier de tous les services PFSENSE ( IPS par exemple)
Pour Cela plusieurs prérequis qui'il a fallut lever:
- Comment porter plusieurs IP Failover sur une seule interface de mon PFSENSE???
- Comment porter 1 seul adresse MAC avec plusieurs IP Failover
- Comment paramétrer PFSENSE pour assigner des IP Failover à certaines VM et pas d'autres.
La Cible
Modifier l'adresse MAC de votre IP Failover pour utiliser une MAC Partagée qui sera porté par une VM
- Eteindre votre VM
- Se connecter sur l'interface Online
- Editer votre mac adress actuelle
- Supprimer votre Mac address
- Une fois suprimée et mise à jour
- Editer la mac et choisissez "Utiliser une Adresse Mac Existante
- Chosir la mac adresse qui porte déjà la patte WAN de votre VM PFSENSE
A partir de là tous paquet à destination de votre IP Failover sera dirigé vers l'adresse MAC partagée portée par votre VM PFSENSE.
Sur PFSENSE:
- Ajouter une IP Virtuelle de type IP Alias ( Votre IP Faiolver que vous voulez migrer) en /32
sur le WAN
- On voit ici 2 IP failover portées par mon pfsense ( en plus de l'ip failover assignée à l'interface WAN)
Occupons nous du NAT :
- Notre VM ne portera plus directement l'IP Failover mais une ip Privée dans le réseau LAN PRIV ( 192.168.100.0/24)
- Nous allons choisir l'adresse IP 192.168.100.130
NAT ENTRANT
Pour cela nous allons dire à PFSENSE que tout ce qui arrive à destination de l'IP Failover sera redirigé vers 192.168.100.130
- Dans Firewall / NAT / 1:1
NAT SORTANT
Pour cela nous allons dire à PFSENSE que tout ce qui sort depuis 192.168.100.130 est natté avec l'IP Failover
- Dans Firewall / NAT / Outbound
Ici on voit que 192.168.100.130 et 192.168.100.110 sortiront avec 2 ip failover différentes
Le reste sortira avec l'adresse WAN par défaut ( qui est aussi une failover)
Le Filtrage
Pour commencer faire une règle de filtrage Simple qui ouvre tout sur l'IP privée de la VM
Sur la Machine Virtuelle qui portait auparavant l'ip Failover
- Sur votre VM qui portait auparavant votre IP Failover.
- Modifier son paramétrage pour etre dans le réseau Privé et ne plus utiliser le Vswitch public
- Redemarrer la VM
- Modifier ces paramètres IP pour ne plus porter l'IP failover mais une IP Privée 192.168.100.130
- Avant
- Après
-Redémarrer la VM
- Après le reboot tout ping aussi bien l'adresse Pivée que Publique ( failover)
- On peut même tester le NAT Unbound
Exemple d'un wget sur un serveur apache externe, on voit bien notre ip publique failover s'afficher dans les logs
Voilà , il vous reste à affiner vos règle de filtrages ( souvenez vous nous avions tout ouvert !! )
N'ouvrez que le necessaire. ( pour ma part par exemple SSH et HTTP)
Je vous conseille d'utiliser les ALIAS qui permettent de relier un objet à une adresse IP
Pratique, pas besoin de se rappeler des IP
#Gnu/Linux, Planet Libre, nas linux qnap openmediavault
Mise en place des Snapshots avec BTRFS et Open Media Vault
Ce NAS contient tous mes documents non structurés.
J'ai bien sur de la backup quotidienne via le formidable outil Urbackup
Même si Urbackup est souple, j'ai eut besoin de pouvoir avoir une souplesse et une granularité de restauration plus souple.
Ayant la plupart du temps un poste client sous Windows, j'ai eu envie de pouvoir utiliser la notion de "versions précedentes."
C'est assez simple à mettre en oeuvre quand on à un serveur de fichier sous Windows.
Mais avec un serveur de fichier Gnu/Linux OMV comment faire ???
En glanant les informations sur le net, j'ai vu que c'était possible via les fonctionnalités
du système de fichiers BTRFS !!!
J'ai donc décidé de mettre en place cela sur un disque de mon NAS et de rendre
cela un peu automatisé.
Plusieurs étapes:
Formatage du disque : File Systeme BTRFS ( prononcé butterFS)Le disque en question est /dev/sdc
Le formater en BTRFS et le monter
A partir de là vous avez un FS en BTRFS
La particularité de BTRFS est qu'il permet de vréer des subvolumes
Ces subvolumes, sans être des disques blocs à proprement parlés
Pourront être utitilisé par l'OS commes des disques.
avec la commande mount, vous pouvez voir sous quel nom
est monté votre FS
Pou rmoi par exemple:
#mount
/dev/sdc1 on /srv/dev-disk-by-label-NASLV1 type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/Création du subvolume:
Création du partage SMB utilisant ce subvolume dans OMV:btrfs subvolume create/srv/dev-disk-by-label-NASLV1/@NASLV1lister les subvolume:
root@nas:/srv/dev-disk-by-id-scsi-1ATA_ST1000DM003-1CH162_S1DE8V17-part1/NASLV2# btrfs subvolume list /srv/dev-disk-by-label-NASLV1/
ID 257 gen 1071 top level 5 path @NASLV1
Vous voyez que votre subvolume @NASLV1 peut etre selectionné directement comme un disque !!
Création du subvolume de snapshot:
De la même nanière on crée un subvolume pour les futurs snapshots.
btrfs subvolume create/srv/dev-disk-by-label-NASLV1/@NASLV1/.snapshots
#/srv/dev-disk-by-id-scsi-1ATA_ST1000DM003-1CH162_S1DE8V17-part1/NASLV2# btrfs subvolume list /srv/dev-disk-by-label-NASLV1/
ID 257 gen 1071 top level 5 path @NASLV1
ID 258 gen 1053 top level 257 path @NASLV1/.snapshots
Modification des options de partages pour que les snapshots soient visibles dans Windows:
Dans "options supplémentaires" du partage omv
Ajouter :
vfs objects = shadow_copy2
shadow:format = @GMT_%Y.%m.%d-%H.%M.%S
shadow:sort = desc
shadow:snapdir = .snapshots
Cela va permettre à Windows de peupler "versions précédentes"
Création d'un snapshot de test:
# btrfs subvolume snapshot /srv/dev-disk-by-label-NASLV1/@NASLV1 /srv/dev-disk-by-label-NASLV1/@NASLV1/.snapshots/@GMT_`date +%Y.%m.%d-%H.%M.%S`
Ce qui donne en retour
Create a snapshot of '/srv/dev-disk-by-label-NASLV1/@NASLV1' in '/srv/dev-disk-by-label-NASLV1/@NASLV1/.snapshots/@GMT_2018.11.13-23.32.28
Montons le partage sous Windows et vérifions l'onglet "versions précedentes."
Nos snapshots sont apparus
si on montre les fichiers cachés on voit aussi notre .snapshots
Programmons les snapshots et la rétention de nos snapshots.
Je n'ai rien trouvé d'automatisé pour créer les snapshots régulièrement et les purger.
J'ai donc créer quelques scripts pour automatiser cela:
take-btrfs-snap.sh
#!/bin/bash
pathsubvol="/srv/dev-disk-by-label-NASLV1/@NASLV1"
pathsnap="$pathsubvol/.snapshots"
snapname="@GMT_`date +%Y.%m.%d-%H.%M.%S`"
btrfs subvolume snapshot $pathsubvol $pathsnap/$snapname
purge-btrfs-snap.sh ( supprime les snapsshots de + de 7 jours)
#!/bin/bash
#Max Age of snapshots in days
agesnapday="7"
#Path snapshots
pathsnap="/srv/dev-disk-by-label-NASLV1/@NASLV1"
#Delete old snapshot
find $pathsnap -mindepth 1 -maxdepth 10 -mtime +$agesnapday -name "@GMT_*" -exec btrfs subvolume delete {} \;
list-btrfs-vol.sh
#!/bin/bash
pathsubvol="/srv/dev-disk-by-label-NASLV1/@NASLV1"
#pathsnap="$pathsubvol/.snapshots"
#snapname="@GMT_`date +%Y.%m.%d-%H.%M.%S`"
btrfs subvolume list $pathsubvol
usage-btrfs-snap.sh ( basé sur btrfs-du qu'il faudra installer)
#!/bin/bash
pathsubvol="/srv/dev-disk-by-label-NASLV1/@NASLV1"
btrfs-du $pathsubvol
Attention pour utiliser btrfs-du il faut activer les quotas sur votre subvolume
btrfs quota enable /srv/dev-disk-by-label-NASLV1/@NASLV1/
Il suffit d'ajouter ces commandes en tant que Tache planifiés sur OMV
J'ai décidé de faire 2 snapshots par jours à 00h00 et 12h00
Et tous les jours purger les snapshots de + de 7 jours
Vous pouvez maintenant avoir accès à des versions antérieurs de vos dossiers/fichiers
Et les copier/coller simplement
Edit 26-11-2018
Je me suis rendu compte au bout de 7 jours que mon script de purge effacait tous les snapshots.
La raison est simple : Les snapshots garde tous la date de leur dossier parent !!!!
Il faut le savoir
On ne peut donc pas se baser sur le find mtime pour effacer les snapshots.
J'ai donc revu ma façon de fonctionner:
- Ajout du temps unix en seconde dans le nom de mes snapshots
- Adaptation du script pour se baser sur un calcul du temps unix
- Adaption des options de partages smb
Les nouveaux scripts :
take-btrfs-snap.sh
#!/bin/bash
pathsubvol="/srv/dev-disk-by-label-NASLV1/@NASLV1"
pathsnap="$pathsubvol/.snapshots"
snapname="@GMT_`date +%Y.%m.%d-%H.%M.%S-%s`"
urge-btrfs-snap.sh ( supprime les snapsshots de + de 7 jours)
#!/bin/bash
#Max Age of snapshots in days
agesnapday="7"
agesnapsec=$(($agesnapday * 86400))
date=$(date +%s)
agesnaplimit=$(($date - $agesnapsec))
logfile=/var/log/snap.log
echo > $logfile
snaplistfile=/tmp/snaplist.txt
#Path snapshots
pathsnap="/srv/dev-disk-by-label-NASLV1/@NASLV1"
ls $pathsnap/.snapshots/ | grep GMT > $snaplistfile
listnap=$(cat $snaplistfile)
#echo $listnap
for i in $listnap
do
agesnap=$(echo $i | awk -F"-" '{print $3}')
if (("$agesnap" < "$agesnaplimit"))
then
echo "snapshot $i superieur a $agesnapday Jour" >> $logfile
echo "supression de $i" >> $logfile
btrfs subvolume delete $pathsnap/.snapshots/$i
else
echo "snapshot $i inferieur a $agesnapday Jour" >> $logfile
echo "pas de supression de $i" >> $logfile
fi
done
Adptation du share smb dans OMV pour prendre en compte le changement de nom
vfs objects = shadow_copy2
shadow:format = @GMT_%Y.%m.%d-%H.%M.%S-%s
shadow:sort = desc
shadow:snapdir = .snapshots
#Gnu/Linux, Planet Libre, jeedom, pfsense
Sécuriser les équipements IOT en Wifi
J'utilise Jeedom comme solution domotique, j'ai plus de 50 objets connectés.
Les équipements IOT sont en général moins bien sécurisés que les autres équipements connectés.
La sécurité par design n'est pas encore dans l'esprit des constructeurs ( pas tous )
Il n'est pas rare de voir des équipements dialoger au niveau réseau avec des serveurs américains ou chinois.
Les informations qu'ils envois ne sont pas controllées.
Il n'est pas rare non plus que les équipements connectés soient utilisés dans des attaques de Botnet
J'ai donc cherché un moyen d'isoler mes équipements Wifi à risque du reste de mon réseau.
Il n'y a guère d'autre solution que de créer des DMZ afin de les isoler.
Les équipements à ma dispositon:
- 1 routeur PFSENSE ( Carte APU 2C4)
- 1 Switch NetGear GS108
- 1 Switch Unifi S8
- 1 AP WIFI Unifi AC PRO
Voiçi le réseau cible : ( simplifié, car j'ai beaucoup d'autre équipements)
La cible à atteindre est de créer 2 réseaux WIFI
Pour cela pas de secret , il va falloir creer des VLANs et des DMZ
- WIFI-MAISON ( Réseau LAN DATA - Full Access)
- WIFI-IOT ( Réseau DMZ-INTERNER - Accès filtré)
Pour cela j'ai dut revoir tout mon réseau, car de base en général un réseau domestique n'utilise pas la notion de VLAN.
Un suel VLAN ( le 1 en général est utilisé de facon transparente)
Pour mon usage, j'ai décidé de ne plus utiliser le VLAN 1
Le VLAN 10 sera mon réseau LAN DATA
Le VLAN 200 ma DMZ- Interne
Je ne parlerai pas ici de la DMZ Publique que j'ai créer sur une interface dédiée de mon pfsense.
Le plan d'action est donc le suivant:
- Création de 2 VLAN ( et des interfaces associées)
- Création des IP des interface ( 10.0.0.254/24 pour le LAN / 172.20.0./24 pour la dmz)
- Création d'étendue DHCP
- Tagg de ces 2 VLAN Depuis PFsense --> Switch Netgear --> Switch Unifi --> AP Unifi
- Paramétrage du Wifi Unifi pour diffuser des SSID sur des VLAN diffrérents
Coté PFSense
Création de 2 VLAN ( et des interfaces associées)Je ne vais pas détailler toutes les actions mais les principales.
La ce qui est important à savoir
C'est que l'interface associée a vos VLAN ne doit porter aucune autre interface logique.
Sinon vous serez obliger de transmporter sur cette interface du vlan untag et du tagged, de qui n'est pas une bonne chose.
La bonne pratique est qu'un port d'interconnexion ne doit transporter que du VLAN Tagged
Par défaut pfsense associe l'interface logique WAN à votre interface physique sur le VLAN1 en untag.
Autrement dit coté pfsense il faut supprimer votre interface logique LAN et la remplacer par un VLAN ( ici le 10)
Vous ne devez avoir que des VLAN sur votre interfaces
Rien ne vou sempeche de la rappeler LAN comme moi
En ayant que des VLAN sur votre interfaces Pfsense, impicitement Pfsense va tagger les 2 VLANs
en sortie de l'interface.
Mettre une IP Statique sur l'interface qui correspondra a votre plan d'adressage
Pour le LAN
Pour la DMZ Interne
Pensez bien à mettre un /24 car sinon la partie DHCP ne sera pas accessible sous Pfsense.
Création des étendues DHCP.
Création d'une règle de Firewall temporaire.
Pour les tests créer une regle de firewall autorisant tout sur la DMZ.
Cela permettra de tester.
Vous fermerez tout plus tard.
Attention à partir de là quand vous validez : Vous perdez l'accès à votre pfsense depuis votre réseau local;
Normal les vlan arrive taggé vers le netgear, mais le netgear n'est pas encore a meme de les recevoir.
Je vous conseille de garder un accès WAN à votre pfsense ( a travers une partage 4g par exemple)
Cela vous permettre de toujours pouvoir agir sur le pfsense même si vous n'y avez plus accès à partir du LAN
Coté Switch Netgear GS108
Le port d'interco relié entre mon PFSENSE et mon netgear sera le 1
Sur le Switch Netgear --> Le port d'interco relié entre mon Sw netgear et mon Switch Unifi sera le 3
Création des VLAN sur le netgear
On voit bien le 10 et le 200
On Tag les ports qui nous interesse
On voit ici que j'ai taggé le VLAN 10 sur les ports 1 et 3
On voit ici que j'ai untag le VLAN 10 sur les autres ports ( port ou seront branché des equipements dans le VLAN 10 - LAN classique)
On voit ici que j'ai taggé le VLAN 200 sur les ports 1 et 3
Rien sur les autres concernant le 200
Il faut aussi mettre les PVID sur les ports
Le Pvid n'a pas d'importance sur les port taggé 1 et 3
Les autres ont le PVID 10
Comme je vous l'ai dit j'ai décidé de remplacer le VLAN 1 historique
Par le VLAN 10
je vais donc mettre ce VLAN 10 comme VLAN de management du switchs
Voila le Netgear est paramétré
Attention vous risquez aussi de vous couper la patte sur le switch
Garder provisoirement un port dans le VLAN1 avant de changer le Management VLAN ID
Coté SwitchUnifi S8
La j'ai pas mal galéré , car autant l'interface Netgear me paraissait logique et old scholl.Très proche des switchs que je manipule souvent ( avaya, cisco)
Autant le paramétrage du switch unifi par le controleur est nouveau.
Il vous faut donc un controlleur Unifi installé ( a minima pour le paramétrage)
Je ne décrit pas la découverte du switch et son provisionning qui est autimatique dans Unifi.
Même si le switch fonctionne en DHCP
Je vous conseille de le mettre en IP Fixe.
Cela évite de se couper la patte quand on taggera.
La partie VLAN se trouve dans Settings / Networks
Quand les Vlan sont crées, il faut les associer à des profiles:
Un profile VLAN-DATA ( Associé au VLAN10)
Cela signifie en langage Switch UNTAG le VLAN 10
Un Profile VLAN-DMZ-INTERNE ( Associé au VLAN 200)
Cela signifie en langage Switch UNTAG le VLAN 200
Et un Profile Interco ( Regroupant les 2 VLAN 10 et 200) Mais cette fois en TAGGED
Cela signifie en langage Switch TAGGED VLAN 10 et 200
Sur le Switch Unifi --> Le port d'interco relié entre mon Sw netgear et mon Switch Unifi sera le 1
Je vous rappelle que le port 3 du Netgear est relié au port 1 de UNIFI
Donc le port 1 de Unifi doit etre taggé des VLAN 10 et 200
Cela se passe sur le port 1 du switch:
Et voilà votre port 1 utilise le profil Interco en taggant les VLAN 10 et 200
Comme le netgear j'ai décidé de mettre le VLAN Management du switch Unifi en VLAN10 ( Profile VLAN-DATA)
Voilà coté Tagging et réseau on est bon.
Attention j'ai du réinitialiser plusieurs fois le switch avant de trouver tout ces paramètres.
Je me suis coupé la patte plus d'une fois.
Soyez vigilant et poser votre schéma sur papier et mesurer les impacts de chaque manipulations.
Coté WIFI Unifi AC PRO
Si vou savez eut le courage de suivre, nous avons réussi à tagged les VLAN 10 et 200
Depuis le pfsense , en passant par le Switch Netgear, jusqu'au Switch Unifi
Tout est prêt pour pouvoir diffuser des Réseaux Wifi portant différent VLAN.
Création du WIFI-MAISON
Tout se passe dans Settings / Wireless Networks
Création d'un SSID nommé WIFI-MAISON
Utilisant le VLAN10
Je vous conseille une bonne clé WPA2 chiffrement AES
réation d'un SSID nommé WIFI-IOT
Utilisant le VLAN200
Je vous conseille une bonne clé WPA2 chiffrement AES
Et voilà.
Si tout va bien, vos 2 SSID sont diffusés:
Si on se connecte sur WIFI-MAISON
On tombe bien dans le VLAN 10
Pfsense nous a donné une IP en 10.0.0.0/24
Si on se connecte sur WIFI-IOT
On tombe bien dans le VLAN 200
Pfsense nous a donné une IP en 172.20.0.0/24
Voilà a partir de là vous pouvez affiner vos règle de filtrage Firewall sur Pfsense sur la DMZ.
Exmple n'accepter que la DMZ n'accede qu'au LAN et pas Internet
Et commencer à voir des flux bloqués :)
C'est là ou le plus dur commence.
Arriver à identifier les flux minimum d'un équipement IOT
#Gnu/Linux, Planet Libre, DNS, jeedom, pfsense
REVERSE PROXY - PFSENSE - JEEDOM
Quelques usages dans l'ordre d'importance:
- Ma domotique avec l'excellent JEEDOM
- Mes caméras
- Mon NAS sous Open Media Vault
- Et pas mal d'autres choses
- Comment acceder avec une seule adresse IP à plusieurs services en interne sur le même port ? ( https 443 , http 80)
- Comment gérer la sécurité ? ( est ce bien sécurisé d'accéder en direct à vos services ? Jeedom ouvert en direct sur internet ? ) ( en cas d'intruision vérifier chaque log de chaque service )
- Certains services ne sont pas sécurisable en https , est ce sérieux d'y accéder directement depuis l'extérieur sans intermédiaire ?? ( mettre un VPN a chaque fois ???)
- Comment gérer la performance ? des choses ne pourraient t'elle pas être compréssées ou mise en cache pour aller plus vite ?
Et bien tout cela, c'est le role du REVERSE PROXY!
cf wikipedia
Le reverse proxy va vous permettre avec un seul équipement d'accéder à plusieurs services Web internes en en faisant qu'une seule redirection de port
Le reverse proxy va ajouter de la sécurité, car il va vous permettre de ne plus laisser vos services web accessible en fontal sur internet
Le reverse proxy va ajouter de la sécurité, car il va vous permettre de chiffrer les flux écoutables sur internet, même vers des services Web qui ne sont pas sécurisés
Le reverse proxy va ajouter de la performance car il va mettre en cache des éléments statiques et va même pouvoir compresser des flux.
Le reverse proxy sur mon réseau privée.
Quand j'ai réfléchi à comment implémenter mon Reverse proxy j'ai voulu ajouter un peu de sécurité.Je trouvait qu'un reverse proxy accessible depuis internet, avait plutot sa place dans une DMZ
En effet il est plus sur de positionner son RP dans une zone qui n'a pas un full accès à tout votre réseau.
Je voulais que le RP n'ai accès qu'aux services qu'il est censé "reverse proxifier"
C'est à dire les ports 443 ou 80 de mes services internes
Voiçi le schéma simplfié de mon réseau focusé sur le RP
J'ai la chance d'avoir choisi un PFSENSE comme routeur / Firewall
De plus j'avais pensé les choses au départ.
Mon PFSENSE est installé sur un ALIX 2D13 ( 3 ports Ethernet)
Coté Gandi:
il faudra bien sur créer les entrées DNS qui pointe vers l'ip publique de votre Box
Pour ma part cam et Maison
Coté PFSENSE:
on remarque que je n'utilise aucune IP dans mes Virtual Hosts.
Que des FQDN, le but et d'utiliser que la fonction DNS
Je vais utiliser la technique du SPLIT DNS
Même FQDN mais résolu différement en fonction de la requête:
J'ai donc utilisé mon PFSENSE en tant que resolveurs DNS
Ce qui est très pratique, car je peux lui donner des noms qu"il resoudra avec une IP locale pour mes équipement interne.
1 - J'ai crée activé ma 3ème interface et je l'ai nommée DMZ2 - Renseigner l'IP de cette interface : Ce sera la passerelle du reverse Proxy
4 - J'ai créer 2 entrée DNS dans mon resolveur PFSENSE ' cela marche aussi si vou sutilisez PFSENSE en Redirecteur)
cam.monfomaine.fr ---> Pour la caméra
maison.mondomaine.fr ---> Pour Jeedom
Le Split DNS est simple voiçi uin schéma de ce qui va se passer.
Pas besoin de paramétrer des règles de routage PFSense s'occupe de tout.
Il faut par contre paramétrer des règles de NAT et de Firewall
NAT : Tous ce qui arrive sur le port 443 est natté vers le RP
Firewall : On ouvre les accès du RP vers les port 443 de Jeedom et 80 de la caméra
On autorise ausi le RP à faire des requetes DNS vers PFSENSE
Attention : PFSENSE m'avait créer une regle de NAT Unbound qui me remplacait l'ip source par l'ip de la DMZ
Du coup dans les logs du reverse proxy on ne voyais que l'ip de la passerelle, ce qui n'est pas pratique pour analyser
Bienn désactiver la regle qui dit Sque tout ce qui vient de l'interface DMZ soit natté par DMZ Adresse. ( dernière ligne)
Voilà coté PFSENSE
Installation du reverse Proxy:
J'ai choisi d'utiliser un équipement tiers : un Raspberry Pie 3j'ai commencé par une installation classique de Rapian strech Lite ( pas besoin d'interface graphique)
https://www.raspberrypi.org/downloads/raspbian/
Je vous conseille d'utiliser d'Etcher : qui est très simple à prendre en main :
Je ne détaille pas l'installation de raspian
Placer une IP Fixe sur le raspberry
Renseigner comme passerelle, l'adresse IP du PFSENSE ( interface DMZ)
Renseigner le DNS qui sera le pfsense.
Une fois le raspian installé on se lance dans l'installation du RP:je pars du principe que vous avez déjà généré un certificat SSL chez un registrar
Je vais détailler un peu ce que j'ai fait pour un Certificat Gandi.
Je passe très vite sur la création du certificat Gandi ; Tout est expliqué sur le site
1 - Achat du certificat Gandi
2 - Création du CSR à fournir à Gandi en ligne de commande
openssl req -nodes -newkey rsa:2048 -sha256 -keyout maison.key -out maison.csr4 - Achat du certificat
5 - Validation du Certificat par ajout d'enregistrement CNAME dans votre DNS
6 - Récupération des certificats
7 - Vous devez avoir 4 fichiers :
GandiStandardSSLCA2.pem maison.crt maison.csr maison.key/etc/ssl/
Pour ma part j"ai placé les fichiers de certificats dans /etc/ssl/
Pour ma caméra même principe:sudo apt-get install apache2
sudo a2enmod ssl
sudo a2enmod proxy
sudo a2enmod proxy_http
Le virtual host pour Jeedomvi /etc/apache2/sites-available/rp.conf<VirtualHost *:443>
ServerName maison.domaine.fr
SSLEngine on
SSLProxyEngine On
SSLCertificateFile /etc/ssl/maison.crt
SSLCertificateKeyFile /etc/ssl/maison.key
SSLCertificateChainFile /etc/ssl/GandiStandardSSLCA2.pem
SSLVerifyClient None
HostnameLookups off
ProxyRequests off
ProxyVia off
ProxyPass / https://maison.domaine.fr/
ProxyPassReverse / https://maison.domaine.fr/
<Proxy *>
Order allow,deny
allow from all
</Proxy>
ErrorLog ${APACHE_LOG_DIR}/rproxy_error.log
CustomLog ${APACHE_LOG_DIR}/rproxy_access.log combined
</VirtualHost>
vi /etc/apache2/sites-available/zcam.conf<VirtualHost *:443>
ServerName cam.domaine.fr
SSLEngine on
SSLProxyEngine On
#SSLProtocol All
SSLCertificateFile /etc/ssl/maison.crt
SSLCertificateKeyFile /etc/ssl/maison.key
SSLCertificateChainFile /etc/ssl/GandiStandardSSLCA2.pem
SSLVerifyClient None
HostnameLookups off
ProxyRequests off
ProxyVia off
ProxyPass / http://cam.domaine.fr/
ProxyPassReverse / http://cam.domaine.fr/
<Proxy *>
Order allow,deny
#Deny from all
allow from all
</Proxy>
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/rproxy_error.log
CustomLog ${APACHE_LOG_DIR}/rproxy_access.log combined
</VirtualHost>cd /etc/apaches/site-available
a2ensite rp.conf
a2ensite zcam.conf
/etc/init.d apache2 reloadVoila notre Reverse proxy est configuré
Si tout est OK depuis l'extérieur on accéde bien à notre Jeedom et à notre Cam en passant
Par le Reverse Proxy
Si tout est OK depuis l'interne on accéde bien à
notre Jeedom et à notre Cam en passant
en direct sur le lan ( DNS Résolu en local par pfsense)
Par contre vous aurez remarqué qu'une erreur de certificat est présent sur la cam
Ce qui est normal car j'utilise le même certificat dans les 2 virtual Hots
Et ce certificat à été grée pour maison.mondomaine.fr et non cam.mondomaine.fr
Cela n'est pas grave, j'ai confiance en mon certificat, et le but est de chiffrer les flux vers ma
caméra.
#Gnu/Linux, Planet Libre, DNS
- DNS MENTEURS - - CENSURE SUR INTERNET -
De nos jours tout Internet est basé sur les noms de domaines.
Sans le système DNS quasiment plus rien ne fonctionnerait.
Pour rappel selon Wikipédia:
Le Domain Name System (ou DNS, système de noms de domaine) est un service permettant de traduire un nom de domaine en informations,
notamment en adresses IP .
Autrement dit quand vous tapper sur http://blog.info16.fr, votre machine va tenter de transformer ce nom en Adresse IP.
Grace à cette addresse votre système va pouvoir aller communiquer avec l'adresse IP de mon blog.
La structure et le fonctionnement du DNS
Le système DNS utilise une structure en arbre.
Tout commence depuis les serveurs Racines ( Root ) : Officiellement
il y en a 13 ( 13 adresses IP) , mais réèllement il y en a plus
de 130 répartis dans le monde
Les serveurs racines utilisent la technologie réseau unicast ; selon votre localisation, l'adresse IP va être routée vers un serveur
le plus prêt de la requete.
sources: https://fr.wikipedia.org/wiki/Serveur_racine_du_DNS
Puis les serveur de TLD ( .fr, .com, ...) ou de premier niveau
Puis les serveurs de second niveau
Puis les serveur de troisième niveau
etc ...
Autrement dit une requete récursive vers ce blog donnerait:
1. Quelle est l'adresse IP de blog.info16.fr ? ( Les serveurs racines voit toujours la requête complète)
2. les serveurs racines répondent la liste des serveurs faisant autorité pour le .FR
3. Le client DNS interroge alors un des serveurs faisant autorité pour .FR en lui demandant "quelle est l'adresse IP de blog.info16.fr"
4. Un des serveurs faisant autorité pour .FR répond la liste des serveurs faisant autorité pour le domaine info16.fr
5. Le client DNS interroge alors un des serveurs faisant autorité pour info16.fr en lui demandant "qu'elle est l'adresse IP de blog.info16.fr"
6. le serveurs faisant autorité pour .info16.fr répond la ou les adresses IP correspondantes au nom blog.info16.fr
On le voit très bien en utilisant la commande dig + Trace
Le resolveur
Cet enchainement de questions/réponses est ce que fait un résolveur
Le résolveur va de plus mettre en cache les réponses trouvées afin de pouvoir les fournir plus rapidement
la prochaine fois qu'on lui demandera. ( le temps du TTL du DNS)
Cela permet de ne pas de réinterroger tous les racines et les serveurs faisant autorités à chaque fois.
Cela explique que les DNS Racines ne sont pas très chargés car la plupart des requetes clients sont fournies via des résolveurs
qui ont la réponse en cache.
Plus le résolveurs est sollicité plus son cache sera fourni et moins il interrogera les serveurs racines.
Source www.afnic.fr
Il y a donc deux types de serveurs DNS:
- Les Serveurs faisants autorité ( à différents niveaux)
- Les resolveurs ( qui connaissent en durs les IP des racines)
Les serveurs faisant autorité ont l'autorité sur un domaine: c'est-à-dire que la réponse ne fait pas appel à un autre serveur ou à un cache
Les resolveurs sont des serveurs qui vont intérroger les serveurs faisant autorité et mettre en cache les réponses pour les fournir à ses clients.
La plupart des utilisateurs de l'internet on
peu ou pas conscience de ce fonctionnement.
L'utilisateur LAMBDA utilise sa box internet fourni par son FAI et navigue sans se poser de question.
La plupart du temps les box internet utilisent les résolveurs du Fournisseur d'accès.
PAr exemple :
Free:
212.27.40.240
212.27.40.241
Orange:
80.10.246.2
80.10.246.1291
SFR:
109.0.66.10
109.0.66.20
Et beaucoup d'autres...
http://www.ariase.com/fr/guides/adresses-dns.html
La censure via les DNS Menteurs
Mais alors mon FAI peut me renvoyer n'importe quelle adresse ? quand j'interroge un domaine ?
OUI mon capitaine.
D'ailleurs si vous suivez l'actualité, des décrets français permettent d'obliger les FAI à bloquer, filtrer des sites internet
Sur décision de justice.
La réponse la plus simple des FAI est d'utiliser le mensonge DNS.
Par exemple cela à été le cas sur des sites de streaming, Torrent, etc ..
T411, Pirate Bay, libertyland, voirfilm ...
Mais aussi des sites islamistes, propagandes, etc ...
Vous allez me dire, oui... c'est pour notre sécurité, et c'est normal de bloquer ce qui est illégal.
On peut le voir comme cela en effet, si vous arrivez à dormir avec cela et que cela ne vous gène pas que
ce qu'on vous affiche à l'écran est ce qu'a décidé votre FAI et votre gouvernement, alors continuez comme cela.
Il faut des moutons :)
Pour ma part je milite pour la neutralité du NET depuis longtemps.
La Quadrature du NET en parle beaucoup mieux que moi : https://www.laquadrature.net/fr/neutralite_du_Net
On peut imaginer alors que ces résolveurs peuvent vous mentir à chaque instant et vous
envoyer l'adresse IP qui leur plait.
Pour par exemple:
- Bloquer des sites
- Vous envoyer sur des adresses publicitaires
- Monetiser des sites
- ...
Plus en détail, bortzmeyer.org. explique que « certains FAI prétendent mettre en place des DNS menteurs pour « le bien des clients »
alors qu'en réalité, ils sont poussés par des intermédiaires qui leur proposent de « monétiser » l'audience du site Web ainsi pointé, comme l'a bien expliqué le directeur technique de Free).
La preuve du mensonge.
Vous allez me dire; oui mais comment prouver que mon résolveur me ment ?
En effet, il y a des cas facile et d'autres nons.
Dans certains cas, la résolution d'un nom de domaine par un resolveur menteur aboutit à la réponse 127.0.0.1
qui est votre adresse locale ce qui explique une page blanche ou une erreur dans votre navigateur.
Dans d'autres cas, le DNS va vous renvoyer un code erreur
Dans d'autre le DNS va vous envoyer sur une page de bloquage ou une publicité.
Exemple : Allez avec votre navigateur sur http://streamcomplet.me/ ( juste pour voir, le téléchargement d'oeuvres protégées est illégales)
Avec mon résolveur:
Pour ma part en utilisant mon propre résolveur ( je vous en parlerait plus loin), le site s'affiche:
D'ailleurs il me redirige vers un autre domaine, car le site essaye déjà de contourner la censure
La résolution DNS donne les adresses IP du FQDN
Moi@linux:~# dig streamcomplet.com +short
104.28.6.68
104.28.7.68
Avec le résolveur de mon FAI
Avec le résolveur de mon FAI ( je vous laisse deviner lequel)
Page blanche.
La résolution DNS renvoi 127.0.0.1
root@NAS:~# dig streamcomplet.com +short @212.27.40.241
127.0.0.1
La preuve avec les sondes ATLAS:
Il est difficile d'avoir une vue de l'internet depuis n'importe quel endroit du monde.
Qui me dit que l'internet est le même si je navigue depuis La France ou ou depuis l'Allemagne.
Pour cela il existe le projet RIPE NCC , qui à un réseau de sonde Atlas.
Selon mon grand gourou Stéphane BORTZMEYER
Le réseau des sondes Atlas, créé et géré par le RIPE-NCC, couvre l'Europe (et au delà) de petites machines connectées à l'internet et qui effectuent en permanence des mesuresdiverses, qui servent par exemple de base aux très intéressants articles des RIPE Labs. Cela permet par exemple de détecter une bogue présente dans beaucoup de routeurs. Les Atlas ne savaient faire au début que des mesures commandées par le RIPE-NCC. Depuis quelque temps, les utilisateurspeuvent également commander des mesures selon leur goût, un système connu sous le nom d'UDM, User-Defined Measurements.
Ces petites sondes, tout le monde peut faire la demande d'en héberger et de la brancher sur sa connection internet.
Si RIPE NCC accepte votre demande vous recevrez votre petite sonde, qui contribuera à sonder la qualité de l'internet.
Héberger cette sonde vous permet de gagner des crédits chez https://atlas.ripe.net/
Ces crédit vous permettent de lancer des mesures internet depuis le site mais aussi depuis leurs APIs
Des scripts disponibles sur Github vous permettent d'utiliser ces API:
https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib
J'ai la chance d'héberger une sonde, et donc de pouvoir faire ces mesures.
Parmis ces mesures on peut mesurer les DNS.
Reprenons l'éxemple de streamcomplet.com
En FRANCE
Nous allons utiliser le script atlas-resolve
% atlas-resolve --country FR --requested 100 streamcomplet.com
[ERROR: SERVFAIL] : 10 occurrences
[104.28.6.68 104.28.7.68] : 47 occurrences
[ERROR: NXDOMAIN] : 7 occurrences
[127.0.0.1] : 35 occurrences
[TIMEOUT(S)] : 1 occurrences
Test #9327211 done at 2017-09-23T10:15:02Z
on lui demande, "résoud moi streamcomplet.com, depuis 100 sondes ATLAS hébergées en FRANCE"
On obtient:
47 bonnes réponse sur 100 requetes ...
Ce domaine est donc en partie "censuré" en France
En ALLEMAGNE
Nous allons utiliser le script atlas-resolve
% atlas-resolve --country DE --requested 100 streamcomplet.com [104.28.6.68 104.28.7.68] : 100 occurrences Test #9327213 done at 2017-09-23T10:16:08Zon lui demande, "résoud moi streamcomplet.com, depuis 100 sondes ATLAS hébergées en FRANCE"
On obtient:
100 bonnes réponse sur 100 requetes !!!
Ce domaine ne subit pas de censure en Allemagne.Mais alors !! Qu'est ce que je dois faire ??
Les Resolveurs publics
Si vous vous interessez un peu à la question, les premières réponses qu'on trouve
sur le NET c'est:
Les DNS de ton FAI ce sont des menteurs, utilise les DNS de Google ; les fameux 8.8... !!! Eux ils te respectent
D'autres te diront Utilise ceux de Open DNS c'est les meilleurs et ils sont OPEN
D'autres réponses un peu moin bêtes vous recommande des Résolveurs associatif qui revendiquent la liberte du NET
Tout cela se discute sur plusieurs points:
Google --> Vous êtes sérieux ? certes ils ne sont pas connus pour mentir, mais encore cela peu changer
Mais vous vous doutez bien que c'est vous le produit, et que vos requetes seront utilisées d'une manière ou d'une autre.
Ceci dit vous utilisez surement leur moteur de recherche . ils savent dejà tout de vous.
Du moment que vous en êtes conscient ...
OpenDNS --> Cela pourrait paraitre une bonne idée à première vue, mais leurs intentions ne sont pas différentes
de celle de Google.
Ils vont même a vous ajouter de la Pub, quand le FQDN n'existe pas.
Tout cela est réglable dans leur interface, mais ma confiance en eux est toute relative.
NB; L'utilisation de OPEN DNS en tant que filtrage parentale peut apporter une solution à mondre cout
Si on est conscient du risque pourquoi pas.
Les DNS Associatifs et les autres --> Certains DNS associatifs s'engagent sur la pureté des résolutions de nom (pas de censure...etc.)
comme les DNS proposés par FDN : 80.67.169.12 et 80.67.169.40.
pourquoi pas, ce serait le moins pire.
Mais encore une fois nous ne savons pas à 100% qu'ils respecteront leurs engagements,et si les resolveurs ne disparaitront pas du jour au lendemain
Il faut aussi voir le coté performance.
En règle général les resolveurs de vos FAI seront les plus rapides ( mais pas toujours)
Ils sont sur le même réseau que vous et sont donc censé etre plus performants.
Si vou ssouhaitez utiliser des résolveurs ouverts publics n'hésitez pas à tester leur temps de réponses avec dig par exemple
;; Query time: 59 msec
;; SERVER: 212.27.40.241#53(212.27.40.241)
;; WHEN: Sat Sep 23 14:54:36 CEST 2017
;; MSG SIZE rcvd: 138
Avoir son propre résolveur.
J'en suis arrivé à la conclusion, que la moins pire des solutions est
d'utiliser son propre resolveur
Cela demande un peu ( très peu) de travail, mais c'est le seul moyen d'éviter les problèmes de DNS Menteur et
d'exploitation de vos requetes DNS
Le tout en gardant une meilleure performance.
Il y a plusieurs outils qui vous permettent de monter votre résolveur
Les plus connus : Unbound et BIND
Unbound est pas mal car beaucoup plus léger que BIND.
Je ne vais pas écrire d'article sur comment monter un résolveur; Il y en a plein sur le NET.
Ce résolveur va lui même réaliser les requetes récursive depuis les racines et les mettre en cache
PAr conséquent, pas de censure, et vous maitrisez vos requetes DNS
de plus la performance est au rendez vous, puisque si votre resolveurs est local, la réponse
en cache sera quasi instantanée
Exemple d'une requete depuis un de mes postes clients, qui utilise mon resolveur local unbound
Premiere requete elle n'est pas en cache --> 176ms
Moi@NAS:~# dig www.info16.fr
;; QUESTION SECTION:
;www.info16.fr. IN A
;; ANSWER SECTION:
www.info16.fr. 3600 IN A 212.129.3.40
;; AUTHORITY SECTION:
info16.fr. 10800 IN NS b.dns.gandi.net.
info16.fr. 10800 IN NS c.dns.gandi.net.
info16.fr. 10800 IN NS a.dns.gandi.net.
;; Query time: 176 msec
;; SERVER: 10.0.0.254#53(10.0.0.254)
;; WHEN: Sat Sep 23 15:06:31 CEST 2017
;; MSG SIZE rcvd: 119
On relance la même requetes --> Elle est instantanée 0ms
Moi@NAS:~# dig www.info16.fr
;; QUESTION SECTION:
;www.info16.fr. IN A
;; ANSWER SECTION:
www.info16.fr. 3592 IN A 212.129.3.40
;; AUTHORITY SECTION:
info16.fr. 10792 IN NS b.dns.gandi.net.
info16.fr. 10792 IN NS c.dns.gandi.net.
info16.fr. 10792 IN NS a.dns.gandi.net.
;; Query time: 0 msec
;; SERVER: 10.0.0.254#53(10.0.0.254)
;; WHEN: Sat Sep 23 15:06:39 CEST 2017
;; MSG SIZE rcvd: 119
Il existe tout de même des inconvénients non négligeables.
Vous ne bénéficier pas de l'énorme cache du résolveur de votre FAI
Sur l'ensemble des requetes de tous ses clients, le cache emmagazine les informations et les fournis
sans faire de requetes récursive.
Vous solliciterez plus les serveurs racines et contribuerez à leur montée en charge.
Mais a mon avis cela reste la meilleures solution à l'heure actuelle.
Pour finir, c'est vrai que monter son resolveur, n'est pas toujours évident.
Surtout pour le grand public ( les entreprises c'est plus facile, elles bénéficient déjà d'infrastructures serveurs))
Avoir un petit serveur qui tourne dans un coin, ou un vrai serveur dédié demande de l'investissement et du temps
Pour ma part j'ai trouvé le compromis qui me convient : Cela est intégré dans mon routeur.
J'utilise ma Box en mode Bridge, ce qui me permet de mettre un vrai routeur / Firewall en frontal de ma connexion.
Pour cela j'utilise le magnifique PFSENSE que j'ai monté dans un petit boitier ALIX:
Dans PFSENSE, le choix de faire un DNS Forwarder ou Resolver est possible: ( d'ailleurs PFSense utilise Unbound)
