C’est un porte clef de mot de passe. Vous avez un mot de passe principal pour déverrouiller votre porte clé. Une fois celui-ci déverrouillé vous pouvez récupérer tout les mots de passe que vous aurez stocker dans ce porte clé.
Sur gnome il est automatiquement utilisé par Chromium, pgp et d’autres…

Par défaut gnome-keyring verrouille le porte clé principal avec le mot de passe de votre session.

Problèmes

Tout ne fonctionne pas correctement avec l’autologin des gestionnaire de session graphiques tel que lightdm

Demande d’entrer son mot de passe

Si vous avez configuré votre session en autologin. C’est root qui va lancer votre session, et il ne connait pas votre mot de passe. Il ne peut donc pas déverrouiller votre trousseau de clé.

Erreur lors de l’arrêt de la machine

En plus cela produit une erreur lors de l’arrêt du PC : « gnome-keyring-daemon not responding ».
Ce processus est lancé en tant que root, l’utilisateur local ne peut donc pas tuer ce processus sans demander un kill.

Solutions

Toutes ces opérations sont a faire en étant connecté avec l’utilisateur qui est en autologin. Jamais en root. (Sinon vous allez configurer gnome-keyring de root).

Demande d’entrer son mot de passe

On va créer un script python qui va entrer votre mot de passe à votre place.

Cette solution est pas très sécurisée. Serte le script sera accessible que par votre user. Mais cela n’empêche pas un virus, qui a prit le contrôle de votre user, de récupérer votre mot de passe. Je vous conseille donc de ne pas stocker votre mot de passe en clair.
Faites attention surtout si votre user peut faire un sudo su !
Il faut quand même noter que si vous avez un user en autologin, c’est que n’importe qui physiquement peut se passer pour cet user. Donc ses droits doivent être réduit au maximum.

Fichier /home/tonUtilisateur/.keyring-unlocker.py

#!/usr/bin/python
import gnomekeyring
gnomekeyring.unlock_sync(None, 'tonMdp');

Il est aussi conseillé d’utiliser des noms de fichiers qui ne comporte aucun signification. Cela permet de rendre plus difficile la détection de mot de passe par un virus.

chmod 700 /home/tonUtilisateur/.keyring-unlocker.py

On va mainteant lancer ce script a chaque login de notre user :
Fichier ~/.config/autologin/keyring-unlocker.desktop

[Desktop Entry]
Type=Application
Exec=/home/tonUser/.keyring-unlocker.py
X-GNOME-Autostart-enabled=true
NoDisplay=false
Hidden=false
Name[fr_FR]=Keyring Unlocker
Comment[fr_FR]=Keyring unlock
X-GNOME-Autostart-Delay=0

Exec : Vous devez mettre le chemin entier. Il n’est pas possible d’utiliser $HOME ou ~
 

Encore une fois je vous conseille de donner aucune significations a votre nom de fichier ainsi que ses commentaires .

Vérifiez que tout fonctionne :

~/.keyring-unlocker.py
echo $?

Si vous la commande echo vous renvoie un 0 c’est que tout fonctionne.
Si vous avez un Keyring IO exception cela veut dire que vous vous êtes trompé dans votre mot de passe.

Erreur lors de l’arrêt de la machine

Si vous faites un :

grep "gnome-keyring-daemon" /var/log/syslog

Vous devez avoir quelque chose dans ce genre :

cinnamon-session[1413]: WARNING: t+53,26576s: Unable to find desktop file 'gnome-keyring-daemon.desktop': Impossible de trouver un fichier de clés valide dans les répertoires de recherche

Cela veut juste dire que cinnamon-session chercher un fichier /home/tonUtilisateur/.config/autologin/gnome-keyring-daemon.desktop
On va donc le créer :

[Desktop Entry]
Type=Application
Exec=/usr/bin/gnome-keyring-daemon -r -d
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Gnome Keyring Daemon
Comment=Charge gnome keyring daemon

Les arguments -r permettent d’arrêter toutes instances de gnome-keyring-daemon déjà lancées. L’erreur vient enfaîte de là.
Et le -d permet de lancer gnome-keyring-daemon en tant que daemon.

Il vous reste plus qu’a redémarrer et tout est bon !

L’article Gnome Keyring et autologin solutions est apparu en premier sur RMFB - Read My F-Blog.

J’ai donc voulus migrer ce petit PC sous Linux Mint. Le problème semble simple, graver une clée USB et hop on la met dans le PC et c’est fini.

Oui, mais non. Les PC récents permettent de faire ça simplement, les anciens c’est toujours plus complexe. Ils n’acceptent pas les même méthodes de boot.

J’ai commencé par graver un DVD, changer le boot order de la machine et… Rien
Je me suis rendus compte que ce BIOS acceptait l’USB-CDROM et USB-FDD. J’ai donc tenté l’USB. J’ai formaté ma clée USB via la CMD et j’ai utilisé Rufus, en utilisant les deux modes de copie du logiciel… Rien sur tout les ports USB de la machine.
Je me suis donc dis, pourquoi pas le faire en Boot PXE. Bon déjà petit tricks, il faut penser a activer l’alimentation de la carte Ethernet avant la séquence de boot. Sinon bah… ça fait rien.

Préambule

Je vais donc vous présenter ici comment installer un serveur PXE sur votre machine afin de permettre l’installation de Linux Mint sur une autre machine.
Les procédures décrites ici partent du principe que c’est une installation temporaire faite depuis un Live CD Linux Mint et que le réseau qui relis le serveur au client et vide de tout serveurs (DHCP entre autre, donc pas de Box). Typiquement un câble reliant le serveur au client.
Si cela corresponds pas à votre configuration il suffira de changer certains chemins, et/ou modifier votre serveur DHCP pour qu’il donne les informations vers votre serveur TFTP.

Présentation du boot PXE

Utilisation

Cette technologie permet de démarrer (booter) une machine sur des ressources distantes qui vont êtres rapatriées à l’aide tu protocole TFTP. Cela est couramment utilisé par les admin sys car cela permet, couplé avec Wake On Lan de réinstaller des machines à intervalles réguliers. A chaque démarrage la machine va télécharger un fichier en TFTP pour savoir si il doit réinstaller son système ou non. Si c’est le cas, via TFTP un second script va été télécharger pour lancer la procédure d’installation. Sinon le script PXE va s’arrêter et le boot normal va alors se faire.

Fonctionnement

Cette technologie se repose sur DHCP/BOOTP. Au démarrage, client va demander une adresse IP au serveur DHCP de son LAN. Ce dernier va lui proposer une adresse IP et fournir les informations de connexion au serveur TFTP.
Le client va utiliser les informations de connexion (IP/port/fichier à télécharger) pour communiquer avec le serveur TFTP. (certains téléphones IP ont le nom du fichier à récupérer codé en dur).
Une fois le fichier principal récupéré (un script, pxelinux.0 en général pour du linux). Il va l’exécuter, et généralement télécharger de nombreuses dépendances pour installer un système pour démarrer un système.
Comme TFTP est un protocole simple(iste), il n’est pas performant. On couple donc souvent TFTP avec un protocole transfert de fichier. Dans le monde linux on utilise souvent NFS mais il est tout à fait possible d’utiliser HTTP ou bien SMB .

Sur un ordinateur disposant de Windows vous pouvez très bien booter sur un système linux (pxelinux.0).

Liste des serveurs à installer

On va installer :

• Serveur DHCP pour fournir les informations du serveur TFTP (fichiers à télécharger et IP du serveur)
• Serveur TFTP pour fournir les fichiers lors du boot PXE
• Serveur NFS pour accélérer les transferts de fichiers une fois le premier script téléchargé

Configuration réseau

J’ai branché la clée USB de Linux Mint dans le pc qui servira de serveur TFTP. J’ai ensuite lancé le live CD de Mint. Le serveur disposera donc en directe de tout les fichiers requis pour le boot PXE.
J’ai branché directement en ethernet le serveur et le client (la veille machine).

Ce nouveau réseau va être configuré pour être 192.168.30.0/24
Le serveur sera en 192.168.30.254. (Cliquez ici si vous ne savez pas le faire).
Et le client va récupérer une adresse IP depuis le serveur DHCP du serveur.

Installation du DHCP

apt-get install isc-dhcp-server

Mainteant il faut configurer le serveur DHCP pour qu’il serve le réseau 192.168.30.0/24. Automatiquement il saura quelle interface écouter. Pour cela il va regarder quelle interface à un adresse IP dans les réseaux qu’il doit servir.

Fichier /etc/dhcp/dhcpd.conf

subnet 192.168.30.0 netmask 255.255.255.0 {
        range 192.168.30.100 192.168.30.200;
        filename "pxelinux.0";
}

Rien d’extraordinaire. On définis le sous réseau, on fixe le range des IPs qui seront délivrées par DHCP. Et on indique le fichier par défaut à récupérer en cas de PXE.

service isc-dhcp-server restart

Vérifiez bien dans /var/log/syslog que le serveur s’est lancé sans erreur

Installation du TFTP

apt-get install tftpd-hpa

On ne va pas installer xinetd ou bien inetutils-inetd. Pour rappel l’intérêt d’un super serveur est d’avoir un seul daemon qui écoute plusieurs services. Cela permet de vérifier qu’un client à le droit d’utiliser un service avant même de rediriger la requête vers ce dit service. Cela peut aussi réduire le nombre de daemons qui tournent sur une machine, ce qui est utiles si vous hébergez des services peu utilisés.

Contrairement à APACHE/PHP qui inclue le moteur PHP dans tout ses fork, xinetd va faire un appel vers le service demandé.

Fichier /etc/default/tftpd-hpa

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
#TFTP_ADDRESS="[::]:69"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"

TFTP_USERNAME : Par défaut, via apt, un utilisateur tftp est crée. Autant l’utiliser.
TFTP_DIRECTORY : J’ai choisis comme racine TFTP ce dossier, mais vous pouvez le changer en /tftpboot
TFTP_ADDRESS : Adresse IP destination écoutée par le serveur TFTP. J’ai choisi n’importe quel adresse IPv4 de mon serveur tant que c’est à destination du port 69 (TFTP).
TFTP_OPTIONS : J’ai rajouté le secure, sans quoi une erreur « Only absolute filename allowed » risque d’apparaître sur le client (Lien du bug).

service tftpd-hpa start

Configuration des fichiers

Le majeur problème via l’ISO de Linux Mint c’est l’absence totale de fichier pour le boot PXE. On va donc les créer.

mkdir -p /var/lib/tftpboot/images/linuxmint /var/lib/tftpboot/pxelinux.cfg

L’argument -p de mkdir permet de créer les dossiers parents si ils n’existent pas.

cp -R /media/cdrom/* /var/lib/tftpboot/images/linuxmint

En supossant que le serveur fonctionne sur le live CD de Linux Mint.

mount --bind /media/cdrom/ /var/lib/tftpboot/images/linuxmint

Pour pas avoir de soucis d’accès pensez à donner les droits de lecteurs aux fichiers :

chmod -R o+r /var/lib/tftpboot

pxelinux.cfg/default

Via la configuration de DHCP on a indiqué a notre client de télécharger pxelinux.0. Mais il est possible de configurer ce script pour faire ce que nous voulons. Voici la configuration requise pour installer Linux Mint.
Fichier /var/lib/tftpboot/pxelinux.cfg/default :

DEFAULT Linux-Mint
 
LABEL Linux-Mint
MENU LABEL Linux-Mint
KERNEL images/linuxmint/casper/vmlinuz
APPEND root=/dev/nfs boot=casper netboot=nfs nfsroot=192.168.30.254:/var/lib/tftpboot/images/linuxmint initrd=images/linuxmint/casper/initrd.lz nosplash --

Dans ce fichier on doit donner le chemins vers le kernel et l’initrd qui va permettre d’installer notre Linux Mint. Evidemment on va utiliser les fichiers de notre Linux Mint.
C’est ici qu’on définis que nous allons utiliser NFS pour télécharger notre installation de Linux Mint. On entre donc l’adresse IP du serveur NFS ainsi que le dossier NFS à demander.

Télécharger pxelinux.0

On a indiqué dans le serveur DHCP que le fichier par défaut à téléharger en PXE (via TFTP) est pxelinux.0, sauf qu’on a pas ce fichier. Et il est pas fournis par Mint. On va donc le télécharger.

Il est possible de le télécharger depuis le site Kernel.org à l’adresse https://www.kernel.org/pub/linux/utils/boot/syslinux/

Le mieux est de télécharger le fichier qui corresponds au linux à déployer. Mais vu que le script de boot est basique on peut prendre presque n’importe quel fichier. Moi j’ai pris le dernier en date.

Il faut ensuite désarchiver et copier le fichier syslinux-x.xx/bios/core/pxelinux.0 vers /var/lib/tftpboot/pxelinux.0

Corriger l’erreur « failed to load ldlinux.c32 »

Il se peut que lors du boot votre client retourne l’erreur « failed to load ldlinux.c32 », a ce moment il faut copier ce fichier dans le dossier tftpboot.

cp /var/lib/tftpboot/images/linuxmint/isolinux/ldlinux.c32 /var/lib/tftpboot

Configuration de NFS

Le protocole TFTP (Trivial File Transfer Protocol) est comme son nom l’indique un protocole basique. Il est très lent et n’est pas fait pour transférer des gros fichiers. Mais comme nous voulons quand même qu’un système d’exploitation entier puisse être installé. On va utiliser un protocole dédier au transfert de fichier.
En gros TFTP va permettre de télécharger un système linux basique, qui va ensuite télécharger tout les gros fichier en NFS. Puis lancer le script d’installation du système.

apt-get install nfs-kernel-server

Fichier /etc/exports

# /etc/exports: the access control list for filesystems which may be exported
#		to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#
/var/lib/tftpboot/images/linuxmint 192.168.30.0/24(ro,sync,no_subtree_check,fsid=42)

On partage que /var/lib/tftpboot/images/linuxmint, car les fichiers qui se trouvent dans le dossier/var/lib/tftpboot/ ne seront accédés que depuis le serveur TFTP.
192.168.30.0/24 : La requête NFS doit être faite depuis une machine dans le réseau 192.168.30.0/24.
ro : On donne l’accès en Read Only.
sync : Permet d’avoir un fonctionnement de nfs-kernel-server tel que définis par le protocole NFS.
no_subtree_check : Réduit le nombre de vérifications a chaque requêtes. Ce qui accélère les accès mais réduit un peu la sécurité (pas dans notre cas).
fsid=42 : Si votre système de fichier n’as pas de UUID ou votre disque n’a pas device number vous devez spécifier un identifiant de de système de fichier. Sans quoi vous aurez cette erreur :

qword_eol: fflush failed: errno 22 (Invalid argument)
Cannot export /var/lib/tftboot/images/linuxmint possibly unsupported filesystem or fsid= required

Comme identifiant fsid vous pouvez mettre n’importe quelle chaîne hexadécimale. La longueur maximale est de 32 caractères. root et 0 sont des identifiants réservés.

service nfs-kernel-server restart

L’article Installer Linux Mint en LAN/PXE est apparu en premier sur RMFB - Read My F-Blog.

table-of-contents-plus/toc.php

On va changer l’ordre de chargement du style CSS, et le mettre en dernier.
Remplacer

add_action( 'wp_enqueue_scripts', array(&$this, 'wp_enqueue_scripts') );

Par

add_action( 'wp_enqueue_scripts', array(&$this, 'wp_enqueue_scripts'), 99 );

table-of-contents-plus/screen.css

Remplacer

#toc_container ul ul {
	margin-left:1.5em;
}

Par

#toc_container ul ul {
	margin:0;
	padding:0;
	margin-left:1.5em;
}

Pour vérifier que tout fonctionne il suffit de faire CTRL+F5 et vérifier que tout est bon.

L’article Corriger le CSS du plugin WP TOC+ est apparu en premier sur RMFB - Read My F-Blog.

Code

Voici comment un créer un utilisateur dit « système » :

addgroup --system openvpn
adduser --no-create-home --system --disabled-login --ingroup openvpn --home /etc/openvpn  openvpn

L’article Créer un utilisateur système est apparu en premier sur RMFB - Read My F-Blog.

• Chiffrer ses communications sur un Wifi non sécurisé ou bien un réseau WPA-personnal (WPA des Box)
• Cacher son identité (utilisation de proxy)
• Permettre d’accéder a un réseau uniquement accessible depuis le serveur VPN
• Pour connecter 2 réseaux locaux via une connexion p2p (point à point) – Je ne vais pas traiter cette partie –

IPv6 est sorti en 1998 et moins de 10% du trafic internet est en IPv6, cependant il serrait bien temps de commencer a prendre en compte IPv6 dans ses configurations. Je vais donc vous présenter une configuration d’OpenVPN en IPv4 ET IPv6.

On trouve sur internet de nombreuses configurations pour OpenVPN en IPv4, moi je vais vous proposer une configuration qui permet a la stack IPv4 ET IPv6 de fonctionner avec votre tunnel. Que ça soit dans le tunnel ou en dehors du tunnel.

Cette solution va utiliser du NAT pour IPv4 ET IPv6. En effet, je ne souhaite pas que mon serveur utilise plusieurs adresses IPv6 vers l’extérieur.

Présentation du protocole VPN

Le principe est que le client va encapsuler son paquet IP (si VPN TUN) dans un nouveau paquets IP avec comme data(payload) le paquet IP de base.

Il est donc possible de chiffrer le contenu du paquets VPN ce qui sécurise le trafic entre le client et le serveur.
Cela va évidement pas sécuriser de bout en bout, puisque le serveur VPN va déchiffrer le contenu du paquet, dés-encapsuler la trame initiale, router cette dernière et la transmettre au destinataire final.

Pour faire cela le logiciel VPN va créer une interface dite virtuelle (car elle existe pas physiquement) sur le client et sur le serveur. Une adresse IP va être assignée a l’interface du client par le serveur. L’interface du client et celle du serveur sont sur le même réseau. Tout ce qui rentre dans l’interface client, re-sort par l’interface serveur. Comme si il y avait eu rien entre les deux machines.

Une grosse partie de la configuration d’un VPN est le routage, comme vous pouvez le penser. Effectivement, il faut rediriger le trafic client que vous voulez vers cette nouvelle interface (celle côté client). Et il faut rediriger le trafic sortant du tunnel vers la cible que vous voulez.
La configuration du routage va beaucoup dépendre de votre utilisation de VPN.

Les différents cas d’utilisation de VPN

Le protocole VPN n’est qu’un protocole réseau, c’est à vous de l’utiliser comme vous en avez besoin. Mais je vais vous présenter ici quelques cas d’utilisations très courants.
Je ne vais pas tous les détailler, car certains ne sont utiles que dans des cas très spécifiques.

Cas « connexion à réseau local a distance »

Ce genre de configuration est très utilisée dans des entreprises multi-sites. Une agence à Paris et une agence à Marseille par exemple. Et on voudrais que les machines de Paris puissent communiquer avec les machines de Marseille comme si il étaient dans le même réseau local.
En général ce genre de configuration se fait sur des routeurs ou des concentrateurs VPN (équipement dédié aux communication VPN) car le trafic est très important.

Dans ce cas les deux équipements VPN (celui de Paris et celui de Marseille) seront connecté en P2P (peer to peer). Il n’y auras donc aucun réseau entre ces deux machines (ou bien un réseau en /30).

Aucun routage n’est requis car dès lors que l’équipement à accès a tout les réseaux locaux, ils saurât router les paquets vers ces réseaux locaux.

Je ne vais pas expliquer en détail comment il faut faire ce genre de configuration. Cependant il suffira de supprimer des directives forçant tout le trafic d’internet vers le serveur VPN, et il n’y auras pas besoin de regarder la partie routage de ce post.

Cas « proxy »

Si vous voulez cacher votre identité (adresse IP). Vous voulez rediriger tout le trafic du client vers cette interface VPN et que le serveur, lui, redirige tout le trafic vers le destinataire final.

Il faut donc rajouter une entrée dans la table de routage du client pour tout rediriger vers l’interface VPN. On pourrais penser à changer la route par défaut, sauf que le client en a déjà une. L’écraser est pas une bonne idée car il faudrait la stocker pour pouvoir la remettre après.
La solution est l’utilisation de deux routes, une qui va rediriger la moitié des IP, et une seconde la deuxième partie des IP. Cela à pour effet de rendre ineffectif la route par défaut, car pour rappel en routage CIDR on cherche la route la plus spécifique en premier et dès qu’on en trouve une : on l’utilise.
Comme le protocole VPN n’est pas magique il va bien falloir lui ajouter une route à destination de serveur VPN. En effet notre interface VPN à pour effet d’encapsuler, mais après il envoie bien les trames au serveur VPN. Il doit donc il y avoir une entrée dans la table de routage pour que ce paquet puisse arriver à destination.

Le serveur va récupérer les trames, mais une fois décapsulées il va trouver une adresse IP de type privée (192.168.x.x ou bien 10.x.x.x en IPv4), en effet le protocole VPN en mode non P2P va créer un réseau privé entre le client et le serveur. Le problème c’est que ces IP privées ne peuvent pas être utilisées sur internet. On va donc remplacer les IP sources avec celle du serveur VPN. Le destinataire final va envoyer sa réponse au serveur VPN, on va cette fois-ci faire le fonctionnement inverse, on va changer l’adresse IP destinataire par l’adresse du client (l’adresse de l’interface VPN). Ce fonctionnement se fait via le protocole NAT. Il est utilisé par votre Box par exemple, toutes vos machines locales ont la même adresse IP publique.

Spécificités IPv6 (Proxy NDP et Unique Local Address)

Vu qu’en général votre FAI vous fournis un bloc /64 en IPv6 il est possible de faire du subnetting pour qu’une partie de ce bloc soit utilisé par votre serveur et ses services et un second bloc soit utilisé par les clients VPN.
En clair vos clients quand ils communiqueront sur internet via le VPN ils auront une adresse IP comprise dans le bloc assigné à votre serveur. Et chaque client aurait une adresse IP différente.
Si votre serveur VPN à l’adresse IP 2001:dead:dead:dead::/64 votre client sera visible sur internet par 2001:dead:dead:dead::10:1
Cependant le routeur de votre serveur doit avoir connaissance de ces nouvelles IP pour pouvoir les router.

C’est la qu’entre en jeu le proxy NDP. Vous avez deux choix, soit à chaque nouveau client créer un nouveau proxy pour la nouvelle adresse IPv6. Soit installer ndpd pour proxifier tout le subnet qui va être réserver au VPN.
Pour plus d’informations : Lien

Cette solution est celle la plus courante sur internet, mais je suis pas fan que de l’extérieur on puisse faire une différenciation entre 2 de mes clients (vu qu’ils auront une adresse IP externe différente). En plus cela demande de surcharger le routeur. Et pour en finir avec cette solution, notre client va avoir tout ses services exposés sur internet. Tout les ports de son PC seront directement accessible depuis internet.
L’idée est donc de faire comme IPv4, utiliser du NAT. On va donc utiliser des adresses IPv6 de type Unique Local Address, elles sont comparables aux adresses privées d’IPv4, elles ne sont pas routables.

NAT ne sécurise pas votre réseau, il ne remplace pas un parfeux sur votre client. De plus le processus NAT fonctionne avec des tables de conversions et augmente la latence contrairement à la solution de proxy NDP.

Authentification des clients

Il est possible de limiter l’accès au serveur VPN, plusieurs solutions existent :

• Par mot de passe
• Par certificats

Généralement on chiffre les communications entre le client et le serveur. Ce chiffrement est habituellement du TLS, il y a donc déjà des certificats qui sont utilisés pour le chiffrement. Il est donc très simple d’utiliser ces certificats pour authentifier le client. Mais il est possible aussi de demander un couple utilisateur/mot de passe.
L’authentification par mot de passe est moins sécurisé car le « secret » est beaucoup plus court. A un potentiel sens (si vous avez un mot de passe faible). Et pour d’autres raisons plus complexes.

L’authentification par certificats se faire à l’aide de signatures.
Pour cela vous avez besoin d’un CA (Certification Authority). Nous allons signer tout nos certificats client avec ce CA. Et le serveur va vérifier que le certificat du client est bien signé par le CA. Si c’est le cas, le client sera autorisé, sinon la connexion se verra rejetée.
La technique de signature est assez complexe, je ne vais pas rentrer dans les détails, mais utilise la notion de clée privé/publique et est sûre.
Vous pouvez soit générer votre propre CA, à ce moment le client doit connaitre la clée Publique du CA. Si vous payez pour utiliser un CA reconnus. A ce moment votre système d’exploitation à déjà la clée Publique de ce CA.

Quand vous naviguez sur internet en https vous pouvez des fois voir « Votre connexion n’est pas privé ». En réalité cela veut dire que le site sur lequel vous naviguez utilise un certificat TLS qui n’a pas été signé par un CA reconnus (certificat auto signé).

Spécification de la configuration

Je vais donc vous présenter comment utiliser le protocole VPN à l’aide du logiciel OpenVPN.

• Cette configuration va chiffrer les communications entre le serveur et le client à l’aide de TLS.
• L’authentification se ferra à l’aides des certificats.
• Le serveur sera configuré pour router les paquets IPv6 ET IPv4 du client vers internet (pour cacher son adresse IP).
• Le serveur sera accessible en IPv4 ET en IPv6.
• Le client auras toujours la même adresse IP sur le réseau VPN.

Malgré tout, je vais vous donner toutes les informations requises pour faire ce que bon vous semble.

Installation d’OpenVPN

C’est donc partis !

apt-get install openvpn

C’était compliqué, avouez-le ! Malheureusement c’est pas comme apache, toute la configuration est à faire par vos soins. Rien n’est pré configuré. On va donc faire tout ça.

Configuration d’OpenVPN

Création des certificats

OpenVPN se base sur des certificats pour le chiffrement, on va donc créer tout les certificats nécessaires. Pour simplifier la génération de ces derniers nous allons utiliser Easy-RSA

apt-get install easy-rsa
cd /etc/openvpn
cp -R /usr/share/easy-rsa/ /etc/openvpn
cd easy-rsa
vim vars

L’édition de ce fichier permet de modifier les valeurs par défaut lors de la génération de certificats, très utile si vous allez générer de nombreux certificats.
Modifiez KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, KEY_EMAIL, KEY_OU et KEY_NAME par ce qui vous convient.
Voici ce que j’ai mis :

export KEY_COUNTRY="FR"
export KEY_PROVINCE="Nord-Pas-De-Calais"
export KEY_CITY="Roubaix"
export KEY_ORG="RMFB"
export KEY_EMAIL="openvpn@angenieux.info"
export KEY_OU="VPN"

# X509 Subject Field
export KEY_NAME="OpenVPN"

Il faut ensuite charger ces variables et générer les différents certificats :

. ./vars
# On supprime les clées si il y en avait
./clean-all
./build-ca

Résultats de la dernière commande :

Generating a 2048 bit RSA private key
.....................++++++
...++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Nord-Pas-De-Calais]:
Locality Name (eg, city) [Roubaix]:
Organization Name (eg, company) [RMFB]:
Organizational Unit Name (eg, section) [VPN]:
Common Name (eg, your name or your server's hostname) []: ca-openvpn
Name [OpenVPN]:
Email Address [openvpn@angenieux.info]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Laissez tout par défaut, pour le common name entrez « ca-openvpn ».
Je vous recommande de définir une passphrase pour le CA. Cette passphrase sera demandé à chaque fois que vous aller signer un nouveau certificat.

Si vous oubliez cette passphrase vous pourrez continuer à utiliser OpenVPN mais vous ne pourrez plus créer de nouveaux certificats ni révoquer des certificats.

Un CA va signer les certificats, si on fait confiance à un CA. On fait confiance a tout les certificats signés par ce CA. OpenVPN va donc autoriser l’accès a tout les possesseurs de certificat signé par le CA que nous venons de créer.

./build-key-server server

Vous pouvez tout laisser par défaut.

Je vous conseille de ne pas utiliser de passphrase, ce sera moins sécurisé mais vous pourrez au moins démarrer votre serveur OpenVPN au démarrage de votre serveur physique. Sinon à chaque démarrage votre serveur demandera la passphrase pour pouvoir accéder au la clée privée du certificat du serveur.

Ensuite il nous reste à générer les certificats pour nos différents clients via cette commande :

./build-key client1

Cette commande permet de créer un certificat signé par le CA avec comme common name client1.
Vous pouvez personnaliser le certificat pour qu’il corresponde au mieux à l’utilisateur.
Le nom (client1 ici) est très important car il permet de désigner l’utilisateur. Je vous recommande d’utiliser des nom comme : « remi-pc« .

Il faut ensuite générer les paramètres Diffie-Hellman, cette étape peut être très longue !

./build-dh

Il est possible qu’un jour vous aller supprimer un utilisateur, ou bien supprimer un certificat car il a été compromis (clée privé divulguée publiquement). On va donc créer un fichier contenant les certificats révoqués. Pour cela on va créer un certificat puis le révoquer.

./build-key revoked
./revoke-full revoked

Le “error 23” a la dernière ligne est normal. Cela indique que la vérification du certificat révoqué à échoué, c’est ce que nous voulons.

Cette manipulation a créé un fichier keys/crl.pem que nous allons utiliser plus tard.

Je vous conseille de garder le dossier /etc/openvpn/easy-rsa comme dossier pour créer et révoquer des certificats, vous y accéderez en root. Et copier les certificats utiles à OpenVPN dans le dossier /etc/openvpn. Ces dernier fichiers seront uniquement accessibles a l’utilisateur système :

addgroup --system openvpn
adduser --no-create-home --system --disabled-login --ingroup openvpn --home /etc/openvpn openvpn
chmod 700 /etc/openvpn/easy-rsa
cp /etc/openvpn/easy-rsa/ca.crt /etc/openvpn/ca.crt
cp /etc/openvpn/easy-rsa/server.crt /etc/openvpn/server.crt
mkdir cp /etc/openvpn/private
chmod -R 700 /etc/openvpn/private
cp /etc/openvpn/easy-rsa/server.key /etc/openvpn/private/server.key
cp /etc/openvpn/easy-rsa/dh2048.pem /etc/openvpn/dh2048.pem
cp /etc/openvpn/easy-rsa/crl.pem /etc/openvpn/crl.pem
chown -R openvpn:openvpn /etc/openvpn/private/
chown openvpn:openvpn /etc/openvpn/dh2048.pem /etc/openvpn/crl.pem /etc/openvpn/server.crt /etc/openvpn/ca.crt

Configuration du serveur

Je vous conseille de partir de la configuration d’OpenVPN fournie en exemple.
Pour cela faites :

zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf

Pour utiliser la configuration que je vous proposer il faut créer le dossier clientstatic. Il va permettre d’assigner un adresse IP fixe aux clients.

mkdir /etc/openvpn/clientstatic
chown openvpn:openvpn /etc/openvpn/clientstatic

Voici mes modifications au fichier server.conf :

# Si vous voulez vous connecter a votre serveur OpenVPN uniquement en IPv4 mettez
# "proto udp". Si vous voulez que votre serveur soit accessible en IPv4 ET en IPv6 laissez "proto udp6"
# Vous pouvez aussi utiliser le protocole tcp. Il sera moins rapide mais plus fiable si vous avez beaucoup de
# pertes de paquets : "proto tcp6" ou "proto tcp"
proto udp6

# Il est aussi possible de faire du TAP
dev tun
# On ne veut pas une topologie p2p mais bien qu'il y ait un réseau entre notre serveur et
# notre client
topology subnet

# Pour indiquer à TLS que ça va être le côté serveur
tls-server
# Chemin vers notre CA
ca /etc/openvpn/keys/ca.crt
# Chemins vers la clée privée et la clée publique du serveur
cert /etc/openvpn/server.crt
key /etc/openvpn/private/server.key
dh /etc/openvpn/dh2048.pem
# A chaque connexion le serveur va vérifier que le certificat n'est pas révoqué
crl-verify /etc/openvpn/crl.pem
# Réseau IPv4 créer pour les interfaces VPN
server 10.8.0.0 255.255.255.0
# Réseau IPv6 créer pour les interfaces VPN
# Il est possible d'utiliser n'importe quel réseau qui commence par fd.
# Cela corresponds aux réseau ULA. (voir plus haut).
server-ipv6 fd42:feed:feed:feed::/64
# Créé l'interface TUN IPv6 sur le serveur
tun-ipv6
# Pousse la création de l'interface TUN IPv6 sur le client
push tun-ipv6
# Pousse la création de la route en destination de réseau local VPN
push "route-ipv6 2001:41d0:2:bb7:80::/64"
# Pousse la création de la route redirigeant tout le trafic internet vers le VPN
# On utilise pas "default" pour ne pas écraser la passerelle IPv6 par défaut.
# Vu que cette route est plus précise que default, elle sera utilisée pour le
# routage de tout les paquets internet. Pour rappel toutes les IPv6 routables sur
# internet sont 2000::/3
push "route-ipv6 2000::/3"
# Permet d'avoir un adressage statique de nos client
# Chaque client aura une adresse IPv4 et IPv6 fixe.
client-config-dir /etc/openvpn/clientstatic
# Permet de garder les même adresses IP, même après une déconnexion.
# Ici cela est une sécurité, si on a oublié de donner une adresse IP fixe à un client
# ce dernier ne risquera pas d'être en conflits avec un adresse IP déjà utilisé.
ifconfig-pool-persist ipp.txt

# Permet de rediriger tout le trafic internet vers notre serveur VPN
push "redirect-gateway def1 bypass-dhcp"
push "redirect-gateway ipv6" # Pour iOS

# Vu que le DNS de votre FAI n'est pas accesible par votre serveur VPN.
# Il faut que les requêtes VPN se fassent sur des serveur DNS publiques.
# Ici c'est du OpenDNS
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
# Si vous avez openvpn => 2.4
push "dhcp-option DNS6 2620:0:ccd::2"
# Sinon
;setenv "ipv6dns 2620:0:ccd::2"
# Permet d’exécuter OpenVPN sur un utilisateur disposant de moins de droits.
# Nous avons créer cet utilisateur/groupe juste avant.
user openvpn
group openvpn

# Utilise le module login de PAM
plugin openvpn-auth-pam.so login
# On ne veut plus vérifier l'utilisateur via son certificat
verify-client-cert none
# Permet d'utiliser l'adressage IP fixe malgré tout
username-as-common-name
Plus d'informations disponibles à ce lien (en).

Pour chaque client/certificat vous allez devoir créer un fichier dans /etc/openvpn/clientstatic.
Voici un exemple de mon user remi-pc (/etc/openvpn/clientstatic/remi-pc) :

# Ces adresses doivent être dans le range définis par server ou server-ipv6
ifconfig-push 10.8.0.10 255.255.255.0 # IPv4
ifconfig-ipv6-push fd42:feed:feed:feed::10/64 # IPv6

Configurer syslog

Par défaut tout les logs sont envoyés vers syslogs, mais on peut souhaiter de rassembler les logs d’OpenVPN.

mkdir /var/log/openvpn
vim /etc/rsyslog.d/openvpn.conf

if $programname startswith 'ovpn-' then /var/log/openvpn/openvpn.log

service rsyslog restart

Configurer logrotate

Le fichier risque de grossir vite, il faut donc mettre en place un logrotate.
Créez le fichier /etc/logrotate.d/openvpn :

/var/log/openvpn/openvpn.log
{
    # On change de fichier toutes les semaines
    weekly
    # On garde 1 an de log
    rotate 48
    # Permet au processus de ne pas s'arrêter à chaque erreur et de poursuivre avec le fichier de log suivant.
    missingok
    # Empêche la rotation de s'effectuer si le fichier de log est vide.
    notifempty
    # Ne compresse pas les fichiers les plus récents
    delaycompress
    compress
}

Démarrer OpenVPN au boot

La commande va dépendre du nom de votre fichier de configuration. Moi j’ai garder le nom par défaut, soit server.conf. La commande est donc :

systemctl enable openvpn@server.service

Et si vous voulez démarrer le serveur c’est :

systemctl start openvpn@server.service

Configuration du client

Déjà il faudra transférer les fichiers /etc/openvpn/easy-rsa/keys/remi-pc.crt et /etc/openvpn/easy-rsa/keys/remi-pc.key vers le client. Utilisez un protocole de transfert sécurisé tel que SSH, ou FTPS. Il ne faut pas que le fichier remi-pc.key soit divulgué. Il contient votre clée privée, si quelqu’un récupère ce fichier, cette personne pourra se faire passer pour vous.
Vous aurez aussi besoin de copier le fichier /etc/openvpn/easy-rsa/keys/ca.crt

Je vous conseille de partir de la configuration d’OpenVPN fournie en exemple.
Cette configuration se situe a l’emplacement : /usr/share/doc/openvpn/examples/sample-config-files/client.conf

Sur Windows il faudra changer l’extension en .ovpn

Limitez l’accès au fichier remi-pc.key. Si vous êtes sur un PC partagé ne mettez pas ce fichier dans le dossier de configuration général mais dans le dossier de votre utilisateur.
Réduisez les droits de lecture sur ce fichier au strict minimum, c’est à dire « vous ».

Voici mes modifications du fichier client.conf :

client
# Vu qu'on a choisi TUN su le serveur
dev tun
# Vu qu'on a choisi UDP sur le serveur, sinon changez
# Si vous voulez vous connecter en IPv6 a votre serveur changer udp en upd6 ou en tcp6
proto udp
# Changer la valeur par l'adresse IPv4 ou IPv6 de votre serveur
remote 8.8.8.8
persist-key
persist-tun
# Indique à TLS que vous êtes du côté client
tls-client
# Chemin vers le fichier ca.cert que vous venez de télécharger (non requis en cas d'authentification par mot de passe)
ca ca.crt
# Chemin vers le fichier remi-pc.cert que vous venez de télécharger
cert remi-pc.crt
# Chemin vers le fichier remi-pc.key que vous venez de télécharger
key remi-pc.key
# Pour augmenter la sécurité on peut vérifier que le certificat du serveur est bien un certificat de type serveur.
# Permet de réduire les risques de "man in the middle".
remote-cert-tls server
# Pour éviter l'usurpation de votre serveur il est possible de vérifier des informations
# du certificat du serveur.
# Pour vérifier le CN (CommonName) du certificat du serveur utilisez la commande :
;verify-x509-name CNDuServeur name
# Dans notre cas ça sera "server"
# Si vous voulez vérifier tout les champs du certificat vous pouvez utiliser :
; verify-x509-name 'C=FR, ST=Nord-Pas-De-Calais, L=Roubaix, O=RMFB, CN=server, name=OpenVPN, emailAddress=openvpn@angenieux.info'

Routage

On a un serveur OpenVPN fonctionnel qui fournis des adresse locales en IPv6 et IPv4 et pousse aussi des DNS. Mais nos paquets ne sont pas router vers internet. On va donc changer ça !

Activer les fonctions de routage dans le kernel :

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv6.conf.all.forwarding=1

Pour que ces options soient permanentes, pas supprimées après un reboot, modifiez le fichier /etc/sysctl.d/10-routing.conf

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Masquerade/NAT

Nous allons maintenant mettre en place le NAT

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
ip6tables -t nat -A POSTROUTING -s fd42:feed:feed:feed::/64 -o eth0 -j MASQUERADE

Il faudra modifier les adresses pour que cela corresponde aux adresses de réseau privé que vous avez configuré sur le serveur.
Je pars du principe que votre serveur est connecté à internet via eth0.

Si vous voulez garder ces règles en cas de reboot de votre serveur, je vous redirige vers cet article.

Si vous utilisez des Dirty protocols tel que Bittorent, vous aurez besoin de faire de la translation de port. Je vous redirige vers cet article.

L’article OpenVPN IPv4/IPv6 en NAT (sans NDP) est apparu en premier sur RMFB - Read My F-Blog.

Il vaut donc mieux changer votre port d’écoute SSH car c’est le service le plus critique. Mais aussi configurer votre firewall. Le mieux étant de rester très restrictif.

Je vais vous proposer ici une configuration qui va par défaut drop (ne pas répondre) les paquets. Puis nous allons lister tout les ports que nous voulons garder ouvert.

Listes les services présent sur votre serveur

Nous allons bloquer tout le trafic entrant, il faut donc savoir quels sont les ports en écoute sur le serveur, pour autoriser le trafic en destination de ces ports.

netstat -tulpn | grep LISTEN

Je vous conseille de vérifier tout les services, il est possibles que votre serveur héberge des services que vous ne voulez pas rendre disponible sur internet.

Configuration

Pour pouvoir vous souvenir de pourquoi vous avez mit telle au telle ligne, je vous conseille de faire un fichier bash qui va contenir toutes les insertions de règles.

Si vous perdez votre connexion SSH vous pourrez toujours redémarrer votre machine (en hard si vous avez accès sinon via le panel de votre hébergeur), toutes les règles ne seront pas reéxécutés.

C’est une configuration en IPv4, la même chose est a faire en IPv6 avec la commande ipv6tables !

#!/bin/sh
IPT="/sbin/iptables"

# Supression des anciennes regles pour que celles presentes soient appliques
$IPT --flush
$IPT --delete-chain
$IPT -t nat --flush
$IPT -t nat --delete-chain

# Regles par defaut
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT # On choisit la solution de facilité et on permet au serveur d'accéder a tout le monde extérieur. Une meilleure pratique est de bloquer la sortie de certains paquets qui pourraient être émis en cas de compromisation de votre serveur. Ce qui permanenterait de réduire les attaques possible à partir de votre serveur.

# Aucune restriction sur l'interface de loopback
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# All TCP session

# Oblige que les paquets TCP commencent pas une connexion (comportement normal de TCP)
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# On accepte tout les paquets qui proviennent d'une session TCP déjà établie.
# Si le serveur ouvre une connexion TCP vers un destination extérieur, via
# cette commande, la réponse ne sera pas DROP.
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p tcp --dport 20 -j ACCEPT # ftp-data
$IPT -A INPUT -p tcp --dport 21 -j ACCEPT # ftp
$IPT -A INPUT -p tcp --dport 22 -j ACCEPT # SSH
$IPT -A INPUT -p tcp --dport 80 -j ACCEPT # http
$IPT -A INPUT -p tcp --dport 443 -j ACCEPT # https

# Accepte les paquets ICMP (pour la configuration des protocoles de routage internet comme BGP
# ICMP ping est utilisé, nous autorisons donc les pings)
$IPT -A INPUT -p ICMP --icmp-type 8 -j ACCEPT

Valider votre configuration

Faites bien tout les tests de tout vos service pour être bien sur que tout est bon. Une fois le cas il vous reste plus qu’a rendre cette configuration permanente (après un reboot iptables reprendra la configuration que vous avez mise).

Sauvegarder votre configuration

Pour sauvegarder votre configuration (vérifiez bien avant que tout est bon !).
Vous aurez besoin de la commande iptables-save.
Vous devez l’installer via.

apt-get install iptables-converter

ou

apt-get install iptables-persistent

mkdir /etc/iptables
iptables-save > /etc/iptables/rules

Cela permet de sauvegarder les règles iptables dans le fichier /etc/iptables/rules

Nous allons maintenant faire un script pour charger ce fichier. Pour cela on va utiliser un hook présent dans ifconfig. Avant que les interfaces réseaux soit disponibles (montées), nous allons charger les règles iptables.

Créez un fichier /etc/network/if-pre-up.d/iptables et mettez cette commande dedans :

#!/bin/sh
/sbin/iptables-restore < /etc/iptables/rules

N’oubliez pas de donner les droit d’execution a ce nouveau fichier et tout est bon !

chmod +x /etc/iptables/rules

L’article Installation et configuration d’un firewall Iptables est apparu en premier sur RMFB - Read My F-Blog.

Général

:q close
:w write/saves
:wa[!] write/save all windows [force]
:wq write/save and close
:x save and quit, same as wq
:q! force close if file has changed and not save changes
v Enter visual mode for selection of LINES
C-v Enter visual mode for selection of BLOCKS
y Yank/copy selected region
yy Yank/copy entire line
"y Yank/copy marked region into register (register from a-z)
c Cut selection
p Paste yanked content
"p Paste yanked content in register (from a-z)
P Paste yanked content BEFORE
u Undo
C-r Redo
:! Execute shell command
C-z send vim to background (fg brings it to front again)

Insert mode

a Append text after the cursor
A Append text at the end of the line
i Insert text before the cursor
I Insert text before the first non-blank in the line
o Begin a new line BELOW the cursor and insert text
O Begin a new line ABOVE the cursor and insert text
s Erase the current letter under the cursor, set insert-mode
S Erase the whole line, set insert-mode
cc Delete the current line, set insert-mode
cw Delete word, set insert-mode
dd Delete line under curser

Commandes

:syntax on
:set number Affiche les numéros de ligne

L’article Raccourcis VIM est apparu en premier sur RMFB - Read My F-Blog.

De ce côté je vais rien vous apprendre, on utilise apt :

apt-get install mysql-server

Lorsque l’installateur vous demander de rentrer le mot de passe superutilisateur de mysql (root) ne mettez surtout pas de caractères spéciaux car sinon vous pourrez pas vous connecter. C’est assez étrange mais bon.

Configuration

Une bonne pratique est de sécuriser votre serveur tout de suite. Pour cela exécutez la commande :

mysql_secure_installation

Rentrez votre mot de passe utilisé lors de l’installation

Si vous avez utilisé des caractère spéciaux ils seront reconnus ici mais pas lors de la connexion a la base de donnée.

Répondez « oui » a toutes les questions pour augmenter au mieux la sécurité.

Création d’un utilisateur

Pour cela on va le faire en SQL, on va donc se connecter en tant que root (utilisateur mysql) pour entrer nos requêtes.

mysql -u root -p

Il suffit ensuite de créer notre nouvel utilisateur comme cela :

CREATE USER "nom_utilisateur"@"localhost";
SET password FOR "nom_utilisateur"@"localhost" = password('mot_de_passe');

Si vous voulez créer une table où il a tout les droits (pas recommandé)

GRANT ALL ON nom_base.* TO "nom_utilisateur"@"localhost";

L’article Installation d’un serveur MySql est apparu en premier sur RMFB - Read My F-Blog.

Iptables

Cas d’utilisation des différentes chaines Iptable

Maintenant que nous une adresse IP statique côté client il faut faire la redirection de port. On va donc travailler dans la table NAT et dans la chaine PREROUTING car c’est la chaine qui permet de modifier une adresse IP/port destinataire.

Ce qui donne cette commande :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 32936 -j DNAT --to-destination 10.0.0.6:32936

Là ça transforme tout les paquets TCP a destination de votre serveur OpenVPN et avec le port destination 3296 en un paquets qui auras pour destination 10.0.0.6 et pour port 32936. Puis le paquet va être routé via la table de routage de votre serveur OpenVPN.

Vous pouvez remplacer TCP par UPD.
Bittorent utilise UDP ET TCP

Vous avez donc bien fait votre redirection de port !

L’article Ouvrir/translation des ports derrière OpenVPN est apparu en premier sur RMFB - Read My F-Blog.

La solution, mettre en place un point de montage

mount --bind /home/dossier/reel/a/partager /home/dossier/d/acces/au/dossier/paratge

Et voilà maintenant ça marche !

Maintenant à vous de vous amuser avec les droits UNIX pour faire ce que vous voulez

L’article FTP – mettre en place des dossiers partagés est apparu en premier sur RMFB - Read My F-Blog.